Windows 10 seemingly ignoring IPv6 Router Advertisement prefix while accepting DNS settings

Question

Setup

Until yesterday everything worked fine:

OpenBSD Router doing NAT64 and DNS64, as well as Router Advertisments (for a subnet requested via DHCPv6-PD)
Windows 10 getting its IP via Router Advertisements
GNU/Linux device in the same network also doing fine
OpenBSD Hyper-V VM on the Windows 10 machine doing IPv4 NAT transparently translating to IPv6 to be NAT64-ed on the other side again (as to provide a fallback for broken software like Steam)

Problem

After some minor changes of the Firewall settings, of which I am 95% sure are rolled back by now, the Windows box doesn't have an IPv6 address anymore. Both the OpenBSD VM, and the GNU/Linux box both get their IPv6s just fine and routing works like a charm. Even the IPv4 NAT for the OpenBSD VM works. So I start debugging and at some point end up looking at Wireshark, clearly seeing the arriving Router Advertisement packets, with an IPv6 prefix (/68), and DNS Search Domain, and DNS Server Address options set. Looking at the Windows 10 networking infos however, I see only the DNS settings applied, those are being applied just fine though. So now the device (a Hyper-V Virtual Switch device endpoint, shared with the OpenBSD VM) has a search domain, a DNS server, and its link-local address, and is unable to access the outside world. If I manually assign an address from the IPv6 prefix it works just fine too.

At this point I think I tried everything to reset my networking configuration back to zero, but the result doesn't change; DNS settings yay, IPv6 address nay.

Configuration

netsh interface ipv6

Interface vEthernet (bridge) Parameters
----------------------------------------------
IfLuid                             : ethernet_32776
IfIndex                            : 25
State                              : connected
Metric                             : 25
Link MTU                           : 1500 bytes
Reachable Time                     : 33500 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       : disabled
Weak Host Sends                    : disabled
Weak Host Receives                 : disabled
Use Automatic Metric               : enabled
Ignore Default Routes              : disabled
Advertised Router Lifetime         : 300 seconds
Advertise Default Route            : disabled
Current Hop Limit                  : 0
Force ARPND Wake up patterns       : disabled
Directed MAC Wake up patterns      : disabled
ECN capability                     : application
RA Based DNS Config (RFC 6106)     : enabled
DHCP/Static IP coexistence         : enabled

Network Adapter

Has everything in its properties disabled except for the QoS Packet Scheduler and the Internet Protocol Version 6 (TCP/IPv6). The latter currently has the hardcoded IPv6 addresses for self, gateway, and DNS set (however those come from DHCPv6-PD and are subject to change in around 12 hours, so that's only a temporary measure) so that I can write this here post. If I set all of those options to automatic, I get the network adapter with only DNS configured as described above.

Question

How to get Windows 10 to accept the Router Advertisement in a way that also uses the prefix and assigns the hardware derived (EUI-64 AFAIK) an the temporary IPv6 address, and installs the default routes (like all other devices currently do)? In case you need any further information regarding my configuration, just tell me what you need and what format you need it in.

Accepted Answer

Turns out the problem was much more straightforward than I had expected.
Stateless address auto-configuration on Windows seems to be using EUI-64, which does use the interface ID (in this case the link-level address) to fill the lower 64 bits of the address.
However as described in my question, the prefix I was using is 68 bits (and later on 80 bits) in size, therefore EUI-64 cannot be used (even though the link-level address would fit perfectly in that /80 subnet).
The same issue exists on Linux when using only sysctl's to configure the address, however I was using dhcpcd which simply doesn't care and generates an address regardless, same for OpenBSD with inet6 autoconf.

The solution here as far as I can determine is to either use DHCPv6 to assign addresses, or to use a prefix of size 64 or larger (i.e. smaller number).
Ever since I got myself another /64, which included a switch of hoster and whatnot, but in the end it turned out to work as soon as I used a /64.

Hope this helps anyone else stumbling across this issue.

Answer

@benaryorg Hi,

Thank you for posting in Q&A!

In the IPv6 stateless autoconfiguration mechanism, when the routers respond the host's request with an RA, which contains the network part of the Layer 3 IPv6 address (IPv6 Prefix). The host will use the IPv6 prefix provided by the RA.

According to your description, the RA message arrived with with an IPv6 prefix (/68), howeve the client fail to accept. It's an unnormal phenomenon.

Firstly I would suggest you to disable the third party application such as firewall on the client. This action is to exclude the possiblity of applications blocking the message.
What' more, you said that "After some minor changes of the Firewall settings" which could also be the cause of this issue. However, since we don't know which specific changes are made in your firewall, so we cannot say it for sure.

After my disscussion with my colleagues, in order to find the cause of your issue, it can only be achieved by capturing network packets. But as a forum engineer, log analysis is beyond the scope of our support. We would suggest you open a case with Microsoft. In this way , they can have a clear picture about your issue and your environment by phone communication and live share session.

You may find phone number for your region accordingly from the link below:
https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

Hope you have a nice day : )
Gloria

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
https://learn.microsoft.com/en-us/answers/articles/67444/email-notifications.html

Share via