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

[Fernando Gont <[e-mail]>]

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.



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