Commentary
August 11, 2005
IPv6 Old Wives' Tales
Any new technology has its detractors, and healthy skepticism is an important force keeping technologists honest about their prize cows. IPv6 is no different -- in its ten years of existence, critics have pointed out numerous potential problems. Much of this criticism has been constructive, resulting in improvements to the IPv6 standard. But now that the U.S. government has set 2008 as its deadline for internal IPv6 implementation, criticism of IPv6 is heating up. Some of this criticism is legitimate, but much of it is a set of oft-repeated Old Wives' Tales, which are either obsolete arguments addressed by IPv6 improvements, or just plain wrong thinking.
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.
Posted by Mel Beckman on August 11, 2005 at 9:36 AM | Comments (2)
June 17, 2005
On Tsunamis and Other Threats
At 6:50 p.m. on Tuesday, June 14th a magnitude 7.2 earthquake occured in the deep sea 90 miles off the coast of northern California. Shortly thereafter, the West Coast and Alaska Tsunami Warning Center issued a Tsunami warning to all residents of coastal California. An hour later, to everyone's relief, the warning was rescinded, as no Tsunami occurred.
Unfortunately, most people knew nothing of the warning until after it was canceled. That's a problem.
On that pleasant summer evening days ago, many people were away from their TVs and radios, and those that heard the few sirens that sounded were simply puzzled. A Tsunami, had one originated so close to the coast, would have innundated many areas witin the hour, before any significant reaction by residents. Despite the ubiquitous distribution of text-message-capable cell phones, there is no coordinated method for distributing a Tsunami warning to individuals in California. In fact, there isn't a way to notifify individuals anywhere in the U.S. of any natural disaster. There are only news media broadcasts and disaster sirens.
A better way to inform the public is through personal alerts delivered by cell phone. Alas, getting the government to instantiate a personal disaster warning system would be a massive undertaking. But there isn't any reason the public can't take matters into its own hands: A grass-roots warning system could be launched just like any other open-source project, and be up and running before the government finished the feasibility study on its own system.
As network administrators, we already have the requisite personal notification mechanisms in place. The network management systems we currently employ to montitor networks have the ability to send pages, make phone calls, and deliver faxes. These systems are battle-tested and generally reliable. They're an excellent way to deliver disaster alerts.
Personal disaster alerts need not reach every individual directly to be effective. If one person in a building gets an alert, he or she can readily notify others nearby, shortening reaction time to the impending disaster. A good model for such a system is the existing NOAA Specific Area Message Encoder (SAME) Emergency Alert System, a radio-based nationwide broadcast system that encodes textual disaster alert messages along with location information to trigger alarms on individual NOAA radio receivers. You can buy these receivers for under $50 and program them to alert you to disasters in your area. An example of such a device is the Midland 74-250C weather radio.
The first step in a personal disaster notification system is marrying NOAA's EAS with our existing NMSs. Once we can receive localized disaster information, we can disseminate it to selected individual cell phones, pagers, and fax machines in realtime. EAS supports two radio notification systems: One using terrestrial FM transmitters, and another using satellite broadcasts. The satellite system, called Emergency Managers Weather Information Network (EMWIN), supports direct-to-computer interfaces. An EMWIN earth station consists of an EMWIN reciever and a three-foot satellite dish antenna. Commercial EMWIN stations cost between $1,000 and $2,000. You can purchase EMWIN hardware and software from Skywalker, Skywatch, Tigertronics, and Zephyrus.
An alternative to an expensive direct radio interface is extracting alerts from NOAA's disaster Web site. Alas, NOAA does not seem to have a single Web point of contact for alert information. Each kind of alert -- earthquake, fire, Tsunami, severe weather, fire -- appears to have its own NOAA page. An experimental XML message service for Tsunamis is at http://wcatwc.arh.noaa.gov/message.shtml. We should lobby NOAA to deliver event messages through a single, well-defined XML-based Web Services interface.
If you know of an existing EMWIN NMS interface, or have ideas on how to construct one, post your ideas here. If enough interest develops, I'll create a Web site dedicated to the grass-roots disaster network concept.
Posted by Mel Beckman on June 17, 2005 at 10:11 AM | Comments (6)
