RFC 7066

IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts

📅 published November 2013, from ietf

RFC 7066: IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts 📱✨

RFC number: 7066 Authors: J. Korhonen (Ed.) of Broadcom, J. Arkko (Ed.) of Ericsson, T. Savolainen of Nokia, and S. Krishnan of Ericsson Category: Informational Date: November 2013 ISSN: 2070-1721 Obsoletes: RFC 3316 Series: Internet Engineering Task Force (IETF)

Abstract 💖

Okay, so cellular networks are blowing up! 📶 As 3G and 4G networks keep rolling out, tons of phones and other cellular hosts are getting plugged into the Internet. Standards bodies have already made IPv6 mandatory in their specs, but IPv6 is a huge topic with loads of specs, so it can get confusing. Cellular links also have their own vibe: limited bandwidth, real costs, and extra delay. That means IPv6 has to be used a little differently here 🫶

This document looks at IPv6 for cellular hosts that connect to GPRS, UMTS, or EPS networks. Those are collectively called 3GPP networks. It also lists the IPv6 features that have to be implemented on top of what the IPv6 Node Requirements document already says (RFC 6434). Finally, it talks through some issues you can hit when using these features on 3GPP networks. This document obsoletes RFC 3316 💅

Status of This Memo 📝

Not a standards-track spec! 💜 This one is published for informational purposes only.

This is a product of the Internet Engineering Task Force (IETF). It reflects what the IETF community agrees on, went through public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is up for any level of Internet Standard. See Section 2 of RFC 5741 for the details 🤓

For the current status, any errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc7066 🔗

Copyright Notice ⚖️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they apply on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🎀

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Scope of This Document .....................................3
      1.2. Abbreviations ..............................................5
      1.3. Cellular Host IPv6 Features ................................6
   2. Basic IP ........................................................6
      2.1. Internet Protocol Version 6 ................................6
      2.2. Neighbor Discovery in 3GPP Networks ........................6
      2.3. Stateless Address Autoconfiguration ........................8
      2.4. IP Version 6 over PPP ......................................8
      2.5. Multicast Listener Discovery (MLD) for IPv6 ................9
      2.6. Privacy Extensions for Address Configuration in IPv6 .......9
      2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ......9
      2.8. DHCPv6 Prefix Delegation ..................................10
      2.9. Router Preferences and More-Specific Routes ...............10
      2.10. Neighbor Discovery and Additional Host Configuration .....10
   3. IP Security ....................................................11
      3.1. Extension Header Considerations ...........................11
   4. Mobility .......................................................11
   5. Acknowledgements ...............................................11
   6. Security Considerations ........................................12
   7. References .....................................................14
      7.1. Normative References ......................................14
      7.2. Informative References ....................................15
   Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model .......17
   Appendix B. Changes from RFC 3316 .................................18

1. Introduction 🦋

Okay, so techs like GPRS, UMTS, EPS, CDMA2000, and eHRPD are making it possible for cellular hosts to stay connected to the Internet all the time 🌈 Basically, the Internet is always on now. IPv6 [RFC2460] has become essential for these networks because the number of cellular hosts is blowing up. Standards groups working on cellular tech noticed this too and made IPv6 mandatory in their specs. It's giving main character energy 👑

IPv6 support and UMTS started with 3GPP Release-99 networks and hosts. If you want the full breakdown of IPv6 in 3GPP networks, including the Evolved Packet System, check out [RFC6459] 🧚

1.1. Scope of This Document 🔍

Here's what counts for this document. A cellular interface is the interface to a cellular access network that follows these standards:

3GPP GPRS and UMTS Release-99 and Release-4 to Release-11
EPS Release-8 to Release-11
Future UMTS or EPS releases

A cellular host is any host that has a cellular interface 📲

This document goes along with the IPv6 Node Requirements [RFC6434]. It fills in the gaps where things need clearing up, and it talks about how the selected IPv6 specs behave when you're running over a cellular interface. This is needed so IPv6 can be used optimally in a cellular network. The whole thing is written from the cellular host's point of view. A cellular host might support other access technologies too, but this doc doesn't go deep on those. There are also important considerations to cut down on pointless user confusion over configuration options, to keep things interoperable, and to give implementers a handy reference. Cellular hosts have to be good citizens of the Internet 🫶

