Independent Submission                                        A. Keranen
Request for Comments: 6948                                      J. Arkko
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                July 2013
        
Independent Submission                                        A. Keranen
Request for Comments: 6948                                      J. Arkko
Category: Informational                                         Ericsson
ISSN: 2070-1721                                                July 2013
        

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

从最终用户的角度衡量世界IPv6日

Abstract

摘要

During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

在2011年6月8日的世界IPv6日期间,一些关键内容提供商使其网络能够同时提供IPv4和IPv6服务。数以百计的组织参与了这项工作,在活动之前的几个月和几个星期里,他们努力准备自己的网络来支持这项活动。公众基本上没有注意到这一事件,这是一件好事,因为这意味着没有发现重大问题。然而,互联网在短时间内发生了重大变化。本备忘录讨论了作者从具有良好IPv4和IPv6连接的最终用户的角度进行的测量。我们的测量包括为其服务提供AAAA记录的最流行网络的数量,以及延迟和连接故障统计数据。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

这是对RFC系列的贡献,独立于任何其他RFC流。RFC编辑器已选择自行发布此文档,并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6948.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6948.

Copyright Notice

版权公告

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

版权所有(c)2013 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

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  . . . . . . . . . . . . . . . . . . . . . . . .   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
1. 介绍

Many large content providers participated in World IPv6 Day on June 8, 2011. On that day, IPv6 [RFC2460] was enabled by default for 24 hours on numerous networks and sites that previously supported only IPv4. The aim was to identify any remaining issues with widespread IPv6 usage in these networks. Most of the potential problems associated with using IPv6 are, after all, of a practical nature, such as ensuring that the necessary components have IPv6 turned on, that configurations are correct, and that any implementation bugs have been removed.

许多大型内容提供商参加了2011年6月8日的世界IPv6日。在那一天,IPv6[RFC2460]在许多以前只支持IPv4的网络和站点上默认启用24小时。目的是确定在这些网络中广泛使用IPv6的任何遗留问题。毕竟,与使用IPv6相关的大多数潜在问题都是实际问题,例如确保必要的组件已打开IPv6,配置正确,并且已删除任何实现错误。

Some content providers have been reluctant to enable IPv6. The reasons for this include delays for applications attempting to connect over broken IPv6 links before falling back to IPv4 [RFC6555] and unreliable IPv6 connectivity. Bad IPv6 routing has been behind many of the problems. Among the causes are broken 6to4 tunneling protocol [RFC3056] connectivity, experimental IPv6 setups that are untested and unmonitored, and configuration problems with firewalls. The situation is improving as more users and operators put IPv6 to use and fix the problems that emerge.

一些内容提供商一直不愿意启用IPv6。原因包括应用程序在返回IPv4[RFC6555]之前试图通过中断的IPv6链路连接的延迟以及不可靠的IPv6连接。许多问题的背后都是糟糕的IPv6路由。原因包括6to4隧道协议[RFC3056]连接中断、未经测试和监控的实验性IPv6设置以及防火墙配置问题。随着越来越多的用户和运营商使用IPv6并解决出现的问题,情况正在改善。

The World IPv6 Day event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. Existing IPv4 connectivity was not damaged by IPv6, and also new IPv6 connectivity worked as expected in vast majority of cases. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with well-working IPv4 and IPv6 connectivity. Our measurements include the number of the most popular networks providing AAAA records for their service, as well as delay and connection failure statistics.

公众基本上没有注意到世界IPv6日活动,这是一件好事,因为这意味着没有发现重大问题。现有的IPv4连接并没有被IPv6破坏,而且新的IPv6连接在绝大多数情况下都能如期工作。然而,互联网在短时间内发生了重大变化。本备忘录讨论了作者从具有良好IPv4和IPv6连接的最终用户的角度进行的测量。我们的测量包括为其服务提供AAAA记录的最流行网络的数量,以及延迟和连接故障统计数据。

The rest of this memo is structured as follows. Section 2 discusses the goals of our measurements, Section 3 describes our measurement methodology, Section 4 gives our preliminary results, and Section 5 draws some conclusions.

本备忘录的其余部分结构如下。第2节讨论了我们的测量目标,第3节描述了我们的测量方法,第4节给出了我们的初步结果,第5节得出了一些结论。

2. Motivation and Goals
2. 动机和目标

