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

[Mark Smith <[e-mail]>]

On Sat, 9 Nov 2019, 09:15 Fernando Gont, <[e-mail]> wrote:

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


It gets to the root of the problem, so you can determine where the problem
truly exists, and where to then prevent the problem.

The Five whys method suggests you need to ask "why" around 5 times to get
to the root cause of a problem.

Five whys
https://en.m.wikipedia.org/wiki/Five_whys

Prevention is better than cure or mitigation.

Mitigation is all that is being proposed here. As someone who has
implemented and had had distributed mitigations for this in 'radvd' (the
DecrementLifetimes and DeprecatePrefix options), they're not as effective
as preventing the problem where it actually exists.

Have a look at how horrible the problem gets and how ineffective these
mitigations are when someone has a routed network using the dynamic PD
prefix.

https://github.com/reubenhwk/radvd/issues/116


Over 30% of IPv6 deployments do dynamic
> prefixes, and hence are prone to face this. That's the deployed reality.
>


Why are they doing it that way when it causes problems for their customers?
Why don't we know the answer to that question?

Why do we always have to try to solve technology problems with more
technology, when sometimes education about a different and better way to
solve the problem can be cheaper, quicker and more effective?

Why is "the ISP is always right" assumed?

Why aren't the IETF allowed to say to ISPs, "this is not the way this
protocol was designed to be deployed, the correct way is 'X'"?


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

If it is common, why haven't we heard about it here in the IETF in any
other context other than ISPs doing dynamic PD prefixes?





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