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

Richard Patterson <> Wed, 13 November 2019 10:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB2CA120072 for <>; Wed, 13 Nov 2019 02:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g1xnurmNVZnn for <>; Wed, 13 Nov 2019 02:50:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53E1F12010F for <>; Wed, 13 Nov 2019 02:50:42 -0800 (PST)
Received: by with SMTP id i13so2016537ioj.5 for <>; Wed, 13 Nov 2019 02:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5N7FINgfrwOXqoGZjVTcDoCP3NAIUrNWos8+Aji0CDM=; b=B/p+/+Cac8fyANyae4ZPTUbLbgVCw5KzOtirGiDo0COwagT5fom9S4vC+OcGxQ/1bV IY8LzR2iOlxdNV9L59tBV7jJsGFw9tAcc2Ugr5o+nT02FeMfziAZBLAPrRkIADxhTySl xVV17b8/YzdKBDZ6m41c307b3eE5FwaB2hvZ7Wbl9lSuOtsco5JjTTWqKnmaCmS5Xb+G hUEhSjEaZW5ZxWZACjJlcHp65bXu+U/zm+06k5Bbr0bi+4JdVPgwqhH+2qsbQFqK0ViI XXIX31+Jpz1XhOD/AG7oZwaPagCwewvty65BxeHxDWeVIXUzrDML+WU+FgbNDexb35D/ gaLw==
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=5N7FINgfrwOXqoGZjVTcDoCP3NAIUrNWos8+Aji0CDM=; b=QKqq7N1m6C2tDxUQjEOUT7Vs8qYuInpEXnoYaW16ldQyuqpm68MjeJnRWlpoff1Zy+ LjA1Jtz8RDZ5zFM4ZFjd0GyygP7YJ6psNDj06P2H2VuKbt9mmmZoxGHPtJ2GvZDxwTRY tYWZPv9+KumunLU/dSFivq7m4BIRtVMV3hFed/f1KetSjNMjTkKGeNJkqcYMI6Z9SExH Fvwjf8OBsoDhxwglXTD7WqR8+qvUnCNd3eTKJpEAh+4/4wWFl/WYhoE3Pv3Umjrbe2hm InGc+UwlM+kGs0L1JAFNpkx4IpUqzuJ1b9ttqg8NXIyHmpkqrW2dl+BeR4ozIFHgfOPg shaA==
X-Gm-Message-State: APjAAAV2GXGtdz9n4TptJpAfrjUkDgwJHgMn7dpVces9IJ4VtcmAA4JF FX7NVwj++RxcT4EFXR5U2rzsPaG0yb4=
X-Google-Smtp-Source: APXvYqx3RD3+AyMBaTUer8dJR9f6gyMkSf+Xrs3MyimWyU/hvjr0/uYvPlE924pfxqtcrJwYpn7f5g==
X-Received: by 2002:a5e:8601:: with SMTP id z1mr51964ioj.214.1573642241373; Wed, 13 Nov 2019 02:50:41 -0800 (PST)
Received: from ( []) by with ESMTPSA id d8sm221363ilr.82.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2019 02:50:40 -0800 (PST)
Received: by with SMTP id m5so1386056ilq.0 for <>; Wed, 13 Nov 2019 02:50:40 -0800 (PST)
X-Received: by 2002:a92:9ace:: with SMTP id c75mr3071844ill.296.1573642240329; Wed, 13 Nov 2019 02:50:40 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Richard Patterson <>
Date: Wed, 13 Nov 2019 10:50:28 +0000
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: v6ops list <>
Content-Type: multipart/alternative; boundary="000000000000bd10e60597382297"
Archived-At: <>
Subject: Re: [v6ops] What problem are we trying to solve? (Re: 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: Wed, 13 Nov 2019 10:50:45 -0000

On Wed, 13 Nov 2019 at 05:08, Fred Baker <> wrote:

> Change "would" to "could", and you're probably close. In general, I would
> expect ISPs to not want to randomly change their routing, and so it would
> not be deterministic - if the customer is no longer using a prefix (e.g.,
> the CPE crashed and routing has changed anyway), when the CPE comes back up
> they might give it a different prefix. However, I'd be surprised if they
> did it "just because".

Depends on the vendor.  For example, one of our BNGs (that's operating as a
DHCPv6 server) will keep a lease in a "held" state for a configurable
duration after the Valid Lifetime expires.  We set that value to 7 days,
allowing a CPE to come back and get the same PD within a week.

A different BNG vendor of ours however, doesn't have this configurable hold
time concept; once the Valid LIfetime expires, the MAC+DUID binding to the
PD is cleared.
They do have setting to retain the MAC+DUID->PD lease binding indefinitely,
however they didn't satisfactorily answer my question about cleanup if
these bindings are exhausted (CPEs that use dynamic DUID values perhaps?
Even though even the DUID-LLT method is *supposed* to be stable).