Practical IPv6 deployment plans benefit from accurate information about the extent to which IPv6 can be used for communication and how its characteristics differ from those of IPv4. For instance, operators planning to deploy dual-stack networking may wish to understand what fraction of their traffic would move to IPv6. This information is useful for estimating the capacity necessary to deal with the IPv6 traffic and the impacts to the operator's IPv4 infrastructure or carrier-grade NAT devices as their traffic is reduced. Network owners also wish to understand the extent to which they can expect different delay characteristics or problems with IPv6 connectivity. The goals of our measurements were to help with these topics by answering the following questions:

实用的IPv6部署计划受益于有关IPv6可用于通信的程度以及其特性与IPv4的特性有何不同的准确信息。例如,计划部署双栈网络的运营商可能希望了解他们的流量中有多少会转移到IPv6。此信息有助于估计处理IPv6流量所需的容量,以及流量减少时对运营商IPv4基础设施或运营商级NAT设备的影响。网络所有者还希望了解他们对IPv6连接的不同延迟特性或问题的期望程度。我们的测量目标是通过回答以下问题来帮助解决这些问题:

o What fraction of the most popular Internet sites offer AAAA records? How did World IPv6 Day change the situation?

o 最受欢迎的互联网站点中有多少提供AAAA记录?世界IPv6日是如何改变这种局面的?

o 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?

o 在提供AAAA记录的站点上,IPv4和IPv6的流量特征有何区别?连接故障率相似吗?往返时间(RTT)如何受到影响?

There have been many measurements about some of these aspects from a service provider perspective, such as Google studies about broken connectivity between Google and its end users. Our measurements start from a different angle, by assuming good dual-stack connectivity at the measurement end, and then probing the rest of the Internet to understand, for instance, how likely there are to be IPv6 connectivity problems or what the delay differences are between IPv4 and IPv6. Similar studies have been performed by the University of Pennsylvania and Comcast [IPv6Monitor] and RIPE NCC [RIPEv6Day].

从服务提供商的角度来看,已经有很多关于这些方面的测量,比如谷歌关于谷歌与其最终用户之间连接中断的研究。我们的测量从不同的角度开始,假设测量端具有良好的双栈连接,然后探测互联网的其余部分,以了解IPv6连接问题的可能性,或者IPv4和IPv6之间的延迟差异。宾夕法尼亚大学和康卡斯特(IPv6Malk)和成熟的NCC [RiVe6Day]已经进行了类似的研究。

3. Measurement Methodology
3. 测量方法

We used the top 10,000 sites of the Alexa 1 million most popular sites list [Alexa] from June 1, 2011. For each domain name in the list, we performed DNS queries with different host names. For IPv4 addresses (A records), we used host name "www" and also performed a query with just the domain name. For IPv6 addresses (AAAA records), we used different combinations of host names that have been used for IPv6 sites, namely, "www6", "ipv6", "v6", "ipv6.www", "www.ipv6", "v6.www", and "www.v6".

从2011年6月1日起,我们使用了Alexa 100万最受欢迎网站列表[Alexa]中的前10000个网站。对于列表中的每个域名,我们使用不同的主机名执行DNS查询。对于IPv4地址(A记录),我们使用主机名“www”,并仅使用域名执行查询。对于IPv6地址(AAAA记录),我们使用了IPv6站点使用的主机名的不同组合,即“www6”、“IPv6”、“v6”、“IPv6.www”、“www.IPv6”、“v6.www”和“www.v6”。

All DNS queries were initiated in the order listed above (first "www" and just the domain name for A records, then "www", domain name, and different IPv6-host names for AAAA records), but the queries were done in parallel (i.e., without waiting for the previous query to finish). The first response for A and AAAA records and the corresponding host names were recorded. The queries had a 3-second retransmission timeout, and if there was no response for 10 seconds, all remaining queries for the site were canceled. We used a custom Perl script and the Net::DNS [net-dns] module for the DNS queries.

所有DNS查询都是按照上面列出的顺序启动的(首先是“www”和A记录的域名,然后是“www”、域名和AAAA记录的不同IPv6主机名),但查询是并行完成的(即,不等待前一个查询完成)。记录A和AAAA记录的第一个响应以及相应的主机名。这些查询有3秒钟的重新传输超时,如果10秒钟内没有响应,则对站点的所有剩余查询都将被取消。我们使用一个定制的Perl脚本和Net::DNS[Net DNS]模块进行DNS查询。

