Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt

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

At Thu, 5 Nov 2020 19:15:54 +0100,
Alexandre Petrescu <[e-mail]> wrote:

> >> First off SLACC works just fine with any size prefix/interface ID.
> >> The protocol supports different sized prefixes/IIDs.   The
> >> purported issue relates to interface ID sizes.   These drafts
> >> appear to be confused about that.
> >
> > +1.  Even the draft title has the confusion: "SLAAC with prefixes of
> > arbitrary length in PIO (Variable SLAAC) - A Problem Statement". The
> > SLAAC protocol itself as defined in RFC4862 already works with an
> > arbitrary prefix length.
>
> I think it is an indirect SLAAC-GUA problem.  The IID len problem taints
> SLAAC.
>
> Yes, SLAAC spec works with 65bit plens.
>
> No, IIDs defined in IPv6-over-foo are not used anywhere else than in
> SLAAC.  SLAAC is the only protocol that uses the IIDs defined in
> IPv6-over-foo.

For IPv6-over-foo, that's correct.  For example, RFC2464 Section 4
specifically states it's for SLAAC.  But that's only a part of the
whole picture; IPv6-over-foo and addr arch (RFC4291) must be
consistent, and the latter is not specific to SLAAC.  In fact, if the
spec for IID length in the addr arch were also only about SLAAC, I
suspect the Bourbaki author(s) wouldn't care too much about it.

The authors of draft-mishra-v6ops-variable-slaac-problem-stmt might
only be interested in SLAAC related use cases, but we can't pretend
it's an SLAAC specific problem (and provide a tweak to SLAAC as a
"solution") without resolving the implication on the addr arch (and
on manually configured addresses, etc).

That's what I tried to point out.

--
JINMEI, Tatuya