Those of us who have been working on IPv6 for over 15 years know what it means to be an advocate for an infrastructure technology that cannot be easily tied to new revenue or short-term risks. It is a battle on an icy uphill slope with head winds and a gallery of skeptics who call themselves realists and cheer your every bruise.

This has often made us cheer any news of a new IPv6 deployment, as a means to keep faith. However in doing so, it sometimes made us overlook the substance of that news—after all, it is easy to claim an IPv6 strategy or IPv6 readiness.

I believe we need technology religion reformation. I believe we need to cheer not just plain adoption numbers but more so, to cheer the IPv6 deployments done right.

There are two reasons for the tech community to support a qualitative rather than just quantitative approach to IPv6 enablement:

1. We pitch IPv6 to be the plan of record for IT infrastructure. While this is true, it means nothing if an IPv6 enabled infrastructure undermines the user experience expectations we set with IPv4.
2. We still have academic discussions about the fact that IPv6 is “not REALLY needed” as the foundation for the next generation IT, which includes IOT, SDN/NFV, the Cloud and mobility. The reality is that neither an IPv4-only nor a dual-stack environment is sustainable. Only an IPv6-based infrastructure would be, however, this fact can be demonstrated only through quality deployments.

More so, there are two reasons why it is our responsibility to do IPv6 right:

1. If we do it well we have a cleaner, more manageable infrastructure that can lead to better user experience, as high as 15% reported by Facebook and Verizon. This translates into business value.
2. If we do not do it right, the enablement of IPv6, which is transparent to the user, can lead to poorer user experience and/or the organization being listed on Google’s blacklist – both leading to a negative impact to the brand. This translates into business risk.

If we want IPv6 to be taken seriously, we need to measure the quality of enablement every step of the way, and we need to monitor IPv6 as the production infrastructure we like to claim it to be.

What and how to measure?

The easy part of quantitatively evaluating IPv6 deployments is that we do not need to come up with absolute values for our metrics. The expectations are already set by IPv4, so all we need to do is make sure user experience over IPv6 is at least as good as over IPv4. Nevertheless, we need to be thoughtful and comprehensive in selecting metrics.

The hard part is that industry lacks tools to measure and systematically monitor IPv6. This in itself casts a long shadow over our claims that IPv6 is production ready.

Last year, Geoff Huston wrote about IPv6 performance, a topic he also presented on at NANOG 66. He argued that there are two relevant metrics for comparing IPv4 and IPv6:

1. Reliability of the protocol (percentage of connection attempts that are successful) and
2. Round Trip time.

He collected data (Figure 1) on these two metrics through the powerful sampling mechanism based on instrumented web ads.

Figure 1. Roundtrip time over IPv6 vs IPv4 (Courtesy of Geoff Huston / Click to Enlarge)

The results show that from a latency perspective the two protocols are within 10 ms of each other 60% of the time. Connection failures are higher for IPv6 and that is attributed to some level of legacy or inconsistency in the infrastructure such as tunnels and IPv6 blocking.

While these two metrics are reasonable choices for a basic comparison of the two protocols, we need to get deeper into operational metrics that reflect user experience with services delivered over IPv6:

• DNS response time – Relevant when OSs make protocol selections based on DNS response
• TCP connect time (and not just connection completion rate) – Relevant in the context of various Happy Eyeballs (RFC 6555) implementations
• Full webpage/app load times – Relevant when comparing User Experience for IPv4 and IPv6. Not all resources are available over IPv6, redirects might behave differently for IPv6, CDNs might do a poorer job for IPv6 than IPv4, and the roundtrip time difference can compound across many resources.
• Application uptime – Relevant when the infrastructures supporting the application over IPv6 and Pv4 are incongruent
• Application Performance Index (APDEX) – Relevant when comparing User Satisfaction for IPv4 and IPv6
• IPv6 effectiveness – Relevant when you want to measure the return on your IPv6 enablement investment. This is a composite metric that takes into consideration DNS response time, Happy Eyeballs and User experience.

These metrics do take a more operational rather than protocol focused perspective. Many of these metrics do require monitoring an application from the same location over a longer period of time. Let us remember that users have no idea which protocol they are using. All they care about is to get to content or functionality faster and without outages.

A deterministic enablement of IPv6

One of the challenges with IPv6 transition is lack of metrics that can be reported to decision makers, and metrics that can be used to avoid gratuitous blaming of IPv6 for anything that goes wrong in the world.

For a measurable transition, one should go past the standard metric—percentage of infrastructure enabled, and pay attention to the larger set of operational metrics mentioned earlier while following these steps:

