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

[Philip Homburg <[e-mail]>]

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

In think it is better to solve two separate problems independently and only
merge the solutions if the same solution happens to apply to both.

When router reboots and switches to a new prefix, hosts should switch to the
new prefix as soon as possible. 

On the other hand, removing addresses that have preferred lifetime of zero
is a bookkeeping task that can take more time.

One question is whether it makes sense for routers to have valid lifetimes of
more than a day for prefixes that are obtained using DHCP-PD.

Another is whether general purpose hosts should accept lifetimes of more
than a day. Maybe hosts should just truncate.

If that doesn't solve the issue, then for the valid lifetime it make sense for
the host to wait multiple RA intervals to make sure the router really doesn't
advertise the prefix.

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

What happens if a router would advertise 4 prefixes in 4 separate RAs?