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

[Owen DeLong <[e-mail]>]

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
> 
>