Re: rfc4941bis: Change to Valid Lifetime of temporary addresses (take two)

[Fernando Gont <[e-mail]>]

Hello, Bruce,

On 20/2/20 14:25, Curtis, Bruce wrote:
> 
> 
>> On Feb 15, 2020, at 12:06 PM, Fernando Gont <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On 11/2/20 18:58, Lorenzo Colitti wrote:
>>> I think this change is an improvement. Keeping arond 5 addresses that 
>>> are not useful seems like a waste of network capacity. An application 
>>> that is not resistant to connection disruption, and *really* wants to 
>>> use long-lived sessions, should probably be using PREFER_SRC_PUBLIC 
>>> anyway.
>>
>> If the addresses are not used, they will not waste network resources.
>>
>> The only difference between short and long valid lifetimes is whether 
>> ongoing ling-lived connections will be aborted or not.
>>
>> e.g., with RFC4941, a host will typically have one preferred address, 
>> and 6 unpreferred (but valid) addresses. If there are no long-lived 
>> connections, the unpreferred addresses will remain configured, but 
>> will not be employed to send or receive packets. Unless I'm missing 
>> something, they wouldn't seem to be wasting network resources. OTOH, 
>> if there *are* ongoing long-lived connections, these addresses would 
>> be actively used, and require effort from the network.
> 
> 
> There are at least one scenario where unpreferred (but valid) addresses 
> can use network resources.
> 
>   In at least one vendor’s implementation of IP Source Guard closet 
> switches keep track of active IP addresses by periodically sending 
> Neighbor Solicitation packets.   So even though there might not be any 
> active connections using an IPv6 address the closet switch will still 
> have info about that IPv6 address (which port it is on and which MAC 
> address is associated with that IPv6 address).  The IP Source Guard 
> feature from this vendor does also include the capability of setting a 
> limit on the number of IPv6 addresses per port.
> 
> In at least one vendor’s wireless solution the wireless controller 
> tracks IPv6 Neighbor status in a cache and uses that cache to act as a 
> proxy and reply to Neighbor Solicitation requests with a unicast packet 
> (and dropping the multicast Neighbor Solicitation request so no wireless 
> clients see the Neighbor Solicitation request).  But this particular 
> wireless controller also limits each client to 8 IPv6 addresses. "When 
> the ninth IPv6 address is encountered, the controller removes the oldest 
> stale entry and accommodates the latest one.”   Although unpreferred 
> (but valid) addresses might not use resources in this vendors 
> implementation it is possible that other vendors might implement IPv6 
> Neighbor Solicitation suppression and proxy in a way that would result 
> in unpreferred (but valid) IPv6 numbers using resources.

Thanks a lot for this analysis!

This, together with other arguments made on the list seem to favor 
reducing both the Valid and Preferred Lifetimes.

I will send a stand-alone email to the list just to double-check once 
more before applying the change.

Thanks a lot!

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