RFC 6948

Some Measurements on World IPv6 Day from an End-User Perspective

📅 published July 2013, from ietf

RFC 6948: Some Measurements on World IPv6 Day from an End-User Perspective 🎀

Okay bestie, this one is a whole vibe. It's an Independent Submission and the Category is Informational 🦋. Two authors, A. Keranen and J. Arkko, both from Ericsson 💅. The ISSN is 2070-1721, and it's dated July 2013 🌸. The title block doesn't list anything it obsoletes or updates, so there's no drama there ✨.

Abstract

Okay so, on World IPv6 Day (June 8, 2011), a bunch of big content providers turned on both IPv4 and IPv6 🌈. Hundreds of organizations were involved, and for months and weeks beforehand they were working so hard to get their networks ready 😭🫶. The event was largely unnoticed by the general public, and honestly that's the best outcome, because it means no major problems showed up 💖. For the Internet though, it was a huge change in a really short time 🔥.

This memo shares measurements the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity 🧚. They looked at how many of the most popular networks had AAAA records for their service, plus delay and connection failure stats 👑.

Status of This Memo

Tea time: this document is not an Internet Standards Track specification. It's published for informational purposes only 💜.

It's a contribution to the RFC Series, and it's independent of any other RFC stream 🎀. The RFC Editor picked to publish it at its own discretion, and they make no statement about how useful it is for implementation or deployment 🙈. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard. For that, see Section 2 of RFC 5741 ✨.

Want the current status, any errata, or a way to send feedback? Check out http://www.rfc-editor.org/info/rfc6948 🦋.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors 🌈. All rights reserved 💅.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are found at http://trustee.ietf.org/license-info and were in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🫶.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Motivation and Goals  . . . . . . . . . . . . . . . . . . . .   3
3.  Measurement Methodology . . . . . . . . . . . . . . . . . . .   4
4.  Measurement Results . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  DNS AAAA Records  . . . . . . . . . . . . . . . . . . . .   5
  4.2.  TCP Connection Setup  . . . . . . . . . . . . . . . . . .   6
  4.3.  TCP Connection Delays . . . . . . . . . . . . . . . . . .   7
5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   8
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
7.  Informative References  . . . . . . . . . . . . . . . . . . .  10
Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11

1. Introduction ✨

Lots of big content providers joined World IPv6 Day on June 8, 2011 💖. That day, IPv6 [RFC2460] got switched on by default for 24 hours across loads of networks and sites that had only ever done IPv4 🌸. The goal was to find any leftover problems with IPv6 being used widely across these networks 🔍. Most of the potential issues with IPv6 are honestly practical stuff, like making sure the right components have IPv6 turned on, configs are correct, and any implementation bugs are gone 🛠️.

Some content providers were kinda hesitant to turn on IPv6 😬. Part of it is that apps trying to connect over broken IPv6 links can get delays before they fall back to IPv4 [RFC6555], and IPv6 connectivity wasn't always reliable 💀. Bad IPv6 routing caused a lot of the trouble 🙈. The culprits include broken 6to4 tunneling protocol [RFC3056] connectivity, experimental IPv6 setups that nobody tests or monitors, and firewall configuration problems 🔥. Thankfully it's getting better as more users and operators actually use IPv6 and fix the problems that pop up 🌈.

World IPv6 Day was largely unnoticed by the general public, which again is a good thing, because it means no major problems were detected 🎀. Existing IPv4 connectivity wasn't damaged by IPv6, and new IPv6 connectivity worked as expected in the vast majority of cases 👑. For the Internet, though, it was still a major change on a short timescale ⭐. This memo talks about measurements the authors made from an end user's point of view, with well-working IPv4 and IPv6 connectivity 🦋. They measured how many of the most popular networks provide AAAA records for their service, along with delay and connection failure statistics 📊.

Here's how the rest of the memo is laid out 🧚. Section 2 covers the goals of the measurements, Section 3 describes the methodology, Section 4 shares the preliminary results, and Section 5 wraps up with some conclusions 💅.

2. Motivation and Goals 💜

Real IPv6 deployment plans get a lot out of accurate info about how well IPv6 can be used for communication and how its characteristics differ from IPv4 🫶. For example, operators planning to run dual-stack networking might want to know what fraction of their traffic would move over to IPv6 🌸. That helps estimate the capacity needed to handle the IPv6 traffic, and also the impact on the operator's IPv4 infrastructure or carrier-grade NAT devices as their traffic goes down 📉. Network owners also want to know how much they can expect delay characteristics or IPv6 connectivity problems to differ 🔍. So the goals of these measurements were to help answer the following questions 💖:

  • What fraction of the most popular Internet sites offer AAAA records? How did World IPv6 Day change the situation? 🎀
  • How do the traffic characteristics differ between IPv4 and IPv6 on sites offering AAAA records? Are the connection failure rates similar? How are round-trip times (RTTs) impacted? 👀

