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

Mark Andrews <marka@isc.org> Mon, 11 November 2019 21:56 UTC

Return-Path: <marka@isc.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 49FA2120893 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 13:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TYRIMJKK_OCT for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 13:56:56 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B7F120089 for <v6ops@ietf.org>; Mon, 11 Nov 2019 13:56:56 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 9FFA23AB00A; Mon, 11 Nov 2019 21:56:55 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 772D116005C; Mon, 11 Nov 2019 21:56:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 47DC516007A; Mon, 11 Nov 2019 21:56:55 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mJmlJXsFX1Zh; Mon, 11 Nov 2019 21:56:55 +0000 (UTC)
Received: from [172.30.42.69] (n1-40-244-161.bla1.nsw.optusnet.com.au [1.40.244.161]) by zmx1.isc.org (Postfix) with ESMTPSA id 3C4C616005C; Mon, 11 Nov 2019 21:56:54 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <F0091D6F-5AB7-4930-A7C4-676733AD6372@employees.org>
Date: Tue, 12 Nov 2019 08:56:51 +1100
Cc: Richard Patterson <richard@helix.net.nz>, "v6ops@ietf.org list" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A290AB5-8CEB-44E6-9A89-5D10160E5B63@isc.org>
References: <CAHL_VyBC3NbT4b-mnacU+ZmzyXus4HXcKx9ykdWJ3_a2uJCi4g@mail.gmail.com> <903CD569-A1A6-4BEC-A1FE-69706D04CF88@fugue.com> <CAHL_VyAS-5sDFQiWGGxmniKETh2ddAAPZxFpdrc+O9SxPXvj3Q@mail.gmail.com> <F0091D6F-5AB7-4930-A7C4-676733AD6372@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hLIsFqcTayJg3Hhn4_L7PiCDOC8>
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:56:58 -0000


> On 12 Nov 2019, at 08:25, Ole Troan <otroan@employees.org> wrote:
> 
>> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

One low piece of hanging fruit is getting nodes to register themselves in the DNS
when their addresses change.  This is easy to do with DNS UPDATE (RFC 2136) and SIG(0)
(RFC 2931).  It just requires that a KEY record be added to the DNS for the UPDATE
request to be authenticated against when the node is commissioned.  That can be done
with DNS UPDATE and TSIG (RFC 2845) or SIG(0).

Similarly registering PTR records for themselves when they get new addresses.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org