> * 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.

Not necessarily true.  The RFC says that the server is supposed to NAK
any broadcast DHCPREQUEST that it receives.  The purpose of NAKing is
that if a client comes up on a new network, you want to tell it it's
misconfigured immediately, rather than letting it time out.  The
admonition to which you refer is for requests for otherwise correct IP
addresses on IP addresses that a particular server doesn't know about
- in that case, it definitely should not NAK.

However, you are right that this behaviour probably should be
configurable, and it has been argued by some other DHCP server users
that the behaviour you want should be the default, and that agressive
NAKing should be something you have to enable.   I have mixed emotions
about this, but my inclination at this point is probably to change the
default behaviour.   :'(

  [...]

   DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired

  [...]

     If the selected server is unable to satisfy the DHCPREQUEST message
     (e.g., the requested network address has been allocated), the
     server SHOULD respond with a DHCPNAK message.

   [...]

      If the client's request is invalid (e.g., the client has moved
      to a new subnet), servers SHOULD respond with a DHCPNAK message to
      the client. Servers SHOULD NOT respond if their information is not
      guaranteed to be accurate.  For example, a server that identifies a
      request for an expired binding that is owned by another server SHOULD
      NOT respond with a DHCPNAK unless the servers are using an explicit
      mechanism to maintain coherency among the servers.

The point one might dispute is whether or not the server's information
is guaranteed to be accurate.   My interpretation has always been that
since only a network administrator should ever set up a DHCP server,
the information the DHCP server has about the network should be
authoritative.   Your server, of course, violates my assumption, and
is a reasonable usage, so at least making it possible for you to say
"information not guaranteed to be accurate" is important.

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

They are only held briefly (two minutes).  It's only if we receive a
DHCPREQUEST on the offered address that we actually reserve the lease
for its offered duration.  Adding code to immediately free up the
lease before the expiry time would be a neat hack, but I'm not
convinced it's worth the trouble - I've never actually had a report of
anybody running into trouble because of this.

			       _MelloN_