Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Richard Patterson <[e-mail]>]

Hi Owen,

On Wed, 27 Feb 2019 at 16:38, Owen DeLong <[e-mail]> wrote:
> > On Feb 26, 2019, at 02:35 , Richard Patterson <[e-mail]> wrote:
> >
> > I get your reasoning, but I'm not sure if it's quite as dire as that,
> > a single RA update with PrefLifetime of 0 should in theory suffice,
> > but then we get in to discussing the reliability of ICMPv6 messaging.
> > (as you have done in draft-gont-6man-slaac-renum-02 )
>
> I think you’re leaving out the fact that there are two lifetimes…
>
> There’s a preferred lifetime and a valid lifetime.

The valid lifetime was intentionally omitted from my response as we
previously discussed that it cannot be lowered below 2 hours or the
RemainingLifetime.

> I’d argue that a prefix which is no longer valid on the link should
> (ideally) be advertised for some period with a valid_lifetime of 0.
> After all, if the prefix is no longer valid, there’s no benefit whatsoever
> to allowing hosts on the link to continue to believe that it is, regardless
> of the amount of time remaining in the timer on a previous RA.
>
> I believe (someone will surely correct me if I am wrong) that a host
> receiving an RA with different lifetime values is obliged to apply those
> new values overriding any time remaining on the old values, regardless
> of whether that increases or decreases the remaining time in the
> lifetime values.

As above, we can deprecate the use of a prefix with Preferred Lifetime
today, but to do the same with Valid Lifetime would require updating
4862.
Fernando documents this in 3.2 here:
https://raw.githubusercontent.com/fgont/draft-slaac-renum/master/draft-gont-6man-slaac-renum-02.txt
The second bullet-point in 3.2 triggered the below thought on how else
we could work-with-what-we've-got (the source address selection
process), to make things more robust.

> > In my head, an address with the higher Preferred Lifetime should be
> > selected over one with a lower value, however I couldn't find any
> > recommendation as such in RFC6724, is this stipulated anywhere else?
> > If not, would an update to 6724 that introduces a Preferred Lifetime
> > comparison as a tie-breaker help?  i.e. When deciding between multiple
> > non-deprecated source addresses, always pick the address with the
> > highest Preferred Lifetime?
>
> Selected for what? Source of a new session originated from the host?

Yes, I did include RFC6724 for context. :)

> (That’s the only case of selection I can think of). That’s governed by the
> source address selection rules in RFC-6724 (obsoletes RFC-3484) in
> the case where the application doesn’t bind a specific source address
> to the socket. In the case where the application does bind a specific
> source address, then, the source address selection methodology is
> entirely in the hands of the application developer and/or any runtime
> configuration said developer chooses to consider.
>
> I guess all else described in RFC6724 being equal, one could use
> longest remaining preferred lifetime as a tie-breaker, but I have yet
> to encounter a network where you would reach such a tiebreaker
> without arriving at a single prefix first by another method.
>
> I do think it might be worth considering a change to how hosts process
> Was wherein we keep track of the address of the router from which we
> received the lifetime values currently being counted down and if we
> receive a new RA from the same router that no longer includes
> one of the prefixes we are counting down, we reduce the preferred
> lifetime to zero while continuing to count down the valid lifetime.

This is just a passive host-side version of the above approach. This
would still require changing all end-host behaviour, where the above
(sending an RA with PIO Preferred Lifetime 0) can be done centrally on
the CPE today without any change to current behaviour of the
end-hosts.