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

Mark Smith <markzzzsmith@gmail.com> Thu, 31 October 2019 02:12 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276F1200FE; Wed, 30 Oct 2019 19:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY6D2Kgg22ds; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885A0120058; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id g81so3826587oib.8; Wed, 30 Oct 2019 19:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com> <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.com> <C0A66DA1-29DE-456A-934D-7ECC07575336@cisco.com> <8755B40E-4075-4AAC-BF59-19B6DF9BA6D1@cisco.com> <B23EE439-1509-43FB-9813-F330117DBF42@fugue.com> <CAOpJ=k25ML8Z0_QRN8yoYdXut=tsZBwtBZEstceT45csb1Aunw@mail.gmail.com> <E8D9F8C2-C4C1-44CC-AB06-87A3461B704A@fugue.com> <A72A93B2-B947-4365-A811-50D8908B01EA@cisco.com> <F2F145F7-E678-48C9-A765-BD2D22F793EE@delong.com>
In-Reply-To: <F2F145F7-E678-48C9-A765-BD2D22F793EE@delong.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 31 Oct 2019 13:12:30 +1100
Message-ID: <CAO42Z2xQ99cjjJzySRS7T32dBYzeyXH8FVH56enuHLE8Eqz=_Q@mail.gmail.com>
To: Owen DeLong <owen@delong.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, dhcwg@ietf.org, IPv6 Operations <v6ops@ietf.org>, Bud Millwood <budm@weird-solutions.com>
Content-Type: multipart/alternative; boundary="0000000000005139f005962b6251"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7YG2oxoAhYPEc3DM_ebH0_ZRCRI>
Subject: Re: [v6ops] [dhcwg] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 02:12:43 -0000

On Thu, 31 Oct 2019, 12:40 Owen DeLong, <owen@delong.com>; wrote:

>
>
> On Oct 30, 2019, at 5:53 PM, Bernie Volz (volz) <volz@cisco.com>; 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 <mellon@fugue.com>; wrote:
>
> On Oct 30, 2019, at 7:18 PM, Bud Millwood <budm@weird-solutions.com>;
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>