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

["Bernie Volz (volz)" <[e-mail]>]

Owen .. this is IF the device remembers (i.e., writes the information to persistent storage).

> A rebind is not going to get useful timer data in response.

Yes, it should. This is because the CPE will include its existing (remembered) prefixes in the Rebind and the server that receives this can immediately respond with lifetimes of 0 if the PDs are no longer valid for where the CPE is "now" connected. Which is exactly what you wanted the device to know.

Here's text from https://tools.ietf.org/html/rfc8415#section-18.3.5:

   If the server finds that the client entry for the IA and any of the
   addresses or delegated prefixes are no longer appropriate for the
   link to which the client's interface is attached according to the
   server's explicit configuration information, the server returns those
   addresses or delegated prefixes to the client with lifetimes of 0.

- Bernie

-----Original Message-----
From: Owen DeLong <[e-mail]> 
Sent: Friday, November 1, 2019 2:15 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: Fernando Gont <[e-mail]>; [e-mail]
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

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) <[e-mail]> 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" <[e-mail] on behalf of [e-mail]> wrote:
> 
> 
> 
>> On Oct 31, 2019, at 8:06 PM, Fernando Gont <[e-mail]> wrote:
>> 
>> On 31/10/19 16:39, Owen DeLong wrote:
>>> 
>>> 
>>>> On Oct 31, 2019, at 12:25 PM, Fernando Gont <[e-mail]> wrote:
>>>> 
>>>> On 27/10/19 10:54, Ted Lemon wrote:
>>>>> On Oct 27, 2019, at 9:41 AM, Philip Homburg 
>>>>> <[e-mail] <mailto:[e-mail]>> 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: [e-mail]
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
> 
>    _______________________________________________
>    v6ops mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
>