IPV6 Myths

Myth #1: IPv6 networking provides service/location separation
Reality: Totally bogus.

A broken protocol stack and a broken reference implementation are among the biggest issues the Internet is facing today. Both require an application to take a service name, translate it into a network address and establish a connection to that address. Burdened with a transport protocol (TCP) that still lives in the dial-up world, the applications simply cannot cope with a service that is available on multiple network locations.

The IPv6 networking protocol could have solved this problem if its architects hadn't limited themselves to the single goal of extending address length. In its current incarnation, IPv6 gives us a longer address and nothing more.

Myth #2: IPv6 will simplify multihoming
Reality: Missed opportunity.

The designers of IPv6 took multihoming seriously and developed a protocol in which a single host can easily acquire multiple IPv6 addresses, even from address spaces belonging to multiple upstream service providers. Unfortunately, they've never tested their theories in real life. Having multiple IPv6 addresses does not help if the upper layers cannot use them efficiently (see previous myth).

Technologies that could support efficient multihoming with IPv6 are already available (SHIM and SCTP, for example) but not widely used because it's easier for everyone to grab a provider-independent (PI) chunk of address space and pollute the global Internet routing tables.

Without an extra layer between the IPv6 addresses and the applications, the multihoming of e-commerce servers in the IPv6 world remains identical to IPv4 multihoming, and providing resilience to smaller client sites actually gets harder because IPv6 does not have Network Address Translation (NAT).

Myth #3: IPv6 will reduce IP routing tables and BGP problems
Reality: Missed opportunity.

The architects of IPv6 envisioned a strictly hierarchical address space in which every service provider would get huge amounts of address space and advertise only a few prefixes into the global routing tables. Unfortunately, they've never considered the high-availability requirements of e-commerce

The Internet Engineering Task Force (IETF) had 15 years to address multihoming issues but failed to do so (see the previous myth). The only solution available to anyone who wants to be somewhat independent of a single service provider is to get a chunk of PI address space, run the border gateway protocol (BGP) and advertise the PI prefix to the global Internet. If anything, the routing tables will grow exponentially with the introduction of IPv6, as everyone will try to get PI address space.

BGP will fare even worse. Not only will the size of the IPv6 global routing table increase, IPv6 BGP tables use more space (and more bandwidth) than the corresponding IPv4 BGP tables. Last but not least, you should also consider what happens in the IPv6 transition period, when the routers will have to carry both IPv4 and IPv6 prefixes for the same set of end-user equipment.

Myth #4: IPv6 has better Quality of Service (QoS)
Reality: Obsolete.

IPv6 packet headers have a flow field designed to identify individual flows, which might be useful on low-speed links. On a decently fast link, you're forced to use class-based QoS (DiffServ) which uses DSCP field in the packet header, as the flow-based QoS (IntServ) does not scale. DSCP field is available in both IPv4 and IPv6 headers.

Myth #5: IPv6 has better security
Reality: Not true.

IPSec might be better integrated in IPv6 headers, but there's nothing you can do with IPv6 IPSec that you cannot do with IPv4 IPSec.

Myth #6: IPv6 is required for mobility
Reality: No longer true.

When IPv6 was designed, IPv4 did not provide any IP mobility features. The lack of IPv6 networking deployment has prompted the development of IPv4 mobility solutions. Today, it's not hard to implement IPv4-based mobility. It is true, however, that the explosive growth of mobile devices requires enormous amounts of address space that cannot be provided with the IPv4 addresses.

Myth #7: Residential IPv6 is less secure because it does not require NAT
Reality: Ignorance.

Some engineers think that the NAT commonly used in residential CPE devices provides extra security owing to obfuscation of actual IP addresses of the hosts behind the CPE device. Enterprise-grade NAT implementations (available, for example, in Cisco IOS) provide security somewhat equivalent to a stateful packet inspection, but consumer-grade NAT available in most CPE devices does not.

Scanning the IPv6 address space looking for vulnerable hosts (a common hacker pastime) is totally useless in the IPv6 networking world. Using the current best practices, each consumer will get the equivalent of a billion's worth of today's Internet's addresses. Even if your workstation sits behind an unprotected CPE, finding it from afar would be quite a feat.

Furthermore, every modern operating system contains basic firewall capabilities (for example, the ability to block unwanted incoming sessions) that to some degree augment the functionality provided by CPE devices.

Last but not least, if residential security becomes an issue, the market will force even the low-cost CPE vendors to implement some basic filters to protect the end users.