Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X"

sthaug@nethelp.no Fri, 01 November 2019 11:44 UTC

Return-Path: <sthaug@nethelp.no>
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 24DDD120828 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 04:44:15 -0700 (PDT)
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 3oRdJ1B7o7Nn for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 04:44:13 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6428120822 for <v6ops@ietf.org>; Fri, 1 Nov 2019 04:44:12 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id 49B07E6079; Fri, 1 Nov 2019 12:44:09 +0100 (CET)
Date: Fri, 01 Nov 2019 12:44:09 +0100 (CET)
Message-Id: <20191101.124409.30333597.sthaug@nethelp.no>
To: otroan@employees.org
Cc: mellon@fugue.com, v6ops@ietf.org
From: sthaug@nethelp.no
In-Reply-To: <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org>
References: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org> <D3B1E770-F199-4605-BF78-A3637D6CDB42@fugue.com> <4288FBC0-C421-464F-9D55-7FB77AA1FA4E@employees.org>
X-Mailer: Mew version 6.7 on Emacs 26 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/CHx5wm1qQx7bf8trSgQcN0t8e8w>
Subject: Re: [v6ops] A broken promise - "You said PD Prefix Valid Lifetime is going to be X"
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 11:44:15 -0000

>> Now, I think what you just said was that none of these scenarios are valid, because the ISP should never renumber the customer.   Is that correct?
>> 
> 
> Neither of your options have IETF consensus behind them. DHCP PD supports renumbering, but it also says:
> 
>    "Many applications expect stable addresses.  Even though this
>    mechanism makes automatic renumbering easier, it is expected that
>    prefixes have a long lifespan.  During renumbering it is expected
>    that the old and the new prefix co-exist for some time."
> 
> RFC4192 is as far as I know the most complete graceful renumbering description.
> 
> To continue my example:
> 
> (4) Continue to delegate prefix A with a lifetime expiring on November 11. On November 4th start also delegating prefix B with a lifetime expiring December 31st 2022.
>     On November 11th, stop advertising prefix A.
> 
> This is how IPv6 renumbering has been specified for 20 years... I presume that was not news?

A comment from an operator perspective:

- We don't "flash renumber" DHCP customers if we can avoid it.
- Sometimes a DHCP customer needs to be moved to a new router or
cluster of routers. This also implies that the customer will be
renumbered.
- We normally perform such moves as a planned activity, during
nighttime, with alerts to customers beforehand.
- We *don't* start delegating new prefixes in advance (and that
would be somewhat difficult in any case since they "belong" to
the router the customer will be moved to). We have no plans to
change this.

So - TL;DR: We don't do "flash renumbering" for fun, on the other
hand we also don't strictly follow RFC 4192.

Steinar Haug, AS2116