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

Ted Lemon <mellon@fugue.com> Wed, 30 October 2019 21:59 UTC

Return-Path: <mellon@fugue.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 546B412012C for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 14:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 1nGFXVwdsHEe for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 14:59:04 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 3123712011A for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:59:04 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id y39so5568534qty.0 for <v6ops@ietf.org>; Wed, 30 Oct 2019 14:59:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4KElR8MQMUqs3BIH+POYDYIf4tc3+IG6ax/OocOIATA=; b=T237j1bJZFIRiyWgMDmr6+LWWRo3m8WT1195S37Uoxn5ukEspd8Vz8OOwpq7xfLOQX ArkNL2L78387kOJshXC0y+Wahl3huytI2pLA4aDwT0UAkbGKM0K+c8YYoeRhM09MryFg yjvh/wn6FWBM46yhHyP8ByeKKhG9o3Pvso+ZpHzU1s7AIfAcKB7RUDx4lkHkVzsjkhxL x5bcyiM82m867dgcrxOX7tWp3kqVWOxjvwWiWgrPek5S8+mEJId9pOzn9iIkc7Peqj1x 5oCmKIPTPM7kvr4HTa7MlRgH9iSziWfl9Cy/KAarBP9SFJqsqPP2m08WWl5pyShjN3iF 6uCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4KElR8MQMUqs3BIH+POYDYIf4tc3+IG6ax/OocOIATA=; b=kKd6dftrMsT9W6MfHw5De0iqjnnc9GwYMMM5ZaR9uYoJtW+Y5nLA3coktGWjnFoNdX 3ZJd7vGykSWuv2ST6UetywFq736lDpjP7BFCH6cs/n1ui4Tvx8Vi5KAyzkbuV00qDoGq c6mHLtullHQiiVJ3PRx6UIfZ77amQUzoJClNLLre3SrhGlwzcv/U77uY9HhpChESgCmx SXHWLZRMCkuzspiA0ACbO3HcbaObOwFG8aod04T7JHa4IPZO+rlfzb0rrKEgMZIdB9T1 TOw8XeIXD0fTFcjXZGn5lADj5QAzxg0+ekVzBr6A8kfXryRTIUiTJs8TggvGyQrpNfLN x19A==
X-Gm-Message-State: APjAAAWIfX52WGyLx9Wl8P/s308aVoVrNkIyR+jdOb9bL7FmAI8/3+3+ TAxrw28j9PUcVHc4vy53/ZAvWg==
X-Google-Smtp-Source: APXvYqx84Dov4TwoXbUO/GsJ1piAs7kODDPOzbswXlzoMEr7D8C4D7aHR+6Q6cPu4xoZcToNc7laew==
X-Received: by 2002:ac8:2fba:: with SMTP id l55mr2396553qta.167.1572472743125; Wed, 30 Oct 2019 14:59:03 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:c5ad:3e58:9e29:c076? ([2601:18b:300:36ee:c5ad:3e58:9e29:c076]) by smtp.gmail.com with ESMTPSA id s67sm723423qkh.70.2019.10.30.14.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Oct 2019 14:59:02 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <B7085E51-25BF-4705-BF54-1C3CACC3815E@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ABAACE6E-7661-4DA5-8269-58A53B65D4D8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Wed, 30 Oct 2019 17:59:00 -0400
In-Reply-To: <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, IPv6 Operations <v6ops@ietf.org>
To: Bud Millwood <budm@weird-solutions.com>
References: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com> <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9gJdwzpqxJ62IUO82RR9Xbw6GIY>
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 21:59:06 -0000

On Oct 30, 2019, at 5:52 PM, Bud Millwood <budm@weird-solutions.com> wrote:
> I wonder if introducing suggestions (1) or (2) aren't pushing existing
> clients to expose new bugs they may have? Suggestion (4) seems
> reasonable to me.

Clients that have bugs should be updated.  Routers that aren’t updatable should be binned.   Sites that have massive numbers of non-updatable routers that can’t be updated don’t have to turn the feature on.   I think it’s fine to make this a server configuration parameter.

The benefit to doing this correctly is that it’s arguably already correct.  There are likely routers out there that will already do the right thing when they get a deprecated prefix.   The most likely use case for a deprecated prefix is not that it has a valid lifetime of zero, but that it has a preferred lifetime of zero: a graceful renumbering event.   DHCPv6 should already support graceful renumbering.   This was a design goal.