Verizon Inc.

gyan.s.mishra@verizon.com

CEA, LIST

CEA Saclay Gif-sur-Yvette Ile-de-France 91190 France +33169089223 Alexandre.Petrescu@cea.fr

Benu Networks

300 Concord Road Billerica MA 01821 United States of America +1 978 223 4700 nkottapalli@benu.net

Ciena

Canada +1-613-670-2425 dmudric@ciena.com

SFR

Paris France dmytro.shytyi@sfr.com

Internet 6MAN Working Group keywords This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 65 in PIO, for example, would be permitted to form an addresses whose interface identifier length is length 63, which allows several benefits. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

From the beginning, the IPv6 addressing plan was based on a 128 bit address format made up of 8 hextets which were broken down into a 64 bit four hextet prefix and 64 bit four hextet interface identifier. For example, the address 2001:db8:3:4::1 has the first 4 hextets forming the /64 prefix 2001:db8:3:4::/64, whereas the last four hextets form an interface identifier abbreviated as ::1 (a 'hextet' is a group of max 4 hex digits between two columns, e.g. "2001" and "db8" are each a hextet). A comprehensive analysis of the 64-bit boundary is provided in . The history of IPv6 Classful models proposed, and the last remnant of IPv6 Classful addressing rigid network interface identifier boundary at /64 is discussed in detail as well as the removal of the fixed position of the boundary for interface addressing in draft . This document discusses the reasons why the interface identifier has been fixed at 64 bits, and the problems that can be addressed by changing the GUA interface identifier from fixed 64 bit size to a variable interface identifier. This change would be consistent with static and DHCPv6 stateful IPv6 address assignment, as well as the proposed solution would ensure maintaining backwards compatibility for existing implementations. This document tries to achieve clearing the confusion related to prefix length, and provide consistency of variable length prefix across the three IPv6 addressing strategies deployed, static, DHCPv6 and Stateless Address Autoconfiguration(SLAAC), and finally update all RFCs with the new variable SLAAC standard. Over the years one of the merits of increasing the prefix length, and reducing the size of the interface identifier has been incorrectly stated as the possibility of IPv6 address space exhaustion could be circumvented, or that a 64 bit interface identifier is a wasteful use of address space.

The fixed length of an Interface Identifier has roots in other early non-IP networks such as IPX of Novell and another from Apple. Over the course of the history of the IPv6 protocol, several addressing models have been proposed to break up the prefix into a hierarchical format. One of the first attempts was which was based on a 13 bit Level Aggregation (TLA), 24 bit Next-Level Aggregation (NLA), 16 bit Site Level aggregator Identifiers. The current IPv6 addressing architecture for global unicast addressing uses for global unicast address currently being delegated by IANA 2000::/3 prefix. With the recommendation in which called for a default end site assignment of a /48 which was adopted by the Regional Internet Registry was revised with to a smaller block size of /56 prefix to end sites to avoid risk of premature address depletion. The current IPv6 addressing architecture for global unicast addressing was now based on an IPv6 hierarchical format which now consists of a 45 bit global routing prefix, 16 bit subnet ID followed by 64 bit interface identifier. In the earlier deployments of IPv6 due to the stringent guidelines of which stated that for all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. Referencing IPv6 Addressing architecture section 2.5.5 depicts examples of global unicast addresses that start with binary 000 are IPv6 addresses with embedded IPv4 addresses and IPv6 address containing encoded NSAP addresses described in . An example use case would be for NAT64 as well as many other use cases that exist with transition technology tunneling using IPv4 IPv6 translators. The general format for IPv6 global unicast addresses is as follows:

Even though states that all global unicast addresses except those that start with binary value 000, which use ipv4 ipv6 translators , that static and DHCPv6 violates as variable length masking to 128 is supported, where SLAAC variable length masking remains forbidden. IPv6 packets over LAN based technologies such as ethernet must use 64 bit interface identifier per . Nothing is mentioned regarding wireless based technologies such as MIP6, V2V or 6loWPAN, with regards to interface identifier length stringent requirement for 64 bit prefix length. Stateful Address Autoconfiguration states that the sum total of the prefix length and interface identifier should equal 128 bits, but does not state that the interface identifier should be 64 bits. Note that states that the PIO (Prefix information Options), that the A-bit Autonomous address-configuration flag when set indicates that the prefix can be used for (SLAAC) stateless address autoconfiguration, and states to silently ignore the PIO options if the A flag is not set in the Router Advertisement. If the A flag is not set then /64 is only a recommendation which applies to DHCPv6 and static. During the early deployments of IPv6, /64 was a 'de facto' standard prefix length for deployment to all router interfaces including point-to-point and loopbacks. In early deployments of IPv6, due to the complexity and overall learning curve, and change going from IPv4 to IPv6, the keep it simple approach of /64 everywhere was the general rule of thumb for deployment. After decades of deployment, operators started to dig further into how IPv4 started out as classful with classful routing protocols such as RIP or IGRP. Later as Classless inter-domain routing with BGP became mainstream with larger enterprises and service providers, operators started looking at IPv6 and variable length masking. Operators now started experimenting trying to subnet at nibble boundaries to start and became brave enough to tackle subnetting on a bit boundary. As variable length subnet masking became more mainstream with IPv6, operators started to use /126 mask on point-to-point links. Around that time came out which talked about the harmful effects of /127 and that it was forbidden due to operational impacts. Harmful impacts of /127 were due to subnet-router anycast being in conflict with /121. Later was found the benefits of /127 avoided the ping-pong effect and the subnet-router anycast conflict could be avoided by disabling Duplicate address detection thus the status of use of /127 on point-to-point links was updated by . As the evolution of IPv6 continued, questions would come as to why the interface identifier is so large at 64 bits, as 64 bits equates to 18,446,744,073,709,551,616 IPv6 addresses, which is more than anyone could ever imagine on a single flat subnet far into the distant future. The main reason for the larger 64 bit interface identifier is for privacy when connected directly to the internet, or on an unsecure public hotspot or location so your device is not traceable. From the beginning of IPv6 deployments most enterprises went with SLAAC, but as DHCPv6 matured, enterprises migrated to DHCPv6, and network infrastructure remained configured manually using static configurations. Since so many RFC’s mention the SLAAC 64 bit boundary requirement and confusion related to this topic, in fact prevented operators proliferation of even attempting to use longer prefixes on host subnets with static or DHCPv6 stateful. Most IPv6 implementations even to this day do not use longer than 64 bit prefixes, and still maintain the 64 bit boundary for host subnet, for both DHCPv6 and static, even though technically feasible, due to fear of interoperability issues that may arise. With this new evolution of IPv6 addressing architecture with variable SLAAC, we can bring back SLAAC to the mainstream for all IPv6 deployments. This will also allow operators to now comfortably deploy both DHCPv6 and static with greater than 64 bit prefix length to host subnets, without fear of interoperability problems. Today we have three methods of IPv6 address deployment, SLAAC, DHCPv6 and static. DHCPv6 does not provide an adequate IPv6 addressing solution as described in detail in the DHCPv6, Static, and SLAAC comparison section. As user subnets flatten out further, as the IPv4 under pinning is eliminated, removing the shackles on IPv6, the subnets will get much flatter. As the subnets flatten out in large Enterprise networks where you have 100’s of Dual Stack subnets migrate to a single “IPV6-ONLY” subnet, the overhead DHCPv6 Normal mode messaging becomes exacerbated. The problem with DHCPv6 is that once the “M” managed bit is set to “1”, all hosts on the subnet cache the M bit and change to DHCPv6 stateful mode. Higher probability of rouge devices such as printers or other appliances misbehaving with IPv6 enabled by default, now in DHCPv6 mode, spewing of millions of DHCPv6 messages that can now impact the router control plane processing of packets. This can be alleviated with special custom Control Plane policer policy, however now adds complexity and administrative overhead to DHCPv6 deployments. Enterprises and Service Providers require a viable IPv6 deployment solution that can accommodate the shortfalls of both static and DHCPv6 addressing. Static addressing due to administrative overhead of manual assignment does not provide a viable solution for even moderately sized networks. An arbitrary length prefix solves problems described in detail in section 7 and are being highlighted here as well as a key part of the problem statement to be addressed. A site may not be able to delegate sufficient address space from a /64 prefix to all of its internal subnets. In this case a site may be partially operational as it is unable to number all of its subnets. An alternative would be to be able to use prefixes longer then /64 to allow multiple subnets for example /80 for numbering subnets with a mixture of hosts that are static or DHCPv6 without worry of interoperability issues. Some operators would like the ability to have a hierarchical addressing structure and may require more than 16 bits given with a /48 allocation. In such instances longer prefix lengths would allow for additional levels of aggregation as required. It is common for some operators to have security audit requirements where they wish to know all active hosts on a /64 subnet. As /64 subnets can contain an enormous number of hosts and thus cannot be scanned as can IPv4 subnets. Operators have argued that one method to be able to scan for active hosts would be by reducing the size of the subnet. Neighbor discovery cache exhaustion when an attacker sends a large number of messages in rapid succession to hosts filling the routers ND cache is another problem with fixed length /64 size SLAAC subnets. Neighbor Discovery cache exhaustion issues are relatively common on IXP (Internet Exchange Points) where a very large number of Internet Service Providers are full mesh peering to exchange routing updates. As the number of hosts on a SLAAC subnet can be 2^64, a much smaller subnet size can drastically reduce the Neighbor Discovery cache exhaustion issues. The goal of this document is to fix the problems related to stateless address autoconfiguration (SLAAC), current obscurities of the 64 bit prefix boundary, issues that exist today with current IPv6 addressing using manual and DHCPv6, and how variable SLAAC can now be used to fill the gaps with static and DHCPv6, and also update all standards specifications to reflect the new variable SLAAC standard making the prefix lengths variable.

IPv6 router interfaces and hosts configured to use Stateful Address Autoconfiguration (SLAAC) will now support variable mask up to 128 bits consistent with static and DHCPv6. This change will allow variable SLAAC to be used on any infrastructure link from point-to-point /127 to infrastructure shared subnets from /65 to /127. All routers support routing of variable length IPv6 prefix lengths called variable length subnet masks(VLSM) up to 128 bits in length, so this variable stateless address autoconfiguration change will be in line with all interior gateway routing protocols and exterior gateway routing protocols. This change is for both Global Unicast address and Unique Local Address . There will be no change to the IPv6 link local address interface identifier which will remain 64 bits for link local fe80::/10 router or host interface fe80::/64 . The term "Variable SLAAC" as defined in this document states that the length of the prefix can now be greater than 64 bits up to 127 bits with a corresponding shorter interface identifier. The interface identifier will range from 64 bits to 1 bit in length. The length of the prefix can now be less than 64 bits to 3 bits in length with a corresponding longer interface identifier and can now be greater than 64 bits to 125 bits in length. The "race to the bottom problem" - is the problem where allowing prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and so on, up to 127 and 128 allocations. At that point the bottom would be reached and thus impossible to extend the network further. One version of the "address waste" problem is: SLAAC is used in a subnet where 2^64 addresses are possible. But there are no link layers that allow as many addresses to connect on a single link. E.g. wired Ethernet allows for a few hundreds or a few thousands nodes in a switched network. Because of that, the difference up to 2^64 addresses will not be used, as such they will be wasted.

This document proposes a plan to provide flexibility for implementers to now have the option to use SLAAC (Stateful Address Autoconfiguration) where previously they used DHCPv6 or static. This will also open the door to interoperability and mixed device types supporting either SLAAC, static or DHCPv6 to now be able to exist on the same subnet or VLAN without risk of interoperability issues. It is recommended to use variable length SLAAC on network infrastructure point-to-point links as well as for host subnets where historically /64 was used that now variable length SLAAC prefix can be used up to 127 bit prefix length. It is recommended that the use of variable length prefix be based on each individual IPv6 deployment requirement. If more address space is required, necessity to break up a /64 for address space management, creating an internal hierarchical addressing plan based on prefixes delegated or allocated, then variable length prefix is now an available option in the designers toolbox that now can be utilized. Changes to DHCPv6 prefix-delegation is outside of the scope of this document. It is recommended that ISP allocations and Customer allocations per and not change due to this variable SLAAC proposed standard.

Listed below are use cases where the 64 bit prefix length MUST be adhered to and in these cases variable SLAAC feature should not be utilized. The precise 64-bit length of the interface identifier is widely mentioned in numerous RFCs describing various aspects of IPv6. It is not straightforward to distinguish cases where this has normative impact or affects interoperability. This section aims to identify specifications that contain an explicit reference to the 64-bit length. Regardless of implementation issues, the RFCs themselves would all need to be updated if the 64-bit rule was changed, even if the updates were small, which would involve considerable time and effort. First and foremost, the RFCs describing the architectural aspects of IPv6 addressing explicitly state, refer, and repeat this apparently immutable value: Addressing Architecture , IPv6 Address Assignment to End Sites , Reserved interface identifiers , and ILNP Node Identifiers . Customer edge routers impose /64 for their interfaces . The IPv6 Subnet Model points out that the assumption of a /64 prefix length is a potential implementation error. Numerous IPv6-over-foo documents make mandatory statements with respect to the 64-bit length of the interface identifier to be used during the Stateless Autoconfiguration. These documents include (Ethernet), (Fiber Distributed Data Interface (FDDI)), (Token Ring), (ATM), (ARCnet), (Frame Relay), (IEEE 1394), (Fibre Channel), (IEEE 802.15.4), (PPP), (IEEE 802.16), (6over4), (Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)), (Asymmetric Extended Route Optimization (AERO)), (BLUETOOTH Low Energy), (IPv6 over MS/TP), and (IPv6 packets over ITU-T G.9959). To a lesser extent, the address configuration RFCs themselves may in some ways assume the 64-bit length of an interface identifier (e.g, for the link-local addresses, DHCPv6 for the potentially assigned EUI- 64-based IP addresses, and Optimistic Duplicate Address Detection that computes 64-bit-based collision probabilities). The Multicast Listener Discovery Version 1 (MLDv1) and MLDv2 protocols mandate that all queries be sent with a link-local source address, with the exception of MLD messages sent using the unspecified address when the link-local address is tentative . At the time of publication of , the IPv6 addressing architecture specified link-local addresses with 64-bit interface identifiers. MLDv2 explicitly specifies the use of the fe80::/64 link-local prefix and bases the querier election algorithm on the link-local subnet prefix of length /64. The "IPv6 Flow Label Specification" gives an example of a 20-bit hash function generation, which relies on splitting an IPv6 address in two equally sized, 64-bit-length parts. The basic transition mechanisms refer to interface identifiers of length 64 for link-local addresses; other transition mechanisms such as Teredo assume the use of interface identifiers of length 64. Similar assumptions are found in 6to4 and 6rd . Translation-based transition mechanisms such as NAT64 and NPTv6 have some dependency on prefix length, discussed below. The proposed method of extending an assigned /64 prefix from a smartphone's cellular interface to its WiFi link relies on prefix length, and implicitly on the length of the interface identifier, to be valued at 64. The Cryptographically Generated Addresses (CGA) and Hash-Based Addresses (HBA) specifications rely on the 64-bit identifier length (see below), as do the Privacy extensions and some examples in "Internet Key Exchange Version 2 (IKEv2)" . 464XLAT explicitly mentions acquiring /64 prefixes. However, it also discusses the possibility of using the interface address on the device as the end point for the traffic, thus potentially removing this dependency. reserves a number of subnet anycast addresses by reserving some anycast interface identifiers. An anycast interface identifier so reserved cannot be less than 7 bits long. This means that a subnet prefix length longer than /121 is not possible, and a subnet of exactly /121 would be useless since all its identifiers are reserved. It also means that half of a /120 is reserved for anycast. This could of course be fixed in the way described for /127 in , i.e., avoiding the use of anycast within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability ; therefore, applications and their developers would expect it to be available. The Mobile IP home network models rely heavily on the /64 subnet length and assume a 64-bit interface identifier. Multicast: defines a method for generating IPv6 multicast group addresses based on unicast prefixes. This method assumes a longest prefix of 64 bits. If a longer prefix is used, there is no way to generate a specific multicast group address using this method. In such cases, the administrator would need to use an "artificial" prefix from within their allocation (a /64 or shorter) from which to generate the group address. This prefix would not correspond to a real subnet. Similarly, , which specifies the Embedded Rendezvous Point (RP)) allowing IPv6 multicast rendezvous point addresses to be embedded in the multicast group address, would also fail, as the scheme assumes a maximum prefix length of 64 bits. CGA: The Cryptographically Generated Address format is heavily based on a /64 interface identifier. has defined a detailed algorithm showing how to generate a 64-bit interface identifier from a public key and a 64-bit subnet prefix. Changing the /64 boundary would certainly invalidate the current CGA definition. However, the CGA might benefit in a redefined version if more bits are used for interface identifiers (which means shorter prefix length). For now, 59 bits are used for cryptographic purposes. The more bits are available, the stronger CGA could be. Conversely, longer prefixes would weaken CGA. NAT64: Both stateless NAT64 and stateful NAT64 are flexible for the prefix length. has defined multiple address formats for NAT64. In Section 2 of "IPv4-Embedded IPv6 Address Prefix and Format" , the network-specific prefix could be one of /32, /40, /48, /56, /64, and /96. The remaining part of the IPv6 address is constructed by a 32-bit IPv4 address, an 8-bit u byte and a variable length suffix (there is no u byte and suffix in the case of the 96-bit Well-Known Prefix). NAT64 is therefore OK with a subnet boundary out to /96 but not longer. NPTv6: IPv6-to-IPv6 Network Prefix Translation is also bound to /64 boundary. NPTv6 maps a /64 prefix to another /64 prefix. When the NPTv6 Translator is configured with a /48 or shorter prefix, the 64-bit interface identifier is kept unmodified during translation. However, the /64 boundary might be changed as long as the "inside" and "outside" prefixes have the same length. ILNP: Identifier-Locator Network Protocol (ILNP) is designed around the /64 boundary, since it relies on locally unique 64-bit node identifiers (in the interface identifier field). While a redesign to use longer prefixes is not inconceivable, this would need major changes to the existing specification for the IPv6 version of ILNP. Shim6: The Multihoming Shim Protocol for IPv6 (Shim6) in its insecure form treats IPv6 addresses as opaque 128-bit objects. However, to secure the protocol against spoofing, it is essential to either use CGAs (see above) or HBAs . Like CGAs, HBAs are generated using a procedure that assumes a 64-bit identifier. Therefore, in effect, secure shim6 is affected by the /64 boundary exactly like CGAs. Duplicate address risk: If SLAAC was modified to work with shorter interface identifiers, the statistical risk of hosts choosing the same pseudo- random identifier would increase correspondingly. The practical impact of this would range from slight to dramatic, depending on how much the interface identifier length was reduced. In particular, a /120 prefix would imply an 8-bit interface identifier and address collisions would be highly probable. The link-local prefix: While is careful not to define any specific length of link-local prefix within fe80::/10, the addressing architecture does define the link-local interface identifier length to be 64 bits. If different hosts on a link used interface identifiers of different lengths to form a link-local address, there is potential for confusion and unpredictable results. Typically today the choice of 64 bits for the link-local interface identifier length is hard-coded per interface, in accordance with the relevant IPv6-over-foo specification, and systems behave as if the link-local prefix was actually fe80::/64. There might be no way to change this except conceivably by manual configuration, which will be impossible if the host concerned has no local user interface.

In this section we are providing the justification for longer prefixes and shorter interface identifiers essentially variable SLAAC.

A site may not be delegated a sufficiently generous prefix from which to allocate a /64 prefix to all of its internal subnets. In this case, the site may either determine that it does not have enough address space to number all its network elements and thus, at the very best, be only partially operational, or it may choose to use internal prefixes longer than /64 to allow multiple subnets and the hosts within them to be configured with addresses. In this case, the site might choose, for example, to use a /80 per subnet in combination with hosts using either manually configured addressing or DHCPv6 . Scenarios that have been suggested where an insufficient prefix might be delegated include home or small office networks, vehicles, building services, and transportation services (e.g., road signs). It should be noted that the homenet architecture text states that Customer Premises Equipment (CPE) should consider the lack of sufficient address space to be an error condition, rather than using prefixes longer than /64 internally. Another scenario occasionally suggested is one where the Internet address registries actually begin to run out of IPv6 prefix space, such that operators can no longer assign reasonable prefixes to users in accordance with . It is sometimes suggested that assigning a prefix such as /48 or /56 to every user site (including the smallest) as recommended by is wasteful. In fact, the currently released unicast address space, 2000::/3, contains 35 trillion /48 prefixes ((2**45 = 35,184,372,088,832), of which only a small fraction have been allocated. Allowing for a conservative estimate of allocation efficiency, i.e., an HD-ratio of 0.94 , approximately 5 trillion /48 prefixes can be allocated. Even with a relaxed HD-ratio of 0.89, approximately one trillion /48 prefixes can be allocated. Furthermore, with only 2000::/3 currently committed for unicast addressing, we still have approximately 85% of the address space in reserve. Thus, there is no objective risk of prefix depletion by assigning /48 or /56 prefixes even to the smallest sites.

Some operators have argued that more prefix bits are needed to allow an aggregated hierarchical addressing scheme within a campus or corporate network. However, if a campus or enterprise gets a /48 prefix (or shorter), then that already provides 16 bits for hierarchical allocation. In any case, flat IGP routing is widely and successfully used within rather large networks, with hundreds of routers and thousands of end systems. Therefore, there is no objective need for additional prefix bits to support hierarchy and aggregation within enterprises.

Some network operators wish to know and audit nodes that are active on a network, especially those that are allowed to communicate off- link or off-site. They may also wish to limit the total number of active addresses and sessions that can be sourced from a particular host, LAN, or site, in order to prevent potential resource-depletion attacks or other problems spreading beyond a certain scope of control. It has been argued that this type of control would be easier if only long network prefixes with relatively small numbers of possible hosts per network were used, reducing the discovery problem. However, such sites most typically operate using DHCPv6, which means that all legitimate hosts are automatically known to the DHCPv6 servers, which is sufficient for audit purposes. Such hosts could, if desired, be limited to a small range of interface identifier values without changing the /64 subnet length. Any hosts inadvertently obtaining addresses via SLAAC can be audited through Neighbor Discovery (ND) logs.

A site may be concerned that it is open to ND cache exhaustion attacks , whereby an attacker sends a large number of messages in rapid succession to a series of (most likely inactive) host addresses within a specific subnet. Such an attack attempts to fill a router's ND cache with ND requests pending completion, which results in denying correct operation to active devices on the network. One potential way to mitigate this attack would be to consider using a /120 prefix, thus limiting the number of addresses in the subnet to be similar to an IPv4 /24 prefix, which should not cause any concerns for ND cache exhaustion. Note that the prefix does need to be quite long for this scenario to be valid. The number of theoretically possible ND cache slots on the segment needs to be of the same order of magnitude as the actual number of hosts. Thus, small increases from the /64 prefix length do not have a noticeable impact; even 2^32 potential entries, a factor of two billion decrease compared to 2^64, is still more than enough to exhaust the memory on current routers. Given that most link-layer mappings cause SLAAC to assume a 64-bit network boundary, in such an approach hosts would likely need to use DHCPv6 or be manually configured with addresses. It should be noted that several other mitigations of the ND cache attack are described in , and that limiting the size of the cache and the number of incomplete entries allowed would also defeat the attack. For the specific case of a point-to-point link between routers, this attack is indeed mitigated by a /127 prefix .

Ability to utilize the longer than 64 bit prefixes to be able to embed geographic or other information into the prefix that could be valuable to the IPv6 addressing architecture providing more flexibility to the operator.

The RA flag S bit setting proposed by this draft for greater or less then /64 bit prefix feature is strictly for enterprises and broadband subscriber customer use only. In the broadband space this feature is to be used only by home broadband users or Small Office Home Office broadband users. ISPs can use DHCPv6-PD to send greater than /64 prefix advertisement message to the CE router. However, ISPs MUST NOT set the RA flag S bit, and send greater than /64 prefix down to the host. With this draft, no changes will be made to any of the current IPv6 prefix allocation guidelines for customers prefixes sizes sent by ISPs. In the enterprise space any router is allowed to set the RA flag S bit for greater then /64 prefix allocation. This provides tremendous flexibility for enterprises as well as broadband subscriber customers to segment and further extend a single /64 allocation. Enterprise use case allows for added further segmentation granularity and functionality for endpoints devices. Broadband subscriber use cases with the proliferation of IoT and 6lo devices in the home or small office use case, allows for added further segmentation granularity and functionality for endpoints devices. This change of stateful address auto configuration to now allow for greater then 64 bit prefix length is not being done because there is wasted space with a /64 prefix length or that there is any even remote possibility of running out of address space. The reason for restriction of use of this feature by ISP’s is also because it puts the customer at the shorter end of the stick with smaller allocation, which you could be interpreted as biased or unfair to smaller customers that cannot afford the larger space as large companies. This would be another form of inequality between customers and service provider similar to net neutrality discussions and fairness in quality of service. ISPs have essentially nothing to gain by advertising smaller prefixes with greater than /64 prefixes allocations as address space is in abundance. On the other hand for ISPs' OPEX costs could be increased and so much less cost effective to administer greater then /64 variable length prefixes versed fixed /64 size prefix would be much more challenging and cost prohibitive to manage.

Static - IPv6 address and Default Gateway: Deactivation of RA processing Good resistance against RA attack Operational impact in configuring interface manually Network dynamics might require renumbering which needs work Static - IPv6 address and Default Route via RA Does not require disabling RA processing Works better with FHRP router redundancy RA related security issues combat with RA Guard DHCPv6 Centralized provisioning of IPv6 addressing IPv6, DNS, NTP can all be distributed Administrative overhead of managing DHCPv6 server Caveats with redundancy and split scopes required for failover. Split scope and failover is resolved with DHCPv6 Failover protocol RA related security issues combat with RA Guard SLAAC Stable Random station-id with privacy and Recommendations for Stable interfae identifier Automatic provisioning IPv6 address to hosts Stable Random station-id with privacy extensions RA related security issues combat with RA Guard Variable SLAAC with Stable Random station-id with privacy and Recommendations for Stable interfae identifier Automatic provisioning IPv6 address to hosts Stable Random station-id with privacy extensions RA related security issues combat with RA Guard Security is reduced with longer prefixes and shorter stable random station-id IPv6 address deployment summary statement. DHCPv6 state machine introduces a large number of messaging packets with Normal mode, four messages called solicit, advertise, request and reply. DHCPv6 Rapid Commit mode reduces the messages from four to two messages only solicit and reply. DHCPv6 Normal mode is the Default. It is recommended to use DHCPv6 Rapid mode in “high mobility” networks where clients come and go often. The overhead of four messages might not be required so two messages might enough to accommodate. However, if you have multiple DHCPv6 servers for redundancy then you need to use DHCPv6 Normal mode. If you have subnets where there are a large flat user subnets with a very large number of hosts and redundancy is required and DHCPv6 Normal mode is utilized, DHCPv6 messaging is exacerbated exponentially as the subnets flatten out further and further. As the paradigm shifts and IPv4 is eliminated as hosts subnets change to “IPv6-ONLY” subnets, the coupling of IPv4 with IPv6 Dual stack dependency is eliminated, thus removing the shackles pinning IPv6 to smaller many IPv4 subnets. This change allows IPv6 subnets to become very large and flat with the only limiting factor being the L2 switch infrastructure. In many cases Dual stacked implementations with 100’s of subnets may change to a single “IPV6 ONLY” subnet. As “IPV6-ONLY” subnets will soon become the future direction of all user access infrastructure, we need a viable solution that will accommodate these very large flat subnets. The problem with DHCPv6 is that once the “M” managed bit is set to “1”, all hosts on the subnet cache the Managed IP "M bit" and changes host to DHCPv6 stateful mode. Higher probability of rouge devices such as printers or other appliances misbehaving with IPv6 enabled by default, now in DHCPv6 mode, spewing of millions of DHCPv6 messages that can now impact the router control plane processing of packets. This can be alleviated with special custom Control plane policer policy, however now adds complexity and administrative overhead to DHCPv6 deployments. Enterprises and Service Providers require a viable IPv6 deployment solution that can accommodate the shortfalls of both static and DHCPv6 addressing. Static addressing due to administrative overhead of manual assignment does not provide a viable solution for even moderately sized networks. Variable SLAAC now has the ability to fill the gaps outlined with DHCPv6 and static that can now be used as a viable ubiquitous all encompassing solution for IPv6 address deployments.

This section describes real world use cases of variable slaac that cannot be done today and with fixed 64 bit prefix lengths.

Permission-less extensions of the network with new links (and by implication with new routers) are not supported. The lack of possibility to realize a permission-less extension of the network is an important problem. The problem appears at the edge of the network. The permission is 'granted' for end users situated at the edge of the network. This permission is 'granted' by advertising a prefix of length 64, typically. This prefix is set in the PIO option in an RA. The end user receives this prefix, forms an address, and is able to connect to the Internet. However, the end user has no permission to further extend the network. Although s/he is able to form subsequent prefixes of a length of, say 65, and further advertise it down in the extension of the network, no other Host in that extension of the network is able to use that advertisement; a Host can not form an address with a prefix length 65 by using SLAAC. The linux error text reported in the kernel log upon reception of a plen 65 is "illegal" (or similar).

Private networks such as Service Provider core not accessable by customers and enterprises where all hosts are trusted are the primary use case for variable SLAAC as the shorter interface identifier does not create any security issues with not having a longer 64 bit interface identifier for privacy extensions stable interface identifier due to all hosts being inherently trusted. Private internal networks such as corporate intranets traditionally have always used static IPv6 addressing for infrastructure. This manual IPv6 address assignment process for network infrastructure links can take long lead times to complete deployment. By changing the behavior of SLAAC to support variable length prefix and interface identifier allows SLAAC to be used programmatically to deploy to large scale IPv6 networks with thousands of point-to-point links. Note that network infrastructure technically does not require IPv6 addressing due to IPv6 next hop being a link local address for IGP routing protocols such as OSPF and ISIS as well as the link local address can be the peer IPv6 address for exterior gateway routing protocols such as BGP. However for hop by hop ping and traceroute capability to have IPv6 reachability at each hop for troubleshooting jitter, latency and drops it is an IPv6 recommended best practice to configure IPv6 address on all infrastructure interfaces.

Old MIP6 (Mobile IPv6) Working Group and old Nemo Working Group's routing solution scenarios related to Mobile IPv6 () (note: nowadays most MIP-related activity is in DMM WG) where the mobile endpoint can now obtain from the home agent variable SLAAC address and not 64 bit prefix /64 address. This maybe useful in cases where a /64 can now be managed from an addressing perspective and subdivided into blocks for manageability of MIP6 endpoints instead of allocating a single /64 per endpoint.

Home and SOHO (Small Office and Home Office) environments where internet access uses a broadband service provider single or dual homed scenario. In those such Home networking Homenet environments where HNCP (Home Network Control Protocol SADR (Source Address Dependent Routing) are deployed for automatic configuration for LAN WIFI endpoint subnets can also now take advantage of variable length SLAAC in deployment scenarios. In cases where multiple routers are deployed in a home environment where routing prefix reachability needs to be advertised where Bable routing protocol is utilized in those cases variable SLAAC can also be utilized to break up a /64 into multiple smaller subnets.

In V2I networking (with 3GPP or with IEEE 802.11bd) the vehicle receives a /64 prefix from the cellular network (or from a Road-Side Unit). This /64 prefix can be used to form one address for the egress interface of the Mobile Router (IP On-Board Unit), but can not be used to form IP addresses for other hosts in the vehicle. 3GPP V2V networking use cases where a /56 is allocated to the 4G modem and a /64 is delegated to downstream devices within the automobile now the /64 prefixes can be sub divided into smaller prefix lengths of /65-/128. This provides additional granularity to use cases.

6lo Working IPv6 over Network Constrained nodes working group use cases. Use cases for IoT devices where have limited network access requirements could now take advantage of variable SLAAC longer prefixes lengths /65-/128.

Large ISP backbone POPs such as IXPs where many carriers share the same backbone and ND cache exhaustion may occur due to /64 subnet size. One mitigation technique employed is the use of an ARP Sponge for IPv4 or Layer 2 multicast rate limiters for IPv6. In those particular cases a longer prefix static or variable SLAAC subnet could be utilized to reduce the maximum number of hosts on the subnet.

currently defines the flags in the NDP Router Advertisement message and these flags are registered in the IANA IPv6 ND Router Advertisement flags Registry [IANA-RF]. This currently contains the following one-bit flags defined in published RFCs:

M: Managed Address Configuration Flag O: Other Configuration Flag H: Mobile IPv6 Home Agent Flag Prf: Router Selection Preferences P: Neighbor Discovery Proxy Flag R: Reserved This document defines bit 6 to be the Variable SLAAC Flag: S: SLAAC Variable length interface identifier Flag This flag has two values. These are: 0: Variable length interface identifier is disabled 1: Variable length interface identifier is enabled (ignored by hosts not supporting) requires that unused flag bits be set to zero. Therefore, a router that does not support the new flag will not appear to assert that the PIO list prefix list advertised does not support variable length interface identifier. Hosts receiving the Router Advertisement SHOULD only process this flag if the advertising router is a Default Router. Specifically, if the Lifetime field in the Router Advertisement is not zero, otherwise it SHOULD be ignored. Note that although this mechanism uses one of only two reserved flag bits in the RA, an extension mechanism is defined in Section 4 of in case additional flags are ever required for future extensions. It should be noted that since was published in 2008, no new RA flags have been assigned in the IANA registry. This draft precludes the use of EUI64 based, 64 bit fixed length interface identifier generation algorithms, and allows the use of any standard variable interface identifier generation algorithm for the auto generating variable length interface identifier less than 64 bits for example Privacy Extensions for Stateless Address Autoconfiguration in IPv6 or Semantically opaque interface identifier with SLAAC privacy extension algorithm for stable variable length interface identifier per . In this particular case the prefix will be greater than 64 bits and the stable interface identifier will be less than 64 bits. This draft precludes the use of EUI64 based, 64 bit fixed length interface identifier generation algorithms, and allows the use of any standard variable interface identifier generation algorithm for the auto generating variable length interface identifier greater than 64 bits for example Privacy Extensions for Stateless Address Autoconfiguration in IPv6 or Semantically opaque interface identifier with SLAAC privacy extension algorithm for stable variable length interface identifier per . In this particular case the prefix will be less than 64 bits and the stable interface identifier will be less than 64 bits. Draft rfc4941bis Privacy Extension for SLAAC using Pseudo-Random Number Generator(PRNG) can also be used as a possible method of generating greater then 64 bit or less then 64 bit interface identifier automatically since stated in the draft that the interface identifier can be generated for any arbitrary length. https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/

The RA flag option for variable length interface identifier is designed to allow administrators send variable length prefixes in the PIO list advertisement to the host and hosts supporting this variable interface identifier option would be able to process the flag and use the prefix with variable interface identifier in the PIO list . Administrators MUST only use this variable length interface identifier flag configured on the router to signal processing of the longer prefix if they have longer then 64 bit prefix configured on the router.

Default IPv6 routers that have the variable interface identifier with longer than 64 bit prefixes SHOULD be configured by the administrator to set the variable SLAAC flag to 1. In all other cases the flag SHOULD NOT be set to 1. The intent is that the administrator of the router configures the router to set the variable SLAAC flag if and only if she/he wants to tell the hosts on the link that the prefixes being sent are greater then 64 bits and shorter then the standard 64 bit interface identifier. This is a configuration flag, it is not something that the router decides on its own. Routers MAY log a configuration error if the flag is set and the prefix is not longer the 64 bits and the interface identifier is not shorter then 64 bits. Routers implementing this document SHOULD log to system or network management inconsistent setting of the variable SLAAC flag. This extends the behavior specified in Section 6.2.7 of .

Host operating system support will be backwards compatible so host that do not support the flag will ignore the variable SLAAC flag being set to 1. In that scenario the router supports the variable length prefix option and would be configured with the flag set and would send the variable length prefix to the host, however the host not supporting the flag will not accept the prefix as it is not 64 bit length and as it is unable to process the flag. Hosts that support the variable SLAAC RA flag MUST have a configuration option to ignore or process the flag. The motivation for this configuration option is for hosts that are capable of processing the variable SLAAC flag to only act on the flag if they are configured to do so. If there are multiple IPv6 default routers on a link, they might send different values of the flag. If at least one IPv6 default router sends the flag with value 1, the host supporting the flag will receive will receive and process the flag and accept the PIO list with variable prefixes. If all IPv6 default routers send the flag with value 1 the host will receive and process the prefix and flag from all routers sending the RA.

The administrator should be aware to maintain 64 bit interface identifier for privacy when connected directly to the internet so that entropy for optimal heuristics are maintained for security. Variable length interface identifier shorter then 64 bits should be only used within corporate intranets and private networks where all hosts are trusted. In all cases where the host is on a public network for privacy concerns to avoid traceability variable interface identifier MUST never be utilized.

IANA is requested to assign the new Router Advertisement flag defined in Section 5 of this document. Bit 6 is the next available bit in this registry, IANA is requested to use this bit unless there is a reason to use another bit in this registry. IANA is also requested to register this new flag bit in the IANA IPv6 ND Router Advertisement flags Registry [IANA-RF].

Contributors.

Ole Trøan.

The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. -00: initial version.