The measurement script used a bind9 DNS server running on the same host as was performing the measurement. The DNS cache of the server was flushed before each measurement run in order to detect the changes in the DNS records in real time. The host, and thus the DNS server, was not part of DNS IPv6 whitelisting agreements. (See Section 4.3 of [RFC6589] for information on DNS resolver whitelisting.)

测量脚本使用与执行测量的主机相同的主机上运行的bind9 DNS服务器。在每次测量运行之前刷新服务器的DNS缓存,以便实时检测DNS记录中的更改。主机以及DNS服务器不是DNS IPv6白名单协议的一部分。(有关DNS解析器白名单的信息,请参见[RFC6589]第4.3节。)

The local network where the host performing the measurements was had native IPv6 (dual-stack) connectivity. The IPv6 connectivity to the local network was provided by an IPv6-over-IPv4 tunnel from the network's default router to the ISP's IPv6 peering point.

执行测量的主机所在的本地网络具有本机IPv6(双堆栈)连接。到本地网络的IPv6连接由IPv6-over-IPv4隧道提供,该隧道从网络的默认路由器到ISP的IPv6对等点。

After obtaining IP addresses for the site, if a site had both A and AAAA records, a simple C program was used to create TCP connections to port 80 (HTTP) simultaneously using both IPv4 and IPv6 to the (first) IP addresses discovered from the DNS. The connection setup was repeated up to 10 times, giving up after the first failed attempt (but only after normal TCP retransmissions). The connection setup delay was measured by recording the time immediately before and after the connect system call. The host used for measurements was a regular Linux PC with a 2.6.32 version kernel and a dual-stack Internet connection via Ethernet.

获取站点的IP地址后,如果站点同时具有a和AAAA记录,则使用简单的C程序创建到端口80(HTTP)的TCP连接,同时使用IPv4和IPv6到从DNS发现的(第一个)IP地址。连接设置最多重复10次,在第一次尝试失败后放弃(但仅在正常TCP重新传输后)。通过记录连接系统调用前后的时间来测量连接设置延迟。用于测量的主机是一台普通的Linux PC,具有2.6.32版本的内核和通过以太网的双栈Internet连接。

The measurements were 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 from two to two-and-a-half hours to complete.

测量在世界IPv6日前一周(6月1日,星期三,UTC 17:30)开始,每三小时运行一次,直到7月11日。一次测试运行需要两到两个半小时才能完成。

The accuracy and generality of the measurement results are limited by several factors. While we ran the tests at three different sites, most of the results discussed in this document present snapshots of the situation from just one measurement point, the Ericsson Research Finland premises, near Helsinki. Also, since one measurement run took quite 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 this selection might have resulted in selection of a non-optimal host; yet, a slight preference was given to the "www" and only-domain-name records since their queries were started before the others. While the host performing the measurements was otherwise idle, the local network was in regular office use during the measurements. The connectivity setup delay was collected in user space, with a regular, non-real-time kernel implementation, resulting in small inaccuracies in the timing information.

测量结果的准确性和通用性受到若干因素的限制。虽然我们在三个不同的地点进行了测试,但本文中讨论的大多数结果仅从赫尔辛基附近的爱立信芬兰研究所(Ericsson Research Finland premises)这一测量点呈现了情况的快照。此外,由于一次测量运行花费了相当长的时间,因此即使在一次运行期间,网络特征和DNS记录也可能发生变化。第一个DNS响应用于TCP连接测试,此选择可能导致选择非最佳主机;然而,由于他们的查询是在其他人之前开始的,所以只对“www”和域名记录有一点偏好。当执行测量的主机在其他方面处于空闲状态时,本地网络在测量期间处于正常的办公室使用状态。连接设置延迟是在用户空间中收集的,采用常规的非实时内核实现,导致定时信息的小误差。

4. Measurement Results
4. 测量结果
4.1. DNS AAAA Records
4.1. DNS AAAA记录

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 performed during World IPv6 Day are shown on the light gray background.

世界IPv6日之前、期间和之后拥有AAAA DNS记录的前10000个站点的数量如图1所示。世界IPv6日期间进行的测量显示在浅灰色背景上。

[See the PDF.]

[见PDF。]

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

图1:前10000个最受欢迎站点中具有AAAA DNS记录的站点数量

