One document matched: draft-ietf-v6ops-mobile-device-profile-03.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 category="info" docName="draft-ietf-v6ops-mobile-device-profile-03"
ipr="trust200902" updates="">
<front>
<title abbrev="IPv6 Profile for Cellular Devices">Internet Protocol
Version 6 (IPv6) Profile for 3GPP Mobile Devices</title>
<author fullname="David Binet" initials="D." surname="Binet">
<organization>France Telecom</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>France Telecom</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="Cameron Byrne" initials="C." surname="Byrne">
<organization>T-Mobile</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>Cameron.Byrne@T-Mobile.com</email>
</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>
<date day="29" month="April" year="2013" />
<workgroup>V6OPS Working Group</workgroup>
<abstract>
<t>This document specifies an IPv6 profile for 3GPP mobile devices. It
lists the set of features a 3GPP mobile device is to be compliant with
to connect to an IPv6-only or dual-stack wireless network (including
3GPP cellular network and IEEE 802.11 network).</t>
<t>This document defines a different profile than the one for general
connection to IPv6 cellular networks defined in <xref
target="I-D.ietf-v6ops-rfc3316bis"></xref>. In particular, this document
identifies also features to deliver IPv4 connectivity service over an
IPv6-only transport.</t>
<t>Both hosts and devices with capability to share their WAN (Wide Area
Network) connectivity are in scope.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IPv6 deployment in 3GPP mobile networks is the only perennial
solution to the exhaustion of IPv4 addresses in those networks. Several
mobile operators have 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.</t>
<t><xref target="I-D.ietf-v6ops-rfc3316bis"></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
service are to be considered.</t>
<t>This document defines a different profile than the one for general
connection to IPv6 mobile networks defined in <xref
target="I-D.ietf-v6ops-rfc3316bis"></xref>; in particular: <list
style="symbols">
<t>It lists an extended list of required features while <xref
target="I-D.ietf-v6ops-rfc3316bis"></xref> identifies issues and
explains how to implement basic IPv6 features in a cellular
context.</t>
<t>It identifies also features to ensure IPv4 service delivery over
an IPv6-only transport.</t>
</list></t>
<t>This document specifies an IPv6 profile for mobile devices listing
required specifications produced by various Standards Developing
Organizations (in particular 3GPP and IETF). The objectives of this
effort are:<list style="numbers">
<t>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 (General
Packet Radio Service), EPC (Evolved Packet Core) or IEEE 802.11
network.</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 minimal set of requirements to allow for
IPv6 connectivity and IPv4 service continuity (over an IPv6-only
transport).</t>
</list></t>
<t>Pointers to some requirements listed in <xref
target="RFC6434"></xref> are included in this profile. The justification
for using a stronger language compared to what is specified in <xref
target="RFC6434"></xref> is provided for some requirements.</t>
<t>The requirements 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>.</t>
<t>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.</t>
<t>A detailed overview of IPv6 support in 3GPP architectures is provided
in <xref target="RFC6459"></xref>.</t>
<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 or IEEE 802.11
networks.</t>
<t>"3GPP cellular device" (or cellular device for short) refers to a
cellular host which supports the capability to share its WAN (Wide
Area Network) connectivity.</t>
<t>"Cellular host" and "mobile host" are used interchangeably.</t>
<t>"Cellular device" and "mobile device" are used
interchangeably.</t>
</list></t>
<t>PREFIX64 denotes an IPv6 prefix used to build IPv4-converted IPv6
addresses <xref target="RFC6052"></xref>.</t>
<section title="Scope">
<t>A 3GPP mobile network can be used to connect various user
equipments such as a mobile telephone, a CPE (Customer Premises
Equipment) or a M2M (machine-to-machine) 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
mobile network. This document describes these functionalities.</t>
<t>This document is structured to provide the generic IPv6
requirements which are valid for all nodes, whatever their function or
service (e.g., SIP <xref target="RFC3261"></xref>) 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)).</t>
<t>The requirements listed below are valid for both 3GPP GPRS and 3GPP
EPS (Evolved Packet System) access. For EPS, PDN-Connection term is
used instead of PDP-Context.</t>
<t>This document identifies also some WLAN-related IPv6 requirements.
Other non-3GPP accesses <xref target="TS.23402"></xref> are out of
scope of this document.</t>
</section>
<section title="Special Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This document is not a standard. It uses the normative keywords
only for precision.</t>
</section>
</section>
<section anchor="generic" title="Connectivity Requirements">
<t></t>
<t><list counter="" hangIndent="5" style="hanging">
<t hangText="REQ#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="REQ#2:">The cellular host MUST support both IPv6 and
IPv4v6 PDP-Contexts. <list style="empty">
<t>This allows each operator to select their own strategy
regarding IPv6 introduction. Both IPv6 and IPv4v6 PDP-Contexts
MUST be supported. IPv4, IPv6 or IPv4v6 PDP-Context request
acceptance depends on the cellular network configuration.</t>
</list></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. In particular, the cellular host MUST
request by default 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 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 in addition to the one already activated for a given
APN (Access Point Name).</t>
<t>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.</t>
</list>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.</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>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.</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 device 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 REQ#23 about privacy addressing
requirement).</t>
<t>For more details, refer to <xref target="RFC6459"></xref> and
<xref target="I-D.ietf-v6ops-rfc3316bis"></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, 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="numbers">
<t>PCO</t>
<t>RA</t>
<t>DHCPv6</t>
</list></t>
<t hangText="REQ#12:">The cellular host SHOULD support a method to
locally construct IPv4-embedded IPv6 addresses <xref
target="RFC6052"></xref>. A method to learn PREFIX64 SHOULD be
supported by the cellular host. <list style="empty">
<t>This solves the issue when applications use IPv4 referrals on
IPv6-only access networks.</t>
<t>In PCP-based environments, cellular hosts SHOULD follow <xref
target="I-D.ietf-pcp-nat64-prefix64"></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="I-D.ietf-behave-nat64-discovery-heuristic"></xref> to
retrieve the PREFIX64.</t>
</list></t>
<t hangText="REQ#13:">The cellular host SHOULD implement the
Customer Side Translator (CLAT, <xref target="RFC6877"></xref>)
function which is compliant 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. CLAT function requires a NAT64 capability <xref
target="RFC6146"></xref> in the core network.</t>
</list></t>
<t hangText="REQ#14:">The cellular device SHOULD embed a DNS64
function <xref target="RFC6147"></xref>. <list style="empty">
<t>Local DNS64 functionality allows for compatibility with DNS
Security Extensions (DNSSEC, <xref target="RFC4033"></xref>,
<xref target="RFC4034"></xref>, <xref target="RFC4035"></xref>).
Means to configure or discover a PREFIX64 is also required on
the cellular device as discussed in REQ#12.</t>
</list></t>
<t hangText="REQ#15:">The cellular host SHOULD support PCP <xref
target="I-D.ietf-pcp-base"></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., 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.</t>
</list></t>
<t hangText="REQ#16:">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.</t>
<t>Cellular hosts SHOULD follow the procedure specified in <xref
target="RFC6724"></xref> for source address selection.</t>
</list></t>
<t hangText="REQ#17:">The cellular host SHOULD support Happy
Eyeballs procedure defined in <xref target="RFC6555"></xref>.</t>
<t hangText="REQ#18:">The cellular device MAY embed a BIH function
<xref target="RFC6535"></xref> facilitating the communication
between an IPv4 application and an IPv6 server.</t>
</list></t>
<section title="WLAN Connectivity Requirements">
<t>It is increasingly common for cellular hosts have a WLAN 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:</t>
<t><list hangIndent="7" style="hanging">
<t hangText="REQ#19:">IPv6 MUST be supported on the WLAN
interface. In particular, IPv6-only connectivity MUST be supported
over the WLAN interface.<list style="empty">
<t>Some tests revealed that IPv4 configuration is required to
enable IPv6-only connectivity. Indeed, some cellular handsets
can access a WLAN 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. Failing to
configure an IPv4 address on the interface MUST NOT prohibit
using IPv6 on the same interface.</t>
<t>IPv6 Stateless Address Autoconfiguration (<xref
target="RFC4862"></xref>) MUST be supported.</t>
</list></t>
<t hangText="REQ#20:">DHCPv6 client SHOULD be supported on WLAN
interface.<list style="empty">
<t>Refer to Section 7.2.1 of <xref
target="RFC6434"></xref>.</t>
</list></t>
<t hangText="REQ#21:">WLAN interface SHOULD support Router
Advertisement Options for DNS configuration (See Section Section
7.3 of <xref target="RFC6434"></xref>).</t>
<t hangText="REQ#22:">If the device receives the DNS information
in several channels for the same interface, the following
preference order MUST be followed: <list style="numbers">
<t>RA</t>
<t>DHCPv6</t>
</list></t>
</list></t>
</section>
</section>
<section title="Advanced Requirements">
<t></t>
<t><list hangIndent="7" style="hanging">
<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>) 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>
</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 also the host must be able to apply the compression to
packets that are carried over the radio bearer dedicated for the
voice media.</t>
</list></t>
<t hangText="REQ#25:">The cellular host SHOULD support IPv6 Router
Advertisement Flags Options (<xref target="RFC5175"></xref>).<list
style="empty">
<t>This is a stronger form compared to what is specified in
<xref target="RFC6434"></xref>.</t>
</list></t>
<t hangText="REQ#26:">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="cpe" title="Cellular Devices with LAN Capabilities">
<t>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 2G, 3G or LTE connection. In addition to the generic
requirements listed in <xref target="generic"></xref>, these cellular
devices have to meet the requirements listed below.</t>
<t><list hangIndent="7" style="hanging">
<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 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.</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 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>
</list></t>
<t hangText="REQ#28:">The cellular device MUST be compliant with the
CPE requirements specified in <xref target="RFC6204"></xref>.</t>
<t hangText="REQ#29:">For deployments requiring to share the same
/64 prefix, the cellular device SHOULD support <xref
target="I-D.ietf-v6ops-64share"></xref> to enable sharing a /64
prefix between the 3GPP interface towards the GGSN/PGW (WAN
interface) and the LAN interfaces.</t>
<t hangText="REQ#30:">The cellular device SHOULD support the
Customer Side Translator (CLAT) <xref target="RFC6877"></xref>.
<list style="empty">
<t>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.</t>
<t>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 <xref
target="generic"></xref>, the CLAT function allows also IPv4
applications to continue running over an IPv6-only host.</t>
</list></t>
<t hangText="REQ#31:">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. <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 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.</t>
</list></t>
</list></t>
</section>
<section title="APIs & Applications">
<t><list hangIndent="7" style="hanging">
<t hangText="REQ#32:">Name resolution libraries MUST support both
IPv4 and IPv6.<list style="empty">
<t>In particular, the cellular host MUST support <xref
target="RFC3596"></xref>.</t>
</list></t>
<t hangText="REQ#33:">Applications MUST be independent of the
underlying IP address family.<list style="empty">
<t>This means applications must be IP version agnostic.</t>
</list></t>
<t hangText="REQ#34:">Applications using URIs MUST follow <xref
target="RFC3986"></xref>. For example, SIP applications MUST follow
the correction defined in <xref target="RFC5954"></xref>.</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>The security considerations identified in <xref
target="I-D.ietf-v6ops-rfc3316bis"></xref> and <xref
target="RFC6459"></xref> are to be taken into account.</t>
<t><list hangIndent="7" style="hanging">
<t hangText="REQ#35:">If the cellular device provides LAN features,
it SHOULD be compliant with the security requirements specified in
<xref target="RFC6092"></xref>.</t>
</list></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 H. Soliman, H. Singh, L. Colliti, T. Lemon, B.
Sarikaya, M. Mawatari, M. Abrahamsson, P. Vickers, V. Kuarsingh, and J.
Woodyatt for the discussion in the v6ops mailing list.</t>
<t>Special thanks to T. Savolainen and J. Korhonen for the detailed
review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.6434'?>
<?rfc include='reference.RFC.6106'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.4862'?>
<?rfc include='reference.RFC.4941'?>
<?rfc include='reference.RFC.6145'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.6603'?>
<?rfc include='reference.RFC.5175'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.5954'?>
<?rfc include='reference.RFC.3596'?>
<?rfc include='reference.RFC.6147'?>
<?rfc include='reference.RFC.5795'?>
<?rfc include='reference.RFC.5942'?>
<?rfc include='reference.RFC.3736'?>
<?rfc include='reference.RFC.4191'?>
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.6724'?>
<?rfc include='reference.RFC.6535'?>
<?rfc include='reference.RFC.6555'?>
<?rfc include='reference.RFC.3261'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6459'?>
<?rfc include='reference.RFC.6092'?>
<?rfc include='reference.RFC.6204'?>
<?rfc include='reference.RFC.4033'?>
<?rfc include='reference.RFC.4034'?>
<?rfc include='reference.RFC.4035'?>
<?rfc include='reference.I-D.ietf-v6ops-rfc3316bis'?>
<?rfc include='reference.I-D.ietf-pcp-nat64-prefix64'?>
<?rfc include='reference.I-D.ietf-behave-nat64-discovery-heuristic'?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.RFC.6877'?>
<?rfc include='reference.I-D.ietf-v6ops-64share'?>
<reference anchor="TS.23060" target="">
<front>
<title>General Packet Radio Service (GPRS); Service description;
Stage 2</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="TS.24008" target="">
<front>
<title>Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="June" year="2011" />
</front>
</reference>
<reference anchor="TS.23401" target="">
<front>
<title>General Packet Radio Service (GPRS) enhancements for Evolved
Universal Terrestrial Radio Access Network (E-UTRAN) access</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="TS.29060" target="">
<front>
<title>General Packet Radio Service (GPRS); GPRS Tunnelling Protocol
(GTP) across the Gn and Gp interface</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="TS.29274" target="">
<front>
<title>3GPP Evolved Packet System (EPS); Evolved General Packet
Radio Service (GPRS) Tunnelling Protocol for Control plane
(GTPv2-C); Stage 3</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="June" year="2011" />
</front>
</reference>
<reference anchor="TS.29281" target="">
<front>
<title>General Packet Radio System (GPRS) Tunnelling Protocol User
Plane (GTPv1-U)</title>
<author fullname="3GPP" surname="3GPP">
<organization></organization>
</author>
<date day="0" month="September" year="2011" />
</front>
</reference>
<reference anchor="TS.23402" target="">
<front>
<title>Architecture enhancements for non-3GPP accesses</title>
<author fullname="3GPP" surname="3GPP">
<organization>UPnP Forum</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="GSMA" surname="GSMA">
<organization></organization>
</author>
<date day="0" month="March" year="2011" />
</front>
</reference>
</references>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:39:56 |