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

[Fernando Gont <[e-mail]>]

On 26/2/19 07:13, Ole Troan wrote:
> Fernando,
> 
>>>> On 25 Feb 2019, at 18:36, Fernando Gont <[e-mail]> wrote:
>>>>
>>>> On 25/2/19 07:32, Richard Patterson wrote:
>>>>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <[e-mail]> wrote:
>>>>>
>>>>>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy
>>>>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
>>>>>> not even the CPEs can (even if they wanted to) do something to fix the
>>>>>> problem.
>>>>>
>>>>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
>>>>> the Preferred Lifetime can.  So we can't invalidate the prefix, but we
>>>>> can deprecate it so it's not used for new outbound sessions.   This is
>>>>> what we've implemented in our CPEs, after an unavoidable change in
>>>>> prefix, and it seems to have mitigated (or reduced the impact of) the
>>>>> issue.
>>>>
>>>> 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)
>>>
>>> When / where was the default Valid Lifetime chosen to be one month?
>>
>> Section 6.2.1 of RFC 4861:
>>
>>      AdvPrefixList
>>                     A list of prefixes to be placed in Prefix
>>                     Information options in Router Advertisement
>>                     messages sent from the interface.
>>
>>                     Default: all prefixes that the router advertises
>>                     via routing protocols as being on-link for the
>>                     interface from which the advertisement is sent.
>>                     The link-local prefix SHOULD NOT be included in the
>>                     list of advertised prefixes.
>>
>>                     Each prefix has an associated:
>>
>>                        AdvValidLifetime
>>                             The value to be placed in the Valid
>>                             Lifetime in the Prefix Information option,
>>                             in seconds.  The designated value of all
>>                             1's (0xffffffff) represents infinity.
>>                             Implementations MAY allow AdvValidLifetime
>>                             to be specified in two ways:
>>
>>                               - a time that decrements in real time,
>>                                 that is, one that will result in a
>>                                 Lifetime of zero at the specified time
>>                                 in the future, or
>>
>>                               - a fixed time that stays the same in
>>                                 consecutive advertisements.
>>
>>                             Default: 2592000 seconds (30 days), fixed
>>                             (i.e., stays the same in consecutive
>>                             advertisements).
> 
> 
> Red herring.
> 
> RA lifetimes cannot be longer than the DHCP PD lifetimes.

I don't disagree with you.


> In the DHCP PD case they should also be counted down in real time.
> And the lifetimes can be dynamically adjusted.

They should. However, quite frequently the DHCPv6-PD part is a different
piece of software from the ra{d,dvd} part. Both pieces are glued by some
script, and the lifetime is *not* dynamically adjusted.

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