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.