Section 10.6. Case Studies
10.6. Case StudiesHere are some case studies that may be of interest to you. The first is an example of an ISP that has quite a few years of operational experience with IPv6 and was willing to share this information with us. Next, we have the description of two universities that have deployed IPv6, and I describe them both because they each have a completely different approach. The last case study is about my ISP in Zurich and how it offers its services over IPv6. Talking to all these people shows that a step-by-step introduction is much easier and less costly than one would anticipate. These people were kind enough to provide the information about their deployments and share their findings and experiences with us. The examples show that IPv6 is ready to be used and may give you some ideas on how to proceed with the plans and strategy for your network. I tried to find different types of deployments, and I hope that the variety of these examples inspires you to find a good and creative deployment path for your network and to enjoy getting there. 10.6.1. NTT CommunicationsAn ISP Case StudyThis case study focuses on NTT Communications's Internet access services. (Some of the companies that are part of the NTT Communications Group were or are known by the name Verio Inc. or other names; in this section, they are all included and referred to by the name NTT Communications.) The company also offers IPv6 web hosting and other services. NTT Communications has a long history with IPv6 that began in 1996 when NTT Labs started one of the world's largest IPv6 research networks in Japan, and just one year later, NTT Communications affiliates started operating major nodes of the 6bone. The ISP made a decision early in the IPv6 growth curve to be a leader in this industry, and in the late 1990s made a decision to productize IPv6 services as soon as practical. A policy was implemented that equipment procurement decisions needed to account for IPv6 support as far back as 1997, and by 1999, NTT Communications was pushing hard for advanced IPv6 support from major router vendors. In the meantime, the company was supporting IPv6 peering and participating in every major global IPv6 exchange. In 1999 and 2000, NTT Communications was allocated sTLAs from the APNIC and ARIN respectively. The ISP's comment regarding this early commitment to IPv6:
NTT Communications decided to roll out IPv6 services to its customers in three phases: a precommercial phase, a commercial phase, and follow-up releases to fill functionality gaps. This phased approach allowed for NTT Communications's IP routing infrastructure to be gradually upgraded while taking on a limited, manageable number of customers. In the meantime, internal tools were enhanced, and testing in the 6bone and in internal private labs continued. The entire process was treated as a product development processtreating IPv6 not just as a technology, but as a technology that needed to be packaged in a manner that could meet the needs of customers who desire to be on the leading edge of IPv6 deployment. No elaborate business case was developed, and NTT Communications realized that IPv6 alone would not open revenue floodgates. But a business decision to commit to providing IPv6 Internet access products was based on the premise that IPv6 could be used as a differentiator to land new customers in an ever-competitive ISP market, and to gain access to new market verticals. The first phase of IPv6 deployment, launched in June of 2003 and called "IPv6 Pre-commercial Services" was relatively modest for a large ISP. Three Cisco 7206 routers running dual-stack IPv4/v6 were deployed in Los Angeles, San Jose, and the Washington, D.C. area. The majority of the NTT Communications backbone remained IPv4-based, with tunnels over the backbone between these three locations and the various IPv6 peering points. Only a handful of customers were brought on during this phase. Customers in any of these three geographic areas could receive native or dual-stack service, while customers in other locations in the United States could get IPv6 access via tunneling (RFC 2893, manually configured tunnels) to one of the three 7206 routers. The precommercial phase allowed engineers to continue testing Cisco's IOS and Juniper Networks's JunOS, and allowed time for the entire global NTT Communications backbone to be upgraded. It also allowed for provisioning and support procedures to be tested and for Network Operation Center (NOC) personnel and other support staff to be trained. In addition to making the routing network IPv6 capable, there were a number of other pieces to consider before launching a commercial product. Customer expectations are set high when they pay for a commercial service. And from the ISP's standpoint, to make money on a product, it must be able to scale and must be supportable. Therefore, a number of other tools and systems also needed to be in place. Router configuration tools needed to be upgraded to support IPv6 as well as NTT Communications's route registry and internal address allocation database. DNS resolvers and servers needed to be upgraded to not only serve IPv6 record types, but also serve these records via either IPv4 or IPv6 transport. The customer portal needed to be upgraded to display IPv6 usage data, albeit over an IPv4 transport. NOC operational and troubleshooting tools were upgraded to accommodate a dual-stack network. Finally, the SNMP infrastructure and SLA monitoring systems were upgraded to support IPv6. The transmission of data for these systems at times still used IPv4, but they had to at least be capable of monitoring IPv6 network elements. The ISP's comment regarding these expenditures:
By the end of 2003, the main support systems were in place and the entire global NTT Communications backbone (Asia, Australia, Europe, and North America) had been upgraded to run dual stack. The AS2914 core was upgraded first, followed shortly thereafter by the aggregation routing infrastructure. In December 2003, NTT Communications launched commercial IPv6 Internet access in the United States, albeit with some functionality limitations when compared to its IPv4 product suite. Outside of the United States, commercial IPv6 service had already been launched in most other NTT Communications regions. Three types of IPv6 access were supported:
The most popular service type was dual stack. Customers were routed both IPv4 and IPv6 address space (usually a /48) and could send either type of packet over their connectionT1, DS3, Ethernet, or whatever type of loop circuit the customer purchased. Since the NTT Communication aggregation and core routing infrastructure is completely dual stack, the aggregation router will accept all packets and will route them accordingly based on either the IPv4 or IPv6 routing tables. This method is very simple and flexible. The native IPv6 access option (only routed IPv6 address space, not IPv4) has been primarily used by organizations that wanted to keep a separate and isolated IPv6 environmentusually for testing or lab purposes. The tunneling option is still available but seldom used since the native and dual stack services offer superior performance. Figure 10-15 shows NTT's peering points. Figure 10-15. NTT Communications's IPv6 network map highlighting IPv6 peering points At the time of the commercial launch, a few gaps still remained between NTT Communications's IPv4 and IPv6 services. This was partly due to internal development time constraints and partly due to vendor feature support. Follow-up releases have allowed NTT Communications to fill these feature gaps. These releases have added IPv6 support for enhanced IP services such as shadow circuit support, managed router services (where NTT Communications manages the customer's IPv6 or dual-stack CPE), and off-net tunneling. The latter allows customers of a third-party ISP to connect to the NTT Communications Global IP Network via a tunnel (either an RFC 2893 manually configured tunnel or GRE). This has been a popular feature since it allows customers of ISPs that do not support IPv6 to access the IPv6 Internet, and it is relatively inexpensive. NTT Communications was the first global ISP to support commercial IPv6 Internet access services. Due to proper planning and foresight, the process was relatively painless and inexpensive. No capital budget was ever specifically allocated for the project of rolling out dual-stack IPv6 to its IP network. Changes to support IPv6 were carried out through normal upgrade cycles over the course of a couple of years. Some capital was eventually spent for Cisco 6509 sup720 card upgrades and router memory, but this was a relatively small amount. Like any product development process, there were expenses for employee training, code development to enhance internal tools to support IPv6, and testing. This phased approach allowed NTT Communications to launch IPv6 services while still solidifying internal process and tools as it bought time to continue testing on features that needed to be developed and allowed vendors to add features. Follow-up releases that could support a greater number of customers on a more flexible set of IPv6 access options were then launched. NTT Communications's IPv6 services have been very successful. In 2005 they report more than 500 IPv6 customers globally. The IPv6 product offerings have strengthened the company's position in some market segments, such as educational institutions, and have opened the door to new verticals such as high tech manufacturing companies and the wireless industry. Cody Christman, Director of Product Engineering at NTT Communications confirms:
There is an informational RFC (RFC 4241), "A Model of IPv6/IPv4 Dual Stack Internet Access Service," that contains a digest of the user network interface specification of NTT Communications's dual-stack ADSL access service, which provides IPv6/IPv4 dual-stack services to home users. The RFC focuses on an architecture for IPv6/IPv4 dual-stack access service and an automatic configuration function for IPv6-specific parameters, such as the prefix assigned to the user and the addresses of IPv6 DNS servers. It specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. 10.6.2. University of PortoThe Faculty of Engineering at the University of Porto (Portugal) has deployed IPv6. The following sections provide a description of the deployment. The project was split into four main areas, which are described next. 10.6.2.1. Access/perimeter technologyIn the beginning, when there was no IPv6 connectivity available, IPv6 tunneling was used. Very early, the university received connectivity and a /56 prefix, which was divided into /64 prefixes distributed evenly throughout the campus, providing the necessary granularity. To give IPv6-only users connectivity to the IPv4 world, they chose to implement Network Address TranslationPort Translation (NAT-PT). The main reason for their choice was that it does not "snoop" the data payload, making it application-unaware and perfect for a heterogeneous environment such as theirs. NAT-PT does not require any modifications or extra software to be installed on any of the end user hosts of either the IPv4 or IPv6 networks. It provides the required interoperability functions within the core network, making the interoperability between hosts easier to manage and faster to deploy. The only work required is to install NAT-PT at the network boundary. Maintenance is also eased, as any alteration to NAT-PT only needs to be downstreamed to the boundary routers, not to every host that requires connectivity across an IPv6/IPv4 boundary. The two issues with NAT-PT are scalability compared with other methods and the performance hit that it has on the network equipment that implements this mechanism. Because NAT-PT is not application-aware and because it works as a level 3 translation mechanism, there is a need to implement an Application Level Gateway (ALG) for specific protocols. These application-specific agents allow an IPv6 node to communicate with an IPv4 node and vice versa. The ALG works seamlessly and in conjunction with NAT-PT to support many mainstream applications, such as DNS-ALG, FTP-ALG, HTTP-ALG, etc. 10.6.2.2. Core and vertical distributionThe internal network consists of 80 level 2 vertical distribution switches of type Nortel Networks Baystack 450/470 and 18 core router switches of type Nortel Networks Passport 8600. They had issues with distributing the IPv6 network prefixes and the IPv6 routing initially when they tried using beta versions on the core router switches. This created too much of a performance hit on the switch-fabric processors and had a very limited level of features. So they decided to use an ISP router type, a Cisco 7609 OSR, to do the level 3 IPv6 Routing based on the level 2 VLANs. The Cisco router announces the IPv6 prefixes according to the VLAN from where the end user is located. For this mechanism, they use Router ADVertisement Daemon (RADVD), and the IPv6 addresses are created using Stateless Autoconfiguration based on the end user's MAC address. The level 2 vertical distribution switches were implemented dual stack with a simple mechanism using protocol-based VLANs. The fact that protocol-based VLANs have a higher priority than any port-based VLANs fit perfectly, so the IPv6-based VLAN has priority over the IPv4 port-based VLAN. This was the perfect recipe for transparency with the end users. Whenever an end user activates the IPv6 protocol, he automatically gets access to his respective VLAN. To configure the clients for their default gateway and DNS servers, operating system-specific scripts are used that automatically configure these parameters according to the Prefix/VLAN. 10.6.2.3. Network servicesAny network infrastructure wouldn't be complete without the services to complement the connectivity. The first and foremost service that had to be set up was a DNS Server to provide name resolution for IPv6 and IPv4 queries. After thorough testing, this service was implemented on existing internal and external DNS servers that have a separate network card for IPv6 queries only. These services were implemented using BIND 9 for Linux, providing the end user with the capability to register their workstations on both IPv4 and IPv6 DNS servers. The next step was to introduce more mainstream services, such as HTTP (http://ipv6.fe.up.pt), FTP (ftp://ftp.fe.up.pt), and NTP. The university's main web site, FEUP (http://www.fe.up.pt/), was a bit trickier to implement because Oracle does not yet support Apache v2.0, which is needed for IPv6 support. A dual-stack proxy was then introduced to provide the IPv6-to-IPv4 connectivity for the IPv4 web server. In addition, an IPv6 support page was created to introduce end users to the IPv6 technology and explain how to configure and use IPv6 inside the campus (http://ipv6.fe.up.pt). The official FTP server also has a separate network card for native IPv6 communication. This machine mirrors various Linux and software distributions and, in most cases, communicates with IPv6 sites. This has been very helpful in convincing the users to use IPv6, since the university has physically distinct links to the Internet (100MBit/s for IPv4 and 100MBit/s for IPv6) and the IPv6 usage is low and therefore very fast. The diagram in Figure 10-16 represents the IPv6 servers and core equipment that connects the university to the IPv6 world. Figure 10-16. IPv6 servers and IPv6 Internet connection 10.6.2.4. SecurityFor security, a Nokia IP 650 Firewall running IPSO v3.8 and a Checkpoint Next Generation Application Intelligence R55 are used. The firewall is a pure IPv6 firewall with only IPv6 policies and logs. Checkpoint is a well-integrated security solution for defeating and preventing both network- and application-level attacks in IPv6. This implementation was overseen directly with the help of Checkpoint. The big advantage in the adoption of Checkpoint for their border gateway security is the comprehensive interface that already exists in IPv4 security gateways. 10.6.2.5. Cost of introductionThe university states the initial cost to be pretty low. In terms of switching, all equipment was configured only for layer 2 switching. The Cisco router was expensive, but usually the backbone upgrade can be done with the next due upgrade, thereby not creating any extra cost. For testing purposes in the lab setup, a Cisco 2600 or a Free BSD server was sufficient. There were some investments in servers and secondary network interface cards for existing servers. But all in all, this wasn't an expensive project. As for human resources, there were two people (one on a part-time basis and one on a full-time basis) working on this project for about one year, between R&D (Research and Development) and deployment of the entire IPv6 network. 10.6.2.6. ConclusionsThe university's conclusion is that the overall result was very good with a high satisfaction rate. They see the project as a very interesting experience with some peculiar and proactive measures to overcome various problems that had to be solved by the network administrators. This is currently and will continue to be an ongoing project, as maintenance and extension of a network always is. They believe that it will still take some time for manufacturers to ultimately implement IPv6 with the same quality and characteristics that are used today in IPv4, and that until companies such as Microsoft deploy IPv6 on their desktop operating systems fully, IPv6 won't take off like it should. They think that Windows Server 2003 is in fact a big step forward in terms of IPv6 features. They found that both MAC OS X and Linux support IPv6 out of the box, and network layers are implemented as they are defined in RFCs. In terms of applications, most of them have limited functionalities compared to native IPv4 mainstream applications. I had an interesting conversation with Paulo Vieira from the university, and his final statement was:
10.6.3. University of StrasbourgOsiris is the name of the Metropolitan Area Network (MAN) for the education and research community in Strasbourg (France). Osiris connects 17 institutions (universities, research institutes, engineering schools, etc.) that represent about 110 buildings, all connected at 1 Gb/s via private fiber optics to the Osiris backbone. The total number of users is 50,000. Osiris is managed by a network operation center called Centre Réseau Communication (CRC), part of University Louis Pasteur (ULP), which is one of the 17 institutions. The decision to migrate Osiris to IPv6 was made in 2002. The renewal of the backbone equipment in 2003 offered the opportunity to invest in IPv6-capable routers. Quality of IPv6 support was then one of the main criteria for the choice of Juniper M20 routers. IPv6 connectivity in parallel to IPv4 connectivity was offered from the beginning. The routing protocol was changed from OSPFv2 to IS-IS because IS-IS can be used for both IPv4 and IPv6 routing. Since all routing is done in the dual-stack backbone, IPv6 support in the core routers allows IPv6 traffic to be brought in all subnetworks without effort for either the CRC or the local network engineers. However, IPv6 connectivity was configured in subnetworks only after the local network engineers had been properly educated about the new protocol. A one-day course about "IPv6 Principles and Client Configuration" was designed, and at the time of writing, 53 engineers have taken this course. During the deployment of new routers, the following network services have also been configured or migrated to support IPv6:
All servers are running FreeBSD. The new Wifi access network (approximately 100 access points at the time of writing, expected to grow to 250 access points by the end of 2005), which requires an authentication with either the 802.1X protocol or a captive portal, now fully supports IPv6. On the client side, IPv6 Stateless autoconfiguration is used as much as possible. Manually configured addresses are assigned only on "public" servers whose addresses should not be changed. If you are interested in how the university designed their IPv6 addressing scheme, you can find the documentation at http://www-crc.u-strasbg.fr/osiris/ipv6/plan-adressage.html. You may need to know a few words of French, but the main structure can be understood without understanding the language. One particular subnetwork is the one where the CRC workstations for the engineers' day-to-day use are located. All these workstations are dual-stacked, being a mix of FreeBSD, Linux (gentoo, debian), and Windows XP. Connectivity to the Internet is offered by Renater, the French National Research and Education Network (NREN) via two 2.5 Gb/s links. Renater supports native IPv6 connectivity. Thus, no complex tunnel settings are necessary. Now the migration to IPv6 is complete for the core backbone and services. At the time of writing, 29 local sub-networks have been (partially or fully) migrated to IPv6, and around 500 different hosts on Osiris are regularly using IPv6. The university made the choice for migration to IPv6 for various strategic reasons:
Retrospectively, the migration was made possible by the enthusiasm of a small group of people and by the opportunity to renew the backbone routers. They have had the chance to be among the first to migrate on such a large scale, but they think that it would have occurred sooner or later anyway. When asked about the cost of introduction, they say that there were no identifiable extra migration costs. The routers had to be upgraded or renewed anyway, so the key element to IPv6 connectivity has been brought without cost. The engineering cost could be the largest one after the routers, but they consider this cost to be a strategic investment towards a high-quality operated network, where ROI cannot be computed by formulae. The overall summary of Pierre David, who kindly provided all this information, was:
10.6.4. This Book Has Been Reviewed over IPv6Sometimes things just happen. While we think about the pitfalls of introducing IPv6, IPv6 is already used in many cases, many of which we may not even be aware. One example is the editing process of this bookwe can say it has been reviewed over IPv6. David Malone from Ireland has been reviewing it. When working on the first couple chapters, I sent David an email with questions regarding his comments. Here's the email header: Received: from [IPv6:2001:8a8:20:1:202:b3ff:fe8d:c678] ([IPv6:2001:8a8:20:1:202:b3ff:fe8d:c678] helo=dachs.cyberlink.ch) by salmon.maths.tcd.ie with SMTP id <aa64060@salmon>; 31 May 2005 21:34:32 +0100 (BST) I must admit that in my office I use an IPv4-based email client, even though I have IPv6 connectivity to the outside world through a Tunnel Broker. This way, I learned that my ISP Cyberlink (http://www.cyberlink.ch) not only hosts my web site on a dual-stack web server, but also my email can go out over IPv6. So I asked whether they would share their setup and experience with us. I was their first customer requesting IPv6 web hosting back in 2001 when I was working on the first edition of this book. At that time, they already had a 6bone tunnel to their private playgrounds, so they had already made their first steps and gathered some experience with IPv6. Their inventory of software and systems that needed to be IPv6-ready showed that this was true for the Cisco router, the web hosting server (Debian Linux 2.4), and the web server software (Apache). From that point on, whenever they upgraded a Cisco router in their network (they run a network with over 30 SDSL POPs and three housing locations), they upgraded flash memory and installed an IPv6-enabled IOS image whenever possible. The Linux Kernel was already IPv6-ready when they needed it. Not so with the Apache 1.3 web server software they used for web hosting. Unfortunately, it was not possible to upgrade to Apache 2.0 because of module incompatibilities between Apache 1.3 and Apache 2.0. Only newer PHP versions (higher than 4) were running on Apache 2, and they still had customers running applications on PHP Version 3.0. So Apache 2.0 was set up in parallel to Version 1.3. With email and DNS over IPv6, cyberlink.ch was one of the first domains to have an IPv6-reachable nameserver registered. The mail server is based on qmail (http://www.qmail.org) for SMTP, vpopmail (http://www.inter7.com) for POP, and courier-imap for IMAP (http://www.courier-mta.org/imap). Qmail installations use the tcpserver program to accept connections and forward the streams to the MTA, POP, or IMAP server, so to enable IPv6, it is sufficient to have an IPv6-capable tcpserver. To send email over IPv6, the basic qmail installation needs to be patched with qmail-send, another component of qmail. Today, Cyberlink's LAN is fully dual stack, and they offer most of their services over IPv6, such as ADSL connectivity, SDSL on most of their POPs, Housing/Rack space with IPv6 upstream, and Web-/Mail-Hosting. One of the problems they encountered is a lack of low-cost IPv6-enabled CPEs. They have learned that one needs to be persistent and keep asking software, hardware, or upstream suppliers again and again to provide support for IPv6. They found that the network layer is ready for IPv6, and many applications are ready to be used over IPv6. Most problems they encountered were related to the IPv6 address format. Additionally, log parsers and management frontends for various software still ignore IPv6. Their plans for the future include providing a 6to4 gateway as soon as customers request such services. When asked for their motivation to offer IPv6 services and a summary of their experience, Ueli Heuer from Cyberlink says:
10.6.5. Moonv6The Largest IPv6 Test NetworkMoonv6 is not a case study of a real-world deployment. But I have referred to it many times throughout this book, and it is one of the largest test beds with a broad participation of vendors. So I think it is appropriate to offer a more detailed description of the project. Moonv6 is a collaboration between the New Hampshire InterOperability Laboratory (UNH-IOL), the U.S. Department of Defense (DoD), the North American IPv6 Task Force (NAv6TF), and Internet2. Moonv6 has established the most diverse and largest native IPv6 network in the world. It was created to advance the interoperability and deployment of the IPv6 protocol and to promote it throughout the industry. It is a platform for service providers, vendors, and equipment providers to work together in the design and testing of operative end-to-end solutions to address large pieces of the interoperability challenge. Moonv6 is an ongoing project and has so far gone through three main testing phases. Detailed information is available on the Moonv6 web site. This section includes a short summary taken from the information provided on the Moonv6 web site. 10.6.5.1. Phase IPhase I took place in October 2003 and demonstrated that current IPv6 networking technology is stable, resilient, and ready for integration with today's Internet. More than 30 organizations pooled their products, technologies, and engineering resources in an industry showcase that confirmed the following:
Tests were conducted at nine locations across the United States. Common network applications were tested running natively over an IPv6 network connection. The applications used peer-to-peer or client-server models for communication and included HTTP and HTTPS, FTP and TFTP, Telnet and SSH, DNS, and DHCP. The compliance to the IPv6 base specification was tested. This included the verification of ICMPv6 Echo Request, Reply and Redirect, ICMP "hop limit exceeded," Neighbor Unreachability Detection, Path MTU Detection and Fragmentation/Reassembly, TCP/UDP interoperability, Address Autoconfiguration, Duplicate Address Detection, Multiple Prefixes, and Network Renumbering. As for routing protocols, only OSPF and BGP-4 were investigated during phase 1. Most of the testing took place in networks where IPv4 and IPv6 were running simultaneously and included scenarios where OSPFv2 was used for IPv4 and OSPFv3 was used for IPv6 at the same time. No interference between the two processes was observed. The testing included a verification of basic functionality and more advanced rerouting scenarios. Overall, the tests had a good rate of success; some minor issues were noted. Phase 1 also tested and proved several key areas of mobility. Basic Mobile Node to Correspondent Node and Mobile Node to Mobile Node communication tests worked without any issues. Various scenarios of Home Network Renumbering and Dynamic Home Agent Address Discovery were successfully tested. In the Security area, IPSec was proven to work with ICMP and TCP in the host-to-host scenarios. The most significant issues emerged in the user-unfriendliness of the key exchange. In the area of Transition scenarios, static tunnels, 6to4, ISATAP, Tunnel Broker, and Tunnel Setup Protocol were verified. 10.6.5.2. Phase IIPhase II ran from February to April 2004. It completed the initial testing by successfully demonstrating high-speed links, advanced routing functionality, firewalls, QoS, and other key features of IPv6. Phase II demonstrated that current IPv6 networking technology is stable and resilient in some of the scenarios tested, but more testing is necessary before it is ready for integration with today's Internet. More than two dozen vendors participated in the tests. The following technologies were tested: QoS forwarding, basic firewall functionality, transition techniques, Mobile IPv6, DNS, and IPv4/IPv6 routing protocols (such as OSPF, BGP, IS-IS) and applications (such as email and PKI). Testing results showed that while most applications run in a dual-stacked or tunneled environment, few applications support native IPv6 environments. Some interesting tests in phase II included operation of media players and web-enabled video cameras over native IPv6 networks. Several commercially available media conferencing applications were successfully tested. They turned PDAs equipped with a mini camera into mobile videophone devices. These applications were also tested to demonstrate IPv6 connectivity over IPv4 wireless networks. IPv6 prefix delegation was tested using a laptop as a mobile wireless router and an IPv6 camera as a remote device. The camera successfully autoconfigured itself and was reachable through the laptop. The camera remained available with short disruptions as the laptop was moving from one IPv4 network to another. 10.6.5.3. Phase IIIThe phase III test set, which ran in October and November 2004, used the same basic concept as earlier phases of testing. Applications such as VoIP and multicast streaming over the backbone were tested. More extensive testing of DNS and DHCPv6 was performed. There were some issues revealed in some implementations with DNS zone transfers and support for authentication. Testing also demonstrated that some popular clients cannot communicate with DNS servers in a native IPv6 network. Successful advanced DNS testing included ENUM-related queries and GSS-TSIG updates. The testing of Stateless DHCPv6 clients and server implementations generated positive results. Stateful DHCPv6 tests were not as successful due to a lack of server implementations with comprehensive support for Stateful DHCPv6. Note that these tests were performed in late 2004, so by the time this book is printed, the market situation will probably have changed quite a bit. Routing protocols and firewall functionality were tested extensively during phase III. Internet SCSI (iSCSI; see RFC 3720), a protocol that encapsulates SCSI commands and data for transport over a standard TCP/IP network to address a remote SCSI device as though it were attached via a local SCSI bus, was demonstrated to operate over native IPv6, even though the implementations tested were in alpha state. Further testing will be performed with products from a greater number of vendors. The largest hurdles to IPv6 deployment and adoption that Moonv6 has identified have been either specific device implementation or user configuration issues. If you are interested in more details as to what was tested and more specific information about the testing results, please refer to the Moonv6 web site (http://www.moonv6.com). If you click on the Project button, you find detailed descriptions of the test phases, the items tested, and the white papers with descriptions of the results. When you get there, you may find more updated and recent test results than the ones described here. IPv6 is an evolving world. The NAv6TF's vision for Moonv6 is to create a virtual Internet backbone with the ability to do preproduction IPv6 testing for security, multimedia, roaming devices, and other services as vendors and system integrators begin leveraging the innovative opportunities inherent in IPv6. It also offers participants who wish to test IPv6-capable technology the following opportunities:
|
