[要約] 要約：RFC 7872は、実世界でIPv6拡張ヘッダーを持つパケットがドロップされる現象についての観察結果をまとめたものです。 目的：このRFCの目的は、IPv6拡張ヘッダーの使用に関する問題を特定し、ネットワークのパフォーマンスやセキュリティに影響を与える可能性のある問題を解決するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7872 SI6 Networks / UTN-FRH
Category: Informational J. Linkova
ISSN: 2070-1721 Google
T. Chown
Jisc
W. Liu
Huawei Technologies
June 2016
Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World
実世界でのIPv6拡張ヘッダーを持つパケットのドロップに関する観察
Abstract
概要
This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.
このドキュメントは、IPv6拡張ヘッダー（EH）を含むパケットがインターネットでドロップされた範囲（元々2014年8月に測定され、2015年6月に測定されたものと同様の結果）に関する実際のデータと、ネットワークのどこでこのようなドロップが発生するかを示しています。前述の結果は、IPv6 EHを伝送するIPv6パケットのフィルタリングに関する運用上のアドバイスをトリガーして、状況が時間とともに改善することが期待される問題ステートメントとして機能します。このドキュメントでは、コミュニティの他のメンバーが対応する測定値を再現し、IPv6 EHによるパケットの処理の変化を観察するために時間をかけて繰り返すことができるように、結果がどのように得られたかも説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7872.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7872で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Support of IPv6 Extension Headers in the Internet . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Normative References . . . . . . . . . . . . . . . . . . 6
4.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Reproducing Our Experiment . . . . . . . . . . . . . 8
A.1. Obtaining the List of Domain Names . . . . . . . . . . . 8
A.2. Obtaining AAAA Resource Records . . . . . . . . . . . . . 8
A.3. Filtering the IPv6 Address Datasets . . . . . . . . . . . 9
A.4. Performing Measurements with Each IPv6 Address Dataset . 9
A.5. Obtaining Statistics from Our Measurements . . . . . . . 10
Appendix B. Measurements Caveats . . . . . . . . . . . . . . . . 12
B.1. Isolating the Dropping Node . . . . . . . . . . . . . . . 12
B.2. Obtaining the Responsible Organization for the Packet
Drops . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. Troubleshooting Packet Drops Due to IPv6 Extension
Headers . . . . . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
IPv6 Extension Headers (EHs) allow for the extension of the IPv6 protocol and provide support for core functionality such as IPv6 fragmentation. While packets employing IPv6 EHs have been suspected to be dropped in some IPv6 deployments, there was not much concrete data on the topic. Some preliminary measurements have been presented in [PMTUD-Blackholes], [Gont-IEPG88], and [Gont-Chown-IEPG89], whereas [Linkova-Gont-IEPG90] presents more comprehensive results on which this document is based.
IPv6拡張ヘッダー（EH）は、IPv6プロトコルの拡張を可能にし、IPv6フラグメンテーションなどのコア機能のサポートを提供します。 IPv6 EHを使用するパケットは、一部のIPv6展開でドロップされる疑いがありますが、このトピックに関する具体的なデータはあまりありませんでした。 [PMTUD-Blackholes]、[Gont-IEPG88]、および[Gont-Chown-IEPG89]にいくつかの予備的な測定値が示されていますが、[Linkova-Gont-IEPG90]は、このドキュメントの基礎となるより包括的な結果を示しています。
This document presents real-world data regarding the extent to which packets containing IPv6 EHs are dropped in the Internet, as measured in August 2014 and later in June 2015 with similar results (pending operational advice in this area). The results presented in this document indicate that in the scenarios where the corresponding measurements were performed, the use of IPv6 EHs can lead to packet drops. We note that, in particular, packet drops occurring at transit networks are undesirable, and it is hoped and expected that this situation will improve over time.
このドキュメントは、IPv6 EHを含むパケットがインターネットでドロップされる範囲に関する実際のデータを示しています。2014年8月および2015年6月に測定され、同様の結果が得られています（この分野の運用に関するアドバイスは保留中）。このドキュメントに示されている結果は、対応する測定が実行されたシナリオでは、IPv6 EHの使用がパケットドロップにつながる可能性があることを示しています。特に、トランジットネットワークで発生するパケットドロップは望ましくなく、この状況が時間とともに改善することが期待され、期待されています。
This section summarizes the results obtained when measuring the support of IPv6 EHs on the path towards different types of public IPv6 servers. Two sources of information were employed for the list of public IPv6 servers: the "World IPv6 Launch" site <http://www.worldipv6launch.org> and Alexa's list of the Top 1-Million Web Sites <http://www.alexa.com>. For each list of domain names, the following datasets were obtained:
このセクションでは、さまざまなタイプのパブリックIPv6サーバーへのパス上のIPv6 EHのサポートを測定したときに得られた結果をまとめます。パブリックIPv6サーバーのリストには、「World IPv6 Launch」サイト<http://www.worldipv6launch.org>とAlexaのトップ100万Webサイトのリスト<http：// www。 alexa.com>。ドメイン名の各リストについて、次のデータセットが取得されました。
o Web servers (AAAA records of the aforementioned list)
o Webサーバー（前述のリストのAAAレコード）
o Mail servers (MX -> AAAA records of the aforementioned list)
o メールサーバー（MX->前述のリストのAAAAレコード）
o Name servers (NS -> AAAA records of the aforementioned list)
o ネームサーバー（NS->前述のリストのAAAAレコード）
Duplicate addresses and IPv6 addresses other than global unicast addresses were eliminated from each of those lists prior to obtaining the results included in this document. Additionally, addresses that were found to be unreachable were discarded from the dataset (please see Appendix B for further details).
このドキュメントに含まれる結果を取得する前に、グローバルユニキャストアドレス以外の重複アドレスおよびIPv6アドレスがこれらの各リストから削除されました。さらに、到達不能であることが判明したアドレスはデータセットから破棄されました（詳細については、付録Bを参照してください）。
For each of the aforementioned address sets, three different types of probes were employed:
前述の各アドレスセットに対して、3つの異なるタイプのプローブが使用されました。
o IPv6 packets with a Destination Options header of 8 bytes;
o 8バイトの宛先オプションヘッダーを持つIPv6パケット。
o IPv6 packets resulting in two IPv6 fragments of 512 bytes each (approximately); and
o それぞれ約512バイトの2つのIPv6フラグメントになるIPv6パケット。そして
o IPv6 packets with a Hop-by-Hop Options header of 8 bytes.
o 8バイトのホップバイホップオプションヘッダーを持つIPv6パケット。
In the case of packets with a Destination Options header and the case of packets with a Hop-by-Hop Options header, the desired EH size was achieved by means of PadN options [RFC2460]. The upper-layer protocol of the probe packets was, in all cases, TCP [RFC793] with the Destination Port set to the service port [IANA-PORT-NUMBERS] of the corresponding dataset. For example, the probe packets for all the measurements involving web servers were TCP segments with the Destination Port set to 80.
Destination Optionsヘッダーを持つパケットの場合、およびHop-by-Hop Optionsヘッダーを持つパケットの場合、PadNオプション[RFC2460]を使用して、目的のEHサイズを実現しました。プローブパケットの上位層プロトコルは、すべての場合において、対応するデータセットのサービスポート[IANA-PORT-NUMBERS]に設定された宛先ポートを持つTCP [RFC793]でした。たとえば、Webサーバーが関係するすべての測定のプローブパケットは、宛先ポートが80に設定されたTCPセグメントでした。
Besides obtaining the packet drop rate when employing the aforementioned IPv6 EHs, we tried to identify whether the Autonomous System (AS) dropping the packets was the same as the AS of the destination/target address. This is of particular interest since it essentially reveals whether the packet drops are under the control of the intended destination of the packets. Packets dropped by the destination AS are less of a concern since the device dropping the packets is under the control of the same organization as that to which the packets are destined (hence, it is probably easier to update the filtering policy if deemed necessary). On the other hand, packets dropped by transit ASes are more of a concern since they affect the deployability and usability of IPv6 EHs (including IPv6 fragmentation) by a third party (the destination AS). In any case, we note that it is impossible to tell whether, in those cases where IPv6 packets with EHs get dropped, the packet drops are the result of an explicit and intended policy or the result of improper device configuration defaults, buggy devices, etc. Thus, packet drops that occur at the destination AS might still prove to be problematic.
前述のIPv6 EHを使用した場合のパケットドロップ率の取得に加えて、パケットをドロップする自律システム（AS）が宛先/ターゲットアドレスのASと同じであるかどうかを確認しようとしました。これは、パケットドロップがパケットの目的の宛先の制御下にあるかどうかを本質的に明らかにするため、特に重要です。宛先ASによってドロップされたパケットは、パケットをドロップするデバイスがパケットの宛先と同じ組織の制御下にあるため、それほど心配する必要はありません（したがって、必要と思われる場合は、フィルタリングポリシーを更新する方がおそらく簡単です）。一方、トランジットASによってドロップされたパケットは、サードパーティ（宛先AS）によるIPv6 EH（IPv6フラグメンテーションを含む）の展開性と使いやすさに影響を与えるため、より懸念されます。いずれの場合も、EHを含むIPv6パケットがドロップされる場合に、パケットドロップが明示的で意図されたポリシーの結果なのか、不適切なデバイス構成のデフォルト、バグのあるデバイスなどの結果なのかを判断できないことに注意してくださいしたがって、宛先ASで発生するパケットドロップは、依然として問題があることが判明する場合があります。
Since there is some ambiguity when identifying the AS to which a specific router belongs (see Appendix B.2), each of our measurements results in two different values: one corresponding to the "best-case scenario" and one corresponding to the "worst-case scenario". The "best-case scenario" is that in which, when in doubt, the packets are assumed to be dropped by the destination AS, whereas the "worst-case scenario" is that in which, when in doubt, the packets are assumed to be dropped by a transit AS (please see Appendix B.2 for details). In the following tables, the values shown within parentheses represent the possibility that, when a packet is dropped, the packet drop occurs in an AS other than the destination AS (considering both the best-case scenario and the worst-case scenario).
特定のルーターが属しているASを特定する際にはあいまいさが存在するため（付録B.2を参照）、それぞれの測定結果は2つの異なる値になります。1つは「最良のシナリオ」に対応し、もう1つは「最悪のシナリオ」に対応します。 -ケースシナリオ」。 「ベストケースシナリオ」は、疑わしい場合にパケットが宛先ASによってドロップされると想定されるシナリオですが、「ワーストケースシナリオ」は、疑わしい場合にパケットがドロップされると想定されるシナリオです。トランジットASによってドロップされる（詳細については、付録B.2を参照してください）。次の表で、括弧内に示されている値は、パケットがドロップされたときに、パケットのドロップが宛先AS以外のASで発生する可能性を表しています（最良のシナリオと最悪のシナリオの両方を考慮）。
+----------+------------------+------------------+------------------+
| Dataset | DO8 | HBH8 | FH512 |
+----------+------------------+------------------+------------------+
| Web | 11.88% | 40.70% | 30.51% |
| servers | (17.60%/20.80%) | (31.43%/40.00%) | (5.08%/6.78%) |
+----------+------------------+------------------+------------------+
| Mail | 17.07% | 48.86% | 39.17% |
| servers | (6.35%/26.98%) | (40.50%/65.42%) | (2.91%/12.73%) |
+----------+------------------+------------------+------------------+
| Name | 15.37% | 43.25% | 38.55% |
| servers | (14.29%/33.46%) | (42.49%/72.07%) | (3.90%/13.96%) |
+----------+------------------+------------------+------------------+
Table 1: WIPv6LD Dataset: Packet Drop Rate for Different Destination Types, and Estimated (Best-Case / Worst-Case) Percentage of Packets That Were Dropped in a Different AS
表1：WIPv6LDデータセット：異なる宛先タイプのパケットドロップ率、および異なるASでドロップされたパケットの推定（ベストケース/ワーストケース）パーセンテージ
NOTE: In the tables above and below, "HBH8" stands for "packets with a Hop-By-Hop Options extension header of 8 bytes", "DO8" stands for "packets with a Destination Options extension header of 8 bytes", and "FH512" stands for "IPv6 packets with a Fragment Header of 512 bytes".
注：上の表と下の表で、「HBH8」は「ホップバイホップオプション拡張ヘッダーが8バイトのパケット」を表し、「DO8」は「宛先オプション拡張ヘッダーが8バイトのパケット」を表し、 「FH512」は「512バイトのフラグメントヘッダーを持つIPv6パケット」を表します。
NOTE: As an example, we note that the cell describing the support of IPv6 packets with DO8 for web servers (containing the value "11.88% (17.60%/20.80%)") should be read as: "when sending IPv6 packets with DO8 to public web servers, 11.88% of such packets get dropped. Among those packets that get dropped, 17.60%/20.80% (best case / worst case) of them get dropped at an AS other than the destination AS".
注：例として、Webサーバー用のDO8でのIPv6パケットのサポートを説明するセル（値「11.88％（17.60％/ 20.80％）」を含む）は、「DO8でIPv6パケットを送信する場合パブリックWebサーバーに対しては、そのようなパケットの11.88％がドロップされます。ドロップされたパケットのうち、17.60％/ 20.80％（ベストケース/ワーストケース）が宛先AS以外のASでドロップされます。
+----------+------------------+------------------+------------------+
| Dataset | DO8 | HBH8 | FH512 |
+----------+------------------+------------------+------------------+
| Web | 10.91% | 39.03% | 28.26% |
| servers | (46.52%/53.23%) | (36.90%/46.35%) | (53.64%/61.43%) |
+----------+------------------+------------------+------------------+
| Mail | 11.54% | 45.45% | 35.68% |
| servers | (2.41%/21.08%) | (41.27%/61.13%) | (3.15%/10.92%) |
+----------+------------------+------------------+------------------+
| Name | 21.33% | 54.12% | 55.23% |
| servers | (10.27%/56.80%) | (50.64%/81.00%) | (5.66%/32.23%) |
+----------+------------------+------------------+------------------+
Table 2: Alexa's Top 1M Sites Dataset: Packet Drop Rate for Different Destination Types, and Estimated (Best-Case / Worst-Case) Percentage of Packets That Were Dropped in a Different AS
表2：Alexaの上位1Mサイトデータセット：異なる宛先タイプのパケットドロップ率、および異なるASでドロップされたパケットの推定（ベストケース/ワーストケース）パーセンテージ
There are a number of observations to be made based on the results presented above. Firstly, while it has been generally assumed that it is IPv6 fragments that are dropped by operators, our results indicate that it is IPv6 EHs in general that result in packet drops. Secondly, our results indicate that a significant percentage of such packet drops occurs in transit ASes; that is, the packet drops are not under the control of the same organization as the final destination.
上記の結果に基づいて行うべき多くの観察があります。第1に、一般に、オペレーターによってドロップされるのはIPv6フラグメントであると想定されていましたが、パケットドロップが発生するのは、一般的にIPv6 EHであることがわかっています。第二に、私たちの結果は、そのようなパケットドロップのかなりの割合がトランジットASで発生することを示しています。つまり、パケットドロップは最終的な宛先と同じ組織の制御下にありません。
This document presents real-world data regarding the extent to which IPv6 packets employing EHs are dropped in the Internet. As such, this document does not introduce any new security issues.
このドキュメントでは、EHを使用するIPv6パケットがインターネットでドロップされる範囲に関する実際のデータを示します。そのため、このドキュメントでは、新しいセキュリティの問題は紹介されていません。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[Gont-Chown-IEPG89] Gont, F. and T. Chown, "A Small Update on the Use of IPv6 Extension Headers", IEPG meeting before IETF 89, March 2014, <http://www.iepg.org/2014-03-02-ietf89/ fgont-iepg-ietf89-eh-update.pdf>.
[Gont-Chown-IEPG89] Gont、F。およびT. Chown、「IPv6拡張ヘッダーの使用に関する小さな更新」、IETF 89の前のIEPGミーティング、2014年3月、<http://www.iepg.org/2014 -03-02-ietf89 / fgont-iepg-ietf89-eh-update.pdf>。
[Gont-IEPG88] Gont, F., "Fragmentation and Extension Header Support in the IPv6 Internet", IEPG meeting before IETF 88, November 2013, <http://www.iepg.org/2013-11-ietf88/ fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.
[Gont-IEPG88] Gont、F。、「IPv6インターネットでのフラグメンテーションと拡張ヘッダーのサポート」、IETF 88の前のIEPGミーティング、2013年11月、<http://www.iepg.org/2013-11-ietf88/ fgont- iepg-ietf88-ipv6-frag-and-eh.pdf>。
[IANA-PORT-NUMBERS] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.
[IANA-PORT-NUMBERS] IANA、「サービス名とトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/ service-names-port-numbers>。
[IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit v2.0 (Guille)", <http://www.si6networks.com/tools/ipv6toolkit>.
[IPv6-Toolkit] SI6 Networks、「SI6 Networks 'IPv6 Toolkit v2.0（Guille）」、<http://www.si6networks.com/tools/ipv6toolkit>。
[Linkova-Gont-IEPG90] Linkova, J. and F. Gont, "IPv6 Extension Headers in the Real World v2.0", IEPG Meeting before IETF 90, July 2014, <http://www.iepg.org/2014-07-20-ietf90/ iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>.
[Linkova-Gont-IEPG90] Linkova、J。およびF. Gont、「現実世界v2.0のIPv6拡張ヘッダー」、IETF 90の前のIEPGミーティング、2014年7月、<http://www.iepg.org/2014 -07-20-ietf90 / iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0.pdf>。
[PMTUD-Blackholes] De Boer, M. and J. Bosma, "Discovering Path MTU black holes on the Internet using RIPE Atlas", July 2012, <http://www.nlnetlabs.nl/downloads/publications/ pmtu-black-holes-msc-thesis.pdf>.
[PMTUD-Blackholes] De Boer、M。、およびJ. Bosma、「RIPE Atlasを使用したインターネット上のパスMTUブラックホールの発見」、2012年7月、<http://www.nlnetlabs.nl/downloads/publications/ pmtu-black -holes-msc-thesis.pdf>。
This section describes, step by step, how to reproduce the experiment with which we obtained the results presented in this document. Each subsection represents one step in the experiment. The tools employed for the experiment are traditional UNIX-like tools (such as gunzip) and the SI6 Networks' IPv6 Toolkit v2.0 (Guille) [IPv6-Toolkit].
このセクションでは、このドキュメントで提示された結果を得た実験を再現する方法を段階的に説明します。各サブセクションは、実験の1つのステップを表します。実験に使用されたツールは、従来のUNIXライクなツール（gunzipなど）とSI6 NetworksのIPv6 Toolkit v2.0（Guille）[IPv6-Toolkit]です。
Throughout this appendix, "#" denotes the command-line prompt for commands that require superuser privileges, whereas "$" denotes the prompt for commands that do not require superuser privileges.
この付録全体で、「＃」はスーパーユーザー権限を必要とするコマンドのコマンドラインプロンプトを示し、「$」はスーパーユーザー権限を必要としないコマンドのプロンプトを示します。
The primary data source employed was Alexa's Top 1M web sites,
available at: <http://s3.amazonaws.com/alexa-static/top-1m.csv.zip>.
The file is a zipped file containing the list of the most popular web
sites, in Comma-Separated Value (CSV) format. The aforementioned
file can be extracted with
$ gunzip < top-1m.csv.zip > top-1m.csv
$ gunzip <top-1m.csv.zip> top-1m.csv
A list of domain names (i.e., with other data stripped) can be obtained with the following command [IPv6-Toolkit]:
ドメイン名のリスト（つまり、他のデータが削除されたもの）は、次のコマンド[IPv6-Toolkit]で取得できます。
$ cat top-1m.csv | script6 get-alexa-domains > top-1m.txt
$ cat top-1m.csv | script6 get-alexa-domains> top-1m.txt
This command will create a "top-1m.txt" file containing one domain name per line.
このコマンドは、1行に1つのドメイン名を含む「top-1m.txt」ファイルを作成します。
NOTE: The domain names corresponding to the WIPv6LD dataset is available at <http://www.si6networks.com/datasets/wipv6day-domains.txt>. Since the corresponding file is a text file containing one domain name per line, the steps produced in this subsection need not be performed. The WIPv6LD dataset should be processed in the same way as the Alexa dataset, starting from Appendix A.2.
注：WIPv6LDデータセットに対応するドメイン名は、<http://www.si6networks.com/datasets/wipv6day-domains.txt>で入手できます。対応するファイルは1行に1つのドメイン名を含むテキストファイルであるため、このサブセクションで作成する手順を実行する必要はありません。 WIPv6LDデータセットは、付録A.2以降のAlexaデータセットと同じ方法で処理する必要があります。
The file obtained in the previous subsection contains a list of domain names that correspond to web sites. The AAAA records for such domain names can be obtained with:
前のサブセクションで取得したファイルには、Webサイトに対応するドメイン名のリストが含まれています。このようなドメイン名のAAAAレコードは、次のようにして取得できます。
$ cat top-1m.txt | script6 get-aaaa > top-1m-web-aaaa.txt The AAAA records corresponding to the mail servers of each of the aforementioned domain names can be obtained with:
$ cat top-1m.txt | script6 get-aaaa> top-1m-web-aaaa.txt前述の各ドメイン名のメールサーバーに対応するAAAAレコードは、次のようにして取得できます。
$ cat top-1m.txt | script6 get-mx | script6 get-aaaa > top-1m-mail-aaaa.txt
$ cat top-1m.txt | script6 get-mx | script6 get-aaaa> top-1m-mail-aaaa.txt
The AAAA records corresponding to the name servers of each of the aforementioned domain names can be obtained with:
前述の各ドメイン名のネームサーバーに対応するAAAAレコードは、次のようにして取得できます。
$ cat top-1m.txt | script6 get-ns | script6 get-aaaa > top-1m-dns-aaaa.txt
$ cat top-1m.txt | script6 get-ns | script6 get-aaaa> top-1m-dns-aaaa.txt
The lists of IPv6 addresses obtained in the previous step could possibly contain undesired addresses (e.g., non-global unicast addresses) and/or duplicate addresses. In order to remove both undesired and duplicate addresses, each of the three files from the previous section should be filtered accordingly:
前の手順で取得したIPv6アドレスのリストには、望ましくないアドレス（非グローバルユニキャストアドレスなど）や重複したアドレスが含まれている可能性があります。不要なアドレスと重複するアドレスの両方を削除するには、前のセクションの3つのファイルのそれぞれをそれに応じてフィルタリングする必要があります。
$ cat top-1m-web-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-web-aaaa-unique.txt
$ cat top-1m-mail-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-mail-aaaa-unique.txt
$ cat top-1m-dns-aaaa.txt | addr6 -i -q -B multicast -B unspec -k
global > top-1m-dns-aaaa-unique.txt
In order to measure DO8 with the list of web servers:
WebサーバーのリストでDO8を測定するには：
# cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80 > top-1m-web-aaaa-do8-m.txt
＃cat top-1m-web-aaaa-unique.txt | script6 trace6 do8 tcp 80> top-1m-web-aaaa-do8-m.txt
In order to measure HBH8 with the list of web servers:
WebサーバーのリストでHBH8を測定するには：
# cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80 > top-1m-web-aaaa-hbh8-m.txt
＃cat top-1m-web-aaaa-unique.txt | script6 trace6 hbh8 tcp 80> top-1m-web-aaaa-hbh8-m.txt
In order to measure FH512 with the list of web servers:
WebサーバーのリストでFH512を測定するには：
# cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80 > top-1m-web-aaaa-fh512-m.txt
＃cat top-1m-web-aaaa-unique.txt | script6 trace6 fh512 tcp 80> top-1m-web-aaaa-fh512-m.txt
In order to measure DO8 with the list of mail servers:
メールサーバーのリストを使用してDO8を測定するには：
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25 > top-1m-mail-aaaa-do8-m.txt
＃cat top-1m-mail-aaaa-unique.txt | script6 trace6 do8 tcp 25> top-1m-mail-aaaa-do8-m.txt
In order to measure HBH8 with the list of mail servers:
メールサーバーのリストを使用してHBH8を測定するには：
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25 > top-1m-mail-aaaa-hbh8-m.txt
＃cat top-1m-mail-aaaa-unique.txt | script6 trace6 hbh8 tcp 25> top-1m-mail-aaaa-hbh8-m.txt
In order to measure FH512 with the list of mail servers:
メールサーバーのリストでFH512を測定するには：
# cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25 > top-1m-mail-aaaa-fh512-m.txt
＃cat top-1m-mail-aaaa-unique.txt | script6 trace6 fh512 tcp 25> top-1m-mail-aaaa-fh512-m.txt
In order to measure DO8 with the list of name servers:
ネームサーバーのリストを使用してDO8を測定するには：
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53 > top-1m-dns-aaaa-do8-m.txt
＃cat top-1m-dns-aaaa-unique.txt | script6 trace6 do8 tcp 53> top-1m-dns-aaaa-do8-m.txt
In order to measure HBH8 with the list of name servers:
ネームサーバーのリストを使用してHBH8を測定するには：
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53 > top-1m-dns-aaaa-hbh8-m.txt
＃cat top-1m-dns-aaaa-unique.txt | script6 trace6 hbh8 tcp 53> top-1m-dns-aaaa-hbh8-m.txt
In order to measure FH512 with the list of name servers:
ネームサーバーのリストでFH512を測定するには：
# cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53 > top-1m-dns-aaaa-fh512-m.txt
＃cat top-1m-dns-aaaa-unique.txt | script6 trace6 fh512 tcp 53> top-1m-dns-aaaa-fh512-m.txt
In order to compute the statistics corresponding to our measurements of DO8 with the list of web servers:
Webサーバーのリストを使用してDO8の測定値に対応する統計を計算するには、次のようにします。
$ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m-web-aaaa-do8-stats.txt In order to compute the statistics corresponding to our measurements of HBH8 with the list of web servers:
$ cat top-1m-web-aaaa-do8-m.txt | script6 get-trace6-stats> top-1m-web-aaaa-do8-stats.txt Webサーバーのリストを使用してHBH8の測定に対応する統計を計算するには、次のようにします。
$ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m-web-aaaa-hbh8-stats.txt
$ cat top-1m-web-aaaa-hbh8-m.txt | script6 get-trace6-stats> top-1m-web-aaaa-hbh8-stats.txt
In order to compute the statistics corresponding to our measurements of FH512 with the list of web servers:
Webサーバーのリストを使用してFH512の測定に対応する統計を計算するには、次のようにします。
$ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats > top-1m-web-aaaa-fh512-stats.txt
$ cat top-1m-web-aaaa-fh512-m.txt | script6 get-trace6-stats> top-1m-web-aaaa-fh512-stats.txt
In order to compute the statistics corresponding to our measurements of DO8 with the list of mail servers:
メールサーバーのリストを使用してDO8の測定値に対応する統計を計算するには、次のようにします。
$ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m-mail-aaaa-do8-stats.txt
$ cat top-1m-mail-aaaa-do8-m.txt | script6 get-trace6-stats> top-1m-mail-aaaa-do8-stats.txt
In order to compute the statistics corresponding to our measurements of HBH8 with the list of mail servers:
メールサーバーのリストを使用してHBH8の測定値に対応する統計を計算するには、次のようにします。
$ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m-mail-aaaa-hbh8-stats.txt
$ cat top-1m-mail-aaaa-hbh8-m.txt | script6 get-trace6-stats> top-1m-mail-aaaa-hbh8-stats.txt
In order to compute the statistics corresponding to our measurements of FH512 with the list of mail servers:
メールサーバーのリストを使用してFH512の測定に対応する統計を計算するには、次のようにします。
$ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats > top-1m-mail-aaaa-fh512-stats.txt
$ cat top-1m-mail-aaaa-fh512-m.txt | script6 get-trace6-stats> top-1m-mail-aaaa-fh512-stats.txt
In order to compute the statistics corresponding to our measurements of DO8 with the list of name servers:
ネームサーバーのリストを使用してDO8の測定に対応する統計を計算するには、次のようにします。
$ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats > top-1m-dns-aaaa-do8-stats.txt
$ cat top-1m-dns-aaaa-do8-m.txt | script6 get-trace6-stats> top-1m-dns-aaaa-do8-stats.txt
In order to compute the statistics corresponding to our measurements of HBH8 with the list of mail servers:
メールサーバーのリストを使用してHBH8の測定値に対応する統計を計算するには、次のようにします。
$ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats > top-1m-dns-aaaa-hbh8-stats.txt In order to compute the statistics corresponding to our measurements of FH512 with the list of mail servers:
$ cat top-1m-dns-aaaa-hbh8-m.txt | script6 get-trace6-stats> top-1m-dns-aaaa-hbh8-stats.txtメールサーバーのリストを使用してFH512の測定に対応する統計を計算するには、次のようにします。
$ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats > top-1m-dns-aaaa-fh512-stats.txt
$ cat top-1m-dns-aaaa-fh512-m.txt | script6 get-trace6-stats> top-1m-dns-aaaa-fh512-stats.txt
A number of issues have needed some consideration when producing the results presented in this document. These same issues should be considered when troubleshooting connectivity problems resulting from the use of IPv6 EHs.
このドキュメントに示されている結果を生成する際には、いくつかの問題を考慮する必要があります。 IPv6 EHの使用に起因する接続の問題のトラブルシューティングを行うときは、これらと同じ問題を考慮する必要があります。
Let us assume that we find that IPv6 packets with EHs are being dropped on their way to the destination system 2001:db8:d::1 and that the output of running traceroute towards such destination is:
EHを含むIPv6パケットが宛先システム2001：db8：d :: 1に向かう途中でドロップされ、そのような宛先に向けてtracerouteを実行した場合の出力が次のようになっていると仮定します。
1. 2001:db8:1:1000::1
2. 2001:db8:2:4000::1
3. 2001:db8:3:4000::1
4. 2001:db8:3:1000::1
5. 2001:db8:4:4000::1
6. 2001:db8:4:1000::1
7. 2001:db8:5:5000::1
8. 2001:db8:5:6000::1
9. 2001:db8:d::1
Additionally, let us assume that the output of EH-enabled traceroute to the same destination is:
さらに、同じ宛先へのEH対応tracerouteの出力が次のようであると仮定します。
1. 2001:db8:1:1000::1
2. 2001:db8:2:4000::1
3. 2001:db8:3:4000::1
4. 2001:db8:3:1000::1
5. 2001:db8:4:4000::1
For the sake of brevity, let us refer to the last-responding node in the EH-enabled traceroute ("2001:db8:4:4000::1" in this case) as "M". Assuming that packets in both traceroutes employ the same path, we'll refer to "the node following the last responding node in the EH-enabled traceroute" ("2001:db8:4:1000::1" in our case), as "M+1", etc.
簡潔にするために、EH対応のtracerouteで最後に応答したノード（この場合は "2001：db8：4：4000 :: 1"）を "M"と呼びます。両方のtracerouteのパケットが同じパスを使用していると仮定すると、「EH対応tracerouteで最後に応答したノードに続くノード」（ここでは「2001：db8：4：1000 :: 1」）を参照します。 「M + 1」など
Based on traceroute information above, which node is the one actually dropping the EH-enabled packets will depend on whether the dropping node filters packets before making the forwarding decision or after making the forwarding decision. If the former, the dropping node will be M+1. If the latter, the dropping node will be "M".
上記のtraceroute情報に基づいて、どのノードが実際にEH対応パケットをドロップするかは、ドロップするノードがパケットをフィルタリングする前に、転送の決定を行うか、転送の決定を行った後かによって異なります。前者の場合、ドロップするノードはM + 1になります。後者の場合、ドロップするノードは「M」になります。
Throughout this document (and our measurements), we assume that those nodes dropping packets that carry IPv6 EHs apply their filtering policy, and only then, if necessary, forward the packets. Thus, in our example above, the last responding node to the EH-enabled traceroute ("M") is "2001:db8:4:4000::1", and we assume the dropping node to be "2001:db8:4:1000::1" ("M+1").
このドキュメント（および測定）全体で、IPv6 EHを伝送するパケットをドロップするノードはフィルタリングポリシーを適用し、必要な場合にのみパケットを転送すると想定しています。したがって、上記の例では、EH対応のtraceroute（ "M"）に応答する最後のノードは "2001：db8：4：4000 :: 1"であり、ドロップするノードは "2001：db8：4"であると想定しています。 ：1000 :: 1 "（" M + 1 "）。
Additionally, we note that when isolating the dropping node we assume that both the EH-enabled and the EH-free traceroutes result in the same paths. However, this might not be the case.
さらに、ドロップするノードを分離するとき、EHが有効なtracerouteとEHが無効なtracerouteの両方が同じパスになると想定していることに注意してください。ただし、これは当てはまらない場合があります。
In order to identify the organization operating the dropping node, one would be tempted to lookup the Autonomous System Numbers (ASNs) corresponding to the dropping node. However, assuming that M and M+1 are two peering routers, any of these two organizations could be providing the address space employed for such peering. Or, in the case of an Internet Exchange Point (IXP), the address space could correspond to the IXP AS rather than to any of the participating ASes. Thus, the organization operating the dropping node (M+1) could be the AS for M+1, but it might as well be the AS for M+2. Only when the ASN for M+1 is the same as the ASN for M+2 do we have certainty about who the responsible organization for the packet drops is (see slides 21-23 of [Linkova-Gont-IEPG90]).
ドロップするノードを運用している組織を特定するために、ドロップするノードに対応する自律システム番号（ASN）を検索したくなるでしょう。ただし、MとM + 1が2つのピアリングルーターであると仮定すると、これら2つの組織のいずれかが、そのようなピアリングに使用されるアドレススペースを提供している可能性があります。または、インターネット交換ポイント（IXP）の場合、アドレススペースは、参加しているASではなくIXP ASに対応する可能性があります。したがって、ドロップするノード（M + 1）を運用している組織は、M + 1のASになることもありますが、M + 2のASになることもあります。 M + 1のASNがM + 2のASNと同じである場合にのみ、パケットドロップの責任組織が誰であるかが確実になります（[Linkova-Gont-IEPG90]のスライド21〜23を参照）。
In the measurement results presented in Section 2, the aforementioned ambiguity results in a "best-case" and a "worst-case" scenario (rather than a single value): the lowest percentage value means that, when in doubt, we assume the packet drops occur in the same AS as the destination; on the other hand, the highest percentage value means that, when in doubt, we assume the packet drops occur at a different AS than the destination AS.
セクション2に示した測定結果では、前述のあいまいさにより「単一の値ではなく」「最良のケース」と「最悪のケース」のシナリオが生じます。最も低いパーセント値は、疑わしい場合、パケットドロップは宛先と同じASで発生します。一方、最も高いパーセンテージ値は、疑わしい場合、パケットドロップが宛先ASとは異なるASで発生すると想定することを意味します。
We note that the aforementioned ambiguity should also be considered when troubleshooting and reporting IPv6 packet drops since identifying the organization responsible for the packet drops might prove to be a non-trivial task.
パケットドロップの原因となっている組織を特定することは簡単な作業ではないことが判明する可能性があるため、IPv6パケットドロップのトラブルシューティングとレポートを行う場合は、前述のあいまいさも考慮する必要があることに注意してください。
Finally, we note that a specific organization might be operating more than one AS. However, our measurements assume that different ASNs imply different organizations.
最後に、特定の組織が複数のASを運用している可能性があることに注意してください。ただし、私たちの測定では、ASNが異なると組織も異なることを意味していると想定しています。
Isolating IPv6 blackholes essentially involves performing IPv6 traceroute for a destination system with and without IPv6 EHs. The EH-free traceroute would provide the full working path towards a destination while the EH-enabled traceroute would provide the address of the last-responding node for EH-enabled packets (say, "M"). In principle, one could isolate the dropping node by looking-up "M" in the EH-free traceroute with the dropping node being "M+1" (see Appendix B.1 for caveats).
IPv6ブラックホールの分離には、本質的に、IPv6 EHがある場合とない場合の宛先システムに対してIPv6 tracerouteを実行することが含まれます。 EHフリーtracerouteは宛先への完全な現用パスを提供し、EH対応tracerouteはEH対応パケット（たとえば、「M」）の最後に応答したノードのアドレスを提供します。原則として、EHフリーのtracerouteで「M」を検索してドロップノードを分離できます。ドロップノードは「M + 1」です（注意事項については、付録B.1を参照）。
At the time of this writing, most traceroute implementations do not support IPv6 EHs. However, the path6 tool of [IPv6-Toolkit] provides such support. Additionally, the blackhole6 tool of [IPv6-Toolkit] automates the troubleshooting process and can readily provide information such as: dropping node's IPv6 address, dropping node's AS, etc.
この記事の執筆時点では、ほとんどのtraceroute実装はIPv6 EHをサポートしていません。ただし、[IPv6-Toolkit]のpath6ツールはそのようなサポートを提供します。さらに、[IPv6-Toolkit]のブラックホール6ツールはトラブルシューティングプロセスを自動化し、ノードのIPv6アドレスの削除、ノードのASの削除などの情報を簡単に提供できます。
Acknowledgements
謝辞
The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Mark Andrews, Fred Baker, Brian Carpenter, Gert Doering, C. M. Heard, Nick Hilliard, Joel Jaeggli, Tatuya Jinmei, Merike Kaeo, Warren Kumari, Ted Lemon, Mark Smith, Ole Troan, and Eric Vyncke for providing valuable comments on draft versions of this document. Additionally, the authors would like to thank participants of the V6OPS and OPSEC working groups for their valuable input on the topics discussed in this document.
著者は（アルファベット順で）ミカエルアブラハムソン、マークアンドリュース、フレッドベイカー、ブライアンカーペンター、ガートドエリング、CMハード、ニックヒリアード、ジョエルジャグリ、タトゥヤジンメイ、メリケケオ、ウォーレンクマリ、テッドレモン、マークスミスに感謝します。このドキュメントのドラフトバージョンに関する貴重なコメントを提供してくれたOle TroanとEric Vyncke。さらに、作成者は、このドキュメントで説明されているトピックに関する貴重な情報を提供してくれたV6OPSおよびOPSECワーキンググループの参加者に感謝します。
The authors would like to thank Fred Baker for his guidance in improving this document.
著者は、このドキュメントの改善に関するガイダンスを提供してくれたFred Bakerに感謝します。
Fernando Gont would like to thank Jan Zorz of Go6 Lab <http://go6lab.si/> and Jared Mauch of NTT America for providing access to systems and networks that were employed to produce some of the measurement results presented in this document. Additionally, he would like to thank SixXS <https://www.sixxs.net> for providing IPv6 connectivity.
フェルナンドゴントは、Go6 Lab <http://go6lab.si/>のJan Zorzと、NTT AmericaのJared Mauchに、このドキュメントに示されている測定結果の一部を生成するために採用されたシステムとネットワークへのアクセスを提供してくれたことに感謝します。さらに、IPv6接続を提供してくれたSixXS <https://www.sixxs.net>に感謝します。
Fernando Gont would like to thank Nelida Garcia and Guillermo Gont for their love and support.
フェルナンドゴントは、ネリダガルシアとギジェルモゴントの愛とサポートに感謝します。
Authors' Addresses
著者のアドレス
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
J. Linkova Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
J. Linkova Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: furry@google.com
Tim Chown Jisc Lumen House, Library Avenue Harwell Oxford, Didcot OX11 0SG United Kingdom
Tim Chown Jisc Lumen House、Library Avenue Harwell Oxford、Didcot OX11 0SGイギリス
Email: tim.chown@jisc.ac.uk
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
will（Shu成）l IU hu Aはテクノロジー禁止の日であり、長いだけの地区は非常に現実的です518129中国
Email: liushucheng@huawei.com