IPv6 Operations (V6OPS)                                 J. Korhonen, Ed.
Internet-Draft                                            Renesas Mobile
Obsoletes: 3316 (if approved)                              J. Arkko, Ed.
Intended status: Informational                                  Ericsson
Expires: November 7, 28, 2013                                 T. Savolainen
                                                             S. Krishnan
                                                            May 6, 27, 2013

                      IPv6 for 3GPP Cellular Hosts


   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 have made 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 functionalities that needs need to be
   implemented in addition what is already prescribed in the IPv6 Node
   Requirements document.  It also discusses some issues relating related 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."
   This Internet-Draft will expire on November 7, 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . .  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.4.  IP version 6 over PPP in 3GPP Networks .  . . . . . . . . .  9
     2.6.  MLD in 3GPP Networks . . . . . . . . . . . .  9
     2.5.  Multicast Listener Discovery (MLD) for IPv6  . . . . . . .  9
     2.7. 10
     2.6.  Privacy Extensions for Address Configuration in IPv6 . . . 10
     2.7.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)  . . 10
     2.8.  DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 10
     2.9.  Router preferences and more specific routes  . . . . . . . 10
     2.11. 11
     2.10. Neighbor Discovery and additional host configuration . . . 11
   3.  IP Security  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Extension header considerations  . . . . . . . . . . . . . 11
   4.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Cellular Host IPv6 Addressing in the 3GPP Model . . . 16
   Appendix B.  Changes to RFC 3316 . . . . . . . . . . . . . . . . . 17
     B.1.  Version draft-ietf-v6ops-rfc3316bis-02 draft-ietf-v6ops-rfc3316bis-03 . . . . . . . . . . 17
     B.2.  Version draft-ietf-v6ops-rfc3316bis-01 draft-ietf-v6ops-rfc3316bis-02 . . . . . . . . . . 17 18
     B.3.  Version draft-ietf-v6ops-rfc3316bis-01 . . . . . . . . . . 18
     B.4.  Version draft-ietf-v6ops-rfc3316bis-00 . . . . . . . . . . 17 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

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

1.1.  Scope of this Document

   For the purposes 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, 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 the with discussion on the use
   of these selected IPv6 specifications when operating over a cellular
   interface.  Such a specification is necessary in order for to enable the
   optimal use of IPv6 in a cellular network environment.  The
   description is made from a cellular host point of view.
   Complementary access technologies may be available in 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 to
   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 mainly primarily targeted towards to 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
   types.  This document should not be used as a definitive list of IPv6
   functionalies 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 build-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.  On  One 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, 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

   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 the scope of
   this document and are left for further study.  The primary transition
   mechanism supported by the 3GPP is dual-stack [RFC4213].  Dual-stack
   capable bearers were bearer support has been added to GPRS starting from the 3GPP
   Release-9 and to EPS starting from the Release-8 [RFC6459], whereas in
   the earlier releases 3GPP releases required multiple single IP version bearers had to be used
   to support
   dual stack. dual-stack.

1.2.  Abbreviations

   2G    Second Generation Mobile Telecommunications, such as GSM and
         GPRS technologies.

   3G    Third Generation Mobile Telecommunications, such as UMTS
   4G    Fourth Generation Mobile Telecommunications, such as LTE
   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
   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
   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 document lists IPv6 features for cellular hosts in that are split
   into three groups.

   Basic IP

      In this group, basic parts a list of the basic IPv6 features essential for
      cellular hosts are described.

   IP Security

      In this group, the IP Security related parts are described.


      In this group, IP layer mobility issues are described.

2.  Basic IP

   For most parts refer to the IPv6 Node Requirements document

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. messages [RFC4861].  Some further notes on how these
   are applied in the particular type of an interface can be useful,

   In GPRS, UMTS and EPS 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 enabled brought up (as described in [RFC4861], Section 6.3.7).

   There are no link layer addresses. 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 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. addresses on the 3GPP cellular link

   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 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 a router (i.e., GGSN/PGW)
   initiated NUD.  However, it is unlikely a router to host NUD should
   ever take place on a GPRS, UMTS and EPS links.  See Appendix A for
   more discussion on the router to host NUD.

   In GPRS, UMTS and EPS 3GPP 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.

   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

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

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 with lifetimes set to infinite (both
   valid and the preferred lifetimes).  The advertised prefix cannot ever be
   used for on-link determination (see [RFC6459], Section 5.2). 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

   Hosts in 3GPP networks can set DupAddrDetectTransmits equal to zero,
   as each delegated assigned 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
   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


