Windows computers getting SLAAC IPv6 from tagged VLAN

I have windows computers on a network that are un-unexpectedly getting an IPv6 address from tagged VLAN.

I have routers/computers connected to a switch with an untagged vlan (id 1), and a tagged (id 2). For simplicity, lets say this VLAN2 is for VoIP handsets that will see an option to use the tagged vlan as part of a DHCP request.

For some reason Windows computers on this network are picking up a SLAAC address from both the 2001:db8:1051:4001::/64 and 2001:db8:1051:4002::/64 subnets. I expected Windows computers to only pick up addresses from the untagged VLAN/Subnet.

A windows computer with address from the 2001:db8:1051:4002::/64 will not be able to actually use this address for anything. It cannot ping the gateway 2001:db8:1051:4002::1 and a ping from the gateway doesn’t work. As far as I can tell it cannot actually use this address in any way.

A wireshark capture from on the Windows system with the filter icmp6 and ip6[40] == 134 will show the route advertisements for both subnets.

A tcpdump capture from that same computer booted to a Linux livecd will show that the 2001:db8:1051:4002::/64 advertisements with the proper vlan id in the Ethernet frame. Linux does not get addresses from both subnets.

The Windows computers are completely clean new installs of Windows 10 1709, and I have seen the behavior on systems with both Realtek, and Broadcom adapters.

Configuration

 +--------------+    +-----------+    +------------------+
 | Linux Router +----+ HP Switch +----+ Windows Computer |
 +--------------+    +-----------+    +------------------+

Linux router interface configuration

3: eth_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0c:c4:7a:14:c7:fd brd ff:ff:ff:ff:ff:ff
    inet 10.2.25.1/24 brd 10.2.25.255 scope global eth_lan
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1051:4001::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ec4:7aff:fe14:c7fd/64 scope link
       valid_lft forever preferred_lft forever
5: eth_lan.2@eth_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0c:c4:7a:14:c7:fd brd ff:ff:ff:ff:ff:ff
    inet 10.2.26.1/24 brd 10.2.26.255 scope global eth_lan.2
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1051:4002::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ec4:7aff:fe14:c7fd/64 scope link
       valid_lft forever preferred_lft forever

Linux RADVD Config

interface eth_lan
{
    AdvSendAdvert on;
    AdvManagedFlag on;
    AdvOtherConfigFlag on;
    MaxRtrAdvInterval 90;
    MinRtrAdvInterval 30;
    prefix ::/64
    {
    };
};
interface eth_lan.2
{
    AdvSendAdvert on;
    MaxRtrAdvInterval 90;
    MinRtrAdvInterval 30;
    prefix ::/64
    {
    };
    AdvDefaultPreference low;
};

Switch configuration

HP-2530-24G-PoEP# show running-config

Running configuration:

; J9773A Configuration Editor; Created on release #YA.15.14.0007
; Ver #05:18.63.ff.37.27:91
hostname "HP-2530-24G-PoEP"
snmp-server community "public" unrestricted
vlan 1
   name "DEFAULT_VLAN"
   untagged 1-28
   ip address dhcp-bootp
   exit
vlan 2
   name "VLAN2"
   tagged 1-28
   no ip address
   exit

Questions:

Why are Windows systems getting a non-functional IPv6 address from the tagged VLAN? Is there any way to stop this without disabling IPv6 on VLAN 2 or not having that VLAN tagged on ports Windows systems are connected to?

---

Answers to questions from the comments

Are the Windows machines able to communicate on the network if you assign them static IPv6 address

A computer connected to a port (untagged vlan1, tagged vlan2) will work perfectly fine if given a static address from the VLAN 1 subnet, but will not work on the VLAN2 subnet which is what I would expect to happen.

Have you tried disabling SLAAC on the router and only using DHCPv6?

If I disable SLAAC AdvAutonomous off; and enable a stateful DHCPv6 server computers will only get an address from the untagged VLAN.

What happens if you disable RA’s on eth_lan.2?

The client will not get addresses from that VLAN 2 subnet then. Though, I want IPv6 to work on that subnet so RA is pretty much required.

I would make sure the NIC’s driver are fully installed with their minidriver to enable VLAN support in the OS correctly.

Native Windows NDIS don’t support correctly VLAN and it just strip the VLANid in worst case.

Quoted from Wireshark;

Windows has no built-in support mechanisms for VLANs. There aren’t
separate physical and VLAN interfaces you can capture from, unless a
specialized driver that adds such support is present.

So whether you see VLAN tags in Wireshark or not will depend on the
network adapter you have and on what it and its driver do with VLAN
tags.

Most “simple” network adapters (e.g. widely used Realtek RTL 8139) and
their drivers will simply pass VLAN tags to the upper layer to handle
these. In that case, Wireshark will see VLAN tags and can handle and
show them.

Some more sophisticated adapters will handle VLAN tags in the adapter
and/or the driver. This includes some Intel adapters and, as far as i
know, Broadcom gigabit chipsets (NetXtreme / 57XX based chips).
Moreover, it is likely that cards that have specialized drivers will
follow this path as well, to prevent interference from the “real”
driver.

Update 1
=======

Found a MS Blog reference there; Windows Core Networking talk about 802.1P, but they give some more info on 802.1Q (VLAN tagging)

The Windows networking stack fully supports the 802.1Q tag, i.e. both
UserPriority (as Mathias discusses in this post) as well as VlanId.
However, no stack component (tcpip, etc.) ever acts on the VlanId
field. Vendors, such as Intel, Broadcom, etc., implement VLANs in
their miniport drivers in combination with NIC hardware. Thus, Windows
enables ISVs to implement VLAN if they wish, but does not natively
implement them.

– Gabe

From that other MS blog (that could explain why your Windows computer can’t ping the IPv6’s gateway (and easy to validate with the wireshark, as the outgooing packet (PC->Gateway) would be unttaged even if it’s supposed to be tagged))

Your NIC is responsible for adding the 802.1q tag to the outgoing
packet.

With that update in mind, my term “strip the vlan id” was a bit heavy at first, as it don’t strip it by default, it get the vlan id as input, but ignore it, and it just don’t send the vlan id out after, and leave all that management to the NIC’s driver.