This document is informational. It is not meant to replace, update, or contradict any IPv6 standards documents or the IPv6 Node Requirements [RFC6434] 🙅‍♀️

This document is mainly for the people building cellular hosts that will work with the networks listed above. It tells you which IPv6-related specs should be implemented in those hosts. Some parts might also apply to other cellular link types, but there's no detailed analysis of those types here. This document should not be used as the definitive list of IPv6 functionalities for cellular links other than the ones listed above. If future changes in 3GPP networks affect host implementations, this document may get updated 🔄

There are different ways to build a cellular host:

The host can be a "closed" device with optimized built-in apps and no way to add or download apps that use IP. A very simple mobile phone is one example 📞
The host can be an open device, like a "smart phone" where you can download apps to extend what it does 📱💅
The cellular radio modem can be separated from the host IP stack by an interface. A laptop using a USB cellular modem for cellular access is one example 💻

If a cellular host also has other IP-capable interfaces (like Ethernet, WLAN, Bluetooth, and so on), there may be extra requirements beyond what's in this document. Also, this document doesn't make recommendations about the functionality needed on laptops with a cellular interface, whether that's an embedded modem or a USB modem stick. The only exception is recommending link-specific behavior on the cellular link itself 🤓

This document covers IPv6 functionality as of when it was written. Ongoing IPv6 work may change what future hosts need 🔮

Transition mechanisms used by cellular hosts are out of scope and are left for further study. The main transition mechanism 3GPP supports is dual-stack [RFC4213]. Dual-stack-capable bearer support was added to GPRS starting in 3GPP Release-9, and to EPS starting in Release-8 [RFC6459]. Earlier 3GPP releases needed multiple single-IP-version bearers to do dual-stack ✨

1.2. Abbreviations 🔤

Here's the abbreviations list, verbatim:

   2G    Second Generation Mobile Telecommunications, such as Global
         System for Mobile Communications (GSM) and GPRS technologies.

   3G    Third Generation Mobile Telecommunications, such as UMTS
         technology.

   4G    Fourth Generation Mobile Telecommunications, such as LTE
         technology.

   3GPP  Third Generation Partnership Project.  Throughout the document,
         the term "3GPP networks" refers to architectures standardized
         by 3GPP, in Second, Third, and Fourth Generation releases: 99,
         4, and 5, as well as future releases.

   EPS   Evolved Packet System.

   GGSN  Gateway GPRS Support Node (a default router for 3GPP IPv6
         cellular hosts in GPRS).

   GPRS  General Packet Radio Service.

   LTE   Long Term Evolution.

   MT    Mobile Terminal, for example, a mobile phone handset.

   MTU   Maximum Transmission Unit.

   PDN   Packet Data Network.

   PDP   Packet Data Protocol.

   PGW   Packet Data Network Gateway (the default router for 3GPP IPv6
         cellular hosts in EPS).

   SGW   Serving Gateway (the user plane equivalent of a Serving GPRS
         Support Node (SGSN) in EPS (and the default router for 3GPP
         IPv6 cellular hosts when using Proxy Mobile IPv6 (PMIPv6))).

   TE    Terminal Equipment, for example, a laptop attached through a
         3GPP handset.

   UMTS  Universal Mobile Telecommunications System.

   WLAN  Wireless Local Area Network.

1.3. Cellular Host IPv6 Features 🎀

This document lists the IPv6 features for cellular hosts. They're split into three groups, and each one is covered below:

Basic IP: The basic IPv6 features that cellular hosts need are listed and described here 🍓
IP Security: The IP Security parts are described in this group 🔐
Mobility: IP-layer mobility issues are described in this group 🧳

2. Basic IP 🌸

For most parts, go check out the IPv6 Node Requirements document [RFC6434] 💜

2.1. Internet Protocol Version 6 🦋

okay so the Internet Protocol version 6 (IPv6) is specified in [RFC2460] 💅. this part is a mandatory part of IPv6, no cap. a cellular host MUST conform to the generic IPv6 host requirements [RFC6434], unless it's specifically pointed out otherwise in this document 🫶.

