IN CONFIDENCE. UK IPv6 Council: 464xlat for mobile operators 25 th September

Transcription

1 IN CONFIDENCE UK IPv6 Council: 464xlat for mobile operators 25 th September

2 Why IPv6 in cellular networks? Major reason - Avoiding IPv4 private address exhaustion Increase in users of data, leading to increasing numbers of addressing, driven by: > Customers demand (always connected) > Customers devices (LTE, always IP) > Number of addresses per customers (incl. VoLTE/IMS, tethering additional devices) Long term strategy, including IoT driving addressing demands Other benefits - Advantage of global addressing of IPv6 Avoiding IPv4 Public address exhaustion Cost avoidance for national regulatory obligations Long term strategy including 5G-Convergence British Telecommunications plc 2017 EXTERNAL BT

3 Mobile Operators have seen successful IPv6 transitions with 464xlat 464xlat (rfc6877): Translation based (i.e. NAT, CGN, already extensive in mobile) Avoids IPv4 Exhaustion; Eligible devices effectively IPv6-only as operator runs IPv6-only access/core network 464xlat (rfc6877) makes use of: stateful NAT64 (rfc6146), stateless client ( CLAT, as per rfc6145) Traffic of ~100Millions of mobile customers: T-Mobile (US) Sprint(US) Reliance Jio (IN) Orange (PL) SK-Telecom(SK) Telstra(AU) Rogers(CA) EE(UK). NAT64 prefix discovery, (currently rfc7050 which uses DNS64) DNS64 (rfc6147) can be scoped for discovery or as part of a wider NAT64/DNS64 regime. British Telecommunications plc 2017 EXTERNAL BT

4 EE MOBILE USECASES IPv6 +464xlat IPv6 1. Voice/IMS OPERATOR VOICE OVER IP / LTE / WIFI IMS APN IMS CELLULAR RADIO OPERATOR NETWORK 2a. Data DATA FROM INTERNET OR OPERATOR SERVICE 2b. Tethered Data WIFI TETHERING FROM HANDSET Operator Services INTERNET APN Internet 3. Mobile Broadband MYFI OR DONGLE CELLULAR RADIO OPERATOR NETWORK TETHERED DEVICE EXTERNAL. BT. NICK HEATLEY, NETWORK ARCHITECT WIFI CELLULAR DEVICE 25/09/2018 4

5 Technology Selection 464xlat has been the deployment choice of cellular operators, for whom 20 Million private IPv4 are not sufficient Cellular Requirements How they fit to 464xlat 1. Be clear on Goals Many cellular operators goals: Avoid private IPv4 exhaustion Target is zero calls into customer services Must be supported on handset OS IPv6-only on handsets. Dualstack won t do 2. Know your usecases 3. Exception handling Mobile usecases, handsets + tethering: Suited to NAT (encapsulation breaks 3GPP PCC architecture) Unrestricted end devices, and services they access Strategy to include: Devices without 464xlat support Business Customers, customers who don t want IPv6, roaming 5. Start tests/trials NAT Translation + solution for literals A Single APN supporting IPv4 OR IPv6 4. Business Case For cellular operator using NAT: Move to IPv6 + NAT64 Save on 65% of NAT load A single CGN running NAT44 & NAT64 Future: MAP-T? Missing support in mobile handset OS IETF looking at alternatives for prefix discovery. 5 British Telecommunications plc 2018 IN CONFIDENCE

6 HOW 464XLAT FIXES IPV4-BOUND APPS IPV6-ONLY WITH 464XLAT (RFC6877) Device Apps Agnostic IPv6-only Single Stack Bearer Content Lookup DNS lookup 1b 2b v6 destination IPv6 address DNS DNS 64 V6 FW Case1b. Following DNS lookup, v6 dest selected. Pure IPv6 direct. Case2b. As destination is IPv4 only, DNS64 synthesises v6 DNS response with v6 destination of the NAT64 gateway. NAT64 based connection. Case3b. IPv4 bound app sends via v4 XLAT stack; 464XLAT CLAT immediately translates to v6 with destination of NAT64 gateway. IPv6 connection IPv6 Content IPv4-bound 3b v4 destination CLAT NAT 64 IPv4 connection IPv4 Content 2a. Data 2b. Tethered Data Related IETF RFCs RFC xlat translation RFC7050 auto discovery of NAT64 prefix RFC7335 spoof IPv4 address for CLATs RFC7278 V6 Prefix sharing on WiFi EXTERNAL. BT. NICK HEATLEY, NETWORK ARCHITECT 25/09/2018 6

7 Apple and Android Both Android and Apple (from ios12) make use of 464xlat, implementations are different. TETHERING (via single APN) ios12 invokes 464xlat for tethering ON-BOARD APPs Apple App-store ecosystem immunised against IPv4 literals: Police the Apps to ensure no literals Fix other literals/server-side: Happy Eyeballs v2 (RFC8305) A bump-in-the-host approach; let the OS help repair literals; clients can perform synthesis of NAT64 destinations (RFC6050) themselves (after the NAT64 prefix is discovered e.g. RFC7050) TETHERING (via single APN) Tethering interface mapped via 464xlat (CLAT) ON-BOARD APPs Android Android uses 464xlat for any apps or server-calls bound to a IPv4-stack 7 British Telecommunications plc 2017 EXTERNAL BT

8 External to ISP Content side Related Limitations 1. DNS64 NAT64 prefix discover only (rfc7050) Obvious 464xlat uses NAT, which can hinder certain protocols/services e.g. gaming. Direct IPv6 DNS64 Prefix discovery IPv6 Less obvious 464xlat URL IPv4 content -A record DNS64 hinders DNSSEC DNS64 can hinder content that mixes URL and literal access (where source address expected to be same) 2. DNS64 - Full scope Literals IPv4 literals DNS64 Deployment choices See diagram: 1. for prefix only, relying fully on 464xlat, or 2. full scope. DNS64 is a hack, so why not remove it? Less bad customer experience than a device with no 464xlat. In all cases enabling IPv6 on content avoids DNS64/NAT64 issues. 8 British Telecommunications plc 2017 Direct IPv6 DNS64 464xlat DNS64 Prefix discovery EXTERNAL BT IPv6 URL Literals IPv4 content -A record IPv4 literals

9 Thank you Any questions? Nick Heatley, BT Network Architect Chief Architect s Office British Telecommunications plc 2018

10