idnits 2.17.1 draft-ietf-v6ops-unique-ipv6-prefix-per-host-13.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 (October 16, 2017) is 2377 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: April 19, 2018 Nokia 6 October 16, 2017 8 Unique IPv6 Prefix Per Host 9 draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 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 April 19, 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. Often service providers 147 have legal requirements, or find it good practice, to provide 148 isolation between the connected visitor devices to control 149 potential abuse of the shared access network. 151 o Provide guidelines regarding best common practices around IPv6 152 neighborship discovery RFC4861 [RFC4861] and IPv6 address 153 management settings between the First Hop router and directly 154 connected hosts/subscribers. 156 3. Design Principles 158 The First Hop router discussed in this document is the L3-Edge router 159 responsible for the communication with the devices (hosts and 160 subscribers) directly connected to a provider managed shared network, 161 and to transport traffic between the directly connected devices and 162 between directly connected devices and remote devices. 164 The work detailed in this document is focused on providing details 165 regarding best common practices of the IPv6 neighbor discovery and 166 related IPv6 address management settings between the First Hop router 167 and directly connected hosts/subscribers. The documented Best 168 Current Practice helps a service provider to better manage the shared 169 provider managed network on behalf of the connected devices. 171 This document recommends providing a unique IPv6 prefix to devices 172 connected to the managed shared network. Each unique IPv6 prefix can 173 function as control-plane anchor point to make sure that each device 174 receives expected subscriber policy and service levels (throughput, 175 QoS, security, parental-control, subscriber mobility management, 176 etc.). 178 4. IPv6 Unique Prefix Assignment 180 When a UE connects to the shared provider managed network and is 181 attached, it will initiate IP configuration phase. During this phase 182 the UE will, from an IPv6 perspective, attempt to learn the default 183 IPv6 gateway, the IPv6 prefix information, the DNS information 184 RFC8106 [RFC8106], and the remaining information required to 185 establish globally routable IPv6 connectivity. For that purpose, the 186 the subscriber sends a RS (Router Solicitation) message. 188 The First Hop Router receives this subscriber RS message and starts 189 the process to compose the response to the subscriber originated RS 190 message. The First Hop Router will answer using a solicited RA 191 (Router Advertisement) to the subscriber. 193 When the First Hop Router sends a solicited RA response, or 194 periodically sends unsolicited RAs, the RA MUST be sent only to the 195 subscriber that has been assigned the Unique IPv6 prefix contained in 196 the RA. This is achieved by sending a solicited RA response or 197 unsolicited RAs to the all-nodes group, as detailed in RFC4861 198 [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link- 199 layer multicast address associated with the all-nodes group, the 200 link-layer unicast address of the subscriber that has been assigned 201 the Unique IPv6 prefix contained in the RA MUST be used as the link- 202 layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a 203 solicited RA response could be sent unicast to the link-local address 204 of the subscriber as detailed in RFC4861 [RFC4861] section 6.2.6, 205 nevertheless unsolicited RAs are always sent to the all-nodes group. 207 This solicited RA contains two important parameters for the 208 subscriber to consume: a Unique IPv6 prefix (currently a /64 prefix) 209 and some flags. The Unique IPv6 prefix can be derived from a locally 210 managed pool or aggregate IPv6 block assigned to the First Hop Router 211 or from a centrally allocated pool. The flags indicate to the 212 subscriber to use SLAAC and/or DHCPv6 for address assignment; it may 213 indicate if the autoconfigured address is on/off-link and if 'Other' 214 information (e.g. DNS server address) needs to be requested. 216 The IPv6 RA flags used for best common practice in IPv6 SLAAC based 217 Provider managed shared networks are: 219 o M-flag = 0 (subscriber address is not managed through DHCPv6), 220 this flag may be set to 1 in the future if/when DHCPv6 prefix 221 delegation support is desired) 223 o O-flag = 1 (DHCPv6 is used to request configuration information 224 i.e. DNS, NTP information, not for IPv6 addressing) 226 o A-flag = 1 (The subscriber can configure itself using SLAAC) 228 o L-flag = 0 (the prefix is not an on-link prefix, which means that 229 the subscriber will never assume destination addresses that match 230 the prefix are on-link and will always send packets to those 231 addresses to the appropriate gateway according to route selection 232 rules.) 234 The use of a unique IPv6 prefix per subscriber adds an additional 235 level of protection and efficiency. The protection is driven because 236 all external communication of a connected device is directed to the 237 first hop router as required by RFC4861 [RFC4861]. Best efficiency 238 is achieved because the recommended RA flags allow broadest support 239 on connected devices to receive a valid IPv6 address (i.e. privacy 240 addresses RFC4941 [RFC4941] or SLAAC RFC4862 [RFC4862]). 242 The architected result of designing the RA as documented above is 243 that each subscriber gets its own unique IPv6 prefix. Each host can 244 consequently use SLAAC or any other method of choice to select its 245 /128 unique address. Either stateless DHCPv6 RFC3736 [RFC3736] or 246 IPv6 Router Advertisement Options for DNS Configuration RFC8106 247 [RFC8106] can be used to get the IPv6 address of the DNS server. If 248 the subscriber desires to send anything external including towards 249 other subscriber devices (assuming device to device communications is 250 enabled and supported), then, due to the L-bit being unset, then 251 RFC4861 [RFC4861] requires that this traffic is sent to the First Hop 252 Router. 254 After the subscriber received the RA, and the associated flags, it 255 will assign itself a 128 bit IPv6 address using SLAAC. Since the 256 address is composed by the subscriber device itself, it will need to 257 verify that the address is unique on the shared network. The 258 subscriber will for that purpose, perform Duplicate Address Detection 259 algorithm. This will occur for each address the UE attempts to 260 utilize on the shared provider managed network. 262 5. IPv6 Neighbor Discovery Best Practices 264 An operational consideration when using IPv6 address assignment using 265 IPv6 SLAAC is that after the onboarding procedure, the subscriber 266 will have a prefix with certain preferred and valid lifetimes. The 267 First Hop Router extends these lifetimes by sending an unsolicited 268 RA, the applicable MaxRtrAdvInterval on the first hop router MUST 269 therefore be lower than the preferred lifetime. One consequence of 270 this process is that the First Hop Router never knows when a 271 subscriber stops using addresses from a prefix and additional 272 procedures are required to help the First Hop Router to gain this 273 information. When using stateful DHCPv6 IA_NA for IPv6 subscriber 274 address assignment, this uncertainty on the First Hop Router is not 275 of impact due to the stateful nature of DHCPv6 IA_NA address 276 assignment. 278 Following is a reference table of the key IPv6 router discovery and 279 neighbor discovery timers for provider managed shared networks: 281 o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 282 300s (or when battery consumption is a concern 686s, see Note 283 below) 285 o IIPv6 Router LifeTime = 3600s (see Note below) 287 o Reachable time = 30s 289 o IPv6 Valid Lifetime = 3600s 290 o IPv6 Preferred Lifetime = 1800s 292 o Retransmit timer = 0s 294 Note: When servicing large numbers of battery powered devices, 295 RFC7772 [RFC7772] suggests a maximum of 7 RAs per hour and a 45-90 296 minute IPv6 Router Lifetime. To achieve a maximum of 7 RAs per hour, 297 the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is 298 the important parameter, and MUST be greater than or equal to 514 299 seconds (1/7 of an hour). Further as discussed in RFC4861 [RFC4861] 300 section 6.2.1, MinRtrAdvInterval <=0.75 * MaxRtrAdvInterval, 301 therefore MaxRtrAdvInterval MUST additionally be greater than or 302 equal to 686 seconds. As for the recommended IPv6 Router Lifetime, 303 since this technique requires that RAs are sent using the link-layer 304 unicast address of the subscriber, the concerns over multicast 305 delivery discussed in RFC7772 [RFC7772] are already mitigated, 306 therefore the above suggestion of 3600 seconds (an hour) seems 307 sufficient for this use case. 309 IPv6 SLAAC requires the router to maintain neighbor state, which 310 implies costs in terms of memory, power, message exchanges, and 311 message processing. Stale entries can prove an unnecessary burden, 312 especially on WiFi interfaces. It is RECOMMENDED that stale neighbor 313 state be removed quickly. 315 When employing stateless IPv6 address assignment, a number of widely 316 deployed operating systems will attempt to utilise RFC4941 [RFC4941] 317 temporary 'private' addresses. 319 Similarly, when using this technology in a datacenter, the UE server 320 may need to use several addresses from the same Unique IPv6 Prefix, 321 for example because is using multiple virtual hosts, containers, etc. 322 in the bridged virtual switch. This can lead to the consequence that 323 a UE has multiple /128 addresses from the same IPv6 prefix. The 324 First Hop Router MUST be able to handle the presence and use of 325 multiple globally routable IPv6 addresses. 327 6. IANA Considerations 329 No IANA considerations are defined at this time. 331 7. Security Considerations 333 The mechanics of IPv6 privacy extensions RFC4941 [RFC4941] is 334 compatible with assignment of a unique IPv6 Prefix per Host. 335 However, when combining both IPv6 privacy extensions and a unique 336 IPv6 Prefix per Host a reduced privacy experience for the subscriber 337 is introduced, because a prefix may be associated with a subscriber, 338 even when the subscriber implemented IPv6 privacy extensions RFC4941 339 [RFC4941]. If the operator assigns the same unique prefix to the 340 same link-layer address every time a host connects, any remote party 341 who is aware of this fact can easily track a host simply by tracking 342 its assigned prefix. This nullifies the benefit provided by privacy 343 addresses RFC4941 [RFC4941]. If a host wishes to maintain privacy on 344 such networks, it SHOULD ensure that its link-layer address is 345 periodically changed or randomized. 347 No other additional security considerations are made in this 348 document. 350 8. Acknowledgements 352 The authors would like to explicit thank David Farmer and Lorenzo 353 Colitti for their extended contributions and suggested text. 355 In addition the authors would like to thank the following, in 356 alphabetical order, for their contributions: 358 Fred Baker, Ben Campbell, Brian Carpenter, Tim Chown, Killian 359 Desmedt, Brad Hilgenfeld, Wim Henderickx, Erik Kline, Suresh 360 Krishnan, Warren Kumari, Thomas Lynn, Jordi Palet, Phil Sanderson, 361 Colleen Szymanik, Jinmei Tatuya, Eric Vyncke, Sanjay Wadhwa 363 9. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 371 C., and M. Carney, "Dynamic Host Configuration Protocol 372 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 373 2003, . 375 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 376 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 377 April 2004, . 379 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 380 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 381 DOI 10.17487/RFC4861, September 2007, 382 . 384 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 385 Address Autoconfiguration", RFC 4862, 386 DOI 10.17487/RFC4862, September 2007, 387 . 389 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 390 Extensions for Stateless Address Autoconfiguration in 391 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 392 . 394 [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, 395 "Address Mapping of IPv6 Multicast Packets on Ethernet", 396 RFC 6085, DOI 10.17487/RFC6085, January 2011, 397 . 399 [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy 400 Consumption of Router Advertisements", BCP 202, RFC 7772, 401 DOI 10.17487/RFC7772, February 2016, 402 . 404 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 405 "Host Address Availability Recommendations", BCP 204, 406 RFC 7934, DOI 10.17487/RFC7934, July 2016, 407 . 409 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 410 "IPv6 Router Advertisement Options for DNS Configuration", 411 RFC 8106, DOI 10.17487/RFC8106, March 2017, 412 . 414 Authors' Addresses 416 John Jason Brzozowski 417 Comcast Cable 418 1701 John F. Kennedy Blvd. 419 Philadelphia, PA 420 USA 422 Email: john_brzozowski@cable.comcast.com 424 Gunter Van De Velde 425 Nokia 426 Antwerp 427 Belgium 429 Email: gunter.van_de_velde@nokia.com