|
In-depth lab work shows support for this new version of IP is good, interoperability is excellent, but applications are weak. By Joel Snyder IPv6, the latest and greatest version of Internet protocol, has been in the pipeline for more than six years. However, serious questions remain as to whether the hardware, software and services are in place to launch IPv6 into the global Internet. The hands-on testing program for the biannual NetWorld+Interop 2000 trade show, called iLabs, will try to answer those questions this week in Atlanta. I'm on the IPv6 testing team, and this is a journal of our experiences looking at how vendors are integrating IPv6 into their hardware and software. Overall, our testing showed that IPv6 support was excellent in certain areas, such as infrastructure and basic operations. While router vendors are nowhere near ready for enterprise IPv6 networks, enough code is available to give network managers a feel for what it will be like to manage a mixed IPv4/IPv6 network. However, as you move up the stack, things get weaker and weaker, with applications still stuck in the demonstration stage. Late last month, our team assembled in a warehouse south of San Francisco airport to set up a "hotstage" for the IPv6 testing that will take place in Atlanta. This article is based on the testing completed during the "hotstage" process. Who's playing the IPv6 game? To find products, we sent team leader Craig Watkins of Transcend to the IPv6 Summit earlier this year to entice vendors to participate. On the infrastructure side of the house, Nortel Networks and 3Com have had IPv6 products on the market for some time and brought those to test. Nortel was running a slightly outdated version of BayRS, Version 14, running on an Access Stack Node, while 3Com gave us Version 11, its most recent version of the Pathbuilder 580 router. Cisco offered public beta-test code for its IPv6-enabled version of IOS, but we managed to get a slightly newer version (based on IOS Version 12.1) directly from the development team, which we loaded on Cisco 3640 and 7505 boxes. We could bridge IPv6 over a Layer 3 switch in the same way we could bridge Appletalk or Decnet, but that is not that interesting as it doesn 't demonstrate true IPv6 support in this gear. On the workstation and server sides, we spent a lot of time with Unix implementations, where the support for IPv6 is strongest. Nortel sent Mike Kadlec to help us, and he brought FreeBSD running the KAME IPv6 code. KAME is a cooperative research project, based in Japan, which is releasing production-quality IPv6 code. This software is being built into most of the freeware Unix kernels. ILabs team member Allen Gwinn, a senior director at Southern Methodist University, brought a Linux system running Red Hat Version 6.2, which has IPv6 built into the kernel. Sun 's IPv6 team came out with its systems. Solaris 8 is the only commercial operating system shipping with IPv6 support, so Sun sent its team of gurus to set up its products for us. Compaq was also an enthusiastic supporter, sending two Alphaserver systems, one running Tru64 Unix and one running OpenVMS, both with prerelease IPv6 software loaded. We showed Microsoft products in two ways. Microsoft engineers set up two systems running Windows 2000 and the Microsoft Research (MSR) IPv6 stack, which is only in the "technology preview" stage at this point. Our team also installed a Windows NT 4.0 system with MSR IPv6 code. For all other systems, we demonstrated LAN interoperability: boxes talking over the LAN to each other. We wanted to show how a network manager could connect to an island of IPv6 from a sea of IPv4. Freenet6, a project of Viagnie, offers a free, IPv6 tunnel over the Internet connecting anyone to the 6BONE, an experimental IPv6 backbone built on top of the IPv4 Internet. Our NT system was connected on the same LAN as everyone else, but was only talking IPv6 via its 6BONE connection. To get back to the iLabs ' LAN, it had to travel over the Internet to Viagnie's Freenet6 site, then over the 6BONE back to iLabs - definitely the long way around. Who didn't come? We were disappointed that the Japanese router vendors, NEC and Hitachi, which have both announced support for IPv6, were not able to participate. Most of the other commercial Unix vendors don 't have much of an IPv6 story. IBM and Santa Cruz Operation (now Caldera) ignored us, and Hewlett-Packard turned us down citing resource constraints. Apple, which had enthusiastically pushed its own IPv6 story earlier, was downright rude on its refusal to lend us the OS X software, and seems to have forgotten that they promised IPv6 support in the MacOS 9 release a few years ago. On the network gear side, the newest heavy-iron vendors were not ready to play: Foundry Networks, Fore, Extreme Networks, and Juniper Networks declined to come. Those companies which no longer see routing as a priority, such as Cabletron/Enterasys and Novell, also had no IPv6 story to tell. And how was interoperability? Interoperability was good - as far as it went. One of the basic tenets of IPv6 is stateless autoconfiguration: devices detect their LAN router and negotiate for an address. This eliminates the need for address management. The systems we tested did a great job at figuring out a unique address to use on the LAN without any configuration on our end. We used RIPng (the IPv6 version of Routing Internet Protocol Version 2) to distribute routing information around our test bed, and the systems could send and receive RIPng routing advertisements without any problems. We also imported RIPng from the 6BONE and saw it successfully propagate across the routers in the test bed. With routing in place, we tested connectivity with basic IPv6-enabled versions of ping and traceroute tools. We tested those on all platforms in the iLabs hotstage and validated that the products could ping6 and traceroute6 to everybody else. When our 6BONE tunnel was up and running, we also got out to the 6BONE and connected to several test sites using traceroute6 and ping6. In all, connectivity testing was an outstanding success. But simply moving packets back and forth on a LAN isn 't enough for real users. Getting off the LAN IPv6 is interesting in and of itself, but not particularly useful if you can't get out of your own LAN. While a variety of IPv6 and IPv4 interoperability tools and techniques exist, we were interested to find out whether any ISPs would be willing to carry IPv6 traffic natively. So far, IPv6 has largely existed as a series of tunnels built on top of the existing IPv4 network. While IPv4 isn 't going away anytime soon, the full power and flexibility of IPv6 requires that ISPs buy into supporting it natively soon. Qwest Communications is the official NetWorld+Interop ISP, so we began there. In early discussions with the engineering side of the house, Qwest was enthusiastic about IPv6 because it has a limited internal infrastructure to support IPv6. However, once the marketing side of Qwest heard about this project, things began to get fuzzy. "Qwest is not currently prepared to offer production-quality IPv6 service," we were told, "and this may send the wrong message to attendees." At press time, Qwest was still waffling on whether it would participate. We also tried RMI.NET, a similar ISP. But while Chief Technology Officer Ehud Gavron told us he was excited by the prospect of native IPv6 capacity, he could only offer a tunnel at this time, because RMI.NET won 't start rolling out native infrastructure until year-end. Because we couldn 't guarantee a native connection, we worked with 3Com to connect our island of IPv6 to the 6BONE, via 3Com 's existing 6BONE connection. What about applications? Obviously IPv6 won 't be useful until there are applications ready to use it. We saw raw infrastructure working pretty well, but higher-level applications are another matter. One of the most important "applications" that has to run on IPv6 before anyone can use it is the Domain Name System (DNS). DNS supports IPv6 in several ways. There are multiple formats for storing IPv6 addresses in the DNS, and one can query the DNS using IPv4 and IPv6 protocols. The dominant DNS server software is BIND (Berkeley Internet Name Domain), maintained by the Internet Software Consortium. Jan Trumbo of Opus One installed BIND Version 9 release candidate 5 in our test bed. BIND supports two kinds of IPv6 addresses: a simple format created to get IPv6 off the ground quickly, called AAAA (quad-A) format, and a more complex format for business deployments, called A6 format. BIND also handles "reverse" or "inverse" lookups with pointer (PTR) records, which translate names to addresses. We loaded A6 and AAAA records for our test bed into the BIND server, as well as the reverse/inverse PTR records. BIND was happy to serve these records. However, we didn 't have any evidence that applications were using anything other than the simplest AAAA format, or that they were querying the DNS over anything but IPv4. Because IPv4 and IPv6 will co-exist for a long time, application developers have chosen to use IPv4 to query the DNS rather than IPv6. Basic operating system-level applications worked well in our tests. For example, Compaq has ported over 40 utilities such as ping and traceroute, system management tools such as netstat and tcpdump, and server utilities such as inetd, the TCP/IP application dispatch daemon, to support IPv6 in its Tru64 Unix operating system. Finding other applications to run over IPv6 was not so simple. For time-sharing operating systems, such as the Unix variants and OpenVMS, it was simple to use their telnet6 and FTP6 clients and servers to test interoperability. Our experiences were good. However, the critical application in today 's networks is Web browsing and Web serving, because this represents the majority of Internet traffic and applications. Porting a Web client to IPv6 is not particularly easy, especially because the most popular Web clients have been tuned to give the best performance possible over the existing IPv4 infrastructure. Nevertheless, we used Internet Explorer Version 5 on NT and Windows 2000 as a Web client, and Netscape client software on the Unix platforms. These Web clients must have Web servers to connect to, but there are not a lot of IPv6 choices in this arena. Microsoft brought in an obscure server called "Fnord!" that they had ported to its Windows platforms, probably because it was easier than tacking IPv6 support on Internet Information Server. On the Unix side, we brought up Apache on FreeBSD, Linux, Tru64 Unix, and Solaris. Because this was just a small test bed, we didn 't try hard to stress out the servers. With Apache, though, we saw a variety of fairly sophisticated applications that showed the IPv6 path back to our client from the Web server. The most sophisticated application set we saw came from Sun 's Solaris team. Sun brought IPv4/IPv6 WWW servers and proxies, Simple Mail Transfer Protocol (SMTP), and Post Office Protocol (POP). As part of the interoperability testing, we used IPv4 and IPv6 protocols to send mail with SMTP, read mail with POP and browse the Web using a IPv4/IPv6 gateway. This demonstrated that a complete IPv6 island could talk to an IPv4 island as long as one system could sit on both networks and act as the gateway. ne application we tested is IP Security (IPSec). Because IPSec - which requires IPv6 for full standards compliance -- is defined in IPv6 terms and was then adapted to IPv4 environments, it 's a natural for IPv6. What IPv6 does not require is some way to set up IPSec security associations, which are normally done with a separate protocol called Internet Key Exchange (IKE). Only the KAME (FreeBSD) implementation of IPv6 claims to support IKE, so we did not delve into that application. Conclusions, caveats and resources One of the biggest problems with rolling out IPv6 into enterprise networks and the Internet is the lack of high-speed hardware to handle IPv6. As businesses have started to pull out hubs and switches, replacing them with Layer 3 switches, the assumption of Layer 3 (IP layer) routing down to the desktop is becoming commonplace. While hubs and switches don 't care, routers (either Layer 3 switches or traditional IP routers) do care about IPv4 vs. IPv6, and this investment is going to make it more difficult to introduce IPv6 into existing networks. The speed requirements for huge networks are not being matched by hardware-based IPv6 switching -- at least not yet. The same performance problem is true with infrastructure routers. Vendors such as Cisco and Nortel Networks have taken great pains to move IP packet switching as far away from a router 's main CPU as possible by building custom Application Specific Integrated Circuits and other support hardware. While IPv6 was designed to be easy and fast to implement in hardware and speeds will likely exceed those available for IPv4 once market momentum begins to roll, that hardware is not yet available. This means that very high-speed IPv6 switching and routing is not available today, even though 3Com and Nortel are providing production-quality IPv6 routers. Cisco, which has yet to deliver production IPv6 code, will be in a similar performance position when it releases its IPv6 product in November. When we first did this demonstration at NetWorld+Interop 2000 in Las Vegas, hundreds of attendees stopped by to see IPv6. But the greatest interest wasn 't in how IPv6 worked or how good interoperability was. Instead, the big question was "when?" In that sense, market-dominating vendors such as Cisco and Microsoft are really going to set the IPv6 timetable. Major ISPs won 't be able to introduce IPv6 until they can get high-speed production hardware to run their networks, and companies aren 't going to be interested in using IPv6 until they can get their common desktop clients connected with IPv6. While the Unix- and OpenVMS-based IPv6 implementations are critical for the server side of the equation, enterprise managers typically only have a small number of Web servers - but thousands of clients to worry about, which means that real IPv6 support hinges on how soon it is supported down to the Windows desktop. IPv6 will become fully available during the next 12 months in three directions. The innovative ISPs will start to roll out IPv6 services on an experimental basis -- they know they 'll have to run it sooner or later, and they might as well start getting experience. At the same time, the mobile and wireless community is a big proponent of IPv6, largely because they anticipate needing a billion IP addresses for the mobile devices out there within the next decade. Their networks will likely become IPv6 islands, with gateways to the Internet, as they roll out next-generation wireless services. |