draft-ietf-v6ops-mobile-device-profile-05.txt   draft-ietf-v6ops-mobile-device-profile-06.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: March 08, 2014 A. Vizdal Expires: March 15, 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
September 04, 2013 September 11, 2013
An 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-05 draft-ietf-v6ops-mobile-device-profile-06
Abstract Abstract
This document defines an IPv6 profile for 3GPP mobile devices. It This document defines an IPv6 profile that a number of operators
lists the set of features a 3GPP mobile device is to be compliant recommend in order to connect 3GPP mobile devices to an IPv6-only or
with to connect to an IPv6-only or dual-stack wireless network dual-stack wireless network (including 3GPP cellular network and IEEE
(including 3GPP cellular network and IEEE 802.11 network). 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.
Both hosts and devices with capability to share their WAN (Wide Area Both hosts and devices with capability to share their WAN (Wide Area
Network) connectivity are in scope. Network) connectivity are in scope.
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 March 08, 2014. This Internet-Draft will expire on March 15, 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 . . . . . . . . . . . . . . . . . . 4 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
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 [RFC2460] or are Several mobile operators have already deployed IPv6 [RFC2460] or are
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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 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 defines an IPv6 profile for mobile devices listing
specifications produced by various Standards Developing Organizations specifications produced by various Standards Developing Organizations
(in particular 3GPP and IETF). The objectives of this effort are: (in particular 3GPP and IETF). The objectives of this 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
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document is not a standard. It uses the normative keywords only NOTE WELL: This document is not a standard, and conformance with
for precision. 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.
This document uses the normative keywords only for precision.
2. Connectivity Requirements 2. Connectivity Requirements
REQ#1: The cellular host MUST be compliant with Section 5.9.1 (IPv6 REQ#1: The cellular host MUST be compliant with Section 5.9.1 (IPv6
Addressing Architecture) and Section 5.8 (ICMPv6 support) of Addressing Architecture) and Section 5.8 (ICMPv6 support) of
[RFC6434]. [RFC6434].
REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP- REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP-
Contexts. Contexts.
This allows each operator to select their own strategy This allows each operator to select their own strategy
regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP- regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP-
Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context
skipping to change at page 6, line 44 skipping to change at page 7, line 5
[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#24 about privacy addressing global addresses (see also REQ#23 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].
skipping to change at page 7, line 48 skipping to change at page 8, line 10
REQ#13: The cellular host SHOULD implement the Customer Side REQ#13: The cellular host SHOULD implement the Customer Side
Translator (CLAT, [RFC6877]) function which is compliant with Translator (CLAT, [RFC6877]) function which is compliant with
[RFC6052][RFC6145][RFC6146]. [RFC6052][RFC6145][RFC6146].
CLAT function in the cellular host allows for IPv4-only CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only application and IPv4-referals to work on an IPv6-only
connectivity. CLAT function requires a NAT64 capability connectivity. CLAT function requires a NAT64 capability
[RFC6146] in the core network. [RFC6146] in the core network.
REQ#14: The cellular device SHOULD embed a DNS64 function [RFC6147]. REQ#14: The cellular host SHOULD embed a DNS64 function [RFC6147].
Local DNS64 functionality allows for compatibility with DNS Local DNS64 functionality allows for compatibility with DNS
Security Extensions (DNSSEC, [RFC4033], [RFC4034], Security Extensions (DNSSEC, [RFC4033], [RFC4034],
[RFC4035]). Means to configure or discover a PREFIX64 is [RFC4035]). Means to configure or discover a PREFIX64 is
also required on the cellular device as discussed in REQ#12. also required on the cellular device as discussed in REQ#12.
REQ#15: The cellular host SHOULD support PCP [RFC6887]. REQ#15: The cellular host SHOULD support PCP [RFC6887].
The support of PCP is seen as a driver to save battery The support of PCP is seen as a driver to save battery
consumption exacerbated by keepalive messages. PCP also consumption exacerbated by keepalive messages. PCP also
skipping to change at page 8, line 35 skipping to change at page 8, line 42
When both IPv4 and IPv6 DNS servers are configured, a dual- When both IPv4 and IPv6 DNS servers are configured, a dual-
stack host MUST contact first its IPv6 DNS server. stack host MUST contact first its IPv6 DNS server.
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: Because of potential operational deficiencies to be
facilitating the communication between an IPv4 application and
an IPv6 server.
REQ#19: Because of potential operational deficiencies to be
experienced in some roaming situations, the cellular host MUST experienced in some roaming situations, the cellular host MUST
be able to be configured with a home IP profile and a roaming IP 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 profile. The aim of the roaming profile is to limit the PDP
type(s) requested by the cellular host when out of the home type(s) requested by the cellular host when out of the home
network. Note, distinct PDP type(s) can be configured for home network. Note, distinct PDP type(s) can be configured for home
and roaming cases. 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#20: IPv6 MUST be supported on the WLAN interface. In REQ#19: 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#21: DHCPv6 client SHOULD be supported on WLAN interface. REQ#20: 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#22: WLAN interface SHOULD support Router Advertisement Options REQ#21: 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#23: If the device receives the DNS information in several REQ#22: 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#24: The cellular host MUST be able to generate IPv6 addresses REQ#23: 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#25: The cellular host MUST support ROHC RTP Profile (0x0001) and Privacy extensions are required by regulatory bodies in
some countries.
REQ#24: 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#26: The cellular host MUST comply with Section 5.3 of [RFC6434] REQ#25: 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#27: The cellular device MUST support Prefix Delegation REQ#26: 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 34 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#28: The cellular device MUST be compliant with the CPE REQ#27: The cellular device MUST be compliant with the CPE
requirements specified in [RFC6204]. requirements specified in [RFC6204].
REQ#29: For deployments requiring to share the same /64 prefix, the 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).
REQ#28: 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#30: The cellular device SHOULD support the Customer Side REQ#29: 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#31: If a RA MTU is advertised from the 3GPP network, the REQ#30: 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#32: Name resolution libraries MUST support both IPv4 and IPv6. REQ#31: 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#33: Applications MUST be independent of the underlying IP REQ#32: Applications provided by the mobile device vendor MUST be
address family. independent of the underlying IP address family.
This means applications must be IP version agnostic. This means applications must be IP version agnostic.
REQ#34: Applications using URIs MUST follow [RFC3986]. For example, REQ#33: Applications provided by the mobile device vendor that use
SIP applications MUST follow the correction defined in URIs MUST follow [RFC3986]. For example, SIP applications
[RFC5954]. MUST follow the correction defined in [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.
Security-related considerations that apply when the cellular device Security-related considerations that apply when the cellular device
provides LAN features are specified in [RFC6092]. provides LAN features are specified in [RFC6092].
7. IANA Considerations 7. IANA Considerations
skipping to change at page 14, line 51 skipping to change at page 15, line 5
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
 End of changes. 30 change blocks. 
42 lines changed or deleted 50 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/