When the measurements began on June 1, 245 sites (2.45%) of the top 10,000 sites had both A and AAAA records. During the following days, the number of such sites slowly increased, reaching 306 sites in the measurement that was started at 22:30 UTC on June 7, the evening before World IPv6 Day. When World IPv6 Day officially started, the following measurement (at 01:30 UTC) recorded 383 sites, and the next one 472 sites. During the day, the number of sites with AAAA records peaked at 491 (4.91% of the measured 10,000 sites), at 19:30 UTC.

6月1日开始测量时,前10000个站点中有245个站点(2.45%)同时拥有A和AAAA记录。在随后的几天中,此类站点的数量缓慢增加,在6月7日UTC 22:30(世界IPv6日前一天晚上)开始的测量中,达到306个站点。当世界IPv6日正式开始时,以下测量(UTC时间01:30)记录了383个站点,下一个记录了472个站点。白天,有AAAA记录的站点数量在UTC 19:30达到峰值491个(占测量的10000个站点的4.91%)。

When World IPv6 Day was over, the number of AAAA records dropped nearly as fast as it had increased just 24 hours earlier. However, the number of sites stabilized at around 310 and did not drop below 300 after that, resulting in over 3% of the top 10,000 sites still having AAAA records at the end of our measurements, on July 11.

当世界IPv6日结束时,AAAA记录的下降速度几乎与24小时前的增长速度一样快。然而,站点数量稳定在310个左右,此后没有下降到300个以下,导致在7月11日我们的测量结束时,前10000个站点中仍有超过3%的站点保持AAAA记录。

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 that is commonly used when accessing a web site. 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). Also, the number of AAAA records for the "www" host name dropped steeply after the day and remained at around 160 sites after that.

在世界IPv6日的前一天,274个站点在其DNS中为某些测试主机名启用了IPv6,但只有116个站点为访问网站时常用的“www”主机名启用了IPv6。在世界IPv6日期间,拥有AAAA记录的“www”主机名数量增加了三倍多,连续3次测量(即至少6小时)达到374个站点。此外,“www”主机名的AAAA记录数量在当天之后急剧下降,此后保持在160个左右。

Similar but more pronounced trends can be seen if only the top 100 of the most popular sites are taken into considerations, as shown in Figure 2.

如图2所示,如果只考虑前100名最受欢迎的网站,可以看到类似但更明显的趋势。

[See the PDF.]

[见PDF。]

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

图2:前100个最受欢迎的站点中具有AAAA DNS记录的站点数量

Here, the number of sites with some of the tested host names having a AAAA record was initially 14; then, it jumped to 36 during the day and eventually dropped to 13. Also, while none of the top 100 sites apparently had a AAAA record for their "www" host name before and after World IPv6 day, during the day the number peaked at 30. Thus, roughly one third of the 100 most popular sites had IPv6 enabled for World IPv6 Day.

在这里,一些测试主机名具有AAAA记录的站点数量最初为14个;然后,白天它跳到36,最终下降到13。此外,尽管排名前100位的网站在世界IPv6日前后都没有“www”主机名的AAAA记录,但在这一天,这一数字达到了30个的峰值。因此,在100个最受欢迎的站点中,大约有三分之一的站点在世界IPv6日启用了IPv6。

Two other test sites in Sweden and Canada experienced similar trends with the DNS records. However, one of the sites used an external DNS server that was part of whitelisting agreements. There, the number of sites with AAAA records before World IPv6 Day was already higher (more than 400), and hence the impact of the day was smaller, because the amount of sites increased to the same numbers as seen by the test site in Finland. With the whitelisted DNS server, the number of sites remained above 450 after the day.

瑞典和加拿大的另外两个测试站点在DNS记录方面也经历了类似的趋势。但是,其中一个站点使用了作为白名单协议一部分的外部DNS服务器。在那里,在世界IPv6日之前拥有AAAA记录的站点数量已经较高(超过400个),因此这一天的影响较小,因为站点数量增加到与芬兰测试站点相同的数量。有了白名单上的DNS服务器,一天后站点的数量保持在450以上。

4.2. TCP Connection Setup
4.2. TCP连接设置

To test whether the IP addresses given by the DNS actually provide connectivity to the web site and whether there is any difference in the connection setup delay and failure rates with IPv4 and IPv6, we attempted to create TCP connections for all domains that contained

