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

Roy Marples <[email protected]> writes:

> Anyway, it's no secret that I've been working on a DHCP server for a
> while now and only recently found some free time to work on it.

News to me but I not shocked...

> It's now in a useable state and I'm just going over RFC2131 with a fine comb to ensure it's compliant.
> It currently has (almost) zero configuration and the following requirements:
>
> You need to specify a list of interfaces for it to create IP pools on
> Each interface MUST have a private address that fits (10/8, 172.16-32/16,192.168/16) AND end with .1
> The first matching address found for the interface will have a pool generated from .10 to the maximal IP within the netmask and will be the Server ID
> The lease time will be an hour, T1 and T2 timers will be automatically generated and sent.
> Router and DNS server options will be sent (if requested) with the Server ID as the value.
> There is currently no persistent storage for leases.

Interesting set of choices and I certainly see the point of keeping it simpler.

> Rationale:
> My use case is an internal router/DNS server which hosts the VM's in my homelab.

My use case is as the main router/firewall/nat which serves dhcp on
multiple vlans.  I guess there's an interesting question as to whether
you see that, meaning "real dhcp server for a network served by a netbsd
router" as in scope, vs serving a subnet of a few test boxes.

> I'm a believer that routers SHOULD have an address ending in .1 or ::1

I believe too, but what does it help to require that, if someone wants
to use .2?

Same question on the rfc1918 requirement.  You could just say "if an
interface is on the list, the first IP address will be used for dhcp".

> In a homelab there SHOULD NOT be a large number of statically configured nodes, hence the pool starting at .10

I see that differently; I have a router and two hosts truly static (addr
in ifconfig.foo0), and over 100 static-dhcp configs, including maybe 10
that are the same host roving to various vlans.  In general, one needs
to coordinate firewall entries with IP addresses, as in
"sketchy-firmware device foo is default block and is allowed to talk to
external address X via port Y only".

As an example, my access points and switches have serial numbers with
labels and I have static-dhcp addresses in a range with the last digit
matching.   These addresses are not within the pool, and they're not
allowed to talk to the Internet.

> I find the configuration of all DHCP servers I've used pretty cumbersome and want something much simpler and easier.
> Infact I really don't want to think about it that much and having somethings "That Just Works" is a selling point IMHO hence the above.

Agreed, but that leads to "if you don't have a config file you get
reasonable behavior" more than it leads to "you can't configure it".

> So the question is, what is the Minimum Viable Product of a DHCP
> server for replacing ISC dhcpd in the NetBSD base system?  Please
> answer with an idea of how it should look without having to refer to
> another resource.

I'm writing this from memory knowing what I've wanted to do and have set
up, with ISC DHCP.  I know I'm somewhat on the edge but I don't think
I'm really odd.

Part of running a home network is security concerns, and that leads to

  - logging of new MAC addresses not known to be associated with an
    authorized client

  - static-dhcp config for known MACs, both to reduce the not-configured
    MAC logging, and to place them on knowable IP addresses for firewall
    configuration.

  - setting the pool to a configurable range, so that they can receive
    whatever firewall treatment is appropriate for the pool, vs known
    hosts.

While I use 30 minutes for leases, I don't care about 30 vs 60.

Not having a persistent lease database is an interesting choice.  While
initially skeptical, after thinking a few minutes I think that's fine.
I set every computer that persists to static-dhcp, So the point of the
lease database is to see "what mac addrs, that are not known/authorized,
have appeared and when".  Hence my comment above about logging as the
real issue.

I would like to see some kind of API so that e.g. Home Assistant could
get notifications of new leases, timeout of leases, etc.  That's
probably just some AF_UNIX datagram, or it could be log parsing, and
that may be just me.


I see the above as necessary to "replace" ISC dhcpd.  If you instead ask
what are the minimal requirements to add a simple/reliable server, then
I'd say enough logging so that one can patrol for rogue MACs and
understand what's going on.  My point is that a minimal server that
isn't configurable enough for many use cases is ok to have also, but
isn't sufficient.

There is the question "should we demote ISC dhcpd to pkgsrc only?", but
I think that should be answered separately, decoupled from "replace?".