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

[Fernando Gont <[e-mail]>]

On 8/11/19 18:50, Mark Smith wrote:
> One of the best questions to often ask is "why?"
> 
> On Sat, 9 Nov 2019, 01:20 Philip Homburg, <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > Probably there is no formal requirement for prefixes to be stable
>     > across crashes and reboots[*], but there is a behaviour of the
>     > client to send CONFIRM after reboot or wake-up from sleep, as
>     > described in the RFC DHCPv6.
> 
>     Sending a CONFIRM after a reboot requires that the client writes the
>     lease to presistant storage.
> 
>     As far as I know, there is no requirement for clients to have suitable
>     persistent storage.
> 
>     Of course, the big issue is: do we want to delay IPv6 by making IPv6
>     deliberately incompatible with common IPv4 deploy strategies?
> 
> 
> Why do you think that this "strategy" exists in IPv4 deployments?
> 
> Why is it relevant and preferable today for IPv6?
> 
> Why is it best for IPv6 when people get something different in IPv6 than
> in IPv4 - public address space to use on their LAN.

Asking "why" is nice. BUt as for many other uses of the question, it
doesn't solve the problem. Over 30% of IPv6 deployments do dynamic
prefixes, and hence are prone to face this. That's the deployed reality.

That aside, I reiterate this is *one of many* possible scenarios where
this issue may be faced.

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