Yesterday's Windows update causes IPv4 to be default

Cameron Byrne cb.list6 at gmail.com
Fri Nov 16 15:13:29 CET 2012


On Nov 16, 2012 1:37 AM, "Christopher Palmer" <
Christopher.Palmer at microsoft.com> wrote:
>
> 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
>
>

This helpful,  thanks !

CB
>
> ---------------------------------------------------------
>
> Christopher.Palmer at microsoft.com
>
> Windows Networking Core – Program Manager
>
> Core Client Connectivity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121116/ad315019/attachment.html 


More information about the ipv6-ops mailing list