GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7066

Internet Engineering Task Force (IETF) J. Korhonen, Ed. Request for Comments: 7066 Broadcom Obsoletes: 3316 J. Arkko, Ed. Category: Informational Ericsson ISSN: 2070-1721 T. Savolainen

                                                                 Nokia
                                                           S. Krishnan
                                                              Ericsson
                                                         November 2013
IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts

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 have made the 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 Third
 Generation Partnership Project (3GPP) networks).  This document also
 lists specific IPv6 functionalities that need to be implemented in
 addition to what is already prescribed in the IPv6 Node Requirements
 document (RFC 6434).  It also discusses some issues related to the
 use of these components when operating in these networks.  This
 document obsoletes RFC 3316.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7066.

Korhonen, et al. Informational [Page 1] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

Copyright Notice

 Copyright (c) 2013 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.

Table of Contents

 1. Introduction ....................................................3
    1.1. Scope of This Document .....................................3
    1.2. Abbreviations ..............................................5
    1.3. Cellular Host IPv6 Features ................................6
 2. Basic IP ........................................................6
    2.1. Internet Protocol Version 6 ................................6
    2.2. Neighbor Discovery in 3GPP Networks ........................6
    2.3. Stateless Address Autoconfiguration ........................8
    2.4. IP Version 6 over PPP ......................................8
    2.5. Multicast Listener Discovery (MLD) for IPv6 ................9
    2.6. Privacy Extensions for Address Configuration in IPv6 .......9
    2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) ......9
    2.8. DHCPv6 Prefix Delegation ..................................10
    2.9. Router Preferences and More-Specific Routes ...............10
    2.10. Neighbor Discovery and Additional Host Configuration .....10
 3. IP Security ....................................................11
    3.1. Extension Header Considerations ...........................11
 4. Mobility .......................................................11
 5. Acknowledgements ...............................................11
 6. Security Considerations ........................................12
 7. References .....................................................14
    7.1. Normative References ......................................14
    7.2. Informative References ....................................15
 Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model .......17
 Appendix B. Changes from RFC 3316 .................................18

Korhonen, et al. Informational [Page 2] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

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
 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 a detailed description of IPv6 in
 3GPP networks, including the Evolved Packet System, see [RFC6459].

1.1. Scope of This Document

 For the purpose 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 and Release-4 to
 Release-11; EPS Release-8 to Release-11; and 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 a cellular
 interface.  Such a specification is necessary in order to enable the
 optimal use of IPv6 in a cellular network environment.  The
 description is made from the point of view of a cellular host.
 Complementary access technologies may be supported by 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
 provide an easy reference for those who are 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 its nature, and it is not intended
 to replace, update, or contradict any IPv6 standards documents or the
 IPv6 Node Requirements [RFC6434].
 This document is primarily targeted to the implementers of cellular
 hosts that will be used with the cellular networks listed in this
 document.  This 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

Korhonen, et al. Informational [Page 3] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 this document does not provide any detailed analysis on other link
 types.  This document should not be used as a definitive list of IPv6
 functionalities 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 built-in
    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.  One example of such a host is a laptop
    computer that uses a USB cellular modem for cellular access.
 If a cellular host has additional IP-capable interfaces (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 was written.  Ongoing work on IPv6 may affect what is
 required of future hosts.
 Transition mechanisms used by cellular hosts are not in the scope of
 this document and are left for further study.  The primary transition
 mechanism supported by 3GPP is dual-stack [RFC4213].  Dual-stack-
 capable bearer support has been added to GPRS starting from 3GPP
 Release-9 and to EPS starting from Release-8 [RFC6459], whereas the
 earlier 3GPP releases required multiple single IP version bearers to
 support dual-stack.

Korhonen, et al. Informational [Page 4] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

1.2. Abbreviations

 2G    Second Generation Mobile Telecommunications, such as Global
       System for Mobile Communications (GSM) and GPRS technologies.
 3G    Third Generation Mobile Telecommunications, such as UMTS
       technology.
 4G    Fourth Generation Mobile Telecommunications, such as LTE
       technology.
 3GPP  Third Generation Partnership Project.  Throughout the document,
       the term "3GPP networks" refers to architectures standardized
       by 3GPP, in Second, Third, and Fourth Generation releases: 99,
       4, and 5, as well as future releases.
 EPS   Evolved Packet System.
 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 a Serving GPRS
       Support Node (SGSN) in EPS (and the default router for 3GPP
       IPv6 cellular hosts when using Proxy Mobile IPv6 (PMIPv6))).
 TE    Terminal Equipment, for example, a laptop attached through a
       3GPP handset.
 UMTS  Universal Mobile Telecommunications System.
 WLAN  Wireless Local Area Network.

