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

[Owen DeLong <[e-mail]>]

> On Feb 26, 2019, at 02:35 , Richard Patterson <[e-mail]> wrote:
> 
> On Mon, 25 Feb 2019 at 18:37, Fernando Gont <[e-mail]> wrote:
>> Agreed. That said, with the current default lifetime values, things
>> become tricky:
>> At least in theory, you should be sending such RAs for "Valid Lifetime"
>> seconds. With a default of one month, that means that, in theory, you
>> should be sending such RAs for a month. And if there are multiple
>> crash-and-reboot events, you should advertise each of the stale
>> prefixes. (I assume the CPE just records the last one)
> 
> 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.

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 such, 

> 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?

(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.

I’m hard pressed to think of harm that comes from an invalid prefix
remaining on an interface so long as it is not preferred in most cases.
The one case that comes to mind is that hosts retaining that prefix
will be unable to reach hosts to which that prefix has been newly
assigned while they still retain it as a valid prefix.

Owen