Hi,
<snip>
I'm not thinking of today but the future. And yes, another
argument would be that there isn't enough address space for this to be
effectively private. Those are two different issues, but fixing the
boundary here reminds me of mistakes we made with IPv4 way back when.
In this day and age we're talking about a lot more cleanup later.
I guess this raises a more fundamental question with respect to whether
we want 64-bit identifiers to be the standard, or not.
A compromise might be to add a *parenthetical* note such as:
"The current IPv6 Addressing architecture defines Interface-Identifiers
to be 64 bits long, hence the low-order 64-bits of F() are employed for
the Interface-ID. Were the IPv6 Addressing Architecture updated to allow
any arbitrary length for the Interface ID, an implementation would need
to be prepared to select as many bits from F() (rather than the fixed
64-bits specified above) for the Interface ID, such that an Interface ID
of appropriate length is obtained"
I'd personally have no issues with that *if* the wg agrees. But I
wouldn't want to remove the text on grabbing the low-order 64-bits,
since that's makes the spec more clear for the current times.
While this part of RFC4291 should make the 64 bit statements safe:
"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."
The /127 prefix length RFC changed that, so I'd suggest it might be safer to
generalise and say take the number of bits from the hash that correspond to the
IID length in use, and then reference 64 bit IIDs as an example.
Regards,
Mark.