Korhonen, et al. Informational [Page 5] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

1.3. Cellular Host IPv6 Features

 This document lists IPv6 features for cellular hosts; these features
 are split into three groups and are discussed below.
 Basic IP
    In this group, the basic IPv6 features essential for cellular
    hosts are listed and described.
 IP Security
    In this group, the parts related to IP Security are described.
 Mobility
    In this group, IP-layer mobility issues are described.

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 to 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 [RFC4861].  Some further notes on how Neighbor
 Discovery is applied in the particular type of an interface can be
 useful.
 In 3GPP 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 brought up (as described in [RFC4861],
 Section 6.3.7).
 There are no link-layer addresses on the 3GPP cellular link
 technology.  Therefore, address resolution and next-hop determination
 are not needed.  If the cellular host still attempts to do address

Korhonen, et al. Informational [Page 6] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 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 on the 3GPP cellular link technology.
 The cellular host must support Neighbor Unreachability Detection
 (NUD) as specified in [RFC4861].  Note that the link-layer address
 considerations above also apply to NUD.  The NUD-triggered Neighbor
 Advertisement is also unlikely to contain the Target link-layer
 address option as there are no link-layer addresses.  The cellular
 host should also be prepared for NUD initiated by a router (i.e.,
 GGSN/PGW).  However, it is unlikely a router-to-host NUD would ever
 take place on GPRS, UMTS, or EPS links.  See Appendix A for more
 discussion on the router-to-host NUD.
 In 3GPP networks, it is 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.
 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 [RFC3550], the RTP Control Protocol (RTCP) [RFC3550]
 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 [RFC3261], 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.

Korhonen, et al. Informational [Page 7] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

2.3. 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.
 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 with lifetimes set to infinite (both
 valid and preferred lifetimes).  The advertised prefix cannot ever be
 used for on-link determination (see [RFC6459], Section 5.2), and the
 lifetime of the advertised prefix is tied to the PDP Context/PDN
 Connection lifetime.  Keeping the forward compatibility in mind,
 there is no reason for the 3GPP cellular host to have 3GPP-specific
 handling of the prefix information option(s) although 3GPP
 specifications state that the Router Advertisement may contain a
 maximum of one prefix information option and the lifetimes are set to
 infinite.
 Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero,
 as each assigned prefix is unique within its scope when advertised
 using 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
 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 on the
 cellular interface.
 See Appendix A for more details on 3GPP IPv6 Stateless Address
 Autoconfiguration.

2.4. IP Version 6 over PPP

 A cellular host in a 3GPP network that supports PPP [RFC1661] on the
 interface between the MT and the TE must support the IPv6 Control
 Protocol (IPV6CP) [RFC5072] 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, e.g., a USB dongle) 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

Korhonen, et al. Informational [Page 8] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 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/PGW 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] or similar
 technologies for unique local IPv6 unicast addresses [RFC4193] and
 global addresses is not affected by the above procedure.

2.5. Multicast Listener Discovery (MLD) for IPv6

 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 is not necessary, although sending them causes
 no harm or interoperability issues.  Refer to Section 5.10 of
 [RFC6434] for MLD usage for multicast group knowledge that is not
 link-local.

2.6. Privacy Extensions for Address Configuration in IPv6

 Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
 or other similar technologies may be supported by a cellular host.
 Privacy, in general, is important for the Internet.  In 3GPP
 networks, the lifetime of an address assignment depends on many
 factors such as radio coverage, device status, and user preferences.
 As a result, the prefix the cellular host uses is also subject to
 frequent changes.
 Refer to Section 6 for a discussion of the benefits of Privacy
 Extensions in a 3GPP network.

2.7. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

 As of 3GPP Release-11, the Dynamic Host Configuration Protocol for
 IPv6 (DHCPv6) [RFC3315] is neither required nor supported for address
 autoconfiguration.  IPv6 Stateless Address 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

Korhonen, et al. Informational [Page 9] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 and SIP server addresses, and DHCPv6 Prefix Delegation [RFC3633] may
 be used to delegate a prefix to the cellular host for use on its
 downstream non-cellular links.

2.8. 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 to 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.9. Router Preferences and More-Specific Routes

 The cellular host should implement the Default Router Preferences and
 More-Specific Routes extension to Router Advertisement messages
 [RFC4191].  These options may be useful for cellular hosts that also
 have additional interfaces on which IPv6 is used.

