summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7278.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7278.txt')
-rw-r--r--doc/rfc/rfc7278.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc7278.txt b/doc/rfc/rfc7278.txt
new file mode 100644
index 0000000..b1ef7ba
--- /dev/null
+++ b/doc/rfc/rfc7278.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Byrne
+Request for Comments: 7278 T-Mobile USA
+Category: Informational D. Drown
+ISSN: 2070-1721 A. Vizdal
+ Deutsche Telekom AG
+ June 2014
+
+
+ Extending an IPv6 /64 Prefix from a
+ Third Generation Partnership Project (3GPP)
+ Mobile Interface to a LAN Link
+
+Abstract
+
+ This document describes requirements for extending an IPv6 /64 prefix
+ from a User Equipment Third Generation Partnership Project (3GPP)
+ radio interface to a LAN link and describes two implementation
+ examples.
+
+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/rfc7278.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Byrne, et al. Informational [Page 1]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+ 2. The Challenge of Providing IPv6 Addresses to a LAN Link via a
+ 3GPP UE .........................................................4
+ 3. Requirements for Extending the 3GPP Interface /64 IPv6
+ Prefix to a LAN Link ............................................4
+ 4. Example Methods for Extending the 3GPP Interface /64
+ IPv6 Prefix to a LAN Link .......................................5
+ 4.1. General Behavior for All Example Scenarios .................5
+ 4.2. Example Scenario 1: Global Address Only Assigned to
+ LAN Link ...................................................5
+ 4.3. Example Scenario 2: A Single Global Address Assigned to a
+ 3GPP Radio and LAN Link ....................................7
+ 5. Security Considerations .........................................8
+ 6. Acknowledgments .................................................8
+ 7. Informative References ..........................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Byrne, et al. Informational [Page 2]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+1. Introduction
+
+ 3GPP mobile cellular networks such as Global System for Mobile
+ Communications (GSM), Universal Mobile Telecommunications System
+ (UMTS), and Long Term Evolution (LTE) have architectural support for
+ IPv6 [RFC6459], but only 3GPP Release-10 and onwards of the 3GPP
+ specification [TS.23401] supports DHCPv6 Prefix Delegation [RFC3633]
+ for delegating IPv6 prefixes to a single LAN link.
+
+ To facilitate the use of IPv6 in a LAN prior to the deployment of
+ DHCPv6 Prefix Delegation in 3GPP networks and in User Equipment (UE),
+ this document describes requirements and provides examples on how the
+ 3GPP UE radio interface assigned global /64 prefix may be extended
+ from the 3GPP radio interface to a LAN link.
+
+ There are two scenarios where this might be done. The first is where
+ the 3GPP node sets up and manages its own LAN (e.g., an IEEE 802.11
+ Service Set Identifier (SSID)) and provides single-homed service to
+ hosts that connect to this LAN. A second scenario is where the 3GPP
+ node connects to an existing LAN and acts as a router in order to
+ provide redundant or multi-homed IPv6 service.
+
+ This document is intended to address the first scenario; it is not
+ applicable to the second scenario, because the operational
+ complexities of the second scenario are not addressed.
+
+ This can be achieved by receiving the Router Advertisement (RA)
+ [RFC4861] announced globally unique /64 IPv6 prefix from the 3GPP
+ radio interface by the UE and then advertising the same IPv6 prefix
+ to the LAN link with RA. For all of the cases in the scope of this
+ document, the UE may be any device that functions as an IPv6 router
+ between the 3GPP network and a LAN.
+
+ This document describes requirements for achieving an IPv6 prefix
+ extension from a 3GPP radio interface to a LAN link including two
+ practical implementation examples:
+
+ 1) The 3GPP UE only has a global-scope address on the LAN link.
+
+ 2) The 3GPP UE maintains the same consistent 128-bit global-scope
+ IPv6 anycast address [RFC4291] on the 3GPP radio interface and the
+ LAN link. The LAN link is configured as a /64 and the 3GPP radio
+ interface is configured as a /128.
+
+ Section 4 describes the characteristics of each of the two example
+ approaches.
+
+
+
+
+
+Byrne, et al. Informational [Page 3]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+1.2. Special Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ Note that this document is not a Standard, and conformance with it is
+ not required in order to claim conformance with IETF Standards for
+ IPv6.
+
+ This document uses the normative keywords only for precision.
+
+2. The Challenge of Providing IPv6 Addresses to a LAN Link via a
+ 3GPP UE
+
+ As described in [RFC6459], 3GPP networks assign a /64 global-scope
+ prefix to each UE using RA. DHCPv6 Prefix Delegation is an optional
+ part of 3GPP Release-10 and is not covered by any earlier releases.
+ Neighbor Discovery Proxy (ND Proxy) [RFC4389] functionality has been
+ suggested as an option for extending the assigned /64 from the 3GPP
+ radio interface to the LAN link, but ND Proxy is an Experimental
+ protocol and has some limitations with loop avoidance.
+
+ DHCPv6 is the best way to delegate a prefix to a LAN link. The
+ methods described in this document SHOULD only be applied when
+ deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP
+ network and the UE. The methods described in this document are at
+ various stages of implementation and deployment planning. The goal
+ of this memo is to document the available methods that may be used
+ prior to DHCPv6 deployment.
+
+3. Requirements for Extending the 3GPP Interface /64 IPv6 Prefix to a
+ LAN Link
+
+ R-1: The 3GPP network provided /64 prefix MUST be made available on
+ the LAN link.
+
+ LAN attached devices shall be able to use the 3GPP network
+ assigned IPv6 prefix (e.g. using IPv6 Stateless Address
+ Autoconfiguration - SLAAC [RFC4862]).
+
+ R-2: The UE MUST defend all of its IPv6 addresses on the LAN link.
+
+ In case a LAN attached node will, for example, autoconfigure the
+ same global IPv6 address as used on the 3GPP interface, the UE
+ must fail the Duplicate Address Detection (DAD) [RFC4862] process
+ run by the LAN node.
+
+
+
+
+Byrne, et al. Informational [Page 4]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+ R-3: The LAN link configuration MUST be tightly coupled with the 3GPP
+ link state.
+
+ R-4: The UE MUST decrement the time to live (TTL) when passing
+ packets between IPv6 links across the UE.
+
+4. Example Methods for Extending the 3GPP Interface /64 IPv6 Prefix to
+ a LAN Link
+
+4.1. General Behavior for All Example Scenarios
+
+ As [RFC6459] describes, the 3GPP-network-assigned /64 is completely
+ dedicated to the UE and the gateway does not consume any of the /64
+ addresses. The gateway routes the entire /64 to the UE and does not
+ perform ND or Neighbor Unreachability Detection (NUD) [RFC4861].
+ Communication between the UE and the gateway is only done using
+ link-local addresses and the link is point-to-point. This allows
+ for the UE to reliably manipulate the /64 from the 3GPP radio
+ interface without negatively impacting the point-to-point 3GPP radio
+ link interface. The LAN link RA configuration must be tightly
+ coupled with the 3GPP link state. If the 3GPP link goes down or
+ changes the IPv6 prefix, that state should be reflected in the LAN
+ link IPv6 configuration. Just as in a standard IPv6 router, the
+ packet TTL will be decremented when passing packets between IPv6
+ links across the UE. The UE is employing the weak host model
+ [RFC1122]. The RA function on the UE is exclusively run on the LAN
+ link.
+
+ The LAN-link-originated RA message carries a copy of the following
+ 3GPP radio-link-received RA message option fields:
+
+ o MTU (if not provided by the 3GPP network, the UE will provide its
+ 3GPP link MTU size)
+
+ o Prefix Information
+
+4.2. Example Scenario 1: Global Address Only Assigned to LAN Link
+
+ For this case, the UE receives the RA from the 3GPP network but does
+ not use a global address on the 3GPP interface. The 3GPP-interface-
+ received RA /64 prefix information is used to configure the Neighbor
+ Discovery Protocol (NDP) on the LAN. The UE assigns itself an IPv6
+ address on the LAN link from the 3GPP-interface-received RA. The LAN
+ link uses RA to announce the prefix to the LAN. The UE LAN link
+ interface defends its LAN IPv6 address with DAD. The UE shall not
+ run SLAAC to assign a global address on the 3GPP radio interface
+ while routing is enabled.
+
+
+
+
+Byrne, et al. Informational [Page 5]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+ This method allows the UE to originate and terminate IPv6
+ communications as a host while acting as an IPv6 router. The
+ movement of the IPv6 prefix from the 3GPP radio interface to the LAN
+ link may result in long-lived data connections being terminated
+ during the transition from a host-only mode to router-and-host mode.
+ Connections that are likely to be affected are ones that have been
+ specifically bound to the 3GPP radio interface. This method is
+ appropriate if the UE or software on the UE cannot support multiple
+ interfaces with the same anycast IPv6 address and the UE requires
+ global connectivity while acting as a router.
+
+ Below is the general procedure for this scenario:
+
+ 1. The user activates router functionality for a LAN on the UE.
+
+ 2. The UE checks to make sure the 3GPP interface is active and has
+ an IPv6 address. If the interface does not have an IPv6 address,
+ an attempt will be made to acquire one; otherwise, the procedure
+ will terminate.
+
+ 3. In this example, the UE finds the 3GPP interface is active and
+ has the IPv6 address 2001:db8:ac10:f002:1234:4567:0:9 assigned.
+
+ 4. The UE moves the address 2001:db8:ac10:f002:1234:4567:0:9 as a
+ /64 from the 3GPP interfaces to the LAN link interface, disables
+ the IPv6 SLAAC feature on the 3GPP radio interface to avoid
+ address autoconfiguration, and begins announcing the prefix
+ 2001:db8:ac10:f002::/64 via RA to the LAN. For this example, the
+ LAN has 2001:db8:ac10:f002:1234:4567:0:9/64 and the 3GPP radio
+ only has a link-local address.
+
+ 5. The UE directly processes all packets destined to itself at
+ 2001:db8:ac10:f002:1234:4567:0:9.
+
+ 6. The UE, acting as a router running NDP on the LAN, will route
+ packets to and from the LAN. IPv6 packets passing between
+ interfaces will have the TTL decremented.
+
+ 7. On the LAN link interface, there is no chance of address conflict
+ since the address is defended using DAD. The 3GPP radio
+ interface only has a link-local address.
+
+
+
+
+
+
+
+
+
+
+Byrne, et al. Informational [Page 6]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+4.3. Example Scenario 2: A Single Global Address Assigned to a
+ 3GPP Radio and LAN Link
+
+ In this method, the UE assigns itself one address from the 3GPP-
+ network RA-announced /64. This one address is configured as anycast
+ [RFC4291] on both the 3GPP radio link as a /128 and on the LAN link
+ as a /64. This allows the UE to maintain long-lived data connections
+ since the 3GPP radio interface address does not change when the
+ router function is activated. This method may cause complications
+ for certain software that may not support multiple interfaces with
+ the same anycast IPv6 address, or are sensitive to prefix length
+ changes. This method also creates complications for ensuring
+ uniqueness for Privacy Extensions [RFC4941]. When Privacy Extensions
+ are in use, all temporary addresses will be copied from the 3GPP
+ radio interface to the LAN link. The preferred and valid lifetimes
+ will be synchronized, such that the temporary anycast addresses on
+ both interfaces expire simultaneously.
+
+ There might also be more complex scenarios in which the prefix length
+ is not changed and privacy extensions are supported by having the
+ subnet span multiple interfaces, as ND Proxy does [RFC4389]. Further
+ elaboration is out of scope of the present document.
+
+ Below is the general procedure for this scenario:
+
+ 1. The user activates router functionality for a LAN on the UE.
+
+ 2. The UE checks to make sure the 3GPP interface is active and has
+ an IPv6 address. If the interface does not have an IPv6 address,
+ an attempt will be made to acquire one; otherwise, the procedure
+ will terminate.
+
+ 3. In this example, the UE finds the 3GPP interface is active and
+ has the IPv6 address 2001:db8:ac10:f002:1234:4567:0:9 assigned.
+
+ 4. The UE moves the address 2001:db8:ac10:f002:1234:4567:0:9 as an
+ anycast /64 from the 3GPP interface to the LAN interface and
+ begins announcing the prefix 2001:db8:ac10:f002::/64 via RA to
+ the LAN. The 3GPP interface maintains the same IPv6 anycast
+ address with a /128. For this example, the LAN has
+ 2001:db8:ac10:f002:1234:4567:0:9/64 and the 3GPP radio interface
+ has 2001:db8:ac10:f002:1234:4567:0:9/128.
+
+ 5. The UE directly processes all packets destined to itself at
+ 2001:db8:ac10:f002:1234:4567:0:9.
+
+
+
+
+
+
+Byrne, et al. Informational [Page 7]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+ 6. On the LAN interface, there is no chance of address conflict
+ since the address is defended using DAD. The 3GPP radio
+ interface only has a /128 and no other systems on the 3GPP radio
+ point-to-point link may use the global /64.
+
+5. Security Considerations
+
+ Since the UE will be switched from an IPv6 host mode to an IPv6
+ router-and-host mode, basic IPv6 Customer Premises Equipment (CPE)
+ security functions [RFC6092] SHOULD be applied.
+
+ Despite the use of temporary IPv6 addresses, the mobile-network-
+ provided /64 prefix is common to all the LAN-attached devices
+ potentially concerning privacy. An IPv6 prefix provided by a nomadic
+ device (e.g., a smartphone) is not a long-lived one due to
+ re-attaches caused by a device reload, traveling through loosely
+ covered areas, etc. The network will provide a new IPv6 prefix after
+ a successful re-attach.
+
+ 3GPP-mobile-network-capable CPEs (e.g., a router) are likely to keep
+ the mobile network data connection up for a longer time. Some mobile
+ networks may be re-setting the mobile network connection regularly
+ (e.g., every 24 hours), others may not. Privacy-concerned users
+ shall take appropriate measures to not keep their IPv6 prefixes long
+ lived.
+
+6. Acknowledgments
+
+ Many thanks for review and discussion from Dave Thaler, Sylvain
+ Decremps, Mark Smith, Dmitry Anipko, Masanobu Kawashima, Teemu
+ Savolainen, Mikael Abrahamsson, Eric Vyncke, Alexandru Petrescu,
+ Jouni Korhonen, Lorenzo Colitti, Julien Laganier, Owen DeLong, Holger
+ Metschulat, Yaron Sheffer, and Victor Kuarsingh. Special thanks to
+ Ann Cerveny for her language review.
+
+7. Informative References
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
+ Host Configuration Protocol (DHCP) version 6", RFC 3633,
+ December 2003.
+
+
+
+
+
+Byrne, et al. Informational [Page 8]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
+ Proxies (ND Proxy)", RFC 4389, April 2006.
+
+ [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.
+
+ [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
+ Capabilities in Customer Premises Equipment (CPE) for
+ Providing Residential IPv6 Internet Service", RFC 6092,
+ January 2011.
+
+ [RFC6459] Korhonen, J., Ed., 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.
+
+ [TS.23401] 3GPP, "General Packet Radio Service (GPRS) enhancements
+ for Evolved Universal Terrestrial Radio Access Network
+ (E-UTRAN) access", 3GPP TS 23.401 10.0.0, June 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Byrne, et al. Informational [Page 9]
+
+RFC 7278 Extending an IPv6 /64 Prefix June 2014
+
+
+Authors' Addresses
+
+ Cameron Byrne
+ T-Mobile USA
+ Bellevue, Washington, USA
+ EMail: Cameron.Byrne@T-Mobile.com
+
+
+ Dan Drown
+ EMail: Dan@Drown.org
+
+
+ Ales Vizdal
+ Deutsche Telekom AG
+ Tomickova 2144/1
+ Prague, 149 00
+ Czech Republic
+ EMail: Ales.Vizdal@T-Mobile.cz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Byrne, et al. Informational [Page 10]
+