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

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

At Mon, 12 Jun 2017 13:17:42 -0700,
Fred Baker <[e-mail]> wrote:

> > 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.
>
> There I disagree, and if I were making a proposal, and if the link
> layer address were to be relevant to it, my proposal would be that
> the IID be the link layer address. In an 802.3 or 802.11 network,
> that is a 48 bit value, in an 802.15.4 network it is 64 bits, and I
> imagine there are other networks with still other link layer address
> formats. The only reason to specify a universal IID length is for a
> universal algorithm that has a specific requirement. The only one I
> know of is SLAAC.

I'm not sure on which point you disagree with me, but what I tried to
say is that it's a logical consequence of the current specification
(not my opinion on how we should design it).

- For SLAAC, RFC4862 assumes that the IID length is defined in a
  link-type doc and it's consistent with the addressing architecture
- The current addressing architecture spec (indirectly) says that IID
  length is 64-bit for all unicast addresses except those starting
  with binary 000 (i.e., for all global unicast addresses used in
  production in practice).

There is no possibility than a 64-bit IID that meet these conditions.
I understand some people think that it has never made sense or at
least it doesn't make sense today anymore.  I have no problem with
having a discussion on updating the current specifications from that
view.  But it's still an update to the current specification.  We can
disagree on what current specs say and update it if we reach consensus
as such, but we cannot change the fact that the current specs have
said it.

Or perhaps you meant when we consider addresses configured manually or
using DHCPv6, the first point is not applicable and the IID
length doesn't have to be defined by the link-type spec?  If so, I see
the point, but in that case we should more emphasize that IID or its
length doesn't matter, IMO.  Only on-link prefixes and the full
128-bit IPv6 addresses matter for actual host behavior, and they are
irrelevant to the concept of IID.  We could still say the IID in this
case is the right-most bits of the address following the on-link
prefix (whose length can be different from 64 bits), but I don't see a
point in that artificial definition.

--
JINMEI, Tatuya