RFC 6312
Mobile Networks Considerations for IPv6 Deployment
Mobile Networks Considerations for IPv6 Deployment 📱✨
💅 Quick heads-up: you asked for RFC 6312, but this text is RFC 6212, the same paper with the same title, so that's the one I've rewritten. It's by R. Koodli of Cisco Systems, it's Informational, and it's dated July 2011. The header doesn't list any documents it obsoletes or updates, so it doesn't replace or change anything else. The ISSN is 2070-1721 🌸
Abstract ✨
Okay so mobile internet on phones and other devices is speeding up the running out of IPv4 addresses 😭 IPv6 is basically seen as crucial for the Internet to keep working and growing, and it's especially critical in mobile networks 💜 This doc looks at the problems you run into when you deploy IPv6 on mobile networks. So it's a useful reference for service providers and network designers 🫶
Status of This Memo
This doc is not an Internet Standards Track spec. It's published just for information 🌈
It's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🎀
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6312. Yes, that URL says 6312, and that's just how the original document has it 🙈
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they're in effect on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 📜
If you pull code components out of this doc, they must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License ⚠️
Table of Contents 🧚
1. Introduction ....................................................2
2. Reference Architecture and Terminology ..........................3
3. IPv6 Considerations .............................................4
3.1. IPv4 Address Exhaustion ....................................4
3.2. NAT Placement in Mobile Networks ...........................7
3.3. IPv6-Only Deployment Considerations ........................9
3.4. Fixed-Mobile Convergence ..................................12
4. Summary and Conclusion .........................................14
5. Security Considerations ........................................15
6. Acknowledgements ...............................................15
7. Informative References .........................................151. Introduction 🦋
The Mobile Internet is growing so fast that it's speeding up the exhaustion of the IPv4 addresses that are still available 🔥 It's widely accepted that IPv6 is necessary for the Internet to keep running and growing, and especially for the Mobile Internet 👑 IPv6 has tons of benefits, but deploying it on mobile networks comes with some unique challenges 🥺 This doc describes those challenges and lays out where the existing IPv6 deployment solutions do and don't apply. So it's a useful reference for service providers and network designers alike 💖 Also, this doc doesn't propose any new protocols or suggest new protocol specification work, so no new protocol drama here 🙅♀️
The main considerations this doc covers, for IPv6 deployment on mobile networks, are:
- Public and Private IPv4 address exhaustion, and how it affects mobile network deployment architecture 🌸
- Placement of Network Address Translation (NAT) functionality, and what that implies 🍓
- IPv6-only deployment considerations and roaming implications 🌍
- Fixed-Mobile Convergence, and what it means for the overall architecture 🧩
We go through each of these in detail in the following sections, so buckle up bestie 🎢
For the most part, we assume the Third Generation Partnership Project (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and [3GPP.4G]. But the considerations are general enough to apply to other mobile network architectures too [3GPP2.EHRPD] ✨
2. Reference Architecture and Terminology 🗺️
Here's a reference architecture of a mobile network. It's giving blueprint vibes 💅
+-----+ +-----+
| AAA | | PCRF|
+-----+ +-----+
Home Network \ /
\ / /-
\ / / I
MN BS \ / / n
| /\ +-----+ /-----------\ +-----+ /-----------\ +----+ / t
+-+ /_ \---| ANG |/ Operator's \| MNG |/ Operator's \| BR |/ e
| |---/ \ +-----+\ IP Network /+-----+\ IP Network /+----+\ r
+-+ \-----------/ / \-----------/ \ n
----------------/------ \ e
Visited Network / \ t
/ \-
+-----+ /------------------\
| ANG |/ Visited Operator's \
+-----+\ IP Network /
\------------------/Figure 1: Mobile Network Architecture 🖼️
A Mobile Node (MN) connects to the mobile network either through its Home Network, or through a Visited Network when the user is roaming outside the Home Network 🧳 In the 3GPP network architecture, an MN accesses the network by connecting to an Access Point Name (APN), and that APN maps to a mobile gateway. Roughly speaking, an APN is similar to a Service Set Identifier (SSID) in a wireless LAN 📶 An APN is a logical concept. It can be used to specify what kinds of services an MN is entitled to, like Internet access, high-definition video streaming, content-rich gaming, and so on 🎮 Each APN can also specify what type of IP connectivity (i.e., IPv4, IPv6, IPv4v6) is enabled on that particular APN 🌈
An APN points the MN to the right gateway, but the MN still needs an end-to-end "link" to that gateway. In Long-Term Evolution (LTE) networks, that link is realized through an Evolved Packet System (EPS) bearer. In 3G Universal Mobile Telecommunications System (UMTS) networks, the link is realized through a Packet Data Protocol (PDP) context 🧠 The end-to-end link goes through several nodes, which are defined below:
- Base Station (BS): The radio Base Station gives the MN its wireless connectivity 📡
- Access Network Gateway (ANG): The ANG forwards IP packets to and from the MN. Typically, this is not the MN's default router, and the ANG does not do IP address allocation and management for the mobile nodes 🚦 The ANG can be located either in the Home Network or in the Visited Network.
- The Mobile Network Gateway (MNG): The MNG is the MN's default router, and it handles IP address management ✨ It does things like offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting. These functions are sometimes collectively called "subscriber-management" operations 💰 The mobile network architecture, shown in Figure 1, defines the protocol interfaces needed to enable subscriber-management operations. The MNG is typically located in the Home Network 🏠
- Border Router (BR): As the name implies, a BR borders the Internet for the mobile network 🌐 The BR does not do subscriber management for the mobile network.
- Authentication, Authorization, and Accounting (AAA): The general AAA functionality is used for subscriber authentication and authorization for services, and for generating billing and accounting info 🧾
In 3GPP network environments, subscriber authentication, and the authorization for connectivity and services that follows, is provided using the "Home Location Register" (HLR) / "Home Subscriber Server" (HSS) functionality 🔐
- Policy and Charging Rule Function (PCRF): The PCRF enables applying policy and charging rules at the MNG 📋
Throughout the rest of this doc, we use the terms "operator", "service provider", and "provider" interchangeably 💜
3. IPv6 Considerations 🎀
…continued in Part 2 🦄
3.1. IPv4 Address Exhaustion ✨
okay so the public IPv4 pool is basically running on fumes 😭 everyone agrees on that. IANA has already used up its available '/8' blocks for handing out to the Regional Internet Registries (RIRs) 💀. Some RIRs have already run out of blocks, and others are projected to run out soon. So service providers are finally paying real attention and looking at new tech to keep the Internet running 🫶. For providers there are two approaches they can run at the same time: stretch out their existing IPv4 pool (conserving what they've got) and bring IPv6 into their operational networks 🦋. We're going to look at both.
Stretching the public IPv4 pool means giving end-users private IPv4 addresses, or squeezing more out of one IPv4 address by using port ranges. Both of those need tunneling and extra signaling, so it's not a free lunch 🙈. A mechanism like the Network Address Translator (NAT) sits at the provider premises (not the customer premises) and handles private address assignment and Internet access 🌸. From here on we're mostly focusing on translation-based mechanisms, specifically NAT44 (translating between public IPv4 and private IPv4, in both directions) and NAT64 (translating between public IPv6 and public IPv4, in both directions) 💅. The reason is that the 3GPP architecture already has a tunneling setup built in with the General Packet Radio Service (GPRS) Tunneling Protocol (GTP), and the architecture also supports dual-stack and IPv6-only deployments 🎀.
In a mobile network, the MNG is the one that assigns an IPv4 address to an MN 🧚. In the 3GPP network architecture, that assignment happens together with Packet Data Network (PDN) connectivity establishment. A PDN connection is an end-to-end link from the MN to the MNG (an EPS bearer in 4G LTE, or a PDP context in 3G UMTS) 💖. Each MN can have one or more PDN connections active at any given time. A PDN connection can carry both IPv4 and IPv6 traffic (like a dual-stack PDN in 4G LTE), or just one of the two (like in the existing 3G UMTS networks) 🌈. The IPv4 address gets assigned when the PDN connectivity is set up, or it can come from DHCP after the PDN is already up ✨. To slow down public IPv4 exhaustion, that address needs to be a private IPv4 address that gets translated into a shared public IPv4 address. That's why mobile networks need a private-public IPv4 translation mechanism, no cap 🔥.
In 4G LTE there's a requirement for an always-on PDN, so the network can reliably reach a mobile user in the All-IP network 📞. The reason is that Voice over IP has to work in LTE, and LTE doesn't have circuit-based infrastructure to fall back on 💜. If that always-on PDN used IPv4, then every MN attaching to the network would need its own private IPv4 address, which could seriously hit how available and how much private IPv4 addressing we can use 😬. One fix is to make the always-on PDN (the one that needs voice) IPv6, and only set up an IPv4 PDN when the user actually needs it 👑.
The 3GPP standards also describe deferred IPv4 address allocation on a dual-stack IPv4v6 PDN, decided at connection setup 🦋. The big win is one PDN doing both IPv6 and IPv4, with the IPv4 address held back until an application actually asks for it 💅. That deferral needs a dynamic configuration protocol like DHCP, plus the right triggers to kick it off 🍓. Right now mobile phones don't have that support. Newer smartphones might add it 📱. Tethering a smartphone to a laptop could also use deferred allocation, depending on when the laptop attaches to the smartphone, since laptops usually support DHCP 💻. Until the triggers and host stack support exist, deferred addressing might not be very useful 😭.
Now the 3G UMTS side. There's no always-on requirement there, even though lots of smartphones rarely let go of an established PDP context 🌸. The older pre-Release-8 deployments don't support dual-stack PDP connections, so you need two separate PDP connections to carry IPv4 and IPv6 traffic 🙃. A lot of MNs in use today, especially smartphones, may already have an IPv6 stack, but there are two things to keep in mind ⭐. First, there's very little operational experience and compliance testing for those existing stacks. So using them in big deployments could expose software errors and interoperability problems that stop IPv6 services from working on those hosts 💀. Second, only a fraction of phones out there have that stack. That means providers have to test, deploy, and operationalize IPv6 as they roll out new handsets, and those handsets still need to reach the mostly IPv4 Internet 🌈.
Putting all that together gives us three big takeaways 🎀. First, mobile networks have a growing need for private IPv4 addressing because of the public IPv4 run-out, which means they need private-public IPv4 translation more and more 💖. Second, both 3G and 4G LTE networks already support IPv6 through PDP contexts and PDN connections ✨. Operators can start by using IPv6 for their own applications and services 🧚. The IETF's recommended dual-stack IPv6 and IPv4 model fits mobile networks pretty well, as long as there are distinct APNs and IPv6 traffic can ride on PDP/PDN connections 🫶. The dual-stack model works with a single IPv4v6 PDN connection from Release-8 onward, but earlier releases need separate PDP contexts 👑. Finally, operators can make IPv6 the default for always-on mobile connections, using either an IPv4v6 PDN or an IPv6 PDN, and bring in IPv4 PDNs only when they're needed 🦋💅
3.2. NAT Placement in Mobile Networks 📱🦋
Okay so last section we figured out that NAT44 is needed to conserve the pool and delay public IPv4 address exhaustion 💅. But here's the tea: the private IPv4 pool itself is not abundant for big networks like mobile ones 😭. The so-called NET10 block [RFC1918] only has about 16.7 million private IPv4 addresses starting at 10.0.0.0, and a large mobile provider can easily have more than 16.7 million subscribers attached at a given time 💀. So private IPv4 pool management and where the NAT44 functionality lives become a whole big deal 👑.
NAT placement matters for other reasons too 🫶. Access networks generally need to produce network and service usage records for billing and accounting, and that's true for mobile networks too, where "subscriber management" features (i.e., QoS, Policy, and Billing and Accounting) can get pretty detailed. Since a NAT creates a binding between two addresses, those bindings become necessary info for subscriber management. For instance, the QoS offered on a private IPv4 address and the (shared) public IPv4 address may need to be correlated for accounting. Another example: Application Servers in the provider network may need to treat traffic based on policy provided by the PCRF. If the IP address those servers see isn't unique, the PCRF needs to be able to inspect the NAT binding to disambiguate among the individual MNs 🙈. The subscriber session management info and the service usage info also need to be correlated so you get harmonized records, and there may be legal requirements for storing the NAT binding records. Plot twist: these problems disappear with the transition to IPv6 🌈. For now, just know that NAT introduces state, which needs to be correlated and possibly stored with other routine subscriber info.
Mobile network deployments vary in how they allocate IP address pools 🧚. Some use the "centralized model," where the pool is managed by a common node, such as the PDN's BR, and shared by multiple MNGs all attached to the same BR. This model served well in pre-3G deployments, when the number of subscribers on the Mobile Internet at any given time never exceeded the available address pool. But with 3G and the dramatic growth in Mobile Internet users, service providers are increasingly forced to rethink their existing network design and choices 🔥. Specifically, they have to address private IPv4 pool exhaustion as well as scalable NAT solutions.
To tackle private IPv4 exhaustion in the centralized model, you'd need to support overlapped private IPv4 addresses in the common NAT functionality as well as in each of the gateways 🎀. 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 the traffic. Tunneling mechanisms like Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], MPLS [RFC3031] VPN tunnels, or even IP-in-IP encapsulation [RFC2003] that can provide a unique identifier for a NAT session can separate overlapping private IPv4 traffic, as described in [GI-DS-LITE]. The perk of centralizing NAT with overlapped addressing is conserving the limited private IPv4 pool. It also enables the operator's enterprise network to use IPv6 from the MNG to the BR, which some providers may view as an additional requirement. The downsides include the need for additional protocols to correlate the NAT state (at the common node) with subscriber session info (at each gateway), suboptimal MN-MN communication, the absence of subscriber-aware NAT (and policy) function, and, of course, the need for a protocol from the MNG to the BR itself. Also, if the NAT function experiences failure, all the connected gateway service will be affected 😱. These drawbacks are not present in the "distributed" model, which we'll get to next.
In a distributed model, the private IPv4 address management is performed by the MNG, which also performs the NAT functionality 💖. 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 NAT to the edge of the network, each MNG can reuse the NET10 block, which avoids overlapped private IPv4 addressing at the network core ✨. Since the MNG is where the subscriber management functions live, NAT state correlation is readily enabled. The MNG also already has existing interfaces to functions like AAA and PCRF, so it can do subscriber management with the unique private IPv4 addresses. Finally, the MNG can pass certain traffic types through without NAT to Application Servers in the service provider's domain, which lets those servers identify subscriber sessions with unique private IPv4 addresses too 🦋. The disadvantages of the "distributed model" include the absence of centralized addressing and centralized management of NAT 🥲.
In addition to the two models above, a hybrid model locates NAT in a dedicated device other than the MNG or the BR 🌸. This would be similar to the distributed model if the IP pool supports unique private addressing for the mobile nodes, or similar to the centralized model if it supports overlapped private IP addresses. Either way, the NAT device has to be able to provide the necessary NAT session binding information to an external entity (such as AAA or PCRF), which then needs to correlate those records with the user's session state present at the MNG.
Okay, recap, bestie 📝. First, managing the private IPv4 pool has become important given the growth in Mobile Internet users, and mechanisms that enable reuse of the available pool are required. Second, in the context of private IPv4 pool management, where NAT functionality is placed has implications for network deployment and operations. Centralized models with a common NAT have the advantages of continuing legacy deployments and reusing private IPv4 addressing, but they need additional functions to enable traffic differentiation and NAT state correlation with subscriber state management at the MNG. Distributed models also achieve private IPv4 address reuse and avoid overlapping private IPv4 traffic in the operator's core, without needing additional mechanisms. Since the MNG performs (unique) IPv4 address assignment and has standard interfaces to AAA and PCRF, the distributed model also enables a single point for subscriber and NAT state reporting as well as policy application 👑. So, in summary: providers who want to readily integrate NAT with other subscriber management functions, while conserving and reusing their private IPv4 pool, may find the distributed model compelling. Those interested in common management of NAT may find the centralized model more compelling 💜.
3.3. IPv6-Only Deployment Considerations 🎀
okay so, like we saw in the last section, NAT functionality in the network brings up a bunch of issues that would just not exist otherwise 😭. NAT should be viewed as an interim solution until IPv6 is widely available, i.e., IPv6 is available for mobile users for all (or most) practical purposes. Sure, NATs at provider premises may slow down the exhaustion of public IPv4 addresses, but expeditious and simultaneous introduction of IPv6 in the operational networks is necessary to keep the Internet "going and growing" 🌈. So it's super 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 3-tuple {nw, mn, ap}. The goal is to reach {IPv6, IPv6, IPv6} from {IPv4, IPv4, IPv4}. However, there are multiple paths to get there 🦋. The classic dual-stack model would traverse {IPv4v6, IPv4v6, IPv4v6}, where each dimension supports co-existence of IPv4 and IPv6. This appears to be the path of least disruption, although we are faced with the implications of supporting large-scale NAT in the network. There is also the cost of supporting separate PDP contexts in the existing 3G UMTS networks. The other intermediate coordinate 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. Ironically 🙈, this transition path would require interworking between IPv6 and IPv4 so the IPv6-only MNs can access IPv4 services and applications on the Internet. In other words, to disengage NAT (for IPv4-IPv4), we need to introduce another form of NAT (i.e., IPv6-IPv4) to expedite the adoption of IPv6. Plot twist of the century 🌸.
It is interesting to consider the preceding 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 reuse, which means no protocol is necessary in the centralized model to disambiguate NAT sessions. However, there is an additional requirement of DNS64 [RFC6147] functionality for IPv6-IPv4 translation. This DNS64 functionality must ensure that the synthesized AAAA record correctly maps to the IPv6-IPv4 translator. ✨
IPv6-only deployments in mobile networks need to reckon with the following considerations. First, both the network and the MNs need to be IPv6 capable. Expedited network upgrades as well as rollout 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 connectivity service can be deployed with appropriate existing tunneling mechanisms in the IPv4-only transport network. 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 mobile 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, an MN may 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 prominent applications start offering IPv6, there can be a strong incentive to provide application-layer (e.g., socket interface) upgrades to IPv6. Also, some IPv4-only applications may be able to make use of alternative access such as WiFi when available. A related challenge in the migration of applications is the use of IPv4 literals in application layer protocols (such as XMPP) or content (as in HTML or XML). Some Internet applications expect their clients to supply IPv4 addresses as literals, and this will not be possible with IPv6-only deployments. Some of these experiences and the related considerations in deploying an IPv6-only network are documented in [ARKKO-V6]. In summary, migration of applications to IPv6 needs to be done, and such a migration is not expected to be uniform across all subsets of existing applications.
Voice over LTE (VoLTE) also brings some unique challenges 📞. The signaling for voice is generally expected to be available for free while the actual voice call itself is typically charged on its duration. Such a separation of signaling and the payload is unique to voice, whereas an Internet connection is accounted without specifically considering application signaling and payload traffic. This model is expected to be supported even during roaming. Furthermore, providers and users generally require voice service regardless of roaming, whereas Internet usage is subject to subscriber preferences and roaming agreements. This requirement to ubiquitously support voice service while providing the flexibility for Internet usage exacerbates the addressing problem and may hasten provisioning of VoLTE using the IPv6-only PDN.
As seen earlier, roaming is unique to mobile networks, and it introduces new challenges 🌍. Service providers can control their own network design but not their peers' networks, which they rely on for roaming. Users expect uniformity in 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 that do not offer IPv6. For instance, when an LTE deployment is IPv6-only, a roamed 3G network may not offer IPv6 PDN connectivity. 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 roamed network support. These considerations also apply when the visited network is used for offering services such as VoLTE in the so-called Local Breakout model; the roaming MN's capability as well as the roamed network capability to support VoLTE using IPv6 determine whether fallback to IPv4 would be necessary. Similarly, there are inbound roamers to an IPv6-ready provider network whose MNs are not capable of IPv6. The IPv6-ready provider network has to be able to support IPv4 PDN connectivity for such inbound roamers. There are encouraging signs that the existing deployed network nodes in the 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 and offer it as a ubiquitous service that can be accounted for. 💜
In summary, IPv6-only deployments should be encouraged alongside the dual-stack model, which is the recommended IETF approach 👑. This is relatively straightforward for an operator's own services and applications, provisioned through an appropriate APN and the corresponding IPv6-only PDP or EPS bearer. Some providers may consider IPv6-only deployment for Internet access as well, and this would require IPv6-IPv4 interworking. When the IPv6-IPv4 translation mechanisms are used in IPv6-only deployments, the protocols and the associated considerations specified in [RFC6146] and [RFC6145] apply. Finally, 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. Until IPv6 connectivity is available in all mobile networks, IPv6-only mobile network deployments need to be prepared to support IPv4 connectivity (and NAT44) for their own outbound roaming users as well as for inbound roaming users. 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. That's the glow-up we want 🧚💖
3.4. Fixed-Mobile Convergence
okay so fixed-mobile convergence is basically the holy grail for providers who run both home broadband AND mobile networks 🫶 but it is NOT easy, bestie 😭. fixed access networks and mobile access networks have some stuff in common, but there are enough differences to make "convergence" lowkey really hard. like, roaming isn't even a thing in fixed networks 🙈. an All-IP mobile provider is required to provide voice service, but a fixed network provider isn't required to. also, a "link" in a fixed network can usually carry IPv6 AND IPv4 traffic, but not every mobile network has "links" (aka PDP/PDN connections) that can do both 💀. and roaming makes it worse, periodt 😤. if the Home Network (see Figure 1) can do IPv6 but the Visited Network (also Figure 1) can't, the link is split in a messy way. all these architecture, policy, and business model differences make convergence a whole thing 💅.
still, within the same provider's space, some stuff is shared ✨. like, IPv4 address management is a big concern for BOTH access networks. so the same mechanisms we talked about earlier, delaying IPv4 address exhaustion and bringing IPv6 into operational networks, also apply to converged networks 🦋. BUT the exact solutions each access network uses can totally vary, for reasons like:
- Tunneling private IPv4 packets inside IPv6 is doable in fixed networks, where the endpoint is often a cable or DSL modem 🌸. That's not the case in mobile networks, where the endpoint is the MN itself.
- Encapsulation-based mechanisms like 6rd [RFC5969] are useful when the operator can't give native or direct IPv6 connectivity, and a residential gateway can become a tunnel endpoint to provide it 🎀. In mobile networks, the operator could give IPv6 connectivity using the existing mobile tunneling mechanisms, without adding another layer of tunneling 🧚.
- A mobile provider may have Application Servers (like an email server) in its network that need unique private IPv4 addresses to identify MNs 👑. A fixed provider may not have that requirement, or the service itself may not need it.
these examples show that the solutions used in an access network mostly come down to that network's own requirements 🍓. still, some sharing between the access and core network might be possible, depending on the requirement and the functionality itself. for example, if a fixed network doesn't require a subscriber-aware feature like NAT, that functionality can live at a core router, while the mobile access network keeps doing NAT at the mobile gateway ✨. if a provider decides to offer common subscriber management at the MNG for both fixed and wireless networks, the MNG becomes a convergence node 💖. it then needs to support the applicable transition mechanisms for BOTH fixed and wireless access networks.
different access networks from the same provider are more likely to share a common core network, so common solutions are way easier to apply in the core 🌈. for instance, configured tunnels or MPLS VPNs from the mobile and fixed gateways can carry traffic to the core routers until the entire core network is IPv6-enabled 🦋.
NAT in access networks can also bring considerations 🙈. Femto Networks, for example, rely on a fixed Internet connection being available so the Femto Base Station can talk to its peer on the mobile network, usually over an IPsec tunnel 💜.
when the Femto Base Station needs a private IPv4 address, mobile network access through it gets hit with NAT policy administration, including periodic cleanup and purge of NAT state 😭. those policies affect how usable the Femto Network is, and they matter to the mobile network provider too. using IPv6 for the Femto (or any other access technology) could help with some of these concerns, IF the IPv6 communication can bypass the NAT 🫶.
so, the summary: there's real interest in Fixed-Mobile Convergence, at least among some providers ✨. harmonizing the network as much as possible has benefits, but the quirks of each access network also shape how convergence goes 💅. maybe more harmonization is possible at the higher service layers, like offering a unified user experience for services and applications 🌸. some harmonization of functions across access networks into the core network might also be feasible. honestly, a provider's core network looks like the place where most convergence is possible 👑.
4. Summary and Conclusion ✨
IPv6 deployment in mobile networks is crucial for the Mobile Internet 💖. in this document we dug into the considerations for deploying IPv6 in mobile networks 🔥. here's the recap, bestie:
- IPv4 address exhaustion and its implications for mobile networks: as mobile service providers start deploying IPv6, conserving their available IPv4 pool means they need network address translation in mobile networks 😭. at the same time, providers can use 3GPP architecture constructs like APN and PDN connectivity to bring in IPv6 WITHOUT messing with the mostly-IPv4 Internet access 🦋. the IETF dual-stack model [RFC4213] can be applied to mobile networks pretty easily 💅.
- The placement of NAT functionality in mobile networks: both the centralized and distributed models of private IPv4 address pool management have their pros 🌈. by letting each MNG manage its own NET10 pool, the distributed model reuses the private IPv4 pool and avoids the problems of non-unique private IPv4 addresses for MNs, WITHOUT needing extra protocol mechanisms 🎀. the distributed model also boosts the "subscriber management" functions at an MNG, like making NAT session correlation with the rest of the subscriber session state super easy 🧚. on the other hand, existing deployments that use centralized IP address management can keep their legacy architecture by putting the NAT at a common node 🍓. the centralized model also achieves private IPv4 address reuse, but it needs additional protocol extensions to tell apart overlapping addresses at the common NAT, and to integrate with policy and billing infrastructure 👑.
- IPv6-only mobile network deployments: this model is feasible in the LTE architecture for an operator's own services and applications ✨. the existing MNs still expect IPv4 address assignment 🙈. roaming, which is unique to mobile networks, also means a provider has to support IPv4 connectivity when its (outbound) users roam into a mobile network that isn't IPv6-enabled 😤. similarly, a provider needs to support IPv4 connectivity for (inbound) users whose MNs aren't IPv6-capable 💜. IPv6-IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet 🔥.
- Fixed-Mobile Convergence: the examples we looked at show how the requirements of fixed and mobile networks differ 💅. some harmonization of functions may be possible across access networks, but the service provider's core network is probably better suited for a converged network architecture 🌸. similar convergence gains are feasible in the service and application layers 🫶.
5. Security Considerations 🔐
This document does not introduce any new security vulnerabilities. 🙌 no new vulnerabilities from this doc, bestie, so you can breathe 😮💨💖
6. Acknowledgements 🫶
This document has benefitted from discussions with and reviews from Cameron Byrne, David Crowe, Hui Deng, Remi Despres, Fredrik Garneij, Jouni Korhonen, Teemu Savolainen, and Dan Wing 💜. Thanks to all of them, they're literal legends ✨. Many thanks to Mohamed Boucadair for providing an extensive review of a draft version of this document 👑. Cameron Byrne, Kent Leung, Kathleen Moriarty, and Jari Arkko also provided reviews that helped improve this document 🌈. and thanks to Nick Heatley for providing valuable review and input on VoLTE 🎀.
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.
[3GPP2.EHRPD]: "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", http://www.3gpp2.org/public_html/Specs/X.S0057-0_v1.0_090406.pdf.
[RFC1918]: Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 🏠
[RFC2003]: Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 🎁
[RFC2784]: Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 🦋
[RFC2890]: Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. 🔑
[RFC3031]: Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 🏷️
[RFC4213]: Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. 🌉
[RFC5969]: Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 🚀
[RFC6145]: Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 🔁
[RFC6146]: Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. 🌐
[RFC6147]: Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. 🧭
[ARKKO-V6]: Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Work in Progress, April 2011. 🧪
[GI-DS-LITE]: Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway Initiated Dual-Stack Lite Deployment", Work in Progress, July 2011. 🍭
Author's Address 💌
Rajeev Koodli Cisco Systems USA
EMail: rkoodli@cisco.com
📦 where this page comes from
- ietf: rfc6312 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms