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

Owen DeLong <> Fri, 01 November 2019 16:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E92C21209FE for <>; Fri, 1 Nov 2019 09:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbsAjuqsqzdh for <>; Fri, 1 Nov 2019 09:22:02 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id 7D8511209EE for <>; Fri, 1 Nov 2019 09:22:02 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id xA1GLxwW025605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 09:22:00 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 xA1GLxwW025605
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1572625321; bh=YPPfy0PFwleLtUFFrhhyhuVCj/I9ehRl4mO9AL8Sps8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IsNAvMbbG9YPuWocZIFMisEzD8JipeUWMkCfRSiJBjmgU1DWRGROmd5NYONWi7BMz P0uMom6LK/YlKayahp77em5IJrnNIsc1cRF90fPZGYE2BX/i+OC4kynk1pcUPRFZfh YOfWDo3t4Zf/oxyMsZrrAEk3s+EO2gQn/YkXH/NQ=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Fri, 1 Nov 2019 09:21:59 -0700
Cc: Sander Steffann <>, v6ops list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Fri, 01 Nov 2019 09:22:01 -0700 (PDT)
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: Fri, 01 Nov 2019 16:22:05 -0000

> On Nov 1, 2019, at 2:29 AM, Fernando Gont <> wrote:
> On 1/11/19 05:22, Sander Steffann wrote:
>> Hi,
>>>> 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...
> You might hope the ISPs do stable prefixes, that CPEs record the leased
> prefixes on stable storage, and that CPE routers does not crash and reboot.
> However, 37% of surveyed ISPs
> (
> indicate they do dynamic prefixes, and thus are likely to be facing this
> problem (possibly being masqueraded by falling back to IPv4).
> You may want to declare ISPs clueless, start a crusade to switch to
> stable prefixes (unlikely success), claim that CPE vendors are cheap, etc.
> But at the end of the day, user experience will still suck.
> (I have had cases in which I have flash-renumbered my network by
> changing and reloading a RA daemon)

Dynamic prefixes do not necessarily imply flash renumbering and broken promises as Sander calls it.

He’s right that even in the case of dynamic prefixes, the ISP _SHOULD_ delegate or at least preserve the operability of the prefix for the duration promised in the lease, even across reboot of the delegated router, etc.

However, you’re also right that vendors and ISPs don’t always do what they should and these proposals can help mitigate the damage when that happens.

If there are problematic tradeoffs associated with these measures, they should be considered, but taking an absolutist approach of “this shouldn’t happen, so we shouldn’t make efforts to handle this case” isn’t useful IMHO.

>>> In any case, as previously noted, there are multiple scenarios that may
>>> lead to this problem.
>> Sure, bad things can happen, and there are cases where despite the best intentions you can't keep your promise. But that doesn't mean everybody should go around making promises without even thinking about keeping them…
> I certainly can't speak for the 37% above. But a number of folks have
> already noted (some on-list, some off-list) that they are running
> networks on which this flash-renumbering events do occur.
> The home network/cpe case is a notable example, but others exists. And
> particularly the host-side mitigations help all of them.

I’d argue that the CPE side mitigations are the low hanging fruit here. I think it will be far faster and easier to update CPE firmware and that the changes proposed to CPE are, in fact, in most cases simpler than the host changes.