mobile | The Networking Nerd

IPv6Revolution

There are days when IPv6 proponents have to feel like Chicken Little. Ever since the final allocation of the last /8s to the RIRs over four years ago, we’ve been saying that the switch to IPv6 needs to happen soon before we run out of IPv4 addresses to allocate to end users.

As of yesterday, ARIN (@TeamARIN) has 0.07 /8s left to allocate to end users. What does that mean? Realistically, according to this ARIN page that means there are 3 /21s left in the pool. There are around 450 /24s. The availability of those addresses is even in doubt, as there are quite a few requests in the pipeline. I’m sure ARIN is now more worried that they have recieved a request that they can’t fulfill and it’s already in their queue.

The sky has indeed fallen for IPv4 addresses. I’m not going to sit here and wax alarmist. My stance on IPv6 and the need to transition is well known. What I find very interesting is that the transition is not only well underway, but it may have found the driver needed to see it through to the end.

Mobility For The Masses

I’ve said before that the driver for IPv6 adoption is going to be an IPv6-only service that forces providers to adopt the standard because of customer feedback. Greed is one of the two most powerful motivators. However, fear is an equally powerful motivator. And fear of having millions of mobile devices roaming around with no address support is an equally unwanted scenario.

Mobile providers are starting to move to IPv6-only deployments for mobile devices. T-Mobile does it. So does Verizon. If a provider doesn’t already offer IPv6 connectivity for mobile devices, you can be assured it’s on their roadmap for adoption soon. The message is clear: IPv6 is important in the fastest growing segment of device adoption.

Making mobile devices the sword for IPv6 adoption is very smart. When we talk about the barriers to entry for IPv6 in the enterprise we always talk about outdated clients. There are a ton of devices that can’t or won’t run IPv6 because of an improperly built networking stack or software that was written before the dawn of DOS. Accounting for those systems, which are usually in critical production roles, often takes more time than the rest of the deployment.

Mobile devices are different. The culture around mobility has created a device refresh cycle that is measured in months, not years. Users crave the ability to upgrade to the latest device as soon as it is available for sale. Where mobile service providers used to make users wait 24 months for a device refresh, we now see them offering 12 month refreshes for a significantly increased device cost. Those plans are booming by all indications. Users want the latest and greatest devices.

With the desire of users to upgrade every year, the age of the device is no longer a barrier to IPv6 adoption. Since the average age of devices in the wild is almost certain to be less than 3 years old providers can also be sure that the capability is there for them to support IPv6. That makes it much easier to enable support for it on the entire install base of handsets.

The IPv6 Trojan Horse

Now that providers have a wide range of IPv6-enabled devices on their networks, the next phase of IPv6 adoption can sneak into existence. We have a lot of IPv6-capable devices in the world, but very little IPv6 driven content. Aside from some websites being reachable over IPv6 we don’t really have any services that depend on IPv6.

Thanks to mobile, we have a huge install base of devices that we now know are IPv6 capable. Since the software for these devices is largely determined by the user base through third party app development, this is the vector for widespread adoption of IPv6. Rather than trumpeting the numbers, mobile providers and developers can quiety enable IPv6 without anyone even realizing it.

Most app resources must live in the cloud by design. Lots of them live in places like AWS. Service providers enable translation gateways at their edge to translate IPv6 requests into IPv4 requests. What would happen if the providers started offering native IPv6 connectivity to AWS? How would app developers react if there was a faster, native connetivity option to their resources? Given the huge focus on speed for mobile applications, do you think they would continue using a method that forces them to use slow translation devices? Or would they jump at the chance to speed up their devices?

And that’s the trojan horse. The app itself spurs adoption of IPv6 without the user even knowing what’s happened. When’s the last time you needed to know your IP on a mobile device? Odds are very good it would take you a while to even find out where that information is stored. The app-driven focus of mobile devices has eliminated the need for visibility for things like IP addresses. As long as the app connects, who cares what addressing scheme it’s using? That makes shifting the underlying infrastructure from IPv4 to IPv6 fairly inconsequential.

Tom’s Take

IPv6 adoption is going to happen. We’ve reached the critical tipping point where the increased cost of acquiring IPv4 resources will outweigh the cost of creating IPv6 connectivity. Thanks to the focus on mobile technologies and third-party applications, the IPv6 revolution will happen quietly at night when IPv6 connectivity to cloud resources becomes a footnote in some minor point update release notes.