2.10. Neighbor Discovery and Additional Host Configuration

 The DNS server configuration is learned from the 3GPP link-layer
 signaling.  However, the cellular host should also implement the IPv6
 Router Advertisement Options for DNS Configuration [RFC6106].  DHCPv6
 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 techniques other than the PPP
 interface.
 The cellular host should also honor the MTU option in the Router
 Advertisement (see [RFC4861], Section 4.6.4).  The 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 to the cellular host an
 MTU that takes the additional tunneling overhead into account.

Korhonen, et al. Informational [Page 10] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

3. IP Security

 IPsec [RFC4301] is a fundamental, but not mandatory, part of IPv6.
 Refer to the IPv6 Node Requirements (Section 11 of [RFC6434]) for the
 security requirements that also apply to cellular hosts.

3.1. Extension Header Considerations

 Support for the Routing Header Type 0 (RH0) has been deprecated
 [RFC5095].  Therefore, the cellular host should by default follow the
 RH0 processing described in Section 3 of [RFC5095].
 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 [RFC6980].

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 the majority of cases.  3GPP Release-8 introduced
 Dual-Stack Mobile IPv6 (DSMIPv6) for client-based mobility [RFC5555].
 Client-based IP mobility is optional in the 3GPP architecture.

5. Acknowledgements

 The authors would like to thank the original authors for their
 groundwork for this document: Gerben Kuijpers, John Loughney, Hesham
 Soliman, and Juha Wiljakka.
 The original [RFC3316] 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 on 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.

Korhonen, et al. Informational [Page 11] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 For this revised version of [RFC3316] the authors would like to thank
 Dave Thaler, Ales Vizdal, Gang Chen, Ray Hunter, Charlie Kaufman,
 Owen DeLong, and Alexey Melnikov for their comments, reviews, and
 input.

6. Security Considerations

 This document does not specify any new protocols or functionalities,
 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 also limits exposure to Denial-of-Service (DoS)
    attacks through cellular hosts.
 o  IPv6 addressing privacy [RFC4941] or similar technology may be
    used in cellular hosts.  However, it should be noted that in the
    3GPP model, the network would assign a new prefix, in most cases,
    to hosts in roaming situations; the network would also typically
    assign a new prefix when the cellular hosts activate a PDP Context
    or a PDN Connection. 3GPP devices must not use interface
    identifiers that are unique to the device, so the only difference
    in address between 3GPP devices using Stateless Address
    Autoconfiguration is in the prefix.  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/PGW's coverage area is expected to
    be very large when compared to currently deployed default routers
    (no handovers between GGSN/PGWs are possible), a cellular host can
    keep a prefix 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 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 and recommendations of various security services such as
    IPsec or Transport Layer Security (TLS) [RFC5246] in the
    connection of typical applications that also apply to cellular
    hosts are discussed in Section 11 of [RFC6434].

Korhonen, et al. Informational [Page 12] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 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 for 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 [RFC6459] further discusses some recent concerns
    related to the security of cellular hosts.

Korhonen, et al. Informational [Page 13] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

7. References

