When I was at Wireless Field Day 2, my standard question to all the vendors concerned IPv6 support.  Since I’m a huge proponent of IPv6 and the Internet will be arriving at IPv6 rather soon, I wanted to know what kind of plans the various wireless companies had for their particular flavor of access devices.  Most of the answers were the same: it’s coming…soon.  The generic response of “soon” usually means that there isn’t much demand for it.  It could also mean that there are some tricky technical challenges.  My first thought was about the operating system kernels being run on these access points.  Since most APs run some flavor of BSD/Linux, kernel space can be a premium.  Based on my own experiments trying to load DD-WRT on Linksys wireless routers, I know that the meager amount of memory on these little things can really restrict the feature sets available to network rock stars.  So it was that I went on thinking about this until I had a chance conversation with Matthew Gast (@MatthewSGast) from Aerohive.  Matthew is the chair for the IEEE 802.11 committee.  Yes, that means he’s in charge of running the ship for all the little subletters that drive wireless standards.  I’d say he’s somewhat familiar with wireless.  I spent some time at a party one night talking to him about the challenges of shoehorning IPv6 support into a wireless AP.  His answers were rather enlightening and may have caused one of my brain cells to explode.

Matthew started things off by telling me about wireless keys.  If you pick up Matthew’s book 802.11 Wireless Networks: The Definitive Guide, you can flip over to page 465 to read about the use of keys in wireless.  Keys are used to ensure that all the traffic flying around in the air between clients stays separated.  That’s a rather important thing when you consider how much data gets pushed around via wireless.  However, the frames that carry those keys are limited in the amount of space they have to carry key information.  So some time ago, the architects of 802.11 took a shortcut.  Rather than duplicating key information over and over again for every possible scenario, they decided to make the broadcast key for each wireless client identical.  This saved space in the packet headers and allowed the AP to send broadcasts to all clients connected to the AP.  They relied on the higher layer mechanisms inherent in ARP and layer 3 broadcast control to prune away unnecessary traffic.  Typically, clients will not respond to a broadcast for a different subnet than the one they are attached to.  The major side effect is that clients may hear broadcasts for VLANs for which they are not a member of.  For the most part, this hasn’t been a very big deal.  That is, until IPv6 came about.

Recall, if you will, that IPv6 uses multicast mechanisms to propagate advertisements about neighbor discovery and router advertisement (RA).  In particular, these RAs tell the IPv6-enabled clients about available routers that can be used to exit the local network.  Mulitcast is a purely layer 3 construct.  At layer 2 (and below), multicasts turn into broadcasts.  This is the mechanism that ensures that non-layer 3 aware devices can receive the traffic.  Now, think about the issue above.  Broadcast keys are all the same for clients no matter which VLAN they may be attached to.  Multicast RAs get converted to broadcasts at layer 2.  Starting to see a problem yet?

Let’s say that we have 3 VLANs in a site, VLAN 21, VLAN 42, and VLAN 63.  We are a member of VLAN 63, but we use the same SSID for all 3 VLANs.  If we turn on IPv6 for each of these three VLANs, we now have 3 different devices sending out RAs and SLAAC packets for addressing hosts.  If these multicast packets are converted into broadcast packets for the SSID, all three VLANs are going to see the same broadcast.  The VLAN information is inconsequential to the broadcast key on the AP.  We’re going to see the RAs for the routers in VLAN 21 and VLAN 42 on top of the one in VLAN 63.  All of these are going to get installed as valid exit points off the local network.  As well, the end system may even assign a SLAAC address to itself with a router from a different VLAN.  According to the end system, it heard about all of these networks, so they must all be valid, right?  The system doesn’t know that it won’t have a layer 2 path to them.  Worse yet, if one of those RAs has the best metric for getting off the local LAN, it’s going to be the preferred exit point.  The end system will be unable to communicate with the exit point.  Bummer.

How do we fix this problem?  Well, the current thinking revolves around suppressing the broadcasts at layer 2.  Cisco does this by default in their wireless controllers.  The WLAN controller acts as a DHCP relay and provides proxy ARP while ignoring all other broadcast traffic.  That’s great to prevent the problem from happening right now.  What happens when the problem grows in the future and we can no longer simply ignore these multicast/broadcast packets.  Thankfully, Matthew had the answer for that as well.  In 802.11ac, the new specification for gigabit speed wireless, they’ve overhauled all the old key mechanisms.  No longer will the broadcast key be shared among all clients on the same AP.  Here’s hoping that we can get some 802.11ac clients and APs out there and supported when the time comes to flip the big switch to IPv6.

I’d like to thank Matthew Gast for his help in creating this blog post and pointing out the problems inherent in broadcast key caching.  I’d also like to thank Andrew von Nagy (@revolutionwifi) for translating Matthew’s discussion into terms a non-wireless guy like me can understand.