2.2. Neighbor Discovery in 3GPP Networks 🌸

bestie, a cellular host MUST support Neighbor Solicitation and Neighbor Advertisement messages [RFC4861] ✨. some extra notes on how Neighbor Discovery gets applied on this particular type of interface can be useful, ngl 🙈.

in 3GPP networks, some Neighbor Discovery messages can be unnecessary in certain cases 💀. GPRS, UMTS, and EPS links resemble a point-to-point link, so the cellular host's only neighbor on the cellular link is the default router that's already known through Router Discovery 🎀. the cellular host always solicits for routers when the cellular interface is brought up (as described in [RFC4861], Section 6.3.7) 🔥.

there are no link-layer addresses on the 3GPP cellular link technology 😭. therefore, address resolution and next-hop determination are not needed 💖. if the cellular host still attempts address resolution, e.g., for the default router, it has to be understood that the GGSN/PGW may not even answer the address resolution Neighbor Solicitations 🙈. and even if it does, the Neighbor Advertisement is unlikely to contain the Target link-layer address option, because there are no link-layer addresses on the 3GPP cellular link technology 💅.

the cellular host MUST support Neighbor Unreachability Detection (NUD) as specified in [RFC4861] 🫶. the link-layer address considerations above also apply to NUD, periodt 💜. the NUD-triggered Neighbor Advertisement is also unlikely to contain the Target link-layer address option, since there are no link-layer addresses ✨. the cellular host SHOULD also be prepared for NUD initiated by a router (i.e., GGSN/PGW) 🦋. however, it is unlikely a router-to-host NUD would ever take place on GPRS, UMTS, or EPS links 🧚. see Appendix A for more discussion on the router-to-host NUD 🌈.

in 3GPP networks, it is desirable to reduce any additional periodic signaling 🍓. so the cellular host SHOULD include a mechanism in upper-layer protocols to provide reachability confirmations when two-way IP-layer reachability can be confirmed (see [RFC4861], Section 7.3.1) ⭐. these confirmations would allow the suppression of NUD-related messages in most cases 👑.

host TCP implementation SHOULD provide reachability confirmation in the manner explained in [RFC4861], Section 7.3.1 💖.

the widespread use of UDP in 3GPP networks poses a problem for providing reachability confirmation 😭. since UDP itself is unable to provide such confirmation, applications running on top of UDP SHOULD provide the confirmation where possible 🎀. in particular, when UDP is used for transporting DNS, the DNS response SHOULD be used as a basis for reachability confirmation 🫶. similarly, when UDP is used to transport RTP [RFC3550], the RTP Control Protocol (RTCP) [RFC3550] feedback SHOULD be used as a basis for the reachability confirmation ✨. if an RTCP packet is received with a reception report block indicating some packets have gone through, then packets are reaching the peer. and if they reached the peer, they also reached the neighbor 💅.

when UDP is used for transporting SIP [RFC3261], responses to SIP requests SHOULD be used as the confirmation that packets sent to the peer are reaching it 🌸. when the cellular host is acting as the server-side SIP node, no such confirmation is generally available 💀. however, a host MAY interpret the receipt of a SIP ACK request as confirmation that the previously sent response to a SIP INVITE request has reached the peer 🦋.

2.3. Stateless Address Autoconfiguration 🧚

IPv6 Stateless Address Autoconfiguration is defined in [RFC4862] ✨. this is a mandatory part of IPv6 and also the only mandatory method to configure an IPv6 address in a 3GPP cellular host, so it's giving main character energy 👑.

a cellular host in a 3GPP network MUST process a Router Advertisement as stated in [RFC4862] 💅. the Router Advertisement contains a maximum of one prefix information option with lifetimes set to infinite (both valid and preferred lifetimes) 🌈. the advertised prefix cannot ever be used for on-link determination (see [RFC6459], Section 5.2), and the lifetime of the advertised prefix is tied to the PDP Context/PDN Connection lifetime 🎀. keeping forward compatibility in mind, there's no reason for the 3GPP cellular host to have 3GPP-specific handling of the prefix information option(s), even though 3GPP specifications state that the Router Advertisement may contain a maximum of one prefix information option and the lifetimes are set to infinite 🙈.

