So I had an interesting experience with dhcpd...

On a particular subnet at MIT, I've been running a dhcpd for a couple
of years, serving a handful of local machines.  MIT Network Operations
finally got around to setting up their own DHCP service (with two
servers on the same network) a while back, and around the same time
they decided to overlap another subnet onto the same physical
(switched) network.

Now my old dhcpd wasn't aware of the new subnet, so the following
happened whenever someone tried to boot a machine that was registered
with the MITnet DHCP service:

* Client sends a broadcast DHCPDISCOVER.
* My server drops request on the floor.
* Their servers both respond with DHCPOFFERs on new subnet (18.187).
* Client sends a broadcast DHCPREQUEST, with a server identifier.
* My server doesn't recognize the subnet and sends a NAK.
* Client restarts configuration process, per DHCP RFC.
* One of their servers responds with a DHCPACK (but too late).

There are a couple of problems here:

* Since the DHCPREQUEST had a server identifier that did not match my
  server, it is inappropriate for *any* response to be generated.  The
  RFC is fairly clear that the only thing the server should do in this
  case is cancel any offers it had made to that client.  The same goes
  for a DHCPDECLINE.

* While looking at this, I noticed that we actually don't cancel
  pending offers.  While not a bug per se, this is suboptimal.

The former, at least, definitely needs to be fixed.