none
Windows update IPv6

    Question

  • Hi all!

    I`ve noticed on 2 of my locations that Win10 and Server 2012 R2 and Server 2016 won`t update via IPv6 network.

    LOG:

    2017. 11. 27 18:42:39.7600313 1280  3972  SLS             Retrieving SLS response from server using ETAG JGVDknXNqOV5QewbT3DPuCa5N8M4P/+G03Lxfzndha4=_1440"..."
    2017. 11. 27 18:42:39.7603019 1280  3972  SLS             Making request with URL HTTPS://sls.update.microsoft.com/SLS/{7971F918-A847-4430-9279-4A52D1EFE18D}/x64/10.0.17046.0/0?CH=545&L=en-US&P=RingInsiderFast;WUMUDCat&PT=0x30&WUA=10.0.17046.1000
    2017. 11. 27 18:44:39.7678401 1280  3972  Misc            *FAILED* [80072EE2] Send request
    2017. 11. 27 18:44:39.7678474 1280  3972  Misc            *FAILED* [80072EE2] WinHttp: SendRequestToServerForFileInformation (retrying with default proxy)
    2017. 11. 27 18:44:49.5381064 8572  3464  AppAU           * START *
    2017. 11. 27 18:44:49.5382103 8572  3464  AppAU           Flight settings ring provisioned default, range-checked minimum search interval: 20 hours
    2017. 11. 27 18:44:49.5436246 8572  3464  AppAU           * START * Finding app updates
    2017. 11. 27 18:44:49.7036785 8572  1368  ComApi          * START *   SLS Discovery
    2017. 11. 27 18:44:49.7126196 1280  12476 IdleTimer       WU operation (CDiscoveryCall::Init ID 2) started; operation # 9; does use network; is not at background priority
    2017. 11. 27 18:44:49.7129339 8572  1368  ComApi          *QUEUED* SLS Discovery
    2017. 11. 27 18:46:39.7719922 1280  3972  Misc            *FAILED* [80072EE2] Send request
    2017. 11. 27 18:46:39.7720024 1280  3972  Misc            *FAILED* [80072EE2] Library download error. Will retry. Retry Counter:0
    2017. 11. 27 18:48:39.7715765 1280  3972  Misc            *FAILED* [80072EE2] Send request
    2017. 11. 27 18:48:39.7715831 1280  3972  Misc            *FAILED* [80072EE2] WinHttp: SendRequestToServerForFileInformation (retrying with default proxy)

    Via ipv4 it goes normally. My Ipv6 is working just fine.

    Monday, November 27, 2017 5:58 PM

