draft-ietf-v6ops-mobile-device-profile-00.txt   draft-ietf-v6ops-mobile-device-profile-01.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, 2013 A. Vizdal Expires: September 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 11, 2013 March 27, 2013
Internet Protocol Version 6 (IPv6) Profile for Mobile Devices Internet Protocol Version 6 (IPv6) Profile for Mobile Devices
draft-ietf-v6ops-mobile-device-profile-00 draft-ietf-v6ops-mobile-device-profile-01
Abstract Abstract
This document specifies an IPv6 profile for mobile devices. It lists This document specifies an IPv6 profile for mobile devices. It lists
the set of features a mobile device is to be compliant with to the set of features a mobile device is to be compliant with to
connect to an IPv6-only or dual-stack mobile network. The document connect to an IPv6-only or dual-stack mobile network.
identifies also features to ensure IPv4 service continuity over an
IPv6-only transport. This document defines a different profile than the one for general
connection to IPv6 mobile networks defined in [RFC3316]. In
particular, this document identifies also features to ensure IPv4
service continuity over an IPv6-only transport.
Both Hosts and devices with LAN capabilities are in scope. Both Hosts and devices with LAN capabilities 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 12, 2013. This Internet-Draft will expire on September 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 18 skipping to change at page 2, line 20
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. Why this document is needed? . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Special Language . . . . . . . . . . . . . . . . . . . . 4
1.3. Special Language . . . . . . . . . . . . . . . . . . . . 4
2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 4 2. Connectivity Requirements . . . . . . . . . . . . . . . . . . 4
2.1. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 8 2.1. WiFi Connectivity . . . . . . . . . . . . . . . . . . . . 8
3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 8 3. Advanced Requirements . . . . . . . . . . . . . . . . . . . . 9
4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 9 4. Cellular Devices with LAN Capabilities . . . . . . . . . . . 10
5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 11 5. APIs & Applications . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
IPv6 deployment in mobile networks is the only perennial solution to
the exhaustion of IPv4 addresses in those networks. Several mobile
operators already deployed IPv6 or are in the pre-deployment phase.
One of the major hurdles encountered by mobile operators is the
availability of non-broken IPv6 implementation in mobile devices.
Some vendors are already proposing some mobile devices with a set of
IPv6 features, but the majority of devices are still lacking IPv6
support.
[RFC3316] lists a set of features to be supported by cellular hosts [RFC3316] lists a set of features to be supported by cellular hosts
to connect to 3GPP cellular networks. Since the publication of that to connect to 3GPP cellular networks. Since the publication of that
document, new functions have been specified within the 3GPP and the document, new functions have been specified within the 3GPP and the
IETF whilst others have been updated. Moreover, in the light of IETF whilst others have been updated. Moreover, in the light of
recent IPv6 production deployments, additional features to facilitate recent IPv6 production deployments, additional features to facilitate
IPv6-only deployments while accessing IPv4-only service are to be IPv6-only deployments while accessing IPv4-only service are to be
considered. considered.
A detailed overview of IPv6 support in 3GPP architectures is provided This document defines a different profile than the one for general
in [RFC6459]. connection to IPv6 mobile networks defined in [RFC3316]; in
particular:
This document makes use of the terms defined in [RFC6459].
PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses [RFC6052].
1.1. Why this document is needed? o It lists an extended list of required features while
[I-D.ietf-v6ops-rfc3316bis] identifies issues and explains how to
implement basic IPv6 features in a mobile context.
IPv6 deployment in mobile networks is the only perennial solution to o It identifies also features to ensure IPv4 service continuity over
the exhaustion of IPv4 addresses in those networks. Several mobile an IPv6-only transport.
operators already deployed IPv6 or are in the pre-deployment phase.
One of the major hurdles encountered by mobile operators is the
availability of non-broken IPv6 implementation in mobile devices.
Some vendors are already proposing some mobile devices with a set of
IPv6 features, but the majority of devices are still lacking IPv6
support.
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 SDOs (in particular 3GPP
and IETF). The objectives of this effort are: 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, EPC or Wi-Fi 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).
This document lists the required features while Pointers to some requirements listed in [RFC6434] are included in
[I-D.ietf-v6ops-rfc3316bis] is doing a good job in identifying issues this profile. The justification for using a stronger language
and explaining how to implement basic IPv6 features in a mobile compared to what is specified in [RFC6434] is provided for some
context. Some of the features discussed in requirements.
[I-D.ietf-v6ops-rfc3316bis] are also listed in this document as a
requirement: the main reason is to collect in one single document a
comprehensive list of requirements with the required language.
1.2. Scope Some of the features listed in this profile document require to
activate dedicated functions at the network side. It is out of scope
of this document to list these network-side functions.
A detailed overview of IPv6 support in 3GPP architectures is provided
in [RFC6459].
This document makes use of the terms defined in [RFC6459].
PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses [RFC6052].
1.1. Scope
Various types of nodes can be connected to 3GPP networks requiring Various types of nodes can be connected to 3GPP networks requiring
specific functions. Indeed, a 3GPP network can be used to connect specific functions. Indeed, a 3GPP network can be used to connect
user equipment such as a mobile telephone, a CPE or a machine-to- user equipment such as a mobile telephone, a CPE or a machine-to-
machine (M2M) device. Because of this diversity of terminals, it is machine (M2M) device. Because of this diversity of terminals, it is
necessary to define a set of IPv6 functionalities valid for any node necessary to define a set of IPv6 functionalities valid for any node
directly connecting to a 3GPP network. This document describes these directly connecting to a 3GPP network. This document describes these
functionalities. functionalities.
This document is structured to initially provide the generic IPv6 This document is structured to initially provide the generic IPv6
skipping to change at page 4, line 18 skipping to change at page 4, line 33
contains, dedicated sections covering specific functionalities the contains, dedicated sections covering specific functionalities the
specific device types must support (e.g., smartphones, devices specific device types must support (e.g., smartphones, devices
providing some LAN functions (mobile CPE or broadband dongles)). providing some LAN functions (mobile CPE or broadband dongles)).
M2M devices profile is out of scope. M2M devices profile is out of scope.
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 access. For EPS, "PDN type" terminology is used instead of "PDP
context". context".
1.3. 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 support the IPv6 addressing REQ#1: The cellular host MUST be compliant with Section 5.9.1 (IPv6
architecture described in ([RFC4291]). For address Addressing Architecture) and Section 5.8 (ICMPv6 support) of
representation, [RFC5952] MUST be supported. [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 in addition to the IPv4 PDP
context. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance context. IPv4, IPv6 or IPv4v6 PDP-Context request acceptance
depends on the mobile network configuration. depends on the mobile network configuration.
skipping to change at page 5, line 37 skipping to change at page 6, line 5
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 mobile
network for certain IP traffic. network for certain IP traffic.
REQ#6: The cellular host MUST support ICMPv6 ([RFC4443]). REQ#6: The device MUST support the Neighbor Discovery Protocol
The base protocol MUST be fully implemented by every IPv6
node as indicated in Section 2 of [RFC4443].
REQ#7: 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
Section 12.2 of [RFC6434]. The support of Neighbor Discovery
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 In particular, MTU communication via Router Advertisement
SHOULD be supported since many 3GPP networks do not have a SHOULD be supported since many 3GPP networks do not have a
standard MTU setting due to inconsistencies in GTP [RFC3314] standard MTU setting due to inconsistencies in GTP [RFC3314]
mobility tunnel infrastructure deployments. mobility tunnel infrastructure deployments.
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 The cellular host MUST use the interface identifier sent in
PDP Context Accept message to configure its link local PDP Context Accept message to configure its link local
address. The cellular host may use a different Interface address. The cellular host may use a different Interface
Identifiers to configure its global addresses. Identifiers to configure its global addresses.
REQ#9: The cellular host SHOULD support Router Advertisement Options REQ#9: The cellular host must comply with Section 7.3 of [RFC6434].
[RFC6106] for DNS configuration.
The support of this function allows for a consistent method The support of Router Advertisement Options for DNS
of informing cellular hosts about DNS recursive servers configuration allows for a consistent method of informing
across various types of access networks. The cellular host cellular hosts about DNS recursive servers across various
SHOULD support RA-based DNS information discovery. types of access networks. The cellular host SHOULD support
RA-based DNS information discovery.
REQ#10: The cellular host SHOULD embed a DHCPv6 client [RFC3736]. REQ#10: The cellular host must comply with Section 7.2.1 of
[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 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 MUST be followed: order MUST be followed:
1. PCO 1. PCP
2. RA 2. RA
3. DHCPv6 3. DHCPv6
REQ#11: The cellular host SHOULD support a method to locally REQ#11: 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
skipping to change at page 8, line 35 skipping to change at page 8, line 49
configuring first a static IPv4 address. Once the device configuring first a static IPv4 address. Once the device
is connected to the network and the wlan0 interface got an is connected to the network and the wlan0 interface got an
IPv6 global address, the IPv4 address can be deleted from IPv6 global address, the IPv4 address can be deleted from
the configuration. This avoids the device to ask the configuration. This avoids the device to ask
automatically for a DHCPv4 server, and allows to connect to automatically for a DHCPv4 server, and allows to connect to
IPv6-only networks. IPv6-only networks.
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 Wi-Fi interface.
([RFC3736]).
REQ#21: Wi-Fi interface SHOULD support Router Advertisement Options Refer to Section 7.2.1 of [RFC6434].
for DNS configuration ([RFC6106]). If the device receives the
DNS information in several channels for the same interface,
the following preference order MUST be followed:
REQ#21: REQ#21: Wi-Fi interface SHOULD support Router Advertisement Options
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
followed:
1. RA 1. RA
2. DHCPv6 2. DHCPv6
3. Advanced Requirements 3. Advanced Requirements
REQ#22: The cellular host MUST support Path MTU discovery REQ#22: The cellular host must comply with Section 5.6.1 of
([RFC1981]). If the MTU used by cellular hosts is larger than [RFC6434]. If the MTU used by cellular hosts is larger than
1280 bytes, they can rely on Path MTU discovery function to 1280 bytes, they can rely on Path MTU discovery function to
discover the real path MTU. discover the real path MTU.
REQ#23: The cellular host SHOULD support the Privacy Extensions for REQ#23: The cellular host must comply with Section 5.9.3 of
Stateless Address Autoconfiguration in IPv6 ([RFC4941]). [RFC6434] for the support of the Privacy Extensions for
Stateless Address Autoconfiguration in IPv6.
The activation of privacy extension makes it more difficult The activation of privacy extension makes it more difficult
to track a host over time when compared to using a to track a host over time when compared to using a
permanent interface identifier. [RFC4941] does not require permanent interface identifier. [RFC4941] does not require
any DAD mechanism to be activated as the GGSN (or PDN-GW) any DAD mechanism to be activated as the GGSN (or PDN-GW)
MUST NOT configure any global address based on the prefix MUST NOT configure any global address based on the prefix
allocated to the cellular host. allocated to the cellular host.
REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]). REQ#24: The cellular host SHOULD support ROHC for IPv6 ([RFC5795]).
Bandwidth in mobile environments must be optimized as much Bandwidth in mobile environments must be optimized as much
as possible. ROHC provides a solution to reduce bandwidth as 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.
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]).
Some flags are used by the GGSN (or PDN-GW) to inform This is a stronger form compared to what is specified in
cellular hosts about the autoconfiguration process. [RFC6434]. The justification is some flags are used by the
GGSN (or PDN-GW) to inform cellular hosts about the
autoconfiguration process.
REQ#26: The cellular host SHOULD support Router Advertisement REQ#26: The cellular host must comply with Section 5.3 of [RFC6434]
extension for communicating default router preferences and and SHOULD support Router Advertisement extension for
more-specific routes as described in [RFC4191]. communicating default router preferences and more-specific
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 GPRS, UMTS or EPS connection. In addition to
the generic requirements listed in Section 2, these cellular devices the generic requirements listed in Section 2, these cellular devices
skipping to change at page 10, line 33 skipping to change at page 11, line 5
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/PDN-GW) will have to ensure [RFC3633] compliancy
(e.g., halving the Delegated prefix and assigning the WAN (e.g., halving the Delegated prefix and assigning the WAN
prefix out of the 1st half and the prefix to be delegated prefix out of the 1st half and the prefix to be delegated
to the terminal from the 2nd half). to the 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: Prefix delegation which allows to allocate a shorter prefix REQ#29: For deployments requiring to share the same /64 prefix, the
to a cellular host is only available since 3GPP Release 10.
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) [I-D.ietf-v6ops-464xlat].
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
skipping to change at page 12, line 9 skipping to change at page 12, line 26
[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, J. Korhonen, M. Mawatari, M. Abrahamsson, P. Vickers,
V. Kuarsingh and J. Woodyatt for the discussion in the v6ops V. Kuarsingh, and J. Woodyatt for the discussion in the v6ops
mailing list. mailing list.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[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.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
skipping to change at page 12, line 45 skipping to change at page 13, line 12
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (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 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[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 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
skipping to change at page 13, line 27 skipping to change at page 13, line 34
Flags Option", RFC 5175, March 2008. Flags Option", RFC 5175, March 2008.
[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.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 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, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
skipping to change at page 14, line 5 skipping to change at page 14, line 10
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012. Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012. Delegation", RFC 6603, May 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
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-14 (work in ietf-behave-nat64-discovery-heuristic-16 (work in
progress), February 2013. progress), March 2013.
[I-D.ietf-mif-happy-eyeballs-extension] [I-D.ietf-mif-happy-eyeballs-extension]
Chen, G., Williams, C., Wing, D., and A. Yourtchenko, Chen, G., Williams, C., Wing, D., and A. Yourtchenko,
"Happy Eyeballs Extension for Multiple Interfaces", draft- "Happy Eyeballs Extension for Multiple Interfaces", draft-
ietf-mif-happy-eyeballs-extension-02 (work in progress), ietf-mif-happy-eyeballs-extension-02 (work in progress),
February 2013. 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-
 End of changes. 40 change blocks. 
93 lines changed or deleted 99 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/