Internet Engineering Task Force C. Zhou, Ed. Internet-Draft T. Taylor Intended status: Informational Huawei Technologies Expires: April 22, 2011 October 19, 2010 IPv6 Transition Use Case For a Large Mobile Network draft-zhou-v6ops-mobile-use-case-00 Abstract This document describes an use case for migrating from IPv4 to IPv6 in a very large mobile network. Its purpose is to enhance general understanding of the challenges associated with the migration of such a network to IPv6 operation. 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 22, 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 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. Zhou & Taylor Expires April 22, 2011 [Page 1] Internet-Draft Mobile Use Case October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview of the Mobile Network Architecture . . . . . . . . . 3 3. Approaches To IPv4 / IPv6 Coexistence . . . . . . . . . . . . 6 3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity With Limited Public IPv4 Address Pools . . . . . . . . . . 7 3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity With Limited Private IPv4 Address Pools . . . . . . . . . 7 3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only Transport and Applications Using IPv6 . . . . . . . . . . 8 3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running On a Dual-Stack Host With an Assigned IPv6 Prefix and a Shared IPv4 Address . . . . . . . . . . . . . . . . . . 8 4. Consideration of IPv4 / IPv6 Coexistence Solutions . . . . . . 8 4.1. Gateway-Initiated Dual-Stack Lite . . . . . . . . . . . . 8 4.2. Protocol Translation . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhou & Taylor Expires April 22, 2011 [Page 2] Internet-Draft Mobile Use Case October 2010 1. Introduction Consider a major mobile network operator, with hundreds of millions of subscribers, currently growing at a rate in the order of 1% per month. To assure continued revenue growth as market penetration approaches its limit, the operator has been deploying 3GPP technology. Currently about 1.5 percent of the operator's subscribers use the third and fourth generation technology discussed in this document. The operator is looking to mobile data services for future revenue gains. Mobile data services currently include mobile payments, music downloads, mobile reading (book downloads), streaming and broadcast video, and internet search services in partnership with content providers such as news agencies. By their nature, these services require communication between the mobile subscriber and a third party application or content provider. Given the importance of these third parties to the operator's business, the operator's IPv6 transition plans have to ensure continuity of service to the third party servers regardless of the IP version they run. At the subscriber end, mobile handsets are typically replaced within two to three years after purchase, apparently putting an upper limit on how long it will take to make IPv6 the preferred protocol for the majority of subscribers. However, in some markets the most popular use of mobile data access is to provide access for personal computers attached to the mobile terminal. This means the transition period at the subscriber end depends to an important extent on the rate at which personal computer operating systems and applications evolve to support IPv6. As a further complication for the migration to IPv6, the operator is facing a major upgrade of its access networks from the older 3GPP technology to LTE ("Long Term Evolution"). LTE flattens out the access network by bringing the IP edge closer to the user equipment. LTE will provide higher data rates, opening up the possibilities for improved services and increased revenue from them. 1.1. Requirements Language This document is descriptive, and as such, contains no requirements language. 2. Overview of the Mobile Network Architecture 3GPP has specified layer 2 access for IPv6 in the legacy 3GPP architecture and in the LTE ("Long Term Evolution") version. The Zhou & Taylor Expires April 22, 2011 [Page 3] Internet-Draft Mobile Use Case October 2010 third generation architecture is shown in Figure 1. Only the user data paths are shown. The IP edge (of the core IP network) is located at the GGSN (Gateway GPRS Support Node, where GPRS itself stands for General Packet Radio Service). Within this system, IPv6 support requires separate bearers (i.e., links) for IPv4 and IPv6 respectively, extending from the User Equipment through the radio network and the SGSN (Serving GPRS Support Node, at which the User Equipment is registered) and, finally, to the GGSN. The bearers are actually propagated from the SGSN to the GGSN using GTP-U, a 3GPP-specified tunneling protocol running over IP. The IP addresses assigned to the SGSN and GGSN for this purpose are not visible to the mobile station. The SGSN locates the GGSN using a DNS service that is also not visible to the User Equipment. +-----+ | | | HSS | | | +-----+ IPv4 link +--------------+ / | | +----+ / +-----+ +------+ +------+ | | |....| |....| |.......| | Core | | UE | L2 | RAN | L2 | SGSN | \ | GGSN | IP | | |....| |....| |....\..| | Network | +----+ \ +-----+ +------+ \ \ +------+ | \ \ \ | | IPv6 link \ \ +--------------+ Links tunnelled over GTP-U over IP UE = User Equipment RAN = Radio access network SGSN = Serving GPRS Support Node GGSN = Gateway GPRS Support Node HSS = Home Subscriber Server (holds subscriber profile) GTP = GPRS Tunneling Protocol Figure 1: Third Generation GPRS Mobile Access Network The use of IPv4 and/or IPv6 is controlled by the combination of subscriber profile and core operator preference. Address allocation to the User Equipment (UE) differs between IPv4 and IPv6. For IPv4, addresses can be assigned in a number of ways. From the point of view of the UE, the choice is between allocation during bearer Zhou & Taylor Expires April 22, 2011 [Page 4] Internet-Draft Mobile Use Case October 2010 activation vs. DHCPv4 exchanges with the core network following bearer activation. From the point of view of the network, the choices are between static and dynamic address allocation. For dynamic allocation, the choice is between: o allocation by the access network (with the GGSN responsible for managing the address pool); o allocation by the core network (with the GGSN acting as DHCPv4 or RADIUS client and passing the configuration data on to the UE during bearer setup; or o via DHCPv4 to the UE after bearer setup, as already mentioned. IPv6 prefix allocation is done by stateless address autoconfiguration (SLAAC), with the GGSN responsible for sending Router Announcements in response to the UE's Router Solicitation. For further details see Sections 9.2.1 and 9.2.1.1 of [3GPP_TR_23_060]. The fourth generation mobile access architecture is described in [3GPP_TR_23_401] and [3GPP_TR_23_402] and shown in Figure 2. The SGSN has been split into a control part, the Mobile Management Entity (MME), and a forwarding part, the Serving Gateway (SGW). The GGSN has been replaced by the Packet Data Network Gateway (PDN Gateway, or PGW). The user data path to the core network changes in several ways with LTE. First, it becomes possible to carry both IPv4 and IPv6 over the same bearer. Thus the figure shows only a single link from the User Equipment to the PDN Gateway. The second change is that the layer 2 protocol used in the third generation architecture to carry the link between the edge of the Radio Access Network and the SGSN is replaced by a tunnel over IP, the same protocol stack (User packets/GTP- U/IP/...) used between the SGSN and the GGSN. Finally, the operator has the option to use PMIPv6 [RFC5213] instead of GTP-U tunneling between the SGW and the PDN Gateway. The SGW acts in the role of Mobility Access Gateway (MAG), while the PDN Gateway acts in the role of Local Mobility Anchor (LMA). PMIP is used only when the core IP network to which the UE is connected has the same operator as the access network. Zhou & Taylor Expires April 22, 2011 [Page 5] Internet-Draft Mobile Use Case October 2010 +--------+ | HSS | +--------+ +---------+ | PCRF | +---------+ +---------+ | MME | +---------+ +------------+ | | +----+ +------ +-----+ +-----+ Core | | UE |.....| RAN |.....| SGW |.....| PGW | IP | +----+ +-----+ +-----+ +-----+ Network | | | +------------+ UE = User Equipment RAN = Radio Access Network SGW = Serving Gateway PGW = Packet Data Network (PDN) Gateway MME = Mobility Management Entity PCRF = Policy and Charging Rules Function HSS = Home Subscriber Server Figure 2: Long Term Evolution (LTE) Mobile Access Network Essentially the same options are available in LTE for address configuration of the User Equipment, except that the PDN Gateway replaces the GGSN as the entity responsible for obtaining and propagating that information. To ease the upgrade from third generation access to LTE, it is possible to mix equipment types in the same access network. Traffic from the SGSN is forwarded to the SGW, which relays it to the PDN. If the Radio Access Network control is upgraded to use GTP tunneling, it is possible to tunnel traffic directly between the Radio Access Network and the SGW. The SGSN retains a control function. The final step is to replace the SGSN by an MME to carry out the control function. To achieve service continuity during handover, legacy mobile devices support MIPv4 [RFC3344]. The GGSN provides the Foreign Agent functionality. More recent devices support DSMIPv6 [RFC5555]. DSMIPv6 assumes that both the UE and the Home Agent are dual-stack. 3. Approaches To IPv4 / IPv6 Coexistence This section discusses the coexistence of user-plane IPv4 and IPv6 traffic. The operator is also faced with the upgrade of the network equipment to use IPv6 for control signalling and for the IP wrapper Zhou & Taylor Expires April 22, 2011 [Page 6] Internet-Draft Mobile Use Case October 2010 for PMIP and GTP-U tunnels carrying user data. This upgrade can proceed independently of the work on user-plane traffic, but presents its own coexistence problem. In the immediate case this is because it will take time to reconfigure all of the equipment in one network. Over the longer term the problem arises because different networks will upgrade at different times, and they must interoperate to support mobile roaming in the meantime. 3.1. IPv6 Coexistence Strategy 1: Dual-Stack Connectivity With Limited Public IPv4 Address Pools In this IPv6 transition scenario, the UEs operate in dual stack mode and are assigned both an IPv6 prefix and an IPv4 address in order to allow them to utilise both IPv4- and IPv6-capable applications. Dual-stack UEs are able to support parallel IPv4 and IPv6 connectivity to a single PDN. As popular services start to support IPv6, IPv4 traffic will gradually be offloaded into the IPv6 domain. Services owned and deployed by the operator may be IPv6-enabled first (while retaining IPv4 capability) and hence will be accessible to dual-stack capable MSs running IPv6. Issue: In dual stack mode, every UE still needs an IPv4 address. As the number of subscribers grows, the lack of additional public IPv4 addresses will force the use of private rather than public IPv4 addresses for some UEs. Aside from anything else, this will complicate the operation of mobile IP. 3.2. IPv6Coexistence Strategy 2: Dual Stack Connectivity With Limited Private IPv4 Address Pools In this scenario, UEs operate in dual stack mode and are assigned both an IPv6 prefix and a private IPv4 address in order to allow them to utilise both IPv4- and IPv6-capable applications. The IPv4 addresses assigned to UEs are taken from one of the private address ranges specified in RFC 1918. NAT is performed on the interface between the PDN Gateway and the core IP network. Issue : The number of private IP addresses is limited. If more than 16 million UEs are active in the same network simultaneously, the network could run out of private IPv4 addresses to assign. The problem could be worse than this, depending on how many addresses are temporarily unused because they haven`t been reclaimed after the UE roamed out of the network or shut down. Zhou & Taylor Expires April 22, 2011 [Page 7] Internet-Draft Mobile Use Case October 2010 3.3. IPv6 Coexistence Strategy 3: UEs With IPv6-only Transport and Applications Using IPv6 In this scenario, the operator decides to assign only IPv6 prefixes to the UEs due to, e.g., shortage of IPv4 addresses or because the UEs support only IPv6. Issue: UEs with IPv6-only connectivity running applications using IPv6 should be able to access both IPv4- or IPv6-enabled services. NAT64 and DNS64 should be performed to let the IPv6-only UEs have access to IPv4 services. 3.4. IPv6 Coexistence Strategy 4: IPv4 Applications Running On a Dual- Stack Host With an Assigned IPv6 Prefix and a Shared IPv4 Address In this scenario an IPv4 application running on a dual-stack UE needs to access IPv4 services without the operator having to allocate a unique non-shared (private or public) IPv4 address to the UE. The dual-stack UE running these applications uses an IPv4 address that is shared amongst many other UEs, and uses an IPv6 prefix. Issue: The obvious issue arises, that IPv4 services need to be able to distinguish between UEs using the same IPv4 address. The source port may be used for this purpose. 4. Consideration of IPv4 / IPv6 Coexistence Solutions The different strategies described above require support to make them work. 4.1. Gateway-Initiated Dual-Stack Lite Dual-stack lite (DS-lite) [I-D.softwire-dual-stack-lite-06] transports IPv4 traffic from the user device in an IPv6 tunnel across an IPv6 provider network to a NAT44, where sharing of IPv4 public addresses can be implemented. To prevent user DNS queries from going through the NAT44, all queries are intercepted and sent to an IPv6 DNS server. Gateway-initiated DS-lite [I-D.softwire-gateway-init-ds-lite-00] makes explicit use of the tunnel set up through the access network to carry user packets to the IP network. The gateway at the IP end of this tunnel maintains a single tunnel between itself and the NAT44, to which it forwards packets from all of the user devices connected to it. The inner source IP address of the individual packets is actually a 32-bit context identifier used with other information to retrieve forwarding state at the gateway and the NAT44. Gateway-initiated DS-lite also reduces or in some configurations eliminates the need for a unique Zhou & Taylor Expires April 22, 2011 [Page 8] Internet-Draft Mobile Use Case October 2010 IPv4 address, public or private, at the UE. As applied to the architectures described in Section 2, the gateway is represented by the PDN Gateway or GGSN. The NAT44 is located beyond the gateway, in the core IP network. The access tunnels are GTP over IP, and indeed the tunnel IP version may be either IPv4 or IPv6 without affecting the operation of gateway-initiated DS lite. Section 5.6.1.2 of [3GPP_TR_23_060] suggests that GTP tunnels run between the core nodes too, so the core network may run IPv4 or IPv6 independently of what is used in the access network. By making the IPv4 address provisioned at the UE almost irrelevant, gateway-initiated DS-lite supports any of the strategies described in Section 3 except the all-IPv6 approach. One issue is that, at the beginning when most traffic is IPv4, a large investment in NAT44 capacity will be needed. As traffic migrates to IPv6, this investment becomes stranded and not reusable. Another issue is that all IPv4 traffic suffers the quality of service penalty imposed by the use of NAT. One issue that has to be resolved is how to handle DNS queries for IPv4 addresses. [I-D.softwire-dual-stack-lite-06] requires that all DNS queries be sent to an IPv6 DNS server. Discussion on the softwires list leading up to this suggested that from there, A record requests could be forwarded to an IPv4 server. Alternatively, the IPv6 server could maintain both AAAA and A records. A third possibility was that the address of an IPv4 DNS server could be configured manually at the UE. This is messy, both on grounds of operational cost and because it would push DNS queries through the NAT44, greatly increasing its workload. 4.2. Protocol Translation NAT-PT was first described in [RFC2766]. [RFC4966] summarized a number of issues identified with NAT-PT in the intervening years. As a result, [RFC2766] was deprecated and given Historic status. The IETF has made a new attempt at solving the problem. [ID_v6v4_framework] explores a number of different translation scenarios. Any particular application must identify which of the scenarios it is dealing with before it can choose stateless versus stateful translation. [ID_IVI] reports on an early implementation of stateless translation, operating in the two directions between an IPv6 network and the IPv4 Internet. This has been deployed in the China Education and Research Network (CERNET). IVI predates the official IETF work in this area, references to which are given both in [ID_v6v4_framework] and Zhou & Taylor Expires April 22, 2011 [Page 9] Internet-Draft Mobile Use Case October 2010 [ID_IVI]. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations This memo does not in itself introduce any security issues. 7. informative References [3GPP_TR_23_060] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2 (Release 9)", TR 23.060, June 2010. [3GPP_TR_23_401] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 9)", TR 23.401, March 2010. [3GPP_TR_23_402] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses (Release 9)", TR 23.402, June 2010. [I-D.huang-behave-pnat-01] Huang, B., "Prefix NAT: Host based IPv6 translation", February 2010. [I-D.softwire-dual-stack-lite-06] Durand, A., "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", August 2010. [I-D.softwire-gateway-init-ds-lite-00] Brockners, F., "Gateway Initiated Dual-Stack Lite Deployment", May 2010. [ID_IVI] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "", January 2010. Zhou & Taylor Expires April 22, 2011 [Page 10] Internet-Draft Mobile Use Case October 2010 [ID_v6v4_framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation (Work in progress)", August 2010. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. Authors' Addresses Cathy Zhou (editor) Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathyzhou@huawei.com Tom Taylor Huawei Technologies 1852 Lorraine Ave. Ottawa K1H 6Z8 Canada Phone: Email: tom111.taylor@bell.net Zhou & Taylor Expires April 22, 2011 [Page 11]