为了测试DNS提供的IP地址是否确实提供了到网站的连接,以及连接设置延迟和失败率是否与IPv4和IPv6有任何差异,我们尝试为包含的所有域创建TCP连接

both A and AAAA DNS records. The fraction of sites for which the first DNS response gave addresses that were not accessible with TCP to port 80 over IPv4 or IPv6 is shown in Figure 3.

A和AAAA DNS记录。图3显示了第一个DNS响应提供的地址无法通过IPv4或IPv6通过TCP访问端口80的站点部分。

[See the PDF.]

[见PDF。]

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

图3:TCP连接设置失败率(对于第一个DNS响应)

There was a baseline failure rate with IPv4 of around 1-3% that was fairly static throughout the test period. For hosts with AAAA records, the fraction of inaccessible sites was much higher: in the beginning, up to one fourth of the tested hosts did not respond to TCP connection attempts. Much of this was likely due to the various test sites with 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. Also, some of the hosts were not even supposed to be accessed with HTTP but provided AAAA records for other purposes, while some sites had clear configuration errors, such as localhost or link-local IPv6 addresses.

IPv4的基线故障率约为1-3%,在整个测试期间相当稳定。对于具有AAAA记录的主机,不可访问站点的比例要高得多:开始时,多达四分之一的测试主机对TCP连接尝试没有响应。这很可能是由于不同的测试站点具有不同的“IPv6前缀”(如第3节所述);在第一次运行中,超过一半具有AAAA记录的测试站点将其用于第一次DNS响应。此外,有些主机甚至不应该使用HTTP访问,而是提供AAAA记录用于其他目的,而有些站点存在明显的配置错误,例如本地主机或链接本地IPv6地址。

As World IPv6 Day came closer, the number of inaccessible IPv6 sites decreased slowly and the number of sites with AAAA records increased at the same time, resulting in the failure ratio dropping to roughly 20% before the day. During the day, the number of IPv6 sites increased rapidly, but also the number of failures decreased, and hence, at the end of the day, the failure ratio dropped to just above 10%. After World IPv6 Day, when many of the participating IPv6 hosts were taken off-line, the fraction of failed sites for IPv6 increased. However, since there was no increase in the absolute number of failed sites, the fraction of inaccessible sites remained at a lower level, between 15% and 20%, than before the day.

随着世界IPv6日的临近,无法访问的IPv6站点数量缓慢减少,同时拥有AAAA记录的站点数量增加,导致故障率在当天之前下降到大约20%。在一天中,IPv6站点的数量迅速增加,但故障的数量也减少了,因此,在一天结束时,故障率下降到略高于10%。在世界IPv6日之后,当许多参与的IPv6主机离线时,IPv6失败站点的比例增加了。然而,由于故障站点的绝对数量没有增加,因此无法访问站点的比例保持在较低的水平,比当天之前低15%到20%。

4.3. TCP Connection Delays
4.3. TCP连接延迟

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

对于同时使用IPv4和IPv6访问的站点,我们测量了使用IPv4和IPv6建立TCP连接之间的时间差。我们取所有10个连接的时间差的中位数(定义见[RFC2330]第11.3节),然后取所有站点的中位数和平均值(中位数)。结果如图4所示。

[See the PDF.]

[见PDF。]

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

图4:TCP连接设置延迟差异(IPv4-IPv6)

In general, the delay differences were small: the median of medians remained less than 3 ms off from zero (i.e., IPv4 and IPv6 delays were equal), and even the mean, which is more sensitive to outliers, remained within +/-5 ms most of the time, with the greatest spikes reaching to roughly -15 ms (i.e., the mean of median IPv6 delays was 15 ms larger than for IPv4 delays). Closer inspection of the results shows that the spikes were often caused by only one site or a handful of sites with bad connectivity and multiple retransmissions of TCP SYN and ACK packets, resulting in connection setup delays an order of magnitude larger than those for the other sites.

总的来说,延迟差异很小:中位数与零的距离保持在3毫秒以内(即IPv4和IPv6延迟相等),即使是对异常值更敏感的平均值,大部分时间都保持在+/-5毫秒以内,最大峰值达到大约-15毫秒(即,IPv6延迟中值的平均值比IPv4延迟的平均值大15毫秒)。仔细检查结果表明,峰值通常是由一个或几个连接不良的站点以及TCP SYN和ACK数据包的多次重传引起的,导致连接设置延迟比其他站点的延迟大一个数量级。

Surprisingly, the median delay for IPv6 connections was, in most cases, equal to or smaller than the IPv4 delay, but during World IPv6 Day, the IPv6 delays increased slightly and became (as a median) slower than their IPv4 counterparts. One reason for such an effect was that some of the sites that enabled IPv6 for World IPv6 Day had an extremely low IPv4 delay, less than 10 ms (e.g., due to the Content Delivery Network (CDN) provider hosting the IPv4 site), but a "regular" delay (over 100 ms) for the IPv6 host.

令人惊讶的是,在大多数情况下,IPv6连接的延迟中值等于或小于IPv4延迟,但在世界IPv6日期间,IPv6延迟略有增加,并且变得(作为中值)比IPv4延迟慢。产生这种影响的一个原因是,一些为世界IPv6日启用IPv6的站点具有极低的IPv4延迟,小于10毫秒(例如,由于承载IPv4站点的内容交付网络(CDN)提供商),但IPv6主机具有“常规”延迟(超过100毫秒)。

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

关于TCP连接设置延迟差异及其原因的更详细分析将留待以后的工作进行。

5. Conclusions
5. 结论

World IPv6 Day had a very visible impact on the availability of content over IPv6, particularly when considering the top 100 content providers. It is difficult to find other examples of bigger one-day swings in some characteristics of the Internet. However, the impact on end users was small, given that when dual-stack works correctly, it should not be visible at the user level, and given that IPv6 availability for end users themselves is small.

世界IPv6日对IPv6上的内容可用性产生了非常明显的影响,特别是在考虑前100名内容提供商时。很难在互联网的某些特征中找到其他更大的单日波动的例子。但是,考虑到双栈正常工作时,它在用户级别不应可见,并且考虑到最终用户本身的IPv6可用性很小,因此对最终用户的影响很小。

The key conclusions are as follows:

主要结论如下:

o On that day, there was a large jump in the number of content providers providing AAAA DNS records.

o 那天,提供AAAA DNS记录的内容提供商数量大幅增加。

o On that day, there was a smaller but apparently permanent increase in the number of content providers supporting AAAA.

o 在那一天,支持AAAA的内容提供商数量出现了较小但明显永久性的增长。

o Large and sudden swings in the relative amount of IPv4 vs. IPv6 traffic are possible merely by supporting a dual-stack access network and having a few large content providers offer their services either globally or to a particular network over IPv6.

o IPv4与IPv6流量的相对数量可能会突然大幅波动,只需支持双栈接入网络,并让少数大型内容提供商通过IPv6向全球或特定网络提供服务即可。

o 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 that which we've seen in our previous measurements, and we are still determining why that was the case. Measurement errors or problems on our side of the network cannot be ruled out at this stage. In any case, it is also clear that as new sites joined, incomplete or in-progress configurations create more connectivity problems in the IPv6 Internet than we've seen before. Other measurements are needed to verify what the general level of IPv6 connectivity is to addresses publicly listed in AAAA records.

o 在其域名下(无论是“www”、“www6”或其他名称)发布AAAA记录的站点中,有很大一部分实际上没有响应IPv6上的TCP-SYN请求。这个分数远远高于我们在之前的测量中看到的分数,我们仍在确定为什么会这样。在这一阶段,我们无法排除网络方面的测量误差或问题。在任何情况下,随着新站点的加入,不完整或正在进行的配置都会在IPv6 Internet上产生比我们以前看到的更多的连接问题。需要其他测量来验证IPv6连接到AAAA记录中公开列出的地址的一般级别。

o Even if the overall level of connection failures was high, activities on and around the IPv6 day appear to have caused a significant permanent drop in the number of these failures.

o 即使连接故障的总体水平很高,IPv6日当天及前后的活动似乎也导致了这些故障数量的显著永久性下降。

o When IPv6 and IPv4 connectivity were both available, their delay characteristics appeared 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, in general, low. In the remaining differences in our measurements, random packet loss played a major role. However, some sites could experience considerable differences simply because of different content distribution mechanisms used for IPv4 and IPv6 content.