Once IPv6 connectity is enabled and preferred in mobile applications, the adoption numbers will go up enough that CEOs focused on Gartner numbers and keeping up with the Joneses will finally get off their collective laurels and start pushing enteprise adoption. Only then will the analyst firms start broadcasting the revolution.

I’ve had the good fortune to be involved with Aerohive Networks ever since Wireless Field Day 1. Since then, I’ve been present for their launch of branch routing. I’ve also convinced the VAR that I work for to become a partner with them, as I believe that their solutions in the wireless space are of great benefit to my customer base. It wasn’t long ago that some interesting rumors started popping up. I noticed that Aerohive started putting out feelers to hire a routing and switching engineer. There was also a routing and switching class that appeared in the partner training list. All of these signs pointed to something abuzz on the horizon.

Today, Aerohive is launching a couple of new products. The first of these is the aforementioned switching line. Aerohive is taking their expertise in HiveOS and HiveManager and placing it into a rack with 24 cables coming out of it. The idea behind this came when they analyzed their branch office BR100 and BR200 models and found that a large majority of their remote/branch office customers needed more than the 4 switch ports offered in those models. Aerohive had a “ah ha” moment and decided that it was time to start making enterprise-grade switches. The beauty of having a switch offering from a company like Aerohive is that the great management software that is already available for their existing products is now available for wired ports as well. All of the existing polices that you can create through HiveManager can now be attached to an Aerohive switch port. The GUI for port role configuration is equally nice:

Screen Shot 2013-03-03 at 4.14.11 PM

In addition, the management dashboard has been extended and expanded to allow for all kinds of information to be pulled out of the network thanks to the visibility that HiveManager has. You can also customize these views to your heart’s content. If you frequently find yourself needing to figure out who is monopolizing your precious bandwidth, you’ll be happy with the options available to you.

The first of three switch models, the SR2024, is available today. It has 24 GigE ports, 8 PoE+ ports, 4 GigE uplinks, and a single power supply. In the coming months, there will be two additional switches that have full PoE+ capability across 24 and 48 ports, redundant power supplies, and 10 GigE SFP+ uplinks. For those that might be curious, I asked Abby Strong about the SFPs, and Aerohive will allow you to use just about anyone’s SFPs. I think that’s a pretty awesome idea.

The other announcement from Aerohive is software based. One of the common things that is seen in today’s wireless networks is containment of application traffic via multiple SSIDs. If you’ve got management users as well as end users and guests accessing your network all at once, you’ve undoubtedly created policies that allow them to access information differently. Perhaps management has unfettered access to sites like Facebook while end users can only access it during break hours. Guests are able to go where they want but are subject to bandwidth restrictions to prevent them from monopolizing resources. In the past you would need three different SSIDs to accomplish something like this. Having a lot of broadcasted SSIDs causes a lot of wireless congestion as well as user confusion and increased attack surface. If only there was a way to have visibility into the applications that the users are accessing and create policies and actions based on that visibility.

Aerohive is also announcing application visibility in the newest HiveOS and HiveManager updates. This allows administrators to peer deeply into the applications being used by users on the network and create policies on a per-user basis to allow or restrict them based on various criteria. These policies follow the user through the network up to and including the branch office. Later in the year, Aerohive will port these policies to their switching line. However, when you consider that the majority of the users today are using mobile devices first and foremost, this is where the majority of the visibility needs to be. Administrators can provide user-based controls and reporting to identify bandwidth hogs and take appropriate action to increase bandwidth for critical applications on the fly. This allows for the most flexibility for both users and administrators. In truth, it’s all the nice things about creating site-wide QoS policies without all the ugly wrench turning involved with QoS. How could you not want that?

Tom’s Take

Aerohive’s dip into the enterprise switching market isn’t all that shocking. They seem to be taking a page from Meraki and offering their software platform on a variety of hardware. This is great for most administrators because once you’ve learned the software interface and policy creation, porting it between wired switch ports and wireless APs is seemless. That creates an environment focused on solving problems with business decisions, not on problems with configuration guides. The Aerohive switches are never going to outperform a Nexus 7000 or a Catalyst 4500. For what they’ve been designed to accomplish in the branch office, however, I think they’ll fit the bill just fine. And that’s something to be buzzing about.

Disclaimer

Aerohive provided a briefing about the release of these products. I spoke with Jenni Adair and Abby Strong. At no time did Aerohive or their representatives ask for any consideration in the writing of this post, nor were they assured of any of the same. All of the analysis and opinions represented herein are mine and mine alone.