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