Eliminating Barriers To Deploying IPv6
Early in my career, I had the opportunity to work with one of the IETF leaders in what was then called IPng, the “next generation” Internet Protocol. Today, that effort is better known by its version number: IPv6.
Unlike some other ballyhooed technologies of the time (ATM, I’m looking at you here), IPv6 turned out to be a technology of the future, and even better, that future arrived.
Work at Aerohive on IPv6 started many years ago, in part because I thought it was interesting. In networking, there is a much closer collaboration of theory and practice than in other technical disciplines. Writing code is, as always, important, with questions of how to best design and build networks as an equally important discipline. As I like to put it: There’s no substitute for actually using a network technology on a real live network.
Hurricane Electric, one of the biggest public supporters of IPv6, agrees with me, at least by their actions. They built a self-directed “certification” program that helps network engineers learn about IPv6 by really using it. At the start of my time at Aerohive many years ago, I hooked up to their IPv6 tunnel broker, put IPv6 addresses on everything I could, and I’ve never looked back.
Been there, done that, and got the t-shirt. Yes, Hurricane Electric gives away a t-shirt with the IPv6 packet format on the back. I proudly wear mine to bed, though it’s getting a bit worn by this point. They also publish some interesting information on the distribution of “IPv6 Sages,” those who have attained the top level in the self-directed program.
What does this mean for Aerohive, and more importantly, our customers?
Well, the first step in working with IPv6 was to not get in the way. Mike Kouri, a long-time networking product manager, calls this the “do no harm” stage. You want to use IPv6? It’s our job to prevent HiveOS from stopping you from doing that. Since we operate largely at layer 2 of the OSI model, no special work was required to support moving IPv6 traffic through an Aerohive AP.
Way back in 2010, I was using an Aerohive network to support IPv6 traffic. (As far as I can tell, my home network was running IPv6 well before many companies were. And yes, I have an IPv6 firewall.) Address assignment can be done either using DHCPv6, or the more commonly used stateless address auto configuration (SLAAC).
Over the years, we quietly worked to remove as much “harm” for IPv6 as possible. IPv6 automatic address assignment and multiple VLANs on Wi-Fi networks can interact poorly. I think we first observed that in the Interop show network years before I joined Aerohive. To prevent problems with SLAAC-assigned addresses on multiple VLANs, we added multicast-to-unicast conversion and filtering.
SLAAC works by having routers dole out the network part of an IPv6 address in a packet called a router advertisement (RA) and letting client devices assign the host part. In rough terms, it would be as if an IPv4 router enabled a network administrator to define a VLAN as being 10.5.0.0/16 (the first two bytes), and letting clients self-assign the last half of the address. Because the RAs are multicast, the easiest way to prevent a wireless client from receiving multiple router advertisements is to convert RAs to unicast only for the intended stations.
IPv6 was developed before cryptographic security was widespread, and address assignments are not authenticated. For basic security, HiveOS can protect the network from misconfigured client devices by blocking both DHCP & RAs.
The final bit of the “do no harm” is to add visibility into HiveManager for IPv6 addresses, both as router advertisements and as the IP addresses assigned to clients.
The next frontier that we’re actively working on is making IPv6 equivalent to IPv4, and we’re planning the release this quarter. Merry Christmas, IPv6 lovers!
For management capabilities on an IPv6 network, we’re adding an IPv6 stack into HiveOS. From the beginning of HiveOS, Aerohive built a flow-based QoS engine for queuing and prioritization. Mapping of the IPv6 QoS signaling into WMM queues will be slightly different from IPv4’s DiffServ Code Point (DSCP), but conceptually, it is a similar feature.
Finally, there are two additional features that will be part of our initial IPv6 release.
Application visibility and control (AVC) works by examining network traffic flows and recognizing applications. Most applications do not need anything to enable support for IPv6 except perhaps the use of a system call to open an IPv6 socket instead of an IPv4 socket. Neither TCP or UDP needed changes to support IPv6, and that is where application recognition plugs into the network stack. It’s a relatively minor effort to connect up the AVC engine with IPv6 packet processing.
The biggest effort in these steps to IPv6 parity is in firewall capabilities for IPv4 and IPv6. For efficiency, speed, and performance, firewalling happens in the HiveOS kernel. Like AVC, it was originally written around the IPv4 packet processing in the kernel. Extending firewalls to IPv6 requires plugging into a the IPv6 stack, as well as creating commands to configure and manage IPv6 packet filtering rules.
If you’re interested in working on IPv6 with us, I highly recommend the Hurricane Electric program, as well as one of the many browser extensions that will tell you whether you have reached a web site using IPv4 or IPv6.
Questions about IPv6? Tweet me.