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

[David Farmer <[e-mail]>]

On Thu, Jun 8, 2017 at 7:10 AM, <[e-mail]> wrote:

> >
> > "Interface Identifiers should be 64 bit long except
> > when the addresses are manually configured,
> >
> > In order to publish that text we need to agree on what it means. Can you
> explain the semantics of the the interface identifier of a manually
> configured IPv6 address? What are they used for?
> >
> > Note: the semantics are *not* the same as the prefix length of an IPv4
> address. The prefix length of an IPv4 address implies that that subnet is
> reachable on, but the IID implies nothing about reachability.
>
> I'm not sure I understand your point.
>
> RFC4291:
>
>    IPv6 nodes may have considerable or little knowledge of the internal
>    structure of the IPv6 address, depending on the role the node plays
>    (for instance, host versus router).  At a minimum, a node may
>    consider that unicast addresses (including its own) have no internal
>    structure:
>
>    |                           128 bits                              |
>    +-----------------------------------------------------------------+
>    |                          node address                           |
>    +-----------------------------------------------------------------+
>
>    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.

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.

The IID is only used to generate an address, once the address has been
generated the IID and its length are actually irrelevant, the address
itself is 128 bits long, and only the on-link prefix and length is relevant
in determining locality.

So, I think if we stop using subnet prefix vocabulary with IPv6, we might
find consensus and resolve this conflict.

Thanks

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================