World IPv6 Launch - Results from HTTP Measurements

Introduction

In a previous article we described the measurements the RIPE NCC performed for World IPv6 Launch. With ping and traceroute we measured performance and reachability on the network layer. On the application layer we measured availability of HTTP service, over both IPv4 and IPv6. These results are visualised in dashboards, for each IP version a matrix which shows the outcome of the latest HTTP measurements from each vantage point to each measured participant (you can click on the images to get a bigger version).

Figure 1. Results of one round of HTTP IPv6 measurements

In the graph, each cell represents the outcome of one single HTTP measurement between a vantage point and a participant. Colours represent the outcome:

• Green for success (we could reach the site over IPv6)
• Red for failure (no response)
• Orange for a DNS problem (an error occurred in looking up the IPv6 address)
• Blue for no IPv6 record in the DNS
• White cells indicate no recent data available (the site was not measured from a particular vantage point).

In each row the cells represent measurements towards a single destination, i.e. a participant's web site. In each column the cells represent a vantage point we measured from.

Figure 1 shows the status at 12:00 on 4 June 2012, 36 hours  before World IPv6 Launch started. The twenty sites which had not yet enabled IPv6 in the DNS clearly stand out as mostly solid blue lines. Google and Youtube, both using white listing, show a mix of blue and green. Many of the vantage points did not receive the AAAA record from the DNS. The nine vantage points which could get an AAAA record had no problem reaching the Google/YouTube websites over IPv6.. The total number of red cells, indicating failures, seems large. However, closer inspection shows most can be attributed to problems at three vantage points (columns) and one participant (row). A similar graph for HTTP over IPv4 does not show these problems, this is a strong indication the issues are related to IPv6 transport.

Because each graph represents a snapshot from one round of measurements, information on the longevity of the failures is missing. One has to look at a number of these plots, for different timestamps, to understand the nature of the problems: were they one-off, relatively short lived events, or did they persist for a longer time. To help in this, we created a timelapse movie from all the snapshots  between 12:00 UTC on 4 June and 12:00 UTC on 8 June 2012. The result nicely summarises the dynamics of 96 hours of HTTP IPv6 measurements in less than 3 minutes.

Observations

Looking at this 4-day sequence of measurement results, some trends stand out:

• Most of the HTTP failures (red cells) are clustered in a few rows and columns. This indicates the majority of problems occurred at the edge of the network, close to a small number of  participating websites and vantage points.

• From the evening of 4 June onwards, no single participant or vantage point shows 100% failures for a prolonged time. Apart from the occasional short lived incident, every site and vantage point had at least some partial success with HTTP over IPv6.

• Generally, things improve over time. Significantly fewer HTTP failures are seen towards the end of the movie; this is also illustrated by Figure 2, a snapshot of the results at 12:00 on 8 June 2012.

Not as prominently visible as the above but still noteworthy are the isolated cells which are colored red all the time. These represent permanent failure between a single vantage point and a single participant. Because both the vantage point and participant are otherwise without problems (dominantly green colored cells in the relevant row and column), our take is that the isolated failures are a sign of problems further in the network, not at the edge. An example could be transit providers with only partial IPv6 connectivity, not carrying routes to all destinations.

Figure 2. Status at 12:00 UTC on 8 June. Compared to the initial state 4 days earlier,
more sites are IPv6 enabled and the measurement network sees fewer problems

Also interesting are the constant state changes for vantage point tt105: many of the measured participants alternate between success and failure for IPv6 HTTP from that vantage point. Looking at the raw data, we see cases where the IPv6 ping measurements were successful, but HTTP over IPv6 timed out. It is not immediately obvious what is causing this. However, as we see this from only one vantage point and only with IPv6, the problem is likely in the hosting site.

Finally, our measurements illustrate the impact of the problems in DNS provisioning services for www.netflix.com (which were discussed on the NANOG mailing list ). From the start of our measurements until about 08:00 UTC on 7 June we see intermittent black-outs, various vantage points not finding AAAA record in the DNS (blue colored cells) for a short period of time. From 08:00 to midnight the blackout of netflix over IPv6 is almost total; only very occasionally does a vantage point find an IPv6 address in the DNS (and when they do, the HTTP works ok). Starting at 00:00 UTC on 8 June things begin to recover. More and more vantage points find the AAAA records and successfully retrieve a page from the www.netflix.com website.

Conclusion

Generally, HTTP over IPv6 worked well; most issues which occurred were local, close to a vantage point or participant. However, compared to HTTP over IPv4  we do see more problems pop up. A possible explanation for this is that in day to day operations issues with IPv6 may not be seen immediately; in case of connectivity issues users with a dual-stack host will fall back to IPv4 and may reach the targeted website without noticeable delay. To keep the IPv6 Internet in a good state, more proactive monitoring is essential. When problems are isolated and occur only on a subset of the paths to or from a host, a distributed measurement system like RIPE Atlas can help to identify and resolve these issues timely.