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

Fernando Gont <fgont@si6networks.com> Tue, 12 November 2019 00:13 UTC

Return-Path: <fgont@si6networks.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 B03221200E0 for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 16:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LSP-SFiJWpMp for <v6ops@ietfa.amsl.com>; Mon, 11 Nov 2019 16:13:18 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB8F1200B6 for <v6ops@ietf.org>; Mon, 11 Nov 2019 16:13:18 -0800 (PST)
Received: from [192.168.1.32] (201-26-46-36.dsl.telesp.net.br [201.26.46.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 941B48606E; Tue, 12 Nov 2019 01:13:14 +0100 (CET)
To: Ole Troan <otroan@employees.org>, Richard Patterson <richard@helix.net.nz>
Cc: "v6ops@ietf.org list" <v6ops@ietf.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>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <3d55e9ba-d761-1497-455a-8a75fc014319@si6networks.com>
Date: Mon, 11 Nov 2019 21:13:06 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <F0091D6F-5AB7-4930-A7C4-676733AD6372@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/oE5ZjavEGLI4mxhQ4576FxG2px4>
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: Tue, 12 Nov 2019 00:13:21 -0000

On 11/11/19 18:25, Ole Troan 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)?"

+ IPv6 UPnP support for punching holes in the fw (a big fail for many CPEs)
+ Resilience to renumbering (slaac-renum)
+ Dynamic DNS updates


In the IPv4 world, assuming no CGNAT, this works just fine:

+ there's IPv4 UPnP suport
+ renumbering is masqueraded by NATs
+ You do dynamic DNS updates with small TTLs

P.S.: Since nobody guarantees there will be no fw and not renumbering,
you have to accommodate for them, or plan to fail.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492