7.1. Normative References

 [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.
 [RFC6980]   Gont, F., "Security Implications of IPv6 Fragmentation
             with IPv6 Neighbor Discovery", RFC 6980, August 2013.

Korhonen, et al. Informational [Page 14] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

7.2. Informative References

 [RFC1661]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
             RFC 1661, July 1994.
 [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
             A., Peterson, J., Sparks, R., Handley, M., and E.
             Schooler, "SIP: Session Initiation Protocol", RFC 3261,
             June 2002.
 [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.
 [RFC3316]   Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and
             J.  Wiljakka, "Internet Protocol Version 6 (IPv6) for
             Some Second and Third Generation Cellular Hosts",
             RFC 3316, April 2003.
 [RFC3550]   Schulzrinne, H., Casner, S., Frederick, R., and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", STD 64, RFC 3550, July 2003.
 [RFC3633]   Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
             Host Configuration Protocol (DHCP) version 6", RFC 3633,
             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.
 [RFC5072]   Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
             PPP", RFC 5072, September 2007.
 [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 [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.

Korhonen, et al. Informational [Page 15] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 [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.
 [TS.23060]  3GPP, "General Packet Radio Service (GPRS); Service
             description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.
 [TS.23401]  3GPP, "General Packet Radio Service (GPRS) enhancements
             for Evolved Universal Terrestrial Radio Access Network
             (E-UTRAN) access", 3GPP TS 23.401 11.5.0, March 2013.
 [TS.23402]  3GPP, "Architectural enhancements for non-3GPP accesses",
             3GPP TS 23.402 11.6.0, March 2013.
 [TS.29061]  3GPP, "Interworking between the Public Land Mobile
             Network (PLMN) supporting packet based services and
             Packet Data Networks (PDN)", 3GPP TS 29.061 11.4.0,
             March 2013.

Korhonen, et al. Informational [Page 16] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

Appendix A. Cellular Host IPv6 Addressing in the 3GPP Model

 This 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 in
 3GPP Technical Specifications [TS.23060] and [TS.29061].  The
 equivalent documentation for 4G can be found in 3GPP Technical
 Specifications [TS.23401], [TS.23402], and [TS.29061].
 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 Address
 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 mandatory and supported
 address configuration method 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 single /64 IPv6 prefix that is unique within its scope
 to each primary PDP Context or PDN Connection that uses IPv6
 Stateless Address Autoconfiguration.  This avoids the necessity to
 perform Duplicate Address Detection (DAD) at the network level for
 any 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/PGW 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 an 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 or PDN
 Connection will allow hosts to implement the Privacy Extensions in
 [RFC4941] without the need for further DAD messages.
 In practice, the GGSN/PGW only needs to route all traffic destined to
 the cellular host that falls under the prefix assigned to it.  This
 implies the GGSN/PGW may implement a minimal Neighbor Discovery
 protocol subset since, due to the point-to-point link model and the
 absence of link-layer addressing, the address resolution can be

Korhonen, et al. Informational [Page 17] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 entirely statically configured per PDP Context or PDN Connection, and
 there is no need to defend any addresses other than the link-local
 addresses for very unlikely duplicates.  This also has an additional
 effect on a router-to-host NUD.  There is really no need for the NUD,
 since from the point of view of GGSN/PGW, GGSN/PGW does not need to
 care for a single address but just routes the whole prefix to the
 cellular host.  However, the cellular host must be prepared for the
 unlikely event of receiving a NUD against its link-local address.  It
 should be noted that the 3GPP specifications at the time of writing
 this document are silent about what should happen if the router-to-
 host NUD fails.
 See Section 5 of [RFC6459] for further discussion on 3GPP address
 allocation and the 3GPP link model.

Appendix B. Changes from RFC 3316

 o  Clarified that [RFC4941] or similar technologies may be used for
    privacy purposes (as stated in [RFC6459]).
 o  Clarified that MLD for link-local addresses is not necessary, but
    doing it causes no harm (instead of saying it may not be needed in
    some cases).
 o  Clarified that a cellular host should not do any changes in its
    stack to meet the 3GPP link restriction on the Router
    Advertisement Prefix Information Options (PIOs).
 o  Clarified that a cellular host should not do any changes in its
    stack to meet the infinite prefix lifetime requirement the 3GPP
    link has.
 o  Clarified that the prefix lifetime is tied to the PDP Context/PDN
    Connection lifetime.
 o  Clarified explicitly that a NUD from the gateway side to the User
    Equipment's link-local address is possible.
 o  Added references to 3GPP specifications.
 o  Provided additional clarification on NUD on 3GPP cellular links.
 o  Added an explicit note that the prefix on the link is /64.
 o  Clarified that DHCPv6 ([RFC3315]) is not used at all for address
    autoconfiguration.
 o  Removed all sections that can be directly found in [RFC6434].

Korhonen, et al. Informational [Page 18] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

 o  Added clarifications to 3GPP link model and how Neighbor Discovery
    works on it.
 o  Added [RFC4191] recommendations.
 o  Added DHCPv6-based Prefix Delegation recommendations.
 o  Added [RFC6106] recommendations.
 o  Added reference to [RFC5555] regarding client-based mobility.
 o  Added text regarding Router Advertisement MTU option handling.
 o  Added Evolved Packet System text.
 o  Added clarification on the primary 3GPP IPv6 transition mechanism.
 o  Added reference to [RFC5095], which deprecates the RH0.
 o  Added references to [RFC5722] and [RFC6980] regarding IPv6
    fragmentation handling.
 o  Added reference to [RFC6583] for Neighbor Discovery denial-of-
    service attack considerations.
 o  Made the PPP IPV6CP [RFC5072] support text conditional.

Korhonen, et al. Informational [Page 19] RFC 7066 IPv6 for 3GPP Cellular Hosts November 2013

Authors' Addresses

 Jouni Korhonen (editor)
 Broadcom
 Porkkalankatu 24
 FIN-00180 Helsinki
 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
 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. Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7066.txt · Last modified: 2013/11/06 01:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki