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

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

At Sat, 10 Jun 2017 15:34:30 -0500,
David Farmer <[e-mail]> wrote:

> >    A slightly sophisticated host (but still rather simple) may
> >    additionally be aware of subnet prefix(es) for the link(s) it is
> >    attached to, where different addresses may have different values for
> >    n:
> >
> >    |          n bits               |           128-n bits            |
> >    +-------------------------------+---------------------------------+
> >    |       subnet prefix           |           interface ID          |
> >    +-------------------------------+---------------------------------+
> >
>
> To be truly honest I've never found that description helpful, in fact I
> think it is part of the problem. It confuses classic IPv4 subnet
> prefix(mask) terminology with IIDs and on-link prefixes for IPv6, which are
> subtly different.  In my opinion, the IPv4 subnet prefix is not used in the
> generation of the IPv4 address per se, it is really only used to determine
> locality, in this way it is similar to an IPv6 on-link prefix, and has
> little to do with the IID length.
> However, the above quote by using subnet prefix terminology, ties the
> subnet prefix length and IID length directly together, also seeming to
> indicate that IIDs and on-link prefixes have to be congruent, but the IID
> and on-link prefix can be incongruent and therefore again using subnet
> prefix terminology really confuses the situation and I think this is the
> root of this conflict. Therefore when we say the IID is 64, the above seems
> says the subnet prefix is /64 and therefore the on-link prefix is also /64,
> but this is not suppose to be the case.

Agreed.

> I've been thinking about this for a while and I think the only way to
> resolve this conflict is to stop using "subnet prefix" in reference to IPv6
> and only use it in reference to IPv4.  I would propose substituting
> "addressing prefix" for "subnet prefix" in the above quotation from RFC4291
> and add a separate discussion of on-link prefixes and then note the classic
> IPv4 subnet prefix length is equivalent to the on-link prefix length in
> IPv6.  If this is done then the statement that the IID length MUST be 64
> says nothing about the on-link prefix length.

Also agreed.  The term "subnet prefix" in RFC4291 and rfc4291bis is so
confusing that we've been having unnecessary controversy.  Although
I'm still not 100% sure about the real goal of
draft-bourbaki-6man-classless-ipv6-00, one thing we could do for
rfc4291bis is to resolve this terminology confusion either by changing
the term and/or by adding more explanation.  IMO this can be done without
changing the addressing architecture itself (so it's within the scope
of rfc4291bis), and I believe it can be accepted by most of us,
whether they prefer "operational needs" or "conceptual purity".

Whether we should keep fixing the IID length for 7/8-ish of unicast
addresses at 64 bits or keep letting link-layer docs specify that
value is an interesting discussion.  But that can and actually should
be done separately and probably be better deferred until we complete
rfc4291bis, since there will be real controversy in that discussion.

--
JINMEI, Tatuya