Re: [v6ops] WG Last Call on draft-ietf-v6ops-cpe-slaac-renum

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

Hi - inline (BV>).

- Bernie

On 4/6/20, 1:18 PM, "Fernando Gont" <[e-mail]> wrote:

    Hi, Ole,
    
    On 6/4/20 13:08, [e-mail] wrote:
    [...]
    >> Yes, when the old PD is switched to a new PD, the server would be expected to send the old PD with 0 lifetimes. But how long will the server remember this is the key question and, for example if 30 days were remaining on the old PD, it should keep sending it for 30 days.
    > 
    > I don't think that necessarily follows.
    > The delegating server is allowed to change the lifetimes of the old prefix, so I would imagine it was only necessary to include the old prefix in one DHCP exchange.
    
    Since the DHCPv6-PD client could come back anytime withing the DHCPv6-PD 
    lease time of the stale prefix, the DHCPv6 server would need to remember 
    this for such period of time. I assume that's what Bernie meant.
  
BV> Correct. The server would be obligated to retain it until the (longest) valid lifetime it had sent the client expired. The question is how the server knows when a DHCP exchange is complete (just because it sent a Reply is not a guarantee the client received it). And, if it does use that then the issue is that this doesn't help the CPE if it rebooted after this (or even) several exchanges as there could still be clients behind the CPE that have not received an updated RA with the deprecated prefix.

    >> If you read the text of the proposed draft, it only puts a requirement on the CPE:
    >>
    >> 2.2.  Signaling Stale Configuration Information
    >>
    >>    In order to phase-out stale configuration information:
    >>
    >>    o  A CE 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, and the "A" and "L" flags of the corresponding
    >>       PIOs.
    > 
    > Yes, and as I said that's a band-aid for a broken deployment.
    > And suggested that a paragraph explaining the correct renumbering procedure was added. To avoid confusion.
    > Not all CPEs are ever going to do this anyway.
    
    How about adding this:
        IPv6 network renumbering is expected to take place in a planned
        manner, with old/stale prefixes being phased-out via reduced prefix
        lifetimes while new prefixes (with normal lifetimes) are introduced.
        However, there are a number of scenarios that may lead to the so-
        called "flash-renumbering" events, where the prefix being employed on
        a network suddenly becomes invalid and replaced by a new prefix
        [I-D.ietf-v6ops-slaac-renum]. One of such scenarios is that in which
        a DHCPv6-server employs dynamic prefixes, and the Customer Edge
        Router crashes and reboots. The requirement in this section is meant
        to allow Customer Edge Routers to deprecate stale information in such
        scenarios.
    
    to the RATIONALE in Section 2.2?
    
    Thanks,
    -- 
    Fernando Gont
    SI6 Networks
    e-mail: [e-mail]
    PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492