--- 1/draft-ietf-v6ops-mobile-device-profile-11.txt 2014-09-17 23:19:54.501386031 -0700 +++ 2/draft-ietf-v6ops-mobile-device-profile-12.txt 2014-09-17 23:19:54.597388342 -0700 @@ -1,26 +1,26 @@ V6OPS Working Group D. Binet Internet-Draft M. Boucadair Intended status: Informational France Telecom -Expires: March 13, 2015 A. Vizdal +Expires: March 21, 2015 A. Vizdal Deutsche Telekom AG G. Chen China Mobile N. Heatley EE R. Chandler eircom | meteor - September 9, 2014 + September 17, 2014 An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices - draft-ietf-v6ops-mobile-device-profile-11 + draft-ietf-v6ops-mobile-device-profile-12 Abstract This 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). This document defines a different profile than the one for general connection to IPv6 cellular networks defined in the IPv6 for Third @@ -38,21 +38,21 @@ 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 March 13, 2015. + This Internet-Draft will expire on March 21, 2015. Copyright Notice Copyright (c) 2014 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 @@ -67,22 +67,22 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Language Considerations . . . . . . . . . . . . . . . . . 4 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 8 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 9 4. Recommendations for Cellular Devices with LAN Capabilities . 12 5. APIs & Applications Recommendations . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 16 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 @@ -157,21 +157,21 @@ o "Cellular device" and "mobile device" are used interchangeably. PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 addresses [RFC6052]. 1.2. Scope A 3GPP mobile network can be used to connect various user equipments such as a mobile telephone, a CPE (Customer Premises Equipment) or a - M2M (machine-to-machine) device. Because of this diversity of + machine-to-machine (M2M) device. Because of this diversity of terminals, it is necessary to define a set of IPv6 functionalities valid for any node directly connecting to a 3GPP mobile network. This document describes these functionalities. This document is structured to provide the generic IPv6 recommendations which are valid for all nodes, whatever their function (e.g., host or CPE) or service (e.g., Session Initiation Protocol (SIP, [RFC3261])) capability. The document also contains sections covering specific functionalities for devices providing some LAN functions (e.g., mobile CPE or broadband dongles). @@ -466,28 +466,28 @@ stateful devices may be deployed in wireless networks (e.g., NAT and/or Firewalls), PCP can be used by the cellular host to control network-based NAT and Firewall functions which will reduce per-application signaling and save battery consumption. According to [Power], the consumption of a cellular device with a keep-alive interval equal to 20 seconds (that is the default value in [RFC3948] for example) is 29mA (2G)/34mA (3G). This consumption is reduced to - 16mA (2G)/24mA (3G) when the interval is increased to 40 - seconds, to 9.1mA (2G)/16mA (3G) if the interval is - equal to 150s, and to 7.3mA (2G)/14mA (3G) if the - interval is equal to 180s. When no keep-alive is - issued, the consumption would be 5.2mA (2G)/6.1mA (3G). - The impact of keepalive messages would be more severe if - multiple applications are issuing those messages (e.g., - SIP, IPsec, etc.). + 16 mA (2G)/24 mA (3G) when the interval is increased to + 40 seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is + equal to 150 seconds, and to 7.3 mA (2G)/14 mA (3G) if + the interval is equal to 180 seconds. When no keep- + alive is issued, the consumption would be 5.2 mA + (2G)/6.1 mA (3G). The impact of keepalive messages + would be more severe if multiple applications are + issuing those messages (e.g., SIP, IPsec, etc.). A_REC#4: In order for host-based validation of DNS Security Extensions (DNSSEC) to continue to function in an IPv6-only with NAT64 deployment context, the cellular host should embed a DNS64 function ([RFC6147]). This is called "DNS64 in stub-resolver mode" in [RFC6147]. As discussed in Section 5.5 of [RFC6147], a security- @@ -565,33 +565,46 @@ the WAN (Wide Area Network) and the delegated prefix to be aggregatable, so the subscriber can be identified using a single prefix. Without the Prefix Exclude Option, the delegating router (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]. 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). 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 + recommended [RFC7278]. + + [RFC7278] must be invoked only if Prefix Delegation is + not in use. + L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only deployment context, the cellular device should support the Customer Side Translator (CLAT) [RFC6877]. Various IP devices are likely to be connected to cellular device, acting as a CPE. Some of these devices can be dual-stack, others are IPv6-only or IPv4-only. IPv6-only connectivity for cellular device does not allow IPv4-only sessions to be established for hosts connected on the LAN segment of cellular devices. @@ -655,22 +668,22 @@ Address privacy considerations are discussed in [RFC4941] [RFC7217]. 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 R. - Chandler for the discussion in the v6ops mailing list. + Kuarsingh, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt for + the discussion in the v6ops mailing list. Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for their detailed reviews and comments. 9. References 9.1. Normative References [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March 2011,