Re: <draft-ietf-6man-rfc4291bis-09.txt>

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

At Mon, 17 Jul 2017 16:42:23 -0500,
David Farmer <[e-mail]> wrote:

> So, I would propose the following for RFC4291bis;
>
> Several components of IPv6 are architecturally based on a requirement that
> Interface Identifiers are 64 bit long except if the first three bits of the
> address are 000. The rationale for using 64 bit Interface Identifiers can
> be found in [RFC7421]. However, other components of IPv6 are
> architecturally based
> on Interface Identifiers of any length, most importantly Neighbor Discovery
> [RFC4861]. Neither of these two architectures override or invalidate the
> other. Accordingly, 64 bit Interface Identifiers are recommended for
> operational use.

I don't see how RFC4861 is related to IID.  This seems to be based on
the common confusion on the difference between on-link prefixes and
address assignment prefixes (RFC4861 refers to "interface identifier"
only in a handful of phrases, none of which seems to be relevant to
this topic).  But I guess you are one of the few people who actually
understand this point quite well, so this is probably an editorial
problem.  Maybe you're trying to answer the question like the one
Brian asked: "if we manually configure an IPv6 address and gets an RA
PIO with L=1 and A=0 whose and the prefix length being 80 bits that
(happens to) match the configured address, then what would we call the
rightmost 48 bits of the address?  Is it the 'interface identifier'"?
I agree that's a valid question, but it's too subtle to explain by
such a brief explanation like the above one.  It's really subtle and
if we want to answer the question in rfc4291bis, much verbose text
will be necessary.

But, even if we address this point, I don't see any possibility in
making "64" a mere "recommendation" in the context rfc4291bis.  Let's
be realistic - it simply won't be accepted by one of the "camp"s that
want to keep the current requirement on this point as much as
possible.

If the proposal only clarifies the question like the above one without
trying to tweak the most contentious points, that may make sense and
as a fan of clarity I might actually support it.  But as I said above
it will result in much more verbose text and it will have its own
drawback - for example I thought Bob didn't want to talk about too
much on how to generate addresses or refer to other specs that do not
directly related to the addressing architecture (ND, SLAAC, DHCPv6
etc).

So, to me, the time for tweaking the text is over.  IMO we should now
just see if we can form a rough consensus on some basic point (e.g.,
explicitly excluding the manually configured addresses for the 64-bit
requirement) and move on or drop the effort.  The result will still
leave questions (such as the above one) and contain some awkward
content (like the listed exceptions in the architecture), and I'd be
sad about that, but that's probably an inconvenient truth when what's
needed to make progress is compromise rather than technical purity.

--
JINMEI, Tatuya