draft-ietf-v6ops-mobile-device-profile-07.txt   draft-ietf-v6ops-mobile-device-profile-08.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: September 12, 2014 A. Vizdal Expires: February 12, 2015 A. Vizdal
Deutsche Telekom AG Deutsche Telekom AG
C. Byrne C. Byrne
T-Mobile T-Mobile
G. Chen G. Chen
China Mobile China Mobile
March 11, 2014 August 11, 2014
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-07 draft-ietf-v6ops-mobile-device-profile-08
Abstract Abstract
This document defines an IPv6 profile that a number of operators This document defines an IPv6 profile that a number of operators
recommend in order to connect 3GPP mobile devices to an IPv6-only or recommend in order to connect 3GPP mobile devices to an IPv6-only or
dual-stack wireless network (including 3GPP cellular network and IEEE dual-stack wireless network (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 [RFC7066]. In connection to IPv6 cellular networks defined in the IPv6 for Third
Generation Partnership Project (3GPP) Cellular Hosts document. In
particular, this document identifies also features to deliver IPv4 particular, this document identifies also features to deliver IPv4
connectivity service over an IPv6-only transport. connectivity service over an IPv6-only 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 47 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 September 12, 2014. This Internet-Draft will expire on February 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Special Language . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 5 1.3. Language Considerations . . . . . . . . . . . . . . . . . 4
2.1. WLAN Connectivity Requirements . . . . . . . . . . . . . 8 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 5
3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9 2.1. WLAN Connectivity Recommendations . . . . . . . . . . . . 9
4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 10 3. Advanced Recommendations . . . . . . . . . . . . . . . . . . 10
5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 12 4. Recommendations for Cellular Devices with LAN Capabilities . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. APIs & Applications Recommendations . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
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
in the pre-deployment phase. One of the major hurdles encountered by in the pre-deployment phase. One of the major hurdles encountered by
mobile operators is the availability of non-broken IPv6 mobile operators is the availability of non-broken IPv6
implementation in mobile devices. implementation in mobile devices.
skipping to change at page 3, line 38 skipping to change at page 3, line 38
also a contribution to harmonize Operators' requirements towards also a contribution to harmonize Operators' requirements towards
device vendors. device vendors.
3. Vendors to be aware of a set of features to allow for IPv6 3. Vendors to be aware of a set of features to allow for IPv6
connectivity and IPv4 service continuity (over an IPv6-only connectivity and IPv4 service continuity (over an IPv6-only
transport). transport).
Pointers to some requirements listed in [RFC6434] are included in Pointers to some requirements listed in [RFC6434] are included in
this profile. The justification for using a stronger language this profile. The justification for using a stronger language
compared to what is specified in [RFC6434] is provided for some compared to what is specified in [RFC6434] is provided for some
requirements. recommendations.
The requirements do not include 3GPP release details. For more The recommendations do not include 3GPP release details. For more
information on the 3GPP releases detail, the reader may refer to information on the 3GPP releases detail, the reader may refer to
Section 6.2 of [RFC6459]. Section 6.2 of [RFC6459].
Some of the features listed in this profile document require to Some of the features listed in this profile document require to
activate dedicated functions at the network side. It is out of scope activate dedicated functions at the network side. It is out of scope
of this document to list these network-side functions. of this document to list these network-side functions.
A detailed overview of IPv6 support in 3GPP architectures is provided A detailed overview of IPv6 support in 3GPP architectures is provided
in [RFC6459]. in [RFC6459].
1.1. Terminology
This document makes use of the terms defined in [RFC6459]. In This document makes use of the terms defined in [RFC6459]. In
addition, the following terms are used: addition, the following terms are used:
o "3GPP cellular host" (or cellular host for short) denotes a 3GPP o "3GPP cellular host" (or cellular host for short) denotes a 3GPP
device which can be connected to 3GPP mobile networks or IEEE device which can be connected to 3GPP mobile networks or IEEE
802.11 networks. 802.11 networks.
o "3GPP cellular device" (or cellular device for short) refers to a o "3GPP cellular device" (or cellular device for short) refers to a
cellular host which supports the capability to share its WAN (Wide cellular host which supports the capability to share its WAN (Wide
Area Network) connectivity. Area Network) connectivity.
o "Cellular host" and "mobile host" are used interchangeably. o "Cellular host" and "mobile host" are used interchangeably.
o "Cellular device" and "mobile device" are used interchangeably. o "Cellular device" and "mobile device" are used interchangeably.
PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6 PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses [RFC6052]. addresses [RFC6052].
1.1. Scope 1.2. Scope
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
which are valid for all nodes, whatever their function or service recommendations which are valid for all nodes, whatever their
(e.g., SIP [RFC3261]) capability. The document also contains 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 sections covering specific functionalities for devices providing some
LAN functions (e.g., mobile CPE or broadband dongles). LAN functions (e.g., mobile CPE or broadband dongles).
The requirements listed below are valid for both 3GPP GPRS and 3GPP The recommendations listed below are valid for both 3GPP GPRS and
EPS (Evolved Packet System) access. For EPS, PDN-Connection term is 3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection
used instead of PDP-Context. term is used instead of PDP-Context.
This document identifies also some WLAN-related IPv6 requirements. This document identifies also some WLAN-related IPv6 recommendations.
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.3. Language Considerations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "must", "must not", "should", "should not", and "may"
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this in this document are to be interpreted as described in RFC 2119
document are to be interpreted as described in RFC 2119 [RFC2119]. [RFC2119].
NOTE WELL: This document is not a standard, and conformance with This document is not a standard, and conformance with it is not
it is not required in order to claim conformance with IETF required in order to claim conformance with IETF standards for IPv6.
standards for IPv6. The support of the full set of features may The support of the full set of features may not be required in some
not be required in some deployment contexts. The authors believe deployment contexts. The authors believe that the support of a
that the support of a subset of the features included in this subset of the features included in this protocol may lead to degraded
protocol may lead to degraded level of service in some deployment level of service in some deployment contexts.
contexts.
This document uses the normative keywords only for precision. This document uses these keywords only for precision.
2. Connectivity Requirements 2. Connectivity Recommendations
REQ#1: The cellular host MUST be compliant with Section 5.9.1 (IPv6 This section identifies the main connectivity recommendations to be
Addressing Architecture) and Section 5.8 (ICMPv6 support) of followed by a cellular host to attach to a network using IPv6. Both
[RFC6434]. 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.
REQ#2: The cellular host MUST support both IPv6 and IPv4v6 PDP- C_REC#1: The cellular host must be compliant with Section 5.9.1
Contexts. (IPv6 Addressing Architecture) and Section 5.8 (ICMPv6
support) of [RFC6434].
This allows each operator to select their own strategy C_REC#2: In order to allow each operator to select their own
regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP- strategy regarding IPv6 introduction, the cellular host
Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060].
request acceptance depends on the cellular network Both IPv6 and IPv4v6 PDP-Contexts must be supported.
configuration. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance
depends on the cellular network configuration.
REQ#3: The cellular host MUST comply with the behavior defined in C_REC#3: The cellular host must comply with the behavior defined in
[TS.23060] [TS.23401] [TS.24008] for requesting a PDP-Context [TS.23060] [TS.23401] [TS.24008] for requesting a PDP-
type. In particular, the cellular host MUST request by default Context type. In particular, the cellular host must
an IPv6 PDP-Context if the cellular host is IPv6-only and request by default an IPv6 PDP-Context if the cellular
requesting an IPv4v6 PDP-Context if the cellular host is dual- host is IPv6-only and requesting an IPv4v6 PDP-Context if
stack or when the cellular host is not aware of connectivity the cellular host is dual-stack or when the cellular host
types requested by devices connected to it (e.g., cellular host is not aware of connectivity types requested by devices
with LAN capabilities as discussed in Section 4): connected to it (e.g., cellular host with LAN capabilities
as discussed in Section 4):
* If the requested IPv4v6 PDP-Context is not supported by the * If the requested IPv4v6 PDP-Context is not supported by
network, but IPv4 and IPv6 PDP types are allowed, then the the network, but IPv4 and IPv6 PDP types are allowed,
cellular host will be configured with an IPv4 address or an then the cellular host will be configured with an IPv4
IPv6 prefix by the network. It MUST initiate another PDP- address or an IPv6 prefix by the network. It must
Context activation in addition to the one already activated initiate another PDP-Context activation in addition to
for a given APN (Access Point Name). the one already activated for a given APN (Access Point
Name).
* If the requested PDP type and subscription data allows only * If the requested PDP type and subscription data allows
one IP address family (IPv4 or IPv6), the cellular host MUST only one IP address family (IPv4 or IPv6), the cellular
NOT request a second PDP-Context to the same APN for the host must not request a second PDP-Context to the same
other IP address family. APN for the other IP address family.
The text above focuses on the specification part which explains The text above focuses on the specification part which
the behavior for requesting IPv6-related PDP-Context(s). explains the behavior for requesting IPv6-related PDP-
Understanding this behavior is important to avoid having broken Context(s). Understanding this behavior is important to
IPv6 implementations in cellular devices. avoid having broken IPv6 implementations in cellular
devices.
REQ#4: The cellular host MUST support the PCO (Protocol C_REC#4: The cellular host must support the PCO (Protocol
Configuration Options) [TS.24008] to retrieve the IPv6 Configuration Options) [TS.24008] to retrieve the IPv6
address(es) of the Recursive DNS server(s). address(es) of the Recursive DNS server(s).
In-band signaling is a convenient method to inform the In-band signaling is a convenient method to inform the
cellular host about various services, including DNS server cellular host about various services, including DNS
information. It does not require any specific protocol to be server information. It does not require any specific
supported and it is already deployed in IPv4 cellular protocol to be supported and it is already deployed in
networks to convey such DNS information. IPv4 cellular networks to convey such DNS information.
REQ#5: The cellular host MUST support IPv6 aware Traffic Flow C_REC#5: The cellular host must support IPv6 aware Traffic Flow
Templates (TFT) [TS.24008]. Templates (TFT) [TS.24008].
Traffic Flow Templates are employing a packet filter to Traffic Flow Templates are employing a packet filter to
couple an IP traffic with a PDP-Context. Thus a dedicated couple an IP traffic with a PDP-Context. Thus a
PDP-Context and radio resources can be provided by the dedicated PDP-Context and radio resources can be
cellular network for certain IP traffic. provided by the cellular network for certain IP
traffic.
REQ#6: The device MUST support the Neighbor Discovery Protocol C_REC#6: The cellular host must support the Neighbor Discovery
([RFC4861] and [RFC5942]). Protocol ([RFC4861] and [RFC5942]).
This is a stronger form compared to what is specified in This is a stronger form compared to what is specified
Section 5.2 and Section 12.2 of [RFC6434]. in Section 5.2 and Section 12.2 of [RFC6434].
The support of Neighbor Discovery Protocol is mandatory in The support of Neighbor Discovery Protocol is mandatory
3GPP cellular environment as it is the only way to convey in 3GPP cellular environment as it is the only way to
IPv6 prefix towards the 3GPP cellular device. convey IPv6 prefix towards the 3GPP cellular device.
In particular, MTU (Maximum Transmission Unit) communication In particular, MTU (Maximum Transmission Unit)
via Router Advertisement MUST be supported since many 3GPP communication via Router Advertisement must be
networks do not have a standard MTU setting. supported since many 3GPP networks do not have a
standard MTU setting.
REQ#7: The cellular host MUST comply with Section 5.6.1 of C_REC#7: The cellular host must comply with Section 5.6.1 of
[RFC6434]. If the MTU used by cellular hosts is larger than [RFC6434]. If the MTU used by cellular hosts is larger
1280 bytes, they can rely on Path MTU discovery function to than 1280 bytes, they can rely on Path MTU discovery
discover the real path MTU. function to discover the real path MTU.
REQ#8: The cellular host MUST support IPv6 Stateless Address C_REC#8: The cellular host must support IPv6 Stateless Address
Autoconfiguration ([RFC4862]) apart from the exceptions noted in Autoconfiguration ([RFC4862]) apart from the exceptions
[TS.23060] (3G) and [TS.23401] (LTE): noted in [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
The GGSN/PGW must allocate a prefix that is unique within its host. The GGSN/PGW must allocate a prefix that is
scope to each primary PDP-Context. unique within its 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
use the Interface Identifier conveyed in 3GPP PDP-Context must use the Interface Identifier conveyed in 3GPP PDP-
setup signaling received from a GGSN/PGW. The cellular host Context setup signaling received from a GGSN/PGW. The
may use a different Interface Identifiers to configure its cellular host may use a different Interface Identifiers
global addresses (see also REQ#23 about privacy addressing to configure its global addresses (see also A_REC#1
requirement). about privacy addressing recommendation).
For more details, refer to [RFC6459] and [RFC7066]. For more details, refer to [RFC6459] and [RFC7066].
REQ#9: The cellular host MUST comply with Section 7.3 of [RFC6434]. C_REC#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 C_REC#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
DNS. information than DNS.
If [RFC6106] is not supported at the network side, the If [RFC6106] is not supported at the network side, the
cellular host SHOULD retrieve DNS information using stateless cellular host should retrieve DNS information using
DHCPv6 [RFC3736]. stateless DHCPv6 [RFC3736].
REQ#11: If the cellular host receives the DNS information in several C_REC#11: If the cellular host receives the DNS information in
channels for the same interface, the following preference order several channels for the same interface, the following
MUST be followed: preference order must be followed:
1. PCO 1. PCO
2. RA 2. RA
3. DHCPv6 3. DHCPv6
REQ#12: The cellular host SHOULD support a method to locally C_REC#12: Because of potential operational deficiencies to be
construct IPv4-embedded IPv6 addresses [RFC6052]. A method to experienced in some roaming situations, the cellular host
learn PREFIX64 SHOULD be supported by 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.
This solves the issue when applications use IPv4 referrals on C_REC#13: In order to ensure IPv4 service continuity in an IPv6-only
IPv6-only access networks. deployment context, the cellular host should support a
method to locally construct IPv4-embedded IPv6 addresses
[RFC6052]. A method to learn PREFIX64 should be supported
by the cellular host.
In PCP-based environments, cellular hosts SHOULD follow This solves the issue when applications use IPv4
[I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used referrals on IPv6-only access networks.
by an upstream PCP-controlled NAT64 device. If PCP is not
enabled, the cellular host SHOULD implement the method
specified in [RFC7050] to retrieve the PREFIX64.
REQ#13: The cellular host SHOULD implement the Customer Side In PCP-based environments, cellular hosts should follow
Translator (CLAT, [RFC6877]) function which is compliant with [RFC7225] to learn the IPv6 Prefix used by an upstream
[RFC6052][RFC6145][RFC6146]. PCP-controlled NAT64 device. If PCP is not enabled,
the cellular host should implement the method specified
in [RFC7050] to retrieve the PREFIX64.
CLAT function in the cellular host allows for IPv4-only C_REC#14: In order to ensure IPv4 service continuity in an IPv6-only
application and IPv4-referals to work on an IPv6-only deployment context, the cellular host should implement the
connectivity. CLAT function requires a NAT64 capability Customer Side Translator (CLAT, [RFC6877]) function which
[RFC6146] in the core network. is compliant with [RFC6052][RFC6145][RFC6146].
REQ#14: The cellular host SHOULD embed a DNS64 function [RFC6147]. CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only
connectivity. CLAT function requires a NAT64
capability [RFC6146] in the core network.
Local DNS64 functionality allows for compatibility with DNS C_REC#15: In order to ensure IPv4 service continuity in an IPv6-only
Security Extensions (DNSSEC, [RFC4033], [RFC4034], deployment context, the cellular host should embed a DNS64
[RFC4035]). Means to configure or discover a PREFIX64 is function [RFC6147].
also required on the cellular device as discussed in REQ#12.
REQ#15: The cellular host SHOULD support PCP [RFC6887]. Local DNS64 functionality allows for compatibility with
DNS Security Extensions (DNSSEC, [RFC4033], [RFC4034],
[RFC4035]). Means to configure or discover a PREFIX64
is also required on the cellular device as discussed in
C_REC#13.
The support of PCP is seen as a driver to save battery C_REC#16: The cellular host should support PCP [RFC6887].
consumption exacerbated by keepalive messages. PCP also
gives the possibility of enabling incoming connections to the
cellular device. Indeed, because several 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.
REQ#16: When the cellular host is dual-stack connected (i.e., The support of PCP is seen as a driver to save battery
configured with an IPv4 address and IPv6 prefix), it SHOULD consumption exacerbated by keepalive messages. PCP
support means to prefer native IPv6 connection over connection also gives the possibility of enabling incoming
established through translation devices (e.g., NAT44 and NAT64). connections to the cellular device. Indeed, because
several 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.
When both IPv4 and IPv6 DNS servers are configured, a dual- C_REC#17: When the cellular host is dual-stack connected (i.e.,
stack host MUST contact first its IPv6 DNS server. configured with an IPv4 address and IPv6 prefix), it
should support means to prefer native IPv6 connection over
connection established through translation devices (e.g.,
NAT44 and NAT64).
Cellular hosts SHOULD follow the procedure specified in When both IPv4 and IPv6 DNS servers are configured, a
[RFC6724] for source address selection. dual-stack host must contact first its IPv6 DNS server.
REQ#17: The cellular host SHOULD support Happy Eyeballs procedure Cellular hosts should follow the procedure specified in
defined in [RFC6555]. [RFC6724] for source address selection.
REQ#18: Because of potential operational deficiencies to be C_REC#18: The cellular host should support Happy Eyeballs procedure
experienced in some roaming situations, the cellular host MUST defined in [RFC6555].
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 Recommendations
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 recommendations:
REQ#19: IPv6 MUST be supported on the WLAN interface. In W_REC#1: IPv6 must be supported on the WLAN interface. In
particular, IPv6-only connectivity MUST be supported over the particular, WLAN interface must behave properly when only
WLAN interface. an IPv6 connectivity is provided.
Some tests revealed that IPv4 configuration is required to Some tests revealed that IPv4 configuration is required
enable IPv6-only connectivity. Indeed, some cellular to 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
first a static IPv4 address. Once the device is connected configuring first a static IPv4 address. Once the
to the network and the wlan0 interface got an IPv6 global device is connected to the network and the wlan0
address, the IPv4 address can be deleted from the interface got an IPv6 global address, the IPv4 address
configuration. This avoids the device to ask automatically can be deleted from the configuration. This avoids the
for a DHCPv4 server, and allows to connect to IPv6-only device to ask automatically for a DHCPv4 server, and
networks. Failing to configure an IPv4 address on the allows to connect to IPv6-only networks. Failing to
interface MUST NOT prohibit using IPv6 on the same configure an IPv4 address on the interface must not
interface. prohibit using IPv6 on the same interface.
IPv6 Stateless Address Autoconfiguration ([RFC4862]) MUST IPv6 Stateless Address Autoconfiguration ([RFC4862])
be supported. must be supported.
REQ#20: DHCPv6 client SHOULD be supported on WLAN interface. W_REC#2: 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 W_REC#3: 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 W_REC#4: 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 Recommendations
REQ#23: The cellular host MUST be able to generate IPv6 addresses This section identifies a set of advanced recommendations to meet
which preserve privacy. regulatory constraints in some countries, fulfill requirements of
critical services such as VoLTE (Voice over LTE), or enforce policies
such as traffic offload.
The activation of privacy extension (e.g., using [RFC4941]) A_REC#1: The cellular host must be able to generate IPv6 addresses
makes it more difficult to track a host over time when which preserve privacy.
compared to using a permanent Interface Identifier. Note,
[RFC4941] does not require any DAD mechanism to be
activated as the GGSN/PGW MUST NOT configure any global
address based on the prefix allocated to the cellular host.
Tracking a host is still possible based on the first 64 The activation of privacy extension (e.g., using
bits of the IPv6 address. Means to prevent against such [RFC4941] or [RFC7217]) makes it more difficult to track
tracking issues may be enabled in the network side. a host over time when compared to using a permanent
Interface Identifier. Note, [RFC4941] does not require
any DAD mechanism to be activated as the GGSN/PGW must
not configure any global address based on the prefix
allocated to the cellular host.
Privacy extensions are required by regulatory bodies in Tracking a host is still possible based on the first 64
some countries. bits of the IPv6 address. Means to prevent against such
tracking issues may be enabled in the network side.
REQ#24: The cellular host MUST support ROHC RTP Profile (0x0001) and Privacy extensions are required by regulatory bodies in
ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other ROHC some countries.
profiles MAY be supported.
Bandwidth in cellular networks must be optimized as much as A_REC#2: The cellular host must support ROHC RTP Profile (0x0001)
possible. ROHC provides a solution to reduce bandwidth and ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other
consumption and to reduce the impact of having bigger ROHC profiles may be supported.
packet headers in IPv6 compared to IPv4.
"RTP/UDP/IP" ROHC profile (0x0001) to compress RTP packets Bandwidth in cellular networks must be optimized as much
and "UDP/IP" ROHC profile (0x0002) to compress RTCP packets as possible. ROHC provides a solution to reduce
are required for Voice over LTE (VoLTE) by IR.92.4.0 bandwidth consumption and to reduce the impact of having
section 4.1 [IR92]. Note, [IR92] indicates also the host bigger packet headers in IPv6 compared to IPv4.
must be able to apply the compression to packets that are
carried over the radio bearer dedicated for the voice
media.
REQ#25: The cellular host MUST comply with Section 5.3 of [RFC6434] "RTP/UDP/IP" ROHC profile (0x0001) to compress RTP
and SHOULD support Router Advertisement extension for packets [RFC3550] and "UDP/IP" ROHC profile (0x0002) to
communicating default router preferences and more-specific compress RTCP packets [RFC3550] are required for Voice
routes as described in [RFC4191]. over LTE (VoLTE) by IR.92.4.0 section 4.1 [IR92]. Note,
[IR92] indicates also the host must be able to apply the
compression to packets that are carried over the radio
bearer dedicated for the voice media.
This function can be used for instance for traffic offload. A_REC#3: The cellular host must comply with Section 5.3 of [RFC6434]
and should support Router Advertisement extension for
communicating default router preferences and more-specific
routes as described in [RFC4191].
4. Cellular Devices with LAN Capabilities This function can be used for instance for traffic
offload.
This section focuses on cellular devices (e.g., CPE, smartphones or 4. Recommendations for Cellular Devices with LAN Capabilities
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 recommendations listed in Section 2, these cellular devices
to meet the requirements listed below. have to meet the recommendations listed below.
REQ#26: The cellular device MUST support Prefix Delegation L_REC#1: The cellular device must support Prefix Delegation
capabilities [RFC3633] and MUST support Prefix Exclude Option capabilities [RFC3633] and must support Prefix Exclude
for DHCPv6-based Prefix Delegation as defined in [RFC6603]. Option for DHCPv6-based Prefix Delegation as defined in
Particularly, it MUST behave as a Requesting Router. [RFC6603]. 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
and multi-link subnet issues to be avoided. prefix and multi-link subnet issues to be avoided.
In case a prefix is delegated to a cellular host using In case a prefix is delegated to a cellular host using
DHCPv6, the cellular device will be configured with two DHCPv6, the cellular device will be configured with two
prefixes: prefixes:
(1) one for 3GPP link allocated using SLAAC mechanism (1) one for 3GPP link allocated using SLAAC mechanism
and and
(2) another one delegated for LANs acquired during (2) another one delegated for LANs acquired during
Prefix Delegation operation. Prefix Delegation operation.
Note that the 3GPP network architecture requires both the Note that the 3GPP network architecture requires both
WAN (Wide Area Network) and the delegated prefix to be the WAN (Wide Area Network) and the delegated prefix to
aggregatable, so the subscriber can be identified using a be aggregatable, so the subscriber can be identified
single prefix. using a 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
halving the delegated prefix and assigning the WAN prefix (e.g., halving the delegated prefix and assigning the
out of the 1st half and the prefix to be delegated to the WAN prefix out of the 1st half and the prefix to be
terminal from the 2nd half). delegated to the terminal from the 2nd half).
REQ#27: The cellular device MUST be compliant with the CPE L_REC#2: The cellular CPE must be compliant with the requirements
requirements specified in [RFC6204]. specified in [RFC6204].
There are several deployments, particularly in emerging There are several deployments, particularly in emerging
countries, that relies on mobile networks to provide countries, that relies on mobile networks to provide
broadband services (e.g., customers are provided with broadband services (e.g., customers are provided with
mobile CPEs). mobile CPEs).
REQ#28: For deployments requiring to share the same /64 prefix, the L_REC#3: For deployments requiring to share the same /64 prefix, the
cellular device SHOULD support [I-D.ietf-v6ops-64share] to cellular device should support [RFC7278] to enable sharing
enable sharing a /64 prefix between the 3GPP interface towards a /64 prefix between the 3GPP interface towards the GGSN/
the GGSN/PGW (WAN interface) and the LAN interfaces. PGW (WAN interface) and the LAN interfaces.
REQ#29: The cellular device SHOULD support the Customer Side L_REC#4: In order to ensure IPv4 service continuity in an IPv6-only
Translator (CLAT) [RFC6877]. deployment context, the cellular device should support the
Customer Side Translator (CLAT) [RFC6877].
Various IP devices are likely to be connected to cellular Various IP devices are likely to be connected to
device, acting as a CPE. Some of these devices can be cellular device, acting as a CPE. Some of these devices
dual-stack, others are IPv6-only or IPv4-only. IPv6-only can be dual-stack, others are IPv6-only or IPv4-only.
connectivity for cellular device does not allow IPv4-only IPv6-only connectivity for cellular device does not
sessions to be established for hosts connected on the LAN allow IPv4-only sessions to be established for hosts
segment of cellular devices. connected on the LAN 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
in the cellular device. As elaborated in Section 2, the function in the cellular device. As elaborated in
CLAT function allows also IPv4 applications to continue Section 2, the CLAT function allows also IPv4
running over an IPv6-only host. applications to continue running over an IPv6-only host.
REQ#30: If a RA MTU is advertised from the 3GPP network, the L_REC#5: 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
the downstream attached LAN devices in RA. to 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
nodes transmit packets that do not exceed the MTU size of end nodes transmit packets that do not exceed the MTU
the mobile network's GTP tunnels. size of 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 Recommendations
REQ#31: Name resolution libraries MUST support both IPv4 and IPv6. The use of address family dependent APIs (Application Programming
Interfaces) or hard-coded IPv4 address literals may lead to broken
applications when IPv6 connectivity is in use. This section
identifies a set of recommendations aiming to minimize broken
applications when the cellular device is attached to an IPv6 network.
In particular, the cellular host MUST support [RFC3596]. APP_REC#1: Name resolution libraries must support both IPv4 and
IPv6.
REQ#32: Applications provided by the mobile device vendor MUST be In particular, the cellular host must support
independent of the underlying IP address family. [RFC3596].
This means applications must be IP version agnostic. APP_REC#2: Applications provided by the mobile device vendor must be
independent of the underlying IP address family.
REQ#33: Applications provided by the mobile device vendor that use This means applications must be IP version agnostic.
URIs MUST follow [RFC3986]. For example, SIP applications
MUST follow the correction defined in [RFC5954]. 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].
6. Security Considerations 6. Security Considerations
The security considerations identified in [RFC7066] and [RFC6459] are The security considerations identified in [RFC7066] and [RFC6459] are
to be taken into account. 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].
Address privacy considerations are discussed in [RFC4941] [RFC7217].
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, N. Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh,
Heatley, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt for the N. Heatley, E. Kline, S. Josefsson, A. Baryun, and J. Woodyatt
discussion in the v6ops mailing list. for the discussion in the v6ops mailing list.
Special thanks to T. Savolainen and J. Korhonen for the detailed Special thanks to T. Savolainen, J. Korhonen, and J. Jaeggli for
review. their detailed reviews and comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March
2011, <http://www.gsma.com/newsroom/
ir-92-v4-0-ims-profile-for-voice-and-sms>.
[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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
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
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, March Header Compression (ROHC) Framework", RFC 5795, March
2010. 2010.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010. Prefixes", RFC 5942, July 2010.
[RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential [RFC5954] Gurbani, V., Carpenter, B., and B. Tate, "Essential
Correction for IPv6 ABNF and URI Comparison in RFC 3261", Correction for IPv6 ABNF and URI Comparison in RFC 3261",
RFC 5954, August 2010. RFC 5954, August 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[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.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
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,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, [RFC7066] Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan,
"IPv6 for Third Generation Partnership Project (3GPP) "IPv6 for Third Generation Partnership Project (3GPP)
Cellular Hosts", RFC 7066, November 2013. Cellular Hosts", RFC 7066, November 2013.
[TS.23060]
3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", September 2011.
[TS.23401]
3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", September 2011.
[TS.24008]
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", June 2011.
9.2. Informative References 9.2. Informative References
[I-D.ietf-pcp-nat64-prefix64] [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Boucadair, M., "Learning NAT64 PREFIX64s using Port A., Peterson, J., Sparks, R., Handley, M., and E.
Control Protocol (PCP)", draft-ietf-pcp-nat64-prefix64-06 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
(work in progress), February 2014. June 2002.
[I-D.ietf-v6ops-64share] [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Byrne, C., Drown, D., and V. Ales, "Extending an IPv6 /64 Jacobson, "RTP: A Transport Protocol for Real-Time
Prefix from a 3GPP Mobile Interface to a LAN link", draft- Applications", STD 64, RFC 3550, July 2003.
ietf-v6ops-64share-09 (work in progress), October 2013.
[IR92] GSMA, "IR.92.V4.0 - IMS Profile for Voice and SMS", March [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
2011, <http://www.gsma.com/newsroom/ (DHCP) Service for IPv6", RFC 3736, April 2004.
ir-92-v4-0-ims-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.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January Residential IPv6 Internet Service", RFC 6092, January
2011. 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[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. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011. 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., [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012. RFC 6459, January 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation", RFC
6877, April 2013. 6877, April 2013.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013. 2013.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013. 7050, November 2013.
[TS.23060] [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
3GPP, "General Packet Radio Service (GPRS); Service Interface Identifiers with IPv6 Stateless Address
description; Stage 2", September 2011. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[TS.23401] [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
3GPP, "General Packet Radio Service (GPRS) enhancements Port Control Protocol (PCP)", RFC 7225, May 2014.
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access", September 2011. [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
2014.
[TS.23402] [TS.23402]
3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP, "Architecture enhancements for non-3GPP accesses",
September 2011. September 2011.
[TS.24008]
3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3", June 2011.
[TS.29060]
3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
September 2011.
[TS.29274]
3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", June 2011.
[TS.29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
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
 End of changes. 128 change blocks. 
391 lines changed or deleted 425 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/