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 Tue, 12 Nov 2019, 05:56 Richard Patterson, <[e-mail]> wrote:

> On Mon, 11 Nov 2019 at 17:11, Ted Lemon <[e-mail]> wrote:
>
>> Nobody is expecting you to never renumber.   Well, at least I am not.
>> What I am talking about here is deliberate, opportunistic renumbering. If
>> your topology changes and you have to renumber, so be it. If you can avoid
>> that it’s better, and if you can give notice it’s also better. If you can
>> do it gracefully with temporary routes, even better. But you shouldn’t be
>> renumbering just ‘cuz.
>>
>
> In that case I think we agree, an operator shouldn't intentionally
> renumber "just 'cuz".  However the scenarios I mentioned are far from the
> Operator going *out of their way* to not support stable prefixes.
>

"What you allow, you encourage." - Michael Josephson.

If the IETF believe that stable prefixes are the correct solution, because
that is the Internet architecture (transport layer connections are to
tolerate transient connectivity faults through retransmission, and that
relies on persistent host IP addresses across transient connectivity
faults), then I don't think the IETF should try to purposefully accommodate
unstable prefixes.

Purposefully accommodating unstable prefixes will only encourage ISPs to
use them.

If an ISP chooses to provide a bad experience to their customers through
unstable prefixes, then the pain and consequences of that decision should
be entirely borne by the ISP, rather than them then expecting the IETF, CPE
and host implementation vendors to then come up with and wear the
development and deployment costs of imperfect work arounds.

These ISPs are choosing to create a problem that doesn't need to exist.


The question is just around how stable they are,
>

The answer is easy.

What the ISP said it would be in the Valid Lifetime field.

It's a broken promise if it isn't, and ISPs should only break promises when
they have no other choice i.e. emergency network reconfiguration in a dire
fault situation.

If an ISP wants to provide short life addresses, they can specify a
ValidLifetime as low as 2 hours, per RFC 4862, 5.5.3, (e).

That would seem to me to be contradictory to the "always on" nature of the
Internet service they're selling, however that's up to them as long as they
wear the consequences of that decision.


and once you start having to ask that question, then shouldn't we be
> looking at ways to mitigate the impact to an end-user?
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>