IPv6 One Year In: Is Your Data Center Any More Efficient?

One year after the date when the main carriers of data traffic on the Internet were encouraged to switch their IP address schemes from IPv4 to IPv6 permanently, the migration to a new way of counting hosts is actually on track.  Last year, the Internet Society told me that we’d be able to measure the real impact of the new address scheme on network performance — both on the small and large scales — in a few years’ time.

According to a live map of IPv6 address deployments by geography compiled by Cisco, IPv6 is the scheme in use by 48.26 percent of US-based IP hosts, and 59.1 percent of US hosts responsible for forwarding IP traffic throughout the Internet.  Many other countries have embraced IPv6 even further, with Switzerland leading the way at 89.56 percent overall IPv6 deployment, and Romania not far behind.  All of this represents significant gains in one year’s time.

But what’s really happened, besides a reduction in the once-perennial warning that the world is running out of network addresses?  When IPv6 was introduced at the turn of the century, its engineers promised to improve the efficiency of the network routing process itself by eliminating the need for IPv4’s most infamous workaround: network address translation (NAT).  A decade ago, NAT was the principal element of firewalls; some used to define the network “inside the firewall” as the set of all addresses assigned through NAT.

Without NAT, network engineers should be finding it easier to implement subnet routing, and to configure routing and domains for enterprise networks.  So we’re experiencing those benefits now... right?

I spoke this week with Leslie Daigle, Chief Internet Technology Officer for the Internet Society — a coalition representing the interests of major Internet stakeholders, and that’s one of the first questions I asked her.

I think the key thing is indeed to separate out the discussion of deploying IPv6, from how to achieve quality of experience, and meeting expectations in network usage.  I think it’s also fair to say we can’t possibly implement achieving expectations if we don’t continue to have a globally addressable network.  All of these coping mechanisms that are deployed — the large-scale Network Address Translation, and whatnot — the complexity that they add makes the IPv4 network that much more difficult to manage as a network, and that much more complex to deal with in terms of making sure you have the network experience that you expect.  In that regard, IPv6 is necessary in order to ensure you have the network you expect.  But if it’s not sufficient, we have other work we have to do.

In recent years, stakeholders discovered it was easier to encourage IP hosts to transition their address scheme by simplifying the goal:  We all want a bigger address space.  Everything else we might want comes later, but first we need more space.

The dawn of IPv6 also appeared to promise engineers new tools for implementing quality-of-service (QoS) provisions.  The most controversial of these had been a system for compartmentalizing service classes — a system which proponents of net neutrality said would give premium treatment to major players like Google and Akamai.  Such proponents would add that such a system, if implemented in that way, would enable preferential bias towards certain cloud service providers that also happen to be major IP traffic carriers.

This issue remains a hotbed of contention in Switzerland, where formal discussions began among members of the Swiss IPv6 Council last May.  Daigle believes such discussions may have their place, but in the context of IPv6 may end up slowing down the transition.

The reality is, there are a lot of discussions around the globe, and still sadly some confusion about what IPv6 is and is not.  We try to keep our messages fairly simple, in terms of focusing on the constructive:  “Why do we need this?”  “Because we’re running out of IPv4.”

Keeping the message simple may have taken one of IPv6’s most promising features out of the discussion: IPsec, the session encryption scheme.  While IPsec is a “bolt-on” feature for IPv4-based networks, it’s a standard feature of IPv6.  But it’s not turned on by default, and that could be because not enough admins know it’s there.  Says Daigle:

I think it’s a question of people turning on IPv6 mostly as an analog to their IPv4 networks these days.  They may grow into some of the feature possibilities as they go along...  In the era when [IPv6] was deployed, the expectation was that everyone would start using it, and dual-stacking their networks [using both address schemes simultaneously], and it would just sort of flow.  It was failing to understand that the Internet was entering a commercial phase, and a lot of players just want a network they can set up and get to run — they don’t want to be thinking about it all the time.  If you look at IPsec in that context, it’s possible that there’s additional complexity, making sure you get it right.  Since then, enterprise networks have also developed to make use of more invasive techniques for what traffic is passing on them, which is a little harder with IPsec.  So the answer is still valid:  This is a way to secure your network traffic.  The question is, do you, the network operator, really want to secure your traffic that way?