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, 08 November 2019 13:09 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 2865E120127 for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 05:09:36 -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 AY4BDlJarVAM for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 05:09:35 -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 F12E3120125 for <v6ops@ietf.org>; Fri, 8 Nov 2019 05:09:34 -0800 (PST)
Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:47d8:f164:391d:aabb:2971]) (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 C6BFF4E11B44; Fri, 8 Nov 2019 13:09:32 +0000 (UTC)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by astfgl.hanazo.no (Postfix) with ESMTP id AC4B621FD130; Fri, 8 Nov 2019 14:09:29 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com>
Date: Fri, 8 Nov 2019 14:09:29 +0100
Cc: v6ops list <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0222E46-E734-4996-8FB2-323E4013885B@employees.org>
References: <m1iPlMZ-0000J5C@stereo.hq.phicoh.net> <FACE45EC-27FC-437A-A5BF-D800DF089B50@fugue.com> <837E9523-14FC-4F6C-88FC-DCC316265299@employees.org> <CAO42Z2wz1H-x1O+k-ra09V=xON7GOYM+0uHkG0d3ExnsGNuDeA@mail.gmail.com> <03aad034-4e35-743f-975d-7d3c9f29b5cc@si6networks.com> <9EC75FDA-10A6-4FDC-BB42-EFC51C6631DE@steffann.nl> <6ecec6fd-4972-66dd-7e39-9c7ba6ec291f@si6networks.com> <B958A56E-1B79-40AF-93C6-80F0831259CC@employees.org> <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6IIHK645K3lMLByrOhT4sZNgEVk>
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, 08 Nov 2019 13:09:36 -0000

>>>>>> I think Ole observed that this is contrary to what the PD 
>>>>>> prefix's Valid Lifetime said would be the case. The ISP supplied 
>>>>>> a PD Prefix with a Valid Lifetime of X seconds, and then broke 
>>>>>> that promise by abruptly changing addressing before X seconds. 
>>>>>> ISPs should be expected to live up to their Valid Lifetime 
>>>>>> promises.
>>>>> 
>>>>> "Hope" doesn't make networks run properly.
>>>> 
>>>> This isn't "Hope", this is breaking promises, and that does break 
>>>> networks. If you can't at least trust that promises are intended to 
>>>> be kept then you have no network at all...
>>> 
>>> They are intended to be kept, but at times s* happens e.g., CPE routers
>>> don't crash and reboot on purpose.
>> 
>> This comment worries me.
>> That a CE reboots is _not_ the problem, nor does it cause the problem.
> 
> Well, if the CPE did keep state, there would be no problem. (is there a
> formal requirement for prefixes to be stable across crash & reboots?).

CPE is not required to keep state.
In PD the DR is in control, and should continue to delegate the same prefix as previously delegated.
If the RR includes prefixes in the request, those are purely there as hints for prefixes it would prefer.

> (just as a reminder, this is just one scenario. there have been at least
> three operators that have noted that their setups experience renumbering
> scenarios for other reasons... and slaac could certainly do much better
> in those)

You have to be clear what the root cause of a problem is.
The DHCP PD protocol is designed to carry leases over CPE reboots.

If an SP uses the opportunity caused by a reboot to flash renumber, then say so.

Ole