RFC 6459
IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)
RFC 6459: IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) 💖
okay bestie, this one is RFC 6459, and it's all about how IPv6 works inside the 3GPP cellular world 📱✨ It's giving "cellular networks finally getting their IPv6 glow-up." 🦋
Here's the tea on the title block 🫶 It's an Informational doc, not a Standards Track spec, so it's published for info, not as a rule you have to follow. 🧚 It's dated January 2012, and its ISSN is 2070-1721. 🌸
The people behind it are J. Korhonen, Ed. from Nokia Siemens Networks (the editor, so the one who held the pen 💅), plus J. Soininen and K. Iisakkila from Renesas Mobile, and B. Patil, T. Savolainen, and G. Bajko from Nokia. Its title block doesn't list anything it obsoletes or updates, so it's standing on its own. ✨
Abstract 🌈
Okay so, people are using cellular broadband to get online on their phones, tablets, and laptops/netbooks more than ever, thanks to fast packet data networks like HSPA, HSPA+, and now Long-Term Evolution (LTE) 📲🔥 Operators running 3rd Generation Partnership Project (3GPP) networks are running out of IPv4 addresses at the Internet registries, so they're feeling the pressure to move to IPv6. 😭 This document describes how IPv6 is supported in 3GPP network architectures. 💜
Status of This Memo 🎀
This doc is NOT an Internet Standards Track specification. It's published for informational purposes, bestie. 🍓
It's a product of the Internet Engineering Task Force (IETF), so 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 IESG-approved doc is a candidate for any level of Internet Standard, though. For that, check Section 2 of RFC 5741. 💅
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6459. 🦋
Copyright Notice ⭐
Copyright (c) 2012 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 stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc, and it's important, no cap. 🙈
Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License. 💀
Table of Contents 🧚
1. Introduction ....................................................4
2. 3GPP Terminology and Concepts ...................................5
2.1. Terminology ................................................5
2.2. The Concept of APN ........................................10
3. IP over 3GPP GPRS ..............................................11
3.1. Introduction to 3GPP GPRS .................................11
3.2. PDP Context ...............................................12
4. IP over 3GPP EPS ...............................................13
4.1. Introduction to 3GPP EPS ..................................13
4.2. PDN Connection ............................................14
4.3. EPS Bearer Model ..........................................15
5. Address Management .............................................16
5.1. IPv4 Address Configuration ................................16
5.2. IPv6 Address Configuration ................................16
5.3. Prefix Delegation .........................................17
5.4. IPv6 Neighbor Discovery Considerations ....................18
6. 3GPP Dual-Stack Approach to IPv6 ...............................18
6.1. 3GPP Networks Prior to Release-8 ..........................18
6.2. 3GPP Release-8 and -9 Networks ............................20
6.3. PDN Connection Establishment Process ......................21
6.4. Mobility of 3GPP IPv4v6 Bearers ...........................23
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks ........24
8. Deployment Issues ..............................................25
8.1. Overlapping IPv4 Addresses ................................25
8.2. IPv6 for Transport ........................................26
8.3. Operational Aspects of Running Dual-Stack Networks ........26
8.4. Operational Aspects of Running a Network with
IPv6-Only Bearers .........................................27
8.5. Restricting Outbound IPv6 Roaming .........................28
8.6. Inter-RAT Handovers and IP Versions .......................29
8.7. Provisioning of IPv6 Subscribers and Various
Combinations during Initial Network Attachment ............29
9. Security Considerations ........................................31
10. Summary and Conclusions .......................................32
11. Acknowledgements ..............................................32
12. Informative References ........................................331. Introduction ✨
Okay, so IPv6 support has been part of the 3rd Generation Partnership Project (3GPP) standards since the very first release of the specs, Release 99 💖 It covers all the radio access and packet-based variants in the 3GPP architecture family. 📡 People have also put a ton of industry work into figuring out different transition and deployment scenarios over the years. 😭 Even so, IPv6 deployment in commercial networks is still low. 💀 There are a bunch of reasons for that, but the biggest one is the same reason IPv6 isn't deployed in other networks either: there's a lack of business and commercial incentives to do it. 🙈
3GPP network architectures have kept evolving since Release 99, which was finalized in early 2000. 🦋 The newest version is the Evolved Packet System (EPS), which people call System Architecture Evolution (SAE), Long-Term Evolution (LTE), or Release-8. ✨ It's a packet-centric architecture, so everything is built around packets. 📦
And the number of subscribers and devices using 3GPP networks for Internet connectivity and data services has grown phenomenally 🚀 Mobile broadband subscribers have increased exponentially over the last couple of years, which is wild. 😭
Subscriber growth is projected to climb even higher. 📈 With the recent depletion of available IPv4 address space by IANA, 3GPP operators and vendors are now figuring out which scenarios and solutions they need to deploy IPv6. 🫶
This document describes how IP connectivity gets set up in 3GPP network architectures. It focuses on IP bearers for 3G General Packet Radio Service (GPRS) and for EPS. 🎀 It gives an overview of how IPv6 is supported under the current set of 3GPP specifications. 💜 It also talks about some of the issues and concerns around deployment and the shortage of private IPv4 addresses within a single network domain. 🌸
The IETF has specified a set of tools and mechanisms you can use to transition to IPv6. 🧚 Besides operating dual-stack networks during the move from IPv4 to IPv6, there are two alternative categories for the transition: encapsulation and translation. 🌈 The IETF keeps specifying more solutions that fit different deployment scenarios and operator/ISP requirements. 💅 There's no single approach to transitioning to IPv6 that works for every deployment and model, bestie. 🙅♀️ The 3GPP transition scenarios, described in [TR.23975], can be handled with transition mechanisms that are already in the toolbox. ✨ The goal of transitioning to IPv6 in 3GPP networks is to ensure that:
- Legacy devices and hosts that have an IPv4-only stack keep getting IP connectivity to the Internet and services. 💖
- Devices that are dual-stack can access the Internet either via IPv6 or IPv4. Which one they use depends on the capability of:
A. the application on the host,
B. the support for IPv4 and IPv6 bearers by the network, and/or
C. the server(s) and other end points.
3GPP networks can already give a host both IPv4 and IPv6 connectivity today. 🔥 In many cases, though, that means upgrading network elements like the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). 🛠️ It's a whole glow-up, periodt 🌈
2. 3GPP Terminology and Concepts 🦋
2.1. Terminology 💖
Okay bestie, let's get into the vocab. These terms are the alphabet soup of 3GPP networks, so grab a snack 🍓
Access Point Name
The Access Point Name (APN) is a Fully Qualified Domain Name (FQDN) and resolves to a set of gateways in an operator's network. The APNs are piggybacked on the administration of the DNS namespace. 🌐
Dual Address PDN/PDP Type
The dual address Packet Data Network/Packet Data Protocol (PDN/PDP) Type (IPv4v6) is used in 3GPP context in many cases as a synonym for dual-stack, i.e., a connection type capable of serving both IPv4 and IPv6 simultaneously. So it's basically dual-stack with a fancy name 💅
Evolved Packet Core
The Evolved Packet Core (EPC) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system. The EPC comprises subcomponents such as the Mobility Management Entity (MME), Serving Gateway (SGW), Packet Data Network Gateway (PDN-GW), and Home Subscriber Server (HSS). ✨
Evolved Packet System
The Evolved Packet System (EPS) is an evolution of the 3GPP GPRS system characterized by a higher-data-rate, lower-latency, packet-optimized system that supports multiple Radio Access Technologies (RATs). The EPS comprises the EPC together with the Evolved Universal Terrestrial Radio Access (E-UTRA) and the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). It's the whole glam package 👑
Evolved UTRAN
The Evolved UTRAN (E-UTRAN) is a communications network, sometimes referred to as 4G, and consists of eNodeBs (4G base stations), which make up the E-UTRAN. The E-UTRAN allows connectivity between the User Equipment and the core network. 📶
GPRS Tunnelling Protocol
The GPRS Tunnelling Protocol (GTP) [TS.29060] [TS.29274] [TS.29281] is a tunnelling protocol defined by 3GPP. It is a network-based mobility protocol and is similar to Proxy Mobile IPv6 (PMIPv6) [RFC5213]. However, GTP also provides functionality beyond mobility, such as in-band signaling related to Quality of Service (QoS) and charging, among others. So GTP does more than just mobility, which is very main character energy 🦋
GSM EDGE Radio Access Network
The Global System for Mobile Communications (GSM) EDGE Radio Access Network (GERAN) is a communications network, commonly referred to as 2G or 2.5G, and consists of base stations and Base Station Controllers (BSCs), which make up the GSM EDGE radio access network. The GERAN allows connectivity between the User Equipment and the core network. 📻
Gateway GPRS Support Node
The Gateway GPRS Support Node (GGSN) is a gateway function in the GPRS that provides connectivity to the Internet or other PDNs. The host attaches to a GGSN identified by an APN assigned to it by an operator. The GGSN also serves as the topological anchor for addresses/prefixes assigned to the User Equipment. 🎀
General Packet Radio Service
The General Packet Radio Service (GPRS) is a packet-oriented mobile data service available to users of the 2G and 3G cellular communication systems -- the GSM -- specified by 3GPP. 📱
High-Speed Packet Access
The High-Speed Packet Access (HSPA) and HSPA+ are enhanced versions of the Wideband Code Division Multiple Access (WCDMA) and UTRAN, thus providing more data throughput and lower latencies. Faster and smoother, obviously 🚀
Home Location Register
The Home Location Register (HLR) is a pre-Release-5 database (but is also used in Release-5 and later networks in real deployments) that contains subscriber data and information related to call routing. All subscribers of an operator, and the subscribers' enabled services, are provisioned in the HLR. 🗂️
Home Subscriber Server
The Home Subscriber Server (HSS) is a database for a given subscriber and was introduced in 3GPP Release-5. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. The HSS is the subscription-info queen 👸
Mobility Management Entity
The Mobility Management Entity (MME) is a network element that is responsible for control-plane functionalities, including authentication, authorization, bearer management, layer-2 mobility, etc. The MME is essentially the control-plane part of the SGSN in the GPRS. The user-plane traffic bypasses the MME. 🧠
Mobile Terminal
The Mobile Terminal (MT) is the modem and the radio part of the Mobile Station (MS). 📡
Public Land Mobile Network
The Public Land Mobile Network (PLMN) is a network that is operated by a single administration. A PLMN (and therefore also an operator) is identified by the Mobile Country Code (MCC) and the Mobile Network Code (MNC). Each (telecommunications) operator providing mobile services has its own PLMN. Every operator gets their own little kingdom 🏰
Policy and Charging Control
The Policy and Charging Control (PCC) framework is used for QoS policy and charging control. It has two main functions: flow-based charging, including online credit control; and policy control (e.g., gating control, QoS control, and QoS signaling). It is optional to 3GPP EPS but needed if dynamic policy and charging control by means of PCC rules based on user and services are desired. The rules and the vibes 💜
Packet Data Network
The Packet Data Network (PDN) is a packet-based network that either belongs to the operator or is an external network such as the Internet or a corporate intranet. The user eventually accesses services in one or more PDNs. The operator's packet core networks are separated from packet data networks either by GGSNs or PDN Gateways (PDN-GWs). 🌍
Packet Data Network Gateway
The Packet Data Network Gateway (PDN-GW) is a gateway function in the Evolved Packet System (EPS), which provides connectivity to the Internet or other PDNs. The host attaches to a PDN-GW identified by an APN assigned to it by an operator. The PDN-GW also serves as the topological anchor for addresses/prefixes assigned to the User Equipment. 🚪
Packet Data Protocol Context
A Packet Data Protocol (PDP) context is the equivalent of a virtual connection between the User Equipment (UE) and a PDN using a specific gateway. Think of it as a little private tunnel 🫶
Packet Data Protocol Type
A Packet Data Protocol Type (PDP Type) identifies the used/allowed protocols within the PDP context. Examples are IPv4, IPv6, and IPv4v6 (dual-stack). 🧩
S4 Serving GPRS Support Node
The S4 Serving GPRS Support Node (S4-SGSN) is compliant with a Release-8 (and onwards) SGSN that connects 2G/3G radio access networks to the EPC via new Release-8 interfaces like S3, S4, and S6d. Upgraded and glowing up ✨
Serving Gateway
The Serving Gateway (SGW) is a gateway function in the EPS, which terminates the interface towards the E-UTRAN. The SGW is the Mobility Anchor point for layer-2 mobility (inter-eNodeB handovers). For each UE connected with the EPS, at any given point in time, there is only one SGW. The SGW is essentially the user-plane part of the GPRS's SGSN. 🛣️
Serving GPRS Support Node
The Serving GPRS Support Node (SGSN) is a network element that is located between the radio access network (RAN) and the gateway (GGSN). A per-UE point-to-point (p2p) tunnel between the GGSN and SGSN transports the packets between the UE and the gateway. 🚚
Terminal Equipment
The Terminal Equipment (TE) is any device/host connected to the Mobile Terminal (MT) offering services to the user. A TE may communicate to an MT, for example, over the Point to Point Protocol (PPP). 💻
UE, MS, MN, and Mobile
The terms UE (User Equipment), MS (Mobile Station), MN (Mobile Node), and mobile refer to the devices that are hosts with the ability to obtain Internet connectivity via a 3GPP network. A MS is comprised of the Terminal Equipment (TE) and a Mobile Terminal (MT). The terms UE, MS, MN, and mobile are used interchangeably within this document. Four names, one fabulous device 📲
UMTS Terrestrial Radio Access Network
The Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) is a communications network, commonly referred to as 3G, and consists of NodeBs (3G base stations) and Radio Network Controllers (RNCs), which make up the UMTS radio access network. The UTRAN allows connectivity between the UE and the core network. The UTRAN is comprised of WCDMA, HSPA, and HSPA+ radio technologies. 📶
User Plane
The user plane refers to data traffic and the required bearers for the data traffic. In practice, IP is the only data traffic protocol used in the user plane. IP is the star of the show here 🌟
Wideband Code Division Multiple Access
The Wideband Code Division Multiple Access (WCDMA) is the radio interface used in UMTS networks. 📡
eNodeB
The eNodeB is a base station entity that supports the Long-Term Evolution (LTE) air interface. The LTE glow-up 🌈
2.2. The Concept of APN 🧚
The Access Point Name (APN) essentially refers to a gateway in the 3GPP network. The 'complete' APN is expressed in a form of a Fully Qualified Domain Name (FQDN) and also piggybacked on the administration of the DNS namespace, thus effectively allowing the discovery of gateways using the DNS. The UE can choose to attach to a specific gateway in the packet core. The gateway provides connectivity to the Packet Data Network (PDN), such as the Internet. An operator may also include gateways that do not provide Internet connectivity but rather provide connectivity to a closed network providing a set of the operator's own services. A UE can be attached to one or more gateways simultaneously. The gateway in a 3GPP network is the GGSN or PDN-GW. Figure 1 illustrates the APN-based network connectivity concept. 🗺️
.--.
_(. `)
.--. +------------+ _( PDN `)_
_(Core`. |GW1 |====( Internet `)
+---+ ( NW )------|APN=internet| ( ` . ) )
[UE]~~~~|RAN|----( ` . ) )--+ +------------+ `--(_______)---'
^ +---+ `--(___.-' |
| | .--.
| | +----------+ _(.PDN`)
| +--|GW2 | _(Operator`)_
| |APN=OpServ|====( Services `)
UE is attached +----------+ ( ` . ) )
to GW1 and GW2 `--(_______)---'
simultaneouslyFigure 1: User Equipment Attached to Multiple APNs Simultaneously 📊
3. IP over 3GPP GPRS ✨
3.1. Introduction to 3GPP GPRS ✨
okay so this is the 2G/3G GPRS architecture 🫶 it covers the GPRS core network from R99 all the way to Release-7, plus the radio techs: GSM (2G), EDGE (2G, often called 2.5G), WCDMA (3G), and HSPA(+) (3G, often called 3.5G). it's giving family resemblance to EPS, and we'll see that in Section 4 💅 the core GPRS functions are split across two nodes, the SGSN and the GGSN, and they're connected through Gn/Gp.
3G
.--. .--.
Uu _( `. Iu +----+ +----+ _( `.
[UE]~~|~~~( UTRAN )--|---|SGSN|--|---|GGSN|--|----( PDN )
( ` . ) ) +----+ Gn +----+ Gi ( ` . ) )
`--(___.-' / | `--(___.-'
/ |
2G Gb-- |
.--. / |
_( `. / --Gp
[UE]~~|~~~( PDN )__/ |
Um ( ` . ) ) .--.
`--(___.-' _(. `)
_( [GGSN] `)_
( other `)
( ` . PLMN ) )
`--(_______)---'
Figure 2: Overview of the 2G/3G GPRS Logical Architecturehere's the interface cheat sheet 🦋
Gn/Gp:these give you network-based mobility for a UE and sit between an SGSN and a GGSN 🌸 Gn is for when the GGSN and SGSN are inside one operator (aka one PLMN). Gp is for when they're in different operator domains (aka different PLMNs). GTP is defined for both (GTP-C for the control plane and GTP-U for the user plane) 💜Gb:the BSS-to-SGSN interface 🍓 it carries packet data transmission info and layer-2 mobility management. It's based on either Frame Relay or IP.Iu:the RNS-to-SGSN interface 🧚 same job as Gb (packet data transmission and layer-2 mobility management). The user-plane side (actually the Iu-PS) is based on GTP-U, and the control-plane side is based on the Radio Access Network Application Protocol (RANAP) ✨Gi:the interface between the GGSN and a PDN. The PDN can be an operator's external public or private packet data network, or an intra-operator packet data network 🌈Uu/Um:the 2G or 3G radio interfaces between a UE and its radio access network 📡
the SGSN is responsible for getting data packets to and from the UE within its geographical service area when the direct tunnel option isn't used 💅 if direct tunnel is used, the user plane goes straight between the RNC (in the RNS) and the GGSN. The control-plane traffic always goes through the SGSN, no exceptions 🙈 and for each UE connected with GPRS, at any given point in time, there is only one SGSN. one SGSN, periodt 👑
3.2. PDP Context 🎀
okay the PDP (Packet Data Protocol) context is basically an association between a UE (represented by one IPv4 address and/or one /64 IPv6 prefix) and a PDN (represented by an APN) 🦋 each PDN can be reached through a gateway, usually a GGSN or PDN-GW. On the UE, a PDP context is basically a network interface, so a UE can be attached to one or more gateways through separate connections (aka separate PDP contexts) 💖 3GPP GPRS supports the PDP Types IPv4 and IPv6, and since Release-9, PDP Type IPv4v6 (dual-stack) too ✨
every primary PDP context gets its own IPv4 address and/or /64 IPv6 prefix, assigned by the PDN and anchored in the matching gateway 🧚 the GGSN or PDN-GW is the first-hop router for the UE. Apps on the UE use whichever network interface (PDP context) fits the PDN they want to talk to. here's the picture 👇
Y
| +---------+ .--.
|--+ __________________________ | APNx in | _( `.
| |O______PDPc1_______________)| GGSN / |----(Internet)
| | | PDN-GW | ( ` . ) )
|UE| +---------+ `--(___.-'
| | _______________________ +---------+ .--.
| |O______PDPc2____________)| APNy in | _(Priv`.
+--+ | GGSN / |-------(Network )
| PDN-GW | ( ` . ) )
+---------+ `--(___.-'
Figure 3: PDP Contexts between the MS/UE and Gatewayin this figure the UE has two PDP contexts 🌸 the 'PDPc1' one is connected to APNx and gives Internet connectivity, and the 'PDPc2' one gives connectivity to a private IP network through APNy (for example, this network might have operator-specific services like the MMS (Multimedia Messaging Service)) 💜 so a web browser would use the PDP context with Internet connectivity to reach Internet services, and an MMS app would use APNy, since that service lives on the private network 🫶
4. IP over 3GPP EPS 🌸
4.1. Introduction to 3GPP EPS 🦋
in its most basic form, the EPS architecture has only two user-plane nodes: a base station and a core network Gateway (GW) 💅 the basic EPS architecture is shown in Figure 4. The functional split of gateways is the fun part, since it lets operators pick optimized topological locations for nodes, supports various deployment models (including sharing radio networks between different operators), and allows independent scaling, growth of traffic throughput, and control-signal processing 🔥
+--------+
| IP |
S1-MME +-------+ S11 |Services|
+----|----| MME |----|----+ +--------+
| | | | |SGi
| +-------+ | S5/ |
+----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+
|UE |----|---|eNodeB |---|-----------------| SGW |--|---|PDN-GW |
| |========|=======|=====================|=======|======| |
+----+ +-------+Dual-Stack EPS Bearer+-------+ +-------+
Figure 4: EPS Architecture for 3GPP Accesshere's the interface lineup 🧚
S5/S8:provides user-plane tunnelling and tunnel management between the SGW and PDN-GW, using GTP (both GTP-U and GTP-C) or PMIPv6 [RFC5213] [TS.23402] as the network-based mobility management protocol. The S5 interface is used when the PDN-GW and SGW are inside one operator (aka one PLMN). The S8 interface is used when they're in different operator domains (aka different PLMNs) 🌈S11:the reference point for the control-plane protocol between the MME and SGW, based on GTP-C (GTP control plane). It's used, for example, when the default bearer is being set up or modified 💖S1-U:provides user-plane tunnelling and inter-eNodeB path switching during handover between the eNodeB and SGW, using GTP-U (GTP user plane) ✨S1-MME:the reference point for the control-plane protocol between the eNodeB and MME 🍓SGi:the interface between the PDN-GW and the PDN. The PDN can be an operator-external public or private packet data network, or an intra-operator packet data network 🎀
4.2. PDN Connection 💜
okay a PDN connection is an association between a UE (represented by one IPv4 address and/or one /64 IPv6 prefix) and a PDN (represented by an APN) 🦋 it's the EPC version of the GPRS PDP context ✨ each PDN can be reached through a gateway (a PDN-GW), and the PDN handles the IP address/prefix allocation to the UE. On the UE, a PDN connection is equivalent to a network interface, so a UE can be attached to one or more gateways through separate connections (aka separate PDN connections) 🫶 3GPP EPS supports the PDN Types IPv4, IPv6, and IPv4v6 (dual-stack) since the very start of EPS, i.e., since Release-8 💅
each PDN connection has its own IP address/prefix, assigned by the PDN and anchored in the matching gateway 🧚 with the GTP-based S5/S8 interface, the PDN-GW is the first-hop router for the UE. With PMIPv6-based S5/S8, the SGW is the first-hop router instead 🌸 Apps on the UE just use the appropriate network interface (PDN connection) to connect 💖
4.3. EPS Bearer Model 🔥
the logical concept of a bearer is an aggregate of one or more IP flows related to one or more services 🎀 an EPS bearer exists between the UE and the PDN-GW, and it gives the same level of packet-forwarding treatment to all the aggregated IP flows inside the bearer. So services with IP flows that need different packet-forwarding treatment would need more than one EPS bearer 👑 The UE binds the uplink IP flows to the bearer, and the PDN-GW does that job for the downlink packets 🦋
to keep connectivity always low-latency 🧚, a default bearer is provided at startup, and an IPv4 address and/or IPv6 prefix gets assigned to the UE. (This is different from GPRS, where UEs aren't automatically connected to a PDN, so they don't get an IPv4 address and/or IPv6 prefix until they activate their first PDP context 🙈.) The default bearer can carry all traffic that isn't associated with a dedicated bearer 🌈 Dedicated bearers carry traffic for IP flows that have been identified as needing specific packet-forwarding treatment 💜. They can be set up at startup, for example for services that need always-on connectivity and better QoS than the default bearer gives ✨. The default bearer and its dedicated bearer(s) share the same IP address(es)/prefix 🫶.
an EPS bearer is called a Guaranteed Bit Rate (GBR) bearer if the dedicated network resources tied to its GBR value are permanently allocated (e.g., by an admission control function in the eNodeB) when the bearer is established or modified 💖 Otherwise, it's a non-GBR bearer 🌸. The default bearer is always non-GBR: its IP flows' resources aren't guaranteed at the eNodeB, and there's no admission control 🙈. The dedicated bearer, though, can be either GBR or non-GBR 💅. A GBR bearer has a GBR and a Maximum Bit Rate (MBR), while more than one non-GBR bearer belonging to the same UE shares an Aggregate MBR (AMBR) 🔥. Non-GBR bearers can suffer packet loss under congestion, while GBR bearers are immune to such losses as long as they honor the contracted bit rates 👑✨
5. Address Management 🎀
5.1. IPv4 Address Configuration 🌸
okay so the UE's IPv4 address config is always handled during the PDP context/EPS bearer setup procedures (on layer 2) 💅 DHCPv4-based [RFC2131] address configuration is supported by the 3GPP specs, but honestly nobody really uses it at scale 🥲 so the UE must always support address configuration as part of the bearer setup signaling, since DHCPv4 is optional for both UEs and networks 🫶
the 3GPP specs also cover a 'deferred IPv4 address allocation' on a PMIPv6-based dual-stack IPv4v6 PDN connection at connection establishment, as described in Section 4.7.1 of [TS.23402] ✨ this is giving one PDN connection for IPv6 and IPv4, plus the IPv4 address waits until an application actually needs it 🦋 the deferred allocation is based on DHCPv4, plus UE-side implementation-dependent triggers that invoke the protocol 🧚
5.2. IPv6 Address Configuration 💜
IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in [RFC4861] and [RFC4862], is the only supported address configuration mechanism 👑 stateful DHCPv6-based address configuration [RFC3315] is not supported by 3GPP specifications, but stateless DHCPv6 for getting other configuration info is supported [RFC3736] ✨ this implies the M-bit is always zero and the O-bit may be set to one in the Router Advertisement (RA) sent to the UE 🌈
the 3GPP network gives each default bearer a unique /64 prefix, and uses layer-2 signaling to suggest an Interface Identifier to the UE that is guaranteed not to conflict with the gateway's Interface Identifier 🎀 the UE must configure its link-local address using this Interface Identifier 💖 the UE can use any Interface Identifier it wants for its other addresses, and there's no restriction on using privacy extensions for SLAAC [RFC4941] or other similar mechanisms 🦋
⚠️ hot tea: some network drivers don't pass the Interface Identifier to the stack and instead make up their own (usually a Media Access Control (MAC) address equivalent) 🙈 if the UE skips the Duplicate Address Detection (DAD) and has other issues with the Neighbor Discovery protocol (see Section 5.4), there's a small theoretical chance the UE configures exactly the same link-local address as the GGSN/PDN-GW 💀 that collision can cause issues in IP connectivity, like the UE not being able to forward any packets to the uplink 😭
in the 3GPP link model, the /64 prefix assigned to the UE cannot be used for on-link determination, because the L-bit in the Prefix Information Option (PIO) in the RA must always be set to zero 🫠 if the advertised prefix is used for SLAAC, then the A-bit in the PIO must be set to one ✨ the full details of the 3GPP link model and address configuration are in Section 11.2.1.3.2a of [TS.29061] 📖 the GGSN/PDN-GW guarantees the /64 prefix is unique for the UE, so there's no need to do any DAD on addresses the UE creates (the 'DupAddrDetectTransmits' variable in the UE could be zero) 🌸 and the GGSN/PDN-GW is not allowed to generate any globally unique IPv6 addresses for itself using the /64 prefix assigned to the UE in the RA 🙅♀️
the current 3GPP architecture limits each bearer to a single /64 prefix 💅 if the UE finds more than one prefix in the RA, it only considers the first one and silently discards the others [TS.29061] 😤 so multi-homing within a single bearer is not possible, and renumbering without closing the layer-2 connection is also not possible 💔 the lifetime of the /64 prefix is bound to the lifetime of the layer-2 connection, even if the advertised prefix lifetime is longer than that 🥀
5.3. Prefix Delegation 🧁
IPv6 prefix delegation is part of Release-10 and isn't covered by any earlier releases 🎀 still, the /64 prefix allocated for each default bearer (and to the UE) may be shared to the local area network by a UE implementing Neighbor Discovery proxy (ND proxy) [RFC4389] functionality ✨
the Release-10 prefix delegation uses DHCPv6-based prefix delegation [RFC3633] 🦋 the model requires aggregatable prefixes, which means the /64 prefix allocated for the default bearer (and to the UE) must be part of the shorter delegated prefix 🧩 but DHCPv6 prefix delegation has an explicit limitation, described in Section 12.1 of [RFC3633], that a prefix delegated to a requesting router cannot be used by the delegating router (here, the PDN-GW) 🙃 this implies the shorter 'delegated prefix' can't just be handed to the requesting router (the UE) as-is. it has to be delivered by the delegating router (the PDN-GW) in such a way that the /64 prefix allocated to the default bearer is not part of the 'delegated prefix' 🌈 an option to exclude a prefix from delegation [PD-EXCLUDE] fixes this problem 👑
5.4. IPv6 Neighbor Discovery Considerations 🔥
the 3GPP link between the UE and the next-hop router (e.g., the GGSN) acts like a point-to-point (p2p) link, which has no link-layer addresses [RFC3316], and this hasn't changed from 2G/3G GPRS to EPS 🫶 the UE IP stack has to take that into account 💅 when the 3GPP PDP context shows up as a PPP interface/link to the UE, the IP stack is usually ready to handle Neighbor Discovery and the related Neighbor Cache state machine transitions, even though Neighbor Discovery messages contain no link-layer address info 🧚 however, some operating systems discard Router Advertisements on their PPP interface/link by default 💀 this makes SLAAC fail when the 3GPP PDP context gets established, which stalls all IPv6 traffic 😭
several operating systems and their network drivers can make the 3GPP PDP context look like an IEEE 802 interface/link to the IP stack 🌸 this has a few known issues, especially when the IP stack thinks the underlying link has link-layer addresses 🙈 first, the Neighbor Advertisement a GGSN sends in response to a Neighbor Solicitation triggered by address resolution might not contain a Target Link-Layer Address option (see Section 4.4 of [RFC4861]) 🥲 then address resolution may never complete when the UE tries to resolve the GGSN's link-layer address, which stalls all IPv6 traffic 💔
second, the GGSN may simply discard all Neighbor Solicitation messages triggered by address resolution 🫠 (Section 2.4.1 of [RFC3316] is sometimes misread as saying responding to address resolution and next-hop determination isn't needed 🙄) so address resolution never completes, and once again all IPv6 traffic stalls 😩 there's little that can be done about this in the GGSN, assuming its neighbor-discovery implementation already does the right thing ✨ but UE stacks must be able to handle address resolution in the way they've chosen to represent the interface 👑 in other words, if they emulate IEEE 802 interfaces, they also need to process Neighbor Discovery messages correctly 💅
6. 3GPP Dual-Stack Approach to IPv6 🌈
6.1. 3GPP Networks Prior to Release-8 🦋
3GPP standards before Release-8 give cellular devices IPv6 access with PDP contexts of type IPv6 [TS.23060] 🎀 for dual-stack access, a PDP context of type IPv6 is set up in parallel with the PDP context of type IPv4, as shown in Figures 5 and 6 💖 IPv4-only service uses connections over the IPv4 PDP context, and IPv6-only service uses connections over the IPv6 PDP context ✨ the two PDP contexts of different types may use the same APN (and the gateway), but standards don't explicitly define this, so cellular device and gateway implementations from different vendors may vary in how well they support it 🙈
Y .--.
| _(IPv4`.
|---+ +---+ +---+ ( PDN )
| D |~~~~~~~//-----| |====| |====( ` . ) )
| S | IPv4 context | S | | G | `--(___.-'
| | | G | | G | .--.
| U | | S | | S | _(IPv6`.
| E | IPv6 context | N | | N | ( PDN )
|///|~~~~~~~//-----| |====|(s)|====( ` . ) )
+---+ +---+ +---+ `--(___.-'Figure 5: Dual-Stack (DS) User Equipment Connecting to Both IPv4 and IPv6 Internet Using Parallel IPv4-Only and IPv6-Only PDP Contexts 🧁
Y
|
|---+ +---+ +---+
| D |~~~~~~~//-----| |====| | .--.
| S | IPv4 context | S | | G | _( DS `.
| | | G | | G | ( PDN )
| U | | S | | S |====( ` . ) )
| E | IPv6 context | N | | N | `--(___.-'
|///|~~~~~~~//-----| |====| |
+---+ +---+ +---+Figure 6: Dual-Stack User Equipment Connecting to Dual-Stack Internet Using Parallel IPv4-Only and IPv6-Only PDP Contexts 🌸
the parallel IPv4 and IPv6 PDP context approach isn't optimal 😒 two PDP contexts mean double the signaling and more network resources than a single PDP context 💔 in Figure 6, the IPv4 and IPv6 PDP contexts are attached to the same GGSN 💅 that's possible, but the dual-stack MS may end up attached to different GGSNs, in a scenario where one GGSN supports IPv4 PDN connectivity while another provides IPv6 PDN connectivity 🦋
6.2. 3GPP Release-8 and -9 Networks ✨
okay so since 3GPP Release-8 we've had this iconic concept called the dual-stack type of PDN connection and EPS bearer [TS.23401] 💅 It lets IPv4 and IPv6 run in parallel on a single bearer (IPv4v6), see Figure 7 below. It makes dual stack way simpler than in earlier 3GPP releases, ngl 😭 And as of Release-9, GPRS network nodes also support dual-stack (IPv4v6) PDP contexts 🌈
Y
|
|---+ +---+ +---+
| D | | | | P | .--.
| S | | | | D | _( DS `.
| | IPv4v6 (DS) | S | | N | ( PDN )
| U |~~~~~~~//-----| G |====| - |====( ` . ) )
| E | bearer | W | | G | `--(___.-'
|///| | | | W |
+---+ +---+ +---+Figure 7: Dual-Stack User Equipment Connecting to Dual-Stack Internet Using a Single IPv4v6 PDN Connection
Here's the rundown of the PDP contexts and PDN bearer types 3GPP specifies 🧚
- For 2G/3G access to the GPRS core (SGSN/GGSN) pre-Release-9, there are two IP PDP Types: IPv4 and IPv6. Two PDP contexts are needed to get dual-stack connectivity.
- For 2G/3G access to the GPRS core (SGSN/GGSN), starting with Release-9, there are three IP PDP Types: IPv4, IPv6, and IPv4v6. A minimum of one PDP context is needed to get dual-stack connectivity.
- For 2G/3G access to the EPC (PDN-GW via S4-SGSN), starting with Release-8, there are three IP PDP Types: IPv4, IPv6, and IPv4v6 (which gets mapped to the PDN connection type). A minimum of one PDP context is needed to get dual-stack connectivity.
- For LTE (E-UTRAN) access to the EPC, starting with Release-8, there are three IP PDN Types: IPv4, IPv6, and IPv4v6. A minimum of one PDN connection is needed to get dual-stack connectivity.
6.3. PDN Connection Establishment Process 🫶
the PDN connection establishment process is spelled out in detail in the 3GPP specs. Figure 8 shows the high-level process and the signaling involved in setting up a PDN connection, so you can see the whole flow at once 👀
UE eNodeB/ MME SGW PDN-GW HSS/
| BS | | | AAA
| | | | | |
|---------->|(1) | | | |
| |---------->|(1) | | |
| | | | | |
|/---------------------------------------------------------\|
| Authentication and Authorization |(2)
|\---------------------------------------------------------/|
| | | | | |
| | |---------->|(3) | |
| | | |---------->|(3) |
| | | | | |
| | | |<----------|(4) |
| | |<----------|(4) | |
| |<----------|(5) | | |
|/---------\| | | | |
| RB setup |(6) | | | |
|\---------/| | | | |
| |---------->|(7) | | |
|---------->|(8) | | | |
| |---------->|(9) | | |
| | | | | |
|============= Uplink Data =========>==========>|(10) |
| | | | | |
| | |---------->|(11) | |
| | | | | |
| | |<----------|(12) | |
| | | | | |
|<============ Downlink Data =======<===========|(13) |
| | | | | |Figure 8: Simplified PDN Connection Setup Procedure in Release-8
- The UE (i.e., the MS) needs a data connection, so it decides to set up a PDN connection with a PDN-GW. The UE sends an "Attach" request (layer-2) to the base station (BS). The BS forwards this Attach request to the MME.
- Authentication of the UE with the Authentication, Authorization, and Accounting (AAA) server/HSS follows. If the UE is authorized to establish a data connection, the process continues with the following steps:
- The MME sends a "Create Session" request message to the SGW. The SGW forwards the Create Session request to the PDN-GW. The SGW knows the address of the PDN-GW it forwards the Create Session request to because the MME got this information during the authentication/authorization phase.
The UE IPv4 address and/or IPv6 prefix gets assigned during this step. If a subscribed IPv4 address and/or IPv6 prefix is statically allocated for the UE for this APN, then the MME passes this previously allocated address information to the SGW and eventually to the PDN-GW in the Create Session request message. Otherwise, the PDN-GW manages the address assignment to the UE. (There is another variation to this step where IPv4 address allocation is delayed until the UE initiates a DHCPv4 exchange, but this is not discussed here.)
- The PDN-GW creates a PDN connection for the UE and sends a Create Session response message to the SGW from which the session request message was received. The SGW forwards the response to the corresponding MME that originated the request.
- The MME sends the "Attach Accept/Initial Context Setup" request message to the eNodeB/BS.
- The radio bearer (RB) between the UE and the eNodeB is reconfigured based on the parameters received from the MME. (See Note 1 below.)
- The eNodeB sends an "Initial Context" response message to the MME.
- The UE sends a "Direct Transfer" message, which includes the "Attach Complete" signal, to the eNodeB.
- The eNodeB forwards the Attach Complete message to the MME.
- The UE can now start sending uplink packets to the PDN GW.
- The MME sends a "Modify Bearer" request message to the SGW.
- The SGW responds with a Modify Bearer response message. At this time, the downlink connection is also ready.
- The UE can now start receiving downlink packets, including possible SLAAC-related IPv6 packets.
The type of PDN connection established between the UE and the PDN-GW can be any of the types described in the previous section. The dual-stack PDN connection, i.e., the one that supports both IPv4 and IPv6 packets, is the default connection that gets established if the UE doesn't specify a particular PDN connection type in Release-8 networks 💖
Note 1: The UE receives the PDN Address Information Element [TS.24301] at the end of radio bearer setup messaging. This information element contains only the Interface Identifier of the IPv6 address. In the case of GPRS, the PDP Address Information Element [TS.24008] would contain a complete IPv6 address. However, the UE must ignore the IPv6 prefix if it receives one in the message (see Section 11.2.1.3.2a of [TS.29061]).
6.4. Mobility of 3GPP IPv4v6 Bearers 🦋
3GPP talked at length about different ways to support mobility between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN for the new dual-stack bearers. The approach they went with, in short: if a UE is allowed to do handovers between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN while it has open PDN connections, only single-stack bearers are used. Basically, that gives you these deployment options:
- If a network knows a UE may do handovers between a Release-8 LTE network and a pre-Release-9 2G/3G network without an S4-SGSN, then the network is configured to provide only single-stack bearers, even if the UE requests dual-stack bearers.
- If the network knows the UE does handovers only between a Release-8 LTE network and a Release-9 2G/3G network or a pre-Release-9 network with an S4-SGSN, then the network is configured to provide the UE with dual-stack bearers on request. The same also applies for LTE-only deployments.
When a network operator and their roaming partners have upgraded their networks to Release-8, it's possible to use the new IPv4v6 dual-stack bearers ✨ A Release-8 UE always requests a dual-stack bearer, but accepts whatever the network assigns 🫶
7. Dual-Stack Approach to IPv6 Transition in 3GPP Networks 👑
3GPP networks can natively carry IPv4 and IPv6 packets between the UE and the gateway (GGSN or PDN-GW), whether that comes from setting up a dual-stack PDP context or parallel IPv4 and IPv6 PDP contexts 🌸
Current 3GPP deployments mostly support IPv4 only. These networks can be upgraded to also support IPv6 PDP contexts. Once they do, devices and applications that are IPv6 capable can start using IPv6 connectivity, and legacy devices and applications keep working with no impact 🙌 As newer devices start using IPv6, demand for actively used IPv4 connections is expected to slowly drop, which helps operators with the transition to IPv6 🌈 With a dual-stack approach there's always the option to fall back to IPv4. A device roaming in a network where the visited network doesn't support IPv6 could fall back to IPv4 PDP contexts, so the end user would at least get some connectivity 🥹
Unfortunately, the dual-stack approach on its own doesn't lower the number of IPv4 addresses in use. Every dual-stack bearer still needs an IPv4 address, private or public. This is a major concern for dual-stack bearers when it comes to IPv6 transition 😬 But if most active IP communication has moved over to IPv6, then the number of active NAT44-translated IPv4 connections can still be expected to gradually decrease in Network Address Translation from IPv4 to IPv4 (NAT44), which gives some level of relief for NAT44 function scalability 💅
As networks evolve to support the Release-8 EPS architecture and dual-stack PDP contexts, newer devices will be able to take advantage of that and have a single bearer that supports both IPv4 and IPv6 🦋 Since IPv4 and IPv6 packets are carried as payload within GTP between the MS and the gateway (GGSN/PDN-GW), it doesn't matter (the transport-network capability is immaterial) whether the interfaces between the eNodeB and SGW, or between the SGW and PDN-GW, support IPv4 or IPv6 🧚
8. Deployment Issues 🎀
8.1. Overlapping IPv4 Addresses 🎀
okay so, IPv4 addresses are literally running out 😭. Because of that, operators tend to hand out private IPv4 addresses [RFC1918] to UEs when they set up an IPv4-only PDP context or an IPv4v6 PDN context. 💖 About 16 million UEs can each get a private IPv4 address that's unique inside one domain. BUT, for lots of operators the subscriber count is bigger than 16 million, so it's giving plot twist 🙈. The fix is to give overlapping RFC 1918 IPv4 addresses to UEs. The result is that an IPv4 address given to a UE inside one operator realm is no longer unique. This has the same obvious, well-known issues as NATed IP connections on the Internet. Direct UE-to-UE connectivity gets messy: unless the UEs are in the same private address range pool and/or anchored to the same gateway, referrals using IP addresses will have issues, and so on. These are generic issues, not just an EPS problem ✨. Still, 3GPP as such doesn't have any mandatory language about NAT44 functionality in the EPC. The obvious deployment choices apply to the EPC too 👑:
- Very large network deployments get partitioned, for example by geographical area 🌸. This partitioning lets overlapping IPv4 address ranges be assigned to UEs in different areas. Each area has its own pool of gateways dedicated to a certain overlapping IPv4 address range (also called a zone). Standard NAT44 functionality allows communication from the [RFC1918] private zone to the Internet. Communication between zones needs special arrangements, such as intermediate gateways (e.g., a Back-to-Back User Agent (B2BUA) in the case of SIP) 🦋.
- A UE attaches to a gateway as part of the Attach process 🧚. The number of UEs one gateway supports is on the order of 1 to 10 million. So all the UEs on a single gateway can be given private IPv4 addresses. Operators with big subscriber bases have multiple gateways, which means the same [RFC1918] IPv4 address space can be reused across gateways. The IPv4 address given to a UE is unique within the scope of a single gateway 💅.
- New services that need direct connectivity between UEs should be built on IPv6 🌈. Existing IPv4-only services and applications that need direct connectivity can be ported to IPv6 ✨.
8.2. IPv6 for Transport 🦋
the various reference points of the 3GPP architecture, like S1-U, S5, and S8, are based on either GTP or PMIPv6 💜. The transport under these reference points can be IPv4 or IPv6, no drama. GTP has been able to run over IPv6 transport (optionally) since R99, and PMIPv6 has supported IPv6 transport since it was introduced in Release-8 🍓. The user-plane traffic between the UE and the gateway can use either IPv4 or IPv6. GTP and PMIPv6 basically treat these packets as payload and transport them accordingly, with no real attention paid (at least from a routing perspective) to what's in the IPv4 or IPv6 headers 🫶. The transport links between the eNodeB and the SGW, and the link between the SGW and the PDN-GW, can be migrated to IPv6 without any direct implications for the architecture 🔥.
Currently, the inter-operator (for 3GPP technology) roaming networks are all IPv4 only (see Inter-PLMN Backbone Guidelines [GSMA.IR.34]) 🙈. Eventually these roaming networks will also get migrated to IPv6, if there's a business reason for it. The migration period can be prolonged a lot, because the 3GPP protocols always tunnel user-plane traffic in the core network, and as we just covered, the transport-network IP version is not in any way tied to the user-plane IP version 💀. Also, the design of the inter-operator roaming networks is such that the user-plane and transport-network IP addressing schemes are completely separated from each other 🌸. The inter-operator roaming network itself is completely separated from the Internet too. Only the core network nodes that must be connected to the inter-operator roaming networks are actually visible there, and they're the only ones able to send and receive (tunneled) traffic within those networks 🧚. Obviously, for roaming to work properly, operators have to agree on supported protocol versions, so the visited network doesn't, for example, unnecessarily drop user-plane IPv6 traffic 👑.
8.3. Operational Aspects of Running Dual-Stack Networks 🎀
running dual-stack networks does come with cost and complexity, not gonna lie 😭. But those factors get softened by the assurance that legacy devices and services are unaffected, and there's always a fallback to IPv4 if something goes wrong with the IPv6 deployment or network elements 💖. The model also lets operators build operational experience and expertise in an incremental way ✨.
Running dual-stack networks requires managing multiple IP address spaces 🌈. Tracking of UEs needs to be expanded, since a UE can be identified by either an IPv4 address or an IPv6 prefix. Network elements also need to be dual-stack capable to support the dual-stack deployment model 💅.
Deployment and migration cases (see Section 6.1) for providing dual-stack capability may mean doubled resource usage in an operator's network 😭. This is a major concern when comparing dual-stack connectivity with the techniques discussed in Section 6.1. Also, handovers between networks with different capabilities regarding whether or not they support dual-stack service may be hard for users to understand and for applications/services to cope with 🙈. These facts can add concerns that aren't just technical for operators planning to roll out dual-stack service offerings 💜.
8.4. Operational Aspects of Running a Network with IPv6-Only Bearers 🦋
it's possible to allocate IPv6-only bearers to UEs in 3GPP networks ✨. The IPv6-only bearer has been part of the 3GPP specification since the beginning. In 3GPP Release-8 (and later), it was defined that a dual-stack UE (or when the radio equipment has no knowledge of the UE IP stack's capabilities) must first attempt to establish a dual-stack bearer and then possibly fall back to a single-stack bearer 🍓. A Release-8 (or later) UE with an IPv6-only stack can directly attempt to establish an IPv6-only bearer 🧚. Whether IPv6-only behavior is used is up to subscription provisioning or PDN-GW configuration, and the fallback scenarios don't necessarily cause additional signaling 🌸.
Although the bullets below introduce IPv6-to-IPv4 address translation and specifically discuss NAT64 technology [RFC6144], the current 3GPP Release-8 architecture doesn't describe the use of address translation or NAT64 💅. It's up to a specific deployment whether address translation is part of the network. The following are some operational aspects to consider for running a network with IPv6-only bearers 👑:
- The UE must have an IPv6-capable stack and a radio interface capable of establishing an IPv6 PDP context or PDN connection.
- The GGSN/PDN-GW must be IPv6 capable in order to support IPv6 bearers. Furthermore, the SGSN/MME must allow the creation of a PDP Type or PDN Type of IPv6.
- Many common applications are IP version agnostic and hence would work using an IPv6 bearer. However, applications that are IPv4 specific would not work 🙈.
- Inter-operator roaming is another aspect that causes issues, at least during the ramp-up phase of the IPv6 deployment. If the visited network that outbound roamers attach to does not support PDP/PDN Type IPv6, then there needs to be a fallback option. The fallback option in this specific case is mostly up to the UE to implement. Several cases are discussed in the following sections 🌈.
- If and when a UE using an IPv6-only bearer needs access to the IPv4 Internet/network, some type of translation from IPv6 to IPv4 has to be deployed in the network. NAT64 (or DNS64) is one solution that can be used for this and works for a certain set of protocols (read TCP, UDP, and ICMP, and when applications actually use DNS for resolving names to IP addresses) 🔥.
8.5. Restricting Outbound IPv6 Roaming 💀
roaming was briefly touched on in Sections 8.2 and 8.4 ✨. While there's interest in offering roaming service for IPv6-enabled UEs and subscriptions, not all visited networks are ready for IPv6 outbound roamers 😭:
- The visited-network SGSN does not support the IPv6 PDP context or IPv4v6 PDP context types. These should mostly concern pre-Release-9 2G/3G networks without an S4-SGSN, but there's no definitive rule, since the deployed feature sets vary depending on implementations and licenses 🦋.
- The visited network might not be commercially ready for IPv6 outbound roamers, even though everything might work technically at the user-plane level. This would lead to "revenue leakage", especially from the visited operator's point of view (note that a visited-network GGSN/PDN-GW doesn't really exist in commercial data-roaming deployments today) 💅.
It might be in operators' interest to prohibit roaming selectively within specific visited networks until IPv6 roaming is in place 🌸. 3GPP does not specify a mechanism that prohibits IPv6 roaming without also disabling IPv4 access and other packet services. The following options for disabling IPv6 access for roaming subscribers could be available in some network deployments 🧚:
- Policy and Charging Control (PCC) [TS.23203] functionality and its rules, for example, could be used to cause bearer authorization to fail when a desired criterion is met. In this case, that would be PDN/PDP Type IPv6/IPv4v6 and a specific visited network. The rules can be provisioned either in the home network or locally in the visited network 🍓.
- Some Home Location Register (HLR) and Home Subscriber Server (HSS) subscriber databases allow prohibiting roaming in a specific (visited) network for a specified PDN/PDP Type 🫶.
The obvious problems are that these solutions aren't mandatory, aren't unified across networks, and therefore also lack a well-specified fallback mechanism from the UE's point of view 😭💜.
8.6. Inter-RAT Handovers and IP Versions 🌈
it's obvious that as operators start to incrementally deploy the EPS alongside the existing UTRAN/GERAN, handovers between different radio technologies (inter-RAT handovers) become inevitable ✨. For inter-RAT handovers, 3GPP supports the following IP addressing scenarios 👑:
- The E-UTRAN IPv4v6 bearer has to map one to one to the UTRAN/GERAN IPv4v6 bearer.
- The E-UTRAN IPv6 bearer has to map one to one to the UTRAN/GERAN IPv6 bearer.
- The E-UTRAN IPv4 bearer has to map one to one to the UTRAN/GERAN IPv4 bearer.
Other types of configurations are not standardized 🙈. The rules above essentially mean the network migration has to be planned, and subscriptions provisioned, based on the lowest common denominator, if inter-RAT handovers are desired. For example, if some part of the UTRAN can only serve IPv4 bearers, then the E-UTRAN is also forced to provide only IPv4 bearers. Various combinations of subscriber provisioning regarding IP versions are discussed further in Section 8.7 💖.
8.7. Provisioning of IPv6 Subscribers and Various Combinations during Initial Network Attachment 🎀
okay so bestie, every subscriber has their own provisioned PDP/PDN Types, and they come in multiple configurations 💅 The supported PDP/PDN Type gets provisioned per APN for each subscriber. In a Release-8 subscription, the HSS can hold these PDN Types [TS.23401]:
- IPv4v6 PDN Type. Heads up: the IPv4v6 PDP Type doesn't exist in an HLR and Mobile Application Part (MAP) [TS.29002] signaling before Release-9 🙈
- IPv6-only PDN Type.
- IPv4-only PDN Type.
- IPv4_or_IPv6 PDN Type. The IPv4_or_IPv6 PDP Type doesn't show up in HLR or MAP signaling either. But an HLR can have multiple APN configurations with different PDN Types, and those configurations end up doing the same job 🧚
A Release-8 dual-stack UE must always attempt to establish a PDP/PDN Type IPv4v6 bearer 🌈 Same goes for when the modem part of the UE doesn't know for sure whether the UE operating system IP stack is dual-stack capable. A UE that's IPv6-only capable must attempt to establish a PDP/PDN Type IPv6 bearer ✨ And last but not least, a UE that's IPv4-only capable must attempt to establish a PDN/PDP Type IPv4 bearer 💜
Now, what if the PDP/PDN Type the UE asks for doesn't match what's provisioned for the subscriber in the HSS (or HLR)? Then the UE might fall back to a different PDP/PDN Type 🦋 The network (that's the MME or the S4-SGSN) can tell the UE during network attachment signaling why it didn't get the type it asked for. The response/cause codes are documented in [TS.24008] for requested PDP Types and [TS.24301] for requested PDN Types:
(E)SM cause #50 "PDN/PDP type IPv4 only allowed".(E)SM cause #51 "PDN/PDP type IPv6 only allowed".(E)SM cause #52 "single address bearers only allowed".
These response/cause codes apply from Release-8 onwards. In pre-Release-8 networks, the codes used vary depending on the vendor, unfortunately 😭
Here are the possible fallback cases when the network deploys MMEs and/or S4-SGSNs (as documented in [TS.23401]) 👑
- Requested and provisioned PDP/PDN Types match => requested.
- Requested IPv4v6 and provisioned IPv6 => IPv6, and the UE gets an indication that an IPv6-only bearer is allowed.
- Requested IPv4v6 and provisioned IPv4 => IPv4, and the UE gets an indication that an IPv4-only bearer is allowed.
- Requested IPv4v6 and provisioned IPv4_or_IPv6 => IPv4 or IPv6 is selected by the MME/S4-SGSN based on unspecified criteria. The UE may then attempt to establish, based on the UE implementation, a parallel bearer of a different PDP/PDN Type 🫶
- Other combinations cause the bearer establishment to fail 💀
Besides the PDP/PDN Types provisioned in the HSS, a PDN-GW (and an MME/S4-SGSN) can also change the final selected PDP/PDN Type 🔥
- Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 or IPv6. If the MME operator had included the
Dual Address Bearerflag in the bearer establishment signaling, then the UE would have received an indication that an IPv6-only or IPv4-only bearer is allowed. - Requested IPv4v6 and configured IPv4 or IPv6 in the PDN-GW => IPv4 or IPv6. If the MME operator had not included the
Dual Address Bearerflag in the bearer establishment signaling, then the UE may have attempted to establish, based on the UE implementation, a parallel bearer of a different PDP/PDN Type 🌸
One more thing: an SGSN that doesn't understand the requested PDP Type is supposed to handle it as IPv4. And if an MME doesn't understand the requested PDN Type, that PDN Type gets handled as IPv6 ⭐
9. Security Considerations 🔐
This document doesn't introduce any security-related concerns. But Section 5 of [RFC3316] already has an in-depth discussion of IPv6-related security considerations in 3GPP networks prior to Release-8, so go read that too 📚 This section covers a few extra security concerns you should keep in mind.
In 3GPP access, the UE and the network always do a mutual authentication during network attachment [TS.33102] [TS.33401] 🔒 Also, every time a PDP context/PDN connection gets created, a new connection is made, an existing connection is modified, or an IPv6 prefix or IP address is assigned, that can be authorized against the PCC infrastructure [TS.23203] and/or the PDN's AAA server 🛡️
The wireless part of the 3GPP link between the UE and the (e)NodeB, plus the signaling messages between the UE and the MME/SGSN, can be protected, depending on regional regulation and the operator's deployment policy. User-plane traffic can be confidentiality protected. The control plane is always at least integrity and replay protected, and it may also be confidentiality protected. How the transmission part of the network is protected depends on the operator's deployment policy [TS.33401] 🌈
Several on-link and neighbor-discovery-related attacks can be mitigated thanks to the nature of the 3GPP point-to-point link model. The UE and the first-hop router (PDN-GW/GGSN or SGW) are the only nodes on the link, which helps a lot ✨ For off-link IPv6 attacks, though, the 3GPP EPS is as vulnerable as any IPv6 system 😬
There have also been concerns that the UE IP stack might use permanent subscriber identities, such as an International Mobile Subscriber Identity (IMSI), as the source for the IPv6 address Interface Identifier. That would be a privacy threat and would allow tracking of subscribers, which is seriously not it 🚫 So using an IMSI (or any identity defined by [TS.23003]) as the Interface Identifier is prohibited [TS.23401]. However, there's no standardized method to block such misbehaving UEs, so this one is a real problem 💀
10. Summary and Conclusions 🍓
The 3GPP network architecture and specifications make it possible to set up IPv4 and IPv6 connections using the right PDP context types 🦋 The current generation of deployed networks can support dual-stack connectivity, as long as the packet core network elements (like the SGSN and GGSN) have that capability. With Release-8, 3GPP specified a more optimal PDP context type that carries IPv4 and IPv6 packets within a single PDP context between the UE and the gateway 👑
As devices and applications get upgraded to support IPv6, they can start using the IPv6 connectivity the networks provide while still being able to fall back to IPv4 💖 Turning on IPv6 connectivity in 3GPP networks will by itself give some relief to the IPv4 address space, since lots of applications and services can start working over IPv6. But without comprehensive testing of widely used applications and solutions for their ability to work over IPv6 PDN connections, an IPv6-only access would cause disruptions. So test first, bestie 🙏
11. Acknowledgements 🫶
The authors thank Shabnam Sultana, Sri Gundavelli, Hui Deng, Zhenqiang Li, Mikael Abrahamsson, James Woodyatt, Wes George, Martin Thomson, Russ Mundy, Cameron Byrne, Ales Vizdal, Frank Brockners, Adrian Farrel, Stephen Farrell, Paco Cortes, and Jari Arkko for their reviews and comments on this document 💜✨
12. Informative References ✨
okay bestie, this is the reading list 📚💅 every doc the RFC leans on for backup, so you can go deeper whenever you want. I'm keeping every title, number, and date exactly as written so nothing gets lost 🫶
[GSMA.IR.34] GSMA, "Inter-PLMN Backbone Guidelines", GSMA
PRD IR.34.4.9, March 2010.
[PD-EXCLUDE] Korhonen, J., Ed., Savolainen, T., Krishnan, S., and O.
Troan, "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", Work in Progress, December 2011.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and
J. Wiljakka, "Internet Protocol Version 6 (IPv6) for
Some Second and Third Generation Cellular Hosts",
RFC 3316, April 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor
Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[TR.23975] 3GPP, "IPv6 Migration Guidelines", 3GPP
TR 23.975 11.0.0, June 2011.
[TS.23003] 3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 10.3.0, September 2011.
[TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 8.14.0,
September 2011.
[TS.23203] 3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 8.12.0, June 2011.
[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", 3GPP TS 23.401 10.5.0,
September 2011.
[TS.23402] 3GPP, "Architecture enhancements for non-3GPP
accesses", 3GPP TS 23.402 10.5.0, September 2011.
[TS.24008] 3GPP, "Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3", 3GPP
TS 24.008 8.14.0, June 2011.
[TS.24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS); Stage 3", 3GPP TS 24.301 8.10.0,
June 2011.
[TS.29002] 3GPP, "Mobile Application Part (MAP) specification",
3GPP TS 29.002 9.6.0, September 2011.
[TS.29060] 3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp
interface", 3GPP TS 29.060 8.15.0, September 2011.
[TS.29061] 3GPP, "Interworking between the Public Land Mobile
Network (PLMN) supporting packet based services and
Packet Data Networks (PDN)", 3GPP TS 29.061 8.8.0,
September 2011.
[TS.29274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved
General Packet Radio Service (GPRS) Tunnelling
Protocol for Control plane (GTPv2-C); Stage 3", 3GPP
TS 29.274 8.10.0, June 2011.
[TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
September 2011.
[TS.33102] 3GPP, "3G security; Security architecture", 3GPP
TS 33.102 10.0.0, December 2010.
[TS.33401] 3GPP, "3GPP System Architecture Evolution (SAE);
Security architecture", 3GPP TS 33.401 10.2.0,
September 2011.Authors' Addresses 🎀
the squad behind this doc 🫶 these are the people who wrote it, with their addresses and emails exactly as listed
Jouni Korhonen (editor)
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
EMail: jouni.nospam@gmail.com
Jonne Soininen
Renesas Mobile
Porkkalankatu 24
FI-00180 Helsinki
FINLAND
EMail: jonne.soininen@renesasmobile.com
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nokia.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
FINLAND
EMail: teemu.savolainen@nokia.com
Gabor Bajko
Nokia
323 Fairchild Drive 6
Mountain View, CA 94043
USA
EMail: gabor.bajko@nokia.com
Kaisu Iisakkila
Renesas Mobile
Porkkalankatu 24
FI-00180 Helsinki
FINLAND
EMail: kaisu.iisakkila@renesasmobile.comthat's the whole doc, bestie 🌈💖 you finished RFC 6459 ✨
📦 where this page comes from
- ietf: rfc6459 2012-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms