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 <> Mon, 11 November 2019 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57556120823 for <>; Mon, 11 Nov 2019 13:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R_LAS2P3YyrV for <>; Mon, 11 Nov 2019 13:06:07 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D47F120812 for <>; Mon, 11 Nov 2019 13:06:07 -0800 (PST)
Received: by with SMTP id c19so12397743otr.11 for <>; Mon, 11 Nov 2019 13:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGRoSf2rv31EcYVz3007MxVUIDpTvkxv9hgQqVh6nho=; b=ZF2A50jpAsEP15Nqi5koVP8br1p1HYwBdCODKxLKkkPpdoh5vTXPoMBjZ+DNB4/3uW MGwwwcJLEdtLwIjFvpcLZti3Fjeh2dTAk0jtq6mdSn4lQ38bwGlLYzn3W5o42Vzaaubt /aT+g9s2SRviCovtBhgMq8O7CY89ZSes0g6Oh4xygztuGUnEEdxDpxKfvOkgEKjUWi/s mht+IzMGFmZ72tyW7vPaXNRrmVCCZVYSphn6C8qzhcNbaEig6X+F3ehYgVe3sSVX6rrz EJviXJdLGxBF/avDTCc1oei4EcjCkNSWrx26R0V89liVe733YGpfeArcav6jsWCdkjWt bEjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGRoSf2rv31EcYVz3007MxVUIDpTvkxv9hgQqVh6nho=; b=lAlOAFmo1I+PGA53RTcdgSau4LQPI10IZdnK/gCwkt9JISjik9fY7yhWJWaJiJ9PL4 slEf5ub3mmaN0RDyugCdruZ+xueDGgQTBC2acHVObFKPA5mZUB1YqXhhPoimSYltmIYw n3H2rbapkRJ3xMgHOWpRr8vvvPy8tfoUBq2l8xyRc+kUtIWsvBpZUpW750Meu7OfJjK5 Xy/lAxeYhAku22ImOVPfXzzA5vvzlVt8g09Gns6hZxyb7e58Y3sl+HO87FKPTNVdRMun gtPwli3Yphp4rmPu3R/H1GF9nAVsCa0sze1LpZ2LzuawR4KVbDC7KeRIMGTY5vPKuJYv AQtA==
X-Gm-Message-State: APjAAAUHcHaPysWZLuMSYDoPjQjWeWxFPOxzkbFzq2oE2jjwCw+G/2Fe g7kiPlpX2FIRNrn/1UAhUEZ15Ob/kB3PYsbuzuenHg==
X-Google-Smtp-Source: APXvYqyXgono+lf2nJN8zEW6dYK6tDPDh4QJaiN2hKUPfoUDf9ak3eSQGIf5fTOCwISrItaRxYDB51e56//PrKJ5HFE=
X-Received: by 2002:a9d:7cc7:: with SMTP id r7mr10482825otn.94.1573506366699; Mon, 11 Nov 2019 13:06:06 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 12 Nov 2019 08:05:56 +1100
Message-ID: <>
To: Richard Patterson <>
Cc: Ted Lemon <>, v6ops list <>
Content-Type: multipart/alternative; boundary="00000000000009fc32059718804f"
Archived-At: <>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: SLAAC renum: Problem Statement & Operational workarounds)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 21:06:09 -0000

On Tue, 12 Nov 2019, 05:56 Richard Patterson, <> wrote:

> On Mon, 11 Nov 2019 at 17:11, Ted Lemon <> 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