idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-06.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 -- The document date (June 30, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops J. Brzozowski 3 Internet-Draft Comcast Cable 4 Intended status: Informational G. Van De Velde 5 Expires: January 1, 2018 Nokia 6 June 30, 2017 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-06 11 Abstract 13 In some IPv6 environments, the need has arisen for hosts to be able 14 to utilize a unique IPv6 prefix, even though the link or media may be 15 shared. Typically hosts (subscribers) on a shared network, either 16 wired or wireless, such as Ethernet, WiFi, etc., will acquire unique 17 IPv6 addresses from a common IPv6 prefix that is allocated or 18 assigned for use on a specific link. 20 In most deployments today, IPv6 address assignment from a single IPv6 21 prefix on a shared network is done by either using IPv6 stateless 22 address auto-configuration (SLAAC) and/or stateful DHCPv6. While 23 this is still viable and operates as designed, there are some large 24 scale environments where this concept introduces significant 25 performance challenges and implications, specifically related to IPv6 26 router and neighbor discovery. 28 This document outlines an approach utilising existing IPv6 protocols 29 to allow hosts to be assigned a unique IPv6 prefix (instead of a 30 unique IPv6 address from a shared IPv6 prefix). Benefits of unique 31 IPv6 prefix over a unique IPv6 address from the service provider 32 include improved subscriber isolation and enhanced subscriber 33 management. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 1, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 71 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 72 4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 73 5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 77 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 The concepts in this document are originally developed as part of a 83 large scale, production deployment of IPv6 support for a provider 84 managed shared network service. In this document IPv6 support does 85 not preclude support for IPv4; however, the primary objectives for 86 this work was to make it so that user equipment (UE) were capable of 87 an IPv6 only experience from a network operators perspective. In the 88 context of this document, UE can be 'regular' end-user-equipment, as 89 well as a server in a datacenter, assuming a shared network (wired or 90 wireless). 92 Details of IPv4 support are out of scope for this document. This 93 document will also, in general, outline the requirements that must be 94 satisfied by UE to allow for an IPv6 only experience. 96 In most current deployments, User Equipment (UE) IPv6 address 97 assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] 98 and/or DHCP IA_NA RFC3315 [RFC3315]. During the time when this 99 approach was developed and subsequently deployed, it has been 100 observed that some operating systems do not support the use of DHCPv6 101 for the acquisition of IA_NA per RFC7934 [RFC7934]. As such the use 102 of IPv6 SLAAC based subscriber and address management for provider 103 managed shared network services is the recommended technology of 104 choice, as it does not exclude any known IPv6 implementation. In 105 addition an IA_NA-only network is not recommended per RFC 7934 106 RFC7934 [RFC7934] section 8. This document will detail the mechanics 107 involved for IPv6 SLAAC based address and subscriber management 108 coupled with stateless DHCPv6, where beneficial. 110 This document will focus upon the process for UEs to obtain a unique 111 IPv6 prefix. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Motivation and Scope of Applicability 121 The motivation for this work falls into the following categories: 123 o Deployment advice for IPv6 that will allow stable and secure IPv6 124 only experience, even if IPv4 support is present 126 o Ensure support for IPv6 is efficient and does not impact the 127 performance of the underlying network and in turn the customer 128 experience 130 o Allow for the greatest flexibility across host implementation to 131 allow for the widest range of addressing and configuration 132 mechanisms to be employed. The goal here is to ensure that the 133 widest population of UE implementations can leverage the 134 availability of IPv6 136 o Lay the technological foundation for future work related to the 137 use of IPv6 over shared media requiring optimized subscriber 138 management 140 o Two devices (subscriber/hosts), both attached to the same provider 141 managed shared network should only be able to communicate through 142 the provider managed First Hop Router 144 o Provide guidelines regarding best common practices around IPv6 145 neighborship discovery RFC4861 [RFC4861] and IPv6 address managent 146 settings between the First Hop router and directly connected 147 hosts/subscribers. 149 3. Design Principles 151 The First Hop router discussed in this document is the L3-Edge router 152 responsible for the communication with the devices (hosts and 153 subscribers) directly connected to a provider managed shared network, 154 and to transport traffic between the directly connected devices and 155 between directly connected devices and remote devices. 157 The work detailed in this document is focused on providing details 158 regarding best common practices of the IPv6 neighbor discovery and 159 related IPv6 address management settings between the First Hop router 160 and directly connected hosts/subscribers. The documented Best 161 Current Practice helps a service provider to better manage the shared 162 provider managed network on behalf of the connected devices. 164 The Best Current Practice documented in this note is to provide a 165 unique IPv6 prefix to hosts/subscribers devices connected to the 166 provider managed shared network. Each unique IPv6 prefix can 167 function as control-plane anchor point to make sure that each 168 subscriber is receiving expected subscriber policy and service levels 169 (throughput, QoS, security, parental-control, subscriber mobility 170 management, etc.). 172 4. IPv6 Unique Prefix Assignment 174 When a UE connects to the shared provider managed network and is 175 attached, it will initiate IP configuration phase. During this phase 176 the UE will, from an IPv6 perspective, attempt to learn the default 177 IPv6 gateway, the IPv6 prefix information, the DNS information 178 RFC8106 [RFC8106], and the remaining information required to 179 establish globally routable IPv6 connectivity. For that purpose, the 180 the UE/subscriber sends a RS (Router Solicitation) message. 182 The First Hop Router receives this UE/subscriber RS message and 183 starts the process to compose the response to the UE/subscriber 184 originated RS message. The First Hop Provider Router will answer 185 using a unicast RA (Router Advertisement) to the UE/subscriber. This 186 RA contains two important parameters for the EU/subscriber to 187 consume: a Unique IPv6 prefix (currently a /64 prefix) and some 188 flags. The Unique IPv6 prefix can be derived from a locally managed 189 pool or aggregate IPv6 block assigned to the First Hop Provider 190 Router or from a centrally allocated pool. The flags indicate to the 191 UE/subscriber to use SLAAC and/or DHCPv6 for address assignment; it 192 may indicate if the autoconfigured address is on/off-link and if 193 'Other' information (e.g. DNS server address) needs to be requested. 195 The IPv6 RA flags used for best common practice in IPv6 SLAAC based 196 Provider managed shared networks are: 198 o M-flag = 0 (UE/subscriber address is not managed through DHCPv6), 199 this flag may be set to 1 in the future if/when DHCPv6 prefix 200 delegation support is desired) 202 o O-flag = 1 (DHCPv6 is used to request configuration information 203 i.e. DNS, NTP information, not for IPv6 addressing) 205 o A-flag = 1 (The UE/subscriber can configure itself using SLAAC) 207 o L-flag = 0 (the prefix is not an on-link prefix, which means that 208 the UE/subscriber will NEVER assume destination addresses that 209 match the prefix are on-link and will ALWAYS send packets to those 210 addresses to the appropriate gateway according to route selection 211 rules.) 213 The use of a unique IPv6 prefix per UE adds an additional level of 214 protection and efficiency as it relates to how IPv6 Neighbor 215 Discovery and Router Discovery processing. Since the UE has a unique 216 IPv6 prefix all traffic by default will be directed to the First Hop 217 provider router. Further, the flag combinations documented above 218 maximise the IPv6 configurations that are available by hosts 219 including the use of privacy IPv6 addressing. 221 The architected result of designing the RA as documented above is 222 that each UE/subscriber gets its own unique IPv6 prefix for which it 223 can use SLAAC or any other method to select its /128 unique address. 224 In addition it will use stateless DHCPv6 to get the IPv6 address of 225 the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive 226 a service provider managed IPv6 address. If the UE/subscriber 227 desires to send anything external including other UE/subscriber 228 devices (assuming device to device communications is enabled and 229 supported), then, due to the L-bit set, it SHOULD send this traffic 230 to the First Hop Provider Router. 232 After the UE/subscriber received the RA, and the associated flags, it 233 will assign itself a 128 bit IPv6 address using SLAAC. Since the 234 address is composed by the UE/subscriber device itself, it will need 235 to verify that the address is unique on the shared network. The UE/ 236 subscriber will for that purpose, perform Duplicate Address Detection 237 algorithm. This will occur for each address the UE attempts to 238 utilize on the shared provider managed network. 240 5. IPv6 Neighbor Discovery Best Practices 242 An operational consideration when using IPv6 address assignment using 243 IPv6 SLAAC is that after the onboarding procedure, the UE/subscriber 244 will have a prefix with certain preferred and valid lifetimes. The 245 First Hop Provider Router extends these lifetimes by sending an 246 unsolicited RA, the applicable MaxRtrAdvInterval on the first hop 247 router MUST therefore be lower than the preferred lifetime. One 248 consequence of this process is that the First Hop Router never knows 249 when a UE/subscriber stops using addresses from a prefix and 250 additional procedures are required to help the First Hop Router to 251 gain this information. When using stateful DHCPv6 IA_NA for IPv6 UE/ 252 subscriber address assignment, this uncertainty on the First Hop 253 Router is not of impact due to the stateful nature of DHCPv6 IA_NA 254 address assignment. 256 Following is a reference table of the key IPv6 router discovery and 257 neighbor discovery timers for provider managed shared networks: 259 o IPv6 Router Advertisement Interval = 300s 261 o IPv6 Router LifeTime = 3600s 263 o Reachable time = 30s 265 o IPv6 Valid Lifetime = 3600s 267 o IPv6 Preferred Lifetime = 1800s 269 o Retransmit timer = 0s 271 The stateless nature of the UE/subscriber IPv6 SLAAC connectivity 272 model provides a consideration to make regarding resource consumption 273 (i.e. memory, neighbor state) on the First Hop Router. To reduce 274 undesired resource consumption on the First Hop Router the desire is 275 to remove UE/subscriber context in the case of non-permanent UE, such 276 as in the case of WiFi hotspots as quickly as possible. A possible 277 solution is to use a subscriber inactivity timer which, after 278 tracking a pre-defined (currently unspecified) number of minutes, 279 deletes the subscriber context on the First Hop Router. 281 When employing stateless IPv6 address assignment, a number of widely 282 deployed operating systems will attempt to utilise RFC 4941 RFC4941 283 [RFC4941] temporary 'private' addresses. 285 Similarly, when using this technology in a datacenter, the UE server 286 may need to use several addresses from the same Unique IPv6 Prefix, 287 for example because is using multiple virtual hosts, containers, etc. 289 in the bridged virtual switch. This can lead to the consequence that 290 a UE has multiple /128 addresses from the same IPv6 prefix. The 291 First Hop Provider Router MUST be able to handle the presence and use 292 of multiple globally routable IPv6 addresses. 294 For accounting purposes, the First Hop Provider Router must be able 295 to send usage statistics per UE/subscriber using Radius attributes. 297 6. IANA Considerations 299 No IANA considerations are defined at this time. 301 7. Security Considerations 303 The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is 304 compatible with assignment of an Unique IPv6 Prefix per Host. The 305 combination of both IPv6 privacy extensions and operator based 306 assignment of a Unique IPv6 Prefix per Host provides each 307 implementing operator a tool to manage and provide subscriber 308 services and hence reduces the experienced privacy within each 309 operator controlled domain. However, beyond the operator controlled 310 domain, IPv6 privacy extensions provide the desired privacy as 311 documented in RFC4941 [RFC4941]. 313 No other additional security considerations are made in this 314 document. 316 8. Acknowledgements 318 The authors would like to thank the following, in alphabetical order, 319 for their contributions: 321 Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian Desmedt, Brad 322 Hilgenfeld, Wim Henderickx, Erik Kline, Warren Kumari, Thomas Lynn, 323 Jordi Palet, Phil Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric 324 Vyncke, Sanjay Wadhwa 326 9. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 334 C., and M. Carney, "Dynamic Host Configuration Protocol 335 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 336 2003, . 338 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 339 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 340 DOI 10.17487/RFC4861, September 2007, 341 . 343 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 344 Address Autoconfiguration", RFC 4862, 345 DOI 10.17487/RFC4862, September 2007, 346 . 348 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 349 Extensions for Stateless Address Autoconfiguration in 350 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 351 . 353 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 354 "Host Address Availability Recommendations", BCP 204, 355 RFC 7934, DOI 10.17487/RFC7934, July 2016, 356 . 358 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 359 "IPv6 Router Advertisement Options for DNS Configuration", 360 RFC 8106, DOI 10.17487/RFC8106, March 2017, 361 . 363 Authors' Addresses 365 John Jason Brzozowski 366 Comcast Cable 367 1701 John F. Kennedy Blvd. 368 Philadelphia, PA 369 USA 371 Email: john_brzozowski@cable.comcast.com 373 Gunter Van De Velde 374 Nokia 375 Antwerp 376 Belgium 378 Email: gunter.van_de_velde@nokia.com