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

On Fri, 6 Nov 2020, 08:06 神明達哉, <jinmei@wide.ad.jp> wrote:

> At Thu, 5 Nov 2020 19:15:54 +0100,
> Alexandre Petrescu <alexandre.petrescu@gmail.com> 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).
>

There's also privacy and security implications, as if prefix lengths become
arbitrary, then at a certain length, privacy addreses become ineffective,
and measures to prevent discovery by unsolicited packet probing become
ineffective.

There's also implications to BCP204, host addressing recommendations,
because I expect people will choose prefix lengths to only give each host a
single address, as that is what they're familiar with from IPv4.

64 bits itself isn't magic, it is that it is a default, "plug-and-play"
size that very effectively accommodates all of these other things that
couldn't exist in IPv4.

A provider giving out a single /64, when the provider has at least 4
billion /64s (i.e., min RIR allocation of a /32) is implicitly and strongly
saying they don't want the receiver to be running a routed network.

The IETF shouldn't come up with technical work arounds to operator
policies, when there are already solutions for operators that don't have
those policies (in this specific case, if customers are allowed to run
routed networks, the operator can provide multiple /64s via PD).

Regards,
Mark.

> That's what I tried to point out.
>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>