hosts in 3GPP networks MAY set DupAddrDetectTransmits equal to zero 🍓, because each assigned prefix is unique within its scope when advertised using 3GPP IPv6 Stateless Address Autoconfiguration ⭐. also, the default router (GGSN/PGW) will not configure any addresses on its interfaces based on prefixes advertised to IPv6 cellular hosts on those interfaces 💖. so the host is not REQUIRED to perform Duplicate Address Detection on the cellular interface 🫶.

furthermore, the GGSN/PGW will provide the cellular host with an interface identifier that MUST be used for link-local address configuration 🔥. the link-local address configured from this interface identifier is guaranteed not to collide with the link-local address that the GGSN/PGW uses 🦋. so the cellular host is not REQUIRED to perform Duplicate Address Detection for the link-local address on the cellular interface ✨.

see Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration 🌸.

2.4. IP Version 6 over PPP 💜

a cellular host in a 3GPP network that supports PPP [RFC1661] on the interface between the MT and the TE MUST support the IPv6 Control Protocol (IPV6CP) [RFC5072] interface identifier option 🎀. this option is needed to be able to connect other devices to the Internet using a PPP link between the cellular device (MT, e.g., a USB dongle) and other devices (TE, e.g., a laptop) 🫶. the MT performs the PDP Context activation based on a request from the TE 🌈. this results in an interface identifier being suggested by the MT to the TE, using the IPV6CP option 💅. to avoid any duplication in link-local addresses between the TE and the GGSN/PGW, the MT MUST always reject other suggested interface identifiers by the TE ⭐. this results in the TE always using the interface identifier suggested by the GGSN/PGW for its link-local address 👑.

the rejection of interface identifiers suggested by the TE is only done for creation of link-local addresses, according to 3GPP specifications 🧚. the use of privacy addresses [RFC4941] or similar technologies for unique local IPv6 unicast addresses [RFC4193] and global addresses is not affected by the above procedure 🦋.

2.5. Multicast Listener Discovery (MLD) for IPv6 🍓

within 3GPP networks, hosts connect to their default routers (GGSN/PGW) via point-to-point links 🌸. moreover, there are exactly two IP devices connected to the point-to-point link, and no attempt is made (at the link layer) to suppress the forwarding of multicast traffic 💀. consequently, sending MLD reports for link-local addresses in a 3GPP environment is not necessary, although sending them causes no harm or interoperability issues 💖. refer to Section 5.10 of [RFC6434] for MLD usage for multicast group knowledge that is not link-local ✨.

2.6. Privacy Extensions for Address Configuration in IPv6 🙈

Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] or other similar technologies MAY be supported by a cellular host 🔮. privacy, in general, is important for the Internet 🫶. in 3GPP networks, the lifetime of an address assignment depends on many factors such as radio coverage, device status, and user preferences 🌈. as a result, the prefix the cellular host uses is also subject to frequent changes 🦋.

refer to Section 6 for a discussion of the benefits of Privacy Extensions in a 3GPP network 💅.

2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ⭐

as of 3GPP Release-11, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address autoconfiguration 😭. IPv6 Stateless Address Autoconfiguration still remains the only mandatory address configuration method 👑. however, DHCPv6 may be useful for other configuration needs on a cellular host, e.g., Stateless DHCPv6 [RFC3736] may be used to configure DNS and SIP server addresses, and DHCPv6 Prefix Delegation [RFC3633] may be used to delegate a prefix to the cellular host for use on its downstream non-cellular links 🎀.

2.8. DHCPv6 Prefix Delegation 🌈

starting from Release-10, DHCPv6 Prefix Delegation was added as an optional feature to the 3GPP system architecture [RFC3633] 🧚. the Prefix Delegation model defined for Release-10 requires that the /64 IPv6 prefix assigned to the cellular host on the 3GPP link MUST aggregate with the shorter delegated IPv6 prefix 🔥. the cellular host SHOULD implement the Prefix Exclude Option for DHCPv6 Prefix Delegation [RFC6603] (see [RFC6459], Section 5.3 for further discussion) 🫶.

2.9. Router Preferences and More-Specific Routes 💖

