A hardship early-on in the development of Internet Protocol version 6 (IPv6) tools was the lack of IPv6 packets to use for testing. A simple PCAP-based Internet Protocol (IP) translator was built by the DREN IPv6 Pilot to convert a file containing IPv4 packets into a file containing IPv6 packets. There are now many synthetic packet test generators available, both open source and commercial. A list of some free packet generators is available here.

(NOTE: For tools to help test or troubleshoot Internet Protocol version 6 (IPv6) network behavior or network services (such as web, mail, DNS, DNSSEC, NTP, or XMPP), see the IPv6 Troubleshooting article in the Network Management section.)

Formal Network Testing

The Chief Information Officers (CIO) Council Federal IPv6 Task Force provided this Demonstration Plan for Federal agencies defining what was required to document compliance with the OMB IPv6 guidelines. 

Products from some of the commercial testing service and equipment providers and open source testing software developers mentioned at the end of the Testing section in the SDN Lessons Learned, Testing, and Training article in the SDN Knowledge Base can be used to conduct network testing and document their results.

Numerous sources providing Internet Protocol version 6 (IPv6) product standards conformance and interoperability testing results are listed below. Unfortunately, there is no single database or website that consolidates the various testing results.

The testing results are provided in 6 categories

1. 1. International,
   2. United States (US) Government,
   3. US Department of Defense (DoD),
   4. Commercial and open-source testing service providers,
   5. Original Equipment Manufacturer (OEM), and
   6. Other.

Some of the earlier organizations and initiatives conducting IPv6 product standards conformance and interoperability testing in a dual-stack environment (both IPv6 and IPv4 are supported) mentioned below are no longer active (and are noted as such). Testing results from these programs remain available. However, the value of such testing results diminishes over time, as the importance of supporting IPv6-only (without any support for IPv4) continues to grow, as the article The Need for IPv6-only Product Support points out.

1. International testing. Since 2003, information about hardware products and system software that have been tested against IPv6 Forum IPv6 Ready Logo Program requirements and placed on that program's Approved Lists may be found here. Information about the products tested in specific categories may be found on this website.

As early as 1991, the European Advanced Networking Test Center (EANTC) began testing network products for IPv4 standards conformance and interoperability. Since 2004, they have been testing IPv6 products as well (search for IPv6 to see the reports). In 2016 the Internet Protocol for Smart Objects (IPSO) Alliance updated its Application Framework to include IPv6 interoperability tests, which is still being maintained. In 2018 the IPSO Alliance and the Open Mobile Alliance (OMA) announced their merger to form OMA Specworks, which is still active. The IPSO Alliance Smart Objects Guidelines are still being maintained by the OMA Specworks. The OMA Specworks Work Program includes several Working Groups, including the Interoperability Working Group, (IOP WG), which continues developing and releasing interoperability test profiles.

Since 2013 the Broadband Forum has released a steady stream of IPv6-telated Test Plans and Technical Reports.

2. United States (US) Government testing. Information about the products that were tested against requirements specified in the National Institute for Standards and Technology (NIST) US Government standards for IPv6 (USGv6) 500-267 until 2020 and since then have been tested against requirements specified in NIST 500-267Br1 are placed on the USGv6 Accredited Test Labs Registry. The USGv6 is also referred to as the USG IPv6 Profile.

3. US Department of Defense (DoD) testing. DoD testing results for products that have been tested against the DoD Unified Capabilities Requirements (UCR 2013 Change 2) by the Joint Interoperability Test Command (JITC) and other Testing Centers of Excellence are placed on the DoD Information Network (DoDIN) Approved Product List (APL) and may be found here. (Caution: The website does not require a DoD Public Key Infrastructure (PKI) certificate for access, although it may ask for one. Click on Cancel if a certificate is requested.) Additional information about the DoD product certification process may be found here.

The JITC testing methodology until 2009 was described in this DoD IPv6 Generic Test Plan. That Generic Test Plan was superseded by a series of device-category specific test procedures. A Joint Interoperability Process Guide Version 2.0 is available. (Caution: Some web browsers may not connect to this website on their first attempt.)

For older testing results that are no longer on the current APL list, the manufacturer may be able to provide a copy, or the testing results may have been on an older APL developed by JITC and archived in 2009, prior to the incorporation of IPv6 conformance testing into the UCR. Under contract to the Navy, Applied Research Associates, Inc. also provided a 2009 report of their early findings.

Additional information about IPv6 product testing as part of the DoD UCR program may be found here.

4. Commercial and open-source testing service providers. The InterOperability Laboratory (IOL) at the University of New Hampshire (UNH) has created a wide variety of test suites and test specifications, many of which are IPv6 specific, and is conducting on-going IPv6 product testing. The test suites, test specifications, and product registries with testing results are available on the UNH IOL website. For example, the UNH IOL conducts an on-going IPv6 testing program for Home Networking equipment and maintains a Session Initiation Protocol version 6 (SIPv6) Interoperability Environment and pre-certification test suite.

