Windows 8 and IPv6

For those that missed the Microsoft blog post by Chris Palmer explaining the IPv6 support that Windows 8 will have it is worth a read. It is important enough that Steven Sinofsky posted it as a guest blog entry on his building Windows 8 page, which is pretty cool. With Windows 8 now RTM understanding how IPv6 works in the Windows OS environment is pretty important. This is the third client OS release from Microsoft with comprehensive IPv6 support (Vista, Windows 7 and now Windows 8) and the server side is equally as impressive (Windows Server 2008, 2008R2 and now 2012) so there is no excuse not to understand and start working with IPv6. After all, you have had since 2007 (Vista's release) to start working on your IPv6 skills!

The important take away from the post to me was that Windows 8 will not have full RFC 6555 (Happy Eyeballs) support in the way many in the industry wanted (Dan Wing and others.) Happy Eyeballs is an important stop gap solution to resolving much of the end user experience issues that happen when IPv6 isn't work correctly. The issues happen when IPv6 is turned on but broken (routing isn't working for example) but is still preferred over IPv4 connectivity. This situation will become more common as IPv6 is more widely deployed but not as well understood by IT Professionals and helpdesk staff. Their lack of comprehensive understanding of troubleshooting dual stack environments will make this issue more common in the next 1-2 years is my feeling. Hopefully this will change as wider adoption of IPv6 means a better understanding of the protocol and its importance.


In my conversations with many at Microsoft regarding IPv6 and RFC 6555 it comes to light that they see their client OS being deployed and supported much longer than many in the industry. One of the principal concerns with doing a full RFC 6555 implementation was that it likely won't be needed in 3-5 years and because of how RFC 6555 works it makes it much tougher to debug application behavior on the client. This is a huge concern for Microsoft as custom applications deployed in Enterprise environments is a large part of their business. Making client behavior different depending on the application that is running and per session spells disaster in the QA testing area.


There are other considerations too about why they chose the path they did for doing such a limited support of RFC 6555 but the reality is... it doesn't matter. You can't change it, Windows 8 will make use of a modified RFC 3484 solution outlined in Chris' blog post and quoted below:

"Windows 8 tests IPv6 connectivity when you connect to a new network that advertises IPv6 routabilty, and it will only use IPv6 if IPv6 connectivity is actually functioning. This approach is a modification of our implementation of RFC 3484. Instead of sorting addresses as a result of policy, we use the actual state of the network as input to our algorithm. On a misconfigured network, this approach improves the experience not only for browsers but also for apps that connect to dual-stack destinations using standard Windows APIs.
Windows 8 performs the network connectivity test when you first connect to a new network; it caches this information and repeats the test every 30 days. The actual test for connectivity is a simple HTTP GET to an IPv6-only server that is hosted by Microsoft. (For standards buffs, this is implemented between rules 5 and 6 of destination address sorting in our implementation of RFC 3484.) Windows performs a similar network connectivity test for IPv4 connectivity. If both IPv4 and IPv6 are functioning, IPv6 will be preferred.
To make sure that Windows 8 does not cause problems on enterprise networks, the functionality has two safeguards:

• If the enterprise has provided specific routing information to a particular destination, then Windows 8 will honor that preference, regardless of the connectivity determined by Windows. In enterprise environments, Windows assumes that network administrators who configure such routes specifically thought it was a good idea to use those routes.
• This change isn’t implemented on networks with web proxies. In these networks, the proxy provides connectivity to the Internet; so end-to-end testing of IPv6 connectivity is not useful. Instead, Windows 8 simply opens connections to the proxy in the most efficient manner possible.

In this way, we’ve ensured that apps and experiences on Windows 8 can remain reliably and speedily connected to the Internet throughout the IPv6 transition, even if your local network is misconfigured."

So there you have it. More details about how it all works can be found in Joseph Davies' Understanding IPv6, Third Edition, an excellent reference book on how Microsoft has implemented IPv6 in Windows. Full discloser, I was the technical editor for the book.
- Ed