--- 1/draft-ietf-v6ops-mobile-device-profile-15.txt 2015-02-01 23:14:54.987621949 -0800 +++ 2/draft-ietf-v6ops-mobile-device-profile-16.txt 2015-02-01 23:14:55.027622923 -0800 @@ -1,56 +1,56 @@ V6OPS Working Group D. Binet Internet-Draft M. Boucadair Intended status: Informational France Telecom -Expires: July 16, 2015 A. Vizdal +Expires: August 5, 2015 A. Vizdal Deutsche Telekom AG G. Chen China Mobile N. Heatley EE R. Chandler eircom | meteor - January 12, 2015 + February 1, 2015 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices - draft-ietf-v6ops-mobile-device-profile-15 + draft-ietf-v6ops-mobile-device-profile-16 Abstract This document defines a profile that is a superset of that of the connection to IPv6 cellular networks defined in the IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts document. This - document identifies features to deliver IPv4 connectivity service - over an IPv6-only transport as well as the required features to - connect 3GPP mobile devices to an IPv6-only or dual-stack wireless - network (including 3GPP cellular network and IEEE 802.11 network). + document defines an IPv6 profile that a number of operators recommend + in order to connect 3GPP mobile devices to an IPv6-only or dual-stack + wireless network (including 3GPP cellular network and IEEE 802.11 + network). Both hosts and devices with capability to share their WAN (Wide Area Network) connectivity are in scope. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 July 16, 2015. + This Internet-Draft will expire on August 5, 2015. Copyright Notice Copyright (c) 2015 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 @@ -59,38 +59,38 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 - 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 7 + 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 8 4. Recommendations for Cellular Devices with LAN Capabilities . 10 5. APIs & Applications Recommendations . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15 1. Introduction IPv6 deployment in 3GPP mobile networks is the only perennial solution to the exhaustion of IPv4 addresses in those networks. Several mobile operators have already deployed IPv6 [RFC2460] or are - in the pre-deployment phase. One of the major hurdles encountered by - mobile operators is the availability of non-broken IPv6 + in the pre-deployment phase. One of the major hurdles as perceived + by some mobile operators is the availability of non-broken IPv6 implementation in mobile devices. [RFC7066] lists a set of features to be supported by cellular hosts to connect to 3GPP mobile networks. In the light of recent IPv6 production deployments, additional features to facilitate IPv6-only deployments while accessing IPv4-only service are to be considered. This document defines an IPv6 profile for mobile devices listing specifications produced by various Standards Developing Organizations (in particular 3GPP and IETF). The objectives of this effort are: @@ -190,20 +190,27 @@ Delegation compared to [RFC7066]. The main motivation is that cellular networks are more and more perceived as an alternative to fixed networks for home IP-based services delivery; especially with the advent of smartphones and 3GPP data dongles. There is a need for an efficient mechanism to assign shorter prefix than /64 to cellular hosts so that each LAN segment can get its own /64 prefix and multi- link subnet issues to be avoided. The support of this functionality in both cellular and fixed networks is key for fixed-mobile convergence. + This document is not a standard, and conformance with it is not + required in order to claim conformance with IETF standards for IPv6. + The support of the full set of features may not be required in some + deployment contexts. The authors believe that the support of a + subset of the features included in this protocol may lead to degraded + level of service in some deployment contexts. + 2. Connectivity Recommendations This section identifies the main connectivity recommendations to be followed by a cellular host to attach to a network using IPv6. Both dual-stack and IPv6-only deployment models are considered. IPv4 service continuity features are listed in this section because these are critical for Operators with an IPv6-only deployment model. C_REC#1: In order to allow each operator to select their own strategy regarding IPv6 introduction, the cellular host @@ -476,31 +482,32 @@ (GGSN/PGW) will have to ensure [RFC3633] compliancy (e.g., halving the delegated prefix and assigning the WAN prefix out of the 1st half and the prefix to be delegated to the terminal from the 2nd half). Because Prefix Delegation capabilities may not be available in some attached networks, L_REC#3 is strongly recommended to accommodate early deployments. L_REC#2: The cellular CPE must be compliant with the requirements - specified in [RFC6204]. + specified in [RFC7084]. There are several deployments, particularly in emerging countries, that relies on mobile networks to provide broadband services (e.g., customers are provided with mobile CPEs). - Note, even if RFC7084 obsoletes [RFC6204], this profile - does not require RFC7084 because IPv4 service continuity - techniques used in mobile networks are not the same as - in fixed networks. + Note, this profile does not require IPv4 service + continuity techniques listed in [RFC7084] because those + are specific to fixed networks. IPv4 service continuity + techniques specific to the mobile networks are included + in this profile. L_REC#3: For deployments requiring to share the same /64 prefix, the cellular device should support [RFC7278] to enable sharing a /64 prefix between the 3GPP interface towards the GGSN/ PGW (WAN interface) and the LAN interfaces. Prefix Delegation (refer to L_REC#1) is the target solution for distributing prefixes in the LAN side but, because the device may attach to earlier 3GPP release networks, a mean to share a /64 prefix is also @@ -558,30 +565,39 @@ In particular, the cellular host must support [RFC3596]. APP_REC#2: Applications provided by the mobile device vendor must be independent of the underlying IP address family. This means applications must be IP version agnostic. APP_REC#3: Applications provided by the mobile device vendor that use Uniform Resource Identifiers (URIs) must follow - [RFC3986]. For example, SIP applications must follow the - correction defined in [RFC5954]. + [RFC3986] and its updates. For example, SIP applications + must follow the correction defined in [RFC5954]. 6. Security Considerations The security considerations identified in [RFC7066] and [RFC6459] are to be taken into account. - Security-related considerations that apply when the cellular device - provides LAN features are specified in [RFC6092]. + In the case of cellular devices that provide LAN features, compliance + with L_REC#2 entails compliance with [RFC7084], which in turn + recommends compliance with Recommended Simple Security Capabilities + in Customer Premises Equipment (CPE) for Providing Residential IPv6 + Internet Service [RFC6092]. Therefore, the security considerations + in Section 6 of [RFC6092] are relevant. In particular, it bears + repeating here that the true impact of stateful filtering may be a + reduction in security, and that IETF make no statement, expressed or + implied, as to whether using the capabilities described in any of + these documents ultimately improves security for any individual users + or for the Internet community as a whole. The cellular host must be able to generate IPv6 addresses which preserve privacy. The activation of privacy extension (e.g., using [RFC7217]) makes it more difficult to track a host over time when compared to using a permanent Interface Identifier. Tracking a host is still possible based on the first 64 bits of the IPv6 address. Means to prevent against such tracking issues may be enabled in the network side. Note, privacy extensions are required by regulatory bodies in some countries. @@ -589,22 +605,23 @@ Section 3). 7. IANA Considerations This document does not require any action from IANA. 8. Acknowledgements Many thanks to C. Byrne, H. Soliman, H. Singh, L. Colliti, T. Lemon, B. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. - Kuarsingh, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, and T. - Kossut for the discussion in the v6ops mailing list. + + Kuarsingh, E. Kline, S. Josefsson, A. Baryun, J. Woodyatt, T. + Kossut, and B. Stark for the discussion in the v6ops mailing list. Thanks to A. Farrel, B. Haberman and K. Moriarty for the comments during the IESG review. Special thanks to T. Savolainen, J. Korhonen, J. Jaeggli, and F. Baker for their detailed reviews and comments. 9. References 9.1. Normative References @@ -702,24 +719,20 @@ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. - [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. - Troan, "Basic Requirements for IPv6 Customer Edge - Routers", RFC 6204, April 2011. - [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011. [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. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. @@ -737,20 +750,24 @@ 2013. [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013. [RFC7051] Korhonen, J. and T. Savolainen, "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, November 2013. + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + November 2013. + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, April 2014. [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, May 2014. [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, June