2.4.  IP version 6 over PPP in 3GPP Networks

   A cellular host in a 3GPP network that supports PPP, PPP on the interface
   between the MT and the TE, 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)
   (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 interface identifier being suggested by the
   MT to the TE, using the IPv6CP option.  To avoid any duplication in link-
   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 (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

2.5.  Multicast Listener Discovery (MLD) for addresses with larger scopes (i.e., ULAs
   and global).

2.6.  MLD in 3GPP Networks 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 may is not always be necessary. necessary, although sending those cause no harm or
   interoperability issues.

   MLD is needed 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.  RFC 4941, and privacy supported by a cellular host.
   Privacy in general, is important for the Internet.  Cellular hosts may use the temporary addresses as
   described in RFC 4941.  However,  In 3GPP networks
   the use lifetime 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 assignment depends upon on many factors such as
   radio coverage, device status and user preferences.  Additionally,  As a result also
   the use of temporary
   address with IPsec may lead prefix the cellular host uses is a subject to more frequent renegotiation for the
   Security Associations. changes.

   Refer to Section 7 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.  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
   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 for 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


2.9.  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 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 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 to the 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

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

5.  IANA Considerations

   This document has no IANA actions.

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

   For the revised version of the RFC 3316 the authors would like thank
   Dave Thaler Thaler, Ales Vizdal, Gang Chen, Ray Hunter and Owen DeLong for his comments
   their comments, reviews and input. inputs.

7.  Security Considerations

   This document does not specify any new protocols or functionality, 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 limits also 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 addresses, prefix, in most cases,
      to hosts in roaming situations and typically, also when the
      cellular hosts activate a PDP Context or a PDN Connection.  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 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 an address 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 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
   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.

8.  References

8.1.  Normative references

              Gont, F., "Security Implications of IPv6 Fragmentation
              with IPv6 Neighbor Discovery",
              draft-ietf-6man-nd-extension-headers-04 (work in
              progress), March 2013.

   [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,
              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.

              3GPP, "General Packet Radio Service (GPRS); Service
              description; Stage 2", 3GPP TS 23.060 11.5.0, March 2013.

              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.

              3GPP, "Architectural enhancements for non-3GPP accesses",
              3GPP TS 23.402 11.6.0, March 2013.

              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.

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 [TS.23060] and [TS.29061].  The
   equivalent documentation for 4G can be found from 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 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 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 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 fall falls 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.  This has also an additional
   effect on a router to host NUD.  There is really no need for, for it,
   since from the GGSN/PGW point of view it does not need to care for a
   addresses, address, just route routes the whole prefix to the cellular host
   direction. 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 what should happen if the router to host NUD fails.

   See Sections 5 of [RFC6459] for further discussion on 3GPP address
   allocation and link model.

Appendix B.  Changes to RFC 3316

B.1.  Version draft-ietf-v6ops-rfc3316bis-03

   o  Clarified that RFC4941 or similar technologies instead of plain
      RFC4941 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 hard (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 RA PIO options.
   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  Implemented numerous WGLC #1 comments.

B.2.  Version draft-ietf-v6ops-rfc3316bis-02

   o  Clarified explicitly that a NUD from the gateway side to the UE's
      link-local address is possible.
   o  Added references to 3GPP specifications.


B.3.  Version draft-ietf-v6ops-rfc3316bis-01

   o  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


B.4.  Version draft-ietf-v6ops-rfc3316bis-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.
   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)
   Renesas Mobile
   Porkkalankatu 24
   FIN-00180 Helsinki

   Email: jouni.nospam@gmail.com
   Jari Arkko (editor)
   Jorvas  02420

   Email: jari.arkko@piuha.net

   Teemu Savolainen
   Hermiankatu 12 D
   FI-33720 Tampere

   Email: teemu.savolainen@nokia.com

   Suresh Krishnan
   8400 Decarie Blvd.
   Town of Mount Royal, QC

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com