draft-ietf-v6ops-mobile-device-profile-04.txt   draft-ietf-v6ops-mobile-device-profile-05.txt 
V6OPS Working Group D. Binet V6OPS Working Group D. Binet
Internet-Draft M. Boucadair Internet-Draft M. Boucadair
Intended status: Informational France Telecom Intended status: Informational France Telecom
Expires: December 12, 2013 A. Vizdal Expires: March 08, 2014 A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
C. Byrne C. Byrne
T-Mobile T-Mobile
G. Chen G. Chen
China Mobile China Mobile
June 10, 2013 September 04, 2013
Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
draft-ietf-v6ops-mobile-device-profile-04 draft-ietf-v6ops-mobile-device-profile-05
Abstract Abstract
This document specifies an IPv6 profile for 3GPP mobile devices. It This document defines an IPv6 profile for 3GPP mobile devices. It
lists the set of features a 3GPP mobile device is to be compliant 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 with to connect to an IPv6-only or dual-stack wireless network
(including 3GPP cellular network and IEEE 802.11 network). (including 3GPP cellular network and IEEE 802.11 network).
This document defines a different profile than the one for general This document defines a different profile than the one for general
connection to IPv6 cellular networks defined in connection to IPv6 cellular networks defined in
[I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies
also features to deliver IPv4 connectivity service over an IPv6-only also features to deliver IPv4 connectivity service over an IPv6-only
transport. transport.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2013. This Internet-Draft will expire on March 08, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Special Language . . . . . . . . . . . . . . . . . . . . 4 1.2. Special Language . . . . . . . . . . . . . . . . . . . . 4
2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 5 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 4
2.1. WLAN Connectivity Requirements . . . . . . . . . . . . . 8 2.1. WLAN Connectivity Requirements . . . . . . . . . . . . . 8
3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9
4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 10 4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 10
5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 12 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
IPv6 deployment in 3GPP mobile networks is the only perennial IPv6 deployment in 3GPP mobile networks is the only perennial
solution to the exhaustion of IPv4 addresses in those networks. solution to the exhaustion of IPv4 addresses in those networks.
Several mobile operators have already deployed IPv6 or are in the Several mobile operators have already deployed IPv6 [RFC2460] or are
pre-deployment phase. One of the major hurdles encountered by mobile in the pre-deployment phase. One of the major hurdles encountered by
operators is the availability of non-broken IPv6 implementation in mobile operators is the availability of non-broken IPv6
mobile devices. implementation in mobile devices.
[I-D.ietf-v6ops-rfc3316bis] lists a set of features to be supported [I-D.ietf-v6ops-rfc3316bis] lists a set of features to be supported
by cellular hosts to connect to 3GPP mobile networks. In the light by cellular hosts to connect to 3GPP mobile networks. In the light
of recent IPv6 production deployments, additional features to of recent IPv6 production deployments, additional features to
facilitate IPv6-only deployments while accessing IPv4-only service facilitate IPv6-only deployments while accessing IPv4-only service
are to be considered. are to be considered.
This document defines a different profile than the one for general This document defines a different profile than the one for general
connection to IPv6 mobile networks defined in connection to IPv6 mobile networks defined in
[I-D.ietf-v6ops-rfc3316bis]; in particular: [I-D.ietf-v6ops-rfc3316bis]; in particular:
o It lists an extended list of required features while o It lists an extended list of features while
[I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how to [I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how to
implement basic IPv6 features in a cellular context. implement basic IPv6 features in a cellular context.
o It identifies also features to ensure IPv4 service delivery over o It identifies also features to ensure IPv4 service delivery over
an IPv6-only transport. an IPv6-only transport.
This document specifies an IPv6 profile for mobile devices listing This document specifies an IPv6 profile for mobile devices listing
required specifications produced by various Standards Developing specifications produced by various Standards Developing Organizations
Organizations (in particular 3GPP and IETF). The objectives of this (in particular 3GPP and IETF). The objectives of this effort are:
effort are:
1. List in one single document a comprehensive list of IPv6 features 1. List in one single document a comprehensive list of IPv6 features
for a mobile device, including both IPv6-only and dual-stack for a mobile device, including both IPv6-only and dual-stack
mobile deployment contexts. These features cover various network mobile deployment contexts. These features cover various network
types such as GPRS (General Packet Radio Service), EPC (Evolved types such as GPRS (General Packet Radio Service), EPC (Evolved
Packet Core) or IEEE 802.11 network. Packet Core) or IEEE 802.11 network.
2. Help Operators with the detailed device requirement list 2. Help Operators with the detailed device requirement list
preparation (to be exchanged with device suppliers). This is preparation (to be exchanged with device suppliers). This is
also a contribution to harmonize Operators' requirements towards also a contribution to harmonize Operators' requirements towards
skipping to change at page 4, line 34 skipping to change at page 4, line 31
A 3GPP mobile network can be used to connect various user equipments A 3GPP mobile network can be used to connect various user equipments
such as a mobile telephone, a CPE (Customer Premises Equipment) or a such as a mobile telephone, a CPE (Customer Premises Equipment) or a
M2M (machine-to-machine) device. Because of this diversity of M2M (machine-to-machine) device. Because of this diversity of
terminals, it is necessary to define a set of IPv6 functionalities terminals, it is necessary to define a set of IPv6 functionalities
valid for any node directly connecting to a 3GPP mobile network. valid for any node directly connecting to a 3GPP mobile network.
This document describes these functionalities. This document describes these functionalities.
This document is structured to provide the generic IPv6 requirements This document is structured to provide the generic IPv6 requirements
which are valid for all nodes, whatever their function or service which are valid for all nodes, whatever their function or service
(e.g., SIP [RFC3261]) capability. The document also contains, (e.g., SIP [RFC3261]) capability. The document also contains
dedicated sections covering specific functionalities the specific sections covering specific functionalities for devices providing some
device types must support (e.g., smartphones, devices providing some LAN functions (e.g., mobile CPE or broadband dongles).
LAN functions (mobile CPE or broadband dongles)).
The requirements listed below are valid for both 3GPP GPRS and 3GPP The requirements listed below are valid for both 3GPP GPRS and 3GPP
EPS (Evolved Packet System) access. For EPS, PDN-Connection term is EPS (Evolved Packet System) access. For EPS, PDN-Connection term is
used instead of PDP-Context. used instead of PDP-Context.
This document identifies also some WLAN-related IPv6 requirements. This document identifies also some WLAN-related IPv6 requirements.
Other non-3GPP accesses [TS.23402] are out of scope of this document. Other non-3GPP accesses [TS.23402] are out of scope of this document.
1.2. Special Language 1.2. Special Language
skipping to change at page 6, line 50 skipping to change at page 6, line 44
[TS.23060] (3G) and [TS.23401] (LTE): [TS.23060] (3G) and [TS.23401] (LTE):
Stateless mode is the only way to configure a cellular host. Stateless mode is the only way to configure a cellular host.
The GGSN/PGW 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. scope to each primary PDP-Context.
To configure its link local address, the cellular host MUST To configure its link local address, the cellular host MUST
use the Interface Identifier conveyed in 3GPP PDP-Context use the Interface Identifier conveyed in 3GPP PDP-Context
setup signaling received from a GGSN/PGW. The cellular host setup signaling received from a GGSN/PGW. The cellular host
may use a different Interface Identifiers to configure its may use a different Interface Identifiers to configure its
global addresses (see also REQ#23 about privacy addressing global addresses (see also REQ#24 about privacy addressing
requirement). requirement).
For more details, refer to [RFC6459] and For more details, refer to [RFC6459] and
[I-D.ietf-v6ops-rfc3316bis]. [I-D.ietf-v6ops-rfc3316bis].
REQ#9: The cellular host MUST comply with Section 7.3 of [RFC6434]. REQ#9: The cellular host MUST comply with Section 7.3 of [RFC6434].
REQ#10: The cellular host MUST comply with Section 7.2.1 of REQ#10: The cellular host MUST comply with Section 7.2.1 of
[RFC6434]. [RFC6434].
Stateless DHCPv6 is useful to retrieve other information than Stateless DHCPv6 is useful to retrieve other information than
DNS. DNS.
If [RFC6106] is not supported, the cellular host SHOULD If [RFC6106] is not supported at the network side, the
retrieve DNS information using stateless DHCPv6 [RFC3736]. cellular host SHOULD retrieve DNS information using stateless
DHCPv6 [RFC3736].
REQ#11: If the cellular host receives the DNS information in several REQ#11: If the cellular host receives the DNS information in several
channels for the same interface, the following preference order channels for the same interface, the following preference order
MUST be followed: MUST be followed:
1. PCO 1. PCO
2. RA 2. RA
3. DHCPv6 3. DHCPv6
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Cellular hosts SHOULD follow the procedure specified in Cellular hosts SHOULD follow the procedure specified in
[RFC6724] for source address selection. [RFC6724] for source address selection.
REQ#17: The cellular host SHOULD support Happy Eyeballs procedure REQ#17: The cellular host SHOULD support Happy Eyeballs procedure
defined in [RFC6555]. defined in [RFC6555].
REQ#18: The cellular device MAY embed a BIH function [RFC6535] REQ#18: The cellular device MAY embed a BIH function [RFC6535]
facilitating the communication between an IPv4 application and facilitating the communication between an IPv4 application and
an IPv6 server. an IPv6 server.
REQ#19: Because of potential operational deficiencies to be
experienced in some roaming situations, the cellular host MUST
be able to be configured with a home IP profile and a roaming IP
profile. The aim of the roaming profile is to limit the PDP
type(s) requested by the cellular host when out of the home
network. Note, distinct PDP type(s) can be configured for home
and roaming cases.
2.1. WLAN Connectivity Requirements 2.1. WLAN Connectivity Requirements
It is increasingly common for cellular hosts have a WLAN interface in It is increasingly common for cellular hosts have a WLAN interface in
addition to their cellular interface. These hosts are likely to be addition to their cellular interface. These hosts are likely to be
connected to private or public hotspots. Below are listed some connected to private or public hotspots. Below are listed some
generic requirements: generic requirements:
REQ#19: IPv6 MUST be supported on the WLAN interface. In REQ#20: IPv6 MUST be supported on the WLAN interface. In
particular, IPv6-only connectivity MUST be supported over the particular, IPv6-only connectivity MUST be supported over the
WLAN interface. WLAN interface.
Some tests revealed that IPv4 configuration is required to Some tests revealed that IPv4 configuration is required to
enable IPv6-only connectivity. Indeed, some cellular enable IPv6-only connectivity. Indeed, some cellular
handsets can access a WLAN IPv6-only network by configuring handsets can access a WLAN IPv6-only network by configuring
first a static IPv4 address. Once the device is connected first a static IPv4 address. Once the device is connected
to the network and the wlan0 interface got an IPv6 global to the network and the wlan0 interface got an IPv6 global
address, the IPv4 address can be deleted from the address, the IPv4 address can be deleted from the
configuration. This avoids the device to ask automatically configuration. This avoids the device to ask automatically
for a DHCPv4 server, and allows to connect to IPv6-only for a DHCPv4 server, and allows to connect to IPv6-only
networks. Failing to configure an IPv4 address on the networks. Failing to configure an IPv4 address on the
interface MUST NOT prohibit using IPv6 on the same interface MUST NOT prohibit using IPv6 on the same
interface. interface.
IPv6 Stateless Address Autoconfiguration ([RFC4862]) MUST IPv6 Stateless Address Autoconfiguration ([RFC4862]) MUST
be supported. be supported.
REQ#20: DHCPv6 client SHOULD be supported on WLAN interface. REQ#21: DHCPv6 client SHOULD be supported on WLAN interface.
Refer to Section 7.2.1 of [RFC6434]. Refer to Section 7.2.1 of [RFC6434].
REQ#21: WLAN interface SHOULD support Router Advertisement Options REQ#22: WLAN interface SHOULD support Router Advertisement Options
for DNS configuration (See Section 7.3 of [RFC6434]). for DNS configuration (See Section 7.3 of [RFC6434]).
REQ#22: If the device receives the DNS information in several REQ#23: If the device receives the DNS information in several
channels for the same interface, the following preference channels for the same interface, the following preference
order MUST be followed: order MUST be followed:
1. RA 1. RA
2. DHCPv6 2. DHCPv6
3. Advanced Requirements 3. Advanced Requirements
REQ#23: The cellular host MUST be able to generate IPv6 addresses REQ#24: The cellular host MUST be able to generate IPv6 addresses
which preserve privacy. which preserve privacy.
The activation of privacy extension (e.g., using [RFC4941]) The activation of privacy extension (e.g., using [RFC4941])
makes it more difficult to track a host over time when makes it more difficult to track a host over time when
compared to using a permanent Interface Identifier. Note, compared to using a permanent Interface Identifier. Note,
[RFC4941] does not require any DAD mechanism to be [RFC4941] does not require any DAD mechanism to be
activated as the GGSN/PGW MUST NOT configure any global activated as the GGSN/PGW MUST NOT configure any global
address based on the prefix allocated to the cellular host. address based on the prefix allocated to the cellular host.
Tracking a host is still possible based on the first 64 Tracking a host is still possible based on the first 64
bits of the IPv6 address. Means to prevent against such bits of the IPv6 address. Means to prevent against such
tracking issues may be enabled in the network side. tracking issues may be enabled in the network side.
REQ#24: The cellular host MUST support ROHC RTP Profile (0x0001) and REQ#25: The cellular host MUST support ROHC RTP Profile (0x0001) and
ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other ROHC ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other ROHC
profiles MAY be supported. profiles MAY be supported.
Bandwidth in cellular networks must be optimized as much as Bandwidth in cellular networks must be optimized as much as
possible. ROHC provides a solution to reduce bandwidth possible. ROHC provides a solution to reduce bandwidth
consumption and to reduce the impact of having bigger consumption and to reduce the impact of having bigger
packet headers in IPv6 compared to IPv4. packet headers in IPv6 compared to IPv4.
"RTP/UDP/IP" ROHC profile (0x0001) to compress RTP packets "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP packets
and "UDP/IP" ROHC profile (0x0002) to compress RTCP packets and "UDP/IP" ROHC profile (0x0002) to compress RTCP packets
are required for Voice over LTE (VoLTE) by IR.92.4.0 are required for Voice over LTE (VoLTE) by IR.92.4.0
section 4.1 [IR92]. Note, [IR92] indicates also the host section 4.1 [IR92]. Note, [IR92] indicates also the host
must be able to apply the compression to packets that are must be able to apply the compression to packets that are
carried over the radio bearer dedicated for the voice carried over the radio bearer dedicated for the voice
media. media.
REQ#25: The cellular host MUST comply with Section 5.3 of [RFC6434] REQ#26: The cellular host MUST comply with Section 5.3 of [RFC6434]
and SHOULD support Router Advertisement extension for and SHOULD support Router Advertisement extension for
communicating default router preferences and more-specific communicating default router preferences and more-specific
routes as described in [RFC4191]. routes as described in [RFC4191].
This function can be used for instance for traffic offload. This function can be used for instance for traffic offload.
4. Cellular Devices with LAN Capabilities 4. Cellular Devices with LAN Capabilities
This section focuses on cellular devices (e.g., CPE, smartphones or This section focuses on cellular devices (e.g., CPE, smartphones or
dongles with tethering features) which provide IP connectivity to dongles with tethering features) which provide IP connectivity to
other devices connected to them. In such case, all connected devices other devices connected to them. In such case, all connected devices
are sharing the same 2G, 3G or LTE connection. In addition to the are sharing the same 2G, 3G or LTE connection. In addition to the
generic requirements listed in Section 2, these cellular devices have generic requirements listed in Section 2, these cellular devices have
to meet the requirements listed below. to meet the requirements listed below.
REQ#26: The cellular device MUST support Prefix Delegation REQ#27: The cellular device MUST support Prefix Delegation
capabilities [RFC3633] and MUST support Prefix Exclude Option capabilities [RFC3633] and MUST support Prefix Exclude Option
for DHCPv6-based Prefix Delegation as defined in [RFC6603]. for DHCPv6-based Prefix Delegation as defined in [RFC6603].
Particularly, it MUST behave as a Requesting Router. Particularly, it MUST behave as a Requesting Router.
Cellular networks are more and more perceived as an Cellular networks are more and more perceived as an
alternative to fixed networks for home IP-based services alternative to fixed networks for home IP-based services
delivery; especially with the advent of smartphones and delivery; especially with the advent of smartphones and
3GPP data dongles. There is a need for an efficient 3GPP data dongles. There is a need for an efficient
mechanism to assign shorter prefix than /64 to cellular mechanism to assign shorter prefix than /64 to cellular
hosts so that each LAN segment can get its own /64 prefix hosts so that each LAN segment can get its own /64 prefix
skipping to change at page 11, line 18 skipping to change at page 11, line 34
WAN (Wide Area Network) and the delegated prefix to be WAN (Wide Area Network) and the delegated prefix to be
aggregatable, so the subscriber can be identified using a aggregatable, so the subscriber can be identified using a
single prefix. single prefix.
Without the Prefix Exclude Option, the delegating router Without the Prefix Exclude Option, the delegating router
(GGSN/PGW) will have to ensure [RFC3633] compliancy (e.g., (GGSN/PGW) will have to ensure [RFC3633] compliancy (e.g.,
halving the delegated prefix and assigning the WAN prefix halving the delegated prefix and assigning the WAN prefix
out of the 1st half and the prefix to be delegated to the out of the 1st half and the prefix to be delegated to the
terminal from the 2nd half). terminal from the 2nd half).
REQ#27: The cellular device MUST be compliant with the CPE REQ#28: The cellular device MUST be compliant with the CPE
requirements specified in [RFC6204]. requirements specified in [RFC6204].
REQ#28: For deployments requiring to share the same /64 prefix, the REQ#29: For deployments requiring to share the same /64 prefix, the
cellular device SHOULD support [I-D.ietf-v6ops-64share] to cellular device SHOULD support [I-D.ietf-v6ops-64share] to
enable sharing a /64 prefix between the 3GPP interface towards enable sharing a /64 prefix between the 3GPP interface towards
the GGSN/PGW (WAN interface) and the LAN interfaces. the GGSN/PGW (WAN interface) and the LAN interfaces.
REQ#29: The cellular device SHOULD support the Customer Side REQ#30: The cellular device SHOULD support the Customer Side
Translator (CLAT) [RFC6877]. Translator (CLAT) [RFC6877].
Various IP devices are likely to be connected to cellular Various IP devices are likely to be connected to cellular
device, acting as a CPE. Some of these devices can be device, acting as a CPE. Some of these devices can be
dual-stack, others are IPv6-only or IPv4-only. IPv6-only dual-stack, others are IPv6-only or IPv4-only. IPv6-only
connectivity for cellular device does not allow IPv4-only connectivity for cellular device does not allow IPv4-only
sessions to be established for hosts connected on the LAN sessions to be established for hosts connected on the LAN
segment of cellular devices. segment of cellular devices.
In order to allow IPv4 sessions establishment initiated In order to allow IPv4 sessions establishment initiated
from devices located on LAN segment side and target IPv4 from devices located on LAN segment side and target IPv4
nodes, a solution consists in integrating the CLAT function nodes, a solution consists in integrating the CLAT function
in the cellular device. As elaborated in Section 2, the in the cellular device. As elaborated in Section 2, the
CLAT function allows also IPv4 applications to continue CLAT function allows also IPv4 applications to continue
running over an IPv6-only host. running over an IPv6-only host.
REQ#30: If a RA MTU is advertised from the 3GPP network, the REQ#31: If a RA MTU is advertised from the 3GPP network, the
cellular device SHOULD relay that upstream MTU information to cellular device SHOULD relay that upstream MTU information to
the downstream attached LAN devices in RA. the downstream attached LAN devices in RA.
Receiving and relaying RA MTU values facilitates a more Receiving and relaying RA MTU values facilitates a more
harmonious functioning of the mobile core network where end harmonious functioning of the mobile core network where end
nodes transmit packets that do not exceed the MTU size of nodes transmit packets that do not exceed the MTU size of
the mobile network's GTP tunnels. the mobile network's GTP tunnels.
[TS.23060] indicates providing a link MTU value of 1358 [TS.23060] indicates providing a link MTU value of 1358
octets to the 3GPP cellular device will prevent the IP octets to the 3GPP cellular device will prevent the IP
layer fragmentation within the transport network between layer fragmentation within the transport network between
the cellular device and the GGSN/PGW. the cellular device and the GGSN/PGW.
5. APIs & Applications 5. APIs & Applications
REQ#31: Name resolution libraries MUST support both IPv4 and IPv6. REQ#32: Name resolution libraries MUST support both IPv4 and IPv6.
In particular, the cellular host MUST support [RFC3596]. In particular, the cellular host MUST support [RFC3596].
REQ#32: Applications MUST be independent of the underlying IP REQ#33: Applications MUST be independent of the underlying IP
address family. address family.
This means applications must be IP version agnostic. This means applications must be IP version agnostic.
REQ#33: Applications using URIs MUST follow [RFC3986]. For example, REQ#34: Applications using URIs MUST follow [RFC3986]. For example,
SIP applications MUST follow the correction defined in SIP applications MUST follow the correction defined in
[RFC5954]. [RFC5954].
6. Security Considerations 6. Security Considerations
The security considerations identified in [I-D.ietf-v6ops-rfc3316bis] The security considerations identified in [I-D.ietf-v6ops-rfc3316bis]
and [RFC6459] are to be taken into account. and [RFC6459] are to be taken into account.
REQ#34: If the cellular device provides LAN features, it SHOULD be Security-related considerations that apply when the cellular device
compliant with the security requirements specified in provides LAN features are specified in [RFC6092].
[RFC6092].
7. IANA Considerations 7. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
8. Acknowledgements 8. Acknowledgements
Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B. Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B.
Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, and Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, N.
J. Woodyatt for the discussion in the v6ops mailing list. Heatley, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt for the
discussion in the v6ops mailing list.
Special thanks to T. Savolainen and J. Korhonen for the detailed Special thanks to T. Savolainen and J. Korhonen for the detailed
review. review.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-v6ops-rfc3316bis]
Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan,
"IPv6 for 3GPP Cellular Hosts", draft-ietf-v6ops-
rfc3316bis-04 (work in progress), September 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
skipping to change at page 15, line 5 skipping to change at page 15, line 26
9.2. Informative References 9.2. Informative References
[I-D.ietf-behave-nat64-discovery-heuristic] [I-D.ietf-behave-nat64-discovery-heuristic]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", draft- the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
ietf-behave-nat64-discovery-heuristic-17 (work in ietf-behave-nat64-discovery-heuristic-17 (work in
progress), April 2013. progress), April 2013.
[I-D.ietf-pcp-nat64-prefix64] [I-D.ietf-pcp-nat64-prefix64]
Boucadair, M., "Learning NAT64 PREFIX64s using PCP", Boucadair, M., "Learning NAT64 PREFIX64s using PCP",
draft-ietf-pcp-nat64-prefix64-03 (work in progress), June draft-ietf-pcp-nat64-prefix64-04 (work in progress), July
2013. 2013.
[I-D.ietf-v6ops-64share] [I-D.ietf-v6ops-64share]
Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64
Prefix from a 3GPP Mobile Interface to a LAN", draft-ietf- Prefix from a 3GPP Mobile Interface to a LAN link", draft-
v6ops-64share-07 (work in progress), May 2013. ietf-v6ops-64share-08 (work in progress), July 2013.
[I-D.ietf-v6ops-rfc3316bis]
Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan,
"IPv6 for 3GPP Cellular Hosts", draft-ietf-v6ops-
rfc3316bis-03 (work in progress), May 2013.
[IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March [IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March
2011, <http://www.gsma.com/newsroom/ir-92-v4-0-ims- 2011, <http://www.gsma.com/newsroom/ir-92-v4-0-ims-
profile-for-voice-and-sms>. profile-for-voice-and-sms>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
skipping to change at page 16, line 47 skipping to change at page 17, line 16
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", September 2011. Protocol User Plane (GTPv1-U)", September 2011.
Authors' Addresses Authors' Addresses
David Binet David Binet
France Telecom France Telecom
Rennes Rennes
France France
Email: david.binet@orange.com EMail: david.binet@orange.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com EMail: mohamed.boucadair@orange.com
Ales Vizdal Ales Vizdal
Deutsche Telekom AG Deutsche Telekom AG
Email: ales.vizdal@t-mobile.cz EMail: ales.vizdal@t-mobile.cz
Cameron Byrne Cameron Byrne
T-Mobile T-Mobile
USA USA
Email: Cameron.Byrne@T-Mobile.com EMail: Cameron.Byrne@T-Mobile.com
Gang Chen Gang Chen
China Mobile China Mobile
Email: phdgang@gmail.com EMail: phdgang@gmail.com
 End of changes. 40 change blocks. 
59 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/