IPv6 Testing – Let’s Get Real
by Bill Kine
Product Manager, Spirent Communications

RIPv6 is here to stay. Progressive vendors have already delivered operational IPv6 hardware and software. These implementations have been tested by several different organizations, including Federal agencies (Moonv6 and other similar endeavors), universities and independent test labs. In most cases, the products have successfully passed these tests. From these tests, we can confidently conclude that IPv6 packets can generally be created, forwarded and processed by several different equipment manufacturers.

It is now time to move to the next phase of IPv6 testing. The basic functionality has been verified in labs throughout the world. However, these tests have typically taken place in highly isolated and static environments with no other extraneous variables. Now is the time to introduce realism to IPv6 testing. In fact, the next phase of testing should also see how devices perform under adverse conditions and worst-case scenarios.

Real networks are constantly changing entities. Users often move, traffic patterns are unpredictable and failures consistently occur at the most inconvenient times and locations. This is the type of environment that must be emulated in the lab in order to determine how a device will function in the real world.

IPv6 Testing – Emulating the Real World in the Lab: The real world represents an extremely complex environment. For the purposes of IPv6 functional and performance testing, some assumptions can be made about the component parts of a real world network. These are listed below, along with their associated testing recommendations. Test engineers are encouraged to specifically select all of the criteria associated with their unique networking requirements.

1. Traffic Patterns: IPv4 will continue to exist for many years. Therefore IPv6 will begin as a small minority of the traffic on any given network. However, over time, this traffic will significantly increase, eventually overtaking the IPv4 traffic. Therefore, various mixes of IPv4 and IPv6 traffic should be tested. Data throughput, latency and packet loss should be measured for each version of IP and for all successive test iterations.
   
2. Multicast Traffic: Many production networks are experiencing increases in multicast applications for data casting, distance learning and video conferencing. Mixed unicast and multicast traffic should be measured over IPv4 and IPv6 network infrastructures.
   
3. Prefix Lengths: Data throughput, loss and latency should be measured for a variety of IPv4 and IPv6 prefix lengths.
   
4. Routing Protocols: IPv4 and IPv6 routing protocol performance should be fully tested. This includes the functional aspects (updates, route withdrawals, etc.) as well as convergence times. Unicast and multicast routing protocols should be tested concurrently. Also, data throughput, loss and latency should be measured during control plane updates.
   
5. Network Problems: Induce failures in your test bed. Simulate broken links, lost routes, device failures and invalid IPv4 and IPv6 packets. Measure the performance and recovery times (for both IPv4 and IPv6) associated with these problems. Stage a complex sequence of repeatable problems that can be run over a 48-hour period in order to validate the stability of the device under test.
   
6. Quality of Service: If video or voice traffic will be run over the network, the overall quality of service is critical. TOS and Differentiated Services values should be mixed for IPv4 and IPv6 traffic in order to validate the ability of a device to correctly categorize and prioritize traffic. Oversubscription should also be tested.
   
7. All of the Above: This is probably the most important category. The combination of all of the above testing scenarios will allow the user to ascertain the IPv4 and IPv6 functionality and performance of a particular device in a truly complex network environment.

The real world consists of very complex networks. However, lab tests often tend to occur in highly controlled and oversimplified situations. While this type of testing is sufficient for validating very specific operational characteristics, it ignores many of the variables that directly impact the overall performance and functionality of a network device. IPv6 is designed to operate in highly scalable, high performance, multiprotocol networks. Therefore, the next few rounds of IPv6 testing should emulate this kind of networking environment.