Internet Protocol
Version 6 (IPv6) Profile for Mobile Devices
France Telecom
Rennes
France
david.binet@orange.com
France Telecom
Rennes
35000
France
mohamed.boucadair@orange.com
Deutsche Telekom AG
ales.vizdal@t-mobile.cz
T-Mobile
USA
Cameron.Byrne@T-Mobile.com
China Mobile
phdgang@gmail.com
V6OPS Working Group
This document specifies an IPv6 profile for mobile devices. It lists
the set of features a mobile device is to be compliant with to connect
to an IPv6-only or dual-stack mobile network.
This document defines a different profile than the one for general
connection to IPv6 mobile networks defined in . In particular, this document identifies also
features to ensure IPv4 service continuity over an IPv6-only transport.
Both Hosts and devices with LAN capabilities are in scope.
IPv6 deployment in mobile networks is the only perennial solution to
the exhaustion of IPv4 addresses in those networks. Several mobile
operators already deployed IPv6 or are in the pre-deployment phase. One
of the major hurdles encountered by mobile operators is the availability
of non-broken IPv6 implementation in mobile devices. Some vendors are
already proposing some mobile devices with a set of IPv6 features, but
the majority of devices are still lacking IPv6 support.
lists a set of features to be
supported by cellular hosts to connect to 3GPP cellular networks. Since
the publication of that document, new functions have been specified
within the 3GPP and the IETF whilst others have been updated. Moreover,
in the light of recent IPv6 production deployments, additional features
to facilitate IPv6-only deployments while accessing IPv4-only service
are to be considered.
This document defines a different profile than the one for general
connection to IPv6 mobile networks defined in ; in particular:
It lists an extended list of required features while identifies issues and
explains how to implement basic IPv6 features in a mobile context.
It identifies also features to ensure IPv4 service continuity
over an IPv6-only transport.
This document specifies an IPv6 profile for mobile devices listing
required specifications produced by various SDOs (in particular 3GPP and
IETF). The objectives of this effort are:
List in one single document all requirements a mobile device is
to comply with to connect to an IPv6 or dual stack mobile network.
These requirements cover various network types such as GPRS, EPC or
Wi-Fi network.
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.
Vendors to be aware of a minimal set of requirements to allow for
IPv6 connectivity and IPv4 service continuity (over an IPv6- only
transport).
Pointers to some requirements listed in are included in this profile. The justification
for using a stronger language compared to what is specified in is provided for some requirements.
Some of the features listed in this profile document require to
activate dedicated functions at the network side. It is out of scope of
this document to list these network-side functions.
A detailed overview of IPv6 support in 3GPP architectures is provided
in .
This document makes use of the terms defined in .
PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses .
Various types of nodes can be connected to 3GPP networks requiring
specific functions. Indeed, a 3GPP network can be used to connect user
equipment such as a mobile telephone, a CPE or a machine-to-machine
(M2M) device. 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 network. This document describes these
functionalities.
This document is structured to initially provide the generic IPv6
requirements which are valid for all nodes, whatever their function or
service (e.g., SIP ) capability. The
document also contains, dedicated sections covering specific
functionalities the specific device types must support (e.g.,
smartphones, devices providing some LAN functions (mobile CPE or
broadband dongles)).
M2M devices profile is out of scope.
The requirements listed below are valid for both 3GPP GPRS and 3GPP
EPS access. For EPS, "PDN type" terminology is used instead of "PDP
context".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
This document is not a standard. It uses the normative keywords
only for precision.
The cellular host MUST be compliant with
Section 5.9.1 (IPv6 Addressing Architecture) and Section 5.8 (ICMPv6
support) of .
The cellular host MUST support both IPv6 and
IPv4v6 PDP Contexts.
This allows each operator to select their own strategy
regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP contexts
MUST be supported in addition to the IPv4 PDP context. IPv4,
IPv6 or IPv4v6 PDP-Context request acceptance depends on the
mobile network configuration.
The cellular host MUST comply with the behavior
defined in for
requesting a PDP context type. In particular, the cellular host MUST
request an IPv6 PDP context if the cellular host is IPv6-only and
requesting 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):
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 and/or an
IPv6 prefix by the network. It MAY initiate another PDP request
in addition to the one already activated for a given APN.
If the requested PDP type and subscription data 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.
The text above focuses on the specification part which
explains the behavior for requesting IPv6-related PDP context(s).
Understanding this behavior is important to avoid having broken IPv6
implementations in cellular devices.
The cellular host MUST support the PCO
(Protocol Configuration Options) to
retrieve the IPv6 address(es) of the Recursive DNS server(s).
In-band signaling is a convenient method to inform the
cellular host about various services, including DNS server
information. It does not require any specific protocol to be
supported and it is already deployed in IPv4 cellular networks
to convey such DNS information.
The cellular host MUST support IPv6 aware
Traffic Flow Templates (TFT) .
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 mobile
network for certain IP traffic.
The device MUST support the Neighbor Discovery
Protocol ( and ).
This is a stronger form compared to what is specified in
Section 12.2 of . The support of
Neighbor Discovery Protocol is mandatory in mobile environment
as it is the only way to convey IPv6 prefix towards the mobile
device.
In particular, MTU communication via Router Advertisement
SHOULD be supported since many 3GPP networks do not have a
standard MTU setting due to inconsistencies in GTP mobility tunnel infrastructure
deployments.
The cellular host MUST support IPv6 Stateless
Address Autoconfiguration () apart
from the exceptions noted in (3G)
and (LTE):
Stateless mode is the only way to configure a cellular host.
The GGSN must allocate a prefix that is unique within its scope
to each primary PDP context.
The cellular host MUST use the interface identifier sent in
PDP Context Accept message to configure its link local address.
The cellular host may use a different Interface Identifiers to
configure its global addresses.
The cellular host must comply with Section 7.3
of .
The support of Router Advertisement Options for DNS
configuration allows for a consistent method of informing
cellular hosts about DNS recursive servers across various types
of access networks. The cellular host SHOULD support RA-based
DNS information discovery.
The cellular host must comply with Section
7.2.1 of .
Stateless DHCPv6 is useful to retrieve other information than
DNS.
If is not supported, the
cellular host SHOULD retrieve DNS information using stateless
DHCPv6 .
If the cellular host receives the DNS information in several
channels for the same interface, the following preference order
MUST be followed:
PCP
RA
DHCPv6
The cellular host SHOULD support a method to
locally construct IPv4-embedded IPv6 addresses . A method to learn PREFIX64 SHOULD be
supported by the cellular host.
This solves the issue when applications use IPv4 referrals on
IPv6-only access networks.
In PCP-based environments, cellular hosts SHOULD follow 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 to
retrieve the PREFIX64.
The cellular host SHOULD implement the
Customer Side Translator (CLAT, ) function which is compliant
with .
CLAT function in the cellular host allows for IPv4-only
application and IPv4-referals to work on an IPv6-only PDP. CLAT
function requires a NAT64 capability in the core network.
The cellular device SHOULD embed a DNS64
function .
Local DNS64 functionality allows for compatibility with
DNSSEC. Means to configure or discover a PREFIX64 is also
required on the cellular device.
The cellular host SHOULD support PCP .
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 user.
Indeed, because several stateful devices may be deployed in
mobile networks (e.g., NAT and/or Firewalls), PCP can be used by
the cellular host to control network based NAT and Firewall
functions which will reduce per-application signaling and save
battery consumption.
When the cellular host is dual stack
connected, it SHOULD support means to prefer native IPv6 connection
over connection established through translation devices (e.g., NAT44
and NAT64).
Cellular hosts SHOULD follow the procedure specified in for source address selection.
Some potential issues are discussed in for MIFed
devices.
The cellular host SHOULD support Happy
Eyeballs procedure defined in .
The cellular host SHOULD NOT perform Duplicate
Address Detection (DAD) for these Global IPv6 addresses (as the GGSN
or PDN-GW must not configure any IPv6 addresses using the prefix
allocated to the cellular host). Refer to
for DAD considerations on the LAN interface when the 3GPP connection
is shared.
The cellular device MAY embed a BIH function
facilitating the communication
between an IPv4 application and an IPv6 server.
It is increasingly common for cellular hosts have a Wi-Fi interface
in addition to their cellular interface. These hosts are likely to be
connected to private or public hotspots. Below are listed some generic
requirements:
IPv6 MUST be supported on the Wi-Fi
interface. In particular, IPv6-only connectivity MUST be supported
over the Wi-Fi interface.
Recent tests revealed that IPv4 configuration is required
to enable IPv6-only connectivity. Indeed, some cellular
handsets can access a Wi-Fi IPv6-only network by configuring
first a static IPv4 address. Once the device is connected to
the network and the wlan0 interface got an IPv6 global
address, the IPv4 address can be deleted from the
configuration. This avoids the device to ask automatically for
a DHCPv4 server, and allows to connect to IPv6-only
networks.
IPv6 Stateless Address Autoconfiguration () MUST be supported.
DHCPv6 client SHOULD be supported on Wi-Fi
interface.
Refer to Section 7.2.1 of .
Wi-Fi interface SHOULD support Router
Advertisement Options for DNS configuration (See Section Section
7.3 of ). If the device receives the
DNS information in several channels for the same interface, the
following preference order MUST be followed:
RA
DHCPv6
The cellular host must comply with Section
5.6.1 of . 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.
The cellular host must comply with Section
5.9.3 of for the support of the
Privacy Extensions for Stateless Address Autoconfiguration in IPv6.
The activation of privacy extension makes it more difficult
to track a host over time when compared to using a permanent
interface identifier. does not
require any DAD mechanism to be activated as the GGSN (or
PDN-GW) MUST NOT configure any global address based on the
prefix allocated to the cellular host.
The cellular host SHOULD support ROHC for IPv6
().
Bandwidth in mobile environments 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.
The cellular host SHOULD support IPv6 Router
Advertisement Flags Options ().
This is a stronger form compared to what is specified in
. The justification is some flags
are used by the GGSN (or PDN-GW) to inform cellular hosts about
the autoconfiguration process.
The cellular host must comply with Section 5.3
of and SHOULD support Router
Advertisement extension for communicating default router preferences
and more-specific routes as described in .
This function can be used for instance for traffic
offload.
This section focuses on cellular devices (e.g., CPE, 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 GPRS, UMTS or EPS connection. In addition to the
generic requirements listed in , these
cellular devices have to meet the requirements listed below.
The cellular device MUST support Prefix
Delegation capabilities and MUST
support Prefix Exclude Option for DHCPv6-based Prefix Delegation as
defined in . Particularly, it MUST
behave as a Requesting Router.
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 shorter prefix than /64 to cellular hosts so that each
LAN segment can get its own /64 prefix and multilink subnet
issues to be avoided.
In case a prefix is delegated to a cellular host using
DHCPv6, the cellular device will be configured with two
prefixes:
(1) one for 3GPP link allocated using SLAAC mechanism
and
(2) another one delegated for LANs acquired during Prefix
Delegation operation.
Note that the 3GPP network architecture requires both
the WAN and the Delegated Prefix to be aggregatable, so the
subscriber can be identified using a single prefix.
Without the Prefix Exclude Option, the delegating router
(GGSN/PDN-GW) will have to ensure
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).
The cellular device MUST be compliant with the
CPE requirements specified in .
For deployments requiring to share the same
/64 prefix, the cellular device SHOULD support to enable sharing a /64
prefix between the 3GPP interface towards the GGSN (WAN interface)
and the LAN interfaces.
The cellular device SHOULD support the
Customer Side Translator (CLAT) .
Various IP devices are likely to be connected to cellular
device, acting as a CPE. Some of these devices can be
dual-stack, others are IPv6-only or IPv4-only. IPv6-only
connectivity for cellular device does not allow IPv4-only
sessions to be established for hosts connected on the LAN
segment of cellular devices.
In order to allow IPv4 sessions establishment initiated from
devices located on LAN segment side and target IPv4 nodes, a
solution consists in integrating the CLAT function in the
cellular device. As elaborated in , the CLAT function allows also IPv4
applications to continue running over an IPv6-only host.
If a RA MTU is advertised from the 3GPP
network, the cellular device SHOULD relay that upstream MTU
information to the downstream attached LAN devices in RA.
Since 3GPP networks extensively use IP-in-IP/UDP GTP tunnels,
the effective MTU is frequently effectively reduced to 1440
bytes. While a host may generate packets with an MTU of 1500
bytes, this results in undesirable fragmentation of the GTP
IP/UDP packets.
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 tunnels.
Name resolution libraries MUST support both
IPv4 and IPv6.
In particular, the cellular host MUST support .
Applications MUST be independent of the
underlying IP address family.
This means applications must be IP version agnostic.
Applications using URIs MUST follow . For example, SIP applications MUST follow
the correction defined in .
The security considerations identified in are to be taken into account.
If the cellular device provides LAN features,
it SHOULD be compliant with the security requirements specified in
.
This document does not require any action from IANA.
Many thanks to H. Soliman, H. Singh, L. Colliti, T. Lemon, B.
Sarikaya, J. Korhonen, M. Mawatari, M. Abrahamsson, P. Vickers, V.
Kuarsingh, and J. Woodyatt for the discussion in the v6ops mailing
list.
General Packet Radio Service (GPRS); Service description;
Stage 2
UPnP Forum
Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3
UPnP Forum
General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access
UPnP Forum