diff options
Diffstat (limited to 'doc/rfc/rfc7066.txt')
| -rw-r--r-- | doc/rfc/rfc7066.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc7066.txt b/doc/rfc/rfc7066.txt new file mode 100644 index 0000000..a367ed8 --- /dev/null +++ b/doc/rfc/rfc7066.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Korhonen, Ed. +Request for Comments: 7066 Broadcom +Obsoletes: 3316 J. Arkko, Ed. +Category: Informational Ericsson +ISSN: 2070-1721 T. Savolainen + Nokia + S. Krishnan + Ericsson + November 2013 + + + IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts + +Abstract + + As the deployment of third and fourth generation cellular networks + progresses, a large number of cellular hosts are being connected to + the Internet. Standardization organizations have made the Internet + Protocol version 6 (IPv6) mandatory in their specifications. + However, the concept of IPv6 covers many aspects and numerous + specifications. In addition, the characteristics of cellular links + in terms of bandwidth, cost, and delay put special requirements on + how IPv6 is used. This document considers IPv6 for cellular hosts + that attach to the General Packet Radio Service (GPRS), Universal + Mobile Telecommunications System (UMTS), or Evolved Packet System + (EPS) networks (hereafter collectively referred to as Third + Generation Partnership Project (3GPP) networks). This document also + lists specific IPv6 functionalities that need to be implemented in + addition to what is already prescribed in the IPv6 Node Requirements + document (RFC 6434). It also discusses some issues related to the + use of these components when operating in these networks. This + document obsoletes RFC 3316. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7066. + + + +Korhonen, et al. Informational [Page 1] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + + + + + + + + +Korhonen, et al. Informational [Page 2] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +1. Introduction + + Technologies such as GPRS (General Packet Radio Service), UMTS + (Universal Mobile Telecommunications System), Evolved Packet System + (EPS), CDMA2000 (Code Division Multiple Access 2000), and eHRPD + (Enhanced High Rate Packet Data) are making it possible for cellular + hosts to have an always-on connection to the Internet. IPv6 + [RFC2460] has become essential to such networks as the number of + cellular hosts is increasing rapidly. Standardization organizations + working with cellular technologies have recognized this and made IPv6 + mandatory in their specifications. + + Support for IPv6 and the introduction of UMTS started with 3GPP + Release-99 networks and hosts. For a detailed description of IPv6 in + 3GPP networks, including the Evolved Packet System, see [RFC6459]. + +1.1. Scope of This Document + + For the purpose of this document, a cellular interface is considered + to be the interface to a cellular access network based on the + following standards: 3GPP GPRS and UMTS Release-99 and Release-4 to + Release-11; EPS Release-8 to Release-11; and future UMTS or EPS + releases. A cellular host is considered to be a host with such a + cellular interface. + + This document complements the IPv6 Node Requirements [RFC6434] in + places where clarifications are needed with discussion on the use of + these selected IPv6 specifications when operating over a cellular + interface. Such a specification is necessary in order to enable the + optimal use of IPv6 in a cellular network environment. The + description is made from the point of view of a cellular host. + Complementary access technologies may be supported by the cellular + host, but those are not discussed in detail. Important + considerations are given in order to eliminate unnecessary user + confusion over configuration options, ensure interoperability, and + provide an easy reference for those who are implementing IPv6 in a + cellular host. It is necessary to ensure that cellular hosts are + good citizens of the Internet. + + This document is informational in its nature, and it is not intended + to replace, update, or contradict any IPv6 standards documents or the + IPv6 Node Requirements [RFC6434]. + + This document is primarily targeted to the implementers of cellular + hosts that will be used with the cellular networks listed in this + document. This document provides guidance on which IPv6-related + specifications are to be implemented in such cellular hosts. Parts + of this document may also apply to other cellular link types, but + + + +Korhonen, et al. Informational [Page 3] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + this document does not provide any detailed analysis on other link + types. This document should not be used as a definitive list of IPv6 + functionalities for cellular links other than those listed above. + Future changes in 3GPP networks that impact host implementations may + result in updates to this document. + + There are different ways to implement cellular hosts: + + o The host can be a "closed" device with optimized built-in + applications, with no possibility to add or download applications + that can have IP communications. An example of such a host is a + very simple form of a mobile phone. + + o The host can be an open device, e.g., a "smart phone" where it is + possible to download applications to expand the functionality of + the device. + + o The cellular radio modem part can be separated from the host IP + stack with an interface. One example of such a host is a laptop + computer that uses a USB cellular modem for cellular access. + + If a cellular host has additional IP-capable interfaces (such as + Ethernet, WLAN, Bluetooth, etc.), then there may be additional + requirements for the device, beyond what is discussed in this + document. Additionally, this document does not make any + recommendations on the functionality required on laptop computers + having a cellular interface such as an embedded modem or a USB modem + stick, other than recommending link-specific behavior on the cellular + link. + + This document discusses IPv6 functionality as of the time when this + document was written. Ongoing work on IPv6 may affect what is + required of future hosts. + + Transition mechanisms used by cellular hosts are not in the scope of + this document and are left for further study. The primary transition + mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack- + capable bearer support has been added to GPRS starting from 3GPP + Release-9 and to EPS starting from Release-8 [RFC6459], whereas the + earlier 3GPP releases required multiple single IP version bearers to + support dual-stack. + + + + + + + + + + +Korhonen, et al. Informational [Page 4] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +1.2. Abbreviations + + 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. + + + + + +Korhonen, et al. Informational [Page 5] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +1.3. Cellular Host IPv6 Features + + This document lists IPv6 features for cellular hosts; these features + are split into three groups and are discussed below. + + Basic IP + + In this group, the basic IPv6 features essential for cellular + hosts are listed and described. + + IP Security + + In this group, the parts related to IP Security are described. + + Mobility + + In this group, IP-layer mobility issues are described. + +2. Basic IP + + For most parts, refer to the IPv6 Node Requirements document + [RFC6434]. + +2.1. Internet Protocol Version 6 + + The Internet Protocol version 6 (IPv6) is specified in [RFC2460]. + This specification is a mandatory part of IPv6. A cellular host must + conform to the generic IPv6 host requirements [RFC6434], unless + specifically pointed out otherwise in this document. + +2.2. Neighbor Discovery in 3GPP Networks + + A cellular host must support Neighbor Solicitation and Neighbor + Advertisement messages [RFC4861]. Some further notes on how Neighbor + Discovery is applied in the particular type of an interface can be + useful. + + In 3GPP networks, some Neighbor Discovery messages can be unnecessary + in certain cases. GPRS, UMTS, and EPS links resemble a point-to- + point link; hence, the cellular host's only neighbor on the cellular + link is the default router that is 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 to do address + + + +Korhonen, et al. Informational [Page 6] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + resolution, e.g., for the default router, it must 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 as 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]. Note that the link-layer address + considerations above also apply to NUD. The NUD-triggered Neighbor + Advertisement is also unlikely to contain the Target link-layer + address option as 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. Therefore, 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. As 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. If they have reached the peer, they have 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. + + + + + +Korhonen, et al. Informational [Page 7] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +2.3. Stateless Address Autoconfiguration + + IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. + This specification is a mandatory part of IPv6 and also the only + mandatory method to configure an IPv6 address in a 3GPP cellular + host. + + 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 the forward compatibility in mind, + there is no reason for the 3GPP cellular host to have 3GPP-specific + handling of the prefix information option(s) although 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 can set DupAddrDetectTransmits equal to zero, + as each assigned prefix is unique within its scope when advertised + using 3GPP IPv6 Stateless Address Autoconfiguration. In addition, + the default router (GGSN/PGW) will not configure any addresses on its + interfaces based on prefixes advertised to IPv6 cellular hosts on + those interfaces. Thus, 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. Thus, 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 + + + +Korhonen, et al. Informational [Page 8] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + 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 + + + + + +Korhonen, et al. Informational [Page 9] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + 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. + + + + + + + + + + + + + +Korhonen, et al. Informational [Page 10] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +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 + + The authors would like to thank the original authors for their + groundwork for this document: Gerben Kuijpers, John Loughney, Hesham + Soliman, and Juha Wiljakka. + + The original [RFC3316] document was based on the results of a team + that included Peter Hedman and Pertti Suomela in addition to the + authors. Peter and Pertti have contributed both text and their IPv6 + experience to this document. + + The authors would like to 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 would also like 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 in preparation of + this document. + + + + + + +Korhonen, et al. Informational [Page 11] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + For this revised version of [RFC3316] the authors would like to 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 + + This document does not specify any new protocols or functionalities, + and as such, it does not introduce any new security vulnerabilities. + However, specific profiles of IPv6 functionality are proposed for + different situations, and vulnerabilities may open or close depending + on which functionality is included and what is not. There are also + aspects of the cellular environment that make certain types of + vulnerabilities more severe. The following issues are discussed: + + o The suggested limitations (Section 3.1) in the processing of + extension headers also limits exposure to Denial-of-Service (DoS) + attacks through cellular hosts. + + o IPv6 addressing privacy [RFC4941] or similar technology may be + used in cellular hosts. However, 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 that 3GPP networks + will 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 when compared to currently deployed default routers + (no handovers between GGSN/PGWs are possible), a cellular host can + keep a prefix for a long time. Hence, 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 additional efforts + confuse potential observers any further, as they could monitor + only the network prefix part. + + o The use and recommendations of various security services such as + IPsec or Transport Layer Security (TLS) [RFC5246] in the + connection of typical applications that also apply to cellular + hosts are discussed in Section 11 of [RFC6434]. + + + + + + +Korhonen, et al. Informational [Page 12] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + o 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 the airtime is used correctly and no extra charges are + applied to users due to misbehaving third parties. The cellular + links also have a limited capacity, which means that 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 experienced by the user. While + Quality-of-Service mechanisms mitigate these problems to an + extent, it is still apparent that DoS aspects may be highlighted + in the cellular environment. It is possible for existing DoS + attacks that use, for instance, packet amplification, to be + substantially more damaging in this environment. How these + attacks can be protected against is still an area for further + study. It is also often easy to fill the cellular link and queues + on both sides with additional or large packets. + + o Within some service provider networks, it is possible to buy a + prepaid cellular subscription without presenting personal + identification. Attackers that wish to remain unidentified could + leverage this. Note that while the user hasn't been identified, + the equipment still is; the 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 the operators to have attack detection tools that + enable them to efficiently detect attacks launched from the + cellular hosts. + + o 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. + + o The 3GPP link model mitigates most of the known IPv6 on-link and + neighbor cache targeted attacks (see Section 2.2 and Appendix A). + + o Advice for implementations in the face of Neighbor Discovery DoS + attacks may be useful in some environments [RFC6583]. + + o Section 9 of [RFC6459] further discusses some recent concerns + related to the security of cellular hosts. + + + + + + + +Korhonen, et al. Informational [Page 13] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +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. + + + + + + + + + + + + + + +Korhonen, et al. Informational [Page 14] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 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. + + + +Korhonen, et al. Informational [Page 15] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + +Korhonen, et al. Informational [Page 16] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model + + This appendix aims to very briefly describe the 3GPP IPv6 addressing + model for 2G (GPRS), 3G (UMTS), and 4G (EPS) cellular networks from + Release-99 onwards. More information for 2G and 3G can be found in + 3GPP Technical Specifications [TS.23060] and [TS.29061]. The + equivalent documentation for 4G can be found in 3GPP Technical + Specifications [TS.23401], [TS.23402], and [TS.29061]. + + There are two possibilities to allocate the address for an IPv6 node: + stateless and stateful autoconfiguration. The stateful address + allocation mechanism needs a DHCP server to allocate the address for + the IPv6 node. On the other hand, the Stateless Address + Autoconfiguration procedure does not need any external entity + involved in the address autoconfiguration (apart from the GGSN/PGW). + At the time of writing this document, the IPv6 Stateless Address + Autoconfiguration mechanism is still the only mandatory and supported + address configuration method for the cellular 3GPP link. + + In order to support the standard IPv6 Stateless Address + Autoconfiguration mechanism as recommended by the IETF, 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 IPv6 + Stateless Address Autoconfiguration. This avoids the necessity to + perform Duplicate Address Detection (DAD) at the network level for + any address built by the mobile host. The GGSN/PGW always provides + an interface identifier to the mobile host. The mobile host uses the + interface identifier provided by the GGSN/PGW to generate its link- + local address. The GGSN/PGW provides the cellular host with the + interface identifier, usually in a random manner. It must ensure the + uniqueness of such an identifier on the link (i.e., no collisions + between its own link-local address and the cellular host's). + + In addition, the GGSN/PGW will not use any of the prefixes assigned + to cellular hosts to generate any of its own addresses. This use of + the interface identifier, combined with the fact that each PDP + Context or PDN Connection is allocated a unique prefix, will + eliminate the need for DAD messages over the air interface and + consequently reduces inefficient use of radio resources. + Furthermore, the allocation of a prefix to each PDP Context or PDN + Connection will allow hosts to implement the Privacy Extensions in + [RFC4941] without the need for further DAD messages. + + In practice, the GGSN/PGW only needs to route all traffic destined to + the cellular host that falls under the prefix assigned to it. This + implies the GGSN/PGW may implement a minimal Neighbor Discovery + protocol subset since, due to the point-to-point link model and the + absence of link-layer addressing, the address resolution can be + + + +Korhonen, et al. Informational [Page 17] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + entirely statically configured per PDP Context or PDN Connection, and + there is no need to defend any addresses other than the link-local + addresses for very unlikely duplicates. This also has an additional + effect on a router-to-host NUD. There is really no need for the NUD, + since from the point of view of GGSN/PGW, GGSN/PGW does not need to + care for a single address but just routes the whole prefix to the + cellular host. However, the cellular host must be prepared for the + unlikely event of receiving a NUD against its link-local address. It + should be noted that the 3GPP specifications at the time of writing + this document 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. + +Appendix B. Changes from RFC 3316 + + o Clarified that [RFC4941] or similar technologies may be used for + privacy purposes (as stated in [RFC6459]). + + o 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). + + o 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). + + o Clarified that a cellular host should not do any changes in its + stack to meet the infinite prefix lifetime requirement the 3GPP + link has. + + o Clarified that the prefix lifetime is tied to the PDP Context/PDN + Connection lifetime. + + o Clarified explicitly that a NUD from the gateway side to the User + Equipment's link-local address is possible. + + o Added references to 3GPP specifications. + + o Provided additional clarification on NUD on 3GPP cellular links. + + o Added an explicit note that the prefix on the link is /64. + + o Clarified that DHCPv6 ([RFC3315]) is not used at all for address + autoconfiguration. + + o Removed all sections that can be directly found in [RFC6434]. + + + +Korhonen, et al. Informational [Page 18] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + + o Added clarifications to 3GPP link model and how Neighbor Discovery + works on it. + + o Added [RFC4191] recommendations. + + o Added DHCPv6-based Prefix Delegation recommendations. + + o Added [RFC6106] recommendations. + + o Added reference to [RFC5555] regarding client-based mobility. + + o Added text regarding Router Advertisement MTU option handling. + + o Added Evolved Packet System text. + + o Added clarification on the primary 3GPP IPv6 transition mechanism. + + o Added reference to [RFC5095], which deprecates the RH0. + + o Added references to [RFC5722] and [RFC6980] regarding IPv6 + fragmentation handling. + + o Added reference to [RFC6583] for Neighbor Discovery denial-of- + service attack considerations. + + o Made the PPP IPV6CP [RFC5072] support text conditional. + + + + + + + + + + + + + + + + + + + + + + + + + +Korhonen, et al. Informational [Page 19] + +RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + + + +Korhonen, et al. Informational [Page 20] + |