RE: draft-bourbaki-6man-classless-ipv6-00

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter

> It's hard to track this conversation, but anyway IMHO 2464bis
> should specify /64 as if the addressing architecture didn't
> even mention it. It has to specify something for SLAAC to work,
> and we have 20 years of deployed code based on /64. So we don't
> have the luxury of changing it, even if we want to.

But it can be changed, in a graceful manner. As you said in another post, the reason/excuse for the 64-bit IID length in RFC 2464 no longer applies. So here's what RFC 2464-bis could say:

Each (updated) host must be capable of creating IIDs of variable lengths, from 64 bits to 1 bit. The 64-bit IID is formed as it is now. To shorten the IID, e.g. as required for SLAAC or other protocols, the host can use a number of techniques. One such might be, truncate the upper bits first, until 16 bits have been truncated, then truncate the upper bit and the lower bit, alternating between one and the other, until the needed IID length is reached.

That's pretty much it for RFC 2464-bis.

Then for RFC 4862, which would need essentially no change. Routers should continue to advertise 64-bit prefix lengths, for legacy hosts that can only support 64-bit IIDs. Routers may also advertise prefixes longer than 64 bits, for use by updated hosts.

A host creates its 128-bit interface address using the prefix length specified in the RA, then appending the appropriate length IID, where the length of the IID is 128-prefix length.

I don't think we should need to state flat out that SLAAC can only work with 64-bit IIDs, nor that Ethernet interfaces can only be identified by 64-bit IIDs. This need not be the case, with RFC 2464-bis (which I think is needed regardless).

Bert