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

[Ted Lemon <[e-mail]>]

On Oct 27, 2019, at 3:30 PM, Owen DeLong <[e-mail]> wrote:
> So this still requires that the CPE has written the lease to persistent storage. Currently many CPE do not do this.

Strictly speaking, if the CPE asks for a PD, and the server had already given it a prefix, it should get the same prefix, even if renumbering is happening; in the case of renumbering, it should get two prefixes, and should use one as the preferred prefix and the other as a deprecated prefix.   There is actually no need to write the prefix to stable storage if the DHCP server is behaving correctly.

However, in the case of incorrect behavior, end users will see more stable behavior in the case that the CPE remembers the old prefix.

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

Honestly, I have no idea.  But that is what the RFC says you should do.   If existing DHCP servers aren’t doing this, they are not fully implementing the specification.  I think in general, current DHCP servers just don’t allow you to cleanly deprecate a prefix, because nobody asked for this capability.   DHCP servers I know of will not renumber at all.   You can trick them into forcing a flash renumber by hacking the lease database, but that’s not correct behavior.

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

To which fix are you referring?