There have been lots of measurements of some of these things from a service provider's perspective, like Google's studies about broken connectivity between Google and its end users 🌈. This work comes at it from a different angle 🦋. It assumes good dual-stack connectivity at the measurement end, and then probes the rest of the Internet to figure out things like how likely IPv6 connectivity problems are, or what the delay differences are between IPv4 and IPv6 ✨. Similar studies were done by the University of Pennsylvania and Comcast [IPv6Monitor] and by RIPE NCC [RIPEv6Day] 🧚.

3. Measurement Methodology 🛠️

They used the top 10,000 sites from the Alexa 1 million most popular sites list [Alexa], as of June 1, 2011 💅. For each domain name on the list, they ran DNS queries using different host names 🔍. For IPv4 addresses (A records), they used the host name www and also ran a query with just the domain name 🌸. For IPv6 addresses (AAAA records), they used different combos of host names that people had been using for IPv6 sites: www6, ipv6, v6, ipv6.www, www.ipv6, v6.www, and www.v6 🌈.

All the DNS queries started in the order listed above (first www and just the domain name for A records, then www, the domain name, and the different IPv6 host names for AAAA records) 🎀. But they ran in parallel, meaning they didn't wait for the previous query to finish 🧚. The first response for the A and AAAA records, and the matching host names, were recorded 📝. The queries had a 3-second retransmission timeout, and if there was no response for 10 seconds, all the remaining queries for that site were canceled 😬. They used a custom Perl script plus the Net::DNS [net-dns] module for the DNS queries 💻.

The measurement script used a bind9 DNS server running on the same host that was doing the measuring 🦋. The DNS cache was flushed before each measurement run so they could catch changes in the DNS records in real time ⚡. The host, and therefore the DNS server, was not part of DNS IPv6 whitelisting agreements 🙈. (See Section 4.3 of [RFC6589] for info on DNS resolver whitelisting 📚.)

The local network where the measurement host sat had native IPv6 (dual-stack) connectivity 🌐. Its IPv6 connectivity came through an IPv6-over-IPv4 tunnel from the network's default router to the ISP's IPv6 peering point 🚇.

After getting IP addresses for a site, if the site had both A and AAAA records, a simple C program created TCP connections to port 80 (HTTP) at the same time over both IPv4 and IPv6 🧁. It used the (first) IP addresses found through DNS 🔍. The connection setup was repeated up to 10 times, and it gave up after the first failed attempt (but only after normal TCP retransmissions) 💀. The connection setup delay was measured by recording the time right before and right after the connect system call ⏱️. The measurement host was a regular Linux PC with a 2.6.32 kernel and a dual-stack Internet connection over Ethernet 🐧.

The measurements started one week before World IPv6 Day (on Wednesday, June 1, 17:30 UTC) and ran once every three hours until July 11 📅. One test run took two to two-and-a-half hours to finish ⏳.

Real talk, the accuracy and generality of the results have some limits 🙃. They ran the tests at three different sites, but most of the results in this document are snapshots from just one measurement point, the Ericsson Research Finland premises near Helsinki 📍. Also, since one run took such a long time, the network characteristics and DNS records might have changed even during a single run 🌀. The first DNS response was used for the TCP connectivity tests, and that choice might have picked a non-optimal host 🫠. A slight preference went to the www and only-domain-name records, though, since their queries started before the others 👑. While the measurement host was otherwise idle, the local network was in regular office use during the measurements 🏢. The connection setup delay was collected in user space, with a regular, non-real-time kernel implementation, which caused small inaccuracies in the timing info ⏲️.

4. Measurement Results 📊✨

The juicy numbers are coming in part 2, so stay tuned, bestie 🫶💖

4.1. DNS AAAA Records ✨

okay so bestie, this is where the DNS side gets spicy 🌸 The number of top 10,000 sites with AAAA DNS records before, during, and after World IPv6 Day is shown in Figure 1. The measurements taken during World IPv6 Day sit on the light gray background 🩶

                               [See the PDF.]

     Figure 1: Number of sites with AAAA DNS records in the top 10,000
                            most popular sites

So when the measurements kicked off on June 1, 245 sites (2.45%) of the top 10,000 already had both A and AAAA records 🎀 Over the next few days the number crept up, reaching 306 sites in the measurement started at 22:30 UTC on June 7, the evening before World IPv6 Day. When the day officially started, the next measurement (at 01:30 UTC) recorded 383 sites, and the one after that hit 472 sites 🚀 During the day, the count peaked at 491 (4.91% of the measured 10,000 sites) at 19:30 UTC. Main character energy, no cap 👑

