--- 1/draft-ietf-v6ops-mobile-device-profile-02.txt 2013-05-02 09:04:52.269054146 +0100 +++ 2/draft-ietf-v6ops-mobile-device-profile-03.txt 2013-05-02 09:04:52.753066177 +0100 @@ -1,24 +1,24 @@ V6OPS Working Group D. Binet Internet-Draft M. Boucadair Intended status: Informational France Telecom -Expires: October 28, 2013 A. Vizdal +Expires: October 31, 2013 A. Vizdal Deutsche Telekom AG C. Byrne T-Mobile G. Chen China Mobile - April 26, 2013 + April 29, 2013 Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices - draft-ietf-v6ops-mobile-device-profile-02 + draft-ietf-v6ops-mobile-device-profile-03 Abstract This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect 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 @@ -37,21 +37,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 October 28, 2013. + This Internet-Draft will expire on October 31, 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 @@ -66,25 +66,25 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Special Language . . . . . . . . . . . . . . . . . . . . 4 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 5 2.1. WLAN Connectivity Requirements . . . . . . . . . . . . . 8 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9 4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 10 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 or are in the pre-deployment phase. One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices. @@ -267,21 +267,21 @@ REQ#7: The cellular host MUST comply with Section 5.6.1 of [RFC6434]. If the MTU used by cellular hosts is larger than 1280 bytes, they can rely on Path MTU discovery function to discover the real path MTU. REQ#8: The cellular host MUST support IPv6 Stateless Address Autoconfiguration ([RFC4862]) apart from the exceptions noted in [TS.23060] (3G) and [TS.23401] (LTE): Stateless mode is the only way to configure a cellular host. - The GGSN must allocate a prefix that is unique within its + The GGSN/PGW must allocate a prefix that is unique within its scope to each primary PDP-Context. To configure its link local address, the cellular host MUST use the Interface Identifier conveyed in 3GPP PDP-Context setup signaling received from a GGSN/PGW. The cellular host may use a different Interface Identifiers to configure its global addresses (see also REQ#23 about privacy addressing requirement). For more details, refer to [RFC6459] and @@ -496,21 +496,21 @@ 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). REQ#28: The cellular device MUST be compliant with the CPE requirements specified in [RFC6204]. REQ#29: For deployments requiring to share the same /64 prefix, the cellular device SHOULD support [I-D.ietf-v6ops-64share] to enable sharing a /64 prefix between the 3GPP interface towards - the GGSN (WAN interface) and the LAN interfaces. + the GGSN/PGW (WAN interface) and the LAN interfaces. REQ#30: 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. @@ -519,26 +519,20 @@ from devices located on LAN segment side and target IPv4 nodes, a solution consists in integrating the CLAT function in the cellular device. As elaborated in Section 2, the CLAT function allows also IPv4 applications to continue running over an IPv6-only host. REQ#31: If a RA MTU is advertised from the 3GPP network, the cellular device SHOULD relay that upstream MTU information to the downstream attached LAN devices in RA. - Since 3GPP networks extensively use IP-in-IP/UDP GTP - tunnels, the effective MTU is frequently effectively - reduced to 1440 bytes. While a host may generate packets - with an MTU of 1500 bytes, this results in undesirable - fragmentation of the GTP IP/UDP packets. - Receiving and relaying RA MTU values facilitates a more harmonious functioning of the mobile core network where end nodes transmit packets that do not exceed the MTU size of the mobile network's GTP tunnels. [TS.23060] indicates providing a link MTU value of 1358 octets to the 3GPP cellular device will prevent the IP layer fragmentation within the transport network between the cellular device and the GGSN/PGW.