Kea: permit reservation to be created without "ip address" field

[whezzel]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guidelines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

The DHCP reservation form (Services -> Kea DHCP -> Kea DHCPv4 -> Reservations; add new reservation) prevents the creation of new reservations if the IP address field is not set. In ISC DHCP, the IP address field is optional, and since Kea is poised to replace ISC DHCP, it should match the functionality where possible.

Per Kea documentation, this is a supported configuration for reservations (https://kb.isc.org/docs/what-are-host-reservations-how-to-use-them#example-addresses-prefixes)

Every host reservation must reserve at least one resource; if not, Kea complains at configure time. Resources include address, prefixes, options, hostname, and client classes.

Describe the solution you like

I would like to be able to create reservations without being required to set an IP address. This would primarily be used to set a specific hostname on a device that does not return the correct hostname, without setting a specific IP on that device.

Describe alternatives you considered

• Create a DHCP reservation with an IP address configured.
• Manually configure Kea and set reservations directly in the config files without using the Web UI.

Additional context

Add any other context or screenshots about the feature request here or links to relevant forum thread or similar

[Monviech]

Why not reserve both hostname and IP? Essentially that should not matter much.

I'm just going to push back a little at making every field optional because I did the host reservation in dnsmasq and there anything is very optional, in the end confusing the user more than it helps and inflating the complexity of the template, model and validations.

Right now I have a PR open where you can decide between IP address and prefix for a reservation, though having some IP address as primitive makes sense here.

Also the lease reservation logic compares duid and mac address to existing reservations, if one of them only has a hostname it would also show as static right now even though no IP address exists.

All in all it's a bit challenging not make this bad from a GUI perspective I'm afraid.

From a model perspective a hostname is also no resource a DHCP server can allocate, even though KEA allows it its more of an override. A DHCP server should allocate resources as IP addresses.

Please give one or two real usecases (not just festure parity with ISC) that is not possible without this functionality.

[whezzel]

I understand your concerns about keeping the GUI clean and avoiding the complexity you ran into with dnsmasq. That makes sense.

The main reason I want hostname-only reservations is for Dynamic DNS updates.

I have roughly 60 ESP32 / Espressif devices that all report the exact same generic hostname (espressif.domain.tld) regardless of the actual hostnames that are set on them. This creates hostname collisions, so dynamic DNS updates fail for them. I do not need or want to assign them static IPs. I just want to override their hostname based on MAC or DUID (just like I could do in the old ISC DHCP server).

It is not a deal-breaker, but it does add extra work during migration and ongoing management since I now have to pick and reserve IPs I never needed before.

[Monviech]

You’re already maintaining a mapping (device to hostname). Extending that to include an IP keeps the system deterministic and aligned with how reservations are modeled (in the OPNsense GUI)

Introducing hostname-only reservations would reduce some configuration effort, but at the cost of added complexity and ambiguity in the GUI and lease handling.

Lets keep this open for now and see how many users request it.

As reference even something "simple" like this might already leak complexity: #10206 (comment)

[alexwbaule]

I build a PR to permit that.

#10401

[tkreagan]

First, I have a draft PR to just do the hostname part - #10423

Second, I am also feeling the pain of IoT devices overloading a single hostname. This is a very common thing to experience, and there aren't many good solutions.

I do think there is real validity to allowing hostname-only reservations. Most importantly, it keeps things very simple from an admin standpoint - if you have to renumber, it's all automatically inherited from upstream.

I agree we don't want to proliferate endless optionality in the configuration - if you want to set DHCP Option 8 - Cookie Server per client, then you probably need to fall back to a manual config. But hostname is a first-class configuration option in Kea, with its own separate section in the docs (https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#reserving-a-hostname) so I think letting people do something pretty basic like is appropriate and easy to distinguish from an infinite array of knobs.

I also think we would benefit from some reorg / simplification of the reservation configuration screen to more clearly distinguish the "inputs" - host-reservation-identifiers - from the "outputs" - address / hostname / DHCP options. I am working on a pull request to support this, but would like support for addressing this issue first.

[tkreagan]

There's another way to deal with the overlapping hostnames - I put it into a new issue / feature request here - #10425