Some of the providers and developers mentioned at the end of the Testing section of the SDN Lessons Learned, Training, and Testing article in the SDN Knowledge Base also perform IPv6-specific testing. Spirent Communications, Inc. is one such commercial testing service provider.

(Note: Commercial testing services and equipment providers typically do not make test results publicly available.)

5. Original Equipment Manufacturer (OEM) testing. In addition to results from the testing programs mentioned above, a few OEMs provide IPv6 testing results and other regulatory compliance information on their own websites. For instance: Cisco hardware, HPE Public Sector Solutions (scroll down to the Federal Certifications section of the web page), Juniper hardware and Red Hat, Inc. software.

Although ephemeral, OEMs often publicize testing results when individual products are approved by the IPv6 Ready Logo, NIST USGv6, or DoD UCR testing programs.

6. Other. If IPv6 conformance testing results for a product of interest cannot be determined using any of the above resources, some level of IPv6 conformance may be inferred (though not confirmed) if test results for earlier products in the same product line show that the manufacturer incorporated IPv6 support in those products, or the product manufacturer's corporate website:

(i) states that the product supports IPv6,
(ii) states that the product supports Software-Defined Networking (SDN) or associated software architectures, or
(iii) is itself IPv6-enabled. This can be determined using one of the IPv6 connectivity testing tools mentioned in the IPv6 Troubleshooting article in the Network Management section.

(NOTE: For tools to help troubleshoot Internet Protocol version 6 (IPv6) network behavior or network services (such as web, mail, DNS, DNSSEC, NTP, or XMPP), see the IPv6 Troubleshooting article in the Network Management section.)

 The IPv6 Test Techniques article is organized in 6 topics:

1. Introduction
2. IPv6 test lab set up
3. Interaction between item under test and test environment
4. Test plans, specifications, scenarios, and data packets
5. Test Network Setup
     5.1 Dual-stack test network setup
     5.2 IPv6-only test network setup
6. IPv6 application testing

1. Introduction

Whenever a change will be made to an existing product or application, testing that change in isolation before deploying it in the real world is a recommended practice. Guidance documents and how-to articles usually recommend setting up an IPv6 test lab or test network as one of the early steps in the process of deploying IPv6. For example: 

Setting up a testing capability is important for the safe, controlled introduction of new features, technology, and versions of control software into your network and prototyping with an emphasis on validation of targeted behavior and performance outcomes (e.g., experimenting with secure IPv6-enabled teleworking). Testing in a controlled environment enables the agency IT group to perform tests that could potentially be disruptive or introduce a security risk if deployed on the production network. The test environment should be set up as close as possible to resemble the production environments, including required network services such as DNS and DHCP. At first, the test sites should not be connected to the production network but be limited to a controlled environment until preliminary testing is complete. During the testing phase, the IT team will gain valuable experience with integrating IPv6, allowing them to determine whether the technology plan or schedule needs to be modified. Once preliminary limited testing is complete, the test environment can be interconnected to other IPv6 test networks.

Note: The above guidance is recommended by the Planning Guide/Roadmap Toward IPv6 Adoption within the US Government, July, 2012. (While the policies contained in that memorandum are no longer in effect [the memorandum was rescinded Aug, 2018 by Office of Management and Budget (OMB) Memorandum M-18-23 Shifting From Low-Value to High-Value Work], the guidance recommended by that memorandum remains valid.) A policy is a statement of specific actions that must be taken or goals that must be achieved while guidance is a statement of non-mandatory actions that could be taken or methods that could be used to achieve recommended goals.

2. IPv6 test lab set up

For Microsoft Windows environments, this Microsoft website, published in 2012 and updated several times since then, shows how to configure an IPv6 test lab using five (5) computers, along with extensions to that basic IPv6 test lab for DHCPv6, DNS Zone Transfers, IPv6-only networking and numerous others. It even suggests how a virtual IPv6 test lab can be set up using only one physical computer. The resulting IPv6 test lab has no external Internet access. An earlier document is also available: Step-by-Step Guide for Setting Up IPv6 in a Test Lab published in 2006.

Part6: Configuring IPv6 Routing through IPv4 in a Microsoft Windows Environment in the article Enabling IPv6 in Microsoft Windows Application Servers in the Infrastructure section provides additional information, including how to add IPv6 network access. 

This article offers various alternative approaches that can be used to set up an IPv6 test lab, either at home or at work, including some without computers. This older WindowsITPro article describes how to set up an IPv6 test lab using a computer, a router, and a tunnel broker to provide Internet access.

This paper (OPNET Modeler referenced by the paper has since been renamed Riverbed Modeler) and this more recent paper (VMWare licensing required) describe how to create an entirely virtual test environment. 

For Linux environments, this American Registry for Internet Numbers (ARIN) web page includes a Home Labs subsection that describes several ways to set up an IPv6 test lab. This article combines IPv6 theory with practical guidance for setting up an IPv6 test lab, as does this article, which includes more detailed explanations. Yet another article describes using Kernel-based Virtual Machine (KVM) to set up a virtual IPv6 test lab in part1 and part2.

