[要約] 要約：RFC 6948は、World IPv6 Dayにおけるエンドユーザーの視点からの測定結果を提供しています。 目的：このRFCの目的は、World IPv6 Dayの経験を通じて、IPv6の導入に関する洞察を提供し、インターネットのIPv6移行を促進することです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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日のWorld IPv6 Dayに参加しました。その日、以前はIPv4のみをサポートしていた多数のネットワークとサイトで、IPv6 [RFC2460]がデフォルトで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.
World IPv6 Dayイベントは一般の人々にはほとんど気づかれませんでした。これは大きな問題が検出されなかったことを意味するので、良いことです。既存の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はいくつかの結論を導き出します。
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レコードを提供していますか？ World IPv6 Dayはどのように状況を変えましたか？
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].
Googleとエンドユーザー間の接続の切断に関するGoogleの調査など、サービスプロバイダーの観点からこれらの側面のいくつかについて多くの測定が行われてきました。私たちの測定は別の角度から始まります。測定の終わりに適切なデュアルスタック接続を想定し、インターネットの残りの部分を調べて、たとえば、IPv6接続の問題が発生する可能性や遅延の違いを理解します。 IPv4およびIPv6。ペンシルベニア大学とコムキャスト[IPv6Monitor]とRIPE NCC [RIPEv6Day]でも同様の研究が行われています。
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]の上位10,000サイトを使用しました。リストの各ドメイン名に対して、異なるホスト名で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秒間応答がない場合、サイトの残りのクエリはすべてキャンセルされました。 DNSクエリには、カスタムPerlスクリプトとNet :: DNS [net-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接続は、ネットワークのデフォルトルーターからISPのIPv6ピアリングポイントへのIPv6-over-IPv4トンネルによって提供されました。
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。接続のセットアップは最大10回繰り返され、最初の試行が失敗した後（ただし、通常のTCP再送信後のみ）あきらめました。接続セットアップ遅延は、connectシステムコールの直前と直後の時間を記録することによって測定されました。測定に使用されたホストは、2.6.32バージョンのカーネルとイーサネット経由のデュアルスタックインターネット接続を備えた通常のLinux PCでした。
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.
測定は、World IPv6デーの1週間前（6月1日水曜日、17：30 UTC）に開始され、7月11日まで3時間ごとに1回実行されました。1回のテスト実行が完了するまで、2時間から2.5時間かかりました。
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.
測定結果の精度と一般性は、いくつかの要因によって制限されます。テストは3つの異なるサイトで実行しましたが、このドキュメントで説明する結果のほとんどは、ヘルシンキ近くのエリクソンリサーチフィンランドの敷地内の1つの測定ポイントからの状況のスナップショットを示しています。また、1回の測定実行には非常に長い時間がかかったため、1回の実行でもネットワーク特性とDNSレコードが変更された可能性があります。最初のDNS応答はTCP接続テストに使用されましたが、この選択により、最適でないホストが選択された可能性があります。しかし、クエリが他のレコードより先に開始されたため、「www」とドメイン名のみのレコードがわずかに優先されました。それ以外の場合、測定を実行するホストはアイドル状態でしたが、測定中はローカルネットワークが通常のオフィスで使用されていました。接続性セットアップの遅延はユーザー空間で収集され、定期的で非リアルタイムのカーネル実装が行われたため、タイミング情報がわずかに不正確になっていました。
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レコードを持つ上位10,000サイトの数を図1に示します。世界IPv6デー中に実行された測定は、薄い灰色の背景に表示されます。
[See the PDF.]
[PDFを参照してください。]
Figure 1: Number of sites with AAAA DNS records in the top 10,000 most popular sites
図1：最も人気のある上位10,000サイトに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日に測定が始まったとき、上位10,000サイトの245サイト（2.45％）にAとAAAAの両方のレコードがありました。次の日の間、そのようなサイトの数はゆっくりと増加し、World IPv6デーの前日の6月7日22:30 UTCに開始された測定では306サイトに達しました。 World IPv6 Dayが正式に開始されたとき、次の測定（UTC 01:30）では383サイト、次の測定では472サイトが記録されました。日中、AAAAレコードのあるサイトの数は491（測定された10,000サイトの4.91％）、19:30 UTCでピークに達しました。
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日の測定の終わりに、上位10,000サイトの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デーの1日前にテストされたホスト名の一部について、274のサイトのDNSでIPv6が有効になっていますが、Webサイトにアクセスするときに一般的に使用される「www」ホスト名のIPv6が有効になっているのは116のみでした。 AAAAレコードを含む「www」ホスト名の数は、World IPv6 Dayの間に3倍以上になり、3回の連続測定（つまり、少なくとも6時間）で374のサイトに到達しました。また、「www」ホスト名のAAAAレコードの数は1日後に急激に減少し、その後約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に落ちました。また、世界のIPv6の日前後に「www」ホスト名のAAAAレコードがあったトップ100サイトはありませんでしたが、日中の数はピークに達しました30.したがって、最も人気のある100のサイトの約3分の1は、World IPv6 Dayで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.
スウェーデンとカナダの他の2つのテストサイトでも、DNSレコードで同様の傾向が見られました。ただし、サイトの1つは、ホワイトリスト契約の一部である外部DNSサーバーを使用していました。そこでは、World IPv6 Dayの前にAAAAレコードがあったサイトの数がすでに多く（400以上）、そのため、フィンランドのテストサイトで見られたのと同じ数までサイトの数が増加したため、その日の影響は小さかった。ホワイトリストに登録されたDNSサーバーでは、サイトの数は1日後も450を超えたままでした。
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 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.
DNSによって指定されたIPアドレスが実際にWebサイトへの接続を提供するかどうか、およびIPv4とIPv6で接続セットアップの遅延と失敗率に違いがあるかどうかをテストするために、AとAAAA DNSレコード。最初のDNS応答がIPv4またはIPv6経由でポート80にTCPでアクセスできないアドレスを提供したサイトの割合を図3に示します。
[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レコードを持つホストの場合、アクセスできないサイトの割合ははるかに高くなりました。最初は、テストされたホストの最大4分の1がTCP接続の試行に応答しませんでした。これの多くは、（セクション3で説明したように）「IPv6プレフィックス」が異なるさまざまなテストサイトが原因であると考えられます。最初の実行では、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％と低いレベルにとどまっていました。
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以内にとどまりましたほとんどの場合ms、最大スパイクは約-15 msに達します（つまり、IPv6遅延の中央値の平均はIPv4遅延の平均よりも15 ms長くなりました）。結果を詳しく調べると、スパイクの原因は、接続が不良で、接続が確立されておらず、TCP SYNおよびACKパケットが複数回再送信されているため、他のサイトよりも1桁大きい遅延が発生したことがわかります。 。
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遅延以下でしたが、World IPv6 Dayの間、IPv6遅延はわずかに増加し、（中央値として）対応するIPv4遅延よりも遅くなりました。そのような影響の1つの理由は、World IPv6 Dayで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接続のセットアップ遅延の違いとその理由の詳細な分析は、今後の作業に残します。
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.
World IPv6 Dayは、特に上位100のコンテンツプロバイダーを検討する場合に、IPv6を介したコンテンツの可用性に非常に目に見える影響を与えました。インターネットのいくつかの特性において、より大きな1日の変動の他の例を見つけることは困難です。ただし、デュアルスタックが正しく機能する場合、ユーザーレベルでは表示されないはずであり、エンドユーザー自身の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インターネットで以前よりも多くの接続問題が発生することも明らかです。 AAAAレコードに公開されているアドレスに対するIPv6接続の一般的なレベルを確認するには、他の測定が必要です。
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サイトの約3分の1（World IPv6 Day中またはホワイトリストが有効になっている）であることは期待できます。ただし、インターネット上の他のコンテンツは、IPv6への移行が難しいロングテールを形成します。たとえば、World IPv6 Dayの前に最も人気のある10,000のWebサイトのうち、IPv6でコンテンツを提供したのはわずか3％でした。肯定的な点として、上位100サイトはインターネットトラフィック全体の非常に大きな部分を占めており[Labovitz]、IPv6に移行する上位サイトでもIPv6上のインターネットトラフィックのかなりの部分を占める可能性があります。ただし、これには、ユーザーがアクセスネットワークでIPv6を使用できるようにする必要があります。これが将来のグローバルIPv6の取り組みの目標であると信じています。
Security issues have not been discussed in this memo.
このメモではセキュリティの問題は議論されていません。
[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、「Framework for IP Performance Metrics」、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]カーペンター、B。およびK.ムーア、「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、「Happy Eyeballs：Success with Dual-Stack Hosts」、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/>.
[IPv6Monitor]ペンシルベニア大学およびコムキャスト、「IPv6 Monitoring @ Penn」、2012年、<http://mnlab-ipv6.seas.upenn.edu/>。
[RIPEv6Day] RIPE NCC, "World IPv6 Day Measurements", <http://v6day.ripe.net/>.
[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>.
[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.
[Labovitz] Labovitz、C.、Iekel-Johnson、S.、McPherson、D.、Oberheide、J。、およびF. Jahanian、「インターネットドメイン間トラフィック」、ACM SIGCOMM 2010、2010年8月の議事録。
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 Colitti、Jason Livingood、Alain Durand、Emile Aben、Jan Melen、Tero Kauppinenに感謝します。徹底的なレビューと多くの役立つコメントを提供してくれたTom PetchとBob Hindenにも感謝します。
Authors' Addresses
著者のアドレス
Ari Keranen Ericsson Jorvas 02420 Finland
あり けらねん えりｃっそん じょｒゔぁｓ ０２４２０ ふぃんぁんｄ
EMail: ari.keranen@ericsson.com
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net