Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 9601 Independent
Updates: 2661, 2784, 3931, 4380, 6040, 7450 August 2024
Category: Standards Track
ISSN: 2070-1721
RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion Notification (ECN) consistent for all forms of IP-in-IP tunnel. This specification updates RFC 6040 to clarify that its scope includes tunnels where two IP headers are separated by at least one shim header that is not sufficient on its own for wide-area packet forwarding. It surveys widely deployed IP tunnelling protocols that use such shim headers and updates the specifications of those that do not mention ECN propagation (including RFCs 2661, 3931, 2784, 4380 and 7450, which specify L2TPv2, L2TPv3, Generic Routing Encapsulation (GRE), Teredo, and Automatic Multicast Tunneling (AMT), respectively). This specification also updates RFC 6040 with configuration requirements needed to make any legacy tunnel ingress safe.
「明示的な混雑通知のトンネル」に関するRFC 6040により、明示的な混雑通知（ECN）の伝播に関する規則は、あらゆる形態のIP-in-IPトンネルに一貫していました。この仕様はRFC 6040を更新して、そのスコープには2つのIPヘッダーが少なくとも1つのシムヘッダーが分離されているトンネルが含まれていることを明確にします。このようなシムヘッダーを使用するIPトンネルプロトコルを広く展開し、ECN伝播について言及していない仕様（RFCS 2661、3931、2784、4380および7450を更新する調査を調査します。テレド、およびそれぞれ自動マルチキャストトンネル（AMT）。この仕様は、レガシートンネルの侵入を安全にするために必要な構成要件でRFC 6040を更新します。
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/rfc9601.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9601で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
1. Introduction
2. Terminology
3. Scope of RFC 6040
3.1. Feasibility of ECN Propagation between Tunnel Headers
3.2. Desirability of ECN Propagation between Tunnel Headers
4. Making a Non-ECN Tunnel Ingress Safe by Configuration
5. ECN Propagation and Fragmentation/Reassembly
6. IP-in-IP Tunnels with Tightly Coupled Shim Headers
6.1. Specific Updates to Protocols under IETF Change Control
6.1.1. L2TP (v2 and v3) ECN Extension
6.1.2. GRE
6.1.3. Teredo
6.1.4. AMT
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Author's Address
[RFC6040] on "Tunnelling of Explicit Congestion Notification" made the rules for propagation of Explicit Congestion Notification (ECN) [RFC3168] consistent for all forms of IP-in-IP tunnel.
[RFC6040]「明示的な混雑通知のトンネル」では、すべての形態のIP-in-IPトンネルについて一貫した、明示的な輻輳通知（ECN）[RFC3168]の伝播の規則を作成しました。
A common pattern for many tunnelling protocols is to encapsulate an inner IP header (v4 or v6) with one or more shim headers then an outer IP header (v4 or v6). Some of these shim headers are designed as generic encapsulations, so they do not necessarily directly encapsulate an inner IP header. Instead, they can encapsulate headers such as link-layer (L2) protocols that, in turn, often encapsulate IP. Thus, the abbreviation 'IP-shim-(L2)-IP' can be used for tunnels that are in scope of this document.
多くのトンネルプロトコルの一般的なパターンは、外部IPヘッダー（V4またはV6）よりも1つ以上のシムヘッダーを使用して、内側のIPヘッダー（V4またはV6）をカプセル化することです。これらのシムヘッダーの一部は、一般的なカプセルとして設計されているため、必ずしも内部IPヘッダーを直接カプセル化するわけではありません。代わりに、Link-Layer（L2）プロトコルなどのヘッダーをカプセル化できます。したがって、略語「IP-Shim-（L2）-IP」は、このドキュメントの範囲内のトンネルに使用できます。
To clear up confusion, this specification clarifies that the scope of [RFC6040] includes any IP-in-IP tunnel, including those with one or more shim headers and other encapsulations between the IP headers. Where necessary, it updates the specifications of the relevant encapsulation protocols with the specific text necessary to comply with [RFC6040].
混乱を解消するために、この仕様では、[RFC6040]の範囲には、IP-in-IPトンネルが含まれていることを明確にします。必要に応じて、関連するカプセル化プロトコルの仕様を[RFC6040]に準拠するために必要な特定のテキストを更新します。
This specification also updates [RFC6040] to state how operators ought to configure a legacy tunnel ingress to avoid unsafe system configurations.
また、この仕様は[RFC6040]を更新して、オペレーターが安全でないシステム構成を避けるためにレガシートンネルの侵入を構成する方法を述べています。
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」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This specification uses the terminology defined in [RFC6040].
この仕様では、[RFC6040]で定義されている用語を使用します。
In Section 1.1 of [RFC6040], its scope is defined as:
[RFC6040]のセクション1.1では、そのスコープは次のように定義されています。
...ECN field processing at encapsulation and decapsulation for any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is used for either the inner or outer headers.
... IPSECまたは非IPSECトンネルのいずれであっても、IP-in-IPトンネルのカプセル化および脱カプセル化でのECNフィールド処理。IPv4またはIPv6が内側ヘッダーまたは外側のヘッダーに使用されるかどうかに関係なく適用されます。
There are two problems with the above scoping statement:
上記のスコーピングステートメントには2つの問題があります。
Problem 1: It was intended to include cases where one or more shim headers sit between the IP headers. Many tunnelling implementers have interpreted the scope of [RFC6040] as it was intended, but it is ambiguous. Therefore, this specification updates [RFC6040] by adding the following scoping text after the sentences quoted above:
問題1：1つ以上のシムヘッダーがIPヘッダーの間に座る場合を含めることを目的としていました。多くのトンネルの実装者は、意図したとおりに[RFC6040]の範囲を解釈していますが、それはあいまいです。したがって、この仕様は、上記の文章の後に次のスコーピングテキストを追加することにより、[RFC6040]を更新します。
It applies in cases where an outer IP header encapsulates an inner IP header either directly or indirectly by encapsulating other headers that in turn encapsulate (or might encapsulate) an inner IP header.
外側のIPヘッダーが、他のヘッダーをカプセル化することにより、内部IPヘッダーを直接または間接的にカプセル化する場合に適用されます。
Problem 2: Like many IETF specifications, [RFC6040] is written as a specification that implementations can choose to claim compliance with. This means it does not cover two important situations:
問題2：多くのIETF仕様と同様に、[RFC6040]は、実装がコンプライアンスを請求することを選択できるようにする仕様として記述されています。これは、2つの重要な状況をカバーしないことを意味します。
1. Cases where it is infeasible for an implementation to access an inner IP header when adding or removing an outer IP header
1. 外側のIPヘッダーを追加または削除するときに、実装が内部IPヘッダーにアクセスすることが不可能な場合
2. Cases where implementations choose not to propagate ECN between IP headers
2. 実装がIPヘッダー間でECNを伝播しないことを選択する場合
However, the ECN field is a non-optional part of the IP header (v4 and v6), so any implementation that creates an outer IP header has to give the ECN field some value. There is only one safe value a tunnel ingress can use if it does not know whether the egress supports propagation of the ECN field; it has to clear the ECN field in any outer IP header to 0b00.
ただし、ECNフィールドはIPヘッダー（V4およびV6）の非感受性部分であるため、外側のIPヘッダーを作成する実装は、ECNフィールドに何らかの価値を与える必要があります。トンネルイングレスがECNフィールドの伝播をサポートしているかどうかがわからない場合、使用できる安全な価値は1つだけです。外側のIPヘッダーのECNフィールドを0B00にクリアする必要があります。
However, an RFC has no jurisdiction over implementations that choose not to comply or cannot comply with the RFC, including all implementations that predated it. Therefore, it would have been unreasonable to add such a requirement to [RFC6040]. Nonetheless, to ensure safe propagation of the ECN field over tunnels, it is reasonable to add requirements on operators to ensure they configure their tunnels safely (where possible). Before resolving 'Problem 2' by stating these configuration requirements (in Section 4), the factors that determine whether propagating ECN is feasible or desirable will be briefly introduced.
ただし、RFCには、それを順守しないことを選択したり、RFCを遵守できないことを選択した実装を管轄していません。したがって、このような要件を[RFC6040]に追加することは不合理だったでしょう。それにもかかわらず、トンネル上のECNフィールドの安全な伝播を確保するために、オペレーターに要件を追加して、トンネルを安全に構成することを保証することが合理的です。これらの構成要件（セクション4で）を記載することにより「問題2」を解決する前に、ECNの伝播が実現可能か望ましいかを決定する要因が簡単に導入されます。
In many cases, one or more shim headers and an outer IP header are always added to (or removed from) an inner IP packet as part of the same procedure. We call these tightly coupled shim headers. Processing a shim and outer header together is often necessary because a shim is not sufficient for packet forwarding in its own right; not unless complemented by an outer header. In these cases, it will often be feasible for an implementation to propagate the ECN field between the IP headers.
多くの場合、同じ手順の一部として内部IPパケットに常に1つ以上のシムヘッダーと外側のIPヘッダーが追加されます（または削除されます）。これらを厳しく結合したシムヘッダーと呼びます。シムと外側のヘッダーを一緒に処理することは、それ自体がパケット転送に十分ではないため、しばしば必要です。外側のヘッダーによって補完されない限り。これらの場合、実装がIPヘッダー間でECNフィールドを伝播することができることがよくあります。
In some cases, a tunnel adds an outer IP header and a tightly coupled shim header to an inner header that is not an IP header, but that, in turn, encapsulates an IP header (or might encapsulate an IP header). For instance, an inner Ethernet (or other link-layer) header might encapsulate an inner IP header as its payload. We call this a tightly coupled shim over an encapsulating header.
場合によっては、トンネルは外側のIPヘッダーと、IPヘッダーではない内側のヘッダーに厳密に結合したシムヘッダーを追加しますが、IPヘッダーをカプセル化する（またはIPヘッダーをカプセル化する可能性があります）。たとえば、内側のイーサネット（または他のリンク層）ヘッダーは、ペイロードとして内側のIPヘッダーをカプセル化する場合があります。これを、カプセル化ヘッダーの上に、しっかりと結合したシムと呼びます。
Digging to arbitrary depths to find an inner IP header within an encapsulation is strictly a layering violation, so it cannot be a required behaviour. Nonetheless, some tunnel endpoints already look within a Layer 2 (L2) header for an IP header, for instance, to map the Diffserv codepoint between an encapsulated IP header and an outer IP header [RFC2983]. In such cases at least, it should be feasible to also (independently) propagate the ECN field between the same IP headers. Thus, access to the ECN field within an encapsulating header can be a useful and benign optimization. The guidelines in Section 5 of [RFC9599] give the conditions for this layering violation to be benign.
カプセル化内で内側のIPヘッダーを見つけるために任意の深さを掘ることは、厳密に階層化違反であるため、必要な動作になることはできません。それにもかかわらず、一部のトンネルのエンドポイントは、例えば、カプセル化されたIPヘッダーと外側のIPヘッダー[RFC2983]の間のDiffserv CodePointをマッピングするために、IPヘッダーのレイヤー2（L2）ヘッダー内ですでに見ています[RFC2983]。少なくともそのような場合は、同じIPヘッダー間でECNフィールドを（独立して）伝播することも実行可能である必要があります。したがって、カプセル化ヘッダー内のECNフィールドへのアクセスは、有用で良性の最適化になります。[RFC9599]のセクション5のガイドラインは、このレイヤー化違反が良性になる条件を示しています。
Developers and network operators are encouraged to implement and deploy tunnel endpoints compliant with [RFC6040] (as updated by the present specification) in order to provide the benefits of wider ECN deployment [RFC8087]. Nonetheless, propagation of ECN between IP headers, whether separated by shim headers or not, has to be optional to implement and to use, because:
開発者とネットワークオペレーターは、より広いECN展開[RFC8087]の利点を提供するために、[RFC6040]（現在の仕様で更新された）に準拠したトンネルエンドポイントを実装および展開することをお勧めします。それにもかかわらず、IPヘッダー間のECNの伝播は、シムヘッダーによって分離されているかどうかにかかわらず、実装および使用するためにオプションでなければなりません。
* legacy implementations of tunnels without any ECN support already exist;
* ECNサポートのないトンネルのレガシー実装はすでに存在します。
* a network might be designed so that there is usually no bottleneck within the tunnel; and
* 通常、トンネル内にボトルネックがないようにネットワークを設計することができます。そして
* if the tunnel endpoints would have to search within an L2 header to find an encapsulated IP header, it might not be worth the potential performance hit.
* トンネルのエンドポイントがL2ヘッダー内で検索してカプセル化されたIPヘッダーを見つける必要がある場合、潜在的なパフォーマンスヒットの価値がないかもしれません。
Even when no specific attempt has been made to implement propagation of the ECN field at a tunnel ingress, it ought to be possible for the operator to render a tunnel ingress safe by configuration. The main safety concern is to disable (clear to zero) the ECN capability in the outer IP header at the ingress if the egress of the tunnel does not implement ECN logic to propagate any ECN markings into the packet forwarded beyond the tunnel. Otherwise, the non-ECN egress could discard any ECN marking introduced within the tunnel, which would break all the ECN-based control loops that regulate the traffic load over the tunnel.
トンネルの侵入でECNフィールドの伝播を実装するための具体的な試みがなされていない場合でも、オペレーターが構成によってトンネルの侵入を安全にすることは可能です。主な安全性の懸念は、トンネルの出口がECNロジックを実装してトンネルを越えて転送されたパケットにECNマークを伝播しない場合、イングレスの外側IPヘッダーのECN機能を無効にすることです（クリア）。それ以外の場合、非ECN出力は、トンネル内に導入されたECNマーキングを破棄し、トンネル上のトラフィック負荷を調節するすべてのECNベースの制御ループを破壊します。
Therefore, this specification updates Section 4.3 of [RFC6040] by inserting the following text at the end of the section:
したがって、この仕様は、セクションの最後に次のテキストを挿入することにより、[RFC6040]のセクション4.3を更新します。
Whether or not an ingress implementation claims compliance with [RFC6040], [RFC4301], or [RFC3168], when the outer tunnel header is IP (v4 or v6), if possible, the ingress MUST be configured to zero the outer ECN field in all of the following cases:
イングレスの実装が[RFC6040]、[RFC4301]、または[RFC3168]へのコンプライアンスを主張しているかどうかにかかわらず、外側のトンネルヘッダーがIP（V4またはV6）である場合、可能であれば、イングレスを構成する必要があります。次のすべての場合：
* if it is known that the tunnel egress does not support any of the RFCs that define propagation of the ECN field ([RFC6040], [RFC4301], or the full functionality mode of [RFC3168]);
* トンネルの出口が、ECNフィールドの伝播（[RFC6040]、[RFC4301]、または[RFC3168]の完全な機能モードを定義するRFCのいずれもサポートしていないことがわかっている場合。
* if the behaviour of the egress is not known or an egress with unknown behaviour might be dynamically paired with the ingress (one way for an operator of a tunnel ingress to determine the behaviour of an otherwise unknown egress is described in [decap-test]);
* 出口の動作が知られていない場合、または未知の動作を持つ出口がイングレスと動的にペアになっている場合（トンネルの侵入のオペレーターがそうでなければ未知の出口の動作を決定するための1つの方法は[decap-test]で説明されています）;
* if an IP header might be encapsulated within a non-IP header that the tunnel ingress is encapsulating, but the ingress does not inspect within the encapsulation.
* IPヘッダーが非IPヘッダー内にカプセル化されている場合、トンネルの侵入がカプセル化されているが、イングレスはカプセル化内で検査しない場合。
For the avoidance of doubt, the above only concerns the outer IP header. The ingress MUST NOT alter the ECN field of the arriving IP header that will become the inner IP header.
疑いを回避するために、上記は外側のIPヘッダーのみに関係しています。侵入は、内側のIPヘッダーになる到着IPヘッダーのECNフィールドを変更してはなりません。
In order that the network operator can comply with the above safety rules, an implementation of a tunnel ingress:
ネットワークオペレーターが上記の安全規則に準拠できるように、トンネルイングレスの実装：
* MUST NOT treat the former Type of Service (ToS) octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field. This is because the resulting linkage of ECN and Diffserv field propagation between inner and outer headers is not consistent with the definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260].
* 以前のタイプのサービス（TOS）Octet（IPv4）または以前のトラフィッククラスOctet（IPv6）を単一の8ビットフィールドとして扱ってはなりません。これは、[RFC2474]および[RFC3260]の6ビットDiffservフィールドの定義と、内側ヘッダーと外側ヘッダーの間のECNとDiffServフィールド伝播のリンクが一致しないためです。
* SHOULD be able to be configured to zero the ECN field of the outer header.
* 外側ヘッダーのECNフィールドをゼロにするように構成できるはずです。
These last two rules apply even if an implementation of a tunnel ingress does not claim to support [RFC6040], [RFC4301], or the full functionality mode of [RFC3168]
これらの最後の2つのルールは、トンネルイングレスの実装が[RFC6040]、[RFC4301]、または[RFC3168]の完全な機能モードをサポートすると主張していない場合でも適用されます。
For instance, if a tunnel ingress with no ECN-specific logic had a configuration capability to refer to the last 2 bits of the old ToS Byte of the outer (e.g., with a 0x3 mask) and set them to zero, while also being able to allow the DSCP to be re-mapped independently, that would be sufficient to satisfy both implementation requirements above.
たとえば、ECN固有のロジックを持たないトンネル侵入が、外側の古いTOSバイトの最後の2ビット（0x3マスクなど）を参照し、ゼロに設定する構成機能がある場合、DSCPを独立して再マッピングできるようにするには、上記の両方の実装要件を満たすのに十分です。
There might be concern that the above "MUST NOT" makes compliant implementations non-compliant at a stroke. However, by definition, it solely applies to equipment that provides Diffserv configuration. Any such Diffserv equipment that is configuring treatment of the former ToS octet (IPv4) or the former Traffic Class octet (IPv6) as a single 8-bit field must have always been non-compliant with the definition of the 6-bit Diffserv field in [RFC2474] and [RFC3260]. If a tunnel ingress does not have any ECN logic, copying the ECN field as a side effect of copying the DSCP is a seriously unsafe bug that risks breaking the feedback loops that regulate load on a tunnel, because it omits to check the ECN capability of the tunnel egress.
上記の「そうでない」と懸念があるかもしれません。ただし、定義上、DiffServ構成を提供する機器にのみ適用されます。以前のTOSオクテット（IPv4）または以前のトラフィッククラスのオクテット（IPv6）の処理を単一の8ビットフィールドとして構成しているこのようなDiffServ機器は、6ビットDiffServフィールドの定義と常に順守されていなかったに違いありません。[RFC2474]および[RFC3260]。トンネルの侵入にECNロジックがない場合、ECNフィールドをDSCPのコピーの副作用としてコピーすることは、トンネルの負荷を調節するフィードバックループを壊すリスクがある重大な安全でないバグです。トンネルの出口。
Zeroing the outer ECN field of all packets in all circumstances would be safe, but it would not be sufficient to claim compliance with [RFC6040] because it would not meet the aim of introducing ECN support to tunnels (see Section 4.3 of [RFC6040]).
すべての状況ですべてのパケットの外側ECNフィールドをゼロにすることは安全ですが、トンネルにECNサポートを導入する目的を満たしていないため、[RFC6040]の順守を主張するだけでは十分ではありません（[RFC6040]のセクション4.3を参照）。
The following requirements update [RFC6040], which omitted handling of the ECN field during fragmentation or reassembly. These changes might alter how many ECN-marked packets are propagated by a tunnel that fragments packets, but this would not raise any backward compatibility issues.
次の要件では、断片化または再組み立て中にECNフィールドの処理を省略した[RFC6040]の更新[RFC6040]。これらの変更は、パケットをフラグメントするトンネルによって伝播されるECNマークされたパケットの数を変更する可能性がありますが、これは後方互換性の問題を引き起こすことはありません。
If a tunnel ingress fragments a packet, it MUST set the outer ECN field of all the fragments to the same value as it would have set if it had not fragmented the packet.
トンネルの侵入がパケットを断片化する場合、すべてのフラグメントの外側ECNフィールドを、パケットを断片化していない場合と同じ値に設定したのと同じ値に設定する必要があります。
Section 5.3 of [RFC3168] specifies ECN requirements for reassembly of sets of 'outer fragments' into packets (in 'outer fragmentation', the fragmentation is visible in the outer header so that the tunnel egress can reassemble the fragments [INTAREA-TUNNELS]). Additionally, the following requirements apply at a tunnel egress:
[RFC3168]のセクション5.3は、「外側フラグメント」のセットをパケットに再組み立てるためのECN要件を指定しています（「外側の断片化」では、断片化が外側のヘッダーに表示され、トンネルの出口がフラグメント[intarea-tunnels]を再組み立てることができます）。さらに、トンネルの出口で次の要件が適用されます。
* During reassembly of outer fragments, the packet MUST be discarded if the ECN fields of the outer headers being reassembled into a single packet consist of a mixture of Not ECN-Capable Transport (Not-ECT) and other ECN codepoints.
* 外側の断片の再組み立て中に、外側のヘッダーのECNフィールドが単一のパケットに再組み立てされている場合、パケットを破棄する必要があります。
* If there is mix of ECT(0) and ECT(1) outer fragments, then the reassembled packet MUST be set to ECT(1).
* ECT（0）とECT（1）の外側フラグメントの混合がある場合、再組み立てされたパケットをECT（1）に設定する必要があります。
Reasoning: [RFC3168] originally defined ECT(0) and ECT(1) as equivalent, but [RFC3168] has been updated by [RFC8311] to make ECT(1) available for congestion marking differences. The rule is independent of the current experimental use of ECT(1) for Low Latency, Low Loss, and Scalable throughput (L4S) [RFC9331]. The rule is compatible with Pre-Congestion Notification (PCN) [RFC6660], which uses 2 levels of congestion severity, with the ranking of severity from highest to lowest being Congestion Experienced (CE), ECT(1), ECT(0). The decapsulation rules in [RFC6040] take a similar approach.
推論：[RFC3168]当初はECT（0）およびECT（1）が同等であると定義されていましたが、[RFC3168]は[RFC8311]によって更新され、ECT（1）が混雑マーキングの違いに利用可能になりました。このルールは、低遅延、低損失、およびスケーラブルなスループット（L4S）のECT（1）の現在の実験的使用とは無関係です[RFC9331]。このルールは、2つのレベルの混雑の重症度を使用して、最高から最低への重症度のランキング（CE）、ECT（1）、ECT（0）を使用する2つのレベルの混雑の重症度を使用する事前同時通知（PCN）[RFC6660]と互換性があります。[RFC6040]の脱カプセル化ルールも同様のアプローチを採用しています。
Below is a list of specifications of encapsulations with tightly coupled shim header(s) in rough chronological order. This list is confined to Standards Track or widely deployed protocols. So, for the avoidance of doubt, the updated scope of [RFC6040] is defined in Section 3 and is not limited to this list.
以下は、大まかな時系列の順序でしっかりと結合したシムヘッダーを備えたカプセルの仕様のリストです。このリストは、標準の追跡または広く展開されたプロトコルに限定されています。したがって、疑いを回避するために、[RFC6040]の更新された範囲はセクション3で定義されており、このリストに限定されません。
* Point-to-Point Tunneling Protocol (PPTP) [RFC2637]
* ポイントツーポイントトンネルプロトコル（PPTP）[RFC2637]
* Layer Two Tunneling Protocol (L2TP), specifically L2TPv2 [RFC2661] and L2TPv3 [RFC3931], which not only includes all the L2-specific specializations of L2TP, but also derivatives such as the Keyed IPv6 Tunnel [RFC8159]
* 2つのトンネリングプロトコル（L2TP）、特にL2TPV2 [RFC2661]およびL2TPV3 [RFC3931]を層レイヤーします。
* Generic Routing Encapsulation (GRE) [RFC2784] and Network Virtualization using GRE (NVGRE) [RFC7637]
* 一般的なルーティングカプセル化（GRE）[RFC2784]およびGRE（NVGRE）を使用したネットワーク仮想化[RFC7637]
* GPRS Tunnelling Protocol (GTP), specifically GTPv1 [GTPv1], GTP v1 User Plane [GTPv1-U], and GTP v2 Control Plane [GTPv2-C]
* GPRSトンネルプロトコル（GTP）、具体的にはGTPV1 [GTPV1]、GTP V1ユーザープレーン[GTPV1-U]、およびGTP V2コントロールプレーン[GTPV2-C]
* Teredo [RFC4380]
* Teredo [RFC4380]
* Control And Provisioning of Wireless Access Points (CAPWAP) [RFC5415]
* ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）[RFC5415]
* Locator/Identifier Separation Protocol (LISP) [RFC9300]
* ロケーター/識別子分離プロトコル（LISP）[RFC9300]
* Automatic Multicast Tunneling (AMT) [RFC7450]
* 自動マルチキャストトンネル（AMT）[RFC7450]
* Virtual eXtensible Local Area Network (VXLAN) [RFC7348] and Generic Protocol Extensions for VXLAN (VXLAN-GPE) [NVO3-VXLAN-GPE]
* 仮想拡張可能なローカルエリアネットワーク（VXLAN）[RFC7348]およびVXLANの汎用プロトコル拡張（VXLAN-GPE）[NVO3-VXLAN-GPE]
* The Network Service Header (NSH) [RFC8300] for Service Function Chaining (SFC)
* サービス機能チェーン（SFC）のネットワークサービスヘッダー（NSH）[RFC8300]
* Geneve [RFC8926]
* Geneve [RFC8926]
* Direct tunnelling of an IP packet within a UDP/IP datagram (see Section 3.1.11 of [RFC8085])
* UDP/IPデータグラム内のIPパケットの直接トンネリング（[RFC8085]のセクション3.1.11を参照）
* TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets (see Section 9.5 of [RFC9329])
* TCPインターネットキーエクスチェンジプロトコル（IKE）とIPSECパケットのカプセル化（[RFC9329]のセクション9.5を参照）
Some of the listed protocols enable encapsulation of a variety of network layer protocols as inner and/or outer. This specification applies to the cases where there is an inner and outer IP header as described in Section 3. Otherwise, [RFC9599] gives guidance on how to design propagation of ECN into other protocols that might encapsulate IP.
リストされているプロトコルの一部は、さまざまなネットワークレイヤープロトコルを内側および/または外側としてカプセル化できるようにします。この仕様は、セクション3で説明されているように内側と外側のIPヘッダーがある場合に適用されます。
Where protocols in the above list need to be updated to specify ECN propagation and are under IETF change control, update text is given in the following subsections. For those not under IETF control, it is RECOMMENDED that implementations of encapsulation and decapsulation comply with [RFC6040]. It is also RECOMMENDED that their specifications are updated to add a requirement to comply with [RFC6040] (as updated by the present document).
上記のリストのプロトコルを更新してECN伝播を指定する必要があり、IETF変更制御下にある場合、次のサブセクションで更新テキストが記載されています。IETF制御下にない場合は、カプセル化と脱カプセル化の実装が[RFC6040]に準拠することをお勧めします。また、[RFC6040]に準拠するための要件を追加するために、それらの仕様を更新することをお勧めします（現在のドキュメントで更新されます）。
PPTP is not under the change control of the IETF, but it has been documented in an Informational RFC [RFC2637]. However, there is no need for the present specification to update PPTP because L2TP has been developed as a standardized replacement.
PPTPはIETFの変更制御下にありませんが、情報RFC [RFC2637]で文書化されています。ただし、L2TPが標準化された代替品として開発されたため、現在の仕様はPPTPを更新する必要はありません。
NVGRE is not under the change control of the IETF, but it has been documented in an Informational RFC [RFC7637]. NVGRE is a specific use case of GRE (it re-purposes the key field from the initial specification of GRE [RFC1701] as a Virtual Subnet ID). Therefore, the text that updates GRE in Section 6.1.2 below is also intended to update NVGRE.
NVGREはIETFの変更制御下にありませんが、情報RFC [RFC7637]で文書化されています。NVGREはGREの特定のユースケースです（仮想サブネットIDとしてGRE [RFC1701]の初期仕様からキーフィールドを再適用します）。したがって、以下のセクション6.1.2でGREを更新するテキストは、NVGREを更新することも目的としています。
Although the definition of the various GTP shim headers is under the control of the Third Generation Partnership Project (3GPP), it is hard to determine whether the 3GPP or the IETF controls standardization of the _process_ of adding both a GTP and an IP header to an inner IP header. Nonetheless, the present specification is provided so that the 3GPP can refer to it from any of its own specifications of GTP and IP header processing.
さまざまなGTPシムヘッダーの定義は第3世代パートナーシッププロジェクト（3GPP）の管理下にありますが、3GPPまたはIETFがGTPとIPヘッダーの両方を追加する_Process_の標準化を制御するかどうかを判断するのは困難です。内側のIPヘッダー。それにもかかわらず、3GPPがGTPおよびIPヘッダー処理の独自の仕様のいずれかから3GPPを参照できるように、現在の仕様が提供されます。
The specification of CAPWAP already specifies [RFC3168] ECN propagation and ECN capability negotiation. Without modification, the CAPWAP specification already interworks with the backward-compatible updates to [RFC3168] in [RFC6040].
CAPWAPの仕様は、[RFC3168] ECN伝播とECN能力交渉を既に指定しています。修正なしでは、CapWap仕様は、[RFC6040]の[RFC3168]の後方互換の更新とすでに相互作用しています。
LISP made the ECN propagation procedures in [RFC3168] mandatory from the start. [RFC3168] has since been updated by [RFC6040], but the changes are backwards compatible, so there is still no need for LISP tunnel endpoints to negotiate their ECN capabilities.
LISPは、[RFC3168]のECN伝播手順を最初から必須にしました。[RFC3168]はその後[RFC6040]によって更新されましたが、変更は後方互換性があるため、ECN機能を交渉するためにLISPトンネルエンドポイントがまだ必要ではありません。
VXLAN is not under the change control of the IETF, but it has been documented in an Informational RFC. It is RECOMMENDED that VXLAN implementations comply with [RFC6040] when the VXLAN header is inserted between (or removed from between) IP headers. The authors of any future update of the VXLAN spec are also encouraged to add a requirement to comply with [RFC6040] as updated by the present specification. In contrast, VXLAN-GPE is being documented under IETF change control and it does require compliance with [RFC6040].
VXLANはIETFの変更制御下にありませんが、情報RFCで文書化されています。VXLANヘッダーがIPヘッダーの間に挿入される（またはその間から削除された）場合、VXLANの実装は[RFC6040]に準拠することをお勧めします。VXLAN仕様の将来の更新の著者は、現在の仕様で更新されるように[RFC6040]に準拠するための要件を追加することも奨励されています。対照的に、VXLAN-GPEはIETF Change Controlの下で文書化されており、[RFC6040]へのコンプライアンスが必要です。
The Network Service Header (NSH) [RFC8300] has been defined as a shim-based encapsulation to identify the Service Function Path (SFP) in the Service Function Chaining (SFC) architecture [RFC7665]. A proposal has been made for the processing of ECN when handling transport encapsulation [SFC-NSH-ECN].
ネットワークサービスヘッダー（NSH）[RFC8300]は、サービス関数チェーン（SFC）アーキテクチャ[RFC7665]のサービス関数パス（SFP）を特定するためのシムベースのカプセル化として定義されています。輸送カプセル化[SFC-NSH-ECN]を処理する際に、ECNの処理に関する提案が作成されました。
The specification of Geneve already refers to [RFC6040] for ECN encapsulation.
Geneveの仕様は、ECNカプセル化の[RFC6040]をすでに指しています。
Section 3.1.11 of [RFC8085] already explains that a tunnel that encapsulates an IP header within a UDP/IP datagram needs to follow [RFC6040] when propagating the ECN field between inner and outer IP headers. Section 3 of the present specification updates [RFC6040] to clarify that its scope includes cases with a shim header between the IP headers. So it indirectly updates the scope of [RFC8085] to include cases with a shim header as well as a UDP header between the IP headers.
[RFC8085]のセクション3.1.11は、UDP/IPデータグラム内のIPヘッダーをカプセル化するトンネルは、内側と外側のIPヘッダーの間にECNフィールドを伝播するときに[RFC6040]に従う必要があることをすでに説明しています。現在の仕様のセクション3は、[RFC6040]を更新し、そのスコープにはIPヘッダー間にシムヘッダーがあるケースが含まれていることを明確にします。したがって、[RFC8085]の範囲を間接的に更新して、シムヘッダーとIPヘッダー間のUDPヘッダーを備えたケースを含めます。
The requirements in Section 4 update [RFC6040], and hence also indirectly update the UDP usage guidelines in [RFC8085] to add the important but previously unstated requirement that, if the UDP tunnel egress does not, or might not, support ECN propagation, a UDP tunnel ingress has to clear the outer IP ECN field to 0b00, e.g., by configuration.
セクション4の要件は[RFC6040]を更新し、したがって[RFC8085]のUDP使用ガイドラインを間接的に更新して、UDPトンネルの出口がECNの伝播をサポートしない場合、またはサポートしていない場合、重要なが以前に述べられていない要件を追加します。UDPトンネルイングレスは、外部IP ECNフィールドを0B00にクリアする必要があります。たとえば、構成ごとに。
Section 9.5 of [RFC9329] already recommends the compatibility mode of [RFC6040] in this case because there is not a one-to-one mapping between inner and outer packets when TCP encapsulates IKE or IPsec.
[RFC9329]のセクション9.5は、TCPがIKEまたはIPSECをカプセル化するときに内側パケットと外側パケットの間に1対1のマッピングがないため、[RFC6040]の互換性モードを既に推奨しています。
The L2TP terminology used here is defined in [RFC2661] and [RFC3931].
ここで使用されるL2TP用語は、[RFC2661]および[RFC3931]で定義されています。
L2TPv3 [RFC3931] is used as a shim header between any packet-switched network (PSN) header (e.g., IPv4, IPv6, and MPLS) and many types of L2 headers. The L2TPv3 shim header encapsulates an L2-specific sub-layer, then an L2 header that is likely to contain an inner IP header (v4 or v6). Then this whole stack of headers can be encapsulated within an optional outer UDP header and an outer PSN header that is typically IP (v4 or v6).
L2TPV3 [RFC3931]は、パケットスイッチネットワーク（PSN）ヘッダー（IPv4、IPv6、MPLSなど）および多くのタイプのL2ヘッダーの間のシムヘッダーとして使用されます。L2TPV3シムヘッダーは、L2固有のサブレイヤーをカプセル化し、次に内側のIPヘッダー（V4またはV6）を含む可能性が高いL2ヘッダーをカプセル化します。次に、このヘッダーのスタック全体を、オプションの外側のUDPヘッダーと、通常IP（V4またはV6）である外部PSNヘッダー内にカプセル化できます。
L2TPv2 is used as a shim header between any PSN header and a PPP header, which is in turn likely to encapsulate an IP header.
L2TPV2は、PSNヘッダーとPPPヘッダーの間のシムヘッダーとして使用され、IPヘッダーをカプセル化する可能性があります。
Even though these shims are rather fat (particularly in the case of L2TPv3), they still fit the definition of a tightly coupled shim header over an encapsulating header (Section 3.1) because all the headers encapsulating the L2 header are added (or removed) together. L2TPv2 and L2TPv3 are therefore within the scope of [RFC6040], as updated by Section 3.
これらのシムはかなり脂肪ですが（特にL2TPV3の場合）、L2ヘッダーをカプセル化するすべてのヘッダーが一緒に追加されている（または削除）されるため、カプセル化ヘッダー（セクション3.1）の上に、しっかりと結合したシムヘッダーの定義に適合します。。したがって、L2TPV2およびL2TPV3は、セクション3で更新されるように、[RFC6040]の範囲内です。
Implementation of the ECN extension to L2TPv2 and L2TPv3 defined in Section 6.1.1.2 is RECOMMENDED in order to provide the benefits of ECN [RFC8087] whenever a node within an L2TP tunnel becomes the bottleneck for an end-to-end traffic flow.
セクション6.1.1.2で定義されているL2TPV2およびL2TPV3へのECN拡張の実装は、L2TPトンネル内のノードがエンドツーエンドの交通流のボトルネックになる場合、ECN [RFC8087]の利点を提供するために推奨されます。
The following text is appended to both Section 5.3 of [RFC2661] and Section 4.5 of [RFC3931] as an update to the base L2TPv2 and L2TPv3 specifications:
次のテキストは、[RFC2661]のセクション5.3と[RFC3931]のセクション4.5の両方に追加されます。ベースL2TPV2およびL2TPV3仕様の更新：
The operator of an LCCE that does not support the ECN extension in Section 6.1.1.2 of RFC 9601 MUST follow the configuration requirements in Section 4 of RFC 9601 to ensure it clears the outer IP ECN field to 0b00 when the outer PSN header is IP (v4 or v6).
RFC 9601のセクション6.1.1.2のECN拡張をサポートしていないLCCEの演算子は、RFC 9601のセクション4の構成要件に従って、外側のPSNヘッダーがIPである場合に外部IP ECNフィールドを0B00にクリアする必要があります（V4またはV6）。
In particular, for an L2TP Control Connection Endpoint (LCCE) implementation that does not support the ECN extension, this means that configuration of how it propagates the ECN field between inner and outer IP headers MUST be independent of any configuration of the Diffserv extension of L2TP [RFC3308].
特に、ECN拡張をサポートしないL2TP制御接続エンドポイント（LCCE）実装の場合、これは、内側と外側のIPヘッダー間のECNフィールドの伝播方法の構成が、L2TPのdiffserv拡張の構成とは無関係でなければならないことを意味します。[RFC3308]。
When the outer PSN header and the payload inside the L2 header are both IP (v4 or v6), an LCCE will propagate the ECN field at ingress and egress by following the rules in Section 4 of [RFC6040].
外側のPSNヘッダーとL2ヘッダー内のペイロードが両方ともIP（V4またはV6）である場合、LCCEは、[RFC6040]のセクション4のルールに従うことにより、IngressとEgressのECNフィールドを伝播します。
Before encapsulating any data packets, [RFC6040] requires an ingress LCCE to check that the egress LCCE supports ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]). If the egress supports ECN propagation, the ingress LCCE can use the normal mode of encapsulation (copying the ECN field from inner to outer). Otherwise, the ingress LCCE has to use compatibility mode [RFC6040] (clearing the outer IP ECN field to 0b00).
データパケットをカプセル化する前に、[RFC6040]では、出力LCCEが[RFC6040]で定義されているECN伝播をサポートしているか、その互換性のある前任者の1つ（[RFC4301]または[RFC3168]の完全な機能モードをサポートすることを確認する必要があります。出口がECN伝播をサポートする場合、侵入LCCEは通常のカプセル化モード（ECNフィールドを内側から外側にコピーする）を使用できます。それ以外の場合、Ingress LCCEは互換性モード[RFC6040]を使用する必要があります（外部IP ECNフィールドを0B00にクリアする）。
An LCCE can determine the remote LCCE's support for ECN either statically (by configuration) or by dynamic discovery during setup of each control connection between the LCCEs using the ECN Capability Attribute-Value Pair (AVP) defined in Section 6.1.1.2.1.
LCCEは、セクション6.1.1.1.2.1で定義されているECN機能属性値ペア（AVP）を使用して、LCCE間の各コントロール接続のセットアップ中の静的（構成による）または動的発見のいずれかのリモートLCCEのサポートを決定できます。
Where the outer PSN header is some protocol other than IP that supports ECN, the appropriate ECN propagation specification will need to be followed, e.g., [RFC5129] for MPLS. Where no specification exists for ECN propagation by a particular PSN, [RFC9599] gives general guidance on how to design ECN propagation into a protocol that encapsulates IP.
外側のPSNヘッダーがECNをサポートするIP以外のプロトコルである場合、MPLSの適切なECN伝播仕様、たとえば[RFC5129]に従う必要があります。特定のPSNによるECN伝播の仕様が存在しない場合[RFC9599]は、IPをカプセル化するプロトコルにECN伝播を設計する方法に関する一般的なガイダンスを提供します。
The ECN Capability AVP defined here has Attribute Type 103. The AVP has the following format:
ここで定義されているECN機能AVPには属性タイプ103があります。AVPには次の形式があります。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 103 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECN Capability AVP for L2TP (v2 or v3)
図1：L2TPのECN機能AVP（V2またはV3）
This AVP MAY be present in the Start-Control-Connection-Request (SCCRQ) and Start-Control-Connection-Reply (SCCRP) message types. This AVP MAY be hidden (the H-bit is set to 0 or 1) and is optional (the M-bit is not set). The length (before hiding) of this AVP is 6 octets. The Vendor ID is the IETF Vendor ID of 0.
このAVPは、Start-Control-Connection-Request（SCCRQ）およびStart-Control-Connection-Reply（SCCRP）メッセージタイプに存在する場合があります。このAVPは隠されている場合があります（Hビットは0または1に設定されています）。オプションです（Mビットは設定されていません）。このAVPの長さ（隠す前）は6オクテットです。ベンダーIDは0のIETFベンダーIDです。
When an LCCE sends an ECN Capability AVP, it indicates that it supports ECN propagation. When no ECN Capability AVP is present, it indicates that the sender does not support ECN propagation.
LCCEがECN機能AVPを送信すると、ECN伝播をサポートすることを示します。ECN機能AVPが存在しない場合、送信者がECN伝播をサポートしていないことを示します。
If an LCCE initiating a control connection supports ECN propagation, it will send an SCCRQ containing an ECN Capability AVP. If the tunnel terminator supports ECN, it will return an SCCRP that also includes an ECN Capability AVP. Then, for any sessions created by that control connection, both ends of the tunnel can use the normal mode of [RFC6040]; i.e., they can copy the IP ECN field from inner to outer when encapsulating data packets.
制御接続を開始するLCCEがECN伝播をサポートする場合、ECN機能AVPを含むSCCRQが送信されます。トンネルターミネーターがECNをサポートする場合、ECN機能AVPも含むSCCRPを返します。次に、その制御接続によって作成されたセッションでは、トンネルの両端が[RFC6040]の通常モードを使用できます。つまり、データパケットをカプセル化するときに、IP ECNフィールドを内側から外側にコピーできます。
On the other hand, if the tunnel terminator does not support ECN, it will ignore the ECN Capability AVP and send an SCCRP to the tunnel initiator without an ECN Capability AVP. The tunnel initiator interprets the absence of the ECN Capability flag in the SCCRP as an indication that the tunnel terminator is incapable of supporting ECN. When encapsulating data packets for any sessions created by that control connection, the tunnel initiator will then use the compatibility mode of [RFC6040] to clear the ECN field of the outer IP header to 0b00.
一方、トンネルターミネーターがECNをサポートしていない場合、ECN機能AVPを無視し、ECN機能AVPなしでSCCRPをトンネルイニシエーターに送信します。トンネルイニシエーターは、トンネルターミネーターがECNをサポートできないことを示すこととして、SCCRPにECN機能フラグが存在しないことを解釈します。その制御接続によって作成されたセッションのデータパケットをカプセル化する場合、トンネルイニシエーターは[RFC6040]の互換性モードを使用して、外側IPヘッダーのECNフィールドを0B00にクリアします。
If the tunnel terminator does not support this ECN extension, the network operator is still expected to configure it to comply with the safety provisions set out in Section 6.1.1.1 when it acts as an ingress LCCE.
トンネルターミネーターがこのECN拡張機能をサポートしていない場合、ネットワークオペレーターは、イングレスLCCEとして機能する場合に、セクション6.1.1.1に定められた安全規定に準拠するように構成することがまだ期待されています。
If ECN support by the ingress and egress LCCEs is configured statically, as allowed in Section 6.1.1.2, they both ignore the presence or absence of any ECN capability AVP.
イングレスおよび出口LCCEによるECNサポートが静的に構成されている場合、セクション6.1.1.2で許可されているように、ECN機能AVPの有無を無視します。
The GRE terminology used here is defined in [RFC2784]. GRE is often used as a tightly coupled shim header between IP headers. Sometimes, the GRE shim header encapsulates an L2 header, which might in turn encapsulate an IP header. Therefore, GRE is within the scope of [RFC6040] as updated by Section 3.
ここで使用されるGRE用語は[RFC2784]で定義されています。GREは、IPヘッダー間の厳密に結合したシムヘッダーとしてよく使用されます。GREシムヘッダーがL2ヘッダーをカプセル化し、IPヘッダーをカプセル化する場合があります。したがって、GREはセクション3で更新されるように[RFC6040]の範囲内です。
Implementation of support for [RFC6040] as updated by the present specification is RECOMMENDED for GRE tunnel endpoints in order to provide the benefits of ECN [RFC8087] whenever a node within a GRE tunnel becomes the bottleneck for an end-to-end IP traffic flow tunnelled over GRE using IP as the delivery protocol (outer header).
現在の仕様によって更新された[RFC6040]のサポートの実装は、GREトンネル内のノードがエンドツーエンドIPトラフィックフローのボトルネックになる場合に、ECN [RFC8087]の利点を提供するために、GREトンネルエンドポイントに推奨されます。配信プロトコル（外側ヘッダー）としてIPを使用してGREを介してTunnelled。
GRE itself does not support dynamic setup and configuration of tunnels. However, control plane protocols, such as Next Hop Resolution Protocol (NHRP) [RFC2332], Mobile IPv4 (MIP4) [RFC5944], Mobile IPv6 (MIP6) [RFC6275], Proxy Mobile IP (PMIP) [RFC5845], and IKEv2 [RFC7296], are sometimes used to set up GRE tunnels dynamically.
GRE自体は、動的なセットアップとトンネルの構成をサポートしていません。ただし、次のホップ解像度プロトコル（NHRP）[RFC2332]、モバイルIPv4（MIP4）[RFC5944]、モバイルIPv6（MIP6）[RFC6275]、プロキシモバイルIP（PMIP）[RFC5845]、IKEV2 [RFC7296]は、GREトンネルを動的にセットアップするために使用されることがあります。
When these control protocols set up IP-in-IP or IPsec tunnels, it is likely that the resulting tunnels will propagate the ECN field as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]). However, if they use a GRE encapsulation, this presumption is less sound.
これらの制御プロトコルがIP-in-IPまたはIPSECトンネルをセットアップすると、結果のトンネルが[RFC6040]またはその互換性のある前任者の1つ（[RFC4301]または[[RFC4301]または[）[]の完全な機能モードで定義されているようにECNフィールドを伝播する可能性があります。RFC3168]）。ただし、GREカプセル化を使用する場合、この推定はあまり健全です。
Therefore, if the outer delivery protocol is IP (v4 or v6), the operator is obliged to follow the safe configuration requirements in Section 4. Section 6.1.2.1 updates the base GRE specification with this requirement to emphasize its importance.
したがって、外側の配信プロトコルがIP（V4またはV6）の場合、オペレーターはセクション4の安全な構成要件に従う義務があります。
Where the delivery protocol is some protocol other than IP that supports ECN, the appropriate ECN propagation specification will need to be followed, e.g., [RFC5129] for MPLS. Where no specification exists for ECN propagation by a particular PSN, [RFC9599] gives more general guidance on how to propagate ECN to and from protocols that encapsulate IP.
配信プロトコルがECNをサポートするIP以外のプロトコルである場合、MPLSの適切なECN伝播仕様、たとえば[RFC5129]に従う必要があります。特定のPSNによるECN伝播の仕様が存在しない場合、[RFC9599]は、IPをカプセル化するプロトコルとの間でECNを伝播する方法に関するより一般的なガイダンスを提供します。
The following text is appended to Section 3 of [RFC2784] as an update to the base GRE specification:
次のテキストは、ベースGRE仕様の更新として[RFC2784]のセクション3に追加されます。
The operator of a GRE tunnel ingress MUST follow the configuration requirements in Section 4 of RFC 9601 when the outer delivery protocol is IP (v4 or v6).
GREトンネルイングレスの演算子は、外部配信プロトコルがIP（V4またはV6）の場合、RFC 9601のセクション4の構成要件に従う必要があります。
Teredo [RFC4380] provides a way to tunnel IPv6 over an IPv4 network with a UDP-based shim header between the two.
Teredo [RFC4380]は、2つの間にUDPベースのShimヘッダーを使用してIPv4ネットワークを介してIPv6をトンネルする方法を提供します。
For Teredo tunnel endpoints to provide the benefits of ECN, the Teredo specification would have to be updated to include negotiation of the ECN capability between Teredo tunnel endpoints. Otherwise, it would be unsafe for a Teredo tunnel ingress to copy the ECN field to the IPv6 outer.
Teredoトンネルのエンドポイントの場合、ECNの利点を提供するために、Teredoトンネルエンドポイント間のECN機能の交渉を含めるために、Teredo仕様を更新する必要があります。それ以外の場合、Teredoトンネルの侵入がECNフィールドをIPv6外側にコピーするのは安全ではありません。
Those implementations known to the authors at the time of writing do not support propagation of ECN, but they do safely zero the ECN field in the outer IPv6 header. However, the specification does not mention anything about this.
執筆時点で著者に知られているこれらの実装は、ECNの伝播をサポートしていませんが、外側のIPv6ヘッダーのECNフィールドを安全にゼロにします。ただし、仕様ではこれについては何も言及していません。
To make existing Teredo deployments safe, it would be possible to add ECN capability negotiation to those that are subject to remote OS update. However, for those implementations not subject to remote OS update, it will not be feasible to require them to be configured correctly because Teredo tunnel endpoints are generally deployed on hosts.
既存のTeredo Deploymentsを安全にするために、リモートOSアップデートの対象となるユーザーにECN機能交渉を追加することができます。ただし、リモートOSの更新の対象とならない実装では、テレドトンネルのエンドポイントが一般にホストに展開されるため、正しく構成することを要求することは実現できません。
Therefore, until ECN support is added to the specification of Teredo, the only feasible further safety precaution available here is to update the specification of Teredo implementations with the following text as a new section:
したがって、Teredoの仕様にECNサポートが追加されるまで、ここで利用可能な唯一の実行可能なさらなる安全予防措置は、次のテキストを含むTeredo実装の仕様を新しいセクションとして更新することです。
5.1.3. Safe "Non-ECN" Teredo Encapsulation
5.1.3. 安全な「非ECN」テレドカプセル化
A Teredo tunnel ingress implementation that does not support ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) MUST zero the ECN field in the outer IPv6 header.
[RFC6040]またはその互換性のある前任者の1つ（[RFC4301]または[RFC3168]の完全性モード）で定義されているECN伝播をサポートしないTeredoトンネルイングレス実装は、外側IPv6ヘッダーのECNフィールドをゼロする必要があります。
AMT [RFC7450] is a tightly coupled shim header that encapsulates an IP packet and is encapsulated within a UDP/IP datagram. Therefore, AMT is within the scope of [RFC6040] as updated by Section 3.
AMT [RFC7450]は、IPパケットをカプセル化し、UDP/IPデータグラム内にカプセル化された、緊密に結合されたシムヘッダーです。したがって、AMTはセクション3で更新されたように[RFC6040]の範囲内です。
Implementation of support for [RFC6040] as updated by the present specification is RECOMMENDED for AMT tunnel endpoints in order to provide the benefits of ECN [RFC8087] whenever a node within an AMT tunnel becomes the bottleneck for an IP traffic flow tunnelled over AMT.
現在の仕様によって更新された[RFC6040]のサポートの実装は、AMTトンネル内のノードがAMTに覆われたIPトラフィックフローのボトルネックになると、ECN [RFC8087]の利点を提供するために、AMTトンネルエンドポイントに推奨されます。
To comply with [RFC6040], an AMT relay and gateway will follow the rules for propagation of the ECN field at ingress and egress, respectively, as described in Section 4 of [RFC6040].
[RFC6040]に準拠するために、AMTリレーとゲートウェイは、[RFC6040]のセクション4で説明されているように、それぞれIngressとEgressでのECNフィールドの伝播のルールに従います。
Before encapsulating any data packets, [RFC6040] requires an ingress AMT relay to check that the egress AMT gateway supports ECN propagation as defined in [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]). If the egress gateway supports ECN, the ingress relay can use the normal mode of encapsulation (copying the IP ECN field from inner to outer). Otherwise, the ingress relay has to use compatibility mode, which means it has to clear the outer ECN field to zero [RFC6040].
データパケットをカプセル化する前に、[RFC6040]では、侵入AMTゲートウェイが[RFC6040]またはその互換性のある前任者の1つ（[RFC4301]または[RFC3168]の完全な機能モード）で定義されているECN伝播をサポートしていることを確認するために、イングレスAMTリレーが必要です。。出力ゲートウェイがECNをサポートする場合、イングレスリレーは通常のカプセル化モード（内側から外側へのIP ECNフィールドをコピー）を使用できます。それ以外の場合、Ingressリレーは互換性モードを使用する必要があります。つまり、外側のECNフィールドをゼロにクリアする必要があります[RFC6040]。
An AMT tunnel is created dynamically (not manually), so the relay will need to determine the remote gateway's support for ECN using the ECN capability declaration defined in Section 6.1.4.2.
AMTトンネルは動的に（手動ではなく）作成されるため、セクション6.1.4.2で定義されているECN機能宣言を使用して、リモートゲートウェイのECNのサポートを決定する必要があります。
The following text is appended to Section 4.2.2 of [RFC7450] as an update to the AMT specification:
次のテキストは、AMT仕様の更新として[RFC7450]のセクション4.2.2に追加されます。
The operator of an AMT relay that does not support [RFC6040] or one of its compatible predecessors ([RFC4301] or the full functionality mode of [RFC3168]) MUST follow the configuration requirements in Section 4 of RFC 9601 to ensure it clears the outer IP ECN field to zero.
[RFC6040]をサポートしていないAMTリレーの演算子またはその互換性のある前任者の1つ（[RFC4301]または[RFC3168]の完全な機能モード）は、RFC 9601のセクション4の構成要件に従って、外側をクリアすることを保証する必要があります。IP ECNフィールドからゼロ。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=0 |Type=3 | Reserved |E|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated AMT Request Message Format
図2：更新されたAMTリクエストメッセージ形式
Bit 14 of the AMT Request Message counting from 0 (or bit 7 of the Reserved field counting from 1) is defined here as the AMT Gateway ECN Capability flag (E) as shown in Figure 2. The definitions of all other fields in the AMT Request Message are unchanged from [RFC7450].
図2に示すように、ここでは0（または1からの予約済みフィールドカウントのビット7）からカウントされているAMTリクエストメッセージカウント（1からの予約済みフィールドカウントのビット7）のビット14は、ここでAMTゲートウェイECN機能フラグ（E）として定義されています。[RFC7450]からリクエストメッセージは変更されていません。
When the E flag is set to 1, it indicates that the sender of the message supports [RFC6040] ECN propagation. When it is cleared to zero, it indicates the sender of the message does not support [RFC6040] ECN propagation. An AMT gateway "that supports [RFC6040] ECN propagation" means one that propagates the ECN field to the forwarded data packet based on the combination of arriving inner and outer ECN fields as defined in Section 4 of [RFC6040].
Eフラグが1に設定されると、メッセージの送信者が[RFC6040] ECN伝播をサポートしていることを示します。ゼロにクリアされると、メッセージの送信者が[RFC6040] ECN伝播をサポートしていないことを示します。[RFC6040] ECN伝播をサポートするAMTゲートウェイは、[RFC6040]のセクション4で定義されているように、内側と外側のECNフィールドの到着と外側のECNフィールドの組み合わせに基づいて、ECNフィールドを転送データパケットに伝播するものを意味します。
The other bits of the Reserved field remain reserved. They will continue to be cleared to zero when sent and ignored when either received or forwarded as specified in Section 5.1.3.3 of [RFC7450].
予約済みフィールドのもう1つのビットは保留されたままです。[RFC7450]のセクション5.1.3.3で指定されているように、受信または転送のいずれかが送信され、無視された場合、それらはゼロに引き続きクリアされます。
An AMT gateway that does not support [RFC6040] MUST NOT set the E flag of its Request Message to 1.
[RFC6040]をサポートしないAMTゲートウェイは、要求メッセージのEフラグを1に設定してはなりません。
An AMT gateway that supports [RFC6040] ECN propagation MUST set the E flag of its Relay Discovery Message to 1.
[RFC6040] ECN伝播をサポートするAMTゲートウェイは、リレー発見メッセージのEフラグを1に設定する必要があります。
The action of the corresponding AMT relay that receives a Request message with the E flag set to 1 depends on whether the relay itself supports [RFC6040] ECN propagation:
eフラグを1に設定した要求メッセージを受信する対応するAMTリレーのアクションは、リレー自体が[RFC6040] ECN伝播をサポートするかどうかによって異なります。
* If the relay supports [RFC6040] ECN propagation, it will store the ECN capability of the gateway along with its address. Then, whenever it tunnels datagrams towards this gateway, it MUST use the normal mode of [RFC6040] to propagate the ECN field when encapsulating datagrams (i.e., it copies the IP ECN field from inner to outer header).
* リレーが[RFC6040] ECN伝播をサポートする場合、アドレスとともにゲートウェイのECN機能を保存します。次に、このゲートウェイに向かってデータグラムをトンネルするたびに、[RFC6040]の通常モードを使用して、データグラムをカプセル化するときにECNフィールドを伝播する必要があります（つまり、IP ECNフィールドを内側から外側のヘッダーにコピーします）。
* If the discovered AMT relay does not support [RFC6040] ECN propagation, it will ignore the E flag in the Reserved field as per Section 5.1.3.3 of [RFC7450].
* 発見されたAMTリレーが[RFC6040] ECN伝播をサポートしていない場合、[RFC7450]のセクション5.1.3.3に従って、予約フィールドのEフラグを無視します。
If the AMT relay does not support [RFC6040] ECN propagation, the network operator is still expected to configure it to comply with the safety provisions set out in Section 6.1.4.1.
AMTリレーが[RFC6040] ECN伝播をサポートしていない場合、ネットワークオペレーターは、セクション6.1.4.1に記載されている安全規定に準拠するように構成することがまだ期待されています。
IANA has assigned the following AVP in the L2TP "Control Message Attribute Value Pairs" registry:
IANAは、L2TP「Control Message属性値ペア」レジストリに次のAVPを割り当てました。
+================+================+===========+
| Attribute Type | Description | Reference |
+================+================+===========+
| 103 | ECN Capability | RFC 9601 |
+----------------+----------------+-----------+
Table 1
The Security Considerations in [RFC6040] and [RFC9599] apply equally to the scope defined for the present specification.
[RFC6040]および[RFC9599]のセキュリティ上の考慮事項は、現在の仕様で定義されているスコープに等しく適用されます。
[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>.
[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>.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, DOI 10.17487/RFC2661, August 1999,
<https://www.rfc-editor.org/info/rfc2661>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[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>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, DOI 10.17487/RFC3931, March 2005,
<https://www.rfc-editor.org/info/rfc3931>.
[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>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<https://www.rfc-editor.org/info/rfc4380>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
[RFC9599] Briscoe, B. and J. Kaippallimalil, "Guidelines for Adding
Congestion Notification to Protocols that Encapsulate IP",
RFC 9599, DOI 10.17487/RFC9599, August 2024,
<https://www.rfc-editor.org/info/rfc9599>.
[decap-test]
Briscoe, B., "A Test for IP-ECN Propagation by a Remote
Tunnel Endpoint", Technical Report, TR-BB-2023-003,
DOI 10.48550/arXiv.2311.16825, November 2023,
<https://arxiv.org/abs/2311.16825>.
[GTPv1] 3GPP, "General Packet Radio Service (GPRS); GPRS
Tunnelling Protocol (GTP) across the Gn and Gp interface",
Technical Specification 29.060.
[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Technical
Specification 29.281.
[GTPv2-C] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General
Packet Radio Service (GPRS) Tunnelling Protocol for
Control plane (GTPv2-C); Stage 3", Technical
Specification 29.274.
[INTAREA-TUNNELS]
Touch, J. D. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-13, 26 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-intarea-
tunnels-13>.
[NVO3-VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN (VXLAN-GPE)", Work in Progress,
Internet-Draft, draft-ietf-nvo3-vxlan-gpe-13, 4 November
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
nvo3-vxlan-gpe-13>.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701,
DOI 10.17487/RFC1701, October 1994,
<https://www.rfc-editor.org/info/rfc1701>.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N.
Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)",
RFC 2332, DOI 10.17487/RFC2332, April 1998,
<https://www.rfc-editor.org/info/rfc2332>.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, DOI 10.17487/RFC2637, July 1999,
<https://www.rfc-editor.org/info/rfc2637>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<https://www.rfc-editor.org/info/rfc2983>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>.
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
Two Tunneling Protocol (L2TP) Differentiated Services
Extension", RFC 3308, DOI 10.17487/RFC3308, November 2002,
<https://www.rfc-editor.org/info/rfc3308>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
<https://www.rfc-editor.org/info/rfc5845>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A
Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059,
DOI 10.17487/RFC7059, November 2013,
<https://www.rfc-editor.org/info/rfc7059>.
[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>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using
Explicit Congestion Notification (ECN)", RFC 8087,
DOI 10.17487/RFC8087, March 2017,
<https://www.rfc-editor.org/info/rfc8087>.
[RFC8159] Konstantynowicz, M., Ed., Heron, G., Ed., Schatzmayr, R.,
and W. Henderickx, "Keyed IPv6 Tunnel", RFC 8159,
DOI 10.17487/RFC8159, May 2017,
<https://www.rfc-editor.org/info/rfc8159>.
[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>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[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>.
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
[SFC-NSH-ECN]
Eastlake 3rd, D., Briscoe, B., Zhuang, S., Malis, A., and
X. Wei, "Explicit Congestion Notification (ECN) and
Congestion Feedback Using the Network Service Header (NSH)
and IPFIX", Work in Progress, Internet-Draft, draft-ietf-
sfc-nsh-ecn-support-13, 15 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-
ecn-support-13>.
Thanks to Ing-jyh (Inton) Tsang for initial discussions on the need for ECN propagation in L2TP and its applicability. Thanks also to Carlos Pignataro, Tom Herbert, Ignacio Goyret, Alia Atlas, Praveen Balasubramanian, Joe Touch, Mohamed Boucadair, David Black, Jake Holland, Sri Gundavelli, Gorry Fairhurst, and Martin Duke for helpful advice and comments. [RFC7059] helped to identify a number of tunnelling protocols to include within the scope of this document.
L2TPでのECN伝播の必要性とその適用性に関する最初の議論について、Ing-Jyh（Inton）Tsangに感謝します。また、カルロス・ピグナタロ、トム・ハーバート、イグナシオ・ゴイレット、アリア・アトラス、プラヴェン・バラスブラマニアン、ジョー・タッチ、モハメド・ブーカデア、デビッド・ブラック、ジェイク・ホランド、スリ・ガンダヴェリ、ゴーリー・フェアハースト、そして有益なアドバイスとコメントをありがとう。[RFC7059]は、このドキュメントの範囲内に含まれる多くのトンネルプロトコルを特定するのに役立ちました。
Bob Briscoe was part-funded by the Research Council of Norway through the TimeIn project for early drafts, and he was funded by Apple Inc. for later draft versions (from -17). The views expressed here are solely those of the authors.
ボブ・ブリスコーは、ノルウェーの研究評議会によって初期のドラフトのためにタイミンプロジェクトを通じて一部資金提供され、後のドラフトバージョン（-17から）のためにApple Inc.から資金提供を受けました。ここで表明された見解は、著者の見解のみです。
Bob Briscoe
Independent
United Kingdom
Email: ietf@bobbriscoe.net
URI: https://bobbriscoe.net/