idnits 2.17.1 draft-byrne-v6ops-64share-03.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...' -- The document date (October 9, 2012) is 4215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.binet-v6ops-cellular-host-reqs-rfc3316update' is defined on line 150, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: April 12, 2013 October 9, 2012 7 Sharing /64 3GPP Mobile Interface Subnet to a LAN 8 draft-byrne-v6ops-64share-03 10 Abstract 12 This document describes a known and implemented method of sharing a 13 /64 IPv6 subnet 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 April 12, 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-byrne-v6ops-64share-03 October 9, 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 . . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 59 7. Informative References . . . . . . . . . . . . . . . . . . . . 4 61 V6OPS Working Group draft-byrne-v6ops-64share-03 October 9, 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, this document describes how the 3GPP User Equipment (UE) 71 interface assigned /64 subnet may be shared from the 3GPP interface 72 to a tethered LAN. This is achieved by specifying the UE 3GPP 73 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 the 90 UE with RA. IPv6 prefix delegation is a part of 3GPP Release-10 and 91 is not covered by any earlier releases. Neighbor Discovery Proxy (ND 92 Proxy) [RFC4389] functionality has been suggested as an option for 93 sharing the assigned /64 from the 3GPP interface to the LAN, but ND 94 Proxy is an experimental protocol and has some limitations with loop- 95 avoidance. 97 DHCPv6 is the best way to assign subnets to tethered LANs. The 98 method described in this document should only be applied when 99 deploying DHCPv6 is not achievable in the 3GPP network. 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. Communication between the UE and the gateway is only done 106 using link-local addresses and the link is point-to-point. This 107 allows for the UE to use the 3GPP network assigned /64 to assign 108 itself a /128 subnet address to the 3GPP radio interface for 109 consistent network reachability and the same address with a /64 111 V6OPS Working Group draft-byrne-v6ops-64share-03 October 9, 2012 113 subnet to the tethered LAN interface. The tethered LAN interface may 114 then advertise the /64 subnet to the LAN with RA. 116 For example, if the 3GPP network assigns to the UE via RA the subnet 117 2001:db8:ac10:f002::/64, the UE may choose the address for its 3GPP 118 interface to be 2001:db8:ac10:f002:1234:4567::9/128. When tethering 119 a LAN, the UE may then assign that same address to its LAN interface 120 with a /64 subnet, such as 2001:db8:ac10:f002:1234:4567::9/64. The 121 UE may then advertise the 2001:db8:ac10:f002::/64 subnet to the 122 tethered LAN using RA. Since the UE only consumes one address from 123 the 3GPP network assigned /64 for both the 3GPP interface and the LAN 124 interface, there is no address conflict potential. On the LAN, the 125 /64 subnet is announced via RA and the interface address is defended 126 with Duplicate Address Detection (DAD) [RFC4862]. Since the 3GPP 127 interface is a point-to-point link and the gateway does not consume 128 an address from the network assigned /64, there is no chance of 129 address conflict on the 3GPP interface for the /64. 131 The UE should be compliant with the relevant requirements in [I- 132 D.binet-v6ops-cellular-host-reqs-rfc3316update]. 134 4. Security Considerations 136 Security considerations identified in [I-D.binet-v6ops-cellular-host- 137 reqs-rfc3316update] are to be taken into account. 139 5. IANA Considerations 141 This document does not require any action from IANA. 143 6. Acknowledgments 145 Many thanks for review and discussion from Masanobu Kawashima, Teemu 146 Savolainen, Mikael Abrahamsson, Eric Vyncke, and Ales Vizdal. 148 7. Informative References 150 [I-D.binet-v6ops-cellular-host-reqs-rfc3316update] Binet, D., 151 Boucadair, M., A. Vizdal, C. Byrne, "Internet Protocol 152 Version 6 (IPv6) for Cellular Hosts", draft-binet-v6ops- 153 cellular-host-reqs-rfc3316update-03 (work in progress), 154 October 2012. 156 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 157 Host Configuration Protocol (DHCP) version 6", RFC 3633, 158 December 2003. 160 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 162 V6OPS Working Group draft-byrne-v6ops-64share-03 October 9, 2012 164 Proxies (ND Proxy)", RFC 4389, April 2006. 166 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 167 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 168 September 2007. 170 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 171 Address Autoconfiguration", RFC 4862, September 2007. 173 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 174 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 175 Partnership Project (3GPP) Evolved Packet System (EPS)", 176 RFC 6459, January 2012. 178 Authors' Addresses 180 Cameron Byrne 181 T-Mobile USA 182 Bellevue, Washington, USA 184 EMail: Cameron.Byrne@T-Mobile.com 186 Dan Drown 187 Email: Dan@Drown.org