One document matched: draft-ietf-v6ops-mobile-device-profile-24.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="info" docName="draft-ietf-v6ops-mobile-device-profile-24"
ipr="trust200902" updates="">
<front>
<title abbrev="IPv6 Profile for Cellular Devices">An Internet Protocol
Version 6 (IPv6) Profile for 3GPP Mobile Devices</title>
<author fullname="David Binet" initials="D." surname="Binet">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>david.binet@orange.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Ales Vizdal" initials="A." surname="Vizdal">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country></country>
</postal>
<phone></phone>
<email>ales.vizdal@t-mobile.cz</email>
<uri></uri>
</address>
</author>
<author fullname="Gang Chen" initials="G." surname="Chen">
<organization>China Mobile</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>phdgang@gmail.com</email>
</address>
</author>
<author fullname="Nick Heatley" initials="N." surname="Heatley">
<organization>EE</organization>
<address>
<postal>
<street>The Point, 37 North Wharf Road,</street>
<city>London</city>
<region></region>
<code>W2 1AG</code>
<country>U.K</country>
</postal>
<email>nick.heatley@ee.co.uk</email>
</address>
</author>
<author fullname="Ross Chandler" initials="R." surname="Chandler">
<organization>eircom | meteor</organization>
<address>
<postal>
<street>1HSQ</street>
<street>St. John’s Road</street>
<city>Dublin 8</city>
<region></region>
<code></code>
<country>Ireland</country>
</postal>
<phone></phone>
<email>ross@eircom.net</email>
</address>
</author>
<author fullname="Dave Michaud " initials="D." surname="Michaud">
<organization>Rogers Communications</organization>
<address>
<postal>
<street>8200 Dixie Rd.</street>
<city>Brampton, ON L6T 0C1</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>dave.michaud@rci.rogers.com</email>
<uri></uri>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego.r.lopez@telefonica.com</email>
</address>
</author>
<author fullname="Walter Haeffner" initials="W." surname="Haeffner">
<organization abbrev="Vodafone">Vodafone D2 GmbH</organization>
<address>
<postal>
<street>Ferdinand-Braun-Platz 1</street>
<region>Duesseldorf</region>
<code>40549</code>
<country>DE</country>
</postal>
<email>walter.haeffner@vodafone.com</email>
</address>
</author>
<date />
<abstract>
<t>This document defines a profile that is a superset of that of the
connection to IPv6 cellular networks defined in the IPv6 for Third
Generation Partnership Project (3GPP) Cellular Hosts document. This
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
wireless network (including 3GPP cellular network) with a special focus
on IPv4 service continuity features.</t>
<t>Both mobile hosts and mobile devices with capability to share their
3GPP mobile connectivity are in scope.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv6 deployment in Third Generation Partnership Project (3GPP) mobile
networks is the only viable solution to the exhaustion of IPv4 addresses
in those networks. Several mobile operators have already deployed IPv6
<xref target="RFC2460"></xref> or are in the pre-deployment phase. One
of the major hurdles as perceived by some mobile operators is the lack
of availability of working IPv6 implementation in mobile devices (e.g.,
Section 3.3 of <xref target="OECD"></xref>).</t>
<t><xref target="RFC7066"></xref> lists a set of features to be
supported by cellular hosts to connect to 3GPP mobile networks. In the
light of recent IPv6 production deployments, additional features to
facilitate IPv6-only deployments while accessing IPv4-only services
should be considered. This document fills this void. Concretely, this
document lists means to ensure IPv4 service over an IPv6-only
connectivity given the adoption rate of this model by mobile operators.
Those operators require that no service degradation is experienced by
customers serviced with an IPv6-only model compared to the level of
service of customers with legacy IPv4-only devices.</t>
<t>This document defines an IPv6 profile for mobile devices listing
specifications produced by various Standards Developing Organizations
(including 3GPP, IETF, and GSMA). The objectives of this effort
are:<list style="numbers">
<t>List in one single document a comprehensive list of IPv6 features
for a mobile device, including both IPv6-only and dual-stack mobile
deployment contexts. These features cover various packet core
architectures such as GPRS (General Packet Radio Service) or EPC
(Evolved Packet Core).</t>
<t>Help Operators with the detailed device requirement list
preparation (to be exchanged with device suppliers). This is also a
contribution to harmonize Operators’ requirements towards
device vendors.</t>
<t>Vendors to be aware of a set of features to allow for IPv6
connectivity and IPv4 service continuity (over an IPv6-only
transport).</t>
</list></t>
<!--
-->
<t>The recommendations do not include 3GPP release details. For more
information on the 3GPP releases detail, the reader may refer to Section
6.2 of <xref target="RFC6459"></xref>. More details can be found at
<xref target="R3GPP"></xref>.</t>
<t>Some of the features listed in this profile document could require to
activate dedicated functions at the network side. It is out of scope of
this document to list these network-side functions.</t>
<t>A detailed overview of IPv6 support in 3GPP architectures is provided
in <xref target="RFC6459"></xref>. IPv6-only considerations in mobile
networks are further discussed in <xref target="RFC6342"></xref>.</t>
<t>This document is organized as follows:<list style="symbols">
<t><xref target="generic"></xref> lists generic recommendations
including functionalities to provide IPv4 service over an IPv6-only
connectivity.</t>
<t><xref target="cpe"></xref> enumerates a set of recommendations
for cellular devices with Local Area Network (LAN) capabilities
(e.g., CE routers (Customer Edge routers) with cellular access link,
dongles with tethering features).</t>
<t><xref target="adv"></xref> identifies a set of advanced
recommendations to fulfill requirements of critical services such as
VoLTE (Voice over Long Term Evolution (LTE)).</t>
</list></t>
<section title="Terminology">
<t>This document makes use of the terms defined in <xref
target="RFC6459"></xref>. In addition, the following terms are
used:<list style="symbols">
<t>3GPP cellular host (or cellular host for short): denotes a 3GPP
device which can be connected to 3GPP mobile networks.</t>
<t>3GPP cellular device (or cellular device for short): refers to
a cellular host which supports the capability to share its 3GPP
mobile connectivity.</t>
<t>IPv4 service continuity: denotes the features used to provide
access to IPv4-only services to customers serviced with an
IPv6-only connectivity. A typical example of IPv4 service
continuity technique is NAT64 (Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers, <xref
target="RFC6146"></xref>).</t>
</list></t>
<t>PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses <xref target="RFC6052"></xref>.</t>
</section>
<section title="Scope">
<t>A 3GPP mobile network can be used to connect various user
equipments such as a mobile telephone or a CE router. Because of this
diversity of terminals, it is necessary to define a set of IPv6
functionalities valid for any node directly connecting to a 3GPP
mobile network. This document describes these functionalities.</t>
<t>Machine-to-machine (M2M) devices profile is out of scope.</t>
<t>This document is structured to provide the generic IPv6
recommendations which are valid for all nodes, whatever their function
(e.g., host or CE router) or service (e.g., Session Initiation
Protocol (SIP, <xref target="RFC3261"></xref>)) capability. The
document also contains sections covering specific functionalities for
devices providing some LAN functions (e.g., mobile CE router or
broadband dongles).</t>
<t>The recommendations listed below are valid for both 3GPP GPRS and
3GPP EPS (Evolved Packet System). For EPS, PDN-Connection term is used
instead of PDP-Context. Other non-3GPP accesses <xref
target="TS.23402"></xref> are out of scope of this document.</t>
<t>This profile is a superset of that of the IPv6 profile for <xref
target="RFC7066">3GPP Cellular Hosts</xref>, which is in turn a
superset of <xref target="RFC6434">IPv6 Node Requirements</xref>. It
targets cellular nodes, including GPRS and EPC (Evolved Packet Core),
that require features to ensure IPv4 service delivery over an
IPv6-only transport in addition to the base IPv6 service. Moreover,
this profile also covers cellular CE routers that are used in various
mobile broadband deployments. Recommendations inspired from real
deployment experiences (e.g., roaming) are included in this profile.
Also, this profile sketches recommendations for the sake of
deterministic behaviors of cellular devices when the same
configuration information is received over several channels.</t>
<t>For conflicting recommendations in <xref target="RFC7066"></xref>
and <xref target="RFC6434"></xref> (e.g., Neighbor Discovery
Protocol), this profile adheres to <xref target="RFC7066"></xref>.
Indeed, the support of Neighbor Discovery Protocol is mandatory in
3GPP cellular environment as it is the only way to convey IPv6 prefix
towards the 3GPP cellular device. In particular, MTU (Maximum
Transmission Unit) communication via Router Advertisement must be
supported since many 3GPP networks do not have a standard MTU
setting.</t>
<t>This profile uses a stronger language for the support of Prefix
Delegation compared to <xref target="RFC7066"></xref>. The main
motivation is that cellular networks are more and more perceived as an
alternative to fixed networks for home IP-based services delivery;
especially with the advent of smartphones and 3GPP data dongles. There
is a need for an efficient mechanism to assign larger prefixes to
cellular hosts so that each LAN segment can get its own /64 prefix and
multi-link subnet issues to be avoided. The support of this
functionality in both cellular and fixed networks is key for
fixed-mobile convergence.</t>
<t>The use of address family dependent Application Programming
Interfaces (APIs) or hard-coded IPv4 address literals may lead to
broken applications when IPv6 connectivity is in use. As such, means
to minimize broken applications when the cellular host is attached to
an IPv6-only network should be encouraged. Particularly, (1) name
resolution libraries (e.g., <xref target="RFC3596"></xref>) must
support both IPv4 and IPv6; (2) applications must be independent of
the underlying IP address family; (3) and applications relying upon
Uniform Resource Identifiers (URIs) must follow <xref
target="RFC3986"></xref> and its updates. Note, some IETF
specifications (e.g., SIP <xref target="RFC3261"></xref>) contains
broken IPv6 Augmented Backus-Naur Form (ABNF) and rules to compare
URIs with embedded IPv6 addresses; fixes (e.g., <xref
target="RFC5954"></xref>) must be used instead.</t>
<t>The recommendations included in each section are listed in a
priority order.</t>
<t>This document is not a standard, and conformance with it is not
required in order to claim conformance with IETF standards for IPv6.
Compliance with this profile does not require the support of all
enclosed items. Obviously, the support of the full set of features may
not be required in some deployment contexts. However, the authors
believe that not supporting relevant features included in this profile
(e.g., Customer Side Translator (CLAT, <xref
target="RFC6877"></xref>)) may lead to a degraded level of
service.</t>
</section>
</section>
<section anchor="generic" title="Connectivity Recommendations">
<t>This section identifies the main connectivity recommendations to be
followed by a cellular host to attach to a network using IPv6 in
addition to what is defined in <xref target="RFC6434"></xref> and <xref
target="RFC7066"></xref>. Both dual-stack and IPv6-only deployment
models are considered. IPv4 service continuity features are listed in
this section because these are critical for Operators with an IPv6-only
deployment model. These recommendations apply also for cellular devices
(see <xref target="cpe"></xref>).</t>
<t><list counter="" style="format C_REC#%d:">
<!--
<t hangText="REC#1:">The cellular host must be compliant with
Section 5.9.1 (IPv6 Addressing Architecture) and Section 5.8 (ICMPv6
support) of <xref target="RFC6434"></xref>.</t>
-->
<t hangText="REC#2:">In order to allow each operator to select their
own strategy regarding IPv6 introduction, the cellular host must
support both IPv6 and IPv4v6 PDP-Contexts <xref
target="TS.23060"></xref>. <vspace blankLines="1" />IPv4, IPv6 or
IPv4v6 PDP-Context request acceptance depends on the cellular
network configuration.</t>
<t hangText="REQ#3:">The cellular host must comply with the behavior
defined in <xref target="TS.23060"></xref> <xref
target="TS.23401"></xref> <xref target="TS.24008"></xref> for
requesting a PDP-Context type. <vspace blankLines="1" />In
particular, the cellular host must request by default an IPv6
PDP-Context if the cellular host is IPv6-only and request an IPv4v6
PDP-Context if the cellular host is dual-stack or when the cellular
host is not aware of connectivity types requested by devices
connected to it (e.g., cellular host with LAN capabilities as
discussed in <xref target="cpe"></xref>): <list style="symbols">
<t>If the requested IPv4v6 PDP-Context is not supported by the
network, but IPv4 and IPv6 PDP types are allowed, then the
cellular host will be configured with an IPv4 address or an IPv6
prefix by the network. It must initiate another PDP-Context
activation of the other address family in addition to the one
already activated for a given APN (Access Point Name). The
purpose of initiating a second PDP-Context is to achieve
dual-stack connectivity by means of two PDP-Contexts.</t>
<t>If the subscription data or network configuration allows only
one IP address family (IPv4 or IPv6), the cellular host must not
request a second PDP-Context to the same APN for the other IP
address family.</t>
</list><vspace blankLines="1" />The network informs the cellular
host about allowed PDP types by means of Session Management (SM)
cause codes. In particular, the following cause codes can be
returned:<list style="symbols">
<t>cause #50 "PDP type IPv4 only allowed". This cause code is
used by the network to indicate that only PDP type IPv4 is
allowed for the requested PDN connectivity.</t>
<t>cause #51 "PDP type IPv6 only allowed". This cause code is
used by the network to indicate that only PDP type IPv6 is
allowed for the requested PDN connectivity.</t>
<t>cause #52 "single address bearers only allowed". This cause
code is used by the network to indicate that the requested PDN
connectivity is accepted with the restriction that only single
IP version bearers are allowed.</t>
</list><vspace blankLines="1" />The text above focuses on the
specification (excerpt from <xref target="TS.23060"></xref> <xref
target="TS.23401"></xref> <xref target="TS.24008"></xref>) which
explains the behavior for requesting IPv6-related
PDP-Context(s).</t>
<t hangText="REQ#4:">The cellular host must support the PCO
(Protocol Configuration Options) <xref target="TS.24008"></xref> to
retrieve the IPv6 address(es) of the Recursive DNS server(s). <list
style="empty">
<t>The 3GPP network communicates parameters by means of the
protocol configuration options information element when
activating, modifying or deactivating a PDP-Context. PCO is a
convenient method to inform the cellular host about various
services, including DNS server information. It does not require
additional protocol to be supported by the cellular host and it
is already deployed in IPv4 cellular networks to convey such DNS
information.</t>
</list></t>
<t hangText="REQ#5:">The cellular host must support IPv6 aware
Traffic Flow Templates (TFT) <xref target="TS.24008"></xref>.<list
style="empty">
<t>Traffic Flow Templates are employing a packet filter to
couple an IP traffic with a PDP-Context. Thus a dedicated
PDP-Context and radio resources can be provided by the cellular
network for certain IP traffic.</t>
</list></t>
<!--
<t hangText="REQ#6:">The cellular host must support the Neighbor
Discovery Protocol (<xref target="RFC4861"></xref> and <xref
target="RFC5942"></xref>).<list style="empty">
<t>This is a stronger form compared to what is specified in
Section 5.2 and Section 12.2 of <xref
target="RFC6434"></xref>.</t>
<t>The support of Neighbor Discovery Protocol is mandatory in
3GPP cellular environment as it is the only way to convey IPv6
prefix towards the 3GPP cellular device.</t>
<t>In particular, MTU (Maximum Transmission Unit) communication
via Router Advertisement must be supported since many 3GPP
networks do not have a standard MTU setting.</t>
</list></t>
-->
<!--
<t hangText="REQ#7:">The cellular host must comply with Section
5.6.1 of <xref target="RFC6434"></xref>. 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.</t>
-->
<!--
<t hangText="REQ#8:">The cellular host must support IPv6 Stateless
Address Autoconfiguration (<xref target="RFC4862"></xref>) apart
from the exceptions noted in <xref target="TS.23060"></xref> (3G)
and <xref target="TS.23401"></xref> (LTE):<list style="empty">
<t>Stateless mode is the only way to configure a cellular host.
The GGSN/PGW must allocate a prefix that is unique within its
scope to each primary PDP-Context.</t>
<t>To configure its link local address, the cellular host must
use the Interface Identifier conveyed in 3GPP PDP-Context setup
signaling received from a GGSN/PGW. The cellular host may use a
different Interface Identifiers to configure its global
addresses (see also A_REC#1 about privacy addressing
recommendation).</t>
<t>For more details, refer to <xref target="RFC6459"></xref> and
<xref target="RFC7066"></xref>.</t>
</list></t>
-->
<!--
<t hangText="REQ#9:">The cellular host must comply with Section 7.3
of <xref target="RFC6434"></xref>.</t>
-->
<!--
<t hangText="REQ#10:">The cellular host must comply with Section
7.2.1 of <xref target="RFC6434"></xref>.<list style="empty">
<t>Stateless DHCPv6 is useful to retrieve other information than
DNS.</t>
<t>If <xref target="RFC6106"></xref> is not supported at the
network side, the cellular host should retrieve DNS information
using stateless DHCPv6 <xref target="RFC3736"></xref>.</t>
</list></t>
-->
<t hangText="REQ#11:">If the cellular host receives the DNS
information in several channels for the same interface, the
following preference order must be followed:<list style="empty">
<t>1. PCO</t>
<t>2. RA</t>
<t>3. DHCPv6</t>
</list>The purpose of this recommendation is to guarantee for a
deterministic behavior to be followed by all cellular hosts when the
DNS information is received in various channels.</t>
<t hangText="REQ#12:">Because of potential operational deficiencies
to be experienced in some roaming situations, the cellular host must
be able to be configured with a home PDP-Context type(s) and a
roaming PDP-Context type(s). The purpose of the roaming profile is
to limit the PDP type(s) requested by the cellular host when out of
the home network. Note that distinct PDP type(s) and APN(s) can be
configured for home and roaming cases.<list style="empty">
<t>A detailed analysis of roaming failure cases is included in
<xref target="RFC7445"></xref>.</t>
<t>The configuration can be either local to the device or be
managed dynamically using, for example, Open Mobile Alliance
(OMA) management. The support of dynamic means is
encouraged.</t>
</list></t>
<t hangText="REQ#12:">In order to ensure IPv4 service continuity in
an IPv6-only deployment context, the cellular host should support a
method to learn PREFIX64(s). <list style="empty">
<t>In the context of NAT64, IPv6-enabled applications relying on
address referrals will fail because an IPv6-only client will not
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 <xref target="RFC6052"></xref>) and, also, to
distinguish between IPv4-converted IPv6 addresses and native
IPv6 addresses. In other words, this feature contributes to
offload both CLAT module and NAT64 devices. Refer to Section 3
of <xref target="RFC7051"></xref> for an inventory of the issues
related to the discovery of PREFIX64(s).</t>
<t>In PCP-based environments, cellular hosts should follow <xref
target="RFC7225"></xref> to learn the IPv6 Prefix used by an
upstream PCP-controlled NAT64 device. If PCP is not enabled, the
cellular host should implement the method specified in <xref
target="RFC7050"></xref> to retrieve the PREFIX64.</t>
</list></t>
<t hangText="REQ#13:">In order to ensure IPv4 service continuity in
an IPv6-only deployment context, the cellular host should implement
the Customer Side Translator (CLAT, <xref target="RFC6877"></xref>)
function in compliance with <xref target="RFC6052"></xref><xref
target="RFC6145"></xref><xref target="RFC6146"></xref>. <list
style="empty">
<t>CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only
connectivity. The more applications are address family
independent, the less CLAT function is solicited. CLAT function
requires a NAT64 capability <xref target="RFC6146"></xref> in
the network.</t>
<t>The cellular host should only invoke the CLAT in the absence
of the IPv4 connectivity on the cellular side, i.e., when the
network does not assign an IPv4 address on the cellular
interface. Note, NAT64 assumes an IPv6-only mode <xref
target="RFC6146"></xref>.</t>
<t>The IPv4 Service Continuity Prefix used by CLAT is defined in
<xref target="RFC7335"></xref>.</t>
<t>CLAT and/or NAT64 do not interfere with native IPv6
communications.</t>
<t>CLAT may not be required in some contexts, e.g., if other
solutions such as Bump-in-the-Host (BIH, <xref
target="RFC6535"></xref>) are supported.</t>
<t>The cellular device can act as a CE router connecting various
IP hosts on a LAN segment; it is also the case with the use of
WLAN (Wireless LAN) tethering or WLAN hotspot from the cellular
device. Some of these IP hosts can be dual-stack, others are
IPv6-only or IPv4-only. IPv6-only connectivity on the cellular
device does not allow IPv4-only sessions to be established for
hosts connected on the LAN segment of the cellular device. IPv4
session establishment initiated from hosts located on LAN
segment side and destined for IPv4 nodes must be maintained. A
solution is to integrate the CLAT function to the LAN segment in
the cellular device. </t>
</list></t>
<t>The cellular host may be able to be configured to limit PDP
type(s) for a given APN. The default mode is to allow all supported
PDP types. Note, C_REC#2 discusses the default behavior for
requesting PDP-Context type(s). <list style="empty">
<t>This feature is useful to drive the behavior of the UE to be
aligned with: (1) service-specific constraints such as the use
of IPv6-only for VoLTE (Voice over LTE), (2) network conditions
with regards to the support of specific PDP types (e.g., IPv4v6
PDP-Context is not supported), (3) IPv4 sunset objectives, (4)
subscription data, etc.</t>
<t>Note, a cellular host changing its connection between an
IPv6-specific APN and an IPv4-specific APN will interrupt
related network connections. This may be considered as a
brokenness situation by some applications.</t>
<t>The configuration can be either local to the device or be
managed dynamically using, for example, Open Mobile Alliance
(OMA) management. The support of dynamic means is
encouraged.</t>
</list></t>
</list></t>
</section>
<section anchor="cpe"
title="Recommendations for Cellular Devices with LAN Capabilities">
<t>This section focuses on cellular devices (e.g., CE router,
smartphones or dongles with tethering features) which provide IP
connectivity to other devices connected to them. In such case, all
connected devices are sharing the same 2G, 3G or LTE connection. In
addition to the generic recommendations listed in <xref
target="generic"></xref>, these cellular devices have to meet the
recommendations listed below.</t>
<t><list style="format L_REC#%d:">
<!--
-->
<t hangText="REQ#27:">For deployments requiring to share the same
/64 prefix, the cellular device should support <xref
target="RFC7278"></xref> to enable sharing a /64 prefix between the
3GPP interface towards the GGSN/PGW (WAN interface) and the LAN
interfaces.<list style="empty">
<t>Prefix Delegation (refer to L_REC#2) is the target solution
for distributing prefixes in the LAN side but, because the
device may attach to earlier 3GPP release networks, a mean to
share a /64 prefix is also recommended <xref
target="RFC7278"></xref>.</t>
<t><xref target="RFC7278"></xref> must be invoked only if Prefix
Delegation is not in use.</t>
</list></t>
<t hangText="REQ#27:">The cellular device must support Prefix
Delegation capabilities <xref target="RFC3633"></xref> and must
support Prefix Exclude Option for DHCPv6-based Prefix Delegation as
defined in <xref target="RFC6603"></xref>. Particularly, it must
behave as a Requesting Router. <list style="empty">
<t>Cellular networks are more and more perceived as an
alternative to fixed broadband networks for home IP-based
services delivery; especially with the advent of smartphones and
3GPP data dongles. There is a need for an efficient mechanism to
assign larger prefixes (other than /64s) to cellular hosts so
that each LAN segment can get its own /64 prefix and multi-link
subnet issues to be avoided.</t>
<t>In case a prefix is delegated to a cellular host using
DHCPv6, the cellular device will be configured with two
prefixes: <list style="empty">
<t>(1) one for 3GPP link allocated using stateless address
autoconfiguration (SLAAC) mechanism and</t>
<t>(2) another one delegated for LANs acquired during Prefix
Delegation operation.</t>
</list>Note that the 3GPP network architecture requires both
the WAN (Wide Area Network) and the delegated prefix to be
aggregatable, so the subscriber can be identified using a single
prefix.</t>
<t>Without the Prefix Exclude Option, the delegating router
(GGSN/PGW) will have to ensure <xref target="RFC3633"></xref>
compliancy (e.g., halving the delegated prefix and assigning the
WAN prefix out of the 1st half and the prefix to be delegated to
the terminal from the 2nd half).</t>
<t>Because Prefix Delegation capabilities may not be available
in some attached networks, L_REC#1 is strongly recommended to
accommodate early deployments.</t>
</list></t>
<t hangText="REQ#27:">The cellular CE router must be compliant with
the requirements specified in <xref target="RFC7084"></xref>.<list
style="empty">
<t>There are several deployments, particularly in emerging
countries, that relies on mobile networks to provide broadband
services (e.g., customers are provided with mobile CE
routers).</t>
<t>Note, this profile does not require IPv4 service continuity
techniques listed in Section 4.4 of <xref
target="RFC7084"></xref> because those are specific to fixed
networks. IPv4 service continuity techniques specific to the
mobile networks are included in this profile.</t>
<t>This recommendation does not apply to handsets with tethering
capabilities; it is specific to cellular CE routers in order to
ensure the same IPv6 functional parity for both fixed and
cellular CE routers. Note, modern CE routers are designed with
advanced functions such as link aggregation that consists in
optimizing the network usage by aggregating the connectivity
resources offered via various interfaces (e.g., Digital
Subscriber Line (DSL), LTE, WLAN, etc.) or offloading the
traffic via a subset of interfaces. Ensuring IPv6 features
parity among these interface types is important for the sake of
specification efficiency, service design simplification and
validation effort optimization.</t>
</list></t>
<t hangText="REQ#28:">If a RA MTU is advertised from the 3GPP
network, the cellular device should send RAs to the downstream
attached LAN devices with the same MTU as seen on the mobile
interface. <list style="empty">
<t>Receiving and relaying RA MTU values facilitates a more
harmonious functioning of the mobile core network where end
nodes transmit packets that do not exceed the MTU size of the
mobile network's GTP (GPRS Tunnelling Protocol) tunnels.</t>
<t><xref target="TS.23060"></xref> 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. More details about
link MTU considerations can be found in Annex C of <xref
target="TS.23060"></xref>.</t>
</list></t>
</list></t>
</section>
<section anchor="adv" title="Advanced Recommendations">
<t>This section identifies a set of advanced recommendations to fulfill
requirements of critical services such as VoLTE. These recommendations
apply for mobile hosts, including mobile devices.</t>
<t><list style="format A_REC#%d:">
<!--
<t hangText="REQ#23:">The cellular host must be able to generate
IPv6 addresses which preserve privacy. <list style="empty">
<t>The activation of privacy extension (e.g., using <xref
target="RFC4941"></xref> or <xref target="RFC7217"></xref>)
makes it more difficult to track a host over time when compared
to using a permanent Interface Identifier. Note, <xref
target="RFC4941"></xref> 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.</t>
<t>Tracking a host is still possible based on the first 64 bits
of the IPv6 address. Means to prevent against such tracking
issues may be enabled in the network side.</t>
<t>Privacy extensions are required by regulatory bodies in some
countries.</t>
</list></t>
-->
<t hangText="REQ#24:">The cellular host must support ROHC RTP
Profile (0x0001) and ROHC UDP Profile (0x0002) for IPv6 (<xref
target="RFC5795"></xref>). Other ROHC profiles may be
supported.<list style="empty">
<t>Bandwidth in cellular networks must be optimized as much as
possible. ROHC provides a solution to reduce bandwidth
consumption and to reduce the impact of having bigger packet
headers in IPv6 compared to IPv4.</t>
<t>"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
<xref target="IR92"></xref>. Note, <xref target="IR92"></xref>
indicates that the host must be able to apply the compression to
packets that are carried over the voice media dedicated radio
bearer.</t>
<!--
-->
</list></t>
<t hangText="REQ#25:">The cellular host should support PCP <xref
target="RFC6887"></xref>.<list style="empty">
<t>The support of PCP is seen as a driver to save battery
consumption exacerbated by keepalive messages. PCP also gives
the possibility of enabling incoming connections to the cellular
device. Indeed, because several stateful devices may be deployed
in wireless networks (e.g., NAT64 and/or IPv6 Firewalls), PCP
can be used by the cellular host to control network-based NAT64
and IPv6 Firewall functions which will reduce per-application
signaling and save battery consumption.</t>
<t>According to <xref target="Power"></xref>, the consumption of
a cellular device with a keep-alive interval equal to 20 seconds
(that is the default value in <xref target="RFC3948"></xref> for
example) is 29 mA (2G)/34 mA (3G). This consumption is reduced
to 16 mA (2G)/24 mA (3G) when the interval is increased to 40
seconds, to 9.1 mA (2G)/16 mA (3G) if the interval is equal to
150 seconds, and to 7.3 mA (2G)/14 mA (3G) if the interval is
equal to 180 seconds. When no keep-alive is issued, the
consumption would be 5.2 mA (2G)/6.1 mA (3G). The impact of
keepalive messages would be more severe if multiple applications
are issuing those messages (e.g., SIP, IPsec, etc.).</t>
<t>PCP allows to avoid embedding ALGs (Application Level
Gateways) at the network side (e.g., NAT64) to manage protocols
which convey IP addresses and/or port numbers (see Section 2.2
of <xref target="RFC6889"></xref>). Avoiding soliciting ALGs
allows for more easiness to make evolve a service independently
of the underlying transport network.</t>
</list></t>
<t hangText="REQ#25:">In order for host-based validation of DNS
Security Extensions (DNSSEC) to continue to function in an IPv6-only
connectivity with NAT64 deployment context, the cellular host should
embed a DNS64 function (<xref target="RFC6147"></xref>). <list
style="empty">
<t>This is called "DNS64 in stub-resolver mode" in <xref
target="RFC6147"></xref>.</t>
<t>As discussed in Section 5.5 of <xref
target="RFC6147"></xref>, a security-aware and validating host
has to perform the DNS64 function locally.</t>
<t>Because synthetic AAAA records cannot be successfully
validated in a host, learning the PREFIX64 used to construct
IPv4-converted IPv6 addresses allows the use of DNSSEC <xref
target="RFC4033"></xref> <xref target="RFC4034"></xref>, <xref
target="RFC4035"></xref>. Means to configure or discover a
PREFIX64 are required on the cellular device as discussed in
C_REC#7.</t>
<t><xref target="RFC7051"></xref> discusses why a security-aware
and validating host has to perform the DNS64 function locally
and why it has to be able to learn the proper PREFIX64(s).</t>
</list></t>
<t hangText="REQ#25:">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
established through translation devices (e.g., NAT44 and
NAT64).<list style="empty">
<t>When both IPv4 and IPv6 DNS servers are configured, a
dual-stack host must contact first its IPv6 DNS server. This
preference allows to offload IPv4-only DNS servers.</t>
<t>Cellular hosts should follow the procedure specified in <xref
target="RFC6724"></xref> for source address selection.</t>
</list></t>
<!--
<t hangText="REQ#25:">The cellular host must comply with Section 5.3
of <xref target="RFC6434"></xref> and should support Router
Advertisement extension for communicating default router preferences
and more-specific routes as described in <xref
target="RFC4191"></xref>.<list style="empty">
<t>This function can be used for instance for traffic
offload.</t>
</list></t>
-->
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>The security considerations identified in <xref
target="RFC7066"></xref> and <xref target="RFC6459"></xref> are to be
taken into account.</t>
<t>In the case of cellular CE routers, compliance with L_REC#3 entails
compliance with <xref target="RFC7084"></xref>, which in turn recommends
compliance with Recommended Simple Security Capabilities in Customer
Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
<xref target="RFC6092"></xref>. Therefore, the security considerations
in Section 6 of <xref target="RFC6092"></xref> are relevant. In
particular, it bears repeating here that the true impact of stateful
filtering may be a reduction in security, and that IETF make no
statement, expressed or implied, as to whether using the capabilities
described in any of these documents ultimately improves security for any
individual users or for the Internet community as a whole.</t>
<t>The cellular host must be able to generate IPv6 addresses which
preserve privacy. The activation of privacy extension (e.g., using <xref
target="RFC7217"></xref>) makes it more difficult to track a host over
time when compared to using a permanent Interface Identifier. Tracking a
host is still possible based on the first 64 bits of the IPv6 address.
Means to prevent against such tracking issues may be enabled in the
network side. Note, privacy extensions are required by regulatory bodies
in some countries.</t>
<t>Host-based validation of DNSSEC is discussed in A_REC#3 (see <xref
target="adv"></xref>).</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to C. Byrne, H. Soliman, H. Singh,
L. Colliti, T. Lemon, B. Sarikaya, M. Mawatari,
M. Abrahamsson, P. Vickers, V. Kuarsingh, E. Kline,
S. Josefsson, A. Baryun, J. Woodyatt, T. Kossut,
B. Stark, and A. Petrescu for the discussion in the v6ops
mailing list and for the comments.</t>
<t>Thanks to A. Farrel, B. Haberman, and K. Moriarty for
the comments during the IESG review.</t>
<t>Special thanks to T. Savolainen, J. Korhonen,
J. Jaeggli, F. Baker, L.M. Contreras Murillo, and
M. Abrahamsson for their detailed reviews and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.6603'?>
<?rfc include='reference.RFC.5954'?>
<?rfc include='reference.RFC.3596'?>
<?rfc include='reference.RFC.5795'?>
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.7066'?>
<reference anchor="TS.23060"
target="http://www.3gpp.org/DynaReport/23060.htm">
<front>
<title>General Packet Radio Service (GPRS); Service description;
Stage 2</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="TS.24008"
target="http://www.3gpp.org/DynaReport/24008.htm">
<front>
<title>Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="June" year="2011" />
</front>
</reference>
<reference anchor="TS.23401"
target="http://www.3gpp.org/DynaReport/23401.htm">
<front>
<title>General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="IR92"
target="http://www.gsma.com/newsroom/ir-92-v4-0-ims-profile-for-voice-and-sms">
<front>
<title>IR.92.V4.0 – IMS Profile for Voice and SMS</title>
<author fullname="" surname="">
<organization>GSMA</organization>
</author>
<date day="0" month="March" year="2011" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6459'?>
<?rfc include='reference.RFC.6145'?>
<?rfc include='reference.RFC.6147'?>
<?rfc include='reference.RFC.7084'?>
<?rfc include='reference.RFC.6434'?>
<?rfc include='reference.RFC.6724'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.7217'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.7051'?>
<?rfc include='reference.RFC.6092'?>
<?rfc include='reference.RFC.4033'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.7335'?>
<?rfc include='reference.RFC.4035'?>
<?rfc include='reference.RFC.7225'?>
<?rfc include='reference.RFC.7050'?>
<?rfc include='reference.RFC.3948'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.RFC.6877'?>
<?rfc include='reference.RFC.7278'?>
<?rfc include='reference.RFC.6342'?>
<?rfc include='reference.RFC.6889'?>
<?rfc include='reference.RFC.7445'?>
<?rfc include='reference.RFC.6535'?>
<reference anchor="TS.23402"
target="http://www.3gpp.org/DynaReport/23402.htm">
<front>
<title>Architecture enhancements for non-3GPP accesses</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="Power"
target="http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=4212635">
<front>
<title>Energy Consumption of Always-On Applications in WCDMA
Networks</title>
<author fullname="Henry Haverinen" initials="H." surname="Haverinen">
<organization>Nokia Enterprise Solutions</organization>
</author>
<author fullname="Jonne Siren" initials="J." surname="Siren">
<organization>Nokia Enterprise Solutions</organization>
</author>
<author fullname="Pasi Eronen" initials="P." surname="Eronen">
<organization>Nokia Research Center</organization>
</author>
<date day="" month="April" year="2007" />
</front>
</reference>
<reference anchor="OECD"
target="http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/ICCP/CISP%282014%293/FINAL&docLanguage=En">
<front>
<title>The Economics of the Transition to Internet Protocol version
6 (IPv6)</title>
<author>
<organization>Organisation for Economic Cooperation and
Development (OECD)</organization>
</author>
<date day="" month="November" year="2014" />
</front>
</reference>
<reference anchor="R3GPP"
target="http://www.3gpp.org/specifications/67-releases">
<front>
<title>The Mobile Broadband Standard, Releases</title>
<author>
<organization>3GPP</organization>
</author>
<date day="" month="" year="2015" />
</front>
</reference>
</references>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:39:59 |