Today's IPv4 networking software and hardware has been proven over time - you know how they work and you have confidence in your network. You know how many routes a specific device can hold and you know your PE routers will handle a routing update, and how much data can be forwarded because the router is working today.
The quality of IPv6 software and features in vendor equipment is unproven and largely untested. While vendors are delivering IPv6 features to their products as new hardware or software updates, these features aren't necessarily perfect, reliable or performing properly. In this article, we consider the causes of poor IPv6 compatibility and how to address them by running a testing environment to detect problems, test vendor fixes and establish a validation process for network equipment.
You can simplify IPv6 product defects to just four primary causes:
- Some IPv6 standards are still changing and updating, which requires ongoing software updates to your network hardware.
- Some vendors started IPv6 development late and features aren't completed.
- Vendors don't always have strong testing and validation processes which results in buggy software.
- Existing network hardware doesn't fully support IPv6 because, for example, the TCAM Memory architectures are tuned to 32-bit addressing which affects IPv6 performance or scalability.
Some IPv6 standards are being updated or extended as feedback from the early deployments is gathered from the industry. This is normal and to be expected but also means that vendors' software and hardware requires regular testing and validation.
While a testing plan should be developed for your specific environment, consider the following elements as inspiration for your initial testing plan. First, a document from RIPE, "Requirements For IPv6 in ICT Equipment," provides a comprehensive resource to the IETF RFCs for IPv6 and makes a great reference for a test plan. Consider the following three core functional tests as examples:
IPv6 native forwarding performance, single and mixed mode with IPv4
Products such as the Cisco ACE 2.0 hardware supports more than 10Gb/s of IPv4 in hardware but IPv6 is software only and supports less than 100Mbps. This led to Cisco withdrawing IPv6 on the Cisco ACE2.0. This test is vital to validating the 'real life' deployment in a mixed mode network and determining where IPv6 scaling is a problem.
IPv6 over IPv4 tunnel performance
Many companies will tunnel IPv6 in GRE tunnels on their existing IPv4 backbones. When tunneling, the network device must perform the encapsulation of the payload in addition to forwarding the frame.
Some devices perform this in CPU and may not scale. Also, the IP packet needs a larger IP MTU to perform the encapsulation and fragmentation can impact system performance. This can change the traffic performance in WAN services and certain types of switching hardware where the Ethernet MTU must also be extended.
In this test, you are looking for packet loss, packet sequence errors, validating device features to support GRE and the performance when tunneling.
IPv6 Routing Protocol performance
This test focuses on validating the performance of routing protocols such as OSPF, IS-IS and BGP for size, convergence and stability and whether devices can handle route flaps reliably. The test platform will be able to emulate many routers and inject routes according to a schedule and measure the propagation of routes between devices.