Then the day ended and the AAAA records dropped almost as fast as they'd climbed just 24 hours earlier 📉 Still, the number settled around 310 and never dipped below 300 after that. So on July 11, when the measurements finished, over 3% of the top 10,000 sites still had AAAA records 🦋

Now here's the tea ☕ While 274 sites had IPv6 enabled in their DNS for some of the tested host names one day before World IPv6 Day, only 116 had it for the "www" host name, the one people usually type when they visit a website 🙈 The number of "www" host names with AAAA records more than tripled during World IPv6 Day, reaching 374 sites for 3 consecutive measurement runs (i.e., for at least 6 hours) 😭 Afterwards, the "www" AAAA count dropped steeply and stuck around 160 sites 💜

Similar but even more dramatic trends show up if you only look at the top 100 most popular sites, as shown in Figure 2 🌈

                               [See the PDF.]

    Figure 2: Number of sites with AAAA DNS records in the top 100 most
                               popular sites

In that group, the number of sites with some of the tested host names having an AAAA record started at 14, jumped to 36 during the day, and then eventually fell to 13 💅 And while none of the top 100 sites apparently had an AAAA record for their "www" host name before or after World IPv6 Day, the number peaked at 30 during the day. So roughly one third of the 100 most popular sites had IPv6 enabled for World IPv6 Day 🔥

Two other test sites, one in Sweden and one in Canada, saw similar DNS trends. One of them, though, used an external DNS server that was part of whitelisting agreements. Its AAAA count before World IPv6 Day was already higher (more than 400), so the day had a smaller impact, because the number rose to the same level the test site in Finland saw 🍓 With the whitelisted DNS server, the count stayed above 450 after the day 🫶

4.2. TCP Connection Setup ✨

To check whether the IP addresses the DNS handed out actually connect to the website, and whether connection setup delay and failure rates differ between IPv4 and IPv6, we tried to create TCP connections for every domain that had both A and AAAA DNS records 🧚 The fraction of sites where the first DNS response gave addresses that couldn't be reached with TCP to port 80 over IPv4 or IPv6 is shown in Figure 3.

                               [See the PDF.]

      Figure 3: TCP connection setup failure ratio (for the first DNS
                                 response)

The IPv4 baseline failure rate sat around 1-3% and stayed pretty steady the whole time 🧊 For hosts with AAAA records, the share of unreachable sites was way higher. At first, up to one fourth of the tested hosts didn't respond to TCP connection attempts 😬 A lot of this was likely down to the different test sites using different "IPv6 prefixes" (as discussed in Section 3). In the first run, more than half of the tested sites with AAAA records used them for the first DNS response. Some hosts also weren't supposed to be accessed with HTTP at all, but had AAAA records for other purposes, and some sites had obvious configuration errors, like localhost or link-local IPv6 addresses 🤦‍♀️

As World IPv6 Day got closer, the number of unreachable IPv6 sites slowly decreased while the number of sites with AAAA records increased, so the failure ratio dropped to roughly 20% before the day 🌷 During the day, the IPv6 site count shot up, and the failures also went down, so by the end of the day the failure ratio was just above 10% 🎉 After World IPv6 Day, when many of the participating IPv6 hosts went offline, the failed fraction for IPv6 went back up. But since the absolute number of failed sites didn't increase, the fraction stayed lower, between 15% and 20%, than it was before the day 💖

4.3. TCP Connection Delays ✨

For sites that were reachable over both IPv4 and IPv6, we measured the time difference between establishing a TCP connection over IPv4 and over IPv6 🦋 We took the median (as defined in Section 11.3 of [RFC2330]) of the time differences across all 10 connections, then the median and mean (of the median) across all sites. The results are shown in Figure 4.

                               [See the PDF.]

      Figure 4: TCP connection setup delay differences (IPv4 - IPv6)

Generally, the delay differences were tiny 🤏 The median of medians stayed less than 3 ms away from zero (i.e., IPv4 and IPv6 delays were equal). The mean, which is more sensitive to outliers, mostly stayed within +/-5 ms, with the biggest spikes reaching roughly -15 ms (i.e., the mean of median IPv6 delays was 15 ms larger than the IPv4 delays) 😳 Looking closer, those spikes were usually caused by one site or a handful of sites with bad connectivity and multiple retransmissions of TCP SYN and ACK packets, which made their connection setup delays an order of magnitude larger than the rest 💀

Here's the surprising part 🙃 The median delay for IPv6 connections was, in most cases, equal to or smaller than the IPv4 delay. But during World IPv6 Day, IPv6 delays crept up a little and became (as a median) slower than their IPv4 counterparts. One reason was that some sites that enabled IPv6 for World IPv6 Day had an extremely low IPv4 delay, under 10 ms (e.g., because of the Content Delivery Network (CDN) provider hosting the IPv4 site), but a "regular" delay (over 100 ms) for the IPv6 host 🌈

