The intended audience is Mobile Packet Core engineers that wish or need to deploy IPv6.
3GPP networks is an acronym rich field. For more general audiences RFC 6459 is an excellent primer.
The introduction of IPv6 to the 3GPP Standards and Mobile Networks
The 3GPP maintains the standards for General Packet Radio Service (GPRS) based 2G/3G wireless access networks and its System Architecture Evolution (SAE) for LTE and LTE-Advanced wireless access. 3GPP Release 8 introduced Evolved-UMTS Terrestrial Radio Access (E-UTRA), which is designed to provide a single evolution path for many different radio access technologies: GSM/ EDGE, UMTS/ HSPA, CDMA2000/ ED-VO, TD-SCDMA to LTE and beyond. Release 8 defines a new Evolved Packet Core (EPC) which must be implemented when deploying LTE access.
IPv6 was first introduced into the 3GPP standards with release 99 (in year 1999) but was not widely implemented by equipment vendors or deployed by Mobile Network Operators.
3GPP Release 9 is considered a minor update to Release 8 but it introduced support in GPRS for dual-stack IPv4v6 PDP contexts on a single shared radio access bearer. Release 9 also resolved the anomalous situation with Release 8 where dual-stack was supported for LTE access but not supported for GPRS access. Others are of the view that the anomaly was with software implementations of the standards. In any case all new equipment is free of the problem. Release 10 introduced DHCPv6-PD to the standards.
User and Transport Planes
IPv6 must be enabled in the user-plane so that subscribers can start using the IPv6 Internet. This is the PDP/PDN bearer from the mobile device to an IP gateway in the Mobile Network Operator's core network. Operators and equipment vendors are therefore prioritising the deployment of IPv6 in the user-plane.
User IP traffic from the mobile device (User Equipment) is in a separate logical user-plane transported over the network. The transport, signalling, OAM, or charging interfaces within the network are hidden from the User Equipment (UE) and initially can continue to use IPv4 while the user-plane is providing IPv4v6 or IPv6 (with IPv4 translated through a local NAT46 clatd) connectivity to the subscriber. Many newer Release 9 networks will have user-plane IPv6 enabled by default even though they have not configured their GGSN/PGWs to assign IPv6 /64s & their HLR/HSS subscriber profiles to allow IPv6 PDP/PDN bearers. It is also important that user-plane IPv6 is allowed for visiting subscribers to get back to their home network that has adopted IPv6. In June 2014 Telenor of Norway started roaming by default using IPv6 for customers with the Samsung S5.
The Radio Access Networks & Mobile Packet Cores
The SGSN and GGSN are the core network elements for GERAN/UTRAN (2G/3G) APN access.
The SGW, PGW and MME are the EPC network elements for E-UTRAN (LTE) APN access.
Real nodes combine these functions to support multiple RAN and core types. For example the SGSN-MME and S/P-GW are common combinations. To ensure data session continuity the GGSN function is also combined with the P-GW function so that there is a common anchor point for the PDP/PDN connection.
PDN Types must match when inter-SGSN RAU (Routing Area Updates) or intra-RAT (Radio Access Technology) handovers for the mobile UE (User Equipment) takes place. All SGSN/MMEs where this can occur in an operator's network must therefore be on Release 9 compliant software for PDP/PDN Type IPv4v6 to be possible.
The PGW (also known as the PDN-GW) is the EPC network element that assigns the IP addressing information to the mobile UE. Individual IPv4 addresses are assigned and/or an IPv6 /64 prefix is assigned.
Typically the addresses or prefixes come from pools configured in the PGW. They may also however come from other sources such as the HLR/HSS, PCRF or RADIUS AAA server.
To facilitate inter-RAT the PGW may also support GGSN functionality if a Gn/Gp SGSN is used initially instead of an S4-SGSN. See 3GPP TS23.401 Annex D (GPRS enhancements for EUTRAN access, Release 9).
SLAAC is used to assign the prefix to the UE, therefore only a /64 prefix can be used. This is prefix size not a configuration option because SLAAC mandates that it be /64. The host bits should change with each connection. DoS protection against attacks on the /64 may be implemented.
3GPP Release 10 allows the UE to request a delegated prefix (IA_PD) using DHCPv6. Note that UEs do not yet implement support for DHCPv6-PD.
Single or Dual-Stack PDP/PDN Bearers
PDP/PDN bearer may be: IPv4 (the existing legacy setting), IPv4v6 (Dual-Stack in a single radio bearer) or IPv6 (without a parallel IPv4 bearer, the target solution).
The transition guidelines of the IETF and 3GPP (TR23.975) is dual-stack first and then IPv6-only as IPv4 is phased out. However there are a couple of issues with dual-stack in 3GPP networks that do not apply to fixed networks (discussed further in this page). There are operators using IPv4v6 (e.g. Verizon Wireless) and IPv6-only (e.g. T-Mobile USA, Orange Poland, Telenor Norway) PDP/PDN bearers.
As the situation currently stands there are many operators with 2G/3G access networks on pre-release 9 and LTE access networks on release 8/9. This rules out the use of dual-stack PDP/PDN bearers in such PLMNs as session continuity (uninterrupted data access) during inter-Radio Access Technology (inter-RAT) handovers is not possible. This situation will improve with time as equipment is software upgraded or decommissioned, however it is currently the main networking issue preventing IPv4v6 PDP/PDN type roaming and inter-RAT handovers.
To make IPv6-only PDP/PDN bearer a viable migration strategy, the operator must provide NAT64/DNS64 service to the UE and the UE must support a RFC 6877 NAT46 clatd. The clat has been standard in Android since 4.4 (or 4.3 in T-Mobile USA's case) and it was introduced in Windows Phone 8.1. Apple iOS is the notable exception. Here is a video http://youtu.be/Xl-hIyZSAmA of Cameron Byrne from T-Mobile US talking about how they are using this to "break free" of IPv4.
Dual-Stack using two separate bearers
This is possible but it: consumes more radio resources, consumes more PDP licences, generates two sets of billing CDRs and can cause session continuity issues with LTE handovers where IPv4_OR_IPv6 is the allowed PDN type. Therefore it is not a desirable configuration for the network operator. To occur: the HLR configuration must allow IPv4 and IPv6 for the APN but not allow dual-stack within a single bearer, the RAN must allow multiple simultaneous radio bearers from the UE and the UE itself must set up separate PDPs for IPv4 and IPv6. This situation may occur where the HPLMN wants to provide home IPv6 access but does not have a means of preventing the sending PDP-Ext-Type (signalling dual-stack within a single radio bearer) to visited SGSNs. A Release 9 compliant HPLMN providing dual-stack within a single bearer is incompatible with roaming to a pre-release 9 visited SGSN that does not fall back gracefully to IPv4. The HLR/HSS needs the capability to allow separate home and roaming PDP/PDN protocol types to avoid these related problems.
vvvvvv CALLID MSID USERNAME IP TIME-IDLE------ -------- --------------- ---------------------- ----------------------------- ---------IUCNAI 160e0eec 27203---------- 35385-------@testdata 100.127.248.16 00h00m09sVUCNAT 160e0eed 27203---------- 35385-------@testdata 2a01:b340:ee0:e51:0:16:e0e:ed01 00h00m04s
The above GGSN/PGW CLI output shows two separate PDP bearers from a single UE (a Samsung S4 based on Android 4.4.2). The UE APN protocol was set to "IPv4/IPv6" and the HLR was set to allow both IPv4 and IPv6 bearers for the APN. In the HLR APN configuration the extended PDP indicator to allow dual-stack on single radio bearer was not set (see example of this in the HLR/HSS section below).
The Dual Address Bearer Flag
If all the SGSNs in an operator's network can support dual-stack PDP then the DAF flag should be set in the node properties of all the SGSN/MMEs concerned. Otherwise dual-stack PDN connections will not be brought up by the PGW. This is even if the HLR/HSS & PGW are configured for IPv4v6 and the mobile UE requests IPv4v6. Instead, the PGW may bring up an IPv4 or an IPv6 PDN bearer.
As IPv6 is deployed mobile operators will need to update their roaming agreements to indicate their ability to support visitors with IPv4v6 and/or IPv6 PDP/PDN connections. The GSMA RAEX IR.21 Roaming Database has fields to take this information. What seems to be happening in the real world is that operators are just doing it without comprehensively updating all their documentation.
They also need a way of controlling the PDP type signalled to visited SGSNs when their subscribers roam. Dual-stack is not possible in roaming situations where the visited pre-release 9 SGSN does not gracefully fallback to an IPv4 PDP session if it receives an Extended PDP type flag from the roaming subscriber's HLR. These problems are currently the subject of an Internet Draft in the IETF v6ops WG. Currently the 3GPP standards do not allow for per VPLMN subscriber profiles depending on the visited operator's ability to correctly handle IPv6. Since IPv4 and IPv6 PDP types were introduced to the standards at the same time support for IPv6 PDP is more widespread. Android provides an APN roaming protocol field which may be set to IPv4. In combination with a subscriber profile allowing IPv6 (used when home) and IPv4 (used when roaming) this Android APN configuration option provides a way for operators to deploy IPv6 at home for maximum impact and leaves the roaming issues for another day when IPv6 is more widely adopted by other PLMNs.
At least one (well known) HLR vendor has a feature to suppress the sending of the Extended PDP Type flag based on SGSN IP address but they have not made it a standard feature included without extra cost.
In at least one vendors SGSN/MME, user plane IPv6 needs to also be explicitly allowed in the case of another PLMNs subscribers visiting the network. It is more straightforward to make the network ready for visitors using IPv6 PDP/PDN connections than it is to allow the IPv6 friendly operator's own subscribers set-up an IPv6 PDP/PDN back to their home network.
The HLR uses SS7/MAP over the Gr interface to send the user profile to the SGSN.
An S4-SGSN uses Diameter and the S6d interface. The HSS uses Diameter and the S6a interface to send the LTE user profile to the MME.
An S4-SGSN is also likely to have been implemented with Release 9 support.
<hgppp:pdpcp=240;HLR PACKET DATA PROTOCOL CONTEXT PROFILE DATAPDPCP APNID EQOSID VPAA PDPCH PDPTY PDPID EPDPIND240 80 1 NO IPV4 25 NO76 1 NO IPV4 26 NO74 1 NO IPV4 31 NO73 1 NO IPV4 32 NO <-- testdata APN V473 1 NO IPV6 50 NO <-- testdata APN V6
The above HLR configuration example shows a single APN (ID = 73) with both IPv4 and IPv6 PDP allowed but the Extended PDP indicator (epdpind) not set. In this situation the desirable APN protocol setting in the UE is IPv6 instead of IPv4/IPv6 because of the reasons listed in the section on single or dual-stack bearers above.
The PDN type options in the HSS with LTE are better: IPv4, IPv6, IPv4_or_IPv6 and IPv4v6.
3GPP Release 10 clarified that when a user profile has PDP/PDN Type IPv4v6, types IPv4 or IPv6 are also allowed if requested by the mobile device.
Large-Scale or so-called Carrier Grade NAT
The use of NAPT44 is very widespread in 3GPP networks. Typically all subscribers will go through the provider NAT. Besides preventing end-to-end connectivity the NAT causes performance degradations such as limits on TCP ports and applications that are broken by NAT. With IPv6, customers get improved service as all applications using it end-to-end will bypass the restrictions of the NAT. As the deployment of IPv6 proceeds traffic growth through the NAT should slow and eventually start declining. There is a strong incentive to eliminate all legacy IPv4 applications in new devices in particular as otherwise NAT subscriber host state may continue to grow as billions more devices are added to the Internet.
Migration Strategies for the PDP/PDN IP Connection
|IP on link to UE||Main Pros||Main Cons|
|IPv4-only (Do Nothing)||Waiting while innovators and early adopters solve any remaining technical barriers to IPv6 adoption||Does nothing to solve the internal private IPv4 addressing problem|
|Increasingly inferior service for customers as the ratio of IPv6 to IPv4 grows|
|No cost savings from bypassing CGN|
|Missed opportunities/lost customers, no one wants to be last to adopt IPv6|
|IPv4v6 (Dual-stack)||iPhone/iOS works at home with it (with restrictions on roaming)||Does nothing to solve the internal private IPv4 addressing problem|
|Allows CGN bypass by IPv6 traffic||Dual-stack is not well supported when roaming. Fallback to IPv4 or proprietary features needed in HLR/HSS to workaround old pre-Release 9 visited Gn/Gp SGSNs that can't handle dual-stack in a single bearer|
|New opportunities/new customers||Retains all of the IPv4 network operations overhead and much of the resource consumption of IPv4|
|IPv6-only (using RFC6877 backwards compatibility for IPv4)||Solves the internal private IPv4 addressing problem||RFC6877 IPv4 "clat" not yet supported by Apple iOS|
|Stock Android 4.4+ works with it|
|Allows CGN bypass by IPv6 traffic|
|New opportunities/new customers|
Billing Domain & Charging
Mobile Packet Core elements (SGSN, GGSN, SGW, PGW) can all generate Charging Data Record (CDR) files which can be used, after further processing, for billing.
The SGSN produces S-CDRs, the SGW produces SGW-CDRs, the PGW can also produce PGW-CDRs.
There are a number of fields in the CDRs where IPv6 related information will appear. The mediation system which processes these CDRs for billing or a pre-processing script stage may be needed to deal with these minor changes to prevent the case of a 128-bit value being loaded into a 32-bit field. Usually the billing domain CDRs (e.g. TAP3) do not use the IP address information in the CDRs coming from the network elements. 3GPP TS 32.251 (Charging management; Packet Switched (PS) domain charging) describes the fields.
From Release 9, S-CDRs contain the following relevant fields, concerned with the mobile devices IP-CAN bearer.
IPv4, IPv6, IPv4v6, PPP, IHOSS:OSP
Served PDP Address
IPv4 address when PDP Type is IPv4, IPv6 address when PDP Type is IPv6 or IPv4v6
|Note this field can hold an 32 bit IPv4 or 128bit IPv6 address depending on PDP Type. A system processing this field may need to be updated accordingly|
Served PDP/PDN Address extension
|IPv4 address of the PDP when the PDP Type is IPv4v6||The generation of this field may be a configuration option (e.g. it is with Cisco Star OS)|
SGW-CDRs & PGW-CDRs contain 3 similar fields. The CDRs produced by the elements may be proprietary and not 3GPP compliant.
If on-line charging (e.g. using PCEF function in the PGW and the Gy interface) is used then the above CDR considerations mainly apply to roaming and the ability of the visited PLMN to process CDRs containing IPv6 addresses.
IMS & VoLTE
VoLTE implements VoIP using IMS instead of using Circuit Switched Fallback (CSFB). IPv6 support was in IMS from the start. It is straightforward to use IPv6 with VoLTE. IMS (GSMA IR.92) requires a separate APN from the Internet APN therefore the inter-RAT and roaming issues with Internet access APNs do not arise. IPv6 is mandatory with VoLTE. All VoLTE phones have Radio Interface Layers that support IPv6.
The evolution to VoLTE should act as a further stimulus to user-plane IPv6 deployment because the UE will require at least two IP addresses at the PGW, one for Internet access and the other for VoLTE.
Mobile Operating Systems
Android, Apple iOS, Windows Phone, Blackberry
|Operating System||Supported PDP/PDN APN Protocols||Separate Control of APN Roaming Protocol||RFC6877 NAT46 clat when APN Protocol is IPv6|
|Android 4.4*||IPv4, IPv4v6, IPv6||Yes||Yes|
|iOS 78.0||IPv4, IPv4v6||?||No|
|iOS 9.0||IPv4, IPv4v6, IPv6||?||No, but bump-in-API approach for IPv4 literals|
|Windows Phone 8.1||IPv4, IPv4v6, IPv6||?||Yes|
|SailfishOS/Jolla Phone||IPv4, IPv4v6, IPv6||No?||No?|
Android 4.4 and beyond has a 464xlat clat, running as a daemon, that works in combination with a NAT64 CGNAT box in the provider's network. It presents an IPv4 interface to the mobile device and other devices tethered off of it. Using the stateful translation algorithm of RFC 6145 IPv4 packets are translated into IPv6 packets so that they may be sent over an IPv6-only PDP/PDN connection. Note that these packets are translated, not encapsulated, it is easier for the charging functions in GGSN/PGWs to be agnostic to 464xlat translated IPv4 traffic or native IPv6 traffic. This has been verified in production networks. MAP-T also uses the translation algorithm of RFC6145 and has the advantage of distributing the NAPT state away from the CGNAT box to the access device. Unlike 464xlat there is no client implementation. It also needs a means of communicating the allowed port range to the client; such as PCP or DHCPv6.
3GPP TS 24.301 says LTE devices must first request IPv4v6 but in practice this is controlled by operator/carrier configuration files. In Android it may be edited and separate home and roaming PDP/PDN types may be set. However as mentioned in the roaming section above this functionality alone is not enough to deal with the problem of old SGSNs.
Apple iOS supports dual-stack tethering when the PDP/PDN connection is IPv4v6. It does not yet support the RFC 6877 464xlat clat necessary for use with an IPv6-only PDP/PDN connection.At WWDC 2015 Apple announced upcoming improvements in IPv6 support in iOS 9. App developers will be required to verify their App with IPv6-only and NAT64+DNS64. iOS 9 will work with IPv4 literals when using the NSURLSession API on a NAT64+DNS64 network. The API will bump in an IPv6 literal synthesized according to RFC 7050. They do not support under-the-sockets bump-in-API (RFC 3338) or 464XLAT (RFC 6877).
*The clatd was introduced in Android 4.3 but the phone needed to be rooted to add the /etc/clatd.conf configuration file or it needed to be an operator specific build (initially T-Mobile US).
Windows Phone 8.1 has recently introduced support for RFC 6877.
Discussion of Sailfish https://together.jolla.com/question/89966/use-dual-stack-ipv4-and-ipv6-on-mobile-data-by-default/ here.
Smartphone APN editing functionality that assists the transition to IPv6
Stock Android 4.4.2 is very IPv6 transition friendly and a number of operators consequently list smartphones based on it amongst the first devices that they support when deploying IPv6. e.g. The Google Nexus 5 and Sony Xperia Z. With these UEs it is possible to edit the APN protocol and APN roaming protocol in the APN settings. At the early stages of the transition being able to select IPv4 or IPv4/IPv6 APN protocol instead of IPv6 is conducive to supporting the small number of subscribers using IPv4 only VPN access protocols.
Samsung's policy since Android 4.4 (KitKat) is that editing of APN protocol and APN roaming protocol is not blocked (option appears greyed out when it is blocked or unavailable). However for operator locked phones the operator needs to request that the new default (unblocked) applies to their CSC.
Tethering IPv6 off a 3GPP Internet connected device
IPv6 Internet tethering of devices using the 3GPP /64 was implemented in a number of devices prior to the creation of an RFC e.g. Apple iOS LTE iPhones on Verizon Wireless, Samsung and Sony devices.
Stock Android 4.4.2 (KitKat) currently only supports single-stack IPv4 tethering when the PDP/PDN connection is IPv4v6 or IPv6. When the PDP/PDN connection is IPv6, IPv4 traffic from the tethered IPv4 RFC 1918 prefix is forwarded through the 464xlat clat4 interface.
Samsung Android 4.4.2 smartphones support dual-stack tethering when the PDP/PDN bearer is IPv4v6 or IPv6. On the latest builds, the availability of which will depend on the operator, IPv4 tethering is supported through the 464xlat clatd on a PDP/PDN IPv6 bearer. All new Samsungs starting with the S5 support IPv4 tethering through the clatd.
Sony Xperia Z phones also support IPv6/464xlat, IPv4v6 and tethering of IPv4 and the shared /64 prefix.
Huawei E5372 3GPP WiFi hotspots also support /64 prefix sharing. The Huawei E3272 USB Stick also works by sharing the /64 prefix.
VPN Access Methods
OpenVPN is the working method because it uses TCP or UDP to transport SSL/TLS traffic. It is compatible with the RFC 6877 464xlat clat4 interface and does not require Application Layer Gateways in the NAT or use GRE as a tunnel transport protocol. OpenVPN 2.3 also introduced support for IPv6 inside the tunnel and as the tunnel transport.
Currently most OpenVPN tunnel providers only offer IPv4 connectivity through the tunnel and use IPv4 as the tunnel transport.
The Cisco VPN client in devices tethered through a UE doing 464xlat works.