Microsoft Windows 'DHCP RELEASE while SELECTING Bug' (re-send)

Irwin Tillman irwin at princeton.edu
Fri Mar 5 14:14:49 GMT 2004


(This is a re-send; first attempt appears to have not gotten through.)

At Princeton we've been seeing DHCP problems due to a bug introduced in
Windows. Since I suspect many other schools with many mobile clients are
experiencing the same bug, I thought I'd post the details for you.

We call this the "Microsoft Windows DHCP RELEASE while SELECTING Bug." 

Briefly, a Windows 2000 client configured to obtain its IP address via DHCP will
occassionally transmit a DHCPRELEASE message while it is in the DHCP SELECTING
state. This is not correct DHCP behavior. Depending on the implementation of the
DHCP server, it may cause the client to fail to receive a DHCP lease.

We're seeing this bug from Windows 2000 clients (at least); I don't know if any
of the clients are instead running Windows XP. We began noticing the problem in
August 2003, so I assume it was introduced in a Microsoft service pack or other
patch at or before that time.

---

We have verified the bug through packet capture:

The Windows client starts in DHCP INIT state, and obtains a DHCP lease normally.
It may renew the lease zero or more times after this.

Later, the device is rebooted, and starts in the INIT-REBOOT state. It
broadcasts a DHCPREQUEST packet, requesting the previous IP address, and is
granted a new lease on that IP address.

A few seconds later, it returns to DHCP INIT state, and broadcasts a
DHCPDISCOVER packet.

By doing so, it has implicitly abandoned its lease on the previous IP address.
(A DHCP client (as identified by its Client Identifier) on a single IP network
can only be in a single DHCP state at a time. It cannot be both in INIT state
and in BOUND, RENEWING, or REBINDING state.)

The DHCP servers respond to the DHCPDISCOVER with DHCPOFFER packets. The
client receives these, and transitions from the DHCP INIT state to the DHCP
SELECTING state.

At this point, the DHCP client misbehaves. It unicasts a DHCPRELEASE message for
the old IP address it implicitly abandoned when it returned to INIT state. (The
packet is unicast to the DHCP server that had granted that abandoned lease.)
Furthermore, the IP source of this DHCPRELEASE packet is that of the abandoned
IP address, which no longer belongs to this client.

After transmitting the erroneous DHCPRELEASE packet, the client broadcasts a
DHCPREQUEST packet, to select one of the IP addresses it was recently offered.

---

The erroneous DHCPRELEASE message may or may not cause a problem for you,
depending on the implementation of your DHCP server.

For example, if all of the following are true, you will have a problem:

* Your DHCP server implements offers as very short leases

* The abandoned IP address mentioned in the erroneous DHCPRELEASE is the same as
  one of the IP addresses in the new offers. (This is very likely, if your DHCP
  server tries to award clients the same IP address they last had, when
  feasible.)

* The DHCPREQUEST next sent by the client specifies that same IP address (This
  will typically happen if the offer for that IP address is the first one to
  reach the client.)

In this scenario, the DHCPREQUEST will fail, because the server has cancelled
the offer as a result of the erroneous DHCPRELEASE.

---

The exact sequence of DHCP packets has varied, and we are not
able to cause a Windows client to reproduce the bug reliably.

However, in all cases, the key details of the bug (the client has a lease,
abandons it by returning to DHCP INIT state and transmitting DHCPDISCOVER,
receives DHCPOFFERs, then erroneously transmits a DHCPRELEASE for the abandoned
lease) remains the same.

---

We've reported the problem to Microsoft, and they have identified the behavior
as a Windows feature that is an attempt to help the DHCP server conserve IP
addresses.

Specifically, they are sending the DHCPRELEASE for the old lease in an attempt
to let the server know it no longer needs to keep the old lease around.

However, I believe that they are sending the DHCPRELEASE at the wrong time. I
don't believe it is valid for a client to transmit a DHCPRELEASE packet while it
is in the DHCP SELECTING state. (And I don't think it is valid for a client to
transmit the packet using the IP source of a lease it has already abandoned.)

If they want to send the DHCPRELEASE, I think they should do so before
transmiting the DHCPDISCOVER.

---

Microsoft does not agree this is a bug. They believe it is valid for a single
DHCP client (as identified by a single DHCP Client Identifier on a single IP
network) to be simultaneously in both the SELECTING and BOUND state.
They have no plans to change the behavior.

---

I wanted to alert other schools to this bug, in the hopes that if this bug is
causing problems for you, you won't have to spend as much time as we have
tracking it down.


Irwin Tillman
Network Systems, Office of Information Technology, Princeton University



More information about the unisog mailing list