The Importance of IPv6 testing - the number of the beast

While service providers fret about the end of IPv4 addresses, how should the enterprise IT team prepare for IPv6? Alan Way International Business Development Manager at Spirent Communications explains

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.

We were 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 the 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 inherent 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 is minor, but you cannot be absolutely sure of their combined effect without exhaustive testing.

This is the work that we 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.

Whether you use Spirent equipment, or outsource the testing to our engineers, the process is the same. The network can be modelled in the lab with simulated real world operation matching the exact profiles of everyday traffic. The load can be increased to the point of failure, providing important data about the network’s load potential, and then a whole range of extreme conditions can be imposed singly or in parallel - local system breakdown, attack conditions, traffic bursts etc. Detailed reports are automatically generated, pinpointing bottlenecks or weak points in the network.

Before the upgrade has even been rolled out, you have prior warning of how it could impact the network. Often the results show minor, inexpensive tweaks that are all that is needed to optimise the network, sometimes customers discover that they were about to over-invest in expensive upgrades where a much cheaper solution would work just as well. The test can pay for itself in such cases.

Then, once the network has been upgraded optimally, you can incorporate an automated ongoing test program that continually monitors the system performance and quality of service, providing advance warning of any new problems that might arise.

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.”