Myths Surrounding IPv6

IPv6 has been on the way for well over ten years now, yet for much of the world it has been irrelevant until recently. Now, as the shortage of IPv4 addresses begins to become obvious to even the most hardened sceptic, awareness and interest is growing.

Change always causes concern - not least about who will pay for it all. But the mood is changing; the need to move to IPv6 is becoming clearer. People are asking "how?" instead of "why?" IPv6 is being seen, correctly, as an investment rather than a cost. The more people learn, the more they realise that IPv6 is not merely a way to avoid the address space crunch, it is also a path to innovation and new opportunities.

As more and more people work with IPv6, more and more information about IPv6 experiences is becoming available on the Web. People are discovering the resources they need. Along with good information, bad information is out there, and some tenacious myths are causing unwarranted concern. We address the more common ones in the following sections. At the end of each section is a short note on why these matters - which often seem to be only of academic or technical relevance - are important to industry.

Myth: We don't need IPv6

This is perhaps the biggest myth, made all the more persistent by the fact that most people can connect to the Internet without IPv6 - at the moment.

There are two ways in which an organisation can need IPv6. The first, and most obvious, is that we really are running out of IPv4 address space. We may quibble about when, but it is most certainly going to happen. Eventually, an organisation which uses only IPv4 will find its plans halted when it makes an application for IPv4 address space which cannot be met. More prudent organisations will move before that crunch comes.

The second way IPv6 is needed is as an generator of opportunity and a platform for innovation. While it would be foolish to say of IPv4 that everything which can be invented has been invented, it is certainly true to say that there are classes of network applications that just aren't possible with IPv4 - for example, vehicle-mounted telemetry, which might involve millions of networked sensors on cars. Or simply giving every adult Indian resident an IP networked mobile telephone. With IPv6 a world of new possibilities for innovation opens up.

Some organisations will continue to use IPv4 and use mechanisms such as NAT to buy time. Countries like India, with huge populations and burgeoning technical competence, will almost certainly not attempt this, and will move to IPv6 directly. In fact, we can see this happening already in places like Japan, Korea and China. These countries either are already or will become very large markets. Organisations that wish to be active in those markets but do not use IPv6 will be at some competitive disadvantage.

Myth: IPv6 will replace IPv4

This may be true in the longer term - decades or more - but is certainly not true in the foreseeable future.

There is simply too much IPv4 infrastructure, with too much money and know-how invested in it, and with too many nooks, crannies and edge cases for IPv6 to simply replace IPv4. Natural (and appropriate!) caution will see IPv6 implemented alongside IPv4, with IPv6 taking over more and more of the network. While IPv4 and IPv6 cannot communicate directly, there are very good solutions for communicating from IPv6 to legacy IPv4 networks.

This is a very important point - an organisation wishing to take advantage of IPv6 does not need to discard its IPv4 infrastructure.

Myth: IPv6 is so much more complicated!

Their larger size makes IPv6 addresses look quite daunting; perhaps because of that a perception has arisen that managing IPv6 is somehow much more complicated than IPv4. This is not really true.

Almost all the important ancillary protocols like DNS work in IPv6 pretty much as they do with IPv4, and in some areas - autoconfiguration and multicast being two major examples - have been greatly simplified.

The vast address space means no more endless reconfiguring of limited address space. This makes life much simpler for network managers, especially in applications where the number of connected nodes varies widely, such as wireless networks.

There are some new ancillary protocols - like multicast listener discovery or router advertising, but for the most part these replace some similar mechanism in IPv4. Network managers have been using CIDR (classless interdomain routing) for years now with IPv4, and addressing works the same way in IPv6.

In general, IPv6 is far more similar to IPv4 than it is different. What this means for industry is that the (often very great) investment an organisation may have made in training and educating its technical staff is not invalidated by IPv6. Quite the contrary - the more people know about IPv4, the more easily they will be able to adapt to and then manage, administer or innovate in an IPv6 environment.

Myth: You can't multi-home with IPv6

Organisations that need uninterrupted network connectivity will often set up network connections to more than one upstream provider. This is known as "multi-homing". Multi-homing is generally managed with some sort of routing protocol, so that if one link goes down, the other can take over. Multi-homing is sometimes done for efficiency - to have the best network paths to different destinations.

The allocation policies for IPv6 address space were based, for a long time, on two things: The assumption that an organisation would need only one upstream provider, and the strong desire to avoid overloading the global routing table. Allocations were thus strictly hierarchical. While an organisation could obtain addresses from more than one provider, downstream allocations would always be from one or the other of those providers.

If the link to that provider failed, those downstream with allocations from that provider would lose connectivity. This led to the belief that IPv6 itself prevented multi-homing, but it was only ever the allocation policies that frustrated multi-homing.

In 2007, allocation policies changed, and address space was set aside for provider-independent allocations. The allocation policy is now essentially the same as it was for IPv4 - if an organisation can demonstrate a need for provider-independent addressing, it can obtain IPv6 address space that is not tied to any provider.

What this means for industry is that organisations having redundancy, reliability or high-availability requirements can meet those requirements with IPv6.

Myth: Quality of Service is better with IPv6

The only QoS mechanisms built-in to IPv6 are a few header fields that are supposed to be used to distinguish packets belonging to various classes of traffic and to identify related packets as a "flow". The intention is that these header fields should allow devices such as routers to identify flows and types of traffic, and do fast lookups on them. In practice, use of these header elements is entirely optional, which means that the vast majority of devices don't bother with anything other than the bare minimum support required.

