[要約] RFC 6040は、明示的な輻輳通知のトンネリングに関する標準化されたプロトコルです。その目的は、ネットワーク上での輻輳情報の効果的な伝達と処理を可能にすることです。
Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 6040 BT
Updates: 3168, 4301, 4774 November 2010
Category: Standards Track
ISSN: 2070-1721
Tunnelling of Explicit Congestion Notification
明示的な混雑通知のトンネル
Abstract
概要
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues.
このドキュメントでは、IPヘッダーの明示的な混雑通知（ECN）フィールドを、IP-in-IPトンネルへの出入り時にどのように構築するかを再定義します。カプセル化では、RFC 3168を更新して、すべてのIP-in-IPトンネル（V4またはV6）をRFC 4301 IPSEC ECN処理に沿ったものにします。脱カプセル化では、RFC 3168とRFC 4301の両方を更新して、以前に使用されていない内側ヘッダーと外側ヘッダーの組み合わせに新しい動作を追加します。新しい規則により、ECNフィールドが、1つまたは2つの重大度レベルの輻輳レベルを合図するために使用されるかどうかにかかわらず、トンネル全体に正しく伝播されることを保証します。以前は、1つの重大度レベルのみがサポートされていました。トンネルのエンドポイントは、ECNフィールドの既存の使用に影響を与えることなく、任意の順序で更新でき、したがって、後方互換性を確保できます。それにもかかわらず、2つの重大度レベルをサポートしたいオペレーター（たとえば、事前の通知の場合 - PCN）は、この新しい仕様のコンプライアンスを必要とすることができます。これらの変更とその意味の推論の徹底的な分析が含まれています。新しいルールが特定のニーズを満たしていない可能性が高い場合、RFC 4774は代替ECNセマンティクスの設計に関するガイダンスを提供し、このドキュメントはトンネリングの問題を含むように拡張されています。
Status of This Memo
本文書の位置付け
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 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6040.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6040で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Terminology .....................................................6
3. Summary of Pre-Existing RFCs ....................................7
3.1. Encapsulation at Tunnel Ingress ............................7
3.2. Decapsulation at Tunnel Egress .............................8
4. New ECN Tunnelling Rules ........................................9
4.1. Default Tunnel Ingress Behaviour ..........................10
4.2. Default Tunnel Egress Behaviour ...........................10
4.3. Encapsulation Modes .......................................12
4.4. Single Mode of Decapsulation ..............................14
5. Updates to Earlier RFCs ........................................15
5.1. Changes to RFC 4301 ECN Processing ........................15
5.2. Changes to RFC 3168 ECN Processing ........................16
5.3. Motivation for Changes ....................................17
5.3.1. Motivation for Changing Encapsulation ..............17
5.3.2. Motivation for Changing Decapsulation ..............18
6. Backward Compatibility .........................................21
6.1. Non-Issues Updating Decapsulation .........................21
6.2. Non-Update of RFC 4301 IPsec Encapsulation ................21
6.3. Update to RFC 3168 Encapsulation ..........................22
7. Design Principles for Alternate ECN Tunnelling Semantics .......22
8. Security Considerations ........................................24
9. Conclusions ....................................................26
10. Acknowledgements ..............................................26
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................27
Appendix A. Early ECN Tunnelling RFCs ............................29
Appendix B. Design Constraints ...................................29
B.1. Security Constraints ......................................29
B.2. Control Constraints .......................................31
B.3. Management Constraints ....................................32
Appendix C. Contribution to Congestion across a Tunnel ...........33
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer ................................................34
Appendix E. Open Issues ..........................................35
Explicit congestion notification (ECN [RFC3168]) allows a forwarding element (e.g., a router) to notify the onset of congestion without having to drop packets. Instead, it can explicitly mark a proportion of packets in the two-bit ECN field in the IP header (Table 1 recaps the ECN codepoints).
明示的な混雑通知（ECN [RFC3168]）により、転送要素（ルーターなど）は、パケットをドロップすることなく、輻輳の開始を通知することができます。代わりに、IPヘッダーの2ビットECNフィールドのパケットの一部を明示的にマークできます（表1はECNコードポイントを要約します）。
The outer header of an IP packet can encapsulate one or more IP headers for tunnelling. A forwarding element using ECN to signify congestion will only mark the immediately visible outer IP header. When a tunnel decapsulator later removes this outer header, it follows rules to propagate congestion markings by combining the ECN fields of the inner and outer IP header into one outgoing IP header.
IPパケットの外側ヘッダーは、トンネリング用の1つ以上のIPヘッダーをカプセル化できます。ECNを使用して輻輳を示す転送要素は、すぐに見える外側のIPヘッダーのみをマークします。トンネルの脱カプセレータが後でこの外側ヘッダーを削除すると、内側と外側のIPヘッダーのECNフィールドを1つの発信IPヘッダーに組み合わせることにより、混雑マーキングを伝播するルールに従います。
This document updates those rules for IPsec [RFC4301] and non-IPsec [RFC3168] tunnels to add new behaviours for previously unused combinations of inner and outer headers. It also updates the ingress behaviour of RFC 3168 tunnels to match that of RFC 4301 tunnels. Tunnel endpoints complying with the updated rules will be backward compatible when interworking with tunnel endpoints complying with RFC 4301, RFC 3168, or any earlier specification.
このドキュメントは、IPSEC [RFC4301]および非IPSEC [RFC3168]トンネルのこれらのルールを更新して、以前に使用されていない内側ヘッダーと外側のヘッダーの組み合わせに新しい動作を追加します。また、RFC 3168トンネルの侵入挙動を更新して、RFC 4301トンネルの動作と一致します。RFC 4301、RFC 3168、または以前の仕様に準拠したトンネルエンドポイントとの相互作用がある場合、更新されたルールに準拠したトンネルエンドポイントは、後方互換性があります。
When ECN and its tunnelling was defined in RFC 3168, only the minimum necessary changes to the ECN field were propagated through tunnel endpoints -- just enough for the basic ECN mechanism to work. This was due to concerns that the ECN field might be toggled to communicate between a secure site and someone on the public Internet -- a covert channel. This was because a mutable field like ECN cannot be protected by IPsec's integrity mechanisms -- it has to be able to change as it traverses the Internet.
ECNとそのトンネルがRFC 3168で定義された場合、ECNフィールドに必要な最小の変更のみがトンネルエンドポイントを介して伝播されました。これは、基本的なECNメカニズムが機能するのに十分です。これは、ECNフィールドが安全なサイトとパブリックインターネット上の誰かとの間を通信するために切り替えられる可能性があるという懸念によるものでした。これは、ECNのような可変フィールドをIPSECの整合性メカニズムによって保護できないためです。インターネットを横断するにつれて変更できる必要があります。
Nonetheless, the latest IPsec architecture [RFC4301] considered a bandwidth limit of two bits per packet on a covert channel to be a manageable risk. Therefore, for simplicity, an RFC 4301 ingress copied the whole ECN field to encapsulate a packet. RFC 4301 dispensed with the two modes of RFC 3168, one which partially copied the ECN field, and the other which blocked all propagation of ECN changes.
それにもかかわらず、最新のIPSECアーキテクチャ[RFC4301]は、カバーチャネル上のパケットあたり2ビットの帯域幅の制限を管理可能なリスクであると考えました。したがって、簡単にするために、RFC 4301 IngressがECNフィールド全体をコピーしてパケットをカプセル化しました。RFC 4301は、RFC 3168の2つのモードを分配しました。1つはECNフィールドを部分的にコピーし、もう1つはECN変化のすべての伝播をブロックしました。
Unfortunately, this entirely reasonable sequence of standards actions resulted in a perverse outcome; non-IPsec tunnels (RFC 3168) blocked the two-bit covert channel, while IPsec tunnels (RFC 4301) did not -- at least not at the ingress. At the egress, both IPsec and non-IPsec tunnels still partially restricted propagation of the full ECN field.
残念ながら、この完全に合理的な一連の標準アクションは、邪悪な結果をもたらしました。非IPSECトンネル（RFC 3168）は2ビットの秘密チャネルをブロックしましたが、IPSECトンネル（RFC 4301）は、少なくとも侵入ではそうではありませんでした。出口では、IPSECと非IPSECの両方のトンネルの両方が、完全なECNフィールドの伝播を部分的に制限しています。
The trigger for the changes in this document was the introduction of pre-congestion notification (PCN [RFC5670]) to the IETF Standards Track. PCN needs the ECN field to be copied at a tunnel ingress and it needs four states of congestion signalling to be propagated at the egress, but pre-existing tunnels only propagate three in the ECN field.
このドキュメントの変更のトリガーは、IETF標準トラックへの事前調理通知（PCN [RFC5670]）の導入でした。PCNは、トンネルの侵入でECNフィールドをコピーする必要があり、出口で伝播するためには4つの輻輳シグナル伝達が必要ですが、既存のトンネルはECNフィールドに3つのみを伝播します。
This document draws on currently unused (CU) combinations of inner and outer headers to add tunnelling of four-state congestion signalling to RFC 3168 and RFC 4301. Operators of tunnels who specifically want to support four states can require that all their tunnels comply with this specification. However, this is not a fork in the RFC series. It is an update that can be deployed first by those that need it, and subsequently by all tunnel endpoint implementations (RFC 4301, RFC 3168, RFC 2481, RFC 2401, RFC 2003), which can safely be updated to this new specification as part of general code maintenance. This will gradually add support for four congestion states to the Internet. Existing three state schemes will continue to work as before.
このドキュメントは、現在使用されていない（CU）内側ヘッダーと外側ヘッダーの組み合わせに基づいて、RFC 3168およびRFC4301に4状態の混雑シグナル伝達のトンネルを追加します。4つの州をサポートしたいトンネルの演算子は、すべてのトンネルがこれに準拠することを要求できます。仕様。ただし、これはRFCシリーズのフォークではありません。これは、最初にそれを必要とし、その後すべてのトンネルエンドポイントの実装（RFC 4301、RFC 3168、RFC 2481、RFC 2401、RFC 2003）によって展開できるアップデートであり、この新しい仕様は一部として安全に更新できます。一般的なコードメンテナンスの。これにより、4つの混雑状態のサポートがインターネットに徐々に追加されます。既存の3つの州のスキームは、以前と同じように引き続き機能します。
In fact, this document is the opposite of a fork. At the same time as supporting a fourth state, the opportunity has been taken to draw together divergent ECN tunnelling specifications into a single consistent behaviour, harmonising differences such as perverse covert channel treatment. Then, any tunnel can be deployed unilaterally, and it will support the full range of congestion control and management schemes without any modes or configuration. Further, any host or router can expect the ECN field to behave in the same way, whatever type of tunnel might intervene in the path.
実際、このドキュメントはフォークの反対です。4番目の州をサポートすると同時に、Divergent ECN Tunneling仕様を単一の一貫した動作に引き付け、邪悪な秘密のチャネル治療などの違いを調和させる機会が得られました。次に、任意のトンネルを一方的に展開でき、モードや構成なしで渋滞制御スキームと管理スキームの全範囲をサポートします。さらに、ホストまたはルーターは、ECNフィールドが同じ方法で動作することを期待できます。
This document only concerns wire protocol processing of the ECN field at tunnel endpoints and makes no changes or recommendations concerning algorithms for congestion marking or congestion response.
このドキュメントは、トンネルエンドポイントでのECNフィールドのワイヤープロトコル処理のみに関係しており、輻輳マーキングまたは輻輳応答のアルゴリズムに関する変更や推奨事項はありません。
This document specifies common 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. It applies for packets with any destination address type, whether unicast or multicast. It applies as the default for all Diffserv per-hop behaviours (PHBs), unless stated otherwise in the specification of a PHB (but Section 4 strongly deprecates such exceptions). It is intended to be a good trade off between somewhat conflicting security, control, and management requirements.
このドキュメントは、IPSECトンネルであろうと非IPSECトンネルであろうと、IP-in-IPトンネルのカプセル化と脱カプセル化時の一般的なECNフィールド処理を指定します。IPv4またはIPv6が内側ヘッダーまたは外側のヘッダーに使用されるかどうかに関係なく適用されます。ユニキャストであろうとマルチキャストであろうと、任意の宛先アドレスタイプのパケットに適用されます。PHBの仕様に特に明記されていない限り、すべてのDiffserv Per Hop動作（PHB）のデフォルトとして適用されます（ただし、セクション4はそのような例外を強く非難します）。これは、やや矛盾するセキュリティ、制御、および管理要件の間の優れたトレードオフになることを目的としています。
[RFC2983] is a comprehensive primer on differentiated services and tunnels. Given ECN raises similar issues to differentiated services when interacting with tunnels, useful concepts introduced in RFC 2983 are used throughout, with brief recaps of the explanations where necessary.
[RFC2983]は、差別化されたサービスとトンネルの包括的な入門書です。ECNは、トンネルと相互作用する際に差別化されたサービスと同様の問題を提起することを考えると、RFC 2983で導入された有用な概念が全体を通して使用され、必要に応じて説明を簡単に要約します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Table 1 recaps the names of the ECN codepoints [RFC3168].
表1は、ECNコードポイント[RFC3168]の名前をまとめます。
+------------------+----------------+---------------------------+
| Binary codepoint | Codepoint name | Meaning |
+------------------+----------------+---------------------------+
| 00 | Not-ECT | Not ECN-capable transport |
| 01 | ECT(1) | ECN-capable transport |
| 10 | ECT(0) | ECN-capable transport |
| 11 | CE | Congestion experienced |
+------------------+----------------+---------------------------+
Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP Header
表1：IPヘッダーのECNフィールド[RFC3168]のコードポイントの要約
Further terminology used within this document:
このドキュメント内で使用されるさらなる用語：
Encapsulator: The tunnel endpoint function that adds an outer IP header to tunnel a packet (also termed the 'ingress tunnel endpoint' or just the 'ingress' where the context is clear).
カプセレータ：外側のIPヘッダーを追加してパケットをトンネルにするトンネルエンドポイント関数（「イングレストンネルエンドポイント」またはコンテキストがクリアされている「イングレス」とも呼ばれます）。
Decapsulator: The tunnel endpoint function that removes an outer IP header from a tunnelled packet (also termed the 'egress tunnel endpoint' or just the 'egress' where the context is clear).
脱カプセレーター：トンネルパケットから外側のIPヘッダーを削除するトンネルエンドポイント関数（「出口トンネルエンドポイント」またはコンテキストが明確な「出口」とも呼ばれます）。
Incoming header: The header of an arriving packet before encapsulation.
着信ヘッダー：カプセル化前の到着パケットのヘッダー。
Outer header: The header added to encapsulate a tunnelled packet.
外側のヘッダー：トンネルパケットをカプセル化するために追加されたヘッダー。
Inner header: The header encapsulated by the outer header.
内側ヘッダー：外側ヘッダーによってカプセル化されたヘッダー。
Outgoing header: The header constructed by the decapsulator using logic that combines the fields in the outer and inner headers.
発信ヘッダー：外側と内側のヘッダーのフィールドを組み合わせたロジックを使用して、脱カプセレーターによって構築されたヘッダー。
Copying ECN: On encapsulation, setting the ECN field of the new outer header to be a copy of the ECN field in the incoming header.
ECNのコピー：カプセル化時に、新しい外側ヘッダーのECNフィールドを、着信ヘッダーのECNフィールドのコピーに設定します。
Zeroing ECN: On encapsulation, clearing the ECN field of the new outer header to Not-ECT ("00").
ECNのゼロ：カプセル化時に、新しい外側ヘッダーのECNフィールドを非ect（ "00"）にクリアします。
Resetting ECN: On encapsulation, setting the ECN field of the new outer header to be a copy of the ECN field in the incoming header except the outer ECN field is set to the ECT(0) codepoint if the incoming ECN field is CE.
ECNのリセット：カプセル化時に、新しい外側ヘッダーのECNフィールドを、着信ECNフィールドを除く、着信ヘッダーのECNフィールドのコピーに設定します。
This section is informative not normative, as it recaps pre-existing RFCs. Earlier relevant RFCs that were either Experimental or incomplete with respect to ECN tunnelling (RFC 2481, RFC 2401, and RFC 2003) are briefly outlined in Appendix A. The question of whether tunnel implementations used in the Internet comply with any of these RFCs is not discussed.
このセクションは、既存のRFCを要約するため、規範的ではありません。ECNトンネル（RFC 2481、RFC 2401、およびRFC 2003）に関して実験的または不完全な以前の関連RFCは、付録Aに簡単に概説されています。議論した。
At the encapsulator, the controversy has been over whether to propagate information about congestion experienced on the path so far into the outer header of the tunnel.
カプセレータでは、これまでの道で経験した混雑に関する情報をトンネルの外側のヘッダーに向けて繁殖させるかどうかは、論争が終わっています。
Specifically, RFC 3168 says that, if a tunnel fully supports ECN (termed a 'full-functionality' ECN tunnel in [RFC3168]), the encapsulator must not copy a CE marking from the incoming header into the outer header that it creates. Instead, the encapsulator must set the outer header to ECT(0) if the ECN field is marked CE in the arriving IP header. We term this 'resetting' a CE codepoint.
具体的には、RFC 3168は、トンネルがECN（[RFC3168]の「フル機能」ECNトンネルと呼ばれる）を完全にサポートしている場合、エンコープカプセレータは、発生するヘッダーからCEマークをコピーして、それが作成する外側のヘッダーにコピーしてはならないと述べています。代わりに、ECNフィールドが到着IPヘッダーでCEとマークされている場合、エンコプセーターは外側ヘッダーをECT（0）に設定する必要があります。これをCEコードポイントと呼んでいます。
However, the new IPsec architecture in [RFC4301] reverses this rule, stating that the encapsulator must simply copy the ECN field from the incoming header to the outer header.
ただし、[RFC4301]の新しいIPSECアーキテクチャは、このルールを逆転させ、エンカプサーがECNフィールドを着信ヘッダーから外側ヘッダーに単純にコピーする必要があると述べています。
RFC 3168 also provided a Limited Functionality mode that turns off ECN processing over the scope of the tunnel by setting the outer header to Not-ECT ("00"). Then, such packets will be dropped to indicate congestion, rather than marked with ECN. This is necessary for the ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401], and [RFC2003]) that do not propagate ECN markings added to the outer header. Otherwise, such legacy decapsulators would throw away congestion notifications before they reached the transport layer.
RFC 3168は、外側ヘッダーをnot-ect（ "00"）に設定することにより、トンネルの範囲でECN処理をオフにする制限された機能モードも提供しました。その後、そのようなパケットは、ECNでマークされるのではなく、混雑を示すためにドロップされます。これは、外部ヘッダーに追加されたECNマーキングを伝播しないレガシー脱カプセル因子（[RFC2481]、[RFC2401]、[RFC2401]、[RFC2401]）とインターワークするために必要です。それ以外の場合、そのようなレガシーの脱カプセルターは、輸送層に到達する前に混雑通知を捨てるでしょう。
Neither Limited Functionality mode nor Full Functionality mode are used by an RFC 4301 IPsec encapsulator, which simply copies the incoming ECN field into the outer header. An earlier key-exchange phase ensures an RFC 4301 ingress will not have to interwork with a legacy egress that does not support ECN.
制限された機能モードもフル機能モードも、RFC 4301 IPSECエンカプセレータによって使用されません。これは、着信ECNフィールドを外部ヘッダーにコピーするだけです。以前のキー交換フェーズにより、RFC 4301イングレスは、ECNをサポートしないレガシー出力とインターワークする必要はありません。
These pre-existing behaviours are summarised in Figure 1.
これらの既存の動作を図1にまとめます。
+-----------------+-----------------------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+---------------+
| departing Inner | RFC 3168 ECN | RFC 3168 ECN | RFC 4301 IPsec|
| Header) | Limited | Full | |
| | Functionality | Functionality | |
+-----------------+---------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) | ECT(1) |
| CE | Not-ECT | ECT(0) | CE |
+-----------------+---------------+---------------+---------------+
Figure 1: IP-in-IP Encapsulation: Recap of Pre-Existing Behaviours
図1：IP-in-IPカプセル化：既存の行動の要約
RFC 3168 and RFC 4301 specify the decapsulation behaviour summarised in Figure 2. The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column).
RFC 3168およびRFC 4301は、図2に要約されている脱カプセル化の動作を指定します。発信ヘッダーのECNフィールドは、適切な到着内ヘッダー（行）と到着する外側ヘッダー（列）の交差点でコードポイントに設定されています。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
RFC 3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
RFC 4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
| ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
| CE | CE | CE | CE | CE |
+---------+---------+------------+------------+------------+
In pre-existing RFCs, the ECN field in the outgoing header was set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet was dropped where indicated.
既存のRFCSでは、発信ヘッダーのECNフィールドは、適切な到着内ヘッダー（行）と到着外側ヘッダー（列）の交差点でコードポイントに設定され、示されている場合はパケットがドロップされました。
Figure 2: IP in IP Decapsulation; Recap of Pre-Existing Behaviour
図2：IP脱カプセル化のIP。既存の行動の要約
The behaviour in the table derives from the logic given in RFC 3168 and RFC 4301, briefly recapped as follows:
表の動作は、RFC 3168およびRFC 4301で与えられたロジックに由来し、次のように一時的に再刻まれました。
o On decapsulation, if the inner ECN field is Not-ECT the outer is ignored. RFC 3168 (but not RFC 4301) also specified that the decapsulator must drop a packet with a Not-ECT inner and CE in the outer.
o 脱カプセル化では、内側のECNフィールドがそれでない場合、外側は無視されます。RFC 3168（ただし、RFC 4301ではありません）は、脱カプセレータが外側の内側とCEを持つパケットをドロップする必要があることも指定しました。
o In all other cases, if the outer is CE, the outgoing ECN field is set to CE; otherwise, the outer is ignored and the inner is used for the outgoing ECN field.
o 他のすべての場合、外側がCEの場合、発信ECNフィールドはCEに設定されます。それ以外の場合、外側は無視され、内側は発信ECNフィールドに使用されます。
Section 9.2.2 of RFC 3168 also made it an auditable event for an IPsec tunnel "if the ECN Field is changed inappropriately within an IPsec tunnel...". Inappropriate changes were not specifically enumerated. RFC 4301 did not mention inappropriate ECN changes.
RFC 3168のセクション9.2.2は、「ECNフィールドがIPSECトンネル内で不適切に変更された場合...」IPSECトンネルの監査可能なイベントにもなりました。不適切な変化は特に列挙されていませんでした。RFC 4301は、不適切なECNの変更について言及していませんでした。
The standards actions below in Section 4.1 (ingress encapsulation) and Section 4.2 (egress decapsulation) define new default ECN tunnel processing rules for any IP packet (v4 or v6) with any Diffserv codepoint.
セクション4.1（イングレスカプセル化）およびセクション4.2（Egress Decapsulation）の以下の標準アクションは、DiffServ CodePointを使用して、任意のIPパケット（V4またはV6）の新しいデフォルトECNトンネル処理ルールを定義します。
If these defaults do not meet a particular requirement, an alternate ECN tunnelling scheme can be introduced as part of the definition of an alternate congestion marking scheme used by a specific Diffserv PHB (see [RFC4774] and Section 5 of [RFC3168]). When designing such alternate ECN tunnelling schemes, the principles in Section 7 should be followed. However, alternate ECN tunnelling schemes SHOULD be avoided whenever possible as the deployment burden of handling exceptional PHBs in implementations of all affected tunnels should not be underestimated. There is no requirement for a PHB definition to state anything about ECN tunnelling behaviour if the default behaviour in the present specification is sufficient.
これらのデフォルトが特定の要件を満たしていない場合、特定のdiffserv PHBで使用される代替輻輳マーキングスキームの定義の一部として、代替ECNトンネルスキームを導入できます（[RFC4774]および[RFC3168]のセクション5を参照）。このような代替ECNトンネルスキームを設計する場合、セクション7の原則に従う必要があります。ただし、影響を受けるすべてのトンネルの実装における例外的なPHBを処理する展開の負担は過小評価されるべきではないため、可能な限り代替ECNトンネルスキームを避ける必要があります。現在の仕様のデフォルトの動作で十分である場合、PHB定義がECNトンネルの動作について何かを述べるための要件はありません。
Two modes of encapsulation are defined here; a REQUIRED 'normal mode' and a 'compatibility mode', which is for backward compatibility with tunnel decapsulators that do not understand ECN. Note that these are modes of the ingress tunnel endpoint only, not the whole tunnel. Section 4.3 explains why two modes are necessary and specifies the circumstances in which it is sufficient to solely implement normal mode.
ここでは、2つのカプセル化モードが定義されています。必要な「通常モード」と「互換性モード」は、ECNを理解していないトンネルの脱カプセル因子との後方互換性のためです。これらは、トンネル全体ではなく、イングレストンネルエンドポイントのみのモードであることに注意してください。セクション4.3では、2つのモードが必要な理由を説明し、通常モードのみを実装するのに十分な状況を指定します。
Whatever the mode, an encapsulator forwards the inner header without changing the ECN field.
モードが何であれ、ECNフィールドを変更せずに、エンカプセーターが内側のヘッダーを転送します。
In normal mode, an encapsulator compliant with this specification MUST construct the outer encapsulating IP header by copying the two-bit ECN field of the incoming IP header. In compatibility mode, it clears the ECN field in the outer header to the Not-ECT codepoint (the IPv4 header checksum also changes whenever the ECN field is changed). These rules are tabulated for convenience in Figure 3.
通常モードでは、この仕様に準拠しているエンコペーターは、着信IPヘッダーの2ビットECNフィールドをコピーすることにより、外側のカプセル化IPヘッダーを構築する必要があります。互換性モードでは、外側ヘッダーのECNフィールドを非ectコードポイントにクリアします（ECNフィールドが変更されるたびにIPv4ヘッダーチェックサムも変更されます）。これらのルールは、図3に便利なために集計されています。
+-----------------+-------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+
| departing Inner | Compatibility | Normal |
| Header) | Mode | Mode |
+-----------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE |
+-----------------+---------------+---------------+
Figure 3: New IP in IP Encapsulation Behaviours
図3：IPカプセル化動作における新しいIP
To decapsulate the inner header at the tunnel egress, a compliant tunnel egress MUST set the outgoing ECN field to the codepoint at the intersection of the appropriate arriving inner header (row) and outer header (column) in Figure 4 (the IPv4 header checksum also changes whenever the ECN field is changed). There is no need for more than one mode of decapsulation, as these rules cater for all known requirements.
トンネル出口で内側のヘッダーを脱カプセル化するには、準拠したトンネル出力では、図4の適切な到着内ヘッダー（行）と外側ヘッダー（列）の交差点で、発信ECNフィールドをコードポイントに設定する必要があります（IPv4ヘッダーチェックサムもECNフィールドが変更されるたびに変更されます）。これらのルールはすべての既知の要件に対応するため、複数の脱カプセル化モードは必要ありません。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet is dropped where indicated. Currently unused combinations are indicated by '(!!!)' or '(!)'
発信ヘッダーのECNフィールドは、適切な到着内ヘッダー（行）と到着外側ヘッダー（列）の交差点でコードポイントに設定されているか、示されている場合はパケットがドロップされます。現在、未使用の組み合わせは「（!!!）」または「（！）」で示されています
Figure 4: New IP in IP Decapsulation Behaviour
図4：IPカプセル化動作における新しいIP
This table for decapsulation behaviour is derived from the following logic:
脱カプセル化行動のこの表は、次のロジックから導き出されます。
o If the inner ECN field is Not-ECT, the decapsulator MUST NOT propagate any other ECN codepoint onwards. This is because the inner Not-ECT marking is set by transports that rely on dropped packets as an indication of congestion and would not understand or respond to any other ECN codepoint [RFC4774]. Specifically:
o 内側のECNフィールドがそれでない場合、脱カプセーターは他のECNコードポイントを以降に伝播してはなりません。これは、内側の非接続マーキングが、渋滞の兆候として落とされたパケットに依存しているトランスポートによって設定され、他のECNコードポイント[RFC4774]を理解または応答しないためです。具体的には：
* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
* 内側のECNフィールドが効果がなく、外側ECNフィールドがCEの場合、脱カプセレータはパケットをドロップする必要があります。
* If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT.
* 内側のECNフィールドが効果的ではなく、外側のECNフィールドが非ect、ECT（0）、またはECT（1）である場合、脱カプセレータは、ECNフィールドをクリアしていないECNフィールドで発信パケットを転送する必要があります。
o In all other cases where the inner supports ECN, the decapsulator MUST set the outgoing ECN field to the more severe marking of the outer and inner ECN fields, where the ranking of severity from highest to lowest is CE, ECT(1), ECT(0), Not-ECT. This in no way precludes cases where ECT(1) and ECT(0) have the same severity;
o 内側がECNをサポートする他のすべてのケースでは、脱カプセレーターが外側のECNフィールドを外側および内側のECNフィールドのより深刻なマーキングに設定する必要があります。0）、not-ect。これは、ECT（1）とECT（0）が同じ重症度を持っている場合を除いていません。
o Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous. In these cases, particularly the more dangerous ones, the decapsulator SHOULD log the event and MAY also raise an alarm.
o 内側と外側のECNフィールドの特定の組み合わせは、電流または以前のECNトンネル仕様の遷移から生じることはできません。これらの現在使用されていない（Cu）組み合わせは、図4に「!!!）」または「（！）」に示されています。'Cuであり、おそらく危険なことを意味します。これらの場合、特に危険な場合は、脱カプセレータがイベントを記録し、アラームを上げる可能性もあります。
Just because the highlighted combinations are currently unused, does not mean that all the other combinations are always valid. Some are only valid if they have arrived from a particular type of legacy ingress, and dangerous otherwise. Therefore, an implementation MAY allow an operator to configure logging and alarms for such additional header combinations known to be dangerous or CU for the particular configuration of tunnel endpoints deployed at run-time.
強調表示されている組み合わせが現在使用されていないからといって、他のすべての組み合わせが常に有効であるという意味ではありません。特定のタイプのレガシーイングレスから到着した場合にのみ有効なものもあれば、それ以外の場合は危険です。したがって、実装により、オペレーターは、実行時に展開されたトンネルエンドポイントの特定の構成に対して危険であると知られているこのような追加のヘッダー組み合わせのロギングとアラームを構成できる場合があります。
Alarms SHOULD be rate-limited so that the anomalous combinations will not amplify into a flood of alarm messages. It MUST be possible to suppress alarms or logging, e.g., if it becomes apparent that a combination that previously was not used has started to be used for legitimate purposes such as a new standards action.
アラームは、異常な組み合わせがアラームメッセージの洪水に増幅されないように、レート制限する必要があります。アラームやロギングを抑制することは可能である必要があります。たとえば、以前に使用されていなかった組み合わせが、新しい標準アクションなどの正当な目的に使用され始めたことが明らかになった場合です。
The above logic allows for ECT(0) and ECT(1) to both represent the same severity of congestion marking (e.g., "not congestion marked"). But it also allows future schemes to be defined where ECT(1) is a more severe marking than ECT(0), in particular, enabling the simplest possible encoding for PCN [PCN3in1] (see Section 5.3.2). Treating ECT(1) as either the same as ECT(0) or as a higher severity level is explained in the discussion of the ECN nonce [RFC3540] in Section 8, which in turn refers to Appendix D.
上記のロジックにより、ECT（0）とECT（1）はどちらも同じ輻輳マーキングの重大度を表すことができます（たとえば、「輻輳はマークされていない」）。ただし、ECT（1）がECT（0）よりも深刻なマーキングである場合、特にPCN [PCN3IN1]の可能な限り単純なエンコードを可能にする場合、将来のスキームを定義することもできます（セクション5.3.2を参照）。ECT（1）をECT（0）と同じまたはより高い重大度レベルとして扱うことを、セクション8のECN NonCE [RFC3540]の議論で説明します。これは、付録Dを参照します。
Section 4.1 introduces two encapsulation modes: normal mode, and compatibility mode, defining their encapsulation behaviour (i.e., header copying or zeroing, respectively). Note that these are modes of the ingress tunnel endpoint only, not the tunnel as a whole.
セクション4.1では、カプセル化動作を定義する（つまり、ヘッダーコピーまたはゼロ）の2つのカプセル化モードと互換性モードの2つのカプセル化モードを紹介します。これらは、イングレストンネルエンドポイントのみのモードであり、全体としてトンネルではないことに注意してください。
To comply with this specification, a tunnel ingress MUST at least implement normal mode. Unless it will never be used with legacy tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the limited functionality mode of RFC 3168), an ingress MUST also implement compatibility mode for backward compatibility with tunnel egresses that do not propagate explicit congestion notifications [RFC4774].
この仕様に準拠するには、トンネルの侵入は少なくとも通常モードを実装する必要があります。レガシートンネル出口ノード（RFC 2003、RFC 2401、またはRFC 2481またはRFC 3168の限定機能モード）で使用されない限り、侵入は、明示的な補償を伝播しないトンネル出力との逆方向の互換性モードを実装する必要があります。通知[RFC4774]。
We can categorise the way that an ingress tunnel endpoint is paired with an egress as either static or dynamically discovered: Static: Tunnel endpoints paired together by prior configuration.
静的または動的に発見されたものとして、イングレストンネルのエンドポイントが出口とペアリングされる方法を分類できます。
Some implementations of encapsulator might always be statically deployed, and constrained to never be paired with a legacy decapsulator (RFC 2003, RFC 2401 or RFC 2481 or the limited functionality mode of RFC 3168). In such a case, only normal mode needs to be implemented.
Encapsuratorのいくつかの実装は常に静的に展開され、レガシー脱カプセレーターとペアリングされないように制約されている可能性があります（RFC 2003、RFC 2401またはRFC 2481またはRFC 3168の限定機能モード）。そのような場合、通常モードのみを実装する必要があります。
For instance, IPsec tunnel endpoints compatible with RFC 4301 invariably use Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] for key exchange, the original specification of which was introduced alongside RFC 4301. Therefore, both endpoints of an RFC 4301 tunnel can be sure that the other end is compatible with RFC 4301, because the tunnel is only formed after IKEv2 key management has completed, at which point both ends will be compliant with RFC 4301 by definition. Therefore an IPsec tunnel ingress does not need compatibility mode, as it will never interact with legacy ECN tunnels. To comply with the present specification, it only needs to implement the required normal mode, which is identical to the pre-existing RFC 4301 behaviour.
たとえば、RFC 4301と互換性のあるIPSECトンネルエンドポイントは、常にインターネットキーエクスチェンジプロトコル2（IKEV2）[RFC5996]を使用してキーエクスチェンジに使用します。トンネルはIKEV2キー管理が完了した後にのみ形成されるため、もう一方の端がRFC 4301と互換性があることを確認します。したがって、IPSECトンネルイングレスは、レガシーECNトンネルとは決して相互作用しないため、互換性モードを必要としません。現在の仕様に準拠するには、既存のRFC 4301動作と同一の必要な正常モードを実装する必要があります。
Dynamic Discovery: Tunnel endpoints paired together by some form of tunnel endpoint discovery, typically finding an egress on the path taken by the first packet.
動的発見：トンネルのエンドポイントは、何らかの形のトンネルエンドポイントの発見によって組み合わされており、通常、最初のパケットがとったパスで出口を見つけます。
This specification does not require or recommend dynamic discovery and it does not define how dynamic negotiation might be done, but it recognises that proprietary tunnel endpoint discovery protocols exist. It therefore sets down some constraints on discovery protocols to ensure safe interworking.
この仕様では、動的な発見を必要とせず、推奨するものではなく、動的な交渉がどのように行われるかを定義しませんが、独自のトンネルエンドポイントディスカバリープロトコルが存在することを認識しています。したがって、安全なインターワーキングを確保するために、発見プロトコルのいくつかの制約を設定します。
If dynamic tunnel endpoint discovery might pair an ingress with a legacy egress (RFC 2003, RFC 2401, or RFC 2481 or the limited functionality mode of RFC 3168), the ingress MUST implement both normal and compatibility mode. If the tunnel discovery process is arranged to only ever find a tunnel egress that propagates ECN (RFC 3168 full functionality mode, RFC 4301, or this present specification), then a tunnel ingress can be compliant with the present specification without implementing compatibility mode.
動的トンネルエンドポイントの発見が、侵入をレガシーエッセイレスと組み合わせる可能性がある場合（RFC 2003、RFC 2401、またはRFC 2481またはRFC 3168の限定機能モード）、侵入は通常と互換性モードの両方を実装する必要があります。トンネルの発見プロセスが、ECN（RFC 3168フル機能モード、RFC 4301、またはこの現在の仕様）を伝播するトンネル出口のみを見つけるように配置されている場合、トンネルの侵入は、互換性モードを実装せずに現在の仕様に準拠できます。
While a compliant tunnel ingress is discovering an egress, it MUST send packets in compatibility mode in case the egress it discovers is a legacy egress. If, through the discovery protocol, the egress indicates that it is compliant with the present specification, with RFC 4301 or with RFC 3168 full functionality mode, the ingress can switch itself into normal mode. If the egress denies compliance with any of these or returns an error that implies it does not understand a request to work to any of these ECN specifications, the tunnel ingress MUST remain in compatibility mode.
準拠したトンネルイングレスは出口を発見していますが、発見した出力がレガシーの出口である場合に備えて、互換性モードでパケットを送信する必要があります。ディスカバリープロトコルを介して、出力が現在の仕様に準拠していることを示している場合、RFC 4301またはRFC 3168フル機能モードには、イングレスはそれ自体を正常モードに切り替えることができます。出力がこれらのいずれかのいずれかのコンプライアンスを拒否したり、これらのECN仕様のいずれかの作業を要求を理解していないことを意味するエラーを返す場合、トンネルの侵入は互換性モードのままでなければなりません。
If an ingress claims compliance with this specification, it MUST NOT permanently disable ECN processing across the tunnel (i.e., only using compatibility mode). It is true that such a tunnel ingress is at least safe with the ECN behaviour of any egress it may encounter, but it does not meet the central aim of this specification: introducing ECN support to tunnels.
イングレスがこの仕様に準拠している場合、トンネル全体でECN処理を永久に無効にしてはなりません（つまり、互換性モードのみを使用してください）。このようなトンネルの侵入は、遭遇する可能性のあるECNの挙動で少なくとも安全であることは事実ですが、この仕様の中心的な目的を満たしていません。トンネルにECNサポートを導入します。
Instead, if the ingress knows that the egress does support propagation of ECN (full functionality mode of RFC 3168 or RFC 4301 or the present specification), it SHOULD use normal mode, in order to support ECN where possible. Note that this section started by saying an ingress "MUST implement" normal mode, while it has just said an ingress "SHOULD use" normal mode. This distinction is deliberate, to allow the mode to be turned off in exceptional circumstances but to ensure all implementations make normal mode available.
代わりに、出口がECNの伝播をサポートしていることを知っている場合（RFC 3168またはRFC 4301または現在の仕様の完全な機能モード）、可能な限りECNをサポートするために通常モードを使用する必要があります。このセクションは、イングレスが通常モードを「実装する必要がある」と言って始まったことに注意してください。一方、侵入は「通常モード」を「使用する必要がある」と言っています。この区別は意図的であり、例外的な状況でモードをオフにすることを可能にしますが、すべての実装が通常モードを利用できるようにします。
Implementation note: If a compliant node is the ingress for multiple tunnels, a mode setting will need to be stored for each tunnel ingress. However, if a node is the egress for multiple tunnels, none of the tunnels will need to store a mode setting, because a compliant egress only needs one mode.
実装注：準拠ノードが複数のトンネルの侵入である場合、各トンネルイングレスにモード設定を保存する必要があります。ただし、ノードが複数のトンネルの出力である場合、準拠した出口には1つのモードのみが必要なため、トンネルはモード設定を保存する必要はありません。
A compliant decapsulator only needs one mode of operation. However, if a compliant egress is implemented to be dynamically discoverable, it may need to respond to discovery requests from various types of legacy tunnel ingress. This specification does not define how dynamic negotiation might be done by (proprietary) discovery protocols, but it sets down some constraints to ensure safe interworking.
準拠した脱カプセレータには、1つの操作モードのみが必要です。ただし、動的に発見できるように準拠した出口が実装されている場合、さまざまな種類のレガシートンネルイングレスからの発見要求に応答する必要がある場合があります。この仕様は、（独自の）ディスカバリープロトコルによって動的な交渉がどのように行われるかを定義するものではなく、安全なインターワーキングを確保するためのいくつかの制約を設定します。
Through the discovery protocol, a tunnel ingress compliant with the present specification might ask if the egress is compliant with the present specification, with RFC 4301 or with RFC 3168 full functionality mode. Or an RFC 3168 tunnel ingress might try to negotiate to use limited functionality or full functionality mode [RFC3168]. In all these cases, a decapsulating tunnel egress compliant with this specification MUST agree to any of these requests, since it will behave identically in all these cases.
Discovery Protocolを通じて、現在の仕様に準拠したトンネルイングレスは、出力が現在の仕様に準拠しているかどうかを尋ねる場合があります。RFC4301またはRFC 3168フル機能モード。または、RFC 3168トンネルイングレスは、限られた機能または完全な機能モードを使用するためにネゴシエートしようとする場合があります[RFC3168]。これらすべての場合において、この仕様に準拠した脱カプセンシングトンネル出力は、これらすべてのケースで同じように動作するため、これらの要求のいずれかに同意する必要があります。
If no ECN-related mode is requested, a compliant tunnel egress MUST continue without raising any error or warning, because its egress behaviour is compatible with all the legacy ingress behaviours that do not negotiate capabilities.
ECN関連のモードが要求されない場合、能力を交渉しないすべてのレガシーイングレス動作とその出口動作が互換性があるため、エラーや警告を発生させることなく、準拠したトンネル出力が継続する必要があります。
A compliant tunnel egress SHOULD raise a warning alarm about any requests to enter modes it does not recognise but, for 'forward compatibility' with standards actions possibly defined after it was implemented, it SHOULD continue operating.
準拠したトンネルの出口は、認識されないモードを入力するリクエストについて警告アラームを上げる必要がありますが、実装後に定義される可能性のある標準アクションを備えた「フォワード互換性」の場合、操作を継続する必要があります。
Ingress: An RFC 4301 IPsec encapsulator is not changed at all by the present specification. It uses the normal mode of the present specification, which defines packet encapsulation identically to RFC 4301.
Ingress：RFC 4301 IPSEC Encapsuratorは、現在の仕様ではまったく変更されていません。現在の仕様の通常モードを使用します。これは、RFC 4301と同じようにパケットカプセル化を定義します。
Egress: An RFC 4301 egress will need to be updated to the new decapsulation behaviour in Figure 4, in order to comply with the present specification. However, the changes are backward compatible; combinations of inner and outer that result from any protocol defined in the RFC series so far are unaffected. Only combinations that have never been used have been changed, effectively adding new behaviours to RFC 4301 decapsulation without altering existing behaviours. The following specific updates to Section 5.1.2 of RFC 4301 have been made:
出力：現在の仕様に準拠するために、図4の新しい脱カプセル化動作にRFC 4301出力を更新する必要があります。ただし、変更は後方互換性があります。これまでにRFCシリーズで定義されているプロトコルから生じる内側と外側の組み合わせは影響を受けません。使用されたことのない組み合わせのみが変更され、既存の動作を変更せずにRFC 4301脱カプセル化に新しい動作を効果的に追加しました。RFC 4301のセクション5.1.2の次の具体的な更新が行われました。
* The outer, not the inner, is propagated when the outer is ECT(1) and the inner is ECT(0);
* 外側ではなく、外側は外側がect（1）であり、内側がect（0）である場合に伝播されます。
* A packet with Not-ECT in the inner and an outer of CE is dropped rather than forwarded as Not-ECT;
* 内側に非ectとCEの外側のパケットは、非ectとして転送されるのではなく、ドロップされます。
* Certain combinations of inner and outer ECN field have been identified as currently unused. These can trigger logging and/or raise alarms.
* 内側と外側のECNフィールドの特定の組み合わせは、現在使用されていないと特定されています。これらは、ロギングをトリガーしたり、アラームを上げることができます。
Modes: RFC 4301 tunnel endpoints do not need modes and are not updated by the modes in the present specification. Effectively, an RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of encapsulation, which is unchanged from RFC 4301 encapsulation. It will never need the OPTIONAL compatibility mode as explained in Section 4.3.
モード：RFC 4301トンネルエンドポイントはモードを必要とせず、現在の仕様のモードによって更新されません。事実上、RFC 4301 IPSEC Ingressは、RFC 4301カプセル化から変化しない、必要な正常なカプセル化モードのみを使用します。セクション4.3で説明されているように、オプションの互換性モードは決して必要ありません。
Ingress: On encapsulation, the new rule in Figure 3 that a normal mode tunnel ingress copies any ECN field into the outer header updates the full functionality behaviour of an RFC 3168 ingress (Section 9.1.1 of [RFC3168]). Nonetheless, the new compatibility mode encapsulates packets identically to the limited functionality mode of an RFC 3168 ingress.
Ingress：カプセル化については、図3の新しいルールでは、通常モードのトンネルが外部ヘッダーにECNフィールドをコピーするという新しいルールは、RFC 3168イングレスの完全な機能動作を更新します（[RFC3168]のセクション9.1.1）。それにもかかわらず、新しい互換性モードは、RFC 3168イングレスの限られた機能モードと同じようにパケットをカプセル化します。
Egress: An RFC 3168 egress will need to be updated to the new decapsulation behaviour in Figure 4, in order to comply with the present specification. However, the changes are backward compatible; combinations of inner and outer that result from any protocol defined in the RFC series so far are unaffected. Only combinations that have never been used have been changed, effectively adding new behaviours to RFC 3168 decapsulation without altering existing behaviours. The following specific updates to Section 9.1.1 of RFC 3168 have been made:
出力：現在の仕様に準拠するために、図4の新しい脱カプセル化動作にRFC 3168の出口を更新する必要があります。ただし、変更は後方互換性があります。これまでにRFCシリーズで定義されているプロトコルから生じる内側と外側の組み合わせは影響を受けません。使用されたことのない組み合わせのみが変更され、既存の動作を変更せずにRFC 3168脱カプセル化に新しい動作を効果的に追加しました。RFC 3168のセクション9.1.1の次の具体的な更新が行われました。
* The outer, not the inner, is propagated when the outer is ECT(1) and the inner is ECT(0);
* 外側ではなく、外側は外側がect（1）であり、内側がect（0）である場合に伝播されます。
* Certain combinations of inner and outer ECN field have been identified as currently unused. These can trigger logging and/or raise alarms.
* 内側と外側のECNフィールドの特定の組み合わせは、現在使用されていないと特定されています。これらは、ロギングをトリガーしたり、アラームを上げることができます。
Modes: An RFC 3168 ingress will need to be updated if it is to comply with the present specification, whether or not it implemented the optional full functionality mode of Section 9.1.1 of RFC 3168.
モード：RFC 3168 3168イングレスは、RFC 3168のセクション9.1.1のオプションの完全な機能モードを実装したかどうかにかかわらず、現在の仕様に準拠する場合は更新する必要があります。
Section 9.1 of RFC 3168 defined a (required) limited functionality mode and an (optional) full functionality mode for a tunnel. In RFC 3168, modes applied to both ends of the tunnel, while in the present specification, modes are only used at the ingress -- a single egress behaviour covers all cases.
RFC 3168のセクション9.1は、トンネルの（必須）限定機能モードと（オプションの）フル機能モードを定義しました。RFC 3168では、トンネルの両端にモードが適用されますが、現在の仕様では、モードはイングレスでのみ使用されます。単一の出口動作はすべてのケースをカバーしています。
The normal mode of encapsulation is an update to the encapsulation behaviour of the full functionality mode of an RFC 3168 ingress. The compatibility mode of encapsulation is identical to the encapsulation behaviour of the limited functionality mode of an RFC 3168 ingress, except it is not always obligatory.
カプセル化の通常のモードは、RFC 3168イングレスの完全な機能モードのカプセル化動作の更新です。カプセル化の互換性モードは、RFC 3168イングレスの限られた機能モードのカプセル化挙動と同一ですが、必ずしも義務的ではありません。
The constraints on how tunnel discovery protocols set modes in Sections 4.3 and 4.4 are an update to RFC 3168, but they are unlikely to require code changes as they document existing safe practice.
セクション4.3および4.4のトンネルディスカバリープロトコルがモードを設定する方法の制約は、RFC 3168の更新ですが、既存の安全な慣行を文書化するため、コードの変更が必要になる可能性は低いです。
An overriding goal is to ensure the same ECN signals can mean the same thing whatever tunnels happen to encapsulate an IP packet flow. This removes gratuitous inconsistency, which otherwise constrains the available design space and makes it harder to design networks and new protocols that work predictably.
オーバーライドの目標は、同じECN信号がIPパケットフローをカプセル化するために起こるトンネルが何であれ同じことを意味することを確認することです。これにより、利用可能な設計スペースを制約し、予想通りに機能するネットワークと新しいプロトコルを設計するのが難しくなります。
The normal mode in Section 4 updates RFC 3168 to make all IP-in-IP encapsulation of the ECN field consistent -- consistent with the way both RFC 4301 IPsec [RFC4301] and IP-in-MPLS or MPLS-in-MPLS encapsulation [RFC5129] construct the ECN field.
セクション4の通常モードは、RFC 3168を更新して、すべてのIP-in-IPカプセルをECNフィールドのカプセル化を一貫させる - RFC 4301 IPSEC [RFC4301]とIP-in-MPLSまたはMPLS-in-MPLSカプセル化の両方と一致するRFC5129] ECNフィールドを構築します。
Compatibility mode has also been defined so that an ingress compliant with a version of IPsec prior to RFC 4301 can still switch to using drop across a tunnel for backward compatibility with legacy decapsulators that do not propagate ECN.
互換性モードも定義されているため、RFC 4301の前にIPSECのバージョンに準拠したイングレスが、ECNを伝播しないレガシー除去器との後方互換性のためにトンネルを横切るドロップを使用することに切り替えることができます。
The trigger that motivated this update to RFC 3168 encapsulation was a Standards-Track proposal for pre-congestion notification (PCN [RFC5670]). PCN excess-traffic-marking only works correctly if the ECN field is copied on encapsulation (as in RFC 4301 and RFC 5129); it does not work if ECN is reset (as in RFC 3168). This is because PCN excess-traffic-marking depends on the outer header revealing any congestion experienced so far on the whole path, not just since the last tunnel ingress.
この更新をRFC 3168カプセル化に動機付けたトリガーは、事前の通知の標準トラック提案（PCN [RFC5670]）でした。PCN過剰トラフィックマークは、ECNフィールドがカプセル化でコピーされた場合にのみ正しく機能します（RFC 4301およびRFC 5129のように）。ECNがリセットされている場合は機能しません（RFC 3168のように）。これは、PCNの過剰な交通マークが外側のヘッダーに依存して、最後のトンネルイングレス以来だけでなく、パス全体で経験した混雑を明らかにするためです。
PCN allows a network operator to add flow admission and termination for inelastic traffic at the edges of a Diffserv domain, but without any per-flow mechanisms in the interior and without the generous provisioning typical of Diffserv, aiming to significantly reduce costs. The PCN architecture [RFC5559] states that RFC 3168 IP-in-IP tunnelling of the ECN field cannot be used for any tunnel ingress in a PCN domain. Prior to the present specification, this left a stark choice between not being able to use PCN for inelastic traffic control or not being able to use the many tunnels already deployed for Mobile IP, VPNs, and so forth.
PCNにより、ネットワークオペレーターは、Diffservドメインのエッジでの非弾性トラフィックのフロー入場と終了を追加できますが、内部には流入あたりのメカニズムがなく、コストを大幅に削減することを目的とした寛大なプロビジョニングがDiffservの典型的なプロビジョニングがありません。PCNアーキテクチャ[RFC5559]は、PCNドメインのトンネルイングレスにはRFC 3168 IP-in-IPトンネルを使用できないと述べています。現在の仕様の前に、これにより、PCNを使用できないためにPCNを使用できないか、モバイルIP、VPNSなどに既に展開されている多くのトンネルを使用できないか、それが厳しい選択が残されました。
The present specification provides a clean solution to this problem, so that network operators who want to use both PCN and tunnels can specify that every tunnel ingress in a PCN region must comply with this latest specification.
現在の仕様は、この問題に対するきれいなソリューションを提供するため、PCNとトンネルの両方を使用したいネットワーク演算子は、PCN領域のすべてのトンネルイングレスがこの最新の仕様に準拠する必要があることを指定できます。
Rather than allow tunnel specifications to fragment further into one for PCN, one for IPsec, and one for other tunnels, the opportunity has been taken to consolidate the diverging specifications back into a single tunnelling behaviour. Resetting ECN was originally motivated by a covert channel concern that has been deliberately set aside in RFC 4301 IPsec. Therefore, the reset behaviour of RFC 3168 is an anomaly that we do not need to keep. Copying ECN on encapsulation is simpler than resetting. So, as more tunnel endpoints comply with this single consistent specification, encapsulation will be simpler as well as more predictable.
トンネルの仕様がPCN、1つはIPSEC、1つは他のトンネル用に1つずつ断片化できるようにするのではなく、分岐した仕様を単一のトンネル挙動に戻す機会が取られています。ECNのリセットは、もともとRFC 4301 IPSECで意図的に確保されている秘密のチャネルの懸念によって動機付けられていました。したがって、RFC 3168のリセット動作は、保持する必要のない異常です。カプセル化でECNをコピーすることは、リセットよりも簡単です。したがって、より多くのトンネルエンドポイントがこの単一の一貫した仕様に準拠しているため、カプセル化はより単純で、より予測可能になります。
Appendix B assesses whether copying rather than resetting CE on ingress will cause any unintended side effects, from the three perspectives of security, control, and management. In summary, this analysis finds that:
付録Bでは、セキュリティ、制御、および管理の3つの視点から、IngressでCEをリセットするのではなく、CEが意図しない副作用を引き起こすかどうかを評価します。要約すると、この分析では次のことがわかります。
o From the control perspective, either copying or resetting works for existing arrangements, but copying has more potential for simplifying control and resetting breaks at least one proposal that is already on the Standards Track.
o 制御の観点からは、既存のアレンジメントのために作業をコピーまたはリセットすることですが、コピーは、すでに標準の追跡にある少なくとも1つの提案を制御とリセットする可能性が高くなります。
o From the management and monitoring perspective, copying is preferable.
o 管理と監視の観点からは、コピーが望ましいです。
o From the traffic security perspective (enforcing congestion control, mitigating denial of service, etc.), copying is preferable.
o トラフィックセキュリティの観点（混雑制御の実施、サービスの拒否など）から、コピーが望ましいです。
o From the information security perspective, resetting is preferable, but the IETF Security Area now considers copying acceptable given the bandwidth of a two-bit covert channel can be managed.
o 情報セキュリティの観点からは、リセットが望ましいですが、IETFセキュリティ領域は、2ビットの秘密チャネルの帯域幅を管理できることを考えると、コピーを許容できると考えるようになりました。
Therefore, there are two points against resetting CE on ingress while copying CE causes no significant harm.
したがって、CEをコピーすることで大きな害はありませんが、IngressにCEをリセットすることに対して2つのポイントがあります。
The specification for decapsulation in Section 4 fixes three problems with the pre-existing behaviours found in both RFC 3168 and RFC 4301:
セクション4の脱カプセル化の仕様では、RFC 3168とRFC 4301の両方に見られる既存の動作に関する3つの問題を修正します。
1. The pre-existing rules prevented the introduction of alternate ECN semantics to signal more than one severity level of congestion [RFC4774], [RFC5559]. The four states of the two-bit ECN field provide room for signalling two severity levels in addition to not-congested and not-ECN-capable states. But, the pre-existing rules assumed that two of the states (ECT(0) and ECT(1)) are always equivalent. This unnecessarily restricts the use of one of four codepoints (half a bit) in the IP (v4 and v6) header. The new rules are designed to work in either case; whether ECT(1) is more severe than or equivalent to ECT(0).
1. 既存の規則により、交互のECNセマンティクスの導入が妨げられ、複数の重大度レベルの混雑[RFC4774]、[RFC5559]を示す。2ビットECNフィールドの4つの状態は、合成されていないおよびeCN対応のない状態に加えて、2つの重大度レベルを信号する余地を提供します。しかし、既存の規則は、2つの州（ECT（0）とECT（1））が常に同等であると想定していました。これにより、IP（V4およびV6）ヘッダーでの4つのコードポイント（半分）の1つの使用が不必要に制限されます。新しいルールは、どちらの場合でも機能するように設計されています。ECT（1）がECT（0）よりも重度であるか、または同等であるか。
As explained in Appendix B.1, the original reason for not forwarding the outer ECT codepoints was to limit the covert channel across a decapsulator to 1 bit per packet. However, now that the IETF Security Area has deemed that a two-bit covert channel through an encapsulator is a manageable risk, the same should be true for a decapsulator.
付録B.1で説明したように、外側のECTコードポイントを転送しない当初の理由は、脱カプセレーターを介した秘密因子をパケットごとに1ビットに制限することでした。ただし、IETFセキュリティ領域は、エンコペーターを介した2ビットの秘密チャネルが管理可能なリスクであると見なされているため、脱カプセレーターにも同じことが当てはまるはずです。
As well as being useful for general future-proofing, this problem is immediately pressing for standardisation of pre-congestion notification (PCN), which uses two severity levels of congestion. If a congested queue used ECT(1) in the outer header to signal more severe congestion than ECT(0), the pre-existing decapsulation rules would have thrown away this congestion signal, preventing tunnelled traffic from ever knowing that it should reduce its load.
一般的な将来の防止に役立つだけでなく、この問題は、2つの重大度レベルの輻輳を使用する事前相関通知（PCN）の標準化を直ちに押し上げています。混雑したキューが外側ヘッダーでECT（1）を使用してECT（0）よりも重度の混雑を信号する場合、既存の脱カプセル化規則がこの鬱血信号を捨ててしまい、トンネルのトラフィックが負荷を減らすことを妨げないようにします。。
Before the present specification was written, the PCN working group had to consider a number of wasteful or convoluted work-rounds to this problem. Without wishing to disparage the ingenuity of these work-rounds, none were chosen for the Standards Track because they were either somewhat wasteful, imprecise, or complicated. Instead, a baseline PCN encoding was specified [RFC5696] that supported only one severity level of congestion but allowed space for these work-rounds as experimental extensions.
現在の仕様が書かれる前に、PCNワーキンググループは、この問題に対する多くの無駄なまたは複雑なワークラウンドを考慮する必要がありました。これらのワークラウンドの創意工夫を軽parすることを望まずに、標準の追跡に選ばれたものはありませんでした。代わりに、ベースラインPCNエンコードが指定されました[RFC5696]。これは、1つの重大度レベルの混雑のみをサポートしましたが、実験的拡張としてこれらの作業ラウンドのスペースを可能にしました。
By far the simplest approach is that taken by the current specification: just to remove the covert channel blockages from tunnelling behaviour -- now deemed unnecessary anyway. Then, network operators that want to support two congestion severity levels for PCN can specify that every tunnel egress in a PCN region must comply with this latest specification. Having taken this step, the simplest possible encoding for PCN with two severity levels of congestion [PCN3in1] can be used.
最も簡単なアプローチは、現在の仕様によって採用されていることです。トンネルの動作から秘密のチャネル閉塞を削除するためだけに、とにかく不必要であると考えられています。次に、PCNの2つの混雑の重症度レベルをサポートしたいネットワークオペレーターは、PCN領域のすべてのトンネル出力がこの最新の仕様に準拠する必要があることを指定できます。この一歩を踏み出した後、2つの重大度レベルの混雑[PCN3IN1]を備えたPCNの可能な限り単純なエンコードを使用できます。
Not only does this make two congestion severity levels available for PCN, but also for other potential uses of the extra ECN codepoint (e.g., [VCP]).
これにより、PCNで2つの輻輳重症度レベルが利用可能になるだけでなく、余分なECNコードポイント（[VCP]など）の他の潜在的な用途も利用できます。
2. Cases are documented where a middlebox (e.g., a firewall) drops packets with header values that were currently unused (CU) when the box was deployed, often on the grounds that anything unexpected might be an attack. This tends to bar future use of CU values. The new decapsulation rules specify optional logging and/or alarms for specific combinations of inner and outer headers that are currently unused. The aim is to give implementers a recourse other than drop if they are concerned about the security of CU values. It recognises legitimate security concerns about CU values, but still eases their future use. If the alarms are interpreted as an attack (e.g., by a management system) the offending packets can be dropped. However, alarms can be turned off if these combinations come into regular use (e.g., through a future standards action).
2. ケースは、ミドルボックス（ファイアウォールなど）が、ボックスが展開されたときに現在使用されていないヘッダー値を備えたパケットをドロップする場合、多くの場合、予期しないことは攻撃である可能性があるという理由でしばしば展開されます。これは、CU値の将来の使用を妨げる傾向があります。新しい脱カプセル化ルールでは、現在使用されていない内側と外側のヘッダーの特定の組み合わせについて、オプションのロギングおよび/またはアラームを指定します。目的は、CU値のセキュリティを懸念している場合、実装者にドロップ以外の手段を提供することです。CUの値に関する正当なセキュリティの懸念を認識していますが、それでも将来の使用を緩和します。アラームが攻撃として解釈される場合（たとえば、管理システムによって）、問題のあるパケットを削除できます。ただし、これらの組み合わせが定期的に使用される場合（たとえば、将来の標準アクションを介して）アラームをオフにすることができます。
3. While reviewing currently unused combinations of inner and outer headers, the opportunity was taken to define a single consistent behaviour for the three cases with a Not-ECT inner header but a different outer. RFC 3168 and RFC 4301 had diverged in this respect and even their common behaviours had never been justified.
3. 内側と外側のヘッダーの現在使用されていない組み合わせをレビューしている間、3つのケースの単一の一貫した動作を、それ以外の内側ヘッダーとは異なる外側を備えた単一の一貫した動作を定義する機会が得られました。RFC 3168およびRFC 4301はこの点で分岐しており、その共通の行動でさえ正当化されたことはありませんでした。
None of these combinations should result from Internet protocols in the RFC series, but future standards actions might put any or all of them to good use. Therefore, it was decided that a decapsulator must forward a Not-ECT inner header unchanged when the arriving outer header is ECT(0) or ECT(1). For safety, it must drop a combination of Not-ECT inner and CE outer headers. Then, if some unfortunate misconfiguration resulted in a congested router marking CE on a packet that was originally Not-ECT, drop would be the only appropriate signal for the egress to propagate -- the only signal a non-ECN-capable transport (Not-ECT) would understand.
これらの組み合わせは、RFCシリーズのインターネットプロトコルから生じるものではありませんが、将来の標準アクションにより、それらのいずれかまたはすべてが有効に活用される可能性があります。したがって、到着する外側のヘッダーがECT（0）またはECT（1）である場合、脱カプセル因子は変化しない内側のヘッダーを転送する必要があることが決定されました。安全のために、それは非ectの内側とCEの外側ヘッダーの組み合わせをドロップする必要があります。次に、不幸な誤解が、元々はそれではなかったパケットにCEをマークする混雑したルーターをマークした場合、ドロップは出口が伝播する唯一の適切な信号です。ect）理解します。
It may seem contradictory that the same argument has not been applied to the ECT(1) codepoint, given it is being proposed as an intermediate level of congestion in a scheme progressing through the IETF [PCN3in1]. Instead, a decapsulator must forward a Not-ECT inner unchanged when its outer is ECT(1). The rationale for not dropping this CU combination is to ensure it will be usable if needed in the future. If any misconfiguration led to ECT(1) congestion signals with a Not-ECT inner, it would not be disastrous for the tunnel egress to suppress them, because the congestion should then escalate to CE marking, which the egress would drop, thus at least preventing congestion collapse.
IETF [PCN3IN1]を介して進行するスキームで中間レベルの混雑として提案されていることを考えると、同じ議論がECT（1）CodePointに適用されていないことは矛盾しているように思えるかもしれません。代わりに、脱カプセレータは、外側がECT（1）の場合、非ectの内側の変更を転送する必要があります（1）。このCUの組み合わせを削除しないという理論的根拠は、将来必要に応じて使用できるようにすることです。誤った構成がECT（1）commingの内側を伴う混雑信号につながった場合、混雑がcEマーキングにエスカレートする必要があるため、トンネルの出口がそれらを抑制することは悲惨ではありません。うっ血の崩壊を防ぐ。
Problems 2 and 3 alone would not warrant a change to decapsulation, but it was decided they are worth fixing and making consistent at the same time as decapsulation code is changed to fix problem 1 (two congestion severity levels).
問題2と3だけでは、脱カプセル化の変更は保証されませんが、問題1（2つの混雑の重大度レベル）を修正するために脱カプセル化コードが変更されると同時に修正され、一貫性を作る価値があると判断されました。
A tunnel endpoint compliant with the present specification is backward compatible when paired with any tunnel endpoint compliant with any previous tunnelling RFC, whether RFC 4301, RFC 3168 (see Section 3), or the earlier RFCs summarised in Appendix A (RFC 2481, RFC 2401, and RFC 2003). Each case is enumerated below.
現在の仕様に準拠したトンネルエンドポイントは、RFC 4301、RFC 3168（セクション3を参照）、または付録A（RFC 2481、RFC 2401にまとめられた以前のRFC（RFC 2481、RFC 2401）など、以前のトンネルRFCに準拠したトンネルエンドポイントとペアリングすると、後方互換性があります。、およびRFC 2003）。各ケースは以下に列挙されています。
At the egress, this specification only augments the per-packet calculation of the ECN field (RFC 3168 and RFC 4301) for combinations of inner and outer headers that have so far not been used in any IETF protocols.
出口では、この仕様は、IETFプロトコルではこれまで使用されていない内側と外側のヘッダーの組み合わせのために、ECNフィールド（RFC 3168およびRFC 4301）のパケットごとの計算のみを強化します。
Therefore, all other things being equal, if an RFC 4301 IPsec egress is updated to comply with the new rules, it will still interwork with any ingress compliant with RFC 4301 and the packet outputs will be identical to those it would have output before (fully backward compatible).
したがって、RFC 4301 IPSEC出力が新しいルールに準拠するように更新された場合、RFC 4301に準拠した侵入とインターワークし、パケット出力は以前に出力されたものと同一になります（完全に等しくなります。下位互換性）。
And, all other things being equal, if an RFC 3168 egress is updated to comply with the same new rules, it will still interwork with any ingress complying with any previous specification (both modes of RFC 3168, both modes of RFC 2481, RFC 2401, and RFC 2003) and the packet outputs will be identical to those it would have output before (fully backward compatible).
そして、他のすべてのものが平等です。RFC3168出口が同じ新しいルールを順守するように更新された場合、以前の仕様に準拠した侵入（RFC 3168の両方のモード、RFC 2481、RFC 2401の両方のモードと相互作業します、およびRFC 2003）およびパケット出力は、以前に出力があったものと同じです（完全に互換性があります）。
A compliant tunnel egress merely needs to implement the one behaviour in Section 4 with no additional mode or option configuration at the ingress or egress nor any additional negotiation with the ingress. The new decapsulation rules have been defined in such a way that congestion control will still work safely if any of the earlier versions of ECN processing are used unilaterally at the encapsulating ingress of the tunnel (any of RFC 2003, RFC 2401, either mode of RFC 2481, either mode of RFC 3168, RFC 4301, and this present specification).
準拠したトンネルの出口は、イングレスまたは出口で追加のモードまたはオプション構成をせずにセクション4に1つの動作を実装したり、イングレスとの追加交渉を行う必要があります。新しい脱カプセル化ルールは、ECN処理の以前のバージョンのいずれかがトンネルのカプセル化の侵入で一方的に使用されている場合、混雑制御が依然として安全に機能するように定義されています（RFC 2003、RFC 2401、RFCのいずれかのモードのいずれかのモードのいずれか2481、RFC 3168、RFC 4301のモード、およびこの現在の仕様）。
An RFC 4301 IPsec ingress can comply with this new specification without any update and it has no need for any new modes, options, or configuration. So, all other things being equal, it will continue to interwork identically with any egress it worked with before (fully backward compatible).
RFC 4301 IPSEC Ingressは、更新せずにこの新しい仕様に準拠することができ、新しいモード、オプション、または構成は必要ありません。したがって、他のすべてのものは平等であるため、以前に動作した退出とは同じようにインターワークを続けます（完全に後方互換性があります）。
The encapsulation behaviour of the new normal mode copies the ECN field, whereas an RFC 3168 ingress in full functionality mode reset it. However, all other things being equal, if an RFC 3168 ingress is updated to the present specification, the outgoing packets from any tunnel egress will still be unchanged. This is because all variants of tunnelling at either end (RFC 4301, both modes of RFC 3168, both modes of RFC 2481, RFC 2401, RFC 2003, and the present specification) have always propagated an incoming CE marking through the inner header and onward into the outgoing header; whether the outer header is reset or copied. Therefore, if the tunnel is considered a black box, the packets output from any egress will be identical with or without an update to the ingress. Nonetheless, if packets are observed within the black box (between the tunnel endpoints), CE markings copied by the updated ingress will be visible within the black box, whereas they would not have been before. Therefore, the update to encapsulation can be termed 'black-box backward compatible' (i.e., identical unless you look inside the tunnel).
新しい正常モードのカプセル化動作はECNフィールドをコピーしますが、RFC 3168フル機能モードのイングレスがリセットされます。ただし、RFC 3168イングレスが現在の仕様に更新されている場合、他のすべてのものが等しい場合、トンネル出口からの発信パケットはまだ変更されません。これは、両端でのトンネリングのすべてのバリエーション（RFC 4301、RFC 3168の両方のモード、RFC 2481、RFC 2401、RFC 2003、および現在の仕様の両方の両方のモード）が常に内側のヘッダーを介した着信CEマークを伝播したためです。発信ヘッダーに。外側のヘッダーがリセットされるかコピーされているか。したがって、トンネルがブラックボックスと見なされる場合、任意の出力からのパケット出力は、イングレスの更新の有無にかかわらず同一になります。それにもかかわらず、ブラックボックス内（トンネルのエンドポイントの間）内でパケットが観察される場合、更新されたイングレスによってコピーされたCEマーキングはブラックボックス内に表示されますが、以前はそうではなかったでしょう。したがって、カプセル化の更新は、「ブラックボックスの後方互換」と呼ぶことができます（つまり、トンネルの内側を見ない限り同一です）。
This specification introduces no new backward compatibility issues when a compliant ingress talks with a legacy egress, but it has to provide similar safeguards to those already defined in RFC 3168. RFC 3168 laid down rules to ensure that an RFC 3168 ingress turns off ECN (limited functionality mode) if it is paired with a legacy egress (RFC 2481, RFC 2401, or RFC 2003), which would not propagate ECN correctly. The present specification carries forward those rules (Section 4.3). It uses compatibility mode whenever RFC 3168 would have used limited functionality mode, and their per-packet behaviours are identical. Therefore, all other things being equal, an ingress using the new rules will interwork with any legacy tunnel egress in exactly the same way as an RFC 3168 ingress (still black-box backward compatible).
この仕様では、準拠した侵入がレガシー出力と話し合っている場合、新しい後方互換性の問題はありませんが、RFC 3168ですでに定義されているものと同様の保護手段を提供する必要があります。機能モード）レガシー出口（RFC 2481、RFC 2401、またはRFC 2003）とペアになっている場合、ECNを正しく伝播しません。現在の仕様では、これらのルールを転送します（セクション4.3）。RFC 3168が制限された機能モードを使用し、パケットごとの動作が同一である場合、互換性モードを使用します。したがって、他のすべてのものが平等であるため、新しいルールを使用した侵入は、RFC 3168イングレス（まだブラックボックスの後方互換性）とまったく同じ方法で、レガシートンネル出口とインターワークします。
This section is informative, not normative.
このセクションは有益であり、規範ではありません。
Section 5 of RFC 3168 permits the Diffserv codepoint (DSCP)[RFC2474] to 'switch in' alternative behaviours for marking the ECN field, just as it switches in different per-hop behaviours (PHBs) for scheduling. [RFC4774] gives best current practice for designing such alternative ECN semantics and very briefly mentions in Section 5.4 that tunnelling needs to be considered. The guidance below complements and extends RFC 4774, giving additional guidance on designing any alternate ECN semantics that would also require alternate tunnelling semantics.
RFC 3168のセクション5では、DiffServ CodePoint（DSCP）[RFC2474]は、スケジューリングのために異なる個人あたりの動作（PHB）に切り替わるように、ECNフィールドをマークするための代替行動の「切り替え」を許可します。[RFC4774]は、このような代替ECNセマンティクスを設計するための最良の現在の慣行を提供し、セクション5.4で非常に簡単に言及し、トンネリングを考慮する必要があると述べています。以下のガイダンスは、RFC 4774を補完および拡張し、代替トンネリングセマンティクスも必要とする代替ECNセマンティクスの設計に関する追加のガイダンスを提供します。
The overriding guidance is: "Avoid designing alternate ECN tunnelling semantics, if at all possible". If a scheme requires tunnels to implement special processing of the ECN field for certain DSCPs, it will be hard to guarantee that every implementer of every tunnel will have added the required exception or that operators will have ubiquitously deployed the required updates. It is unlikely a single authority is even aware of all the tunnels in a network, which may include tunnels set up by applications between endpoints, or dynamically created in the network. Therefore, it is highly likely that some tunnels within a network or on hosts connected to it will not implement the required special case.
最優先ガイダンスは、「可能であれば、代替ECNトンネルセマンティクスの設計を避けないでください」です。スキームが特定のDSCPのECNフィールドの特別な処理を実装するためにトンネルを要求する場合、すべてのトンネルのすべての実装者が必要な例外を追加したか、オペレーターが必要な更新を遍在的に展開することを保証することは困難です。単一の当局がネットワーク内のすべてのトンネルを認識している可能性は低いです。これには、エンドポイント間のアプリケーションによって設定されたトンネル、またはネットワークで動的に作成されたトンネルが含まれる場合があります。したがって、ネットワーク内の一部のトンネルまたはそれに接続されているホスト上のトンネルは、必要な特別なケースを実装しない可能性が高いです。
That said, if a non-default scheme for tunnelling the ECN field is really required, the following guidelines might prove useful in its design:
とはいえ、ECNフィールドをトンネリングするための非デフォルトスキームが本当に必要な場合、次のガイドラインはその設計で有用であることが証明される可能性があります。
On encapsulation in any alternate scheme:
代替スキームのカプセル化について：
1. The ECN field of the outer header ought to be cleared to Not-ECT ("00") unless it is guaranteed that the corresponding tunnel egress will correctly propagate congestion markings introduced across the tunnel in the outer header.
1. 外側ヘッダーのECNフィールドは、対応するトンネル出力が外側ヘッダーのトンネル全体に導入されたうっ血マーキングを正しく伝播することが保証されない限り、非（「00」）にクリアされるべきです。
2. If it has established that ECN will be correctly propagated, an encapsulator also ought to copy incoming congestion notification into the outer header. The general principle here is that the outer header should reflect congestion accumulated along the whole upstream path, not just since the tunnel ingress (Appendix B.3 on management and monitoring explains).
2. ECNが正しく伝播されることが確立されている場合、エンコープカプレーターは、入ってくる混雑通知を外側のヘッダーにコピーする必要があります。ここでの一般的な原則は、外側のヘッダーが、トンネルの侵入以来だけでなく、上流の経路全体に沿って蓄積されたうっ血を反映する必要があるということです（管理と監視に関する付録B.3は説明します）。
In some circumstances (e.g., PCN [RFC5559] and perhaps some pseudowires [RFC5659]), the whole path is divided into segments, each with its own congestion notification and feedback loop. In these cases, the function that regulates load at the start of each segment will need to reset congestion notification for its segment. Often, the point where congestion notification is reset will also be located at the start of a tunnel. However, the resetting function can be thought of as being applied to packets after the encapsulation function -- two logically separate functions even though they might run on the same physical box. Then, the code module doing encapsulation can keep to the copying rule and the load regulator module can reset congestion, without any code in either module being conditional on whether the other is there.
状況によっては（たとえば、PCN [RFC559]およびおそらく一部の擬似動物[RFC5659]）では、パス全体がセグメントに分割され、それぞれが独自の混雑通知とフィードバックループを備えています。これらの場合、各セグメントの開始時に負荷を調節する関数は、そのセグメントに対して混雑通知をリセットする必要があります。多くの場合、混雑通知がリセットされるポイントもトンネルの開始時に配置されます。ただし、リセット関数は、カプセル化関数の後にパケットに適用されていると考えることができます。同じ物理ボックスで実行されている場合でも、2つの論理的に個別の機能です。次に、カプセル化を行うコードモジュールは、コピールールに維持でき、負荷レギュレータモジュールはうっ血をリセットできます。どちらのモジュールにもコードがあり、他のモジュールがそこにあるかどうかを条件とします。
On decapsulation in any alternate scheme:
代替スキームの脱カプセル化について：
1. If the arriving inner header is Not-ECT, the transport will not understand other ECN codepoints. If the outer header carries an explicit congestion marking, the alternate scheme would be expected to drop the packet -- the only indication of congestion the transport will understand. If the alternate scheme recommends forwarding rather than dropping such a packet, it will need to clearly justify this decision. If the inner is Not-ECT and the outer carries any other ECN codepoint that does not indicate congestion, the alternate scheme can forward the packet, but probably only as Not-ECT.
1. 到着する内側のヘッダーがそれでない場合、トランスポートは他のECNコードポイントを理解しません。外側のヘッダーが明示的な混雑マーキングを搭載している場合、代替スキームはパケットをドロップすることが期待されます - 輸送が理解する渋滞の唯一の兆候。代替スキームがそのようなパケットをドロップするのではなく転送を推奨する場合、この決定を明確に正当化する必要があります。内側が極端ではなく、外側が輻輳を示さない他のECNコードポイントを運ぶ場合、代替スキームはパケットを転送できますが、おそらくそれは非それとしてのみです。
2. If the arriving inner header is one other than Not-ECT, the ECN field that the alternate decapsulation scheme forwards ought to reflect the more severe congestion marking of the arriving inner and outer headers.
2. 到着する内側のヘッダーがそれ以外の1つである場合、代替の脱カプセル化スキームが到着する内側と外側のヘッダーのより深刻な混雑マーキングを反映する必要があるECNフィールド。
3. Any alternate scheme will need to define a behaviour for all combinations of inner and outer headers, even those that would not be expected to result from standards known at the time and even those that would not be expected from the tunnel ingress paired with the egress at run-time. Consideration should be given to logging such unexpected combinations and raising an alarm, particularly if there is a danger that the invalid combination implies congestion signals are not being propagated correctly. The presence of currently unused combinations may represent an attack, but the new scheme should try to define a way to forward such packets, at least if a safe outgoing codepoint can be defined.
3. 代替スキームは、内側と外側のヘッダーのすべての組み合わせの動作を定義する必要があります。当時知られている標準から生じると予想されていなかったものでさえ、トンネルの侵入から予想されないものでさえ、出口と組み合わせたものでさえも定義する必要があります。ランタイム。特に無効な組み合わせが渋滞信号が正しく伝播されていないことを意味するという危険がある場合、そのような予期しない組み合わせを記録し、アラームを上げることを考慮する必要があります。現在使用されていない組み合わせの存在は攻撃を表す可能性がありますが、新しいスキームは、少なくとも安全な発信コードポイントを定義できる場合は、そのようなパケットを転送する方法を定義しようとする必要があります。
Raising an alarm allows a management system to decide whether the anomaly is indeed an attack, in which case it can decide to drop such packets. This is a preferable approach to hard-coded discard of packets that seem anomalous today, but may be needed tomorrow in future standards actions.
アラームを上げると、管理システムが異常が実際に攻撃であるかどうかを判断することができます。その場合、そのようなパケットをドロップすることができます。これは、今日は異常に見えるが、明日は将来の基準アクションで必要とされるかもしれないハードコーディングされたパケットの破棄に対する好ましいアプローチです。
Appendix B.1 discusses the security constraints imposed on ECN tunnel processing. The new rules for ECN tunnel processing (Section 4) trade-off between information security (covert channels) and traffic security (congestion monitoring and control). Ensuring congestion markings are not lost is itself an aspect of security, because if we allowed congestion notification to be lost, any attempt to enforce a response to congestion would be much harder.
付録B.1では、ECNトンネル処理に課されるセキュリティの制約について説明します。ECNトンネル処理（セクション4）情報セキュリティ（秘密チャネル）とトラフィックセキュリティ（混雑の監視と制御）の間のトレードオフの新しいルール。混雑マーキングが失われないことを保証すること自体はセキュリティの側面です。なぜなら、混雑通知を失うことを許可した場合、混雑に対する応答を実施しようとする試みははるかに難しいからです。
Security issues in unlikely, but possible, scenarios:
ありそうもない、しかし可能なシナリオでのセキュリティの問題：
Tunnels intersecting Diffserv regions with alternate ECN semantics: If alternate congestion notification semantics are defined for a certain Diffserv PHB, the scope of the alternate semantics might typically be bounded by the limits of a Diffserv region or regions, as envisaged in [RFC4774] (e.g., the pre-congestion notification architecture [RFC5559]). The inner headers in tunnels crossing the boundary of such a Diffserv region but ending within the region can potentially leak the external congestion notification semantics into the region, or leak the internal semantics out of the region. [RFC2983] discusses the need for Diffserv traffic conditioning to be applied at these tunnel endpoints as if they are at the edge of the Diffserv region. Similar concerns apply to any processing or propagation of the ECN field at the endpoints of tunnels with one end inside and the other outside the domain. [RFC5559] gives specific advice on this for the PCN case, but other definitions of alternate semantics will need to discuss the specific security implications in each case.
トンネルと交差するDiffserv領域と代替ECNセマンティクス：代替渋滞通知セマンティクスが特定のDiffserv PHBに対して定義されている場合、代替セマンティクスの範囲は通常、[RFC4774]で想定されているように、Diffserv領域または領域の限界によって制限される可能性があります（E.G.、前構成前の通知アーキテクチャ[RFC559]）。このようなDiffServ領域の境界を横切るトンネルの内側のヘッダーは、地域内で終わる可能性があります。[RFC2983]は、これらのトンネルエンドポイントにdiffserv領域の端にあるかのように、これらのトンネルエンドポイントに適用されるDiffservトラフィックコンディショニングの必要性について説明しています。同様の懸念は、トンネルのエンドポイントでのECNフィールドの処理または伝播にも適用されます。[RFC5559]は、PCNケースについてこれに関する具体的なアドバイスを提供しますが、代替セマンティクスの他の定義は、それぞれの場合の特定のセキュリティへの影響を議論する必要があります。
ECN nonce tunnel coverage: The new decapsulation rules improve the coverage of the ECN nonce [RFC3540] relative to the previous rules in RFC 3168 and RFC 4301. However, nonce coverage is still not perfect, as this would have led to a safety problem in another case. Both are corner-cases, so discussion of the compromise between them is deferred to Appendix D.
ECN NonCeNCENNELのカバレッジ：新しい脱カプセル化ルールは、RFC 3168およびRFC 4301の以前のルールと比較して、ECN NonCe [RFC3540]のカバレッジを改善します。ただし、NonCeカバレッジはまだ完璧ではありません。別のケース。どちらもコーナーケースなので、それらの間の妥協についての議論は付録Dに延期されます。
Covert channel not turned off: A legacy (RFC 3168) tunnel ingress could ask an RFC 3168 egress to turn off ECN processing as well as itself turning off ECN. An egress compliant with the present specification will agree to such a request from a legacy ingress, but it relies on the ingress always sending Not-ECT in the outer header. If the egress receives other ECN codepoints in the outer it will process them as normal, so it will actually still copy congestion markings from the outer to the outgoing header. Referring, for example, to Figure 5 (Appendix B.1), although the tunnel ingress 'I' will set all ECN fields in outer headers to Not-ECT, 'M' could still toggle CE or ECT(1) on and off to communicate covertly with 'B', because we have specified that 'E' only has one mode regardless of what mode it says it has negotiated. We could have specified that 'E' should have a limited functionality mode and check for such behaviour. However, we decided not to add the extra complexity of two modes on a compliant tunnel egress merely to cater for an historic security concern that is now considered manageable.
カバーチャネルがオフになっていない：レガシー（RFC 3168）トンネルイングレスは、RFC 3168出口にECN処理をオフにするように依頼することができ、それ自体がECNをオフにすることができます。現在の仕様に準拠した出力は、レガシーイングレスからのそのような要求に同意しますが、それは常に外側のヘッダーに非ectを送信する侵入に依存しています。出力が外側の他のECNコードポイントを受信した場合、通常どおりそれらを処理するため、実際には外側から外側のヘッダーまでの混雑マーキングをコピーします。たとえば、図5（付録B.1）を参照してください。ただし、トンネルイングレス「I」は外側ヘッダーのすべてのECNフィールドを非表示に設定しますが、「M」はCEまたはECT（1）のオンとオフを切り替えることができます。「b」と密かに通信するために、「e」には、交渉したモードに関係なく、1つのモードのみが1つしかないことを指定したためです。「e」には機能モードが制限され、そのような動作を確認する必要があることを指定できました。ただし、現在管理可能と見なされている歴史的なセキュリティ上の懸念に対応するためだけに、準拠したトンネル出口に2つのモードの余分な複雑さを追加しないことにしました。
This document allows tunnels to propagate an extra level of congestion severity. It uses previously unused combinations of inner and outer headers to augment the rules for calculating the ECN field when decapsulating IP packets at the egress of IPsec (RFC 4301) and non-IPsec (RFC 3168) tunnels.
このドキュメントにより、トンネルは余分なレベルの混雑の重症度を伝播することができます。IPSEC（RFC 4301）および非IPSEC（RFC 3168）トンネルの出口でIPパケットを脱カプセル化するときに、ECNフィールドを計算するためのルールを拡張するために、以前に使用されていない内側ヘッダーと外側ヘッダーの組み合わせを使用します。
This document also updates the ingress tunnelling encapsulation of RFC 3168 ECN to bring all IP-in-IP tunnels into line with the new behaviour in the IPsec architecture of RFC 4301, which copies rather than resets the ECN field when creating outer headers.
このドキュメントでは、RFC 3168 ECNの侵入トンネリングカプセル化を更新して、すべてのIP-in-IPトンネルをRFC 4301のIPSECアーキテクチャの新しい動作に沿ったものにします。
The need for both these updated behaviours was triggered by the introduction of pre-congestion notification (PCN) onto the IETF Standards Track. Operators wanting to support PCN or other alternate ECN schemes that use an extra severity level can require that their tunnels comply with the present specification. This is not a fork in the RFC series, it is an update that can be deployed first by those that need it, and subsequently by all tunnel endpoint implementations during general code maintenance. It is backward compatible with all previous tunnelling behaviours, so existing single severity level schemes will continue to work as before, but support for two severity levels will gradually be added to the Internet.
これらの両方の更新された動作の必要性は、IETF標準トラックへの事前コングション通知（PCN）の導入によりトリガーされました。PCNまたは余分な重大度レベルを使用する他の代替ECNスキームをサポートしたいオペレーターでは、トンネルが現在の仕様に準拠する必要があります。これはRFCシリーズのフォークではなく、最初にそれを必要とするものが展開できるアップデートであり、その後、一般的なコードメンテナンス中にすべてのトンネルエンドポイントの実装によって展開できます。これは、以前のすべてのトンネリング動作と後方互換性があるため、既存の単一の重大度レベルスキームは以前と同じように機能し続けますが、2つの重大度レベルのサポートは徐々にインターネットに追加されます。
The new rules propagate changes to the ECN field across tunnel endpoints that previously blocked them to restrict the bandwidth of a potential covert channel. Limiting the channel's bandwidth to two bits per packet is now considered sufficient.
新しいルールは、潜在的な秘密チャネルの帯域幅を制限するために以前にブロックしたトンネルエンドポイントを介したECNフィールドへの変更を伝播します。チャネルの帯域幅をパケットごとに2ビットに制限するだけで十分と見なされます。
At the same time as removing these legacy constraints, the opportunity has been taken to draw together diverging tunnel specifications into a single consistent behaviour. Then, any tunnel can be deployed unilaterally, and it will support the full range of congestion control and management schemes without any modes or configuration. Further, any host or router can expect the ECN field to behave in the same way, whatever type of tunnel might intervene in the path. This new certainty could enable new uses of the ECN field that would otherwise be confounded by ambiguity.
これらのレガシーの制約を削除すると同時に、分岐したトンネルの仕様を単一の一貫した動作にまとめる機会が得られました。次に、任意のトンネルを一方的に展開でき、モードや構成なしで渋滞制御スキームと管理スキームの全範囲をサポートします。さらに、ホストまたはルーターは、ECNフィールドが同じ方法で動作することを期待できます。この新しい確実性は、曖昧さによって混乱するECNフィールドの新しい使用を可能にする可能性があります。
Thanks to David Black for his insightful reviews and patient explanations of better ways to think about function placement and alarms. Thanks to David and to Anil Agarwal for pointing out cases where it is safe to forward CU combinations of headers. Also, thanks to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster, Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson, Philip Eardley, and David Harrington for their thoughts and careful review comments, and to Stephen Hanna, Ben Campbell, and members of the IESG for respectively conducting the Security Directorate, General Area, and IESG reviews.
洞察に富んだレビューと、機能の配置とアラームについて考えるより良い方法の患者の説明をしてくれたDavid Blackに感謝します。DavidとAnil Agarwalに、ヘッダーのCUの組み合わせを安全に転送できる場合を指摘してくれたAnil Agarwalに感謝します。また、付録Cのアイデアについては、Arnaud Jacquetに感謝します。GorryFairhurst、Teco Boot、Michael Menth、Bruce Davie、Toby Moncaster、Sally Floyd、Alfred Hoenes、Gabriele Corliano、Ingemar Johansson、Philip Eardey、David Harrington思考と慎重なレビューのコメント、およびスティーブンハンナ、ベンキャンベル、およびIESGのメンバーへのそれぞれ、セキュリティ局、一般エリア、およびIESGレビューを実施しています。
Bob Briscoe is partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme.
Bob Briscoeは、7番目のフレームワークプログラムの下で欧州共同体がサポートする研究プロジェクト（ICT-216372）であるTrilogyによって部分的に資金提供されています。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[PCN3in1] Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-States in the IP header using a single DSCP", Work in Progress, July 2010.
[PCN3IN1] Briscoe、B.、Moncaster、T。、およびM. Menth、「単一のDSCPを使用してIPヘッダーの3つのPCNステートをエンコードする」、2010年7月に進行中の作業。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[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, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RFC2481] Ramakrishnan、K。およびS. Floyd、「IPに明示的な混雑通知（ECN）を追加する提案」、RFC 2481、1999年1月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540] Spring、N.、Wetherall、D。、およびD. Ely、「Noncesによる堅牢な明示的な混雑通知（ECN）シグナル伝達」、RFC 3540、2003年6月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
[RFC4774] Floyd、S。、「明示的な混雑通知（ECN）フィールドの代替セマンティクスの指定」、BCP 124、RFC 4774、2006年11月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129] Davie、B.、Briscoe、B。、およびJ. Tay、「MPLSの明示的な混雑マーキング」、RFC 5129、2008年1月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P。、「前後通知（PCN）アーキテクチャ」、RFC 5559、2009年6月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤーエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P。、「PCN-Nodesの計量およびマーキング動作」、RFC 5670、2009年11月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696] Moncaster、T.、Briscoe、B。、およびM. Menth、「ベースラインのエンコードと事前の情報の輸送」、RFC 5696、2009年11月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", Proc. SIGCOMM'05, ACM CCR 35(4)37--48, 2005, <http://doi.acm.org/10.1145/1080091.1080098>.
[VCP] Xia、Y.、Subramanian、L.、Stoica、I。、およびS. Kalyanaraman、「もう1つだけで十分」、Proc。Sigcomm'05、ACM CCR 35（4）37--48、2005、<http://doi.acm.org/10.1145/1080091.1080098>。
IP-in-IP tunnelling was originally defined in [RFC2003]. On encapsulation, the incoming header was copied to the outer and on decapsulation, the outer was simply discarded. Initially, IPsec tunnelling [RFC2401] followed the same behaviour.
IP-in-IPトンネリングは、もともと[RFC2003]で定義されていました。カプセル化時に、着信ヘッダーは外側にコピーされ、脱カプセル化では、外側は単に破棄されました。当初、IPSECトンネル[RFC2401]は同じ動作に従いました。
When ECN was introduced experimentally in [RFC2481], legacy (RFC 2003 or RFC 2401) tunnels would have discarded any congestion markings added to the outer header, so RFC 2481 introduced rules for calculating the outgoing header from a combination of the inner and outer on decapsulation. RFC 2481 also introduced a second mode for IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer header on encapsulation because an RFC 2401 decapsulator would discard the outer on decapsulation. For RFC 2401 IPsec, this had the side effect of completely blocking the covert channel.
[RFC2481]でECNが実験的に導入されたとき、レガシー（RFC 2003またはRFC 2401）トンネルは外側のヘッダーに追加された混雑マーキングを廃棄したため、RFC 2481は内側と外側の組み合わせから発信ヘッダーを計算するためのルールを導入しました。脱カプセル化。RFC 2481は、IPSECトンネルの2番目のモードも導入しました。これは、RFC 2401の脱カプセレータが脱カプセル化の外側を破棄するため、カプセル化の外側ヘッダーのECN処理（not-ect）をオフにしました。RFC 2401 IPSECの場合、これはカバーチャネルを完全にブロックするという副作用がありました。
In RFC 2481, the ECN field was defined as two separate bits. But when ECN moved from Experimental to Standards Track [RFC3168], the ECN field was redefined as four codepoints. This required a different calculation of the ECN field from that used in RFC 2481 on decapsulation. RFC 3168 also had two modes; a 'full functionality mode' that restricted the covert channel as much as possible but still allowed ECN to be used with IPsec, and another that completely turned off ECN processing across the tunnel. This 'limited functionality mode' both offered a way for operators to completely block the covert channel and allowed an RFC 3168 ingress to interwork with a legacy tunnel egress (RFC 2481, RFC 2401, or RFC 2003).
RFC 2481では、ECNフィールドは2つの個別のビットとして定義されました。しかし、ECNが実験的なものから標準への追跡[RFC3168]に移動したとき、ECNフィールドは4つのコードポイントとして再定義されました。これには、脱カプセル化でRFC 2481で使用されたECNフィールドとは異なる計算が必要でした。RFC 3168には2つのモードもありました。カバーチャネルを可能な限り制限していたが、それでもECNをIPSECで使用することを許可する「完全な機能モード」、およびトンネル全体でECN処理を完全にオフにした別の「ECN」を許可しました。この「制限された機能モード」は、両方ともオペレーターが秘密のチャネルを完全にブロックする方法を提供し、RFC 3168イングレスがレガシートンネル出口（RFC 2481、RFC 2401、またはRFC 2003）とインターワークすることを可能にしました。
The present specification includes a similar compatibility mode to interwork safely with tunnels compliant with any of these three earlier RFCs. However, unlike RFC 3168, it is only a mode of the ingress, as decapsulation behaviour is the same in either case.
現在の仕様には、これら3つの以前のRFCのいずれかに準拠したトンネルと安全にインターワークするための同様の互換性モードが含まれています。ただし、RFC 3168とは異なり、脱カプセル化の挙動はどちらの場合でも同じであるため、侵入のモードにすぎません。
Tunnel processing of a congestion notification field has to meet congestion control and management needs without creating new information security vulnerabilities (if information security is required). This appendix documents the analysis of the trade-offs between these factors that led to the new encapsulation rules in Section 4.1.
混雑通知フィールドのトンネル処理は、新しい情報セキュリティの脆弱性を作成せずに、混雑管理と管理のニーズを満たす必要があります（情報セキュリティが必要な場合）。この付録は、セクション4.1の新しいカプセル化規則につながったこれらの要因間のトレードオフの分析を文書化しています。
Information security can be assured by using various end-to-end security solutions (including IPsec in transport mode [RFC4301]), but a commonly used scenario involves the need to communicate between two physically protected domains across the public Internet. In this case, there are certain management advantages to using IPsec in tunnel mode solely across the publicly accessible part of the path. The path followed by a packet then crosses security 'domains'; the ones protected by physical or other means before and after the tunnel and the one protected by an IPsec tunnel across the otherwise unprotected domain. The scenario in Figure 5 will be used where endpoints 'A' and 'B' communicate through a tunnel. The tunnel ingress 'I' and egress 'E' are within physically protected edge domains, while the tunnel spans an unprotected internetwork where there may be 'men in the middle', M.
情報セキュリティは、さまざまなエンドツーエンドセキュリティソリューション（トランスポートモードのIPSEC [RFC4301]を含む）を使用することで保証できますが、一般的に使用されるシナリオには、パブリックインターネット上の2つの物理的に保護されたドメイン間で通信する必要があります。この場合、パスの公的にアクセス可能な部分でのみトンネルモードでIPSECを使用することには、特定の管理上の利点があります。パスが続くパケットの後に、セキュリティ「ドメイン」を横断します。トンネルの前後の物理的またはその他の手段によって保護されているものと、それ以外の場合は保護されていないドメインを横切るIPSECトンネルによって保護されているもの。図5のシナリオは、エンドポイント「A」と「B」がトンネルを介して通信する場合に使用されます。トンネルの侵入「I」と出口「E」は物理的に保護されたエッジドメイン内にあり、トンネルは「中央に男性」がいる可能性のある保護されていないインターネットワークに及びます。
physically unprotected physically
<-protected domain-><--domain--><-protected domain->
+------------------+ +------------------+
| | M | |
| A-------->I=========>==========>E-------->B |
| | | |
+------------------+ +------------------+
<----IPsec secured---->
tunnel
Figure 5: IPsec Tunnel Scenario
図5：IPSECトンネルシナリオ
IPsec encryption is typically used to prevent 'M' seeing messages from 'A' to 'B'. IPsec authentication is used to prevent 'M' masquerading as the sender of messages from 'A' to 'B' or altering their contents. 'I' can use IPsec tunnel mode to allow 'A' to communicate with 'B', but impose encryption to prevent 'A' leaking information to 'M'. Or 'E' can insist that 'I' uses tunnel mode authentication to prevent 'M' communicating information to 'B'.
IPSEC暗号化は、通常、「A」から「B」から「M」を見るのを防ぐために使用されます。IPSEC認証は、「A」から「B」へのメッセージの送信者としての「M」のマスカレードを防止したり、コンテンツを変更したりするために使用されます。「I」はIPSECトンネルモードを使用して、「A」と「B」と通信できるようにしますが、「A」が「M」に漏れている「A」を防ぐために暗号化を課すことができます。または「E」は、「I」が「M」と「B」への通信を防ぐためにトンネルモード認証を使用すると主張することができます。
Mutable IP header fields such as the ECN field (as well as the Time to Live (TTL) / Hop Limit and DS fields) cannot be included in the cryptographic calculations of IPsec. Therefore, if 'I' copies these mutable fields into the outer header that is exposed across the tunnel it will have allowed a covert channel from 'A' to 'M' that bypasses its encryption of the inner header. And if 'E' copies these fields from the outer header to the outgoing, even if it validates authentication from 'I', it will have allowed a covert channel from 'M' to 'B'.
ECNフィールドなどの可変IPヘッダーフィールド（およびライブ（TTL） /ホップ制限フィールドとDSフィールド）をIPSECの暗号化計算に含めることはできません。したがって、「I」がこれらの可変フィールドをトンネル全体に露出している外側ヘッダーにコピーすると、内側のヘッダーの暗号化をバイパスする「A」から「M」までの秘密のチャネルが許可されます。また、「e」がこれらのフィールドを外側のヘッダーから発信にコピーした場合、たとえ「i」から認証を検証しても、「M」から「B」へのカバーチャネルが許可されます。
ECN at the IP layer is designed to carry information about congestion from a congested resource towards downstream nodes. Typically, a downstream transport might feed the information back somehow to the point upstream of the congestion that can regulate the load on the congested resource, but other actions are possible [RFC3168], Section 6. In terms of the above unicast scenario, ECN effectively intends to create an information channel (for congestion signalling) from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore, the goals of IPsec and ECN are mutually incompatible, requiring some compromise.
IPレイヤーのECNは、混雑したリソースから下流ノードに向かって混雑したリソースに関する情報を伝えるように設計されています。通常、下流の輸送は、混雑したリソースの負荷を調節できる混雑の上流のポイントに何らかの形で情報を送り返す可能性がありますが、他のアクションは可能です[RFC3168]、セクション6。上記のユニキャストシナリオに関して、ECNは効果的にECN「M」から「B」（「B」の場合は「A」にフィードバックするための情報チャネル（輻輳シグナリング用）を作成する予定です。したがって、IPSECとECNの目標は相互に互換性があり、ある程度の妥協が必要です。
With respect to using the DS or ECN fields as covert channels, Section 5.1.2 of RFC 4301 says, "controls are provided to manage the bandwidth of this channel". Using the ECN processing rules of RFC 4301, the channel bandwidth is two bits per datagram from 'A' to 'M' and one bit per datagram from 'M' to 'B' (because 'E' limits the combinations of the 2-bit ECN field that it will copy). In both cases, the covert channel bandwidth is further reduced by noise from any real congestion marking. RFC 4301 implies that these covert channels are sufficiently limited to be considered a manageable threat. However, with respect to the larger (six-bit) DS field, the same section of RFC 4301 says not copying is the default, but a configuration option can allow copying "to allow a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying". Of course, an administrator who plans to copy the DS field has to take into account that it could be concatenated with the ECN field, creating a covert channel with eight bits per datagram.
DSまたはECNフィールドをカバーチャネルとして使用することに関して、RFC 4301のセクション5.1.2は、「このチャネルの帯域幅を管理するためにコントロールが提供されている」と述べています。RFC 4301のECN処理ルールを使用すると、チャネル帯域幅はデータグラムごとに2ビットから「A」から「M」から1ビット、「M」から「B」から1ビットです（「E」は2-の組み合わせを制限します。コピーすることをビットECNフィールド）。どちらの場合も、秘密のチャネル帯域幅は、実際の輻輳マーキングからのノイズによってさらに減少します。RFC 4301は、これらの隠れたチャネルが管理可能な脅威と見なされるために十分に制限されていることを意味します。ただし、より大きな（6ビット）DSフィールドに関しては、RFC 4301の同じセクションでコピーがデフォルトであると述べていますが、構成オプションでは「ローカル管理者がコピーして提供されたカバーチャネルが提供されるかどうかを決定できるようにすることができます。これらのビットは、コピーの利点を上回ります」。もちろん、DSフィールドをコピーすることを計画している管理者は、ECNフィールドと連結して、データグラムごとに8ビットのカバーチャネルを作成できることを考慮する必要があります。
For tunnelling the six-bit Diffserv field, two conceptual models have had to be defined so that administrators can trade off security against the needs of traffic conditioning [RFC2983]:
6ビットのDiffServフィールドをトンネリングするには、2つの概念モデルを定義する必要があり、管理者がトラフィックコンディショニングのニーズに対してセキュリティを交換できるようにしました[RFC2983]：
The uniform model: where the Diffserv field is preserved end-to-end by copying into the outer header on encapsulation and copying from the outer header on decapsulation.
均一なモデル：DiffServフィールドがエンドツーエンドで保存されている場合、カプセル化のカプセル化の外側ヘッダーにコピーし、脱カプセル化の外側ヘッダーからコピーします。
The pipe model: where the outer header is independent of that in the inner header so it hides the Diffserv field of the inner header from any interaction with nodes along the tunnel.
パイプモデル：外側のヘッダーが内側ヘッダーのそれから独立している場合、トンネルに沿ったノードとの相互作用から内側ヘッダーのdiffservフィールドを隠します。
However, for ECN, the new IPsec security architecture in RFC 4301 only standardised one tunnelling model equivalent to the uniform model. It deemed that simplicity was more important than allowing administrators the option of a tiny increment in security, especially given not copying congestion indications could seriously harm everyone's network service.
ただし、ECNの場合、RFC 4301の新しいIPSECセキュリティアーキテクチャは、均一モデルに相当する標準化された1つのトンネルモデルのみを標準化されています。特に、渋滞の兆候をコピーしないことで、すべての人のネットワークサービスに深刻な損害を与える可能性があることを考えると、管理者がセキュリティの小さな増分のオプションを許可するよりも単純さは重要であると考えました。
Congestion control requires that any congestion notification marked into packets by a resource will be able to traverse a feedback loop back to a function capable of controlling the load on that resource. To be precise, rather than calling this function the data source, it will be called the 'Load Regulator'. This allows for exceptional cases where load is not regulated by the data source, but usually the two terms will be synonymous. Note the term "a function _capable of_ controlling the load" deliberately includes a source application that doesn't actually control the load but ought to (e.g., an application without congestion control that uses UDP).
混雑制御では、リソースによってパケットにマークされた混雑通知が、フィードバックループをそのリソースの負荷を制御できる関数に戻すことができることが必要です。正確には、この関数をデータソースと呼ぶのではなく、「ロードレギュレータ」と呼ばれます。これにより、負荷がデータソースによって規制されていないが、通常は2つの用語が同義語になる例外的なケースが可能になります。「関数_capable of_負荷を制御する」という用語には、実際に負荷を制御しないが、そうすべきであるソースアプリケーション（UDPを使用する輻輳制御のないアプリケーション）を意図的に含むという用語に注意してください。
A--->R--->I=========>M=========>E-------->B
Figure 6: Simple Tunnel Scenario
図6：単純なトンネルシナリオ
A similar tunnelling scenario to the IPsec one just described will now be considered, but without the different security domains, because the focus now shifts to whether the control loop and management monitoring work (Figure 6). If resources in the tunnel are to be able to explicitly notify congestion and the feedback path is from 'B' to 'A', it will certainly be necessary for 'E' to copy any CE marking from the outer header to the outgoing header for onward transmission to 'B'; otherwise, congestion notification from resources like 'M' cannot be fed back to the Load Regulator ('A'). But it does not seem necessary for 'I' to copy CE markings from the incoming to the outer header. For instance, if resource 'R' is congested, it can send congestion information to 'B' using the congestion field in the inner header without 'I' copying the congestion field into the outer header and 'E' copying it back to the outgoing header. 'E' can still write any additional congestion marking introduced across the tunnel into the congestion field of the outgoing header.
これまでに説明したIPSECと同様のトンネルシナリオが考慮されますが、セキュリティドメインは異なりません。これは、コントロールループと管理監視が機能するかどうかに焦点が移行するためです（図6）。トンネル内のリソースが輻輳を明示的に通知し、フィードバックパスが「B」から「A」までのものである場合、「E」が外側のヘッダーから発信ヘッダーにCEマーキングをコピーする必要があることは確かです。「b」への以降の伝送。それ以外の場合、「M」のようなリソースからの混雑通知を負荷レギュレーター（ 'A'）に供給することはできません。しかし、「I」が着信から外側のヘッダーにCEマーキングをコピーする必要はないようです。たとえば、リソース「R」が混雑している場合、「I」を「I」なしで内側のヘッダーの輻輳フィールドを使用して、輻輳情報を「b」に送信できます。ヘッダ。「E」は、トンネルを越えて発信ヘッダーの輻輳場に導入された追加の輻輳マーキングを書くことができます。
All this shows that 'E' can preserve the control loop irrespective of whether 'I' copies congestion notification into the outer header or resets it.
これはすべて、「e」が「i」が輻輳通知を外側のヘッダーにコピーするかリセットするかに関係なく、コントロールループを保存できることを示しています。
That is the situation for existing control arrangements but, because copying reveals more information, it would open up possibilities for better control system designs. For instance, resetting CE marking on encapsulation breaks the Standards-Track PCN congestion marking scheme [RFC5670]. It ends up removing excessive amounts of traffic unnecessarily (Section 5.3.1). Whereas copying CE markings at ingress leads to the correct control behaviour.
それが既存の制御の取り決めの状況ですが、コピーがより多くの情報を明らかにするため、システム設計を改善するための可能性が開かれます。たとえば、カプセル化のCEマーキングをリセットすると、標準トラックPCN混雑マーキングスキーム[RFC5670]が破損します。過剰な量のトラフィックを不必要に除去することになります（セクション5.3.1）。一方、イングレスでCEマーキングをコピーすると、正しい制御挙動が生じます。
As well as control, there are also management constraints. Specifically, a management system may monitor congestion markings in passing packets, perhaps at the border between networks as part of a service level agreement. For instance, monitors at the borders of autonomous systems may need to measure how much congestion has accumulated so far along the path, perhaps to determine between them how much of the congestion is contributed by each domain.
コントロールだけでなく、管理上の制約もあります。具体的には、管理システムは、おそらくサービスレベル契約の一環として、おそらくネットワーク間の境界線で、通過パケットの混雑マーキングを監視する場合があります。たとえば、自律システムの境界でのモニターは、おそらく各ドメインによって混雑のどれだけが寄与されるかを決定するために、パスに沿ってこれまでの渋滞がどれだけ蓄積されてきたかを測定する必要があるかもしれません。
In this document, the baseline of congestion marking (or the Congestion Baseline) is defined as the source of the layer that created (or most recently reset) the congestion notification field. When monitoring congestion, it would be desirable if the Congestion Baseline did not depend on whether or not packets were tunnelled. Given some tunnels cross domain borders (e.g., consider 'M' in Figure 6 is monitoring a border), it would therefore be desirable for 'I' to copy congestion accumulated so far into the outer headers, so that it is exposed across the tunnel.
このドキュメントでは、うっ血マーキングのベースライン（または輻輳ベースライン）は、混雑通知フィールドを作成（または最近リセット）したレイヤーのソースとして定義されます。輻輳を監視する場合、輻輳ベースラインがパケットがトンネルにされているかどうかに依存しなかった場合、それは望ましいでしょう。したがって、いくつかのトンネルクロスドメインの境界線（たとえば、図6の「M」が境界線を監視していることを考慮してください）を考えると、トンネルを横切って露出するように、これまでに蓄積された混雑を外側のヘッダーにコピーすることが望ましいでしょう。。
For management purposes, it might be useful for the tunnel egress to be able to monitor whether congestion occurred across a tunnel or upstream of it. Superficially, it appears that copying congestion markings at the ingress would make this difficult, whereas it was straightforward when an RFC 3168 ingress reset them. However, Appendix C gives a simple and precise method for a tunnel egress to infer the congestion level introduced across a tunnel. It works irrespective of whether the ingress copies or resets congestion markings.
管理目的では、トンネルの出口がトンネル全体で輻輳が発生したのか、それの上流で発生したのかを監視できることが役立つ場合があります。表面的には、イングレスでの混雑マーキングをコピーするとこれが困難になるように見えますが、RFC 3168のイングレスがリセットされたときは簡単でした。ただし、付録Cは、トンネルの出口がトンネル全体に導入された混雑レベルを推測するためのシンプルで正確な方法を提供します。イングレスが混雑マーキングをコピーするかリセットするかに関係なく機能します。
This specification mandates that a tunnel ingress determines the ECN field of each new outer tunnel header by copying the arriving header. Concern has been expressed that this will make it difficult for the tunnel egress to monitor congestion introduced only along a tunnel, which is easy if the outer ECN field is reset at a tunnel ingress (RFC 3168 full functionality mode). However, in fact copying CE marks at ingress will still make it easy for the egress to measure congestion introduced across a tunnel, as illustrated below.
この仕様は、トンネルの侵入が、到着するヘッダーをコピーすることにより、各新しい外側トンネルヘッダーのECNフィールドを決定することを義務付けています。これにより、トンネルの出口がトンネルに沿ってのみ導入された混雑を監視することが難しくなるという懸念が表明されています。これは、外側のECNフィールドがトンネルイングレス（RFC 3168フル機能モード）でリセットされている場合は簡単です。ただし、実際には、IngressでCEマークをコピーすることで、以下に示すように、トンネル全体に導入された混雑を測定できるようになります。
Consider 100 packets measured at the egress. Say it measures that 30 are CE marked in the inner and outer headers and 12 have additional CE marks in the outer but not the inner. This means packets arriving at the ingress had already experienced 30% congestion. However, it does not mean there was 12% congestion across the tunnel. The correct calculation of congestion across the tunnel is p_t = 12/ (100-30) = 12/70 = 17%. This is easy for the egress to measure. It is simply the proportion of packets not marked in the inner header (70) that have a CE marking in the outer header (12). This technique works whether the ingress copies or resets CE markings, so it can be used by an egress that is not sure with which RFC the ingress complies.
出口で測定された100個のパケットを考慮してください。30が内側と外側のヘッダーにマークされているCEであり、12が外側には追加のCEマークがあるが、内側には追加のCEマークがあることを測定するとします。これは、イングレスに到着するパケットがすでに30％の混雑を経験していたことを意味します。ただし、トンネル全体に12％の混雑があったという意味ではありません。トンネル全体の輻輳の正しい計算は、p_t = 12/（100-30）= 12/70 = 17％です。これは、出口が簡単に測定できます。外側のヘッダー（12）にCEマーキングがあるのは、内側ヘッダー（70）にマークされていないパケットの割合です。この手法は、イングレスがCEマーキングをコピーするかリセットするかどうかにかかわらず機能するため、侵入がどのRFCに準拠しているかわからない出口で使用できます。
Figure 7 illustrates this in a combinatorial probability diagram. The square represents 100 packets. The 30% division along the bottom represents marking before the ingress, and the p_t division up the side represents marking introduced across the tunnel.
図7は、これを組み合わせ確率図で示しています。正方形は100個のパケットを表します。底部に沿った30％の分割は、入り口の前のマーキングを表し、側面のP_T分割はトンネル全体に導入されたマーキングを表します。
^ outer header marking
|
100% +-----+---------+ The large square
| | | represents 100 packets
| 30 | |
| | | p_t = 12/(100-30)
p_t + +---------+ = 12/70
| | 12 | = 17%
0 +-----+---------+--->
0 30% 100% inner header marking
Figure 7: Tunnel Marking of Packets Already Marked at Ingress
図7：イングレスですでにマークされているパケットのトンネルマーキング
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
付録D. ECT（1）内側とECT（0）外側のDecapの妥協
A packet with an ECT(1) inner and an ECT(0) outer should never arise from any known IETF protocol. Without giving a reason, RFC 3168 and RFC 4301 both say the outer should be ignored when decapsulating such a packet. This appendix explains why it was decided not to change this advice.
ECT（1）内側とECT（0）の外側を備えたパケットは、既知のIETFプロトコルから決して発生しないでください。理由を与えることなく、RFC 3168とRFC 4301はどちらも、そのようなパケットを脱カプセル化するときは外側を無視する必要があると言います。この付録は、このアドバイスを変更しないことが決定された理由を説明しています。
In summary, ECT(0) always means 'not congested' and ECT(1) may imply the same [RFC3168] or it may imply a higher severity congestion signal [RFC4774], [PCN3in1], depending on the transport in use. Whether or not they mean the same, at the ingress the outer should have started the same as the inner, and only a broken or compromised router could have changed the outer to ECT(0).
要約すると、ECT（0）は常に「混雑していない」を意味し、ECT（1）は同じ[RFC3168]を意味する場合があります。または、使用中の輸送に応じて、より高い重症度輻輳シグナル[RFC4774]、[PCN3IN1]を意味する場合があります。それらが同じことを意味するかどうかにかかわらず、侵入で外側は内側と同じように開始されるべきであり、壊れたルーターまたは妥協したルーターのみが外側をECT（0）に変更できた可能性があります。
The decapsulator can detect this anomaly. But the question is, should it correct the anomaly by ignoring the outer, or should it reveal the anomaly to the end-to-end transport by forwarding the outer?
脱カプセーターはこの異常を検出できます。しかし、問題は、外側を無視することで異常を修正すべきか、それとも外側を転送することによってエンドツーエンドの輸送の異常を明らかにする必要があるということです。
On balance, it was decided that the decapsulator should correct the anomaly, but log the event and optionally raise an alarm. This is the safe action if ECT(1) is being used as a more severe marking than ECT(0), because it passes the more severe signal to the transport. However, it is not a good idea to hide anomalies, which is why an optional alarm is suggested. It should be noted that this anomaly may be the result of two changes to the outer: a broken or compromised router within the tunnel might be erasing congestion markings introduced earlier in the same tunnel by a congested router.
バランスをとると、脱カプセーターは異常を修正するが、イベントを記録し、オプションでアラームを上げることが決定されました。これは、ECT（1）がECT（0）よりも深刻なマーキングとして使用されている場合、輸送へのより深刻な信号を渡すため、安全なアクションです。ただし、異常を隠すことは良い考えではありません。そのため、オプションのアラームが提案されています。この異常は、外側への2つの変更の結果である可能性があることに注意してください。トンネル内の壊れたルーターまたは侵害されたルーターは、混雑したルーターによって同じトンネルで前に導入された混雑マーキングを消去している可能性があります。
In this case, the anomaly would be losing congestion signals, which needs immediate attention.
この場合、異常はうっ血信号を失い、すぐに注意が必要です。
The original reason for defining ECT(0) and ECT(1) as equivalent was so that the data source could use the ECN nonce [RFC3540] to detect if congestion signals were being erased. However, in this case, the decapsulator does not need a nonce to detect any anomalies introduced within the tunnel, because it has the inner as a record of the header at the ingress. Therefore, it was decided that the best compromise would be to give precedence to solving the safety issue over revealing the anomaly, because the anomaly could at least be detected and dealt with internally.
ECT（0）とECT（1）を同等物として定義する当初の理由は、データソースがECN NonCe [RFC3540]を使用して、混雑信号が消去されているかどうかを検出できるようにするためです。ただし、この場合、脱カプセーターは、イングレスのヘッダーの記録として内側を持っているため、トンネル内に導入された異常を検出するために非CEを必要としません。したがって、最も妥協は、異常を明らかにすることよりも安全性の問題を解決することに優先されることが決定されました。
Superficially, the opposite case where the inner and outer carry different ECT values, but with an ECT(1) outer and ECT(0) inner, seems to require a similar compromise. However, because that case is reversed, no compromise is necessary; it is best to forward the outer whether the transport expects the ECT(1) to mean a higher severity than ECT(0) or the same severity. Forwarding the outer either preserves a higher value (if it is higher) or it reveals an anomaly to the transport (if the two ECT codepoints mean the same severity).
表面的には、内側と外側が異なるECT値を運ぶが、ECT（1）外側とECT（0）内側の場合、同様の妥協が必要と思われる反対の場合。ただし、そのケースは逆になっているため、妥協は必要ありません。輸送がECT（1）がECT（0）よりも高い重症度を意味するか、同じ重大度を意味するかを期待するかどうかを外側に転送することが最善です。外側を転送すると、より高い値（高い場合）が保持されるか、輸送の異常が明らかになります（2つのECTコードポイントが同じ重大度を意味する場合）。
The new decapsulation behaviour defined in Section 4.2 adds support for propagation of two severity levels of congestion. However, transports have no way to discover whether there are any legacy tunnels on their path that will not propagate two severity levels. It would have been nice to add a feature for transports to check path support, but this remains an open issue that will have to be addressed in any future standards action to define an end-to-end scheme that requires two severity levels of congestion. PCN avoids this problem because it is only for a controlled region, so all legacy tunnels can be upgraded by the same operator that deploys PCN.
セクション4.2で定義されている新しい脱カプセル化の動作は、2つの重大度レベルの輻輳の伝播のサポートを追加します。ただし、輸送には、2つの重大度レベルを伝播しないレガシートンネルがパスにあるかどうかを発見する方法はありません。パスサポートをチェックするためのトランスポート用の機能を追加することは良かったでしょうが、これは、2つの重大度レベルの混雑を必要とするエンドツーエンドスキームを定義するために、将来の標準アクションで対処する必要があるオープンな問題のままです。PCNは、制御された領域のみであるため、この問題を回避するため、すべてのレガシートンネルはPCNを展開するのと同じオペレーターによってアップグレードできます。
Author's Address
著者の連絡先
Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Bob Briscoe BT B54/77、Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/