Yesterday's Windows update causes IPv4 to be default

[Christopher Palmer]

Networks with captive portals are exempt from the change. Once/if the user escapes the portal (by paying for service or whatever), than the heuristic will take effect as described. 

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu] 
Sent: Friday, November 16, 2012 6:37 AM
To: Christopher Palmer
Cc: ipv6-ops at lists.cluenet.de; farmer at umn.edu
Subject: Re: Yesterday's Windows update causes IPv4 to be default

On 11/16/12 03:36 , Christopher Palmer 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.

Thanks for joining the list and I agree with others comments that this was helpful.  (I have additional comments and questions below)

> 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.

Could you additionally clarify if or how captive portals may interact with this feature and its set of activators.

> 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.

Thanks for clarifying, this seems more reasonable now.

> 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.

Yep, there are other consequences that are much more visible to the typical user if there are issue with the hosting of these beacons, which I think is a good thing.

> 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 think you are making a positive contribution in this space, but please be as open and transparent as possible.  There are a lot of people working on these issues from the OSes, applications, content and provider nets to end-user nets, to the extent possible we need to make sure we don't step on each others toes.

> 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
>


--
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================