By Kowsik Guruswamy, CTO Mu Dynamics

Six-Core Opteron HE Processor
The networks of mobile operators are going through extreme transition. User-driven demand for new devices, more applications and services and faster upload and download speeds, have most mobile operators working round the clock just to keep their existing networks running. It’s easy to understand why the transition from IPv4 to IPv6, which seems to have been on the horizon for years now, has often been put on the back burner. Who has time to be proactive, even when you want to be?

Ready or not, that trend is going to need to change because the time for IPv6 is coming, fast. The IPv4 address space is rapidly being depleted, as new IP-enabled devices swamp mobile networks. Just look at the growth of smart phones, such as Apple’s iPhone®, phones based on Google’s Android™ OS and RIM’s BlackBerry®, then consider the rapid adoption of netbooks, readers and tablets - three million iPads were sold in the first 80 days of their introduction; iPad 3G subscriptions hit half a million in just three months. While all this growth is a boon for the coffers of many carriers, without more IP addresses, growth could quickly come to a complete standstill.

To say that IPv6 could impact everything might actually be understating its ramifications. IPv6 introduces a completely new way of addressing end points in a mobile network, which means there are implications starting at the network layer all the way up to the application layer. And if mobile operators aren’t prepared for the inevitable transition to IPv6, they could suffer severe network issues, including complete network failures.

It’s also why, in addition to conducting interoperability testing for all the new 3G devices and 4G infrastructure, network staff must now look at how to incorporate IPv4 to IPv6 testing into their planning and processes. Operators need to figure out a way to test everything, including IPv4-based protocols and applications in an IPv6 context, across multiple perspectives: Functionality, Interoperability, Scalability and Security. All devices and applications need to be tested to understand how they will behave over multiple networks (3G and 4G) using both IPv4 and IPv6.

The challenge for carriers is that testing is often both labor-intensive and time-consuming, typically requiring new, customized tests for each new application, service and/or network element. Adapting tests to accommodate any changes to the environment is very difficult to do with static or internally developed tests, forcing test teams to develop all new tests from scratch for each and every permutation. Carriers need to test changes to the infrastructure before they are rolled out into production, so any delays in developing tests map 1:1 to delays in rolling out new services. With mixed-configuration networks, a veritable explosion of configurations occurs, all of which need to be tested and verified. Adding IPv6 to the existing test plan could potentially double the time to test, which is not only undesirable, it’s unacceptable.

Determining how the different applications operate when they run concurrently and interact with each device and operating system will be of the utmost importance to the operators. It makes sense that existing functionality over IPv4 will need to be re-tested over IPv6, but it’s not as simple as flipping a switch. New code generally needs to be written for many existing applications and services to function correctly in an IPv6-enabled “dual stack” environment. Test teams must be able to rapidly come up with new tests to cover the new code’s complex code paths, as well as ensure the code still works in IPv4 for regression testing.

Running a network based on IPv6 means delivering not only the IPv6 packets at the network layer, but also testing any conceivable higher-layer application that works over IPv4 today and verifying that it also works over IPv6. Testing must be flexible enough to accommodate the differences between the protocols up and down the stack from layers 2 to 7.

Many legacy IPv4-based applications violate layering recommendations by referencing literal IPv4 addresses in the application layer; so simply changing the network layer may result in mismatches when a 16-byte IPv6 address is translated into a 4-byte field designed for an IPv4 address. Testers need to be confident their network is able to detect known exploits when delivered over IPv4 or IPv6, and to ensure the overall security assurance and resilience of their information assets.

Organizations also need to be confident that their IPv6 implementations can scale to the same degree as their IPv4 implementations. In order to ensure a seamless crossover capable of supporting both protocols, testing must be done in real-world conditions across every layer. It needs to accurately and statefully emulate exactly what will happen and it needs to be able to scale to meet real world mobile operator conditions. For instance, what happens when 100 million votes are cast via SMS for the next American Idol or Dancing with the Stars champ? What happens when thousands of users at a ballpark want to send a video of the game winning homerun to all their friends at the same time? Users don’t care whether it’s running over IPv4 or IPv6; their apps just need to work.

To succeed in today’s environment, where success is measured by how well a carrier handles unexpected demand, testers need to be able to rapidly develop custom-tailored tests that represent the mobile operator’s unique environment and all of the new and evolving applications and networks they are supporting. They need to be able to quickly develop a purpose-built library of test scenarios that can be used for functional and interoperability testing to significantly reduce test creation and execution time. Finally, they need to be able to test all of their supported applications, devices, operating systems and networks at scale.

A successful transition from IPv4 to IPv6 on mobile networks relies on operators being able to properly test their networks for interoperability in real-world conditions. Anything less could have disastrous effects on the network, disrupting and jeopardizing the end-user experience. Are you ready?