If you read this blog regularly, you already know that a team of authors — including Jeff Carrell (the lead), James Pyles, Tom Lancaster, Mark Mirrotto, and myself — are reworking a college textbook called Guide to TCP/IP. In fact, our primary motivations for this revision are to switch from Ethereal to Wireshark as the protocol analyzer of choice, and to add substantial IPv6 coverage to the previously IPv4 centric focus in the prior edition. With IPv4 public address space all but exhausted, and industry, government, research, academia, and communications providers busily switching over to IPv6, it’s highest time we provided students with the information and examples they need to understand the latest iteration of TCP/IP in detail.
Along the way we realized that Windows 7 doesn’t actually use the right default for auto-generating IPv6 addresses. While the specifications do allow for various methods to do this, the preferred method is to use the brand-new Neighbor Discovery Protocol (NDP) to determine local network and interface identifiers, and to create a corresponding 128-bit IPv6 network address. Alas, Microsoft chose to implement an alternate method known as “random interface identifier assignment” instead.
This means that Windows 7 computers on IPv6 networks don’t behave the way that network administrators and IPv6-ready devices think they should, and can cause odd incompatibility issues to appear. Fortunately the fix for this problem involves running a single network shell (
netsh) command at the Windows command line:
netsh interface ipv6 set global randomizeidentifiers=disabled
Alas, Microsoft still doesn’t support the Secure Neighbor Discovery (SEND) protocol either, a more secure follow-on to NDP that verifies that neighbor devices discovered on a LAN actually belong there. It didn’t make it into SP1 for Windows 7, so we’ll have to hope to see it in Windows 7 SP2 and in Windows 8 next year!
[Comment Added 10/25/2011, thanks to Jeff Carrell. FYI, Jeff is my co-author on the TCP/IP textbook and has technical oversight for our latest and upcoming revision to that book]
RFC4861-NDP doesn’t care about how an interface get an IPv6 address, it defines some of the mechanisms to ensure no duplicate addresses (DAD) exist on-link. RFC4862 Stateless Address Autoconfiguration, mentions using the EUI-64 address and DAD test. There is also an update that mentions RFC4941 in the appendix.
It appears to be allowed to use either the RFC4291-EUI-64 or RFC4941-Privacy (random number) address formats for stateless address autoconfiguration.
Microsoft just happens to be using the Privacy format (since Vista/W2K8 came out in 2006/2008), which is actually more secure since it doesn’t have the MAC address embedded in the address string, but is different from the way that most other OS’s (client, server, infrastructure, etc) do it: they typically use the original standard known as EUI-64.
Agreed, RFC3971-SEND would be better, but I haven’t found any OS using it yet….actually I’ll be doing alot of resaerch on that for Ch13.