More elaborate IPv6 test lab setups are described here (in a business environment) and here (in a military environment).

3. Interaction between item under test and test environment 

Guidance documents and how-to articles often skip over this aspect. In the course of modifying an item to make it IPv6-capable (whether hardware or software), the way IPv4 packets are processed may be changed. The following table shows eight ways that any item which has been modified to become IPv6-capable should be tested to verify that no new vulnerabilities or undesired behaviors have been introduced as a result. As Internet Engineering Task Force (IETF) Request for Comments (RFC) 6586 Experiences from an IPv6-Only Network makes clear, inadequate testing for test case 9 is presently the norm. 

Most commercial and open source operating system and web browser clients are now IPv6-enabled by default, so they need to be reconfigured to disable IPv6 before being tested.

Too often, only test cases 7 and 8 are used. To give just two examples of the importance of the other test cases, sometimes the modified networking hardware can crash in test case 6 or a large packet (containing IPv6 records that are larger because of their larger addresses) can cause a buffer overflow in a modified DNS resolver in test case 5.

4. Test plans, specifications, scenarios, and data packets

Sample test plans and procedures, specifications, and the scenarios they are part of may be found on the websites of six different categories of organizations:

(1) International,
(2) United States (US) Government,
(3) US Department of Defense (DoD),
(4) Commercial and open source testing service providers,
(5) Original Equipment Manufacturer (OEM), and
(6) Other

that conduct IPv6 standards conformance and interoperability testing are referenced in the IPv6 Product Testing Results article in the Testing section.

The standard IPv6 profiles approved for use by the US Government departments and agencies, US DoD, and European countries are discussed in the IPv6 Boiler Plate Acquisitions Language article in the Deployment section.

A network test plan used by the Malaysian Communications and Multimedia Commission is available in Appendix B of this document.

It is desirable to use real streams of IPv4 and IPv6 packets in test cases 2, 5, and 8 in the table above. One way to create such packet streams is with the Simple Packet Translator tool discussed by an article of the same name in the Testing section. Packet streams can also be generated by tools referenced in that article.

5. Test Network Setup

Guidelines, techniques, and recommendations for setting up test networks may be found in the following:

a. IPv6 test lab setup (see part 2 above),
b. The project management factors mentioned in the Before You Begin article in the IPv6 Deployment section,
c. IETF RFC 5180 IPv6 Benchmarking Methodology for Network Interconnect Devices, May 2008 (IPv6-specific guidelines for benchmarking),
d. IETF RFC 2544 Benchmarking Methodology for Network Interconnect Devices, Mar 1999, along with associated updates in RFCs 6201, 6815 and 9004,
e. Tips on configuring your network to use Google Public DNS, and
f. Lessons learned in transitioning from IPv4 to IPv6 at the United States Naval Academy.

Note: This article describes ways to "Avoid the Top 5 IPv6 Network Testing Troubles" when setting up or reconfiguring an IPv6 network. Additional tips and techniques for troubleshooting IPv6 networks is available in the IPv6 Troubleshooting article in the Network Management section.

5.1. Dual-stack test network setup

It is no longer the case that an organization needs to set up its own test network. See Available Internet Service Providers (ISPs) and Networks in the FAQ section for a list of Internet Service Providers (ISPs) offering dual-stack network services.

During the early stages of IPv6 deployment, a few organizations chose to set up dual-stack test networks to gain experience with IPv6 deployment. In Europe, the 6bone was established as an informal collaborative test bed through the efforts of the IETF in 1996. It ceased operation in 2006. In the United States, the Defense Research and Engineering Network (DREN) IPv6 pilot was established in July 2003 by the DoD High Performance Computing Modernization Program (HPCMP). It became a production network in 2007. In Australia, the VIC6 network was established in 2008 by the AI Group and IPv6Now. It became a production network in 2010.

This report from 2004 describes the setup of a network to test IPv6 Quality-of-Service performance for Aviation applications.

5.2. IPv6-only test network setup

IPv6-only networks are not yet currently commercially available in the United States although they might be closer than you think. However, any organization may set up a test network that supports only the IPv6 protocol, in order to gain experience with IPv6-only networking, for reasons described in RFC 6586 Experiences from an IPv6-only network.

Facebook, LinkedIn (Part1, Part2, and Part3), Cisco, Microsoft and other organizations have deployed IPv6-only test networks on their premises. References to their experiences are available in the Overview of Lessons Learned Deploying IPv6 article in the General Information section. The Trans-European Research and Education Networking Association (TERENA) extensively documented their experience while deploying an IPv6-only test network in their office.

6. IPv6 application testing

Whether developing a new dual-stack or IPv6-only application or updating an existing IPv4-only application to enable support for IPv6, testing for correct behavior is required. Testing techniques that can be used during the development of new and conversion of existing applications to support IPv6 are discussed in the Application Conversion Introduction and Application Conversion Tools articles in the Applications section.