RFC 6342
Mobile Networks Considerations for IPv6 Deployment
1. Introduction ✨
The mobile internet is blowing up 💥 and it's speeding up how fast we run out of IPv4 addresses 😭 IPv6 is widely accepted as necessary for the Internet to keep working and growing, and for the mobile Internet especially 🔥 IPv6 comes with a lot of perks, but deploying it in mobile networks brings some unique challenges. This doc breaks those challenges down and shows where the existing IPv6 deployment solutions fit 🦋 So it's a super useful reference for service providers and network designers 💅 It doesn't propose any new protocols or ask for new protocol spec work, so no new homework 🙈
The main topics we cover here about IPv6 deployment in mobile networks are:
- Public and Private IPv4 address exhaustion, and what that means for how a mobile network gets built 🌸
- Where Network Address Translation (NAT) functionality gets placed, and why that matters 🎀
- IPv6-only deployment considerations and the roaming implications that come with them 🧚
- Fixed-Mobile Convergence, and how it affects the overall architecture 👑
We'll go through each one in detail in the sections that follow ✨
For the most part, we assume the Third Generation Partnership Project (3GPP) 3G and 4G network architectures specified in [3GPP.3G] and [3GPP.4G]. The considerations are still general enough to apply to other mobile network architectures too [3GPP2.EHRPD] 💜
2. Reference Architecture and Terminology 🧚
Okay, here's the reference architecture of a mobile network 🌈
+-----+ +-----+
| 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 ArchitectureSo 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 of the Home Network 🧳 In the 3GPP network architecture, an MN gets online by connecting to an Access Point Name (APN), and that APN maps to a mobile gateway. Roughly speaking, an APN is kind of like a Service Set Identifier (SSID) in a wireless LAN 📶 An APN is a logical concept that says what kinds of services an MN is allowed to use, 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, it's realized through a Packet Data Protocol (PDP) context. That end-to-end link goes through multiple nodes, which are defined below:
- Base Station (BS): The radio Base Station gives the MN its wireless connection 📡
- Access Network Gateway (ANG): The ANG forwards IP packets to and from the MN. Usually, it's not the MN's default router, and the ANG doesn't do IP address allocation and management for the mobile nodes 🙅♀️ The ANG can be in either the Home Network or the Visited Network.
- The Mobile Network Gateway (MNG): The MNG is the MN's default router, and it handles IP address management 🏠 It also does things like offering Quality of Service (QoS), applying subscriber-specific policy, and enabling billing and accounting. These functions are sometimes grouped together as "subscriber-management" operations 💅 The mobile network architecture in Figure 1 defines the protocol interfaces needed for subscriber-management operations. The MNG is typically located in the Home Network.
- Border Router (BR): Like the name says, a BR is the border between the mobile network and the Internet 🌐 The BR doesn't do subscriber management for the mobile network.
- Authentication, Authorization, and Accounting (AAA): AAA handles the general stuff: subscriber authentication and authorization for services, plus generating billing and accounting information 🧾 In 3GPP network environments, subscriber authentication and the authorization for connectivity and services that follows are handled by the "Home Location Register" (HLR) / "Home Subscriber Server" (HSS) functionality.
- Policy and Charging Rule Function (PCRF): The PCRF lets policy and charging rules get applied at the MNG 🎀
For the rest of this document, "operator," "service provider," and "provider" all mean the same thing 💜
3. IPv6 Considerations ✨
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 .......................10
3.4. Fixed-Mobile Convergence ..................................13
4. Summary and Conclusion .........................................14
5. Security Considerations ........................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................163.1. IPv4 Address Exhaustion ✨
okay so everyone kinda agrees the pool of public IPv4 addresses is running on fumes 🥺. IANA has already handed out all its available /8 blocks to the Regional Internet Registries (RIRs) 💀. Some RIRs have totally run out already, and others are projected to hit empty soon. This has got service providers super aware that they need to start introducing some tech to keep the Internet running 💅. For providers, there are two things happening at once to deal with the run-out problem: stretching out their existing IPv4 pool (conserving what they have) and bringing IPv6 into their operational networks 🦋. We'll look at both of these below.
Stretching out public IPv4 for providers 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 🧚. A mechanism like the Network Address Translator (NAT) sits at the provider's premises (not the customer's) to manage those private addresses and handle access to the Internet 🌸. We're mostly focusing on translation-based mechanisms here, like NAT44 (translating between public IPv4 and private IPv4, and back again) and NAT64 (translating between public IPv6 and public IPv4, and back again) 🎀. The reason is that the 3GPP architecture already has a tunneling setup built in, the GPRS Tunneling Protocol (GTP), and the architecture supports both dual-stack and IPv6-only deployments 🫶.
In a mobile network, the MNG is the one that hands out the IPv4 address to an MN 📱. In the 3GPP network architecture, this happens alongside the Packet Data Network (PDN) connectivity setup 🔥. A PDN connection is basically 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 might carry both IPv4 and IPv6 traffic (like a dual-stack PDN in 4G LTE networks), or it might only carry one of those types (like in the existing 3G UMTS networks) 💜. The IPv4 address gets assigned either when the PDN connectivity is set up or later on using DHCP, once the PDN connection already exists 🍓. To slow down public IPv4 exhaustion, that address has to be a private IPv4 address that gets translated into a shared public IPv4 address 🙈. So the mobile network really needs a private-public IPv4 translation mechanism. No way around it, bestie 😭.
In 4G LTE, there's a requirement for an always-on PDN connection so the network can reliably reach a mobile user on the All-IP network 📞. That's because Voice over IP service runs over LTE, and LTE doesn't have circuit-based infrastructure to fall back on 💖. If that always-on PDN used IPv4, every MN that attaches to the network would need its own private IPv4 address, and that could seriously hurt the availability and usage of private IPv4 addresses 💀. One way around this is to make the always-on PDN (the one that needs voice service) 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 at connection setup time 🌸. The upside is that you get one PDN for both IPv6 and IPv4, and the IPv4 address doesn't get allocated until an application actually needs it 👑. Deferred allocation does need support for a dynamic configuration protocol like DHCP, plus the right triggers to kick that protocol off 🧚. Mobile phones don't have that support today, but newer smartphones could bring it in 📱. Tethering a smartphone to a laptop (laptops usually support DHCP) could also use deferred allocation, depending on when the laptop attaches to the smartphone 💅. Until the right triggers and host stack support show up, the address-deferring option may be limited 🥲.
On the flip side, 3G UMTS networks don't require an always-on connection, even though lots of smartphones rarely let go of an established PDP context 🙈. The older pre-Release-8 deployments don't support the dual-stack PDP connection, so you'd need two separate PDP connections to carry both IPv4 and IPv6 traffic 🎀. Some MNs in use today, especially smartphones, might have an IPv6 stack, but there are two things to keep in mind 🤔. First, there's very little operational experience and compliance testing for these existing stacks, so using them in large deployments could uncover software errors and interoperability problems that get in the way of IPv6-based services 💀. Second, only a fraction of phones in use have that kind of stack 📉. That means providers have to test, deploy, and operationalize IPv6 as they roll out new handsets, and those handsets still need access to the mostly IPv4 Internet 🫠.
Putting all of this together, a few things stand out 💖. First, mobile networks increasingly need to support private IPv4 addressing because of the public IPv4 run-out, which also means they need private-public IPv4 translation more than ever 🔥. Second, both 3G and 4G LTE already support IPv6 through PDP contexts and PDN connections 🌈. Operators can start by bringing in IPv6 for their own applications and services, and the IETF's recommended dual-stack IPv6 and IPv4 model fits mobile networks nicely, since they support distinct APNs and can carry IPv6 traffic on PDP/PDN connections 👑. The dual-stack model can use a single IPv4v6 PDN connection from Release-8 onwards, but earlier releases need separate PDP contexts ✨. Finally, operators can make IPv6 the default for always-on mobile connections, using either the IPv4v6 PDN or the IPv6 PDN, and only use IPv4 PDNs when they're needed 🦋💅
3.2. NAT Placement in Mobile Networks ✨
okay so bestie, in the last section we figured out that NAT44 is needed to stretch the public IPv4 pool and push back public IPv4 exhaustion 💅 but here's the tea: the private IPv4 pool itself is NOT giving "abundant" 🙈 for big networks like mobile ones. The so-called NET10 block [RFC1918] 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 one time 😭 so private pool management and where the NAT44 functionality gets placed become a huge deal 🎀
NAT placement matters for other reasons too, obviously 💖 access networks usually need to produce network and service usage records for billing and accounting, and that's true for mobile networks as well, 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 are themselves necessary info for subscriber management ✨ for example, the QoS offered on a private IPv4 address and the (shared) public IPv4 address might need to be correlated for accounting purposes 📊 another example: the Application Servers inside the provider network may need to treat traffic based on policy supplied by the PCRF. If the IP address those servers see isn't unique, the PCRF needs to be able to look at the NAT binding to tell the individual MNs apart 👑 the subscriber session management info and the service usage info also need to be correlated so the records line up 🫶 and yes, there may be legal requirements for storing NAT binding records too 💀 BUT honestly these problems disappear once we move to IPv6 🦋 for now, it's enough to say that NAT introduces state, which needs to be correlated and possibly stored alongside routine subscriber info 🌸
Mobile network deployments don't all handle IP address pools the same way 🌈 some use the "centralized model", where a common node (like the PDN's BR) manages the pool and that pool is shared by multiple MNGs all attached to the same BR 💜 honestly this model slayed in the pre-3G days, when the number of subscribers using the Mobile Internet at any given time never went past the available address pool ✨ but then 3G showed up, users on the Mobile Internet exploded, and providers are now being forced to rethink their existing network design and choices 😭 specifically, they have to deal with private IPv4 pool exhaustion AND scalable NAT solutions 🔥
To tackle private IPv4 exhaustion in the centralized model, the common NAT functionality AND each of the gateways would need to support overlapped private IPv4 addresses 🎀 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, and that NAT needs to be able to tell the traffic apart 🙈 tunneling mechanisms like Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890], MPLS [RFC3031] VPN tunnels, or even IP-in-IP encapsulation [RFC2003] can provide a unique identifier for a NAT session, and they can be used to separate overlapping private IPv4 traffic as described in [GI-DS-LITE] 🧚 a perk of centralizing the NAT and using overlapped private IPv4 addressing is that it conserves the limited private IPv4 pool 💖 it also lets the operator's enterprise network use IPv6 from the MNG to the BR, and some providers may see that (i.e., the need for an IPv6-routed enterprise network) as an extra requirement 🦋 the downsides? the centralized model needs additional protocols to correlate the NAT state (at the common node) with subscriber session info (at each of the gateways) 😭 there's suboptimal MN-MN communication, no 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 fails, all the connected gateway service gets affected 🙈 none of these drawbacks show up in the "distributed" model, which we'll get into next ✨
In a distributed model, the MNG handles private IPv4 address management AND performs the NAT functionality 👑 each MNG gets a block of 16.7 million unique addresses, which is plenty compared to the number of mobile subscribers active on each MNG 🫶 by pushing NAT out to the edge of the network, each MNG can reuse the available NET10 block, which avoids overlapped private IPv4 addressing at the network core 🌈 and since the MNG is where subscriber management functions live, NAT state correlation is readily enabled 💖 an MNG also already has existing interfaces to functions like AAA and PCRF, so it can run subscriber management functions using the unique private IPv4 addresses 🧚 finally, the MNG can pass certain traffic types through without NAT to the Application Servers in the service provider's domain, so those servers can identify subscriber sessions by unique private IPv4 addresses too 🎀 the catch with the "distributed model" is the lack of centralized addressing and centralized NAT management 😭
Besides those two models, there's a hybrid model where NAT lives in a dedicated device that's neither the MNG nor the BR 🦋 that setup would look like the distributed model if the IP pool supports unique private addressing for the mobile nodes, or like the centralized model if it supports overlapped private IP addresses ✨ either way, the NAT device has to be able to hand the necessary NAT session binding info to an external entity (like AAA or PCRF), which then needs to correlate those records with the user's session state present at the MNG 🌸
So here's the recap, periodt 💅 first, managing the available private IPv4 pool has become important now that Mobile Internet users are increasing, and mechanisms that enable reuse of the available pool are required 🔥 second, in the context of private IPv4 pool management, NAT placement has implications for network deployment and operations 👑 the centralized models with a common NAT get to keep their legacy deployments and reuse private IPv4 addressing 🎀 but they need extra functions to enable traffic differentiation and NAT state correlation with subscriber state management at the MNG 🙈 the distributed models also get private IPv4 address reuse and avoid overlapping private IPv4 traffic in the operator's core, and they DON'T need extra mechanisms for that 💖 since the MNG does (unique) IPv4 address assignment and has standard interfaces to AAA and PCRF, the distributed model also gives you a single point for subscriber and NAT state reporting and for policy application 🧚 in summary, providers who want to integrate NAT smoothly with other subscriber management functions, while conserving and reusing their private IPv4 pool, might find the distributed model compelling ✨ on the other hand, providers who care about common management of NAT may find the centralized model more compelling 🫶
3.3. IPv6-Only Deployment Considerations ✨
okay so bestie, remember how the last section was all about the weird problems NAT causes? 🙈 Well, here's the real tea: NAT should only be seen as an interim solution 💅 until IPv6 is basically everywhere for mobile users, meaning it works for all (or most) practical purposes. NATs at provider premises might slow down how fast public IPv4 addresses run out, but we really need IPv6 to roll out quickly and at the same time across operational networks so the Internet can keep "going and growing" 🌈. So it's super important to understand what it takes to deploy IPv6-only networks 🎀.
There are three dimensions to IPv6-only deployments: the network itself, the mobile nodes, and the applications, which we write as the 3-tuple {nw, mn, ap} 🧚. The goal is to go from {IPv4, IPv4, IPv4} all the way to {IPv6, IPv6, IPv6} 🦋. But there's more than one way to get there, no cap. The classic dual-stack model goes through {IPv4v6, IPv4v6, IPv4v6}, where every dimension supports IPv4 and IPv6 living together ✨. This is giving the path of least disruption, but the catch is we have to deal with large-scale NAT in the network 💀. There's also the cost of supporting separate PDP contexts in existing 3G UMTS networks 😭.
Another intermediate coordinate worth knowing about is {IPv6, IPv6, IPv4}, where the network and the MN are IPv6-only but Internet applications are still mostly IPv4 🍓. Ironically, this path needs interworking between IPv6 and IPv4 so IPv6-only MNs can still reach IPv4 services and applications on the Internet 🙃. Basically, to get rid of NAT for IPv4-to-IPv4, we have to introduce another kind of NAT (IPv6-to-IPv4) to speed up IPv6 adoption 🔥.
Now, about where that IPv6-to-IPv4 NAT should live: there's no overlapping private IPv4 address problem here, because every IPv6 address is unique and there are tons of them 🌸. So there's no requirement for IPv6 address reuse, which means the centralized model doesn't need any protocol to tell NAT sessions apart 👑. However, there is an extra requirement: DNS64 [RFC6147] functionality for IPv6-to-IPv4 translation 🫶. This DNS64 functionality MUST make sure the synthesized AAAA record maps correctly to the IPv6-IPv4 translator 💖.
IPv6-only deployments in mobile networks have to deal with the following considerations, periodt 💅. First, both the network and the MNs need to be IPv6 capable 🩷. Speedy network upgrades and rolling out IPv6-capable MNs would really help with this 🚀. Lucky for us, the 3GPP network design for LTE already requires network nodes and mobile nodes to support IPv6 🎉. Even though the transport network doesn't have to be IPv6, a working IPv6 connectivity service can still be deployed using existing tunneling mechanisms over an IPv4-only transport network 🌊. So a service provider might choose to enforce IPv6-only PDN and address assignment for their own subscribers in their Home Networks (see Figure 1) 🏠. This works for newer MNs once the mobile network can offer IPv6-only PDN support and IPv6-to-IPv4 interworking for Internet access ✨. For existing MNs, though, the provider still has to support IPv4-only PDP/PDN connectivity 🥺.
Migrating applications to IPv6 on MNs with IPv6-only PDN connectivity comes with its own drama 🎭. The provider's own applications and services obviously need to be IPv6-capable 💜. But an MN might run other apps too, and those also need to be IPv6-capable in IPv6-only deployments 😬. This can be a "long-tail" situation, but once a few big-name apps start offering IPv6, there's a strong incentive to add IPv6 upgrades at the application layer (for example, the socket interface) 🦋. Also, some IPv4-only apps may be able to use alternative access like WiFi when it's available 📶. Another challenge is the use of IPv4 literals in application layer protocols (such as XMPP) or in content (like HTML or XML) 😭. Some Internet apps expect their clients to supply IPv4 addresses as literals, and that just won't work with IPv6-only deployments 🙈. Some of these experiences and related considerations are written up in [ARKKO-V6] 📚. Bottom line: migrating apps to IPv6 has to happen, and it's not going to be uniform across all existing apps 🌈.
Voice over LTE (VoLTE) brings its own unique challenges too 📞. The signaling for voice is generally free, while the voice call itself is usually charged by duration 💸. This split between signaling and payload is unique to voice, whereas an Internet connection is billed without specifically looking at application signaling and payload traffic 🤔. This model is expected to keep working even while roaming 🌍. Plus, providers and users generally need voice service no matter what, whereas Internet usage depends on subscriber preferences and roaming agreements 📵. Having to support voice everywhere while still giving flexibility for Internet usage makes the addressing problem worse, and it may speed up VoLTE provisioning over the IPv6-only PDN 🚀.
Roaming is unique to mobile networks, and it brings new challenges too 🌏. Providers control their own network design but not their peers' networks, which they depend on for roaming 🤷♀️. Users expect the experience to be uniform even when they're roaming 🥹. So providers who want IPv6-only deployments also have to support IPv4 addressing when their own outbound subscribers roam into networks that don't offer IPv6 🧳. For example, when an LTE deployment is IPv6-only, a roamed 3G network might not offer IPv6 PDN connectivity 💔. Since a PDN connection involves the radio base station, the ANG, and the MNG (see Figure 1), IPv6 PDN connectivity just can't be enabled without support from the roamed network 🙅♀️. These same points apply when the visited network is used for services like VoLTE in the so-called Local Breakout model. Whether a fallback to IPv4 is needed depends on the roaming MN's capability and on whether the roamed network can support VoLTE over IPv6 🔍. Similarly, there are inbound roamers coming into an IPv6-ready provider network whose MNs can't do IPv6 😵. The IPv6-ready provider network has to support IPv4 PDN connectivity for those inbound roamers 🫠. There are encouraging signs that existing deployed network nodes in the 3GPP architecture already support IPv6 PDP context ⭐. Still, this support would need to be scaled up for a (very) large number of mobile users and offered as a ubiquitous, billable service 💰.
In summary, IPv6-only deployments SHOULD be encouraged alongside the dual-stack model, which is the IETF's recommended approach 👑. This is pretty straightforward for an operator's own services and applications, which are provisioned through an appropriate APN and the matching IPv6-only PDP or EPS bearer 🎀. Some providers may also consider IPv6-only deployment for Internet access, and that would require IPv6-to-IPv4 interworking 🔁. When IPv6-to-IPv4 translation mechanisms are used in IPv6-only deployments, the protocols and considerations specified in [RFC6146] and [RFC6145] apply 📜. Finally, IPv6-only deployments can be phased in for newer mobile nodes, while existing ones keep demanding IPv4-only connectivity 🐣.
Roaming matters a lot in mobile networks, and it brings diversity in network deployments 🌍✨. Until IPv6 connectivity is available in all mobile networks, IPv6-only mobile network deployments MUST be prepared to support IPv4 connectivity (and NAT44) for their own outbound roaming users as well as inbound roaming users 🛟. But by taking the initiative to introduce IPv6-only for newer MNs, mobile networks can significantly reduce the demand for private IPv4 addresses 💅🌸.
3.4. Fixed-Mobile Convergence ✨
Okay so bestie, lots of providers run BOTH fixed broadband AND mobile networks 📱🏠, and those access networks are kinda different. They share some vibes but not enough to make "convergence" easy 😭. Roaming isn't even a thing in fixed access networks 🙅♀️. An All-IP mobile network service provider is required to provide voice service, but a fixed network provider isn't required to do that. A "link" on a fixed network is usually capable of carrying IPv6 and IPv4 traffic, but not every mobile network has "links" (aka PDP/PDN connections) that can handle both 💅. And roaming makes it worse when one part of the link (the Home Network in Figure 1) can do IPv6 but the other part (the Visited Network in Figure 1) can't 💀. Those architectural differences, plus policy and business model differences, make convergence a whole thing 🙃.
Still, within the same provider's space, some common considerations apply 🫶. IPv4 address management is a shared concern for both access networks. That means the same mechanisms we talked about earlier, delaying IPv4 address exhaustion and introducing IPv6 in operational networks, apply to the converged networks too 🔥. The exact solutions deployed for each access network can still vary, though, for reasons like:
- Tunneling of private IPv4 packets within IPv6 is feasible in fixed networks, where the endpoint is often a cable or DSL modem. This is not the case in mobile networks, where the endpoint is an MN itself.
- Encapsulation-based mechanisms such as 6rd [RFC5969] are useful where the operator is unable to provide native or direct IPv6 connectivity and a residential gateway can become a tunnel endpoint for providing this service. In mobile networks, the operator could provide IPv6 connectivity using the existing mobile network tunneling mechanisms without introducing an additional layer of tunneling 🧚.
- 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 show that the actual solutions used in an access network are largely determined by the requirements specific to that access network 💖. Some sharing between an access network and the core network may still 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 can be provided at a core router, while the mobile access network keeps providing NAT at the mobile gateway. If a provider chooses to offer common subscriber management at the MNG for both fixed and wireless networks, the MNG itself becomes a convergence node that needs to support the applicable transition mechanisms for both fixed and wireless access networks 👑.
Different access networks of a provider are more likely to share a common core network, so common solutions are easier to apply there ✨. For instance, configured tunnels or MPLS VPNs from the gateways of both the mobile and fixed networks can be used to carry traffic to the core routers until the entire core network is IPv6-enabled 🦋.
There can also be considerations due to the use of NAT in access networks 🙈. Solutions such as Femto Networks rely on a fixed Internet connection being available for the Femto Base Station to communicate with its peer on the mobile network, typically via an IPsec tunnel. When the Femto Base Station needs to use a private IPv4 address, mobile network access through the Femto Base Station is subject to NAT policy administration, including periodic cleanup and purge of NAT state. Those policies affect the usability of the Femto Network and have implications for the mobile network provider 😬. Using IPv6 for the Femto (or any other access technology) could ease some of these concerns, if the IPv6 communication could bypass the NAT 💜.
In summary, there is interest in Fixed-Mobile Convergence, at least among some providers 🌈. Harmonizing the network as much as possible has benefits, but the idiosyncrasies of disparate access networks also influence convergence. Greater harmonization may be feasible at the higher service layers, e.g., in terms of offering a unified user experience for services and applications 💅. Some harmonization of functions across access networks into the core network may also be feasible. A provider's core network appears to be the place where most convergence is feasible 🔥.
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 💅:
- IPv4 address exhaustion and its implications to mobile networks: As mobile service providers begin to deploy 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 such as APN and PDN connectivity to introduce IPv6 without affecting the predominantly IPv4 Internet access 🧁. The IETF dual-stack model [RFC4213] can be applied to mobile networks readily ✨.
- The placement of NAT functionality in mobile networks: Both the centralized and distributed models of private IPv4 address pool management have their merits 🦄. By letting each MNG manage its own NET10 pool, the distributed model achieves reuse of the available private IPv4 pool and avoids the problems associated with 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, existing deployments that have used centralized IP address management can continue their legacy architecture by placing the NAT at a common node 🍓. The centralized model also achieves private IPv4 address reuse, but it needs additional protocol extensions to differentiate overlapping addresses at the common NAT, as well as to integrate with policy and billing infrastructure 😭.
- IPv6-only mobile network deployments: This deployment model is feasible in the LTE architecture for an operator's own services and applications 🚀. The existing MNs still expect IPv4 address assignment. Furthermore, roaming, which is unique to mobile networks, requires that a provider support IPv4 connectivity when its (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. IPv6-IPv4 interworking is necessary for IPv6-only MNs to access the IPv4 Internet 💫.
- Fixed-Mobile Convergence: The examples discussed illustrate the differences in the requirements of fixed and mobile networks 🎀. While some harmonization of functions may be possible across access networks, the service provider's core network is perhaps better suited for a converged network architecture 👑. Similar gains in convergence are feasible in the service and application layers ✨.
5. Security Considerations 🔒
This document does not introduce any new security vulnerabilities 🛡️. Phew, no drama here, bestie 💅.
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 💖. 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 provided reviews that helped improve this document 🌸. 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: rfc6342 2011-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms