RFC 3314
Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards
Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards 🎀
Okay bestie, the title block first, because it's giving important vibes 💅
- Who wrote it: M. Wasserman, Ed. from Wind River 🦋
- Category: Informational, so it's advice and not a standard 🌸
- Date: September 2002 ✨
- Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates 🫶
- RFC number: 3314, so you can find it on the RFC Editor site 💜
Status of This Memo 📌
This memo gives info to the Internet community. It does not specify an Internet standard of any kind, so don't go treating it like a spec 🙈 Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved. 💖
Abstract ✨
So this document is basically a set of recommendations from the IETF IPv6 Working Group to the Third Generation Partnership Project (3GPP) community about using IPv6 in the 3GPP standards 🧚 The main ask is that 3GPP specify that multiple prefixes may be assigned to each primary PDP context. It also says a given prefix must not be assigned to more than one primary PDP context, and that 3GPP nodes can use multiple identifiers within those prefixes, including randomly generated identifiers. Literally a whole plan 🔥
The IPv6 Working Group is totally supportive of IPv6 in 3GPP, and they're offering these recs out of open cooperation between the two groups 🫶 Since this was first published as an Internet-Draft, 3GPP has adopted the primary recommendations from this document. Iconic behavior from 3GPP honestly 👑
Conventions Used In This Document 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORD]. These are the serious requirement words, so pay attention to them 🤓
Table of Contents 🌸
1 Introduction............................................. 2
1.1 What is the 3GPP?........................................ 3
1.2 What is the IETF?........................................ 4
1.3 Terminology.............................................. 4
1.3.1 3GPP Terminology......................................... 4
1.3.2 IETF Terminology......................................... 5
1.4 Overview of the IPv6 Addressing Architecture............. 6
1.5 An IP-Centric View of the 3GPP System.................... 7
1.5.1 Overview of the UMTS Architecture........................ 7
1.5.2 The PDP Context.......................................... 10
1.5.3 IPv6 Address Autoconfiguration in GPRS................... 11
2 Recommendations to the 3GPP.............................. 13
2.1 Limitations of 3GPP Address Assignment................... 13
2.2 Advertising Multiple Prefixes............................ 14
2.3 Assigning a Prefix to Only One Primary PDP Context....... 14
2.3.1 Is a /64 per PDP Context Too Much?....................... 15
2.3.2 Prefix Information in the SGSN........................... 16
2.4 Multiple Identifiers per PDP Context..................... 16
3 Additional IPv6 Work Items............................... 16
4 Security Considerations.................................. 17
Appendix A: Analysis of Findings................................ 18
Address Assignment Solutions..................................... 18
References....................................................... 19
Authors and Acknowledgements..................................... 22
Editor's Address................................................. 22
Full Copyright Statement......................................... 231. Introduction 🦋
Okay so back in May 2001, the IPv6 Working Group (WG) held an interim meeting in Redmond, WA to talk about using IPv6 within the 3GPP standards 💅 The first day was a joint discussion with 3GPP, where they got an architectural overview of how 3GPP uses IPv6, and there was a lot of discussion about specific parts of that. At that meeting, they decided to form a design team to write a doc giving advice from the IPv6 WG to the 3GPP community about their use of IPv6. This document is the result of that effort ✨
This document gives recommendations to the 3GPP community from the IETF IPv6 Working Group. It's organized into three main sections:
- An introduction (this section) that gives background on the IETF IPv6 WG and the 3GPP, plus a high-level overview of the technologies discussed in this document.
- Recommendations from the IPv6 WG to the 3GPP community. These can be found in section 2.
- Further work items that should be considered by the IPv6 WG. These items are discussed in section 3.
The whole point of this doc is to give advice from the IPv6 Working Group to the 3GPP community 🧚 They kept the contents limited to stuff that's directly related to using IPv6 within 3GPP. This document defines no standards, and it's not a definitive source of info about IPv6 or 3GPP, so don't treat it like gospel 🙈 They also didn't dig into 3GPP-related issues with other IETF protocols (i.e., SIP, IPv4, etc.), since those are outside the scope of the IPv6 Working Group.
The IPv6 Working Group fully supports using IPv6 within 3GPP, and they encourage 3GPP implementers and operators to join in on the IETF process 🌈 They're offering these suggestions out of open cooperation between the IPv6 Working Group and the 3GPP community, and they hope that ongoing cooperation will help strengthen both sets of standards. Main character collab energy 🫶
The 3GPP address allocation info in this document is based on the 3GPP document TS 23.060 version 4.1.0 [OLD-TS23060]. At the 3GPP plenary meeting TSG #15 in March 2002, 3GPP adopted the two primary recommendations in this document: allocating a unique prefix to each primary PDP context when IPv6 stateless address autoconfiguration is used, and allowing the terminals to use multiple interface identifiers. These changes were retroactively applied from 3GPP release 99 onwards, in TS23.060 versions 3.11.0, 4.4.0 and 5.1.0 [NEW-TS23060]. Iconic retroactive glow-up 💖
1.1 What is the 3GPP? 🌸
The Third Generation Partnership Project (3GPP) is a global standardization partnership founded in late 1998. Its Organizational Partners agreed to cooperate on producing technical specifications for a Third Generation Mobile System, based on the evolved GSM core networks 📱
The 3GPP Organizational Partners are a bunch of different standardization orgs: ETSI from Europe, Standards Committee T1 Telecommunications (T1) in the USA, China Wireless Telecommunication Standard Group (CWTS), Korean Telecommunications Technology Association (TTA), the Association of Radio Industries and Businesses (ARIB), and the Telecommunication Technology Committee (TTC) in Japan. So many squad members 🌍
The work is coordinated by a Project Co-ordination Group (PCG) and structured into Technical Specification Groups (TSGs). There are five TSGs: Core Network (TSG CN), Radio Access Networks (TSG RAN), Services and System Aspects (TSG SA), GSM/EDGE Radio Access Network (GERAN), and the Terminals (TSG T). The TSGs are further divided into Working Groups (WGs). The technical work gets done in the working groups, and then it's approved in the TSGs ✨
3GPP working methods are different from IETF working methods, and the big difference is where most of the work happens. In 3GPP, the work is done in face-to-face meetings. The mailing list is mainly used for distributing contributions, and for handling documents that didn't get handled in the meeting because there wasn't enough time. Decisions are usually made by consensus, though voting does exist. It's honestly pretty rare to vote 🙈 3GPP documents are public and can be accessed via the 3GPP web site [3GPP-URL]. Free content, periodt 🎀
1.2 What is the IETF? 🦋
The Internet Engineering Task Force (IETF) is a large, open, international community of network designers, operators, vendors, and researchers, concerned with the evolution of the Internet architecture and the smooth operation of the Internet 💜 It's also the primary standards body developing Internet protocols and standards. It's open to any interested individual, so literally anyone can join. More info about the IETF can be found at the IETF web site [IETF-URL] 🌈
The actual technical work of the IETF gets done in working groups, which are organized by topic into several areas (e.g., routing, transport, security, etc.). The IPv6 Working Group is chartered within the Internet area of the IETF. A lot of the work happens over mailing lists, and the IETF holds meetings three times per year 🍓
1.3 Terminology 🧚
This section defines the 3GPP and IETF terminology used in this document. The 3GPP terms and their meanings were taken from [TR21905] ✨
1.3.1 3GPP Terminology 📡
APN Access Point Name. The APN is a logical name referring
to a GGSN and an external network.
CS Circuit Switched
GERAN GSM/EDGE Radio Access Network
GGSN Gateway GPRS Support Node. A router between the GPRS
network and an external network (i.e., the Internet).
GPRS General Packet Radio Services
GTP-U General Tunneling Protocol - User Plane
MT Mobile Termination. For example, a mobile phone
handset.
PDP Packet Data Protocol
PDP Context A PDP connection between the UE and the GGSN.
PS Packet Switched
SGSN Serving GPRS Support Node
TE Terminal Equipment. For example, a laptop attached
through a 3GPP handset.
UE User Equipment (TE + MT + USIM). An example would be
a mobile handset with a USIM card inserted and a
laptop attached.
UMTS Universal Mobile Telecommunications System
USIM Universal Subscriber Identity Module. Typically, a
card that is inserted into a mobile phone handset.
UTRAN Universal Terrestrial Radio Access Network1.3.2 IETF Terminology 💅
IPv6 Internet Protocol version 6 [RFC 2460]
NAS Network Access Server
NAT Network Address Translator
NAT-PT Network Address Translation with Protocol Translation.
An IPv6 transition mechanism. [NAT-PT]
PPP Point-to-Point Protocol [PPP]
SIIT Stateless IP/ICMP Transition Mechanism [SIIT]Part 2 is next, with the Overview of the IPv6 Addressing Architecture and the 3GPP system, so stay tuned 🫶💖
1.4 Overview of the IPv6 Addressing Architecture ✨
okay so this section is the foundation for everything else in the doc 🧚 the recs are mostly about how IPv6 addresses get assigned, so we need to understand the IPv6 addressing architecture and the way addresses are assigned right now 💅
the IPv6 addressing architecture is a huge glow-up from IPv4 addressing [ADDRARCH] 🦋 every IPv6 node is required to be able to build its own addresses from interface identifiers and prefix information 🫶 that's called IPv6 Host Autoconfiguration [AUTOCONF], and it lets nodes configure themselves without stateful configuration servers (i.e., DHCPv6) or statically configured addresses 🌸 no babysitter server needed, it's giving independence 😭
interface identifiers can be globally unique, like modified EUI-64 addresses [ADDRARCH], or non-unique, like randomly generated identifiers 🎀 hosts that already have a globally unique identifier can still pick randomly generated addresses for privacy [PRIVADDR] or other reasons 🙈 IPv6 hosts are free to make new identifiers whenever they want, and Duplicate Address Detection (DAD) is what protects against duplicate identifiers on a single link [IPV6ND] 🛡️ the safety net is iconic ✨
a constant link-local prefix can be paired with any interface identifier to make an address for talking on a locally attached link 🍓 IPv6 routers may advertise extra prefixes (site-local and/or global prefixes)[IPV6ND] 💜 and hosts can mix those advertised prefixes with their own interface identifiers to make addresses for site-local and global communication 🌈 mix and match, periodt 💅
IPv6 bakes in architectural support for scoped unicast addressing [SCOPARCH] 👑 a single interface will usually have several addresses for different scopes: link-local, site-local and/or global [ADDRARCH] 🌷 link-local addresses let things talk locally even when no IPv6 router is around 🫧 some IPv6 protocols (i.e., routing protocols) are required to use link-local addresses 🔥 site-local addressing keeps communication administratively contained within one site 🏠 and link-local or site-local connections can survive changes to global prefix information (e.g., site renumbering) 🦄 that's a big mood, no cap
IPv6 explicitly ties each address to an interface 💖 multiple-interface hosts can have interfaces on more than one link or in more than one site 🧩 links and sites are identified internally with zone identifiers 🪪 proper routing of non-global traffic and proper address selection are both ensured by the IPv6 scoped addressing architecture [SCOPARCH] ✨ very organized, very slay
IPv6 introduces the concept of privacy addresses [PRIVADDR] 🕶️ these are generated from an advertised global prefix and a randomly generated identifier, and they're used for anonymous access to Internet services 🙈 applications control how privacy addresses get generated, and new addresses can be made at any time 🌸 the app is literally the boss of it 👑
the IPv6 site renumbering specification [SITEREN] depends on the fact that IPv6 nodes will generate new addresses when new prefixes get advertised on the link, and that they will deprecate addresses that use deprecated prefixes 🦋 so the whole renumbering plan is built on nodes being that responsive 🫶
in the future, more IPv6 specs may rely on the ability of IPv6 nodes to use multiple prefixes and/or multiple identifiers to dynamically create new addresses 🔮 the possibilities are literally endless bestie 🌈
1.5. An IP-Centric View of the 3GPP System 🌈
okay so the 3GPP specs define a Third Generation Mobile System 📱✨ bestie, this section gives you a tour of the packet switched (PS) domain of the 3GPP Release 99 system. the authors hope it's enough for anyone who's new to the UMTS packet switched service to get how UMTS works and how IPv6 is currently defined to be used inside it 🫶
1.5.1. Overview of the UMTS Architecture 🏗️
the UMTS architecture splits into two main domains, the packet switched (PS) domain and the circuit switched (CS) domain 💅 this document focuses on the PS domain, also called General Packet Radio Services (GPRS) 🧚
------
| TE |
------
|
+R
|
------ Uu ----------- Iu ----------- Gn ----------- Gi
| MT |--+--| UTRAN |--+--| SGSN |--+--| GGSN |--+--
------ ----------- ----------- -----------
(UE)
Figure 1: Simplified GPRS Architecture ------
| |
| App |- - - - - - - - - - - - - - - - - - - - - - - - -(to app peer)
| |
|------| -------------
| IP |- - - - - - - - - - - - - - - - - - - - - - -| IP |->
| v4/6 | | v4/6 |
|------| ------------- ------------- |------ |
| | | \ Relay / | | \ Relay / | | | |
| | | \ / | | \ / | | | |
| | | \ / | | \ / | | | |
| PDCP |- - -| PDCP\ /GTP_U|- - -|GTP_U\ /GTP_U|- - -|GTP_U | |
| | | | | | | | | | |
|------| |------|------| |------|------| |------| |
| | | | UDP |- - -| UDP | UDP |- - -| UDP | |
| | | |------| |------|------| |------| |
| RLC |- - -| RLC | IP |- - -| IP | IP |- - -| IP | |
| | | | v4/6 | | v4/6 | v4/6 | |v4/6 | |
|------| |------|------| |------|------| |------|------|
| MAC | | MAC | AAL5 |- - -| AAL5 | L2 |- - -| L2 | L2 |
|------| |------|------| |------|------| |------|------|
| L1 |- - -| L1 | ATM |- - -| ATM | L1 |- - -| L1 | L1 |
------ ------------- ------------- -------------
UE UTRAN SGSN GGSN
(handset)
Figure 2: GPRS Protocol Stacks ------
| |
| App. |- - - - - - - - - - - - - - - - - - - - - - (to app peer)
| |
|------|
| |
| IP |- - - - - - - - - - - - - - - - - - - - - - (to GGSN)
| v4/6 |
| | | |
|------| |-------------|
| | | \ Relay / |
| | | \ / |
| | | \ / |
| | | \ / PDCP|- - - (to UTRAN)
| | | | |
| PPP |- - -| PPP |------|
| | | | RLC |- - - (to UTRAN)
| | | |------|
| | | | MAC |
|------| |------|------|
| L1a |- - -| L1a | L1b |- - - (to UTRAN)
------ -------------
TE MT
(laptop) (handset)
Figure 3: Laptop Attached to 3GPP Handsetthe GPRS core network elements, shown in Figures 1 and 2, are the User Equipment (UE), Serving GPRS Support Node (SGSN), and Gateway GPRS Support Node (GGSN) 🎀 the UTRAN is made up of Radio Access Network Controllers (RNC) and the UTRAN base stations 🦋
- GGSN: A specialized router that functions as the gateway between the GPRS network and the external networks, e.g., Internet. It also gathers charging information about the connections. In many ways, the GGSN is similar to a Network Access Server (NAS). 🌐
- SGSN: The SGSN's main functions include authentication, authorization, mobility management, and collection of billing information. The SGSN is connected to the SS7 network and through that, to the Home Location Register (HLR), so that it can perform user profile handling, authentication, and authorization. 💼
- GTP-U: A simple tunnelling protocol running over UDP/IP and used to route packets between RNC, SGSN and GGSN within the same, or between different, UMTS backbone(s). A GTP-U tunnel is identified at each end by a Tunnel Endpoint Identifier (TEID). 🚇
only the most significant elements of the GPRS system are discussed in this document 🙈 if you want more, check out [OLD-TS23060] 📚
1.5.2. The PDP Context 💜
the most important 3GPP concept here is the PDP Context 👑 a PDP Context is a connection between the UE and the GGSN, and that's the pipe the packets travel through 🫧 there are two kinds, primary and secondary 💖
the primary PDP Context is what first sets up the link to the GGSN ✨ for example, an IP address gets assigned to each primary PDP Context 🌸 then you can add one or more secondary PDP Contexts to a primary one, and they share the same IP address 🦋 the secondary ones can have different Quality of Service characteristics than the primary one 💅
put together, a primary PDP Context and zero or more secondary PDP Contexts define, in IETF terms, a link 🔗 GPRS links are point-to-point 🎯 once activated, all PDP contexts have equal status 🫶 that means a primary PDP context can be deleted while the link between the UE and the GGSN stays up, as long as there are other (secondary) PDP contexts active for the same IP address 🙌
there are currently three PDP Types supported in GPRS: IPv4, IPv6, and PPP 🌈 this document only discusses the IPv6 PDP Type 🧚
there are three basic actions you can do to a PDP Context: PDP Context Activation, Modification, and Deactivation 🎀
- Activate PDP Context: Opens a new PDP Context to a GGSN. If a new primary PDP Context is activated, there is a new link created between a UE and a GGSN. A UE can open multiple primary PDP Contexts to one or more GGSNs. ✨
- Modify PDP Context: Changes the characteristics of a PDP Context, for example QoS attributes. 🔧
- Deactivate PDP Context: Deactivates a PDP Context. If a primary PDP Context and all secondary PDP contexts associated with it are deactivated, a link between the UE and the GGSN is removed. 🥀
the APN is a name that's logically linked to a GGSN 🏷️ it can identify a service or an external network, and its syntax corresponds to a fully qualified domain name 🌍 at PDP context activation, the SGSN does a DNS query to find out which GGSN(s) serve the APN the terminal asked for 🔍 the DNS response has a list of GGSN addresses, and the SGSN picks one of them (in a round-robin fashion) 🔁
--------- --------
| | | GGSN |
| | LINK 1 | |
| -======== PDP Context A ========- - - -> ISP X
| | | |
| | | |
| | | |
| /======= PDP Context B =======\ |
| - | LINK 2 | - - - -> ISP Y
| \======= PDP Context C =======/ |
| | | |
| MT | --------
|(handset)|
| | --------
-------- | | | GGSN |
| | | | LINK 3 | |
| | | -======== PDP Context D ========- |
| TE | | | | |
|(laptop)| | | | - - -> ISP Z
| | | | LINK 4 | |
| -====PPP====-----======== PDP Context E ========- |
| | | | | |
| | | | | |
-------- --------- --------
Figure 3: Correspondence of PDP Contexts to IPv6 Links1.5.3. IPv6 Address Autoconfiguration in GPRS 🫧
GPRS supports static and dynamic address allocation 💫 there are two kinds of dynamic allocation, stateless and stateful 🌼 stateful configuration uses an external protocol to talk to a server that hands out the IP address, e.g., DHCP 📮
stateless IPv6 autoconfiguration works differently in GPRS than it does in Ethernet networks 🙈 GPRS nodes have no unique identifier, whereas Ethernet nodes can make one from their EUI-48 address 😭 since GPRS networks are similar to dialup networks, stateless address autoconfiguration in GPRS was based on PPPv6 [PPPV6] 🧠
3GPP address autoconfiguration has the following steps:
- The Activate PDP Context message is sent to the SGSN (PDP Type=IPv6, PDP Address = 0, etc.).
- The SGSN sends a Create PDP Context message to the GGSN with the above parameters.
- GGSN chooses an interface identifier for the PDP Context and creates the link-local address. It answers the SGSN with a Create PDP Context response (PDP Address = link-local address).
- The SGSN sends an Activate PDP Context accept message to the UE (PDP Address = link-local address).
- The UE keeps the link-local address, and extracts the interface identifier for later use. The UE may send a Router Solicitation message to the GGSN (first hop router).
- After the PDP Context Activation, the GGSN sends a Router Advertisement to the UE.
- The UE should be configured not to send a Neighbor Solicitation message. However, if one is sent, the GGSN will silently discard it.
- The GGSN updates the SGSN with the whole IPv6 address.
each connected handset or laptop creates a primary PDP context for communication on the Internet 📱💻 a handset can create lots of primary and/or secondary PDP contexts over the whole life of its connection with a GGSN 🔄
within 3GPP, the GGSN assigns a single 64-bit identifier to each primary PDP context 🎟️ the GGSN also advertises a single /64 prefix to the handset, and those two pieces get assembled into one IPv6 address 🧩 later, the GGSN updates the PDP context entry in the SGSN to include the whole IPv6 address, so the SGSN can know the single address of each 3GPP node (e.g., for billing purposes) 💰 that address is also used in the GGSN to identify the PDP context associated with each packet 📦 it is assumed that 3GPP nodes will not generate any addresses, except for the single identifier/prefix combination the GGSN assigns 🙅♀️ DAD is not performed, as the GGSN will not assign the same address to multiple nodes 🫶✨
2. Recommendations to the 3GPP ✨
Okay so, in the spirit of productive cooperation 🫶, the IPv6 Working Group is recommending that the 3GPP consider three changes for using IPv6 within GPRS. Specifically, we recommend that the 3GPP:
- Specify that multiple prefixes may be assigned to each primary PDP context,
- Require that a given prefix must not be assigned to more than one primary PDP context, and
- Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
Making these changes would give 3GPP implementers and users some major wins 🔥:
- Laptops that connect to 3GPP handsets will work without any software changes 💻✨. Their implementation of the standard IPv6 over PPP, address assignment, and autoconfiguration mechanisms will work without any modification. This will eliminate the need for vendors and operators to build and test special 3GPP drivers and related software. As currently specified, the 3GPP standards will be incompatible with laptop implementations that generate their own identifiers for privacy or other purposes. It's literally giving "why is this not already how it works" 🙈.
- IPv6 software implementations could be used in 3GPP handsets without any modifications to the IPv6 protocol mechanisms 📱. This will make it easier to build and test 3GPP handsets.
- Applications in 3GPP handsets will be able to take advantage of different types of IPv6 addresses (e.g., static addresses, temporary addresses for privacy, site-scoped addresses for site only communication, etc.) 🦋.
- The GPRS system will be better positioned to take advantage of new IPv6 features that are built around the current addressing architecture 🌈.
2.1. Limitations of 3GPP Address Assignment
Okay, so the current 3GPP address assignment mechanism has the following limitations 💀:
- The GGSN only advertises a single /64 prefix, rather than a set of prefixes. This will prevent the participation of 3GPP nodes (e.g., handsets or 3GPP-attached laptops) in IPv6 site renumbering, or in other mechanisms that expect IPv6 hosts to create addresses based on multiple advertised prefixes. 😭
- A 3GPP node is assigned a single identifier and is not allowed to generate additional identifiers. This will prevent the use of privacy addresses by 3GPP nodes. This also makes 3GPP mechanisms not fully compliant with the expected behavior of IPv6 nodes, which will result in incompatibility with popular laptop IPv6 stacks. For example, a laptop that uses privacy addresses for web browser connections could not currently establish a web browser connection over a 3GPP link. Not me being shocked by this 🙅♀️.
These limitations could be avoided by enabling the standard IPv6 address allocation mechanisms in 3GPP nodes 🧚. The GGSN could advertise one or more prefixes for the local link in standard IPv6 Router Advertisements, and IPv6 addresses could be assembled, as needed, by the IPv6 stack on the handset or laptop. An interface identifier could still be assigned by the GGSN, as is currently specified in the 3GPP standards. However, the handset or laptop could generate additional identifiers, as needed for privacy or other reasons. The fix is so clean, bestie 👑.
2.2. Advertising Multiple Prefixes
For compliance with current and future IPv6 standards, the IPv6 WG recommends that the 3GPP allow multiple prefixes to be advertised for each primary PDP context. This would have several advantages, including:
- 3GPP nodes could participate in site renumbering and future IPv6 mechanisms that rely on the use of multiple global prefixes on a single link 🌸.
- Site-local prefixes could be advertised on 3GPP links, if desired, allowing for site-constrained communication that could survive changes to global prefix information (e.g., site renumbering) 💜.
2.3. Assigning a Prefix to Only One Primary PDP Context
The IPv6 WG recommends that the 3GPP treat a primary PDP context, along with its secondary PDP contexts, as a single IPv6 link, and that the GGSN view each primary PDP context as a single subnet. Accordingly, a given global (or site-local) prefix should not be assigned to more than one PDP context. Think of it like a group chat with one invite link per room, no sharing 🫠.
Because multiple IPv6 hosts may attach through a 3GPP handset, the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary PDP context. This will allow sufficient address space for a 3GPP-attached node to allocate privacy addresses and/or route to a multi-link subnet [MULTLINK], and will discourage the use of NAT within 3GPP-attached devices 🍓.
2.3.1. Is a /64 per PDP Context Too Much?
Okay but the real question is: if an operator assigns a /64 per PDP context, can we be assured that there is enough address space for millions of mobile devices? 🤔 Yes, this can be answered in the positive using the Host Density (HD) Ratio for address assignment efficiency [HD]. This is a measure of the number of addresses that can practically and easily be assigned to hosts, taking into consideration the inefficiencies in usage resulting from the various address assignment processes. The HD ratio was empirically derived from actual telephone number and data network address assignment cases. Receipts, bestie 🧾.
We can calculate the number of easily assignable /64's making the following assumptions:
- An HD ratio of
0.8(representing the efficiency that can be achieved with no particular difficulty). - Only addresses with the 3-bit prefix
001(the Aggregatable Global Unicast Addresses defined by RFC 2373) are used, resulting in 61 bits of assignable address space.
Using these assumptions, a total of 490 trillion (490x10^12) /64 prefixes can be assigned. This translates into around 80,000 PDP Contexts per person on the earth today 🌍. Even assuming that a majority of these IPv6 /64 prefixes will be used by non-3GPP networks, there is still clearly a sufficient number of /64 prefixes. Literally so much room 🦋.
Given this, it can be safely concluded that the IPv6 address space will not be exhausted if /64 prefixes are allocated to primary PDP contexts. Address space: not running out, periodt ✨
For more information regarding policies for IPv6 address assignment, refer to the IAB/IESG recommendations regarding address assignment [IABAA], and the APNIC, ARIN and RIPE address allocation policy [AAPOL] 📚.
2.3.2. Prefix Information in the SGSN
Currently, the 3GPP standards allow only one prefix and one identifier for each PDP context. So, the GGSN can send a single IPv6 address to the SGSN, to be used for billing purposes, etc. 💸
Instead of using the full IPv6 address to identify a PDP context, the IPv6 WG recommends that the SGSN be informed of each prefix that is currently assigned to a PDP context. By assigning a prefix to only one primary PDP context, the SGSN can associate a prefix list with each PDP context 🧠. Main character energy for the SGSN, honestly.
2.4. Multiple Identifiers per PDP Context
The IPv6 WG also recommends that the 3GPP standards be modified to allow multiple identifiers, including randomly generated identifiers, to be used within each assigned prefix. This would allow 3GPP nodes to generate and use privacy addresses, and would be compatible with future IPv6 standards that may depend on the ability of IPv6 nodes to generate new interface identifiers for communication 🎀.
This is a vital change, necessary to allow standards-compliant IPv6 nodes to connect to the Internet through 3GPP handsets, without modification. It is expected that most IPv6 nodes, including the most popular laptop stacks, will generate privacy addresses. The current 3GPP specifications will not be compatible with those implementations. 🚨
3. Additional IPv6 Work Items
During our work on this document, we have discovered several areas that could benefit from further informational or standards-track work within the IPv6 Working Group 🔍.
The IPv6 WG should work to define a point-to-point architecture and specify how the standard IPv6 address assignment mechanisms are applicable to IPv6 over point-to-point links. We should also review and clarify the IPv6 over PPP specification [PPP] to match the current IPv6 addressing architecture [ADDRARCH] 🛠️.
The IPv6 WG should consider publishing an "IPv6 over PDP Contexts" (or similar) document. This document would be useful for developers writing drivers for IPv6 stacks to work over 3GPP PDP Contexts 🧑💻.
The IPv6 working group should undertake an effort to define the minimal requirements for all IPv6 nodes. Minimalism era, bestie 🌷.
4. Security Considerations 🔐
This document contains recommendations on the use of the IPv6 protocol in 3GPP standards. It does not specify a protocol, and it introduces no new security considerations. Phew, no drama here ✨.
Appendix A: Analysis of Findings 📖
This section includes some analysis that may be useful to understanding why the IPv6 working group is making the above recommendations. It also includes some other options that were explored, and the reasons why those options were less suitable than the recommendations outlined above 💖.
A.1 Address Assignment Solutions 🎀
Okay so, bestie, to let a primary PDP Context carry multiple IPv6 addresses with different interface identifiers, we'd need some changes to the current 3GPP specs 🛠️✨
The team judged the possible solutions against these factors:
- Scarcity and high cost of wireless spectrum 📡
- Complexity of implementation and state maintenance 🧠
- Stability of the relevant IETF standards 🏛️
- Impact on current 3GPP standards 📑
Two ways to get autoconfiguration of multiple addresses on the same primary PDP Context were on the table 👀
- Assign one or more entire prefixes (
/64s) to a PDP Context upon PDP Context activation and allow the autoconfiguration of multiple addresses 💖- a) The assignment may be performed by having the GGSN advertise one or more
/64prefixes to the mobile device 📣 - b) The assignment may be performed by building "prefix delegation" functionality into the PDP Context messages or by using layer 3 mechanisms such as [PREFDEL]. In this way, the prefix is not assigned to the link between the GGSN and the mobile device (as in 1a), but it is assigned to the mobile device itself. Note that [PREFDEL] cannot be considered stable and has not, at this stage, been adopted by the IPv6 WG as a WG document 🥺
- a) The assignment may be performed by having the GGSN advertise one or more
- Share the same prefix between multiple PDP Contexts connected to the same GGSN (and APN). Mobile devices may generate multiple addresses using more than one interface identifier, so this would need DAD for the newly generated addresses over the air interface, plus a proxy DAD function. That would bump up the complexity and the amount of state the GGSN has to keep 😵💫 Also, the GGSN would need to figure out when the temporary addresses are no longer in use, which would be really hard 💀 One possible fix could be periodic unicast neighbor solicitations for the temporary addresses [IPV6ND] 🧩
Okay, so after weighing all the factors, the recommendation is to go with Solution 1a 👑. It needs the least change to the current 3GPP standards and still keeps all the perks of the other solutions 💅
Effectively, each APN in a GGSN would have a certain number of /64 prefixes that can be handed out at PDP context activation, through Router Advertisements 🌸 So instead of using the full IPv6 address to identify a primary PDP context, the IPv6 WG recommends that the GGSN use the entire prefix (together with other 3GPP specific information), and that the SGSN be informed of the prefixes assigned to a PDP context 🫶 Since a given prefix is assigned to only one primary PDP context, the GGSN and SGSN can associate a prefix list with each PDP context whenever it's needed 🦋
Note that the recommended solution does not imply or assume that the mobile device is a router 🙈 The MT is expected to use the /64 for itself, and it may also use this prefix for devices attached to it. That's not required, though, if each device behind the MT is connected to a separate primary PDP Context, so it can use a /64 that isn't shared with anyone else 🎀 The MT is also expected to handle DAD locally for devices attached to it (e.g., laptops), without forwarding Neighbor Solicitations over the air to the GGSN 🧚
References 📚
[OLD-TS23060] TS 23.060, "General Packet Radio Service (GPRS); Service description; Stage 2", V4.1.0
[NEW-TS23060] TS 23.060 version 3.11.0 (release 99), 4.4.0 (release 4) and 5.1.0 (release 5).
[3GPP-URL] http://www.3gpp.org
[IETF-URL] http://www.ietf.org
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.
[TR21905] 3GPP TR 21.905, "Vocabulary for 3GPP Specifications", V5.0.0
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[NAT-PT] Tsirtsis, G. and P. Shrisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[SIIT] Nordmark, N., "Stateless IP/ICMP Translation Algorithm", RFC 2765, February 2000.
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[IPV6ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[AUTOCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998
[PRIVADDR] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[IPV6ETH] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[PPPv6] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[MULTLINK] C. Huitema, D. Thaler, "Multi-link Subnet Support in IPv6", Work in Progress.
[SITEREN] C. Huitema, "IPv6 Site Renumbering", Work in Progress.
[HD] Durand, A. and C. Huitema, "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio", RFC 3194, November 2001.
[IABAA] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[AAPOL] APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and Assignment Global Policy", Work in Progress.
[SCOPARCH] S. Deering, et. al., "IPv6 Scoped Address Architecture", Work in Progress.
[CELLREQ] J. Arkko, et. al., "Minimum IPv6 Functionality for a Cellular Host", Work in Progress.
[PREFDEL] J. Martin, B. Haberman, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)", Work in Progress.
Authors and Acknowledgements 💜
This document was written by the IPv6 3GPP design team:
Steve Deering, Cisco Systems EMail: deering@cisco.com
Karim El-Malki, Ericsson Radio Systems EMail: Karim.El-Malki@era.ericsson.se
Paul Francis, Tahoe Networks EMail: francis@tahoenetworks.com
Bob Hinden, Nokia EMail: hinden@iprg.nokia.com
Christian Huitema, Microsoft EMail: huitema@windows.microsoft.com
Niall Richard Murphy, Hutchison 3G EMail: niallm@enigma.ie
Markku Savela, Technical Research Centre of Finland Email: Markku.Savela@vtt.fi
Jonne Soininen, Nokia EMail: Jonne.Soininen@nokia.com
Margaret Wasserman, Wind River EMail: mrw@windriver.com
Information was incorporated from a presentation co-authored by:
Juan-Antonio Ibanez, Ericsson Eurolab
Editor's Address 💌
Comments or questions regarding this document should be sent to:
Margaret Wasserman Wind River 10 Tara Blvd., Suite 330 Nashua, NH 03062 USA
Phone: (603) 897-2067 EMail: mrw@windriver.com
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc3314 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms