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

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

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of [Tatuya Jinmei]

> If the address is manually configured or configured using
> DHCPv6 with some "prefix", that prefix is actually an on-link
> prefix and has nothing to do with IID.  The IID length would
> still be defined by the link-type specification, and since that
> should be consistent with the addressing architecture, it *must*
> be 64 bits in practice.

Some of us are saying that the above need not be the case. It is simple enough to create RFC 2464-bis, where this old notion is discarded, and where hosts with Ethernet (or other interfaces too, for that matter) can generate IID lengths that can vary from 64 bits (or actually even 128 bits) to 1 or to 0 bits, if need be. They can do so in real time, in response to the prefix length received in a RA. (We can argue about what algorithm makes sense to create these other IID lengths. Doesn't seem very difficult.) And because the rationale used for 64-bit IIDs, in RFC 2464, is no longer believed to be good, that says a -bis version is warranted.

Said another way, the premise upon which RFC 2464 is written is no longer valid. Therefore, what derived from this premise needs to be re-evaluated. SLAAC should not be used as a reason for fixed length IIDs, much less a 64-bit boundary, in this draft.

So, even before an RFC 2464-bis is written, the language that states that 64-bit IIDs are "mandatory" can be softened. It just does not sound credible or defensible these days.

Bert