Re: [v6ops] [dhcwg] SLAAC renum: Problem Statement & Operational workarounds

Mark Smith <> Thu, 31 October 2019 02:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F276F1200FE; Wed, 30 Oct 2019 19:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Status: No, score=-0.496 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, URIBL_BLOCKED=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 VY6D2Kgg22ds; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 885A0120058; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
Received: by with SMTP id g81so3826587oib.8; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
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=JMZQlqC6lRY0rCdL/GQFOvfmNiZMuL1w+XPqWfKzKso=; b=Fv3I6f8yQgQL1grA7HSbhS7QredjP4No0boZY5Nna1E3gc7n//37QSRyD3PRl+ed8b W4JJYDV0ianBQGB2/1CwKTmCjLCitZKNJkdi/Ghma7AQFwbe2xVDOImcKwB7iYig05aR JzlyjfJ/oj3PbmkGCLzwiTfmnoMgCdCcWzcpj5VBBF75uQultP3x+HtqRm2S1hEC7Iy9 Yox727LOsdVX8OQM2ROE7UhOVw4ZH70idMdJXwgPeBKY4vS8O22VY9Hx1ESTdkjLnbPd id4UyhYV745VqK2uMdoqhbvG/UruoExEaq0sR82su94hW4Ag4I4MNFT+TV2snRCRKtrf jnSA==
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=JMZQlqC6lRY0rCdL/GQFOvfmNiZMuL1w+XPqWfKzKso=; b=CsEsArmTOF3nS0DyEuSsZ9GynwdgQ717Fvrjfu3Pn8mjwFvypT2W6jCiEmnoPuJ1Ml 9fQWdNY3K3WQjzt4SNEfA7/boyTnJjnYYe6e/4TzG2AzQhQDR2Iy4Xrk1tj5LStBLxK1 /HwaiW2jausesXZVbEcz6DTAuGPeXAGYkmwNg3CATkBHIddZf84Fha7kbwADflxaX88T PPTyDmivou4nPMAydtRc8ykZ9+6Bhn6bcd42jilUf53xc6LaOKPMvPdLwb0YGzkrBzfJ 7/CtyexnsNOxZGJ8pCj83AGlK++J7VIRAZThQiirtdPOjdYdBpnbeqJfX/+p43wDdP/B 9iCQ==
X-Gm-Message-State: APjAAAW58ujaf1JflwkaG/q83ysq+52wEt4dGwOb1C5lbS4EbrBUibtc JwTjAa9pMCNYkrQZhmSu0tLP0VEKnWV4mwhtZhY=
X-Google-Smtp-Source: APXvYqx4qi/EqqjAk82SKSZazsSxxwptzJS2Frcsjbv+m9blfVoLbi3LZsCSPg0kdXVrXHiD5YanCzdki57C/nGb7M4=
X-Received: by 2002:aca:f553:: with SMTP id t80mr2004102oih.60.1572487960802; Wed, 30 Oct 2019 19:12:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Thu, 31 Oct 2019 13:12:30 +1100
Message-ID: <>
To: Owen DeLong <>
Cc: "Bernie Volz (volz)" <>,, IPv6 Operations <>, Bud Millwood <>
Content-Type: multipart/alternative; boundary="0000000000005139f005962b6251"
Archived-At: <>
Subject: Re: [v6ops] [dhcwg] 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: Thu, 31 Oct 2019 02:12:43 -0000

On Thu, 31 Oct 2019, 12:40 Owen DeLong, <> wrote:

> On Oct 30, 2019, at 5:53 PM, Bernie Volz (volz) <> wrote:
> Mark Smith on v6ops ml wrote:
> “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.”
> Sure, but in the real world, there is an entire class of ISPs that have
> repeatedly demonstrated utter and near complete disregard for such niceties
> as promises to customers (e.g. most major eyeball ISPs in the US at a
> minimum), so having CPE behavior that accommodates this fact in favor of
> the user will likely lead to a better user experience than stomping or feet
> and insisting that ISPs behave properly.

So if some enterprise network operators said to the IETF,

"We want to be able to change the VLAN assignments of any of our IPv6 hosts
randomly and unexpectedly, including at 9:10 am when everybody is checking
their email, and have the hosts handle that entirely seamlessly."

would we consider that to be a reasonable request?

> And it would be worth better understanding exactly what happens in these
> situations (perhaps it was covered earlier but I missed or lost that)  ...
> if the Prefix configuration really is radically changed, even the SP dhcp
> server may be unable to assist.
> With what is being proposed, the SP DHCP server doesn’t need to assist.
> The CPU should write the set of received prefixes and their expected
> expiration times (preferred, valid) to persistent storage. The CPU should
> update this when a packet making a change to these timers is received. It
> should make every effort to deprecate prefixes it cannot renew from the
> links where it previously advertised them.
> This doesn’t require anything special on the SP side.
> Owen
> - Bernie
> On Oct 30, 2019, at 7:32 PM, Ted Lemon <> wrote:
> On Oct 30, 2019, at 7:18 PM, Bud Millwood <>
> wrote:
> It's not so much about the lifetime of the prefix as about putting two
> prefixes in a reply to a request, right? And any CPE that can't handle
> that gracefully gets hosed. I agree that providers of course need to
> test this feature, and a server side configuration makes that
> possible. Also, I'm all for firmware upgrades, but requiring it to fix
> a hosed CPE is could be a big issue.
> The thing is, if they can’t handle a two-PD response, they are out of
> spec.  This is already allowed in the RFC.
> Granted, there may be plenty of CPEs that won’t handle this correctly.
> If they can be bricked by a message with two PDs, then bricking them is the
> right thing to do, because that’s a zero-day vulnerability wide open on the
> customer network.
> _______________________________________________
> v6ops mailing list
> _______________________________________________
> v6ops mailing list