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

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

>    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