draft-ietf-v6ops-mobile-device-profile-18.txt | draft-ietf-v6ops-mobile-device-profile-19.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: August 22, 2015 A. Vizdal | Expires: August 27, 2015 A. Vizdal | |||
Deutsche Telekom AG | Deutsche Telekom AG | |||
G. Chen | G. Chen | |||
China Mobile | China Mobile | |||
N. Heatley | N. Heatley | |||
EE | EE | |||
R. Chandler | R. Chandler | |||
eircom | meteor | eircom | meteor | |||
D. Michaud | D. Michaud | |||
Rogers Communications | Rogers Communications | |||
D. Lopez | D. Lopez | |||
Telefonica I+D | Telefonica I+D | |||
February 18, 2015 | February 23, 2015 | |||
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-18 | draft-ietf-v6ops-mobile-device-profile-19 | |||
Abstract | Abstract | |||
This document defines a profile that is a superset of that of the | This document defines a profile that is a superset of that of the | |||
connection to IPv6 cellular networks defined in the IPv6 for Third | connection to IPv6 cellular networks defined in the IPv6 for Third | |||
Generation Partnership Project (3GPP) Cellular Hosts document. This | Generation Partnership Project (3GPP) Cellular Hosts document. This | |||
document defines an IPv6 profile that a number of operators recommend | document defines an IPv6 profile that a number of operators recommend | |||
in order to connect 3GPP mobile devices to an IPv6-only or dual-stack | in order to connect 3GPP mobile devices to an IPv6-only or dual-stack | |||
wireless network (including 3GPP cellular network) with a special | wireless network (including 3GPP cellular network) with a special | |||
focus on IPv4 service continuity features. | focus on IPv4 service continuity features. | |||
skipping to change at page 2, line 4 | skipping to change at page 2, line 4 | |||
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 August 22, 2015. | This Internet-Draft will expire on August 27, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 28 | skipping to change at page 2, line 28 | |||
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Connectivity Recommendations . . . . . . . . . . . . . . . . 6 | 2. Connectivity Recommendations . . . . . . . . . . . . . . . . 6 | |||
3. Recommendations for Cellular Devices with LAN Capabilities . 9 | 3. Recommendations for Cellular Devices with LAN Capabilities . 9 | |||
4. Advanced Recommendations . . . . . . . . . . . . . . . . . . 11 | 4. Advanced Recommendations . . . . . . . . . . . . . . . . . . 12 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 16 | 8.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
1. Introduction | 1. Introduction | |||
IPv6 deployment in 3GPP mobile networks is the only perennial | IPv6 deployment in 3GPP mobile networks is the only perennial | |||
solution to the exhaustion of IPv4 addresses in those networks. | solution to the exhaustion of IPv4 addresses in those networks. | |||
Several mobile operators have already deployed IPv6 [RFC2460] or are | Several mobile operators have already deployed IPv6 [RFC2460] or are | |||
in the pre-deployment phase. One of the major hurdles as perceived | in the pre-deployment phase. One of the major hurdles as perceived | |||
by some mobile operators is the availability of non-broken IPv6 | by some mobile operators is the availability of non-broken IPv6 | |||
implementation in mobile devices (e.g., Section 3.3 of [OECD]). | implementation in mobile devices (e.g., Section 3.3 of [OECD]). | |||
skipping to change at page 3, line 36 | skipping to change at page 3, line 36 | |||
The recommendations 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]. IPv6-only considerations in mobile networks are | |||
further discussed in [RFC6342]. | ||||
This document is organized as follows: | This document is organized as follows: | |||
o Section 2 lists generic recommendations including functionalities | o Section 2 lists generic recommendations including functionalities | |||
to provide IPv4 service continuity over an IPv6-only connectivity. | to provide IPv4 service continuity over an IPv6-only connectivity. | |||
o Section 3 enumerates a set of recommendations for cellular devices | o Section 3 enumerates a set of recommendations for cellular devices | |||
with LAN capabilities (e.g., CPE, dongles with tethering | with LAN capabilities (e.g., CPE, dongles with tethering | |||
features). | features). | |||
o Section 4 identifies a set of advanced recommendations to fulfill | o Section 4 identifies a set of advanced recommendations to fulfill | |||
requirements of critical services such as VoLTE (Voice over LTE). | requirements of critical services such as VoLTE (Voice over LTE). | |||
1.1. Terminology | 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. | |||
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 "IPv4 service continuity" denotes the features used to provide | o "IPv4 service continuity" denotes the features used to provide | |||
access to IPv4-only services to customers serviced with an | access to IPv4-only services to customers serviced with an | |||
IPv6-only connectivity. A typical example of IPv4 service | IPv6-only connectivity. A typical example of IPv4 service | |||
continuity technique is NAT64 [RFC6146]. | continuity technique is NAT64 [RFC6146]. | |||
skipping to change at page 4, line 49 | skipping to change at page 4, line 48 | |||
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 recommendations listed below are valid for both 3GPP GPRS and | The recommendations listed below are valid for both 3GPP GPRS and | |||
3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection | 3GPP EPS (Evolved Packet System) access. For EPS, PDN-Connection | |||
term is used instead of PDP-Context. Other non-3GPP accesses | term is used instead of PDP-Context. Other non-3GPP accesses | |||
[TS.23402] are out of scope of this document. | [TS.23402] are out of scope of this document. | |||
This profile is a superset of that of the IPv6 profile for 3GPP | This profile is a superset of that of the IPv6 profile for 3GPP | |||
Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node | Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node | |||
Requirements [RFC6434]. It targets cellular nodes, including GPRS, | Requirements [RFC6434]. It targets cellular nodes, including GPRS | |||
EPC (Evolved Packet Core) and IEEE 802.11 networks, that require | and EPC (Evolved Packet Core), that require features to ensure IPv4 | |||
features to ensure IPv4 service delivery over an IPv6-only transport | service delivery over an IPv6-only transport in addition to the base | |||
in addition to the base IPv6 service. Moreover, this profile covers | IPv6 service. Moreover, this profile covers cellular CPEs that are | |||
cellular CPEs that are used in various deployments to offer fixed- | used in various deployments to offer fixed-like services. | |||
like services. Recommendations inspired from real deployment | ||||
experiences (e.g., roaming) are included in this profile. Also, this | Recommendations inspired from real deployment experiences (e.g., | |||
profile sketches recommendations for the sake of deterministic | roaming) are included in this profile. Also, this profile sketches | |||
behaviors of cellular devices when the same configuration information | recommendations for the sake of deterministic behaviors of cellular | |||
is received over several channels. | devices when the same configuration information is received over | |||
several channels. | ||||
For conflicting recommendations in [RFC7066] and [RFC6434] (e.g., | For conflicting recommendations in [RFC7066] and [RFC6434] (e.g., | |||
Neighbor Discovery Protocol), this profile adheres to [RFC7066]. | Neighbor Discovery Protocol), this profile adheres to [RFC7066]. | |||
Indeed, the support of Neighbor Discovery Protocol is mandatory in | Indeed, the support of Neighbor Discovery Protocol is mandatory in | |||
3GPP cellular environment as it is the only way to convey IPv6 prefix | 3GPP cellular environment as it is the only way to convey IPv6 prefix | |||
towards the 3GPP cellular device. In particular, MTU (Maximum | towards the 3GPP cellular device. In particular, MTU (Maximum | |||
Transmission Unit) communication via Router Advertisement must be | Transmission Unit) communication via Router Advertisement must be | |||
supported since many 3GPP networks do not have a standard MTU | supported since many 3GPP networks do not have a standard MTU | |||
setting. | setting. | |||
This profile uses a stronger language for the support of Prefix | This profile uses a stronger language for the support of Prefix | |||
Delegation compared to [RFC7066]. The main motivation is that | Delegation compared to [RFC7066]. The main motivation is that | |||
cellular networks are more and more perceived as an alternative to | cellular networks are more and more perceived as an alternative to | |||
fixed networks for home IP-based services delivery; especially with | fixed networks for home IP-based services delivery; especially with | |||
the advent of smartphones and 3GPP data dongles. There is a need for | the advent of smartphones and 3GPP data dongles. There is a need for | |||
an efficient mechanism to assign shorter prefix than /64 to cellular | an efficient mechanism to assign larger prefixes to cellular hosts so | |||
hosts so that each LAN segment can get its own /64 prefix and multi- | that each LAN segment can get its own /64 prefix and multi-link | |||
link subnet issues to be avoided. The support of this functionality | subnet issues to be avoided. The support of this functionality in | |||
in both cellular and fixed networks is key for fixed-mobile | both cellular and fixed networks is key for fixed-mobile convergence. | |||
convergence. | ||||
The use of address family dependent APIs (Application Programming | The use of address family dependent APIs (Application Programming | |||
Interfaces) or hard-coded IPv4 address literals may lead to broken | Interfaces) or hard-coded IPv4 address literals may lead to broken | |||
applications when IPv6 connectivity is in use. As such, means to | applications when IPv6 connectivity is in use. As such, means to | |||
minimize broken applications when the cellular host is attached to an | minimize broken applications when the cellular host is attached to an | |||
IPv6-only network should be encouraged. Particularly, (1) name | IPv6-only network should be encouraged. Particularly, (1) name | |||
resolution libraries (e.g., [RFC3596]) must support both IPv4 and | resolution libraries (e.g., [RFC3596]) must support both IPv4 and | |||
IPv6; (2) applications must be independent of the underlying IP | IPv6; (2) applications must be independent of the underlying IP | |||
address family; (3) and applications relying upon Uniform Resource | address family; (3) and applications relying upon Uniform Resource | |||
Identifiers (URIs) must follow [RFC3986] and its updates. Note, some | Identifiers (URIs) must follow [RFC3986] and its updates. Note, some | |||
skipping to change at page 6, line 20 | skipping to change at page 6, line 19 | |||
This section identifies the main connectivity recommendations to be | This section identifies the main connectivity recommendations to be | |||
followed by a cellular host to attach to a network using IPv6 in | followed by a cellular host to attach to a network using IPv6 in | |||
addition to what is defined in [RFC6434] and [RFC7066]. Both dual- | addition to what is defined in [RFC6434] and [RFC7066]. Both dual- | |||
stack and IPv6-only deployment models are considered. IPv4 service | stack and IPv6-only deployment models are considered. IPv4 service | |||
continuity features are listed in this section because these are | continuity features are listed in this section because these are | |||
critical for Operators with an IPv6-only deployment model. | critical for Operators with an IPv6-only deployment model. | |||
C_REC#1: In order to allow each operator to select their own | C_REC#1: In order to allow each operator to select their own | |||
strategy regarding IPv6 introduction, the cellular host | strategy regarding IPv6 introduction, the cellular host | |||
must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. | must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060]. | |||
IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends | IPv4, IPv6 or IPv4v6 PDP-Context request acceptance depends | |||
on the cellular network configuration. | on the cellular network configuration. | |||
C_REC#2: The cellular host must comply with the behavior defined in | C_REC#2: The cellular host must comply with the behavior defined in | |||
[TS.23060] [TS.23401] [TS.24008] for requesting a PDP- | [TS.23060] [TS.23401] [TS.24008] for requesting a PDP- | |||
Context type. In particular, the cellular host must | Context type. | |||
request by default an IPv6 PDP-Context if the cellular host | ||||
is IPv6-only and request an IPv4v6 PDP-Context if the | In particular, the cellular host must request by default an | |||
cellular host is dual-stack or when the cellular host is | IPv6 PDP-Context if the cellular host is IPv6-only and | |||
not aware of connectivity types requested by devices | request an IPv4v6 PDP-Context if the cellular host is dual- | |||
connected to it (e.g., cellular host with LAN capabilities | stack or when the cellular host is not aware of | |||
as discussed in Section 3): | connectivity types requested by devices connected to it | |||
(e.g., cellular host with LAN capabilities as discussed in | ||||
Section 3): | ||||
* If the requested IPv4v6 PDP-Context is not supported by | * If the requested IPv4v6 PDP-Context is not supported by | |||
the network, but IPv4 and IPv6 PDP types are allowed, | the network, but IPv4 and IPv6 PDP types are allowed, | |||
then the cellular host will be configured with an IPv4 | then the cellular host will be configured with an IPv4 | |||
address or an IPv6 prefix by the network. It must | address or an IPv6 prefix by the network. It must | |||
initiate another PDP-Context activation in addition to | initiate another PDP-Context activation in addition to | |||
the one already activated for a given APN (Access Point | the one already activated for a given APN (Access Point | |||
Name). | Name). The purpose of initiating a second PDP-Context | |||
is to achieve dual-stack connectivity by means of two | ||||
PDP-Contexts. | ||||
* If the subscription data or network configuration allows | * If the subscription data or network configuration allows | |||
only one IP address family (IPv4 or IPv6), the cellular | only one IP address family (IPv4 or IPv6), the cellular | |||
host must not request a second PDP-Context to the same | host must not request a second PDP-Context to the same | |||
APN for the other IP address family. | APN for the other IP address family. | |||
The text above focuses on the specification part which | The text above focuses on the specification (excerpt from | |||
explains the behavior for requesting IPv6-related PDP- | [TS.23060] [TS.23401] [TS.24008]) which explains the | |||
Context(s). Understanding this behavior is important to | behavior for requesting IPv6-related PDP-Context(s). | |||
avoid having broken IPv6 implementations in cellular | ||||
devices. | ||||
C_REC#3: The cellular host must support the PCO (Protocol | C_REC#3: 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 | cellular host about various services, including DNS | |||
server information. It does not require any specific | server information. It does not require any specific | |||
protocol to be supported and it is already deployed in | protocol to be supported and it is already deployed in | |||
IPv4 cellular networks to convey such DNS information. | IPv4 cellular networks to convey such DNS information. | |||
skipping to change at page 7, line 51 | skipping to change at page 8, line 6 | |||
This feature is useful to drive the behavior of the UE | This feature is useful to drive the behavior of the UE | |||
to be aligned with: (1) service-specific constraints | to be aligned with: (1) service-specific constraints | |||
such as the use of IPv6-only for VoLTE (Voice over LTE), | such as the use of IPv6-only for VoLTE (Voice over LTE), | |||
(2) network conditions with regards to the support of | (2) network conditions with regards to the support of | |||
specific PDP types (e.g., IPv4v6 PDP-Context is not | specific PDP types (e.g., IPv4v6 PDP-Context is not | |||
supported), (3) IPv4 sunset objectives, (4) subscription | supported), (3) IPv4 sunset objectives, (4) subscription | |||
data, etc. | data, etc. | |||
Note, a cellular host changing its connection between an | Note, a cellular host changing its connection between an | |||
IPv6-specific APN and an IPv4-specific APN restarts the | IPv6-specific APN and an IPv4-specific APN will | |||
ongoing applications. This may be considered as a | interrupt related network connections. This may be | |||
brokenness situation. | considered as a brokenness situation by some | |||
applications. | ||||
C_REC#7: Because of potential operational deficiencies to be | C_REC#7: Because of potential operational deficiencies to be | |||
experienced in some roaming situations, the cellular host | experienced in some roaming situations, the cellular host | |||
must be able to be configured with a home PDP-Context | must be able to be configured with a home PDP-Context | |||
type(s) and a roaming PDP-Context type(s). The purpose of | type(s) and a roaming PDP-Context type(s). The purpose of | |||
the of the roaming profile is to limit the PDP type(s) | the roaming profile is to limit the PDP type(s) requested | |||
requested by the cellular host when out of the home | by the cellular host when out of the home network. Note | |||
network. Note that distinct PDP type(s) and APN(s) can be | that distinct PDP type(s) and APN(s) can be configured for | |||
configured for home and roaming cases. | home and roaming cases. | |||
A detailed analysis of roaming failure cases is included | A detailed analysis of roaming failure cases is included | |||
in [RFC7445]. | in [RFC7445]. | |||
C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only | C_REC#8: In order to ensure IPv4 service continuity in an IPv6-only | |||
deployment context, the cellular host should support a | deployment context, the cellular host should support a | |||
method to locally construct IPv4-embedded IPv6 addresses | method to learn PREFIX64(s). | |||
[RFC6052]. A method to learn PREFIX64 should be supported | ||||
by the cellular host. | ||||
This solves the issue when applications use IPv4 | In the context of NAT64, IPv6-enabled applications | |||
referrals on IPv6-only access networks. | relying on address referrals will fail because an | |||
IPv6-only client won't be able to make use of an IPv4 | ||||
address received in a referral. This feature allows to | ||||
solve the referral problem (because an IPv6-enabled | ||||
application can construct IPv4-embedded IPv6 addresses | ||||
[RFC6052]) and, also, to distinguish between | ||||
IPv4-converted IPv6 addresses and native IPv6 addresses. | ||||
In other words, this feature contributes to offload both | ||||
CLAT module (C_REC#9) and NAT64 devices. Refer to | ||||
Section 3 of [RFC7051] for an inventory of the issues | ||||
related to the discovery of PREFIX64(s). | ||||
In PCP-based environments, cellular hosts should follow | In PCP-based environments, cellular hosts should follow | |||
[RFC7225] to learn the IPv6 Prefix used by an upstream | [RFC7225] to learn the IPv6 Prefix used by an upstream | |||
PCP-controlled NAT64 device. If PCP is not enabled, the | PCP-controlled NAT64 device. If PCP is not enabled, the | |||
cellular host should implement the method specified in | cellular host should implement the method specified in | |||
[RFC7050] to retrieve the PREFIX64. | [RFC7050] to retrieve the PREFIX64. | |||
C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only | C_REC#9: In order to ensure IPv4 service continuity in an IPv6-only | |||
deployment context, the cellular host should implement the | deployment context, the cellular host should implement the | |||
Customer Side Translator (CLAT, [RFC6877]) function in | Customer Side Translator (CLAT, [RFC6877]) function in | |||
skipping to change at page 9, line 30 | skipping to change at page 9, line 40 | |||
L_REC#1: The cellular device must support Prefix Delegation | L_REC#1: The cellular device must support Prefix Delegation | |||
capabilities [RFC3633] and must support Prefix Exclude | capabilities [RFC3633] and must support Prefix Exclude | |||
Option for DHCPv6-based Prefix Delegation as defined in | Option for DHCPv6-based Prefix Delegation as defined in | |||
[RFC6603]. Particularly, it must behave as a Requesting | [RFC6603]. Particularly, it must behave as a Requesting | |||
Router. | 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 larger prefixes (other than /64s) to | |||
hosts so that each LAN segment can get its own /64 | cellular hosts so that each LAN segment can get its own | |||
prefix and multi-link subnet issues to be avoided. | /64 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 | Note that the 3GPP network architecture requires both | |||
the WAN (Wide Area Network) and the delegated prefix to | the WAN (Wide Area Network) and the delegated prefix to | |||
be aggregatable, so the subscriber can be identified | be aggregatable, so the subscriber can be identified | |||
using a 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 | (GGSN/PGW) will have to ensure [RFC3633] compliancy | |||
skipping to change at page 17, line 10 | skipping to change at page 17, line 22 | |||
[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. | |||
[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6 | ||||
Deployment", RFC 6342, August 2011. | ||||
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node | [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node | |||
Requirements", RFC 6434, December 2011. | Requirements", RFC 6434, December 2011. | |||
[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. | |||
[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 | |||
End of changes. 21 change blocks. | ||||
55 lines changed or deleted | 69 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |