RFC 3316
Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
RFC 3316 🎀 Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
okay bestie, so this is RFC 3316 🦋 It's an Informational doc from the Network Working Group, dated April 2003. J. Arkko, G. Kuijpers and H. Soliman wrote it from Ericsson, and J. Loughney and J. Wiljakka wrote it from Nokia 💅 It doesn't obsolete or update anything, since the header doesn't list anything like that. It's info, not a standard, so no pressure 💖
Status of this Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 📜
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🌸
okay so as more second and third generation cellular networks roll out, a huge pile of cellular hosts are getting connected to the Internet 📱 Standards orgs are making IPv6 mandatory in their specs, but IPv6 covers a LOT of stuff and tons of specs, so it can get messy ngl 🙈 Cellular links also have their own vibe with bandwidth, cost and delay, which puts special requirements on how IPv6 gets used. This doc looks at IPv6 for cellular hosts that attach to GPRS or UMTS networks. It also lists the basic pieces of IPv6 functionality and talks through some issues with using those pieces on these networks 🧚
Table of Contents 🗂️
1. Introduction.....................................................3
1.1 Scope of this Document......................................3
1.2 Abbreviations...............................................4
1.3 Cellular Host IPv6 Features.................................5
2. Basic IP.........................................................5
2.1 RFC1981 - Path MTU Discovery for IP Version 6...............5
2.2 RFC3513 - IP Version 6 Addressing Architecture..............6
2.3 RFC2460 - Internet Protocol Version 6.......................6
2.4 RFC2461 - Neighbor Discovery for IPv6.......................7
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration..........8
2.6 RFC2463 - Internet Control Message Protocol for the IPv6....8
2.7 RFC2472 - IP version 6 over PPP.............................9
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification....9
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6.......9
2.10 RFC2711 - IPv6 Router Alert Option.........................10
2.11 RFC3041 - Privacy Extensions for Address Configuration
in IPv6 .........................................10
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)......10
2.13 RFC3484 - Default Address Selection for IPv6...............11
2.14 DNS........................................................11
3. IP Security.....................................................11
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication...12
3.2 RFC2401 - Security Architecture for the Internet Protocol..12
3.3 RFC2402 - IP Authentication Header.........................12
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH.........12
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH.........12
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With
Explicit IV......................................12
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)..........12
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP..........12
3.9 RFC2408 - The Internet Security Association and Key
Management Protocol..............................13
3.10 RFC2409 - The Internet Key Exchange (IKE)..................13
3.11 RFC2410 - The NULL Encryption Algorithm & its Use
With IPsec.......................................14
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms...............14
4. Mobility........................................................14
5. Security Considerations.........................................14
6. References......................................................16
6.1 Normative..................................................16
6.2 Informative................................................18
7. Contributors....................................................19
8. Acknowledgements................................................19
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model.......20
Authors' Addresses.................................................21
Full Copyright Statement...........................................221 Introduction 🦋
okay so GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System) and CDMA2000 (Code Division Multiple Access 2000) are making it possible for cellular hosts to be always-on 🔥 IPv6 becomes necessary because the number of these hosts is expected to grow super fast. The standards orgs working on cellular tech noticed this and are making IPv6 mandatory in their specs 💅
IPv6 support and the intro of UMTS kick off with 3GPP Release 99 networks and hosts. IPv6 is also the only IP version supported for IP Multimedia Subsystem (IMS) starting from Release 5 ✨
1.1 Scope of this Document 🧚
so for this doc, a cellular interface means an interface to a cellular access network based on these standards: 3GPP GPRS and UMTS Release 99, Release 4, Release 5, plus future UMTS releases. A cellular host is any host with that kind of cellular interface 📱
This doc lists IPv6 specs and talks about how to use them over cellular interfaces. That's needed so IPv6 can be used optimally in a cellular environment. It's written from the cellular host point of view. The goal is to avoid unnecessary user confusion over configuration options, make sure everything interoperates, and give implementers an easy reference for IPv6 in a cellular host. It's also necessary that cellular hosts are good citizens of the Internet 🫶
This doc is informational in nature. It isn't meant to replace, update, or contradict any IPv6 standards documents [RFC-2026] 💖
The main audience is implementers of cellular hosts that will be used with GPRS, 3GPP UMTS Release 99, Release 4, Release 5, or future UMTS releases. It gives guidance on which parts of IPv6 to implement in those hosts. Parts of this doc may also apply to other cellular link types, but nobody has done a detailed analysis for those yet, so that's future work 👀 This doc is not a definitive list of IPv6 functionality for cellular links other than the ones above. Future 3GPP network changes that need changes in host implementations may lead to updates to this doc 🌈
There are different ways to build a cellular host:
- A "closed 2G or 3G host" is super compact and has optimized apps, with no way to add or download apps that can do IP communications. A very simple mobile phone is an example 📞
- An "open 2G or 3G host" is also compact, but you can download apps, like a PDA-type phone 📲
If a cellular host has extra interfaces that use IP (like Ethernet, WLAN, Bluetooth, etc.), there may be extra requirements for the device, beyond what's in this doc 🙈 This doc also doesn't make any recommendations for laptops with a cellular interface, like a PC card, other than recommending link-specific behavior on the cellular link 💻
This doc discusses IPv6 functionality as specified when it was written. Ongoing IPv6 work may change what future hosts need. Also, other relevant work exists for other layers. Examples are the header compression work done in the IETF ROHC group, the analysis of how error-prone links affect performance in [RFC-3155], and the TCP work in [RFC-3481] 🍓
Transition mechanisms used by cellular hosts aren't described in this doc. They're left for further study 🦋
1.2 Abbreviations 📚
2G Second Generation Mobile Telecommunications, such as GSM and
GPRS technologies.
3G Third Generation Mobile Telecommunications, such as UMTS
technology.
3GPP 3rd Generation Partnership Project. Throughout the document,
the term 3GPP (3rd Generation Partnership Project) networks
refers to architectures standardized by 3GPP, in Second and
Third Generation releases: 99, 4, and 5, as well as future
releases.
AH Authentication Header
APN Access Point Name. The APN is a logical name referring to a
GGSN and an external network.
ESP Encapsulating Security Payload
ETSI European Telecommunications Standards Institute
IMS IP Multimedia Subsystem
GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6
cellular hosts)
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
IKE Internet Key Exchange
ISAKMP Internet Security Association and Key Management Protocol
MT Mobile Terminal, for example, a mobile phone handset.
MTU Maximum Transmission Unit
PDP Packet Data Protocol
SGSN Serving GPRS Support Node
TE Terminal Equipment, for example, a laptop attached through a
3GPP handset.
UMTS Universal Mobile Telecommunications System
WLAN Wireless Local Area Network1.3 Cellular Host IPv6 Features 🎀
this spec defines IPv6 features for cellular hosts in three groups:
- Basic IP: in this group, the basic parts of IPv6 are described 🧩
- IP Security: in this group, the IP Security parts are described 🔐
- Mobility: in this group, IP layer mobility issues are described 🌍
2 Basic IP 🧚
2.1 RFC1981 - Path MTU Discovery for IP Version 6 ✨
okay so Path MTU Discovery [RFC-1981] may be used 💅 Cellular hosts with a link MTU bigger than the minimum IPv6 link MTU (1280 octets) can use Path MTU Discovery to figure out the real path MTU 🦋 The IPv6 headers take up less of the packet this way because the packets are longer, so you get more out of the bandwidth 🌸
The IPv6 spec [RFC-2460] says in Section 5 that "a minimal IPv6 implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 1280 octets, and omit implementation of Path MTU Discovery." 🧚
If Path MTU Discovery is not implemented, the sending packet size is limited to 1280 octets (the standard limit in [RFC-2460]) 💀 But if that's the route, the cellular host must be able to receive packets up to the link MTU before reassembly. Why? The node on the other side of the link has no way of knowing that anything less than the MTU is accepted 🙈
2.2 RFC3513 - IP Version 6 Addressing Architecture 🌈
The IPv6 Addressing Architecture [RFC-3513] is a mandatory part of IPv6. Not optional, bestie 🫶
2.3 RFC2460 - Internet Protocol Version 6 💜
The Internet Protocol Version 6 is specified in [RFC-2460]. This specification is a mandatory part of IPv6 ✨
By definition, a cellular host acts as a host, not as a router. Requirements for a cellular router are not defined in this document, so we're not going there 🍓
So the cellular host must implement all non-router packet receive processing as described in RFC 2460. This includes generating ICMPv6 error reports and processing at least the following extension headers:
- Hop-by-Hop Options header: at least the Pad1 and PadN options
- Destination Options header: at least the Pad1 and PadN options
- Routing (Type 0) header: final destination (host) processing only
- Fragment header
- AH and ESP headers (see also a discussion on the use of IPsec for various purposes in Section 3)
- The No Next Header value
Unrecognized options in Hop-by-Hop Options or Destination Options extensions must be processed as described in RFC 2460 🔥
The cellular host must follow the packet transmission rules in RFC 2460 💅
The cellular host must always be able to receive and reassemble fragment headers. It will also need to be able to send a fragment header when it talks to an IPv4 host through a translator (see Section 5 of RFC2460) 🦋
Cellular hosts should only process routing headers when they're the final destination, and return errors if processing the routing header would require forwarding the packet to another node. This also keeps cellular hosts from being inappropriately used as relays or components in Denial-of-Service (DoS) attacks 😭 Acting as the destination looks like this: the cellular hosts must check the Segments Left field in the header, and proceed if it is zero or one and the next address is one of the host's addresses. If not, the host must implement error checks as specified in Section 4.4 of RFC 2460. And there is no need for the host to send Routing Headers 🌸
2.4 RFC2461 - Neighbor Discovery for IPv6 🎀
Neighbor Discovery is described in [RFC-2461]. This specification is a mandatory part of IPv6 ✨
2.4.1 Neighbor Discovery in 3GPP Networks 🛰️
A cellular host must support Neighbor Solicitation and Advertisement messages 💖
In GPRS and UMTS networks, some Neighbor Discovery messages can be unnecessary in certain cases. GPRS and UMTS links look a lot like a point-to-point link, so the cellular host's only neighbor on the cellular link is the default router, which is already known through Router Discovery. There are no link layer addresses, so address resolution and next-hop determination are not needed 🧚
The cellular host must support neighbor unreachability detection as specified in [RFC-2461] 💅
In GPRS and UMTS networks, bandwidth is precious, so it's very desirable to conserve it 🥺 That's why the cellular host should include a mechanism in upper layer protocols to provide reachability confirmation when two-way IP layer reachability can be confirmed (see RFC-2461, Section 7.3.1). These confirmations allow most NUD-related messages to be suppressed in most cases ✨
Host TCP implementation should provide reachability confirmation in the manner explained in RFC 2461, Section 7.3.1 🌈
Here's the tricky bit: the common use of UDP in 3GPP networks poses a problem for providing reachability confirmation, because UDP itself is unable to provide such confirmation 💀 So applications running over UDP should provide the confirmation where possible. Especially when UDP carries RTP, the RTCP protocol 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've reached the peer, they've also reached the neighbor 🫶
When UDP is used for transporting SIP, 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.5 RFC2462 - IPv6 Stateless Address Autoconfiguration 🦋
IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. This specification is a mandatory part of IPv6 ✨
2.5.1 Stateless Address Autoconfiguration in 3GPP Networks 🌸
A cellular host in a 3GPP network must process a Router Advertisement as stated in Section 2.4 💅
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero, because each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration 🔥 On top of that, the default router (GGSN) will not configure or assign to its interfaces any addresses based on prefixes delegated to IPv6 hosts. So the host is not required to perform Duplicate Address Detection on the cellular interface. No DAD drama 🙈
See Appendix A for more details on 3GPP IPv6 Stateless Address Autoconfiguration 🧚
2.6 RFC2463 - Internet Control Message Protocol for the IPv6 🌈
The Internet Control Message Protocol for the IPv6 is defined [RFC-2463]. This specification is a mandatory part of IPv6. Currently, this work is being updated 💖
As per RFC 2463 Section 2, ICMPv6 requirements must be fully implemented by every IPv6 node. See also Section 3 for an explanation of the use of IPsec for protecting ICMPv6 communications 🔒
2.7 RFC2472 - IP version 6 over PPP 🎀
IPv6 over PPP [RFC-2472] must be supported for cellular hosts that implement PPP 🍓
2.7.1 IP version 6 over PPP in 3GPP Networks 📱
A cellular host in a 3GPP network must support the IPv6CP interface identifier option. This option is needed so other devices can connect to the Internet using a PPP link between the cellular device (MT) and those 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, the MT must always reject other suggested interface identifiers by the TE. So the TE always ends up using the interface identifier suggested by the GGSN for its link-local address 👑
The rejection of interface identifiers suggested by the TE is only done for creating link-local addresses, according to 3GPP specifications. The use of privacy addresses [RFC-3041] for site-local and global addresses is not affected by the above procedure. This procedure is only concerned with assigning the interface identifier used for forming link-local addresses, and it does not preclude the TE from using other interface identifiers for addresses with larger scopes (i.e., site-local and global) 🌸
2.8 RFC2473 - Generic Packet Tunneling in IPv6 Specification 🦋
Generic Packet Tunneling [RFC-2473] may be supported if needed for transition mechanisms 🧚
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 💜
Multicast Listener Discovery [RFC-2710] must be supported by cellular hosts ✨
MLD requires that MLD messages be sent for link-local multicast addresses (excluding the all-nodes address). This requirement, that MLD runs even for link-local addresses, helps layer-two devices (e.g., Ethernet bridges) that try to suppress forwarding of link-layer multicast packets to parts of the layer-two network with no listeners. If MLD is used to announce the presence of listeners for all IP multicast addresses (including link-local multicast addresses), layer 2 devices can snoop MLD messages to reliably work out which parts of the network need IP multicast messages forwarded to them 🕸️
2.9.1 MLD in 3GPP Networks 🌈
Within 3GPP networks, hosts connect to their default routers (GGSN) via point-to-point links. There are exactly two IP devices on that point-to-point link, and no attempt is made (at the link-layer) to suppress the forwarding of multicast traffic. So sending MLD reports for link-local addresses in a 3GPP environment may not always be necessary 💅
MLD is needed for multicast group knowledge that is not link-local 💖
2.10 RFC2711 - IPv6 Router Alert Option 🚨
The Router Alert Option [RFC-2711] must be supported, and its use is required when MLD is used (see Section 2.9) or when RSVP [RFC-2205] is used 🔥
2.11 RFC3041 - Privacy Extensions for Address Configuration in IPv6 🙈
Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] should be supported. RFC 3041, and privacy in general, is important for the Internet 🫶 Cellular hosts may use the temporary addresses described in RFC 3041. However, using the Privacy Extension in an environment where IPv6 addresses are short-lived may not be necessary. At the time this document was written, there was no experience on how long-lived cellular network address assignments (i.e., attachments to the network) are. The length of the address assignments depends on many factors, such as radio coverage, device status and user preferences 📶 Additionally, using temporary addresses with IPsec may lead to more frequent renegotiation for the Security Associations 😵
Refer to Section 5 for a discussion of the benefits of privacy extensions in a 3GPP network 🌸
2.12 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 🍓
The Dynamic Host Configuration Protocol for IPv6 [DHCPv6] may be used. DHCPv6 is not required for address autoconfiguration when IPv6 stateless autoconfiguration is used. However, DHCPv6 may be useful for other configuration needs on a cellular host 🧚
2.13 RFC3484 - Default Address Selection for IPv6 👑
Default Address Selection [RFC-3484] is needed for cellular hosts 💅✨
2.14 DNS ✨
Okay bestie, cellular hosts SHOULD support DNS 🌸, as described in [RFC-1034], [RFC-1035], [RFC-1886], and [RFC-3152].
If DNS is used, a cellular host can make DNS requests in recursive mode, which limits signaling over the air interface 📡. Both the iterative and the recursive approach SHOULD be supported, though 🤔. The specs require implementing the iterative approach, and they only allow the recursive approach as an option. Also, not all DNS servers support recursive queries, so the security benefits of DNS Security can't always be reached with them 🙈.
3 IP Security 🔐
IPsec [RFC-2401] is a fundamental part of IPv6, and support for AH and ESP is described as mandatory in the specifications 💜.
The first part of this section talks about how useful IP Security and other security mechanisms are for common tasks on cellular hosts. The second part, Sections 3.1 to 3.13, lists the specs related to IPsec and explains how those parts of IPsec fit into a cellular setup 🧚.
Generally, whether you need a security mechanism depends on the app you're using it for ✨. Different mechanisms work in different contexts and have different limits. Some apps require TLS [RFC-2246], and in some situations IPsec gets used 💅.
Listing every possible service here isn't realistic, so app protocol specs are expected to say which security services they need 🎀. Heads up: cellular hosts that can download apps MUST be ready to provide enough security services for those apps, no matter what the initial set of apps on the host needs 🔥.
The following sections list specs related to the IPsec functionality and talk about how they apply in a cellular context 🦋. This discussion focuses on using IPsec. Some apps might need a different set of protocols, and this discussion doesn't apply to apps that use security services other than IPsec 🌈.
3.1 RFC2104 - HMAC: Keyed-Hashing for Message Authentication
This specification [RFC-2104] MUST be supported 🔥. RFC 2403 references it, and that one describes how IPsec protects the integrity of packets 🫶.
3.2 RFC2401 - Security Architecture for the Internet Protocol
This specification [RFC-2401] MUST be supported 💖.
3.3 RFC2402 - IP Authentication Header
This specification [RFC-2402] MUST be supported 💜.
3.4 RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
This specification [RFC-2403] MUST be supported ✨.
3.5 RFC2404 - The Use of HMAC-SHA-96 within ESP and AH
This specification [RFC-2404] MUST be supported 🌸.
3.6 RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
This specification [RFC-2405] MAY be supported 🤷. It is, however, RECOMMENDED that stronger algorithms than DES be used 🔐. Algorithms like AES are being worked on in the IPsec working group. These new algorithms are useful, and they SHOULD be supported as soon as their standardization is ready 🚀.
3.7 RFC2406 - IP Encapsulating Security Payload (ESP)
This specification [RFC-2406] MUST be supported 💅.
3.8 RFC2407 - The Internet IP Security DoI for ISAKMP
Automatic key management, [RFC-2408] and [RFC-2409], is not a mandatory part of the IP Security Architecture 🙃. But here's the tea: in cellular, a host's IP addresses can change dynamically 📱. So manually configured Security Associations aren't practical, because the newest host address would have to be updated in the peer's SA database too 😩.
Even so, it's not clear that every app would use IKE for key management 🤔. For example, hosts may use IPsec ESP [RFC-2406] to protect SIP signaling in the IMS [3GPP-ACC], but handle authentication and key management with another mechanism, like UMTS AKA (Authentication and Key Agreement) [UMTS-AKA] 🧚.
Several simplifying assumptions can probably be made in the cellular environment for the mandated parts of the IP Security DoI, ISAKMP, and IKE 💭. Working on those simplifications would be useful, but it's outside the scope of this document 📝.
3.9 RFC2408 - The Internet Security Association and Key Management Protocol
This specification [RFC-2408] is OPTIONAL according to the IPv6 specifications, but it may be necessary in some apps, as described in Section 3.8 🌈.
3.10 RFC2409 - The Internet Key Exchange (IKE)
This specification [RFC-2409] is OPTIONAL according to the IPv6 specifications, but it may be necessary in some apps, as described in Section 3.8 🌷.
Here's a plot twist 😭: interactions between ICMPv6 packets and IPsec policies can cause unexpected behavior for IKE-based SA negotiation, unless the implementations do some special handling 🙈.
ICMPv6 does a lot of jobs that, in IPv4, either didn't exist or were handled by lower layers 💫. For example, IPv6 does address resolution using an IP packet, the ICMPv6 Neighbor Solicitation message 📨. IPv4, on the other hand, uses an ARP message at a lower layer 🍓.
The IPsec architecture has a Security Policy Database that specifies which traffic gets protected, and how 🛡️. Writing policies that cover ICMPv6 traffic turns out to be not easy at all 😵💫. For instance, a simple policy that protects all traffic between two hosts on the same network would also trap address resolution messages 🪤. That leads to a mess where IKE can't set up a Security Association, because sending the IKE UDP packets would first require sending a Neighbor Solicitation Message, and that would require an SA already 🔁.
To avoid this problem, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages MUST NOT lead to the use of IKE-based SA negotiation 🚫. The Redirect message SHOULD NOT lead to the use of IKE-based SA negotiation 🙅♀️. Other ICMPv6 messages MAY use IKE-based SA negotiation, as desired in the Security Policy Data Base 🎀.
Note that all of this limits how useful IPsec is for protecting every ICMPv6 communication 😤. For example, it may not be possible to protect the ICMPv6 traffic between a cellular host and its next hop router. (That may be hard anyway, because you'd need a suitable public key infrastructure. Since roaming is allowed, that infrastructure would have to authenticate all hosts to all routers 🥲.)
3.11 RFC2410 - The NULL Encryption Algorithm & its Use With IPsec
This specification [RFC-2410] MUST be supported 💖.
3.12 RFC2451 - The ESP CBC-Mode Cipher Algorithms
This specification [RFC-2451] MUST be supported if encryption algorithms other than DES are implemented, e.g., CAST-128, RC5, IDEA, Blowfish, 3DES 🧁.
4. Mobility 🦋
For this document's purposes, IP mobility isn't relevant 🙌. When the Mobile IPv6 specification is approved, a future update to this document may address these issues, since Mobile IP may have some effects on all IPv6 hosts 🌍. Right now, movement of cellular hosts within 3GPP networks is handled by link layer mechanisms 📶.
5. Security Considerations 🚨
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 may open or close depending on what functionality is included and what isn't 😱. Some aspects of the cellular environment also make certain types of vulnerabilities more severe 💀. These issues are discussed:
- The suggested limitations (Section 2.3) on processing routing headers also limit exposure to DoS attacks through cellular hosts 🛑.
- IPv6 addressing privacy [RFC3041] MAY be used in cellular hosts 🕶️. Be aware, though, that in the 3GPP model, the network assigns new addresses to hosts in most cases when they roam, and typically also when a cellular host activates a PDP context 🔄. So 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, a GGSN's coverage area is expected to be very large compared to currently deployed default routers (no handovers between GGSNs are possible), so a cellular host can keep an address for a long time ⏳. That means IPv6 addressing privacy can add privacy while the host is on and in the same area 🧥. The privacy features can also make different transport sessions appear to come from different IP addresses 🎭. But it's not clear these extra efforts confuse potential observers any further, since they could still monitor just the network prefix part 👀.
- The use of security services like IPsec or TLS in the connection of typical applications on cellular hosts is discussed in Section 3, and recommendations are given there 📚.
- Section 3 also discusses under what conditions IPsec protection of things like ICMPv6 communications is possible 🔐.
- Airtime on cellular hosts is expensive 💸. In some cases, users get billed for the amount of data they transfer to and from their host 🧾. It's crucial for both the network and the users that airtime is used correctly and that no extra charges land on users because of misbehaving third parties 🙅. Cellular links also have limited capacity, so they may not be able to handle more traffic than what the user picked, like a multimedia call 📞. Extra traffic might mess with the service level the user experiences 😩. QoS mechanisms help with these problems to some extent, but DoS aspects still stand out in the cellular environment 🚩. Existing DoS attacks that use things like packet amplification could be way more damaging here 💥. How to protect against these attacks is still an area for further study 🔬. It's also often easy to fill the cellular link and the queues on both sides with extra or large packets 📦.
- In some service provider networks, you can buy a prepaid cellular subscription without showing personal identification 🪪. Attackers who want to stay unidentified could take advantage of this 🕵️♀️. Keep in mind that even though the user isn't identified, the equipment still is 📟. Operators can follow the identity of the device and block it from further use 🚫. Operators MUST have procedures in place to take notice of third party complaints about the use of their customers' devices 📣. It may also be necessary for operators to have attack detection tools that help them efficiently detect attacks launched from cellular hosts 🛠️.
- Cellular devices with local network interfaces (like IrDA or Bluetooth) may be used to launch attacks through them, unless those local interfaces are secured properly 🦷. So local network interfaces SHOULD have access control to stop others from using the cellular host as an intermediary 🔒.
6. References 📚
6.1. Normative
Okay, the normative refs are the ones you have to read to get the spec right, bestie 📚✨ Here they are:
[RFC-1035]Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.[RFC-1886]Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6, RFC 1886, December 1995.[RFC-1981]McCann, J., Mogul, J. and S. Deering, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.[RFC-2026]Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.[RFC-2104]Krawczyk, K., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[RFC-2246]Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.[RFC-2401]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[RFC-2402]Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.[RFC-2403]Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP and AH", RFC 2403, November 1998.[RFC-2404]Madson, C., and R. Glenn, "The Use of HMAC-SHA-1 within ESP and AH", RFC 2404, November 1998.[RFC-2405]Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.[RFC-2406]Kent, S. and R. Atkinson, "IP Encapsulating Security Protocol (ESP)", RFC 2406, November 1998.[RFC-2407]Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.[RFC-2408]Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.[RFC-2409]Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.[RFC-2410]Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.[RFC-2451]Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.[RFC-2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[RFC-2461]Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.[RFC-2462]Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.[RFC-2463]Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.[RFC-2473]Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.[RFC-2710]Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.[RFC-2711]Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.[RFC-2874]Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.[RFC-3041]Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.[RFC-3152]Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.[RFC-3155]Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.[RFC-3484]Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.[RFC-3513]Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
6.2. Informative
These ones are the extra-credit reading 🧚 Totally worth a peek if you want the full story:
[3GPP-ACC]3GPP Technical Specification 3GPP TS 33.203, "Technical Specification Group Services and System Aspects; 3G Security; Access security for IP-based services (Release 5)", 3rd Generation Partnership Project, March 2002.[3GPP-IMS]3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia (IM) Subsystem - Stage 2; (3G TS 23.228)[3GPP-IPv6]3rd Generation Partnership Project; Technical Specification Group Services and System Aspects "Architectural requirements" (TS 23.221)[DHCPv6]Bound, J., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in progress.[RFC-1034]Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.[RFC-2529]Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.[RFC-2205]Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.[RFC-3314]Wasserman, M., Editor, "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards, RFC 3314, September 2002.[RFC-3481]Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. Khafizov, "TCP over Second (2.5G) and Third (3G) Generation Wireless Networks", BCP 71, RFC 3481, February 2003.[UMTS-AKA]3GPP Technical Specification 3GPP TS 33.102, "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 4)", 3rd Generation Partnership Project, December 2001.
7. Contributors ✨
This doc came from a whole team, not just the authors! 🫶 Peter Hedman and Pertti Suomela helped out too. They wrote text AND brought their IPv6 experience to the table, so huge thanks to them 💜
8. Acknowledgements 🌸
The authors wanted to thank Jim Bound, Brian Carpenter, Steve Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark, Michael Thomas, Margaret Wasserman and everyone else on the IPv6 WG mailing list for their comments and input. Iconic behavior, honestly 👑
They also wanted 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 prepared. Literally the whole squad 🦋
Appendix A - Cellular Host IPv6 Addressing in the 3GPP Model 📱
Okay so this appendix is a quick tour of how the 3GPP folks handle IPv6 addresses for phones 📱✨ It covers 2G (GPRS) and 3G (UMTS) cellular networks from Release 99 onwards. If you want the deep dive, go read 3GPP Technical Specification 23.060.
There are two ways to give an IPv6 node its address: stateless and stateful autoconfiguration. Stateful needs a DHCP server to hand out the address. Stateless autoconfiguration doesn't need any outside entity involved in the address setup (other than the GGSN) 🌈
Now, to support the standard IPv6 stateless address autoconfiguration (the kind the IETF recommends), the GGSN shall assign a prefix that is unique within its scope to each primary PDP context that uses IPv6 stateless address autoconfiguration. This way nobody has to do Duplicate Address Detection at the network level for every address the mobile host builds. The GGSN always gives the mobile host an Interface Identifier, and the mobile host uses that Interface Identifier to generate its link-local address. The GGSN usually picks the Interface Identifier in a random manner. It must make sure that identifier is unique on the link, meaning no collisions between its own link-local address and the cellular host's 🔥
Also, the GGSN will not use any of the prefixes assigned to cellular hosts to generate any of its own addresses. Put that together with each PDP context getting its own unique prefix, and you don't need DAD messages going over the air interface, which means efficient use of bandwidth 💅 Giving each PDP context a prefix also lets hosts use the privacy extensions in RFC 3041 without needing any extra DAD messages 🔒
Authors' Addresses 📮
Here are the authors and how to reach them 💌
Jari Arkko
Ericsson
02420 Jorvas
Finland
EMail: jari.arkko@ericsson.com
Gerben Kuijpers
Ericsson
Skanderborgvej 232
DK-8260 Viby J
Denmark
EMail: gerben.a.kuijpers@ted.ericsson.se
John Loughney
Nokia Research Center
Itamerenkatu 11 - 13
FIN-00180 HELSINKI
Finland
EMail: john.loughney@nokia.com
Hesham Soliman
Ericsson Radio Systems AB
Torshamnsgatan 23, Kista, Stockholm
Sweden
EMail: hesham.soliman@era.ericsson.se
Juha Wiljakka
Nokia Mobile Phones
Sinitaival 5
FIN-33720 TAMPERE
Finland
EMail: juha.wiljakka@nokia.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2003). 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. Thank you to them for keeping the RFC lights on ✨
📦 where this page comes from
- ietf: rfc3316 2003-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms