Re: MVP for a DHCP server (was Re: ISC's EoL dhcp suite, including dhcpd)

[Roy Marples <roy%marples.name@localhost>]

 ---- On Mon, 14 Jul 2025 14:49:38 +0100  Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote --- 
 > That is difficult if you're working with a smaller-than-/24 subnet.
 > 
 > I also don't understand why you restrict it to RFC-1918 addresses.

True, but if you want to serve up non private addresses then this probably isn't the DHCP server for you right now.

 > 
 > > In a homelab there SHOULD NOT be a large number of statically
 > > configured nodes, hence the pool starting at .10
 > 
 > I strongly disagree.  The only reason I have a DHCP server on my home
 > network at all is for devices which either insist on DHCP or are
 > configured for DHCP and can't be reconfigured without first getting
 > them on the net.  PXE boot ROMs are an example.

Is PXE booting anything extra? I've not looked into it.
Anyway, you could have a subnet for your DHCP devices which is different from your statically configured ones.
That's an implementation detail and doesn't change my proposal I think.

 > > There is currently no persistent storage for leases.
 > 
 > IMO that is a crippling bug.
 > 
 > > But please note, I don't see persistent leases as MVP because oddly enough t$
 > 
 > Work fine...for your use cases.  How rigorously have you tested
 > rebooting the DHCP server without rebooting its clients?  The case I'd
 > expect to be most probelmatic is rebooting the DHCP server without
 > rebooting anything else, then bringing new clients up before the
 > existing clients try to renew their leases.

So on the happy path, each client will renew it's lease and on a clean start with no prior knowledge we will honour the request if no-one has yet claimed it and it's within the address pool.
For the unhappy path you describe where a new client comes up it's currently dependent on the client to validate no host is using the offered address.

RFC 2131 says this:
As a consistency check, the allocating
   server SHOULD probe the reused address before allocating the address,
   e.g., with an ICMP echo request, and the client SHOULD probe the
   newly received address, e.g., with ARP.

dhcpcd for example supports ARP probing. So eventually it will get a working IP.

I guess the MVP here is supporting ICMP ping to the IP address in the server as we cannot assume the client is as good as dhcpcd.

 > 
 > In my (relatively inexpert, and very much not authoritative) opinion:
 > except for the lack of a persistent lease database, what you describe
 > is reasonable as a default, but everything about it needs to be
 > configurable otherwise.  For example, restricting it to RFC-1918
 > addresses is fine as a default, but it must be configurable for any
 > subnet (including those smaller than /24).

I'm open to relaxing the requirement for ending in .1 which should allow any subnets smaller than /24.
We could say that if ending in .1 for a /24 then the pool automatically starts from .10 otherwise it starts from address + 1

>   I would also consider it a
 > bug if it can't be configured to support two different subnets on the
 > same interface.

I would consider it a missing feature. I don't see that as MVP.
I'm going to guess that two different subnets on the same interface only works if you are doing host reserverations unless you know otherwise?

Roy