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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 08 November 2019 13:15 UTC

Return-Path: <alexandre.petrescu@gmail.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 D6D8612008C for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 05:15:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] 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 bBOoKmCFAse2 for <v6ops@ietfa.amsl.com>; Fri, 8 Nov 2019 05:15:45 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC9212006F for <v6ops@ietf.org>; Fri, 8 Nov 2019 05:15:44 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA8DFgMQ001371 for <v6ops@ietf.org>; Fri, 8 Nov 2019 14:15:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DE76B2059B2 for <v6ops@ietf.org>; Fri, 8 Nov 2019 14:15:42 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D46C02016B7 for <v6ops@ietf.org>; Fri, 8 Nov 2019 14:15:42 +0100 (CET)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xA8DFgKn013247 for <v6ops@ietf.org>; Fri, 8 Nov 2019 14:15:42 +0100
To: v6ops@ietf.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>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <42bd669d-a18b-ef1a-beba-b73f0e5d3448@gmail.com>
Date: Fri, 8 Nov 2019 14:15:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <404f30c0-4162-c33b-ae83-3700eb723ca9@si6networks.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Xxxjthh1w0lktnFg12siS-kSPD8>
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:15:47 -0000


Le 08/11/2019 à 13:55, Fernando Gont a écrit :
> On 8/11/19 09:47, Ole Troan wrote:
>>>>>> 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?).

Probably there is no formal requirement for prefixes to be stable across
crashes and reboots[*], but there is a behaviour of the client to send
CONFIRM after reboot or wake-up from sleep, as described in the RFC DHCPv6.

That is how my home network work with DHCPv6 for addresses: the Windows
client reboots and sends CONFIRM to DHCPv6 server on CPE, who agrees
with it in turn.  So the same address is being used by the Client after
reboot.

I suspect it should work the same way when PD is implemented.

Alex

[*]: as for formal requirements for prefix stability:
- there are commitments from certain cellular operator to maintain a
stable IPv4 address for a cellular User Equipment;
- there are cellular operators open to at least try to provide stable
IPv6 addresses to smartphone users by using DHCPv6.
- there are are commitments (some times unwritten, but visible in their
design of use of static IPv6 addresses per intermediary equipment) from
some ADSL ISPs to provide stable IPv4 and IPv6 addresses to home networks;


> 
> (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)
> 
> Thanks,
>