the cellular host SHOULD implement the Default Router Preferences and More-Specific Routes extension to Router Advertisement messages [RFC4191] ✨. these options may be useful for cellular hosts that also have additional interfaces on which IPv6 is used 🦋.

2.10. Neighbor Discovery and Additional Host Configuration 🍓

the DNS server configuration is learned from the 3GPP link-layer signaling 🌸. however, the cellular host SHOULD also implement the IPv6 Router Advertisement Options for DNS Configuration [RFC6106] 💅. DHCPv6 is still optional for cellular hosts, and learning the DNS server addresses from the link-layer signaling can be cumbersome when the MT and the TE are separated using techniques other than the PPP interface 💀.

the cellular host SHOULD also honor the MTU option in the Router Advertisement (see [RFC4861], Section 4.6.4) 🎀. the 3GPP system architecture uses extensive tunneling in its packet core network below the 3GPP link, and this may lead to packet fragmentation issues 😭. therefore, the GGSN/PGW MAY propose to the cellular host an MTU that takes the additional tunneling overhead into account 🌈.

3. IP Security 🔒

IPsec [RFC4301] is a fundamental, but not mandatory, part of IPv6 🧚. refer to the IPv6 Node Requirements (Section 11 of [RFC6434]) for the security requirements that also apply to cellular hosts 💜.

3.1. Extension Header Considerations 🎀

support for the Routing Header Type 0 (RH0) has been deprecated [RFC5095] 😭. therefore, the cellular host SHOULD by default follow the RH0 processing described in Section 3 of [RFC5095] 🫶.

IPv6 packet fragmentation has known security concerns 🚨. the cellular host MUST follow the handling of overlapping fragments as described in [RFC5722], and the cellular host MUST NOT fragment any Neighbor Discovery messages as described in [RFC6980] 🔥.

4. Mobility 🦋

for the purposes of this document, IP mobility is not relevant 🌸. the movement of cellular hosts within 3GPP networks is handled by link-layer mechanisms in the majority of cases 💖. 3GPP Release-8 introduced Dual-Stack Mobile IPv6 (DSMIPv6) for client-based mobility [RFC5555] ✨. client-based IP mobility is optional in the 3GPP architecture 🌈.

5. Acknowledgements ✨

Okay bestie, the authors wanted to give a huge shoutout to the original authors for their groundwork on this doc: Gerben Kuijpers, John Loughney, Hesham Soliman, and Juha Wiljakka. 🫶

The original [RFC3316] document came from a team that included Peter Hedman and Pertti Suomela, besides the authors. Peter and Pertti gave both text and their IPv6 experience to this document, which is so iconic of them. 💜

The authors also thank Jim Bound, Brian Carpenter, Steve Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Michael Thomas, Margaret Wasserman, and others on the IPv6 WG mailing list for their comments and input. 🌸

We also want to thank David DeCamp, Karim El Malki, Markus Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu, and Shabnam Sultana for their comments and input while this document was being put together. ✨

For this revised version of [RFC3316], the authors thank Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman, Owen DeLong, and Alexey Melnikov for their comments, reviews, and input. 👑

6. Security Considerations 💀

Okay, this section is serious, so let's get into it. 🙈 This document doesn't specify any new protocols or functionality, so it doesn't introduce any new security vulnerabilities. BUT specific profiles of IPv6 functionality are proposed for different situations, and vulnerabilities can open or close depending on what's included and what isn't. The cellular environment also has aspects that make certain kinds of vulnerabilities more severe. The following issues are discussed:

