--- 1/draft-ietf-v6ops-rfc3316bis-00.txt 2013-02-25 15:31:09.451709256 +0100 +++ 2/draft-ietf-v6ops-rfc3316bis-01.txt 2013-02-25 15:31:09.483708965 +0100 @@ -1,23 +1,23 @@ IPv6 Operations (V6OPS) J. Korhonen, Ed. -Internet-Draft Nokia Siemens Networks +Internet-Draft Renesas Mobile Obsoletes: 3316 (if approved) J. Arkko, Ed. Intended status: Informational Ericsson -Expires: May 16, 2013 T. Savolainen +Expires: August 29, 2013 T. Savolainen Nokia S. Krishnan Ericsson - November 12, 2012 + February 25, 2013 IPv6 for 3GPP Cellular Hosts - draft-ietf-v6ops-rfc3316bis-00.txt + draft-ietf-v6ops-rfc3316bis-01.txt 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 are making 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 @@ -38,25 +38,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 16, 2013. + This Internet-Draft will expire on August 29, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + 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 @@ -68,37 +68,38 @@ 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Cellular Host IPv6 Features . . . . . . . . . . . . . . . 6 2. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Internet Protocol Version 6 . . . . . . . . . . . . . . . 7 2.2. Neighbor Discovery in 3GPP Networks . . . . . . . . . . . 7 2.3. IPv6 Stateless Address Autoconfiguration . . . . . . . . . 8 2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8 2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9 2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9 - 2.7. Privacy Extensions for Address Configuration in IPv6 . . . 9 + 2.7. Privacy Extensions for Address Configuration in IPv6 . . . 10 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10 2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10 2.10. Router preferences and more specific routes . . . . . . . 10 - 2.11. Neighbor Discovery and additional host configuration . . . 10 + 2.11. Neighbor Discovery and additional host configuration . . . 11 3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Extension header considerations . . . . . . . . . . . . . 11 4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative references . . . . . . . . . . . . . . . . . . . 14 - 8.2. Informative references . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative references . . . . . . . . . . . . . . . . . . 15 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15 - Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 16 - B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 16 + Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17 + B.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 17 + B.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 such @@ -264,24 +265,27 @@ There are no link layer addresses. Therefore, address resolution and next-hop determination are not needed. If the cellular host still attempts the address 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. The cellular host must support Neighbor Unreachability Detection (NUD) as specified in [RFC4861]. Note that the link-layer address - considerations above also apply to the Neighbor Unreachability - Detection. The NUD triggered Neighbor Advertisement is also unlikely - to contain the Target link-layer address option as there are no link- - layer addresses. + considerations above also apply to the 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 a router (i.e., GGSN/PGW) + initiated NUD. However, it is unlikely a router to host NUD should + ever take place on a GPRS, UMTS and EPS links. See Appendix A for + more discussion on the router to host NUD. In GPRS, UMTS and EPS networks, it is very 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. @@ -387,29 +391,29 @@ assignments depends upon many factors such as radio coverage, device status and user preferences. Additionally, the use of temporary address with IPsec may lead to more frequent renegotiation for the Security Associations. Refer to Section 7 for a discussion of the benefits of privacy extensions in a 3GPP network. 2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] - may be used. As of 3GPP Release-11 DHCPv6 is neither required nor - supported for address autoconfiguration. The IPv6 stateless - 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 non-cellular links. + As of 3GPP Release-11 The Dynamic Host Configuration Protocol for + IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address + autoconfiguration. The IPv6 stateless 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.9. 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 for 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 @@ -500,30 +504,30 @@ 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 limits also exposure to Denial-of-Service (DoS) attacks through cellular hosts. o IPv6 addressing privacy [RFC4941] may be used in cellular hosts. However, it should be noted that in the 3GPP model, the network would assign new addresses, in most cases, to hosts in roaming situations and typically, also when the cellular hosts activate a - PDP context. 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's coverage area is expected to be very large when - compared to currently deployed default routers (no handovers - between GGSNs are possible), a cellular host can keep an address - 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 + PDP Context or a PDN Connection. 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's coverage area is expected to be + very large when compared to currently deployed default routers (no + handovers between GGSNs are possible), a cellular host can keep an + address 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 of various security services such as IPsec or TLS in the connection of typical applications in cellular hosts is discussed in Section 3 and further pointer for recommendations are given there. 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 @@ -562,24 +567,24 @@ o Advice for implementations in the face of Neighbor Discovery DoS attacks may be useful in some environments [RFC6583]. o Section 9 of RFC 6459 discusses further some recent concerns related to cellular hosts security. 8. References 8.1. Normative references [I-D.ietf-6man-nd-extension-headers] - Gont, F., "Security Implications of the Use of IPv6 - Extension Headers with IPv6 Neighbor Discovery", - draft-ietf-6man-nd-extension-headers-00 (work in - progress), June 2012. + Gont, F., "Security Implications of IPv6 Fragmentation + with IPv6 Neighbor Discovery", + draft-ietf-6man-nd-extension-headers-03 (work in + progress), January 2013. [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. @@ -651,67 +656,79 @@ documentation for 4G can be found from 3GPP Technical Specifications 23.401, 23.402 and 29.061. 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 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 madatory and supported address configuration method - for the cellular 3GPP link. + 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 prefix that is unique within its scope to each primary - PDP context that uses IPv6 stateless address autoconfiguration. This - avoids the necessity to perform Duplicate Address Detection (DAD) at - the network level for every 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 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 identifier on the link (i.e., no - collisions between its own link-local address and the cellular - host's). + 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 + every 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 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 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 will allow hosts to implement the privacy extensions in RFC 4941 without the need for further DAD messages. In practice, the GGSN/PGW only needs to route all traffic to the cellular host that fall under the prefix assigned to it. This implies the GGSN/PGW may implement a minimal neighbor discovery protocol subset; since, due the point-to-point link model and the absence of link-layer addressing the address resolution can be entirely statically configured per PDP Context or PDN Connection, and there is no need to defend any other address than the link-local - address for very unlikely duplicates. + address for very unlikely duplicates. This has also an additional + effect on a router to host NUD. There is really no need for one, + since from the GGSN/PGW point of view it does not need to care for + single addresses, just route the whole prefix to the cellular host + direction. Furthermore, 3GPP specifications at the time of writing + this document are silent what should happen if the router to host NUD + fails. See Sections 5 of RFC 6459 for further discussion on 3GPP address allocation and link model. Appendix B. Changes to RFC 3316 -B.1. Version -00 +B.1. Version -01 + + o 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. + +B.2. Version -00 o Removal of all sections that can be directly found from RFC 6434. o Clarifications to 3GPP link model and how Neighbor Discovery works on it. - o Addition of RFC 4191 recommendations. o Addition of DHCPv6-based Prefix Delegation recommendations. o Addition of RFC 6106 recommendations. o Addition of RFC 5555 regarding client based mobility. o Addition of Router Advertisement MTU option handling. o Addition of Evolved Packet System text. o Clarification on the primary 3GPP IPv6 transition mechanism. o Addition of RFC 5095 that deprecates the RH0 o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers regarding the IPv6 fragmentation handling. @@ -715,27 +732,26 @@ o Addition of RFC 5095 that deprecates the RH0 o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers regarding the IPv6 fragmentation handling. o Addition of RFC 6583 for Neighbor Discovery denial-of-service attack considerations. o Made the PPP IPV6CP support text conditional. Authors' Addresses Jouni Korhonen (editor) - Nokia Siemens Networks - Linnoitustie 6 - FIN-02600 Espoo + Renesas Mobile + 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