In the first part of this blog, we reviewed some recent studies on the performance of IPv6 compared with IPv4. Geoff Huston’s research concluded that IPv4 and IPv6 can be equivalent in many cases. Facebook’s Paul Saab concluded that their customers experience faster performance over native IPv6. Similar to the measurements of the amounts of IPv6 traffic observed on the Internet, it depends on where you take your measurements. Now, let’s consider the IPv6 protocol and see if there are any fundamental characteristics of IPv6 that could make it faster in certain circumstances.
NAT Avoidance
One of the key differences between IPv4 and IPv6 is that IPv4 relies heavily on Network Address Translation (NAT) and Port Address Translation (PAT) due to IPv4 address exhaustion. IPv6 uses global addresses and typically does not rely on NAT in any way. For IPv4, every time a packet crosses a NAT/PAT middle-box, the packet source address is re-written, and the TCP/UDP source port is changed. The packet is then forwarded on to the IPv4 destination address. The NAT/PAT system then has to maintain connection state, reversing the process on the response packets, so that the return traffic can reach the original packet source.
Many applications create many connections and with numerous users behind a single NAT/PAT. As a result, there is congestion, not for Internet bandwidth, but for TCP/UDP port space and limited IPv4 address pool resources. The packet manipulation performed by the NAT function can add latency and jitter to IPv4 packets. There are many benefits to avoiding the use of NATs. As ISPs explore the use of Carrier Grade NAT (CGN), they start to understand how this can negatively impact their end-user experience by negatively affecting some applications. Lee Howard has given presentations on the TCO for CGN and has concluded that service providers should work to deploy as little CGN as they can get away with.
Refreshingly, IPv6 does not need or use any NAT or PAT functionality and restores the native end-to-end nature of the IP protocol. IPv6 performance is streamlined as a result of its native communication.
Checksums for Determining IP Packet Bit Errors
IPv4 was created at a time when WAN transmission links were prone to bit errors. Therefore, IPv4 implements a header checksum to determine if there is an error in the fields in the IPv4 header itself. With IPv4, as each packet is forwarded across a Layer-3 hop, the header Time To Live (TTL) value is decremented by one. This results in the router having to re-compute the header checksum each hop along the transmission path. There are methods to detect bit errors at Layer-1, there are checksums at Layer-2, a checksum in the header at Layer-3, and TCP implements options for retransmissions, of course, so applications can check if an error occurred in the payload. This all adds up to lots of checking to determine if a bit error has occurred, adding to the protocol overhead, and potentially decreasing performance.
In contrast, IPv6 was created when transmission link quality was improving. We now have higher quality copper connections and cables and far greater use of fiber optic communications with vastly better error rates than links from the 1980s. IPv6 does not have any type of header checksum. IPv6 still uses a Hop Limit value within its header and that is decremented every Layer-3 hop along the transmission path, but that does not result in any header checksum calculation. Another difference between IPv4 and IPv6 is that IPv4 packets may be variable in length while the basic IPv6 header is a fixed 40-bytes. Even though IPv6 packets are larger, they can still be hardware accelerated like IPv4 and the performance difference is negligible.
Both IPv4 and IPv6 protocols support the same transport layer protocols above them. Both IPv4 and IPv6 use checksums for TCP and UDP packets. There are TCP checksums for IPv4 and IPv6 and UDP checksums for IPv4 and IPv6. These checksums are functionally equivalent and the computation of the checksum is only slightly different for IPv4 and IPv6. The way that these transport layer checksums are computed have virtually identical performance for IPv4 and IPv6. When an IPv4 packet traverses a NAT that modifies the TCP or UDP checksum, then those header checksums must also be recomputed which adds a small amount of delay. Without NAT, IPv6 packets won’t need their TCP or UDP header checksums recomputed along the transmission path.
Testing IPv6 and IPv4 Performance
There are many different ways to test end-to end IPv4 and IPv6 connectivity, speed, throughput, packet loss, and any other number of communication measurements. To test end-to-end network performance, this requires tools that load a network with IPv6 traffic. This could be synthetic or real traffic. There are numerous network tools that you can use to test end-to-end connectivity and gain some round-trip-time (RTT) measurements or other performance statistics. Common tools include: ping, traceroute, Microsoft pathping, MTR, tcptraceroute6, Cisco IOS IP SLA, iperf, xjperf, pchar, among others. However, often it is easier to simply browse to one of many speedtest sites and click on the test button.
Speedtest.net has been a long time “go to” site for testing network performance. However, it only tests raw download and upload performance and ping latency to the closest test point. Unfortunately, it doesn’t compare IPv4 to IPv6 speeds.
There are several dual-protocol tests that measure the performance of your IPv6 Internet link. You just need to be sure that it is one that tests IPv6 connectivity. This speedtest site http://ipv6.speedtest.premieronline.net is operated by Premier Communications in the U.S. If you are in the UK, you can check out http://ipv6-speedtest.net and if you are in Japan, this site would work for you http://speedtest6.com. Many of these speedtest sites seem to be operated by Oookla. Fast.com also offers a free Internet Speed Test that works over IPv6.
Comcast Speedtest
Comcast has put a tremendous amount of effort into their IPv6 deployment over the past decade. The graphs from World IPv6 Launch site shows that a significant amount of Comcast subscribers are now using IPv6.
There have also been documented cases where using IPv6 with Comcast can be faster than using IPv4. Comcast has their own Speedtest system that compares the performance of IPv4 and IPv6. If you are a Comcast subscriber you can try this by browsing to http://speedtest.xfinity.com/. One subscriber Shumon Huque found that IPv6 ping latency was 32 ms. compared to IPv4 ping latency of 63 ms. and his download speeds and upload speeds were both significantly faster with IPv6.
I have been a long-time satisfied Comcast subscriber with solid dual-protocol connectivity to my house in Denver. Using this speedtest with the local testing location results is nearly equivalent performance for IPv4 and IPv6.
If you are an AT&T subscriber, you can use their speedtest site. Charter Communications has a speedtest site. Your service provider may have their own speedtest site, but you may want to try to verify yourself it is tests IPv6 and IPv4 performance and compare the results.
Conclusions
As they often say, “Your Mileage May Vary (YMMV)”. Depending on the nature of your applications, operating system, network equipment, and Internet connectivity, IPv6 might actually be slower for you than IPv4. This could be the case if you are relying on 6to4 and Teredo tunnels. However, if you have native IPv6 connectivity and a robust ISP, you may actually be getter better performance over IPv6 transport. However, there is much work remaining to make IPv6 as ubiquitous as IPv4.
There are still many content providers and popular web sites that are not yet using IPv6. There is still work to be done to complete IPv6 and deploy it within corporate networks to end-users. Stated another way, many organizations are not benefiting from the same performance improvements that Facebook is experiencing by enabling IPv6. And when organizations deploy IPv6, they may experience a faster Internet.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/t5/IPv6-Center-of-Excellence/Can-IPv6-Really-Be-Faster-than-IPv4-Part-2/ba-p/6748.
Scott Hogg is the Chief Technology Officer (CTO) for GTRI.