More detailed analysis of the TCP connection setup delay differences, and the reasons behind them, is left for future work 🔮

5. Conclusions ✨

World IPv6 Day had a very visible impact on IPv6 content availability, especially among the top 100 content providers 👑 It's hard to find other examples of bigger one-day swings in certain characteristics of the Internet 🤯 The impact on end users, though, was small. When dual-stack works correctly it shouldn't be visible at the user level, and IPv6 availability for end users themselves is still small 🫶

The key conclusions are as follows:

  • On that day, there was a large jump in the number of content providers providing AAAA DNS records 🎀
  • On that day, there was a smaller but apparently permanent increase in the number of content providers supporting AAAA 🌸
  • Large and sudden swings in the relative amount of IPv4 vs. IPv6 traffic are possible just by supporting a dual-stack access network and having a few large content providers offer their services globally or to a particular network over IPv6 🔥
  • A large fraction of sites that published AAAA records for a name under their domain (be it "www", "www6", or something else) were actually not responding to TCP SYN requests on IPv6. This fraction was far higher than what we'd seen in our previous measurements, and we're still figuring out why. Measurement errors or problems on our side of the network can't be ruled out at this stage. Either way, as new sites joined, incomplete or in-progress configurations created more connectivity problems in the IPv6 Internet than we'd seen before 😭 Other measurements are needed to verify the general level of IPv6 connectivity to addresses publicly listed in AAAA records 🔍
  • Even though the overall level of connection failures was high, activities on and around IPv6 day appear to have caused a significant permanent drop in the number of these failures 📉
  • When IPv6 and IPv4 connectivity were both available, their delay characteristics looked very similar. In other words, most of the providers that made IPv6 connectivity available appear to have provided a production-quality network 💅 TCP connection setup delay differences due to RTT differences between IPv4 and IPv6 connections were generally low. In the remaining differences, random packet loss played a major role. Still, some sites could see considerable differences simply because of different content distribution mechanisms used for IPv4 and IPv6 content 🧩

It's promising that the amount of the most popular Internet content on IPv6 was surprisingly high, roughly one third of the top 100 sites (during World IPv6 Day or with whitelisting enabled) 🌟 Other content on the Internet forms a long tail that's harder to move to IPv6, though. For instance, only 3% of the 10,000 most popular web sites provided their content over IPv6 before World IPv6 Day 🐢 On a positive note, the top 100 sites make up a very large part of overall Internet traffic [Labovitz], so even the top sites moving to IPv6 could represent a significant fraction of Internet traffic on IPv6 🚀 However, this requires users to be enabled to use IPv6 in their access networks. We believe this should be the goal of future global IPv6 efforts 🌍

6. Security Considerations ✨

Security issues have not been discussed in this memo. 🚨💀 Dramatic, I know, but the document really doesn't cover them. Keep that in mind when you're building on top of it 🫶

7. Informative References ✨

okay bestie, here are all the sources this doc leans on 📚🦋 (I've kept every detail so you can look them up yourself)

  • [RFC2330]: Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
  • [RFC2460]: Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC3056]: Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
  • [RFC6555]: Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
  • [RFC6589]: Livingood, J., "Considerations for Transitioning Content to IPv6", RFC 6589, April 2012.
  • [net-dns]: Fuhr, M., "Net::DNS", <http://www.net-dns.org/>.
  • [IPv6Monitor]: University of Pennsylvania and Comcast, "IPv6 Monitoring @ Penn", 2012, <http://mnlab-ipv6.seas.upenn.edu/>.
  • [RIPEv6Day]: RIPE NCC, "World IPv6 Day Measurements", <http://v6day.ripe.net/>.
  • [Alexa]: Alexa the Web Information Company, "Alexa Top 1,000,000 Sites", <http://s3.amazonaws.com/alexa-static/top-1m.csv.zip>.
  • [Labovitz]: Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., and F. Jahanian, "Internet Inter-Domain Traffic", Proceedings of ACM SIGCOMM 2010, August 2010.

Appendix A. Acknowledgments 🌸

Big thank-yous to Suresh Krishnan, Fredrik Garneij, Lorenzo Colitti, Jason Livingood, Alain Durand, Emile Aben, Jan Melen, and Tero Kauppinen for the super interesting discussions in this problem space 🫶 Extra love to Tom Petch and Bob Hinden for the thorough reviews and loads of helpful comments 💜

Authors' Addresses 💖

Ari Keranen
Ericsson
Jorvas  02420
Finland

EMail: ari.keranen@ericsson.com


Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net

And that's the whole doc, bestie! 🌈👑💅

📦 where this page comes from