Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Owen DeLong <owen@delong.com> Fri, 01 November 2019 18:14 UTC

Return-Path: <owen@delong.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 5596D120F5E for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 l_WrxHIoqh1a for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 11:14:55 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 99AE4120F20 for <v6ops@ietf.org>; Fri, 1 Nov 2019 11:14:48 -0700 (PDT)
Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1IEX4Y019328 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 11:14:34 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1IEX4Y019328
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572632076; bh=6Aik4EGAChy2NnGoFi4zgmeeyBsd6B6jpQqisMEJUBA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OmTYNaw7Fr9uNngcdib8cor4tjKzBqUa5bqdzVoAOJssUUvGcy60i8YtZsKvoMItD 7vbU/VqHknXdnHjK2Ypgw46VktoqqXcIYuojrocYekjCeG2fYVNBqkHFU+WWP15U8i C6wV0rT6qnQCNBdlkZur8iaBs3JQ9ENUYFerhsqw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <B1BF35FC-852E-43C7-847D-7C62C7418E6E@cisco.com>
Date: Fri, 1 Nov 2019 11:14:32 -0700
Cc: Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <020501A3-CF94-474A-8763-1DC9E111B865@delong.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <e67f597d-93a7-3882-3a12-69519178893d@foobar.org> <m1iOinq-0000J3C@stereo.hq.phicoh.net> <DC2F31E2-8CA4-483A-B1A1-6730A904BA32@fugue.com> <c06adfb0-1bab-d177-96e4-d1263e618000@si6networks.com> <E9C816FC-57A7-49A9-A4E3-90A3E2F38D5D@delong.com> <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> <B1BF35FC-852E-43C7-847D-7C62C7418E6E@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 11:14:36 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i1T0VvM_3XGyjnAfth9cLUm9dfI>
Subject: Re: [v6ops] 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 18:14:57 -0000

Rebind isn’t the same as remembering.

Consider the situation where a cable provider rehouse the customer to an entirely different CMTS which may utilize an entirely different DHCP server. A rebind is not going to get useful timer data in response.

Owen


> On Nov 1, 2019, at 9:16 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> 
>>   Where is the mention of storing the expiration times?
> 
> Also, based on RFC8415 this means that the client should use a DHCPv6 Rebind when it powers back on as now it has the information to ask whether it is still valid (assuming it hasn't expired)?
> 
> See Section 18.2.18 of RFC8415:
> 
>   Whenever a client may have moved to a new link, the
>   prefixes/addresses assigned to the interfaces on that link may no
>   longer be appropriate for the link to which the client is attached.
>   Examples of times when a client may have moved to a new link include
>   the following:
> 
>   -  The client reboots (and has stable storage and persistent DHCP
>      state).
> 
>   -  The client is reconnected to a link on which it has obtained
>      leases.
> 
>   -  The client returns from sleep mode.
> 
>   -  The client changes access points (e.g., if using Wi-Fi
>      technology).
> ...
> 
>   If the client has any valid delegated prefixes obtained from the DHCP
>   server, the client MUST initiate a Rebind/Reply message exchange as
> ...
> 
> 
> - Bernie
> 
> On 11/1/19, 11:41 AM, "v6ops on behalf of Owen DeLong" <v6ops-bounces@ietf.org on behalf of owen@delong.com> wrote:
> 
> 
> 
>> On Oct 31, 2019, at 8:06 PM, Fernando Gont <fgont@si6networks.com> wrote:
>> 
>> On 31/10/19 16:39, Owen DeLong wrote:
>>> 
>>> 
>>>> On Oct 31, 2019, at 12:25 PM, Fernando Gont <fgont@si6networks.com> wrote:
>>>> 
>>>> On 27/10/19 10:54, Ted Lemon wrote:
>>>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com
>>>>> <mailto:pch-v6ops-9@u-1.phicoh.com>> wrote:
>>>>>> The little bit missing is that the CPE should write prefixes
>>>>>> advertised using
>>>>>> SLAAC to persistent storage which allows the CPE to invalidate stale
>>>>>> prefixes
>>>>>> after a reboot.
>>>>> 
>>>>> Actually I do not believe this is correct behavior.   Let us assume
>>>>> prefix delegation.   If we have prefix delegation, then when the CPE
>>>>> comes back from a power cycle, it should reconfirm the prefix it had
>>>>> previously; the assumption is that that prefix is still valid.  This can
>>>>> be handled in infrastructure—the ISP edge router should know whether the
>>>>> prefix is still valid, because if it is it should be advertising a route
>>>>> for it.   If it is not still valid, then the CPE router should attempt
>>>>> to renew it, which would go to the DHCP server (possibly both messages
>>>>> would).
>>>> 
>>>> That assues the CPE has stored the previously-leased prefix on stable
>>>> storage -- which does not need to be the case. Hence the related text in
>>>> our I-D.
>>> 
>>> IMHO, the CPE requirements should be increased and the CPE should be required
>>> to store the prefix and it’s expected valid and preferred expiration times in persistent
>>> storage. I would like to see the text in the I-D updated accordingly.
>> 
>> It's already there (draft-gont-v6ops-slaac-renum-00):
>> 
>> 3.2.1.  Signaling Stale Configuration Information
>> 
>>  In order to phase-out stale configuration information:
>> 
>>  o  A CPE router sending RAs that advertise dynamically-learned
>>     prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
>>     stable storage, the list of prefixes being advertised on each
>>     network segment.
> 
>    Where is the mention of storing the expiration times?
> 
>    Did I miss it, or did you miss that part of my comment?
> 
>    Owen
> 
>> 
>> 
>> Thanks!
>> 
>> Cheers,
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
> 
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
>