IETF Logo Mail Archive

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 10:57 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 6FF7D120089 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 03:57:00 -0700 (PDT)
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 s9uHyC_l4Q1M for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 03:56:58 -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 919A812004E for <v6ops@ietf.org>; Fri, 1 Nov 2019 03:56:58 -0700 (PDT)
Received: from [192.168.10.190] (246.51-175-81.customer.lyse.net [51.175.81.246]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 7BA3A4E11AD4; Fri, 1 Nov 2019 10:56:57 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Fri, 01 Nov 2019 11:56:55 +0100
Message-Id: <94BBC308-365D-41A8-96FB-242BF63FFBF9@employees.org>
References: <m1iQUNM-0000KTC@stereo.hq.phicoh.net>
Cc: v6ops@ietf.org
In-Reply-To: <m1iQUNM-0000KTC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
X-Mailer: iPhone Mail (17B5084a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZWJxRKISiogW3BcPmDzmbv111jk>
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 10:57:00 -0000

Philip,

> On 1 Nov 2019, at 11:42, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
> 
> 
>> 
>>> "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...
> 
> Maybe somebody can do a text analysis and show which promise is broken.
> 
> The typical case is a CPE rebooting, requesting a prefix using DHCPv6 and
> getting a different prefix from before.
> 
> As far as I know, there is no text that requires a DHCPv6 server to return
> the previous lease if it is still valid.

As an author of rfc3633, let me tell what the intention of prefix delegation is. Then you can choose to bring your lawyer to argue the finer points to justify your use after. :-)

PD was intended as a fax replacement. Which was the typical provisioning mechanism at the time. The intention was that prefixes delegated had a lifetime equal to the length of the user’s contract with the ISP.

Lifetimes in PD give you an expiry date. E.g a value of 864000 means that the delegating entity promises that you are delegated and control this prefix until November 11th. Unless extended. 

There’s really little value in having both valid and preferred lifetimes in PD. 

The finer points of the DHCP machinery is really no excuse for this practice.

Ole


> The next question would be, if the CPE would try to renew the old prefix and
> the DHCPv6 server declines. Is there any text the requires a DHCPv6 server
> to do that.
> 
> Then the question is, if a CPE reboots can it continue to use the old lease?
> Typically, link attachment requires obtaining a new lease. But I don't know
> if that is specified anywhere. 
> 
> I do know that some routers do not install a forwarding entry if you don't 
> get a new lease. I don't think we have any spec for that.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email