none
Windows 10 Anniversary Update breaks DHCPv6 client

    Question

  • I have an IPv6 enabled LAN.  I use Stateless Address Autoconfiguration (M flag on the router set to 0) and Stateful Other configuration (O flag set to 1) so the IPv6 clients generate thier own IPv6 addresses and use DHCPv6 to obtain the DNS server IPv6 addresses.  I have a couple of Windows 2008 R2 DHCP servers with just Global Server Options configured under IPv6.  These options are '23 DNS Recursive Name Server IPv6 Address List' and '24 Domain Search List'.  These servers are on different networks so I have DHCPv6 forwarding configured on my layer-3 switches to the IPv6 addresses of the two DHCPv6 servers.

    This has worked effortlessly with Windows Vista, Windows 7 and Windows 2008/R2 as well as Windows 10 version 1511.  The clients see the router advertisements with the M flag set to 0 and the O flag set to 1 and generate their own IPv6 addresses and then send a DHCPv6 Information Request requesting options 23, 24, 17 & 32.  The DHCPv6 server responds with options 23 & 24 and the client gets the IPv6 DNS servers.

    I have built a couple of machines with the new Windows 10 Anniversay Update and the DHCPv6 behaviour has changed.  The client generates its own stateless IPv6 addresses but no longer sends a DHCPv6 Information Request and instead sends a Solicit like it would if the M flag was set to 1.  Obviously the DHCPv6 server does not respond since it doesn't have a scope configured for the clients prefix.

    This is what it shows on the client:

    netsh interface ipv6>show dnsservers

    Configuration for interface "Ethernet"

        DNS servers configured through DHCP:  None

        Register with which suffix:           Primary only

    Configuration for interface "WiFi"

        DNS servers configured through DHCP:  None

        Register with which suffix:           Primary only

    netsh interface ipv6>show interface wifi

    Interface WiFi Parameters

    ----------------------------------------------

    IfLuid                             : wireless_32768

    IfIndex                            : 3

    State                              : connected

    Metric                             : 40

    Link MTU                           : 1500 bytes

    Reachable Time                     : 18500 ms

    Base Reachable Time                : 30000 ms

    Retransmission Interval            : 1000 ms

    DAD Transmits                      : 1

    Site Prefix Length                 : 64

    Site Id                            : 1

    Forwarding                         : disabled

    Advertising                        : disabled

    Neighbor Discovery                 : enabled

    Neighbor Unreachability Detection  : enabled

    Router Discovery                   : enabled

    Managed Address Configuration      : disabled

    Other Stateful Configuration       : enabled

    Weak Host Sends                    : disabled

    Weak Host Receives                 : disabled

    Use Automatic Metric               : enabled

    Ignore Default Routes              : disabled

    Advertised Router Lifetime         : 1800 seconds

    Advertise Default Route            : disabled

    Current Hop Limit                  : 64

    Force ARPND Wake up patterns       : disabled

    Directed MAC Wake up patterns      : disabled

    ECN capability                     : application

    netsh interface ipv6>

    I tried adding a scope to the DHCPv6 server and it does reply and I can see in the WireShark trace that options 23 & 24 are given, however the client does not complete the DHCPv6 process and still shows no IPv6 DNS Servers received via DHCPv6.  I have also configured the router to set the M flag to 1 and I can see that it knows the M & O flags are now both set to 1 on the client:

    Managed Address Configuration      : enabled

    Other Stateful Configuration       : enabled

    I have compared this behaviour to a Windows 7 SP1 host and whether I use Stateless DHCPv6 (M=0, O=1) or Stateful DHCPv6 (M=1, O=1) it works perfectly.

    I have also booted a Windows 10 AU machine on the same VLAN as one of the DHCPv6 servers and the behaviour is the same.  I did notice on one occasion that at 1st boot it did send an Information Request and showed the IPv6 DNS Servers in ipconfig, however after disabling and re-enabling the NIC they disappeared and on subsequent reboots it didn't work.

    I am guessing that this is a bug in the IPv6 stack in Windows 10 Anniversary Update?  I have seen some other people complaining about this issue so has Microsoft acknowledged it and commited to providing a fix?

    Andy



    • Edited by AndyBut Thursday, August 25, 2016 4:30 PM
    Thursday, August 25, 2016 11:37 AM

All replies

  • Found another post regarding other people reporting this issue. Its obviously a core networking issue and Microsoft need to address it with some urgency.

    As a workaround I can issue the command 'ipconfig /renew6' and Windows sends out a DHCPv6 information request (as Windows 7 does) and gets a reply from the DHCPv6 server with the IPv6 DNS servers and the domain search list (options 23 & 24).

    Andy

    Saturday, August 27, 2016 8:01 AM
  • I experience the same issue with statefull DHCPv6 and "ipconfig /renew6" resolves the issue temporary, but Windows 10 loses it's address when the lease time expires. It does not automatically renew.
    Monday, October 03, 2016 10:54 AM
  • You are in the "Windows desktop debugging" forum (because of some other routing error?)

    The Windows (Server) Platform networking forum is here.

    Win10 client networking forum is here.

    Regards,

    - pa

    Monday, October 03, 2016 11:44 AM
  • Noticed this issue today and your workaround provides temporary relief.  Thanks.
    Tuesday, October 04, 2016 2:56 PM
  • I've encountered this issue as well. It's pretty inexcusable for it to take so long for this issue to be addressed, let alone for such a fundamental feature to be broken in the first place.
    Thursday, October 06, 2016 8:46 PM
  • It's been 2 month since you reported that and MS still haven't addressed the problem..... ?!
    Monday, October 24, 2016 10:30 AM
  • Its quite shocking to be honest.

    I am on the Windows Insider Programme and have a machine configured for 'Fast Ring' updates.  Last night it upgraded to Build 14955 and the problem is still there.  How can such a fundamental networking problem still exist

    Wednesday, October 26, 2016 7:51 AM
  • Its quite shocking to be honest.

    I am on the Windows Insider Programme and have a machine configured for 'Fast Ring' updates.  Last night it upgraded to Build 14955 and the problem is still there.  How can such a fundamental networking problem still exist

    I'm in the process of updating my system to 14955. I'm disappointed and completely unimpressed that this inexcusable problem has not been fixed. Microsoft, if you are listening, this does nothing to instill confidence or respect from your user community.
    Wednesday, October 26, 2016 6:38 PM
  • Note that you keep posting to a wrong forum. So maybe the right MS people just have not seen your message.

    - pa

    Wednesday, October 26, 2016 7:00 PM
  • Noted, thanks.
    Thursday, October 27, 2016 5:58 PM