[要約] RFC 8219は、IPv6移行技術のベンチマーク方法論に関するものであり、IPv6移行技術の性能評価を目的としています。
Internet Engineering Task Force (IETF) M. Georgescu
Request for Comments: 8219 L. Pislaru
Category: Informational RCS&RDS
ISSN: 2070-1721 G. Lencse
Szechenyi Istvan University
August 2017
Benchmarking Methodology for IPv6 Transition Technologies
IPv6移行テクノロジのベンチマーク手法
Abstract
概要
Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability.
IPv4またはIPv6対応のネットワーク相互接続デバイスのパフォーマンスに対処するベンチマーク手法は存在しますが、IPv6移行テクノロジーはその範囲外です。このドキュメントは、IPv6移行テクノロジのパフォーマンスを評価するための補足的なガイドラインを提供します。具体的には、RFC 2544および5180の推奨事項を使用してデュアルスタックノードをテストできるため、このドキュメントはカプセル化または変換メカニズムを採用するIPv6移行テクノロジーを対象としています。
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/rfc8219.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8219で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 ....................................................4
1.1. IPv6 Transition Technologies ...............................4
2. Conventions Used in This Document ...............................6
3. Terminology .....................................................7
4. Test Setup ......................................................7
4.1. Single-Translation Transition Technologies .................8
4.2. Encapsulation and Double-Translation Transition
Technologies ...............................................8
5. Test Traffic ....................................................9
5.1. Frame Formats and Sizes ....................................9
5.1.1. Frame Sizes to Be Used over Ethernet ...............10
5.2. Protocol Addresses ........................................10
5.3. Traffic Setup .............................................10
6. Modifiers ......................................................11
7. Benchmarking Tests .............................................11
7.1. Throughput ................................................11
7.2. Latency ...................................................11
7.3. Packet Delay Variation ....................................13
7.3.1. PDV ................................................13
7.3.2. IPDV ...............................................14
7.4. Frame Loss Rate ...........................................15
7.5. Back-to-Back Frames .......................................15
7.6. System Recovery ...........................................15
7.7. Reset .....................................................15
8. Additional Benchmarking Tests for Stateful IPv6 Transition
Technologies ...................................................15
8.1. Concurrent TCP Connection Capacity ........................15
8.2. Maximum TCP Connection Establishment Rate .................15
9. DNS Resolution Performance .....................................15
9.1. Test and Traffic Setup ....................................16
9.2. Benchmarking DNS Resolution Performance ...................17
9.2.1. Requirements for the Tester ........................18
10. Overload Scalability ..........................................19
10.1. Test Setup ...............................................19
10.1.1. Single-Translation Transition Technologies ........19
10.1.2. Encapsulation and Double-Translation
Transition Technologies ...........................20
10.2. Benchmarking Performance Degradation .....................21
10.2.1. Network Performance Degradation with
Simultaneous Load .................................21
10.2.2. Network Performance Degradation with
Incremental Load ..................................22
11. NAT44 and NAT66 ...............................................22
12. Summarizing Function and Variation ............................23
13. Security Considerations .......................................23
14. IANA Considerations ...........................................24
15. References ....................................................24
15.1. Normative References .....................................24
15.2. Informative References ...................................25
Appendix A. Theoretical Maximum Frame Rates........................29
Acknowledgements...................................................30
Authors' Addresses ................................................30
The methodologies described in [RFC2544] and [RFC5180] help vendors and network operators alike analyze the performance of IPv4 and IPv6-capable network devices. The methodology presented in [RFC2544] is mostly IP version independent, while [RFC5180] contains complementary recommendations that are specific to the latest IP version, IPv6. However, [RFC5180] does not cover IPv6 transition technologies.
[RFC2544]と[RFC5180]で説明されている方法論は、ベンダーとネットワークオペレーターがIPv4およびIPv6対応のネットワークデバイスのパフォーマンスを分析するのに役立ちます。 [RFC2544]で提示されている方法は、ほとんどIPバージョンに依存しませんが、[RFC5180]には、最新のIPバージョンであるIPv6に固有の補足的な推奨事項が含まれています。ただし、[RFC5180]はIPv6移行テクノロジーをカバーしていません。
IPv6 is not backwards compatible, which means that IPv4-only nodes cannot directly communicate with IPv6-only nodes. To solve this issue, IPv6 transition technologies have been proposed and implemented.
IPv6には下位互換性がないため、IPv4のみのノードはIPv6のみのノードと直接通信できません。この問題を解決するために、IPv6移行テクノロジが提案および実装されています。
This document presents benchmarking guidelines dedicated to IPv6 transition technologies. The benchmarking tests can provide insights about the performance of these technologies, which can act as useful feedback for developers and network operators going through the IPv6 transition process.
このドキュメントでは、IPv6移行テクノロジ専用のベンチマークガイドラインを示します。ベンチマークテストは、これらのテクノロジーのパフォーマンスに関する洞察を提供することができます。これは、IPv6移行プロセスを通過する開発者およびネットワークオペレーターに役立つフィードバックとして機能します。
The document also includes an approach to quantify performance when operating in overload. Overload scalability can be defined as a system's ability to gracefully accommodate a greater number of flows than the maximum number of flows that the Device Under Test (DUT) can operate normally. The approach taken here is to quantify the overload scalability by measuring the performance created by an excessive number of network flows and comparing performance to the non-overloaded case.
このドキュメントには、過負荷で動作しているときのパフォーマンスを定量化する方法も含まれています。過負荷スケーラビリティは、テスト対象デバイス（DUT）が正常に動作できるフローの最大数よりも多くのフローに適切に対応するシステムの能力として定義できます。ここで採用するアプローチは、過剰な数のネットワークフローによって作成されたパフォーマンスを測定し、パフォーマンスを非過負荷の場合と比較することにより、過負荷のスケーラビリティを定量化することです。
Two of the basic transition technologies, dual IP layer (also known as dual stack) and encapsulation, are presented in [RFC4213]. IPv4/IPv6 translation is presented in [RFC6144]. Most of the transition technologies employ at least one variation of these mechanisms. In this context, a generic classification of the transition technologies can prove useful.
[RFC4213]には、デュアルIPレイヤー（デュアルスタックとも呼ばれる）とカプセル化という2つの基本的な移行技術が示されています。 IPv4 / IPv6変換は[RFC6144]で提示されます。ほとんどの移行テクノロジーは、これらのメカニズムの少なくとも1つのバリエーションを採用しています。このコンテキストでは、移行テクノロジの一般的な分類が有用であることがわかります。
We can consider a production network transitioning to IPv6 as being constructed using the following IP domains:
IPv6に移行する本番ネットワークは、次のIPドメインを使用して構築されていると見なすことができます。
o Domain A: IPvX-specific domain
o ドメインA：IPvX固有のドメイン
o Core domain: IPvY-specific or dual-stack (IPvX and IPvY) domain
o コアドメイン：IPvY固有またはデュアルスタック（IPvXおよびIPvY）ドメイン
o Domain B: IPvX-specific domain
o ドメインB：IPvX固有のドメイン
Note: X,Y are part of the set {4,6}, and X is NOT EQUAL to Y.
注：X、Yはセット{4、6}の一部であり、XはYと等しくありません。
The transition technologies can be categorized according to the technology used for traversal of the core domain:
移行テクノロジは、コアドメインの走査に使用されるテクノロジに従って分類できます。
1. Dual stack: Devices in the core domain implement both IP protocols.
1. デュアルスタック：コアドメインのデバイスは、両方のIPプロトコルを実装します。
2. Single translation: In this case, the production network is assumed to have only two domains: Domain A and the core domain. The core domain is assumed to be IPvY specific. IPvX packets are translated to IPvY at the edge between Domain A and the core domain.
2. 単一の翻訳：この場合、実稼働ネットワークには、ドメインAとコアドメインの2つのドメインしかないと想定されています。コアドメインはIPvY固有であると想定されます。 IPvXパケットは、ドメインAとコアドメイン間のエッジでIPvYに変換されます。
3. Double translation: The production network is assumed to have all three domains; Domains A and B are IPvX specific, while the core domain is IPvY specific. A translation mechanism is employed for the traversal of the core network. The IPvX packets are translated to IPvY packets at the edge between Domain A and the core domain. Subsequently, the IPvY packets are translated back to IPvX at the edge between the core domain and Domain B.
3. 二重変換：本番ネットワークには3つのドメインすべてがあると想定されています。ドメインAおよびBはIPvX固有であり、コアドメインはIPvY固有です。コアネットワークのトラバースには、変換メカニズムが使用されます。 IPvXパケットは、ドメインAとコアドメイン間のエッジでIPvYパケットに変換されます。その後、IPvYパケットは、コアドメインとドメインBの間のエッジでIPvXに変換されます。
4. Encapsulation: The production network is assumed to have all three domains; Domains A and B are IPvX specific, while the core domain is IPvY specific. An encapsulation mechanism is used to traverse the core domain. The IPvX packets are encapsulated to IPvY packets at the edge between Domain A and the core domain. Subsequently, the IPvY packets are de-encapsulated at the edge between the core domain and Domain B.
4. カプセル化：本番ネットワークには3つのドメインすべてがあると想定されています。ドメインAおよびBはIPvX固有であり、コアドメインはIPvY固有です。カプセル化メカニズムは、コアドメインを通過するために使用されます。 IPvXパケットは、ドメインAとコアドメイン間のエッジでIPvYパケットにカプセル化されます。その後、IPvYパケットはコアドメインとドメインBの間のエッジでカプセル化が解除されます。
The performance of dual-stack transition technologies can be fully evaluated using the benchmarking methodologies presented by [RFC2544] and [RFC5180]. Consequently, this document focuses on the other three categories: single-translation, double-translation, and encapsulation transition technologies.
デュアルスタック移行テクノロジーのパフォーマンスは、[RFC2544]と[RFC5180]によって提示されたベンチマーク手法を使用して完全に評価できます。したがって、このドキュメントでは、他の3つのカテゴリ、つまり単一翻訳、二重翻訳、カプセル化移行テクノロジに焦点を当てています。
Another important aspect by which IPv6 transition technologies can be categorized is their use of stateful or stateless mapping algorithms. The technologies that use stateful mapping algorithms (e.g., Stateful NAT64 [RFC6146]) create dynamic correlations between IP addresses or {IP address, transport protocol, transport port number} tuples, which are stored in a state table. For ease of reference, IPv6 transition technologies that employ stateful mapping algorithms will be called "stateful IPv6 transition technologies". The efficiency with which the state table is managed can be an important performance indicator for these technologies. Hence, additional benchmarking tests are RECOMMENDED for stateful IPv6 transition technologies.
IPv6移行テクノロジを分類できるもう1つの重要な側面は、ステートフルまたはステートレスマッピングアルゴリズムの使用です。ステートフルマッピングアルゴリズム（ステートフルNAT64 [RFC6146]など）を使用するテクノロジーは、IPアドレスまたは{IPアドレス、トランスポートプロトコル、トランスポートポート番号}タプル間の動的相関を作成し、これらはタプルテーブルに格納されます。参照しやすいように、ステートフルマッピングアルゴリズムを使用するIPv6移行テクノロジは、「ステートフルIPv6移行テクノロジ」と呼ばれます。状態テーブルの管理効率は、これらのテクノロジーの重要なパフォーマンス指標になる場合があります。したがって、ステートフルIPv6移行テクノロジには、追加のベンチマークテストをお勧めします。
Table 1 contains the generic categories and associations with some of the IPv6 transition technologies proposed in the IETF. Please note that the list is not exhaustive.
表1は、IETFで提案されているIPv6移行テクノロジのいくつかとの一般的なカテゴリおよび関連を示しています。リストは完全なものではないことに注意してください。
+---+--------------------+------------------------------------+
| | Generic category | IPv6 Transition Technology |
+---+--------------------+------------------------------------+
| 1 | Dual stack | Dual IP Layer Operations [RFC4213] |
+---+--------------------+------------------------------------+
| 2 | Single translation | NAT64 [RFC6146], IVI [RFC6219] |
+---+--------------------+------------------------------------+
| 3 | Double translation | 464XLAT [RFC6877], MAP-T [RFC7599] |
+---+--------------------+------------------------------------+
| 4 | Encapsulation | DS-Lite [RFC6333], MAP-E [RFC7597],|
| | | Lightweight 4over6 [RFC7596], |
| | | 6rd [RFC5569], 6PE [RFC4798], |
| | | 6VPE [RFC4659] |
+---+--------------------+------------------------------------+
Table 1: IPv6 Transition Technologies Categories
表1：IPv6移行テクノロジのカテゴリ
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Although these terms are usually associated with protocol requirements, in this document, the terms are requirements for users and systems that intend to implement the test conditions and claim conformance with this specification.
これらの用語は通常、プロトコル要件に関連付けられていますが、このドキュメントでは、これらの用語は、テスト条件を実装し、この仕様への適合を主張しようとするユーザーとシステムの要件です。
A number of terms used in this memo have been defined in other RFCs. Please refer to the RFCs below for definitions, testing procedures, and reporting formats.
このメモで使用されるいくつかの用語は、他のRFCで定義されています。定義、テスト手順、およびレポート形式については、以下のRFCを参照してください。
o Throughput (Benchmark) [RFC2544]
o スループット（ベンチマーク）[RFC2544]
o Frame Loss Rate (Benchmark) [RFC2544]
o フレーム損失率（ベンチマーク）[RFC2544]
o Back-to-Back Frames (Benchmark) [RFC2544]
o バックツーバックフレーム（ベンチマーク）[RFC2544]
o System Recovery (Benchmark) [RFC2544]
o システム回復（ベンチマーク）[RFC2544]
o Reset (Benchmark) [RFC6201]
o リセット（ベンチマーク）[RFC6201]
o Concurrent TCP Connection Capacity (Benchmark) [RFC3511]
o 同時TCP接続容量（ベンチマーク）[RFC3511]
o Maximum TCP Connection Establishment Rate (Benchmark) [RFC3511]
o 最大TCP接続確立率（ベンチマーク）[RFC3511]
The test environment setup options recommended for benchmarking IPv6 transition technologies are very similar to the ones presented in Section 6 of [RFC2544]. In the case of the Tester setup, the options presented in [RFC2544] and [RFC5180] can be applied here as well. However, the DUT setup options should be explained in the context of the targeted categories of IPv6 transition technologies: single translation, double translation, and encapsulation.
IPv6移行テクノロジーのベンチマークに推奨されるテスト環境設定オプションは、[RFC2544]のセクション6に示されているものと非常によく似ています。テスター設定の場合、[RFC2544]と[RFC5180]に示されているオプションをここでも適用できます。ただし、DUTセットアップオプションは、IPv6移行テクノロジの対象となるカテゴリ（単一変換、二重変換、およびカプセル化）のコンテキストで説明する必要があります。
Although both single Tester and sender/receiver setups are applicable to this methodology, the single Tester setup will be used to describe the DUT setup options.
単一のテスターと送信側/受信側のセットアップの両方がこの方法に適用できますが、単一のテスターのセットアップを使用してDUTセットアップオプションを説明します。
For the test setups presented in this memo, dynamic routing SHOULD be employed. However, the presence of routing and management frames can represent unwanted background data that can affect the benchmarking result. To that end, the procedures defined in Sections 11.2 and 11.3 of [RFC2544] related to routing and management frames SHOULD be used here. Moreover, the "trial description" recommendations presented in Section 23 of [RFC2544] are also valid for this memo.
このメモに示されているテストセットアップでは、動的ルーティングを採用する必要があります（SHOULD）。ただし、ルーティングフレームと管理フレームの存在は、ベンチマーク結果に影響を与える可能性のある不要なバックグラウンドデータを表す場合があります。そのためには、ルーティングと管理フレームに関連する[RFC2544]のセクション11.2と11.3で定義された手順をここで使用する必要があります。さらに、[RFC2544]のセクション23で提示された「トライアルの説明」の推奨事項もこのメモに有効です。
In terms of route setup, the recommendations of Section 13 of [RFC2544] are valid for this document, assuming that IPv6-capable routing protocols are used.
ルートの設定に関しては、[RFC2544]のセクション13の推奨事項は、IPv6対応のルーティングプロトコルが使用されていることを前提として、このドキュメントに有効です。
For the evaluation of single-translation transition technologies, a single DUT setup (see Figure 1) SHOULD be used. The DUT is responsible for translating the IPvX packets into IPvY packets. In this context, the Tester device SHOULD be configured to support both IPvX and IPvY.
単一翻訳遷移テクノロジの評価には、単一のDUTセットアップ（図1を参照）を使用する必要があります（SHOULD）。 DUTは、IPvXパケットをIPvYパケットに変換します。このコンテキストでは、テスターデバイスはIPvXとIPvYの両方をサポートするように構成する必要があります（SHOULD）。
+--------------------+
| |
+------------|IPvX Tester IPvY|<-------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ |
| | | |
+----------->|IPvX DUT IPvY|--------------+
| |
+--------------------+
Figure 1: Test Setup 1 (Single DUT)
図1：テストセットアップ1（単一DUT）
For evaluating the performance of encapsulation and double-translation transition technologies, a dual DUT setup (see Figure 2) SHOULD be employed. The Tester creates a network flow of IPvX packets. The first DUT is responsible for the encapsulation or translation of IPvX packets into IPvY packets. The IPvY packets are de-encapsulated/translated back to IPvX packets by the second DUT and forwarded to the Tester.
カプセル化および二重変換遷移テクノロジーのパフォーマンスを評価するには、デュアルDUTセットアップ（図2を参照）を使用する必要があります（SHOULD）。テスターは、IPvXパケットのネットワークフローを作成します。最初のDUTは、IPvXパケットのカプセル化またはIPvYパケットへの変換を担当します。 IPvYパケットは、2番目のDUTによってカプセル化解除/ IPvXパケットに変換され、テスターに転送されます。
+--------------------+
| |
+---------------------|IPvX Tester IPvX|<------------------+
| | | |
| +--------------------+ |
| |
| +--------------------+ +--------------------+ |
| | | | | |
+----->|IPvX DUT 1 IPvY |----->|IPvY DUT 2 IPvX |------+
| | | |
+--------------------+ +--------------------+
Figure 2: Test Setup 2 (Dual DUT)
図2：テストセットアップ2（デュアルDUT）
One of the limitations of the dual DUT setup is the inability to reflect asymmetries in behavior between the DUTs. Considering this, additional performance tests SHOULD be performed using the single DUT setup.
デュアルDUTセットアップの制限の1つは、DUT間の動作の非対称性を反映できないことです。これを考慮して、単一のDUTセットアップを使用して追加のパフォーマンステストを実行する必要があります。
Note: For encapsulation IPv6 transition technologies in the single DUT setup, the Tester SHOULD be able to send IPvX packets encapsulated as IPvY in order to test the de-encapsulation efficiency.
注：単一のDUTセットアップでのカプセル化IPv6移行テクノロジの場合、テスターは、カプセル化解除の効率をテストするために、IPvYとしてカプセル化されたIPvXパケットを送信できる必要があります（SHOULD）。
The test traffic represents the experimental workload and SHOULD meet the requirements specified in this section. The requirements are dedicated to unicast IP traffic. Multicast IP traffic is outside of the scope of this document.
テストトラフィックは実験的なワークロードを表し、このセクションで指定された要件を満たす必要があります。要件はユニキャストIPトラフィック専用です。マルチキャストIPトラフィックは、このドキュメントの範囲外です。
[RFC5180] describes the frame size requirements for two commonly used media types: Ethernet and SONET (Synchronous Optical Network). [RFC2544] also covers other media types, such as token ring and Fiber Distributed Data Interface (FDDI). The recommendations of those two documents can be used for the dual-stack transition technologies. For the rest of the transition technologies, the frame overhead introduced by translation or encapsulation MUST be considered.
[RFC5180]は、2つの一般的に使用されるメディアタイプのフレームサイズ要件について説明しています：イーサネットとSONET（同期光ネットワーク）。 [RFC2544]は、トークンリングやファイバー分散データインターフェイス（FDDI）などの他のメディアタイプもカバーしています。これら2つのドキュメントの推奨事項は、デュアルスタック移行テクノロジーに使用できます。残りの移行テクノロジでは、変換またはカプセル化によって導入されるフレームオーバーヘッドを考慮する必要があります。
The encapsulation/translation process generates different size frames on different segments of the test setup. For instance, the single-translation transition technologies will create different frame sizes on the receiving segment of the test setup, as IPvX packets are translated to IPvY. This is not a problem if the bandwidth of the employed media is not exceeded. To prevent exceeding the limitations imposed by the media, the frame size overhead needs to be taken into account when calculating the maximum theoretical frame rates. The calculation method for the Ethernet, as well as a calculation example, are detailed in Appendix A. The details of the media employed for the benchmarking tests MUST be noted in all test reports.
カプセル化/変換プロセスは、テストセットアップの異なるセグメントに異なるサイズのフレームを生成します。たとえば、IPvXパケットはIPvYに変換されるため、単一変換の移行テクノロジでは、テストセットアップの受信セグメントに異なるフレームサイズが作成されます。使用するメディアの帯域幅を超えない場合、これは問題ではありません。メディアの制限を超えないようにするには、理論上の最大フレームレートを計算するときに、フレームサイズのオーバーヘッドを考慮する必要があります。イーサネットの計算方法と計算例については、付録Aで詳しく説明します。ベンチマークテストに使用したメディアの詳細は、すべてのテストレポートに記載する必要があります。
In the context of frame size overhead, MTU recommendations are needed in order to avoid frame loss due to MTU mismatch between the virtual encapsulation/translation interfaces and the physical network interface controllers (NICs). To avoid this situation, the larger MTU between the physical NICs and virtual encapsulation/translation interfaces SHOULD be set for all interfaces of the DUT and Tester.
フレームサイズのオーバーヘッドのコンテキストでは、仮想カプセル化/変換インターフェイスと物理ネットワークインターフェイスコントローラー（NIC）間のMTUの不一致によるフレーム損失を回避するために、MTUの推奨事項が必要です。この状況を回避するには、物理NICと仮想カプセル化/変換インターフェース間のより大きなMTUを、DUTとテスターのすべてのインターフェースに設定する必要があります。
To be more specific, the minimum IPv6 MTU size (1280 bytes) plus the encapsulation/translation overhead is the RECOMMENDED value for the physical interfaces as well as virtual ones.
具体的には、IPv6 MTUの最小サイズ（1280バイト）にカプセル化/変換のオーバーヘッドを加えたものが、物理インターフェイスと仮想インターフェイスの推奨値です。
Based on the recommendations of [RFC5180], the following frame sizes SHOULD be used for benchmarking IPvX/IPvY traffic on Ethernet links: 64, 128, 256, 512, 768, 1024, 1280, 1518, 1522, 2048, 4096, 8192, and 9216.
[RFC5180]の推奨に基づいて、イーサネットリンク上のIPvX / IPvYトラフィックのベンチマークに次のフレームサイズを使用する必要があります（SHOULD）：64、128、256、512、768、1024、1280、1518、1522、2048、4096、8192、および9216。
For Ethernet frames exceeding 1500 bytes in size, the [IEEE802.1AC] standard can be consulted.
サイズが1500バイトを超えるイーサネットフレームについては、[IEEE802.1AC]規格を参照できます。
Note: For single-translation transition technologies (e.g., NAT64) in the IPv6 -> IPv4 translation direction, 64-byte frames SHOULD be replaced by 84-byte frames. This would allow the frames to be transported over media such as the ones described by the [IEEE802.1Q] standard. Moreover, this would also allow the implementation of a frame identifier in the UDP data.
注：IPv6-> IPv4変換方向の単一変換遷移テクノロジー（NAT64など）の場合、64バイトフレームを84バイトフレームに置き換える必要があります（SHOULD）。これにより、[IEEE802.1Q]標準で記述されているようなメディアを介してフレームを転送できます。さらに、これにより、UDPデータにフレーム識別子を実装することもできます。
The theoretical maximum frame rates considering an example of frame overhead are presented in Appendix A.
フレームオーバーヘッドの例を考慮した理論上の最大フレームレートを付録Aに示します。
The selected protocol addresses should follow the recommendations of Section 5 of [RFC5180] for IPv6 and Section 12 of [RFC2544] for IPv4.
選択したプロトコルアドレスは、IPv6の場合は[RFC5180]のセクション5、IPv4の場合は[RFC2544]のセクション12の推奨事項に従う必要があります。
Note: Testing traffic with extension headers might not be possible for the transition technologies that employ translation. Proposed IPvX/IPvY translation algorithms such as IP/ICMP translation [RFC7915] do not support the use of extension headers.
注：拡張ヘッダーを使用してトラフィックをテストすることは、変換を採用する移行テクノロジーでは可能でない場合があります。 IP / ICMP変換[RFC7915]などの提案されているIPvX / IPvY変換アルゴリズムは、拡張ヘッダーの使用をサポートしていません。
Following the recommendations of [RFC5180], all tests described SHOULD be performed with bidirectional traffic. Unidirectional traffic tests MAY also be performed for a fine-grained performance assessment.
[RFC5180]の推奨に従い、記述されているすべてのテストは双方向トラフィックで実行する必要があります（SHOULD）。単方向トラフィックテストは、きめ細かいパフォーマンス評価のためにも実行される場合があります。
Because of the simplicity of UDP, UDP measurements offer a more reliable basis for comparison than other transport-layer protocols. Consequently, for the benchmarking tests described in Section 7 of this document, UDP traffic SHOULD be employed.
UDPは単純であるため、UDP測定は、他のトランスポート層プロトコルよりも比較のための信頼できる基準を提供します。したがって、このドキュメントのセクション7で説明されているベンチマークテストでは、UDPトラフィックを使用する必要があります（SHOULD）。
Considering that a transition technology could process both native IPv6 traffic and translated/encapsulated traffic, the following traffic setups are recommended:
移行テクノロジがネイティブIPv6トラフィックと変換/カプセル化されたトラフィックの両方を処理できることを考慮して、次のトラフィック設定をお勧めします。
i) IPvX only traffic (where the IPvX traffic is to be translated/encapsulated by the DUT) ii) 90% IPvX traffic and 10% IPvY native traffic iii) 50% IPvX traffic and 50% IPvY native traffic iv) 10% IPvX traffic and 90% IPvY native traffic
i) IPvXのみのトラフィック（IPvXトラフィックがDUTによって変換/カプセル化される場合）ii）90％IPvXトラフィックと10％IPvYネイティブトラフィックiii）50％IPvXトラフィックと50％IPvYネイティブトラフィックiv）10％IPvXトラフィックと90 IPvYネイティブトラフィックの割合
For the benchmarks dedicated to stateful IPv6 transition technologies, included in Section 8 of this memo (Concurrent TCP Connection Capacity and Maximum TCP Connection Establishment Rate), the traffic SHOULD follow the recommendations of Sections 5.2.2.2 and 5.3.2.2 of [RFC3511].
このメモのセクション8に含まれるステートフルIPv6移行テクノロジー専用のベンチマーク（同時TCP接続容量と最大TCP接続確立率）の場合、トラフィックは[RFC3511]のセクション5.2.2.2および5.3.2.2の推奨に従う必要があります（SHOULD）。
The idea of testing under different operational conditions was first introduced in Section 11 of [RFC2544] and represents an important aspect of benchmarking network elements, as it emulates, to some extent, the conditions of a production environment. Section 6 of [RFC5180] describes complementary test conditions specific to IPv6. The recommendations in [RFC2544] and [RFC5180] can also be followed for testing of IPv6 transition technologies.
さまざまな運用条件下でのテストのアイデアは、最初に[RFC2544]のセクション11で導入され、本番環境の条件をある程度エミュレートするため、ネットワーク要素のベンチマークの重要な側面を表しています。 [RFC5180]のセクション6では、IPv6に固有の補足的なテスト条件について説明しています。 [RFC2544]と[RFC5180]の推奨事項は、IPv6移行テクノロジのテストにも従うことができます。
The following sub-sections describe all recommended benchmarking tests.
次のサブセクションでは、推奨されるすべてのベンチマークテストについて説明します。
Use Section 26.1 of [RFC2544] unmodified.
[RFC2544]のセクション26.1を変更せずに使用します。
Objective: To determine the latency. Typical latency is based on the definitions of latency from [RFC1242]. However, this memo provides a new measurement procedure.
目的：待ち時間を決定する。一般的なレイテンシは、[RFC1242]のレイテンシの定義に基づいています。ただし、このメモは新しい測定手順を提供します。
Procedure: Similar to [RFC2544], the throughput for DUT at each of the listed frame sizes SHOULD be determined. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 120 seconds in duration.
手順：[RFC2544]と同様に、リストされた各フレームサイズでのDUTのスループットを決定する必要があります。特定のフレームサイズのフレームストリームを、決定されたスループットレートでDUTを介して特定の宛先に送信します。ストリームの継続時間は少なくとも120秒である必要があります。
Identifying tags SHOULD be included in at least 500 frames after 60 seconds. For each tagged frame, the time at which the frame was fully transmitted (timestamp A) and the time at which the frame was received (timestamp B) MUST be recorded. The latency is timestamp B minus timestamp A as per the relevant definition from RFC 1242, namely, latency as defined for store and forward devices or latency as defined for bit forwarding devices.
識別タグは、60秒後に少なくとも500フレームに含める必要があります。タグ付けされたフレームごとに、フレームが完全に送信された時刻（タイムスタンプA）およびフレームが受信された時刻（タイムスタンプB）を記録する必要があります。レイテンシは、RFC 1242の関連定義に従って、タイムスタンプBからタイムスタンプAを差し引いたものです。つまり、ストアアンドフォワードデバイスに対して定義されたレイテンシまたはビット転送デバイスに対して定義されたレイテンシです。
We recommend encoding the identifying tag in the payload of the frame. To be more exact, the identifier SHOULD be inserted after the UDP header.
識別タグをフレームのペイロードにエンコードすることをお勧めします。より正確には、UDPヘッダーの後に識別子を挿入する必要があります（SHOULD）。
From the resulted (at least 500) latencies, two quantities SHOULD be calculated. One is the typical latency, which SHOULD be calculated with the following formula:
結果の（少なくとも500）レイテンシから、2つの量を計算する必要があります（SHOULD）。 1つは一般的なレイテンシであり、次の式で計算する必要があります。
TL = Median(Li)
TL =中央値（l i）
Where:
ただし：
o TL = the reported typical latency of the stream
o TL =ストリームの報告された典型的な待ち時間
o Li = the latency for tagged frame i
o Li =タグ付きフレームiのレイテンシ
The other measure is the worst-case latency, which SHOULD be calculated with the following formula:
もう1つの指標は、最悪の場合のレイテンシで、次の式で計算する必要があります。
WCL = L99.9thPercentile
WCL = L99.9thPercentile
Where:
ただし：
o WCL = the reported worst-case latency
o WCL =報告された最悪の場合の遅延
o L99.9thPercentile = the 99.9th percentile of the stream-measured latencies
o L99.9thPercentile =ストリームで測定されたレイテンシの99.9パーセンタイル
The test MUST be repeated at least 20 times with the reported value being the median of the recorded values for TL and WCL.
テストは少なくとも20回繰り返す必要があります。報告された値は、TLとWCLの記録された値の中央値です。
Reporting Format: The report MUST state which definition of latency (from RFC 1242) was used for this test. The summarized latency results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size, the rate at which the latency test was run for that frame size, the media types tested, and the resultant typical latency, and the worst-case latency values for each type of data stream tested. To account for the variation, the 1st and 99th percentiles of the 20 iterations MAY be reported in two separated columns. For a fine-grained analysis, the histogram (as exemplified in Section 4.4 of [RFC5481]) of one of the iterations MAY be displayed.
レポート形式：レポートは、このテストに使用された（RFC 1242からの）待ち時間の定義を記述しなければなりません（MUST）。要約されたレイテンシ結果は、テストされた各フレームサイズの行を含む表の形式で報告する必要があります（SHOULD）。フレームサイズの列、そのフレームサイズでレイテンシテストが実行されたレート、テストされたメディアタイプ、結果として得られる典型的なレイテンシ、およびテストされた各タイプのデータストリームの最悪の場合のレイテンシ値の列が存在する必要があります。変動を説明するために、20回の反復の1番目と99番目のパーセンタイルが2つの別々の列に報告される場合があります。きめの細かい分析では、いずれかの反復のヒストグラム（[RFC5481]のセクション4.4に例示）を表示できます（MAY）。
[RFC5481] presents two metrics: Packet Delay Variation (PDV) and Inter Packet Delay Variation (IPDV). Measuring PDV is RECOMMENDED; for a fine-grained analysis of delay variation, IPDV measurements MAY be performed.
[RFC5481]は、パケット遅延変動（PDV）とパケット間遅延変動（IPDV）の2つのメトリックを示しています。 PDVの測定が推奨されます。遅延変動のきめ細かい分析のために、IPDV測定を実行してもよい（MAY）。
Objective: To determine the Packet Delay Variation as defined in [RFC5481].
目的：[RFC5481]で定義されているパケット遅延変動を決定すること。
Procedure: As described by [RFC2544], first determine the throughput for the DUT at each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 60 seconds in duration. Measure the one-way delay as described by [RFC3393] for all frames in the stream. Calculate the PDV of the stream using the formula:
手順：[RFC2544]で説明されているように、最初に、リストされている各フレームサイズでのDUTのスループットを決定します。特定のフレームサイズのフレームストリームを、決定されたスループットレートでDUTを介して特定の宛先に送信します。ストリームの継続時間は少なくとも60秒である必要があります。ストリーム内のすべてのフレームについて、[RFC3393]で説明されている一方向の遅延を測定します。次の式を使用して、ストリームのPDVを計算します。
PDV = D99.9thPercentile - Dmin
VAT = D99.9thPercentile-Dmin
Where:
ただし：
o D99.9thPercentile = the 99.9th percentile (as described in [RFC5481]) of the one-way delay for the stream
o D99.9thPercentile =ストリームの一方向遅延の99.9パーセンタイル（[RFC5481]で説明）
o Dmin = the minimum one-way delay in the stream
o Dmin =ストリームの最小一方向遅延
As recommended in [RFC2544], the test MUST be repeated at least 20 times with the reported value being the median of the recorded values. Moreover, the 1st and 99th percentiles SHOULD be calculated to account for the variation of the dataset.
[RFC2544]で推奨されているように、テストは少なくとも20回繰り返されなければならず（MUST）、報告された値は記録された値の中央値です。さらに、1番目と99番目のパーセンタイルは、データセットの変動を考慮して計算する必要があります（SHOULD）。
Reporting Format: The PDV results SHOULD be reported in a table with a row for each of the tested frame sizes and columns for the frame size and the applied frame rate for the tested media types. Two columns for the 1st and 99th percentile values MAY be displayed. Following the recommendations of [RFC5481], the RECOMMENDED units of measurement are milliseconds.
レポート形式：PDVの結果は、テストされた各フレームサイズの行とフレームサイズの列、およびテストされたメディアタイプに適用されたフレームレートの表で報告する必要があります（SHOULD）。 1パーセンタイル値と99パーセンタイル値の2つの列が表示される場合があります。 [RFC5481]の推奨に従い、推奨される測定単位はミリ秒です。
Objective: To determine the Inter Packet Delay Variation as defined in [RFC5481].
目的：[RFC5481]で定義されているパケット間遅延変動を決定すること。
Procedure: As described by [RFC2544], first determine the throughput for the DUT at each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 60 seconds in duration. Measure the one-way delay as described by [RFC3393] for all frames in the stream. Calculate the IPDV for each of the frames using the formula:
手順：[RFC2544]で説明されているように、最初に、リストされている各フレームサイズでのDUTのスループットを決定します。特定のフレームサイズのフレームストリームを、決定されたスループットレートでDUTを介して特定の宛先に送信します。ストリームの継続時間は少なくとも60秒である必要があります。ストリーム内のすべてのフレームについて、[RFC3393]で説明されている一方向の遅延を測定します。次の式を使用して、各フレームのIPDVを計算します。
IPDV(i) = D(i) - D(i-1)
Where:
ただし：
o D(i) = the one-way delay of the i-th frame in the stream
o D（i）=ストリームのi番目のフレームの一方向遅延
o D(i-1) = the one-way delay of (i-1)th frame in the stream
o D（i-1）=ストリーム内の（i-1）番目のフレームの一方向遅延
Given the nature of IPDV, reporting a single number might lead to over-summarization. In this context, the report for each measurement SHOULD include three values: Dmin, Dmed, and Dmax.
IPDVの性質を考えると、単一の数値を報告すると要約が過剰になる可能性があります。このコンテキストでは、各測定のレポートには、Dmin、Dmed、およびDmaxの3つの値が含まれる必要があります（SHOULD）。
Where:
ただし：
o Dmin = the minimum IPDV in the stream
o Dmin =ストリーム内の最小IPDV
o Dmed = the median IPDV of the stream
o Dmed =ストリームのIPDVの中央値
o Dmax = the maximum IPDV in the stream
o Dmax =ストリーム内の最大IPDV
The test MUST be repeated at least 20 times. To summarize the 20 repetitions, for each of the three (Dmin, Dmed, and Dmax), the median value SHOULD be reported.
テストは少なくとも20回繰り返す必要があります。 20回の繰り返しを要約するには、3つ（Dmin、Dmed、およびDmax）のそれぞれについて、中央値を報告する必要があります（SHOULD）。
Reporting format: The median for the three proposed values SHOULD be reported. The IPDV results SHOULD be reported in a table with a row for each of the tested frame sizes. The columns SHOULD include the frame size and associated frame rate for the tested media types and sub-columns for the three proposed reported values. Following the recommendations of [RFC5481], the RECOMMENDED units of measurement are milliseconds.
報告形式：3つの提案された値の中央値を報告する必要があります。 IPDVの結果は、テストされた各フレームサイズの行を含む表で報告する必要があります（SHOULD）。列には、テストされたメディアタイプのフレームサイズと関連するフレームレート、および3つの提案されたレポート値のサブ列を含める必要があります（SHOULD）。 [RFC5481]の推奨に従い、推奨される測定単位はミリ秒です。
Use Section 26.3 of [RFC2544] unmodified.
[RFC2544]のセクション26.3を変更せずに使用します。
Use Section 26.4 of [RFC2544] unmodified.
[RFC2544]のセクション26.4を変更せずに使用します。
Use Section 26.5 of [RFC2544] unmodified.
[RFC2544]のセクション26.5を変更せずに使用します。
Use Section 4 of [RFC6201] unmodified.
[RFC6201]のセクション4を変更せずに使用します。
8. Additional Benchmarking Tests for Stateful IPv6 Transition Technologies
8. ステートフルIPv6移行テクノロジの追加のベンチマークテスト
This section describes additional tests dedicated to stateful IPv6 transition technologies. For the tests described in this section, the DUT devices SHOULD follow the test setup and test parameters recommendations presented in Sections 5.2 and 5.3 of [RFC3511].
このセクションでは、ステートフルIPv6移行テクノロジ専用の追加のテストについて説明します。このセクションで説明するテストの場合、DUTデバイスは、[RFC3511]のセクション5.2および5.3で提示されているテストセットアップおよびテストパラメーターの推奨事項に従う必要があります（SHOULD）。
The following additional tests SHOULD be performed.
次の追加のテストを実行する必要があります。
Use Section 5.2 of [RFC3511] unmodified.
[RFC3511]のセクション5.2をそのまま使用します。
Use Section 5.3 of [RFC3511] unmodified.
[RFC3511]のセクション5.3を変更せずに使用します。
This section describes benchmarking tests dedicated to DNS64 (see [RFC6147]), used as DNS support for single-translation technologies such as NAT64.
このセクションでは、NAT64などの単一変換テクノロジのDNSサポートとして使用される、DNS64（[RFC6147]を参照）専用のベンチマークテストについて説明します。
The test setup in Figure 3 follows the setup proposed for single-translation IPv6 transition technologies in Figure 1.
図3のテストセットアップは、図1の単一変換IPv6移行テクノロジ用に提案されたセットアップに従います。
1:AAAA query +--------------------+
+------------| |<-------------+
| |IPv6 Tester IPv4| |
| +-------->| |----------+ |
| | +--------------------+ 3:empty | |
| | 6:synt'd AAAA, | |
| | AAAA +--------------------+ 5:valid A| |
| +---------| |<---------+ |
| |IPv6 DUT IPv4| |
+----------->| (DNS64) |--------------+
+--------------------+ 2:AAAA query, 4:A query
Figure 3: Test Setup 3 (DNS64)
図3：テストセットアップ3（DNS64）
The test traffic SHOULD be composed of the following messages.
テストトラフィックは、次のメッセージで構成される必要があります。
1. Query for the AAAA record of a domain name (from client to DNS64 server)
1. ドメイン名のAAAAレコードのクエリ（クライアントからDNS64サーバーへ）
2. Query for the AAAA record of the same domain name (from DNS64 server to authoritative DNS server)
2. 同じドメイン名のAAAAレコードのクエリ（DNS64サーバーから信頼できるDNSサーバーへ）
3. Empty AAAA record answer (from authoritative DNS server to DNS64 server)
3. 空のAAAAレコードの回答（信頼できるDNSサーバーからDNS64サーバーへ）
4. Query for the A record of the same domain name (from DNS64 server to authoritative DNS server)
4. 同じドメイン名のAレコードのクエリ（DNS64サーバーから信頼できるDNSサーバーへ）
5. Valid A record answer (from authoritative DNS server to DNS64 server)
5. 有効なAレコードの回答（信頼できるDNSサーバーからDNS64サーバーへ）
6. Synthesized AAAA record answer (from DNS64 server to client)
6. 合成されたAAAAレコードの回答（DNS64サーバーからクライアントへ）
The Tester plays the role of DNS client as well as authoritative DNS server. It MAY be realized as a single physical device, or alternatively, two physical devices MAY be used.
テスターは、DNSクライアントおよび信頼できるDNSサーバーの役割を果たします。それは、単一の物理デバイスとして実現される場合もあれば、2つの物理デバイスが使用される場合もあります。
Please note that:
その点に注意してください：
o If the DNS64 server implements caching and there is a cache hit, then step 1 is followed by step 6 (and steps 2 through 5 are omitted).
o DNS64サーバーがキャッシングを実装し、キャッシュヒットがある場合、ステップ1の後にステップ6が続きます（ステップ2から5は省略されます）。
o If the domain name has a AAAA record, then it is returned in step 3 by the authoritative DNS server, steps 4 and 5 are omitted, and the DNS64 server does not synthesize a AAAA record but returns the received AAAA record to the client.
o ドメイン名にAAAAレコードがある場合は、権限のあるDNSサーバーからステップ3で返され、ステップ4と5は省略されます。DNS64サーバーはAAAAレコードを合成せず、受信したAAAAレコードをクライアントに返します。
o As for the IP version used between the Tester and the DUT, IPv6 MUST be used between the client and the DNS64 server (as a DNS64 server provides service for an IPv6-only client), but either IPv4 or IPv6 MAY be used between the DNS64 server and the authoritative DNS server.
o テスターとDUTの間で使用されるIPバージョンについては、クライアントとDNS64サーバーの間でIPv6を使用する必要があります（DNS64サーバーがIPv6のみのクライアントにサービスを提供するため）。ただし、DNS64の間でIPv4またはIPv6を使用できます（MAY）。サーバーと権威DNSサーバー。
Objective: To determine DNS64 performance by means of the maximum number of successfully processed DNS requests per second.
目的：1秒あたりに正常に処理されたDNS要求の最大数を使用してDNS64のパフォーマンスを判断します。
Procedure: Send a specific number of DNS queries at a specific rate to the DUT, and then count the replies from the DUT that are received in time (within a predefined timeout period from the sending time of the corresponding query, having the default value 1 second) and that are valid (contain a AAAA record). If the count of sent queries is equal to the count of received replies, the rate of the queries is raised, and the test is rerun. If fewer replies are received than queries were sent, the rate of the queries is reduced, and the test is rerun. The duration of each trial SHOULD be at least 60 seconds. This will reduce the potential gain of a DNS64 server, which is able to exhibit higher performance by storing the requests and thus also utilizing the timeout time for answering them. For the same reason, no higher timeout time than 1 second SHOULD be used. For further considerations, see [Lencse1].
手順：特定の数のDNSクエリを特定のレートでDUTに送信し、時間内に受信されたDUTからの応答をカウントします（対応するクエリの送信時刻からの既定のタイムアウト期間内で、デフォルト値は1です） 2番目）およびそれは有効です（AAAAレコードが含まれています）。送信されたクエリの数が受信された応答の数と等しい場合、クエリのレートが上げられ、テストが再実行されます。送信されたクエリよりも少ない数の応答を受信した場合、クエリのレートが低下し、テストが再実行されます。各試行の期間は少なくとも60秒である必要があります。これにより、要求を格納し、タイムアウト時間を利用して応答することで、より高いパフォーマンスを発揮できるDNS64サーバーの潜在的な利益が減少します。同じ理由で、1秒を超えるタイムアウト時間は使用しないでください。詳細については、[Lencse1]を参照してください。
The maximum number of processed DNS queries per second is the fastest rate at which the count of DNS replies sent by the DUT is equal to the number of DNS queries sent to it by the test equipment.
1秒あたりに処理されるDNSクエリの最大数は、DUTによって送信されるDNS応答の数が、テスト機器によってそれに送信されるDNSクエリの数と等しい最高速度です。
The test SHOULD be repeated at least 20 times, and the median and 1st/99th percentiles of the number of processed DNS queries per second SHOULD be calculated.
テストは少なくとも20回繰り返す必要があり、1秒あたりの処理されたDNSクエリ数の中央値と1/99パーセンタイルを計算する必要があります（SHOULD）。
Details and parameters:
詳細とパラメータ：
1. Caching
1. キャッシング
First, all the DNS queries MUST contain different domain names (or domain names MUST NOT be repeated before the cache of the DUT is exhausted). Then, new tests MAY be executed when domain names are 20%, 40%, 60%, 80%, and 100% cached. Ensuring that a record is cached requires repeating a domain name both "late enough" after the first query to be already resolved and be present in the cache and "early enough" to be still present in the cache.
まず、すべてのDNSクエリには異なるドメイン名が含まれている必要があります（または、DUTのキャッシュが使い果たされる前にドメイン名を繰り返すことはできません）。次に、ドメイン名が20％、40％、60％、80％、および100％キャッシュされると、新しいテストが実行される場合があります。レコードを確実にキャッシュするには、最初のクエリが解決されてキャッシュに存在する「十分に遅い」ドメインと、キャッシュにまだ存在する「十分早い」ドメイン名を繰り返す必要があります。
2. Existence of a AAAA record
2. AAAAレコードの存在
First, all the DNS queries MUST contain domain names that do not have a AAAA record and have exactly one A record. Then, new tests MAY be executed when 20%, 40%, 60%, 80%, and 100% of domain names have a AAAA record.
まず、すべてのDNSクエリには、AAAAレコードがなく、Aレコードが1つだけあるドメイン名が含まれている必要があります。次に、ドメイン名の20％、40％、60％、80％、および100％にAAAAレコードがある場合、新しいテストが実行される場合があります。
Please note that the two conditions above are orthogonal; thus, all their combinations are possible and MAY be tested. The testing with 0% cached domain names and with 0% existing AAAA records is REQUIRED, and the other combinations are OPTIONAL. (When all the domain names are cached, then the results do not depend on what percentage of the domain names have AAAA records; thus, these combinations are not worth testing one by one.)
上記の2つの条件は直交していることに注意してください。したがって、それらのすべての組み合わせが可能であり、テストすることができます。 0％のキャッシュドメイン名と0％の既存のAAAAレコードを使用したテストは必須であり、他の組み合わせはオプションです。 （すべてのドメイン名がキャッシュされる場合、結果はドメイン名の何パーセントがAAAAレコードを持っているかに依存しないため、これらの組み合わせを1つずつテストする価値はありません。）
Reporting format: The primary result of the DNS64 test is the median of the number of processed DNS queries per second measured with the above mentioned "0% + 0% combination". The median SHOULD be complemented with the 1st and 99th percentiles to show the stability of the result. If optional tests are done, the median and the 1st and 99th percentiles MAY be presented in a two-dimensional table where the dimensions are the proportion of the repeated domain names and the proportion of the DNS names having AAAA records. The two table headings SHOULD contain these percentage values. Alternatively, the results MAY be presented as a corresponding two-dimensional graph. In this case, the graph SHOULD show the median values with the percentiles as error bars. From both the table and the graph, one-dimensional excerpts MAY be made at any given fixed-percentage value of the other dimension. In this case, the fixed value MUST be given together with a one-dimensional table or graph.
レポート形式：DNS64テストの主な結果は、上記の「0％+ 0％の組み合わせ」で測定された1秒あたりの処理済みDNSクエリ数の中央値です。中央値は、結果の安定性を示すために1パーセンタイルと99パーセンタイルで補完する必要があります（SHOULD）。オプションのテストが行われる場合、中央値と1パーセンタイルと99パーセンタイルは、次元が繰り返しドメイン名の割合とAAAAレコードを持つDNS名の割合である2次元の表で提示される場合があります。 2つのテーブル見出しには、これらのパーセント値を含める必要があります（SHOULD）。あるいは、結果は対応する2次元グラフとして提示される場合があります。この場合、グラフは、パーセンタイルをエラーバーとして中央値を表示する必要があります（SHOULD）。表とグラフの両方から、1次元の抜粋を、他の次元の任意の固定パーセント値で作成できます（MAY）。この場合、固定値は1次元の表またはグラフと共に指定する必要があります。
Before a Tester can be used for testing a DUT at rate r queries per second with t seconds timeout, it MUST perform a self-test in order to exclude the possibility that the poor performance of the Tester itself influences the results. To perform a self-test, the Tester is looped back (leaving out DUT), and its authoritative DNS server subsystem is configured to be able to answer all the AAAA record queries. To pass the self-test, the Tester SHOULD be able to answer AAAA record queries at rate of 2*(r+delta) within a 0.25*t timeout, where the value of delta is at least 0.1.
テスターがt秒のタイムアウトで毎秒rクエリの速度でDUTをテストする前に、テスター自体のパフォーマンスの低下が結果に影響する可能性を排除するために、セルフテストを実行する必要があります。セルフテストを実行するには、テスターをループバックし（DUTを除外）、その信頼できるDNSサーバーサブシステムがすべてのAAAAレコードクエリに応答できるように構成されます。セルフテストに合格するために、テスターは、0.25 * tタイムアウト内で2 *（r + delta）のレートでAAAAレコードクエリに応答できなければなりません（デルタの値は少なくとも0.1）。
Explanation: When performing DNS64 testing, each AAAA record query may result in at most two queries sent by the DUT: the first for a AAAA record and the second for an A record (they are both sent when there is no cache hit and also no AAAA record exists). The parameters above guarantee that the authoritative DNS server subsystem of the DUT is able to answer the queries at the required frequency using up not more than half of the timeout time.
説明：DNS64テストを実行する場合、各AAAAレコードクエリは、DUTによって最大2つのクエリを送信する可能性があります。最初のクエリはAAAAレコード用で、2番目のクエリはAレコード用です（キャッシュヒットがなく、またキャッシュヒットがない場合、両方とも送信されます） AAAAレコードが存在します）。上記のパラメーターは、DUTの信頼できるDNSサーバーサブシステムが、タイムアウト時間の半分以下を使用して必要な頻度でクエリに応答できることを保証します。
Note: A sample open-source test program, dns64perf++, is available from [Dns64perf] and is documented in [Lencse2]. It implements only the client part of the Tester and should be used together with an authoritative DNS server implementation, e.g., BIND, NSD, or YADIFA. Its experimental extension for testing caching is available from [Lencse3] and is documented in [Lencse4].
注：サンプルのオープンソーステストプログラムdns64perf ++は、[Dns64perf]から入手でき、[Lencse2]に記載されています。テスターのクライアント部分のみを実装し、BIND、NSD、YADIFAなどの信頼できるDNSサーバー実装と一緒に使用する必要があります。キャッシングをテストするための実験的な拡張機能は、[Lencse3]から入手でき、[Lencse4]に文書化されています。
Scalability has been often discussed; however, in the context of network devices, a formal definition or a measurement method has not yet been proposed. In this context, we can define overload scalability as the ability of each transition technology to accommodate network growth. Poor scalability usually leads to poor performance. Considering this, overload scalability can be measured by quantifying the network performance degradation associated with an increased number of network flows.
スケーラビリティについてはよく議論されてきました。ただし、ネットワークデバイスのコンテキストでは、正式な定義または測定方法はまだ提案されていません。このコンテキストでは、過負荷スケーラビリティを、ネットワークの成長に対応する各移行テクノロジーの能力として定義できます。通常、スケーラビリティが低いと、パフォーマンスが低下します。これを考慮して、過負荷スケーラビリティは、ネットワークフロー数の増加に伴うネットワークパフォーマンスの低下を定量化することで測定できます。
The following subsections describe how the test setups can be modified to create network growth and how the associated performance degradation can be quantified.
次のサブセクションでは、テストのセットアップを変更してネットワークを拡張する方法と、関連するパフォーマンスの低下を定量化する方法について説明します。
The test setups defined in Section 4 have to be modified to create network growth.
セクション4で定義されたテストセットアップは、ネットワークを拡張するために変更する必要があります。
In the case of single-translation transition technologies, the network growth can be generated by increasing the number of network flows (NFs) generated by the Tester machine (see Figure 4).
単一翻訳の移行テクノロジの場合、テスターマシンによって生成されるネットワークフロー（NF）の数を増やすことによって、ネットワークの成長を生み出すことができます（図4を参照）。
+-------------------------+
+------------|NF1 NF1|<-------------+
| +---------|NF2 Tester NF2|<----------+ |
| | ...| | | |
| | +-----|NFn NFn|<------+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-------------------------+ | | |
| | +---->|NFn NFn|-------+ | |
| | ...| DUT | | |
| +-------->|NF2 (translator) NF2|-----------+ |
+----------->|NF1 NF1|--------------+
+-------------------------+
Figure 4: Test Setup 4 (Single DUT with Increased Network Flows)
図4：テストセットアップ4（ネットワークフローが増加した単一のDUT）
Similarly, for the encapsulation and double-translation transition technologies, a multi-flow setup is recommended. Considering a multipoint-to-point scenario, for most transition technologies, one of the edge nodes is designed to support more than one connecting device. Hence, the recommended test setup is an n:1 design, where n is the number of client DUTs connected to the same server DUT (see Figure 5).
同様に、カプセル化と二重翻訳の移行テクノロジについては、マルチフロー設定をお勧めします。マルチポイントツーポイントのシナリオを考えると、ほとんどの移行テクノロジーでは、エッジノードの1つが複数の接続デバイスをサポートするように設計されています。したがって、推奨されるテストセットアップはn：1設計です。ここで、nは同じサーバーDUTに接続されているクライアントDUTの数です（図5を参照）。
+-------------------------+
+--------------------|NF1 NF1|<--------------+
| +-----------------|NF2 Tester NF2|<-----------+ |
| | ...| | | |
| | +-------------|NFn NFn|<-------+ | |
| | | +-------------------------+ | | |
| | | | | |
| | | +-----------------+ +---------------+ | | |
| | +--->| NFn DUT n NFn |--->|NFn NFn| ---+ | |
| | +-----------------+ | | | |
| | ... | | | |
| | +-----------------+ | DUT n+1 | | |
| +------->| NF2 DUT 2 NF2 |--->|NF2 NF2|--------+ |
| +-----------------+ | | |
| +-----------------+ | | |
+---------->| NF1 DUT 1 NF1 |--->|NF1 NF1|-----------+
+-----------------+ +---------------+
Figure 5: Test Setup 5 (DUAL DUT with Increased Network Flows)
図5：テストセットアップ5（ネットワークフローが増加したDUAL DUT）
This test setup can help to quantify the scalability of the server device. However, for testing the overload scalability of the client DUTs, additional recommendations are needed.
このテストセットアップは、サーバーデバイスのスケーラビリティの定量化に役立ちます。ただし、クライアントDUTの過負荷スケーラビリティをテストするには、追加の推奨事項が必要です。
For encapsulation transition technologies, an m:n setup can be created, where m is the number of flows applied to the same client device and n the number of client devices connected to the same server device.
カプセル化移行テクノロジの場合、m：nセットアップを作成できます。ここで、mは同じクライアントデバイスに適用されるフローの数、nは同じサーバーデバイスに接続されているクライアントデバイスの数です。
For translation-based transition technologies, the client devices can be separately tested with n network flows using the test setup presented in Figure 4.
翻訳ベースの移行テクノロジの場合、クライアントデバイスは、図4に示すテストセットアップを使用して、n個のネットワークフローで個別にテストできます。
Objective: To quantify the performance degradation introduced by n parallel and simultaneous network flows.
目的：n個の並列および同時のネットワークフローによるパフォーマンスの低下を定量化する。
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow.
手順：最初に、セクション7に示すベンチマークテストを1つのネットワークフローに対して実行する必要があります。
The same tests have to be repeated for n network flows, where the network flows are started simultaneously. The performance degradation of the X benchmarking dimension SHOULD be calculated as relative performance change between the 1-flow (single flow) results and the n-flow results, using the following formula:
ネットワークフローが同時に開始されるn個のネットワークフローに対して同じテストを繰り返す必要があります。 Xベンチマークディメンションのパフォーマンス低下は、次の式を使用して、1フロー（単一フロー）の結果とnフローの結果の間の相対的なパフォーマンスの変化として計算する必要があります（SHOULD）。
Xn - X1
Xpd = ----------- * 100, where: X1 = result for 1-flow
X1 Xn = result for n-flows
This formula SHOULD be applied only for "lower is better" benchmarks (e.g., latency). For "higher is better" benchmarks (e.g., throughput), the following formula is RECOMMENDED:
この数式は、「低いほど良い」ベンチマーク（レイテンシなど）にのみ適用する必要があります（SHOULD）。 「高いほど良い」ベンチマーク（スループットなど）の場合、次の公式が推奨されます。
X1 - Xn
Xpd = ----------- * 100, where: X1 = result for 1-flow
X1 Xn = result for n-flows
As a guideline for the maximum number of flows n, the value can be deduced by measuring the Concurrent TCP Connection Capacity as described by [RFC3511], following the test setups specified by Section 4.
フローの最大数nのガイドラインとして、この値は、セクション4で指定されたテスト設定に従って、[RFC3511]で説明されているように同時TCP接続容量を測定することで推定できます。
Reporting Format: The performance degradation SHOULD be expressed as a percentage. The number of tested parallel flows n MUST be clearly specified. For each of the performed benchmarking tests, there SHOULD be a table containing a column for each frame size. The table SHOULD also state the applied frame rate. In the case of benchmarks for which more than one value is reported (e.g., IPDV, discussed in Section 7.3.2), a column for each of the values SHOULD be included.
レポート形式：パフォーマンスの低下は、パーセンテージとして表現する必要があります（SHOULD）。テストする並列フローの数nは明確に指定する必要があります。実行されたベンチマークテストのそれぞれについて、各フレームサイズの列を含むテーブルが存在する必要があります。表には、適用されるフレームレートも記載する必要があります（SHOULD）。複数の値が報告されているベンチマーク（たとえば、セクション7.3.2で説明されているIPDV）の場合、各値の列を含める必要があります（SHOULD）。
Objective: To quantify the performance degradation introduced by n parallel and incrementally started network flows.
目的：n個の並列で増分的に開始されるネットワークフローによってもたらされるパフォーマンスの低下を定量化すること。
Procedure: First, the benchmarking tests presented in Section 7 have to be performed for one network flow.
手順：最初に、セクション7に示すベンチマークテストを1つのネットワークフローに対して実行する必要があります。
The same tests have to be repeated for n network flows, where the network flows are started incrementally in succession, each after time t. In other words, if flow i is started at time x, flow i+1 will be started at time x+t. Considering the time t, the time duration of each iteration must be extended with the time necessary to start all the flows, namely, (n-1)xt. The measurement for the first flow SHOULD be at least 60 seconds in duration.
同じテストをn個のネットワークフローに対して繰り返す必要があります。この場合、ネットワークフローは、時間tの後にそれぞれ連続して増分的に開始されます。言い換えると、フローiが時間xで開始される場合、フローi + 1は時間x + tで開始されます。時間tを考慮すると、各反復の継続時間は、すべてのフローを開始するのに必要な時間、つまり（n-1）xtで延長する必要があります。最初のフローの測定は、継続時間が60秒以上である必要があります。
The performance degradation of the x benchmarking dimension SHOULD be calculated as relative performance change between the 1-flow results and the n-flow results, using the formula presented in Section 10.2.1. Intermediary degradation points for 1/4*n, 1/2*n, and 3/4*n MAY also be performed.
xベンチマークディメンションのパフォーマンスの低下は、セクション10.2.1に示す式を使用して、1フローの結果とnフローの結果の間の相対的なパフォーマンスの変化として計算する必要があります（SHOULD）。 1/4 * n、1/2 * n、および3/4 * nの中間劣化ポイントも実行できます（MAY）。
Reporting Format: The performance degradation SHOULD be expressed as a percentage. The number of tested parallel flows n MUST be clearly specified. For each of the performed benchmarking tests, there SHOULD be a table containing a column for each frame size. The table SHOULD also state the applied frame rate and time duration T, which is used as an incremental step between the network flows. The units of measurement for T SHOULD be seconds. A column for the intermediary degradation points MAY also be displayed. In the case of benchmarks for which more than one value is reported (e.g., IPDV, discussed in Section 7.3.2), a column for each of the values SHOULD be included.
レポート形式：パフォーマンスの低下は、パーセンテージとして表現する必要があります（SHOULD）。テストする並列フローの数nは明確に指定する必要があります。実行されたベンチマークテストのそれぞれについて、各フレームサイズの列を含むテーブルが存在する必要があります。テーブルは、ネットワークフロー間の増分ステップとして使用される、適用されるフレームレートと期間Tも示す必要があります（SHOULD）。 Tの測定単位は秒です。中間劣化ポイントの列も表示される場合があります。複数の値が報告されているベンチマーク（たとえば、セクション7.3.2で説明されているIPDV）の場合、各値の列を含める必要があります（SHOULD）。
Although these technologies are not the primary scope of this document, the benchmarking methodology associated with single-translation technologies as defined in Section 4.1 can be employed to
これらのテクノロジーはこのドキュメントの主要な範囲ではありませんが、セクション4.1で定義されている単一翻訳テクノロジーに関連するベンチマーク手法を使用して、
benchmark implementations that use NAT44 (as defined by [RFC2663] with the behavior described by [RFC7857]) and implementations that use NAT66 (as defined by [RFC6296]).
NAT44を使用するベンチマーク実装（[RFC2663]で定義されている動作と[RFC7857]で説明されている動作）、およびNAT66を使用する実装（[RFC6296]で定義されている）。
To ensure the stability of the benchmarking scores obtained using the tests presented in Sections 7 through 9, multiple test iterations are RECOMMENDED. Using a summarizing function (or measure of central tendency) can be a simple and effective way to compare the results obtained across different iterations. However, over-summarization is an unwanted effect of reporting a single number.
セクション7から9で提示されたテストを使用して得られたベンチマークスコアの安定性を確保するために、複数のテストの反復が推奨されます。集計関数（または中心傾向の測定）を使用すると、異なる反復で得られた結果を比較するための簡単で効果的な方法になります。ただし、過剰な要約は、単一の数値を報告することの望ましくない影響です。
Measuring the variation (dispersion index) can be used to counter the over-summarization effect. Empirical data obtained following the proposed methodology can also offer insights on which summarizing function would fit better.
変動（分散指数）の測定を使用して、過集約効果に対抗することができます。提案された方法論に従って得られた経験的データは、どの集計機能がより適切に適合するかについての洞察を提供することもできます。
To that end, data presented in [ietf95pres] indicate the median as a suitable summarizing function and the 1st and 99th percentiles as variation measures for DNS Resolution Performance and PDV. The median and percentile calculation functions SHOULD follow the recommendations of Section 11.3 of [RFC2330].
そのため、[ietf95pres]に示されているデータは、中央値を適切な要約関数として示し、1番目と99番目のパーセンタイルをDNS解決パフォーマンスとPDVの変動尺度として示しています。中央値と百分位数の計算関数は、[RFC2330]のセクション11.3の推奨事項に従う必要があります。
For a fine-grained analysis of the frequency distribution of the data, histograms or cumulative distribution function plots can be employed.
データの頻度分布のきめ細かい分析には、ヒストグラムまたは累積分布関数プロットを使用できます。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているベンチマーク活動は、専用のアドレススペースと上記のセクションで指定された制約を使用して、実験環境で制御された刺激を使用した技術の特性評価に限定されます。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT or System Under Test (SUT). Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUTまたはSystem Under Test（SUT）の外部で観測可能な測定のみに依存します。特別な機能は、特にベンチマークの目的でDUT / SUTに存在すべきではありません。 DUT / SUTから生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります。
The IANA has allocated the prefix 2001:2::/48 [RFC5180] for IPv6 benchmarking. For IPv4 benchmarking, the 198.18.0.0/15 prefix was reserved, as described in [RFC6890]. The two ranges are sufficient for benchmarking IPv6 transition technologies. Thus, no action is requested.
IANAはIPv6ベンチマーク用にプレフィックス2001：2 :: / 48 [RFC5180]を割り当てました。 IPv4ベンチマークでは、[RFC6890]で説明されているように、198.18.0.0 / 15プレフィックスが予約されていました。 2つの範囲は、IPv6移行テクノロジのベンチマークに十分です。したがって、アクションは要求されません。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、DOI 10.17487 / RFC1242、1991年7月、<http://www.rfc-editor.org/info/rfc1242>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<http：//www.rfc -editor.org/info/rfc2330>。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<http://www.rfc-editor.org/info/rfc2544>。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <http://www.rfc-editor.org/info/rfc3393>.
[RFC3393] Demichelis、C。およびP. Chimento、「IP Performance Metrics（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、DOI 10.17487 / RFC3393、2002年11月、<http://www.rfc-editor.org / info / rfc3393>。
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, "Benchmarking Methodology for Firewall Performance", RFC 3511, DOI 10.17487/RFC3511, April 2003, <http://www.rfc-editor.org/info/rfc3511>.
[RFC3511] Hickman、B.、Newman、D.、Tadjudin、S。、およびT. Martin、「ファイアウォールパフォーマンスのベンチマーク手法」、RFC 3511、DOI 10.17487 / RFC3511、2003年4月、<http：//www.rfc -editor.org/info/rfc3511>。
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, <http://www.rfc-editor.org/info/rfc5180>.
[RFC5180] Popoviciu、C.、Hamza、A.、Van de Velde、G。、およびD. Dugatkin、「ネットワーク相互接続デバイスのIPv6ベンチマーク手法」、RFC 5180、DOI 10.17487 / RFC5180、2008年5月、<http：/ /www.rfc-editor.org/info/rfc5180>。
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、DOI 10.17487 / RFC5481、2009年3月、<http://www.rfc-editor.org/info/rfc5481>。
[RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, "Device Reset Characterization", RFC 6201, DOI 10.17487/RFC6201, March 2011, <http://www.rfc-editor.org/info/rfc6201>.
[RFC6201] Asati、R.、Pignataro、C.、Calabria、F。、およびC. Olvera、「Device Reset Characterization」、RFC 6201、DOI 10.17487 / RFC6201、2011年3月、<http：//www.rfc-editor .org / info / rfc6201>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<http://www.rfc-editor.org/info / rfc2663>。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、DOI 10.17487 / RFC4213、2005年10月、<http://www.rfc-editor.org/info/rfc4213 >。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, <http://www.rfc-editor.org/info/rfc4659>.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP Virtual Private Network（VPN）Extension for IPv6 VPN」、RFC 4659、DOI 10.17487 / RFC4659、 2006年9月、<http://www.rfc-editor.org/info/rfc4659>。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, <http://www.rfc-editor.org/info/rfc4798>.
[RFC4798] De Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用したIPv4 MPLSを介したIPv6アイランドの接続」、RFC 4798、DOI 10.17487 / RFC4798、 2007年2月、<http://www.rfc-editor.org/info/rfc4798>。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, January 2010, <http://www.rfc-editor.org/info/rfc5569>.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、DOI 10.17487 / RFC5569、2010年1月、<http://www.rfc-editor.org/info/rfc5569>。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4 / IPv6変換のフレームワーク」、RFC 6144、DOI 10.17487 / RFC6144、2011年4月、<http：// www。 rfc-editor.org/info/rfc6144>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to RFC」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<http://www.rfc-editor.org/info/rfc6147>。
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <http://www.rfc-editor.org/info/rfc6219>.
[RFC6219] Li、X.、Bao、C.、Chen、M.、Zhang、H。、およびJ. Wu、「IPv4 / IPv6共存のための中国教育研究ネットワーク（CERNET）IVI変換設計および導入移行」、RFC 6219、DOI 10.17487 / RFC6219、2011年5月、<http://www.rfc-editor.org/info/rfc6219>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<http://www.rfc-editor.org/info/rfc6296 >。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877] Mawatari、M.、Kawashima、M。、およびC. Byrne、「464XLAT：Combination of Stateful and Stateless Translation」、RFC 6877、DOI 10.17487 / RFC6877、2013年4月、<http：//www.rfc-editor .org / info / rfc6877>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<http://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<http://www.rfc-editor.org/info/rfc7597>。
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7599] Li、X.、Bao、C.、Dec、W.、Ed。、Troan、O.、Matsushima S.、T。Murakami、「変換を使用したアドレスとポートのマッピング（MAP-T）」 、RFC 7599、DOI 10.17487 / RFC7599、2015年7月、<http://www.rfc-editor.org/info/rfc7599>。
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <http://www.rfc-editor.org/info/rfc7857>.
[RFC7857] Penno、R.、Perreault、S.、Boucadair、M.、Ed。、Sivakumar、S.、and K. Naito、 "Updates to Network Address Translation（NAT）Behavioral Requirements"、BCP 127、RFC 7857、 DOI 10.17487 / RFC7857、2016年4月、<http://www.rfc-editor.org/info/rfc7857>。
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <http://www.rfc-editor.org/info/rfc7915>.
[RFC7915] Bao、C.、Li、X.、Baker、F.、Anderson、T。、およびF. Gont、「IP / ICMP変換アルゴリズム」、RFC 7915、DOI 10.17487 / RFC7915、2016年6月、<http： //www.rfc-editor.org/info/rfc7915>。
[Dns64perf] Bakai, D., "A C++11 DNS64 performance tester", <https://github.com/bakaid/dns64perfpp>.
[Dns64perf] Bakai、D。、「A C ++ 11 DNS64 Performance Tester」、<https://github.com/bakaid/dns64perfpp>。
[ietf95pres] Georgescu, M., "Benchmarking Methodology for IPv6 Transition Technologies", IETF 95 Proceedings, Buenos Aires, Argentina, April 2016, <https://www.ietf.org/proceedings/95/slides/ slides-95-bmwg-2.pdf>.
[ietf95pres] Georgescu、M。、「IPv6移行テクノロジのベンチマーク手法」、IETF 95 Proceedings、ブエノスアイレス、アルゼンチン、2016年4月、<https://www.ietf.org/proceedings/95/slides/ slides-95- bmwg-2.pdf>。
[Lencse1] Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", Computer
Communications, vol. 109, no. 1, pp. 162-175,
DOI 10.1016/j.comcom.2017.06.004, September 2017,
<http://www.sciencedirect.com/science/article/pii/
S0140366416305904?via%3Dihub>
[Lencse2] Lencse, G. and D. Bakai, "Design and Implementation of a Test Program for Benchmarking DNS64 Servers", IEICE Transactions on Communications, Vol. E100-B, No. 6, pp. 948-954, DOI 10.1587/transcom.2016EBN0007, June 2017, <https://www.jstage.jst.go.jp/article/transcom/E100.B/ 6/E100.B_2016EBN0007/_article>.
[Lencse2] Lencse、G.およびD. Bakai、「DNS64サーバーのベンチマーク用テストプログラムの設計と実装」、電子情報通信学会論文誌、Vol。 E100-B、No。6、pp.948-954、DOI 10.1587 / transcom.2016EBN0007、2017年6月、<https://www.jstage.jst.go.jp/article/transcom/E100.B/ 6 / E100 .B_2016EBN0007 / _article>。
[Lencse3] dns64perfppc, <http://www.hit.bme.hu/~lencse/dns64perfppc/>.
[Lencse3] dns64perfppc、<http://www.hit.bme.hu/~lencse/dns64perfppc/>。
[Lencse4] Lencse, G., "Enabling Dns64perf++ for Benchmarking the Caching Performance of DNS64 Servers", unpublished, review version, <http://www.hit.bme.hu/~lencse/publications/ IEICE-2016-dns64perfppc-for-review.pdf>.
[Lencse4] Lencse、G。、「DNS64サーバーのキャッシュパフォーマンスのベンチマークのためのDns64perf ++の有効化」、非公開、レビューバージョン、<http://www.hit.bme.hu/~lencse/publications/ IEICE-2016-dns64perfppc- for-review.pdf>。
[IEEE802.1AC] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Service Definition", IEEE 802.1AC.
[IEEE802.1AC] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Service Definition」、IEEE 802.1AC。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q.
[IEEE802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q。
This appendix describes the recommended calculation formulas for the theoretical maximum frame rates to be employed over Ethernet as example media. The formula takes into account the frame size overhead created by the encapsulation or translation process. For example, the 6in4 encapsulation described in [RFC4213] adds 20 bytes of overhead to each frame.
この付録では、サンプルメディアとしてイーサネット経由で使用される理論上の最大フレームレートの推奨計算式について説明します。この式では、カプセル化または変換プロセスによって生じるフレームサイズのオーバーヘッドが考慮されます。たとえば、[RFC4213]で説明されている6in4カプセル化は、各フレームに20バイトのオーバーヘッドを追加します。
Considering X to be the frame size and O to be the frame size overhead created by the encapsulation or translation process, the maximum theoretical frame rate for Ethernet can be calculated using the following formula:
Xをフレームサイズ、Oをカプセル化または変換プロセスによって作成されるフレームサイズのオーバーヘッドと見なすと、イーサネットの理論上の最大フレームレートは、次の式を使用して計算できます。
Line Rate (bps)
------------------------------------
(8 bits/byte) * (X+O+20) bytes/frame
The calculation is based on the formula recommended by [RFC5180] in Appendix A.1. As an example, the frame rate recommended for testing a 6in4 implementation over 10 Mb/s Ethernet with 64 bytes frames is:
計算は、付録A.1の[RFC5180]で推奨されている式に基づいています。例として、64バイトフレームの10 Mb / sイーサネットを介した6in4実装のテストに推奨されるフレームレートは次のとおりです。
10,000,000 (bps)
-------------------------------------- = 12,019 fps
(8 bits/byte) * (64+20+20) bytes/frame
The complete list of recommended frame rates for 6in4 encapsulation can be found in the following table:
6in4カプセル化の推奨フレームレートの完全なリストは、次の表にあります。
+------------+---------+----------+-----------+------------+
| Frame size | 10 Mb/s | 100 Mb/s | 1000 Mb/s | 10000 Mb/s |
| (bytes) | (fps) | (fps) | (fps) | (fps) |
+------------+---------+----------+-----------+------------+
| 64 | 12,019 | 120,192 | 1,201,923 | 12,019,231 |
| 128 | 7,440 | 74,405 | 744,048 | 7,440,476 |
| 256 | 4,223 | 42,230 | 422,297 | 4,222,973 |
| 512 | 2,264 | 22,645 | 226,449 | 2,264,493 |
| 678 | 1,740 | 17,409 | 174,094 | 1,740,947 |
| 1024 | 1,175 | 11,748 | 117,481 | 1,174,812 |
| 1280 | 947 | 9,470 | 94,697 | 946,970 |
| 1518 | 802 | 8,023 | 80,231 | 802,311 |
| 1522 | 800 | 8,003 | 80,026 | 800,256 |
| 2048 | 599 | 5,987 | 59,866 | 598,659 |
| 4096 | 302 | 3,022 | 30,222 | 302,224 |
| 8192 | 152 | 1,518 | 15,185 | 151,846 |
| 9216 | 135 | 1,350 | 13,505 | 135,048 |
+------------+---------+----------+-----------+------------+
Acknowledgements
謝辞
The authors thank Youki Kadobayashi and Hiroaki Hazeyama for their constant feedback and support. The thanks should be extended to the NECOMA project members for their continuous support. We thank Emanuel Popa, Ionut Spirlea, and the RCS&RDS IP/MPLS Backbone Team for their support and insights. We thank Scott Bradner for the useful suggestions and note that portions of text from Scott's documents were used in this memo (e.g., the "Latency" section). A big thank you to Al Morton and Fred Baker for their detailed review of the document and very helpful suggestions. Other helpful comments and suggestions were offered by Bhuvaneswaran Vengainathan, Andrew McGregor, Nalini Elkins, Kaname Nishizuka, Yasuhiro Ohara, Masataka Mawatari, Kostas Pentikousis, Bela Almasi, Tim Chown, Paul Emmerich, and Stenio Fernandes. A special thank you to the RFC Editor Team for their thorough editorial review and helpful suggestions.
執筆者は、常にフィードバックとサポートを提供してくれた門林洋貴と羽山広章に感謝します。 NECOMAプロジェクトメンバーの皆様には、引き続きご支援を賜りますようお願い申し上げます。 Emanuel Popa、Ionut Spirlea、およびRCS＆RDS IP / MPLSバックボーンチームのサポートと洞察に感謝します。有益な提案をしてくれたScott Bradnerに感謝し、Scottのドキュメントのテキストの一部がこのメモで使用されたことに注意してください（たとえば、「待ち時間」セクション）。ドキュメントの詳細なレビューと非常に役立つアドバイスを提供してくれたAl MortonとFred Bakerに感謝します。その他の役立つコメントと提案は、ブヴァネスワランヴェンゲイナサン、アンドリューマックレガー、ナリーニエルキンス、西塚要、小原康弘、馬渡正孝、コスタスペンティコウシス、ベラアルマシ、ティムチョウン、ポールエメリッヒ、ステニーオフェルナンデスによって提供されました。徹底的な編集レビューと有用な提案をしてくれたRFC Editorチームに特別に感謝します。
Authors' Addresses
著者のアドレス
Marius Georgescu RCS&RDS Strada Dr. Nicolae D. Staicovici 71-75 Bucharest 030167 Romania
Marius Georgescu RCS＆RDS Dr. Nicolae D. Staicovici Street 71-75 Bucharest 030167ルーマニア
Phone: +40 31 005 0979
Email: marius.georgescu@rcs-rds.ro
Liviu Pislaru RCS&RDS Strada Dr. Nicolae D. Staicovici 71-75 Bucharest 030167 Romania
リビウピスラルRCS＆RDSストラーダ博士Nicolae D.Staicovici 71-75ブカレスト030167ルーマニア
Phone: +40 31 005 0979
Email: liviu.pislaru@rcs-rds.ro
Gabor Lencse Szechenyi Istvan University Egyetem ter 1. Gyor Hungary
ガボールレンツェセーチェーニイストヴァン大学ter 1.ジョールハンガリー
Phone: +36 20 775 8267
Email: lencse@sze.hu