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> Fri, 01 November 2019 13:39 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 2EC64120142 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 06:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 NAnJyj9Zgs-I for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 06:39:03 -0700 (PDT)
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 0569712013A for <v6ops@ietf.org>; Fri, 1 Nov 2019 06:39:03 -0700 (PDT)
Received: from [IPv6:2a02:2121:280:6edf:11a4:ab34:580:9bbc] (unknown [IPv6:2a02:2121:280:6edf:11a4:ab34:580:9bbc]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 0FC774E11A42; Fri, 1 Nov 2019 13:39:01 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-2AE8114E-045A-46F4-BA13-EF3AF5F02C24
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 1 Nov 2019 14:38:58 +0100
Message-Id: <DB6DEE53-8B79-4D27-9E0E-B71644D1C6A0@employees.org>
References: <B586DB4C-7E4B-49CC-BC7F-7FAB98F47812@fugue.com>
Cc: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>, v6ops@ietf.org
In-Reply-To: <B586DB4C-7E4B-49CC-BC7F-7FAB98F47812@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (17B5084a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sdCVo77FM-1CMiLsCU8LYGwLIas>
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: Fri, 01 Nov 2019 13:39:04 -0000

Ted,

Ok. Thanks. I don’t think I have heard from anyone who thinks there’s a gap with regards to pd and renumbering before. Or renumbering with addresses for that matter.

The main issue here seems that people want to do renumbering differently. Then we as a community have to figure out how harmful that is to the Internet. Or what other changes would be required for that. 

Cheers 
Ole

> On 1 Nov 2019, at 13:57, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Nov 1, 2019, at 8:36 AM, Ole Troan <otroan@employees.org> wrote:
>> (4) is the definition of graceful renumbering. What makes you conclude "then we just assume that people will do whatever they want"?
>> (especially since your options 1-3 are exactly that, people do whatever they want…)
> 
> Okay, I missed a step (or five).  We have specified what a renumbering process should ideally look like, without taking into account several likely operational circumstances.  We have not specified in sufficient detail how renumbering works using DHCPv6 PD, e.g. in a home environment.  Consequently, providers do not have a viable way to follow our recommendations for how to renumber, and hence just do whatever they can think of, possibly without realizing that there might be a better way to do it.   Also, DHCP server vendors in particular do not implement what we intended that they implement, because we never said explicitly that they should do so, not specified what a CPE should expect in this situation.
> 
> Does that help?
> 
> FWIW, I was asked to consult with an operator who shall remain nameless about how to solve this problem, and the solution I came up with relied on the recommendations from RFC 4192. and further relied on DHCPv6 prefix delegation offering two prefixes, one valid and one preferred.  Unfortunately I don’t think this was ever implemented, but I still think it’s the right thing to do; what I’m realizing from this conversation is that not everybody saw this solution as obvious.   Which I think is a problem.
>