draft-ietf-v6ops-mobile-device-profile-01.txt | draft-ietf-v6ops-mobile-device-profile-02.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 28, 2013 A. Vizdal | Expires: October 28, 2013 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 27, 2013 | April 26, 2013 | |||
Internet Protocol Version 6 (IPv6) Profile for Mobile Devices | Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices | |||
draft-ietf-v6ops-mobile-device-profile-01 | draft-ietf-v6ops-mobile-device-profile-02 | |||
Abstract | Abstract | |||
This document specifies an IPv6 profile for mobile devices. It lists | This document specifies an IPv6 profile for 3GPP mobile devices. It | |||
the set of features a mobile device is to be compliant with to | lists the set of features a 3GPP mobile device is to be compliant | |||
connect to an IPv6-only or dual-stack mobile network. | with to connect to an IPv6-only or dual-stack wireless network | |||
(including 3GPP cellular network and IEEE 802.11 network). | ||||
This document defines a different profile than the one for general | This document defines a different profile than the one for general | |||
connection to IPv6 mobile networks defined in [RFC3316]. In | connection to IPv6 cellular networks defined in | |||
particular, this document identifies also features to ensure IPv4 | [I-D.ietf-v6ops-rfc3316bis]. In particular, this document identifies | |||
service continuity over an IPv6-only transport. | also features to deliver IPv4 connectivity service over an IPv6-only | |||
transport. | ||||
Both Hosts and devices with LAN capabilities are in scope. | Both hosts and devices with capability to share their WAN (Wide Area | |||
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. | |||
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 28, 2013. | This Internet-Draft will expire on October 28, 2013. | |||
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 | |||
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 | |||
skipping to change at page 2, line 22 | 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. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 11 | 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 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
IPv6 deployment in mobile networks is the only perennial solution to | IPv6 deployment in 3GPP mobile networks is the only perennial | |||
the exhaustion of IPv4 addresses in those networks. Several mobile | solution to the exhaustion of IPv4 addresses in those networks. | |||
operators already deployed IPv6 or are in the pre-deployment phase. | Several mobile operators have already deployed IPv6 or are in the | |||
One of the major hurdles encountered by mobile operators is the | pre-deployment phase. One of the major hurdles encountered by mobile | |||
availability of non-broken IPv6 implementation in mobile devices. | operators is the availability of non-broken IPv6 implementation in | |||
Some vendors are already proposing some mobile devices with a set of | mobile devices. | |||
IPv6 features, but the majority of devices are still lacking IPv6 | ||||
support. | ||||
[RFC3316] lists a set of features to be supported by cellular hosts | [I-D.ietf-v6ops-rfc3316bis] lists a set of features to be supported | |||
to connect to 3GPP cellular networks. Since the publication of that | by cellular hosts to connect to 3GPP mobile networks. In the light | |||
document, new functions have been specified within the 3GPP and the | of recent IPv6 production deployments, additional features to | |||
IETF whilst others have been updated. Moreover, in the light of | facilitate IPv6-only deployments while accessing IPv4-only service | |||
recent IPv6 production deployments, additional features to facilitate | are to be considered. | |||
IPv6-only deployments while accessing IPv4-only service 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 [RFC3316]; in | connection to IPv6 mobile networks defined 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 required 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 mobile context. | implement basic IPv6 features in a cellular context. | |||
o It identifies also features to ensure IPv4 service continuity 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 SDOs (in particular 3GPP | required specifications produced by various Standards Developing | |||
and IETF). The objectives of this effort are: | Organizations (in particular 3GPP and IETF). The objectives of this | |||
effort are: | ||||
1. List in one single document all requirements a mobile device is | 1. List in one single document all requirements a mobile device is | |||
to comply with to connect to an IPv6 or dual stack mobile | to comply with to connect to an IPv6 or dual-stack mobile | |||
network. These requirements cover various network types such as | network. These requirements cover various network types such as | |||
GPRS, EPC or Wi-Fi network. | GPRS (General Packet Radio Service), EPC (Evolved 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 | |||
device vendors. | device vendors. | |||
3. Vendors to be aware of a minimal set of requirements to allow for | 3. Vendors to be aware of a minimal set of requirements to allow for | |||
IPv6 connectivity and IPv4 service continuity (over an IPv6- only | IPv6 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. | requirements. | |||
The requirements do not include 3GPP release details. For more | ||||
information on the 3GPP releases detail, the reader may refer to | ||||
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]. | |||
This document makes use of the terms defined in [RFC6459]. | This document makes use of the terms defined in [RFC6459]. In | |||
addition, the following terms are used: | ||||
o "3GPP cellular host" (or cellular host for short) denotes a 3GPP | ||||
device which can be connected to 3GPP mobile networks or IEEE | ||||
802.11 networks. | ||||
o "3GPP cellular device" (or cellular device for short) refers to a | ||||
cellular host which supports the capability to share its WAN (Wide | ||||
Area Network) connectivity. | ||||
o "Cellular host" and "mobile host" 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.1. Scope | |||
Various types of nodes can be connected to 3GPP networks requiring | A 3GPP mobile network can be used to connect various user equipments | |||
specific functions. Indeed, a 3GPP network can be used to connect | such as a mobile telephone, a CPE (Customer Premises Equipment) or a | |||
user equipment such as a mobile telephone, a CPE or a machine-to- | M2M (machine-to-machine) device. Because of this diversity of | |||
machine (M2M) device. Because of this diversity of terminals, it is | terminals, it is necessary to define a set of IPv6 functionalities | |||
necessary to define a set of IPv6 functionalities valid for any node | valid for any node directly connecting to a 3GPP mobile network. | |||
directly connecting to a 3GPP network. This document describes these | This document describes these functionalities. | |||
functionalities. | ||||
This document is structured to initially provide the generic IPv6 | ||||
requirements which are valid for all nodes, whatever their function | ||||
or service (e.g., SIP [RFC3261]) capability. The document also | ||||
contains, dedicated sections covering specific functionalities the | ||||
specific device types must support (e.g., smartphones, devices | ||||
providing some LAN functions (mobile CPE or broadband dongles)). | ||||
M2M devices profile is out of scope. | This document is structured to provide the generic IPv6 requirements | |||
which are valid for all nodes, whatever their function or service | ||||
(e.g., SIP [RFC3261]) capability. The document also contains, | ||||
dedicated sections covering specific functionalities the specific | ||||
device types must support (e.g., smartphones, devices providing some | ||||
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 access. For EPS, "PDN type" terminology is used instead of "PDP | EPS (Evolved Packet System) access. For EPS, PDN-Connection term is | |||
context". | used instead of PDP-Context. | |||
This document identifies also some WLAN-related IPv6 requirements. | ||||
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 | This document is not a standard. It uses the normative keywords only | |||
for precision. | 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 in addition to the IPv4 PDP | Contexts MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context | |||
context. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance | request acceptance depends on the cellular network | |||
depends on the mobile network configuration. | configuration. | |||
REQ#3: The cellular host MUST comply with the behavior defined in | REQ#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-Context | |||
type. In particular, the cellular host MUST request an IPv6 PDP | type. In particular, the cellular host MUST request by default | |||
context if the cellular host is IPv6-only and requesting an | an IPv6 PDP-Context if the cellular host is IPv6-only and | |||
IPv4v6 PDP context if the cellular host is dual stack or when | requesting an IPv4v6 PDP-Context if the cellular host is dual- | |||
the cellular host is not aware of connectivity types requested | stack or when the cellular host is not aware of connectivity | |||
by devices connected to it (e.g., cellular host with LAN | types requested by devices connected to it (e.g., cellular host | |||
capabilities): | 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 the | |||
network, but IPv4 and IPv6 PDP types are allowed, then the | network, but IPv4 and IPv6 PDP types are allowed, then the | |||
cellular host will be configured with an IPv4 address and/or | cellular host will be configured with an IPv4 address or an | |||
an IPv6 prefix by the network. It MAY initiate another PDP | IPv6 prefix by the network. It MUST initiate another PDP- | |||
request in addition to the one already activated for a given | Context activation in addition to the one already activated | |||
APN. | 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 only | |||
one IP address family (IPv4 or IPv6), the cellular host MUST | one IP address family (IPv4 or IPv6), the cellular host MUST | |||
NOT request a second PDP context to the same APN for the | NOT request a second PDP-Context to the same APN for the | |||
other IP address family. | other IP address family. | |||
The text above focuses on the specification part which explains | The text above focuses on the specification part which explains | |||
the behavior for requesting IPv6-related PDP context(s). | the behavior for requesting IPv6-related PDP-Context(s). | |||
Understanding this behavior is important to avoid having broken | Understanding this behavior is important to avoid having broken | |||
IPv6 implementations in cellular devices. | IPv6 implementations in cellular devices. | |||
REQ#4: The cellular host MUST support the PCO (Protocol | REQ#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 server | |||
information. It does not require any specific protocol to be | information. It does not require any specific protocol to be | |||
supported and it is already deployed in IPv4 cellular | supported and it is already deployed in IPv4 cellular | |||
networks to convey such DNS information. | networks to convey such DNS information. | |||
REQ#5: The cellular host MUST support IPv6 aware Traffic Flow | REQ#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 dedicated | |||
PDP-Context and radio resources can be provided by the mobile | PDP-Context and radio resources can be provided by the | |||
network for certain IP traffic. | cellular network for certain IP traffic. | |||
REQ#6: The device MUST support the Neighbor Discovery Protocol | REQ#6: The device MUST support the Neighbor Discovery Protocol | |||
([RFC4861] and [RFC5942]). | ([RFC4861] and [RFC5942]). | |||
This is a stronger form compared to what is specified in | This is a stronger form compared to what is specified in | |||
Section 12.2 of [RFC6434]. The support of Neighbor Discovery | Section 5.2 and Section 12.2 of [RFC6434]. | |||
Protocol is mandatory in mobile environment as it is the only | ||||
way to convey IPv6 prefix towards the mobile device. | ||||
In particular, MTU communication via Router Advertisement | The support of Neighbor Discovery Protocol is mandatory in | |||
SHOULD be supported since many 3GPP networks do not have a | 3GPP cellular environment as it is the only way to convey | |||
standard MTU setting due to inconsistencies in GTP [RFC3314] | IPv6 prefix towards the 3GPP cellular device. | |||
mobility tunnel infrastructure deployments. | ||||
In particular, MTU (Maximum Transmission Unit) communication | ||||
via Router Advertisement MUST be 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 | ||||
[RFC6434]. If the MTU used by cellular hosts is larger than | ||||
1280 bytes, they can rely on Path MTU discovery function to | ||||
discover the real path MTU. | ||||
REQ#8: The cellular host MUST support IPv6 Stateless Address | REQ#8: The cellular host MUST support IPv6 Stateless Address | |||
Autoconfiguration ([RFC4862]) apart from the exceptions noted in | Autoconfiguration ([RFC4862]) apart from the exceptions noted in | |||
[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 must allocate a prefix that is unique within its | The GGSN must allocate a prefix that is unique within its | |||
scope to each primary PDP context. | scope to each primary PDP-Context. | |||
The cellular host MUST use the interface identifier sent in | To configure its link local address, the cellular host MUST | |||
PDP Context Accept message to configure its link local | use the Interface Identifier conveyed in 3GPP PDP-Context | |||
address. The cellular host may use a different Interface | setup signaling received from a GGSN/PGW. The cellular host | |||
Identifiers to configure its global addresses. | may use a different Interface Identifiers to configure its | |||
global addresses (see also REQ#23 about privacy addressing | ||||
requirement). | ||||
REQ#9: The cellular host must comply with Section 7.3 of [RFC6434]. | For more details, refer to [RFC6459] and | |||
[I-D.ietf-v6ops-rfc3316bis]. | ||||
The support of Router Advertisement Options for DNS | REQ#9: The cellular host MUST comply with Section 7.3 of [RFC6434]. | |||
configuration allows for a consistent method of informing | ||||
cellular hosts about DNS recursive servers across various | ||||
types of access networks. The cellular host SHOULD support | ||||
RA-based DNS information discovery. | ||||
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, the cellular host SHOULD | |||
retrieve DNS information using stateless DHCPv6 [RFC3736]. | retrieve DNS information using stateless DHCPv6 [RFC3736]. | |||
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 | channels for the same interface, the following preference order | |||
order MUST be followed: | MUST be followed: | |||
1. PCP | 1. PCO | |||
2. RA | ||||
3. DHCPv6 | 2. RA | |||
REQ#11: The cellular host SHOULD support a method to locally | 3. DHCPv6 | |||
REQ#12: The cellular host SHOULD support a method to locally | ||||
construct IPv4-embedded IPv6 addresses [RFC6052]. A method to | construct IPv4-embedded IPv6 addresses [RFC6052]. A method to | |||
learn PREFIX64 SHOULD be supported by the cellular host. | learn PREFIX64 SHOULD be supported by the cellular host. | |||
This solves the issue when applications use IPv4 referrals on | This solves the issue when applications use IPv4 referrals on | |||
IPv6-only access networks. | IPv6-only access networks. | |||
In PCP-based environments, cellular hosts SHOULD follow | In PCP-based environments, cellular hosts SHOULD follow | |||
[I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used | [I-D.ietf-pcp-nat64-prefix64] to learn the IPv6 Prefix used | |||
by an upstream PCP-controlled NAT64 device. If PCP is not | by an upstream PCP-controlled NAT64 device. If PCP is not | |||
enabled, the cellular host SHOULD implement the method | enabled, the cellular host SHOULD implement the method | |||
specified in [I-D.ietf-behave-nat64-discovery-heuristic] to | specified in [I-D.ietf-behave-nat64-discovery-heuristic] to | |||
retrieve the PREFIX64. | retrieve the PREFIX64. | |||
REQ#12: The cellular host SHOULD implement the Customer Side | REQ#13: The cellular host SHOULD implement the Customer Side | |||
Translator (CLAT, [I-D.ietf-v6ops-464xlat]) function which is | Translator (CLAT, [RFC6877]) function which is compliant with | |||
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 PDP. | application and IPv4-referals to work on an IPv6-only | |||
CLAT function requires a NAT64 capability [RFC6146] in the | connectivity. CLAT function requires a NAT64 capability | |||
core network. | [RFC6146] in the core network. | |||
REQ#13: The cellular device SHOULD embed a DNS64 function [RFC6147]. | REQ#14: The cellular device SHOULD embed a DNS64 function [RFC6147]. | |||
Local DNS64 functionality allows for compatibility with | Local DNS64 functionality allows for compatibility with DNS | |||
DNSSEC. Means to configure or discover a PREFIX64 is also | Security Extensions (DNSSEC, [RFC4033], [RFC4034], | |||
required on the cellular device. | [RFC4035]). Means to configure or discover a PREFIX64 is | |||
also required on the cellular device as discussed in REQ#12. | ||||
REQ#14: The cellular host SHOULD support PCP [I-D.ietf-pcp-base]. | REQ#15: The cellular host SHOULD support PCP [I-D.ietf-pcp-base]. | |||
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 | |||
gives the possibility of enabling incoming connections to the | gives the possibility of enabling incoming connections to the | |||
user. Indeed, because several stateful devices may be | cellular device. Indeed, because several stateful devices | |||
deployed in mobile networks (e.g., NAT and/or Firewalls), PCP | may be deployed in wireless networks (e.g., NAT and/or | |||
can be used by the cellular host to control network based NAT | Firewalls), PCP can be used by the cellular host to control | |||
and Firewall functions which will reduce per-application | network-based NAT and Firewall functions which will reduce | |||
signaling and save battery consumption. | per-application signaling and save battery consumption. | |||
REQ#15: When the cellular host is dual stack connected, it SHOULD | REQ#16: When the cellular host is dual-stack connected (i.e., | |||
configured with an IPv4 address and IPv6 prefix), it SHOULD | ||||
support means to prefer native IPv6 connection over connection | support means to prefer native IPv6 connection over connection | |||
established through translation devices (e.g., NAT44 and NAT64). | established through translation devices (e.g., NAT44 and NAT64). | |||
When both IPv4 and IPv6 DNS servers are configured, a dual- | ||||
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. | |||
Some potential issues are discussed in | REQ#17: The cellular host SHOULD support Happy Eyeballs procedure | |||
[I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices. | ||||
REQ#16: The cellular host SHOULD support Happy Eyeballs procedure | ||||
defined in [RFC6555]. | defined in [RFC6555]. | |||
REQ#17: The cellular host SHOULD NOT perform Duplicate Address | ||||
Detection (DAD) for these Global IPv6 addresses (as the GGSN or | ||||
PDN-GW must not configure any IPv6 addresses using the prefix | ||||
allocated to the cellular host). Refer to Section 4 for DAD | ||||
considerations on the LAN interface when the 3GPP connection is | ||||
shared. | ||||
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. | |||
2.1. WiFi Connectivity | 2.1. WLAN Connectivity Requirements | |||
It is increasingly common for cellular hosts have a Wi-Fi interface | It is increasingly common for cellular hosts have a WLAN interface in | |||
in addition to their cellular interface. These hosts are likely to | addition to their cellular interface. These hosts are likely to be | |||
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 Wi-Fi 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 | |||
Wi-Fi interface. | WLAN interface. | |||
Recent tests revealed that IPv4 configuration is required | Some tests revealed that IPv4 configuration is required to | |||
to enable IPv6-only connectivity. Indeed, some cellular | enable IPv6-only connectivity. Indeed, some cellular | |||
handsets can access a Wi-Fi IPv6-only network by | handsets can access a WLAN IPv6-only network by configuring | |||
configuring first a static IPv4 address. Once the device | first a static IPv4 address. Once the device is connected | |||
is connected to the network and the wlan0 interface got an | to the network and the wlan0 interface got an IPv6 global | |||
IPv6 global address, the IPv4 address can be deleted from | address, the IPv4 address can be deleted from the | |||
the configuration. This avoids the device to ask | configuration. This avoids the device to ask automatically | |||
automatically for a DHCPv4 server, and allows to connect to | for a DHCPv4 server, and allows to connect to IPv6-only | |||
IPv6-only networks. | networks. Failing to configure an IPv4 address on the | |||
interface MUST NOT prohibit using IPv6 on the same | ||||
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 Wi-Fi 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#21: Wi-Fi interface SHOULD support Router Advertisement Options | REQ#21: WLAN interface SHOULD support Router Advertisement Options | |||
for DNS configuration (See Section Section 7.3 of [RFC6434]). | for DNS configuration (See Section Section 7.3 of [RFC6434]). | |||
If the device receives the DNS information in several channels | ||||
for the same interface, the following preference order MUST be | REQ#22: If the device receives the DNS information in several | |||
followed: | channels for the same interface, the following preference | |||
order MUST be followed: | ||||
1. RA | 1. RA | |||
2. DHCPv6 | 2. DHCPv6 | |||
3. Advanced Requirements | 3. Advanced Requirements | |||
REQ#22: The cellular host must comply with Section 5.6.1 of | REQ#23: The cellular host MUST be able to generate IPv6 addresses | |||
[RFC6434]. If the MTU used by cellular hosts is larger than | which preserve privacy. | |||
1280 bytes, they can rely on Path MTU discovery function to | ||||
discover the real path MTU. | ||||
REQ#23: The cellular host must comply with Section 5.9.3 of | The activation of privacy extension (e.g., using [RFC4941]) | |||
[RFC6434] for the support of the Privacy Extensions for | makes it more difficult to track a host over time when | |||
Stateless Address Autoconfiguration in IPv6. | 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. | ||||
The activation of privacy extension makes it more difficult | Tracking a host is still possible based on the first 64 | |||
to track a host over time when compared to using a | bits of the IPv6 address. Means to prevent against such | |||
permanent interface identifier. [RFC4941] does not require | tracking issues may be enabled in the network side. | |||
any DAD mechanism to be activated as the GGSN (or PDN-GW) | ||||
MUST NOT configure any global address based on the prefix | ||||
allocated to the cellular host. | ||||
REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). | REQ#24: The cellular host MUST support ROHC RTP Profile (0x0001) and | |||
ROHC UDP Profile (0x0002) for IPv6 ([RFC5795]). Other ROHC | ||||
profiles MAY be supported. | ||||
Bandwidth in mobile environments must be optimized as much | Bandwidth in cellular networks must be optimized as much as | |||
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 | ||||
and "UDP/IP" ROHC profile (0x0002) to compress RTCP packets | ||||
are required for Voice 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. | ||||
REQ#25: The cellular host SHOULD support IPv6 Router Advertisement | REQ#25: The cellular host SHOULD support IPv6 Router Advertisement | |||
Flags Options ([RFC5175]). | Flags Options ([RFC5175]). | |||
This is a stronger form compared to what is specified in | This is a stronger form compared to what is specified in | |||
[RFC6434]. The justification is some flags are used by the | [RFC6434]. | |||
GGSN (or PDN-GW) to inform cellular hosts about the | ||||
autoconfiguration process. | ||||
REQ#26: 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 GPRS, UMTS or EPS connection. In addition to | are sharing the same 2G, 3G or LTE connection. In addition to the | |||
the generic requirements listed in Section 2, these cellular devices | generic requirements listed in Section 2, these cellular devices have | |||
have to meet the requirements listed below. | to meet the requirements listed below. | |||
REQ#27: 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 | |||
skipping to change at page 10, line 40 | skipping to change at page 11, line 16 | |||
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 the | |||
WAN and the Delegated Prefix to be aggregatable, so the | WAN (Wide Area Network) and the delegated prefix to be | |||
subscriber can be identified using a single prefix. | aggregatable, so the subscriber can be identified using a | |||
single prefix. | ||||
Without the Prefix Exclude Option, the delegating router | Without the Prefix Exclude Option, the delegating router | |||
(GGSN/PDN-GW) will have to ensure [RFC3633] compliancy | (GGSN/PGW) will have to ensure [RFC3633] compliancy (e.g., | |||
(e.g., halving the Delegated prefix and assigning the WAN | halving the delegated prefix and assigning the WAN prefix | |||
prefix out of the 1st half and the prefix to be delegated | out of the 1st half and the prefix to be delegated to the | |||
to the terminal from the 2nd half). | terminal from the 2nd half). | |||
REQ#28: 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#29: 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 (WAN interface) and the LAN interfaces. | the GGSN (WAN interface) and the LAN interfaces. | |||
REQ#30: The cellular device SHOULD support the Customer Side | REQ#30: The cellular device SHOULD support the Customer Side | |||
Translator (CLAT) [I-D.ietf-v6ops-464xlat]. | 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 | |||
skipping to change at page 11, line 42 | skipping to change at page 12, line 20 | |||
tunnels, the effective MTU is frequently effectively | tunnels, the effective MTU is frequently effectively | |||
reduced to 1440 bytes. While a host may generate packets | reduced to 1440 bytes. While a host may generate packets | |||
with an MTU of 1500 bytes, this results in undesirable | with an MTU of 1500 bytes, this results in undesirable | |||
fragmentation of the GTP IP/UDP packets. | fragmentation of the GTP IP/UDP packets. | |||
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 | ||||
octets to the 3GPP cellular device will prevent the IP | ||||
layer fragmentation within the transport network between | ||||
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#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#33: 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#34: 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 [RFC3316] are to be taken | The security considerations identified in [I-D.ietf-v6ops-rfc3316bis] | |||
into account. | and [RFC6459] are to be taken into account. | |||
REQ#35: If the cellular device provides LAN features, it SHOULD be | REQ#35: If the cellular device provides LAN features, it SHOULD be | |||
compliant with the security requirements specified in | compliant with the security requirements 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, J. Korhonen, M. Mawatari, M. Abrahamsson, P. Vickers, | Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, | |||
V. Kuarsingh, and J. Woodyatt for the discussion in the v6ops | and J. Woodyatt for the discussion in the v6ops mailing list. | |||
mailing list. | ||||
Special thanks to T. Savolainen and J. Korhonen for the detailed | ||||
review. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[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. | |||
[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. | |||
skipping to change at page 14, line 32 | skipping to change at page 15, line 18 | |||
[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. | |||
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-16 (work in | ietf-behave-nat64-discovery-heuristic-17 (work in | |||
progress), March 2013. | progress), April 2013. | |||
[I-D.ietf-mif-happy-eyeballs-extension] | ||||
Chen, G., Williams, C., Wing, D., and A. Yourtchenko, | ||||
"Happy Eyeballs Extension for Multiple Interfaces", draft- | ||||
ietf-mif-happy-eyeballs-extension-02 (work in progress), | ||||
February 2013. | ||||
[I-D.ietf-pcp-base] | [I-D.ietf-pcp-base] | |||
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. | Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. | |||
Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp- | Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp- | |||
base-29 (work in progress), November 2012. | base-29 (work in progress), November 2012. | |||
[I-D.ietf-pcp-nat64-prefix64] | [I-D.ietf-pcp-nat64-prefix64] | |||
Boucadair, M., "Learn NAT64 PREFIX64s using PCP", draft- | Boucadair, M., "Learn NAT64 PREFIX64s using PCP", draft- | |||
ietf-pcp-nat64-prefix64-00 (work in progress), February | ietf-pcp-nat64-prefix64-00 (work in progress), February | |||
2013. | 2013. | |||
[I-D.ietf-v6ops-464xlat] | ||||
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: | ||||
Combination of Stateful and Stateless Translation", draft- | ||||
ietf-v6ops-464xlat-10 (work in progress), February 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", draft-ietf- | |||
v6ops-64share-03 (work in progress), February 2013. | v6ops-64share-04 (work in progress), April 2013. | |||
[I-D.ietf-v6ops-rfc3316bis] | [I-D.ietf-v6ops-rfc3316bis] | |||
Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, | Korhonen, J., Arkko, J., Savolainen, T., and S. Krishnan, | |||
"IPv6 for 3GPP Cellular Hosts", draft-ietf-v6ops- | "IPv6 for 3GPP Cellular Hosts", draft-ietf-v6ops- | |||
rfc3316bis-01 (work in progress), February 2013. | rfc3316bis-01 (work in progress), February 2013. | |||
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third | [IR92] GSMA, , "IR.92.V4.0 - IMS Profile for Voice and SMS", | |||
Generation Partnership Project (3GPP) Standards", RFC | March 2011, <http://www.gsma.com/newsroom/ir-92-v4-0-ims- | |||
3314, September 2002. | profile-for-voice-and-sms>. | |||
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. | [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Wiljakka, "Internet Protocol Version 6 (IPv6) for Some | Rose, "DNS Security Introduction and Requirements", RFC | |||
Second and Third Generation Cellular Hosts", RFC 3316, | 4033, March 2005. | |||
April 2003. | ||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "Resource Records for the DNS Security Extensions", | ||||
RFC 4034, March 2005. | ||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | ||||
Rose, "Protocol Modifications for the DNS Security | ||||
Extensions", RFC 4035, March 2005. | ||||
[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. | |||
[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. | |||
[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. | |||
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: | ||||
Combination of Stateful and Stateless Translation", RFC | ||||
6877, April 2013. | ||||
[TS.23060] | [TS.23060] | |||
3GPP, , "General Packet Radio Service (GPRS); Service | 3GPP, , "General Packet Radio Service (GPRS); Service | |||
description; Stage 2", September 2011. | description; Stage 2", September 2011. | |||
[TS.23401] | [TS.23401] | |||
3GPP, , "General Packet Radio Service (GPRS) enhancements | 3GPP, , "General Packet Radio Service (GPRS) enhancements | |||
for Evolved Universal Terrestrial Radio Access Network | for Evolved Universal Terrestrial Radio Access Network | |||
(E-UTRAN) access", September 2011. | (E-UTRAN) access", September 2011. | |||
[TS.23402] | ||||
3GPP, , "Architecture enhancements for non-3GPP accesses", | ||||
September 2011. | ||||
[TS.24008] | [TS.24008] | |||
3GPP, , "Mobile radio interface Layer 3 specification; | 3GPP, , "Mobile radio interface Layer 3 specification; | |||
Core network protocols; Stage 3", June 2011. | 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. 86 change blocks. | ||||
214 lines changed or deleted | 269 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/ |