The suggested limitations (Section 3.1) on processing extension headers also limit exposure to Denial-of-Service (DoS) attacks through cellular hosts. 🛡️
IPv6 addressing privacy [RFC4941] or similar technology may be used in cellular hosts. Now, it should be noted that in the 3GPP model, the network would assign a new prefix, in most cases, to hosts in roaming situations. The network would also typically assign a new prefix when the cellular hosts activate a PDP Context or a PDN Connection. 3GPP devices must not use interface identifiers that are unique to the device, so the only difference in address between 3GPP devices using Stateless Address Autoconfiguration is in the prefix. This means 3GPP networks already provide a limited form of addressing privacy, and no global tracking of a single host is possible through its address. 🦋 On the other hand, since a GGSN/PGW's coverage area is expected to be very large compared to currently deployed default routers (no handovers between GGSN/PGWs are possible), a cellular host can keep a prefix for a long time. So IPv6 addressing privacy can be used for additional privacy during the time the host is on and in the same area. The privacy features can also be used to, e.g., make different transport sessions appear to come from different IP addresses. However, it is not clear that these extra efforts confuse potential observers any further, since they could monitor only the network prefix part. 🤷‍♀️
The use and recommendations of various security services, such as IPsec or Transport Layer Security (TLS) [RFC5246], for typical applications that also apply to cellular hosts are discussed in Section 11 of [RFC6434]. 🔐
The airtime used by cellular hosts is expensive! 💸 In some cases, users are billed according to the amount of data they transfer to and from their host. It is crucial for both the network and the users that airtime is used correctly and that no extra charges are applied to users due to misbehaving third parties. The cellular links also have limited capacity, which means they may not necessarily be able to accommodate more traffic than what the user selected, such as a multimedia call. Additional traffic might interfere with the service level the user experiences. Quality-of-Service mechanisms mitigate these problems to an extent, but it's still apparent that DoS aspects may be highlighted in the cellular environment. Existing DoS attacks that use, for instance, packet amplification could be substantially more damaging in this environment. How these attacks can be protected against is still an area for further study. It's also often easy to fill the cellular link and queues on both sides with additional or large packets. 😭
Within some service provider networks, it's possible to buy a prepaid cellular subscription without presenting personal identification. Attackers who want to stay unidentified could leverage this. Note that while the user hasn't been identified, the equipment still is. Operators can follow the identity of the device and block it from further use. The operators must have procedures in place to take notice of third-party complaints regarding the use of their customers' devices. It may also be necessary for operators to have attack detection tools that let them efficiently detect attacks launched from the cellular hosts. 🕵️‍♀️
Cellular devices that have local network interfaces (such as WLAN or Bluetooth) may be used to launch attacks through them, unless the local interfaces are secured in an appropriate manner. Therefore, local network interfaces should have access control to prevent others from using the cellular host as an intermediary. 🚫
The 3GPP link model mitigates most of the known IPv6 on-link and neighbor cache targeted attacks (see Section 2.2 and Appendix A). 🧚
Advice for implementations facing Neighbor Discovery DoS attacks may be useful in some environments [RFC6583]. 📝
Section 9 of [RFC6459] further discusses some recent concerns related to the security of cellular hosts. 🌈

7. References 📚

