Conferences & Events
Events for all Levels and InterestsStay
Jump Start Your Career GrowthStay
Get on the Higher Ed IT MapStay
Uncommon Thinking for the Common Good™Stay
IPv6 VLAN tagging in Windows
In June of 2011, LSU encountered a peculiar issue with IPv6 while participating in World IPv6 Day. To explain the cause of the issue, a brief overview of port configuration is necessary.
Every switchport on the LSU campus is set up with an untagged VLAN for data and a voice VLAN command. This setup allows for the rapid deployment of VOIP phones and is also critical in the event of a disaster scenario. This network implementation will also allow disaster personnel to attach VOIP phones without the aid of a network team to configure ports on-the-fly. With this configuration, Windows clients will receive an address from the untagged data VLAN and then later an address from the tagged VOIP VLAN.
Initially, a device connected to these ports will receive an ipv6 address from the untagged vlan. After a short, random amount of time some devices will obtain a second ipv6 address that corresponds to the tagged vlan. This behavior will cause ipv6 network connectivity to cease within the routed domain but works between routing domains. This scenario only presents itself on routers that have the same MAC address (and thus same link-local address) on each switch virtual interface (SVI). If the link-local addresses are different on each SVI this will not cause an issue, as the client will receive multiple link-local addresses for its default gateway and be able to route properly.
The issue described above was only encountered on Windows clients. This behavior is a result of how VLAN tagging is handled according to Microsoft’s NDIS. If VLAN tags are not stripped then SVI’s having the identical MAC addresses will not be an issue as shown with MAC and Linux operating systems. It is important to note, however, that this issue only occurs with IPv6. Windows seems to treat IPv6/IPv4 differently when it concerns VLAN tagging.
It is important for Microsoft to take a second look at how the NDIS is written and how they treat VLAN tagging. LSU has already contacted Microsoft concerning the issue, but was informed that a design change request will only be entertained if there is enough business justification and interest backing the change. Therefore, being that this group is part of a handful that has operational experience with ipv6, we encourage you to explore this issue. Then, contact your Microsoft representative to help create a backing for this request.
We do have several workarounds in place, which we will gladly share upon request. Thank you for your consideration.
Network Analyst II
University Networking & Infrastructure
Louisiana State University
Baton Rouge, LA 70803
Convergence Specialist, M.S.E.E., P.E.
University Networking and Infrastructure - LSU
200 Computing Services Building
Baton Rouge, LA 70803