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 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 details the 64-bit boundary problem statement.

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. 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 an efficient use of address space.

This section details the problem statement as to what is broken today with fixed length Stateless Address Autoconfiguration SLAAC and why it is critical to resolve this problem. The main problem is that SLAAC RA or PD allocates a /64 by the wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however segmentation of the /64 via SLAAC is required so that downstream interfaces can be further sub-netted. The use case section of this draft discusses this scenario as one of the use cases for shorter interface identifier, and this use case is the only one stated here in the problem statement as this is broken today with the current SLAAC specification , and there is not any workaround for this use case. There are two reasons why this was not a problem in the past, but now with increased bandwidth there are more and more devices being piled onto a single handset or mobile hotspot. In the past generations of cellular systems (e.g. 2.5G aka GPRS and some 3G) the bandwidth available to the User Equipment was not enough to accommodate several applications; bandwidth available was roughly 256Kbit/s. For that reason, users were rarely tempted to use an UE to link other devices than that UE to the Internet. However, with the arrival of 3G, 3G+ (e.g. HSDPA / HSUPA), and even more so with 4G and 4G+, the bandwidth made available to UE increased significantly; this became an average effective of 1Mbit/s and even more. With this available bandwidth, the users are more and more tempted to connect several devices to the Internet. This operation is named 'connection sharing' or 'tethering'. Another answer to this question is that IPv6 technology that is widely used to 'tether' several IP devices to a smartphone is '64share' RFC7278. This technology is used for smartphones but is not so in vehicles. One of the reasons of not being used in vehicles is the lack of scalability: a /64 prefix is shared between the UE ptp link and the subnet (typically Wi-Fi), but can not be further sub-netted to other subnets in the car. The reason why all devices in a car cannot remain on a single /64 are as follows. These devices have different link-layer technologies, and not all WiFi could be bridged into Ethernet such as to keep all devices into one /64. They could be on links that are not bridgeable: devices on 802.11-OCB cannott be bridged, devices on Bluetooth cannott be bridged, devices on 3GPP cannott be bridged, and so one. Other than the impossibility to bridge several such link-layer technologies there is also a problem of noise: in a vehicle one wants the braking pedal signal to not be disturbed by entertainment sites such as YouTube. That physical technical requirement separation of different link layer technologies segmentation on to different smaller IPv6 subnets cannot be achieved if all devices are on a single /64, or bridged. Therefore, the only possible solution to connect these disparate devices onto a 3GPP network for internet access is to keep these separate link layer technologies segmented onto separate greater then /64 prefix subnets and breaking the /64 boundary that exists today with a Variable SLAAC solution. Thus, when the 3GPP network gives a /64 to the car, and when there are unbridgeable technologies in the car (e.g. WiFi cant be bridged to Bluetooth), then the only possibility is to divide that /64 into two /65s. One /65 would be used on the WiFi and another /65 would be used on Bluetooth. But in order for SLAAC to work with /65 then there is a need to have the shorter interface identifier of length 63. Hence the need of lengths of PIOs other than 64 (variable plen). There are three scenarios that require SLAAC to be able to be routed between two greater then /64 prefix segments as part of the requirement for variable length SLAAC and what is broken with the current SLAAC specification defined in . The first scenario is within a car using car manufacturer single SIM for internet access and being able to bridge(Route) other link layer devices like BT via variable slaac. In this scenario the communication between downstream devices are all located within the car using the car manufacturer built in SIM card for in-vehicle communication. The in-vehicle scenario covers both the built-in car manufacturer SIM card scenario, or if the car manufacturer does not support built-in SIM card then a single mobile handset providing 3GPP internet access to all devices in the car. The second scenario is V2V (vehicle to vehicle) between cars requiring SLAAC to subnet the >64 prefix so that the two cars have WiFi connectivity. This third scenario is a uCPE(Universal Customer Premises Equipment) device is LTE 4G and Wi-Fi capable, and utilizes NFV (Network Function Virtualization) framework, providing SFC (Service Function Chaining), where one VNF (Virtual Network Function) is a CPE Layer 3 router and is the uCPE device which will receive a /64 prefix from 4G 3GPP Wireless provider and would like to be able to provide further segmentation. In order to provide further segmentation and subdivide the /64 into smaller longer prefix subnets variable SLAAC must be employed. In this example we would give 1st /66 to Wi-Fi users, 2nd /66 to Wired connected network device without security, 3rd /66 prefix to VNF firewall instance, and 4th /66 prefix VNF load balancer instance. The uCPE (Universal Customer Premises Equipment) defined in draft . From a segmented bandwidth perspective while breaking up the /64 subnet into smaller subnets, there is not any impact to the user experience of the now shared bandwidth, as long as the cellular signal has adequate enough bars as far as signal strength to accommodate the now multiple devices sharing the single cellular signal. These scenarios described above are the problems that can only be solved with a variable SLAAC solution. There is no other solution or workaround for this problem.

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, which appears at the edge of the network. The permission is 'granted' for end users situated at the edge of the network, and is 'granted' by advertising a prefix of length 64 inside the PIO option in a RA typically. 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 the device 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 cannot 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 accessible 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 Wi-Fi 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 Babel 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 IP-OBU in the vehicle receives a /64 prefix from the cellular network (or from a IP-RSU - Road-Side Unit). This /64 prefix can be used to form one address for the egress interface of the Mobile Router (MR, which is also termed 'IP-OBU', for IP On-Board Unit, in IPWAVE WG documents such as RFC8691), but can not be used to form IP addresses for other hosts in the vehicle. In the following two paragraphs we explain this problem. In certain 3GPP V2I networking use cases a /56 is allocated by the 3GPP infrastructure to the 4G modem of the IP-OBU in the vehicle. In such use case it is possible that the IP-OBU sub-divides the allocated /56 into multiple 'result' /64 prefixes. Such a 'result' /64 prefix could be used to form addresses for deeper subnets in the vehicle, by employing existing SLAAC and existing IPv6-over-foo specifications of Interface ID. If in other 3GPP V2I networking use-cases the infrastructure does not allocate a /56 (or 'longer' prefix lengths such as a /57, /58../63) to the IP-OBU, i.e. a /64 is allocated to the IP-OBU, then the 'result' prefix obtained after a sub-divide operation can only be of length /65, or /66, or longer. A prefix of such length (longer than 64) can not be used with SLAAC and existing IP-over-foo Interface Identifiers, because the length of all Interface Identifiers in all IPv6-over-foo documents must always be 64, and the length of the IPv6 is always 128bit. The 64bit of an IID added to the 65bit (or more) of a prefix is larger than 128bit. It is for this reason that a SLAAC with other than 64bit Interface IDs (hence a 'Variable Prefix Length SLAAC') is needed. The problem of /64 allocation to the vehicle is mostly present in V2I use-cases. In V2V use-cases this problem is less apparent but deserves consideration. Until now there was no clearcut design and decision about the infrastructure allocating addresses to several vehicles (just to one, in V2I, see above). In some use-cases, the prefix allocated to one vehicle could be further extended by that vehicle to delegate prefixes to other vehicles nearby which might not have 3GPP connections, but only 802.11-OCB interfaces. In such cases it is again necessary that a /64 allocated by the infrastructure to the first vehicle be further sub-divided in multiple 'result' longer-than-/64 prefixes; and one of these longer-than-64 prefixes might be used for the second vehicle (instead of being used for the internal subnets of the first vehicle); this latter vehicle will need to use a form of SLAAC and IP-over-foo that are not limited by the /64 limit.

Smart traffic lights are traffic lights equipped with a communication system. Smart traffic lights are deployed at intersections of roads and serve the purpose of safely arbitrating the passage of automobiles, pedestrians and cyclists. A typical smart traffic lights setting is made of several computers, included but not limited to: a traffic lights controller, a power controller and a communication gateway. More advanced smart traffic lights are equipped with more computers for radars, detection loops, lidars, V2X wireless capabilities, Wi-Fi, Bluetooth and cellular 4G or 5G. All these computers need to use IP addresses: at least one IP address per computer. Since smart traffic lights are deployed in areas where Internet might not be available by cable, fibre or other Wireless MAN technology the only way to connect all computers in the smart traffic lights setting is to employ a 4G (or 5G) gateway. This gateway obtains typically a /64 prefix from the network operator; there is a problem in subdividing that /64 prefix into smaller prefixes, because the obtained prefixes can not be used by SLAAC, because SLAAC uses Interface IDs of length 64 in practice. Even if the SLAAC specification is independent of the prefix length, the length of the Interface ID dictates the prefix length by side effect (128 minus IID length imposes the prefix length). SLAAC might work with a plen 65 by specification, but all IIDs in all IPv6-over-foo request that IIDs be 64; and the sum of IID len plus plen must be 128.

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.

When one wants to extend the network, one typically wants to add new computers to it. Currently, there are two ways to achieve it: (1) ask the network administrator to provide addresses while also inserting a route towards the new subnet of devices and (2) use NAT. With IPv6, NAT is not desirable. In order to extend the network without asking for permission one needs to obtain addresses and to obtain that route inserted. In order to obtain addresses, one might take advantage of the /64 prefix typically advertised by the network to an edge of it. To do that, one needs to sub-divide the /64 prefix into /65 sub-prefixes (or longer, such as /66, /67, etc.) which could be further advertised in the extension of the network. For the action of inserting a route, the particular topic is outside the scope of this document.

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.