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

[Alexandre Petrescu <[e-mail]>]

Le 05/11/2020 à 22:49, Mark Smith a écrit :
> 
> 
> On Fri, 6 Nov 2020, 08:06 神明達哉, <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     At Thu, 5 Nov 2020 19:15:54 +0100,
>     Alexandre Petrescu <[e-mail]
>     <mailto:[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).
> 
> 
> 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).

MArk,

There are operators and operators.  And, within operators, we use a 
generic term 'operator' to mean many things.  But there are humans and 
computers at our each mention of 'operator'.  We should not 
misunderstand each other at IETF.

Operators depend on hardware manufacturers.

At this time, the conclusion of all these dependencies, is that it's not 
possible to do a /56 for a smartphone.

Some people and some computers and some policies at some operators do 
not mind if an IETF solution does 65+63 on the Ethernet or WiFi 
interface.  They dont mind that any more than doing 64share or NAT for 
IPv4.  Doing 65+63 on the WiFi interface of a smartphone might even be 
seen as an advantage, by certain people on some computers at some 
operators with some policies.

This 65+63 is not a workaround operators interests.

Alex

> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
> 
>     That's what I tried to point out.
> 
>     --
>     JINMEI, Tatuya
> 
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>