Microsoft Windows 'Resumes Using Old IP Address Bug'

Irwin Tillman irwin at princeton.edu
Thu Mar 4 15:50:34 GMT 2004


At Princeton we've been seeing IP address conflicts due to a bug introduced
recently 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 Resumes Using Old IP Address Bug." Briefly,
a Windows 2000 client configured to obtain its IP address via DHCP will
sometimes re-use its last IP address briefly as it comes up, just before it
requests a new DHCP lease. Naturally, if that IP address has since been awarded
to another client, this can interfere with service to the other client.

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:

When the Windows client brings up IP on an interface, *before* it transmits
a DHCPDISCOVER packet, it transmits an IP ARP Request. (This is not typical
use of ARP.)

This ARP Request is the client ARP'ing for the IP router associated with its
*last* DHCP lease.

However, the IP ARP Request claims to be coming from the client's old IP
address, even though the lease on that IP address has expired. This is
the problem.

In more detail, the characteristics of the erroneous ARP Request packet are:

   ether_src: Windows client
   ether_dst: ff:ff:ff:ff:ff:ff
   arp_sha: Windows client
   arp_spa: IP address from Windows client's last lease
   arp_tha: don't care
   arp_tpa: IP address of default IP router from Windows client's last lease

Clearly, arp_spa should not contain the IP address of the Windows client's
last lease.

---

If the Windows client happens now to be attached to an IP subnet where the
"stolen" IP address (arp_spa) is valid (e.g. the client is attached to the same
IP network as before), this erroneous ARP Request interferes with network
service to the device that currently has a legitimate lease on that IP address.

We have seen the bug happen regardless of whether the Windows client is
completely powered off between uses or put to sleep. We have seen it happen
regardless of whether the lease on the old IP address has expired or has not
expired. The only thing we have NOT been able to do is to reproduce it reliably;
when we set up a client known to exhibit the behavior, we're unable to force it
to exhibit the bug on demand. So the erroneous IP ARP Request is apparently not
transmitted in all circumstances.

This bug has been interfering with network service to customers here at
Princeton.  The problem has become so common among our mobile customers
that we've started turning off mobile IP service for devices exhibiting the bug. 
Essentially, Windows no longer is well-enough behaved to enjoy dynamic DHCP assignments 
on campus.

---

We've reported the problem to Microsoft, and they have identified the 
ARP Request as being generated in support of a new Windows feature. This new
feature (according to a Microsoft white paper) involves the Windows client
(at start) probing the network to determine if it is attached to the same IP
network to which it was last attached. It apparently makes this decision by
ARPing for the old IP router.

I believe that as currently implemented, this feature is broken. The IP address
it "steals" does not belong to the client at the time, and the erroneous
ARP Request does interfere with service to another legitimate client.

---

It appeared that for a brief time, Microsoft agreed that this was a bug, but the
most-recent information I've received from our support folks here is that
Microsoft has decided this is not a Windows bug, and the behavior will not be changed.

Microsoft has suggested to our support folks a workaround: they suggest setting
a per-interface registry key on each Windows 2000 client. (The per-interface
registry key tells the client to issue a DHCPRELEASE for that interface at
shutdown. It's not clear to me if this configuration change will indeed cause
the client to stop transmitting the erroneous ARP Request when it brings up the
interface, but we're trying it. Even if it does work, at best this is a
workaround for a bug that shouldn't be present in the first place.)

---

I wanted to alert other schools to this bug, in the hopes this will save some of
you time tracking down the problem. 


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



More information about the unisog mailing list