o 当IPv6和IPv4连接都可用时,它们的延迟特性看起来非常相似。换句话说,提供IPv6连接的大多数提供商似乎都提供了高质量的生产网络。由于IPv4和IPv6连接之间的RTT差异,TCP连接设置延迟差异通常较低。在我们测量的其余差异中,随机数据包丢失起了主要作用。但是,一些站点可能会遇到相当大的差异,这仅仅是因为IPv4和IPv6内容使用了不同的内容分发机制。

It is promising that the amount of the most popular Internet content on IPv6 was surprisingly high, roughly one third of top 100 sites (during World IPv6 Day or with whitelisting enabled). However, other content on the Internet forms a long tail that is harder to move to IPv6. 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 form a very large part of overall Internet traffic [Labovitz], and thus even the top sites moving to IPv6 could represent a significant fraction of Internet traffic on IPv6. However, this requires that users be enabled to use IPv6 in their access networks. We believe that this should be the goal of future global IPv6 efforts.

IPv6上最受欢迎的互联网内容数量惊人地高,约占前100个网站的三分之一(在世界IPv6日期间或启用了白名单)。然而,互联网上的其他内容形成了一条长尾,很难转移到IPv6。例如,在世界IPv6日之前,10000个最受欢迎的网站中只有3%通过IPv6提供了内容。值得肯定的是,前100个站点构成了整个互联网流量的很大一部分[Labovitz],因此,即使是移动到IPv6的前100个站点也可能代表IPv6上互联网流量的很大一部分。但是,这要求用户能够在其接入网络中使用IPv6。我们相信这应该是未来全球IPv6努力的目标。

6. Security Considerations
6. 安全考虑

Security issues have not been discussed in this memo.

本备忘录中未讨论安全问题。

7. Informative References
7. 资料性引用

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.

[RFC2330]Paxson,V.,Almes,G.,Mahdavi,J.,和M.Mathis,“IP性能度量框架”,RFC 2330,1998年5月。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2460]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,RFC 2460,1998年12月。

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.

[RFC3056]Carpenter,B.和K.Moore,“通过IPv4云连接IPv6域”,RFC 3056,2001年2月。

[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.

[RFC6555]Wing,D.和A.Yourtchenko,“快乐眼球:双堆栈主机的成功”,RFC 6555,2012年4月。

[RFC6589] Livingood, J., "Considerations for Transitioning Content to IPv6", RFC 6589, April 2012.

[RFC6589]Livingood,J.,“将内容转换为IPv6的注意事项”,RFC 6589,2012年4月。

[net-dns] Fuhr, M., "Net::DNS", <http://www.net-dns.org/>.

[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/>.

[IPv6Meal]宾夕法尼亚大学和康卡斯特,“IPv6监测@宾夕法尼亚大学”,2012,<http://mnlab-ipv6.seas.upenn.edu/>.

[RIPEv6Day] RIPE NCC, "World IPv6 Day Measurements", <http://v6day.ripe.net/>.

[RIPEv6Day]成熟的NCC,“世界IPv6日测量”<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>.

[Alexa]Alexa网络信息公司,“Alexa Top 1000000网站”<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.

[Labovitz]Labovitz,C.,Iekel Johnson,S.,McPherson,D.,Oberheide,J.,和F.Jahanian,“互联网域间流量”,ACM SIGCOMM 2010年会议记录,2010年8月。

Appendix A. Acknowledgments
附录A.确认书

The authors would like to thank Suresh Krishnan, Fredrik Garneij, Lorenzo Colitti, Jason Livingood, Alain Durand, Emile Aben, Jan Melen, and Tero Kauppinen for interesting discussions in this problem space. Thanks also to Tom Petch and Bob Hinden for thorough reviews and many helpful comments.

作者要感谢Suresh Krishnan、Fredrik Garneij、Lorenzo Coletti、Jason Livingood、Alain Durand、Emile Aben、Jan Melen和Tero Kauppinen在这个问题空间进行了有趣的讨论。还要感谢Tom Petch和Bob Hinden的全面评论和许多有用的评论。

Authors' Addresses

作者地址

Ari Keranen Ericsson Jorvas 02420 Finland

Ari Keranen Ericsson Jorvas 02420芬兰

   EMail: ari.keranen@ericsson.com
        
   EMail: ari.keranen@ericsson.com
        

Jari Arkko Ericsson Jorvas 02420 Finland

雅丽爱立信芬兰公司02420

   EMail: jari.arkko@piuha.net
        
   EMail: jari.arkko@piuha.net