idnits 2.17.1 draft-keranen-ipv6day-measurements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2012) is 4244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft J. Arkko 4 Intended status: Informational Ericsson 5 Expires: March 15, 2013 September 11, 2012 7 Some Measurements on World IPv6 Day from End-User Perspective 8 draft-keranen-ipv6day-measurements-04 10 Abstract 12 During the World IPv6 Day on June 8th, 2011, several key content 13 providers enabled their networks to offer both IPv4 and IPv6 14 services. Hundreds of organizations participated in this effort, and 15 in the months and weeks leading up to the event worked hard on 16 preparing their networks to support this event. The event was 17 largely unnoticed by the general public, which is a good thing since 18 it means that no major problems were detected. For the Internet, 19 however, there was a major change on such a small timescale. This 20 memo discusses measurements that the authors made from the 21 perspective of an end-user with good IPv4 and IPv6 connectivity. Our 22 measurements include the number of most popular networks providing 23 AAAA records for their service as well as delay and connection 24 failure statistics. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 15, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Motivation and Goals . . . . . . . . . . . . . . . . . . . . . 3 62 3. Measurement Methodology . . . . . . . . . . . . . . . . . . . 4 63 4. Measurement Results . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. DNS AAAA Records . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. TCP Connection Setup . . . . . . . . . . . . . . . . . . . 7 66 4.3. TCP Connection Delays . . . . . . . . . . . . . . . . . . 7 67 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Many large content providers participated in World IPv6 Day on June 79 8, 2011. On that day, IPv6 [RFC2460] was enabled by default for 24 80 hours on numerous networks and sites that previously supported only 81 IPv4. The aim was to identify any remaining issues with widespread 82 IPv6 usage in these networks. Most of the potential problems 83 associated with using IPv6 are, after all, of a practical nature, 84 such as: ensuring that the necessary components have IPv6 turned on; 85 that configurations are correct; and that any implementation bugs 86 have been removed. 88 Some content providers have been reluctant to enable IPv6. The 89 reasons for this include delays for applications attempting to 90 connect over broken IPv6 links before falling back to IPv4 [RFC6555], 91 and unreliable IPv6 connectivity. Bad IPv6 routing has been behind 92 many of the problems. Among the causes are broken 6to4 tunneling 93 protocol [RFC3056] connectivity, experimental IPv6 setups that are 94 untested and unmonitored, and configuration problems with firewalls. 95 The situation is improving as more users and operators put IPv6 to 96 use and fix the problems that emerge. 98 World IPv6 Day event was largely unnoticed by the general public, 99 which is a good thing since it means that no major problems were 100 detected. Existing IPv4 connectivity was not damaged by IPv6 and 101 also new IPv6 connectivity worked as expected in vast majority of 102 cases. For the Internet, however, there was a major change on such a 103 small timescale. This memo discusses measurements that the authors 104 made from the perspective of an end-user with well-working IPv4 and 105 IPv6 connectivity. Our measurements include the number of most 106 popular networks providing AAAA records for their service as well as 107 delay and connection failure statistics. 109 The rest of this memo is structured as follows. Section 2 discusses 110 the goals of our measurements, Section 3 describes our measurement 111 methodology, Section 4 gives our preliminary results, and Section 5 112 draws some conclusions. 114 2. Motivation and Goals 116 Practical IPv6 deployment plans benefit from accurate information 117 about the extent to which IPv6 can be used for communication, and how 118 its characteristics differ from those of IPv4. For instance, 119 operators planning to deploy dual-stack networking may wish to 120 understand what fraction of their traffic would move to IPv6. This 121 information is useful for estimating the necessary capacity to deal 122 with the IPv6 traffic and impacts to the operator's IPv4 123 infrastructure or carrier-grade NAT devices as their traffic is 124 reduced. Network owners also wish to understand the extent to which 125 they can expect different delay characteristics or problems with IPv6 126 connectivity. The goals of our measurements were to help with these 127 topics by answering the following questions: 129 o What fraction of most popular Internet sites offer AAAA records? 130 How did the World IPv6 Day change the situation? 132 o How do the traffic characteristics differ between IPv4 and IPv6 on 133 sites offering AAAA records? Are the connection failure rates 134 similar? How are RTTs impacted? 136 There have been many measurements about some of these aspects from a 137 service provider perspective, such as the Google studies on which end 138 users have broken connectivity towards them. Our measurements start 139 from a different angle, by assuming good dual-stack connectivity at 140 the measurement end, and then probing the rest of the Internet to 141 understand, for instance, how likely there are to be IPv6 142 connectivity problems, or what the delay differences are between IPv4 143 and IPv6. Similar studies have been performed by the Comcast IPv6 144 Adoption Monitor [IPv6Monitor] and RIPE NCC [RIPEv6Day]. 146 3. Measurement Methodology 148 We used the top 10,000 sites of the Alexa 1 million most popular 149 sites list [Alexa] from June 1st 2011. For each domain name in the 150 list, we performed DNS queries with different host names. For IPv4 151 addresses (A records) we used host name "www" and also performed a 152 query with just the domain name. For IPv6 addresses (AAAA records) 153 we used also different combinations of host names that have been used 154 for IPv6 sites, namely "www6", "ipv6", "v6", "ipv6.www", "www.ipv6", 155 "v6.www", and "www.v6". 157 All DNS queries were initiated in the order listed above (first "www" 158 and just the domain name for A-records, then "www", domain name, and 159 different IPv6-host names for AAAA records) but the queries were done 160 in parallel (i.e., without waiting for the previous query to finish). 161 The first response for A and AAAA records and the corresponding host 162 names were recorded. The queries had 3 second re-transmission 163 timeout and if there wasn't any response for 10 seconds, all 164 remaining queries for the site were canceled. We used a custom-made 165 Perl script and the Net::DNS [net-dns] module for the DNS queries. 167 The measurement script used a bind9 DNS server running on the same 168 host as was performing the measurement. The DNS cache of the server 169 was flushed before each measurement run in order to detect the 170 changes in the DNS records in real-time. The host, and thus the DNS 171 server, was not part of DNS IPv6 whitelisting agreements. 173 The local network where the host performing the measurements was has 174 native IPv6 (dual-stack) connectivity. The IPv6 connectivity to the 175 local network was provided by an IPv6-over-IPv4 tunnel from the 176 network's default router to the ISP's IPv6 peering point. 178 After obtaining IP addresses for the site, if a site had both A and 179 AAAA records, a simple C program was used to create TCP connections 180 to the port 80 (HTTP) simultaneously using both IPv4 and IPv6 to the 181 (first) IP addresses discovered from the DNS. The connection setup 182 was repeated up to 10 times, giving up after the first failed attempt 183 (but only after normal TCP re-transmissions). The connection setup 184 delay was measured by recording the time immediately before and after 185 the connect system call. The host used for measurements is a regular 186 Linux PC with 2.6.32 version kernel and dual-stack Internet 187 connection via Ethernet. 189 The measurements were started one week before the World IPv6 Day (on 190 Wednesday, June 1st, 17:30 UTC) and were running until July 11th, 191 once every three hours. One test run takes from two to two and a 192 half hours to complete. 194 The accuracy and generality of the measurement results is limited by 195 several factors. While we ran the tests in three different sites, 196 most of the results discussed in this document present snapshots of 197 the situation from just one measurement point, the Ericsson Research 198 Finland premises, near Helsinki. Also, since one measurement run 199 takes quite a long time, the network characteristics and DNS records 200 may change even during a single run. The first DNS response was used 201 for the TCP connectivity tests and this selection may result in 202 selection of a non-optimal host; yet, a slight preference is given to 203 the "www" and only-domain-name records since their queries were 204 started before the others. While the host performing the 205 measurements was otherwise idle, the local network was in regular 206 office use during the measurements. The connectivity setup delay is 207 collected in user space, with regular, non real-time, kernel 208 implementation, resulting in small inaccuracies in the timing 209 information. 211 4. Measurement Results 213 4.1. DNS AAAA Records 215 The number of top 10,000 sites with AAAA DNS records before, during, 216 and after the World IPv6 Day, is shown in [DNS-top10k]. The 217 measurements performed during the World IPv6 Day are shown on the 218 light gray background. 220 When the measurements began on June 1st, there were 245 sites (2.45%) 221 of the top 10,000 sites with both A and AAAA record. During the 222 following days the number of such sites slowly increased, reaching 223 306 sites at the measurement that was started 22:30 UTC on June 7th, 224 the evening before the World IPv6 Day. When the World IPv6 Day 225 officially started, the following measurement (1:30 UTC) recorded 383 226 sites, and the next one 472 sites. During the day the number of 227 sites with AAAA records peaked at 491 (4.91% of the measured 10,000 228 sites) at 19:30 UTC. 230 When the World IPv6 Day was over, the number of AAAA records dropped 231 nearly as fast as it had increased just 24 hours earlier. However, 232 the number of sites stabilized around 310 and did not drop below 300 233 since, resulting in over 3% of the top 10,000 sites still having AAAA 234 records at the end of our measurements. 236 While 274 sites had IPv6 enabled in their DNS for some of the tested 237 host names one day before the World IPv6 Day, only 116 had it for the 238 "www" host name that is commonly used when accessing a web site. The 239 number of "www" host names with AAAA records more than tripled during 240 the World IPv6 Day reaching 374 sites for 3 consecutive measurement 241 runs (i.e., for at least 6 hours). Also the number of AAAA records 242 for the "www" host name dropped steeply after the day and remained at 243 around 160 sites since. 245 Similar but more pronounced trends can be seen if only top 100 of the 246 most popular sites are taken into considerations, as show in 247 [DNS-top100]. Here, the number of sites with some of the tested host 248 names having an AAAA record was initially 14, jumped to 36 during the 249 day, and eventually dropped to 13. Also, while none of the top 100 250 sites apparently had an AAAA record for their "www" host name before 251 and after the World IPv6 day, during the day the number peaked at 30. 252 Thus, roughly one third of the 100 most popular sites had IPv6 253 enabled for the World IPv6 Day. 255 Two other test sites in Sweden and Canada experienced similar trends 256 with the DNS records. However, one of the sites used an external DNS 257 server that was part of whitelisting agreements. There the number of 258 sites with AAAA records before the World IPv6 Day was already higher 259 (above 400) and hence the impact of the day was smaller as the amount 260 of sites increased to same numbers as seen by the test site in 261 Finland. With the whitelisted DNS server the level of sites remained 262 above 450 after the day. 264 4.2. TCP Connection Setup 266 To test whether the IP addresses given by the DNS actually provide 267 connectivity to the web site, and if there is any difference in the 268 connection setup delay and failure rates with IPv4 and IPv6, we 269 attempted to create TCP connections for all domains that contained 270 both A and AAAA DNS records. The fraction of sites for which the 271 first DNS response gave addresses that were not accessible with TCP 272 to port 80 over IPv4 or IPv6 is shown in [TCP-fails]. 274 There is a baseline failure rate with IPv4 around 1-3% that is fairly 275 static throughout the test period. For hosts with AAAA records, the 276 fraction of inaccessible sites was much higher: in the beginning up 277 to one fourth of the tested hosts did not respond to TCP connection 278 attempts. Much of this was likely due to the various test sites with 279 different "IPv6 prefixes" (as discussed in Section 3); in the first 280 run more than half of the tested sites with AAAA records used them 281 for the first DNS response. Also, some of the hosts may not even be 282 supposed to be accessed with HTTP but provide AAAA records for other 283 purposes while some sites had clear configuration errors, such as 284 localhost or link-local IPv6 addresses. 286 As the World IPv6 Day came closer, the number of inaccessible IPv6 287 sites decreased slowly and the number of sites with AAAA records 288 increased at the same time, resulting in the failure ratio dropping 289 to roughly 20% before the day. During the day the number of IPv6 290 sites increased rapidly but also the number of failures decreased and 291 hence, at the end of the day, the failure ratio dropped to just above 292 10%. After the World IPv6 Day when many of the participating IPv6 293 hosts were taken off-line, the fraction of failed sites for IPv6 294 increased. However, since there was no increase in the absolute 295 number of failed sites, the fraction of inaccessible sites remained 296 at a lower level, between 15% and 20%, than before the day. 298 4.3. TCP Connection Delays 300 For sites that were accessible with both IPv4 and IPv6, we measured 301 the time difference between establishing a TCP connection with IPv4 302 and IPv6. We took the median (as defined in Section 11.3 of 303 [RFC2330]) of the time differences of all 10 connections, and then 304 median and mean (of the median) over all sites; the result is shown 305 in [timediff]. 307 In general, the delay differences are small: median of medians stays 308 less than 3ms off from zero (i.e., IPv4 and IPv6 delays being equal) 309 and even the mean, which is more sensitive to outliers, stays most of 310 the time within +/- 5ms; with the greatest spikes reaching to roughly 311 -15ms (i.e., mean of median IPv6 delays being 15ms larger than for 312 IPv4 delays). Closer inspection of the results shows that the spikes 313 are often caused by only one or a handful of sites with bad 314 connectivity and multiple re-transmissions of TCP SYN and ACK packets 315 resulting in connection setup delays an order of magnitude larger. 317 Surprisingly the median delay for IPv6 connections is in most cases 318 equal to or smaller than the IPv4 delay, but during the World IPv6 319 Day, the IPv6 delays increased slightly and became (as median) slower 320 than their IPv4 counterparts. One reason for such an effect was that 321 some of the sites that enabled IPv6 for the World IPv6 Day, had 322 extremely low, less than 10ms, IPv4 delay (e.g., due to Content 323 Delivery Network (CDN) provider hosting the IPv4 site), but 324 "regular", over hundred millisecond, delay for the IPv6 host. 326 More detailed analysis of the TCP connection setup delay differences, 327 and the reasons behind them, is left for future work. 329 5. Conclusions 331 The World IPv6 Day had a very visible impact to the availability of 332 content over IPv6, particularly when considering the top 100 content 333 providers. It is difficult to find other examples of bigger one day 334 swings in some characteristic of the Internet. However, the impact 335 on end users was small, given that when dual-stack works correctly it 336 should not be visible at the user level and that IPv6 availability 337 for end users themselves is small. 339 The key conclusions are as follows: 341 o The day caused a large jump in the number of content providers 342 providing AAAA DNS records on that day. 344 o The day caused a smaller but apparently permanent increase in the 345 number of content providers supporting AAAA. 347 o Large and sudden swings in the relative amount of IPv4 vs. IPv6 348 traffic are possible merely by supporting a dual-stack access 349 network and having a few large content providers offer their 350 service either globally or to this particular network over IPv6. 352 o Large fraction of sites that published AAAA records for a name 353 under their domain (be it "www" or "www6" or something else) were 354 actually not responding to TCP SYN requests on IPv6. This 355 fraction is far higher than that which we've seen in our previous 356 measurements, and we are still determining why that is the case. 357 Measurement errors or problems on our side of the network cannot 358 be ruled out at this stage. In any case, it is also clear that as 359 new sites join, incomplete or in-progress configurations create 360 more connectivity problems in the IPv6 Internet than we've seen 361 before. Other measurements are needed to verify what the general 362 level IPv6 connectivity is to addresses publicly listed in AAAA 363 records. 365 o Even if the overall level of connection failures was high, 366 activities on and around the IPv6 day appear to have caused a 367 significant permanent drop in the number of failures. 369 o When IPv6 and IPv4 connectivity were both available, the delay 370 characteristics appear very similar. In other words, most of the 371 providers that made IPv6 connectivity available appear to provide 372 a production quality network. TCP connection setup delay 373 differences due to RTT differences between IPv4 and IPv6 374 connections are in general low. In the remaining differences in 375 our measurements, random packet loss plays a major role. However, 376 some sites can experience considerable differences simply because 377 of different content distribution mechanisms used for IPv4 and 378 IPv6 content. 380 It is promising that the amount of most popular Internet content on 381 IPv6 was surprisingly high, roughly one third of top 100 sites 382 (during the IPv6 day or with whitelisting enabled). However, other 383 content on the Internet forms a long tail that is harder to move to 384 IPv6. For instance, only 3% of the 10,000 most popular web sites 385 provided their content over IPv6 before the IPv6 day. On a positive 386 note, the top 100 sites form a very large part of overall Internet 387 traffic [Labovitz] and thus even the top sites moving to IPv6 could 388 represent a significant fraction of Internet traffic on IPv6. 389 However, this requires that users are enabled to use IPv6 in their 390 access networks. We believe that this should be the goal of future 391 global IPv6 efforts. 393 6. Security Considerations 395 Security issues have not been discussed in this memo. 397 7. IANA Considerations 399 This memo has no IANA implications. 401 8. References 402 8.1. Normative References 404 [timediff] 405 Keranen, A., "TCP connection setup delay differences [RFC 406 editor: please change the references to the graphs to 407 refer to the PDF version of the document]", June 2011, 408 . 410 [DNS-top10k] 411 Keranen, A., "Number of sites with AAAA DNS records in the 412 top 10,000 most popular sites", June 2011, 413 . 416 [DNS-top100] 417 Keranen, A., "Number of sites with AAAA DNS records in the 418 top 100 most popular sites", June 2011, . 421 [TCP-fails] 422 Keranen, A., "TCP connection setup failure ratio (for the 423 first DNS response)", June 2011, . 426 8.2. Informative References 428 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 429 "Framework for IP Performance Metrics", RFC 2330, 430 May 1998. 432 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 433 (IPv6) Specification", RFC 2460, December 1998. 435 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 436 via IPv4 Clouds", RFC 3056, February 2001. 438 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 439 Dual-Stack Hosts", RFC 6555, April 2012. 441 [net-dns] Fuhr, M., "Net::DNS", . 443 [IPv6Monitor] 444 Comcast and University of Pennsylvania, "IPv6 Adoption 445 Monitor", . 447 [RIPEv6Day] 448 RIPE NCC, "World IPv6 Day Measurements", 449 . 451 [Alexa] Alexa the Web Information Company, "Alexa Top 1,000,000 452 Sites", 453 . 455 [Labovitz] 456 Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, 457 J., and F. Jahanian, "Internet Inter-Domain Traffic", 458 Proceedings of ACM SIGCOMM 2010, August 2010. 460 Appendix A. Acknowledgments 462 The authors would like to thank Suresh Krishnan, Fredrik Garneij, 463 Lorenzo Colitti, Jason Livingood, Alain Durand, Emile Aben, Jan 464 Melen, and Tero Kauppinen for interesting discussions in this problem 465 space. Thanks also to Tom Petch and Bob Hinden for thorough reviews 466 and many helpful comments. 468 Authors' Addresses 470 Ari Keranen 471 Ericsson 472 Jorvas 02420 473 Finland 475 Email: ari.keranen@ericsson.com 477 Jari Arkko 478 Ericsson 479 Jorvas 02420 480 Finland 482 Email: jari.arkko@piuha.net