Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

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

At Fri, 18 Aug 2017 10:16:52 +0900,
Lorenzo Colitti <[e-mail]> wrote:

> > This is not correct.  SLAAC implementations faithful to the spec
> > should leave the IID length (and therefore its prefix length) open to
> > the underlying link-type specification (such as RFC2464).  It's not
> > open to be configurable/settable by the admin.
>
> Actually, even more than that. For everything except ::/3 (which it is
> unlikely that any implementation will encounter), IIDs are 64 bits long
> because of RFC 4291.

I knew that, and I actually considered to note that, too.  But I chose
the most straightforward explanation to point out that the prefix/IID
len is NOT "open to be configurable/settable by the admin" according
to the protocol specification, in order to avoid unnecessary
distraction.

> Personally, I think this is why there is such a lack of consensus on
> 4291bis. The lack of consensus is about the future, not the
> present.Currently, any new link layer that is defined has to either use
> 64-bit IIDs or update 4291. And any new address assignment mechanism that
> is based on IIDs has to use 64-bit IIDs. If we change 4291bis to allow
> non-64-bit IIDs, that all goes out of the window.

I agree that it's one major source of confusion that both addrarch and
link-type specs define the IID length (and the former defines it per
address space basis and the latter defines it for a particular link
type, and therefore these two could easily be inconsistent).  Although
I don't know if that's why we don't have consensus for 4291bis.

Anyway, isn't this thread about draft-ietf-v6ops-unique-ipv6-prefix-per-host-07?
I'm not sure why we are talking about our favorite topic of 64-bit (or
not) IIDs here:-)  This thread is even more inappropriate for that
topic than 4291bis (even where it's out of scope as it's not feasible
to change that as part of promoting it to IS).  People who want to
discuss the endless IID length debate should really aware of the scope
of the topic.

--
JINMEI, Tatuya