"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign lease to reserved host)
When resolving conflicts between active leases and host reservations, Kea relies on the client with the active lease to cooperate. When lease times are long, and the client with the active lease goes offline, the host with the reservation must wait for the lease to expire fully before it will be assigned to it.
This is a feature request for what the documentation calls the "naive approach" of just re-assigning IPs, at least for out-of-pool reservations.
I posted this to the Kea-Users mailing list in January, and got a bunch of replies, indicating that this feature would be appreciated by other users, too: https://lists.isc.org/pipermail/kea-users/2023-January/003847.html
Picture the following situation:
Initially:
- Leases are valid for a long time (11 days, per customer requirement)
- There is a host reservation for <mac1> and <ip1>
- The device with <mac1> got a lease for <ip1>
Now, the hardware is replaced and the reservation is updated, so the new device gets the same IP:
- remove reservation for <mac1> and <ip1>
- add reservation for <mac2> and <ip1>
- the old device is unplugged, and therefore cannot release its lease
- the new device is plugged in and requests a lease
Now, Kea looks for the host reservation for <mac2> and notices that <ip1> is still leased to <mac1>, so it refuses to reassign this IP.
I read through section 8.3.2 of the documentation, and the conflict resolution protocol used seems to not handle our case here (where the old device doesn't release its lease). It expects the old device with <mac1> to renew its lease, before responding with DHCPNAK and reallocating <ip1> to <mac2>.
The documentation describes that "A naive approach would to be immediately remove the existing lease for Host A and create a new one for Host B" -- this would be exactly what we want, and what our previous setup did.