My customer has about a dozen WAP200 access points. We are currently in the process of deploying IPv6 and we have hit upon a serious problem where the WAP200 forwards some untagged traffic from the ethernet into wireless SSIDs which should be bridging only VLAN tagged traffic. This results in wireless clients seeing IPv6 Router Advertisements from the wrong VLAN and prevents IPv6 from working correctly.
I believe this is a serious bug in the WAP200 firmware which causes it to process broadcast traffic without a VLAN tag as if it was also sent in the configured VLANs. This breaks IPv6 stateless autoconfiguration in some (presumably quite common) network configurations.
I have reproduced this problem with firmware 2.0.2.4-ETSI (latest available) and also 1.0.22-ETSI (with which the devices were shipped).
The customer's network carries a mix of VLAN tagged and untagged traffic. The untagged traffic is their main internal network. Most workstations are not aware of the VLANs and happily see and use the internal network. The customer's security policy does not allow the internal network to be bridged onto 802.11 wireless, so we also run three separate VLANs on the same ethernet segment. Each of these VLANs is exposed by the WAP200s as a separate SSID. This means that the customer's staff can pick up a WAP200 and plug it into the network at any point and it will allow all three wireless networks to be used from that locality and there is no risk of violating the security policy by accidentally connecting it to the wrong socket.
The WAP200s are all configured with three SSIDs. Each SSID has a separate VLAN tag associated with it. The WAP200's management VLAN is also set to one of these VLANs. When VLAN tagged traffic is bridged onto the wireless SSID the tag is stripped off and when traffic arrives on the wireless interface the VLAN tag associated with the SSID is attached before it is bridged onto the wired network. In other words, the WAP200 should never process untagged traffic on the wired network -- it should totally ignore it.
We've recently deployed IPv6 at the site. IPv6 uses Router Advertisements to allow hosts to automatically configure their IPv6 address. The IPv6 Router Advertisements are sent to the IPv6 address FF02::1 which is the link-local all-nodes multicast address. On ethernet this corresponds to a MAC address of 33:33:00:00:00:01 (recall that ethernet addresses with a 1 in the least-significant bit of the first octet are multicast). The IPv6 router sends an untagged Router Advertisements advertising the IPv6 prefix for the main company network, as well as three VLAN tagged Router Advertisements advertising the three IPv6 prefixes for each of the wireless networks.
The problem we see is that a wireless client connected via a WAP200 will see two separate router advertisements: The router advertisement for the wireless network IPv6 prefix is received as expected, but ALSO the router advertisement for the main company network prefix. This is wrong; the WAP200 is forwarding the untagged IPv6 Router Advertisement into the SSID where only VLAN tagged traffic should be forwarded!
The net result is that wireless clients assign themselves IPv6 addresses in two prefixes, but the prefix they assign relating to the main company network is unusable. They cannot send traffic to the main company network IPv6 router address, and they cannot receive reply traffic sent onto the main company network to their address.
When I first discovered this I assumed I had made an egregious error and set about isolating where the problem was.
I unplugged the IPv6 router and plugged it directly into a laptop running wireshark. I confirmed that I saw four router advertisements and that each bore the correct VLAN tagging;
- No VLAN tag: 2001:888:ffaa:1::/64
- VLAN tag 111: 2001:888:ffaa:111::/64
- VLAN tag 112: 2001:888:ffaa:112::/64
- VLAN tag 113: 2001:888:ffaa:113::/64
So the IPv6 router is generating the correct traffic.
I then thought that maybe the switch was forwarding the untagged traffic into the tagged VLANs, so I unplugged a WAP200 and plugged in my laptop running wireshark instead. I saw the same four router advertisements. I did not see any frames with VLAN tags carrying a router advertisement for 2001:888:ffaa:1::/64.
I then reconnected the WAP200 and connected my laptop's wireless card to the SSID associated with VLAN tag 112. I ran wireshark again and saw router advertisements for both 2001:888:ffaa:112::/64 (as expected) and 2001:888:ffaa:1::/64 (which was wrong!). Note that I did not see the router advertisements for 2001:888:ffaa:111::/64 or 2001:888:ffaa:113::/64 in this SSID.
Here's what tcpdump sees arriving on the wireless interface:
21:05:04.953360 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 88) fe80::d685:64ff:fed5:863b > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 88
hop limit 64, Flags [none], pref medium, router lifetime 180s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): 2001:888:ffaa:1::1/64, Flags [onlink, auto, router], valid time 3600s, pref. time 1800s
0x0000: 40e0 0000 0e10 0000 0708 0000 0000 2001
0x0010: 0888 ffaa 0001 0000 0000 0000 0001
rdnss option (25), length 24 (3): lifetime 180s, addr: 2001:888:ffaa:1::1
0x0000: 8000 0000 00b4 2001 0888 ffaa 0001 0000
0x0010: 0000 0000 0001
mtu option (5), length 8 (1): 1460
0x0000: 0000 0000 05b4
source link-address option (1), length 8 (1): d4:85:64:d5:86:3b
0x0000: d485 64d5 863b
21:05:06.915092 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 88) fe80::d685:64ff:fed5:863b > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 88
hop limit 64, Flags [none], pref medium, router lifetime 180s, reachable time 0s, retrans time 0s
prefix info option (3), length 32 (4): 2001:888:ffaa:112::1/64, Flags [onlink, auto, router], valid time 3600s, pref. time 1800s
0x0000: 40e0 0000 0e10 0000 0708 0000 0000 2001
0x0010: 0888 ffaa 0112 0000 0000 0000 0001
rdnss option (25), length 24 (3): lifetime 180s, addr: 2001:888:ffaa:112::1
0x0000: 8000 0000 00b4 2001 0888 ffaa 0112 0000
0x0010: 0000 0000 0001
mtu option (5), length 8 (1): 1460
0x0000: 0000 0000 05b4
source link-address option (1), length 8 (1): d4:85:64:d5:86:3b
0x0000: d485 64d5 863b
This bug does not seem to affect IPv4 broadcast traffic (which is sent to MAC FF:FF:FF:FF:FF:FF with type field 0x0800) but it does affect at least IPv6 multicast traffic sent to MAC 33:33:00:00:00:01 with type field 0x86DD. It may be that other traffic is also affected but this is what I managed to observe in my limited testing yesterday.
Please note that the customer has requested I change the top 48 bits of the IPv6 prefix to conceal their identity.
Is this a bug in the WAP200 as I believe? If so, how to do I go about getting this bug fixed? It is clearly a serious issue that will affect increasingly large numbers of people as IPv6 becomes more widely deployed -- likely to be quite soon as the IPv4 address space is due to be exhausted in less than 100 days.
