[要約] RFC 9347 は、ESPでIPパケットを集約および断片化するメカニズムを説明しており、IPトラフィックフローセキュリティを向上させることを目的としています。新しいペイロードタイプは、小さなIPパケットのカプセル化オーバーヘッドを減らすために使用できますが、この文書では、暗号化されたIPカプセル化トラフィックにトラフィックフロー機密性を追加することに焦点を当てています。
Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 9347 LabN Consulting, L.L.C.
Category: Standards Track January 2023
ISSN: 2070-1721
This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in Encapsulating Security Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IP Traffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage.
このドキュメントでは、セキュリティペイロードのカプセル化にカプセル化されている場合のIPパケットの集約と断片化のメカニズムについて説明します（ESP）。この新しいペイロードタイプは、小さなIPパケットのカプセル化オーバーヘッドの減少など、さまざまな目的に使用できます。ただし、このドキュメントの焦点は、トラフィックフローの機密性（TFC）を暗号化されたIPでカプセル化したトラフィックに追加することにより、IPトラフィックフローセキュリティ（IP-TFS）を強化することです。TFCは、固定サイズの一定のレートのIPSECトンネルを使用して、IPトラフィックのサイズと頻度を不明瞭にすることにより提供されます。このソリューションにより、混雑制御、および非緊張レートの使用法が可能になります。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9347.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9347で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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. Terminology & Concepts
2. The AGGFRAG Tunnel
2.1. Tunnel Content
2.2. Payload Content
2.2.1. DataBlocks
2.2.2. End Padding
2.2.3. Fragmentation, Sequence Numbers, and All-Pad Payloads
2.2.4. Empty Payload
2.2.5. IP Header Value Mapping
2.2.6. IPv4 Time To Live (TTL), IPv6 Hop Limit, and ICMP
Messages
2.2.7. Effective MTU of the Tunnel
2.3. Exclusive SA Use
2.4. Modes of Operation
2.4.1. Non-Congestion-Controlled Mode
2.4.2. Congestion-Controlled Mode
2.5. Summary of Receiver Processing
3. Congestion Information
3.1. ECN Support
4. Configuration of AGGFRAG Tunnels for IP-TFS
4.1. Bandwidth
4.2. Fixed Packet Size
4.3. Congestion Control
5. IKEv2
5.1. USE_AGGFRAG Notification Message
6. Packet and Data Formats
6.1. AGGFRAG_PAYLOAD Payload
6.1.1. Non-Congestion-Control AGGFRAG_PAYLOAD Payload Format
6.1.2. Congestion Control AGGFRAG_PAYLOAD Payload Format
6.1.3. Data Blocks
6.1.4. IKEv2 USE_AGGFRAG Notification Message
7. IANA Considerations
7.1. ESP Next Header Value
7.2. AGGFRAG_PAYLOAD Sub-Types
7.3. USE_AGGFRAG Notify Message Status Type
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example of an Encapsulated IP Packet Flow
Appendix B. A Send and Loss Event Rate Calculation
Appendix C. Comparisons of IP-TFS
C.1. Comparing Overhead
C.1.1. IP-TFS Overhead
C.1.2. ESP with Padding Overhead
C.2. Overhead Comparison
C.3. Comparing Available Bandwidth
C.3.1. Ethernet
Acknowledgements
Contributors
Author's Address
Traffic analysis [RFC4301] [AppCrypt] is the act of extracting information about data being sent through a network. While directly obscuring the data with encryption [RFC4303], the patterns in the message traffic may expose information due to variations in its shape and timing [RFC8546] [AppCrypt]. Hiding the size and frequency of traffic is referred to as Traffic Flow Confidentiality (TFC), per [RFC4303].
トラフィック分析[RFC4301] [AppCrypt]は、ネットワークを介して送信されるデータに関する情報を抽出する行為です。暗号化[RFC4303]を使用してデータを直接覆い隠している間、メッセージトラフィックのパターンは、その形状とタイミング[RFC8546] [AppCrypt]の変動により情報を公開する可能性があります。トラフィックのサイズと頻度を隠すことは、[RFC4303]ごとに、トラフィックフローの機密性（TFC）と呼ばれます。
[RFC4303] provides for TFC by allowing padding to be added to encrypted IP packets and allowing for transmission of all-pad packets (indicated using protocol 59). This method has the major limitation that it can significantly underutilize the available bandwidth.
[RFC4303]は、暗号化されたIPパケットにパディングを追加し、全パッドパケットの送信を可能にすることにより、TFCを提供します（プロトコル59を使用して示されています）。この方法には、利用可能な帯域幅を大幅に十分に活用できるという大きな制限があります。
This document defines an aggregation and fragmentation (AGGFRAG) mode for ESP, as well as ESP's use for IP Traffic Flow Security (IP-TFS). This solution provides for full TFC without the aforementioned bandwidth limitation. This is accomplished by using a constant-send-rate IPsec [RFC4303] tunnel with fixed-size encapsulating packets; however, these fixed-size packets can contain partial, whole, or multiple IP packets to maximize the bandwidth of the tunnel. A nonconstant send rate is allowed, but the confidentiality properties of its use are outside the scope of this document.
このドキュメントでは、ESPの集約とフラグメンテーション（AggFrag）モード、およびIPトラフィックフローセキュリティ（IP-TFS）に使用するESPの使用を定義しています。このソリューションは、前述の帯域幅の制限なしに完全なTFCを提供します。これは、固定サイズのカプセル化パケットを備えた一定のゼンドレートIPSEC [RFC4303]トンネルを使用することによって達成されます。ただし、これらの固定サイズのパケットは、トンネルの帯域幅を最大化するために、部分的、全体、または複数のIPパケットを含めることができます。コンセントではない送信料金は許可されていますが、その使用の機密性のプロパティは、このドキュメントの範囲外です。
For a comparison of the overhead of IP-TFS with the TFC solution prescribed in [RFC4303], see Appendix C.
[RFC4303]で規定されているTFCソリューションとのIP-TFSのオーバーヘッドとの比較については、付録Cを参照してください。
Additionally, IP-TFS provides for operating fairly within congested networks [RFC2914]. This is important for when the IP-TFS user is not in full control of the domain through which the IP-TFS tunnel path flows.
さらに、IP-TFSは、混雑したネットワーク[RFC2914]内で公正に動作することを規定しています。これは、IP-TFSユーザーがIP-TFSトンネルパスが流れるドメインを完全に制御しない場合に重要です。
The mechanisms, such as the AGGFRAG mode, defined in this document are generic with the intent of allowing for non-TFS uses, but such uses are outside the scope of this document.
このドキュメントで定義されているAggFragモードなどのメカニズムは、非TFSの使用を許可する意図と一般的なものですが、そのような用途はこのドキュメントの範囲外です。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document assumes familiarity with IP security concepts, including TFC, as described in [RFC4301].
このドキュメントは、[RFC4301]で説明されているように、TFCを含むIPセキュリティの概念に精通しています。
As mentioned in Section 1, the AGGFRAG mode utilizes an IPsec [RFC4303] tunnel as its transport. For the purpose of IP-TFS, fixed-size encapsulating packets are sent at a constant rate on the AGGFRAG tunnel.
セクション1で述べたように、AggFragモードはIPSEC [RFC4303]トンネルをその輸送として利用します。IP-TFSの目的で、固定サイズのカプセル化パケットは、AggFragトンネルの一定の速度で送信されます。
The primary input to the tunnel algorithm is the requested bandwidth to be used by the tunnel. Two values are then required to provide for this bandwidth use: the fixed size of the encapsulating packets and the rate at which to send them.
トンネルアルゴリズムへの主要な入力は、トンネルが使用する要求された帯域幅です。この帯域幅の使用を提供するには、2つの値が必要です。カプセル化パケットの固定サイズと、それらを送信するレートです。
The fixed packet size MAY either be specified manually or be determined through other methods, such as the Packetization Layer MTU Discovery (PLMTUD) [RFC4821] [RFC8899] or Path MTU Discovery (PMTUD) [RFC1191] [RFC8201]. PMTUD is known to have issues, so PLMTUD is considered the more robust option. For PLMTUD, congestion control payloads can be used as in-band probes (see Section 6.1.2 and [RFC8899]).
固定パケットサイズは、手動で指定するか、パケット化レイヤーMTU発見（PLMTUD）[RFC4821] [RFC8899]またはPATH MTU発見（PMTUD）[RFC1191] [RFC8201]など、他の方法で決定することができます。PMTUDには問題があることが知られているため、PLMTUDはより堅牢なオプションと見なされます。PLMTUDの場合、輻輳制御ペイロードはバンド内プローブとして使用できます（セクション6.1.2および[RFC8899]を参照）。
Given the encapsulating packet size and the requested bandwidth to be used, the corresponding packet send rate can be calculated. The packet send rate is the requested bandwidth to be used, which is then divided by the size of the encapsulating packet.
カプセル化パケットサイズと使用する要求された帯域幅を考えると、対応するパケット送信レートを計算できます。パケット送信レートは、使用する要求された帯域幅であり、それをカプセル化するパケットのサイズで除算します。
The egress (receiving) side of the AGGFRAG tunnel MUST allow for and expect the ingress (sending) side of the AGGFRAG tunnel to vary the size and rate of sent encapsulating packets, unless constrained by other policy.
Aggfragトンネルの出口（受信）側は、他のポリシーに制約されない限り、Aggfragトンネルの侵入（送信）側を許可し、予想しなければなりません。
As previously mentioned, one issue with the TFC padding solution in [RFC4303] is the large amount of wasted bandwidth, as only one IP packet can be sent per encapsulating packet. In order to maximize bandwidth, IP-TFS breaks this one-to-one association by introducing an AGGFRAG mode for ESP.
前述のように、[RFC4303]のTFCパディングソリューションの1つの問題は、カプセル化パケットごとに1つのIPパケットを送信できるため、無駄な帯域幅の大量です。帯域幅を最大化するために、IP-TFSはESPのAggFragモードを導入することにより、この1対1の関連性を破ります。
The AGGFRAG mode aggregates and fragments the inner IP traffic flow into encapsulating IPsec tunnel packets. For IP-TFS, the IPsec encapsulating tunnel packets are a fixed size. Padding is only added to the tunnel packets if there is no data available to be sent at the time of tunnel packet transmission or if fragmentation has been disabled by the receiver.
AggFragモードは、内部IPトラフィックがカプセル化されたIPSECトンネルパケットに集計し、断片化します。IP-TFSの場合、IPSECカプセル化トンネルパケットは固定サイズです。パディングは、トンネルパケット送信時に送信されるデータがない場合、または受信機によって断片化が無効になっている場合にのみ、トンネルパケットに追加されます。
This is accomplished using a new Encapsulating Security Payload (ESP) [RFC4303] Next Header field value AGGFRAG_PAYLOAD (Section 6.1).
これは、新しいカプセル化セキュリティペイロード（ESP）[RFC4303]次のヘッダーフィールド値AGGFRAG_PAYLOAD（セクション6.1）を使用して達成されます。
Other non-IP-TFS uses of this AGGFRAG mode have been suggested, such as increased performance through packet aggregation, as well as handling MTU issues using fragmentation. These uses are not defined here but are also not restricted by this document.
このAggFragモードの他の非IP-TFSの使用は、パケット集約によるパフォーマンスの向上、断片化を使用したMTUの問題の処理など、提案されています。これらの用途はここでは定義されていませんが、このドキュメントでも制限されていません。
The AGGFRAG_PAYLOAD payload content defined in this document consists of a 4- or 24-octet header, followed by either a partial data block, a full data block, or multiple partial or full data blocks. The following diagram illustrates this payload within the ESP packet. See Section 6.1 for the exact formats of the AGGFRAG_PAYLOAD payload.
このドキュメントで定義されているAGGFRAG_PAYLOADペイロードコンテンツは、4または24オクテットのヘッダーで構成され、その後、部分データブロック、完全なデータブロック、または複数の部分データブロックまたは完全なデータブロックが続きます。次の図は、ESPパケット内のこのペイロードを示しています。AGGFRAG_PAYLOADペイロードの正確な形式については、セクション6.1を参照してください。
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Outer Encapsulating Header ... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. ESP Header... .
+---------------------------------------------------------------+
| [AGGFRAG sub-type/flags] : BlockOffset |
+---------------------------------------------------------------+
: [Optional Congestion Info] :
+---------------------------------------------------------------+
| DataBlocks ... ~
~ ~
~ |
+---------------------------------------------------------------|
. ESP Trailer... .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 1: Layout of an AGGFRAG Mode IPsec Packet
図1：AggFragモードIPSECパケットのレイアウト
The BlockOffset value is either zero or some offset into or past the end of the DataBlocks data.
ブロックオフセット値は、DataBlocksデータの端にゼロまたはオフセットまたは過去のいずれかです。
If the BlockOffset value is zero, it means that the DataBlocks data begins with a new data block.
ブロックオフセット値がゼロの場合、Datablocksデータは新しいデータブロックから始まることを意味します。
Conversely, if the BlockOffset value is non-zero, it points to the start of the new data block, and the initial DataBlocks data belongs to the data block that is still being reassembled.
逆に、ブロックオフセット値がゼロではない場合、新しいデータブロックの開始を指し、最初のDataBlocksデータはまだ再組み立てされているデータブロックに属します。
If the BlockOffset points past the end of the DataBlocks data, then the next data block occurs in a subsequent encapsulating packet.
BlockOffsetがDataBlocksデータの端を超えて指している場合、次のデータブロックは後続のカプセル化パケットで発生します。
Having the BlockOffset always point at the next available data block allows for recovering the next inner packet in the presence of outer encapsulating packet loss.
BlockOffsetを常に次の使用可能なデータブロックでポイントすることで、外側のカプセル化パケット損失が存在する場合に次の内側パケットを回復できます。
An example AGGFRAG mode packet flow can be found in Appendix A.
アグフラグモードのパケットフローの例は、付録Aにあります。
+---------------------------------------------------------------+
| Type | rest of IPv4, IPv6, or pad...
+--------
Figure 2: Layout of a Data Block
図2：データブロックのレイアウト
A data block is defined by a 4-bit type code, followed by the data block data. The type values have been carefully chosen to coincide with the IPv4/IPv6 version field values so that no per-data block type overhead is required to encapsulate an IP packet. Likewise, the length of the data block is extracted from the encapsulated IPv4's Total Length or IPv6's Payload Length fields.
データブロックは、4ビットタイプコードで定義され、その後にデータブロックデータが続きます。タイプの値は、IPv4/IPv6バージョンのフィールド値と一致するように慎重に選択されているため、IPパケットをカプセル化するためにDATAごとのブロックタイプのオーバーヘッドは必要ありません。同様に、データブロックの長さは、カプセル化されたIPv4の全長またはIPv6のペイロード長フィールドから抽出されます。
Since a data block's type is identified in its first 4 bits, the only time padding is required is when there is no data to encapsulate. For this end padding, a Pad Data Block is used.
データブロックのタイプは最初の4ビットで識別されるため、パディングが必要なのは、カプセル化するデータがない場合です。このエンドパディングでは、パッドデータブロックが使用されます。
In order for a receiver to reassemble fragmented inner packets, the sender MUST send the inner packet fragments back to back in the logical outer packet stream (i.e., using consecutive ESP sequence numbers). However, the sender is allowed to insert "all-pad" payloads (i.e., payloads with a BlockOffset of zero and a single pad data block ) in between the packets carrying the inner packet fragment payloads. This interleaving of all-pad payloads allows the sender to always send a tunnel packet, regardless of the encapsulation computational requirements.
受信者が断片化された内側パケットを再組み立てるために、送信者は、論理外側パケットストリームに内側のパケットフラグメントを背中に戻す必要があります（つまり、連続したESPシーケンス番号を使用）。ただし、送信者は、内側のパケットフラグメントペイロードを運ぶパケットの間に「ゼロのブロックオフセットと単一のパッドデータブロックを備えたペイロード）を挿入することができます。この全パッドペイロードのこのインターリービングにより、送信者は、カプセル化の計算要件に関係なく、常にトンネルパケットを送信できます。
When a receiver is reassembling an inner packet, and it receives an "all-pad" payload, it increments the expected sequence number that the next inner packet fragment is expected to arrive in.
受信機が内側のパケットを再組み立てし、「全パッド」ペイロードを受信すると、次の内側パケットフラグメントが到着する予定の予想シーケンス番号が増加します。
Given the above, the receiver will need to handle out-of-order arrival of outer ESP packets prior to reassembly processing. ESP already provides for optionally detecting replay attacks. Detecting replay attacks normally utilizes a window method. A similar sequence-number-based sliding window can be used to correct reordering of the outer packet stream. Receiving a larger (newer) sequence number packet advances the window, and if any older ESP packets whose sequence numbers the window has passed by are received, then the packets are dropped. A good choice for the size of this window depends on the amount of misordering the user is experiencing; however, a value of 3 has been suggested as a default when no more informed choice exists.
上記を考慮して、受信者は、再組み立て処理の前に外側のESPパケットの外れている到着を処理する必要があります。ESPは、オプションでリプレイ攻撃を検出することを既に提供しています。リプレイ攻撃の検出は通常、ウィンドウメソッドを使用します。同様のシーケンス番号ベースのスライディングウィンドウを使用して、外側のパケットストリームの並べ替えを修正できます。大きい（新しい）シーケンス番号パケットを受信すると、ウィンドウが進行し、ウィンドウが通過したシーケンス番号を受け取った古いESPパケットを受信した場合、パケットがドロップされます。このウィンドウのサイズに適した選択は、ユーザーが経験している誤った注文の量によって異なります。ただし、情報に基づいた選択が存在しない場合、3の値はデフォルトとして提案されています。
As the amount of misordering that may be present is hard to predict, the window size SHOULD be configurable by the user. Implementations MAY also dynamically adjust the reordering window based on actual misordering seen in arriving packets.
存在する可能性のある誤った注文の量を予測するのは困難であるため、ウィンドウサイズはユーザーが構成できる必要があります。また、実装は、到着パケットに見られる実際の誤った秩序化に基づいて、並べ替えウィンドウを動的に調整することもできます。
Please note, when IP-TFS sends a continuous stream of packets, there is no requirement for an explicit lost packet timer; however, using a lost packet timer is RECOMMENDED. If an implementation does not use a lost packet timer and only considers an outer packet lost when the reorder window moves by it, the inner traffic can be delayed by up to the reorder window size times the per-packet send rate. This delay could be significant for slower send rates or when larger reorder window sizes are in use. As the lost packet timer affects the delay of inner packet delivery, an implementation or user could choose to set it proportionate to the tunnel rate.
IP-TFSがパケットの連続ストリームを送信する場合、明示的な失われたパケットタイマーの要件はありません。ただし、紛失したパケットタイマーを使用することをお勧めします。実装が紛失したパケットタイマーを使用せず、再注文ウィンドウが移動するときに外側のパケットが失われたと考える場合、内部トラフィックは、パケットごとの送信レートの再注文ウィンドウサイズの時間までに遅延することができます。この遅延は、送信金利が遅い場合、またはより大きな再注文ウィンドウサイズが使用されている場合に重要になる可能性があります。失われたパケットタイマーは内部パケット配信の遅延に影響するため、実装またはユーザーがトンネルレートに比例して設定することを選択できます。
While ESP guarantees an increasing sequence number with subsequently sent packets, it does not actually require the sequence numbers to be generated consecutively (e.g., sending only even-numbered sequence numbers would be allowed, as long as they are always increasing). Gaps in the sequence numbers will not work for this document, so the sequence number stream MUST increase monotonically by 1 for each subsequent packet.
ESPは、その後送信されたパケットでシーケンス番号を増やすことを保証しますが、実際には連続してシーケンス番号を生成する必要はありません（たとえば、均等なシーケンス番号のみを送信することは、常に増加している限り許可されます）。シーケンス番号のギャップはこのドキュメントでは機能しないため、シーケンス番号ストリームは、後続のパケットごとに単調に1だけ増加する必要があります。
When using the AGGFRAG_PAYLOAD in conjunction with replay detection, the window size for both MAY be reduced to the smaller of the two window sizes. This is because packets outside of the smaller window but inside the larger window would still be dropped by the mechanism with the smaller window size. However, there is also no requirement to make these values the same. Indeed, in some cases, such as slow tunnels where a very small or zero reorder window size is appropriate, the user may still want a large replay detection window to log replayed packets. Additionally, large replay windows can be implemented with very little overhead, compared to large reorder windows.
Replay検出と組み合わせてAggFrag_Payloadを使用する場合、両方のウィンドウサイズが2つのウィンドウサイズのうち小さい方に縮小される場合があります。これは、小さなウィンドウの外側のパケットが、より小さなウィンドウのサイズのメカニズムによって引き下げられるためです。ただし、これらの値を同じようにするための要件もありません。実際、場合によっては、非常に小さいまたはゼロの再注文ウィンドウサイズが適切な遅いトンネルなど、ユーザーは再生されたパケットをログにするために大きなリプレイ検出ウィンドウが必要になる場合があります。さらに、大きな再注文ウィンドウと比較して、オーバーヘッドがほとんどなく、大きなリプレイウィンドウを実装できます。
Finally, as sequence numbers are reset when switching Security Associations (SAs) (e.g., when rekeying a Child SA), senders MUST NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA.
最後に、セキュリティアソシエーション（SAS）を切り替えるとシーケンス番号がリセットされるため（たとえば、子SAを再キーにするとき）、送信者は1つのSAとその後のSAでその後のフラグメントを使用して内側のパケットの初期フラグメントを送信してはなりません。
A note on BlockOffset values: Senders MUST encode the BlockOffset consistently with the immediately preceding non-all-pad payload packet. Specifically, if the immediately preceding non-all-pad payload packet ended with a Pad Data Block, this BlockOffset MUST be zero, as Pad Data Blocks are never fragmented. The BlockOffset MUST be consistent with the remaining size implied by the length field from the fragmented inner packet.
ブロックオフセット値に関するメモ：送信者は、ブロックオフセットを直前の非オールパッドペイロードパケットと一貫してエンコードする必要があります。具体的には、パッドデータブロックが断片化されないため、直前の非パッドペイロードパケットがパッドデータブロックで終了した場合、このブロックオフセットはゼロでなければなりません。ブロックオフセットは、断片化された内側パケットから長さフィールドによって暗示される残りのサイズと一致する必要があります。
When the tunnel bandwidth is not being fully utilized, a sender MAY pad out the current encapsulating packet in order to deliver an inner packet unfragmented in the following outer packet. The benefit would be to avoid inner packet fragmentation in the presence of a bursty offered load (non-bursty traffic will naturally not fragment). Senders MAY also choose to allow for a minimum fragment size to be configured (e.g., as a percentage of the AGGFRAG_PAYLOAD payload size) to avoid fragmentation at the cost of tunnel bandwidth. The costs with these methods are complexity and an added delay of inner traffic. The main advantage to avoiding fragmentation is to minimize inner packet loss in the presence of outer packet loss. When this is worthwhile (e.g., how much loss and what type of loss is required, given different inner traffic shapes and utilization, for this to make sense) and what values to use for the allowable/added delay may be worth researching but is outside the scope of this document.
トンネルの帯域幅が完全に使用されていない場合、送信者は、次の外側パケットでフラージュされていない内側のパケットを配信するために、現在のカプセル化パケットを埋めることができます。利点は、バーストされた提供された負荷の存在下で内側のパケットの断片化を避けることです（非燃えるトラフィックは当然フラグメントではありません）。送信者は、トンネル帯域幅のコストでの断片化を避けるために、最小フラグメントサイズを構成することを選択することもできます（たとえば、AGGFRAG_Payloadペイロードサイズの割合として）。これらの方法のコストは、複雑さと内部交通の追加の遅延です。断片化を回避することの主な利点は、外側のパケット損失の存在下での内部パケット損失を最小限に抑えることです。これが価値がある場合（たとえば、これを意味するために、さまざまな内部交通形状と使用率を考えると、どのくらいの損失と損失の種類が必要か）、許容/追加の遅延に使用する価値は調査する価値があるかもしれませんが、外にありますこのドキュメントの範囲。
While use of padding to avoid fragmentation does not impact interoperability, if padding is used inappropriately, it can reduce the effective throughput of a tunnel. Senders implementing either of the above approaches will need to take care to not reduce the effective capacity, and overall utility, of the tunnel through the overuse of padding.
断片化を回避するためにパディングを使用しても相互運用性に影響を与えませんが、パディングが不適切に使用されている場合、トンネルの効果的なスループットを減らすことができます。上記のアプローチのいずれかを実装する送信者は、パディングの過剰使用を通じてトンネルの有効能力と全体的な有用性を減らないように注意する必要があります。
To support reporting of congestion control information (described later) using a non-AGGFRAG_PAYLOAD-enabled SA, it is allowed to send an AGGFRAG_PAYLOAD payload with no data blocks (i.e., the ESP payload length is equal to the AGGFRAG_PAYLOAD header length). This special payload is called an empty payload.
非AGGFRAG_PAYLOAD対応のSAを使用して、輻輳制御情報の報告（後述）をサポートするために、データブロックなしでAGGFRAG_PAYLOADペイロードを送信することができます（つまり、ESPペイロード長はAGGFRAG_PAYLOADヘッダー長に等しくなります）。この特別なペイロードは、空のペイロードと呼ばれます。
Currently, this situation is only applicable in use cases without Internet Key Exchange Protocol Version 2 (IKEv2).
現在、この状況は、インターネットキー交換プロトコルバージョン2（IKEV2）のないユースケースでのみ適用されます。
[RFC4301] provides some direction on when and how to map various values from an inner IP header to the outer encapsulating header, namely the Don't Fragment (DF) bit [RFC0791], the Differentiated Services (DS) field [RFC2474], and the Explicit Congestion Notification (ECN) field [RFC3168]. Unlike in [RFC4301], the AGGFRAG mode may, and often will, be encapsulating more than one IP packet per ESP packet. To deal with this, these mappings are restricted further.
[RFC4301]は、内側のIPヘッダーから外部カプセル化ヘッダーにさまざまな値をマッピングする時期と方法に関するある程度の方向を提供します。および明示的な混雑通知（ECN）フィールド[RFC3168]。[RFC4301]とは異なり、AggFragモードは、ESPパケットごとに複数のIPパケットをカプセル化する場合があります。これに対処するために、これらのマッピングはさらに制限されています。
The AGGFRAG mode never maps the inner DF bit, as it is unrelated to the AGGFRAG tunnel functionality; the AGGFRAG mode never needs to IP fragment the inner packets, and the inner packets will not affect the fragmentation of the outer encapsulation packets.
AggFragモードは、AggFragトンネルの機能とは無関係であるため、内側のDFビットをマップすることはありません。AggFragモードは、内側のパケットをIPフラグメントする必要はなく、内側のパケットは外側のカプセル化パケットの断片化に影響しません。
The ECN value need not be mapped, as any congestion related to the constant-send-rate IP-TFS tunnel is unrelated (by design) to the inner traffic flow. The sender MAY still set the ECN value of inner packets based on the normal ECN specification [RFC3168] [RFC4301] [RFC6040].
eCN値をマッピングする必要はありません。一定のレートのIP-TFSトンネルに関連する混雑は、内部の交通フローとは無関係に（設計上）関連しています。送信者は、通常のECN仕様[RFC3168] [RFC4301] [RFC6040]に基づいて、内部パケットのECN値を設定することができます。
By default, the DS field SHOULD NOT be copied, although a sender MAY choose to allow for configuration to override this behavior. A sender SHOULD also allow the DS value to be set by configuration.
デフォルトでは、DSフィールドをコピーしてはなりませんが、送信者はこの動作をオーバーライドする構成を許可することを選択できます。送信者は、DS値を構成によって設定できるようにする必要があります。
How to modify the inner packet IPv4 TTL [RFC0791] or IPv6 Hop Limit [RFC8200] is specified in [RFC4301].
内側のパケットIPv4 TTL [RFC0791]またはIPv6ホップ制限[RFC8200]を変更する方法[RFC4301]で指定されています。
[RFC4301] specifies how to apply policy to authenticated and unauthenticated ICMP error packets (e.g., Destination Unreachable) arriving at or being forwarded through the endpoint, in particular, whether to process, ignore, or forward said packets. With the one exception that this document does not change the handling of these packets, they should be handled as specified in [RFC4301].
[RFC4301]は、エンドポイントに到着または転送される認証および認証されていないICMPエラーパケット（到達不能など）、特に処理、無視、または前向きなパケットを介して転送されることにポリシーを適用する方法を指定します。このドキュメントがこれらのパケットの処理を変更しないという1つの例外を除き、[RFC4301]で指定されているように処理する必要があります。
The one way in which an AGGFRAG tunnel differs in ICMP error packet mechanics is with PMTU. When fragmentation is enabled on the AGGFRAG tunnel, then no ICMP "Too Big" errors need to be generated for arriving ingress traffic, as the arriving inner packets will be naturally fragmented by the AGGFRAG encapsulation.
ICMPエラーパケットメカニクスでAggFragトンネルが異なる1つの方法は、PMTUの場合です。Aggfragトンネルでフラグメンテーションが有効になると、到着する内側のパケットがAggfragのカプセル化によって自然に断片化されるため、INGMPの「大きすぎる」エラーを生成する必要はありません。
Otherwise, when fragmentation has been disabled on the AGGFRAG tunnel, then the treatment of arriving inner traffic exactly maps to that of a non-AGGFRAG ESP tunnel. Explicitly, IPv4 with DF set and IPv6 packets that cannot fit in its own outer packet payload will generate the appropriate ICMP "Too Big" error, as described in [RFC4301], and IPv4 packets without DF set will be IP fragmented, as described in [RFC4301].
それ以外の場合、断片化がアグフラグトンネルで無効になっている場合、内部の交通を到達する処理は、非aggfrag espトンネルのそれに正確にマップします。明示的に、DFセットを備えたIPv4および独自の外側のパケットペイロードに収まることができないIPv6パケットは、[RFC4301]で説明されているように、適切なICMP「大きすぎる」エラーを生成し、DFセットのないIPv4パケットはIP断片化されます。[RFC4301]。
Packets egressing the tunnel continue to be handled as specified in [RFC4301].
トンネルの出力をするパケットは、[RFC4301]で指定されているように引き続き処理されます。
All other aspects of PMTU and the handling of ICMP "Too Big" messages (i.e., with regards to the outer AGGFRAG/ESP tunnel packet size) also remain unchanged from [RFC4301].
PMTUの他のすべての側面とICMPの「大きすぎる」メッセージ（つまり、外側のAggfrag/ESPトンネルパケットサイズに関して）の取り扱いも[RFC4301]から変更されません。
Unlike in [RFC4301], there is normally no effective MTU (EMTU) on an AGGFRAG tunnel, as all IP packet sizes are properly transmitted without requiring IP fragmentation prior to tunnel ingress. That said, a sender MAY allow for explicitly configuring an MTU for the tunnel.
[RFC4301]とは異なり、すべてのIPパケットサイズはトンネルイングレスの前にIP断片化を必要とせずに適切に送信されるため、通常、AggFragトンネルに効果的なMTU（EMTU）はありません。とはいえ、送信者は、トンネル用のMTUを明示的に構成することを可能にする場合があります。
If fragmentation has been disabled on the AGGFRAG tunnel, then the tunnel's EMTU and behaviors are the same as normal IPsec tunnels [RFC4301].
Aggfragトンネルで断片化が無効になっている場合、トンネルのEMTUと行動は通常のIPSECトンネルと同じです[RFC4301]。
This document does not specify mixed use of an AGGFRAG_PAYLOAD-enabled SA. A sender MUST only send AGGFRAG_PAYLOAD payloads over an SA configured for AGGFRAG mode.
このドキュメントでは、AGGFRAG_PAYLOAD-ENABLED SAの混合使用を指定していません。送信者は、AggFragモード向けに構成されたSAに対してAggFrag_Payloadペイロードのみを送信する必要があります。
Just as with normal IPsec/ESP SAs, AGGFRAG SAs are unidirectional. Bidirectional IP-TFS functionality is achieved by setting up 2 AGGFRAG SAs, one in either direction.
通常のIPSEC/ESP SASと同様に、Aggfrag SASは単方向です。双方向IP-TFS機能は、どちらの方向にも2つのAggfrag SASをセットアップすることで実現されます。
An AGGFRAG tunnel used for IP-TFS can operate in 2 modes, a non-congestion-controlled mode and congestion-controlled mode.
IP-TFSに使用されるAggFragトンネルは、2つのモード、非合成コントロールモードと輻輳制御モードで動作できます。
In the non-congestion-controlled mode, IP-TFS sends fixed-size packets over an AGGFRAG tunnel at a constant rate. The packet send rate is constant and is not automatically adjusted, regardless of any network congestion (e.g., packet loss).
非合成コントロールモードでは、IP-TFSは一定の速度でAggFragトンネル上に固定サイズのパケットを送信します。パケット送信レートは一定であり、ネットワークの輻輳（パケット損失など）に関係なく、自動的に調整されません。
For similar reasons as given in [RFC7510], the non-congestion-controlled mode MUST only be used where the user has full administrative control over any path the tunnel will take and MUST NOT be used if this is not the case. This is required so the user can guarantee the bandwidth and also be sure as to not be negatively affecting network congestion [RFC2914]. In this case, packet loss should be reported to the administrator (e.g., via syslog, YANG notification, SNMP traps, etc.) so that any failures due to a lack of bandwidth can be corrected. The use of circuit breakers is also RECOMMENDED (Section 2.4.2.1).
[RFC7510]で与えられた同様の理由により、非合成制御モードは、ユーザーがトンネルがとるパスを完全に管理することを行う場合にのみ使用する必要があり、そうでない場合は使用してはなりません。これが必要なので、ユーザーは帯域幅を保証し、ネットワークの輻輳に悪影響を及ぼさないようにしてください[RFC2914]。この場合、帯域幅の不足による障害を修正できるように、パケットの損失を管理者（たとえば、Syslog、Yang通知、SNMPトラップなどを介して）に報告する必要があります。回路ブレーカーの使用もお勧めします（セクション2.4.2.1）。
Users that choose the non-congestion-controlled mode need to understand that this mode will send packets at a constant rate, utilizing a constant, fixed bandwidth, and will not adjust based on congestion. Thus, if they do not guarantee the bandwidth required by the tunnel, the tunnel's operation, as well as the rest of their network, may be negatively impacted.
非合成モードを選択するユーザーは、このモードが一定の固定帯域幅を利用して一定の速度でパケットを送信することを理解する必要があり、混雑に基づいて調整されません。したがって、トンネルが必要とする帯域幅を保証しない場合、トンネルの操作、およびネットワークの残りの部分が悪影響を受ける可能性があります。
One expected use case for the non-congestion-controlled mode is to guarantee the full tunnel bandwidth is available and preferred over other non-tunnel traffic. In fact, a typical site-to-site use case might have all of the user traffic utilizing the IP-TFS tunnel.
非合成コントロールモードの予想されるユースケースの1つは、他の非トンネルトラフィックよりもトンネル帯域幅全体が利用可能であることを保証することです。実際、典型的なサイトからサイトへのユースケースでは、すべてのユーザートラフィックがIP-TFSトンネルを利用している可能性があります。
The non-congestion-controlled mode is also appropriate if ESP over TCP is in use [RFC9329]. However, the use of TCP is considered a fallback-only solution for IPsec; it is highly not preferred. This is also one of the reasons that TCP was not chosen as the encapsulation for IP-TFS instead of AGGFRAG.
ESP上のTCPが使用されている場合、非合成コントロールモードも適切です[RFC9329]。ただし、TCPの使用は、IPSECのフォールバックのみのソリューションと見なされます。それは非常に好まれていません。これは、AggFragの代わりにIP-TFSのカプセル化としてTCPが選択されなかった理由の1つでもあります。
With the congestion-controlled mode, IP-TFS adapts to network congestion by lowering the packet send rate to accommodate the congestion, as well as raising the rate when congestion subsides. Since overhead is per packet, by allowing for maximal fixed-size packets and varying the send rate, transport overhead is minimized.
輻輳制御モードでは、IP-TFSは、混雑に対応するためにパケット送信レートを下げることと、混雑が沈むときにレートを上げることにより、ネットワーク輻輳に適応します。オーバーヘッドはパケットごとにあるため、最大固定サイズのパケットを許可し、送信レートを変化させることにより、輸送オーバーヘッドが最小化されます。
The output of the congestion control algorithm will adjust the rate at which the ingress sends packets. While this document does not require a specific congestion control algorithm, best current practice RECOMMENDS that the algorithm conform to [RFC5348]. Congestion control principles are documented in [RFC2914] as well. There is an example in [RFC4342] of the algorithm in [RFC5348], which matches the requirements of IP-TFS (i.e., designed for fixed-size packets and send rate varied based on congestion).
輻輳制御アルゴリズムの出力は、イングレスがパケットを送信する速度を調整します。このドキュメントでは特定の混雑制御アルゴリズムは必要ありませんが、最良の現在の練習では、アルゴリズムが[RFC5348]に適合することを推奨しています。混雑制御原則は[RFC2914]にも文書化されています。[RFC5348]のアルゴリズムの[RFC4342]には、IP-TFSの要件に一致する例があります（つまり、固定サイズのパケット用に設計され、渋滞に基づいてさまざまなレートを送信します）。
The required inputs for the TCP-friendly rate control algorithm described in [RFC5348] are the receiver's loss event rate and the sender's estimated round-trip time (RTT). These values are provided by IP-TFS using the congestion information header fields described in Section 3. In particular, these values are sufficient to implement the algorithm described in [RFC5348].
[RFC5348]で説明されているTCPフレンドリーレート制御アルゴリズムに必要な入力は、受信者の損失イベント率と送信者の推定往復時間（RTT）です。これらの値は、セクション3で説明されている混雑情報ヘッダーフィールドを使用してIP-TFによって提供されます。特に、これらの値は[RFC5348]で説明されているアルゴリズムを実装するのに十分です。
At a minimum, the congestion information MUST be sent, from the receiver and from the sender, at least once per RTT. Prior to establishing an RTT, the information SHOULD be sent constantly from the sender and the receiver so that an RTT estimate can be established. Not receiving this information over multiple consecutive RTT intervals should be considered a congestion event that causes the sender to adjust its sending rate lower. For example, this is called the "no feedback timeout" in [RFC4342], and it is equal to 4 RTT intervals. When a "no feedback timeout" has occurred, the sending rate is halved, as per [RFC4342].
少なくとも、RTTごとに少なくとも1回は、受信者と送信者から輻輳情報を送信する必要があります。RTTを確立する前に、RTTの見積もりを確立できるように、情報を送信者と受信機から絶えず送信する必要があります。複数の連続したRTT間隔でこの情報を受け取らないことは、送信者が送信率を低く調整する輻輳イベントと見なされるべきです。たとえば、これは[RFC4342]の「ノーフィードバックタイムアウト」と呼ばれ、4つのRTT間隔に等しくなります。[フィードバックタイムアウトなし]が発生した場合、[RFC4342]に従って送信率が半分になります。
An implementation MAY choose to always include the congestion information in its AGGFRAG payload header if it is sending it on an IP-TFS-enabled SA. Since IP-TFS normally will operate with a large packet size, the congestion information should represent a small portion of the available tunnel bandwidth. An implementation choosing to always send the data MAY also choose to only update the LossEventRate and RTT header field values it sends every RTT through.
実装は、IP-TFS対応SAで送信している場合、AggFragペイロードヘッダーに渋滞情報を常に含めることを選択できます。IP-TFSは通常、大きなパケットサイズで動作するため、混雑情報は利用可能なトンネル帯域幅のごく一部を表す必要があります。常にデータを送信することを選択する実装は、すべてのRTTを通過するLosseventrateおよびRTTヘッダーフィールド値を更新することのみを選択する場合があります。
When choosing a congestion control algorithm (or a selection of algorithms), note that IP-TFS is not providing for reliable delivery of IP traffic, and so per-packet acknowledgements (ACKs) are not required and are not provided.
輻輳制御アルゴリズム（またはアルゴリズムの選択）を選択する場合、IP-TFSはIPトラフィックの信頼できる配信を提供していないため、パケットごとの確認（ACK）は必要ありません。
It is worth noting that the variable send rate of a congestion-controlled AGGFRAG tunnel is not private; however, this send rate is being driven by network congestion, and as long as the encapsulated (inner) traffic flow shape and timing are not directly affecting the (outer) network congestion, the variations in the tunnel rate will not weaken the provided inner traffic flow confidentiality.
混雑制御されたaggfragトンネルの変数送信レートはプライベートではないことは注目に値します。ただし、この送信レートはネットワークの輻輳によって駆動されており、カプセル化された（内側の）トラフィックフローの形状とタイミングが（外側の）ネットワークの混雑に直接影響しない限り、トンネル速度の変動は提供された内部トラフィックを弱めませんフローの機密性。
In addition to congestion control, implementations that support the non-congestion-control mode SHOULD implement circuit breakers [RFC8084] as a recovery method of last resort. When circuit breakers are enabled, an implementation SHOULD also enable congestion control reports so that circuit breakers have information to act on.
混雑制御に加えて、非合成コントロールモードをサポートする実装は、最後の手段の回復方法として回路ブレーカー[RFC8084]を実装する必要があります。サーキットブレーカーが有効になっている場合、実装により、回路ブレーカーが行動する情報があるように、渋滞制御レポートも有効にする必要があります。
The pseudowire congestion considerations [RFC7893] are equally applicable to the mechanisms defined in this document, notably the text on inelastic traffic.
擬似化渋滞の考慮事項[RFC7893]は、このドキュメントで定義されているメカニズム、特に非弾性トラフィックに関するテキストに等しく適用できます。
One example of a simple, slow-trip circuit breaker that an implementation may provide would utilize 2 values: the amount of persistent loss rate required to trip the circuit breaker and the required length of time this persistent loss rate must be seen to trip the circuit breaker. These 2 value are required configurations from the user. When the circuit breaker is tripped, the tunnel traffic is disabled and an appropriate log message or other management type alarm is triggered, indicating operation intervention is required.
実装が提供する可能性のあるシンプルで遅いトリップ回路ブレーカーの1つの例は、2つの値を利用します。回路ブレーカーをトリップするのに必要な持続的な損失率と、必要な時間の長さこの永続的な損失率を回路のトリップに見なければなりません。ブレーカ。これらの2つの値は、ユーザーからの必要な構成です。回路ブレーカーがつまずかれると、トンネルのトラフィックが無効になり、適切なログメッセージまたはその他の管理型アラームがトリガーされ、操作介入が必要であることが示されています。
An AGGFRAG-enabled SA receiver has a few tasks to perform.
Aggfrag対応SAレシーバーには、実行するタスクがいくつかあります。
The receiver MAY process incoming AGGFRAG_PAYLOAD payloads as soon as they arrive, as much as it can, i.e., if the incoming AGGFRAG_PAYLOAD packet contains complete inner packet(s), the receiver should extract and transmit them immediately. For partial packets, the receiver needs to keep the partial packets in the memory until they fall out from the reordering window or until the missing parts of the packets are received, in which case, it will reassemble and transmit them. If the AGGFRAG_PAYLOAD payload contains multiple packets, they SHOULD be sent out in the order they are in the AGGFRAG_PAYLOAD (i.e., keep the original order they were received on the other end). The cost of using this method is that an amplification of out-of-order delivery of inner packets can occur due to inner packet aggregation.
受信者は、できる限り、到着したらすぐにaggfrag_payloadペイロードを処理することができます。つまり、着信Aggfrag_payloadパケットに完全な内側パケットが含まれている場合、受信者はすぐに抽出して送信する必要があります。部分的なパケットの場合、受信者は、並べ替えウィンドウから外れるまで、またはパケットの欠落部分が受信されるまでメモリに部分的なパケットを保持する必要があります。その場合、それらを再組み立てして送信します。AggFrag_Payloadペイロードに複数のパケットが含まれている場合、AGGFRAG_PAYLOADにある順序で送信する必要があります（つまり、反対側に受け取った元の注文を保持します）。この方法を使用するコストは、内側のパケット集約により、内側のパケットの注文不足の配信の増幅が発生する可能性があることです。
Instead of the method described in the previous paragraph, the receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3), and only after it has an in-order AGGFRAG_PAYLOAD payload stream would the receiver transmit the inner packets. Using this method will ensure the inner packets are sent in order. The cost of this method is that a lost packet will cause a delay of up to the lost packet timer interval (or the full reorder window if no lost packet timer is used). Additionally, there can be extra burstiness in the output stream. This burstiness can happen when a lost packet is dropped from the reorder window, and the remaining outer packets in the reorder window are immediately processed and sent out back to back.
前の段落で説明されている方法の代わりに、受信者は、順序のaggfrag_payloadペイロード（セクション2.2.3）に受け取った順序外のaggfrag_payloadペイロードを並べ替えることができます。受信機は内側のパケットを送信します。この方法を使用すると、内側のパケットが順番に送信されるようにします。この方法のコストは、失われたパケットが失われたパケットタイマー間隔（または失われたパケットタイマーが使用されない場合は完全な再注文ウィンドウ）の遅延を引き起こすことです。さらに、出力ストリームには余分な破裂があります。この爆発は、紛失したパケットが再注文ウィンドウからドロップされ、再注文ウィンドウの残りの外側パケットがすぐに処理され、後ろに送信されると発生する可能性があります。
Additionally, if congestion control is enabled, the receiver sends congestion control data (Section 6.1.2) back to the sender, as described in Sections 2.4.2 and 3.
さらに、輻輳制御が有効になっている場合、受信者はセクション2.4.2および3で説明されているように、輻輳制御データ（セクション6.1.2）を送信者に送り返します。
Finally, a note on receiving incorrect BlockOffset values: To account for misbehaving senders, a receiver SHOULD gracefully handle the case where the BlockOffset of consecutive packets, and/or the inner packet they share, do not agree. It MAY drop the inner packet or one or both of the outer packets.
最後に、誤ったブロックオフセット値を受信することに関するメモ：誤動作の送信者を説明するには、受信者は、連続したパケットのブロックオフセット、および/または共有する内部パケットが同意しない場合に優雅に処理する必要があります。外側のパケットの内側または一方または両方をドロップする場合があります。
In order to support the congestion-controlled mode, the sender needs to know the loss event rate and to approximate the RTT [RFC5348]. In order to obtain these values, the receiver sends congestion control information on its SA back to the sender. Thus, to support congestion control, the receiver MUST have a paired SA back to the sender (this is always the case when the tunnel was created using IKEv2). If the SA back to the sender is a non-AGGFRAG_PAYLOAD-enabled SA, then an AGGFRAG_PAYLOAD empty payload (i.e., header only) is used to convey the information.
輻輳制御モードをサポートするために、送信者は損失イベント率を知り、RTT [RFC5348]を近似する必要があります。これらの値を取得するために、受信者はSAに関する混雑制御情報を送信者に送信します。したがって、輻輳制御をサポートするには、受信者は送信者にペアのSAを戻す必要があります（これは、IKEV2を使用してトンネルが作成された場合に常に当てはまります）。送信者に戻るSAがaggfrag_payload対応のsaである場合、Aggfrag_payload空のペイロード（つまり、ヘッダーのみ）が情報を伝えるために使用されます。
In order to calculate a loss event rate compatible with [RFC5348], the receiver needs to have an RTT estimate. Thus, the sender communicates this estimate in the RTT header field. On startup, this value will be zero, as no RTT estimate is yet known.
[RFC5348]と互換性のある損失イベント率を計算するには、受信者はRTTの推定値を持つ必要があります。したがって、送信者は、RTTヘッダーフィールドでこの推定値を伝えます。スタートアップでは、RTTの見積もりはまだ知られていないため、この値はゼロになります。
In order for the sender to estimate its RTT value, the sender places a timestamp value in the TVal header field. On first receipt of this TVal, the receiver records the new TVal value, along with the time it arrived locally. Subsequent receipt of the same TVal MUST NOT update the recorded time.
送信者がRTT値を推定するために、送信者はTVALヘッダーフィールドにタイムスタンプの値を配置します。このtvalを最初に受け取ったとき、レシーバーは新しいtval値を記録し、地元で到着した時間とともに記録します。同じTVALの後続の受領は、記録された時間を更新してはなりません。
When the receiver sends its congestion control header, it places this latest recorded TVal in the TEcho header field, along with 2 delay values: Echo Delay and Transmit Delay. The Echo Delay value is the time delta from the recorded arrival time of TVal and the current clock in microseconds. The second value, Transmit Delay, is the receiver's current transmission delay on the tunnel (i.e., the average time between sending packets on its half of the AGGFRAG tunnel).
受信者が混雑制御ヘッダーを送信すると、この最新の記録されたTVALをTechOヘッダーフィールドに配置し、2つの遅延値：エコー遅延と送信遅延。エコー遅延値は、TVALの記録された到着時間からの時間と、マイクロ秒単位の現在のクロックです。2番目の値である送信遅延は、トンネル上の受信機の現在の伝送遅延です（つまり、Aggfragトンネルの半分にパケットを送信する間の平均時間）。
When the sender receives back its TVal in the TEcho header field, it calculates 2 RTT estimates. The first is the actual delay found by subtracting the TEcho value from its current clock and then subtracting the Echo Delay as well. The second RTT estimate is found by adding the received Transmit Delay header value to the sender's own transmission delay (i.e., the average time between sending packets on its half of the AGGFRAG tunnel). The larger of these 2 RTT estimates SHOULD be used as the RTT value.
送信者がTechoヘッダーフィールドでTVALを受け取ると、2つのRTTの推定値が計算されます。1つ目は、現在のクロックからTechO値を差し引き、エコー遅延を差し引くことで見つかった実際の遅延です。2番目のRTT推定値は、受信した送信遅延ヘッダー値を送信者自身の送信遅延に追加することで見つかります（つまり、Aggfragトンネルの半分にパケットを送信する間の平均時間）。これら2つのRTT推定値のうち大きいものは、RTT値として使用する必要があります。
The two RTT estimates are required to handle different combinations of faster or slower tunnel packet paths with faster or slower fixed tunnel rates. Choosing the larger of the two values guarantees that the RTT is never considered faster than the aggregate transmission delay based on the IP-TFS send rate (the second estimate), as well as never being considered faster than the actual RTT along the tunnel packet path (the first estimate).
2つのRTT推定値は、より速いまたは遅い固定トンネル速度を備えた、より速いまたは遅いトンネルパケットパスのさまざまな組み合わせを処理するために必要です。2つの値のうち大きいものを選択すると、RTTがIP-TFS送信レート（2番目の推定値）に基づいて集約される伝送遅延よりも速く考慮されないことを保証し、トンネルパケットパスに沿った実際のRTTよりも速く考慮されることはありません（最初の見積もり）。
The receiver also calculates, and communicates in the LossEventRate header field, the loss event rate for use by the sender. This is slightly different from [RFC4342], which periodically sends all the loss interval data back to the sender so that it can do the calculation. See Appendix B for a suggested way to calculate the loss event rate value. Initially, this value will be zero (indicating no loss) until enough data has been collected by the receiver to update it.
また、受信者は、送信者が使用するための損失イベント率であるLosseventrateヘッダーフィールドで計算し、通信します。これは[RFC4342]とはわずかに異なります。これは、すべての損失間隔データを送信者に定期的に送り、計算を行うことができます。損失イベント率の値を計算するための提案された方法については、付録Bを参照してください。当初、この値は、レシーバーが更新するのに十分なデータが収集されるまでゼロ（損失がないことを示しています）になります。
In addition to normal packet loss information, the AGGFRAG mode supports use of the ECN bits in the encapsulating IP header [RFC3168] for identifying congestion. If ECN use is enabled and a packet arrives at the egress (receiving) side with the Congestion Experienced (CE) value set, then the receiver considers that packet as being dropped, although it does not drop it. The receiver MUST set the E bit in any AGGFRAG_PAYLOAD payload header containing a LossEventRate value derived from a CE value being considered.
通常のパケット損失情報に加えて、AggFragモードは、混雑を特定するために、カプセル化IPヘッダー[RFC3168]のECNビットの使用をサポートしています。ECNの使用が有効になり、パケットが出口（受信）側に到着すると、渋滞が発生した（CE）値セットが設定されている場合、レシーバーはそのパケットがドロップされていると見なしますが、ドロップしません。受信者は、考慮されるCE値から派生したロスベントレート値を含むAGGFRAG_PAYLOADペイロードヘッダーにEビットを設定する必要があります。
In [RFC6040], which updates [RFC3168] and [RFC4301], behaviors for marking the outer ECN field value based on the ECN field of the inner packet are defined. As the AGGFRAG mode may have multiple inner packets present in a single outer packet, and there is no obvious correct way to map these multiple values to the single outer packet ECN field value, the tunnel ingress endpoint SHOULD operate in the "compatibility" mode, rather than the "default" mode from [RFC6040]. In particular, this means that the ingress (sending) endpoint of the tunnel always sets the newly constructed outer encapsulating packet header ECN field to Not-ECT [RFC6040].
[RFC3168]および[RFC4301]を更新する[RFC6040]では、内側のパケットのECNフィールドに基づいて外側のECNフィールド値をマークするための動作が定義されています。AggFragモードには単一の外側パケットに複数の内側パケットが存在する可能性があり、これらの複数の値を単一の外側パケットECNフィールド値にマッピングする明白な正しい方法はないため、トンネルイングレスエンドポイントは「互換性」モードで動作するはずです。[RFC6040]の「デフォルト」モードではなく。特に、これは、トンネルの侵入（送信）エンドポイントが常に、新しく構築された外側のカプセル化パケットヘッダーECNフィールドを、[RFC6040]に常に設定することを意味します。
IP-TFS is meant to be deployable with a minimal amount of configuration. All IP-TFS-specific configuration should be specified at the unidirectional tunnel ingress (sending) side. It is intended that non-IKEv2 operation is supported, at least, with local static configuration.
IP-TFSは、最小限の構成で展開できることを目的としています。すべてのIP-TFS固有の構成は、単方向トンネルイングレス（送信）側で指定する必要があります。少なくともローカルの静的構成で、非Kikev2操作がサポートされることを意図しています。
YANG and MIB documents have been defined for IP-TFS in [RFC9348] and [RFC9349].
YangおよびMIBドキュメントは、[RFC9348]および[RFC9349]のIP-TFに対して定義されています。
Bandwidth is a local configuration option. For the non-congestion-controlled mode, the bandwidth SHOULD be configured. For the congestion-controlled mode, the bandwidth can be configured or the congestion control algorithm discovers and uses the maximum bandwidth available. No standardized configuration method is required.
帯域幅はローカル構成オプションです。非合成コントロールモードの場合、帯域幅を構成する必要があります。輻輳制御モードの場合、帯域幅を構成するか、うっ血制御アルゴリズムを発見して使用可能な最大帯域幅を発見して使用できます。標準化された構成方法は必要ありません。
The fixed packet size to be used for the tunnel encapsulation packets MAY be configured manually or can be automatically determined using other methods, such as PLMTUD [RFC4821] [RFC8899] or PMTUD [RFC1191] [RFC8201]. As PMTUD is known to have issues, PLMTUD is considered the more robust option. No standardized configuration method is required.
トンネルカプセル化パケットに使用される固定パケットサイズは、PLMTUD [RFC4821] [RFC8899]またはPMTUD [RFC1191] [RFC8201]など、他の方法を使用して手動で構成することもできます。PMTUDには問題があることが知られているため、PLMTUDはより堅牢なオプションと見なされます。標準化された構成方法は必要ありません。
Congestion control is a local configuration option. No standardized configuration method is required.
輻輳制御はローカル構成オプションです。標準化された構成方法は必要ありません。
As mentioned previously, AGGFRAG tunnels utilize ESP payloads of type AGGFRAG_PAYLOAD.
前述のように、Aggfragトンネルは、aggfrag_payloadタイプのESPペイロードを利用しています。
When using IKEv2, a new "USE_AGGFRAG" notification message enables the AGGFRAG_PAYLOAD payload on a Child SA pair. The method used is similar to how USE_TRANSPORT_MODE is negotiated, as described in [RFC7296].
IKEV2を使用する場合、新しい「use_aggfrag」通知メッセージにより、子SAペアのaggfrag_payloadペイロードが可能になります。使用される方法は、[RFC7296]で説明されているように、use_transport_modeがネゴシエートされる方法に似ています。
To request use of the AGGFRAG_PAYLOAD payload on the Child SA pair, the initiator includes the USE_AGGFRAG notification in an SA payload requesting a new Child SA (either during the initial IKE_AUTH or during CREATE_CHILD_SA exchanges). If the request is accepted, then the response MUST also include a notification of type USE_AGGFRAG. If the responder declines the request, the Child SA will be established without AGGFRAG_PAYLOAD payload use enabled. If this is unacceptable to the initiator, the initiator MUST delete the Child SA.
Child SAペアでAggFrag_Payloadペイロードの使用をリクエストするために、イニシエーターには、新しい子SAを要求するSAペイロードにuse_aggfrag通知を含めます（最初のike_authまたはcreate_child_sa取引所の中）。リクエストが受け入れられた場合、応答には、型の型の通知も含める必要があります。レスポンダーがリクエストを拒否した場合、子SAはAGGFRAG_PAYLOADペイロード使用を有効にして確立されます。これがイニシエーターに対して受け入れられない場合、イニシエーターはChild SAを削除する必要があります。
As the use of the AGGFRAG_PAYLOAD payload is currently only defined for non-transport-mode tunnels, the USE_AGGFRAG notification MUST NOT be combined with the USE_TRANSPORT notification.
AggFrag_Payloadペイロードの使用は現在、非トランスポートモードトンネルに対してのみ定義されているため、use_aggfrag通知をuse_transport通知と組み合わせることはできません。
The USE_AGGFRAG notification contains a 1-octet payload of flags that specify requirements from the sender of the notification. If any requirement flags are not understood or cannot be supported by the receiver, then the receiver SHOULD NOT enable use of AGGFRAG_PAYLOAD (either by not responding with the USE_AGGFRAG notification or, in the case of the initiator, by deleting the Child SA if the now-established non-AGGFRAG_PAYLOAD using SA is unacceptable).
use_aggfrag通知には、通知の送信者からの要件を指定するフラグの1-OCTETペイロードが含まれています。要件フラグが理解されていないか、レシーバーがサポートできない場合、受信者はAGGFRAG_Payloadの使用を有効にしてはなりません（use_aggfrag通知で応答しないか、イニシエーターの場合、子saを削除することにより、イニシエーターの場合は今の場合は削除することにより、-SAを使用したaggfrag_payloadを確立することは受け入れられません）。
The notification type and payload flag values are defined in Section 6.1.4.
通知タイプとペイロードフラグの値は、セクション6.1.4で定義されています。
The packet and data formats defined below are generic with the intent of allowing for non-IP-TFS uses, but such uses are outside the scope of this document.
以下に定義されているパケット形式とデータ形式は、非IP-TFSの使用を許可する意図を持つ一般的なものですが、そのような使用はこのドキュメントの範囲外です。
ESP Next Header value: 144
ESP次のヘッダー値：144
An AGGFRAG payload is identified by the ESP Next Header value AGGFRAG_PAYLOAD, which has the value 144, which has been reserved in the IP protocol numbers space. The first octet of the payload indicates the format of the remaining payload data.
AggFragペイロードは、IPプロトコル番号スペースに予約されている値144を持つESP Next Header Value AggFrag_Payloadによって識別されます。ペイロードの最初のオクテットは、残りのペイロードデータの形式を示します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-
| Sub-type | ...
+-+-+-+-+-+-+-+-+-+-+-
Figure 3: AGGFRAG_PAYLOAD Payload Format
図3：AGGFRAG_PAYLOADペイロード形式
Sub-type:
サブタイプ：
An 8-bit value indicating the payload format.
ペイロード形式を示す8ビット値。
This document defines 2 payload sub-types. These payload formats are defined in the following sections.
このドキュメントは、2つのペイロードサブタイプを定義します。これらのペイロード形式は、次のセクションで定義されています。
The non-congestion-control AGGFRAG_PAYLOAD payload consists of a 4-octet header, followed by a variable amount of DataBlocks data, as shown below.
以下に示すように、非合成 - コントロールAggFrag_Payloadペイロードは4-OCTETヘッダーで構成され、その後に可変量のDataBlockデータが続きます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type (0) | Reserved | BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Non-Congestion-Control Payload Format
図4：非合成制御ペイロード形式
Sub-type:
サブタイプ：
An octet indicating the payload format. For this non-congestion-control format, the value is 0.
ペイロード形式を示すオクテット。この非合成コントロール形式の場合、値は0です。
Reserved:
予約済み：
An octet set to 0 on generation and ignored on receipt.
発電中に0に設定され、受領時に無視されます。
BlockOffset:
ブロックオフセット：
A 16-bit unsigned integer counting the number of octets of DataBlocks data before the start of a new data block. If the start of a new data block occurs in a subsequent payload, the BlockOffset will point past the end of the DataBlocks data. In this case, all the DataBlocks data belongs to the current data block being assembled. When the BlockOffset extends into subsequent payloads, it continues to only count DataBlocks data (i.e., it does not count subsequent packets of the non-DataBlocks data, such as header octets).
新しいデータブロックが開始される前に、Datablocksデータのオクテットの数をカウントする16ビットの署名のない整数。新しいデータブロックの開始が後続のペイロードで発生した場合、ブロックオフセットはDataBlocksデータの端を超えて指します。この場合、すべてのDatablocksデータは、組み立てられている現在のデータブロックに属します。BlockOffsetがその後のペイロードに拡張されると、DataBlocksデータのみをカウントし続けます（つまり、ヘッダーオクテットなどの非Datablocksデータの後続のパケットをカウントしません）。
DataBlocks:
DataBlocks：
Variable number of octets that begins with the start of a data block or the continuation of a previous data block, followed by zero or more additional data blocks.
データブロックの開始または以前のデータブロックの継続から始まり、その後にゼロ以上の追加データブロックが続く、可変数のオクテット数。
The congestion control AGGFRAG_PAYLOAD payload consists of a 24-octet header, followed by a variable amount of DataBlocks data, as shown below.
輻輳制御aggfrag_payloadペイロードは、24オクセットのヘッダーで構成されており、以下に示すように、さまざまな量のデータブロックデータが続きます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-type (1) | Reserved |P|E| BlockOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LossEventRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT | Echo Delay ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Echo Delay | Transmit Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TVal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TEcho |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataBlocks ...
+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Congestion Control Payload Format
図5：混雑制御ペイロード形式
Sub-type:
サブタイプ：
An octet indicating the payload format. For this congestion control format, the value is 1.
ペイロード形式を示すオクテット。この混雑制御形式の場合、値は1です。
Reserved:
予約済み：
A 6-bit field set to 0 on generation and ignored on receipt.
生成時に0に設定され、受領時に無視された6ビットフィールド。
P:
P：
A 1-bit value that, if set, indicates that PLMTUD probing is in progress. This information can be used to avoid treating missing packets as loss events by the congestion control algorithm when running the PLMTUD probe algorithm.
設定された場合、PLMTUDプロービングが進行中であることを示す1ビット値。この情報は、PLMTUDプローブアルゴリズムを実行する際に、不足制御制御アルゴリズムによる損失イベントとして欠落パケットを扱うことを避けるために使用できます。
E:
E：
A 1-bit value that, if set, indicates that Congestion Experienced (CE) ECN bits were received and used in deriving the reported LossEventRate.
設定されている場合、輻輳が経験した（CE）ECNビットが受信され、報告されたLosseventrateの導出に使用された1ビット値。
BlockOffset:
ブロックオフセット：
The same value as the non-congestion-controlled payload format value.
非合成制御されたペイロード形式の値と同じ値。
LossEventRate:
losseventrate：
A 32-bit value specifying the inverse of the current loss event rate, as calculated by the receiver. A value of zero indicates no loss. Otherwise, the loss event rate is 1/LossEventRate.
受信機によって計算された現在の損失イベント率の逆を指定する32ビット値。ゼロの値は、損失がないことを示します。それ以外の場合、損失イベント率は1/losseventrateです。
RTT:
RTT：
A 22-bit value specifying the sender's current RTT estimate in microseconds. The value MAY be zero prior to the sender having calculated an RTT estimate. The value SHOULD be set to zero on non-AGGFRAG_PAYLOAD-enabled SAs. If the RTT is equal to or larger than 0x3FFFFF, the value MUST be set to 0x3FFFFF.
送信者の現在のRTT推定値をマイクロ秒単位で指定する22ビット値。送信者がRTT推定値を計算する前に、値はゼロになる場合があります。値は、nonaggfrag_payload対応のSASでゼロに設定する必要があります。RTTが0x3FFFFF以上の場合、値は0x3FFFFに設定する必要があります。
Echo Delay:
エコー遅延：
A 21-bit value specifying the delay in microseconds incurred between the receiver first receiving the TVal value, which it is sending back in TEcho. If the delay is equal to or larger than 0x1FFFFF, the value MUST be set to 0x1FFFFF.
TVal値を最初に受信するレシーバー間で発生したマイクロ秒の遅延を指定する21ビット値。遅延が0x1fffff以上の場合、値は0x1fffffに設定する必要があります。
Transmit Delay:
送信遅延：
A 21-bit value specifying the transmission delay in microseconds. This is the fixed (or average) delay on the receiver between it sending packets on the IP-TFS tunnel. If the delay is equal to or larger than 0x1FFFFF, the value MUST be set to 0x1FFFFF.
マイクロ秒の伝送遅延を指定する21ビット値。これは、IP-TFSトンネルにパケットを送信する間のレシーバーの固定（または平均）遅延です。遅延が0x1fffff以上の場合、値は0x1fffffに設定する必要があります。
TVal:
tval：
An opaque, 32-bit value that will be echoed back by the receiver in later packets in the TEcho field, along with an Echo Delay value of how long that echo took.
Techoフィールドの後のパケットのレシーバーによって反響される不透明な32ビット値と、そのエコーがどれくらいかかったかというエコー遅延値。
TEcho:
Techo：
The opaque, 32-bit value from a received packet's TVal field. The received TVal is placed in TEcho, along with an Echo Delay value indicating how long it has been since receiving the TVal value.
受信したパケットのTValフィールドからの不透明な32ビット値。受信したTVALは、TVAL値を受信してからどれくらいの期間がかかったかを示すエコー遅延値とともに、TechOに配置されます。
DataBlocks:
DataBlocks：
Variable number of octets that begins with the start of a data block or the continuation of a previous data block, followed by zero or more additional data blocks. For the special case of sending congestion control information on a non-IP-TFS-enabled SA, this field MUST be empty (i.e., be zero octets long).
データブロックの開始または以前のデータブロックの継続から始まり、その後にゼロ以上の追加データブロックが続く、可変数のオクテット数。非IP-TFS対応SAに関する混雑制御情報を送信する特別なケースの場合、このフィールドは空でなければなりません（つまり、長さはゼロである）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | IPv4, IPv6, or pad...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Data Block Format
図6：データブロック形式
Type:
タイプ：
A 4-bit field where 0x0 identifies a Pad Data Block, 0x4 indicates an IPv4 data block, and 0x6 indicates an IPv6 data block.
0x0がパッドデータブロックを識別する4ビットフィールド、0x4はIPv4データブロックを示し、0x6はIPv6データブロックを示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4 | IHL | TypeOfService | TotalLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rest of the inner packet ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: IPv4 Data Block Format
図7：IPv4データブロック形式
These values are the actual values within the encapsulated IPv4 header. In other words, the start of this data block is the start of the encapsulated IP packet.
これらの値は、カプセル化されたIPv4ヘッダー内の実際の値です。つまり、このデータブロックの開始は、カプセル化されたIPパケットの開始です。
Type:
タイプ：
A 4-bit value of 0x4 indicating IPv4 (i.e., first nibble of the IPv4 packet).
IPv4（つまり、IPv4パケットの最初のニブル）を示す0x4の4ビット値。
TotalLength:
全長：
The 16-bit unsigned integer "Total Length" field of the IPv4 inner packet.
IPv4インナーパケットの16ビットの符号なし整数「総長さ」フィールド。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x6 | TrafficClass | FlowLabel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadLength | Rest of the inner packet ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: IPv6 Data Block Format
図8：IPv6データブロック形式
These values are the actual values within the encapsulated IPv6 header. In other words, the start of this data block is the start of the encapsulated IP packet.
これらの値は、カプセル化されたIPv6ヘッダー内の実際の値です。つまり、このデータブロックの開始は、カプセル化されたIPパケットの開始です。
Type:
タイプ：
A 4-bit value of 0x6 indicating IPv6 (i.e., first nibble of the IPv6 packet).
IPv6（つまり、IPv6パケットの最初のニブル）を示す0x6の4ビット値。
PayloadLength:
PayloadLength：
The 16-bit unsigned integer "Payload Length" field of the inner IPv6 inner packet.
内側のIPv6内側パケットの16ビットの符号なし整数「ペイロード長」フィールド。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Padding ...
+-+-+-+-+-+-+-+-+-+-+-
Figure 9: Pad Data Block Format
図9：パッドデータブロック形式
Type:
タイプ：
A 4-bit value of 0x0 indicating a padding data block.
パディングデータブロックを示す0x0の4ビット値。
Padding:
パディング：
Extends to end of the encapsulating packet.
カプセル化パケットの終わりまで拡張されます。
As discussed in Section 5.1, a notification message USE_AGGFRAG is used to negotiate use of the ESP AGGFRAG_PAYLOAD Next Header value.
セクション5.1で説明したように、通知メッセージUSE_AGGFRAGを使用して、ESP AGGFRAG_PAYLOAD次のヘッダー値の使用を交渉します。
The USE_AGGFRAG Notification Message State Type is 16442.
use_aggfrag通知メッセージ状態タイプは16442です。
The notification payload contains 1 octet of requirement flags. There are currently 2 requirement flags defined. This may be revised by later specifications.
通知ペイロードには、1オクテットの要件フラグが含まれています。現在、2つの要件フラグが定義されています。これは、後の仕様によって改訂される場合があります。
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|C|D|
+-+-+-+-+-+-+-+-+
Figure 10: USE_AGGFRAG Requirement Flags
図10：use_aggfrag要件フラグ
0:
0：
6 bits - Reserved MUST be zero on send, unless defined by later specifications.
6ビット - 後の仕様で定義されていない限り、予約済みは送信時にゼロでなければなりません。
C:
C：
Congestion Control bit. If set, then the sender is requiring that congestion control information MUST be returned to it periodically, as defined in Section 3.
混雑制御ビット。設定されている場合、送信者は、セクション3で定義されているように、輻輳制御情報を定期的に返却する必要があることを要求しています。
D:
D：
Don't Fragment bit. If set, it indicates the sender of the notify message does not support receiving packet fragments (i.e., inner packets MUST be sent using a single Data Block). This value only applies to what the sender is capable of receiving; the sender MAY still send packet fragments unless similarly restricted by the receiver in its USE_AGGFRAG notification.
ビットを断片化しないでください。設定すると、Notifyメッセージの送信者が受信パケットフラグメントをサポートしていないことを示します（つまり、単一のデータブロックを使用して内側のパケットを送信する必要があります）。この値は、送信者が受け取ることができるものにのみ適用されます。送信者は、そのuse_aggfrag通知でレシーバーによって同様に制限されていない限り、パケットフラグメントを送信する場合があります。
IANA has allocated an IP protocol number from the "Protocol Numbers - Assigned Internet Protocol Numbers" registry as follows.
IANAは、次のように「プロトコル番号 - 割り当てられたインターネットプロトコル番号」レジストリからIPプロトコル番号を割り当てました。
Decimal:
小数：
144
144
Keyword:
キーワード：
AGGFRAG
aggfrag
Protocol:
プロトコル：
AGGFRAG encapsulation payload for ESP
aggfrag capsulation espのペイロード
Reference:
参照：
RFC 9347
RFC 9347
IANA has created a registry called "AGGFRAG_PAYLOAD Sub-Types" under a new category named "ESP AGGFRAG_PAYLOAD". The registration policy for this registry is "Expert Review" [RFC8126] [RFC7120].
IANAは、「aggfrag_paylag_payload」という名前の新しいカテゴリの下に「aggfrag_payload sub-types」というレジストリを作成しました。このレジストリの登録ポリシーは、「専門家のレビュー」[RFC8126] [RFC7120]です。
Name:
名前：
AGGFRAG_PAYLOAD Sub-Types
aggfrag_payloadサブタイプ
Description:
説明：
AGGFRAG_PAYLOAD Payload Formats
aggfrag_payloadペイロードフォーマット
Reference:
参照：
RFC 9347
RFC 9347
This initial content for this registry is as follows:
このレジストリのこの初期コンテンツは次のとおりです。
+==========+===============================+===========+
| Sub-Type | Name | Reference |
+==========+===============================+===========+
| 0 | Non-Congestion-Control Format | RFC 9347 |
+----------+-------------------------------+-----------+
| 1 | Congestion Control Format | RFC 9347 |
+----------+-------------------------------+-----------+
| 3-255 | Reserved | |
+----------+-------------------------------+-----------+
Table 1: AGGFRAG_PAYLOAD Sub-Types
表1：aggfrag_payloadサブタイプ
IANA has allocated a status type USE_AGGFRAG from the "IKEv2 Notify Message Types - Status Types" registry.
IANAは、「IKEV2通知メッセージタイプ - ステータスタイプ」レジストリからステータスタイプのuse_aggfragを割り当てました。
Decimal:
小数：
16442
16442
Name:
名前：
USE_AGGFRAG
use_aggfrag
Reference:
参照：
RFC 9347
RFC 9347
This document describes an aggregation and fragmentation mechanism to efficiently implement TFC for IP traffic. This approach is expected to reduce the efficacy of traffic analysis on IPsec communication. Other than the additional security afforded by using this mechanism, IP-TFS utilizes the security protocols [RFC4303] and [RFC7296], and so their security considerations apply to IP-TFS as well.
このドキュメントでは、IPトラフィックにTFCを効率的に実装するための集約および断片化メカニズムについて説明します。このアプローチは、IPSEC通信に対するトラフィック分析の有効性を低下させると予想されます。このメカニズムを使用することで提供される追加のセキュリティ以外に、IP-TFSはセキュリティプロトコル[RFC4303]と[RFC7296]を利用しているため、セキュリティ上の考慮事項もIP-TFSに適用されます。
As noted in Section 3.1, the ECN bits are not protected by IPsec and thus may constitute a covert channel. For this reason, ECN use SHOULD NOT be enabled by default.
セクション3.1で述べたように、ECNビットはIPSECによって保護されていないため、秘密のチャネルを構成する可能性があります。このため、ECNの使用をデフォルトで有効にしないでください。
As noted previously in Section 2.4.2, for TFC to be maintained, the encapsulated traffic flow should not be affecting network congestion in a predictable way, and if it would be, then non-congestion-controlled mode use should be considered instead.
セクション2.4.2に前述したように、TFCが維持される場合、カプセル化されたトラフィックフローは、予測可能な方法でネットワークの輻輳に影響を与えるべきではありません。
[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>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[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>.
[AppCrypt] Schneier, B., "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
DOI 10.17487/RFC4342, March 2006,
<https://www.rfc-editor.org/info/rfc4342>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<https://www.rfc-editor.org/info/rfc5348>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.
[RFC7893] Stein, Y(J)., Black, D., and B. Briscoe, "Pseudowire
Congestion Considerations", RFC 7893,
DOI 10.17487/RFC7893, June 2016,
<https://www.rfc-editor.org/info/rfc7893>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet
Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329,
DOI 10.17487/RFC9329, November 2022,
<https://www.rfc-editor.org/info/rfc9329>.
[RFC9348] Fedyk, D. and C. Hopps, "A YANG Data Model for IP Traffic
Flow Security", RFC 9348, DOI 10.17487/RFC9348, January
2023, <https://www.rfc-editor.org/info/rfc9348>.
[RFC9349] Fedyk, D. and E. Kinzie, "Definitions of Managed Objects
for IP Traffic Flow Security", RFC 9349,
DOI 10.17487/RFC9349, January 2023,
<https://www.rfc-editor.org/info/rfc9349>.
Below, an example inner IP packet flow within the encapsulating tunnel packet stream is shown. Notice how encapsulated IP packets can start and end anywhere, and more than one or less than one may occur in a single encapsulating packet.
以下に、カプセル化するトンネルパケットストリーム内の内部IPパケットフローの例が示されています。カプセル化されたIPパケットがどこからでも開始および終了する方法に注意してください。1つのカプセル化パケットで1つ以上が発生する可能性があります。
Offset: 0 Offset: 100 Offset: 2000 Offset: 600
[ ESP1 (1404) ][ ESP2 (1404) ][ ESP3 (1404) ][ ESP4 (1404) ]
[--750--][--750--][60][-240-][--3000----------------------][pad]
Figure 11: Inner and Outer Packet Flow
図11：内側と外側のパケットフロー
Each outer encapsulating ESP space is a fixed size of 1404 octets, the first 4 octets of which contain the AGGFRAG header. The encapsulated IP packet flow (lengths include the IP header and payload) is as follows: a 750-octet packet, a 750-octet packet, a 60-octet packet, a 240-octet packet, and a 3000-octet packet.
ESPスペースの各外側のカプセル化は、1404オクテットの固定サイズで、最初の4オクテットにはAggFragヘッダーが含まれています。カプセル化されたIPパケットフロー（長さにはIPヘッダーとペイロードが含まれます）は次のとおりです。750-OCTETパケット、750オクテットパケット、60オクテットパケット、240オクテットパケット、3000オクテットパケット。
The BlockOffset values in the 4 AGGFRAG payload headers for this packet flow would thus be: 0, 100, 2000, and 600, respectively. The first encapsulating packet (ESP1) has a zero BlockOffset, which points at the IP data block immediately following the AGGFRAG header. The following packet's (ESP2) BlockOffset points inward 100 octets to the start of the 60-octet data block. The third encapsulating packet (ESP3) contains the middle portion of the 3000-octet data block, so the offset points past its end and into the fourth encapsulating packet. The fourth packet's (ESP4) offset is 600, pointing at the padding that follows the completion of the continued 3000-octet packet.
したがって、このパケットフローの4つのAggFragペイロードヘッダーのブロックオフセット値は、それぞれ0、100、2000、および600になります。最初のカプセル化パケット（ESP1）のブロックオフセットはゼロで、AggFragヘッダーの直後のIPデータブロックを指します。次のパケット（ESP2）ブロックオフセットは、60オクテットデータブロックの開始に100オクテットを内側にポイントします。3番目のカプセル化パケット（ESP3）には、3000-OCTETデータブロックの中央部分が含まれているため、オフセットはその端を過ぎて4番目のカプセル化パケットにポイントします。4番目のパケット（ESP4）のオフセットは600で、継続的な3000オクテットのパケットの完成に続くパディングを指しています。
The current best practice indicates that congestion control SHOULD be done in a TCP-friendly way. A TCP-friendly congestion control algorithm is described in [RFC5348]. For this IP-TFS use case (as with [RFC4342]), the (fixed) packet size is used as the segment size for the algorithm. The main formula in the algorithm for the send rate is then as follows:
現在のベストプラクティスは、混雑制御をTCPに優しい方法で行う必要があることを示しています。TCPに優しい混雑制御アルゴリズムは、[RFC5348]で説明されています。このIP-TFSユースケース（[RFC4342]と同様）では、（固定）パケットサイズがアルゴリズムのセグメントサイズとして使用されます。送信レートのアルゴリズムの主要な式は次のとおりです。
1
X = -----------------------------------------------
R * (sqrt(2*p/3) + 12*sqrt(3*p/8)*p*(1+32*p^2))
X is the send rate in packets per second, R is the RTT estimate, and p is the loss event rate (the inverse of which is provided by the receiver).
xは1秒あたりのパケットの送信レート、RはRTT推定値、Pは損失イベント率（その逆数が受信機によって提供される）です。
In addition, the algorithm in [RFC5348] also uses an X_recv value (the receiver's receive rate). For IP-TFS, one MAY set this value according to the sender's current tunnel send rate (X).
さらに、[RFC5348]のアルゴリズムはX_RECV値（受信者の受信率）も使用します。IP-TFSの場合、送信者の現在のトンネル送信レート（x）に従ってこの値を設定できます。
The IP-TFS receiver, having the RTT estimate from the sender, can use the same method as described in [RFC5348] and [RFC4342] to collect the loss intervals and calculate the loss event rate value using the weighted average as indicated. The receiver communicates the inverse of this value back to the sender in the AGGFRAG_PAYLOAD payload header field LossEventRate.
送信者からのRTT推定値を持つIP-TFSレシーバーは、[RFC5348]および[RFC4342]で説明されているのと同じ方法を使用して、損失間隔を収集し、示されているように加重平均を使用して損失イベントレート値を計算できます。受信者は、この値の逆をAggFrag_PayloadペイロードヘッダーフィールドLosseventrateの送信者に伝えます。
The IP-TFS sender now has both the R and p values and can calculate the correct sending rate. If following [RFC5348], the sender should also use the slow start mechanism described therein when the IP-TFS SA is first established.
IP-TFS送信者には、R値とPの両方の値があり、正しい送信率を計算できます。[RFC5348]に従う場合、送信者は、IP-TFS SAが最初に確立されたときに説明されているスロースタートメカニズムも使用する必要があります。
For comparing overhead, the overhead of ESP for both normal and AGGFRAG tunnel packets must be calculated, and so an algorithm for encryption and authentication must be chosen. For the data below, AES-GCM-256 was selected. This leads to an IP+ESP overhead of 54.
オーバーヘッドを比較するには、通常とAggfragトンネルパケットの両方のESPのオーバーヘッドを計算する必要があるため、暗号化と認証のためのアルゴリズムを選択する必要があります。以下のデータでは、AES-GCM-256が選択されました。これにより、54のIP ESPオーバーヘッドにつながります。
54 = 20 (IP) + 8 (ESPH) + 2 (ESPF) + 8 (IV) + 16 (ICV)
Additionally, for IP-TFS, non-congestion-control AGGFRAG_PAYLOAD headers were chosen, which adds 4 octets, for a total overhead of 58.
さらに、IP-TFSの場合、非合成制御aggfrag_payloadヘッダーが選択され、58の合計オーバーヘッドで4オクテットが追加されました。
For comparison, the overhead of an AGGFRAG payload is 58 octets per outer packet. Therefore, the octet overhead per inner packet is 58 divided by the number of outer packets required (fractions allowed). The overhead as a percentage of inner packet size is a constant based on the Outer MTU size.
比較のために、アグフラグペイロードのオーバーヘッドは、外側パケットごとに58オクテットです。したがって、内側のパケットあたりのオクテットのオーバーヘッドは、必要な外側パケットの数（許可された分数）で58を割った58です。内側のパケットサイズの割合としてのオーバーヘッドは、外側のMTUサイズに基づいて定数です。
OH = 58 / Outer Payload Size / Inner Packet Size
OH % of Inner Packet Size = 100 * OH / Inner Packet Size
OH % of Inner Packet Size = 5800 / Outer Payload Size
+=======+========+========+========+
| Type | IP-TFS | IP-TFS | IP-TFS |
+=======+========+========+========+
| MTU | 576 | 1500 | 9000 |
+=======+========+========+========+
| PSize | 518 | 1442 | 8942 |
+=======+========+========+========+
| 40 | 11.20% | 4.02% | 0.65% |
+-------+--------+--------+--------+
| 576 | 11.20% | 4.02% | 0.65% |
+-------+--------+--------+--------+
| 1500 | 11.20% | 4.02% | 0.65% |
+-------+--------+--------+--------+
| 9000 | 11.20% | 4.02% | 0.65% |
+-------+--------+--------+--------+
Table 2: IP-TFS Overhead as Percentage of Inner Packet Size
表2：内側のパケットサイズの割合としてのIP-TFSオーバーヘッド
The overhead per inner packet for constant-send-rate-padded ESP (i.e., original IPsec TFC) is 36 octets plus any padding, unless fragmentation is required.
断片化が必要な場合を除き、一定のレートパッドESP（つまり、元のIPSEC TFC）の内側の頭上（つまり、元のIPSEC TFC）は、36オクテットとパディングです。
When fragmentation of the inner packet is required to fit in the outer IPsec packet, overhead is the number of outer packets required to carry the fragmented inner packet times both the inner IP Overhead (20) and the outer packet overhead (54) minus the initial inner IP Overhead plus any required tail padding in the last encapsulation packet. The required tail padding is the number of required packets times the difference of the Outer Payload Size and the IP Overhead minus the Inner Payload Size. So:
外側のIPSECパケットに収まるために内側のパケットの断片化が必要な場合、オーバーヘッドは、内側のIPオーバーヘッド（20）と外側パケットオーバーヘッド（54）の両方の断片化された内側パケット時間を運ぶために必要な外側パケットの数です。内側のIPオーバーヘッドと、最後のカプセル化パケットに必要なテールパディング。必要なテールパディングは、必要なパケットの数であり、外側のペイロードサイズの差とIPオーバーヘッドから内部ペイロードサイズを差し引いたものです。それで：
Inner Payload Size = IP Packet Size - IP Overhead
Outer Payload Size = MTU - IPsec Overhead
Inner Payload Size
NF0 = ----------------------------------
Outer Payload Size - IP Overhead
NF = CEILING(NF0)
OH = NF * (IP Overhead + IPsec Overhead)
- IP Overhead
+ NF * (Outer Payload Size - IP Overhead)
- Inner Payload Size
OH = NF * (IPsec Overhead + Outer Payload Size)
- (IP Overhead + Inner Payload Size)
OH = NF * (IPsec Overhead + Outer Payload Size)
- Inner Packet Size
The following tables collect the overhead values for some common L3 MTU sizes in order to compare them. The first table is the number of octets of overhead for a given L3 MTU-sized packet. The second table is the percentage of overhead in the same MTU-sized packet.
次のテーブルは、それらを比較するために、いくつかの一般的なL3 MTUサイズのオーバーヘッド値を収集します。最初のテーブルは、特定のL3 MTUサイズのパケットのオーバーヘッドのオクテット数です。2番目のテーブルは、同じMTUサイズのパケットのオーバーヘッドの割合です。
+========+=========+=========+=========+========+========+========+
| Type | ESP+Pad | ESP+Pad | ESP+Pad | IP-TFS | IP-TFS | IP-TFS |
+========+=========+=========+=========+========+========+========+
| L3 MTU | 576 | 1500 | 9000 | 576 | 1500 | 9000 |
+========+=========+=========+=========+========+========+========+
| PSize | 522 | 1446 | 8946 | 518 | 1442 | 8942 |
+========+=========+=========+=========+========+========+========+
| 40 | 482 | 1406 | 8906 | 4.5 | 1.6 | 0.3 |
+--------+---------+---------+---------+--------+--------+--------+
| 128 | 394 | 1318 | 8818 | 14.3 | 5.1 | 0.8 |
+--------+---------+---------+---------+--------+--------+--------+
| 256 | 266 | 1190 | 8690 | 28.7 | 10.3 | 1.7 |
+--------+---------+---------+---------+--------+--------+--------+
| 518 | 4 | 928 | 8428 | 58.0 | 20.8 | 3.4 |
+--------+---------+---------+---------+--------+--------+--------+
| 576 | 576 | 870 | 8370 | 64.5 | 23.2 | 3.7 |
+--------+---------+---------+---------+--------+--------+--------+
| 1442 | 286 | 4 | 7504 | 161.5 | 58.0 | 9.4 |
+--------+---------+---------+---------+--------+--------+--------+
| 1500 | 228 | 1500 | 7446 | 168.0 | 60.3 | 9.7 |
+--------+---------+---------+---------+--------+--------+--------+
| 8942 | 1426 | 1558 | 4 | 1001.2 | 359.7 | 58.0 |
+--------+---------+---------+---------+--------+--------+--------+
| 9000 | 1368 | 1500 | 9000 | 1007.7 | 362.0 | 58.4 |
+--------+---------+---------+---------+--------+--------+--------+
Table 3: Overhead Comparison in Octets
表3：オクテットのオーバーヘッド比較
+=======+=========+=========+==========+========+========+========+
| Type | ESP+Pad | ESP+Pad | ESP+Pad | IP-TFS | IP-TFS | IP-TFS |
+=======+=========+=========+==========+========+========+========+
| MTU | 576 | 1500 | 9000 | 576 | 1500 | 9000 |
+=======+=========+=========+==========+========+========+========+
| PSize | 522 | 1446 | 8946 | 518 | 1442 | 8942 |
+=======+=========+=========+==========+========+========+========+
| 40 | 1205.0% | 3515.0% | 22265.0% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 128 | 307.8% | 1029.7% | 6889.1% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 256 | 103.9% | 464.8% | 3394.5% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 518 | 0.8% | 179.2% | 1627.0% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 576 | 100.0% | 151.0% | 1453.1% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 1442 | 19.8% | 0.3% | 520.4% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 1500 | 15.2% | 100.0% | 496.4% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 8942 | 15.9% | 17.4% | 0.0% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
| 9000 | 15.2% | 16.7% | 100.0% | 11.20% | 4.02% | 0.65% |
+-------+---------+---------+----------+--------+--------+--------+
Table 4: Overhead as Percentage of Inner Packet Size
表4：内側のパケットサイズの割合としてのオーバーヘッド
Another way to compare the two solutions is to look at the amount of available bandwidth each solution provides. The following sections consider and compare the percentage of available bandwidth. For the sake of providing a well-understood baseline, normal (unencrypted) Ethernet and normal ESP values are included.
2つのソリューションを比較する別の方法は、各ソリューションが提供する利用可能な帯域幅の量を調べることです。次のセクションでは、利用可能な帯域幅の割合を検討して比較します。よく理解されているベースラインを提供するために、通常の（暗号化されていない）イーサネットと通常のESP値が含まれています。
In order to calculate the available bandwidth, the per-packet overhead is calculated first. The total overhead of Ethernet is 14+4 octets of header and Cyclic Redundancy Check (CRC) plus an additional 20 octets of framing (preamble, start, and inter-packet gap), for a total of 38 octets. Additionally, the minimum payload is 46 octets.
使用可能な帯域幅を計算するために、パケットごとのオーバーヘッドが最初に計算されます。イーサネットの合計オーバーヘッドは、ヘッダーと周期冗長チェック（CRC）の14 4オクテットと、さらに20オクテットのフレーミング（プリアンブル、スタート、およびパケット間ギャップ）で、合計38オクテットです。さらに、最小ペイロードは46オクテットです。
+====+=======+=======+=======+=======+=======+=======+======+======+
|Size| E + P | E + P | E + P | IPTFS | IPTFS | IPTFS | Enet | ESP |
+====+=======+=======+=======+=======+=======+=======+======+======+
|MTU | 590 | 1514 | 9014 | 590 | 1514 | 9014 | any | any |
+====+=======+=======+=======+=======+=======+=======+======+======+
|OH | 92 | 92 | 92 | 96 | 96 | 96 | 38 | 74 |
+====+=======+=======+=======+=======+=======+=======+======+======+
|40 | 614 | 1538 | 9038 | 47 | 42 | 40 | 84 | 114 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|128 | 614 | 1538 | 9038 | 151 | 136 | 129 | 166 | 202 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|256 | 614 | 1538 | 9038 | 303 | 273 | 258 | 294 | 330 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|518 | 614 | 1538 | 9038 | 614 | 552 | 523 | 574 | 610 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|576 | 1228 | 1538 | 9038 | 682 | 614 | 582 | 614 | 650 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|1442| 1842 | 1538 | 9038 | 1709 | 1538 | 1457 | 1498 | 1534 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|1500| 1842 | 3076 | 9038 | 1777 | 1599 | 1516 | 1538 | 1574 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|8942| 11052 | 10766 | 9038 | 10599 | 9537 | 9038 | 8998 | 9034 |
+----+-------+-------+-------+-------+-------+-------+------+------+
|9000| 11052 | 10766 | 18076 | 10667 | 9599 | 9096 | 9038 | 9074 |
+----+-------+-------+-------+-------+-------+-------+------+------+
Table 5: L2 Octets Per Packet
表5：パケットごとのL2オクテット
+====+=======+=======+======+=======+=======+=======+=======+=======+
|Size| E + P | E + | E + | IPTFS | IPTFS | IPTFS | Enet | ESP |
| | | P | P | | | | | |
+====+=======+=======+======+=======+=======+=======+=======+=======+
|MTU | 590 | 1514 | 9014 | 590 | 1514 | 9014 | any | any |
+====+=======+=======+======+=======+=======+=======+=======+=======+
|OH | 92 | 92 | 92 | 96 | 96 | 96 | 38 | 74 |
+====+=======+=======+======+=======+=======+=======+=======+=======+
|40 | 2.0M | 0.8M | 0.1M | 26.4M | 29.3M | 30.9M | 14.9M | 11.0M |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|128 | 2.0M | 0.8M | 0.1M | 8.2M | 9.2M | 9.7M | 7.5M | 6.2M |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|256 | 2.0M | 0.8M | 0.1M | 4.1M | 4.6M | 4.8M | 4.3M | 3.8M |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|518 | 2.0M | 0.8M | 0.1M | 2.0M | 2.3M | 2.4M | 2.2M | 2.1M |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|576 | 1.0M | 0.8M | 0.1M | 1.8M | 2.0M | 2.1M | 2.0M | 1.9M |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|1442| 678K | 812K | 138K | 731K | 812K | 857K | 844K | 824K |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|1500| 678K | 406K | 138K | 703K | 781K | 824K | 812K | 794K |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|8942| 113K | 116K | 138K | 117K | 131K | 138K | 139K | 138K |
+----+-------+-------+------+-------+-------+-------+-------+-------+
|9000| 113K | 116K | 69K | 117K | 130K | 137K | 138K | 137K |
+----+-------+-------+------+-------+-------+-------+-------+-------+
Table 6: Packets Per Second on 10G Ethernet
表6：10gイーサネットのパケット
+====+======+======+======+======+======+========+========+========+
|Size|E + P |E + P |E + P |IP-TFS|IP-TFS| IP-TFS | Enet | ESP |
+====+======+======+======+======+======+========+========+========+
|MTU |590 |1514 |9014 |590 |1514 | 9014 | any | any |
+====+======+======+======+======+======+========+========+========+
|OH |92 |92 |92 |96 |96 | 96 | 38 | 74 |
+====+======+======+======+======+======+========+========+========+
|40 |6.51% |2.60% |0.44% |84.36%|93.76%| 98.94% | 47.62% | 35.09% |
+----+------+------+------+------+------+--------+--------+--------+
|128 |20.85%|8.32% |1.42% |84.36%|93.76%| 98.94% | 77.11% | 63.37% |
+----+------+------+------+------+------+--------+--------+--------+
|256 |41.69%|16.64%|2.83% |84.36%|93.76%| 98.94% | 87.07% | 77.58% |
+----+------+------+------+------+------+--------+--------+--------+
|518 |84.36%|33.68%|5.73% |84.36%|93.76%| 98.94% | 93.17% | 87.50% |
+----+------+------+------+------+------+--------+--------+--------+
|576 |46.91%|37.45%|6.37% |84.36%|93.76%| 98.94% | 93.81% | 88.62% |
+----+------+------+------+------+------+--------+--------+--------+
|1442|78.28%|93.76%|15.95%|84.36%|93.76%| 98.94% | 97.43% | 95.12% |
+----+------+------+------+------+------+--------+--------+--------+
|1500|81.43%|48.76%|16.60%|84.36%|93.76%| 98.94% | 97.53% | 95.30% |
+----+------+------+------+------+------+--------+--------+--------+
|8942|80.91%|83.06%|98.94%|84.36%|93.76%| 98.94% | 99.58% | 99.18% |
+----+------+------+------+------+------+--------+--------+--------+
|9000|81.43%|83.60%|49.79%|84.36%|93.76%| 98.94% | 99.58% | 99.18% |
+----+------+------+------+------+------+--------+--------+--------+
Table 7: Percentage of Bandwidth on 10G Ethernet
表7：10Gイーサネットの帯域幅の割合
A sometimes unexpected result of using an AGGFRAG tunnel (or any packet aggregating tunnel) is that, for small- to medium-sized packets, the available bandwidth is actually greater than plain Ethernet. This is due to the reduction in Ethernet framing overhead. This increased bandwidth is paid for with an increase in latency. This latency is the time to send the unrelated octets in the outer tunnel frame. The following table illustrates the latency for some common values on a 10G Ethernet link. The table also includes latency introduced by padding if using ESP with padding.
Aggfragトンネル（または任意のパケット集約トンネル）を使用することの予期しない結果は、小規模から中型のパケットの場合、利用可能な帯域幅は実際にはプレーンイーサネットよりも大きいことです。これは、イーサネットフレーミングオーバーヘッドの減少によるものです。この帯域幅の増加は、レイテンシの増加とともに支払われます。このレイテンシは、外側のトンネルフレームに無関係なオクテットを送信する時です。次の表は、10Gイーサネットリンクのいくつかの一般的な値のレイテンシを示しています。このテーブルには、パディングでESPを使用する場合、パディングによって導入されたレイテンシも含まれています。
+======+=========+=========+=========+=========+
| Size | ESP+Pad | ESP+Pad | IP-TFS | IP-TFS |
+======+=========+=========+=========+=========+
| MTU | 1500 | 9000 | 1500 | 9000 |
+======+=========+=========+=========+=========+
| 40 | 1.12 us | 7.12 us | 1.17 us | 7.17 us |
+------+---------+---------+---------+---------+
| 128 | 1.05 us | 7.05 us | 1.10 us | 7.10 us |
+------+---------+---------+---------+---------+
| 256 | 0.95 us | 6.95 us | 1.00 us | 7.00 us |
+------+---------+---------+---------+---------+
| 518 | 0.74 us | 6.74 us | 0.79 us | 6.79 us |
+------+---------+---------+---------+---------+
| 576 | 0.70 us | 6.70 us | 0.74 us | 6.74 us |
+------+---------+---------+---------+---------+
| 1442 | 0.00 us | 6.00 us | 0.05 us | 6.05 us |
+------+---------+---------+---------+---------+
| 1500 | 1.20 us | 5.96 us | 0.00 us | 6.00 us |
+------+---------+---------+---------+---------+
Table 8: Added Latency
表8：レイテンシを追加しました
Notice that the latency values are very similar between the two solutions; however, whereas IP-TFS provides for constant high bandwidth, in some cases even exceeding plain Ethernet, ESP with padding often greatly reduces available bandwidth.
2つのソリューション間でレイテンシ値が非常に似ていることに注意してください。ただし、IP-TFSは一定の高い帯域幅を提供しますが、場合によってはプレーンイーサネットを超えることさえありますが、PADDINGを備えたESPは利用可能な帯域幅を大幅に減らします。
We would like to thank Don Fedyk for help in reviewing and editing this work. We would also like to thank Michael Richardson, Sean Turner, Valery Smyslov, and Tero Kivinen for reviews and many suggestions for improvements, as well as Joseph Touch for the transport area review and suggested improvements.
この作品のレビューと編集の助けについては、Don Fedykに感謝します。また、マイケル・リチャードソン、ショーン・ターナー、ヴァレリー・スミースロフ、テロ・キビネンに、改善のための多くの提案をしてくれたこと、そして輸送エリアのレビューと提案の改善のためのジョセフ・タッチに感謝します。
The following person made significant contributions to this document.
次の人は、この文書に多大な貢献をしました。
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org