Nick Hilliard
2017-07-12 17:10:30 UTC
We've seen how hard it is to wordsmith the exceptions.
Brian,the whole idea of exceptions may have hit the nail on the head.
We've spent weeks discussing hard-coding or not hardcoding /64 to no
avail, but the issue may not be as important to 4291bis as it may seem.
The reason why is that in practice, the interface ID length depends on
how the interface is configured: no-one is disputing that you can
configure a static IP address with a non-/64 prefix length. This
implies by necessity that the number 64 as an IID length is not an
intrinsic part of ipv6 addressing per-se, but a statement of defaults.
If you split interface addressing down into the different protocols
used, they are:
1. link-local: IID length defined as /64 in rfc4291, section 2.5.6
2. SLAAC: IID length defined in rfc4862
3. DHCP: dependent on SLAAC
4. static addressing: consensus this is variable
5. others (e.g. PPP defines its interface mask length in rfc5072; does
AERO define interface adddressing? Any others?)
6. future protocols
There's consensus on IID length for #1 and #4. #3 depends on #2 (dhcpv6
pulls the netmask from slaac, but if addressing is not handled in slaac,
it uses /128). Other cases (#5) seem to be defined in the individual
rfcs which describe them.
This means that the only substantive issues are SLAAC and whether future
protocols should be /64 by default or whether the prefix length needs to
be explicitly defined in the document which defines it. All the other
cases state the IID length explicitly in the documents which describe
them, with the exception of static addressing, about which there isn't
really any argument to start with.
I would suggest that future protocols need to define what makes sense
for them, and mandating a constant in advance isn't necessary or even
appropriate.
Regarding SLAAC, if there needs to be a definition that its IID size is
hard-coded at /64, then this is a discussion for 4862bis, not 4291bis.
So outside SLAAC, we're left in a situation where either there is
consensus or explicit definition in the individual protocol definitions.
Given this, I'd like to suggest that we drop the sentence from 4291bis
completely and devolve the specification for IID length down to the
individual protocols where it belongs. This may mean updating rfc4862.
Nick