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インIPトンネルからの入口と出口に構築する方法を再定義します。カプセル化では、それはRFC 4301のIPsec ECN処理とラインにすべてのIP・イン・IPトンネル（V4またはV6）をもたらすためにRFC 3168に更新します。デカプセル化には、内側と外側のヘッダの未使用の組み合わせのための新たな行動を追加するRFC 3168及びRFC 4301の両方を更新します。新しいルールは、ECNフィールドが正しく輻輳の一つまたは二つの重大度レベルを通知するために使用されているか否かのトンネルを横切って伝播されていることを確認します。前のに対し、唯一の重大度レベルがサポートされていました。トンネルエンドポイントは、このように、下位互換性を確保し、ECNフィールドの既存の用途に影響を与えることなく、任意の順序で更新することができます。それにもかかわらず、（プレ輻輳通知のために、例えば - PCN）は、2つの重大度レベルをサポートしたい事業者は、この新しい仕様の遵守を要求することができます。これらの変化と意義についての推論の徹底的な分析が含まれています。新しい規則は、特定のニーズを満たしていない万一、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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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]）転送要素（例えば、ルータ）は、パケットを廃棄することなく、輻輳の発生を通知することを可能にします。代わりに、明示的に（表1 ECNコードポイントをrecaps）IPヘッダ内の2ビットの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ヘッダをマークします。トンネルカプセル開放後でこの外部ヘッダを削除したとき、1つの発信IPヘッダに内側と外側のIPヘッダのECNフィールドを組み合わせることにより、輻輳マークを伝播する規則に従います。
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 4301トンネルのものと一致する3168本のトンネルRFCの進入動作を更新します。トンネルエンドポイントは、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機構が機能するためにちょうど十分な - ECNとトンネリングは、RFC 3168で定義された場合、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入力は、パケットをカプセル化するために全体ECNフィールドをコピーします。 RFC 4301は、RFC 3168の二つのモード、部分的にECNフィールドをコピーしたものに分注し、そして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 4301）はなかったが、非IPsecトンネル（RFC 3168）は、2ビットの秘密チャネルを遮断しました。出口では、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フィールドを必要とし、それが出口で伝播するシグナリング輻輳の四つの状態を必要とするが、既存のトンネルは、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およびRFC特にすべてのトンネルは、この遵守することを要求できる4つの状態をサポートしたいトンネルの4301オペレータに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の状態をサポートすると同時に、チャンスは、このような邪悪な隠れチャネル処理などの違いを調和、単一一貫した動作に一緒に発散ECNトンネリング仕様を描画するためにとられています。次いで、任意のトンネルを一方的に展開することができ、それは、任意の形態または構成することなく、輻輳制御及び管理スキームの完全な範囲をサポートします。さらに、任意のホストまたはルータが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内IPトンネリングのためのカプセル化とカプセル化解除で共通ECNフィールドの処理を指定します。これは、IPv4またはIPv6のいずれかの内側または外側のヘッダーに使用されているかどうかにかかわらず適用されます。これは、ユニキャストまたはマルチキャストかどうか、任意の宛先アドレスタイプのパケットに適用されます。 PHBの仕様では特に断りのない限り、それは、すべてのDiffservホップごとの挙動（の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で導入された有益な概念は、必要に応じて説明を簡単にrecapsと、全体を通して使用されている差別化されたサービスと同様の問題を提起します。
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]の名前をrecaps。
+------------------+----------------+---------------------------+
| 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
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：カプセル化では、しない-ECT（「00」）新アウターヘッダのECNフィールドをクリアします。
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フィールドがCEである場合ECT（0）コードポイントに設定されている外側の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をrecapsとしてこのセクションでは、規範的で有益ではありません。実験またはECNトンネリング（RFC 2481、RFC 2401、およびRFC 2003）に対して不完全のいずれかであった以前の関連するRFCは簡単に付録Aにインターネットで使用されるトンネルの実装はこれらのRFCのいずれかに準拠しているかどうかの質問をされていない概説されています議論。
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は（[RFC3168]の「フル機能」ECNトンネルと呼ばれる）トンネルが完全ECNをサポートしている場合、と言う、カプセル化は、それが作成され、外側ヘッダに入ってくるヘッダからCEマーキングをコピーしてはなりません。 ECNフィールドが到着したIPヘッダのCEをマークされている場合代わりに、カプセル化は（0）ECTに、外側のヘッダーを設定する必要があります。私たちは、この「リセット」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は、外側ヘッダしない-ECT（「00」）を設定することにより、トンネルの範囲にわたってECN処理をオフにする機能制限モードを提供しました。そこで、このようなパケットはECNでマークされたのではなく、輻輳を示すために削除されます。これは、外側のヘッダに付加ECNマーキングを伝播しないレガシーdecapsulators（[RFC2481]、[RFC2401]及び[RFC2003]）と連動する入力が必要です。彼らはトランスポート層に到達する前に、そうでなければ、そのようなレガシーdecapsulatorsは、輻輳通知を捨てるでしょう。
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.
機能制限モードでも全機能モードのいずれも、外側ヘッダに単にコピー着信ECNフィールドRFC 4301のIPsecカプセル化が使用されます。以前の鍵交換フェーズは、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.
既存のRFCで、発信ヘッダに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.
内側のECNフィールドがない-ECTであればOカプセル開放では、外は無視されます。 RFC 3168は、（ただし、RFC 4301）もカプセル化を解くには、外側にない-ECTの内側および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.
アウターがCEである場合、O、他のすべての場合において、発信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.
「ECNフィールドは、IPsecトンネル内不適切に変更された場合...」RFC 3168のセクション9.2.2はまた、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項（出力デカプセル化）任意のDiffservコードポイントと任意の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
これらのデフォルト値は、特定の要件を満たしていない場合、代替のECNトンネリング方式は、（[RFC4774]及び[RFC3168]のセクション5を参照）、特定のDiffservのPHBによって使用されるスキームをマーキング代替輻輳の定義の一部として導入することができます。そのような代替のECNトンネリングスキームを設計する際に、第7の原理はすべき
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.
続くこと。影響を受けるすべてのトンネルの実装で例外のPHBを扱うの展開負担を過小評価すべきではないとして、しかし、代わりのECNトンネリング方式は、可能な限り避けるべきです。なお、本明細書のデフォルトの動作が十分であればECNトンネル行動について何を述べるPHBの定義のための要件はありません。
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を理解していないトンネルdecapsulatorsとの下位互換性のためであるREQUIRED「通常モード」と「互換モード」、。これらは、入口トンネルエンドポイントだけではなく、全体のトンネルモードであることに留意されたいです。 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には、適切な到着内部ヘッダ（行）の交点のコードポイント及び外部ヘッダ（列）にIPv4ヘッダのチェックサムを送信ECNフィールドを設定しなければなりません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:
内側のECNフィールドが-ECTされていない場合は、O、カプセル化を解くには、以降、他のECNコードポイントを伝播してはなりません。インナーない-ECTが輻輳の指標としてドロップされたパケットに依存していると理解したり、他のECNコードポイント[RFC4774]に応答しないでしょうトランスポートで設定されているマーキングためです。具体的に：
* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
*内側のECNフィールドがない-ECTと外側の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フィールドがない-ECTと外側のECNフィールドが-ECTない、ECT（0）、またはECTでされている場合は（1）、カプセル化を解くわけではありません-ECTにクリア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をサポートする他のすべての場合において、カプセル開放装置は、最高から最低まで重症度のランキングがCEで外側及び内側ECNフィールドのマーキングより重度に発信ECNフィールドを設定しなければならない、ECT（1）、ECT （0）、未-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であり手段（！） 「それは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.
強調表示の組み合わせは、現在使用されていないという理由だけで、他のすべての組み合わせが常に有効であることを意味するものではありません。いくつかは、彼らがそうでなければ、従来の侵入の特定のタイプから到着し、危険なている場合にのみ有効です。したがって、実装は、オペレータが実行時に展開トンネルエンドポイントの特定の構成のために危険な又はCuであることが知られているような追加のヘッダーの組み合わせのためのロギングおよびアラームを設定することを可能にし得ます。
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）（0）、特に、PCNのための最も単純な符号化を可能にする[PCN3in1]（セクション5.3.2を参照）ECTよりマーキングより重篤である場合に定義されることを可能にします。治療ECT（1）のいずれかとECTと同じ（0）以上の重大度レベルは今度は付録Dを指すセクション8におけるECNナンス[RFC3540]の議論で説明されるよう
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節は、二つのカプセル化モードを導入します。これらは、全体としてトンネル入口トンネルエンドポイントのモードのみではないことに留意されたいです。
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の制限された機能モード）で使用されることはありませんがない限り、進入も明示的輻輳が伝播しないトンネルegressesとの下位互換性のために互換性モードを実装しなければなりません通知[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.
カプセル化のいくつかの実装では、常に静的に展開され、従来のカプセル化を解く（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トンネルエンドポイントが必ず鍵交換、したがって、RFC 4301と一緒に導入された元の仕様のためにインターネット鍵交換プロトコルバージョン2（IKEv2の）[RFC5996]を使用して、RFC 4301トンネルの両方の終点とすることができますIKEv2の鍵管理は両端が定義によってRFC 4301に準拠される時点で、完了した後にトンネルのみ形成されているので、もう一方の端は、RFC 4301と互換性があることを確認してください。それは、従来のECNトンネルと対話することはありませんそのためのIPsecトンネル入口には、互換モードを必要としません。現在の仕様に準拠するには、それだけで、既存の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.
実装注：対応ノードが複数のトンネルのための入口である場合、モード設定は、各トンネル入口のために保存する必要があります。ノードは、複数のトンネルの出口がある場合に準拠した出口は一つだけのモードを必要とするためしかし、トンネルのどれも、モード設定を保存する必要がありません。
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.
準拠したカプセル化を解くだけである動作モードを必要とします。対応出力を動的に検出可能に実装されている場合しかし、それは従来のトンネル入口の様々なタイプからのディスカバリ要求に応答する必要があるかもしれません。この仕様は、（独自の）ディスカバリプロトコルによって行われるかもしれない方法ダイナミック交渉定義していませんが、それは安全なインターワーキングを保証するために、いくつかの制約を下に設定します。
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.
出口は、RFC 4301または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.
イングレス：RFC 4301のIPsecカプセル化は、現在の仕様では全く変更されません。これは、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:
出口：RFC 4301の出口は存在仕様に準拠するために、図4の新しいカプセル化解除の動作に更新する必要があります。ただし、変更は下位互換性があります。これまでRFCシリーズで定義されたプロトコルに起因する内側及び外側の組み合わせが影響を受けません。使用されたことのない組み合わせだけでは効果的に既存の行動を変えることなく、4301カプセル開放をRFCする新しい行動を追加、変更されています。 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;
*内側およびCEの外にない、ECTを持つパケットはドロップではなく未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進入はもっぱらRFC 4301のカプセル化から変更されていないカプセル化のREQUIRED通常モードを使用しています。 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.
入口：外部ヘッダへのカプセル化、図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:
出口：RFC 3168の出口は存在仕様に準拠するために、図4の新しいカプセル化解除の動作に更新する必要があります。ただし、変更は下位互換性があります。これまでRFCシリーズで定義されたプロトコルに起因する内側及び外側の組み合わせが影響を受けません。使用されたことのない組み合わせだけでは効果的に既存の行動を変えることなく、3168カプセル開放をRFCする新しい行動を追加、変更されています。 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件の入口は、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.
最優先の目標は、トンネルがIPパケットフローをカプセル化するために起こるものは何でも同じことを意味することができ、同じECN信号を確実にするためです。これは、そうでない場合は利用可能な設計スペースを制約し、それが困難なネットワークと予想通りに動作する新しいプロトコルを設計することができ無償矛盾を、削除します。
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.
通常一貫したECNフィールドの全てのIP-in-IPカプセル化を行うための第4のアップデートのRFC 3168においてモード - 方法と一致両方RFC 4301のIPsec [RFC4301]及びIPインMPLSまたはMPLSイン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を伝播しないレガシーdecapsulatorsとの後方互換性のためにトンネル経由でドロップの使用に切り替えることができるように互換モードも定義されています。
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]）のための標準トラックの提案でした。 ECNフィールドが（RFC 4301およびRFC 5129のように）カプセル化にコピーされた場合PCN過剰トラフィックマーキングは正常に動作します。 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]はECNフィールドのRFC 3168 IPインIPトンネルはPCNドメイン内の任意のトンネル入口に使用することができないと述べています。なお、本明細書に先立ち、これは非弾性トラフィック制御のためのPCNを使用することができないか、すでになどのモバイルIP、VPNのために展開され、多くのトンネルを使用することができないとの赤裸々な選択を残しました。
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つの、及び他のトンネルの一つにさらに断片化することを可能にするよりも、機会がバック単一トンネル挙動に発散仕様を統合するために取られています。リセット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つの視点から、意図しない副作用を引き起こすだろう進入に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制御の観点から、コピーするか、既存の取り決めのためのリセット動作しますが、コピーのいずれかが制御を簡素化し、休憩に標準化過程の上にすでにある少なくとも一つの提案をリセットするためのより多くの可能性を有します。
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は有意な障害を与えていないコピー中に侵入に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で見つかった既存の行動との三つの問題でカプセル化解除のための仕様：
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.既存のルールは、混雑の複数の重大度[RFC4774]、[RFC5559]をシグナリングする代替のECN意味論の導入を防止します。 2ビットのECNフィールドの4つの状態が、輻輳していないと、ECNに対応していない状態に加えて二つの重大度レベルをシグナリングするための余地を提供します。しかし、既存のルールは状態の2（ECT（0）とECT（1））は、常に等価であると仮定しました。これは、不必要にIP（V4およびV6）ヘッダ内の4つのコードポイント（半ビット）のいずれかの使用を制限します。新しいルールは、いずれの場合で動作するように設計されています。 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.
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.
同様に、一般的な将来の校正のために有用であるとして、この問題はすぐに混雑二重大度レベルを使用してプレ輻輳通知（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ワーキンググループは、この問題に無駄なまたは複雑な作業ラウンド数を考慮しなければなりませんでした。彼らは多少、無駄な不正確、または複雑なのいずれかであったので、これらの作業ラウンドの創意工夫を非難するつもりはない、どれも標準化過程のために選ばれませんでした。その代わりに、ベースラインPCNエンコーディングが指定された[RFC5696]渋滞の唯一の重大度レベルを支持したが、実験の拡張として、これらの作業のラウンドのためのスペースを許可されています。
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地域内のすべてのトンネル出口はこの最新仕様に準拠しなければならないことを指定することができます。このステップ、[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).
ミドルボックス（例えば、ファイアウォール）ボックスは、しばしば予期しないものが攻撃かもしれないという理由で、配備されたとき（CU）は、現在、未使用であったヘッダ値を持つパケットをドロップここで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.
前記内側及び外側ヘッダの現在未使用の組み合わせを検討しながら、機会がNOT-ECT内部ヘッダと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.
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）コードポイントに適用されていないと矛盾に見えるかもしれません。その外側はECT（1）の場合に代わりに、カプセル化を解くには、そのまま未-ECTの内側を転送する必要があります。このCUの組み合わせを落としていないための理論的根拠は、将来的に必要であれば、それが使用可能になります保証することです。任意の設定ミスではなく、ECT内側とECT（1）輻輳信号につながった場合に輻輳が次に従って、少なくとも、出力が低下あろう、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（二輻輳の重大度レベル）を固定するために変更されると同時に固定し、一貫製造する価値があることを決定しました。
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に準拠した任意のトンネルエンドポイントと組み合わせた場合、本仕様に準拠トンネルエンドポイントは、RFC 4301、RFC 3168（セクション3を参照）、または付録A（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).
RFC 3168の出口が同じ新しい規則に準拠するように更新されている場合や、他のすべてのものが等しい場合、それはまだ、以前の仕様（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進入はいかなる更新せずに、この新しい仕様に準拠することができますし、それはどんな新しいモード、オプション、または構成を必要としません。だから、他のすべてのものが等しい場合、それは前に（完全な下位互換性）で働いていたすべての出力と同様にインターワークしていきます。
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 3168で定義されたものと同様の保護手段を提供しなければならないが、RFC 3168の進入がECNをオフにすることを確実にするためのルールを定めたときに、この仕様は新しい下位互換性の問題を紹介しません（制限機能モード）、それは正しくECNを伝播しませんレガシー出口（RFC 2481、RFC 2401、またはRFC 2003）、とペアになっている場合。本明細書は、前方これらの規則（セクション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は、スケジューリングのために、異なるホップ単位行動（のPHB）のスイッチと同様に、ECNフィールドをマーキングするための代替的な行動「のスイッチ」にDiffservのコードポイント（DSCP）[RFC2474]を可能にします。 [RFC4774]は、このような代替ECN意味論を設計するための最良の現在の慣行を与え、非常に簡単にトンネリングを検討する必要があることを5.4節で言及しています。補完下記のガイダンスや、代替トンネリングのセマンティクスを必要とする任意の代わりのECN意味論を設計する上で追加のガイダンスを与え、RFC 4774を拡張します。
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フィールドは、対応するトンネル出口が正しく外部ヘッダにトンネルを横切って導入された輻輳マーキングを伝播することが保証されていない限り、NOT-ECT（「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).
それはECNが正しく伝播されることを確立している場合2.カプセル化はまた、外側のヘッダに着信輻輳通知をコピーするべきです。ここでの一般的な原理は、外側ヘッダはトンネル入口（管理および監視に付録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.
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.到着インナーヘッダは-ECTされていない場合、トランスポートは、他のECNコードポイントを理解することはありません。輸送は理解する輻輳表示のみ - 外部ヘッダマーキング明示的輻輳を搬送する場合、代替のスキームは、パケットをドロップすることが期待されます。別のスキームではなく、そのようなパケットを落とすよりも、転送を推奨している場合、それは明らかに、この決定を正当化する必要があります。インナーはない-ECTと外側が輻輳を示すものではありません、他のECNコードポイントを運ぶされている場合は、別の方式では、パケットを転送することができますが、おそらく唯一のないよう-ECT。
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.
到着内部ヘッダではなく、ECT、ECNフィールド以外のものである場合2.その代替デカプセル化方式を転送は、到着内側および外側ヘッダのマーキングより重度の輻輳を反映するべきです。
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.
代替のECN意味論とDiffservの領域と交差するトンネル：代替的輻輳通知のセマンティクスは、特定のDiffservのPHBのために定義されている場合に想定されるように、代替の意味論の範囲は、典型的には、Diffservの領域または領域の境界で囲まれるかもしれない[RFC4774]（例えば、プレ輻輳通知アーキテクチャ[RFC5559]）。トンネルこのような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ナンストンネルカバレッジ：新しいカプセル解除規則がECNナンス[RFC3540]のカバレッジを向上させ、これは、安全上の問題につながっていたとしてRFC 3168およびRFC 4301で、前のルールに比べしかし、ナンスカバレッジは、まだ完璧ではありません別のケース。どちらも、コーナーケースであるので、それらの間の妥協の議論は、付録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）トンネル入口は、ECN処理をオフにするだけでなく、それ自体がECNをオフにするためにRFC 3168出力を求めることができます。なお、本明細書に準拠した出力は、従来の侵入からそのような要求に同意するだろうが、それは常に外側のヘッダーでない-ECTを送信して侵入に依存しています。出口は、外側に他のECNコードポイントを受信した場合、それは実際にはまだ外から発信ヘッダに輻輳マークをコピーするので、それは、通常のようにそれらを処理します。トンネル入口が、5（付録B.1）を図ために、例えば、参照する「I」が「M」が依然としてCE又はECT（1）のオンとオフを切り替えることができ、未ECTにアウターヘッダ内のすべてのECNフィールドを設定します私たちは「E」が唯一かかわらず、それが交渉した言うモードの1つのモードを持っていることを指定しているので、「B」と密かに通信します。私たちは、「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.
また、このドキュメントでは、外側のヘッダーを作成するときではなく、ECNフィールドをリセットするコピー、RFC 4301のIPsecのアーキテクチャの新しい動作とラインにすべてのIPインIPトンネルをもたらすためにRFC 3168 ECNの進入トンネルカプセル化を更新します。
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シリーズのフォークではありません。これは、以前のすべてのトンネリング行動との後方互換性があるため、既存の単一の重大度レベルのスキームは、以前と同じように動作し続けますが、二つの重大度レベルのサポートが徐々にインターネットに追加されます。
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,
彼の洞察に満ちたレビューと機能の配置とアラームを考えるためのより良い方法の患者説明のためのデビッド・ブラックに感謝します。ヘッダーのCUの組み合わせを転送しても安全である例を指摘してダビデとアニルAgarwalさんに感謝します。また、Gorry Fairhurst、テコブーツ、マイケルMenth、ブルースデイビー、トビーMoncasterの付録C.感謝のアイデアのためのアルノー・ジャケのおかげで、
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.
自分の考えと慎重なレビューコメントについてサリー・フロイド、アルフレッドHoenes、ガブリエレCorliano、インゲマル・ヨハンソン、フィリップEardley、そしてデヴィッドハリントン、そしてスティーブン・ハンナ、ベン・キャンベル、それぞれのセキュリティ総局を行うためのIESGのメンバー、一般的なエリアにあり、 IESGはレビュー。
Bob Briscoe is partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme.
ボブ・ブリスコーが一部トリロジーによって資金を供給され、その第七次フレームワーク計画の下で欧州共同体でサポートされている研究プロジェクト（ICT-216372）。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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】ブリスコー、B.、Moncaster、T.、およびM. Menth、進歩、2010年7月ワーク "は、単一のDSCPを使用して、IPヘッダ内のエンコーディング3 PCN-状態"。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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]春、N.、Wetherall、D.、およびD.イーリー、 "ロバスト明示的輻輳通知（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]フロイド、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]デイビー、B.、ブリスコー、B.、およびJ.テイ、 "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]ボッチ、M.とS.ブライアント、「マルチセグメント擬似回線エミュレーションエッジツーエッジのためのアーキテクチャ」、RFC 5659、2009年10月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P.、 "メーターとPCN-ノードのマーキング行動"、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.、ブリスコー、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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン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]夏、Y.、スブラマニアン、L.、ストイカ、I.、およびS・カリヤナラーマンは、PROC "もう一つのビットで十分です"。 SIGCOMM'05、ACM CCR 35（4）37--48、2005年<http://doi.acm.org/10.1145/1080091.1080098>。
Appendix A. Early ECN Tunnelling RFCs
付録A.初期のECNトンネリングのRFC
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内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.
ECNは、[RFC2481]に実験的に導入した場合、レガシー（RFC 2003またはRFC 2401）トンネルは、外側のヘッダーに追加された輻輳マークを捨てたことになるので、RFC 2481は、内側および外側上の組み合わせから発信ヘッダを計算するためのルールを導入しましたカプセル化解除。 RFC 2481はまた、RFC 2401カプセル開放装置は、デカプセル化で外側を捨てることになるため、カプセルにアウターヘッダにECN処理（NOT-ECT）をオフにIPsecトンネルのための第二のモードを導入しました。 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処理をオフその「全機能モード」。この「機能制限モード」は、両方のオペレータが完全に隠れチャネルをブロックするための方法を提供し、従来のトンネル出口（RFC 2481、RFC 2401またはRFC 2003）と連動するRFC 3168進入を可能にしました。
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とは異なり、それは、侵入の唯一のモードです。
Appendix B. Design Constraints
付録B.デザイン制約
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節では新しいカプセル化ルールにつながったこれらの要因間のトレードオフの分析が記載されています。
B.1. Security Constraints
B.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.
情報セキュリティは、（[RFC4301]トランスポート・モードのIPsecを含む）様々なエンドツーエンドのセキュリティソリューションを使用して確保することができるが、一般的に使用されるシナリオは、公衆インターネットを介して2つの物理的に保護されたドメイン間で通信する必要性を伴います。この場合には、単に経路の公的にアクセス可能な部分を横切るトンネルモードでIPsecを使用する特定の管理上の利点があります。パケットがたどる経路は、セキュリティ「ドメイン」を横切ります。ものは、トンネル、そうでなければ保護されていないドメイン全体のIPsecトンネルによって保護1前後の物理的または他の手段によって保護します。エンドポイント「A」および「B」は、トンネルを介して通信を行う場合、図5のシナリオが使用されます。トンネルは「中央の男性」が存在し得る保護されていないインターネット、M.にまたがるながらトンネル入口「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暗号化は、一般的に「M」「B」から「A」からのメッセージを見るのを防ぐために使用されます。 IPsec認証は、「B」またはそれらの内容を変更することを「A」からのメッセージの送信者を装っ「M」を防ぐために使用されます。 「I」「」は「B」と通信するが、「M」に '漏洩情報を防ぐために暗号化を課すことを可能にするために、IPsecトンネルモードを使用することができます。または「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フィールド（並びに、生存時間（TTL）/ホップリミットとDSフィールド）のような変更可能なIPヘッダフィールドは、IPSecの暗号計算に含めることができません。したがって、もし「I」のコピーこれらの可変フィールドが「A」から内部ヘッダのその暗号化をバイパス「M」に隠れチャネルを許可しているれるトンネルを横切って露出している外側のヘッダに。そして、「E」コピーならば、それは「私は」から認証を検証していても、発信に外側のヘッダーからこれらのフィールドは、それが「B」に「M」から隠れチャネルを許可しています。
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
IP層でのECNを下流ノードに向かって輻輳リソースから渋滞情報を運ぶように設計されています。典型的には、効果的に下流側搬送輻輳リソース上の負荷を調節することができ、輻輳の上流の点に戻って何とか情報を送るかもしれないが、他のアクションが可能[RFC3168]は、上記ユニキャストシナリオの観点から第6章、ECN意向
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.
（「A」にフィードバックする「B」の）「B」に「M」から（輻輳シグナリングのため）情報チャネルを作成します。そのため、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処理ルールを使用して、チャネル帯域幅は、「M」と「B」に「M」からのデータグラムあたり1ビットに「A」からのデータグラム当たり2ビットである（「E」は、2-の組み合わせを制限するためそれがコピーされますビットECNフィールド）。両方の場合において、隠れチャネル帯域幅はさらにマーキング任意の実際の混雑からのノイズによって低減されます。 RFC 4301は、これらの隠れチャネルが十分に管理可能な脅威と見なされるために限定されていることを意味します。しかし、より大きな（6ビット）DSフィールドに関して、RFC 4301の同じセクションはないコピーがデフォルトであると言いますが、構成オプションは、コピーは、「ローカル管理者は、隠れチャネルは、コピーで提供するかどうかを判断できるように許可することができますコピーのメリットを上回るこれらのビット」。もちろん、DSフィールドをコピーすることを計画し、管理者は、それがデータグラムあたり8ビットのひそかなチャンネルを作成し、ECNフィールドと連結することができることを考慮に入れる必要があります。
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フィールドをトンネリングするための二つの概念モデルは、管理者が、トラフィックコンディショニング[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つのトンネリングモデルと同等の標準化。それは、そのシンプルさが特に混雑指摘をコピーしないで与えられた管理者はセキュリティにおける小さな増分のオプションは、真剣にみんなのネットワークサービスに害を及ぼす可能性が許可するよりも重要だったとみなします。
B.2. Control Constraints
B.2。制御の制約
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つの用語は同義であろう。用語故意実際の負荷を制御しないソース・アプリケーションを含むが、べき「負荷制御OF_機能_capable」を注意することは（例えば、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.
フォーカスが今かどうか制御ループと管理監視作業（図6）に移行するので、今説明したIPsecのものと同様のトンネリングシナリオは現在、異なるセキュリティドメインせず、考慮されます。トンネル内のリソースは、明示的輻輳を通知することができるようにされ、フィードバック経路は、「A」と「B」からのものである場合、確かにするための送信ヘッダを外部ヘッダからマーキング任意CEをコピーするために、「E」のために必要となります以降「B」への送信。そうでない場合は、「M」のようなリソースから輻輳通知は、バックロード・レギュレータ（「A」）に供給することができません。 「私は」外側のヘッダに入ってくるからCEマーキングをコピーするためにしかし、それは必要ないないようです。リソース「R」が輻輳している場合、例えば、それは「I」が外側のヘッダに輻輳フィールドをコピーし、「E」はバック発信にコピーすることなく、内部ヘッダの輻輳フィールドを使用して、「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マーキングをコピーするのに対し、正しい制御動作につながります。
B.3. Management Constraints
B.3。管理制約
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は、トンネルを横切って導入された輻輳レベルを推定するトンネル出口のための簡単かつ正確な方法を与えます。これは、入口コピーまたはリセットするかどうか、輻輳のマーキングとは無関係に動作します。
Appendix C. Contribution to Congestion across a Tunnel
トンネル全体で輻輳の付録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全機能モード）でリセットされた場合には容易であるだけトンネルに沿って導入輻輳を監視するために作ることが表されています。出口がトンネル経由で導入された輻輳を測定するために、以下に示すように、しかし、実際には入口でコピー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マークを持っていることを計測言います。これは、入口に到着するパケットは、既に30％の輻輳を経験していたことを意味します。しかし、それはトンネル全体で12％の輻輳があったわけではありません。トンネルを通過輻輳の正確な計算はP_T = 12 /（100-30）= 70分の12 = 17％です。これは、出力が測定しやすいです。これは単に、外部ヘッダ（12）にCEマークを有する内部ヘッダ（70）でマークされていないパケットの割合です。この技術は、入口コピーかどう働くか、それは入口準拠のRFCいると確認されていません出口で使用することができますので、CEマーキングをリセットします。
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
ECT（1）内部及びECT（0）外でデキャップの付録D.妥協
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ナンス[RFC3540]を使用することができるようになりました。それは入口におけるヘッダのレコードとして内側を持っているのでしかし、この場合には、カプセル開放装置は、トンネル内に導入された任意の異常を検出するためにナンスを必要としません。したがって、異常が少なくとも検出され、内部的に対処する可能性があるため、最良の妥協点は、異常を明らかに上の安全性の問題の解決に優先権を与えることであろうことを決定しました。
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値を運ぶ逆の場合が、（1）外側ECT及びECT（0）内で、同様の妥協を必要とすると思われます。その場合は、逆にされているのでしかし、一切の妥協は必要ありません。それは、トランスポートは、ECT（1）ECTよりも高い重大度（0）または同じ重要度を意味する予定かどうか、外側を転送するのが最善です。 （それが高い場合）、外側は高い値を維持いずれかまたは（二ECTコードポイントが同じ重症度を意味する場合）、それが輸送に異常を明らかに転送します。
Appendix E. Open Issues
付録E.未解決の問題
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
ボブ・ブリスコーBT B54 / 77、Adastral公園MartleshamヒースイプスウィッチIP5 3RE英国
Phone: +44 1473 645196 EMail: bob.briscoe@bt.com URI: http://bobbriscoe.net/
電話：+44 1473 645196 Eメール：bob.briscoe@bt.com URI：http://bobbriscoe.net/