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

Bud Millwood <budm@weird-solutions.com> Wed, 30 October 2019 23:18 UTC

Return-Path: <budmillwood@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 AA882120168; Wed, 30 Oct 2019 16:18:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 VPLPJkcBEaSy; Wed, 30 Oct 2019 16:18:40 -0700 (PDT)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 72D24120817; Wed, 30 Oct 2019 16:18:40 -0700 (PDT)
Received: by mail-io1-f54.google.com with SMTP id r144so4532795iod.8; Wed, 30 Oct 2019 16:18:40 -0700 (PDT)
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:content-transfer-encoding; bh=j4stawB2/aZsWbMsFsShm5v3V/Vs3NGBGv1Ps/UfGrE=; b=GK41SkWMIS6SNHWkPcfkK40rVahFmSyOJHv5LH1dic1klFazs813Q3lzQNDfTCiOLQ k9wHsXs6e5gkMpmwOhFAaMSKy2Qa0700r6vWvTOnZA5mXmltRLG00AwZaIF67lRso16A /sORVa8pon3NOTdDIi5MYZmlul0eUPp+sY+A9ZTudGBrwA0fGN1C9U25d9uhv1clj582 RLlxGWDx5UsFnODyQIzTdirEN3ksdZb+rW3zS4wL1U9Askw0zWtQZd1CAsdgGghZMZMt xhcl+M2pPme6+5HwLJM4tsfMHZpGywRiYJUofi+UqqJtfVApPy9zd2mq5lF27kG+eK8y Ushw==
X-Gm-Message-State: APjAAAXBH7O+hKPtvpfvEaHop2BEHDj/2SysM4cedUzVNS5xMy9qjbD2 4n+3PGabS0fjDK9kMDzFIpVIHLZ9bHjKRthugPk=
X-Google-Smtp-Source: APXvYqypdC1HaIYuTf23y5q4bKWfnnAGCJgBKxYXk166pD1eQvNfiqM7IhdtVVukedwHu3gxnsfvstVW2SWRp89KFVU=
X-Received: by 2002:a6b:8f58:: with SMTP id r85mr2100897iod.308.1572477519634; Wed, 30 Oct 2019 16:18:39 -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>
In-Reply-To: <B23EE439-1509-43FB-9813-F330117DBF42@fugue.com>
From: Bud Millwood <budm@weird-solutions.com>
Date: Thu, 31 Oct 2019 00:18:28 +0100
Message-ID: <CAOpJ=k25ML8Z0_QRN8yoYdXut=tsZBwtBZEstceT45csb1Aunw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ioHfF1ji1svumd1EDXESl2zT_h8>
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: Wed, 30 Oct 2019 23:18:42 -0000

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.

> This would avoid the need for the CPE to keep this information in stable storage.
> So this isn’t going to be prefect (only storage on CPE will do that)

I'm leaning towards a server-side configuration option. Creating a new
option to request something that may or may not work doesn't seem
great.

- Bud

On Wed, Oct 30, 2019 at 11:43 PM Ted Lemon <mellon@fugue.com>; wrote:
>
> On Oct 30, 2019, at 6:23 PM, Bernie Volz (volz) <volz@cisco.com>; wrote:
> > I should point out that having the dhcp server supply this information may not work all the time. It really depends on what configuration changes were made and the server implementation. And of course is useless if you “move” the CPE.
>
> In this case the prefix would presumably no longer be valid; if it was valid and was offered as a deprecated prefix, it would cause no harm.
>
> I am not suggesting that this should just start happening with no testing.   What I am suggesting is that forcing firmware updates on CPE routers isn’t something we should be as chary of as we used to be.
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg