Internet DRAFT - draft-korhonen-v6ops-rfc3316bis
draft-korhonen-v6ops-rfc3316bis
IPv6 Operations (V6OPS) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks
Obsoletes: 3316 (if approved) J. Arkko, Ed.
Intended status: Informational Ericsson
Expires: April 18, 2013 T. Savolainen
Nokia
S. Krishnan
Ericsson
October 15, 2012
IPv6 for 3GPP Cellular Hosts
draft-korhonen-v6ops-rfc3316bis-00.txt
Abstract
As the deployment of third and fourth generation cellular networks
progresses, a large number of cellular hosts are being connected to
the Internet. Standardization organizations are making Internet
Protocol version 6 (IPv6) mandatory in their specifications.
However, the concept of IPv6 covers many aspects and numerous
specifications. In addition, the characteristics of cellular links
in terms of bandwidth, cost and delay put special requirements on how
IPv6 is used. This document considers IPv6 for cellular hosts that
attach to the General Packet Radio Service (GPRS), Universal Mobile
Telecommunications System (UMTS), or Evolved Packet System (EPS)
networks (Hereafter collectively referred to as 3GPP networks). This
document also lists out specific IPv6 functionality that needs to be
implemented in addition what is already prescribed in the IPv6 Node
Requirements document. It also discusses some issues relating to the
use of these components when operating in these networks. This
document obsoletes RFC 3316.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Korhonen, et al. Expires April 18, 2013 [Page 1]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Korhonen, et al. Expires April 18, 2013 [Page 2]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Cellular Host IPv6 Features . . . . . . . . . . . . . . . 6
2. Basic IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Internet Protocol Version 6 . . . . . . . . . . . . . . . 7
2.2. Neighbor Discovery in 3GPP Networks . . . . . . . . . . . 7
2.3. IPv6 Stateless Address Autoconfiguration . . . . . . . . . 8
2.4. Stateless Address Autoconfiguration in 3GPP Networks . . . 8
2.5. IP version 6 over PPP in 3GPP Networks . . . . . . . . . . 9
2.6. MLD in 3GPP Networks . . . . . . . . . . . . . . . . . . . 9
2.7. Privacy Extensions for Address Configuration in IPv6 . . . 9
2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . . 10
2.9. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.10. Router preferences and more specific routes . . . . . . . 10
2.11. Neighbor Discovery and additional host configuration . . . 10
3. IP Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Extension header considerations . . . . . . . . . . . . . 11
4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative references . . . . . . . . . . . . . . . . . . . 14
8.2. Informative references . . . . . . . . . . . . . . . . . . 14
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model . . . 15
Appendix B. Changes to RFC 3316 . . . . . . . . . . . . . . . . . 16
B.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Korhonen, et al. Expires April 18, 2013 [Page 3]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
1. Introduction
Technologies such as GPRS (General Packet Radio Service), UMTS
(Universal Mobile Telecommunications System), Evolved Packet System
(EPS), CDMA2000 (Code Division Multiple Access 2000) and eHRPD
(Enhanced High Rate Packet Data) are making it possible for cellular
hosts to have an always-on connection to the Internet. IPv6
[RFC2460] has become essential to such networks as the number of such
cellular hosts is increasing rapidly. Standardization organizations
working with cellular technologies have recognized this and made IPv6
mandatory in their specifications.
Support for IPv6 and the introduction of UMTS started with 3GPP
Release-99 networks and hosts. For detailed description of IPv6 in
3GPP networks including the Evolved Packet System, see [RFC6459].
1.1. Scope of this Document
For the purposes of this document, a cellular interface is considered
to be the interface to a cellular access network based on the
following standards: 3GPP GPRS and UMTS Release-99, Release-4 to
Release-11, and EPS Release-8 to Release-11 as well as future UMTS or
EPS releases. A cellular host is considered to be a host with such a
cellular interface.
This document complements the IPv6 node requirements [RFC6434] in
places where clarifications are needed with discussion on the use of
these selected IPv6 specifications when operating over cellular
interfaces. Such a specification is necessary in order for the
optimal use of IPv6 in a cellular environment. The description is
made from a cellular host point of view. Complementary access
technologies may be available in the cellular host, but those are not
discussed in detail. Important considerations are given in order to
eliminate unnecessary user confusion over configuration options,
ensure interoperability and to provide an easy reference for those
implementing IPv6 in a cellular host. It is necessary to ensure that
cellular hosts are good citizens of the Internet.
This document is informational in nature, and it is not intended to
replace, update, or contradict any IPv6 standards documents or the
IPv6 node requirements [RFC6434].
This document is mainly targeted towards the implementers of cellular
hosts that will be used with the cellular networks listed in the
scope. The document provides guidance on which IPv6 related
specifications are to be implemented in such cellular hosts. Parts
of this document may also apply to other cellular link types, but
this document does not provide any detailed analysis on other link
Korhonen, et al. Expires April 18, 2013 [Page 4]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
types. This document should not be used as a definitive list of IPv6
functionality for cellular links other than those listed above.
Future changes in 3GPP networks that impact host implementations may
result in updates to this document.
There are different ways to implement cellular hosts:
o The host can be a "closed" device with optimized applications,
with no possibility to add or download applications that can have
IP communications. An example of such a host is a very simple
form of a mobile phone.
o The host can be an open device, e.g., a "smart phone" where it is
possible to download applications to expand the functionality of
the device.
o The cellular radio modem part can be separated from the host IP
stack with an interface. On example of such host is a laptop
computer that uses a USB cellular modem for the cellular access.
If a cellular host has additional interfaces on which IP is used,
(such as Ethernet, WLAN, Bluetooth, etc.) then there may be
additional requirements for the device, beyond what is discussed in
this document. Additionally, this document does not make any
recommendations on the functionality required on laptop computers
having a cellular interface such as an embedded modem or a USB modem
stick, other than recommending link specific behavior on the cellular
link.
This document discusses IPv6 functionality as of the time when this
document has been written. Ongoing work on IPv6 may affect what is
required of future hosts.
Transition mechanisms used by cellular hosts are not described in
this document and are left for further study. The primary transition
mechanism supported by 3GPP is dual-stack [RFC4213]. Dual-stack
capable bearers were added to GPRS starting from 3GPP Release-9 and
to EPS starting from Release-8 [RFC6459], whereas in earlier releases
3GPP multiple single IP version bearers had to be used to support
dual stack.
1.2. Abbreviations
2G Second Generation Mobile Telecommunications, such as GSM and
GPRS technologies.
3G Third Generation Mobile Telecommunications, such as UMTS
technology.
Korhonen, et al. Expires April 18, 2013 [Page 5]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
4G Fourth Generation Mobile Telecommunications, such as LTE
technology.
3GPP 3rd Generation Partnership Project. Throughout the document,
the term 3GPP (3rd Generation Partnership Project) networks
refers to architectures standardized by 3GPP, in Second, Third
and Fourth Generation releases: 99, 4, and 5, as well as future
releases.
APN Access Point Name. The APN is a logical name referring to a
GGSN and/or a PGW, and an external network.
EPC Evolved Packet Core.
EPS Evolved Packet System.
ESP Encapsulating Security Payload
GGSN Gateway GPRS Support Node (a default router for 3GPP IPv6
cellular hosts in GPRS).
GPRS General Packet Radio Service.
LTE Long Term Evolution.
MT Mobile Terminal, for example, a mobile phone handset.
MTU Maximum Transmission Unit.
PDN Packet Data Network.
PDP Packet Data Protocol.
PGW Packet Data Network Gateway (the default router for 3GPP IPv6
cellular hosts in EPS).
SGW Serving Gateway. The user plane equivalent of an SGSN in EPS
(and the default router for 3GPP IPv6 cellular hosts when using
PMIPv6).
TE Terminal Equipment, for example, a laptop attached through a
3GPP handset.
UMTS Universal Mobile Telecommunications System.
WLAN Wireless Local Area Network.
1.3. Cellular Host IPv6 Features
This specification defines IPv6 features for cellular hosts in three
groups.
Basic IP
In this group, basic parts of IPv6 are described.
IP Security
In this group, the IP Security parts are described.
Mobility
In this group, IP layer mobility issues are described.
Korhonen, et al. Expires April 18, 2013 [Page 6]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
2. Basic IP
For most parts refer to the IPv6 Node Requirements document
[RFC6434].
2.1. Internet Protocol Version 6
The Internet Protocol Version 6 (IPv6) is specified in [RFC2460].
This specification is a mandatory part of IPv6. A cellular host must
conform the generic IPv6 Host Requirements [RFC6434], unless
specifically pointed out otherwise in this document.
2.2. Neighbor Discovery in 3GPP Networks
A cellular host must support Neighbor Solicitation and Neighbor
Advertisement messages. Some further notes on how these are applied
in the particular type of an interface can be useful, however:
In GPRS, UMTS and EPS networks, some Neighbor Discovery messages can
be unnecessary in certain cases. GPRS, UMTS and EPS links resemble a
point- to-point link; hence, the cellular host's only neighbor on the
cellular link is the default router that is already known through
Router Discovery. The cellular host always solicits for routers when
the cellular interface is enabled (as described in [RFC4861], Section
6.3.7).
There are no link layer addresses. Therefore, address resolution and
next-hop determination are not needed. If the cellular host still
attempts the address resolution e.g., for the default router, it must
be understood that the GGSN/PGW may not even answer the address
resolution Neighbor Solicitations. And even if it does, the Neighbor
Advertisement is unlikely to contain the Target link-layer address
option as there are no link-layer addresses.
The cellular host must support Neighbor Unreachability Detection
(NUD) as specified in [RFC4861]. Note that the link-layer address
considerations above also apply to the Neighbor Unreachability
Detection. The NUD triggered Neighbor Advertisement is also unlikely
to contain the Target link-layer address option as there are no link-
layer addresses.
In GPRS, UMTS and EPS networks, it is very desirable to reduce any
additional periodic signaling. Therefore, the cellular host should
include a mechanism in upper layer protocols to provide reachability
confirmations when two-way IP layer reachability can be confirmed
(see [RFC4861], Section 7.3.1). These confirmations would allow the
suppression of NUD-related messages in most cases.
Korhonen, et al. Expires April 18, 2013 [Page 7]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
Host TCP implementation should provide reachability confirmation in
the manner explained in [RFC4861], Section 7.3.1.
The widespread use of UDP in 3GPP networks poses a problem for
providing reachability confirmation. As UDP itself is unable to
provide such confirmation, applications running on top of UDP should
provide the confirmation where possible. In particular, when UDP is
used for transporting DNS, the DNS response should be used as a basis
for reachability confirmation. Similarly, when UDP is used to
transport RTP, the RTCP protocol feedback should be used as a basis
for the reachability confirmation. If an RTCP packet is received
with a reception report block indicating some packets have gone
through, then packets are reaching the peer. If they have reached
the peer, they have also reached the neighbor.
When UDP is used for transporting SIP, responses to SIP requests
should be used as the confirmation that packets sent to the peer are
reaching it. When the cellular host is acting as the server side SIP
node, no such confirmation is generally available. However, a host
may interpret the receipt of a SIP ACK request as confirmation that
the previously sent response to a SIP INVITE request has reached the
peer.
2.3. IPv6 Stateless Address Autoconfiguration
IPv6 Stateless Address Autoconfiguration is defined in [RFC4862].
This specification is a mandatory part of IPv6 and also the only
mandatory method to configure an IPv6 address in a 3GPP cellular
host.
2.4. Stateless Address Autoconfiguration in 3GPP Networks
A cellular host in a 3GPP network must process a Router Advertisement
as stated in [RFC4862]. The Router Advertisement contains a maximum
of one prefix information option and the advertised prefix cannot
ever be used for on-link determination (see [RFC6459], Section 5.2).
Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero,
as each delegated prefix is unique within its scope when advertised
using the 3GPP IPv6 Stateless Address Autoconfiguration. In
addition, the default router (GGSN/PGW) will not configure any
addresses on its interfaces based on prefixes advertised to IPv6
cellular hosts on those interfaces. Thus, the host is not required
to perform Duplicate Address Detection on the cellular interface.
Furthermore, the GGSN/PGW will provide the cellular host with an
interface identifier that must be used for link-local address
configuration. The link-local address configured from this interface
Korhonen, et al. Expires April 18, 2013 [Page 8]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
identifier is guaranteed not to collide with the link-local address
that the GGSN/PGW uses. Thus, the cellular host is not required to
perform Duplicate Address Detection for the link-local address either
on the cellular interface.
See Appendix A for more details on 3GPP IPv6 Stateless Address
Autoconfiguration.
2.5. IP version 6 over PPP in 3GPP Networks
A cellular host in a 3GPP network that supports PPP, must support the
IPv6CP interface identifier option. This option is needed to be able
to connect other devices to the Internet using a PPP link between the
cellular device (MT) and other devices (TE, e.g., a laptop). The MT
performs the PDP Context activation based on a request from the TE.
This results in an interface identifier being suggested by the MT to
the TE, using the IPv6CP option. To avoid any duplication in link-
local addresses between the TE and the GGSN/PGW, the MT must always
reject other suggested interface identifiers by the TE. This results
in the TE always using the interface identifier suggested by the GGSN
for its link-local address.
The rejection of interface identifiers suggested by the TE is only
done for creation of link-local addresses, according to 3GPP
specifications. The use of privacy addresses [RFC4941] for unique
local IPv6 unicast addresses (ULA) [RFC4193] and global addresses is
not affected by the above procedure. The above procedure is only
concerned with assigning the interface identifier used for forming
link-local addresses, and does not preclude TE from using other
interface identifiers for addresses with larger scopes (i.e., ULAs
and global).
2.6. MLD in 3GPP Networks
Within 3GPP networks, hosts connect to their default routers (GGSN/
PGW) via point-to-point links. Moreover, there are exactly two IP
devices connected to the point-to-point link, and no attempt is made
(at the link-layer) to suppress the forwarding of multicast traffic.
Consequently, sending MLD reports for link-local addresses in a 3GPP
environment may not always be necessary.
MLD is needed for multicast group knowledge that is not link-local.
2.7. Privacy Extensions for Address Configuration in IPv6
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
should be supported. RFC 4941, and privacy in general, is important
for the Internet. Cellular hosts may use the temporary addresses as
Korhonen, et al. Expires April 18, 2013 [Page 9]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
described in RFC 4941. However, the use of the Privacy Extension in
an environment where IPv6 addresses are short-lived may not be
necessary. At the time this document has been written, there is no
experience on how long-lived cellular network address assignments
(i.e., attachments to the network) are. The length of the address
assignments depends upon many factors such as radio coverage, device
status and user preferences. Additionally, the use of temporary
address with IPsec may lead to more frequent renegotiation for the
Security Associations.
Refer to Section 7 for a discussion of the benefits of privacy
extensions in a 3GPP network.
2.8. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]
may be used. As of 3GPP Release-11 DHCPv6 is neither required nor
supported for address autoconfiguration. The IPv6 stateless
autoconfiguration still remains the only mandatory address
configuration method. However, DHCPv6 may be useful for other
configuration needs on a cellular host. e.g. Stateless DHCPv6
[RFC3736] may be used to configure DNS and SIP server addresses, and
DHCPv6 prefix delegation [RFC3633] may be used to delegate a prefix
to the cellular host for use on its non-cellular links.
2.9. DHCPv6 Prefix Delegation
Starting from Release-10 DHCPv6 Prefix Delegation was added as an
optional feature to the 3GPP system architecture [RFC3633]. The
prefix delegation model defined for Release-10 requires that the /64
IPv6 prefix assigned for the cellular host on the 3GPP link must
aggregate with the shorter delegated IPv6 prefix. The cellular host
should implement the Prefix Exclude Option for DHCPv6 Prefix
Delegation [RFC6603] (see [RFC6459], Section 5.3 for further
discussion).
2.10. Router preferences and more specific routes
The cellular host should implement the Default Router Preferences and
More-Specific Routes extension to extension to Router Advertisement
messages [RFC4191]. These options me be useful for cellular hosts
that also have additional interfaces on which IPv6 is used.
2.11. Neighbor Discovery and additional host configuration
The DNS server configuration is learned from 3GPP link layer
signaling. However, the cellular host should also implement the IPv6
Router Advertisement Options for DNS Configuration [RFC6106]. DHCPv6
Korhonen, et al. Expires April 18, 2013 [Page 10]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
is still optional for cellular hosts, and learning the DNS server
addresses from the link layer signaling can be cumbersome when the MT
and the TE are separated using other techniques than PPP interface.
The cellular host should also honor the MTU option in the Router
Advertisement (see [RFC4861], Section 4.6.4). 3GPP system
architecture uses extensive tunneling in its packet core network
below the 3GPP link and this may lead to packet fragmentation issues.
Therefore, the GGSN/PGW may propose a MTU to the cellular host that
takes the additional tunneling overhead into account.
3. IP Security
IPsec [RFC4301] is a fundamental but not mandatory part of IPv6.
Refer IPv6 Node Requirements Section 11 of [RFC6434] for the security
requirements that also apply to cellular hosts.
3.1. Extension header considerations
The support for the Routing Header Type 0 (RH0) has been deprecated
[RFC5095]. Therefore, the cellular host should as a default setting
follow the RH0 processing described in Section 3 of RFC 5095.
IPv6 packet fragmentation has known security concerns. The cellular
host must follow the handling of overlapping fragments as described
in [RFC5722] and the cellular host must not fragment any neighbor
discovery messages as described in
[I-D.ietf-6man-nd-extension-headers].
4. Mobility
For the purposes of this document, IP mobility is not relevant. The
movement of cellular hosts within 3GPP networks is handled by link
layer mechanisms in majority of cases. 3GPP Release-8 introduced the
dual-stack Mobile IPv6 (DSMIPv6) for a client based mobility
[RFC5555]. Client based IP mobility is optional in 3GPP
architecture.
5. IANA Considerations
This document has no IANA actions.
Korhonen, et al. Expires April 18, 2013 [Page 11]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
6. Acknowledgements
The authors would like to thank the original authors for their
grounding work on this documents: Gerben Kuijpers, John Loughney,
Hesham Soliman and Juha Wiljakka.
The original RFC 3316 document was based on the results of a team
that included Peter Hedman and Pertti Suomela in addition to the
authors. Peter and Pertti have contributed both text and their IPv6
experience to this document.
The authors would like to thank Jim Bound, Brian Carpenter, Steve
Deering, Bob Hinden, Keith Moore, Thomas Narten, Erik Nordmark,
Michael Thomas, Margaret Wasserman and others at the IPv6 WG mailing
list for their comments and input.
We would also like to thank David DeCamp, Karim El Malki, Markus
Isomaki, Petter Johnsen, Janne Rinne, Jonne Soininen, Vlad Stirbu and
Shabnam Sultana for their comments and input in preparation of this
document.
7. Security Considerations
This document does not specify any new protocols or functionality,
and as such, it does not introduce any new security vulnerabilities.
However, specific profiles of IPv6 functionality are proposed for
different situations, and vulnerabilities may open or close depending
on which functionality is included and what is not. There are also
aspects of the cellular environment that make certain types of
vulnerabilities more severe. The following issues are discussed:
o The suggested limitations (Section 3.1) in the processing of
extension headers limits also exposure to Denial-of-Service (DoS)
attacks through cellular hosts.
o IPv6 addressing privacy [RFC4941] may be used in cellular hosts.
However, it should be noted that in the 3GPP model, the network
would assign new addresses, in most cases, to hosts in roaming
situations and typically, also when the cellular hosts activate a
PDP context. This means that 3GPP networks will already provide a
limited form of addressing privacy, and no global tracking of a
single host is possible through its address. On the other hand,
since a GGSN's coverage area is expected to be very large when
compared to currently deployed default routers (no handovers
between GGSNs are possible), a cellular host can keep an address
for a long time. Hence, IPv6 addressing privacy can be used for
additional privacy during the time the host is on and in the same
area. The privacy features can also be used to e.g., make
Korhonen, et al. Expires April 18, 2013 [Page 12]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
different transport sessions appear to come from different IP
addresses. However, it is not clear that these additional efforts
confuse potential observers any further, as they could monitor
only the network prefix part.
o The use of various security services such as IPsec or TLS in the
connection of typical applications in cellular hosts is discussed
in Section 3 and further pointer for recommendations are given
there.
o The airtime used by cellular hosts is expensive. In some cases,
users are billed according to the amount of data they transfer to
and from their host. It is crucial for both the network and the
users that the airtime is used correctly and no extra charges are
applied to users due to misbehaving third parties. The cellular
links also have a limited capacity, which means that they may not
necessarily be able to accommodate more traffic than what the user
selected, such as a multimedia call. Additional traffic might
interfere with the service level experienced by the user. While
Quality of Service mechanisms mitigate these problems to an
extent, it is still apparent that DoS aspects may be highlighted
in the cellular environment. It is possible for existing DoS
attacks that use for instance packet amplification to be
substantially more damaging in this environment. How these
attacks can be protected against is still an area of further
study. It is also often easy to fill the cellular link and queues
on both sides with additional or large packets.
o Within some service provider networks, it is possible to buy a
prepaid cellular subscription without presenting personal
identification. Attackers that wish to remain unidentified could
leverage this. Note that while the user hasn't been identified,
the equipment still is; the operators can follow the identity of
the device and block it from further use. The operators must have
procedures in place to take notice of third party complaints
regarding the use of their customers' devices. It may also be
necessary for the operators to have attack detection tools that
enable them to efficiently detect attacks launched from the
cellular hosts.
o Cellular devices that have local network interfaces (such as WLAN
or Bluetooth) may be used to launch attacks through them, unless
the local interfaces are secured in an appropriate manner.
Therefore, local network interfaces should have access control to
prevent others from using the cellular host as an intermediary.
o The 3GPP link model mitigates most of the known IPv6 on-link and
neighbor cache targeted attacks (see Section 2.2 and Appendix A).
o Advice for implementations in the face of Neighbor Discovery DoS
attacks may be useful in some environments [RFC6583].
o Section 9 of RFC 6459 discusses further some recent concerns
related to cellular hosts security.
Korhonen, et al. Expires April 18, 2013 [Page 13]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
8. References
8.1. Normative references
[I-D.ietf-6man-nd-extension-headers]
Gont, F., "Security Implications of the Use of IPv6
Extension Headers with IPv6 Neighbor Discovery",
draft-ietf-6man-nd-extension-headers-00 (work in
progress), June 2012.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011.
8.2. Informative references
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
Korhonen, et al. Expires April 18, 2013 [Page 14]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model
The appendix aims to very briefly describe the 3GPP IPv6 addressing
model for 2G (GPRS), 3G (UMTS) and 4G (EPS) cellular networks from
Release-99 onwards. More information for 2G and 3G can be found from
3GPP Technical Specifications 23.060 and T29.061. The equivalent
documentation for 4G can be found from 3GPP Technical Specifications
23.401, 23.402 and 29.061.
There are two possibilities to allocate the address for an IPv6 node:
stateless and stateful autoconfiguration. The stateful address
allocation mechanism needs a DHCP server to allocate the address for
the IPv6 node. On the other hand, the stateless autoconfiguration
procedure does not need any external entity involved in the address
autoconfiguration (apart from the GGSN/PGW). At the time of writing
this document, the IPv6 stateless address autoconfiguration mechanism
is still the only madatory and supported address configuration method
Korhonen, et al. Expires April 18, 2013 [Page 15]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
for the cellular 3GPP link.
In order to support the standard IPv6 stateless address
autoconfiguration mechanism as recommended by the IETF, the GGSN/PGW
shall assign a prefix that is unique within its scope to each primary
PDP context that uses IPv6 stateless address autoconfiguration. This
avoids the necessity to perform Duplicate Address Detection (DAD) at
the network level for every address built by the mobile host. The
GGSN/PGW always provides an Interface Identifier to the mobile host.
The Mobile host uses the interface identifier provided by the GGSN to
generate its link-local address. The GGSN/PGW provides the cellular
host with the interface identifier, usually in a random manner. It
must ensure the uniqueness of such identifier on the link (i.e., no
collisions between its own link-local address and the cellular
host's).
In addition, the GGSN/PGW will not use any of the prefixes assigned
to cellular hosts to generate any of its own addresses. This use of
the interface identifier, combined with the fact that each PDP
Context or PDN Connection is allocated a unique prefix, will
eliminate the need for DAD messages over the air interface, and
consequently reduces inefficient use of radio resources.
Furthermore, the allocation of a prefix to each PDP context will
allow hosts to implement the privacy extensions in RFC 4941 without
the need for further DAD messages.
In practice, the GGSN/PGW only needs to route all traffic to the
cellular host that fall under the prefix assigned to it. This
implies the GGSN/PGW may implement a minimal neighbor discovery
protocol subset; since, due the point-to-point link model and the
absence of link-layer addressing the address resolution can be
entirely statically configured per PDP Context or PDN Connection, and
there is no need to defend any other address than the link-local
address for very unlikely duplicates.
See Sections 5 of RFC 6459 for further discussion on 3GPP address
allocation and link model.
Appendix B. Changes to RFC 3316
B.1. Version -00
o Removal of all sections that can be directly found from RFC 6434.
o Clarifications to 3GPP link model and how Neighbor Discovery works
on it.
Korhonen, et al. Expires April 18, 2013 [Page 16]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
o Addition of RFC 4191 recommendations.
o Addition of DHCPv6-based Prefix Delegation recommendations.
o Addition of RFC 6106 recommendations.
o Addition of RFC 5555 regarding client based mobility.
o Addition of Router Advertisement MTU option handling.
o Addition of Evolved Packet System text.
o Clarification on the primary 3GPP IPv6 transition mechanism.
o Addition of RFC 5095 that deprecates the RH0
o Addition of RFC 5722 and draft-ietf-6man-nd-extension-headers
regarding the IPv6 fragmentation handling.
o Addition of RFC 6583 for Neighbor Discovery denial-of-service
attack considerations.
o Made the PPP IPV6CP support text conditional.
Authors' Addresses
Jouni Korhonen (editor)
Nokia Siemens Networks
Linnoitustie 6
FIN-02600 Espoo
Finland
Email: jouni.nospam@gmail.com
Jari Arkko (editor)
Ericsson
Jorvas 02420
Finland
Email: jari.arkko@piuha.net
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
FINLAND
Email: teemu.savolainen@nokia.com
Korhonen, et al. Expires April 18, 2013 [Page 17]
Internet-Draft IPv6 for for 3GPP Cellular Hosts October 2012
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Korhonen, et al. Expires April 18, 2013 [Page 18]
