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

[Fernando Gont <[e-mail]>]

On 31/1/19 10:43, Philip Homburg wrote:
>> So while I am generally sympathetic to this draft and what it tries to 
>> achieve (especially the part where it ties the router announcing something 
>> to what it's later announcing, and lack of something means it's implicitly 
>> zero preferred time for that), we need to figure out a few more things 
>> first. RFC7084 was informational which made it fairly easy to get through, 
>> now you're proposing a standards track document so we need to make sure 
>> everything works. Changing all hosts is a big thing.
> 
> I think changing host behavior is good in this case if we can make hosts more
> robust. I prefer the network to do the right thing, but reality is that that
> will not always happen, so it is good to have robust hosts.
> 
> That said, I don't like playing games with the valid lifetime. Changes to 
> preferred lifetime are relatively benign, setting the valid lifetime of a
> prefix to zero may have more serious consequences.

FWIW, our first initial version only changed the "Preferred Lifetime",
and never modified the "Valid Lifetime". Then we realized it was easy to
update the "Valid Lifetime" with the same "mechanism" and incorporated
that. THe most important bit is, indeed, updating the "Preferred Lifetime".

Question:
How about making the update to the "Valid Lifetime" a SHOULD or MAY,
instead?  Or, maybe, at least, set it to the current "Valid Lifetime"?
Otherwise, with the default values for the "Valid Lifetime", the
addresses might lie around for 1 month....



> I think the algorithm can be simplified to:
> - When a RA is received that contains a PIO with the A bit set, then set the
>   preferred lifetime to zero for all addresses derived from prefixes that were
>   announced by the same router and that are not covered by the current RA.
> 
> In extreme cases this may cause the preferred lifetime to ping-pong. But that
> just causes source address selection to become more random, which should be
> fine.

The mechanism in the document tries to accommodate the case where the
information conveyed in an RA is split among two RA messages -- so it's
the second RA with the PIO that causes the update, rather than the first
one. In all current practical cases, all info is normally conveyed into
a single RA. However, the mechanism that's currently in the I-D allows
for cases where it can be split in two.

Based on whether we want to allow such case or not, we may or may not
simplify the mechanism as you suggest.

What do other folks think?

Thanks!

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