Burnin’ rubber with v6 under your bonnet

Much has already been written about the pressures driving the enterprise to migrate to IPv6, but what about the positive performance benefits it could bring? asks Alan Way, International Development Manager, Spirent Communications.

In the build-up to IPv6 Day, and since, a lot has been written about the exhaustion of IPv4 addresses. The pool of unallocated addresses has run out, and the Regional Internet Registries (RIRs) will soon exhaust their local pools - Asia has already done so. For now, all new internet services will continue to require IPv4 addresses to access legacy addresses, but supplies will not last for long - despite temporary measures such as recovery of unused public addresses and the use of public Network Address Translation (NAT). By 2015, 17% of the internet is predicted to use IPv6, with 28% of new internet users running the protocol.

Even if a business is confident that, for the time being, IPV4 plus NAT will give it all the visibility it needs, other factors could still force it to adopt IPv6 sooner than expected. For example: a growing number of national governments are applying mandates for IPv6 readiness. Also many new applications and services are being designed for a new generation of devices such as sensors, appliance-based controls, power management (smart grid), 4G wireless/LTE that are only just beginning to migrate to the internet and amounting to a surging demand for extra addresses - necessarily IPv6 because of the sheer numbers, predicted by companies such as IDC, Intel and Cisco to reach 15 billion intelligent, internet connected devices by 2015. Also, even if IPv6 devices can reach the company website via NAT, it could still miss key customer information based on web server logs which require native IPv6.

With pressures such as these being touted, IPv6 migration can begin to feel like yet another depressing burden on an already overstretched IT team. So let us, for a change, ‘accentuate the positive’ and ask if there might not be other benefits to look forward to, positive reasons to consider the move to IPv6? Yes, there are significant performance benefits of moving towards IPv6 that are often overlooked. It’s not just about addressing, it can actually put a little vrooooom into your network - a V6 under the bonnet really is preferable to a V4 if you are looking for added performance. In this case it can even be more efficient …

Checksums and efficiency

IPv6 is a much more structured, streamlined and efficient protocol than IPv4. IPv6 routers need not waste their precious resources calculating checksums on IP packets. Why bother, when the upper layer protocols already have protection in place? UDP, TCP and ICMPv6 all have checksums to protect the data and, along with the checksum at the MAC layer, do we really need another checksum? I don’t think so and neither did the designers of IPv6.

Fragmentation and packet length

Fragmentation is another task retired from router functionality. End points within the network have to maintain their packets within the MTU provided by the router - but with IPv6’s fixed length packets, these busy routers no longer have to reconstitute packet sizes to fit the pipes. Instead the routers can continue to focus on their primary task of directing packets to the correct destination.

Unlike IPv4’s varying packet lengths, IPv6 has a fixed packet length of 40 bytes. So the Header Length field for IPv4 is no longer present in IPv6, because we know it is going to be 40 bytes. This makes processing the packet much more efficient from the router’s perspective. There is still a field to describe the payload length, but this now also includes the packet options or extension headers. Again this helps improve the efficiency of the routers. With few exceptions, options are passed transparently through the router with no processing required.

So what are the exceptions that will have to be processed by the router? A few packets will have the hop by hop extension header in the very first position set to ‘0’ - indicating that the extensions following have to be processed by the router. This could, for example, indicate a router alert or jumbo gram - a very large packet anything up to 4 GB in length. But these options will only be handled on an exception basis, and that frees up a lot of resource within the router. Unlike IPv4 options, they do not have to be processed at every hop.

And don’t forget the flow label

The flow label is a 20-bit field at the top of the IPv6 packet - seldom used to date, but bringing the promise of much improved quality of service. Unlike differentiated services, it could deliver a more assured quality of service, similar to RSVP. Differentiated services, such as assured forwarding, rely on good human engineering at the initial network design because, for example, the QoS provisioning is largely static so, if the network is oversubscribed, certain applications such as VoIP could degrade voice quality across the entire network for all users. With the use of the flow label, however, we can implement a much more dynamic model that could more effectively mimic the PSTN. Rather than degrading the service for all users, we can provide a ‘busy’ signal when there is no longer sufficient resource within the network to guarantee a minimum QoS.

Generally the source will allocate a unique flow label for a given flow, maintaining the same destination address and source address for the life of the flow. A specific service level agreement (SLA) can be requested when the flow is initiated: if the network agrees to the requested SLA, such as throughput and latency, then this SLA will be maintained for the duration of the flow.

Experimental use of the flow label

One experimental use of the flow label showed that a tremendous improvement in throughput could be achieved in high latency communications more prone to errors - such as satellite communications. One enterprising user modified their TCP stack to bypass the TCP slow start rules - the rationale for this was that, if the network has an agreed SLA due to the flow label negotiation, there would be little need to go through the TCP slow start process, or drop the throughput by 50% on account of occasional packet loss.

Although I was not able to get direct copies of the test results you can get a very good idea of the improvement from the following diagram showing results recorded by a Spirent Test Center comparing the performance of:

• On the left, stateless data (no TCP slow start or 50% drop in throughput due to packet loss).
• On the right, normal TCP traffic following the TCP slow Start rules.

Notice how much more the TCP traffic is affected due to a mere 3% packet loss. The results shown are mimicking a comparison of a modified TCP stack using the flow label with an unmodified TCP stack. This unmodified stack could also be operating with a flow label, while the modified TCP stack could still be used to recover lost packets and ensure the integrity of the traffic flow.

Conclusion

So here’s yet another reason to migrate to IPv6. It is not just a question of a need for IPv6 readiness to be visible to, and communicate with, a growing population of new IPv6 addresses out there - there are also significant performance benefits to be gained by running IPv6 on your internal network.

What can we look forward to in this respect? One customer I know that has made the full migration is already reporting a 300% overall improvement as a result of the sort of efficiencies described above. I look forward to seeing the results of further tests along these lines - what might IPv6 do for your company network?