• Baseline them for IPv4—learn a few things about your environment and establish a reference point
• While enabling IPv6, monitor the IPv4 baselines and make sure they do not move up
• Baseline them for IPv6 and make sure they are on par or better than IPv4
• Monitor the IPv6 baselines while running IPv6 in production and then as you sunset IPv4.

This data will help you justify the investment in IPv6, qualify the work done, and operationalize IPv6.

IPv6 in production

At Nephos6, we use our own tool, v6Sonar, to monitor all the metrics mentioned earlier. We monitor during IPv6 enablement of IT infrastructures and we monitor operational services. v6Sonar data allows us to observe performance of services over time and troubleshoot issues that differentiate behavior over IPv6 vs IPv4.

Our measurements do show that some IPv6 implementation projects do very well compared to IPv4 while others lack in performance and consistency. Monitoring Facebook from several locations around the world confirms the reports that load time over IPv6 is on average 15% faster than over IPv4. Figure 2 shows a snapshot of data collected over a period of a week, however the averages remain consistent over multiple months of observation.

Figure 2. Facebook load time over IPv6 vs IPv4 (Click to Enlarge)

Facebook is not the only property showing better user experience over IPv6 compared to IPv4. Figure 3 shows the global average load times over IPv4 and IPv6 for manufacturer, social app, e-commerce and government websites picked specifically to showcase good examples of IPv6 being implemented.

Figure 3. Global average load times over IPv6 vs IPv4 (Click to Enlarge)

It is interesting to note that unlike amazon.com, which does not support IPv6, its newest competitor jet.com enabled IPv6 from day one. The improved user experience over IPv6 should be credited to their CDN, Cloudflare.

We also evaluated the user satisfaction for these sites by observing and calculating their Application Performance Index (APDEX) (Figure 4) over the two protocols. In calculating the APDEX for IPv6 we used the observed IPv4 user experience as the target response time. The idea is that users already have expectations set (based on the experience they have over IPv4).

Figure 4. User satisfaction over IPv6 vs IPv4 (Click to Enlarge)

The higher the APDEX, the better the service performs. Data shows that as far as user satisfaction is concerned, these sites are performing on par over IPv4 and IPv6.

At this point it is important to stop for a moment and make one thing very clear: the better user experience described above is not a reflection of a protocol specific differentiator; it is rather the byproduct of better, cleaner, more scalable implementations.

These are examples of good implementations, however not all sites are faring as well. There are many sites with poorer user experience over IPv6 compared to IPv4. Figure 5 shows an example of a site experiencing significant changes in user experience over IPv6 due to topology changes. For reference, the data for nih.gov is shown for the same period and all the agents monitoring it.

Figure 5. Load times for a site measure from San Francisco compared with NIH site
over the same period (Click to Enlarge)

In this case, the topology changes point to CDN issues. With IPv6 becoming available to more and more Internet users, such performance differences between IPv6 and IPv4 and variations over time will no longer go unnoticed. TCP sessions do close over IPv6 and a simple spot check of the IPv6 roundtrip delay might very well be close to that for IPv4 but that might not tell us the full picture of the service quality.

Poor IPv6 implementation will lead to a business cost. This is why, if we want to take IPv6 as the plan of record, we must baseline it and monitor it on an ongoing basis similar to any production service.

In conjunction with other measurements, these kinds of measurements help identify weak areas in global IPv6 support. For example, we do see systemic tunnels that likely are transition leftovers. These tunnels still impact performance over IPv6.

The more people involved in IPv6 monitoring, the better we will make the IPv6 infrastructure. The Swiss IPv6 Council is currently conducting a longer term regional study to evaluate the quality of implementation across Switzerland. Stay tuned for their report.

Conclusion

IPv6 is the next generation of the Internet Protocol. All the wonderful innovations related to our IT world today, the technologies and operational models baked in our multiyear IPv4 experiment: Cloud, SDN/NFV, IOT, Mobility will not be able to fully deliver on their promise in the absence of IPv6. IPv6 can make these technologies better but it most definitely makes them more scalable and easier to operate. This is all about the system perspective; about the operational perspective.

The only way to benefit from the resources provided by IPv6 is to think about solutions in IPv6 terms and to deploy IPv6 well. A poor IPv6 deployment is, at best, a missed opportunity, and at worst, a loss to the business and brand. Therefore, it is time to treat IPv6 like the production protocol that it is, and to measure and monitor the quality of its execution from deployment to operations. The more we focus on the quality and not just quantity of deployment, the stronger the case for IPv6 adoption will be.

Originally published on APNIC blog.