Re: Disabling temporary addresses by default?

[Fernando Gont <[e-mail]>]

On 28/1/20 18:35, Bob Hinden wrote:
[....]
> 
>> Instead of disabling, why not change the default of the number of addresses maintained? For example, instead of maintaining 1 permanent + 1 valid + 7 deprecated, why not just default to maintaining 1 permanent + 1 valid + 1 deprecated. That means that applications would have to re-establish their connections once a day instead of once every 7 days. But if they use privacy addresses, they already need to re-establish connections after 7 days. And they can always use not to use privacy addresses via the appropriate socket option.
> 
> If the concern with privacy addresses is that a node might have a large number of these addresses, then this seems reasonable to me.

In this respect, we have a few knobs to play with:

1) Valid Lifetime and Temporary Lifetime timers

In principle, N = Valid Lifetime / Preferred Lifetime, is the maxium 
number of addresses that a host may have at a given time. So far, we 
have a VL of one week, and a PL of 1 day, resulting in seven addresses.

If we change that ratio, as Lorenzo suggested, that would change the 
maximum number of addresses at any given time.

That said, the maximum number of N addresses should only actually be 
seen on the network if long-lived sessions were employing each of the N 
addresses. Otherwise, the host would *have* N addresses, but only emit 
traffic with the currently "Preferred" addresses. (i.e., configured 
addresses that are not actively used are not a problem).



2) Whether ongoing sessions should be allowed to continue using invalid 
addresses

By default (SLAAC-wise), they are not allowed. But section "Future Work" 
of RFC4941 hints on that as "future work". This could address the 
concerns of sessions that break up, but at the same time possible 
increase the number of concurrent addresses (you keep the addresses that 
are in use, but keep generating new ones).

One should note that this possible problem can be addressed by the app 
specifying preference of the address type to be used (i.e., override the 
default).


Based on the above, the options kind of become:

Option #1: Reduce the N ratio above, and disallow the use of invalid 
addresses for ongoing sessions. Apps that need long-lived sessions and 
that have not properly overriden the system default will have their 
connections torn down, and we'll have a hard limit on the maximum number 
of addresses.

Option #2: Reduce the N ratio, but allow ongoing sessions to use invalid 
addresses. This could be worse than legacy RFC4941 (if long lived 
sessions last more than a week), since now temporary addresses would not 
have a limited lifetime (the lifetime would only be limited wrt the 
ability to employ them for new transport protocol instances)

Option #3: Keep current N ratio, don't allow apps to use invalid 
addresses. This is the status quo, and enforces a limit  on the maximum 
number of addresses. But obviously this "N" is larger than that of #1 above.

Option #4: Keep the current N ratio, and allow apps to use invalid 
addresses. This is *not* RFC4941. I wonder if any implementations do 
this. This would obviously be worse in terms of the number of addresses 
than legacy RFC4941bis.


If I had to choose, I'd go for #1 or #3 above. If apps hint the network 
layer about the addresses to use (e.g. stable addresses if they mean to 
use long-lived connections), #1 is fine. OTOH, #3, the status quo, is 
more concervative in this respect.

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