Yesterday's Windows update causes IPv4 to be default

[Christopher Palmer]

Hi Folks.

Until an hour ago, I wasn't on this list. I've been trolling the archive in response to some email forwarding. It appears that Microsoft's most recent Windows Update caused some concern amongst this list's members that we broke Windows 7. I wanted to respond to some of the questions and feedback I've seen so far.

We have a blog post on this functionality. That blog post describes the Windows 8 work, and our update to Windows 7 presents no substantive changes from that post's contents. Most of the questions and concerns I saw on this list appear to be answered by that post, but there were some omissions certainly, and we didn't link the Windows 7 WU documentation clearly to that post. These were my mistakes and I apologize for the frustration that arose.

This functionality only depreferences default routes on networks without proxies. If the PC is unable to resolve the AAAA record for the NCSI beacon, this functionality does not activate.

Only a combination of no proxies, AAAA resolution success, a default route, and a failure to connect to the beacon - enables this functionality to activate. And its activation is limited to depreferncing the default route. Any scoped routes that have been configured are untouched.

This fairly long set of activators is meant to focus this change on the particular scenarios we care about, consumers dealing with ISPs or network equipment causing painful brokenness for apps that use connectbyname() style APIs.

There have been questions about caching. I'll note that we actually only cache successes. If a network has been tagged as broken, we'll still probe the beacon regularly (at each network attach), in the hope that connectivity will be restored. This is a result of our belief that most brokenness is caused by long-lived misconfigurations. Temporary burps are less of a concern, at least from my perspective.

The beacon itself is hosted by a content delivery network of considerable prestige. We have both IPv4 and IPv6 beacons, and those beacons are important to a wide array of Windows functionality, most visibly the networking icon's status. I'll admit that we had some operational issues with the IPv6 beacon in the Windows 8 Beta period (thanks to Dan for helping us figure out some issues). The IPv6 and IPv4 beacons are hosted together now, and if they go down, this functionality is the least of my concerns. I'll have a couple hundred million people asking why their networking icons died.

My last thought : our design here provides considerable temporal stability, has no repercussions on server load, and is consistent across apps. It's also insensitive to "speed" differences between IPv4 and IPv6 - which is important if Windows is to do its part to move the IPv6 transition along.  My biggest worry is that we didn't do "enough" to fix brokenness, and were in fact too conservative in our approach.

There are other solutions to the brokenness problem from our counterparts at Google, Apple, etc. I think those have considerable merit, the diversity of solutions is a sign of the diverse viewpoints that intelligent people can have in this space. I think our design is the right model for Windows as an operating system to undertake, to ensure a good experience for users throughout the transition, while ensuring that the transition actually happens.

I know people might disagree and have further feedback, but I hope this assuages much of the concern.

All the best,
Chris

---------------------------------------------------------
Christopher.Palmer at microsoft.com
Windows Networking Core - Program Manager
Core Client Connectivity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121116/c79e8ee3/attachment.htm>