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

[神明達哉 <[e-mail]>]

At Mon, 12 Jun 2017 18:41:21 +0000,
"Manfredi, Albert E" <[e-mail]> wrote:

> > 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.

I know.  I just pointed out that it would be an update to the current
spec, and that when someone sas something like that, that person
should be clearer whether it's a proposal of an update or explanation
of the current spec:

>> I'm afraid this is not really a correct description of the current
>> specification (if you're actually proposing to change the current
>> specifications on this, it would be more helpful if you could
>> clarify it's a proposal, not an explanation of the current spec).
>> It's subtle, but I suspect this subtlety is part of the controversy
>> we've seen that should actually be unnecessary to have.

I have no problem with having a discussion on update proposals like
below.  Of course, however, I may or may not agree on specific
proposals, depending their details.  I'm also not so optimistic about
how "simple" it is.  I'd expect a lot of controversy and long
discussions.

> 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.

And, ...

> 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.

... perhaps, but it's still an update to the current specification.
Unless and until we have an update RFC I doubt we can say the softened
behavior is part of the formal protocol specification.  That is,
developers will still refer to RFC2464, RFC4862, RFC4291 (or its bis
if published), and I don't think we can blame if they use a fixed
64-bit IID length for an ethernet interface, even if they use it for
RFC7217.

--
JINMEI, Tatuya