Re: SLAAC vs DHCPv6 (II)

[Fernando Gont <[e-mail]>]

On 28/1/20 03:13, Lorenzo Colitti wrote:
> On Tue, Jan 28, 2020 at 2:59 PM Pascal Thubert (pthubert) 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>      > Well, the whole thread entitled "RFC4941bis: consequences of many
>     addresses for the network" seem to be in conflict with RFC7934. --
>     i.e., folks have concerns about nodes configuring an arbitrary
>     number of addresses at will.
> 
> I think we should try to dig deeper into the reasons for this and see if 
> we can come to a compromise on some of them.

My view is that this is out of scope for rfc4941bis (being RFC4941 a 
widely implemented and deployed spec), but the topic certainly deserves 
analysis in a different document.


> 
>   * If the concern is that the host could configure "too many addresses"
>     - This sort of behaviour is not in anyone's interest (either host or
>     network), so I don't think it will happen in practice. There's also
>     an easy way to fix it: just drop the packets past N addresses.

The question is that the host does not know what's "too many". To many, 
in a way, is in the eyes of the operator or network admin, that run the 
network and possibly know what may break if the group of connected hosts 
exceed some number of configured addresses.

COnveying some sort of policy information in SLAAC helps hosts what's 
"too many". Similarly, a DHCPv6 server can "enforce" such policy, based 
on its knowledge of the network.



>   * If the concern is load on the network or tracking, I think we can
>     come up with a reasonable engineering compromise here.

I'm curious what would such compromise be.



>   * If the concern is that the host should use exactly the single
>     address (or low-N number of addresses) that is assigned by the
>     network, then that has the downsides discussed in RFC 7934 and
>     that's a problem.

As noted, I think that when it comes to RFC4941, the cat is out of the 
box, already. Besides, we're talking about a dozen address per host, 
which I guess is the minimum one could expect in the context of RFC7934.

That said, the issue is worth exploring, because it certainly affects 
more agressive approaches such as "one address per application".


> 
>     I agree. I see GRAND as a useful hack for the lack of the real
>     thing. It does not maintain nor tears down a binding. It is lacking
>     essential ingredients like a lifetime. It does not prevent address
>     theft and impersonation.
> 
>     Could this group seriously consider RFC 8505?
> 
> 
> The problem with RFC 8505 is the conflict with the text in RFC 7934 
> section 8 which recommends that networks allow devices to create 
> addresses at will. Requiring use of RFC 8505 by general purpose hosts 
> violates those recommendations.

Creating addresses at will seems, exactly, the concern being expressed 
by operators on this list. I'm not arguing one way or another, but just 
noting that "creating addresses at will" seems to be at odds with what 
the ops people are expressing.

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492