doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7066.txt b/doc/rfc/rfc7066.txt
new file mode 100644
index 0000000..a367ed8
--- /dev/null
+++ b/doc/rfc/rfc7066.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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]
+