DHCPREQUEST unicast conflicts with RFC 1122 (when USE_LPF)

[Kim F. Storm]

I've just spent quite some time trying to understand why some of the
DHCP-enabled equipment we have locally does not work well together
with a Windows 2000 based DHCP server -- the server does not respond
to DHCPREQUEST renewal requests until T2 expires.

I see the problem with the ISC DHCP clients that I've configured on
our GNU/Linux clients using LPF to send requests.

Initially, clients get a lease from the server
(i.e. DISCOVER/OFFER/REQUEST/ACK work as expected).

Later when the DHCP client has to renew the lease, it sends an IP
unicast DHCPREQUEST to the server, but the link-layer destination
address of the packet is the MAC broadcast address, rather than the
MAC address of the server.  The server seems to discard these packets.

When the T2 timer runs out, the DHCP client will switch to IP broadcast,
and the server _does_ respond to this.

I tried to hack the DHCP client to use the MAC address of the Windows
server instead of MAC broadcast, and then the server happily responds
to the IP unicasts.

Using the Network Monitor on the Windows server, I can see that the
unicast requests are received by the server, but it never respond to
those requests.

I have observed this behaviour on two different Windows 2000 servers,
using a number of different clients.


In my quest to explain this, I came across RFC 1122, section 3.3.6, which
states the following on broadcasts:

         When a host sends a datagram to a link-layer broadcast address,
         the IP destination address MUST be a legal IP broadcast or IP
         multicast address.

         A host SHOULD silently discard a datagram that is received via
         a link-layer broadcast (see Section 2.4) but does not specify
         an IP multicast or broadcast destination address.

So it seems that an RFC1122 conforming implementation should indeed
discard an MAC broadcast / IP unicast packet.  I cannot confirm that
this is what the Windows 2000 server does, but it looks like it.

Are any of you aware of this problem, or am I on a wild goose chase here?

-- 
Kim F. Storm <storm at cua.dk> http://www.cua.dk