idnits 2.17.1 draft-ietf-v6ops-64share-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 48 has weird spacing: '...g Group draf...' == Line 61 has weird spacing: '...g Group draf...' == Line 111 has weird spacing: '...g Group draf...' == Line 162 has weird spacing: '...g Group draf...' == Line 213 has weird spacing: '...g Group draf...' -- The document date (December 14, 2012) is 4141 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.draft-binet-v6ops-cellular-host-requirement' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 203, but no explicit reference was found in the text -- No information found for draft-binet-v6ops-cellular-host-requirement - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS Working Group C. Byrne 3 Internet-Draft T-Mobile USA 4 Intended Status: Informational D. Drown 5 Expires: June 17, 2013 December 14, 2012 7 Sharing /64 3GPP Mobile Interface Subnet to a LAN 8 draft-ietf-v6ops-64share-00 10 Abstract 12 This document describes a known and implemented method of sharing a 13 /64 IPv6 prefix from a User Equipment 3GPP radio interface to a 14 tethered LAN. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 17, 2013. 33 Copyright and License Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. The Challenge of Providing IPv6 Addresses to a 3GPP Tethered 54 LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Method for Sharing the 3GPP Interface /64 to the Tethered LAN . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. Informative References . . . . . . . . . . . . . . . . . . . . 5 61 V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 63 1. Introduction 65 3GPP mobile cellular networks such as GSM, UMTS, and LTE have 66 architectural support for IPv6 [RFC6459], but only 3GPP Release-10 67 and onwards of the 3GPP specification supports DHCPv6 [RFC3633] for 68 delegating IPv6 addresses to a tethered LAN. To facilitate the use 69 of IPv6 in a tethered LAN prior to deployment of DHCPv6 in a 3GPP 70 network and in User Equipment (UE), this document describes how the 71 3GPP UE interface assigned /64 subnet may be shared from the 3GPP 72 interface to a tethered LAN. This is achieved by specifying the UE 73 3GPP interface as an IPv6 /128 subnet taken from the 3GPP interface's 74 network assigned /64 subnet. Then, assign the same address to the 75 tethered LAN interface with the full /64 subnet. The /64 tethered 76 LAN subnet will then be advertised to the tethered LAN via Router 77 Advertisements (RA) [RFC4861]. 79 The end result is that all UE interfaces have link-local IPv6 80 addresses, the UE's 3GPP interface has a /128 address from the 3GPP 81 network assigned /64, and the same address that is assigned to the 82 3GPP interface is assigned to the tethered LAN interface with a /64 83 subnet and advertised to the LAN via RA. This approach only impacts 84 the UE configuration and does not require any changes to the 3GPP 85 network. 87 2. The Challenge of Providing IPv6 Addresses to a 3GPP Tethered LAN 89 As described in [RFC6459], 3GPP networks assign a /64 subnet to each 90 UE with RA. IPv6 prefix delegation is an optional part of 3GPP 91 Release-10 and is not covered by any earlier releases. Neighbor 92 Discovery Proxy (ND Proxy) [RFC4389] functionality has been suggested 93 as an option for sharing the assigned /64 from the 3GPP interface to 94 the LAN, but ND Proxy is an experimental protocol and has some 95 limitations with loop-avoidance. 97 DHCPv6 is the best way to delegate a prefix to a tethered LAN. The 98 method described in this document should only be applied when 99 deploying DHCPv6 is not achievable in the 3GPP network and the UE. 101 3. Method for Sharing the 3GPP Interface /64 to the Tethered LAN 103 As [RFC6459] describes, the 3GPP network assigned /64 is completely 104 dedicated to the UE and the gateway does not consume any of the /64 105 addresses. The gateway routes the entire /64 to the UE and does not 106 perform ND or Network Unreachability Detection (NUD) [RFC4861]. 107 Communication between the UE and the gateway is only done using link- 108 local addresses and the link is point-to-point. This allows for the 109 UE to use the 3GPP network assigned /64 to assign itself a /128 111 V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 113 address to the 3GPP radio interface for consistent network connection 114 formation and the same address with a /64 to the tethered LAN 115 interface. The tethered LAN interface may then advertise the /64 to 116 the LAN with RA. The LAN interface RA configuration must be tightly 117 coupled with the 3GPP interface state. If the 3GPP interface goes 118 down or changes address, that state should be reflected in the LAN 119 IPv6 configuration. Just as in a standard IPv6 router, the packet 120 TTL will be decremented when passing packets between interfaces. 122 The procedure may also be described in terms of the following usage 123 example: 125 1. The user activates tethering on the wireless LAN of the UE. 127 2. The UE checks to make sure the 3GPP interfaces is active and has 128 an IPv6 address. If the interface does not have an IPv6 address, 129 an attempt will be made to acquire one, or else the procedure 130 will terminate. 132 3. In this example, the UE finds the 3GPP interface has the IPv6 133 address 2001:db8:ac10:f002:1234:4567:0:9/128 assigned and active. 135 4. The UE copies the address 2001:db8:ac10:f002:1234:4567:0:9 with a 136 64 bit mask from the 3GPP interfaces to the wireless LAN 137 interfaces and begins announcing the prefix 138 2001:db8:ac10:f002::/64 via RA to the wireless LAN. 140 5. The gateway in the 3GPP network routes all packets for 141 2001:db8:ac10:f002::/64 to the UE using the link-local address as 142 the next hop. The gateway does not perform Neighbor Discover or 143 Network Unreachability Detection on 3GPP wireless link segment 144 towards the UE. 146 6. The UE directly processes all packets destine to itself at 147 2001:db8:ac10:f002:1234:4567:0:9. 149 7. The UE, acting as a router running NDP on the LAN, will route 150 packet to and from the LAN. IPv6 packets passing between 151 interfaces will have the TTL decremented. 153 8. If the 3GPP interface state changes, the LAN will immediately 154 update to reflect the change and ensure that the LAN IPv6 prefix 155 remains a valid extension of the 3GPP network. 157 9. Since the address 2001:db8:ac10:f002:1234:4567:0:9/128 is the 158 only instance of the assigned /64 on the 3GPP interface, there is 159 no chance of an address conflict on that interface. On the LAN 160 interface, there is no chance of address conflict since the 162 V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 164 address is defended using Duplicate Address Detection (DAD). 166 The UE should be compliant with the relevant requirements in [I- 167 D.draft-binet-v6ops-cellular-host-requirement]. 169 4. Security Considerations 171 Security considerations identified in [I-D.draft-binet-v6ops- 172 cellular-host-requirement] are to be taken into account. 174 5. IANA Considerations 176 This document does not require any action from IANA. 178 6. Acknowledgments 180 Many thanks for review and discussion from Masanobu Kawashima, Teemu 181 Savolainen, Mikael Abrahamsson, Eric Vyncke, Alexandru Petrescu, 182 Jouni Korhonen, Julien Laganier, and Ales Vizdal. 184 7. Informative References 186 [I-D.draft-binet-v6ops-cellular-host-requirement] Binet, D., 187 Boucadair, M., A. Vizdal, C. Byrne, G. Chen, "Internet 188 Protocol Version 6 (IPv6) for Cellular Hosts", draft- 189 draft-binet-v6ops-cellular-host-requirement (work in 190 progress), October 2012. 192 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 193 Host Configuration Protocol (DHCP) version 6", RFC 3633, 194 December 2003. 196 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 197 Proxies (ND Proxy)", RFC 4389, April 2006. 199 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 200 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 201 September 2007. 203 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 204 Address Autoconfiguration", RFC 4862, September 2007. 206 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 207 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 208 Partnership Project (3GPP) Evolved Packet System (EPS)", 209 RFC 6459, January 2012. 211 Authors' Addresses 213 V6OPS Working Group draft-ietf-v6ops-64share-00 December 14, 2012 215 Cameron Byrne 216 T-Mobile USA 217 Bellevue, Washington, USA 219 EMail: Cameron.Byrne@T-Mobile.com 221 Dan Drown 222 Email: Dan@Drown.org