idnits 2.17.1 draft-mishra-6man-variable-slaac-01.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 76 has weird spacing: '... prefix usage...' -- The document date (October 30, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IANA-RF' is mentioned on line 1085, but not defined == Unused Reference: 'I-D.ietf-6man-ipv6-address-generation-privacy' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-opsec-ipv6-host-scanning' is defined on line 1484, but no explicit reference was found in the text == Unused Reference: 'I-D.shytyi-opsawg-vysm' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: 'RFC8273' is defined on line 1494, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-bourbaki-6man-classless-ipv6-05 -- Possible downref: Normative reference to a draft: ref. 'I-D.bourbaki-6man-classless-ipv6' == Outdated reference: A later version (-06) exists of draft-mishra-v6ops-variable-slaac-problem-stmt-00 ** Downref: Normative reference to an Informational draft: draft-mishra-v6ops-variable-slaac-problem-stmt (ref. 'I-D.mishra-v6ops-variable-slaac-problem-stmt') -- Possible downref: Normative reference to a draft: ref. 'I-D.templin-aerolink' ** Downref: Normative reference to an Informational RFC: RFC 2450 ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3587 ** Obsolete normative reference: RFC 3627 (Obsoleted by RFC 6547) ** Downref: Normative reference to an Informational RFC: RFC 3756 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental RFC: RFC 4389 ** Downref: Normative reference to an Informational RFC: RFC 4692 ** Downref: Normative reference to an Informational RFC: RFC 4887 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Downref: Normative reference to an Informational RFC: RFC 5214 ** Downref: Normative reference to an Informational RFC: RFC 5375 ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 6583 ** Downref: Normative reference to an Experimental RFC: RFC 6741 ** Downref: Normative reference to an Informational RFC: RFC 6877 ** Downref: Normative reference to an Informational RFC: RFC 7084 ** Downref: Normative reference to an Informational RFC: RFC 7094 ** Downref: Normative reference to an Informational RFC: RFC 7278 ** Downref: Normative reference to an Informational RFC: RFC 7368 ** Downref: Normative reference to an Informational RFC: RFC 7421 == Outdated reference: A later version (-10) exists of draft-shytyi-opsawg-vysm-08 Summary: 25 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN Working Group G. Mishra 3 Internet-Draft Verizon Inc. 4 Updates: RFC2464, RFC4291, RFC4861, A. Petrescu 5 RFC4862, RFC7136, RFC8273 (if CEA, LIST 6 approved) N. Kottapalli 7 Intended status: Standards Track Benu Networks 8 Expires: May 3, 2021 N. Kottapalli 9 Ciena 10 D. Shytyi 11 SFR 12 October 30, 2020 14 SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC) 15 draft-mishra-6man-variable-slaac-01 17 Abstract 19 This draft proposes the use of arbitrary length prefixes in PIO for 20 SLAAC. A prefix of length 65 in PIO, for example, would be permitted 21 to form an addresses whose interface identifier length is length 63, 22 which allows several benefits. 24 In the past, various IPv6 addressing models have been proposed based 25 on a subnet hierarchy embedding a 64-bit prefix. The last remnant of 26 IPv6 classful addressing is a inflexible interface identifier 27 boundary at /64. This document proposes flexibility to the fixed 28 position of that boundary for interface addressing. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. The History behind the 64 bit fixed boundary . . . . . . . . 4 67 4. Identifier and Subnet Length Statements . . . . . . . . . . . 7 68 5. Recommendations for implementation of variable SLAAC . . . . 8 69 6. Recommended use cases where 64 bit prefix should be utilized 8 70 7. Reasons for longer than 64 bit prefix length . . . . . . . . 12 71 7.1. Insufficient Address Space Delegated . . . . . . . . . . 12 72 7.2. Hierarchical Addressing . . . . . . . . . . . . . . . . . 13 73 7.3. Audit Requirement . . . . . . . . . . . . . . . . . . . . 13 74 7.4. Concerns over ND Cache Exhaustion . . . . . . . . . . . . 14 75 7.5. Longer prefixes lengths used for embedding information . 14 76 8. Greater than 64 bit prefix usage by ISPs is strictly 77 prohibited . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. Comparison of Static, SLAAC, DHCPv6 and Variable SLAAC . . . 15 79 10. Variable SLAAC Use Cases . . . . . . . . . . . . . . . . . . 18 80 10.1. Permission-less Extension of the Network . . . . . . . . 18 81 10.2. Private Networks . . . . . . . . . . . . . . . . . . . . 18 82 10.3. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . 19 83 10.4. Home and SOHO . . . . . . . . . . . . . . . . . . . . . 19 84 10.5. 3GPP V2I and V2V networking . . . . . . . . . . . . . . 19 85 10.6. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 10.7. Large ISP's backbone POP . . . . . . . . . . . . . . . . 20 87 11. Variable SLAAC implementation using RA Flag . . . . . . . . . 20 88 12. Applicability Statements . . . . . . . . . . . . . . . . . . 22 89 13. Router and Operational Considerations . . . . . . . . . . . . 22 90 14. Host Behavior Considerations . . . . . . . . . . . . . . . . 22 91 15. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 94 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 19.1. Normative References . . . . . . . . . . . . . . . . . . 24 97 19.2. Informative References . . . . . . . . . . . . . . . . . 32 98 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 101 1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 2. Introduction 111 From the beginning, the IPv6 addressing plan was based on a 128 bit 112 address format made up of 8 hextets which were broken down into a 64 113 bit four hextet prefix and 64 bit four hextet interface identifier. 114 For example, the address 2001:db8:3:4::1 has the first 4 hextets 115 forming the /64 prefix 2001:db8:3:4::/64, whereas the last four 116 hextets form an interface identifier abbreviated as ::1 (a 'hextet' 117 is a group of max 4 hex digits between two columns, e.g. "2001" and 118 "db8" are each a hextet). A comprehensive analysis of the 64-bit 119 boundary is provided in [RFC7421]. The history of IPv6 Classful 120 models proposed, and the last remnant of IPv6 Classful addressing 121 rigid network interface identifier boundary at /64 is discussed in 122 detail as well as the removal of the fixed position of the boundary 123 for interface addressing in draft [I-D.bourbaki-6man-classless-ipv6]. 125 This document discusses the reasons why the interface identifier has 126 been fixed at 64 bits, and the problems that can be addressed by 127 changing the GUA interface identifier from fixed 64 bit size to a 128 variable interface identifier. This change would be consistent with 129 static and DHCPv6 stateful IPv6 address assignment, as well as the 130 proposed solution would ensure maintaining backwards compatibility 131 for existing implementations. This document tries to achieve 132 clearing the confusion related to prefix length, and provide 133 consistency of variable length prefix across the three IPv6 134 addressing strategies deployed, static, DHCPv6 and Stateless Address 135 Autoconfiguration(SLAAC), and finally update all RFCs with the new 136 variable SLAAC standard. The 64 bit fixed boundary problem statment 137 is defined in draft [I-D.mishra-v6ops-variable-slaac-problem-stmt]. 139 Over the years one of the merits of increasing the prefix length, and 140 reducing the size of the interface identifier has been incorrectly 141 stated as the possibility of IPv6 address space exhaustion could be 142 circumvented, or that a 64 bit interface identifier is a wasteful use 143 of address space. 145 3. The History behind the 64 bit fixed boundary 147 The fixed length of an Interface Identifier has roots in other early 148 non-IP networks such as IPX of Novell and another from Apple. 150 Over the course of the history of the IPv6 protocol, several 151 addressing models have been proposed to break up the prefix into a 152 hierarchical format. One of the first attempts was [RFC2450] which 153 was based on a 13 bit Level Aggregation (TLA), 24 bit Next-Level 154 Aggregation (NLA), 16 bit Site Level aggregator Identifiers. The 155 current IPv6 addressing architecture for global unicast addressing 156 uses [RFC3587] for global unicast address currently being delegated 157 by IANA 2000::/3 prefix. With the recommendation in [RFC3177] which 158 called for a default end site assignment of a /48 which was adopted 159 by the Regional Internet Registry was revised with [RFC6177] to a 160 smaller block size of /56 prefix to end sites to avoid risk of 161 premature address depletion. The current IPv6 addressing 162 architecture [RFC3587] for global unicast addressing was now based on 163 an IPv6 hierarchical format which now consists of a 45 bit global 164 routing prefix, 16 bit subnet ID followed by 64 bit interface 165 identifier. In the earlier deployments of IPv6 due to the stringent 166 guidelines of [RFC4291] which stated that for all unicast addresses, 167 except those that start with the binary value 000, Interface IDs are 168 required to be 64 bits long and to be constructed in Modified EUI-64 169 format. Referencing IPv6 Addressing architecture [RFC3513] section 170 2.5.5 depicts examples of global unicast addresses that start with 171 binary 000 are IPv6 addresses with embedded IPv4 addresses and IPv6 172 address containing encoded NSAP addresses [RFC4548] described in 173 [RFC6052]. An example use case would be for NAT64 [RFC6146] as well 174 as many other use cases that exist with transition technology 175 tunneling using IPv4 IPv6 translators. 177 The general format for IPv6 global unicast addresses is as follows: 179 | n bits | m bits | 128-n-m bits | 180 +------------------------+-----------+----------------------------+ 181 | global routing prefix | subnet ID | interface ID | 182 +------------------------+-----------+----------------------------+ 184 Figure 1: Format of the IPv6 global unicast addresses 186 Even though [RFC4291] states that all global unicast addresses except 187 those that start with binary value 000, which use ipv4 ipv6 188 translators [RFC6052], that static and DHCPv6 violates [RFC4291] as 189 variable length masking to 128 is supported, where SLAAC variable 190 length masking remains forbidden. IPv6 packets over LAN based 191 technologies such as ethernet must use 64 bit interface identifier 192 per [RFC2464]. Nothing is mentioned regarding wireless based 193 technologies such as MIP6, V2V or 6loWPAN, with regards to interface 194 identifier length stringent requirement for 64 bit prefix length. 195 Stateful Address Autoconfiguration [RFC4862] states that the sum 196 total of the prefix length and interface identifier should equal 128 197 bits, but does not state that the interface identifier should be 64 198 bits. Note that [RFC4861] states that the PIO (Prefix information 199 Options), that the A-bit Autonomous address-configuration flag when 200 set indicates that the prefix can be used for (SLAAC) stateless 201 address autoconfiguration, and [RFC4862] states to silently ignore 202 the PIO options if the A flag is not set in the Router Advertisement. 203 If the A flag is not set then /64 is only a recommendation which 204 applies to DHCPv6 and static. 206 During the early deployments of IPv6, /64 was a 'de facto' standard 207 prefix length for deployment to all router interfaces including 208 point-to-point and loopbacks. In early deployments of IPv6, due to 209 the complexity and overall learning curve, and change going from IPv4 210 to IPv6, the keep it simple approach of /64 everywhere was the 211 general rule of thumb for deployment. After decades of deployment, 212 operators started to dig further into how IPv4 started out as 213 classful with classful routing protocols such as RIP or IGRP. Later 214 as Classless inter-domain routing with BGP became mainstream with 215 larger enterprises and service providers, operators started looking 216 at IPv6 and variable length masking. Operators now started 217 experimenting trying to subnet at nibble boundaries to start and 218 became brave enough to tackle subnetting on a bit boundary. As 219 variable length subnet masking became more mainstream with IPv6, 220 operators started to use /126 mask on point-to-point links. Around 221 that time [RFC3627] came out which talked about the harmful effects 222 of /127 and that it was forbidden due to operational impacts. 223 Harmful impacts of /127 were due to subnet-router anycast being in 224 conflict with [RFC2526] /121. Later was found the benefits of /127 225 avoided the ping-pong effect and the subnet-router anycast conflict 226 could be avoided by disabling Duplicate address detection thus the 227 status of use of /127 on point-to-point links was updated by 228 [RFC6164]. As the evolution of IPv6 continued, questions would come 229 as to why the interface identifier is so large at 64 bits, as 64 bits 230 equates to 18,446,744,073,709,551,616 IPv6 addresses, which is more 231 than anyone could ever imagine on a single flat subnet far into the 232 distant future. The main reason for the larger 64 bit interface 233 identifier is for privacy when connected directly to the internet, or 234 on an unsecure public hotspot or location so your device is not 235 traceable. 237 From the beginning of IPv6 deployments most enterprises went with 238 SLAAC, but as DHCPv6 matured, enterprises migrated to DHCPv6, and 239 network infrastructure remained configured manually using static 240 configurations. Since so many RFC's mention the SLAAC 64 bit 241 boundary requirement and confusion related to this topic, in fact 242 prevented operators proliferation of even attempting to use longer 243 prefixes on host subnets with static or DHCPv6 stateful. Most IPv6 244 implementations even to this day do not use longer than 64 bit 245 prefixes, and still maintain the 64 bit boundary for host subnet, for 246 both DHCPv6 and static, even though technically feasible, due to fear 247 of interoperability issues that may arise. With this new evolution 248 of IPv6 addressing architecture with variable SLAAC, we can bring 249 back SLAAC to the mainstream for all IPv6 deployments. This will 250 also allow operators to now comfortably deploy both DHCPv6 and static 251 with greater than 64 bit prefix length to host subnets, without fear 252 of interoperability problems. 254 Today we have three methods of IPv6 address deployment, SLAAC, DHCPv6 255 and static. DHCPv6 does not provide an adequate IPv6 addressing 256 solution as described in detail in the DHCPv6, Static, and SLAAC 257 comparison section. As user subnets flatten out further, as the IPv4 258 under pinning is eliminated, removing the shackles on IPv6, the 259 subnets will get much flatter. As the subnets flatten out in large 260 Enterprise networks where you have 100's of Dual Stack subnets 261 migrate to a single "IPV6-ONLY" subnet, the overhead DHCPv6 Normal 262 mode messaging becomes exacerbated. The problem with DHCPv6 is that 263 once the "M" managed bit is set to "1", all hosts on the subnet cache 264 the M bit and change to DHCPv6 stateful mode. Higher probability of 265 rouge devices such as printers or other appliances misbehaving with 266 IPv6 enabled by default, now in DHCPv6 mode, spewing of millions of 267 DHCPv6 messages that can now impact the router control plane 268 processing of packets. This can be alleviated with special custom 269 Control Plane policer policy, however now adds complexity and 270 administrative overhead to DHCPv6 deployments. Enterprises and 271 Service Providers require a viable IPv6 deployment solution that can 272 accommodate the shortfalls of both static and DHCPv6 addressing. 273 Static addressing due to administrative overhead of manual assignment 274 does not provide a viable solution for even moderately sized 275 networks. 277 An arbitrary length prefix solves problems described in detail in 278 section 7 and are being highlighted here as well as a key part of the 279 problem statement to be addressed. A site may not be able to 280 delegate sufficient address space from a /64 prefix to all of its 281 internal subnets. In this case a site may be partially operational 282 as it is unable to number all of its subnets. An alternative would 283 be to be able to use prefixes longer then /64 to allow multiple 284 subnets for example /80 for numbering subnets with a mixture of hosts 285 that are static or DHCPv6 without worry of interoperability issues. 286 Some operators would like the ability to have a hierarchical 287 addressing structure and may require more than 16 bits given with a 288 /48 allocation. In such instances longer prefix lengths would allow 289 for additional levels of aggregation as required. It is common for 290 some operators to have security audit requirements where they wish to 291 know all active hosts on a /64 subnet. As /64 subnets can contain an 292 enormous number of hosts and thus cannot be scanned as can IPv4 293 subnets. Operators have argued that one method to be able to scan 294 for active hosts would be by reducing the size of the subnet. 295 Neighbor discovery cache exhaustion when an attacker sends a large 296 number of messages in rapid succession to hosts filling the routers 297 ND cache is another problem with fixed length /64 size SLAAC subnets. 298 Neighbor Discovery cache exhaustion issues are relatively common on 299 IXP (Internet Exchange Points) where a very large number of Internet 300 Service Providers are full mesh peering to exchange routing updates. 301 As the number of hosts on a SLAAC subnet can be 2^64, a much smaller 302 subnet size can drastically reduce the Neighbor Discovery cache 303 exhaustion issues. 305 The goal of this document is to fix the problems related to stateless 306 address autoconfiguration (SLAAC), current obscurities of the 64 bit 307 prefix boundary, issues that exist today with current IPv6 addressing 308 using manual and DHCPv6, and how variable SLAAC can now be used to 309 fill the gaps with static and DHCPv6, and also update all standards 310 specifications to reflect the new variable SLAAC standard making the 311 prefix lengths variable. 313 4. Identifier and Subnet Length Statements 315 IPv6 router interfaces and hosts configured to use Stateful Address 316 Autoconfiguration (SLAAC) will now support variable mask up to 128 317 bits consistent with static and DHCPv6. This change will allow 318 variable SLAAC to be used on any infrastructure link from point-to- 319 point /127 to infrastructure shared subnets from /65 to /127. All 320 routers support routing of variable length IPv6 prefix lengths called 321 variable length subnet masks(VLSM) up to 128 bits in length, so this 322 variable stateless address autoconfiguration change will be in line 323 with all interior gateway routing protocols and exterior gateway 324 routing protocols. This change is for both Global Unicast address 325 [RFC3587] and Unique Local Address [RFC4193]. There will be no 326 change to the IPv6 link local address interface identifier which will 327 remain 64 bits for link local fe80::/10 router or host interface 328 fe80::/64 [RFC4291]. 330 The term "Variable SLAAC" as defined in this document states that the 331 length of the prefix can now be greater than 64 bits up to 127 bits 332 with a corresponding shorter interface identifier. The interface 333 identifier will range from 64 bits to 1 bit in length. The length of 334 the prefix can now be less than 64 bits to 3 bits in length with a 335 corresponding longer interface identifier and can now be greater than 336 64 bits to 125 bits in length. 338 The "race to the bottom problem" - is the problem where allowing 339 prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and 340 so on, up to 127 and 128 allocations. At that point the bottom would 341 be reached and thus impossible to extend the network further. 343 One version of the "address waste" problem is: SLAAC is used in a 344 subnet where 2^64 addresses are possible. But there are no link 345 layers that allow as many addresses to connect on a single link. 346 E.g. wired Ethernet allows for a few hundreds or a few thousands 347 nodes in a switched network. Because of that, the difference up to 348 2^64 addresses will not be used, as such they will be wasted. 350 5. Recommendations for implementation of variable SLAAC 352 This document proposes a plan to provide flexibility for implementers 353 to now have the option to use SLAAC (Stateful Address 354 Autoconfiguration) where previously they used DHCPv6 or static. This 355 will also open the door to interoperability and mixed device types 356 supporting either SLAAC, static or DHCPv6 to now be able to exist on 357 the same subnet or VLAN without risk of interoperability issues. 359 It is recommended to use variable length SLAAC on network 360 infrastructure point-to-point links as well as for host subnets where 361 historically /64 was used that now variable length SLAAC prefix can 362 be used up to 127 bit prefix length. It is recommended that the use 363 of variable length prefix be based on each individual IPv6 deployment 364 requirement. If more address space is required, necessity to break 365 up a /64 for address space management, creating an internal 366 hierarchical addressing plan based on prefixes delegated or 367 allocated, then variable length prefix is now an available option in 368 the designers toolbox that now can be utilized. Changes to DHCPv6 369 prefix-delegation is outside of the scope of this document. 371 It is recommended that ISP allocations and Customer allocations per 372 [RFC6177] and [RFC5375] not change due to this variable SLAAC 373 proposed standard. 375 6. Recommended use cases where 64 bit prefix should be utilized 377 Listed below are use cases where the 64 bit prefix length MUST be 378 adhered to and in these cases variable SLAAC feature should not be 379 utilized. 381 The precise 64-bit length of the interface identifier is widely 382 mentioned in numerous RFCs describing various aspects of IPv6. It is 383 not straightforward to distinguish cases where this has normative 384 impact or affects interoperability. This section aims to identify 385 specifications that contain an explicit reference to the 64-bit 386 length. Regardless of implementation issues, the RFCs themselves 387 would all need to be updated if the 64-bit rule was changed, even if 388 the updates were small, which would involve considerable time and 389 effort. 391 First and foremost, the RFCs describing the architectural aspects of 392 IPv6 addressing explicitly state, refer, and repeat this apparently 393 immutable value: Addressing Architecture [RFC4291], IPv6 Address 394 Assignment to End Sites [RFC6177], Reserved interface identifiers 395 [RFC5453], and ILNP Node Identifiers [RFC6741]. Customer edge 396 routers impose /64 for their interfaces [RFC7084]. The IPv6 Subnet 397 Model [RFC5942] points out that the assumption of a /64 prefix length 398 is a potential implementation error. 400 Numerous IPv6-over-foo documents make mandatory statements with 401 respect to the 64-bit length of the interface identifier to be used 402 during the Stateless Autoconfiguration. These documents include 403 [RFC2464] (Ethernet), [RFC2467] (Fiber Distributed Data Interface 404 (FDDI)), [RFC2470] (Token Ring), [RFC2492] (ATM), [RFC2497] (ARCnet), 405 [RFC2590] (Frame Relay), [RFC3146] (IEEE 1394), [RFC4338] (Fibre 406 Channel), [RFC4944] (IEEE 802.15.4), [RFC5072] (PPP), [RFC5121] 407 [RFC5692] (IEEE 802.16), [RFC2529] (6over4), [RFC5214] (Intra-Site 408 Automatic Tunnel Addressing Protocol (ISATAP)), 409 [I-D.templin-aerolink] (Asymmetric Extended Route Optimization 410 (AERO)), [I-D.ietf-6lowpan-btle] (BLUETOOTH Low Energy), 411 [I-D.ietf-6lo-6lobac] (IPv6 over MS/TP), and [I-D.ietf-6lo-lowpanz] 412 (IPv6 packets over ITU-T G.9959). 414 To a lesser extent, the address configuration RFCs themselves may in 415 some ways assume the 64-bit length of an interface identifier (e.g, 416 [RFC4862] for the link-local addresses, DHCPv6 for the potentially 417 assigned EUI- 64-based IP addresses, and Optimistic Duplicate Address 418 Detection [RFC4429] that computes 64-bit-based collision 419 probabilities). 421 The Multicast Listener Discovery Version 1 (MLDv1) [RFC2710] and 422 MLDv2 [RFC3810] protocols mandate that all queries be sent with a 423 link-local source address, with the exception of MLD messages sent 424 using the unspecified address when the link-local address is 425 tentative [RFC3590]. At the time of publication of [RFC2710], the 426 IPv6 addressing architecture specified link-local addresses with 427 64-bit interface identifiers. MLDv2 explicitly specifies the use of 428 the fe80::/64 link-local prefix and bases the querier election 429 algorithm on the link-local subnet prefix of length /64. 431 The "IPv6 Flow Label Specification" [RFC6437] gives an example of a 432 20-bit hash function generation, which relies on splitting an IPv6 433 address in two equally sized, 64-bit-length parts. 435 The basic transition mechanisms [RFC4213] refer to interface 436 identifiers of length 64 for link-local addresses; other transition 437 mechanisms such as Teredo [RFC4380] assume the use of interface 438 identifiers of length 64. Similar assumptions are found in 6to4 439 [RFC3056] and 6rd [RFC5969]. Translation-based transition mechanisms 440 such as NAT64 and NPTv6 have some dependency on prefix length, 441 discussed below. 443 The proposed method [RFC7278] of extending an assigned /64 prefix 444 from a smartphone's cellular interface to its WiFi link relies on 445 prefix length, and implicitly on the length of the interface 446 identifier, to be valued at 64. 448 The Cryptographically Generated Addresses (CGA) and Hash-Based 449 Addresses (HBA) specifications rely on the 64-bit identifier length 450 (see below), as do the Privacy extensions [RFC4941] and some examples 451 in "Internet Key Exchange Version 2 (IKEv2)" [RFC7296]. 453 464XLAT [RFC6877] explicitly mentions acquiring /64 prefixes. 454 However, it also discusses the possibility of using the interface 455 address on the device as the end point for the traffic, thus 456 potentially removing this dependency. 458 [RFC2526] reserves a number of subnet anycast addresses by reserving 459 some anycast interface identifiers. An anycast interface identifier 460 so reserved cannot be less than 7 bits long. This means that a 461 subnet prefix length longer than /121 is not possible, and a subnet 462 of exactly /121 would be useless since all its identifiers are 463 reserved. It also means that half of a /120 is reserved for anycast. 464 This could of course be fixed in the way described for /127 in 465 [RFC6164], i.e., avoiding the use of anycast within a /120 subnet. 466 Note that support for "on-link anycast" is a standard IPv6 neighbor 467 discovery capability [RFC4861] [RFC7094]; therefore, applications and 468 their developers would expect it to be available. 470 The Mobile IP home network models [RFC4887] rely heavily on the /64 471 subnet length and assume a 64-bit interface identifier. 473 o Multicast: [RFC3306] defines a method for generating IPv6 474 multicast group addresses based on unicast prefixes. This method 475 assumes a longest prefix of 64 bits. If a longer prefix is used, 476 there is no way to generate a specific multicast group address 477 using this method. In such cases, the administrator would need to 478 use an "artificial" prefix from within their allocation (a /64 or 479 shorter) from which to generate the group address. This prefix 480 would not correspond to a real subnet. 482 o Similarly, [RFC3956], which specifies the Embedded Rendezvous 483 Point (RP)) allowing IPv6 multicast rendezvous point addresses to 484 be embedded in the multicast group address, would also fail, as 485 the scheme assumes a maximum prefix length of 64 bits. 487 o CGA: The Cryptographically Generated Address format [RFC3972] is 488 heavily based on a /64 interface identifier. [RFC3972] has 489 defined a detailed algorithm showing how to generate a 64-bit 490 interface identifier from a public key and a 64-bit subnet prefix. 491 Changing the /64 boundary would certainly invalidate the current 492 CGA definition. However, the CGA might benefit in a redefined 493 version if more bits are used for interface identifiers (which 494 means shorter prefix length). For now, 59 bits are used for 495 cryptographic purposes. The more bits are available, the stronger 496 CGA could be. Conversely, longer prefixes would weaken CGA. 498 o NAT64: Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] 499 are flexible for the prefix length. [RFC6052] has defined 500 multiple address formats for NAT64. In Section 2 of 501 "IPv4-Embedded IPv6 Address Prefix and Format" [RFC6052], the 502 network-specific prefix could be one of /32, /40, /48, /56, /64, 503 and /96. The remaining part of the IPv6 address is constructed by 504 a 32-bit IPv4 address, an 8-bit u byte and a variable length 505 suffix (there is no u byte and suffix in the case of the 96-bit 506 Well-Known Prefix). NAT64 is therefore OK with a subnet boundary 507 out to /96 but not longer. 509 o NPTv6: IPv6-to-IPv6 Network Prefix Translation [RFC6296] is also 510 bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 511 prefix. When the NPTv6 Translator is configured with a /48 or 512 shorter prefix, the 64-bit interface identifier is kept unmodified 513 during translation. However, the /64 boundary might be changed as 514 long as the "inside" and "outside" prefixes have the same length. 516 o ILNP: Identifier-Locator Network Protocol (ILNP) [RFC6741] is 517 designed around the /64 boundary, since it relies on locally 518 unique 64-bit node identifiers (in the interface identifier 519 field). While a redesign to use longer prefixes is not 520 inconceivable, this would need major changes to the existing 521 specification for the IPv6 version of ILNP. 523 o Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] in 524 its insecure form treats IPv6 addresses as opaque 128-bit objects. 525 However, to secure the protocol against spoofing, it is essential 526 to either use CGAs (see above) or HBAs [RFC5535]. Like CGAs, HBAs 527 are generated using a procedure that assumes a 64-bit identifier. 528 Therefore, in effect, secure shim6 is affected by the /64 boundary 529 exactly like CGAs. 531 o Duplicate address risk: If SLAAC was modified to work with shorter 532 interface identifiers, the statistical risk of hosts choosing the 533 same pseudo- random identifier [RFC7217] would increase 534 correspondingly. The practical impact of this would range from 535 slight to dramatic, depending on how much the interface identifier 536 length was reduced. In particular, a /120 prefix would imply an 537 8-bit interface identifier and address collisions would be highly 538 probable. 540 o The link-local prefix: While [RFC4862] is careful not to define 541 any specific length of link-local prefix within fe80::/10, the 542 addressing architecture [RFC4291] does define the link-local 543 interface identifier length to be 64 bits. If different hosts on 544 a link used interface identifiers of different lengths to form a 545 link-local address, there is potential for confusion and 546 unpredictable results. Typically today the choice of 64 bits for 547 the link-local interface identifier length is hard-coded per 548 interface, in accordance with the relevant IPv6-over-foo 549 specification, and systems behave as if the link-local prefix was 550 actually fe80::/64. There might be no way to change this except 551 conceivably by manual configuration, which will be impossible if 552 the host concerned has no local user interface. 554 7. Reasons for longer than 64 bit prefix length 556 In this section we are providing the justification for longer 557 prefixes and shorter interface identifiers essentially variable 558 SLAAC. 560 7.1. Insufficient Address Space Delegated 562 A site may not be delegated a sufficiently generous prefix from which 563 to allocate a /64 prefix to all of its internal subnets. In this 564 case, the site may either determine that it does not have enough 565 address space to number all its network elements and thus, at the 566 very best, be only partially operational, or it may choose to use 567 internal prefixes longer than /64 to allow multiple subnets and the 568 hosts within them to be configured with addresses. 570 In this case, the site might choose, for example, to use a /80 per 571 subnet in combination with hosts using either manually configured 572 addressing or DHCPv6 [RFC3315]. 574 Scenarios that have been suggested where an insufficient prefix might 575 be delegated include home or small office networks, vehicles, 576 building services, and transportation services (e.g., road signs). 577 It should be noted that the homenet architecture text [RFC7368] 578 states that Customer Premises Equipment (CPE) should consider the 579 lack of sufficient address space to be an error condition, rather 580 than using prefixes longer than /64 internally. 582 Another scenario occasionally suggested is one where the Internet 583 address registries actually begin to run out of IPv6 prefix space, 584 such that operators can no longer assign reasonable prefixes to users 585 in accordance with [RFC6177]. It is sometimes suggested that 586 assigning a prefix such as /48 or /56 to every user site (including 587 the smallest) as recommended by [RFC6177] is wasteful. In fact, the 588 currently released unicast address space, 2000::/3, contains 35 589 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a 590 small fraction have been allocated. Allowing for a conservative 591 estimate of allocation efficiency, i.e., an HD-ratio of 0.94 592 [RFC4692], approximately 5 trillion /48 prefixes can be allocated. 593 Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 594 prefixes can be allocated. Furthermore, with only 2000::/3 currently 595 committed for unicast addressing, we still have approximately 85% of 596 the address space in reserve. Thus, there is no objective risk of 597 prefix depletion by assigning /48 or /56 prefixes even to the 598 smallest sites. 600 7.2. Hierarchical Addressing 602 Some operators have argued that more prefix bits are needed to allow 603 an aggregated hierarchical addressing scheme within a campus or 604 corporate network. However, if a campus or enterprise gets a /48 605 prefix (or shorter), then that already provides 16 bits for 606 hierarchical allocation. In any case, flat IGP routing is widely and 607 successfully used within rather large networks, with hundreds of 608 routers and thousands of end systems. Therefore, there is no 609 objective need for additional prefix bits to support hierarchy and 610 aggregation within enterprises. 612 7.3. Audit Requirement 614 Some network operators wish to know and audit nodes that are active 615 on a network, especially those that are allowed to communicate off- 616 link or off-site. They may also wish to limit the total number of 617 active addresses and sessions that can be sourced from a particular 618 host, LAN, or site, in order to prevent potential resource-depletion 619 attacks or other problems spreading beyond a certain scope of 620 control. It has been argued that this type of control would be 621 easier if only long network prefixes with relatively small numbers of 622 possible hosts per network were used, reducing the discovery problem. 623 However, such sites most typically operate using DHCPv6, which means 624 that all legitimate hosts are automatically known to the DHCPv6 625 servers, which is sufficient for audit purposes. Such hosts could, 626 if desired, be limited to a small range of interface identifier 627 values without changing the /64 subnet length. Any hosts 628 inadvertently obtaining addresses via SLAAC can be audited through 629 Neighbor Discovery (ND) logs. 631 7.4. Concerns over ND Cache Exhaustion 633 A site may be concerned that it is open to ND cache exhaustion 634 attacks [RFC3756], whereby an attacker sends a large number of 635 messages in rapid succession to a series of (most likely inactive) 636 host addresses within a specific subnet. Such an attack attempts to 637 fill a router's ND cache with ND requests pending completion, which 638 results in denying correct operation to active devices on the 639 network. 641 One potential way to mitigate this attack would be to consider using 642 a /120 prefix, thus limiting the number of addresses in the subnet to 643 be similar to an IPv4 /24 prefix, which should not cause any concerns 644 for ND cache exhaustion. Note that the prefix does need to be quite 645 long for this scenario to be valid. The number of theoretically 646 possible ND cache slots on the segment needs to be of the same order 647 of magnitude as the actual number of hosts. Thus, small increases 648 from the /64 prefix length do not have a noticeable impact; even 2^32 649 potential entries, a factor of two billion decrease compared to 2^64, 650 is still more than enough to exhaust the memory on current routers. 651 Given that most link-layer mappings cause SLAAC to assume a 64-bit 652 network boundary, in such an approach hosts would likely need to use 653 DHCPv6 or be manually configured with addresses. 655 It should be noted that several other mitigations of the ND cache 656 attack are described in [RFC6583], and that limiting the size of the 657 cache and the number of incomplete entries allowed would also defeat 658 the attack. For the specific case of a point-to-point link between 659 routers, this attack is indeed mitigated by a /127 prefix [RFC6164]. 661 7.5. Longer prefixes lengths used for embedding information 663 Ability to utilize the longer than 64 bit prefixes to be able to 664 embed geographic or other information into the prefix that could be 665 valuable to the IPv6 addressing architecture providing more 666 flexibility to the operator. 668 8. Greater than 64 bit prefix usage by ISPs is strictly prohibited 670 The RA flag S bit setting proposed by this draft for greater or less 671 then /64 bit prefix feature is strictly for enterprises and broadband 672 subscriber customer use only. In the broadband space this feature is 673 to be used only by home broadband users or Small Office Home Office 674 broadband users. ISPs can use DHCPv6-PD to send greater than /64 675 prefix advertisement message to the CE router. However, ISPs MUST 676 NOT set the RA flag S bit, and send greater than /64 prefix down to 677 the host. With this draft, no changes will be made to any of the 678 current IPv6 prefix allocation guidelines for customers prefixes 679 sizes sent by ISPs. In the enterprise space any router is allowed to 680 set the RA flag S bit for greater then /64 prefix allocation. This 681 provides tremendous flexibility for enterprises as well as broadband 682 subscriber customers to segment and further extend a single /64 683 allocation. Enterprise use case allows for added further 684 segmentation granularity and functionality for endpoints devices. 685 Broadband subscriber use cases with the proliferation of IoT and 6lo 686 devices in the home or small office use case, allows for added 687 further segmentation granularity and functionality for endpoints 688 devices. This change of stateful address auto configuration to now 689 allow for greater then 64 bit prefix length is not being done because 690 there is wasted space with a /64 prefix length or that there is any 691 even remote possibility of running out of address space. The reason 692 for restriction of use of this feature by ISP's is also because it 693 puts the customer at the shorter end of the stick with smaller 694 allocation, which you could be interpreted as biased or unfair to 695 smaller customers that cannot afford the larger space as large 696 companies. This would be another form of inequality between 697 customers and service provider similar to net neutrality discussions 698 and fairness in quality of service. ISPs have essentially nothing to 699 gain by advertising smaller prefixes with greater than /64 prefixes 700 allocations as address space is in abundance. On the other hand for 701 ISPs' OPEX costs could be increased and so much less cost effective 702 to administer greater then /64 variable length prefixes versed fixed 703 /64 size prefix would be much more challenging and cost prohibitive 704 to manage. 706 9. Comparison of Static, SLAAC, DHCPv6 and Variable SLAAC 708 o Static - IPv6 address and Default Gateway: 710 Pros: 712 + Deactivation of RA processing 713 + Good resistance against RA attack 715 Cons: 717 + Operational impact in configuring interface manually 719 + Network dynamics might require renumbering which needs work 721 o Static - IPv6 address and Default Route via RA 723 Pros: 725 + Does not require disabling RA processing 727 + Works better with FHRP router redundancy 729 Cons: 731 + RA related security issues combat with RA Guard 733 o DHCPv6 [RFC3315] 735 Pros: 737 + Centralized provisioning of IPv6 addressing 739 + IPv6, DNS, NTP can all be distributed 741 Cons: 743 + Administrative overhead of managing DHCPv6 server 745 + Caveats with redundancy and split scopes required for 746 failover. Split scope and failover is resolved with DHCPv6 747 Failover protocol [RFC8156] 749 + RA related security issues combat with RA Guard 751 o SLAAC [RFC7217] Stable Random station-id with privacy and 752 [RFC8064] Recommendations for Stable interfae identifier 754 Pros: 756 + Automatic provisioning IPv6 address to hosts 758 + [RFC7217] Stable Random station-id with privacy extensions 760 Cons: 762 + RA related security issues combat with RA Guard 764 o Variable SLAAC with [RFC7217] Stable Random station-id with 765 privacy and [RFC8064] Recommendations for Stable interfae 766 identifier 768 Pros: 770 + Automatic provisioning IPv6 address to hosts 772 + [RFC7217] Stable Random station-id with privacy extensions 774 Cons: 776 + RA related security issues combat with RA Guard 778 + Security is reduced with longer prefixes and shorter stable 779 random station-id 781 IPv6 address deployment summary statement. 783 DHCPv6 [RFC3315] state machine introduces a large number of messaging 784 packets with Normal mode, four messages called solicit, advertise, 785 request and reply. DHCPv6 Rapid Commit mode reduces the messages 786 from four to two messages only solicit and reply. DHCPv6 Normal mode 787 is the Default. It is recommended to use DHCPv6 Rapid mode [RFC4039] 788 in "high mobility" networks where clients come and go often. The 789 overhead of four messages might not be required so two messages might 790 enough to accommodate. However, if you have multiple DHCPv6 servers 791 for redundancy then you need to use DHCPv6 Normal mode. If you have 792 subnets where there are a large flat user subnets with a very large 793 number of hosts and redundancy is required and DHCPv6 Normal mode is 794 utilized, DHCPv6 messaging is exacerbated exponentially as the 795 subnets flatten out further and further. As the paradigm shifts and 796 IPv4 is eliminated as hosts subnets change to "IPv6-ONLY" subnets, 797 the coupling of IPv4 with IPv6 Dual stack dependency is eliminated, 798 thus removing the shackles pinning IPv6 to smaller many IPv4 subnets. 799 This change allows IPv6 subnets to become very large and flat with 800 the only limiting factor being the L2 switch infrastructure. In many 801 cases Dual stacked implementations with 100's of subnets may change 802 to a single "IPV6 ONLY" subnet. As "IPV6-ONLY" subnets will soon 803 become the future direction of all user access infrastructure, we 804 need a viable solution that will accommodate these very large flat 805 subnets. The problem with DHCPv6 is that once the "M" managed bit is 806 set to "1", all hosts on the subnet cache the Managed IP "M bit" and 807 changes host to DHCPv6 stateful mode. Higher probability of rouge 808 devices such as printers or other appliances misbehaving with IPv6 809 enabled by default, now in DHCPv6 mode, spewing of millions of DHCPv6 810 messages that can now impact the router control plane processing of 811 packets. This can be alleviated with special custom Control plane 812 policer policy, however now adds complexity and administrative 813 overhead to DHCPv6 deployments. Enterprises and Service Providers 814 require a viable IPv6 deployment solution that can accommodate the 815 shortfalls of both static and DHCPv6 addressing. Static addressing 816 due to administrative overhead of manual assignment does not provide 817 a viable solution for even moderately sized networks. Variable SLAAC 818 now has the ability to fill the gaps outlined with DHCPv6 and static 819 that can now be used as a viable ubiquitous all encompassing solution 820 for IPv6 address deployments. 822 10. Variable SLAAC Use Cases 824 This section describes real world use cases of variable slaac that 825 cannot be done today and with fixed 64 bit prefix lengths. 827 10.1. Permission-less Extension of the Network 829 Permission-less extensions of the network with new links (and by 830 implication with new routers) are not supported. 832 The lack of possibility to realize a permission-less extension of the 833 network is an important problem. The problem appears at the edge of 834 the network. The permission is 'granted' for end users situated at 835 the edge of the network. This permission is 'granted' by advertising 836 a prefix of length 64, typically. This prefix is set in the PIO 837 option in an RA. The end user receives this prefix, forms an 838 address, and is able to connect to the Internet. However, the end 839 user has no permission to further extend the network. Although s/he 840 is able to form subsequent prefixes of a length of, say 65, and 841 further advertise it down in the extension of the network, no other 842 Host in that extension of the network is able to use that 843 advertisement; a Host can not form an address with a prefix length 65 844 by using SLAAC. The linux error text reported in the kernel log upon 845 reception of a plen 65 is "illegal" (or similar). 847 10.2. Private Networks 849 Private networks such as Service Provider core not accessable by 850 customers and enterprises where all hosts are trusted are the primary 851 use case for variable SLAAC as the shorter interface identifier does 852 not create any security issues with not having a longer 64 bit 853 interface identifier for privacy extensions stable interface 854 identifier [RFC8084] due to all hosts being inherently trusted. 855 Private internal networks such as corporate intranets traditionally 856 have always used static IPv6 addressing for infrastructure. This 857 manual IPv6 address assignment process for network infrastructure 858 links can take long lead times to complete deployment. By changing 859 the behavior of SLAAC to support variable length prefix and interface 860 identifier allows SLAAC to be used programmatically to deploy to 861 large scale IPv6 networks with thousands of point-to-point links. 862 Note that network infrastructure technically does not require IPv6 863 addressing due to IPv6 next hop being a link local address for IGP 864 routing protocols such as OSPF and ISIS as well as the link local 865 address can be the peer IPv6 address for exterior gateway routing 866 protocols such as BGP. However for hop by hop ping and traceroute 867 capability to have IPv6 reachability at each hop for troubleshooting 868 jitter, latency and drops it is an IPv6 recommended best practice to 869 configure IPv6 address on all infrastructure interfaces. 871 10.3. Mobile IPv6 873 Old MIP6 (Mobile IPv6) Working Group and old Nemo Working Group's 874 routing solution scenarios related to Mobile IPv6 ([RFC3775]) (note: 875 nowadays most MIP-related activity is in DMM WG) where the mobile 876 endpoint can now obtain from the home agent variable SLAAC address 877 and not 64 bit prefix /64 address. This maybe useful in cases where 878 a /64 can now be managed from an addressing perspective and 879 subdivided into blocks for manageability of MIP6 endpoints instead of 880 allocating a single /64 per endpoint. 882 10.4. Home and SOHO 884 Home and SOHO (Small Office and Home Office) environments where 885 internet access uses a broadband service provider single or dual 886 homed scenario. In those such Home networking Homenet environments 887 where HNCP (Home Network Control Protocol [RFC7788] SADR (Source 888 Address Dependent Routing) are deployed for automatic configuration 889 for LAN WIFI endpoint subnets can also now take advantage of variable 890 length SLAAC in deployment scenarios. In cases where multiple 891 routers are deployed in a home environment where routing prefix 892 reachability needs to be advertised where Bable [RFC6126] routing 893 protocol is utilized in those cases variable SLAAC can also be 894 utilized to break up a /64 into multiple smaller subnets. 896 10.5. 3GPP V2I and V2V networking 898 In V2I networking (with 3GPP or with IEEE 802.11bd) the vehicle 899 receives a /64 prefix from the cellular network (or from a Road-Side 900 Unit). This /64 prefix can be used to form one address for the 901 egress interface of the Mobile Router (IP On-Board Unit), but can not 902 be used to form IP addresses for other hosts in the vehicle. 904 3GPP V2V networking use cases where a /56 is allocated to the 4G 905 modem and a /64 is delegated to downstream devices within the 906 automobile now the /64 prefixes can be sub divided into smaller 907 prefix lengths of /65-/128. This provides additional granularity to 908 use cases. 910 10.6. 6lo 912 6lo Working IPv6 over Network Constrained nodes working group use 913 cases. Use cases for IoT devices where have limited network access 914 requirements could now take advantage of variable SLAAC longer 915 prefixes lengths /65-/128. 917 10.7. Large ISP's backbone POP 919 Large ISP backbone POPs such as IXPs where many carriers share the 920 same backbone and ND cache exhaustion may occur due to /64 subnet 921 size. One mitigation technique employed is the use of an ARP Sponge 922 for IPv4 or Layer 2 multicast rate limiters for IPv6. In those 923 particular cases a longer prefix static or variable SLAAC subnet 924 could be utilized to reduce the maximum number of hosts on the 925 subnet. 927 11. Variable SLAAC implementation using RA Flag 929 [RFC5175] currently defines the flags in the NDP Router Advertisement 930 message and these flags are registered in the IANA IPv6 ND Router 931 Advertisement flags Registry [IANA-RF]. This currently contains the 932 following one-bit flags defined in published RFCs: 934 0 1 2 3 4 5 6 7 935 +-+-+-+-+-+-+-+-+ 936 |M|O|H|Prf|P|R|R| 937 +-+-+-+-+-+-+-+-+ 939 Figure 2: Format of flags in Router Advertisement message 941 o M: Managed Address Configuration Flag [RFC4861] 943 o O: Other Configuration Flag [RFC4861] 945 o H: Mobile IPv6 Home Agent Flag [RFC3775] 947 o Prf: Router Selection Preferences [RFC4191] 949 o P: Neighbor Discovery Proxy Flag [RFC4389] 951 o R: Reserved 952 This document defines bit 6 to be the Variable SLAAC Flag: 954 o S: SLAAC Variable length interface identifier Flag 956 This flag has two values. These are: 958 o 0: Variable length interface identifier is disabled 960 o 1: Variable length interface identifier is enabled (ignored by 961 hosts not supporting) 963 [RFC5175] requires that unused flag bits be set to zero. Therefore, 964 a router that does not support the new flag will not appear to assert 965 that the PIO list prefix list advertised does not support variable 966 length interface identifier. 968 Hosts receiving the Router Advertisement SHOULD only process this 969 flag if the advertising router is a Default Router. Specifically, if 970 the Lifetime field in the Router Advertisement is not zero, otherwise 971 it SHOULD be ignored. 973 Note that although this mechanism uses one of only two reserved flag 974 bits in the RA, an extension mechanism is defined in Section 4 of 975 [RFC5175] in case additional flags are ever required for future 976 extensions. It should be noted that since [RFC5175] was published in 977 2008, no new RA flags have been assigned in the IANA registry. 979 This draft precludes the use of EUI64 based, 64 bit fixed length 980 interface identifier generation algorithms, and allows the use of any 981 standard variable interface identifier generation algorithm for the 982 auto generating variable length interface identifier less than 64 983 bits for example [RFC4941] Privacy Extensions for Stateless Address 984 Autoconfiguration in IPv6 or [RFC7217] Semantically opaque interface 985 identifier with SLAAC privacy extension algorithm for stable variable 986 length interface identifier per [RFC8064]. In this particular case 987 the prefix will be greater than 64 bits and the stable interface 988 identifier will be less than 64 bits. 990 This draft precludes the use of EUI64 based, 64 bit fixed length 991 interface identifier generation algorithms, and allows the use of any 992 standard variable interface identifier generation algorithm for the 993 auto generating variable length interface identifier greater than 64 994 bits for example [RFC4941] Privacy Extensions for Stateless Address 995 Autoconfiguration in IPv6 or [RFC7217] Semantically opaque interface 996 identifier with SLAAC privacy extension algorithm for stable variable 997 length interface identifier per [RFC8064]. In this particular case 998 the prefix will be less than 64 bits and the stable interface 999 identifier will be less than 64 bits. 1001 Draft rfc4941bis Privacy Extension for SLAAC using [RFC4086] Pseudo- 1002 Random Number Generator(PRNG) can also be used as a possible method 1003 of generating greater then 64 bit or less then 64 bit interface 1004 identifier automatically since stated in the draft that the interface 1005 identifier can be generated for any arbitrary length. 1006 https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/ 1008 12. Applicability Statements 1010 The RA flag option for variable length interface identifier is 1011 designed to allow administrators send variable length prefixes in the 1012 PIO list advertisement to the host and hosts supporting this variable 1013 interface identifier option would be able to process the flag and use 1014 the prefix with variable interface identifier in the PIO list . 1016 Administrators MUST only use this variable length interface 1017 identifier flag configured on the router to signal processing of the 1018 longer prefix if they have longer then 64 bit prefix configured on 1019 the router. 1021 13. Router and Operational Considerations 1023 Default IPv6 routers that have the variable interface identifier with 1024 longer than 64 bit prefixes SHOULD be configured by the administrator 1025 to set the variable SLAAC flag to 1. In all other cases the flag 1026 SHOULD NOT be set to 1. 1028 The intent is that the administrator of the router configures the 1029 router to set the variable SLAAC flag if and only if she/he wants to 1030 tell the hosts on the link that the prefixes being sent are greater 1031 then 64 bits and shorter then the standard 64 bit interface 1032 identifier. This is a configuration flag, it is not something that 1033 the router decides on its own. Routers MAY log a configuration error 1034 if the flag is set and the prefix is not longer the 64 bits and the 1035 interface identifier is not shorter then 64 bits. 1037 Routers implementing this document SHOULD log to system or network 1038 management inconsistent setting of the variable SLAAC flag. This 1039 extends the behavior specified in Section 6.2.7 of [RFC4861]. 1041 14. Host Behavior Considerations 1043 Host operating system support will be backwards compatible so host 1044 that do not support the flag will ignore the variable SLAAC flag 1045 being set to 1. In that scenario the router supports the variable 1046 length prefix option and would be configured with the flag set and 1047 would send the variable length prefix to the host, however the host 1048 not supporting the flag will not accept the prefix as it is not 64 1049 bit length and as it is unable to process the flag. Hosts that 1050 support the variable SLAAC RA flag MUST have a configuration option 1051 to ignore or process the flag. The motivation for this configuration 1052 option is for hosts that are capable of processing the variable SLAAC 1053 flag to only act on the flag if they are configured to do so. 1055 If there are multiple IPv6 default routers on a link, they might send 1056 different values of the flag. If at least one IPv6 default router 1057 sends the flag with value 1, the host supporting the flag will 1058 receive will receive and process the flag and accept the PIO list 1059 with variable prefixes. If all IPv6 default routers send the flag 1060 with value 1 the host will receive and process the prefix and flag 1061 from all routers sending the RA. 1063 15. Security Considerations 1065 The administrator should be aware to maintain 64 bit interface 1066 identifier for privacy when connected directly to the internet so 1067 that entropy for optimal heuristics are maintained for security. 1069 Variable length interface identifier shorter then 64 bits should be 1070 only used within corporate intranets and private networks where all 1071 hosts are trusted. 1073 In all cases where the host is on a public network for privacy 1074 concerns to avoid traceability variable interface identifier MUST 1075 never be utilized. 1077 16. IANA Considerations 1079 IANA is requested to assign the new Router Advertisement flag defined 1080 in Section 5 of this document. Bit 6 is the next available bit in 1081 this registry, IANA is requested to use this bit unless there is a 1082 reason to use another bit in this registry. 1084 IANA is also requested to register this new flag bit in the IANA IPv6 1085 ND Router Advertisement flags Registry [IANA-RF]. 1087 17. Contributors 1089 Contributors. 1091 18. Acknowledgements 1092 19. References 1094 19.1. Normative References 1096 [I-D.bourbaki-6man-classless-ipv6] 1097 Bourbaki, N., "IPv6 is Classless", draft-bourbaki-6man- 1098 classless-ipv6-05 (work in progress), April 2019. 1100 [I-D.ietf-6lo-6lobac] 1101 Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, 1102 "Transmission of IPv6 over MS/TP Networks", draft-ietf- 1103 6lo-6lobac-08 (work in progress), March 2017. 1105 [I-D.ietf-6lo-lowpanz] 1106 Brandt, A. and J. Buron, "Transmission of IPv6 packets 1107 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08 1108 (work in progress), October 2014. 1110 [I-D.ietf-6lowpan-btle] 1111 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 1112 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 1113 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 1114 (work in progress), February 2013. 1116 [I-D.mishra-v6ops-variable-slaac-problem-stmt] 1117 Mishra, G., Petrescu, A., Kottapalli, N., Mudric, D., and 1118 D. Shytyi, "SLAAC with prefixes of arbitrary length in PIO 1119 (Variable SLAAC)", draft-mishra-v6ops-variable-slaac- 1120 problem-stmt-00 (work in progress), October 2020. 1122 [I-D.templin-aerolink] 1123 Templin, F., "Asymmetric Extended Route Optimization 1124 (AERO)", draft-templin-aerolink-82 (work in progress), May 1125 2018. 1127 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1128 Requirement Levels", BCP 14, RFC 2119, 1129 DOI 10.17487/RFC2119, March 1997, 1130 . 1132 [RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", 1133 RFC 2450, DOI 10.17487/RFC2450, December 1998, 1134 . 1136 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1137 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 1138 . 1140 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 1141 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 1142 . 1144 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 1145 IPv6 Packets over Token Ring Networks", RFC 2470, 1146 DOI 10.17487/RFC2470, December 1998, 1147 . 1149 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 1150 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 1151 . 1153 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 1154 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 1155 . 1157 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1158 Addresses", RFC 2526, DOI 10.17487/RFC2526, March 1999, 1159 . 1161 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1162 Domains without Explicit Tunnels", RFC 2529, 1163 DOI 10.17487/RFC2529, March 1999, 1164 . 1166 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 1167 IPv6 Packets over Frame Relay Networks Specification", 1168 RFC 2590, DOI 10.17487/RFC2590, May 1999, 1169 . 1171 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1172 Listener Discovery (MLD) for IPv6", RFC 2710, 1173 DOI 10.17487/RFC2710, October 1999, 1174 . 1176 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1177 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1178 2001, . 1180 [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets 1181 over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, 1182 October 2001, . 1184 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1185 Allocations to Sites", RFC 3177, DOI 10.17487/RFC3177, 1186 September 2001, . 1188 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1189 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 1190 August 2002, . 1192 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1193 C., and M. Carney, "Dynamic Host Configuration Protocol 1194 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1195 2003, . 1197 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1198 (IPv6) Addressing Architecture", RFC 3513, 1199 DOI 10.17487/RFC3513, April 2003, 1200 . 1202 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1203 Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, 1204 August 2003, . 1206 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1207 Listener Discovery (MLD) Protocol", RFC 3590, 1208 DOI 10.17487/RFC3590, September 2003, 1209 . 1211 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 1212 Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, 1213 September 2003, . 1215 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 1216 Neighbor Discovery (ND) Trust Models and Threats", 1217 RFC 3756, DOI 10.17487/RFC3756, May 2004, 1218 . 1220 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1221 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 1222 . 1224 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1225 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1226 DOI 10.17487/RFC3810, June 2004, 1227 . 1229 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1230 Point (RP) Address in an IPv6 Multicast Address", 1231 RFC 3956, DOI 10.17487/RFC3956, November 2004, 1232 . 1234 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1235 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1236 . 1238 [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for 1239 the Dynamic Host Configuration Protocol version 4 1240 (DHCPv4)", RFC 4039, DOI 10.17487/RFC4039, March 2005, 1241 . 1243 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1244 "Randomness Requirements for Security", BCP 106, RFC 4086, 1245 DOI 10.17487/RFC4086, June 2005, 1246 . 1248 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1249 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1250 November 2005, . 1252 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1253 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1254 . 1256 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1257 for IPv6 Hosts and Routers", RFC 4213, 1258 DOI 10.17487/RFC4213, October 2005, 1259 . 1261 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1262 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1263 2006, . 1265 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 1266 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 1267 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 1268 January 2006, . 1270 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1271 Network Address Translations (NATs)", RFC 4380, 1272 DOI 10.17487/RFC4380, February 2006, 1273 . 1275 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1276 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 1277 2006, . 1279 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1280 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 1281 . 1283 [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code 1284 Point (ICP) Assignments for NSAP Addresses", RFC 4548, 1285 DOI 10.17487/RFC4548, May 2006, 1286 . 1288 [RFC4692] Huston, G., "Considerations on the IPv6 Host Density 1289 Metric", RFC 4692, DOI 10.17487/RFC4692, October 2006, 1290 . 1292 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1293 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1294 DOI 10.17487/RFC4861, September 2007, 1295 . 1297 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1298 Address Autoconfiguration", RFC 4862, 1299 DOI 10.17487/RFC4862, September 2007, 1300 . 1302 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 1303 Mobility Home Network Models", RFC 4887, 1304 DOI 10.17487/RFC4887, July 2007, 1305 . 1307 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1308 Extensions for Stateless Address Autoconfiguration in 1309 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1310 . 1312 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1313 "Transmission of IPv6 Packets over IEEE 802.15.4 1314 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1315 . 1317 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1318 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1319 . 1321 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 1322 Madanapalli, "Transmission of IPv6 via the IPv6 1323 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 1324 DOI 10.17487/RFC5121, February 2008, 1325 . 1327 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 1328 Advertisement Flags Option", RFC 5175, 1329 DOI 10.17487/RFC5175, March 2008, 1330 . 1332 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1333 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1334 DOI 10.17487/RFC5214, March 2008, 1335 . 1337 [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., 1338 and C. Hahn, "IPv6 Unicast Address Assignment 1339 Considerations", RFC 5375, DOI 10.17487/RFC5375, December 1340 2008, . 1342 [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", 1343 RFC 5453, DOI 10.17487/RFC5453, February 2009, 1344 . 1346 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1347 Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533, 1348 June 2009, . 1350 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 1351 DOI 10.17487/RFC5535, June 2009, 1352 . 1354 [RFC5692] Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP 1355 over Ethernet over IEEE 802.16 Networks", RFC 5692, 1356 DOI 10.17487/RFC5692, October 2009, 1357 . 1359 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 1360 Model: The Relationship between Links and Subnet 1361 Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, 1362 . 1364 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1365 Infrastructures (6rd) -- Protocol Specification", 1366 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1367 . 1369 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1370 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1371 DOI 10.17487/RFC6052, October 2010, 1372 . 1374 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 1375 DOI 10.17487/RFC6126, April 2011, 1376 . 1378 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1379 NAT64: Network Address and Protocol Translation from IPv6 1380 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1381 April 2011, . 1383 [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, 1384 L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- 1385 Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, 1386 . 1388 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1389 Assignment to End Sites", BCP 157, RFC 6177, 1390 DOI 10.17487/RFC6177, March 2011, 1391 . 1393 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1394 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1395 . 1397 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1398 "IPv6 Flow Label Specification", RFC 6437, 1399 DOI 10.17487/RFC6437, November 2011, 1400 . 1402 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 1403 Neighbor Discovery Problems", RFC 6583, 1404 DOI 10.17487/RFC6583, March 2012, 1405 . 1407 [RFC6741] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 1408 Protocol (ILNP) Engineering Considerations", RFC 6741, 1409 DOI 10.17487/RFC6741, November 2012, 1410 . 1412 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1413 Combination of Stateful and Stateless Translation", 1414 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1415 . 1417 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1418 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1419 DOI 10.17487/RFC7084, November 2013, 1420 . 1422 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1423 "Architectural Considerations of IP Anycast", RFC 7094, 1424 DOI 10.17487/RFC7094, January 2014, 1425 . 1427 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1428 Interface Identifiers with IPv6 Stateless Address 1429 Autoconfiguration (SLAAC)", RFC 7217, 1430 DOI 10.17487/RFC7217, April 2014, 1431 . 1433 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 1434 /64 Prefix from a Third Generation Partnership Project 1435 (3GPP) Mobile Interface to a LAN Link", RFC 7278, 1436 DOI 10.17487/RFC7278, June 2014, 1437 . 1439 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1440 Kivinen, "Internet Key Exchange Protocol Version 2 1441 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1442 2014, . 1444 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 1445 Weil, "IPv6 Home Networking Architecture Principles", 1446 RFC 7368, DOI 10.17487/RFC7368, October 2014, 1447 . 1449 [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., 1450 Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit 1451 Boundary in IPv6 Addressing", RFC 7421, 1452 DOI 10.17487/RFC7421, January 2015, 1453 . 1455 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1456 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1457 2016, . 1459 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1460 "Recommendation on Stable IPv6 Interface Identifiers", 1461 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1462 . 1464 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1465 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1466 . 1468 [RFC8156] Mrugalski, T. and K. Kinnear, "DHCPv6 Failover Protocol", 1469 RFC 8156, DOI 10.17487/RFC8156, June 2017, 1470 . 1472 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1473 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1474 May 2017, . 1476 19.2. Informative References 1478 [I-D.ietf-6man-ipv6-address-generation-privacy] 1479 Cooper, A., Gont, F., and D. Thaler, "Privacy 1480 Considerations for IPv6 Address Generation Mechanisms", 1481 draft-ietf-6man-ipv6-address-generation-privacy-08 (work 1482 in progress), September 2015. 1484 [I-D.ietf-opsec-ipv6-host-scanning] 1485 Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1486 Networks", draft-ietf-opsec-ipv6-host-scanning-08 (work in 1487 progress), August 2015. 1489 [I-D.shytyi-opsawg-vysm] 1490 Shytyi, D., Beylier, L., and L. Iannone, "A YANG Module 1491 for uCPE management.", draft-shytyi-opsawg-vysm-08 (work 1492 in progress), May 2020. 1494 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1495 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1496 . 1498 Appendix A. ChangeLog 1500 The changes are listed in reverse chronological order, most recent 1501 changes appearing at the top of the list. 1503 -00: initial version. 1505 Authors' Addresses 1507 Gyan Mishra 1508 Verizon Inc. 1510 Email: gyan.s.mishra@verizon.com 1512 Alexandre Petrescu 1513 CEA, LIST 1514 CEA Saclay 1515 Gif-sur-Yvette, Ile-de-France 91190 1516 France 1518 Phone: +33169089223 1519 Email: Alexandre.Petrescu@cea.fr 1520 Naveen Kottapalli 1521 Benu Networks 1522 300 Concord Road 1523 Billerica MA 01821 1524 United States of America 1526 Phone: +1 978 223 4700 1527 Email: nkottapalli@benu.net 1529 Dusan Mudric 1530 Ciena 1531 Canada 1533 Phone: +1-613-670-2425 1534 Email: dmudric@ciena.com 1536 Dmytro Shytyi 1537 SFR 1538 Paris 1539 France 1541 Email: dmytro.shytyi@sfr.com