Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

[Fernando Gont <[e-mail]>]

Hello, Gyan,

On 28/6/20 02:15, Gyan Mishra wrote:
> 
> 
> Bob & Ole
> 
> The one main concern I do have as stated is that the flash renumbering 
> event is a unique corner case for home or SOHO broadband users.

This is incorrect. Please see: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum



> We recently went through prior to this draft with Fernando on the 
> 4941bis review after many thread and going through various scenarios and 
> operations issues and finally came up with a solid update to change the 
> VL & PL to 2 days.  We took into account long lived connections and 
> operational impact of having many addresses and strived to strike a 
> solid balance between broadband  and enterprise use cases.
> 
> This drafts update is a drastic change to 4941bis VL PL lifetimes which 
> we spent a considerable amount of time on coming to consensus.

This is incorrect. The RFC4941/RFC4941bis VL/PL values enforce a maximum 
preferred lifetime and valid lifetime. This means that even if the 
corresponding prefixes keep being announced with non-zero PL and VL, you 
will still unprefer the corresponding addresses, and eventually 
invalidate the corresponding addresses.

OTOH, the PL and VL you advertise in RAs simply mean "these are the 
maximum values you should use until you hear from me again". Since RAs 
are routinely transmitted as per RFC4862, these timers will be 
refreshed. Only when there's an actual network failure will there be any 
practical difference.



> Since the flash renumbering is such a corner case I think we really have 
> to vet the impact of changes in all other scenarios.  Also the fact that 
> users at home are causal users not business critical that can result in 
> revenue loss I think that would be a consideration.
> 
> Also maybe having a v6ops draft that talks about corners case issues 
> which below does exist.

Would you mind elaborating on what you mean by "corner case"? Operators 
have repeatedly noted on the v6ops list that these scenarios do happen. 
And as noted in another email, work on this topic was indeed triggered 
by an ISP that asked for guidance while dealing with this issues.

https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum should make it 
evident that this is a general issue with SLAAC, as opposed to a "corner 
case" that happens in one particular scenario.

Thanks!

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