All replies

  • Hi ,

    Please check if the following link is helpful:

    Windows Server update on IPv6-only network

    https://serverfault.com/questions/844107/windows-server-update-on-ipv6-only-network

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    It seems that windows update won't work on an IPV6-only connection.

    As Dave said, you might provide feedback on uservoice.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 28, 2017 5:41 AM
    Moderator
  • Hi!

    This was working until 2017/11/20.

    Since this date it does not work any more.

    Tuesday, November 28, 2017 8:02 AM
  • Hi ,

    Before the issue happened, did you do any modifications? 

    Also check the log to see if there are something related for us to troubleshooting,

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, November 28, 2017 8:14 AM
    Moderator
  • Huh no changes at all.

    If I open sls.update.microsoft.com in firefox on ipv4 it displays 403 error, which is OK.

    If I do the  same on IPv6, page is not displayed at all.

    This is server side issue, I`m sure...

    Tuesday, November 28, 2017 10:02 AM
  • I have had the same issue in the UK (using a HE tunnel terminated in France) for I think about a couple of weeks.  It appears to be a MTU issue along the path to the IPv6 hosts that are hosting this (AAAA alias to sls.update.microsoft.com.nsatc.net).  Probably ICMP packet-to-big being blocked somewhere.

    If I reduce the MTU on the client side down to 1280 it all starts to work.  It seems this isn't a problem to the host fe2.update.microsoft.com (AAAA alias to fe2.update.microsoft.com.nsatc.net) that the Windows 7 hosts connect to.

    As a workaround as I didn't want to start changing the MTU on the clients or the internal VLAN SVI interfaces so I have changed the IPv6 MTU to 1280 on the P2P L3 interface between my switch and my router to the ISP.  I am guessing I could make this bigger but not knowing the maximum MTU along the path (and not having the time...) I have left it at 1280.

    Microsoft need to sort this out with nsatc.net...

    Andy







    • Edited by AndyBut Tuesday, November 28, 2017 7:50 PM
    Tuesday, November 28, 2017 4:52 PM
  • I've clamped MSS down to 1392 bytes and this seems to work for simple curl check via HE tunnel in Warsaw:

    ip6tables -t mangle -A POSTROUTING -d 2a01:110::/31 -o <interface> -p tcp --syn -j TCPMSS --set-mss 1392

    Tomek

    Tuesday, November 28, 2017 8:48 PM
  • Hi ,

    Just checking in to see if the information provided was helpful.

    Please let us know if you would like further assistance.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 30, 2017 9:58 AM
    Moderator
  • I think the information provided should help people with a workaround to the issue. However I believe the issue is a Microsoft (or their CDN provider) issue and should be investigated by Microsoft.

    Cheers

    Andy

    Thursday, November 30, 2017 11:37 AM
  • Hi!

    Info was unfortunatley not helpful.

    Saying that WinUpdate on IPv6 is not working while in reality was until 20.11. 2017 is nonsense.

    Please report this upstream, maybe someone will handle it in month or so.

    Thursday, November 30, 2017 5:33 PM
  • I'm also experiencing this same issue.

    No updates since 11/20/2017.

    Thursday, November 30, 2017 6:02 PM
  • tracert sls.update.microsoft.com
    Tracing route to sls.update.microsoft.com.nsatc.net [2a01:111:f335:1792::f001:7a5]

    According to their WHOIS information here: https://apps.db.ripe.net/db-web-ui/#/query?searchtext=2a01:111:f335:1792::f001:7a5

    ioc@microsoft.com

    Is the tech contact.

    I sent an email to them and I'll let you guys know if I hear back.

    Thursday, November 30, 2017 8:24 PM
  • Hi ,

    Based on the complexity and the specific situation, we need do more researches. If we have any updates or any thoughts about this issue, we will keep you posted as soon as possible. Your kind understanding is appreciated. If you have further information during this period, you could post it on the forum.

    Sorry for the inconvenience and thank you for your understanding and patience.

    Best Regards,

    Candy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, December 01, 2017 1:57 AM
    Moderator
  • It shouldn't be too complex.

    We have host names, IP addresses, problems descriptions (MTU misconfig/ICMPv6 blocking), even a date of breakage.

    Surely a company as large as Microsoft should have a process to keep track of changes.

    Plus, this has been broken for 10 days now so that is very slow response to a networking issue blocking access to services.

    Friday, December 01, 2017 2:29 AM
  • I would like to add a me too to this issue.

    David

    Friday, December 01, 2017 6:21 PM
  • As a work around for this issue, I applied the following DNS filter on my 2016 DNS hosts:

    Add-DnsServerQueryResolutionPolicy -Name "Filter AAAA Requests" -action deny -fqdn "EQ,*.microsoft.com" -QType "EQ,AAAA
    Saturday, December 02, 2017 5:35 PM
  • I posted a workaround (forcing a lower MTU at the client side), however the point is we shouldn't need to do this.  Even if there are lower MTU links in the path, ICMPv6 should take care of this.

    I have just checked and it still hasn't been fixed.  This is how many days and counting?


    • Edited by AndyBut Sunday, December 03, 2017 3:26 PM
    Sunday, December 03, 2017 3:20 PM
  • Yeah it`s kind of frustrating that such obvious issue can`t be fixed in few days...
    Monday, December 04, 2017 7:41 PM
  • Just tested this now and it seems this is now working.  Not sure who did what...

    Thursday, December 07, 2017 12:15 AM
  • I also confirm that this is working today.

    I removed the DNS filter and confirmed I am able to reach https://sls.update.microsoft.com [2a01:111:f335:1792::f001:7a5] again.

    Thursday, December 07, 2017 1:48 PM