It is possible that, as IPv6 is more widely deployed, these header elements will become more important. However, IPv4 has similar header elements, intended to be used in similar ways, so the claim that IPv6 QoS is better than that in IPv4 is tenuous.

What this means for industry is that any QoS requirement will probably have to be met with solutions that are protocol independent.

Myth: IPv6 is automatically more secure than IPv4

It would be more accurate to say that IPv6 is no less secure than IPv4. The main security mechanism built into IPv6 is IPsec. IPsec is not new - it can be used with IPv4 as well, and this has been possible since its earliest days. However, a conforming implementation of IPv6 must support IPsec, while there is no such requirement in IPv4. This has led to the misconception that IPv6 is automatically more secure than IPv4: instead, it still requires careful implementation and well-educated system and network staff.

In some other ways IPv6 in fact does support better security: that IPsec can be guaranteed to be supported fosters its use and propagation. The header design in IPv6 is better, leading to a cleaner division between encryption metadata and the encrypted payload, which some analysts consider has improved the IPsec implementation. And the huge address space can, if desired, be used to defeat scanning attacks by simply allocating random addresses within subnets.

However, the bottom line for IPv6, as for all protocols and systems, is that education, training and awareness are the best investments from a security perspective.

Myth: The lack of NAT in IPv6 reduces security

This is a myth based on a myth - the real myth is that NAT increases security. Because NAT exists to overcome a shortage of IPv4 addresses, and because IPv6 has no such shortage, IPv6 networks do not require NAT. To those who see NAT as security, this appears to mean a reduction in the security of IPv6. However, NAT does not offer any meaningful security.

NAT works by changing outgoing packets in a predictable, harmless and reversible way, so that returning packets can be identified as belonging to a particular connection. A side effect of this is that the internal addresses of the hosts behind the NAT device are obfuscated. This is the only security NAT offers, and it does no more than prevent random attacks; it presents no real barrier to a skilled attack. And of course, it is no barrier at all to attacks coming in as email payloads or via open ports.

Many NAT devices (for example, small consumer routers) allow incoming connections to specific services - such as a web server - to be forwarded to hosts on the internal network. Some NAT devices offer a "DMZ" feature, where all incoming connections are directed to a particular internal host. The hosts in these cases are entirely unprotected by NAT, though the NAT device may implement other strategies to protect them. These other strategies are independent of NAT itself, and are as easy to implement and as valid in IPv6 as in IPv4.

Myth: NAT is not a problem

The issue of address exhaustion is regarded by many as a solved problem, and NAT is seen as a robust, effective and problem-free solution. This is not the case.

First, NAT can only ever offer about 16 million contiguous addresses (the size of a /8 IPv4 network). More can be achieved by using multiple levels of NAT, but each level introduces a performance loss, and makes it harder to troubleshoot network problems. It would require a preposterous number of layers of IPv4 NAT to approach the size of a single /64 IPv6 subnet. The address spaces offered by NAT simply do not compare to the vast, flat address spaces possible with IPv6. An organisation that wants to use lots of addresses will want to avoid NAT.

Second, NAT works by rewriting parts of the packets it forwards - especially addresses - in ways that the recipient cannot necessarily reverse. This is a fundamental problem for any protocol that carries address information as part of the packet payload. NAT devices must be programmed to recognise such protocols, so that the addresses can be properly rewritten wherever they appear in outgoing or incoming packets. It is also a fundamental problem for any protocol that wants to use a back-channel - where the remote host opens a second (or third or fourth) connection back to the instigating host.

NAT has been around for years, so most of the popular protocols have long since been dealt with. However, precisely because NAT is now so entrenched, all new IPv4 protocols must be written with NAT in mind. This leads to complex solutions which are complex solely because of the requirement to work with NAT. Any peer-to-peer protocol will tend to have difficulties with NAT, for example, because peer-to-peer protocols almost by definition involve the transfer of addressing information between the peers. So we see the rise of STUN servers for VoIP, for example. Some kinds of protocol have insurmountable difficulties with NAT (some security protocols for example, and some QoS protocols), precisely because they need to know the real structure of the network in order to be effective. An organisation wanting to create or use an innovative new protocol will be hampered by NAT. An organisation wanting to use end-to-end security like IPsec will be hampered by NAT.

Third, the outside address of a NAT device typically changes, in many cases often. The hosts behind NAT do not reliably have the same address over time. This has led to the rise of dynamic DNS solutions, but these are barely adequate. They are slow to react to changes, and leave the organisation dependent on outside entities for name service. An organisation wanting to be visible on the Internet will want to be statically addressable, which in the IPv4 world means greater expense.

Fourth, the addresses of the hosts behind NAT are not visible to the outside world; in fact, as far as the outside world is concerned, all of the hosts behind NAT have the same address. Individual hosts are not addressable except via port forwarding and similar stop-gaps in NAT.

Fifth, because it hides the real structure of the network, NAT imposes often unnoticed additional costs on enterprises and small users alike - costs such as the difficulty of troubleshooting, but also the difficulty of tracing bad behaviour. An organisation that wants to know, for example, which of its hosts is responsible for what connections will find itself severely hampered by NAT.

In short, NAT is a problem. But because it exists above all to deal with a shortage of addresses, it is simply not necessary with IPv6. This means that protocols running over IPv6 can be simpler, cleaner and more efficient. This leads in turn to them being easier to implement, easier to debug and easier to deploy. IPv6, as far as managers, administrators and innovators alike are concerned, is a vastly to be preferred platform.