Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Fernando Gont <[e-mail]>]

On 23/10/19 10:08, Philip Homburg wrote:
>> The document is available at:
>> https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum
> 
> I think this is an important subject that is worth fixing.
> 
> In this reply I'll focus on the preferred and valid lifetimes.
> 
> On a host, the preferred and valid lifetimes play quite different roles.
> 
> The preferred lifetime plays a role in setting up new flows. I.e. if the
> application does not provide a source address then the IPv6 layer uses
> the preferred lifetime to select the best source address among multiple
> candidates. Mistakenly setting the preferred lifetime of an address to zero 
> may cause problems for new flows but has no impact on existing flows
> 
> In contrast setting the valid lifetime to zero immediately signals an error
> condition to existing flows. This could cause a lot of trouble for long 
> lived flows.
> 
> The other side of the coin is that if a host ends up with stale prefixes,
> then the user maybe willing to wait for a few minutes for the situation to
> resolve itself, but probably not much longer.

Agreed.



> So the suggestion that
> 	AdvPreferredLifetime: AdvDefaultLifetime
> is likely not sufficient to be responsive to a user. And at the same time
> 	AdvValidLifetime: 1.5 * AdvDefaultLifetime
> is very risky if AdvDefaultLifetime is low.
> 
> Note that RFC 4861 allows MaxRtrAdvInterval to be a low as 4 seconds, 
> AdvDefaultLifetime can be as low as MaxRtrAdvInterval, so also 4 seconds.
> 
> This creates a very fragile system.

I may agree. That said, note that according to RFC7772, you'd never send
RAs at a high frequency such as once as every 4 seconds.



> At the same time, AdvDefaultLifetime is commonly 1800 seconds. Which is way
> too long to wait for stale information to expire.
> 
> I agree that valid and preferred lifetimes of resp. 30 days and 7 days 
> are excessive. But I'm not at all convinced that tying them to 
> AdvDefaultLifetime will have a positive effect.

I'd say that at the very least the Preferred lifetime shouldn't be
larger than AdvDefaultLifetime (what's the point of preferring an
address you don't have a router for?).

I do agree with your analysis of the valid lifetime -- is trickier.



> I'm also not convinced
> that there are sensible values for these lifetimes that are robust enough 
> and at the same time responsive enough to deal with the issue at hand.
> 
> Reducing the lifetimes would help against build up of stale prefixes. If
> they are set to a couple of hours.

I do agree that this is not a complete solution, but, as you correctly
note, would help against build up of stale prefixes.


A better mitigation is to affect the preferred and possibly the valid
lifetimes in response to consecutive RAs from the same router that lack
the original (stale) prefix. e.g., after two consecutive RAs that do not
contain the existing prefix, reduce the preferred lifetime. After two
additional RAs, reduce the valid lifetime.

Thoughts?

Thanks!

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