7.1. Normative References

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[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.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.

7.2. Informative References

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3315] Droms, R., 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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 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.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[TS.23060] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.
[TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013.
[TS.23402] 3GPP, "Architectural enhancements for non-3GPP accesses", 3GPP TS 23.402 11.6.0, March 2013.
[TS.29061] 3GPP, "Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)", 3GPP TS 29.061 11.4.0, March 2013.

Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model ✨

Okay bestie, this appendix is a quick tour of how phones get IPv6 addresses on 2G (GPRS), 3G (UMTS), and 4G (EPS) networks, from Release-99 onwards 📱. It's super brief, so if you want the deep dive, the 2G and 3G details live in the 3GPP Technical Specifications [TS.23060] and [TS.29061]. The 4G docs are [TS.23401], [TS.23402], and [TS.29061] 💅.

There are two ways an IPv6 node can get its address: stateless and stateful autoconfiguration 🎀. Stateful allocation needs a DHCP server to hand out the address to the node. Stateless Address Autoconfiguration doesn't need any outside entity involved (apart from the GGSN/PGW) 🦋. And at the time of writing, Stateless Address Autoconfiguration is still the only mandatory and supported address configuration method for the cellular 3GPP link 👑. Not me being obsessed with that word "only" 😭.

To support standard Stateless Address Autoconfiguration the way the IETF recommends, the GGSN/PGW shall assign a single /64 IPv6 prefix that is unique within its scope to each primary PDP Context or PDN Connection that uses Stateless Address Autoconfiguration 🌸. Why does this matter? It means nobody has to run Duplicate Address Detection (DAD) at the network level for any address the mobile host builds itself 🙈. The GGSN/PGW always provides an interface identifier to the mobile host, and the mobile host uses that identifier to generate its link-local address. The GGSN/PGW usually picks the interface identifier in a random manner 🎲. It must make sure that identifier is unique on the link, so there are no collisions between its own link-local address and the cellular host's 🔥.

The GGSN/PGW will also not use any of the prefixes assigned to cellular hosts to generate any of its own addresses 💜. Put that together with each PDP Context or PDN Connection getting its own unique prefix, and you get no need for DAD messages over the air interface. That means less wasted radio resources, which is honestly iconic 🧚. Also, giving each PDP Context or PDN Connection its own prefix lets hosts use the Privacy Extensions in [RFC4941] without needing any extra DAD messages 🦋🔐.

In practice, the GGSN/PGW only needs to route all traffic destined for the cellular host that falls under the prefix assigned to it 🚀. This means the GGSN/PGW may implement a minimal subset of Neighbor Discovery protocol. Because this is a point-to-point link with no link-layer addressing, address resolution can be entirely statically configured per PDP Context or PDN Connection 🍓. There's also no need to defend any addresses other than the link-local addresses, and only against very unlikely duplicates 🛡️. This also has an effect on router-to-host NUD. There is really no need for the NUD, since from the GGSN/PGW's point of view it doesn't need to care about a single address. It just routes the whole prefix to the cellular host ✨. Even so, the cellular host must be prepared for the unlikely event of receiving a NUD against its link-local address 🫶. It should be noted that, at the time of writing, the 3GPP specifications are silent about what should happen if the router-to-host NUD fails 🤷‍♀️.

See Section 5 of [RFC6459] for further discussion on 3GPP address allocation and the 3GPP link model. Go read it, it's the good stuff 📚.

Appendix B. Changes from RFC 3316 🎀

Here's what's new since RFC 3316, bestie. The list is long, so grab a snack 🍿.

Clarified that [RFC4941] or similar technologies may be used for privacy purposes (as stated in [RFC6459]) 🦋.
Clarified that MLD for link-local addresses is not necessary, but doing it causes no harm (instead of saying it may not be needed in some cases) 💅.
Clarified that a cellular host should not do any changes in its stack to meet the 3GPP link restriction on the Router Advertisement Prefix Information Options (PIOs) 🌈.
Clarified that a cellular host should not do any changes in its stack to meet the infinite prefix lifetime requirement the 3GPP link has ♾️.
Clarified that the prefix lifetime is tied to the PDP Context/PDN Connection lifetime ⏳.
Clarified explicitly that a NUD from the gateway side to the User Equipment's link-local address is possible 🙌.
Added references to 3GPP specifications 📚.
Provided additional clarification on NUD on 3GPP cellular links 🔍.
Added an explicit note that the prefix on the link is /64 💜.
Clarified that DHCPv6 ([RFC3315]) is not used at all for address autoconfiguration 🚫.
Removed all sections that can be directly found in [RFC6434] 🧹.
Added clarifications to 3GPP link model and how Neighbor Discovery works on it 🧚.
Added [RFC4191] recommendations 👑.
Added DHCPv6-based Prefix Delegation recommendations 🍓.
Added [RFC6106] recommendations ✨.
Added reference to [RFC5555] regarding client-based mobility 📱.
Added text regarding Router Advertisement MTU option handling 📏.
Added Evolved Packet System text 🌸.
Added clarification on the primary 3GPP IPv6 transition mechanism 🦋.
Added reference to [RFC5095], which deprecates the RH0 🙅‍♀️.
Added references to [RFC5722] and [RFC6980] regarding IPv6 fragmentation handling 🧩.
Added reference to [RFC6583] for Neighbor Discovery denial-of-service attack considerations 🛡️.
Made the PPP IPV6CP [RFC5072] support text conditional 💖.

Authors' Addresses 🫶

Meet the squad who wrote this thing. Here are their contact details, exactly as they appear in the document:

Jouni Korhonen (editor)
Broadcom
Porkkalankatu 24
FIN-00180 Helsinki
Finland

EMail: jouni.nospam@gmail.com

Jari Arkko (editor)
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net

Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
Finland

EMail: teemu.savolainen@nokia.com

Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada

Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com

📦 where this page comes from

ietf: rfc7066 2013-11
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms