SLAAC Prefixes with Variable Interface ID (IID)
Gyan Mishra
Verizon Inc.
gyan.s.mishra@verizon.com
Dmytro Shytyi
6WIND
Paris
France
dmytro@shytyi.net
Alexandre Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette
Ile-de-France
91190
France
+33169089223
Alexandre.Petrescu@cea.fr
Naveen Kottapalli
Ciena
300 Concord Road
Billerica
MA 01821
United States of America
+1 978 223 4700
nkottapalli@benu.net
Dusan Mudric
Ciena
Canada
+1-613-670-2425
dmudric@ciena.com
2024
Internet
6MAN Working Group
keywords
This draft proposes the use of a longer prefixes in PIO for SLAAC allowing a maximum prefix length of /80 with an IID of 48 bits. This would eliminate the race to the bottom concerns.
This implementation uses the RA/PIO bits to carry the variable IID to ensure backwards compatibility.
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.

Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Introduction
The Variable IID problem statement document [I-D.mishra-v6ops-variable-iids-problem-statement] goes into detail surrounding the problem we are trying to solve with this document. There are many reasons that have come up as to why the fixed boundary must be changed and the two leading issues are firstly parity between addressing mechanisms SLAAC, DHCPv6 and Static, Thus the only solution is variable IID. It is recommended to read the problem statement document before this solutions space document.
The lowest common denominator method of configuration for IPv6 nodes is SLAAC [RFC4862], which is carefully designed to allow any prefix length and any interface identifier (IID) length, provided that they do not total more than 128 bits. Until now, specifications of "IPv6 over foo" mappings, starting with [RFC2464], have specified an IID length of 64 bits, consistent with the value specified by [RFC4291].
This document allows a router to announce an IID length other than 64 on a given link, and updates RFC [RFC4291], [RFC2464] (and numerous other "IPv6 over foo" documents TBD), and [RFC4862] accordingly. It extends [RFC4861] by defining a new "IID length" mechanism in RA messages.
This document proposes longer prefixes in PIO for SLAAC allowing a maximum prefix lenght of /80 and an IID for 48 bits. The recommendation would eliminate the race to the bottom. The implementaion for backwards compatibility leverages the use of 6 LSB bits of the 32 bit Reserved2 field in the PIO options header which today per RFC 4861 is initialized to 0 and is ignored by the receiver. Since the PIO Reserved2 field is initialized to 0 by the sender and is ignored by the receiver, it allows for backwards compatibility for Unmodified hosts.

Terminology
Terminolgoy used in defining the IPv6-Only Edge specification.
Modified Host: Supports this specification
Unmodified Host: Does not support this specification

Modified Procedures for Network side signaling
The use case here is for Mobile Broadband (MBB) and Fixed Broadband (FBB) conected to the internet being signaled from the network to host the variable IID Length Reserved2 field.
The predefined IID length specified by [RFC4291], [RFC2464], etc. is used to configure the link-local IPv6 address of a node exactly as described in [RFC4862].
On a link where variable IID length is not supported, the predefined IID length will continue to be used to configure all other addresses using SLAAC.
On a link where variable IID length is supported, each modified router will include an "IID length" indication in every RA/PIO message with the A bit set. This will override the value defined in [RFC2464] (etc.) and in [RFC4291], for the prefix concerned.
In this variable IID specification it is recommended to put the IID length in the 6 LSB bits of the 32 Reserved2 field of the PIO for signaling to Modified hosts supporting variable IID that the prefix being advertised is not 64 bits.
00000000 would mean 64, i.e. no change and backwards compatible. Any other value would define an IID length in bits. Values less than 48 (00110000) are NOT RECOMMENDED. Values greater than 64 are impossible.
Exmaple of valid IID Length value: "00111011" /69 with 59 bit IID
(Note: Reserved1 is not available - see [RFC8425].)
When a modified node receives an "IID length" less than 64, it will use that value instead of the default for all unicast address autoconfiguration under that prefix, except link-local.

Modified procedure for host side signaling
The main use case here is for Data Center for Service Provider or Enterprise networks host compute CNF, VNF, PNF. Host side siganls to the network the Varriable IID Reserved2 field and the network accomodates the variable IID. This could be a Devops model case where the server team is network aware server compute side use case to initiate the signaling.
The predefined IID length specified by [RFC4291], [RFC2464], etc. is used to configure the link-local IPv6 address of a node exactly as described in [RFC4862].
On a link where variable IID length is not supported, the predefined IID length will continue to be used to configure all other addresses using SLAAC.
On a link where variable IID length is supported, each modified router will include an "IID length" indication in every RA/PIO message with the A bit set. This will override the value defined in [RFC2464] (etc.) and in [RFC4291], for the prefix concerned.
In this variable IID specification it is recommended to put the IID length in the 6 LSB bits of the 32 Reserved2 field of the PIO for signaling to Modified hosts supporting variable IID that the prefix being advertised is not 64 bits.
00000000 would mean 64, i.e. no change and backwards compatible. Any other value would define an IID length in bits. Values less than 48 (00110000) are NOT RECOMMENDED. Values greater than 64 are impossible.
Exmaple of valid IID Length value: "00111011" /69 with 59 bit IID
(Note: Reserved1 is not available - see [RFC8425].)
When a modified node receives an "IID length" less than 64, it will use that value instead of the default for all unicast address autoconfiguration under that prefix, except link-local.

Host side use of sysctl tool local configuration
The main use case here is for Data Center for Service Provider or Enterprise networks host compute CNF, VNF, PNF. Host side siganls to the network the Varriable IID Reserved2 field and the network accomodates the variable IID. This could be a Devops model case where the server team is network aware server compute side use case to initiate the signaling.
With this solution we are able to use the Linux kernel sysctl bit for backwards compatibility. This solution would allow for modified and unmodified hosts to exist on the same subnet and no issues with breaking anything that is already working by default.
Users Equipment to have a possibility to manually enable (button, cli, etc.) to signal in RS via option(bit) that it wishes/capable to activate the Variable IIDs service, otherwise it is off by default (like hotspot button in Smartphones).
It might be used as a _manual-client-side-only-activation_ of the feature that is transparent for operator configuration side (no need of manual service activation by provider via cli/button).
In other words client-side activates with a button the action to send the RS with a variable-IIDs specific bit, Where server side, when receives RS with a Variable-IID bit -> replies with unicast RA with Variable-IID.
The sysctl is a tool that helps to implement the client-manual-activation behavior in Linux environment. As well as it might be for UNIX-like systems, or similar. I Windows, MAC, iOS and Android and any other OS would have to come up with a similar to sysctl tool to activate the behavior. Android uses a modified linux kernel. Mac uses XNU kerenl and does have syctl tool. Windows is the only gap that wo

Operational Considerations
- Unmodified hosts and unmodified routers: no change, all use 64-bit IIDs.
- Modified hosts and unmodified routers: no change, all use 64-bit IIDs.
- Modified routers and unmodified hosts: no change, all use 64-bit IIDs.
- Modified hosts and modified routers: configure to use longer prefixes and shorter IIDs if desired.
- Modified routers and mixture of modified and unmodified hosts on a link:
  Modified:
    - The modified hosts will use a shorter IID and longer prefix if that is announced.
- The unmodified hosts, according to RFC 4861, MUST ignore the Reserved1 field. So, according to section 5.5.3 clause d) of RFC 4862, they will ignore any PIO advertising a shorter IID.
  Unmodified:
    - Therefore, operators have two choices for Unmodified hosts:
    - 1. Decide that unmodified hosts will not be supported (i.e. will not be able to configure an address using SLAAC).
    - 2. Announce (at least) two prefixes on the link - a /64 and a longer one, with a shorter IID. For that to make sense, we need an extra rule for modified hosts: if a host receives several PIOs from the same router, it prefers all those with the shortest IID and ignores the others.
Mixure of Modifiled and Unmodified hosts router on a link is not recommmended.

Security Considerations
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 than 64 bits should be used within networks where there there are out-of-band guarantees that the hosts are trusted (e.g. corporate intranets and private networks).

IANA Considerations
IANA Request for RA PIO registry for RESERVE2

Contributors
Brian Carpenter.

Acknowledgements

Normative References

Informative References
[I-D.mishra-v6ops-variable-iids-problem-statement]
[RFC4862]
[RFC2464]
[RFC4291]
[RFC4861]
[RFC8425]