Broadcasts of DHCPNAK: In the bullring

[Mark Sirota <[e-mail]>]

In the previous message, I quoted four passages from the latest DHCP spec,
draft-ietf-dhc-dhcp-07.txt.  I discovered all of that after wrestling with
a problem involving the Windows 95 DHCP client, a Cisco IOS 11.1(2) router
acting as a BOOTP relay agent, and the ISC DHCP Server, Beta release 4
patchlevel 5A.

I had outlined this earlier to this list, but at the time I had a lot less
information, and some of my conjectures and theories were just plain wrong.

I would appreciate any insight as to which piece is at fault here, and what
might be done to solve it, either as a temporary workaround or preferably as
a permanent solution.

The situation is as follows:
	The server sits on Subnet A.
	The client gets a lease on Subnet A, and is then carried to
		Subnet B, and is booted up.
	The client sends a REQUEST for the Subnet A address.
	The router forwards the REQUEST to the server.
	The server sends a NAK to the router, because the client is on the
		wrong subnet for the requested address.
	The router broadcasts the NAK (both link level and IP level) on
		Subnet B.
	The client does not seem to recognize the NAK, and so sends another
		REQUEST.

In the converse situation, everything works fine:
	The server sits on Subnet A.
	The client gets a lease on Subnet B, and is then carried to
		Subnet A, and is booted up.
	The client sends a REQUEST for the Subnet B address.
	The server broadcasts a NAK (both link level and IP level) on
		Subnet A, ebcause the client is on the wrong subnet for
		the requested address.
	The client understands the NAK, and so responds with a DISCOVER.

I have analyzed the two NAK packets in detail, one which is understood and
one which is not.  There are no differences that seem to matter.  Both are
broadcast at both the IP layer and the link layer on the client's subnet,
so it should hear both.  I am theorizing that the Windows 95 client is doing
some sanity checks on the packet, and sees that it came through a BOOTP
forwarder, and therefore doesn't like that it got there via broadcast, based
on one or more of the conflicting paragraphs in the spec.

I can provide details on the packets -- I have bunches of them saved up in
the sniffer, if anyone cares to help tear them apart.

Any and all opinions are most welcome!
-- 
Mark Sirota, Network Systems Engineer
University of Pennsylvania, Information Systems and Computing
[e-mail], 215/573-7214