Modification of handling of global reservations with IP addresses set

Customer request, ref: https://support.isc.org/Ticket/Display.html?id=21365

NOTE: Support ticket has patches that have been reviewed by Thomas and Francis and are not seen as appropriate. It would appear that the customers need is real and that we should determine a good course forward.

---

Ticket narrative provided below:

I would like to put in a feature request to modify the handling of global reservations with IP addresses set.

Background

I'd like to detail some of our use case and the behaviors we have had to work around in our Kea implementation. We have created a self-service portal for users to register their devices to access the network. In the general case, this consists of a user giving us a MAC address and an FQDN for us to create a host reservation with, but we do allow IT administrators to reserve IP addresses as well. Even when a user requests a certain IP address, we do not necessarily restrict them from only using that network; i.e. they should be able to get a valid IP address in any network (with DDNS determined by the subnet they land in).

A few behaviors we've ran into using global host reservations:

1. Global reservations with IP addresses do no bounds checking on if the IP address is correct for a subnet. a) If a device requests an address from a shared-network that does not contain its IP address, it will receive an address which cannot be used b) If a device requests an address from a shared-network that does contain its IP address, but it's IP address is not a part of the subnet with the lowest ID, it will receive the correct address but incorrect options (e.g. routers).
2. Updated reservation MAC addresses may create conflicts when a lease with the old MAC address still exists (we use match-client-id: false)
3. I suspect that updated reservation FQDNs do not reflect when a client lease is updated, but have not verified

We have worked around issues 1b, 2, and 3 by modifying leases through the API via the self-service portal. On every create of update of a device with an IP reservation in our self-service portal, we ensure that the hostname, MAC address, and subnet-id on the lease(s) match what we expect. (1a) is still an issue for us and requires manual intervention to either move the device into the shared-network where it should exist, or change the host reservation to be in the shared-network where the device currently resides.

I understand there is a workaround: create two reservations (one global without an IP address and one inside the subnet with an IP address). This increases our complexity by adding another data store to keep in sync, and I believe could end up reducing performance due to more host lookups. It's my opinion that the current global reservation behavior is a footgun which can be easily avoided, and the requested behavior is more in line with what users of ISC DHCPd would expect.

Feature Request

Kea should only hand out feasible addresses to clients and correctly match leases to subnets for global reservations with IP addresses.

Current behavior:

• if a host reservation does not have an IP address:

  • defer to normal dynamic lease creation

• if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:

  • create/reuse a lease tied to the first subnet that the client class allows

• if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network

  • create/reuse a lease tied to a subnet unfit for the IP address

Requested behavior:

• if a host reservation does not have an IP address:

  • defer to normal dynamic lease creation

• if a host reservation has an IP address, and the IP address overlaps with any subnet within a shared network:

  • create/reuse a lease tied to the matching subnet

• if a host reservation has an IP address, and the IP address does not overlap with any subnet in a shared network

  • defer to normal dynamic lease creation

I have attached a patch series to implement this behavior for both DHCPv4 and DHCPv6 IA_NA reservations. Descriptions of the patches are below:

• alloc_engine4.patch: implements requested behavior for DHCPv4 reservations
• alloc_engine_tests4.patch: implements tests for requested behavior in DHCPv4
• alloc_engine6.patch: implements requested behavior for DHCPv6 IA_NA reservations
• alloc_engine_tests6.patch: implements tests for requested behavior in DHCPv6