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

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

>I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

That is actually the RFC8415 specified behavior … the DHCP server I work on (Cisco Prime Network Registrar) will do this if steps are taken to “invalidate” a lease.

See RFC 8415, Section 18.3.4:

   If the server finds that any of the addresses in the IA are not
   appropriate for the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.

   If the server finds that any of the delegated prefixes in the IA are
   not appropriate for the link to which the client is attached, the
   server returns the delegated prefix to the client with lifetimes
   of 0.


  *   Bernie

From: v6ops <[e-mail]> on behalf of Owen DeLong <[e-mail]>
Date: Sunday, October 27, 2019 at 4:18 PM
To: Ted Lemon <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds




On Oct 27, 2019, at 06:54 , Ted Lemon <[e-mail]<mailto:[e-mail]>> 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).  If the lease on the address is still valid, the ISP should renew the lease and not issue a new one.   It is a misconfiguration for some other thing to happen in this case.   This would then re-establish the route in the ISP edge router.

So this still requires that the CPE has written the lease to persistent storage. Currently many CPE do not do this.

I agree that the CPE should attempt to reconfirm/renew the existing prefix lease. However, if that fails for some reason (and there are multiple scenarios which present valid reasons this could fail without misconfiguration on either side), I think that the behavior described is preferable to simply removing the old prefix from RAs and waiting for them to time out on the unsuspecting hosts. Especially in the case of 1 week preferred and 1 month valid lifetime timers.

If the ISP wants to deprecate the old prefix, the thing to do is not to fail to renew it, but rather to renew it with a preferred lifetime of zero and offer another prefix with a preferred lifetime that is not zero.   The CPE router should in this case advertise both prefixes, with the applicable lifetimes.  Using my limited SEND proposal, the advertisement with a preferred lifetime of zero would be immediately seen by all hosts that implement limited SEND, and they would start using the new preferred prefix.  Hosts that don’t implement limited SEND would still behave correctly, but might take longer to stop using the old prefix.  This should be okay because the old valid lifetime is still valid.

Can you point to any authoritative document which supports this particular mechanism?

I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

That’s the way things should go when everything is working correctly.   If however the ISP’s DHCP server loses its cookies and can’t renew the old prefix, then we’d see the new behavior where hosts that implement limited SEND could immediately see that the old prefix was no longer usable, and would stop using it in preference to the new prefix.   Hosts that don’t implement limited SEND would behave as they behave today.

While there may be advantages to limited SEND, I don’t see that as a reason not to implement this particular fix across the board since it would benefit both hosts implementing limited SEND as well as hosts not implementing it.

Owen