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