Questions about DHCPd: new service on the agenda? DHCP pool restrictions?

JeGr

Hi there,

as ISC has officially EOL'ed ISC-DHCPD at the end of 2022, what are the plans going forward?
Are you thinking about using the new implementation of ISC (kea) or is it more a OpenBSD-like scenario where FreeBSD did the same as Open with maintaining its own version of isc-dhcpd that isn't related to the upstreams EOL? As I'm not that deep into FreeBSDs packages that would be nice to know.
On another note, the ISC implementation had support - for many years now - to add static IP4 reservations in the same IP space as the pool. A restriction that is but still enforced by pfSense GUI part that won't let you create static mappings if it collides with the DHCP pool range.
Is there a quick possibility to remove that restriction? As many service providers we have a lot of customers migrating from other systems where the majority seems to allow exactly that. Be it Cisco, Microsofts own DHCPd etc. etc. - we have a lot of configurations that we have to workaround with unnecessary complex DHCP Pool configs (e.g. 20-80,84-89,92-105,113-200 to avoid conflict of static mappings) just to accommodate the old setup that can't be easily switched.

jimp

Yes, it's EOL. We'll be working on moving to Kea but not for this release. We've been using Kea with much success on TNSR, so we are hopeful that is the best path forward. That said, we still need to look into how it does things like failover pools.
Mappings inside the pool(s) are not reservations in ISC DHCPD, they are preferences. "Static" mapping addresses inside pools can be assigned to dynamic clients since they are a part of the pool. Then if the static mapping client comes along later they'd get some other random address. For this reason we prevent defining them in the GUI. Removing the input validation can be done if you want them in your setup, but it would not be something we would consider changing for everyone. Since they behave differently I suspect customers would be shocked to find out their addresses were not reserved like they wanted if you just bypass the input validation.

I'm not sure how Kea handles that second part but if they are actually reservations there then we can obviously lift that restriction after moving to Kea.

JeGr

@jimp said in Questions about DHCPd: new service on the agenda? DHCP pool restrictions?:

Yes, it's EOL. We'll be working on moving to Kea but not for this release. We've been using Kea with much success on TNSR, so we are hopeful that is the best path forward. That said, we still need to look into how it does things like failover pools.

Oh really exciting to read. I almost assumed it's a OpenBSD like situation that FreeBSD runs its own fork and will do so further down the road but I see that I now have to read on and check out Kea myself :)

@jimp said in Questions about DHCPd: new service on the agenda? DHCP pool restrictions?:

I'm not sure how Kea handles that second part but if they are actually reservations there then we can obviously lift that restriction after moving to Kea.

Oh then I'm sorry and "my bad" for assuming they actually were reservations. I just followed a similar discussion where ISC-dhcpd was concerned and either there was some misconception or they weren't aware, that preferences weren't really reservations.

But thanks for the update that gives additional input if that question pops up in the future again. Have to read Kea docs, if that is actually supported there (just for informational purpose).

Thanks again,
Jens