AUGUST 20, 2010

Why Rethink Dual Stack IPv4/IPv6 Testing?

With IPv4 address space shrinking by the second and the exploding growth of the number of mobile computing devices, IPv6 has already been adopted and deployed by government agencies, service providers and enterprises. IPv6 device advancements, from personal computers and application servers, to networking products including routers, switches, and security devices, have also increased the roll-out of IPv6 based networks and services.

In order to meet the high expectation of the IPv6 network and service quality, and deal with the reality of dual stack IPv4/IPv6 traffic, organizations are looking for an efficient, realistic and scalable tool to measure the impact of dual stack traffic. Their ability to measure the performance, security and stability of any network handling IPv4/IPv6 traffic will directly determine if the launch of any IPv6 based network and service is successful.

Measuring Dual Stack Means Simulating Realistic Dual Stack Traffic

As you have read here lately, BreakingPoint has taken on the challenges of IPv6 in our webcast and methodology. Both of these are great resources and I would encourage everyone to download the IPv6 Resiliency Methodology. But I wanted to spend the time we have in this post giving you a quick demonstration of how to easily and efficiently to set up a quick dual-stack IPv4/IPv6 test to measure against an IPv6 capable networking element and/or infrastructure.

Figure 1 below illustrates the setup for a simple dual-stack IPv4/IPv6 simulation. We will leverage the BreakingPoint Storm CTM to simultaneously generate both IPv4 and IPv6 based application traffic running through the device under test (DUT) to check whether it can handle both IPv4 and IPv6 traffic in as accurate and scalable way as it does when dealing with IPv4 only traffic.

As most of you might already know, on the BreakingPoint Storm CTM, it really only takes two steps to set up a real-world simulation:

Network Neighborhood Setup

Just like assigning both IPv4 and IPv6 addresses to a real host, on the BreakingPoint Storm CTM, you can allocate both IPv4 and IPv6 address segments on a single interface at the same time to emulate numerous hosts during the test run.

Let us start with interface 1 which represents the client side. Here, we create two independent IPv4 and IPv6 address domains for this purpose. As shown in Figure 2 below, under the IPv6 domain, we will assign a global unicast v6 address space (starting with 2001::) for this simulation.

Next, we repeat the similar steps for the Network Neighborhood setup on interface 2, which is the server side.

Please be aware that in order to avoid a potential device issue make sure that there is no overlapping of the lower 64-bit of the IPv6 address allocation on interface 1 and interface 2. This is due to equipment vendors only using the hashing of the lower 64-bit address (instead of the full 128-bit v6 address) when it comes to the v6 traffic forwarding. If one flow bearing the same lower 64-bit of the source and destination address (even though their higher 64-bit network addresses are different), the device will drop the packet due to the identical source/destination address because of its lower 64-bit hashing implementation.

Application Simulator Components Setup

As shown in Figure 3 below, we will set up the real application traffic emulation for the test. This can be done via the BreakingPoint Storm’s Application Simulator (AppSim) component. For this dual-stack IPv4/IPv6 test, we need two AppSim components, one for the IPv4 based traffic and one for the IPv6 based traffic.

For the IPv4 based application simulation, go to the AppSim interface setting and select the IPv4 domain of interface 1 as client and interface 2 as the server. Similarly, for the IPv6 based AppSim, please go to the AppSim interface setting and select the IPv6 domain of interface 1 and interface 2 as the client and server side.

Besides the AppSim parameter settings you may already know about within the BreakingPoint Storm CTM, I recommend you also change the TCP MSS size. As you know, the IPv6 address is 128-bit long, compared to the 32-bit long IPv4 address. Therefore, the IPv6 based IP header (refer to RFC2460 for details) is 40-Bytes long compared to the 20-Byte IPv4 header. To make sure that the test will not cause too many unnecessary v6 packet fragmentations, which hurts the overall performance of the IPv6 traffic handled by the device, set the TCP MSS size to 1440 bytes. This will avoid the packet fragmentation with the default 1500 bytes MTU size of both the device and the BreakingPoint Storm CTM.

In addition, you should gradually add the IPv6 based traffic volume to find the capability of the device as it handles the dual stack IPv4/IPv6 traffic simultaneously. From our early test results, when it comes to the performance and scalability of the handling of IPv6 traffic, some devices could not match the same benchmark it holds for handling IPv4 only traffic.

Additional Resources

Beyond this simple but efficient dual stack IPv4/IPv6 simulation, BreakingPoint has provided an in-depth methodology, which shows how to create more complex tests in order to measure:

The ability of a device to transmit IPv6 traffic
The ability of the device to transmit both IPv4 and IPv6 traffic
The impact of malformed packets that are present on today’s networks
The effect of security threats on overall performance

The time is now for people to begin rethinking the way they are testing IPv6. This post and our methodology, combined with the BreakingPoint Storm CTM, will have you prepared for the oncoming wave of IPv6 traffic.

Posted by Yong Zhou