Windows computers getting SLAAC IPv6 from tagged VLAN

Solution 1:

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.