Last week, I had the pleasure of attending the Aruba Networks 2011 Partner Summit. This event ran from Monday 4/4 through Wednesday 4/6 with the most significant density of activity on Tuesday.
I took about 14 pages of notes – more than usual for an event of this sort and feel like the event was worthwhile, in spite of the invariable backlog I accumulated back at the office.
We’ve been working with the Aruba Air Mesh (their outdoor industrial mesh product acquired from Azalea Networks) since 2008, but are a “newly-minted” Aruba Indoor Partner, so I had a lot of ground to cover.
First and foremost, I walked away with a very crisp vision of Aruba’s place in the market – how they view their products and the marketplace itself. Understanding the way they see the world helped me to understand a lot of things, especially their recent entrance into the closet switching market (see their Mobility Access Switches).
I’ll have to admit that, though the switching platforms seemed like great devices, I didn’t understand why Aruba would want to increase their competitive overlap with big players like Cisco, Juniper (did you know we’re now a Juniper partner?!) and HP. It didn’t make a lot of sense on the surface – until I heard from the Aruba CEO, Dominic Orr.
The Security Philosophy
I’ve long said that one of the biggest problems we face as IT professionals is the schizophrenic nature of security policies applied using differing tools, protocols and devices all over the network like a patchwork quilt. There are too many seams and too much complexity. The reality is that increased complexity is less secure – human nature has too many opportunities to slip us up as we make things more complex.
So how does Aruba simplify things? It all boils down to a radically different philosophy about network attachment: for as long as I’ve been involved in networking, the underlying vision has always been port-centric. Everything tied back to the port in some way. Granted, there were complex schemes to make bits and parts more “user focused”, but they were inelegant and inefficient. Aruba has really stepped up the game with a model that provides what we’ve really needed all along. I’m frankly amazed that nobody’s gone here before – though hindsight usually works like that!
Aruba’s focus is on identifying the user and device, independant of where and how they connect – and then applying a security edge that’s tailored to that user and their device (and even their OS/browser, etc.), no matter what media they use to connect. With this user-centric contextual model, security can be adapted to the requirements of the individual user and then further enhanced to account for the different types of devices they use to access the network. You don’t need to think about how they connect at all – it’s just enough to know that they can connect and leave it at that.
What happened to “Core/Distribution/Access”?
To see how this plays out, you need to understand how Aruba’s view of the future world for networking differs philosophically from the view of traditional providers (read: Cisco) in a fairly significant way: they see it consisting of essentially two big “buckets”. The first is datacenter – this can be internal to an organization, or in the cloud. It’s a market in which Aruba seems to have no horse or interest. The second (and final, in their mind) is the “access” layer. This encompasses EVERYTHING else: wired access, wireless access, VPN access. Any method a user can connect to the datacenter.
What’s particularly important here is that Aruba’s product strategy provides for a centralized user-centric AAA model that’s unified across all of the connection methods that also pushes a security policy to the point of connection based not only on user identity, but also based on other context information (such as device type and OS).
For example, if I connect to the network via WiFi with my laptop, and then via WiFi with my iPad, the context is different based on the device and OS – so a differential layered security policy can be applied: first the one for my user and then what amounts to an overlay on top of that for my device type (and even OS/Browser version). This policy can be applied to my wired ports, my wifi access and my VPN access (soft or hard client).
It’s all managed through the same centralized Mobility Controller architecture that Aruba wireless customers already know so well – just extended to wired access. Also, it’s all manageable by the Aruba AirWave management suite.
This is a significant break from the view of traditional wired access vendors – and amounts to the equivalent of a “wired access point” if you want to think of it that way.
Bad news for Intel and Microsoft? We’re plumbers?
Dominic got a few good laughs during his presentation on Wednesday, but one of his semi-humorous comments resonated with me when he was discussing the huge shift in the marketplace away from traditional architectures (wired to wireless), devices (PCs to smart phones and tablets) and vendors (away from Intel/MSFT to an architecture dominated by players like ARM/Apple). He said that Aruba’s role and Aruba’s partner’s roles were as “plumbers”. I like that particular analogy a lot.
His central point was that a HUGE amount of money will change hands as these marketplace and technology transitions take place and that the core infrastructure providers (us plumbers) are well positioned to capture a significant part of that.
It’s the people
Another key take-away for me was purely qualitative – and was with regard to the people at Aruba Networks and their corporate culture. They feel, to me, like Cisco used to feel back in the mid to late 1990s and early 2000s (yes, I’ve been a Cisco partner for that long!). They want to innovate, to disrupt, to partner, to team. They want to get deals done and they have the flexibility to make a deal happen. There wasn’t a single big ego to be found among the Aruba staff. THESE are the kind of people I want to work with and I want my customers to work with. They get things done and have fun doing it.
So, lest I sound like a total Aruba fan-boy, I’d be remiss if I didn’t mention a significant place where Aruba has been totally silent (at least so far as I’ve observed). It’s the inside of the device – especially the new wave of mobile devices like smart-phones and tablets.
We can make connection of these devices easy and flexible, we can implement a user-centric, device modified security perimeter at the point of connection, but that device still ends up with access to the network. So we still need to make sure that the device isn’t owned by malware. I think this is obvious, but it’s notably absent from Aruba’s articulation of their world view and the picture they paint is a little too rosy for my taste. I don’t want them to help customers lose sight of this important part of a secure architecture. In the meantime, it just means that we, as a partner, need to emphasize this element a little more carefully.
Seriously? The iPad will drive my business?
What else stood out? Tablets. The iPad in particular. It really is everywhere. It’s in the hands of all of the participants. It (and iPhone) is in the hands people in >80% of Fortune 100 companies. It was a $54.8M market in 2011 and is expected to be a $300M market by 2013 (thanks Gartner Group for the data that Aruba passed on to us!). Given my concerns about the security of such devices in enterprise environments, I’m still hesitant about this development, but cannot deny its impact.
It’s clear to me that helping my customers understand how to handle this inrush of “iDevices” will help me to better help them. I’ve been seeing them in the marketplace with increasing frequency and we’re actually making significant changes to our own network and internal security to support them securely – so too do our customers need to invest in the planning and implementation of policies and infrastructure to handle this massive new challenge.
A few more stand-out statistics (from Gartner as well, according to Aruba) that were scattered in various presentations throughout the event:
- The SmartPhone market was $289M in 2011 and expected to be $1B in 2013.
- Virtual desktops should be 45M strong by 2013. They accounted for 2% of desktops in 2009 and should be 13% by the end of 2012.
- The enterprise access market is $11B for 2013 – of which ~$3B is WLAN and with the impact of the iPad alone may be as high as $3.75B.
- Mobility budgets are increased 10% year-over-year since 2007 – despite the recession.
- 2011 – 2014 compound annual growth of network access for traditional Ethernet Switching is expected to be -2% and WLAN is +80%!
- Licensed band wireless infrastructure (cellular) costs 8-10X as much as WLAN to provide similar density coverage (this stat is an Aruba source, not Gartner – Aruba didn’t cite a source here).
Other notable items were:
- Aruba is increasingly hearing about WLAN coverage problems in non-traditional coverage locations: Bathrooms. Stairwells. Elevators. People want coverage EVERYWHERE! Remind me not to use other people’s iPads from now on. Ick!
- Density requirements for WLAN have changed: 5 years ago in a conference room meeting of 25 people, a handful might have had laptops with active WiFi. Today, every person could reasonably be expected to have one or MORE devices that could actually be active on WiFi. Smart phones, tablets and still even laptops. So a meeting of 25 people might have 30 or 50 (or more) active devices!
- Cloud architectures put users on the “wrong side” of the corporate firewall. I suppose I’ve been aware of the perimeter implications of cloud, but haven’t thought of it in quite this context.
That Tesla guy was smarter than everyone thought
In closing, I was reminded during a presentation of a quote by Nikola Tesla in 1926. This is, truly, mind blowing prescience:
“When wireless is perfectly applied the whole earth will be converted into a huge brain, which in fact it is, all things being particles of a real and rhythmic whole. We shall be able to communicate with one another instantly, irrespective of distance. Not only this, but through television and telephony we shall see and hear one another as perfectly as though we were face to face, despite intervening distances of thousands of miles; and the instruments through which we shall be able to do his will be amazingly simple compared with our present telephone. A man will be able to carry one in his vest pocket.”
There’s been much noise about IPv4 address runout and IPv6 adoption lately, even as far as some poorly written articles in the mainstream media. The IANA address pool was depleted on February 3rd, 2011, with the final /8 blocks being assigned to the RIRs for allocation. (ARIN article on IANA runout) Now, just over 2 months later, APNIC appears to be close to exhausting their assignable address pool, the first of the RIRs to do so. (IPv4 Address Report)
So, what does all this mean for non-carrier companies who haven’t adopted IPv6 yet? Will your networks fall off the face of the internet? Will websites become unavailable to your employees, or even worse, your customers?
Well, no. In fact, you probably won’t notice anything at all. IPv4/IPv6 dual-stack hosts will be the norm for the foreseeable future in most regions. However, we are facing the possibility of IPv6 only clients starting to show up in the Asia/Pacific region. This means that even though the sky isn’t falling, steps should be taken to adopt IPv6 in a manageable fashion, particularly if you have a global presence including a customer base in Asia.
Here at Semaphore Corporation, we’ve been running down this road for some time both to migrate our own network, as well as prepare ourselves for the process of assisting our customers in their migration. I’ll present a straightforward high-level roadmap of how we recommend handling IPv6 adoption based on our own experiences.
IPv6 adoption is a 6-phase process (more or less)
Phase 1 – Internet Connectivity and External Infrastructure
Several of the other phases are optional based on your needs and the scope of your customer base. This phase, however, is not. The single most important step in IPv6 adoption is ensuring your network provider supports IPv6 natively.
At this point, any major business class carrier should offer IPv6 support to their customers. Broadband providers may or may not be an exception to this, although most have pilot programs in place. The first step in this process should be to call your carrier and ask to receive an IPv6 address allocation and have it routed to you. You can typically base your address space request size on your current network infrastructure. The following list is the most likely possibilities for address allocation:
- Single directly-connected subnet – This model is most often seen in the datacenter for small deployments. Your layer-3 gateway for your external devices is your ISP, and you either have a single server or a layer-2 infrastructure handling connectivity to your servers. Your ISP will likely assign you a /64 (single IPv6 subnet) to match your current IPv4 needs.
- Single external subnet, multiple internal – There is much confusion as to how perimeter security will function under IPv6. Many state (myself among them) that NAT is no longer necessary and security should be performed on routed subnets. Even if you currently use NAT, if you have infrastructure with multiple subnets behind your firewall, I could recommend requesting an address allocation which can be divided up into smaller subnets. The size of this allocation will vary based on your carrier, ranging from a /60 (16 /64 subnets), a /56 (256 /64 subnets) all the way to a /48 (a lot of /64 subnets)
- BGP connected and/or multihomed network – If you’re running BGP and have your routes propagating into the global table via your own AS, a /48 is required. This appears to have been decided upon as the new /24, the longest prefix length that will be allowed into the global table. Attempting to announce a netblock smaller than a /48 will likely lead to it being filtered by many networks. There isn’t a particular need for a netblock larger than a /48, so this is likely what you will get.
- Tier 1/Tier 2 Network Service Provider – If you will be delegating BGP routable space to your end-customers, you will need to go to ARIN (or your local RIR) for you address assignment. The RIRs appear to be assigning /32 length networks to NSPs. Presumably, if you fall into this category, you’re already well on your way to adoption and this post isn’t for you. =)
External Network Infrastructure
This may or may not be required, depending on your particular network model. If your external servers live outside a firewall and are directly connected to a switch (the datacenter model mentioned above), then you may not need to do anything at all here. If you have a router outside your firewall, or a layer-3 switch, you’ll need to assess its IPv6 capability. Most modern layer-3 devices offered by the large players (Cisco, Juniper, etc) have supported IPv6 for years. A code upgrade may be required on some older chassis however. If you do have an external layer-3 device that supports IPv6, now is the time to bind the IPv6 network assigned by your ISP to the internet facing interface and begin testing IPv6 connectivity to outside networks. If you’ve gotten that far, congratulations, the hardest part is done! (Getting started)
Phase 2 – External Servers
This is the second phase that I would consider “mandatory” for most companies at this point. Everything past this phase can wait, since mostly likely companies in all regions will run their externally facing servers dual-stack indefinitely. However, if IPv6 only clients begin showing up, you need to make sure they can reach you! This phase includes external webservers, mail servers (although this is less critical as mail will be relayed by dual-stack hosts), DNS servers (again, relayed, so less critical). Focus first on ensuring that your external web presence is visible by both IPv4 and IPv6 users. Your primary website should be accessible by both v4 and v6 clients at the same URL. So, for example, http://semaphore.wpengine.com has both an A and a AAAA record. Earlier is was typical to see a site such as http://ipv6.semaphore.com or http://ipv6.www.semaphore.com. However, these are becoming less common, since users don’t know to look for them and they will expect the same names they used on IPv4 to work with IPv6. Most DNS servers should support querying on IPv6 addresses at this point. Note that you do not need to query a DNS server on its IPv6 address to receive an IPv6 AAAA record back from the server. Most dual-stack clients will continue to query their DNS servers on their IPv4 addresses for the time being. However, enabling IPv6 on your DNS servers will allow other IPv6 enabled DNS servers to switch to v6 as their primary querying method. Additionally, if your nameservers exist within you own domain (E.G semaphore.net’s DNS servers at ns1.semaphore.net and ns2.semaphore.net) you will need to register an IPv6 Glue Record for your server with your DNS registrar. This allows the registrar to point IPv6 clients to the server’s address to bootstrap the resolution process. This should be done for all DNS servers once they become IPv6 enabled.
Phase 3 – Firewalls and DMZ Servers
If your website is served by a server on a DMZ for security reasons, this phase is for you! Firewalls provided by the large networks vendors (recent Cisco ASA firewalls, and Juniper Netscreen and SRX firewalls) support IPv6 in all recent code revisions. You will need to confirm support from whoever your existing vendor is, or evaluate replacing your firewall. (I’m a big fan of the Juniper SRX, personally.) Something else to consider is caveats for IPv6 deployment. If you are running active/passive stateful failover, there may be restrictions on IPv6. For example, older Cisco PIX firewalls support IPv6, but not in stateful failover mode. This is also the time to determine whether you will be doing NAT or not. Again, my recommendation is to drop NAT for IPv6. A modern flow/session based firewall can provide just as much security without requiring complex NAT/PAT rules for inbound traffic. If you are doing NAT, you will need to research the site-local scoped address space, the IPv6 equivalent of RFC1918 Private IPv4 address space.
Servers in your DMZ will need to be evaluated in the same way as your external servers in the above phase. If you aren’t doing NAT, then all that will be required is to allow inbound traffic for web, mail, etc to the server’s address and you’re done. No port-translations are required for the DMZ, which was the typical approach for a DMZ in the IPv4 world.
Phase 4 – Internal Network Infrastructure
This is the first phase that is truly optional at this point. As I mentioned above, all externally facing resources even in IPv4 constrained Asia will likely continue to respond on both IPv4 and IPv6 addresses for the foreseeable future. However, progress should be made towards eventually supporting a dual-stack architecture company-wide.
Much like the external infrastructure above, all internal layer-3 devices should be assessed for IPv6 support. Internal layer-2 only devices (access switches) need not be upgraded, although if you want the future capability to manage them via an IPv6 address, they too will need IPv6 support. If you were assigned a subnettable block from your ISP, address space planning should be done at this stage, matching your IPv4 internal subnetting scheme. Again, if NAT is in use, you will be using the site-local IPv6 address space for your internal networks.
If your network uses any site-to-site VPN via IPSec or other secured tunnels, this is also the time to evaluate if the tunnel endpoints support IPv6. Because IPSec is built in to the IPv6 protocol, most site-to-site VPN endpoints should support it fully. Configuration may be dramatically different than the equivalent IPv4 configuration.
Phase 5 – LAN Servers
Many LAN services simply do not support IPv6 at this point. However, some basic services most likely do and can be turned up immediately. Services such as internal DNS can be assigned IPv6 addresses which will allow them to query IPv6 DNS servers on the internet. Things such as internal web services, file servers and other basic LAN servers can slowly have dual-stack IPv6 addresses added over time. Corporate mail servers such as Exchange (2007 or later) support IPv6 and can have v6 addresses added, but make sure to read the vendor’s list of caveats for the particular software and OS version you are running prior to adding any IPv6 addresses to the server.
Phase 6 – LAN and VPN clients
As mentioned above, there is no reason to have IPv6 only clients at this point in time. This is a good thing, as IPv6 only clients have some major hurdles at this point. In particular, there is no widely supported way to pass DNS server configuration information to clients receiving and automatic IPv6 address. IPv6 address autoconfiguration is performed via one of three methods currently:
- Router Advertisement (Stateless autoconf) – This is the most common method for client autoconfiguration at this point in time. The router on the subnet periodically broadcasts its address and the address of the network. IPv6 clients listen for this broadcast and assign themselves an address and default gateway based on that information. There are extensions to allow for DNS configuration to be passed to the client as well, (RDNSS), but they are not widely supported at this time. For dual-stack hosts, this method works perfectly and seamlessly. When we implemented this on our network, our employees were happily surfing IPv6 websites without even realizing it was happening.
- DHCPv6 (Stateful autoconf) – This method requires a DHCPv6 server running on the network (either on the router, or elsewhere). Much like IPv4’s DHCP, DHCPv6 maintains a database of all address leases on the network. It can also pass along information such as DNS server addresses or other custom options to the clients. However, at this point, DHCPv6 CANNOT pass along a gateway IP address, making it of questionable value.
- Stateless DHCPv6 – This will mostly likely be where we end up once the dust settles. This method relies on the router advertisement/network discovery model to handle address and routing/gateway management. An “other configuration method” flag is set on the router, telling the client to broadcast for a DHCPv6 server once it has its address. The DHCPv6 server in this case hands off DNS information (and other other custom) fields to the client, but does not need to keep a database of addresses.
VPN clients will most likely be using the IPv6-specified IPSec protocol. You should check with your VPN concentrator/firewall vendor for support for IPv6. It will also be necessary to confirm that the VPN software being used by your clients supports IPv6 as well. We have not yet implemented client-based dynamic VPN for IPv6, so I can’t speak to how easy this process is to implement. If you’ve made it work, let us know!
This process can still seem daunting at first, although it is fairly straightforward if you handle it in small manageable chunks. Semaphore Received its /32 allocation from ARIN in 2003 and has been working with IPv6 even since. If you are a company in the Pacific Northwest Area and would like assistance with IPv6 adoption, please don’t hesitate to contact us! Our consulting engineers would be happy to help you with a readiness assessment and help you form a plan for full IPv6 adoption over time.
To contact us, please email email@example.com.