Internet Engineering Task Force (IETF) G. Lencse
Request for Comments: 9693 Széchenyi István University
Category: Informational K. Shima
ISSN: 2070-1721 SoftBank Corp.
January 2025
RFC 2544 defines a benchmarking methodology for network interconnect devices. RFC 5180 addresses IPv6 specificities, and it also provides a technology update but excludes IPv6 transition technologies. RFC 8219 addresses IPv6 transition technologies, including stateful NAT64. However, none of them discuss how to apply pseudorandom port numbers from RFC 4814 to any stateful NATxy (such as NAT44, NAT64, and NAT66) technologies. This document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. It recommends a solution that limits the port number ranges and uses two test phases (phase 1 and phase 2). This document shows how the classic performance measurement procedures (e.g., throughput, frame loss rate, latency, etc.) can be carried out. New performance metrics and measurement procedures are also defined for measuring the maximum connection establishment rate, connection tear-down rate, and connection tracking table capacity.
RFC 2544は、ネットワーク相互接続デバイスのベンチマーク方法論を定義します。RFC 5180はIPv6の特異性に対応し、テクノロジーの更新も提供しますが、IPv6トランジションテクノロジーは除外されます。RFC 8219は、Stateful NAT64を含むIPv6トランジションテクノロジーに対処します。ただし、RFC 4814から擬似ランダムポート番号をステートフルNATXY（NAT44、NAT64、NAT66など）テクノロジーに適用する方法については何も議論していません。このドキュメントでは、Steudorandomポート番号をStateful Natxy Gatewaysで使用することが難しい問題である理由について説明します。ポート番号の範囲を制限し、2つのテストフェーズ（フェーズ1とフェーズ2）を使用するソリューションを推奨します。このドキュメントは、古典的なパフォーマンス測定手順（スループット、フレーム損失率、レイテンシなど）を実行する方法を示しています。新しいパフォーマンスメトリックと測定手順は、最大接続の確立レート、接続の引き裂きレート、および接続追跡テーブル容量を測定するために定義されています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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 https://www.rfc-editor.org/info/rfc9693.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9693で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
2. Pseudorandom Port Numbers and Stateful Translation
3. Test Setup and Terminology
3.1. When Testing with a Single IP Address Pair
3.2. When Testing with Multiple IP Addresses
4. Recommended Benchmarking Method
4.1. Restricted Number of Network Flows
4.2. Test Phase 1
4.3. Consideration of the Cases of Stateful Operation
4.4. Control of the Connection Tracking Table Entries
4.5. Measurement of the Maximum Connection Establishment Rate
4.6. Validation of Connection Establishment
4.7. Test Phase 2
4.8. Measurement of the Connection Tear-Down Rate
4.9. Measurement of the Connection Tracking Table Capacity
4.10. Writing and Reading Order of the State Table
5. Scalability Measurements
5.1. Scalability Against the Number of Network Flows
5.2. Scalability Against the Number of CPU Cores
6. Reporting Format
7. Implementation and Experience
8. Limitations of Using UDP as a Transport Layer Protocol
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
[RFC2544] defines a comprehensive benchmarking methodology for network interconnect devices that is still in use. It is mainly independent of IP version, but it uses IPv4 in its examples. [RFC5180] addresses IPv6 specificities and also adds technology updates but declares IPv6 transition technologies are out of its scope. [RFC8219] addresses the IPv6 transition technologies, including stateful NAT64. It reuses several benchmarking procedures from [RFC2544] (e.g., throughput, frame loss rate), and it redefines the latency measurement and adds further ones (e.g., the Packet Delay Variation (PDV) measurement).
[RFC2544]は、まだ使用されているネットワーク相互接続デバイスの包括的なベンチマーク方法論を定義しています。主にIPバージョンから独立していますが、例ではIPv4を使用しています。[RFC5180]はIPv6の特異性に対処し、テクノロジーの更新も追加しますが、IPv6トランジションテクノロジーはその範囲外であると宣言します。[RFC8219]は、ステートフルNAT64を含むIPv6遷移技術に対処します。[RFC2544]（たとえば、スループット、フレームの損失率）からいくつかのベンチマーク手順を再利用し、レイテンシ測定を再定義し、さらなるもの（たとえば、パケット遅延変動（PDV）測定）を追加します。
However, none of them discuss how to apply pseudorandom port numbers from [RFC4814] when benchmarking stateful NATxy gateways (such as NAT44 [RFC3022], NAT64 [RFC6146], and NAT66). (It should be noted that stateful NAT66 is not an IETF specification but refers to an IPv6 version of the stateful NAT44 specification.) The authors are not aware of any other RFCs that address this question.
ただし、ステートフルなNatxyゲートウェイ（Nat44 [RFC3022]、Nat64 [RFC6146]、Nat66など）のベンチマーク時に[RFC4814]から擬似ランダム番号を適用する方法については何も議論していません。（Stateful NAT66はIETF仕様ではなく、Stateful NAT44仕様のIPv6バージョンを指します。）著者は、この質問に対処する他のRFCを認識していません。
First, this document discusses why using pseudorandom port numbers with stateful NATxy gateways is a difficult problem. Then, a solution is recommended.
まず、このドキュメントでは、Stateful Natxyゲートウェイで擬似ランダムポート番号を使用することが難しい問題である理由について説明します。次に、ソリューションをお勧めします。
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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In its appendix, [RFC2544] defines a frame format for test frames, including specific source and destination port numbers. [RFC4814] recommends using pseudorandom and uniformly distributed values for both source and destination port numbers. However, stateful NATxy (such as NAT44, NAT64, and NAT66) solutions use the port numbers to identify connections. The usage of pseudorandom port numbers causes different problems depending on the direction:
付録では、[RFC2544]は、特定のソースおよび宛先ポート番号を含むテストフレームのフレーム形式を定義しています。[RFC4814]は、ソースと宛先ポート番号の両方に擬似ランダムと均一に分布した値を使用することをお勧めします。ただし、Stateful Natxy（Nat44、Nat64、Nat66など）ソリューションは、ポート番号を使用して接続を識別します。擬似ランダムポート番号の使用は、方向に応じて異なる問題を引き起こします。
* For the client-to-server direction, pseudorandom source and destination port numbers could be used; however, this approach would be a denial-of-service attack against the stateful NATxy gateway, because it would exhaust its connection tracking table capacity. To that end, let us see some calculations using the recommendations of [RFC4814]:
* クライアントからサーバーへの方向には、擬似ランダムソースと宛先ポート番号を使用できます。ただし、このアプローチは、接続トラッキングテーブル容量を使い果たすため、ステートフルNatxyゲートウェイに対するサービス拒否攻撃です。そのために、[RFC4814]の推奨事項を使用して、いくつかの計算を見てみましょう。
- The recommended source port range is 1024-65535; thus, its size is 64512.
- 推奨されるソースポート範囲は1024-65535です。したがって、そのサイズは64512です。
- The recommended destination port range is 1-49151; thus, its size is 49151.
- 推奨宛先ポートレンジは1-49151です。したがって、そのサイズは49151です。
- The number of source and destination port number combinations is 3,170,829,312.
- ソースと宛先のポート番号の組み合わせの数は3,170,829,312です。
It should be noted that the usage of different source and destination IP addresses further increases the number of connection tracking table entries.
異なるソースと宛先IPアドレスの使用により、接続追跡テーブルエントリの数がさらに増加することに注意してください。
* For the server-to-client direction, the stateful Device Under Test (DUT) would drop any packets that do not belong to an existing connection; therefore, the direct usage of pseudorandom port numbers from the ranges mentioned above is not feasible.
* サーバーからクライアントへの方向の場合、テスト中のステートフルデバイス（DUT）は、既存の接続に属さないパケットをドロップします。したがって、上記の範囲からの擬似ランダムポート番号を直接使用することは実行不可能です。
Section 12 of [RFC2544] requires testing using a single protocol source and destination address pair first and then also using multiple protocol addresses. The same approach is followed: first, a single source and destination IP address pair is used, and then it is explained how to use multiple IP addresses.
[RFC2544]のセクション12では、最初に単一のプロトコルソースと宛先アドレスペアを使用して、複数のプロトコルアドレスを使用してテストする必要があります。同じアプローチが続きます。最初に、単一のソースと宛先IPアドレスペアが使用され、次に複数のIPアドレスの使用方法が説明されています。
The methodology works with any IP version to benchmark stateful NATxy gateways, where x and y are in {4, 6}. To facilitate an easy understanding, two typical examples are used: stateful NAT44 and stateful NAT64.
方法論は、任意のIPバージョンと連携して、xとyが{4、6}にあるステートフルなNatxyゲートウェイをベンチマークします。簡単に理解を促進するために、2つの典型的な例が使用されます：Stateful Nat44とStateful Nat64。
The test setup for the well-known stateful NAT44 (also called Network Address and Port Translation (NAPT)) solution is shown in Figure 1.
よく知られているステートフルNAT44（ネットワークアドレスとポート翻訳（NAPT）とも呼ばれる）のテストセットアップを図1に示します。
Note that the private IP addresses from [RFC1918] are used to facilitate an easy understanding of the example, and the usage of the IP addresses reserved for benchmarking is absolutely legitimate.
[RFC1918]のプライベートIPアドレスは、例の簡単な理解を促進するために使用され、ベンチマーク用に予約されたIPアドレスの使用は絶対に合法であることに注意してください。
+--------------------------------------+
10.0.0.2 |Initiator Responder| 198.19.0.2
+-------------| Tester |<------------+
| private IPv4| [state table]| public IPv4 |
| +--------------------------------------+ |
| |
| +--------------------------------------+ |
| 10.0.0.1 | DUT: | 198.19.0.1 |
+------------>| Stateful NAT44 gateway |-------------+
private IPv4| [connection tracking table] | public IPv4
+--------------------------------------+
Figure 1: Test Setup for Benchmarking Stateful NAT44 Gateways
図1：Stateful Nat44ゲートウェイのベンチマークのテストセットアップ
The test setup for the stateful NAT64 solution [RFC6146], which is also widely used, is shown in Figure 2.
Stateful Nat64ソリューション[RFC6146]のテストセットアップも広く使用されていますが、図2に示されています。
+--------------------------------------+
2001:2::2 |Initiator Responder| 198.19.0.2
+-------------| Tester |<------------+
| IPv6 address| [state table]| IPv4 address|
| +--------------------------------------+ |
| |
| +--------------------------------------+ |
| 2001:2::1 | DUT: | 198.19.0.1 |
+------------>| Stateful NAT64 gateway |-------------+
IPv6 address| [connection tracking table] | IPv4 address
+--------------------------------------+
Figure 2: Test Setup for Benchmarking Stateful NAT64 Gateways
図2：Stateful Nat64ゲートウェイのベンチマークのテストセットアップ
As for the transport layer protocol, [RFC2544] recommended testing with UDP, and it was also kept in [RFC8219]. UDP is also kept for a general recommendation; thus, the port numbers in the following text are to be understood as UDP port numbers. The rationale and limitations of this approach are discussed in Section 8.
輸送層プロトコルについては、[RFC2544]はUDPでのテストを推奨し、[RFC8219]にも保持されました。UDPは、一般的な推奨のためにも保持されています。したがって、次のテキストのポート番号は、UDPポート番号として理解されます。このアプローチの理論的根拠と制限については、セクション8で説明します。
The most important elements of the proposed benchmarking system are defined as follows:
提案されたベンチマークシステムの最も重要な要素は、次のように定義されています。
Connection:
繋がり：
Although UDP itself is a connectionless protocol, stateful NATxy gateways keep track of their translation mappings in the form of a "connection" as well as in the case of UDP using the same kind of entries as in TCP.
UDP自体はコネクションレスプロトコルですが、Stateful Natxy Gatewaysは、TCPと同じ種類のエントリを使用してUDPの場合と同様に、「接続」の形で翻訳マッピングを追跡します。
Connection tracking table:
接続追跡テーブル：
The stateful NATxy gateway uses a connection tracking table to be able to perform the stateful translation in the server-to-client direction. Its size, policy, and content are unknown to the Tester.
ステートフルなNatxy Gatewayは、接続追跡テーブルを使用して、サーバーからクライアントの方向でステートフルな翻訳を実行できるようにします。そのサイズ、ポリシー、およびコンテンツは、テスターには不明です。
Four tuple:
4タプル：
The four numbers that identify a connection are source IP address, source port number, destination IP address, and destination port number.
接続を識別する4つの数値は、ソースIPアドレス、ソースポート番号、宛先IPアドレス、および宛先ポート番号です。
State table:
州の表：
The Responder of the Tester extracts the four tuple from each received test frame and stores it in its state table. A recommendation is given for the writing and reading order of the state table in Section 4.10.
テスターの応答者は、受信した各テストフレームから4つのタプルを抽出し、状態テーブルに保存します。セクション4.10の州テーブルの執筆と読み取り順序の推奨事項が与えられます。
Initiator:
イニシエータ：
The port of the Tester that may initiate a connection through the stateful DUT in the client-to-server direction. Theoretically, it can use any source and destination port numbers from the ranges recommended by [RFC4814]: if the used four tuple does not belong to an existing connection, the DUT will register a new connection into its connection tracking table.
クライアント間方向のステートフルDUTを介して接続を開始する可能性のあるテスターのポート。理論的には、[RFC4814]が推奨する範囲からのソースおよび宛先ポート番号を使用できます。使用済みの4つのタプルが既存の接続に属していない場合、DUTは接続追跡テーブルに新しい接続を登録します。
Responder:
レスポンダー：
The port of the Tester that may not initiate a connection through the stateful DUT in the server-to-client direction. It may only send frames that belong to an existing connection. To that end, it uses four tuples that have been previously extracted from the received test frames and stores in its state table.
サーバーからクライアントの方向にあるステートフルなDUTを介して接続を開始できない可能性のあるテスターのポート。既存の接続に属するフレームのみを送信する場合があります。そのために、受信したテストフレームとその状態テーブルのストアから以前に抽出された4つのタプルを使用します。
Test phase 1:
テストフェーズ1：
The test frames are sent only by the Initiator to the Responder through the DUT to fill both the connection tracking table of the DUT and the state table of the Responder. This is a newly introduced operation phase for stateful NATxy benchmarking. The necessity of this test phase is explained in Section 4.2.
テストフレームは、DUTを介してイニシエーターによってのみResponderに送信され、DUTの接続追跡テーブルとResponderの状態テーブルの両方を埋めます。これは、Stateful Natxyベンチマークのために新しく導入された操作フェーズです。このテストフェーズの必要性については、セクション4.2で説明します。
Test phase 2:
テストフェーズ2：
The measurement procedures defined by [RFC8219] (e.g., throughput, latency, etc.) are performed in this test phase after the completion of test phase 1. Test frames are sent as required (e.g., a bidirectional test or a unidirectional test in any of the two directions).
[RFC8219]（例えば、スループット、レイテンシなど）で定義された測定手順は、テストフェーズ1の完了後にこのテストフェーズで実行されます。テストフレームは必要に応じて送信されます（例：双方向テストまたは単方向テストで2つの方向の）。
One further definition is used in the text of this document:
このドキュメントのテキストでは、さらに1つの定義が使用されています。
Black box testing:
ブラックボックステスト：
A testing approach when the Tester is not aware of the details of the internal structure and operation of the DUT. It can send input to the DUT and observe the output of the DUT.
テスターがDUTの内部構造と操作の詳細を認識していない場合のテストアプローチ。DUTに入力を送信し、DUTの出力を観察することができます。
This section considers the number of the necessary and available IP addresses.
このセクションでは、必要なIPアドレスと利用可能なIPアドレスの数を検討します。
In Figure 1, the single 198.19.0.1 IPv4 address is used on the WAN side port of the stateful NAT44 gateway. However, in practice, it is not a single IP address, but rather an IP address range that is assigned to the WAN side port of the stateful NAT44 gateways. Its required size depends on the number of client nodes and on the type of the stateful NAT44 algorithm. (The traditional algorithm always replaces the source port number when a new connection is established. Thus, it requires a larger range than the extended algorithm, which replaces the source port number only when it is necessary. Please refer to Tables 1 and 2 of [LEN2015].)
図1では、シングル198.19.0.1 IPv4アドレスが、ステートフルNAT44ゲートウェイのWAN側ポートで使用されています。ただし、実際には、単一のIPアドレスではなく、ステートフルNAT44ゲートウェイのWAN側ポートに割り当てられたIPアドレス範囲です。必要なサイズは、クライアントノードの数と、ステートフルNAT44アルゴリズムのタイプに依存します。（新しい接続が確立されている場合、従来のアルゴリズムは常にソースポート番号を置き換えます。したがって、必要な場合にのみソースポート番号を置き換える拡張アルゴリズムよりも大きい範囲が必要です。len2015]。）
When router testing is done, Section 12 of [RFC2544] requires testing using a single source and destination IP address pair first and then using destination IP addresses from 256 different networks. The 16-23 bits of the 198.18.0.0/24 and 198.19.0.0/24 addresses can be used to express the 256 networks. As this document does not deal with router testing, no multiple destination networks are needed; therefore, these bits are available for expressing multiple IP addresses that belong to the same "/16" network. Moreover, both the 198.18.0.0/16 and the 198.19.0.0/16 networks can be used on the right side of the test setup, as private IP addresses from the 10.0.0.0/16 network are used on its left side.
ルーターテストが完了した場合、[RFC2544]のセクション12では、最初に単一のソースと宛先IPアドレスペアを使用してテストを必要とし、次に256の異なるネットワークの宛先IPアドレスを使用してテストする必要があります。198.18.0.0/24および198.19.0.0/24のアドレスの16〜23ビットを使用して、256のネットワークを表現できます。このドキュメントはルーターテストを扱っていないため、複数の宛先ネットワークは必要ありません。したがって、これらのビットは、同じ「/16」ネットワークに属する複数のIPアドレスを表現するために使用できます。さらに、198.18.0.0/16と198.19.0.0/16ネットワークは、10.0.0.0/16ネットワークのプライベートIPアドレスが左側に使用されるため、テストセットアップの右側で使用できます。
10.0.0.2/16 - 10.0.255.254/16 198.19.0.0/15 - 198.19.255.254/15
\ +--------------------------------------+ /
\ |Initiator Responder| /
+-------------| Tester |<------------+
| private IPv4| [state table]| public IPv4 |
| +--------------------------------------+ |
| |
| +--------------------------------------+ |
| 10.0.0.1/16 | DUT: | public IPv4 |
+------------>| Stateful NAT44 gateway |-------------+
private IPv4| [connection tracking table] | \
+--------------------------------------+ \
198.18.0.1/15 - 198.18.255.255/15
Figure 3: Test Setup for Benchmarking Stateful NAT44 Gateways Using Multiple IPv4 Addresses
図3：複数のIPv4アドレスを使用して、ステートフルなNAT44ゲートウェイをベンチマークするためのテストセットアップ
A possible solution for assigning multiple IPv4 addresses is shown in Figure 3. On the left side, the private IP address range is abundantly large. (The 16-31 bits were used for generating nearly 64k potential different source addresses, but the 8-15 bits are also available if needed.) On the right side, the 198.18.0.0./15 network is used, and it was cut into two equal parts. (Asymmetric division is also possible, if needed.)
複数のIPv4アドレスを割り当てるための可能なソリューションを図3に示します。左側では、プライベートIPアドレス範囲が豊富に大きくなっています。（16-31ビットは、64K近くの潜在的な異なるソースアドレスを生成するために使用されましたが、必要に応じて8〜15ビットも利用できます。）右側では、198.18.0.0./15ネットワークが使用され、カットされました2つの等しい部分に。（必要に応じて、非対称分割も可能です。）
It should be noted that these are the potential address ranges. The actual address ranges to be used are discussed in Section 4.1.
これらは潜在的なアドレス範囲であることに注意する必要があります。使用する実際のアドレス範囲については、セクション4.1で説明します。
In the case of stateful NAT64, a single "/64" IPv6 prefix contains a high number of bits to express different IPv6 addresses. Figure 4 shows an example where bits 96-111 are used for that purpose.
Stateful NAT64の場合、単一の「/64」IPv6プレフィックスには、異なるIPv6アドレスを表現するための多数のビットが含まれています。図4は、その目的のためにビット96-111が使用される例を示しています。
2001:2::[0000-ffff]:0002/64 198.19.0.0/15 - 198.19.255.254/15
\ +--------------------------------------+ /
IPv6 \ |Initiator Responder| /
+-------------| Tester |<------------+
| addresses | [state table]| public IPv4 |
| +--------------------------------------+ |
| |
| +--------------------------------------+ |
| 2001:2::1/64| DUT: | public IPv4 |
+------------>| Stateful NAT64 gateway |-------------+
IPv6 address | [connection tracking table] | \
+--------------------------------------+ \
198.18.0.1/15 - 198.18.255.255/15
Figure 4: Test Setup for Benchmarking Stateful NAT64 Gateways Using Multiple IPv6 and IPv4 Addresses
図4：複数のIPv6およびIPv4アドレスを使用して、ステートフルなNAT64ゲートウェイをベンチマークするためのテストセットアップ
When a single IP address pair is used for testing, then the number of network flows is determined by the number of source and destination port number combinations.
単一のIPアドレスペアがテストに使用される場合、ネットワークフローの数は、ソースと宛先のポート番号の組み合わせの数によって決まります。
The Initiator SHOULD use restricted ranges for source and destination port numbers to avoid the exhaustion of the connection tracking table capacity of the DUT as described in Section 2. If it is possible, the size of the source port number range SHOULD be larger (e.g., in the order of a few tens of thousands), whereas the size of the destination port number range SHOULD be smaller (e.g., it may vary from a few to several hundreds or thousands as needed). The rationale is that source and destination port numbers that can be observed in Internet traffic are not symmetrical. Whereas source port numbers may be random, there are a few very popular destination port numbers (e.g., 443 or 80; see [IIR2020]), and others hardly occur. Additionally, it was found that their role is also asymmetric in the Linux kernel routing hash function [LEN2020].
イニシエーターは、セクション2で説明されているように、DUTの接続追跡テーブル容量の消耗を回避するために、ソースおよび宛先ポート番号に制限範囲を使用する必要があります。可能であれば、ソースポート番号範囲のサイズは大きくする必要があります（例：数万の順序で）、宛先ポート番号の範囲のサイズは小さくする必要があります（たとえば、必要に応じて数百または数千から数千から数千から数千から数千から数千から数千から数千かかります）。理論的根拠は、インターネットトラフィックで観察できるソースおよび宛先ポート番号が対称ではないということです。ソースポート番号はランダムかもしれませんが、非常に人気のある宛先ポート番号（443または80; [IIR2020]を参照）がいくつかあり、その他はほとんど発生しません。さらに、それらの役割はLinuxカーネルルーティングハッシュ関数[LEN2020]でも非対称であることがわかりました。
However, in some special cases, the size of the source port range is limited. For example, when benchmarking the Customer Edge (CE) and Border Relay (BR) of a Mapping of Address and Port using Translation (MAP-T) system [RFC7599] together (as a compound system performing stateful NAT44), the source port range is limited to the number of source port numbers assigned to each subscriber. (It could be as low as 2048 ports.)
ただし、特別な場合には、ソースポート範囲のサイズが制限されています。たとえば、翻訳（MAP-T）システム[RFC7599]を使用したアドレスとポートのマッピングの顧客エッジ（CE）とボーダーリレー（BR）を一緒にベンチマークするとき（ステートフルNAT44を実行する複合システムとして）、ソースポート範囲は各サブスクライバーに割り当てられたソースポート番号の数に制限されています。（2048ポートと同じくらい低いかもしれません。）
When multiple IP addresses are used, then the port number ranges should be even more restricted, as the number of potential network flows is the product of the size of:
複数のIPアドレスを使用する場合、潜在的なネットワークフローの数は次のサイズの積であるため、ポート番号の範囲はさらに制限される必要があります。
* the source IP address range,
* ソースIPアドレス範囲、
* the source port number range,
* ソースポート番号の範囲、
* the destination IP address range, and
* 宛先IPアドレスの範囲、および
* the destination port number range.
* 宛先ポート番号の範囲。
In addition, the recommended method requires the enumeration of all their possible combinations in test phase 1 as described in Section 4.4.
さらに、推奨される方法では、セクション4.4で説明されているように、テストフェーズ1のすべての可能な組み合わせの列挙が必要です。
The number of network flows can be used as a parameter. The performance of the stateful NATxy gateway MAY be examined as a function of this parameter as described in Section 5.1.
ネットワークフローの数は、パラメーターとして使用できます。Stateful Natxyゲートウェイのパフォーマンスは、セクション5.1で説明されているように、このパラメーターの関数として調べることができます。
Test phase 1 serves two purposes:
テストフェーズ1は2つの目的を果たします。
1. The connection tracking table of the DUT is filled. This is important because its maximum connection establishment rate may be lower than its maximum frame forwarding rate (that is, its throughput).
1. DUTの接続追跡テーブルが満たされています。これは、最大接続確立率が最大フレーム転送レート（つまりスループット）よりも低い可能性があるため重要です。
2. The state table of the Responder is filled with valid four tuples. It is a precondition for the Responder to be able to transmit frames that belong to connections that exist in the connection tracking table of the DUT.
2. レスポンダーの状態テーブルには、有効な4つのタプルで満たされています。Responderが、DUTの接続追跡テーブルに存在する接続に属するフレームを送信できることは前提条件です。
Whereas the above two things are always necessary before test phase 2, test phase 1 can be used without test phase 2. This is done when the maximum connection establishment rate is measured (as described in Section 4.5).
上記の2つのことはテストフェーズ2の前に常に必要ですが、テストフェーズ1はテストフェーズ2なしで使用できます。これは、最大接続確立率を測定すると行われます（セクション4.5で説明されています）。
Test phase 1 MUST be performed before all tests are performed in test phase 2. The following things happen in test phase 1:
すべてのテストがテストフェーズ2で実行される前に、テストフェーズ1を実行する必要があります。テストフェーズ1で次のことが起こります。
1. The Initiator sends test frames to the Responder through the DUT at a specific frame rate.
1. イニシエーターは、特定のフレームレートでDUTを通じてテストフレームをResponderに送信します。
2. The DUT performs the stateful translation of the test frames, and it also stores the new connections in its connection tracking table.
2. DUTは、テストフレームのステートフルな翻訳を実行し、接続追跡テーブルに新しい接続を保存します。
3. The Responder receives the translated test frames and updates its state table with the received four tuples. The Responder transmits no test frames during test phase 1.
3. レスポンダーは翻訳されたテストフレームを受け取り、受信した4つのタプルで状態テーブルを更新します。レスポンダーは、テストフェーズ1の間にテストフレームを送信しません。
When test phase 1 is performed in preparation for test phase 2, the applied frame rate SHOULD be safely lower than the maximum connection establishment rate. (It implies that maximum connection establishment rate measurement MUST be performed first.) Please refer to Section 4.4 for further conditions regarding timeout and the enumeration of all possible four tuples.
テストフェーズ1がテストフェーズ2に備えて実行される場合、適用されたフレームレートは、最大接続確立レートよりも安全に低くする必要があります。（最大接続確立レート測定を最初に実行する必要があることを意味します。）タイムアウトと可能なすべての4つのタプルの列挙に関するさらなる条件については、セクション4.4を参照してください。
The authors consider the most important events that may happen during the operation of a stateful NATxy gateway and the Actions of the gateway as follows.
著者は、ステートフルなNatxyゲートウェイの操作中に発生する可能性のある最も重要なイベントと、次のようにゲートウェイのアクションを検討します。
1. EVENT: A packet not belonging to an existing connection arrives in the client-to-server direction.
1. イベント：既存の接続に属さないパケットは、クライアントからサーバーへの方向に到着します。
ACTION: A new connection is registered into the connection tracking table, and the packet is translated and forwarded.
アクション：新しい接続が接続追跡テーブルに登録され、パケットが翻訳され、転送されます。
2. EVENT: A packet not belonging to an existing connection arrives in the server-to-client direction.
2. イベント：既存の接続に属さないパケットがサーバーからクライアントへの方向に到着します。
ACTION: The packet is discarded.
アクション：パケットは破棄されます。
3. EVENT: A packet belonging to an existing connection arrives (in any direction).
3. イベント：既存の接続に属するパケットが（任意の方向に）到着します。
ACTION: The packet is translated and forwarded, and the timeout counter of the corresponding connection tracking table entry is reset.
アクション：パケットが翻訳され、転送され、対応する接続追跡テーブルエントリのタイムアウトカウンターがリセットされます。
4. EVENT: A connection tracking table entry times out.
4. イベント：接続追跡テーブルの入力時間。
ACTION: The entry is deleted from the connection tracking table.
アクション：エントリは、接続追跡テーブルから削除されます。
Due to "black box" testing, the Tester is not able to directly examine (or delete) the entries of the connection tracking table. However, the entries can and MUST be controlled by setting an appropriate timeout value and carefully selecting the port numbers of the packets (as described in Section 4.4) to be able to produce meaningful and repeatable measurement results.
「ブラックボックス」テストにより、テスターは接続追跡テーブルのエントリを直接調べ（または削除する）ことができません。ただし、適切なタイムアウト値を設定し、意味のある再現性のある測定結果を作成できるようにパケットのポート番号（セクション4.4で説明）を慎重に選択することにより、エントリを制御する必要があります。
This document aims to support the measurement of the following performance characteristics of a stateful NATxy gateway:
このドキュメントは、ステートフルなNatxyゲートウェイの次のパフォーマンス特性の測定をサポートすることを目的としています。
* maximum connection establishment rate
* 最大接続確立率
* all "classic" performance metrics like throughput, frame loss rate, latency, etc.
* スループット、フレーム損失率、レイテンシなどのすべての「クラシック」パフォーマンスメトリック。
* connection tear-down rate
* 接続の引き裂きレート
* connection tracking table capacity
* 接続追跡テーブル容量
It is necessary to control the connection tracking table entries of the DUT to achieve clear conditions for the measurements. One can simply achieve the following two extreme situations:
測定の明確な条件を達成するには、DUTの接続追跡テーブルエントリを制御する必要があります。単に次の2つの極端な状況を達成することができます。
1. All frames create a new entry in the connection tracking table of the DUT, and no old entries are deleted during the test. This is required for measuring the maximum connection establishment rate.
1. すべてのフレームは、DUTの接続追跡テーブルに新しいエントリを作成し、テスト中に古いエントリは削除されません。これは、最大接続確立率を測定するために必要です。
2. No new entries are created in the connection tracking table of the DUT, and no old ones are deleted during the test. This is ideal for the measurements to be executed in phase 2, like throughput, latency, etc.
2. DUTの接続追跡テーブルに新しいエントリは作成されておらず、テスト中に古いエントリは削除されません。これは、スループット、レイテンシなど、フェーズ2で測定が実行されるのに最適です。
From this point, the following two assumptions are used:
この時点から、次の2つの仮定が使用されます。
1. The connection tracking table of the stateful NATxy is large enough to store all connections defined by the different four tuples.
1. ステートフルNatxyの接続追跡テーブルは、さまざまな4つのタプルで定義されたすべての接続を保存するのに十分な大きさです。
2. Each experiment is started with an empty connection tracking table. (This can be ensured by deleting its content before the experiment.)
2. 各実験は、空の接続追跡テーブルで開始されます。（実験の前にコンテンツを削除することで、これを保証できます。）
The first extreme situation can be achieved by:
最初の極端な状況は、次のように達成できます。
* using different four tuples for every single test frame in test phase 1 and
* テストフェーズ1とテストフレームごとに異なる4つのタプルを使用し、
* setting the UDP timeout of the NATxy gateway to a value higher than the length of test phase 1.
* NatxyゲートウェイのUDPタイムアウトを、テストフェーズ1の長さよりも高い値に設定します。
The second extreme situation can be achieved by:
2番目の極端な状況は、次のように達成できます。
* enumerating all possible four tuples in test phase 1 and
* テストフェーズ1と
* setting the UDP timeout of the NATxy gateway to a value higher than the length of test phase 1 plus the gap between the two phases plus the length of test phase 2.
* NatxyゲートウェイのUDPタイムアウトを、テストフェーズ1の長さよりも高い値に、2つのフェーズ間のギャップとテストフェーズ2の長さに設定します。
As described in [RFC4814], pseudorandom port numbers are REQUIRED, which the authors believe is a good approximation of the distribution of the source port numbers a NATxy gateway on the Internet may be faced with.
[RFC4814]で説明されているように、擬似ランダムポート番号が必要です。著者は、インターネット上のNatxyゲートウェイが直面する可能性のあるソースポート番号の分布の適切な近似であると著者は信じています。
Although the enumeration of all possible four tuples is not a requirement for the first extreme situation and the usage of different four tuples in test phase 1 is not a requirement for the second extreme situation, pseudorandom enumeration of all possible four tuples in test phase 1 is a good solution in both cases. Pseudorandom enumeration of all possible four tuples may be generated in a computationally efficient way by using Durstenfeld's random shuffle algorithm [DUST1964] to prepare a random permutation of the previously enumerated all possible four tuples.
すべての可能な4つのタプルの列挙は最初の極端な状況の要件ではなく、テストフェーズ1の異なる4つのタプルの使用は2番目の極端な状況の要件ではありませんが、テストフェーズ1のすべての可能な4つのタプルの擬似ランダム列挙はです。どちらの場合も良い解決策。Durstenfeldのランダムシャッフルアルゴリズム[Dust1964]を使用して、以前に列挙されたすべての4つのタプルのランダムな順列を準備することにより、可能なすべての4つのタプルの擬似ランダム列挙は、計算上効率的な方法で生成される場合があります。
The enumeration of the four tuples in increasing or decreasing order (or in any other specific order) MAY be used as an additional measurement.
順序の増加または減少（またはその他の特定の順序で）の4つのタプルの列挙は、追加の測定として使用できます。
The maximum connection establishment rate is an important characteristic of the stateful NATxy gateway, and its determination is necessary for the safe execution of test phase 1 (without frame loss) before test phase 2.
最大接続確立率は、ステートフルNatxyゲートウェイの重要な特性であり、テストフェーズ2の前にテストフェーズ1（フレーム損失なし）の安全な実行にはその決定が必要です。
The measurement procedure of the maximum connection establishment rate is very similar to the throughput measurement procedure defined in [RFC2544].
最大接続確立率の測定手順は、[RFC2544]で定義されているスループット測定手順と非常に似ています。
The procedure is as follows:
手順は次のとおりです。
* The Initiator sends a specific number of test frames using all different four tuples at a specific rate through the DUT.
* イニシエーターは、DUTを通じて特定のレートで異なる4つのタプルすべてを使用して、特定の数のテストフレームを送信します。
* The Responder counts the frames that are successfully translated by the DUT.
* レスポンダーは、DUTによって正常に翻訳されたフレームをカウントします。
* If the count of offered frames is equal to the count of received frames, the rate of the offered stream is raised and the test is rerun.
* 提供されたフレームのカウントが受信したフレームのカウントに等しい場合、提供されるストリームのレートが上昇し、テストが再実行されます。
* If fewer frames are received than were transmitted, the rate of the offered stream is reduced and the test is rerun.
* 送信されたフレームが少ない場合、提供されるストリームのレートが減少し、テストが再実行されます。
The maximum connection establishment rate is the fastest rate at which the count of test frames successfully translated by the DUT is equal to the number of test frames sent to it by the Initiator.
最大接続確立率は、DUTによって翻訳されたテストフレームのカウントが、イニシエーターから送信されたテストフレームの数に等しい最速のレートです。
Note: In practice, the usage of binary search is RECOMMENDED.
注：実際には、バイナリ検索の使用が推奨されます。
Due to "black box" testing, the entries of the connection tracking table of the DUT may not be directly examined. However, the presence of the connections can be checked easily by sending frames from the Responder to the Initiator in test phase 2 using all four tuples stored in the state table of the Tester (at a low enough frame rate). The arrival of all test frames indicates that the connections are indeed present.
「ブラックボックス」テストにより、DUTの接続追跡テーブルのエントリは直接検討できない場合があります。ただし、テスターの状態テーブルに保存されている4つのタプルすべて（十分な低フレームレート）を使用して、テストフェーズ2でレスポンダーからイニシエーターにフレームを送信することにより、接続の存在を簡単に確認できます。すべてのテストフレームの到着は、接続が実際に存在することを示しています。
The procedure is as follows:
手順は次のとおりです。
When all the desired N number of test frames are sent by the Initiator to the Receiver at frame rate R in test phase 1 for the maximum connection establishment rate measurement and the Receiver has successfully received all the N frames, the establishment of the connections is checked in test phase 2 as follows:
最大接続確立速度測定のために、テストフェーズ1のフレームレートrで、イニシエーターによってすべての希望のn回数がイニシエーターによって受信機に送信され、受信機がすべてのnフレームを正常に受信した場合、接続の確立がチェックされます次のようにテストフェーズ2で：
* The Responder sends test frames to the Initiator at frame rate r=R*alpha for the duration of N/r, using a different four tuple from its state table for each test frame.
* レスポンダーは、各テストフレームの状態テーブルとは異なる4タプルを使用して、N/Rの期間中、フレームレートr = r*アルファでイニシエーターにテストフレームを送信します。
* The Initiator counts the received frames, and if all N frames have arrived, then the R frame rate of the maximum connection establishment rate measurement (performed in test phase 1) is raised for the next iteration; otherwise, it is lowered (as well as in the case that test frames were missing in the preliminary test phase, as well).
* イニシエーターは受信したフレームをカウントし、すべてのnフレームが到着した場合、次の反復のために最大接続確立速度測定（テストフェーズ1で実行）のRフレームレートが発生します。それ以外の場合は、（および予備テスト段階でもテストフレームが欠落している場合と同様に）下げられます。
Notes:
注：
* The alpha is a kind of "safety factor"; it aims to make sure that the frame rate used for the validation is not too high, and the test may fail only in the case of if at least one connection is not present in the connection tracking table of the DUT. (Therefore, alpha should be typically less than 1, e.g., 0.8 or 0.5.)
* アルファは一種の「安全係数」です。検証に使用されるフレームレートが高すぎないことを確認することを目的としており、DUTの接続追跡テーブルに少なくとも1つの接続が存在しない場合にのみテストが失敗する可能性があります。（したがって、アルファは通常1未満である必要があります。たとえば、0.8または0.5。）
* The duration of N/r and the frame rate of r means that N frames are sent for validation.
* N/Rの持続時間とRのフレームレートは、nフレームが検証のために送信されることを意味します。
* The order of four tuple selection is arbitrary, provided that all four tuples MUST be used.
* 4つのタプル選択の順序は、4つのタプルすべてを使用する必要がある場合、任意です。
* Please refer to Section 4.9 for a short analysis of the operation of the measurement and what problems may occur.
* 測定の操作と問題が発生する可能性のある短い分析については、セクション4.9を参照してください。
As for the traffic direction, there are three possible cases during test phase 2:
交通方向に関しては、テストフェーズ2の間に3つの可能なケースがあります。
1. Bidirectional traffic: The Initiator sends test frames to the Responder, and the Responder sends test frames to the Initiator.
1. 双方向トラフィック：イニシエーターはテストフレームをレスポンダーに送信し、レスポンダーはテストフレームをイニシエーターに送信します。
2. Unidirectional traffic from the Initiator to the Responder: The Initiator sends test frames to the Responder, but the Responder does not send test frames to the Initiator.
2. イニシエーターからレスポンダーへの単方向トラフィック：イニシエーターはテストフレームをレスポンダーに送信しますが、レスポンダーはテストフレームをイニシエーターに送信しません。
3. Unidirectional traffic from the Responder to the Initiator: The Responder sends test frames to the Initiator, but the Initiator does not send test frames to the Responder.
3. レスポンダーからイニシエーターへの一方向トラフィック：レスポンダーはテストフレームをイニシエーターに送信しますが、イニシエーターはテストフレームをレスポンダーに送信しません。
If the Initiator sends test frames, then it uses pseudorandom source port numbers and destination port numbers from the restricted port number ranges. (If it uses multiple source and/or destination IP addresses, then their ranges are also limited.) The Responder receives the test frames, updates its state table, and processes the test frames as required by the given measurement procedure (e.g., only counts them for the throughput test, handles timestamps for latency or PDV tests, etc.).
イニシエーターがテストフレームを送信する場合、制限付きポート番号の範囲から擬似ランダムソースポート番号と宛先ポート番号を使用します。（複数のソースおよび/または宛先IPアドレスを使用している場合、範囲も限られています。）レスポンダーはテストフレームを受信し、状態テーブルを更新し、特定の測定手順の要求に応じてテストフレームを処理します（たとえば、カウントのみ、カウントします。スループットテストのために、レイテンシまたはPDVテストなどのタイムスタンプを処理します）。
If the Responder sends test frames, then it uses the four tuples from its state table. The reading order of the state table may follow different policies (discussed in Section 4.10). The Initiator receives the test frames and processes them as required by the given measurement procedure.
レスポンダーがテストフレームを送信する場合、状態テーブルから4つのタプルを使用します。州の表の読み取り順序は、さまざまなポリシーに従うことができます（セクション4.10で説明）。イニシエーターはテストフレームを受信し、指定された測定手順で要求されるようにそれらを処理します。
As for the actual measurement procedures, the usage of the updated ones from Section 7 of [RFC8219] is RECOMMENDED.
実際の測定手順については、[RFC8219]のセクション7から更新された手順の使用法が推奨されます。
Connection tear-down can cause significant load for the NATxy gateway. The connection tear-down performance can be measured as follows:
接続の裂け目は、Natxyゲートウェイに大きな負荷を引き起こす可能性があります。接続の引き裂きパフォーマンスは、次のように測定できます。
1. Load a certain number of connections (N) into the connection tracking table of the DUT (in the same way as done to measure the maximum connection establishment rate).
1. 特定の数の接続（n）をDUTの接続追跡テーブルにロードします（最大接続確立率を測定するために行われた方法と同じ方法で）。
2. Record TimestampA.
2. 記録タイムスタンパ。
3. Delete the content of the connection tracking table of the DUT.
3. DUTの接続追跡テーブルのコンテンツを削除します。
4. Record TimestampB.
4. record timestampb。
The connection tear-down rate can be computed as:
接続の引き裂きレートは、次のように計算できます。
connection tear-down rate = N / ( TimestampB - TimestampA)
接続引き裂き速度= in /（timestamppb -timestamp）
The connection tear-down rate SHOULD be measured for various values of N.
nのさまざまな値について、接続の涙液率を測定する必要があります。
It is assumed that the content of the connection tracking table may be deleted by an out-of-band control mechanism specific to the given NATxy gateway implementation (e.g., by removing the appropriate kernel module under Linux).
接続追跡テーブルのコンテンツは、指定されたNatxyゲートウェイの実装に固有のバンド外の制御メカニズムによって削除される可能性があると想定されています（たとえば、Linuxの下で適切なカーネルモジュールを削除することにより）。
It is noted that the performance of removing the entire content of the connection tracking table at one time may be different from removing all the entries one by one.
接続追跡テーブルのコンテンツ全体を一度に削除するパフォーマンスは、すべてのエントリを1つずつ削除することとは異なる場合があることに注意してください。
The connection tracking table capacity is an important metric of stateful NATxy gateways. Its measurement is not easy, because an elementary step of a validated maximum connection establishment rate measurement (defined in Section 4.6) may have only a few distinct observable outcomes, but some of them may have different root causes:
接続追跡テーブル容量は、ステートフルなNatxyゲートウェイの重要なメトリックです。検証済みの最大接続確立率測定の基本ステップ（セクション4.6で定義）には、いくつかの明確な観察可能な結果しかない可能性があるため、その測定は容易ではありませんが、それらのいくつかは異なる根本原因を持っている可能性があります。
* During test phase 1, the number of test frames received by the Responder is less than the number of test frames sent by the Initiator. It may have different root causes, including:
* テストフェーズ1では、レスポンダーが受信したテストフレームの数は、イニシエーターが送信したテストフレームの数よりも少なくなります。以下を含むさまざまな根本原因がある場合があります。
- The R frame sending rate was higher than the maximum connection establishment rate. (Note that now the maximum connection establishment rate is considered unknown because one cannot measure the maximum connection establishment without assumption 1 in Section 4.4.) This root cause may be eliminated by lowering the R rate and re-executing the test. (This step may be performed multiple times while R>0.)
- Rフレームの送信率は、最大接続確立率よりも高かった。（セクション4.4の仮定1なしで最大接続確立を測定できないため、最大接続確立率は不明と見なされます。）この根本原因は、Rレートを下げてテストを再実行することで排除される可能性があります。（この手順は複数回実行される場合があり、r> 0。）
- The capacity of the connection tracking table of the DUT has been exhausted (and either the DUT does not want to delete connections or the deletion of the connections makes it slower; this case is not investigated further in test phase 1).
- DUTの接続追跡テーブルの容量は使い果たされています（そして、DUTが接続を削除したくないか、接続の削除により遅くなります。このケースはテストフェーズ1ではこれ以上調査されません）。
* During test phase 1, the number of test frames received by the Responder equals the number of test frames sent by the Initiator. In this case, the connections are validated in test phase 2. The validation may have two kinds of observable results:
* テストフェーズ1では、レスポンダーが受信したテストフレームの数は、イニシエーターが送信したテストフレームの数に等しくなります。この場合、接続はテストフェーズ2で検証されています。検証には、2種類の観察可能な結果があります。
1. The number of validation frames received by the Initiator equals the number of validation frames sent by the Responder. (It proves that the capacity of the connection tracking table of the DUT is enough and both R and r were chosen properly.)
1. イニシエーターが受信した検証フレームの数は、レスポンダーが送信した検証フレームの数に等しくなります。（DUTの接続追跡テーブルの容量で十分であり、RとRの両方が適切に選択されたことを証明しています。）
2. The number of validation frames received by the Initiator is less than the number of validation frames sent by the Responder. This phenomenon may have various root causes:
2. イニシエーターが受信した検証フレームの数は、レスポンダーから送信された検証フレームの数よりも少ないです。この現象には、さまざまな根本原因がある場合があります。
- The capacity of the connection tracking table of the DUT has been exhausted. (It does not matter whether some existing connections are discarded and new ones are stored or if the new connections are discarded. Some connections are lost anyway, and it makes validation fail.)
- DUTの接続追跡テーブルの容量は使い果たされました。（既存の接続が破棄され、新しい接続が格納されているかどうか、または新しい接続が破棄されるかどうかは関係ありません。とにかくいくつかの接続が失われ、検証が失敗します。）
- The R frame sending rate used by the Initiator was too high in test phase 1; thus, some connections were not established even though all test frames arrived at the Responder. This root cause may be eliminated by lowering the R rate and re-executing the test. (This step may be performed multiple times while R>0.)
- イニシエーターが使用するRフレーム送信速度は、テストフェーズ1で高すぎました。したがって、すべてのテストフレームがレスポンダーに到着したとしても、いくつかの接続は確立されていません。この根本原因は、Rレートを下げてテストを再実行することにより排除される場合があります。（この手順は複数回実行される場合があり、r> 0。）
- The r frame sending rate used by the Responder was too high in test phase 2; thus, some test frames did not arrive at the Initiator even though all connections were present in the connection tracking table of the DUT. This root cause may be eliminated by lowering the r rate and re-executing the test. (This step may be performed multiple times while r>0.)
- レスポンダーが使用するRフレーム送信率は、テストフェーズ2で高すぎました。したがって、すべての接続がDUTの接続追跡テーブルに存在していても、一部のテストフレームはイニシエーターに到達しませんでした。この根本原因は、Rレートを下げてテストを再実行することにより排除される場合があります。（この手順は複数回実行される場合があり、r> 0。）
This is the problem: As the above three root causes are indistinguishable, it is not easy to decide whether R or r should be decreased.
これが問題です。上記の3つの根本原因は区別できないため、RまたはRを減らすべきかどうかを判断するのは容易ではありません。
Experience shows that the DUT may collapse if its memory is exhausted. Such a situation may make the connection tracking table capacity measurements rather inconvenient. This possibility is included in the recommended measurement procedure, but the detection and elimination of such a situation is not addressed (e.g., how the algorithm can reset the DUT).
経験は、その記憶が使い果たされた場合、DUTが崩壊する可能性があることを示しています。このような状況は、接続追跡テーブル容量の測定をかなり不便にする可能性があります。この可能性は推奨される測定手順に含まれていますが、そのような状況の検出と排除は対処されていません（たとえば、アルゴリズムがDUTをリセットする方法）。
For the connection tracking table size measurement, first, one needs a safe number: C0. It is a precondition that C0 number of connections can surely be stored in the connection tracking table of the DUT. Using C0, one can determine the maximum connection establishment rate using C0 number of connections. It is done with a binary search using validation. The result is R0. The values C0 and R0 will serve as "safe" starting values for the following two searches.
接続追跡テーブルサイズの測定には、最初に、安全な番号が必要です。C0。C0の接続数がDUTの接続追跡テーブルに確実に保存できることは前提条件です。C0を使用すると、C0接続数を使用して最大接続確立率を決定できます。検証を使用してバイナリ検索で行われます。結果はR0です。値C0とR0は、次の2つの検索で「安全な」開始値として機能します。
First, an exponential search is performed to find the order of magnitude of the connection tracking table capacity. The search stops if the DUT collapses OR the maximum connection establishment rate severely drops (e.g., to its one tenth) due to doubling the number of connections.
最初に、接続追跡テーブル容量の順序を見つけるために指数検索が実行されます。接続の数が2倍になるため、DUTが崩壊したり、最大接続確立率が大幅に低下したりする（たとえば、その10番目に）検索が停止します。
Then, the result of the exponential search gives the order of magnitude of the size of the connection tracking table. Before disclosing the possible algorithms to determine the exact size of the connection tracking table, three possible replacement policies for the NATxy gateway are considered:
次に、指数検索の結果により、接続追跡テーブルのサイズの大きさが得られます。可能なアルゴリズムを開示して接続追跡テーブルの正確なサイズを決定する前に、Natxyゲートウェイの3つの可能な交換ポリシーを考慮します。
1. The gateway does not delete any live connections until their timeout expires.
1. ゲートウェイは、タイムアウトが期限切れになるまでライブ接続を削除しません。
2. The gateway replaces the live connections according to the Least Recently Used (LRU) policy.
2. ゲートウェイは、最近使用されていない（LRU）ポリシーに従ってライブ接続を置き換えます。
3. The gateway does a garbage collection when its connection tracking table is full and a frame with a new four tuple arrives. During the garbage collection, it deletes the K LRU connections, where K is greater than 1.
3. ゲートウェイは、接続追跡テーブルがいっぱいになり、新しい4タプルが到着したフレームが到着すると、ごみ収集を行います。ガベージコレクション中に、K LRU接続が削除されます。ここで、Kは1より大きいです。
Now, it is examined what happens and how many validation frames arrive in the three cases. Let the size of the connection tracking table be S and the number of preliminary frames be N, where S is less than N.
これで、3つのケースで何が起こるか、検証フレームの数が到着するものが調べられます。接続トラッキングテーブルのサイズをSとし、予備フレームの数をnとします。Sはn未満です。
1. The connections defined by the first S test frames are registered into the connection tracking table of the DUT, and the last N-S connections are lost. (It is another question if the last N-S test frames are translated and forwarded in test phase 1 or simply dropped.) During validation, the validation frames with four tuples corresponding to the first S test frames will arrive at the Initiator and the other N-S validation frames will be lost.
1. 最初のSテストフレームによって定義された接続は、DUTの接続追跡テーブルに登録され、最後のN-S接続が失われます。（最後のN-Sテストフレームがテストフェーズ1で翻訳および転送されるか、単にドロップされているかどうかは別の質問です。）検証中、最初のSテストフレームに対応する4つのタプルを持つ検証フレームは、イニシエーターと他のN-S検証に到達しますフレームは失われます。
2. All connections are registered into the connection tracking table of the DUT, but the first N-S connections are replaced (and thus lost). During validation, the validation frames with four tuples corresponding to the last S test frames will arrive to the Initiator, and the other N-S validation frames will be lost.
2. すべての接続はDUTの接続追跡テーブルに登録されますが、最初のN-S接続は交換されます（したがって失われます）。検証中、最後のSテストフレームに対応する4つのタプルを持つ検証フレームがイニシエーターに到着し、他のN-S検証フレームが失われます。
3. Depending on the values of K, S, and N, maybe less than S connections will survive. In the worst case, only S-K+1 validation frames arrive, even though the size of the connection tracking table is S.
3. k、s、およびnの値に応じて、S接続が生存するよりも少ないかもしれません。最悪の場合、接続追跡テーブルのサイズがSですが、S-K+1の検証フレームのみが到着します。
If one knows that the stateful NATxy gateway uses the first or second replacement policy and one also knows that both R and r rates are low enough, then the final step of determining the size of the connection tracking table is simple. If the Responder sent N validation frames and the Initiator received N' of them, then the size of the connection tracking table is N'.
ステートフルのNatxy Gatewayが最初または2番目の交換ポリシーを使用していることを知っている場合、RレートとRレートの両方が十分に低いことも知っている場合、接続追跡テーブルのサイズを決定する最終ステップは簡単です。レスポンダーがn検証フレームを送信し、イニシエーターがそれらのn 'を受け取った場合、接続追跡テーブルのサイズはn'です。
In the general case, a binary search is performed to find the exact value of the connection tracking table capacity within E error. The search chooses the lower half of the interval if the DUT collapses OR the maximum connection establishment rate severely drops (e.g., to its half); otherwise, it chooses the higher half. The search stops if the size of the interval is less than the E error.
一般的なケースでは、バイナリ検索が実行され、Eエラー内の接続追跡テーブル容量の正確な値が見つかります。検索では、DUTが崩壊した場合、または最大接続確立率が大幅に低下した場合（例：半分に）間隔の下半分を選択します。それ以外の場合、それはより高い半分を選択します。間隔のサイズがEエラーよりも少ない場合、検索は停止します。
The algorithms for the general case are defined using C-like pseudocode in Figure 5. In practice, this algorithm may be made more efficient in the way that the binary search for the maximum connection establishment rate stops if an elementary test fails at a rate under RS*beta or RS*gamma during the external search or during the final binary search for the capacity of the connection tracking table, respectively. (This saves a high amount of execution time by eliminating the long-lasting tests at low rates.)
一般的なケースのアルゴリズムは、図5のc様擬似コードを使用して定義されます。実際には、このアルゴリズムは、基本テストが下のレートで故障した場合に最大接続確立レートのバイナリ検索が停止するように、より効率的になる場合があります。RS*ベータまたはRS*ガンマ外部検索中または接続追跡テーブルの容量の最終バイナリ検索中。（これにより、長期にわたるテストを低速度で排除することにより、大量の実行時間を節約できます。）
// The binarySearchForMaximumConnectionCstablishmentRate(c,r)
// function performs a binary search for the maximum connection
// establishment rate in the [0, r] interval using c number of
// connections.
// This is an exponential search for finding the order of magnitude
// of the connection tracking table capacity
// Variables:
// C0 and R0 are beginning safe values for the connection
// tracking table size and connection establishment rate,
// respectively
// CS and RS are their currently used safe values
// CT and RT are their values for the current examination
// beta is a factor expressing an unacceptable drop in R (e.g.,
// beta=0.1)
// maxrate is the maximum frame rate for the media
R0=binarySearchForMaximumConnectionCstablishmentRate(C0,maxrate);
for ( CS=C0, RS=R0; 1; CS=CT, RS=RT )
{
CT=2*CS;
RT=binarySearchForMaximumConnectionCstablishmentRate(CT,RS);
if ( DUT_collapsed || RT < RS*beta )
break;
}
// At this point, the size of the connection tracking table is
// between CS and CT.
// This is the final binary search for finding the connection
// tracking table capacity within E error
// Variables:
// CS and RS are the safe values for connection tracking table size
// and connection establishment rate, respectively
// C and R are the values for the current examination
// gamma is a factor expressing an unacceptable drop in R
// (e.g., gamma=0.5)
for ( D=CT-CS; D>E; D=CT-CS )
{
C=(CS+CT)/2;
R=binarySearchForMaximumConnectionCstablishmentRate(C,RS);
if ( DUT_collapsed || R < RS*gamma )
CT=C; // take the lower half of the interval
else
CS=C,RS=R; // take the upper half of the interval
}
// At this point, the size of the connection tracking table is
// CS within E error.
Figure 5: Measurement of the Connection Tracking Table Capacity
図5：接続追跡テーブル容量の測定
As for the writing policy of the state table of the Responder, round robin is RECOMMENDED, because it ensures that its entries are automatically kept fresh and consistent with that of the connection tracking table of the DUT.
Responderの州のテーブルの執筆ポリシーに関しては、Rove Robinが推奨されます。これは、そのエントリが自動的に新鮮に保たれ、DUTの接続追跡テーブルのそれと一致することを保証するためです。
The Responder can read its state table in various orders, for example:
レスポンダーは、さまざまな注文で州のテーブルを読むことができます。
* pseudorandom
* 擬似ランダム
* round robin
* ラウンドロビン
Pseudorandom is RECOMMENDED to follow the approach of [RFC4814]. Round robin may be used as a computationally cheaper alternative.
[RFC4814]のアプローチに従うことをお勧めします。ラウンドロビンは、計算的に安価な代替品として使用できます。
As for scalability measurements, no new types of performance metrics are defined, but it is RECOMMENDED to perform measurement series through which the value of one or more parameter(s) are changed to discover how the various values of the given parameter(s) influence the performance of the DUT.
スケーラビリティ測定に関しては、新しいタイプのパフォーマンスメトリックが定義されていませんが、1つ以上のパラメーターの値を変更して、指定されたパラメーターの影響のさまざまな値がどのように影響するかを発見する測定シリーズを実行することをお勧めします。DUTのパフォーマンス。
The scalability measurements aim to quantify how the performance of the stateful NATxy gateways degrades with the increase of the number of network flows.
スケーラビリティ測定は、ネットワークフローの数の増加とともに、ステートフルなNatxyゲートウェイのパフォーマンスがどのように分解されるかを定量化することを目的としています。
As for the actual values for the number of network flows to be used during the measurement series, it is RECOMMENDED to use some representative values from the range of the potential number of network flows the DUT may be faced with during its intended usage.
測定シリーズ中に使用するネットワークフローの数の実際の値については、意図した使用状況中にDUTが直面する可能性のあるネットワークフローの潜在的な数の範囲からいくつかの代表的な値を使用することをお勧めします。
It is important how the given number of network flows are generated. The sizes of the ranges of the source and destination IP addresses and port numbers are essential parameters to be reported together with the results. Please also see Section 6 about the reporting format.
特定の数のネットワークフローがどのように生成されるかが重要です。ソースおよび宛先IPアドレスとポート番号の範囲のサイズは、結果と一緒に報告するために不可欠なパラメーターです。レポート形式に関するセクション6もご覧ください。
If a single IP address pair is used, then it is RECOMMENDED to use:
単一のIPアドレスペアを使用する場合は、以下を使用することをお勧めします。
* a fixed, larger source port number range (e.g., a few times 10,000) and
* 固定された、より大きなソースポート番号の範囲（たとえば、数回10,000）と
* a variable-size destination port number range (e.g., 10, 100, 1,000, etc.), where its expedient granularity depends on the purpose.
* 可変サイズの宛先ポート番号範囲（例：10、100、1,000など）。
Stateful NATxy gateways are often implemented in software that is not bound to a specific hardware but can be executed by commodity servers. To facilitate the comparison of their performance, it can be useful to determine:
Stateful Natxyゲートウェイは、多くの場合、特定のハードウェアにバインドされていないが、コモディティサーバーで実行できるソフトウェアに実装されます。パフォーマンスの比較を容易にするために、以下を決定することは有用です。
* the performance of the various implementations using a single core of a well-known CPU and
* よく知られているCPUの単一コアを使用したさまざまな実装のパフォーマンスと
* the scale-up of the performance of the various implementations with the number of CPU cores.
* CPUコアの数を使用したさまざまな実装のパフォーマンスのスケールアップ。
If the number of the available CPU cores is a power of two, then it is RECOMMENDED to perform the tests with 1, 2, 4, 8, 16, etc. number of active CPU cores of the DUT.
利用可能なCPUコアの数が2のパワーである場合、DUTのアクティブなCPUコアの数、2、4、8、16などでテストを実行することをお勧めします。
Measurements MUST be executed multiple times. The necessary number of repetitions to achieve statistically reliable results may depend on the consistent or scattered nature of the results. The report of the results MUST contain the number of repetitions of the measurements. The median is RECOMMENDED as the summarizing function of the results complemented with the first percentile and the 99th percentile as indices of the dispersion of the results. The average and standard deviation MAY also be reported.
測定は複数回実行する必要があります。統計的に信頼できる結果を達成するために必要な繰り返しの数は、結果の一貫したまたは散在する性質に依存する可能性があります。結果のレポートには、測定の繰り返しの数が含まれている必要があります。結果の要約関数として、最初のパーセンタイルと99パーセンタイルが結果の分散の指標として補完されたものとして推奨されます。平均および標準偏差も報告される場合があります。
All parameters and settings that may influence the performance of the DUT MUST be reported. Some of them may be specific to the given NATxy gateway implementation, like the "hashsize" (hash table size) and "nf_conntrack_max" (number of connection tracking table entries) values for iptables or the limit of the number of states for OpenBSD PF (set by the "set limit states number" command in the pf.conf file).
DUTのパフォーマンスに影響を与える可能性のあるすべてのパラメーターと設定を報告する必要があります。それらのいくつかは、「ハッシュサイズ」（ハッシュテーブルサイズ）や「nf_conntrack_max」（接続追跡テーブルエントリの数）値またはopenbsd PFの州の数の制限（接続追跡テーブルエントリの数）など、指定されたNatxyゲートウェイの実装に固有の場合があります（pf.confファイルの「set lime states番号」コマンドによって設定されます）。
+----------------------------+--------+--------+--------+--------+
| number of sessions (req.) | 0.4M | 4M | 40M | 400M |
+----------------------------+--------+--------+--------+--------+
| source port numbers (req.) | 40,000 | 40,000 | 40,000 | 40,000 |
+----------------------------+--------+--------+--------+--------+
| destination port numbers | 10 | 100 | 1,000 | 10,000 |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
| "hashsize" (i.s.) | 2^17 | 2^20 | 2^23 | 2^27 |
+----------------------------+--------+--------+--------+--------+
| "nf_conntrack_max" (i.s.) | 2^20 | 2^23 | 2^26 | 2^30 |
+----------------------------+--------+--------+--------+--------+
| num. sessions / "hashsize" | 3.05 | 3.81 | 4.77 | 2.98 |
| (i.s.) | | | | |
+----------------------------+--------+--------+--------+--------+
| number of experiments | 10 | 10 | 10 | 10 |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
| error of binary search | 1,000 | 1,000 | 1,000 | 1,000 |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
| connections/s median | | | | |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
| connections/s 1st perc. | | | | |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
| connections/s 99th perc. | | | | |
| (req.) | | | | |
+----------------------------+--------+--------+--------+--------+
Table 1: Example Table of the Maximum Connection Establishment Rate of Iptables Against the Number of Sessions
表1：セッションの数に対するiptablesの最大接続確立率の例
Table 1 shows an example of table headings for reporting the measurement results regarding the scalability of the iptables stateful NAT44 implementation against the number of sessions. The table indicates the required fields (req.) and the implementation-specific ones (i.s.). A computed value was also added in row 6; it is the number of sessions per hashsize ratio, which helps the reader to interpret the achieved maximum connection establishment rate. (A lower value results in shorter linked lists hanging on the entries of the hash table, thus facilitating higher performance. The ratio is varying, because the number of sessions is always a power of 10, whereas the hash table size is a power of 2.) To reflect the accuracy of the results, the table contains the value of the "error" of the binary search, which expresses the stopping criterion for the binary search. The binary search stops when the difference between the "higher limit" and "lower limit" of the binary search is less than or equal to the "error".
表1は、セッションの数に対するIPTABLESTABLESTABLEのStateful NAT44実装のスケーラビリティに関する測定結果を報告するためのテーブル見出しの例を示しています。テーブルは、必要なフィールド（Req。）と実装固有のフィールド（I.S.）を示します。計算された値も行6に追加されました。これは、ハッシュサイズ比あたりのセッション数であり、読者が達成された最大接続確立率を解釈するのに役立ちます。（値が低いとリンクされたリストがハッシュテーブルのエントリにぶら下がっているため、より高いパフォーマンスが促進されます。セッションの数は常に10のパワーであるのに対し、ハッシュテーブルサイズは2のパワーであるため、比率はさまざまです。。）結果の精度を反映するために、表にはバイナリ検索の「エラー」の値が含まれており、バイナリ検索の停止基準を表します。バイナリ検索の「上限」と「下限」の差が「エラー」と等しくない場合、バイナリ検索は停止します。
The table MUST be complemented with reporting the relevant parameters of the DUT. If the DUT is a general-purpose computer and some software NATxy gateway implementation is tested, then the hardware description SHOULD include the following:
テーブルは、DUTの関連パラメーターを報告することで補完する必要があります。DUTが汎用コンピューターであり、一部のソフトウェアNatxy Gatewayの実装がテストされている場合、ハードウェアの説明には以下を含める必要があります。
* computer type
* コンピュータータイプ
* CPU type
* CPUタイプ
* number of active CPU cores
* アクティブなCPUコアの数
* memory type, size, and speed
* メモリタイプ、サイズ、速度
* network interface card type (also reflecting the speed)
* ネットワークインターフェイスカードタイプ（速度も反映）
* the fact that direct cable connections were use or the type of switch used for interconnecting the Tester and the DUT
* 直接ケーブル接続が使用されたという事実、またはテスターとDUTの相互接続に使用されるスイッチの種類
The operating system type and version, kernel version, and version of the NATxy gateway implementation (including the last commit date and number if applicable) SHOULD also be given.
オペレーティングシステムのタイプとバージョン、カーネルバージョン、およびNatxy Gateway実装のバージョン（該当する場合は最後のコミット日と番号を含む）も指定する必要があります。
The stateful extension of siitperf [SIITPERF] is an implementation of this concept. Its first version that only supports multiple port numbers is documented in this (open access) paper: [LEN2022]. Its extended version that also supports multiple IP addresses is documented in this (open access) paper: [LEN2024b].
Siitperf [siitperf]のステートフルな拡張は、この概念の実装です。複数のポート番号のみをサポートする最初のバージョンは、この（オープンアクセス）論文[LEN2022]に文書化されています。また、複数のIPアドレスをサポートする拡張バージョンは、この（オープンアクセス）ペーパー：[LEN2024B]に記載されています。
The proposed benchmarking methodology has been validated by performing benchmarking measurements with three radically different stateful NAT64 implementations (Jool, tayga+iptables, and OpenBSD PF) in this (open access) paper: [LEN2023].
提案されたベンチマーク方法論は、この（Open Access）論文で、根本的に異なる3つの状態NAT64実装（Jool、Tayga+Iptables、およびOpenBSD PF）を使用してベンチマーク測定を実行することにより検証されています：[LEN2023]。
Further experience with this methodology of using siitperf for measuring the scalability of the iptables stateful NAT44 and Jool stateful NAT64 implementations are described in [SCALABILITY].
Iptables Stateful Nat44およびJool Stateful Nat64の実装のスケーラビリティを測定するためにSiitperfを使用したこの方法のさらなる経験は、[Scalability]で説明されています。
This methodology was successfully applied for the benchmarking of various IPv4-as-a-Service (IPv4aas) technologies without the usage of technology-specific Testers by reducing the aggregate of their Customer Edge (CE) and Provider Edge (PE) devices to a stateful NAT44 gateway documented in this (open access) paper: [LEN2024a].
この方法論は、顧客エッジ（CE）とプロバイダーのエッジ（PE）デバイスの総合性を状態フルに削減することにより、テクノロジー固有のテスターを使用することなく、さまざまなIPv4-as-a-Service（IPV4AAS）テクノロジーのベンチマークに成功裏に適用されました。この（オープンアクセス）論文で文書化されたNAT44ゲートウェイ：[len2024a]。
The test frame format defined in [RFC2544] exclusively uses UDP (and not TCP) as a transport layer protocol. Testing with UDP was kept in both [RFC5180] and [RFC8219] regarding the standard benchmarking procedures (throughput, latency, frame loss rate, etc.). The benchmarking methodology proposed in this document follows this long-established benchmarking tradition using UDP as a transport layer protocol, too. The rationale for this is that the standard benchmarking procedures require sending frames at arbitrary constant frame rates, which would violate the flow control and congestion control algorithms of the TCP protocol. TCP connection setup (using the three-way handshake) would further complicate testing.
[RFC2544]で定義されているテストフレーム形式は、輸送層プロトコルとしてUDP（およびTCPではなく）のみを使用しています。UDPでのテストは、標準のベンチマーク手順（スループット、レイテンシ、フレーム損失率など）に関して[RFC5180]と[RFC8219]の両方に保持されました。このドキュメントで提案されているベンチマークの方法論は、UDPを輸送層プロトコルとして使用して、この老化したベンチマークの伝統に従っています。これの理論的根拠は、標準のベンチマーク手順では、任意の一定のフレームレートでフレームを送信する必要があり、TCPプロトコルのフロー制御および渋滞制御アルゴリズムに違反することです。TCP接続のセットアップ（3方向の握手を使用）は、テストをさらに複雑にします。
Further potential transport layer protocols, e.g., the Datagram Congestion Control Protocol (DCCP) [RFC4340] and the Stream Control Transmission Protocol (SCTP) [RFC9260], are outside of the scope of this document, as the widely used stateful NAT44 and stateful NAT64 implementations do not support them. Although QUIC [RFC9000] is also considered a transport layer protocol, QUIC packets are carried in UDP datagrams; thus, QUIC does not need a special handling.
さらなる潜在的な輸送層プロトコル、たとえば、データグラムの混雑制御プロトコル（DCCP）[RFC4340]およびストリーム制御伝送プロトコル（SCTP）[RFC9260]は、広く使用されている州立NAT44およびステートフルNAT644であるため、このドキュメントの範囲外です。実装はそれらをサポートしていません。QUIC [RFC9000]はトランスポートレイヤープロトコルとも見なされますが、QUICパケットはUDPデータグラムで運ばれます。したがって、QUICには特別な取り扱いは必要ありません。
Some stateful NATxy solutions handle TCP and UDP differently, e.g., iptables use a 30s timeout for UDP and a 60s timeout for TCP. Thus, benchmarking results produced using UDP do not necessarily characterize the performance of a NATxy gateway well enough when they are used for forwarding Internet traffic. As for the given example, timeout values of the DUT may be adjusted, but it requires extra consideration.
一部のステートフルなNatxyソリューションは、TCPとUDPを異なる方法で処理します。たとえば、IPTABLEはUDPに30秒のタイムアウトを使用し、TCPには60年代のタイムアウトを使用しています。したがって、UDPを使用して生成されたベンチマーク結果は、インターネットトラフィックを転送するために使用される場合、Natxyゲートウェイのパフォーマンスを十分に特徴付けるものではありません。特定の例としては、DUTのタイムアウト値が調整される場合がありますが、追加の考慮が必要です。
Other differences in handling UDP or TCP are also possible. Thus, the authors recommend that further investigations should be performed in this field.
UDPまたはTCPの処理におけるその他の違いも可能です。したがって、著者は、この分野でさらなる調査を行う必要があることを推奨しています。
As a mitigation of this problem, this document recommends that testing with protocols using TCP (like HTTP and HTTPS up to version 2) can be performed as described in [RFC9411]. This approach also solves the potential problem of protocol helpers that may be present in the stateful DUT.
この問題の緩和として、このドキュメントでは、[RFC9411]で説明されているように、TCPを使用したプロトコル（HTTPやHTTPなど）を使用したテストを実行できることを推奨しています。このアプローチは、ステートフルDUTに存在する可能性のあるプロトコルヘルパーの潜在的な問題も解決します。
As for HTTP/3, it uses QUIC, which uses UDP as stated above. It should be noted that QUIC is treated as any other UDP payload. The proposed measurement method does not aim to measure the performance of QUIC, rather, it aims to measure the performance of the stateful NATxy gateway.
HTTP/3については、上記のようにUDPを使用するQUICを使用します。QUICは他のUDPペイロードとして扱われることに注意する必要があります。提案された測定方法は、QUICのパフォーマンスを測定することを目的としていません。むしろ、ステートフルなNatxyゲートウェイのパフォーマンスを測定することを目的としています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document has no further security considerations beyond that of [RFC8219]. They should be cited here so that they can be applied not only for the benchmarking of IPv6 transition technologies but also for the benchmarking of any stateful NATxy gateways (allowing for x=y, too).
このドキュメントには、[RFC8219]のそれ以外のセキュリティ上の考慮事項はありません。ここでは、IPv6遷移テクノロジーのベンチマークだけでなく、ステートフルNatxyゲートウェイのベンチマークにも適用できるように引用する必要があります（x = yも可能です）。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<https://www.rfc-editor.org/info/rfc4340>.
[RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked
Factors in Network Device Benchmarking", RFC 4814,
DOI 10.17487/RFC4814, March 2007,
<https://www.rfc-editor.org/info/rfc4814>.
[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, <https://www.rfc-editor.org/info/rfc5180>.
[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, <https://www.rfc-editor.org/info/rfc6146>.
[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, <https://www.rfc-editor.org/info/rfc7599>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9411] Balarajah, B., Rossenhoevel, C., and B. Monkman,
"Benchmarking Methodology for Network Security Device
Performance", RFC 9411, DOI 10.17487/RFC9411, March 2023,
<https://www.rfc-editor.org/info/rfc9411>.
[DUST1964] Durstenfeld, R., "Algorithm 235: Random permutation",
Communications of the ACM, vol. 7, no. 7, p. 420,
DOI 10.1145/364520.364540, July 1964,
<https://dl.acm.org/doi/pdf/10.1145/364520.364540>.
[IIR2020] Kurahashi, T., Matsuzaki, Y., Sasaki, T., Saito, T., and
F. Tsutsuji, "Periodic Observation Report: Internet Trends
as Seen from IIJ Infrastructure - 2020", Internet
Initiative Japan Inc., Internet Infrastructure Review,
vol. 49, December 2020,
<https://www.iij.ad.jp/en/dev/iir/pdf/
iir_vol49_report_EN.pdf>.
[LEN2015] Lencse, G., "Estimation of the Port Number Consumption of
Web Browsing", IEICE Transactions on Communications, vol.
E98-B, no. 8. pp. 1580-1588,
DOI 10.1587/transcom.E98.B.1580, August 2015,
<https://www.hit.bme.hu/~lencse/publications/
e98-b_8_1580.pdf>.
[LEN2020] Lencse, G., "Adding RFC 4814 Random Port Feature to
Siitperf: Design, Implementation and Performance
Estimation", International Journal of Advances in
Telecommunications, Electrotechnics, Signals and Systems,
vol 9, no 3, pp. 18-26., DOI 10.11601/ijates.v9i3.291,
November 2020,
<http://ijates.org/index.php/ijates/article/view/291>.
[LEN2022] Lencse, G., "Design and Implementation of a Software
Tester for Benchmarking Stateful NAT64xy Gateways: Theory
and Practice of Extending Siitperf for Stateful Tests",
Computer Communications, vol. 192, pp. 75-88,
DOI 10.1016/j.comcom.2022.05.028, August 2022,
<https://www.sciencedirect.com/science/article/pii/
S0140366422001803>.
[LEN2023] Lencse, G., Shima, K., and K. Cho, "Benchmarking
methodology for stateful NAT64 gateways", Computer
Communications, vol. 210, pp. 256-272,
DOI 10.1016/j.comcom.2023.08.009, October 2023,
<https://www.sciencedirect.com/science/article/pii/
S0140366423002931>.
[LEN2024a] Lencse, G. and Á. Bazsó, "Benchmarking methodology for
IPv4aaS technologies: Comparison of the scalability of the
Jool implementation of 464XLAT and MAP-T", Computer
Communications, vol. 219, pp. 243-258,
DOI 10.1016/j.comcom.2024.03.007, April 2024,
<https://www.sciencedirect.com/science/article/pii/
S0140366424000999>.
[LEN2024b] Lencse, G., "Making stateless and stateful network
performance measurements unbiased", Computer
Communications, vol. 225, pp. 141-155,
DOI 10.1016/j.comcom.2024.05.018, September 2024,
<https://www.sciencedirect.com/science/article/abs/pii/
S0140366424001993>.
[SCALABILITY]
Lencse, G., "Scalability of IPv6 Transition Technologies
for IPv4aaS", Work in Progress, Internet-Draft, draft-
lencse-v6ops-transition-scalability-05, 14 October 2023,
<https://datatracker.ietf.org/doc/html/draft-lencse-v6ops-
transition-scalability-05>.
[SIITPERF] "Siitperf: An RFC 8219 compliant SIIT and stateful NAT64/
NAT44 tester", commit 165cb7f, September 2023,
<https://github.com/lencsegabor/siitperf>.
The authors would like to thank Al Morton, Sarah Banks, Edwin Cordeiro, Lukasz Bromirski, Sándor Répás, Tamás Hetényi, Timothy Winters, Eduard Vasilenko, Minh Ngoc Tran, Paolo Volpato, Zeqi Lai, and Bertalan Kovács for their comments.
著者は、アル・モートン、サラ・バンクス、エドウィン・コルデイロ、ルーカス・ブロミルスキー、サンドール・レパス、タマス・ヘテニー、ティモシー・ウィンターズ、エドゥアルド・ヴァシレンコ、ミン・ンゴック・トラン、パオロ・ヴォルパト、ゼキ・ライ、そしてベルタラン・クワン・クワンのコメントに感謝したいと思います。
The authors thank Warren Kumari, Michael Scharf, Alexey Melnikov, Robert Sparks, David Dong, Roman Danyliw, Erik Kline, Murray Kucherawy, Zaheduzzaman Sarker, and Éric Vyncke for their reviews and comments.
著者は、ウォーレン・クマリ、マイケル・シャーフ、アレクセイ・メルニコフ、ロバート・スパークス、デビッド・ドン、ローマン・ダニリウ、エリック・クライン、マレー・クチェラウィー、ザヘダッザマン・サルカー、エリック・ヴィンチにレビューとコメントを感謝します。
This work was supported by the Japan Trust International Research Cooperation Program of the National Institute of Information and Communications Technology (NICT), Japan.
この作業は、国立情報通信技術（NICT）の日本信託国際研究協力プログラム（NICT）によってサポートされています。
Gábor Lencse
Széchenyi István University
Győr
Egyetem tér 1.
H-9026
Hungary
Email: lencse@sze.hu
Keiichi Shima
SoftBank Corp.
1-7-1 Kaigan, Minato-ku, Tokyo
105-7529
Japan
Email: shima@wide.ad.jp
URI: https://softbank.co.jp/