Individual Submission J. Korhonen, Ed. Internet-Draft J. Soininen Intended status: Informational Nokia Siemens Networks Expires: April 24, 2011 B. Patil T. Savolainen G. Bajko K. Iisakkila Nokia October 21, 2010 IPv6 in 3GPP Evolved Packet System draft-korhonen-v6ops-3gpp-eps-04 Abstract The increased use of data services, growth of subscribers in 3GPP based mobile networks, and the impending exhaustion of available IPv4 addresses from the registries is driving the need to specify the transition to IPv6 solutions in 3GPP network architectures. This document describes the support for IPv6 in 3GPP network architectures and a solution to transition to IPv6 using a dual-stack approach. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 24, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Korhonen, et al. Expires April 24, 2011 [Page 1] Internet-Draft IPv6 in 3GPP EPS October 2010 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 3GPP Terminology and Concepts . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. The concept of APN . . . . . . . . . . . . . . . . . . . . 6 3. IP over 3GPP GPRS . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction to 3GPP GPRS . . . . . . . . . . . . . . . . 7 3.2. PDP Context . . . . . . . . . . . . . . . . . . . . . . . 9 4. IP over 3GPP EPS . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Introduction to 3GPP EPS . . . . . . . . . . . . . . . . . 10 4.2. PDN Connection . . . . . . . . . . . . . . . . . . . . . . 11 4.3. EPS bearer model . . . . . . . . . . . . . . . . . . . . . 11 5. Address Management . . . . . . . . . . . . . . . . . . . . . . 12 5.1. IPv4 Address Configuration . . . . . . . . . . . . . . . . 12 5.2. IPv6 Address Configuration . . . . . . . . . . . . . . . . 12 5.3. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 13 6. 3GPP Dual-Stack Approach to IPv6 . . . . . . . . . . . . . . . 13 6.1. 3GPP Networks Prior to Release-8 . . . . . . . . . . . . . 13 6.2. 3GPP Release-8 and -9 Networks . . . . . . . . . . . . . . 15 6.3. PDN Connection Establishment Process . . . . . . . . . . . 15 6.4. Mobility of 3GPP IPv4v6 Type of Bearers . . . . . . . . . 18 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks . . . 18 8. Deployment issues . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Overlapping IPv4 Addresses . . . . . . . . . . . . . . . . 19 8.2. IPv6 for transport . . . . . . . . . . . . . . . . . . . . 20 8.3. Operational Aspects of Running Dual-Stack Networks . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 11. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 13. Informative References . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Korhonen, et al. Expires April 24, 2011 [Page 2] Internet-Draft IPv6 in 3GPP EPS October 2010 1. Introduction IPv6 has been specified in the 3rd Generation Partnership Project (3GPP) standards since the early architectures developed for R99 General Packet Radio Service (GPRS). However, the support for IPv6 in commercially deployed networks is nearly non-existent. There are many factors that can be attributed to the lack of IPv6 deployment in 3GPP networks. The most relevant one is essentially the same as the reason for IPv6 not being deployed by other networks as well, i.e. the lack of business and commercial incentives for deployment. 3GPP network architectures have also evolved since 1999 (since R99). The most recent version of the 3GPP architecture, the Evolved Packet System (EPS), which is commonly referred as SAE, LTE or Release-8, is a packet centric architecture. The number of subscribers and devices that are using the 3GPP networks for Internet connectivity and data services has also increased significantly. With the subscriber growth numbers projected to increase even further and the IPv4 addresses depletion problem looming in the near term, 3GPP operators and vendors have started the process of identifying the scenarios and solutions needed to transition to IPv6. This document describes the establishment of IP connectivity in 3GPP network architectures, specifically in the context of IP bearers for 3GPP GPRS and for 3GPP EPS. It provides an overview of how IPv6 is supported as per the current set of 3GPP specifications. A solution to transitioning to IPv6 based on a dual-stack technology is described as well as some of the issues and concerns with respect to deployment and shortage of private IPv4 addresses within a single network domain. The IETF has specified a set of tools and mechanisms that can be utilized for transitioning to IPv6. In addition to the dual-stack technology, the two alternative categories for the transition are encapsulation and translation. Most of the mechanisms available in the toolbox can be categorized as belonging to either one of these. The IETF continues to specify additional solutions for enabling the transition based on the deployment scenarios and operator/ISP requirements. The 3GPP scenarios for transition, described in [3GPP.23.975], can be addressed using transition mechanisms that are already available in the toolbox. The objective of transition to IPv6 in 3GPP networks is to ensure that: 1. Legacy devices and hosts which have an IPv4 only stack will continue to be provided with IP connectivity to the Internet and services, 2. Devices which are dual-stack can access the Internet either via IPv6 or IPv4. The choice of using IPv6 or IPv4 depends on the Korhonen, et al. Expires April 24, 2011 [Page 3] Internet-Draft IPv6 in 3GPP EPS October 2010 capability of: A. the application on the host, B. the support for IPv4 and IPv6 bearers by the network and/or, C. the capability of the server(s) and other end points. 3GPP networks are capable of providing a host with IPv4 and IPv6 connectivity today, albeit in many cases with upgrades to network elements such as the SGSN and GGSN. 2. 3GPP Terminology and Concepts 2.1. Terminology Access Point Name Access Point Name (APN) is a fully qualified domain name and resolves to a specific gateway in an operators network. The APNs are piggybacked on the administration of the DNS namespace. Packet Data Protocol Context A Packet Data Protocol (PDP) Context is the equivalent of a virtual connection between the host and a gateway. General Packet Radio Service General Packet Radio Service (GPRS) is a packet oriented mobile data service available to users of the 2G and 3G cellular communication systems Global System for Mobile communications (GSM), and specified by 3GPP. Packet Data Network Packet Data Network (PDN) is a packet based network that either belongs to the operator or is an external network such as Internet and corporate intranet. The user eventually accesses services in one or more PDNs. The operator's packet domain network are separated from packet data networks either by GGSNs or PDN Gateways (PDN-GW). Gateway GPRS Support Node Gateway GPRS Support Node (GGSN) is a gateway function in GPRS, which provides connectivity to Internet or other PDNs. The host Korhonen, et al. Expires April 24, 2011 [Page 4] Internet-Draft IPv6 in 3GPP EPS October 2010 attaches to a GGSN identified by an APN assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/prefixes assigned to the mobile host. Packet Data Network Gateway Packet Data Network Gateway (PDN-GW) is a gateway function in Evolved Packet System (EPS), which provides connectivity to Internet or other PDNs. The host attaches to a PDN-GW identified by an APN assigned to it by an operator. The PDN-GW also serves as the topological anchor for addresses/prefixes assigned to the mobile host. Serving Gateway Serving Gateway (SGW) is a gateway function in EPS, which terminates the interface towards E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each User Equipment connected with the EPS, at any given point of time, there is only one SGW. The SGW is essentially the user plane part of the GPRS' SGSN forwarding packets between a PDN-GW. Serving Gateway Support Node Serving Gateway Support Node (SGSN) is a network element that is located between the radio access network (RAN) and the gateway (GGSN). A per mobile host point to point (p2p) tunnel between the GGSN and SGSN transports the packets between the mobile host and the gateway. GPRS tunnelling protocol GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a tunnelling protocol defined by 3GPP. It is a network based mobility protocol and similar to Proxy Mobile IPv6 (PMIPv6) [RFC5213]. However, GTP also provides functionality beyond mobility such as inband signaling related to Quality of Service (QoS) and charging among others. Evolved Packet System Evolved Packet System (EPS) is an evolution of the 3G GPRS system characterized by higher-data-rate, lower-latency, packet-optimized system that supports multiple Radio Access Technologies (RAT). The EPS comprises the Evolved Packet Core (EPC) together with the evolved radio access network (E-UTRA and E-UTRAN). Korhonen, et al. Expires April 24, 2011 [Page 5] Internet-Draft IPv6 in 3GPP EPS October 2010 Mobility Management Entity Mobility Management Entity (MME) is a network element that is responsible for control plane functionalities, including authentication, authorization, bearer management, layer-2 mobility, etc. The MME is essentially the control plane part of the GPRS' SGSN and not located on the user plane data path, i.e. user plane traffic bypasses the MME. UMTS Terrestrial Radio Access Network UMTS Terrestrial Radio Access Network (UTRAN) is communications network, commonly referred to as 3G, and consists of NodeBs (3G base station) and Radio Network Controllers (RNC) which make up the UMTS radio access network. The UTRAN allows connectivity between the mobile host/device and the core network. Evolved UTRAN Evolved UTRAN (E-UTRAN) is communications network, sometimes referred to as 4G, and consists of eNodeBs (4G base station) which make up the E-UTRAN radio access network. The E-UTRAN allows connectivity between the mobile host/device and the core network. GSM EDGE Radio Access Network GSM EDGE Radio Access Network (GERAN) is communications network, commonly referred to as 2G or 2.5G, and consists of base stations and Base Station Controllers (BSC) which make up the GSM EDGE radio access network. The GERAN allows connectivity between the mobile host/device and the core network. UE, MS, MN and Mobile The terms UE (User Equipment), MS (Mobile Station), MN (Mobile Node) and, mobile refer to the devices which are hosts with ability to obtain Internet connectivity via a 3GPP network. The terms UE, MS, MN and devices are used interchangeably within this document. 2.2. The concept of APN The Access Point Name (APN) essentially refers to a gateway in the 3GPP network. The 'complete' APN is expressed in a form of a Fully Qualified Domain Name (FQDN) and also piggybacked on the administration of the DNS namespace, thus effectively allowing the discovery of gateways using the DNS. Mobile hosts/devices can choose to attach to a specific gateway in the packet core. The gateway Korhonen, et al. Expires April 24, 2011 [Page 6] Internet-Draft IPv6 in 3GPP EPS October 2010 provides connectivity to the Packet Data Network (PDN) such as the Internet. An operator may also include gateways which do not provide Internet connectivity, rather a connectivity to closed network providing a set of operator's own services. A mobile host/device can be attached to one or more gateways simultaneously. The gateway in a 3GPP network is the GGSN or PDN-GW. Figure 1 below illustrates the APN-based network connectivity concept. .--. _(. `) .--. +------------+ _( PDN `)_ _(Core`. |GW1 |====( Internet `) +---+ ( NW )------|APN=internet| ( ` . ) ) [MN]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---' ^ +---+ `--(___.-' | | | .--. | | +----------+ _(.PDN`) | +--|GW2 | _(Operator`)_ | |APN=OpServ|====( Services `) MN is attached +----------+ ( ` . ) ) to GW1 and GW2 `--(_______)---' simultaneously Figure 1: Mobile host/device attached to multiple APNs simultaneously 3. IP over 3GPP GPRS 3.1. Introduction to 3GPP GPRS A simplified 2G/3G GPRS architecture is illustrated in Figure 2. This architecture basically covers the GPRS core network since R99 to Release-7, and radio access technologies such as GSM (2G), EDGE (2G), WCDMA (3G) and HSPA (3G). The architecture shares obvious similarities with the Evolved Packet System (EPS) as will be seen in Section 4. Based on Gn/Gp interfaces, the GPRS core network functionality is logically implemented on two network nodes, the SGSN and the GGSN. Korhonen, et al. Expires April 24, 2011 [Page 7] Internet-Draft IPv6 in 3GPP EPS October 2010 3G .--. Uu +-----+ Iu +----+ +----+ _( `. [TE]+[MT]~~|~~~|UTRAN|--|---|SGSN|--|---|GGSN|--|----( PDN ) +-----+ +----+ Gn +----+ Gi ( ` . ) ) / | `--(___.-' 2G Gb-- | +---+ / --Gp [TE]+[MT]~~|~~~|BSS|___/ | Um +---+ .--. _(. `) _( [GGSN] `)_ ( other `) ( ` . PLMN ) ) `--(_______)---' Figure 2: Overview of the 2G/3G GPRS Logical Architecture Gn/Gp: These interfaces provide a network based mobility service for a mobile host and are used between a SGSN and a GGSN. The Gn interface is used when GGSN and SGSN are located inside one operator (i.e. PLMN). The Gp-interface is used if the GGSN and the SGSN are located in different operator domains (i.e. 'other' PLMN). GTP protocol is defined for the Gn/Gp interfaces (both GTP-C for the control plane and GTP-U for the user plane). Gb: Is the Base Station System (BSS) to SGSN interface, which is used to carry information concerning packet data transmission and layer-2 mobility management. The Gb-interface is based on either on Frame Relay or IP. Iu: Is the Radio Network System (RNS) to SGSN interface, which is used to carry information concerning packet data transmission and layer-2 mobility management. The user plane part of the Iu-interface (actually the Iu-PS) is based on GTP-U. The control plane part of the Iu-interface is based on Radio Access Network Application Protocol (RANAP). Gi: It is the interface between the GGSN and a PDN. The PDN may be an operator external public or private packet data network or an intra-operator packet data network. Uu/Um: Are either 2G or 3G radio interfaces between a mobile terminal and a respective radio access network. The SGSN is responsible for the delivery of data packets from and to the mobile hosts within its geographical service area when a direct tunnel option is not used. If the direct tunnel is used, then the Korhonen, et al. Expires April 24, 2011 [Page 8] Internet-Draft IPv6 in 3GPP EPS October 2010 user plane goes directly between the RNS and the GGSN. The control plane traffic always goes through the SGSN. For each mobile host connected with the GPRS, at any given point of time, there is only one SGSN. 3.2. PDP Context A PDP context is an association between a mobile host represented by one IPv4 address and/or one /64 IPv6 prefix and a PDN represented by an APN. Each PDN can be accessed via a gateway (typically a GGSN or PDN-GW). On the device/mobile host a PDP context is equivalent to a virtual interface/connection. A host may hence be attached to one or more gateways via separate virtual interfaces/connections, i.e. PDP contexts. Each primary PDP context has its own IPv4 address and/or one /64 IPv6 prefix assigned to it by the PDN and anchored in the corresponding gateway. Applications on the host use the appropriate PDP context (virtual interface) for connectivity to a specific PDN. Figure 3 represents a high level view of what a PDP context implies in 3GPP networks. Y | +---------+ .--. |--+ __________________________ | APNx in | _( `. | |O__________________________)| GGSN / |----(Internet) |MS| | PDN-GW | ( ` . ) ) |/ | +---------+ `--(___.-' |UE| _______________________ +---------+ .--. | |O_______________________)| APNy in | _(Priv`. +--+ | GGSN / |-------(Network ) | PDN-GW | ( ` . ) ) +---------+ `--(___.-' Figure 3: PDP contexts between the MS/UE and gateway In the above figure there are two PDP contexts at the MS/UE (UE=User Equipment in 3GPP parlance). The PDP context that is connected to APNx provided Internet connectivity and the other PDP context provides connectivity to a private IP network (as an example this network may include operator specific services such as MMS (Multi media service). An application on the host such as a web browser would use the PDP context that provides Internet connectivity for accessing services on the Internet. An application such as MMS would use APNy in the figure above because the service is provided through the private network. Korhonen, et al. Expires April 24, 2011 [Page 9] Internet-Draft IPv6 in 3GPP EPS October 2010 4. IP over 3GPP EPS 4.1. Introduction to 3GPP EPS In its most basic form, the EPS architecture consists of only two nodes on the user plane, a base station and a core network Gateway (GW). The basic EPS architecture is illustrated in Figure 4. The Mobility Management Entity (MME) node performs control-plane functionality and is separated from the node(s) that performs bearer- plane functionality (GW), with a well-defined open interface between them (S11). The optional interface S5 can be used to split the Gateway (GW) into two separate nodes, the Serving Gateway (SGW) and the PDN-GW. This allows independent scaling and growth of traffic throughput and control signal processing. The functional split of gateways also allows operators to choose optimized topological locations of nodes within the network in order to optimize the network in different aspects. +--------+ S1-MME +-------+ S11 | IP | +----|----| MME |---|----+ |Services| | | | | +--------+ | +-------+ | |SGi +----+ LTE-Uu +-------+ S1-U +-------+ S5 +-------+ |MN |----|---|eNodeB |---|----------------| SGW |--|---|PDN-GW | | |========|=======|====================|=======|======| | +----+ +-------+DualStack EPS Bearer+-------+ +-------+ Figure 4: EPS Architecture for 3GPP Access S5: It provides user plane tunnelling and tunnel management between SGW and PDN-GW, using GTP or PMIPv6 as the network based mobility management protocol. S1-U: Provides user plane tunnelling and inter eNodeB path switching during handover between eNodeB and SGW, using the GTP-U protocol (GTP user plane). S1-MME: Reference point for the control plane protocol between eNodeB and MME. SGi: It is the interface between the PDN-GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra operator packet data network. The eNodeB is a base station entity that supports the Long Term Evolution (LTE) air interface and includes functions for radio Korhonen, et al. Expires April 24, 2011 [Page 10] Internet-Draft IPv6 in 3GPP EPS October 2010 resource control, user plane ciphering, and other lower layer functions. MME is responsible for control plane functionalities, including authentication, authorization, bearer management, layer-2 mobility, etc. The SGW is the Mobility Anchor point for layer-2 mobility. For each MN connected with the EPS, at any given point of time, there is only one SGW. 4.2. PDN Connection A PDN connection is an association between a mobile host represented by one IPv4 address and/or one /64 IPv6 prefix, and a PDN represented by an APN. Each PDN can be accessed via a gateway (a PDN-GW). PDN is responsible for the IP address/prefix allocation to the mobile host. On the device/mobile host a PDN connection is equivalent to a virtual interface/connection. A host may hence be attached to one or more gateways via separate virtual interfaces/connections, i.e. PDN connection. Each PDP connection has its own IP address/prefix assigned to it by the PDN and anchored in the corresponding gateway. Applications on the host use the appropriate PDN connection (virtual interface) for connectivity. The PDN connection is the EPC equivalent of the GPRS PDP context. 4.3. EPS bearer model The logical concept of a bearer has been defined to be an aggregate of one or more IP flows related to one or more services. An EPS bearer exists between the Mobile Node (MN i.e. a mobile host) and the PDN-GW and is used to provide the same level of packet forwarding treatment to the aggregated IP flows constituting the bearer. Services with IP flows requiring a different packet forwarding treatment would therefore require more than one EPS bearer. The mobile host performs the binding of the uplink IP flows to the bearer while the PDN-GW performs this function for the downlink packets. In order to provide low latency for always on connectivity, a default bearer will be provided at the time of startup and an IPv4 address and/or IPv6 prefix gets assigned to the mobile host (this is different from GPRS, where mobile hosts are not automatically assigned with an IP address or prefix). This default bearer will be allowed to carry all traffic which is not associated with a dedicated bearer. Dedicated bearers are used to carry traffic for IP flows that have been identified to require a specific packet forwarding treatment. They may be established at the time of startup; for example, in the case of services that require always-on connectivity and better QoS than that provided by the default bearer. The default bearer and the dedicated bearer(s) associated to it share the same IP Korhonen, et al. Expires April 24, 2011 [Page 11] Internet-Draft IPv6 in 3GPP EPS October 2010 address(es)/prefix. An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the eNodeB) at bearer establishment/ modification. Otherwise, an EPS bearer is referred to as a non-GBR bearer. The default bearer is always non-GBR, with the resources for the IP flows not guaranteed at eNodeB, and with no admission control. However, the dedicated bearer can be either GBR or non-GBR. A GBR bearer has a Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR) while more than one non-GBR bearer belonging to the same UE shares an Aggregate Maximum Bit Rate (AMBR). Non-GBR bearers can suffer packet loss under congestion while GBR bearers are immune to such losses. 5. Address Management 5.1. IPv4 Address Configuration Mobile host's IPv4 address configuration is essentially always conducted during PDP context/EPS bearer setup procedures (on layer-2). DHCPv4-based [RFC2131] address configuration is supported by the 3GPP specifications, but is not used in wide scale. The mobile host must always support layer-2 based address configuration, since DHCPv4 is optional for both mobile hosts and networks. 5.2. IPv6 Address Configuration IPv6 Stateless Address Autoconfiguration (SLAAC) is the only supported address configuration mechanisms [RFC4862]. Stateful DHCPv6-based address configuration is not supported by 3GPP specifications [RFC3315]. On the other hand, Stateless DHCPv6- service to obtain other configuration information is supported [RFC3736]. This implies that the M-bit must always be set to zero and the O-bit may be set to one in the Router Advertisement (RA) sent to the UE. 3GPP network allocates each default bearer a unique /64 prefix, and uses layer-2 signaling to suggest user equipment an Interface Identifier that is guaranteed not to conflict with gateway's Interface Identifier. The UE may configure link local address using this Interface Identifier, but is allowed to use also other Interface Identifiers and as many globally scoped addresses as it needs. There is no restriction, for example, of using Privacy Extension for SLAAC [RFC4941] or other similar types of mechanisms. In the 3GPP link model the /64 prefix assigned to the UE is always Korhonen, et al. Expires April 24, 2011 [Page 12] Internet-Draft IPv6 in 3GPP EPS October 2010 off-link (i.e. the L-bit in the Prefix Information Option (PIO) in the RA must be set to zero). If the advertised prefix is used for SLAAC then the A-bit in the PIO must be set to one. The details of the 3GPP link-model and address configuration is described in Section 11.2.1.3.2a of [3GPP.29.061]. The current 3GPP architecture limits number of prefixes in each bearer to a single /64 prefix. Therefore, multi-homing within a single bearer is not possible. Renumbering without closing layer-2 connection is also not possible. The lifetime of /64 prefix is bound to lifetime of layer-2 connection even if the advertised prefix lifetime would be longer than the layer-2 connection lifetime. 5.3. Prefix Delegation IPv6 prefix delegation is a part of Release-10 and is not covered by any earlier release. However, the /64 prefix allocated for each default bearer (and to the user equipment) may be shared to local area network by user equipment implementing Neighbor Discovery proxy (ND proxy) [RFC4389] functionality. Release-10 prefix delegation uses the DHCPv6-based prefix delegation [RFC3633]. The model defined for Release-10 requires aggregatable prefixes, which means the /64 prefix allocated for the default bearer (and to the user equipment) must be part of the shorter delegated prefix. DHCPv6 prefix delegation has an explicit limitation described in Section 12.1 of [RFC3633] that a prefix delegated to a requesting router cannot be used by the delegating router (i.e., the PDN-GW in this case). This implies the shorter 'delegated prefix' cannot be given to the requesting router (i.e. the user equipment) as such but has to be delivered by the delegating router (i.e. the PDN-GW) in such a way the /64 prefix allocated to the default bearer is not part of the 'delegated prefix'. IETF is working on a solution for DHCPv6-based prefix delegation to exclude a specific prefix from the 'delegated prefix' [I-D.ietf-dhc-pd-exclude], which could actually be used to solve the above problem. 6. 3GPP Dual-Stack Approach to IPv6 6.1. 3GPP Networks Prior to Release-8 3GPP standards prior to Release-8 provide IPv6 access for cellular devices with PDP contexts of type IPv6 [3GPP.23.060]. For dual-stack access, a PDP context of type IPv6 is established in parallel to the PDP context of type IPv4, as shown in Figure 5 and Figure 6. For IPv4-only service, connections are created over the PDP context of type IPv4 and for IPv6-only service connections are created over the Korhonen, et al. Expires April 24, 2011 [Page 13] Internet-Draft IPv6 in 3GPP EPS October 2010 PDP context of type IPv6. The two PDP contexts of different type may use the same APN (and the gateway), however, this aspect is not explicitly defined in standards. Therefore, cellular device and gateway implementations from different vendors may have varying support for this functionality. Y .--. | _(IPv4`. |---+ +---+ +---+ ( PDN ) | D |~~~~~~~//-----| |====| |====( ` . ) ) | S | IPv4 context | S | | G | `--(___.-' | | | G | | G | .--. | M | | S | | S | _(IPv6`. | N | IPv6 context | N | | N | ( PDN ) |///|~~~~~~~//-----| |====|(s)|====( ` . ) ) +---+ +---+ +---+ `--(___.-' Figure 5: A dual-stack mobile host connecting to both IPv4 and IPv6 Internet using parallel IPv4-only and IPv6-only PDP contexts Y | |---+ +---+ +---+ | D |~~~~~~~//-----| |====| | .--. | S | IPv4 context | S | | G | _( DS `. | | | G | | G | ( PDN ) | M | | S | | S |====( ` . ) ) | N | IPv6 context | N | | N | `--(___.-' |///|~~~~~~~//-----| |====| | +---+ +---+ +---+ Figure 6: A dual-stack mobile host connecting to dual-stack Internet using parallel IPv4-only and IPv6-only PDP contexts The approach of having parallel IPv4 and IPv6 type of PDP contexts open is not optimal, because two PDP contexts require double the signaling and consume more network resources than a single PDP context. However, these costs and complexities are lesser than what other transition solutions would incur. In the figure above the IPv4 and IPv6 PDP contexts are attached to the same GGSN. While this is possible, the DS MS may be attached to different GGSNs in the scenario where one GGSN supports IPv4 PDN connectivity while another GGSN provides IPv6 PDN connectivity. Korhonen, et al. Expires April 24, 2011 [Page 14] Internet-Draft IPv6 in 3GPP EPS October 2010 6.2. 3GPP Release-8 and -9 Networks Since 3GPP Release-8, the powerful concept of a dual-stack type of PDN connection and EPS bearer have been introduced [3GPP.23.401]. This enables parallel use of both IPv4 and IPv6 on a single bearer (IPv4v6), as illustrated in Figure 7, and makes dual stack simpler than in earlier 3GPP releases. As of Release-9, GPRS network nodes also support dual-stack type (IPv4v6) PDP contexts. Y | |---+ +---+ +---+ | D | | | | P | .--. | S | | | | D | _( DS `. | | IPv4v6 (DS) | S | | N | ( PDN ) | M |~~~~~~~//-----| G |====| - |====( ` . ) ) | N | bearer | W | | G | `--(___.-' |///| | | | W | +---+ +---+ +---+ Figure 7: A dual-stack mobile host connecting to dual-stack Internet using a single IPv4v6 type PDN connection The following is a description of the various PDP contexts/PDN bearer types that are specified by 3GPP: 1. For 2G/3G access to GPRS core (SGSN/GGSN) pre-Release-9 there are two IP PDP Types, IPv4 and IPv6. Two PDP contexts are needed to get dual stack connectivity. 2. For 2G/3G access to GPRS core (SGSN/GGSN) from Release-9 there are three IP PDP Types, IPv4, IPv6 and IPv4v6. Minimum one PDP context is needed to get dual stack connectivity. 3. For 2G/3G access to EPC core (PDN-GW via S4 Release-8 SGSN) from Release-8 there are three IP PDP Types, IPv4, IPv6 and IPv4v6 which gets mapped to PDN Connection type. Minimum one PDP Context is needed to get dual stack connectivity. 4. For LTE (E-UTRAN) access to EPC core from Release-8 there are three IP PDN Types, IPv4, IPv6 and IPv4v6. Minimum one PDN Connection is needed to get dual stack connectivity. 6.3. PDN Connection Establishment Process The PDN connection establishment process is specified in detail in 3GPP specifications. Figure 8 illustrates the high level process and signaling involved in the establishment of a PDN connection. Korhonen, et al. Expires April 24, 2011 [Page 15] Internet-Draft IPv6 in 3GPP EPS October 2010 UE eNb/ MME SGW PDN-GW HSS/ | BS | | | AAA | | | | | | |---------->|(1) | | | | | |---------->|(1) | | | | | | | | | |/---------------------------------------------------------\| | Authentication and Authorization |(2) |\---------------------------------------------------------/| | | | | | | | | |---------->|(3) | | | | | |---------->|(3) | | | | | | | | | | |<----------|(4) | | | |<----------|(4) | | | |<----------|(5) | | | |/---------\| | | | | | RB setup |(6) | | | | |\---------/| | | | | | |---------->|(7) | | | |---------->|(8) | | | | | |---------->|(9) | | | | | | | | | |============= UL Data =============>==========>|(10) | | | | | | | | | |---------->|(11) | | | | | | | | | | |<----------|(12) | | | | | | | | |<============ DL Data =============<===========|(13) | | | | | | | Figure 8: Simplified PDN connection setup procedure in Release-8 1. The UE (i.e the MS) requires a data connection and hence decides to establish a PDN connection with a PDN-GW. The UE sends an "Attach Request" (layer-2) to the BS. The BS forwards this attach request to the MME. 2. Authentication of the UE with the AAA server/HSS follows. If the UE is authorized for establishing a data connection, the following steps continue 3. The MME sends a "Create Session Request" message to the Serving-GW. The SGW forwards the create session request to the PDN-GW. The SGW knows the address of the PDN-GW to forward the create session request to as a result of this information having been obtained by the MME during the authentication/authorization Korhonen, et al. Expires April 24, 2011 [Page 16] Internet-Draft IPv6 in 3GPP EPS October 2010 phase. The UE IPv4 address and/or IPv6 prefix get assigned during this step. If a subscribed IPv4 address and/or IPv6 prefix is statically allocated for the UE for this APN, then the MME already passes the address information to the SGW and eventually to the PDN-GW in the "Create Session Request" message. Otherwise, the PDN-GW manages the address assignment to the UE (there is another variation to this where IPv4 address allocation is delayed until the UE initiates a DHCPv4 exchange but this is not discussed here). 4. The PDN-GW creates a PDN connection for the UE and sends "Create Session Response" message to the SGW from which the session request message was received from. The SGW forwards the response to the corresponding MME which originated the request. 5. The MME sends the "Attach Accept/Initial Context Setup request" message to the eNodeB/BS. 6. The radio bearer between the UE and the eNb is reconfigured based on the parameters received from the MME 7. The eNb sends "Initial Context Response" message to the MME. 8. The UE sends a "Direct Transfer" message to the eNodeB which includes the Attach complete signal. 9. The eNodeB forwards the Attach complete message to the MME. 10. The UE can now start sending uplink packets to the PDN GW. 11. The MME sends a "Modify Bearer Request" message to the SGW. 12. The SGW responds with a "Modify Bearer Response" message. At this time the downlink connection is also ready 13. The UE can now start receiving downlink packets The type of PDN connection established between the UE and the PDN-GW can be any of the types described in the previous section. The DS PDN connection, i.e the one which supports both IPv4 and IPv6 packets is the default one that will be established if no specific PDN connection type is specified by the UE in Release-8 networks. Korhonen, et al. Expires April 24, 2011 [Page 17] Internet-Draft IPv6 in 3GPP EPS October 2010 6.4. Mobility of 3GPP IPv4v6 Type of Bearers 3GPP discussed at length various approaches to support mobility between Release-8 and pre-Release-8 networks for the new dual-stack type of bearers. The chosen approach for mobility is as follows, in short: if a mobile is known to be at risk for doing handovers between Release-8 and pre- Release-8 networks, only single stack bearers are used. Essentially meaning: 1. If a network knows a mobile may do handovers between Release-8 and pre-Release-8 networks (segment), network will only provide single stack bearers, even if the mobile host requests dual-stack bearers. This can happen e.g. if an operator is using pre- Release-8 SGSNs in some parts of the network. The single stack bearers of Release-8 are easy to map one-to-one to pre-Release-8 bearers. 2. If a network knows a mobile will not be able to do handover to pre-Release-8 network (segment), it will provide mobile with dual-stack bearers on request. This can happen e.g. if an operator has upgraded their SGSNs to support dual-stack bearers, or if an operator is running LTE-only network. The operators should upgrade their, and also if possible roaming partners', networks to Release-8 level in order to support new dual- stack type of bearers. A Release-8 mobile device always requests for a dual-stack bearer, but accepts what is assigned by the network. 7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 3GPP networks can natively transport IPv4 and IPv6 packets between the mobile station/UE and the gateway (GGSN or PDN-GW) as a result of establishing either a dual-stack PDP context or parallel IPv4 and IPv6 PDP contexts. Current deployments of 3GPP networks primarily support IPv4 only. These networks can be upgraded to also support IPv6 PDP contexts. By doing so devices and applications that are IPv6 capable can start utilizing the IPv6 connectivity. This will also ensure that legacy devices and applications continue to work with no impact. As newer devices start using IPv6 connectivity, the number of IPv4 addresses in use is expected to slowly decrease, providing operators with a smooth transition to IPv6 With a dual-stack approach, there is always Korhonen, et al. Expires April 24, 2011 [Page 18] Internet-Draft IPv6 in 3GPP EPS October 2010 the potential to fallback to IPv4. A device which may be roaming in a network wherein IPv6 is not supported by the visited network would fall back to using IPv4 PDP contexts and hence the end user does not see an interruption to the services. As the networks evolve to support Release-8 EPS architecture and the dual-stack PDP contexts, newer devices will be able to leverage such capability and have a single bearer which supports both IPv4 and IPv6. Since IPv4 and IPv6 packets are carried as payload within GTP between the MS and the gateway (GGSN/PDN-GW) the transport network capability in terms of whether it supports IPv4 or IPv6 on the interfaces between the eNodeB and SGW or, SGW and PDN-GW is immaterial. The dual-stack approach enables a systematic migration path to IPv6. From an operational standpoint operators are concerned about ensuring that there is no disruption to the connectivity that subscribers rely on. This can be achieved by upgrading the network to support IPv6 while continuing to maintain IPv4 legacy. Dual-stack capability in the network and devices for the foreseeable future at least is a pragmatic solution. 8. Deployment issues 8.1. Overlapping IPv4 Addresses Given the shortage of globally routable public IPv4 addresses, operators tend to assign private IPv4 addresses [RFC1918] to hosts when they establish an IPv4 only PDP context or an IPv4v6 type PDN context. About 16 million hosts can be assigned a private IPv4 address that is unique within a domain. However, in case of many operators the number of subscribers is greater than 16 million. The issue can be dealt with by assigning overlapping RFC 1918 IPv4 addresses to hosts. As a result the IPv4 address assigned to a host within the context of a single operator realm would no longer be unique. This has the obvious and know issues of NATed IP connection in the Internet. Direct host to host connectivity becomes complicated, unless the hosts are within the same private address range pool and/or anchored to the same gateway, referrals using IP addresses will have issues and so forth. However, these are generic issues and not only a concern of the EPS. In general this is not seen as a major issue in the EPS for the following reasons: 1. Very large network deployments are partitioned, for example, based on a geographical areas. This partitioning allows overlapping IPv4 addresses ranges to be assigned to hosts that are in different areas. Each area has its own pool of gateways Korhonen, et al. Expires April 24, 2011 [Page 19] Internet-Draft IPv6 in 3GPP EPS October 2010 that are dedicated for a certain overlapping IPv4 address range (referred here later as a zone). Standard NAT44 functionality enables the communication between hosts that are assigned the same IPv4 address but belong to different zones, yet are part of the same operator domain. 2. A mobile host/device attaches to a gateway as part of the attach process. The number of hosts that a gateway supports is in the order of 1 to 10 million. Hence all the hosts assigned to a single gateway can be assigned private IPv4 addresses. Operators with large subscriber bases have multiple gateways and hence the same [RFC1918] IPv4 address space can be reused across gateways. The IPv4 address assigned to a host is unique within the scope of a single gateway. 3. The IPv4 address assigned to a host could also be made irrelevant from a routing perspective at least by the use of protocol solutions such as GI-DSLite [I-D.ietf-softwire-gateway-init-ds-lite]. This requires a Large Scale NAT (LSN) entity that is detached from the gateway (GGSN or PDN-GW). Multiple gateways in an operator domain would attach to a LSN in such an approach and the hosts across these gateways can be assigned overlapping IPv4 addresses. 4. New services requiring direct connectivity between hosts should be build on IPv6. Possible existing IPv4-only services and applications requiring direct connectivity can be ported to IPv6. 8.2. IPv6 for transport The various reference points of the 3GPP architecture such as S1-U, S5 and S8 are based on either GTP or PMIPv6. The underlying transport for these reference points can be IPv4 or IPv6. GTP has been able to operate over IPv6 transport (optionally) since R99 and PMIPv6 has supported IPv6 transport starting from its introduction in Release-8. The user plane traffic between the mobile host and the gateway can use either IPv4 or IPv6. These packets are essentially treated as payload by GTP/PMIPv6 and transported accordingly with no real attention paid to the information (at least from a routing perspective) contained in the IPv4 or IPv6 headers. The transport links between the eNodeB and the SGW, and the link between the SGW and PDN-GW can be migrated to IPv6 without any direct implications to the architecture. Currently, the inter-operator (for 3GPP technology) roaming networks are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]). Eventually these roaming networks will also get migrated to IPv6, if there is a business reason for that. The migration period can be Korhonen, et al. Expires April 24, 2011 [Page 20] Internet-Draft IPv6 in 3GPP EPS October 2010 prolonged considerably because the 3GPP protocols always tunnel user plane traffic in the core network and as described earlier the transport network IP version is not in any way tied to user plane IP version. Furthermore, the design of the inter-operator roaming networks is such that the user plane and transport network IP addressing is completely separated from each other. The inter- operator roaming network itself is also completely separated from the Internet. Only those core network nodes that must be connected to the inter-operator roaming networks are actually visible there, and be able to send and receive (tunneled) traffic within the inter- operator roaming networks. Obviously, in order the roaming to work properly, the operators have to agree on supported protocol versions so that the visited network does not, for example, unnecessarily drop user plane IPv6 traffic. 8.3. Operational Aspects of Running Dual-Stack Networks Operating dual-stack networks does imply cost and complexity to a certain extent. However these factors are mitigated by the assurance that legacy devices and services are unaffected and there is always a fallback to IPv4 in case of issues with the IPv6 deployment or network elements. The model also enables operators to develop operational experience and expertise in an incremental manner. Running dual-stack networks requires the management of multiple IP address spaces. Tracking of hosts needs to be expanded since it can be identified by either an IPv4 address or IPv6 prefix. Network elements will also need to be dual-stack capable in order to support the dual-stack deployment model. Deployment and migration cases described in Section 6.1 for providing dual-stack like capability may mean doubled resource usage in operator's network. Also handovers between networks with different capabilities in terms of networks being dual-stack like service capable or not, may turn out hard to comprehend for users and for application/services to cope with. These facts may add other than just technical concerns for operators when planning to roll out dual- stack service offerings. 9. IANA Considerations This document has no requests to IANA. 10. Security Considerations This document does not introduce any security related concerns. Korhonen, et al. Expires April 24, 2011 [Page 21] Internet-Draft IPv6 in 3GPP EPS October 2010 11. Summary and Conclusion The 3GPP network architecture and specifications enable the establishment of IPv4 and IPv6 connections through the use of appropriate PDP context types. The current generation of deployed networks can support dual-stack connectivity if the packet core network elements such as the SGSN and GGSN have the capability. With Release-8, 3GPP has specified a more optimal PDP context type which enables the transport of IPv4 and IPv6 packets within a single PDP context between the mobile station and the gateway. The authors believe that transitioning to IPv6 in 3GPP networks can be achieved without disruption to legacy devices, networks and services only by taking a dual-stack approach to deployment. As devices and applications are upgraded to support IPv6 they can start leveraging the IPv6 connectivity provided by the networks while maintaining the fallback to IPv4 capability. Enabling IPv6 connectivity in the 3GPP networks by itself will provide some degree of relief to the IPv4 address space as many of the applications and services can start to work over IPv6 right away. However without comprehensive testing of different applications and solutions that exist today and are widely used, for their ability to operate over IPv6 PDN connections, an IPv6 only access would cause disruptions. Hence we recommend adopting the dual-stack approach to IPv6 transition in 3GPP networks. 12. Acknowledgements The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, and Zhenqiang Li for their reviews and comments on this document. 13. Informative References [3GPP.23.060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 8.8.0, March 2010. [3GPP.23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.1.0, September 2010. [3GPP.23.975] 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 1.1.1, June 2010. Korhonen, et al. Expires April 24, 2011 [Page 22] Internet-Draft IPv6 in 3GPP EPS October 2010 [3GPP.29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 8.11.0, April 2010. [3GPP.29.061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 8.5.0, April 2010. [GSMA.IR.34] GSMA, "Inter-PLMN Backbone Guidelines", GSMA PRD IR.34.4.9, March 2010. [I-D.ietf-dhc-pd-exclude] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", draft-ietf-dhc-pd-exclude-00 (work in progress), October 2010. [I-D.ietf-softwire-gateway-init-ds-lite] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment", draft-ietf-softwire-gateway-init-ds-lite-01 (work in progress), October 2010. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Korhonen, et al. Expires April 24, 2011 [Page 23] Internet-Draft IPv6 in 3GPP EPS October 2010 Address Autoconfiguration", RFC 4862, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Authors' Addresses Jouni Korhonen (editor) Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND Email: jouni.nospam@gmail.com Jonne Soininen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo FINLAND Email: jonne.soininen@nsn.com Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75019 USA Email: basavaraj.patil@nokia.com Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere FINLAND Email: teemu.savolainen@nokia.com Korhonen, et al. Expires April 24, 2011 [Page 24] Internet-Draft IPv6 in 3GPP EPS October 2010 Gabor Bajko Nokia 323 Fairchild drive 6 Mountain view, CA 94043 USA Email: gabor.bajko@nokia.com Kaisu Iisakkila Nokia Itamerenkatu 11-13 FI-00180 Helsinki FINLAND Email: kaisu.iisakkila@nokia.com Korhonen, et al. Expires April 24, 2011 [Page 25]