While service providers fret about the end of IPv4 addresses, how should enterprises prepare for IPv6?

IPv6

IPv6 is suddenly hot news. Running out of Internet addresses has a suitably Armageddon sound to boost news headlines, and we are all sufficiently hooked on the Internet to shiver at the thought of losing it.

You would think that IPv6 had just leapt out of the unknown like some marauding beast, but that’s far from true. We’ve been helping organisations test their support for the new protocol and dual stack functionality since 2004.

I was helping some organisations, including the US Department of Defence, get ready for IPv6 over five years back. The problem was understood, but did not look like an imminent threat so people got a bit bored with it. Now suddenly IPv6 is back in the news and we’re being asked to help again. In the meantime, it seems, economic difficulties put IPv6 on the back burner and it was forgotten, until the recent scare about ”the end of IPv4”.

So it is time to take another cool look at the issue from the enterprise user angle. How serious is it? What is the real threat for the enterprise? What is the best strategy to adopt and why?

Will it just go away?

If the topic has been on the back burner for several years, why not just wait it out for now? There’s not a lot of short term incentive to gear up for IPv6 if your partners and customers are all on IPv4, which is almost certainly the case across Europe and the USA. Where IPv6 is growing fastest is in the East or developing nations, where many new users are coming on line and the shortage of new addresses is an imminent threat.

Even when we run out of addresses later this year, it is not be the end of Internet services, because service providers have several ways round the problem. NAT (Network Address Translation) means that IPv4 addresses already in use elsewhere can be ascribed within a network, and given a unique IPv6 label outside the network.

As a message comes into the network, the NAT server translates that unique address IPv6 into the internal IPv4 address, and vice versa as a message leaves the network. Another approach is to ”tunnel” IPv6 packets inside IPv4 packets, so that your IPv6 contacts can communicate with your legacy IPv4 system, and similarly your messages can be tunnelled back to them inside IPv6 packets if need be. The 6RD (IPv6 Rapid Development) solution uses thae tunnelling approach.

So why bother to upgrade? The answer is that NAT and tunnelling solutions are just a workaround, needing in-line processing of the messages and so adding latency to the system. The organisation that sticks doggedly to its old IPv4 inheritance won’t be cut off from the outside world, it will simply suffer increasingly degraded performance as more and more communications move to IPv6. For financial services and such high speed transactions this would be disastrous. For other businesses, it could still erode their competitive edge.

The risks

There are other problems in store if you do nothing about IPv6. Firewalls won’t recognise IPv6 traffic unless programmed to do so. So a legacy system could allow IPv6 packets through unimpeded. The only reason this easy route has not been taken up widely by the criminal community is because so far the majority of targets are still on IPv4. But there are IPv6 botnet and malicious control packets already in circulation, so the danger will only grow. If your organisation really does not need IPv6, then the safest thing is to block all IPv6 traffic until such time when your customer base demands it.

If you do decide to support IPv6 traffic, then be aware that tunnelling can provide a route for malicious IPv6 code to be concealed in harmless seeming IPv4 packets. It is not enough for the firewall to simply support IPv6, you must also add deep packet inspection technology to ensure clean traffic, and it must do so without compromising your network performance.

There are further risks tnherent in the IPv6 protocol itself. For example, IPv6 allows multicast traffic that could be blocked in IPv4, and it is possible to define rogue virtual devices that behave like a router and kidnap legitimate IPv6 traffic. These are getting beyond the scope of this article, it is enough to know that such risks exist.

On the plus side, IPv6 within the corporate network makes it much easier to encrypt traffic. Considering the fact that two-thirds of all successful hacks are initiated inside a network, rather than penetrating from without, the ability to run encryption from the desktop instead of just from the network edge has significant security implications – a consideration in the early uptake of IPv6 among government and defence organisations.

An optimal strategy

It is clear that, for many SMOs at least, there is something to be said for denial. If you do not rely on IPv6 users at present, then block such traffic for the time being. That will give you breathing space to plan better decisions for the future. Let others do the pioneering, give time for some of the security issues mentioned to be solved or sorted, and upgrade to IPv6 properly when the time is ripe.

A ”proper” upgrade must include pre-testing the network. One can list all the changes and carefully think through their implications and take every precaution to ensure no snags, and yet, such is the complexity of today’s networks, that the only sure way to know you have done it right is to test the whole structure both for functionality and performance, especially under attack or stress conditions. A network can work perfectly for months and then collapse under rush traffic – the very time when you most depend on it.

Upgrading to IPv6 inevitably means running both protocols in tandem – the time when no-one will need IPv4 lies years ahead. So consider what this means. In addition to your firewalls and intruder prevention systems having to be programmed for both types of traffic, routers will need to be re-configured, and servers interfaces and border relay routers will be running in dual stack mode. Each of these changes are minor, but you cannot be absolutely sure of their combined effect without exhaustive testing.

This is the work that I began in 2004 when a few large and forward looking organisations decided that they should be IPv6 ready. The secret is to build testing into the upgrade strategy from the very beginning, rather than tacking it on as an afterthought.

Today’s networks are complex, they form an ecosystem that can be finely balanced and subject to surprising behaviour when relatively small changes are made. IPv6 is just such a change – so don’t take it up without being sure your system can take it. Test it, or be tested.

Alan Way is the International Business Development Manager for Spirent. A telecommunications industry veteran with more than 20 years of experience, Alan has worked on deploying a variety of network technologies. During this time, he has lectured extensively on the integration of voice and data networks, IPTV, IPv6, cloud computing, SAN technologies, virtualization and associated technologies. Originally from Guernsey in the Channel Islands, enjoys Surfing, Skiing & Golf going to the movies and the pub on Friday night.

  • Hi Alan:

    Great post today – we hear this all the time from investors to clients (why now?) and you nailed it – it is simply no longer an option and the ushering in of v6 promises to enhance entire internet experience from end to end by “flattening” the internet architecture.

    Out of curiosity, to approach v6 (selfish question here), what do you see as most pressing for organizations as far as firs steps (e.g., what, if any, tools are people looking to assist them in both dual stacking as well as managing IPv6?)