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.