Re: RFC4941bis: consequences of many addresses for the network

[Fernando Gont <[e-mail]>]

On 23/1/20 20:49, Michael Richardson wrote:
[....]
> 
> I also have doubts about whether the rotating temporary address mechanisms
> that 4941 provides is useful privacy when the upper-64 bits are unchanging.
> But, I agree with you, that it is an improvement... except when it causes
> other issues.  So we should consider when and where it's more effort than
> it's worth, and when it has benefit.  That requires information that is
> presently not available to hosts.

As noted by Bob, myself, and others, this is a slaac issue, and not 
something specifically related to 4942bis.

For instance, an ipv6-aware browser might e.g. decide to configure and 
employ different addresses for each tab, or for different apps. And 
you'll end up with way more addresses than those resulting from rfc4941.




> 
> I also think that we need to recognize that we have a number of distinct
> deployment environments, and I think that we should be explicit about them:
> 1) protected home environments
> 2) guest home environments
> 3) enteprise environments
> 4) conference/guest/coffee-shop environments
> 5)  >4< at ridiculous scale
> 6) segregated L2 environments with vertically integrated operators (aka
>     "LTE", Fred's ATN work, possibly RAW).

If you expect hosts to behave nicely with your network, then you should 
probably convey policy information in RAs (as we tried, to some extent, 
in draft-gont-6man-managing-privacy-extensions). At the time, there was 
pushback.

If slaac doesn't convey policy, then nodes do what they assume is in 
their best interest.

And if the network doesn't really like the possible chaos resulting from 
slaac, then it should probably be using dhcpv6.

The nice thing about us doing nothing about the automatic configuration 
mess, is that it typically gets worse: e.g. my CPE sets "M" and "O" in 
RAs, while advertising PIOs for autoconf. So my Ubuntu conf ends up with:
* slaac stable addresses (RFC7217)
* slaac temporary addresses (rfc4941)
* one dhcpv6-leased address


PLease let me reiterate: the problem being discussed in this thread is a 
shortcoming of slaac.

It's certainly fine to add a note along the lines of "hey! don't 
regenerate addresses too frequently (i.e., beware when overriding 
default falues(, or else you might end up screwing the network".

But other than that, 4941bis is not about addressing shortcomings of slaac.

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