idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.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 (September 18, 2017) is 2409 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 3 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: Best Current Practice G. Van De Velde 5 Expires: March 22, 2018 Nokia 6 September 18, 2017 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 11 Abstract 13 This document outlines an approach utilising existing IPv6 protocols 14 to allow hosts to be assigned a unique IPv6 prefix (instead of a 15 unique IPv6 address from a shared IPv6 prefix). Benefits of unique 16 IPv6 prefix over a unique service provider IPv6 address include 17 improved host isolation and enhanced subscriber management on shared 18 network segments. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 22, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Motivation and Scope of Applicability . . . . . . . . . . . . 3 57 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 58 4. IPv6 Unique Prefix Assignment . . . . . . . . . . . . . . . . 4 59 5. IPv6 Neighbor Discovery Best Practices . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 The concepts in this document are originally developed as part of a 69 large scale, production deployment of IPv6 support for a provider 70 managed shared access network service. 72 A shared network service, is a service offering where a particular L2 73 access network (e.g. wifi) is shared and used by multiple visiting 74 devices (i.e. subscribers). Many service providers offering shared 75 access network services, have legal requirements, or find it good 76 practice, to provide isolation between the connected visitor devices 77 to control potential abuse of the shared access network. 79 A network implementing a unique IPv6 prefix per host, can simply 80 ensure that devices cannot send packets to each other except through 81 the first-hop router. This will automatically provide robust 82 protection against attacks between devices that rely on link-local 83 ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, 84 malicious redirects, and rogue RAs. This form of protection is much 85 more scalable and robust than alternative mechanisms such as DAD 86 proxying, forced forwarding, or ND snooping. 88 In this document IPv6 support does not preclude support for IPv4; 89 however, the primary objectives for this work was to make it so that 90 user equipment (UE) were capable of an IPv6 only experience from a 91 network operators perspective. In the context of this document, UE 92 can be 'regular' end-user-equipment, as well as a server in a 93 datacenter, assuming a shared network (wired or wireless). 95 Details of IPv4 support are out of scope for this document. This 96 document will also, in general, outline the requirements that must be 97 satisfied by UE to allow for an IPv6 only experience. 99 In most current deployments, User Equipment (UE) IPv6 address 100 assignment is commonly done using either IPv6 SLAAC RFC4862 [RFC4862] 101 and/or DHCP IA_NA (Identity Association - Non-temporary Address) 102 RFC3315 [RFC3315]. During the time when this approach was developed 103 and subsequently deployed, it has been observed that some operating 104 systems do not support the use of DHCPv6 for the acquisition of IA_NA 105 per RFC7934 [RFC7934]. To not exclude any known IPv6 106 implementations, IPv6 SLAAC based subscriber and address management 107 is the recommended technology to reach highest percentage of 108 connected IPv6 devices on a provider managed shared network service. 109 In addition an IA_NA-only network is not recommended per RFC 7934 110 RFC7934 [RFC7934] section 8. This document will detail the mechanics 111 involved for IPv6 SLAAC based address and subscriber management 112 coupled with stateless DHCPv6, where beneficial. 114 This document focuses upon the process for UEs to obtain a unique 115 IPv6 prefix. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2. Motivation and Scope of Applicability 125 The motivation for this work falls into the following categories: 127 o Deployment advice for IPv6 that will allow stable and secure IPv6 128 only experience, even if IPv4 support is present 130 o Ensure support for IPv6 is efficient and does not impact the 131 performance of the underlying network and in turn the customer 132 experience 134 o Allow for the greatest flexibility across host implementation to 135 allow for the widest range of addressing and configuration 136 mechanisms to be employed. The goal here is to ensure that the 137 widest population of UE implementations can leverage the 138 availability of IPv6 140 o Lay the technological foundation for future work related to the 141 use of IPv6 over shared media requiring optimized subscriber 142 management 144 o Two devices (subscriber/hosts), both attached to the same provider 145 managed shared network should only be able to communicate through 146 the provider managed First Hop Router 148 o Provide guidelines regarding best common practices around IPv6 149 neighborship discovery RFC4861 [RFC4861] and IPv6 address managent 150 settings between the First Hop router and directly connected 151 hosts/subscribers. 153 3. Design Principles 155 The First Hop router discussed in this document is the L3-Edge router 156 responsible for the communication with the devices (hosts and 157 subscribers) directly connected to a provider managed shared network, 158 and to transport traffic between the directly connected devices and 159 between directly connected devices and remote devices. 161 The work detailed in this document is focused on providing details 162 regarding best common practices of the IPv6 neighbor discovery and 163 related IPv6 address management settings between the First Hop router 164 and directly connected hosts/subscribers. The documented Best 165 Current Practice helps a service provider to better manage the shared 166 provider managed network on behalf of the connected devices. 168 This document recommends providing a unique IPv6 prefix to devices 169 connected to the managed shared network. Each unique IPv6 prefix can 170 function as control-plane anchor point to make sure that each device 171 receives expected subscriber policy and service levels (throughput, 172 QoS, security, parental-control, subscriber mobility management, 173 etc.). 175 4. IPv6 Unique Prefix Assignment 177 When a UE connects to the shared provider managed network and is 178 attached, it will initiate IP configuration phase. During this phase 179 the UE will, from an IPv6 perspective, attempt to learn the default 180 IPv6 gateway, the IPv6 prefix information, the DNS information 181 RFC8106 [RFC8106], and the remaining information required to 182 establish globally routable IPv6 connectivity. For that purpose, the 183 the subscriber sends a RS (Router Solicitation) message. 185 The First Hop Router receives this subscriber RS message and starts 186 the process to compose the response to the subscriber originated RS 187 message. The First Hop Provider Router will answer using a solicited 188 RA (Router Advertisement) to the subscriber. 190 When the First Hop Provider Router sends a solicited RA response, or 191 periodically sends unsolicited RAs, the RA MUST be sent only to the 192 subscriber that has been assigned the Unique IPv6 prefix contained in 193 the RA. This is achieved by sending a solicited RA response or 194 unsolicited RAs to the all-nodes group, as detailed in RFC4861 195 [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link- 196 layer multicast address associated with the all-nodes group, the 197 link-layer unicast address of the subscriber that has been assigned 198 the Unique IPv6 prefix contained in the RA MUST be used as the link- 199 layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a 200 solicited RA response could be sent unicast to the link-local address 201 of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6, 202 nevertheless unsolicited RAs are always sent to the all-nodes group. 204 This solicited RA contains two important parameters for the 205 subscriber to consume: a Unique IPv6 prefix (currently a /64 prefix) 206 and some flags. The Unique IPv6 prefix can be derived from a locally 207 managed pool or aggregate IPv6 block assigned to the First Hop 208 Provider Router or from a centrally allocated pool. The flags 209 indicate to the subscriber to use SLAAC and/or DHCPv6 for address 210 assignment; it may indicate if the autoconfigured address is on/off- 211 link and if 'Other' information (e.g. DNS server address) needs to 212 be requested. 214 The IPv6 RA flags used for best common practice in IPv6 SLAAC based 215 Provider managed shared networks are: 217 o M-flag = 0 (subscriber address is not managed through DHCPv6), 218 this flag may be set to 1 in the future if/when DHCPv6 prefix 219 delegation support is desired) 221 o O-flag = 1 (DHCPv6 is used to request configuration information 222 i.e. DNS, NTP information, not for IPv6 addressing) 224 o A-flag = 1 (The subscriber can configure itself using SLAAC) 226 o L-flag = 0 (the prefix is not an on-link prefix, which means that 227 the subscriber will never assume destination addresses that match 228 the prefix are on-link and will always send packets to those 229 addresses to the appropriate gateway according to route selection 230 rules.) 232 The use of a unique IPv6 prefix per subscriber adds an additional 233 level of protection and efficiency as it relates to how IPv6 Neighbor 234 Discovery and Router Discovery processing. Since the UE has a unique 235 IPv6 prefix all traffic by default will be directed to the First Hop 236 router. Further, the flag combinations documented above maximise the 237 IPv6 configurations that are available by hosts including the use of 238 privacy IPv6 addressing. 240 The architected result of designing the RA as documented above is 241 that each subscriber gets its own unique IPv6 prefix. Each host can 242 consequently use SLAAC or any other method of choice to select its 243 /128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or 244 IPv6 Router Advertisement Options for DNS Configuration RFC8106 245 [RFC8106] can be used to get the IPv6 address of the DNS server. If 246 the subscriber desires to send anything external including other 247 subscriber devices (assuming device to device communications is 248 enabled and supported), then, due to the L-bit being unset, it SHOULD 249 send this traffic to the First Hop Router. 251 After the subscriber received the RA, and the associated flags, it 252 will assign itself a 128 bit IPv6 address using SLAAC. Since the 253 address is composed by the subscriber device itself, it will need to 254 verify that the address is unique on the shared network. The 255 subscriber will for that purpose, perform Duplicate Address Detection 256 algorithm. This will occur for each address the UE attempts to 257 utilize on the shared provider managed network. 259 5. IPv6 Neighbor Discovery Best Practices 261 An operational consideration when using IPv6 address assignment using 262 IPv6 SLAAC is that after the onboarding procedure, the subscriber 263 will have a prefix with certain preferred and valid lifetimes. The 264 First Hop Provider Router extends these lifetimes by sending an 265 unsolicited RA, the applicable MaxRtrAdvInterval on the first hop 266 router MUST therefore be lower than the preferred lifetime. One 267 consequence of this process is that the First Hop Router never knows 268 when a subscriber stops using addresses from a prefix and additional 269 procedures are required to help the First Hop Router to gain this 270 information. When using stateful DHCPv6 IA_NA for IPv6 subscriber 271 address assignment, this uncertainty on the First Hop Router is not 272 of impact due to the stateful nature of DHCPv6 IA_NA address 273 assignment. 275 Following is a reference table of the key IPv6 router discovery and 276 neighbor discovery timers for provider managed shared networks: 278 o Maximum IPv6 Router Advertisement Interval = 300s (or 600s when 279 battery consumption is a concern according RFC7772 [RFC7772]). 281 o IPv6 Router LifeTime = 3600s 283 o Reachable time = 30s 285 o IPv6 Valid Lifetime = 3600s 287 o IPv6 Preferred Lifetime = 1800s 288 o Retransmit timer = 0s 290 The stateless nature of the subscriber IPv6 SLAAC connectivity model 291 introduces non-optimal resource consumption (i.e. memory, neighbor 292 state) on the First Hop Router. To reduce undesired resource 293 consumption, such as in the case of WiFi hotspots, is to remove 294 subscriber context as quickly as possible when a device or subscriber 295 becomes non-active. A possible solution is to use a subscriber or 296 device inactivity timer, that after tracking a pre-defined (currently 297 unspecified) number of minutes, deletes the subscriber context on the 298 First Hop Router. 300 When employing stateless IPv6 address assignment, a number of widely 301 deployed operating systems will attempt to utilise RFC 4941 RFC4941 302 [RFC4941] temporary 'private' addresses. 304 Similarly, when using this technology in a datacenter, the UE server 305 may need to use several addresses from the same Unique IPv6 Prefix, 306 for example because is using multiple virtual hosts, containers, etc. 307 in the bridged virtual switch. This can lead to the consequence that 308 a UE has multiple /128 addresses from the same IPv6 prefix. The 309 First Hop Provider Router MUST be able to handle the presence and use 310 of multiple globally routable IPv6 addresses. 312 For accounting purposes, the First Hop Provider Router must be able 313 to send usage statistics per subscriber using Radius attributes. 315 6. IANA Considerations 317 No IANA considerations are defined at this time. 319 7. Security Considerations 321 The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is 322 compatible with assignment of a unique IPv6 Prefix per Host. 323 However, when combining both IPv6 privacy extensions and a unique 324 IPv6 Prefix per Host a reduced privacy experience for the subscriber 325 is introduced, because a prefix may be associated with a subscriber, 326 even when the subscriber implemented IPv6 privacy extensions RFC4941 327 [RFC4941]. 329 No other additional security considerations are made in this 330 document. 332 8. Acknowledgements 334 The authors would like to thank the following, in alphabetical order, 335 for their contributions: 337 Ben Campbell, Brian Carpenter, Tim Chown, Lorenzo Colitti, Killian 338 Desmedt, David Farmer, Brad Hilgenfeld, Wim Henderickx, Erik Kline, 339 Suresh Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil 340 Sanderson, Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay 341 Wadhwa 343 9. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 351 C., and M. Carney, "Dynamic Host Configuration Protocol 352 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 353 2003, . 355 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 356 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 357 April 2004, . 359 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 360 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 361 DOI 10.17487/RFC4861, September 2007, 362 . 364 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 365 Address Autoconfiguration", RFC 4862, 366 DOI 10.17487/RFC4862, September 2007, 367 . 369 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 370 Extensions for Stateless Address Autoconfiguration in 371 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 372 . 374 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 375 "Address Mapping of IPv6 Multicast Packets on Ethernet", 376 RFC 6085, DOI 10.17487/RFC6085, January 2011, 377 . 379 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 380 Consumption of Router Advertisements", BCP 202, RFC 7772, 381 DOI 10.17487/RFC7772, February 2016, 382 . 384 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 385 "Host Address Availability Recommendations", BCP 204, 386 RFC 7934, DOI 10.17487/RFC7934, July 2016, 387 . 389 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 390 "IPv6 Router Advertisement Options for DNS Configuration", 391 RFC 8106, DOI 10.17487/RFC8106, March 2017, 392 . 394 Authors' Addresses 396 John Jason Brzozowski 397 Comcast Cable 398 1701 John F. Kennedy Blvd. 399 Philadelphia, PA 400 USA 402 Email: john_brzozowski@cable.comcast.com 404 Gunter Van De Velde 405 Nokia 406 Antwerp 407 Belgium 409 Email: gunter.van_de_velde@nokia.com