A case in point is a recent editorial published by Network World columnist Johna Till Johnson. Entitled IPv6: Time's still not right. Johnson argues that IPv6 is not ready for prime time, but then uses most of the aforementioned Old Wives' Tales (OWTs) to justify that opinion. I have no quarrel with Johnson's title thesis, but there is no reason to put up with bad arguments. As 6-Day -- the day that you will deploy IPv6 in your network -- approaches, you'll encounter these arguments more often. Here's why they're wrong.

OWT 1. IPv6 packets require dramatically more bandwidth. Since IPv6 addresses are four times larger than IPv4 addresses -- 128 vs. 32 bits -- it stands to reason that IPv6 packets are larger, and thus will require more bandwidth to transport. While technically true, the actual increase in overall packet size is miniscule, and the overall effect on bandwidth requirements is less than zero. This OWT, however, usually pegs IPv6 overhead as unacceptably high -- Johnson says up to 250 percent! -- warning of dramatic transport cost increases. Do the math, though, and you see otherwise.

Due to improvements in packet layout, an IPv6 packet is only 20 bytes larger than an IPv4 packet, despite having 24 extra addressing bytes. In the worst-case scenario of a packet with a 64-byte payload, that amounts to a 24 percent packet size increase -- one-tenth Johnson's threatened 250 percent. But most packets on the Internet are not 64-byte payloads -- they're much larger than that. According to several CAIDA studies, the bulk of Internet traffic is carried in 500-byte or larger packets, in which IPv6's overhead is only a 1 to 5 percent hit. But wait, there's more. IPv6 improves overall transport efficiency by eliminating packet fragmenting in the network -- a major source of performance trouble today. This more than makes up for even a 5 percent increased packet size, resulting in a net positive performance increase -- and a less-than-zero increased bandwidth requirement. Put another way, IPv6 actually requires less bandwidth than IPv4.

OWT 2. IPv6 routing is an unsolved problem. There is a grain of truth in this OWT, but it's a transition issue, not a fundamental IPv6 flaw. Somehow we have to move from IPv4 to IPv6, and that transition network will be more complex than either IPv4 or IPv6 alone. The whole truth to the tale, though, is that IPv6 has transition mechanisms designed into it -- well-conceived, tested transition mechanisms. You can route IPv6 through tunnels in IPv4 networks and vice-versa, and IPv6 and IPv4 can coexist on the same LAN. Virtually all operating systems and network hardware now support IPv6, so you could transition to it today if you like. The existing Internet and private network infrastructure will efficiently carry IPv6 traffic without hardware upgrades for the most part.

This OWT also overlooks one huge benefit of IPv6: vastly simpler routing on the Internet backbone. Because IPv6 addresses are for the most part issued in a provider hierarchy, IPv6 BGP-4+ backbone routing tables will be one-fourth to one-tenth the size of today's tables. That will speed backbone performance and eliminate some of the security risks inherent in today's BGP-4 backbone. This enhancement also makes it very difficult to spoof IPv6 source addresses, one of the main reasons Denial of Service (DoS) attacks are so hard to track down today.

IPv6 routing is a non-issue: You simply enable the IPv6 versions of the routing protocols you're using now: RIPng, OSPF, and BGP-4+. Since IPv6 solves many thorny IPv4 routing issues with very little adaptation required on the part of network admins, it's a serious mischaracterization to label IPv6 as a routing-problem child.

OWT 3. IPv4 already has the valuable features of IPv6. In addition to solving the address space problem, IPv6 promises to bring new Quality-of-Service (QoS), encryption, and security benefits to the Internet. This OWT argues that IPv4 already has these features, in the form of Network Address Translation (NAT) and Virtual Private Networking (VPN).

The grain of truth here is that NAT did help stave off the need for IPv6 -- a good thing, too, since nobody was ready to move to IPv6 in the late 1900s, when NAT was conceived. But NAT ain't nothin' but a hound dog, to paraphrase a favorite OHCMS (Old Husband's Country Music Song). It's a hack that has cost us dearly in network trouble in exchange for rescuing us from IP address exhaustion. NAT makes end-to-end encryption between hosts very difficult -- something IPv6 provides for free -- and breaks many higher-layer protocols. I personally have spent hundreds of hours troubleshooting network problems ultimately traced to NAT failures.

NAT is a performance bottleneck as well. A common problem -- exploited by DoS attackers -- is exhaustion of NAT session tables by high traffic rates. And since all traffic passing through a NAT device must be deeply inspected and modified, the speed of your NAT box effectively limits the speed of your Internet connection.

Part 2 of this OWT is that VPNs give us all the encryption we need, so IPv6 is redundant. But today's VPNs implement either gateway-to-gateway or, at best, host-to-gateway tunnels. Yet many threats today are behind the corporate gateway -- viruses, Trojans, and spyware -- for which VPNs provide no protection. Today's VPNs also require dedicated hardware and software, which require expert configuration. When was the last time one of your end users set up their own VPN?

With IPv6 you get complete application-to-application encryption, which is better even than host-to-host protection. Every IPv6 implementation must support authentication and encryption at the session level, so you need no additional software or hardware to get the best possible data protection.

OWT 4. NAT enhances security, while IPv6 address visibility is a privacy threat. NAT's private IP addresses are hidden to the outside world, which is presumably an advantage since you want to give hackers as little information about your internal infrastructure as possible. Since IPv6 addresses are visible to the outside world, this seems like a threat to personal privacy -- someone could track your IPv6 IP address to monitor your network activities.

The truth is that NAT's security advantage is illusory. Your enterprise firewall is what actually provides protection from outside attack -- not security by obscuring IP addresses. Servers mapped to public IP addresses through NAT are already completely visible -- as is your behind-the-firewall routing infrastructure -- through the TCP Traceroute utility (which unlike ordinary traceroute, passes right through NAT server mappings). Individual users are masked, but IPv6 already addressed this problem in an improvement made in an Internet standard in RFC 3041, Privacy Extensions for Stateless Address Autoconfiguration in IPv6. End-user IPv6 addresses can be random, changing values, eliminating their value as tracking devices.

The Truth is Out There
There are legitimate hurdles for IPv6 to overcome, so there is no need to fabricate problems. For example, the cost of transitioning to IPv6 is unknown, and IPv6 requires updating of applications to support the larger IPv6 address. Worse, nobody has any idea how to motivate software developers and end users to migrate to IPv6, even though we know that a slow, controlled migration will be much better than a mad rush in the face of some catastrophic IPv4-borne catastrophe.

But there are bright people working on these problems -- the same bright people that already have overcome hundreds of similar difficulties in hammering out the very ingenious IPv6 protocol to begin with. More importantly, none of IPv6's detractors have a better solution. The best tradition of Internet invention has been this: If you have a better idea, go implement it and the Internet will make it a standard. IPv6 naysayers have no better ideas.