v6ops Working Group Rajeev Koodli Internet-Draft Cisco Systems Intended status: Standards Track April 14, 2010 Expires: October 16, 2010 Mobile Networks Considerations for IPv6 Deployment draft-koodli-ipv6-in-mobile-networks-02.txt Abstract Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. 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 October 16, 2010. 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 Koodli Expires October 16, 2010 [Page 1] Internet-Draft IPv6 in Mobile Networks April 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Architecture and Terminology . . . . . . . . . . . . 3 3. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 5 3.1. IPv4 Address Exhaustion . . . . . . . . . . . . . . . . . 5 3.2. NAT Placement in the mobile networks . . . . . . . . . . . 7 3.3. IPv6-only Deployment Considerations . . . . . . . . . . . 9 3.4. Fixed - Mobile Convergence . . . . . . . . . . . . . . . . 12 4. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Koodli Expires October 16, 2010 [Page 2] Internet-Draft IPv6 in Mobile Networks April 2010 1. Introduction The dramatic growth of the Mobile Internet is accelerating the exhaustion of available IPv4 addressing pool. It is widely accepted that IPv6 is necessary for the continued operation, and growth of the Internet in general, and that of the Mobile Internet in particular. When deploying IPv6 in mobile networks, certain unique challenges arise. This document describes such challenges, and outlines the applicability of the existing IPv6 deployment solutions. As such, it can be a useful reference document for service providers as well as network designers. This document does not propose any new protocols or suggest new protocol specification work. The primary considerations that we address in this document on IPv6 deployment in mobile networks are: o Public and Private IPv4 address exhaustion and implications to mobile network deployment architecture; o Placement of Network Address Translation (NAT) functionality and its implications; o IPv6-only deployment considerations and roaming; o Fixed-Mobile Convergence and implications to overall architecture. In the following sections, we discuss each of these in detail. For the most part, we assume the 3GPP 3G and 4G network architectures specified in [3gpp.3g] and [3gpp.4g]. However, the considerations are general enough for other mobile network architectures as well [3gpp2.ehrpd]. 2. Reference Architecture and Terminology The following is a reference architecture of a mobile network. Koodli Expires October 16, 2010 [Page 3] Internet-Draft IPv6 in Mobile Networks April 2010 +-----+ +-----+ | AAA | | PCRF| +-----+ +-----+ Home Network \ / \ / \ / /- MN BS \ / / | /\ +-----+ /-----------\ +-----+ /-----------\ +-----+ / +-+ /_ \---| ANG |/ Operator's \| MNG |/ Operator's \| BR |/Inte | |---/ \ +-----+\ IP Network /+-----+\ IP Network /+-----+\rnet +-+ \-----------/ / \-----------/ \ ----------------/------ \- Visited Network / / +-----+ /------------------\ |ANG |/ Visited Operator's \ +-----+\ IP Network / \------------------/ Figure 1: Mobile Network Architecture A Mobile Node (MN) connects to the mobile network either via its Home Network or via a Visited Network when roaming. In the 3GPP network architecture, a MN accesses the network by connecting to an Access Point Name (APN), which maps to a mobile gateway. Roughly speaking, an APN is similar to an SSID in wireless LAN. An APN is a logical concept which can be used to specify what kinds of services, such as Internet access, high-definition video streaming, content-rich gaming, and so on, a MN is entitled to. And, each APN can specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN. Whereas an APN directs a MN to an appropriate gateway, the MN needs (an end-end) 'link' to the gateway, which is realized through a Packet Data Network (PDN) connection in the Long-term Evolution (LTE) networks, and through a Packet Data Protocol Context/connection in 3G UMTS networks. The different nodes in the figure are defined below: o ANG: The Access Network Gateway. This is a node that forwards IP packets to and from the MN. Typically, this is not the MN's default router, and the ANG does not perform IP address allocation and management for the mobile nodes. Koodli Expires October 16, 2010 [Page 4] Internet-Draft IPv6 in Mobile Networks April 2010 o MNG: The Mobile Network Gateway is the MN's default router which provides IP address management. The MNG performs functions such as offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting; these functions are sometimes collectively referred to as "subscriber-management" operations. The mobile network architecture, as shown in the figure, defines the necessary protocol interfaces to enable subscriber management operations. o BR: The Border Router, as the name implies, borders the Internet for the mobile network. The BR does not perform subscriber management for the mobile network. o AAA: Authentication, Authorization and Accounting. The general functionality of AAA is used for subscriber authentication and authorization for services, as well as for generating billing and accounting information. In 3GPP network environments, the subscriber authentication and the subsequent authorization for connectivity and services is provided using the "Home Subscriber Server" (HSS) functionality. o PCRF: Policy and Charging Rule Function enables applying policy and charging rules at the MNG. In the rest of this document, we use the terms operator, service provider or provider interchangeably. 3. IPv6 Considerations 3.1. IPv4 Address Exhaustion It is generally agreed that the pool of public IPv4 addressing is nearing its exhaustion. The '/8' IANA blocks for Regional Internet Registries (RIRs) are projected to 'run-out' towards the end of 2011. Subsequently, the addressing pool available to RIRs for assignment to Internet Service Providers is anticipated to run-out in the following 2-3 years. This has led to a hightened awareness among the providers to consider introducing technologies to keep the Internet operational. There are two simultaneous approaches to addressing the run-out problem: delaying the IPv4 address exhaustion, and introducing IPv6 in operational networks. We consider both in the following. Delaying the public IPv4 address exhaustion involves assigning private IPv4 addressing for end-users, as well as extending an IPv4 address (with the use of extended port ranges). Mechanisms such as a Koodli Expires October 16, 2010 [Page 5] Internet-Draft IPv6 in Mobile Networks April 2010 Network Address Translator (NAT) and "A+P" are used at the provider premises (as opposed to customer premises in the existing deployments) to manage IP address assignment and access to the Internet. In the following, we primarily focus on translation based mechanisms such as NAT44 (i.e., translation from public IPv4 to private IPv4 and vice versa) and NAT64 (i.e., translation from public IPv6 to public IPv4 and vice versa). In a mobile network, the IPv4 address assignment for a MN is performed by the MNG. In the 3GPP network architecture, this assignment is performed in conjunction with the PDN connectivity establishment. As mentioned earlier, a PDN can be understood to be the end-end link from the MN to the MNG. There can be one or more PDN connections active at any given time for each MN. A PDN connection may support both IPv4 and IPv6 traffic (as in a dual-stack PDN in 4G LTE networks) or it may support either one only (as in the existing 3G UMTS networks). The IPv4 address is assigned at the time of PDN connectivity establishment, or is assigned using the DHCP protocol after the PDN connectivity is established. This IP address needs to be a private IPv4 address which is translated into a shared public IPv4 address in order to delay the exhaustion of public IPv4 addresses as IPv6 is being deployed. Hence, there is a need for private - public IPv4 translation mechanism in the mobile network. In the Long-Term Evolution (LTE) 4G network, there is a requirement for an always-on PDN connection in order to reliably reach a mobile user in the All-IP network. If this PDN connection were to use IPv4 addressing, a private IPv4 address is needed for every MN that attaches to the network. This could significantly affect the availability and usage of private IPv4 addresses. Alternatively, the always-on PDN connection may be assigned with an IPv6 prefix (typically a /64) at the time of connection establishment, and an IPv4 address is assigned only on-demand (e.g., when an application binds to an IPv4 socket interface). This is feasible on the same (dual-stack) PDN in LTE networks (with short DHCP lease times), or with on-demand IPv4 PDNs. On-demand IPv4 PDN and address management can be effective in conserving IPv4 addresses; however, such a management could have some implications to how the PDN and addresses are managed at the MN. On the other hand, in the existing 3G UMTS networks, there is no requirement for an always-on connection (a 'link' from the MN to the MNG in 3G UMTS is referred to as a Packet Data Protocol (PDP) context/connection) even though many SmartPhones seldom relinquish an established PDP context. And, the existing (so-called pre-Release-8) deployments do not support the dual-stack PDP connection. Hence two separate PDP connections are necessary to support IPv4 and IPv6 traffic. Even though some MNs (especially the SmartPhones) in use Koodli Expires October 16, 2010 [Page 6] Internet-Draft IPv6 in Mobile Networks April 2010 today may have IPv6 stack, such a capability is not tested (if any at all) extensively and deployed in operational networks. Given this, it is reasonable to expect that IPv6 can only be introduced in the newer MNs, and that such newer MNs still need to be able to access the (predominantly IPv4) Internet. The considerations from the preceeding paragraphs lead to the following observations. First, there is a need to support private IPv4 addressing in mobile networks in order to address the public IPv4 run-out problem. This means there is a need for private - public IPv4 translation in the mobile network. Second, there is support for IPv6 in both 3G and 4G LTE networks already in the form of PDP context and PDN connections. Operators can introduce IPv6 in their networks, perhaps to access operator's own applications and services to begin with. In other words, the IETF's dual-stack model of separate IPv6 and IPv4 networks is readily applicable to mobile networks with the support for distinct APNs and the ability to carry IPv6 traffic on PDP/PDN connections. Finally, operators can make IPv6 as the default for always-on mobile connections, and use IPv4 (private) addressing only on-demand. 3.2. NAT Placement in the mobile networks In the previous section, we observed that the NAT44 functionality is needed in order to conserve the available pool, and delay public IPv4 address exhaustion. However, the available private IPv4 pool itself is not abundant for large networks such as mobile networks. For instance, the so-called NET10 block [RFC1918] has approximately 16.7 million private IPv4 addresses starting with 10.0.0.0. A large mobile service provider network can easily have more than 16.7 million subscribers attached to the network at a given time. Hence, the private IPv4 address pool management and the placement of NAT44 functionality becomes important. In addition to the developments cited above, NAT placement is important for other reasons. Access networks generally need to produce network and service usage records for billing and accounting. This is true for mobile networks as well where "subscriber management" features (i.e., QoS, Policy, and Billing and Accounting) can be fairly detailed. Since a NAT introduces a binding between two addresses, the bindings themselves become necessary information for subscriber management. For instance, the offered QoS on private IPv4 address and the (shared) public IPv4 address may need to be correlated. And, the subscriber session management information and the service usage information also need to be correlated in order to produce harmonized records. Furthermore, there may be legal requirements to store the NAT binding records. Indeed, these problems disappear with the transition to IPv6. For now, it suffices Koodli Expires October 16, 2010 [Page 7] Internet-Draft IPv6 in Mobile Networks April 2010 to state that NAT introduces state which needs to be correlated and possibly stored with other routine subscriber information. Mobile network deployments vary in their allocation of IP address pools. Some network deployments use the "centralized model" where the pool is managed by a common node, such as the PDN's Border Router, and the pool shared by multiple gateways all attached to the same BR. This model has served well in the pre-3G deployments where the number of subscribers accessing the mobile Internet at any given time perhaps did not exceed the available address pool. However, with the advent of 3G networks and the subsequent dramatic growth in the number of users on the mobile Internet, the service providers are increasingly forced to consider their existing network design and choices. Specifically, the providers are forced to address private IPv4 pool exhaustion as well as scalable NAT solutions. In order to address the private IPv4 exhaustion in the "centralized model", there would be a need to support overlapped private IPv4 addresses in the common NAT functionality as well as in each of the gateways. In other words, the IP addresses used by two or more MNs (which may be attached to the same MNG) are very likely to overlap at the centralized NAT, which needs to be able to differentiate traffic. The approach specified in [gi-ds-lite] is one way to achieve traffic separation for overlapping private IPv4; the others include MPLS VPN tunnels or any tunneling mechanism with a unique identifier for the session. An obvious advantage of centralizing the NAT and using overlapped private IPv4 addressing is that a large number of mobile subscribers can be supported with a common limited pool at the BR. It also enables the operator's enterprise network to use IPv6 from the MNG to the BR. The disadvantages include diminished subscriber management, need for additional protocol to correlate the NAT state (at the common node) with subscriber session information (at each of the gateways), suboptimal MN - MN communication, and of course the need for a protocol from the MNG to BR itself. Also, if the NAT function were to experience failure, all the connected gateway service will be affected. These drawbacks are not present in the "distributed" model which we discuss in the following. In a "distributed" model, the private IPv4 address management is performed by the MNG which also performs the NAT functionality. In this model, each MNG has a block of 16.7 million unique addresses, which is sufficient compared to the number of mobile subscribers active on each MNG. By distributing the NAT functionality to the edge of the network, each MNG is allowed to re-use the available NET10 block, which avoids the problem of overlapped private IPv4 addressing at the network core. In addition, since the MNG is where subscriber management functions are located, the NAT state correlation is readily enabled. Furthermore, an MNG already has Koodli Expires October 16, 2010 [Page 8] Internet-Draft IPv6 in Mobile Networks April 2010 existing interfaces to functions such as AAA and PCRF, which allows it to perform subscriber management functions with the unique private IPv4 addresses. Finally, the MNG can also pass-through certain traffic types without performing NAT to the application servers located within the service provider's domain, which allows the servers to also identify subscriber sessions with unique private IPv4 addresses. The foregoing discussion can be summarized as follows: First, the management of available private IPv4 pool has become important given the growth of the mobile Internet users. The mechanisms that enable re-use of the available pool are required. Second, in the context of private IPv4 pool management, the placement of NAT functionality has implications to the network deployment and operations. Whereas the "centralized" models with a common NAT have the advantages of continuing their legacy deployments, re-use of private IPv4 addressing, and centralized NAT, they need additional functions to enable traffic differentiation, and NAT state correlation with subscriber state management at the MNG. The "distributed" models also achieve private IPv4 address re-use, and avoid overlapping private IPv4 traffic in the operator's core, but without the need for additional mechanisms. They also readily enable subscriber awareness since the (unique) IPv4 address management is performed by the MNG, which already has well-defined interfaces to AAA, and PCRF. In summary, providers interested in readily integrating NAT with other subscriber management functions, as well as conserving and re-using their private IPv4 pool, may find the distributed model compelling. 3.3. IPv6-only Deployment Considerations As we observed in the previous section, the NAT functionality in the network brings multiple issues which would otherwise be not present with the end-end access. NAT should be viewed as an interim solution until IPv6 is widely available, i.e., it is available for mobile users for all (or most) practical purposes. Whereas NATs at provider premises may slow down the exhaustion of public IPv4 addresses, expeditious and simultaneous introduction of IPv6 in the operational networks is necessary to keep the "Internet going and growing". Towards this goal, it is important to understand the considerations in deploying IPv6-only networks. There are three dimensions to IPv6-only deployments: the network itself, the mobile nodes and the applications, represented by the tuple [nw, mn, ap]. The goal is to reach the co-ordinate [IPv6, IPv6, IPv6] from [IPv4, IPv4, IPv4]. However, there are multiple paths to arrive at the goal. The classic dual-stack model would traverse the co-ordinate [IPv4v6, IPv4v6, IPv4v6], where each dimension supports co-existence of IPv4 and IPv6. This appears to be Koodli Expires October 16, 2010 [Page 9] Internet-Draft IPv6 in Mobile Networks April 2010 the path of least disruption, although we are faced with the implications of supoorting large-scale NAT in the network. The other intermediate co-ordinate of interest is [IPv6, IPv6, IPv4], where the network and the MN are IPv6-only, and the Internet applications are recognized to be predominantly IPv4. This transition path would, ironically, require interworking between IPv6 and IPv4 in order for the IPv6-only MNs to be able to access IPv4 services and applications on the Internet. In other words, in order to disengage NAT (for IPv4 - IPv4), we need to introduce another form of NAT (i.e., IPv6 - IPv4) to expedite the adoption of IPv6. It is interesting to consider the preceeding discussion surrounding the placement of NAT for IPv6 - IPv4 interworking. There is no overlapping private IPv4 address problem because each IPv6 address is unique (and there are plenty of them available!). Hence, there is also no requirement for (IPv6) address re-use, which means no protocol is necessary in the "centralized model" to disambiguiate NAT sessions. However, an IPv6 prefix is managed and assigned by the MNG (unlike in the "centralized" NAT44 model where address pool management is common for all the gateways). Hence, the subscriber management functions for the IPv6 prefix are vastly simplified. Furthermore, for NAT binding correlation, billing and accounting, as well as for subscriber management, it may be beneficial to locate the IPv6 - IPv4 interworking function at the MNG. The IPv6-only deployments in mobile networks need to recknon with the following considerations. First, both the network and the MNs need to be IPv6-capable. Expedited network upgrades as well as roll-out of MNs with IPv6 would greatly facilitate this. Fortunately, the 3GPP network design for LTE already requires the network nodes and the mobile nodes to support IPv6. Even though there are no requirements for the transport network to be IPv6, an operational IPv6 network can be deployed with configured tunneling between the network nodes with IPv4-only transport. Hence a service provider may choose to enforce IPv6-only PDN and address assignment for their own subscribers in their Home Networks, see Figure 1. This is feasible for the newer MNs when the provider's network is "IPv6-ready", which means the network is able to provide IPv6-only PDN support and IPv6 - IPv4 interworking for Internet access. For the existing MNs however, the provider still needs to be able to support IPv4-only PDP/PDN connectivity. Migration of applications to IPv6 in MNs with IPv6-only PDN connectivity brings challenges. The applications and services offered by the provider obviously need to be IPv6-capable. However, a MN may be host other applications which also need to be IPv6- capable in IPv6-only deployments. This can be a "long-tail" phenomenon; however, when a few prominant applications start offering Koodli Expires October 16, 2010 [Page 10] Internet-Draft IPv6 in Mobile Networks April 2010 IPv6, there can be a strong incentive to provide application layer (e.g., socket interface) upgrades to IPv6. Furthermore, some IPv4- only applications may be able to make use of alternative access such as WiFi when available. In summary, application migration to IPv6 needs to be done even though it is likely to take a while before all applications migrate to IPv6. An important consideration in mobile networks is roaming, where users may roam to networks operated by providers other than their own. The service providers can control their own network design but not their peer's networks which they rely on for roaming. Perhaps more importantly, the users expect similar experience even when they are roaming. This imposes a constraint on providers interested in IPv6- only deployments to also support IPv4 addressing when their own (outbound) subscribers roam to networks which do not offer IPv6. This is a realistic scenario today where an LTE deployment may be IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN connectivity service. Since a PDN connection involves the radio base station, the ANG and the MNG (See Figure 1), it would not be possible to enable IPv6 PDN connectivity without the roamed network support. Similarly, there are inbound roamers to an IPv6-ready provider network whose MN's are not capable of IPv6. The IPv6-ready provider network has to be able to support IPv4 PDN connectivity for such inbound roamers as well. There are encouraging signs that the existing deployed network nodes in 3GPP architecture already provide support for IPv6 PDP context. It would be necessary to scale this support for a (very) large number of mobile users. In summary, IPv6-only deployments should be encouraged. This is relatively straightforward for an operator's own services and applications, provisioned through an appropriate APN (and IPv6-only PDP/PDN). Some providers may consider IPv6-only deployment for Internet access as well, and this would require IPv6 - IPv4 interworking. Such IPv6-only deployments can be phased-in for newer mobile nodes, while the existing ones continue to demand IPv4-only connectivity. Roaming is important in mobile networks and roaming introduces diversity in network deployments. This means IPv6-only mobile network deployments need to support IPv4 connectivity (and NAT44) for their own users who roam into peer provider networks, and also for inbound roaming users with no IPv6 capability. However, by taking the initiative to introduce IPv6-only for the newer MNs, the mobile networks can significantly reduce the demand for private IPv4 addresses. Koodli Expires October 16, 2010 [Page 11] Internet-Draft IPv6 in Mobile Networks April 2010 3.4. Fixed - Mobile Convergence Many service providers have both fixed broadband and mobile networks. Access networks are generally disparate, with some common characteristics but with enough differences to make it challenging to achieve "convergence". For instance, roaming is not a consideration in fixed access networks. And, an All-IP mobile network service provider is required to provide voice service as well, whereas a fixed network provider is not required to. A "link" in fixed networks is generally capable of carrying IPv6 and IPv4 traffic, whereas not all mobile networks have "links" (i.e., PDP/PDN connections) capable of supporting IPv6 and IPv4; indeed roaming makes this problem worse when a "portion" of the link (i.e., the Home Network in Figure 1) is capable of supporting IPv6 and the other "portion" of the link (i.e., the Visited Network in Figure 1) is not. Such architectural differences as well as policy and business model differences make convergence challenging. Nevertheless, within the same provider's space, some common considerations may apply. For instance, IPv4 address management is a common concern for both the access networks. This implies the same mechanisms discussed earlier, i.e., delaying IPv4 address exhaustion and introducing IPv6 in operational networks, apply for the "converged" networks as well. However, the exact solutions deployed for each access network can vary for a variety of reasons. Tunneling of private IPv4 packets within IPv6, for example, is feasible in fixed networks where the end-point is often a cable or DSL modem. This is not the case in mobile networks where the end-point is a MN itself. Similarly, encapsulation-based mechanisms such as 6rd [6rd] are feasible where a residential gateway can become a tunnel end- point for connecting subscribers to IPv6-only networks, whereas translation is perhaps necessary for IPv6-only mobile networks. A mobile network provider may have application servers (e.g., an email server) in its network that require unique private IPv4 addresses for MN identification, whereas a fixed network provider may not have such a requirement or the service itself. These examples illustrate that the actual solutions used in an access network are largely determined by the requirements specific to that access network. However, some sharing between access and core network may be possible depending on the nature of the requirement and the functionality itself: for example, when a fixed network does not require a subscriber-aware feature such as NAT, the functionality may be provided at a core router while the mobile access network continues to provide the NAT functionality at the mobile gateway. Different access networks of a provider are more likely to share a common core network. Hence, common solutions can be more easily applied in the core network. For instance, configured tunnels or Koodli Expires October 16, 2010 [Page 12] Internet-Draft IPv6 in Mobile Networks April 2010 MPLS VPNs from the gateways from both mobile and fixed networks can be used to carry traffic to the core routers, until the entire core network is IPv6-enabled. In summary, there is clear interest in fixed-mobile convergence at least among some providers. While there are benefits from harmonizing the network as much as possible, there are also idiosyncrasies of disparate access networks which influence the convergence. Perhaps greater harmonization is feasible at the higher service layers, e.g., in terms of offering unified user experience for services and applications. Some harmonization of functions across access networks into the core network may be feasible. A provider's core network appears to the place where most convergence is feasible. 4. Summary and Conclusion IPv6 deployment in mobile networks is crucial for the mobile Internet. The 3GPP and IETF are working on the necessary system architecture and protocol mechanisms respectively, in order to enable IPv6 operational networks. In this document, we discussed the considerations in deploying IPv6 in mobile networks. Specifically, we discussed: o IPv4 address exhaustion and its implications to mobile networks: we saw that, as the mobile networks begin to deploy IPv6, conserving the available IPv4 pool and delaying its exhaustion implies the need for network translation in mobile networks. At the same time, providers can make use of the 3GPP architecture constructs such as the APN and PDN connectivity to introduce IPv6 without affecting the (predominantly IPv4) Internet access. The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily. o The placement of NAT functionality in mobile networks: we discussed the "centralized" and "distributed" models of private IPv4 address pool management and their relative merits. We saw that by enabling each MNG to manage its own NET10 pool, the distributed model achieves re-use of available private IPv4 pool, and avoids the problems associated with the non-unique private IPv4 addresses for the MNs without additional protocol mechanisms. The distributed model also augments the "subscriber management" functions at an MNG, such as readily enabling NAT session correlation with the rest of the subscriber session state. On the other hand, the existing deployments which have used the "centralized" IP address management can continue their legacy architecture by placing the NAT at a common node. The Koodli Expires October 16, 2010 [Page 13] Internet-Draft IPv6 in Mobile Networks April 2010 "centralized" model also achieves private IPv4 address re-use, but needs additional protocol extensions to differentiate overlapping addresses at the common NAT, as well as to integrate with policy and billing infrastructure. o IPv6-only mobile network deployments: we saw that this is feasible in the LTE architecture for an operator's own services and applications. We observed that the existing MNs still expect IPv4 address assignment. And, roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when their (outbound) users roam into a mobile network that is not IPv6-enabled. Similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs are not IPv6-capable. And, we also observed that IPv6 - IPv4 interworking is necessary for IPv6-only MNs to access IPv4 Internet. o Fixed-Mobile Convergence: we discussed the examples illustrating the differences in the requirements of fixed and mobile networks. While some harmonization of functions may be possible across the access networks, the service provider's core network is perhaps best-suited for converged network architecture. Perhaps even greater gains are feasible in the service and application layers. 5. Security Considerations This document does not introduce any new security vulnerabilities. 6. Acknowledgement This document has benefitted from discussions with and reviews from Cameron Byrne, David Crowe, Hui Deng, Fredrik Garneij, Teemu Savolainen and Dan Wing. Thanks to all of them. Mohamed Boucadier provided an extensive review of version 01; many thanks Mohamed. 7. Informative References [3gpp.3g] "General Packet Radio Service (GPRS); Service description; Stage 2, 3GPP TS 23.060, December 2006", . [3gpp.4g] "General Packet Radio Service (GPRS);enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 8.8.0, December 2009.", . Koodli Expires October 16, 2010 [Page 14] Internet-Draft IPv6 in Mobile Networks April 2010 [3gpp2.ehrpd] "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", http://www.3gpp2.org/Public_html/Misc/ X.P0057-0_v0.13_E-UTRAN- eHRPD_Interworking_VV_Due_5_December-2008.pdf. [6rd] Townsley, M. and O. Troan, "IPv6 via IPv4 Service Provider Networks "6rd"", draft-ietf-softwire-ipv6-6rd-04.txt, Feb 2010. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [gi-ds-lite] Brockners, F. and S. Gundavelli, "Gateway Initiated Dual- stack Lite Deployment", draft-gundavelli-softwire-gateway-init-ds-lite-01.txt, Oct 2009. Author's Address Rajeev Koodli Cisco Systems USA Email: rkoodli@cisco.com Koodli Expires October 16, 2010 [Page 15]