Unsolicited DHCP NAK

[David W. Hankins]

On Mon, Jul 28, 2008 at 09:36:31PM -0400, Norman Elton wrote:
> I believe that unsolicited DHCP NAK messages should be dropped by
> default. That is, if a client with a valid DHCP lease receives a DHCP
> NAK, they should ignore it.

The rfc2131 suggestion (I don't think this is normative, but it is
described in the infamous state diagram) is to discard DHCPNAK while
BOUND.

I haven't done any extensive testing myself on clients in general, but
I can say ISC DHCP's approach is to discard DHCPNAKs unless in the
REBOOTING, REQUESTING, RENEWING, or REBINDING states.  This check is
only reached if the XID magically matched, so they generally get
logged as "DHCPNAK in wrong transaction."

> We're trying to identify a way to force a client to renew their IP
> address after being moved from one virtual network (vlan) to another.

DHCPFORCERENEW was written for this purpose, but has not been widely
implemented in clients (so blinking ports is way more effective).

ISC dhclient doesn't implement it either; I am wary of a unicast
method to DOS a client...I prefer to implement this after some form of
DHCP server authentication.

The single best way to control clients reliably remains the lease
time, and even this suffers the occaisional bad clock.

> Right now, we "blink" their port, simulating them unplugging and
> reconnecting to the network. This works great in 99% of the cases.

Particularly not stock ISC DHCP.  Some unixes (like my trusty RedHat)
have a fancy dBus layer that detects link state changes.

> If
> a user is plugged into a mini-switch hanging off our network, then
> they never actually see the link go down. It has been suggested that
> we send a NAK packet, but my gut feeling says this would not be
> supported in mainstream OSes.

Your biggest challenge in (mis)using DHCPNAK for this purpose will be
in either caching or sensing the XID the client most recently used in
its previous DHCPREQUEST message.

> I was going to reproduce this in the lab, but figured someone may be
> able to reply quicker than I could craft a NAK packet.

I think blinking the port is the current state of the art on the
subject.

If you can sense "clients that do not respond to port blinking" (not
Windows, not MacOS), you might set a much lower lease time.  So long
as there are not many devices, it is not a big strain to keep them
renewing on a more reasonable schedule; something you wouldn't mind
waiting for on a VLAN change.

Of course any nonzero number is kind of a problem if you're using
overlapping address ranges on the VLANs.

Similarly, if you can forecast VLAN changes, then you can reduce the
lease time for all affected clients in advance of a change.