Hi all.
Anyone ever figured out why Windows updates fail when the computer has an IPv6 connection?
Google has tickets and tickets of this to and outside of Microsoft since 2013, with no real solution or answer as to what the problem actually is. In essence, many of the solutions out there point toward making sure the updates do not occur over IPv6, which, in effect, is the same as disabling it.
I have a family PC at home running Windows 10 Pro, and noticed updates would fail in recent months. It took me a moment to realize that this started happening only after I enabled IPv6 in the TCP/IP stack. Disabling it immediately solves the issue.
Quite odd that this is happening in 2018…
Mark.
I’ve had IPv6 enabled for a while and I don’t have the same issue. We also peer directly with Microsoft. Are you sure it’s an IPv6 issue and not a general reachability issue?
-Daniel
Also no problems here with IPv6 and Windows Updates…
The issue is affecting (and has affected) quite a few folk:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/a9b1b537-ad27-4718-821b-57ef33174974/windows-update-fails-if-ipv6-is-enabled?forum=w8itpronetworking
https://social.technet.microsoft.com/Forums/office/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016
https://answers.microsoft.com/en-us/windows/forum/all/windows-8-pro-windows-update-fails-if-ipv6-is/7ebdac22-6675-402b-ad43-e3fa8450659d
It occurs to me that this, could, perhaps be CDN specific.
I'm currently not in Johannesburg, but last time I checked, the majority
of Windows updates were being handled by Akamai. Perhaps this is where
the issue could be, although we have got local IPv6 peering with Akamai
and don't generally have issues with it.
I'll dig deeper into how Akamai may be involved when I get back home.
Thanks for the pointers.
Mark.
I’m on native IPv6 via Spectrum and have no problems with Windows Updates. Could this be a tunneling issue?
Tony
Let me know if you see anything related to Akamai. Looking at these threads I don’t see anything really obvious and some are much older posts.
- Jared
I saw this issue randomly on Windows PCs due to IPV6 TCP checksum offloading.
Try the following on the problem Windows machine:
-
Open the Device Manager -> Network Adapters -> Network Interface (Ethernet NIC):
-
Under the Network Adapter -> Advanced Tab, disable these options if present:
TCP Checksum Offloading (IPV6) -> Disabled
UDP Checksum Offloading (IPV6) -> Disabled
Not to beat a dead horse, but could the problem be so simple? I have tons of dual-stacked machines that have updated forever without issue, so I assume they update via IPV4.
That being said, I've not packet sniffed any of the update stuff in a while but if the DNS is any indication then dual-stacked machines can update via IPV4 while IPV6 ONLY machines will likely fail since the DNS shows IPV4 only....
host windowsupdate.microsoft.com
windowsupdate.microsoft.com is an alias for windowsupdate.redir.update.microsoft.com.nsatc.net.
windowsupdate.redir.update.microsoft.com.nsatc.net is an alias for redir.update.microsoft.com.nsatc.net.
redir.update.microsoft.com.nsatc.net has address 157.56.77.153
I do run 6-in-4 from my backbone to my house as my FTTH provider does
not do IPv6.
I can't imagine this to specifically be the issue, as all other IPv6
traffic is fine, but at this point, I'm open to suggestion.
Mark.
Let me know if you see anything related to Akamai.
Will do.
Looking at these threads I don’t see anything really obvious and some are much older posts.
Agreed - but those posts were never really solved, and the issue
description and behaviour mirrors my own.
Mark.
Thanks, Airdrie, but I don't have those options on the network adapter.
Mark.
Are you doing TCP MSS adjust/clamping? If you don't, try that and see if it helps. This might be a PMTUD issue.
Otherwise if possible, try lowering the MTU sent in RA to the one you have on your tunnel (this depends on if this is available to you in your RA sending device).
I recently go a Linksys home wifi router, by default it enables ipv6 on the LAN. If there is no native IPv6 on the WAN side (which is my case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.
For the first few weeks of using the router, I had no idea alot of my traffic was going out via the v6 tunnel.
Then I started getting random reachability and availability issues. Google would not load, but Bing and Yahoo would, and so on. I thought it was a FiOS issue, but after digging, I discovered the v6 tunnel, disabled it and all my issues went away.
I dont know what Linksys uses for the v6 tunnel because its buried in the firmware, but any tunnel service is vulnerable to a variety of issues that could effect access. Its odd that it always effects Windows update all the time, but who knows.
-John
Which just shows content providers and tunnel end point problems.
* load balancers that don’t properly handle ICMP{v6}
* stupid firewalls that block PTB
* tunnel end points that don’t generate PTB for EVERY oversize packet
(you wouldn’t drop TCP ACKS and PTBs are just as important)
PMTD requires PTBs to be generated.
Report the problems so they can get fixed.
Mark
Thanks, Mikael.
I'll have a sniff and see of this helps.
Mark.
John Von Essen <john@essenz.com> writes:
I recently go a Linksys home wifi router, by default it enables ipv6
on the LAN. If there is no native IPv6 on the WAN side (which is my
case since FiOS doesnt do v6 yet) the Linksys defaults to a v6 tunnel.
Could this be a 6RD tunnel requested by your ISP using DHCP with
OPTION_6RD? Ref RFC5969
Setting up any tunnel to some pre-configured endpoint by default does
not sound like a good idea.... But DHCP on the WAN side is "trusted",
so configuring a DHCP requested tunnel by default is reasonable.
For the first few weeks of using the router, I had no idea alot of my
traffic was going out via the v6 tunnel.
Then I started getting random reachability and availability
issues. Google would not load, but Bing and Yahoo would, and so on. I
thought it was a FiOS issue, but after digging, I discovered the v6
tunnel, disabled it and all my issues went away.
I dont know what Linksys uses for the v6 tunnel because its buried in
the firmware, but any tunnel service is vulnerable to a variety of
issues that could effect access. Its odd that it always effects
Windows update all the time, but who knows.
It would be great to have more details about this default tunnel setup.
Can't you sniff the traffic?
Anyway: Thanks for yet another argument for native dual-stack.
Avoiding such unwanted tunnels is really simple:
If you're an ISP:
Offer native dual-stack to your Internet access customers.
If you're an Internet access customer:
Request native dual-stack from your ISP
Problem solved.
Bjørn
Hi all.
Just an update on this… it did turn out to be an MTU issue which I’ve been working on since last year, November. The trick was finding the right combination of settings between my Mikrotik home router and one of our Cisco ASR1006 edge routers in my backbone that terminates the 6-in-4 tunnel.
After testing this at the office, I was, then, sure that the problem was MTU-related as it only occurred at my house.
My FTTH service is delivered over GPON, and after a bit of testing, concluded that my MTU for IPv4 is 1,452 bytes. Across the 6-in-4 tunnel, the tested MTU is 1,232 for IPv6.
The Mikrotik will not pass any IPv6 traffic if the 6-in-4 tunnel does not have the minimum default MTU for IPv6, i.e., 1,280 bytes (even if the tunnel cannot actually transport 1,280 byte-sized packets). This is not documented anywhere, so it took a while to figure out.
On the Cisco, you can’t configure an IPv6 interface MTU lower than 1,280 bytes… but that is within the standard IPv6 spec., so no major drama.
So the right combination of settings is to have 1,280 bytes on the Mikrotik and enable “ipv6 tcp adjust-mss 1232” on the Cisco (the latter for my specific case - yours may vary depending on your IPv4 conditions).
Just wanted to update this thread in case someone else runs into this issue.
Thanks for the clue, Mikael and all.
Mark.
[..]
Across the 6-in-4 tunnel, the tested MTU is 1,232 for IPv6.
IPv6 requires a minimum MTU of 1280.
If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel.
[..]
So the right combination of settings is to have 1,280 bytes on the Mikrotik and enable "ipv6 tcp adjust-mss 1232" on the Cisco (the latter for my specific case - yours may vary depending on your IPv4 conditions).
Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem...
And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves 
Greets,
Jeroen
IPv6 requires a minimum MTU of 1280.
If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel.
As you know, IPv6 does not support fragmentation in transit. So that's
not an option.
Host fragmentation is per standard, but signaling of that was not so
successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here.
Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem...
I considered this issue, but as with all things UDP re: fragmentation,
it depends.
Testing I've been doing all day shows previously (mostly-TCP) issues
have resolved, and I've not run into any major problems that are
impacting UDP. Nonetheless, I'm keeping an eye out.
And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves
Is it an ideal situation? About as ideal as flying in the cargo bay. But
my reality is that until my FTTH provider can deliver native IPv6, this
is what I have.
Mark.
IPv6 requires a minimum MTU of 1280.
If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel.
As you know, IPv6 does not support fragmentation in transit. So that's
not an option.
The transport (tunnel) CAN support that kind of fragmentation.
(e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing).
Indeed, IPv6 won't do it: get a better transport.
Host fragmentation is per standard, but signaling of that was not so
successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here.
Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes.
Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem...
I considered this issue, but as with all things UDP re: fragmentation,
it depends.
Testing I've been doing all day shows previously (mostly-TCP) issues
have resolved, and I've not run into any major problems that are
impacting UDP. Nonetheless, I'm keeping an eye out.
And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves
Is it an ideal situation? About as ideal as flying in the cargo bay. But
my reality is that until my FTTH provider can deliver native IPv6, this
is what I have.
Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...)
Greets,
Jeroen