Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)

[Ole Troan <[e-mail]>]

>>>>>> I think Ole observed that this is contrary to what the PD 
>>>>>> prefix's Valid Lifetime said would be the case. The ISP supplied 
>>>>>> a PD Prefix with a Valid Lifetime of X seconds, and then broke 
>>>>>> that promise by abruptly changing addressing before X seconds. 
>>>>>> ISPs should be expected to live up to their Valid Lifetime 
>>>>>> promises.
>>>>> 
>>>>> "Hope" doesn't make networks run properly.
>>>> 
>>>> This isn't "Hope", this is breaking promises, and that does break 
>>>> networks. If you can't at least trust that promises are intended to 
>>>> be kept then you have no network at all...
>>> 
>>> They are intended to be kept, but at times s* happens e.g., CPE routers
>>> don't crash and reboot on purpose.
>> 
>> This comment worries me.
>> That a CE reboots is _not_ the problem, nor does it cause the problem.
> 
> Well, if the CPE did keep state, there would be no problem. (is there a
> formal requirement for prefixes to be stable across crash & reboots?).

CPE is not required to keep state.
In PD the DR is in control, and should continue to delegate the same prefix as previously delegated.
If the RR includes prefixes in the request, those are purely there as hints for prefixes it would prefer.

> (just as a reminder, this is just one scenario. there have been at least
> three operators that have noted that their setups experience renumbering
> scenarios for other reasons... and slaac could certainly do much better
> in those)

You have to be clear what the root cause of a problem is.
The DHCP PD protocol is designed to carry leases over CPE reboots.

If an SP uses the opportunity caused by a reboot to flash renumber, then say so.

Ole