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

Ole Troan <otroan@employees.org> Mon, 11 November 2019 21:25 UTC

Return-Path: <otroan@employees.org>
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 1FE59120877 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 13:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 v15muTF2huDn for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 13:25:33 -0800 (PST)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D488F120142 for <v6ops@ietf.org>; Mon, 11 Nov 2019 13:25:33 -0800 (PST)
Received: from astfgl.hanazo.no (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 2DC124E11A75; Mon, 11 Nov 2019 21:25:33 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id B6DE02298668; Mon, 11 Nov 2019 22:25:28 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CAHL_VyAS-5sDFQiWGGxmniKETh2ddAAPZxFpdrc+O9SxPXvj3Q@mail.gmail.com>
Date: Mon, 11 Nov 2019 22:25:28 +0100
Cc: Ted Lemon <mellon@fugue.com>, "v6ops@ietf.org list" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0091D6F-5AB7-4930-A7C4-676733AD6372@employees.org>
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com> <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <CAHL_VyAS-5sDFQiWGGxmniKETh2ddAAPZxFpdrc+O9SxPXvj3Q@mail.gmail.com>
To: Richard Patterson <richard@helix.net.nz>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3NkGLfQ2umhFrDT6vKfuB9UsPjI>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X" (Re: 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: Mon, 11 Nov 2019 21:25:35 -0000

> On Mon, 11 Nov 2019 at 17:11, Ted Lemon <mellon@fugue.com> wrote:
> Nobody is expecting you to never renumber.   Well, at least I am not. What I am talking about here is deliberate, opportunistic renumbering. If your topology changes and you have to renumber, so be it. If you can avoid that it’s better, and if you can give notice it’s also better. If you can do it gracefully with temporary routes, even better. But you shouldn’t be renumbering just ‘cuz. 
> 
> In that case I think we agree, an operator shouldn't intentionally renumber "just 'cuz".  However the scenarios I mentioned are far from the Operator going out of their way to not support stable prefixes. The question is just around how stable they are, and once you start having to ask that question, then shouldn't we be looking at ways to mitigate the impact to an end-user?

I agree with you, we should look at ways to mitigate the impact for the end-user.
Can we find a way that do that without relegating IPv6 end-users to be clients and consumers only, like they are on the NATed IPv4 Internet?

Would you join in effort to try to define how that would look like and what the gaps are?
The big question:
"What would it take to make a network with ephemeral addressing work (work as in not limit the user to only run "client only" applications)?"

And sure, there might be lower hanging fruits, but let's not pick those that can serve as encouragement that this addressing model works correctly today.

Best regards,
Ole