draft-ietf-v6ops-mobile-device-profile-19.txt   draft-ietf-v6ops-mobile-device-profile-20.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 27, 2015 A. Vizdal Expires: September 3, 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 23, 2015 March 2, 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-19 draft-ietf-v6ops-mobile-device-profile-20
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 27, 2015. This Internet-Draft will expire on September 3, 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 35 skipping to change at page 2, line 35
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 . . . . . . . . . . . . . . . . . . 12 4. Advanced Recommendations . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 45 skipping to change at page 3, line 46
A detailed overview of IPv6 support in 3GPP architectures is provided A detailed overview of IPv6 support in 3GPP architectures is provided
in [RFC6459]. IPv6-only considerations in mobile networks are in [RFC6459]. IPv6-only considerations in mobile networks are
further discussed in [RFC6342]. 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., CE Routers, 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:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
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].
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.2. Scope 1.2. Scope
A 3GPP mobile network can be used to connect various user equipments A 3GPP mobile network can be used to connect various user equipments
such as a mobile telephone, a CPE (Customer Premises Equipment) or a such as a mobile telephone or a Customer Edge Routers. Because of
machine-to-machine (M2M) device. Because of this diversity of this diversity of terminals, it is necessary to define a set of IPv6
terminals, it is necessary to define a set of IPv6 functionalities functionalities valid for any node directly connecting to a 3GPP
valid for any node directly connecting to a 3GPP mobile network. mobile network. This document describes these functionalities.
This document describes these functionalities.
Machine-to-machine (M2M) devices profile is out of scope.
This document is structured to provide the generic IPv6 This document is structured to provide the generic IPv6
recommendations which are valid for all nodes, whatever their recommendations which are valid for all nodes, whatever their
function (e.g., host or CPE) or service (e.g., Session Initiation function (e.g., host or CE router) or service (e.g., Session
Protocol (SIP, [RFC3261])) capability. The document also contains Initiation Protocol (SIP, [RFC3261])) capability. The document also
sections covering specific functionalities for devices providing some contains sections covering specific functionalities for devices
LAN functions (e.g., mobile CPE or broadband dongles). providing some LAN functions (e.g., mobile CE router 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
and EPC (Evolved Packet Core), that require features to ensure IPv4 and EPC (Evolved Packet Core), that require features to ensure IPv4
service delivery over an IPv6-only transport in addition to the base service delivery over an IPv6-only transport in addition to the base
IPv6 service. Moreover, this profile covers cellular CPEs that are IPv6 service. Moreover, this profile also covers cellular CE routers
used in various deployments to offer fixed-like services. that are used in various deployments to offer fixed-like services.
Recommendations inspired from real deployment experiences (e.g., Recommendations inspired from real deployment experiences (e.g.,
roaming) are included in this profile. Also, this profile sketches roaming) are included in this profile. Also, this profile sketches
recommendations for the sake of deterministic behaviors of cellular recommendations for the sake of deterministic behaviors of cellular
devices when the same configuration information is received over devices when the same configuration information is received over
several channels. 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
IPv6-only mode [RFC6146]. IPv6-only mode [RFC6146].
The IPv4 Service Continuity Prefix used by CLAT is The IPv4 Service Continuity Prefix used by CLAT is
defined in [RFC7335]. defined in [RFC7335].
CLAT and/or NAT64 do not interfere with native IPv6 CLAT and/or NAT64 do not interfere with native IPv6
communications. communications.
3. Recommendations for Cellular Devices with LAN Capabilities 3. Recommendations for Cellular Devices with LAN Capabilities
This section focuses on cellular devices (e.g., CPE, smartphones, or This section focuses on cellular devices (e.g., CE router,
dongles with tethering features) which provide IP connectivity to smartphones, or dongles with tethering features) which provide IP
other devices connected to them. In such case, all connected devices connectivity to other devices connected to them. In such case, all
are sharing the same 2G, 3G or LTE connection. In addition to the connected devices are sharing the same 2G, 3G or LTE connection. In
generic recommendations listed in Section 2, these cellular devices addition to the generic recommendations listed in Section 2, these
have to meet the recommendations listed below. cellular devices have to meet the recommendations listed below.
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
skipping to change at page 10, line 22 skipping to change at page 10, line 22
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
(e.g., halving the delegated prefix and assigning the (e.g., halving the delegated prefix and assigning the
WAN prefix out of the 1st half and the prefix to be WAN prefix out of the 1st half and the prefix to be
delegated to the terminal from the 2nd half). delegated to the terminal from the 2nd half).
Because Prefix Delegation capabilities may not be Because Prefix Delegation capabilities may not be
available in some attached networks, L_REC#3 is strongly available in some attached networks, L_REC#3 is strongly
recommended to accommodate early deployments. recommended to accommodate early deployments.
L_REC#2: The cellular CPE must be compliant with the requirements L_REC#2: The cellular CE router must be compliant with the
specified in [RFC7084]. requirements specified in [RFC7084].
There are several deployments, particularly in emerging There are several deployments, particularly in emerging
countries, that relies on mobile networks to provide countries, that relies on mobile networks to provide
broadband services (e.g., customers are provided with broadband services (e.g., customers are provided with
mobile CPEs). mobile CE routers).
Note, this profile does not require IPv4 service Note, this profile does not require IPv4 service
continuity techniques listed in [RFC7084] because those continuity techniques listed in [RFC7084] because those
are specific to fixed networks. IPv4 service continuity are specific to fixed networks. IPv4 service continuity
techniques specific to the mobile networks are included techniques specific to the mobile networks are included
in this profile. in this profile.
This recommendation does not apply to handsets with This recommendation does not apply to handsets with
tethering capabilities; it is specific to cellular CPEs tethering capabilities; it is specific to cellular CE
in order to ensure the same IPv6 functional parity for routers in order to ensure the same IPv6 functional
both fixed and cellular CPEs. Note, modern CPEs are parity for both fixed and cellular CE routers. Note,
designed with advanced functions such as link modern CE routers are designed with advanced functions
aggregation that consists in optimizing the network such as link aggregation that consists in optimizing the
usage by aggregating the connectivity resources offered network usage by aggregating the connectivity resources
via various interfaces (e.g., DSL, LTE, WLAN, etc.) or offered via various interfaces (e.g., DSL, LTE, WLAN,
offloading the traffic via a subset of interfaces. etc.) or offloading the traffic via a subset of
Mutualizing IPv6 features among these interface types is interfaces. Mutualizing IPv6 features among these
important for the sake of specification efficiency, interface types is important for the sake of
service design simplification and validation effort specification efficiency, service design simplification
optimization. and validation effort optimization.
L_REC#3: For deployments requiring to share the same /64 prefix, the L_REC#3: For deployments requiring to share the same /64 prefix, the
cellular device should support [RFC7278] to enable sharing cellular device should support [RFC7278] to enable sharing
a /64 prefix between the 3GPP interface towards the GGSN/ a /64 prefix between the 3GPP interface towards the GGSN/
PGW (WAN interface) and the LAN interfaces. PGW (WAN interface) and the LAN interfaces.
Prefix Delegation (refer to L_REC#1) is the target Prefix Delegation (refer to L_REC#1) is the target
solution for distributing prefixes in the LAN side but, solution for distributing prefixes in the LAN side but,
because the device may attach to earlier 3GPP release because the device may attach to earlier 3GPP release
networks, a mean to share a /64 prefix is also networks, a mean to share a /64 prefix is also
recommended [RFC7278]. recommended [RFC7278].
[RFC7278] must be invoked only if Prefix Delegation is [RFC7278] must be invoked only if Prefix Delegation is
not in use. not in use.
L_REC#4: In order to allow IPv4 service continuity in an IPv6-only L_REC#4: In order to allow IPv4 service continuity in an IPv6-only
deployment context, the cellular device should support the deployment context, the cellular device should support the
Customer Side Translator (CLAT) [RFC6877]. Customer Side Translator (CLAT) [RFC6877].
Various IP devices are likely to be connected to Various IP devices are likely to be connected to
cellular device, acting as a CPE. Some of these devices cellular device, acting as a CE router. Some of these
can be dual-stack, others are IPv6-only or IPv4-only. devices can be dual-stack, others are IPv6-only or
IPv6-only connectivity for cellular device does not IPv4-only. IPv6-only connectivity for cellular device
allow IPv4-only sessions to be established for hosts does not allow IPv4-only sessions to be established for
connected on the LAN segment of cellular devices. hosts connected on the LAN segment of cellular devices.
In order to allow IPv4 sessions establishment initiated In order to allow IPv4 sessions establishment initiated
from devices located on LAN segment side and target IPv4 from devices located on LAN segment side and target IPv4
nodes, a solution consists in integrating the CLAT nodes, a solution consists in integrating the CLAT
function in the cellular device. As elaborated in function in the cellular device. As elaborated in
Section 2, the CLAT function allows also IPv4 Section 2, the CLAT function allows also IPv4
applications to continue running over an IPv6-only applications to continue running over an IPv6-only
device. device.
The cellular host should only invoke the CLAT in the The cellular host should only invoke the CLAT in the
skipping to change at page 14, line 10 skipping to change at page 14, line 10
This preference allows to offload IPv4-only DNS servers. This preference allows to offload IPv4-only DNS servers.
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.
5. Security Considerations 5. Security Considerations
The security considerations identified in [RFC7066] and [RFC6459] are The security considerations identified in [RFC7066] and [RFC6459] are
to be taken into account. to be taken into account.
In the case of cellular CPEs, compliance with L_REC#2 entails In the case of cellular CE routers, compliance with L_REC#2 entails
compliance with [RFC7084], which in turn recommends compliance with compliance with [RFC7084], which in turn recommends compliance with
Recommended Simple Security Capabilities in Customer Premises Recommended Simple Security Capabilities in Customer Premises
Equipment (CPE) for Providing Residential IPv6 Internet Service Equipment (CPE) for Providing Residential IPv6 Internet Service
[RFC6092]. Therefore, the security considerations in Section 6 of [RFC6092]. Therefore, the security considerations in Section 6 of
[RFC6092] are relevant. In particular, it bears repeating here that [RFC6092] are relevant. In particular, it bears repeating here that
the true impact of stateful filtering may be a reduction in security, the true impact of stateful filtering may be a reduction in security,
and that IETF make no statement, expressed or implied, as to whether and that IETF make no statement, expressed or implied, as to whether
using the capabilities described in any of these documents ultimately using the capabilities described in any of these documents ultimately
improves security for any individual users or for the Internet improves security for any individual users or for the Internet
community as a whole. community as a whole.
 End of changes. 15 change blocks. 
44 lines changed or deleted 46 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/