Sometimes, a small change can make a big difference. When the change makes a bad difference, it can be a disaster. One of those slow-motion disasters may be in the making with a small change that Microsoft slipped into the network stack for Windows Vista.The description of the problem comes from this blog entry. The author doesn't want to name his company, but the story seems technically detailed and credible. The short version is that Vista changed the way that it chooses servers when a DNS query returns multiple possible IP addresses. As a result, Vista users tend to congregate in the data center at one IP, rather than equally distributing across all the data center IP addresses as they did in previous Windows versions.

After some research, the author came across RFC3484, which specifies how clients should decide which IP address to select when DNS returns multiple addresses. Although this RFC primarily addresses the issue for IPv6, parts of the RFC can be applied to IPv4 as well. The problematic part of the spec is Section 6, Rule 9 ("Use longest matching prefix"). Instead of randomly choosing an IP as previous versions of Windows did, Vista now follows RFC3484 and chooses the IP that shares the most number of "high bits" with the client's source IP address.

Perhaps there's solid reasoning in using the "longest matching prefix" approach in IPv6, if IPv6 addresses that share similar prefixes are geographically close to each other. That's just not the case with IPv4, though. Nearly every home user, and many if not most business users, are behind a network address translation (NAT) firewall. The majority of those firewalls use an IPv4 address range of 192.168.x.x, whether they're in San Francisco, London, Moscow, or Hong Kong. Those private addresses don't have any relationship to the physical location of the client, and using them to choose an IP is worse than random choice.

Some of you may be thinking, "Why blame Microsoft for correctly implementing an Internet RFC?" There's just one problem with that: Microsoft wrote the RFC. No doubt others outside Microsoft reviewed it and didn't see the flaw in trying to apply these rules to the IPv4 world. At this point, the important thing is not to assign blame but to fix the problem before it gets worse.