Network Working Group K. Ramakrishnan
Request for Comments: 3168 TeraOptic Networks
Updates: 2474, 2401, 793 S. Floyd
Obsoletes: 2481 ACIRI
Category: Standards Track D. Black
EMC
September 2001
The Addition of Explicit Congestion Notification (ECN) to IP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header.
このメモは、IPヘッダ内の2ビットのECNの使用を含むTCP及びIPのECN（明示的輻輳通知）の取り込みを、指定します。
Table of Contents
目次
1. Introduction.................................................. 3
2. Conventions and Acronyms...................................... 5
3. Assumptions and General Principles............................ 5
4. Active Queue Management (AQM)................................. 6
5. Explicit Congestion Notification in IP........................ 6
5.1. ECN as an Indication of Persistent Congestion............... 10
5.2. Dropped or Corrupted Packets................................ 11
5.3. Fragmentation............................................... 11
6. Support from the Transport Protocol........................... 12
6.1. TCP......................................................... 13
6.1.1 TCP Initialization......................................... 14
6.1.1.1. Middlebox Issues........................................ 16
6.1.1.2. Robust TCP Initialization with an Echoed Reserved Field. 17
6.1.2. The TCP Sender............................................ 18
6.1.3. The TCP Receiver.......................................... 19
6.1.4. Congestion on the ACK-path................................ 20
6.1.5. Retransmitted TCP packets................................. 20
6.1.6. TCP Window Probes......................................... 22
7. Non-compliance by the End Nodes............................... 22
8. Non-compliance in the Network................................. 24
8.1. Complications Introduced by Split Paths..................... 25
9. Encapsulated Packets.......................................... 25
9.1. IP packets encapsulated in IP............................... 25
9.1.1. The Limited-functionality and Full-functionality Options.. 27
9.1.2. Changes to the ECN Field within an IP Tunnel.............. 28
9.2. IPsec Tunnels............................................... 29
9.2.1. Negotiation between Tunnel Endpoints...................... 31
9.2.1.1. ECN Tunnel Security Association Database Field.......... 32
9.2.1.2. ECN Tunnel Security Association Attribute............... 32
9.2.1.3. Changes to IPsec Tunnel Header Processing............... 33
9.2.2. Changes to the ECN Field within an IPsec Tunnel........... 35
9.2.3. Comments for IPsec Support................................ 35
9.3. IP packets encapsulated in non-IP Packet Headers............ 36
10. Issues Raised by Monitoring and Policing Devices............. 36
11. Evaluations of ECN........................................... 37
11.1. Related Work Evaluating ECN................................ 37
11.2. A Discussion of the ECN nonce.............................. 37
11.2.1. The Incremental Deployment of ECT(1) in Routers.......... 38
12. Summary of changes required in IP and TCP.................... 38
13. Conclusions.................................................. 40
14. Acknowledgements............................................. 41
15. References................................................... 41
16. Security Considerations...................................... 45
17. IPv4 Header Checksum Recalculation........................... 45
18. Possible Changes to the ECN Field in the Network............. 45
18.1. Possible Changes to the IP Header.......................... 46
18.1.1. Erasing the Congestion Indication........................ 46
18.1.2. Falsely Reporting Congestion............................. 47
18.1.3. Disabling ECN-Capability................................. 47
18.1.4. Falsely Indicating ECN-Capability........................ 47
18.2. Information carried in the Transport Header................ 48
18.3. Split Paths................................................ 49
19. Implications of Subverting End-to-End Congestion Control..... 50
19.1. Implications for the Network and for Competing Flows....... 50
19.2. Implications for the Subverted Flow........................ 53
19.3. Non-ECN-Based Methods of Subverting End-to-end Congestion
Control.................................................... 54
20. The Motivation for the ECT Codepoints........................ 54
20.1. The Motivation for an ECT Codepoint........................ 54
20.2. The Motivation for two ECT Codepoints...................... 55
21. Why use Two Bits in the IP Header?........................... 57
22. Historical Definitions for the IPv4 TOS Octet................ 58
23. IANA Considerations.......................................... 60
23.1. IPv4 TOS Byte and IPv6 Traffic Class Octet................. 60
23.2. TCP Header Flags........................................... 61
23.3. IPSEC Security Association Attributes....................... 62
24. Authors' Addresses........................................... 62
25. Full Copyright Statement..................................... 63
We begin by describing TCP's use of packet drops as an indication of congestion. Next we explain that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers can instead set the Congestion Experienced (CE) codepoint in the IP header of packets from ECN-capable transports. We describe when the CE codepoint is to be set in routers, and describe modifications needed to TCP to make it ECN-capable. Modifications to other transport protocols (e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. We also describe in this document the issues involving the use of ECN within IP tunnels, and within IPsec tunnels in particular.
私たちは、混雑のしるしとしてパケット滴のTCPの使用を記述することから始めます。次は、輻輳の指標として低下ルータは、キューがオーバーフローする前に、輻輳を検出するインターネットインフラストラクチャ、アクティブキュー管理（例えば、RED）を添加して、ルータはもはやパケットに限定されることを説明しません。ルータは、代わりにECN対応のトランスポートからのパケットのIPヘッダで経験輻輳（CE）コードポイントを設定することができます。私たちは、CEコードポイントは、ルータに設定する場合について説明し、それがECN-可能にするためにTCPに必要な変更を説明します。これらのプロトコルは、標準化プロセスを通じて開発事前される他のトランスポートプロトコル（例えば、信頼性のないユニキャストまたはマルチキャスト、信頼できるマルチキャスト、他の信頼できるユニキャストトランスポートプロトコル）への変形が考えられます。また、IPトンネル内のECNの使用に関する問題、特にIPsecトンネル内でこの文書で説明します。
One of the guiding principles for this document is that, to the extent possible, the mechanisms specified here be incrementally deployable. One challenge to the principle of incremental deployment has been the prior existence of some IP tunnels that were not compatible with the use of ECN. As ECN becomes deployed, non-compatible IP tunnels will have to be upgraded to conform to this document.
この文書の指針の一つは、可能な限り、ここで指定されたメカニズムは増分的展開である、ということです。増分展開の原則への1つの課題は、ECNの使用と互換性がありませんでしたいくつかのIPトンネルの前に存在してきました。 ECNが展開になると、非互換性のあるIPトンネルは、この文書に準拠するようにアップグレードする必要があります。
This document obsoletes RFC 2481, "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet Community. This document also updates RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", in defining the ECN field in the IP header, RFC 2401, "Security Architecture for the Internet Protocol" to change the handling of IPv4 TOS Byte and IPv6 Traffic Class Octet in tunnel mode header construction to be compatible with the use of ECN, and RFC 793, "Transmission Control Protocol", in defining two new flags in the TCP header.
この文書は、インターネットコミュニティのための実験プロトコルとしてECNを定義し、「IPへの明示的輻輳通知（ECN）を追加するための提案を」RFC 2481を廃止します。この資料はまた変更するには、RFC 2401、IPヘッダにECNフィールドを定義するには、「インターネットプロトコルのためのセキュリティアーキテクチャ」RFC 2474、「IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義」を更新しますTCPヘッダに二つの新しいフラグを定義するECNの使用に適合するように、トンネルモードのヘッダ構成でIPv4のTOSバイトとIPv6のトラフィッククラスオクテットの取り扱い、およびRFC 793、「伝送制御プロトコル」、。
TCP's congestion control and avoidance algorithms are based on the notion that the network is a black-box [Jacobson88, Jacobson90]. The network's state of congestion or otherwise is determined by end-systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. Treating the network as a "black-box" and treating loss as an indication of congestion in the network is appropriate for pure best-effort data carried by TCP, with little or no sensitivity to delay or loss of individual packets. In addition, TCP's congestion management algorithms have techniques built-in (such as Fast Retransmit and Fast Recovery) to minimize the impact of losses, from a throughput perspective. However, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets. Interactive traffic such as telnet, web-browsing, and transfer of audio and video data can be sensitive to packet losses (especially when using an unreliable data delivery transport such as UDP) or to the increased latency of the packet caused by the need to retransmit the packet after a loss (with the reliable data delivery semantics provided by TCP).
TCPの輻輳制御と回避アルゴリズムは、ネットワークがブラックボックスであるという概念[Jacobson88、Jacobson90]に基づいています。ネットワークの状態輻輳又はそうでなければ、徐々にネットワークが混雑になり、パケットになるまで（ネットワークに傑出しているパケットのウィンドウを増加させることによって）ネットワークの負荷を増大させることによって、ネットワークの状態のためのプローブエンドシステムによって決定されます失われました。 「ブラックボックス」のようなネットワークを処理し、ネットワークの輻輳の指標として損失を治療する遅延または個々のパケットの損失をほとんどまたは全く感度で、TCPによって運ば純粋なベストエフォート型のデータのために適切です。また、TCPの輻輳管理アルゴリズムは、スループットの観点から、損失の影響を最小限にする（例えば、高速再送信及び高速リカバリなど）を組み込み技術を持っています。しかし、これらのメカニズムは、実際には1つの以上の個々のパケットの遅延や損失に敏感なアプリケーションを支援することを意図していません。インタラクティブtelnetなどのトラフィック、ウェブ・ブラウジング、オーディオおよびビデオデータの転送は、パケットロスの影響を受けやすいことができます（UDPなどの信頼性の低いデータ配信トランスポートを使用して特に）、または再送信する必要性によって引き起こされるパケットの待ち時間の増加に（TCPが提供する信頼性の高いデータ配信セマンティクス）の損失後のパケット。
Since TCP determines the appropriate congestion window to use by gradually increasing the window size until it experiences a dropped packet, this causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow (e.g., tail-drop on queue overflow), this means that some of the packets of latency-sensitive flows may be dropped. In addition, such drop policies lead to synchronization of loss across multiple flows.
TCPは徐々に増加し、ウィンドウのサイズによって使用する適切な輻輳ウィンドウを決定するので、それがドロップされたパケットを経験するまで、これがボトルネックルータのキューが構築させます。各個々のフロー（キューのオーバーフローに、例えば、テールドロップ）によって配置負荷に対して敏感ではないルータで最もパケットドロップポリシーでは、これは、レイテンシに敏感なフローのパケットの一部が廃棄されてもよいことを意味します。また、このようなドロップポリシーは、複数のフロー間で損失の同期につながります。
Active queue management mechanisms detect congestion before the queue overflows, and provide an indication of this congestion to the end nodes. Thus, active queue management can reduce unnecessary queuing delay for all traffic sharing that queue. The advantages of active queue management are discussed in RFC 2309 [RFC2309]. Active queue management avoids some of the bad properties of dropping on queue overflow, including the undesirable synchronization of loss across multiple flows. More importantly, active queue management means that transport protocols with mechanisms for congestion control (e.g., TCP) do not have to rely on buffer overflow as the only indication of congestion.
アクティブキュー管理機構は、キューがオーバーフローする前に輻輳を検出し、エンドノードこの輻輳の指標を提供します。このように、アクティブキュー管理は、そのキューを共有するすべてのトラフィックのために不必要なキューイング遅延を減らすことができます。アクティブキュー管理の利点は、RFC 2309 [RFC2309]に記載されています。アクティブキュー管理は、複数のフロー間で損失の望ましくない同期を含め、キューのオーバーフローの上に落下の悪い性質のいくつかを回避することができます。さらに重要なことは、アクティブキュー管理は、輻輳制御（例えば、TCP）のためのメカニズムを有するトランスポートプロトコルは、輻輳の唯一の指標としてバッファオーバーフローに依存する必要がないことを意味します。
Active queue management mechanisms may use one of several methods for indicating congestion to end-nodes. One is to use packet drops, as is currently done. However, active queue management allows the router to separate policies of queuing or dropping packets from the policies for indicating congestion. Thus, active queue management allows routers to use the Congestion Experienced (CE) codepoint in a packet header as an indication of congestion, instead of relying solely on packet drops. This has the potential of reducing the impact of loss on latency-sensitive flows.
アクティブキュー管理機構は、ノードを終了する輻輳を示すためにいくつかの方法のいずれかを使用してもよいです。一つは、現在行われているように、パケットドロップを使用することです。しかし、アクティブキュー管理は、ルータが輻輳を示すための政策からのキューイングまたはドロップするパケットのポリシーを分離することができます。したがって、アクティブキュー管理は、ルータが輻輳の代わりにパケットドロップのみに頼るの指標としてパケットヘッダにおいて経験輻輳（CE）コードポイントを使用することを可能にします。これは、遅延に敏感なフロー損失の影響を低減させる可能性を有します。
There exist some middleboxes (firewalls, load balancers, or intrusion detection systems) in the Internet that either drop a TCP SYN packet configured to negotiate ECN, or respond with a RST. This document specifies procedures that TCP implementations may use to provide robust connectivity even in the presence of such equipment.
ECNを交渉するために構成されたTCP SYNパケットをドロップ、またはRSTで応答のいずれか、インターネットでいくつかの中間箱（ファイアウォール、ロードバランサ、または侵入検知システム）が存在します。このドキュメントでは、TCPの実装でも、このような機器の存在下で、強固な接続性を提供するために使用することができます手順を指定します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
In this section, we describe some of the important design principles and assumptions that guided the design choices in this proposal.
このセクションでは、この提案では、設計上の選択を導いた重要な設計原理と仮定のいくつかを説明します。
* Because ECN is likely to be adopted gradually, accommodating migration is essential. Some routers may still only drop packets to indicate congestion, and some end-systems may not be ECN-capable. The most viable strategy is one that accommodates incremental deployment without having to resort to "islands" of ECN-capable and non-ECN-capable environments.
* ECNが徐々に採用される可能性が高いので、移行を収容することが不可欠です。一部のルータは、まだのみ輻輳を示すために、パケットをドロップすることができ、いくつかのエンドシステムは、ECN-ことができない可能性があります。最も実行可能な戦略は、ECN対応の「島」と非ECN対応の環境に頼らずに、増分展開を収納するものです。
* New mechanisms for congestion control and avoidance need to co-exist and cooperate with existing mechanisms for congestion control. In particular, new mechanisms have to co-exist with TCP's current methods of adapting to congestion and with routers' current practice of dropping packets in periods of congestion.
*輻輳制御と回避のための新しいメカニズムが共存し、輻輳制御のための既存のメカニズムと協力する必要があります。具体的には、新しいメカニズムが輻輳し、輻輳期間中のパケットをドロップするルータの現在の慣行と適応のTCPの現在の方法と共存しなければなりません。
* Congestion may persist over different time-scales. The time scales that we are concerned with are congestion events that may last longer than a round-trip time.
*混雑は異なる時間スケールにわたり持続します。私たちはと懸念している時間スケールは、往復時間よりも長く続くことが輻輳イベントです。
* The number of packets in an individual flow (e.g., TCP connection or an exchange using UDP) may range from a small number of packets to quite a large number. We are interested in managing the congestion caused by flows that send enough packets so that they are still active when network feedback reaches them.
*個々の流れ（例えば、TCP接続またはUDPを使用して交換）内のパケット数は、パケットの少数の非常に大きい数の範囲であってもよいです。私たちは、ネットワークのフィードバックがそれらに到達したとき、彼らはまだアクティブになるように、十分なパケットを送信する流れによって引き起こされる輻輳管理に興味を持っています。
* Asymmetric routing is likely to be a normal occurrence in the Internet. The path (sequence of links and routers) followed by data packets may be different from the path followed by the acknowledgment packets in the reverse direction.
*非対称ルーティングは、インターネットで通常発生する可能性があります。データパケットがたどる経路（リンク及びルータの配列）は、逆方向の確認応答パケットがたどる経路は異なっていてもよいです。
* Many routers process the "regular" headers in IP packets more efficiently than they process the header information in IP options. This suggests keeping congestion experienced information in the regular headers of an IP packet.
*多くのルータは、彼らがIPオプションのヘッダー情報を処理するよりも効率的にIPパケットに「通常の」ヘッダを処理します。これは、IPパケットの定期的なヘッダに輻輳経験豊富な情報を保持示唆しています。
* It must be recognized that not all end-systems will cooperate in mechanisms for congestion control. However, new mechanisms shouldn't make it easier for TCP applications to disable TCP congestion control. The benefit of lying about participating in new mechanisms such as ECN-capability should be small.
*ないすべてのエンドシステムは、輻輳制御のためのメカニズムに協力することを認識しなければなりません。しかし、新しいメカニズムは、それが簡単にTCPアプリケーションは、TCPの輻輳制御を無効にするために作るべきではありません。このようECN-機能などの新しいメカニズムの参加について嘘の利益は小さいはずです。
Random Early Detection (RED) is one mechanism for Active Queue Management (AQM) that has been proposed to detect incipient congestion [FJ93], and is currently being deployed in the Internet [RFC2309]. AQM is meant to be a general mechanism using one of several alternatives for congestion indication, but in the absence of ECN, AQM is restricted to using packet drops as a mechanism for congestion indication. AQM drops packets based on the average queue length exceeding a threshold, rather than only when the queue overflows. However, because AQM may drop packets before the queue actually overflows, AQM is not always forced by memory limitations to discard the packet.
ランダム早期検出（RED）初期の混雑[FJ93]を検出することが提案されており、現在はインターネット[RFC2309]で展開されているアクティブキュー管理（AQM）ごとに1つのメカニズムです。 AQMは、輻輳表示のためのいくつかの選択肢のいずれかを使用して一般的なメカニズムであることを意味するが、ECNの非存在下で、AQM輻輳表示するためのメカニズムとして低下パケットを使用することに制限されています。 AQMはなく、キューがオーバーフローした場合にのみよりも、閾値を超える平均キュー長に基づいてパケットをドロップ。キューが実際にオーバーフローする前に、AQMは、パケットをドロップする可能性があるためしかし、AQMは常にパケットを廃棄するようにメモリの制限によって強制されていません。
AQM can set a Congestion Experienced (CE) codepoint in the packet header instead of dropping the packet, when such a field is provided in the IP header and understood by the transport protocol. The use of the CE codepoint with ECN allows the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses. We use the term 'CE packet' to denote a packet that has the CE codepoint set.
AQMは、代わりに、そのようなフィールドは、IPヘッダに設けられ、トランスポートプロトコルによって理解されているパケットをドロップするパケットのヘッダに経験輻輳（CE）コードポイントを設定することができます。 ECNとCEコードポイントを使用すると、パケットロスの後に再送信への過度の遅延の可能性を避け、受信機（s）は、パケットを受信することができます。私たちは、CEコードポイントが設定されているパケットを示すために、長期的「CEパケット」を使用します。
This document specifies that the Internet provide a congestion indication for incipient congestion (as in RED and earlier work [RJ90]) where the notification can sometimes be through marking packets rather than dropping them. This uses an ECN field in the IP header with two bits, making four ECN codepoints, '00' to '11'. The ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the data sender to indicate that the end-points of the transport protocol are ECN-capable; we call them ECT(0) and ECT(1) respectively. The phrase "the ECT codepoint" in this documents refers to either of the two ECT codepoints. Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.
この文書は、インターネット通知が時々パケットマーキングではなく、それらをドロップを介し得る（REDおよび以前の研究[RJ90]のように）初期輻輳のために輻輳表示を提供することを指定します。これは、4つのECNコードポイント、「11」を「00」を作る、2つのビットを有するIPヘッダ内のECNフィールドを使用します。 ECN-可能なトランスポート（ECT）コードポイント「10」および「01」は、トランスポートプロトコルのエンドポイントは、ECN-可能であることを示すために、データ送信者によって設定されます。我々は、ECT（0）とECT（1）それぞれそれらを呼び出します。この文書では、フレーズ「ECTコードポイント」は、2つのECTコードポイントのいずれかを意味します。ルータは、同等のものとしてECT（0）とECT（1）コードポイントを扱います。送信者は、パケットごとに、ECTを示すために、ECT（0）かECT（1）コードポイントのいずれかを自由に使用できます。
The use of both the two codepoints for ECT, ECT(0) and ECT(1), is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol. Guidelines for the senders and receivers to differentiate between the ECT(0) and ECT(1) codepoints will be addressed in separate documents, for each transport protocol. In particular, this document does not address mechanisms for TCP end-nodes to differentiate between the ECT(0) and ECT(1) codepoints. Protocols and senders that only require a single ECT codepoint SHOULD use ECT(0).
ECT、ECTのための2つのコードポイントの両方の使用（0）とECT（1）は、データ送信側のためのメカニズムは、そのネットワーク要素がCEコードポイントを消去しないされていることを確認することを可能にする欲求によって主に動機付けされ、そのデータ受信器がありますトランスポートプロトコルによって要求されるよう適切に、送信者にCEコードポイントが設定されたパケットの受信を通知します。送信側と受信側のためのガイドラインは、（1）コードポイントは、各トランスポートプロトコルのために、別の文書に対処するECT（0）とECT区別します。 TCPエンドノードがECT（0）とECT（1）コードポイントを区別するために、特に、この文書は、メカニズムに対処していません。一つだけECTコードポイントを必要とするプロトコルと送信者は、ECT（0）を使用する必要があります。
The not-ECT codepoint '00' indicates a packet that is not using ECN. The CE codepoint '11' is set by a router to indicate congestion to the end nodes. Routers that have a packet arriving at a full queue drop the packet, just as they do in the absence of ECN.
ない-ECTコードポイント「00」は、ECNを使用していないパケットを示しています。 CEコードポイント「11」は、エンドノードに輻輳を示すためにルータによって設定されています。フルキューに到着するパケットを持っているルータは、彼らがECNの不存在下で行うのと同様に、パケットをドロップします。
+-----+-----+
| ECN FIELD |
+-----+-----+
ECT CE [Obsolete] RFC 2481 names for the ECN bits.
0 0 Not-ECT
0 1 ECT(1)
1 0 ECT(0)
1 1 CE
Figure 1: The ECN Field in IP.
図1：IPでECNフィールド。
The use of two ECT codepoints essentially gives a one-bit ECN nonce in packet headers, and routers necessarily "erase" the nonce when they set the CE codepoint [SCWA99]. For example, routers that erased the CE codepoint would face additional difficulty in reconstructing the original nonce, and thus repeated erasure of the CE codepoint would be more likely to be detected by the end-nodes. The ECN nonce also can address the problem of misbehaving transport receivers lying to the transport sender about whether or not the CE codepoint was set in a packet. The motivations for the use of two ECT codepoints is discussed in more detail in Section 20, along with some discussion of alternate possibilities for the fourth ECT codepoint (that is, the codepoint '01'). Backwards compatibility with earlier ECN implementations that do not understand the ECT(1) codepoint is discussed in Section 11.
2 ECTコードポイントの使用は、本質的に、パケットヘッダ内の1ビットECN nonceを与え、それらがCEコードポイント[SCWA99]を設定すると、ルータは、必ずしもnonceを「消去します」。例えば、CEコードポイントを消去ルータは、元のナンスを再構成における追加の困難に直面することになるので、CEコードポイントの繰り返しの消去は、エンドノードによって検出される可能性が高いであろう。 ECNナンスもCEコードポイントがパケットに設定されたかどうかについてのトランスポート送信者に横たわっているトランスポート・レシーバを不正な動作の問題に対処することができます。 2 ECTコードポイントを使用するための動機は、第ECTコードポイント（すなわち、コードポイント「01」である）の代替の可能性のいくつかの議論と共に、セクション20で詳しく説明されています。 （1）コードポイントが、セクション11で説明されてECTを理解していない以前ECN実装との下位互換性。
In RFC 2481 [RFC2481], the ECN field was divided into the ECN-Capable Transport (ECT) bit and the CE bit. The ECN field with only the ECN-Capable Transport (ECT) bit set in RFC 2481 corresponds to the ECT(0) codepoint in this document, and the ECN field with both the
RFC 2481 [RFC2481]では、ECNフィールドは、ECN-できるトランスポート（ECT）ビットとCEビットに分割しました。唯一ECN-可能なトランスポート（ECT）とECNフィールドが両方と、この文書に記載されているECT（0）コードポイント、およびECNフィールドに対応RFC 2481に設定されたビット
ECT and CE bit in RFC 2481 corresponds to the CE codepoint in this document. The '01' codepoint was left undefined in RFC 2481, and this is the reason for recommending the use of ECT(0) when only a single ECT codepoint is needed.
RFC 2481でECTとCEビットは、この文書のCEコードポイントに対応しています。 「01」のコードポイントは、RFC 2481で未定義のまま、これが唯一のECTコードポイントが必要なとき（0）ECTの使用を推奨する理由ですました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint ECN: Explicit Congestion Notification
DSCP：差別化サービスコードポイントのECN：明示的輻輳通知
Figure 2: The Differentiated Services and ECN Fields in IP.
図2：IPとの差別化されたサービスとECNフィールド。
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field. The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6, and the ECN field is defined identically in both cases. The definitions for the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet have been superseded by the six-bit DS (Differentiated Services) Field [RFC2474, RFC2780]. Bits 6 and 7 are listed in [RFC2474] as Currently Unused, and are specified in RFC 2780 as approved for experimental use for ECN. Section 22 gives a brief history of the TOS octet.
IPv4のTOSオクテットのビット6と7は、ECNフィールドとして指定されます。 IPv4のTOSオクテットは、IPv6におけるトラフィッククラスオクテットに対応し、ECNフィールドは、両方の場合で同じ定義されています。 IPv4のTOSオクテット[RFC791]とIPv6のトラフィッククラスオクテットの定義は、6ビットのDS（差別化サービス）フィールド[RFC2474、RFC2780]に置き換えられています。ビット6と7は、現在使用されていない[RFC2474]に記載されている、およびECNのための実験的使用のために承認されたRFC 2780に指定されています。セクション22は、TOSオクテットの簡単な歴史を提供します。
Because of the unstable history of the TOS octet, the use of the ECN field as specified in this document cannot be guaranteed to be backwards compatible with those past uses of these two bits that pre-date ECN. The potential dangers of this lack of backwards compatibility are discussed in Section 22.
そのためTOSオクテットの不安定な歴史を、この文書で指定されたECNフィールドの使用は、事前に日付ECNこれら2つのビットのものを過去の使用と後方互換性を保証することはできません。後方互換性の欠如の潜在的な危険性は、セクション22で議論されています。
Upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems MUST be essentially the same as the congestion control response to a *single* dropped packet. For example, for ECN-Capable TCP the source TCP is required to halve its congestion window for any window of data containing either a packet drop or an ECN indication.
単一のCEパケットのECN-可能な輸送によって受信すると、輻輳制御アルゴリズムは、本質的に単一* *に輻輳制御応答と同じでなければなりませんエンドシステムで追跡パケットを落としました。例えば、ECN-可能なTCPのソースTCPは、パケットのドロップやECN指示のいずれかを含むデータの任意のウィンドウのために輻輳ウィンドウを半分にすることが要求されます。
One reason for requiring that the congestion-control response to the CE packet be essentially the same as the response to a dropped packet is to accommodate the incremental deployment of ECN in both end-systems and in routers. Some routers may drop ECN-Capable packets (e.g., using the same AQM policies for congestion detection) while other routers set the CE codepoint, for equivalent levels of congestion. Similarly, a router might drop a non-ECN-Capable packet but set the CE codepoint in an ECN-Capable packet, for equivalent levels of congestion. If there were different congestion control responses to a CE codepoint than to a packet drop, this could result in unfair treatment for different flows.
CEパケットに輻輳制御応答がドロップされたパケットへの応答と本質的に同じであることを要求するための一つの理由は、両方のエンドシステムおよびルータにおけるECNの増分展開に適応することです。他のルータが輻輳の同等レベルの、CEコードポイントを設定しながら、いくつかのルータ（例えば、輻輳検出のための同じAQMポリシーを使用して）ECN-可能なパケットをドロップすることができます。同様に、ルータは、非ECN対応のパケットをドロップするかもしれないが、混雑の等価レベルについて、ECN-可能なパケットでCEコードポイントを設定します。パケットドロップによりCEコードポイントに異なる輻輳制御応答があった場合、これは、異なるフローのための不当な扱いになる可能性があります。
An additional goal is that the end-systems should react to congestion at most once per window of data (i.e., at most once per round-trip time), to avoid reacting multiple times to multiple indications of congestion within a round-trip time.
追加の目標は、エンドシステムは、往復時間内混雑の複数の適応症に複数回の反応を避けるために、（すなわち、高々一回のラウンドトリップ時間あたり）で最も一度データのウィンドウごとの混雑に反応すべきであるということです。
For a router, the CE codepoint of an ECN-Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes. When the router's buffer is not yet full and the router is prepared to drop a packet to inform end nodes of incipient congestion, the router should first check to see if the ECT codepoint is set in that packet's IP header. If so, then instead of dropping the packet, the router MAY instead set the CE codepoint in the IP header.
ルータが他のエンドノードに輻輳の指標としてパケットを落としたならば、ルータは、ECN-可能なパケットのCEコードポイントにのみ設定されるべきです。ルータのバッファがまだ満杯でないと、ルータが初期の混雑のエンドノードを知らせるために、パケットをドロップする用意があると、ルータは最初ECTコードポイントは、そのパケットのIPヘッダに設定されているかどうかを確認する必要があります。もしそうなら、代わりにパケットをドロップすると、ルータではなく、IPヘッダのCEコードポイントを設定することができます。
An environment where all end nodes were ECN-Capable could allow new criteria to be developed for setting the CE codepoint, and new congestion control mechanisms for end-node reaction to CE packets. However, this is a research issue, and as such is not addressed in this document.
すべてのエンドノードがECN対応した環境は、CEパケットにエンドノード反応のための新しいCEコードポイントを設定するために開発される基準、及び新たな輻輳制御機構を可能性があります。しかし、これは研究課題であり、そのようなものとして、本書で扱われていません。
When a CE packet (i.e., a packet that has the CE codepoint set) is received by a router, the CE codepoint is left unchanged, and the packet is transmitted as usual. When severe congestion has occurred and the router's queue is full, then the router has no choice but to drop some packet when a new packet arrives. We anticipate that such packet losses will become relatively infrequent when a majority of end-systems become ECN-Capable and participate in TCP or other compatible congestion control mechanisms. In an ECN-Capable environment that is adequately-provisioned, packet losses should occur primarily during transients or in the presence of non-cooperating sources.
CEパケット（CEコードポイントが設定されている、すなわち、パケット）は、ルータによって受信されると、CEコードポイントが変更されないままになり、パケットは通常通り送信されます。深刻な輻輳が発生していると、ルータのキューがいっぱいになると、ルータは、新たなパケットが到着したときに、いくつかのパケットを廃棄するしかありません。私たちは、エンドシステムの大半は、ECN-できるようになると、TCPまたはその他の互換性の輻輳制御メカニズムに参加したときに、パケット損失が比較的まれになることを期待しています。適切にプロビジョニングされたECN対応の環境では、パケット損失は過渡時や非協力源の存在下で主に発生する必要があります。
The above discussion of when CE may be set instead of dropping a packet applies by default to all Differentiated Services Per-Hop Behaviors (PHBs) [RFC 2475]. Specifications for PHBs MAY provide more specifics on how a compliant implementation is to choose between setting CE and dropping a packet, but this is NOT REQUIRED. A router MUST NOT set CE instead of dropping a packet when the drop that would occur is caused by reasons other than congestion or the desire to indicate incipient congestion to end nodes (e.g., a diffserv edge node may be configured to unconditionally drop certain classes of traffic to prevent them from entering its diffserv domain).
CEは、代わりにパケットをドロップで設定することができる場合の上記の説明は、ホップ単位動作（のPHB）[RFC 2475]すべての差別化サービスにデフォルトで適用されます。 PHBの仕様は、準拠した実装は、CEを設定し、パケットをドロップするとの間で選択することです方法の詳細詳細を提供することができるが、これは必須ではありません。ルータはなく起こる降下が輻輳やノード（例えば終了する初期の輻輳を示す願望以外の理由によるものである場合、パケットをドロップのCEを設定してはいけません、DiffServのエッジノードは、無条件の特定のクラスを削除するように構成することができます）そののDiffServドメインに入ることを防ぐためのトラフィック。
We expect that routers will set the CE codepoint in response to incipient congestion as indicated by the average queue size, using the RED algorithms suggested in [FJ93, RFC2309]. To the best of our knowledge, this is the only proposal currently under discussion in the IETF for routers to drop packets proactively, before the buffer overflows. However, this document does not attempt to specify a particular mechanism for active queue management, leaving that endeavor, if needed, to other areas of the IETF. While ECN is inextricably tied up with the need to have a reasonable active queue management mechanism at the router, the reverse does not hold; active queue management mechanisms have been developed and deployed independent of ECN, using packet drops as indications of congestion in the absence of ECN in the IP architecture.
我々は、平均キューサイズによって示されるようにルータが[FJ93、RFC2309]で提案されているREDアルゴリズムを使用して、初期輻輳に応答してCEコードポイントを設定することを期待します。我々の知る限り、これは、バッファオーバーフローの前に、積極的にパケットをドロップするようにルータのIETFで現在審議中の唯一の提案です。しかし、この文書では、必要に応じて、IETFの他のエリアに、その努力を残して、アクティブキュー管理のための特定の機構を指定しようとしません。 ECNは密接ルータで、合理的なアクティブキュー管理メカニズムを持つ必要性に縛られている間、逆は成り立ちません。アクティブキュー管理機構を開発し、ECNとは独立して展開し、パケットを使用してIPアーキテクチャにおけるECNの非存在下における輻輳の兆候として低下してきました。
We emphasize that a *single* packet with the CE codepoint set in an IP packet causes the transport layer to respond, in terms of congestion control, as it would to a packet drop. The instantaneous queue size is likely to see considerable variations even when the router does not experience persistent congestion. As such, it is important that transient congestion at a router, reflected by the instantaneous queue size reaching a threshold much smaller than the capacity of the queue, not trigger a reaction at the transport layer. Therefore, the CE codepoint should not be set by a router based on the instantaneous queue size.
私たちは、IPパケットに設定CEコードポイントを持つ*シングル*パケットは、パケットのドロップすると同じように、輻輳制御の観点では、対応するトランスポート層を引き起こすことを強調する。瞬間的なキューサイズは、ルータが永続的な輻輳を経験していない場合であっても、かなりのバリエーションを参照してくださいする可能性があります。このように、キューの容量よりもかなり小さい閾値に達する瞬間キューサイズによって反射ルータの過渡輻輳が、トランスポート層での反応を誘発しないことが重要です。そのため、CEコードポイントは、瞬間キューのサイズに基づいて、ルータによって設定されるべきではありません。
For example, since the ATM and Frame Relay mechanisms for congestion indication have typically been defined without an associated notion of average queue size as the basis for determining that an intermediate node is congested, we believe that they provide a very noisy signal. The TCP-sender reaction specified in this document for ECN is NOT the appropriate reaction for such a noisy signal of congestion notification. However, if the routers that interface to the ATM network have a way of maintaining the average queue at the interface, and use it to come to a reliable determination that the ATM subnet is congested, they may use the ECN notification that is defined here.
輻輳表示のためのATMおよびフレーム・リレー機構は、典型的には、中間ノードが輻輳していると判断するための基礎としての平均キューサイズの関連概念なしで定義されているので、例えば、我々は、彼らが非常にノイズの多い信号を提供すると信じています。 ECNについては、この文書で指定されたTCP-送信者の反応は、輻輳通知のようにノイズの多い信号のための適切な反応ではありません。 ATMネットワークへのインタフェースは、界面での平均キューを維持する方法を持って、そしてそれを使用するルータがATMサブネットが輻輳していることを確実な決意に来ている場合しかし、彼らはここで定義されたECN通知を使用することができます。
We continue to encourage experiments in techniques at layer 2 (e.g., in ATM switches or Frame Relay switches) to take advantage of ECN. For example, using a scheme such as RED (where packet marking is based on the average queue length exceeding a threshold), layer 2 devices could provide a reasonably reliable indication of congestion. When all the layer 2 devices in a path set that layer's own Congestion Experienced codepoint (e.g., the EFCI bit for ATM, the FECN bit in Frame Relay) in this reliable manner, then the interface router to the layer 2 network could copy the state of that layer 2
私たちは、ECNを利用するために（例えば、ATMのスイッチやリレースイッチフレーム）のレイヤ2での技術で実験を奨励し続けます。例えば、そのような（パケットマーキングが閾値を超える平均キュー長に基づいている）REDとしてスキームを使用して、レイヤ2つのデバイスは、輻輳の合理的に信頼性の指標を提供することができます。パス内のすべてのレイヤ2つのデバイスは、この信頼性の高い方法でその層自身の輻輳に遭遇したコードポイント（例えば、ATM、フレームリレーでFECNビットのためのEFCIビット）を設定すると、その後、レイヤ2ネットワークへのインタフェースルータは状態をコピーすることができその層2の
Congestion Experienced codepoint into the CE codepoint in the IP header. We recognize that this is not the current practice, nor is it in current standards. However, encouraging experimentation in this manner may provide the information needed to enable evolution of existing layer 2 mechanisms to provide a more reliable means of congestion indication, when they use a single bit for indicating congestion.
輻輳は、IPヘッダーのCEコードポイントにコードポイントを経験しました。私たちは、これが現在の実務ではないことを認識し、またそれは、現在の規格です。しかしながら、このようにして実験を奨励することは、それらが輻輳を示すための単一のビットを使用する場合、輻輳表示のより信頼性の高い手段を提供するために、既存のレイヤ2機構の進化を可能にするために必要な情報を提供してもよいです。
For the proposed use for ECN in this document (that is, for a transport protocol such as TCP for which a dropped data packet is an indication of congestion), end nodes detect dropped data packets, and the congestion response of the end nodes to a dropped data packet is at least as strong as the congestion response to a received CE packet. To ensure the reliable delivery of the congestion indication of the CE codepoint, an ECT codepoint MUST NOT be set in a packet unless the loss of that packet in the network would be detected by the end nodes and interpreted as an indication of congestion.
この文書に記載されているECNのための提案された使用のために（すなわち、ドロップされたデータパケットが輻輳表示されているTCPなどのトランスポートプロトコルのために）、エンドノードがデータパケットをドロップ検出、及びにエンドノードの輻輳応答ドロップされたデータパケットは、受信されたCEパケットに輻輳応答と少なくとも同じくらい強力です。ネットワーク内のそのパケットの損失がエンドノードによって検出された輻輳の指標として解釈されない限りCEコードポイントの輻輳表示の信頼できる配信を保証するために、ECTコードポイントは、パケットに設定してはいけません。
Transport protocols such as TCP do not necessarily detect all packet drops, such as the drop of a "pure" ACK packet; for example, TCP does not reduce the arrival rate of subsequent ACK packets in response to an earlier dropped ACK packet. Any proposal for extending ECN-Capability to such packets would have to address issues such as the case of an ACK packet that was marked with the CE codepoint but was later dropped in the network. We believe that this aspect is still the subject of research, so this document specifies that at this time, "pure" ACK packets MUST NOT indicate ECN-Capability.
TCPのようなトランスポートプロトコルは、必ずしも、このような「純粋な」ACKパケットのドロップなど、すべてのパケットがドロップし検出されません。例えば、TCPはACKパケットをドロップ以前に応じて、後続のACKパケットの到着率を低下させません。そのようなパケットにECN-能力を拡張するための任意の提案は、そのようなCEコードポイントでマークされたが、後にネットワークに滴下したACKパケットの場合などの問題に対処しなければなりません。私たちは、この側面は、まだ研究の対象であると信じているので、この文書では、この時点では、「純粋な」ACKパケットがECN-能力を示してはいけないことを指定します。
Similarly, if a CE packet is dropped later in the network due to corruption (bit errors), the end nodes should still invoke congestion control, just as TCP would today in response to a dropped data packet. This issue of corrupted CE packets would have to be considered in any proposal for the network to distinguish between packets dropped due to corruption, and packets dropped due to congestion or buffer overflow. In particular, the ubiquitous deployment of ECN would not, in and of itself, be a sufficient development to allow end-nodes to interpret packet drops as indications of corruption rather than congestion.
CEパケットが破損（ビットエラー）に起因するネットワークの後半でドロップされた場合、同様に、エンド・ノードは、依然としてわずかTCPは、ドロップされたデータパケットに応答して、今日と同じように、輻輳制御を起動しなければなりません。破損したCEパケットのこの問題は、パケットを区別するために、ネットワークのための任意の提案で考慮しなければならによる破損に落ち、そしてパケットが輻輳またはバッファオーバーフローに下がりました。具体的には、ECNのユビキタス展開は、それ自体が、エンドノードが破損なく輻輳の指標としてパケット滴を解釈することを可能にするのに十分な開発ではありません。
ECN-capable packets MAY have the DF (Don't Fragment) bit set. Reassembly of a fragmented packet MUST NOT lose indications of congestion. In other words, if any fragment of an IP packet to be reassembled has the CE codepoint set, then one of two actions MUST be taken:
ECN対応のパケットはDF（かないフラグメント）ビットセットを持っているかもしれません。断片化されたパケットの再組み立ては、輻輳の兆候を失ってはなりません。換言すれば、再組み立てされるIPパケットの任意の断片は、CEコードポイントが設定されている場合、1〜2のアクションがとられなければなりません。
* Set the CE codepoint on the reassembled packet. However, this MUST NOT occur if any of the other fragments contributing to this reassembly carries the Not-ECT codepoint.
*再構成されたパケットのCEコードポイントを設定します。この再構築に貢献する他のフラグメントのいずれかがない-ECTコードポイントを運ぶ場合は、これは発生してはなりません。
* The packet is dropped, instead of being reassembled, for any other reason.
*パケットは、他の理由のために、代わりに再組立されるので、廃棄されます。
If both actions are applicable, either MAY be chosen. Reassembly of a fragmented packet MUST NOT change the ECN codepoint when all of the fragments carry the same codepoint.
両方のアクションが適用された場合は、どちらかを選択することができます。フラグメントの全てが同じコードポイントを運ぶ際に断片化されたパケットの再組み立ては、ECNコードポイントを変更しないでください。
We would note that because RFC 2481 did not specify reassembly behavior, older ECN implementations conformant with that Experimental RFC do not necessarily perform reassembly correctly, in terms of preserving the CE codepoint in a fragment. The sender could avoid the consequences of this behavior by setting the DF bit in ECN-Capable packets.
私たちは、RFC 2481を再構築動作を指定しなかったので、その実験的RFCに準拠古いECNの実装は必ずしもフラグメントでCEコードポイントを維持するという点で、正しく再構築を実行しないことに注意します。送信者は、ECN対応のパケットでDFビットを設定することで、この動作の結果を回避することができます。
Situations may arise in which the above reassembly specification is insufficiently precise. For example, if there is a malicious or broken entity in the path at or after the fragmentation point, packet fragments could carry a mixture of ECT(0), ECT(1), and/or Not-ECT codepoints. The reassembly specification above does not place requirements on reassembly of fragments in this case. In situations where more precise reassembly behavior would be required, protocol specifications SHOULD instead specify that DF MUST be set in all ECN-capable packets sent by the protocol.
状況は、上記再構成仕様が十分正確である生じ得ます。悪意のあるまたは壊れたエンティティがフラグメンテーション点で以降のパスに存在する場合、例えば、パケットのフラグメントがECT（0）、ECT（1）、および/またはNOT-ECTコードポイントの混合物を運ぶことができます。上記の再組み立ての仕様が、この場合、フラグメントの再構築に要件を課しません。より正確な再構成動作が必要とされる状況では、プロトコル仕様ではなく、DFプロトコルによって送信されるすべてのECN可能なパケットに設定しなければならないことを特定すべきです。
ECN requires support from the transport protocol, in addition to the functionality given by the ECN field in the IP packet header. The transport protocol might require negotiation between the endpoints during setup to determine that all of the endpoints are ECN-capable, so that the sender can set the ECT codepoint in transmitted packets. Second, the transport protocol must be capable of reacting appropriately to the receipt of CE packets. This reaction could be in the form of the data receiver informing the data sender of the received CE packet (e.g., TCP), of the data receiver unsubscribing to a layered multicast group (e.g., RLM [MJV96]), or of some other action that ultimately reduces the arrival rate of that flow on that congested link. CE packets indicate persistent rather than transient congestion (see Section 5.1), and hence reactions to the receipt of CE packets should be those appropriate for persistent congestion.
ECNは、IPパケットヘッダ内のECNフィールドに指定された機能に加えて、トランスポート・プロトコルのサポートを必要とします。トランスポートプロトコルは、送信者が送信したパケットにECTコードポイントを設定することができるよう、すべてのエンドポイントは、ECN-可能であることを決定するために、セットアップ中にエンドポイント間の交渉が必要になることがあります。第二に、トランスポートプロトコルは、CEパケットの受信に適切に反応することができなければなりません。この反応は、受信CEパケットのデータを送信者に通知するデータ受信装置の形態であってもよい（例えば、TCP）、階層化マルチキャストグループに退会データ受信機（例えば、RLM [MJV96]）、またはいくつかの他のアクションそれは最終的にはその混雑したリンク上のそのフローの到着率を低減します。 CEパケットがパーシステントよりもむしろ一過混雑（セクション5.1を参照）、したがってCEパケットの受信に反応が持続的な輻輳のために適切なものでなければならないことを示します。
This document only addresses the addition of ECN Capability to TCP, leaving issues of ECN in other transport protocols to further research. For TCP, ECN requires three new pieces of functionality: negotiation between the endpoints during connection setup to determine if they are both ECN-capable; an ECN-Echo (ECE) flag in the TCP header so that the data receiver can inform the data sender when a CE packet has been received; and a Congestion Window Reduced (CWR) flag in the TCP header so that the data sender can inform the data receiver that the congestion window has been reduced. The support required from other transport protocols is likely to be different, particularly for unreliable or reliable multicast transport protocols, and will have to be determined as other transport protocols are brought to the IETF for standardization.
この文書では、唯一の研究を促進するために、他のトランスポートプロトコルにECNの課題を残して、TCPのECN機能の追加に対応しています。彼らはECN対応の両方であるかどうかを判断するために、接続のセットアップ中にエンドポイント間の交渉;：TCPの場合、ECN 3つの新しい機能の一部を必要としTCPヘッダ内のECN-エコー（ECE）フラグデータ受信装置は、CEパケットを受信したデータの送信者に通知することができるように。データ送信側は、輻輳ウィンドウが縮小されたことをデータ受信装置に通知することができるように輻輳ウィンドウは、TCPヘッダ内（CWR）フラグを削減します。他のトランスポートプロトコルから必要なサポートは、特に信頼できない、または信頼できるマルチキャストトランスポートプロトコルのために、異なる可能性があり、かつ他のトランスポートプロトコルが標準化のためにIETFにされるように決定する必要があります。
In a mild abuse of terminology, in this document we refer to `TCP packets' instead of `TCP segments'.
用語の軽度の乱用では、この文書では、我々はの代わりに `TCPセグメントの` TCPパケットを参照してください。
The following sections describe in detail the proposed use of ECN in TCP. This proposal is described in essentially the same form in [Floyd94]. We assume that the source TCP uses the standard congestion control algorithms of Slow-start, Fast Retransmit and Fast Recovery [RFC2581].
次のセクションでは詳細にTCPにおけるECNの提案された使用を記載しています。この提案は、[Floyd94]において本質的に同じ形式で記述されています。私たちは、ソースTCPはスロースタートの標準輻輳制御アルゴリズム、高速再送信および高速リカバリ[RFC2581]を使用していることを前提としています。
This proposal specifies two new flags in the Reserved field of the TCP header. The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 4 of RFC 793 [RFC793] (and is reproduced below for completeness). This specification of the ECN Field leaves the Reserved field as a 4-bit field using bits 4-7.
この提案は、TCPヘッダーの予約フィールドに二つの新しいフラグを指定します。 ECN-能力を交渉するためのTCPメカニズムはTCPヘッダ内のECN-エコー（ECE）フラグを使用します。 TCPヘッダのReservedフィールドのビット9は、ECN-エコーフラグとして指定されます。 TCPヘッダーの6ビットのReservedフィールドの位置は、RFC 793 [RFC793]の図4に示されている（および完全性のために以下に再現されています）。 ECNフィールドのこの仕様は、ビット4-7を用いて、4ビットのフィールドとしてReservedフィールドを残します。
To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, we introduce a second new flag in the TCP header, the CWR flag. The CWR flag is assigned to Bit 8 in the Reserved field of the TCP header.
ECN-エコーフラグを設定停止する時を決定するためにTCP受信を可能にするために、我々は、TCPヘッダにCWRフラグを第二の新しいフラグを導入します。 CWRフラグがTCPヘッダーのReservedフィールドのビット8に割り当てられます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: The old definition of bytes 13 and 14 of the TCP header.
図3：バイト13とTCPヘッダの14の古い定義。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 4: The new definition of bytes 13 and 14 of the TCP Header.
図4：バイト13とTCPヘッダの14の新しい定義。
Thus, ECN uses the ECT and CE flags in the IP header (as shown in Figure 1) for signaling between routers and connection endpoints, and uses the ECN-Echo and CWR flags in the TCP header (as shown in Figure 4) for TCP-endpoint to TCP-endpoint signaling. For a TCP connection, a typical sequence of events in an ECN-based reaction to congestion is as follows:
したがって、ECNは、ルータと接続エンドポイント間のシグナリングのために（図1に示されるように）IPヘッダのECTとCEフラグを使用し、（図4に示すように）TCPのTCPヘッダ内のECN-エコーとCWRフラグを使用しますTCPエンドポイントのシグナリングに-endpoint。次のようにTCP接続のために、輻輳ECNベースの反応におけるイベントの典型的な配列は以下のとおりであります：
* An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets.
* ECTコードポイントは、ECNは、これらのパケットのトランスポートエンティティによってサポートされていることを示すために、送信者が送信したパケットに設定されています。
* An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet.
* ECN対応ルータは、差し迫った輻輳を検出し、ECTコードポイントは、落下しようとするパケットに設定されていることを検出します。代わりに、パケットをドロップで、ルータは、IPヘッダ内のCEコードポイントを設定することを選択してパケットを転送します。
* The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender.
*受信機は、CEコードポイントが設定されたパケットを受信し、送信者に送信されたその次のTCP ACKでECN-エコーフラグをセットします。
* The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped.
*送信者は、ECN-エコーが設定されたTCP ACKを受信すると、パケットが廃棄されたかのように混雑に反応します。
* The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.
*送信者は、そのの受信およびECN-エコーフラグの反応を確認するために受信機に送信される次のパケットのTCPヘッダにCWRフラグをセットします。
The negotiation for using ECN by the TCP transport entities and the use of the ECN-Echo and CWR flags is described in more detail in the sections below.
TCPトランスポートエンティティとECN-エコーとCWRフラグの使用によってECNを使用するための交渉は、以下のセクションで詳しく説明されています。
In the TCP connection setup phase, the source and destination TCPs exchange information about their willingness to use ECN. Subsequent to the completion of this negotiation, the TCP sender sets an ECT codepoint in the IP header of data packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet. This indicates to the routers that they may mark this packet with the CE codepoint, if they would like to use that as a method of congestion notification. If the TCP connection does not wish to use ECN notification for a particular packet, the sending TCP sets the ECN codepoint to not-ECT, and the TCP receiver ignores the CE codepoint in the received packet.
TCP接続設定フェーズでは、彼らの意欲についての送信元と宛先のTCP交換情報は、ECNを使用します。このネゴシエーションの完了に続いて、TCP送信者は、輸送が可能とこのパケットのECNに参加する意思があるネットワークに示すために、データパケットのIPヘッダ内のECTコードポイントを設定します。これは、彼らが輻輳通知の方法として、それを使用したい場合、彼らは、CEコードポイントで、このパケットをマークして、ルータに指示します。 TCP接続が特定のパケットのためのECN通知を使用したくない場合は、送信側TCPはない-ECTにECNコードポイントを設定し、TCP受信機は、受信したパケットにCEコードポイントを無視します。
For this discussion, we designate the initiating host as Host A and the responding host as Host B. We call a SYN packet with the ECE and CWR flags set an "ECN-setup SYN packet", and we call a SYN packet with at least one of the ECE and CWR flags not set a "non-ECN-setup SYN packet". Similarly, we call a SYN-ACK packet with only the ECE flag set but the CWR flag not set an "ECN-setup SYN-ACK packet", and we call a SYN-ACK packet with any other configuration of the ECE and CWR flags a "non-ECN-setup SYN-ACK packet".
ホストAと応答ホストがホストBとして私たちは、「ECN-セットアップSYNパケット」に設定ECEとCWR旗をSYNパケットを呼び出し、そして私たちは、少なくともでSYNパケットを呼び出すと、この議論のために、我々は、開始ホストを指定しますECEとCWRフラグの1つは、「非ECN-setup SYNパケット」を設定していません。同様に、我々はセットのみECEフラグでSYN-ACKパケットを呼び出すが、CWRフラグが「ECN-セットアップSYN-ACKパケット」を設定していない、と私たちはECEとCWRフラグの任意の他の構成でSYN-ACKパケットを呼び出します"非ECN-セットアップSYN-ACKパケット"。
Before a TCP connection can use ECN, Host A sends an ECN-setup SYN packet, and Host B sends an ECN-setup SYN-ACK packet. For a SYN packet, the setting of both ECE and CWR in the ECN-setup SYN packet is defined as an indication that the sending TCP is ECN-Capable, rather than as an indication of congestion or of response to congestion. More precisely, an ECN-setup SYN packet indicates that the TCP implementation transmitting the SYN packet will participate in ECN as both a sender and receiver. Specifically, as a receiver, it will respond to incoming data packets that have the CE codepoint set in the IP header by setting ECE in outgoing TCP Acknowledgement (ACK) packets. As a sender, it will respond to incoming packets that have ECE set by reducing the congestion window and setting CWR when appropriate. An ECN-setup SYN packet does not commit the TCP sender to setting the ECT codepoint in any or all of the packets it may transmit. However, the commitment to respond appropriately to incoming packets with the CE codepoint set remains even if the TCP sender in a later transmission, within this TCP connection, sends a SYN packet without ECE and CWR set.
TCP接続がECNを使用する前に、ホストAは、ECN-セットアップSYNパケットを送信し、ホストBは、ECN-セットアップSYN-ACKパケットを送信します。 SYNパケットに対して、ECN-セットアップSYNパケットにECEとCWRの両方の設定は、送信TCPがECN対応ではなく、輻輳又は輻輳に対する応答の指標としてであることを示すものとして定義されます。より正確には、ECN-セットアップSYNパケットがSYNパケットを送信するTCPの実装では、送信者と受信者の両方としてECNに参加することを示しています。具体的には、受信機としては、発信TCP肯定応答（ACK）パケットにECEを設定することにより、IPヘッダに設定CEコードポイントを有する着信データパケットに応答します。送信者として、それは輻輳ウィンドウを縮小し、適切な場合にCWRを設定することにより、設定ECEを持つ着信パケットに応答します。 ECN-セットアップSYNパケットは、それが伝送することができるパケットのいずれかまたは全てにECTコードポイントを設定するTCPの送信者をコミットしません。 CEコードポイントセットは、後の伝送におけるTCPの送信側は、このTCP接続内で、ECEとCWRセットせずにSYNパケットを送信した場合でも残っているとしかし、コミットメントは、着信パケットに適切に対応します。
When Host B sends an ECN-setup SYN-ACK packet, it sets the ECE flag but not the CWR flag. An ECN-setup SYN-ACK packet is defined as an indication that the TCP transmitting the SYN-ACK packet is ECN-Capable. As with the SYN packet, an ECN-setup SYN-ACK packet does not commit the TCP host to setting the ECT codepoint in transmitted packets.
ホストBは、ECN-セットアップSYN-ACKパケットを送信すると、それはECEフラグではなく、CWRフラグを設定します。 ECN-セットアップSYN-ACKパケットは、SYN-ACKパケットを送信するTCPは、ECN-可能であることを示すものとして定義されます。 SYNパケットと同様に、ECN-セットアップSYN-ACKパケットが送信されたパケットにECTコードポイントを設定するTCPホストをコミットしません。
The following rules apply to the sending of ECN-setup packets within a TCP connection, where a TCP connection is defined by the standard rules for TCP connection establishment and termination.
以下のルールは、TCP接続がTCP接続の確立及び終了のための標準的なルールによって定義されたTCP接続、内ECN-セットアップパケットの送信に適用されます。
* If a host has received an ECN-setup SYN packet, then it MAY send an ECN-setup SYN-ACK packet. Otherwise, it MUST NOT send an ECN-setup SYN-ACK packet.
*ホストがECN-セットアップSYNパケットを受信した場合、それはECN-セットアップSYN-ACKパケットを送信することができます。それ以外の場合は、ECN-セットアップSYN-ACKパケットを送ってはいけません。
* A host MUST NOT set ECT on data packets unless it has sent at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has received at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has sent no non-ECN-setup SYN or non-ECN-setup SYN-ACK packet. If a host has received at least one non-ECN-setup SYN or non-ECN-setup SYN-ACK packet, then it SHOULD NOT set ECT on data packets.
*ホストは、それが少なくとも一つのECN-セットアップSYNやECN-セットアップSYN-ACKパケットを送信した場合を除き、データパケットにECTを設定してはいけませんと、少なくとも1つのECN-セットアップSYNやECN-セットアップSYN-ACKパケットを受信した、と何の非ECN-セットアップSYNまたは非ECN-セットアップSYN-ACKパケットを送信していません。ホストは少なくとも1つの非ECN-セットアップSYNまたは非ECN-セットアップSYN-ACKパケットを受信した場合、それは、データパケットにECTを設定しないでください。
* If a host ever sets the ECT codepoint on a data packet, then that host MUST correctly set/clear the CWR TCP bit on all subsequent packets in the connection.
ホストは、これまでのデータパケットにECTコードポイントを設定した場合*、そのホストが正しく接続内のすべての後続のパケットに/ CWR TCPビットを明確に設定しなければなりません。
* If a host has sent at least one ECN-setup SYN or ECN-setup SYN-ACK packet, and has received no non-ECN-setup SYN or non-ECN-setup SYN-ACK packet, then if that host receives TCP data packets with ECT and CE codepoints set in the IP header, then that host MUST process these packets as specified for an ECN-capable connection.
*ホストは、そのホストがTCPデータを受信した後ならば、少なくとも一つのECN-セットアップSYNまたはECN-セットアップSYN-ACKパケットを送信した、と何の非ECN-セットアップSYNまたは非ECN-セットアップSYN-ACKパケットを受信しなかった場合ECN-可能な接続のために指定されたIPヘッダに設定ECTとCEコードポイントを持つパケットは、そのホストは、これらのパケットを処理しなければなりません。
* A host that is not willing to use ECN on a TCP connection SHOULD clear both the ECE and CWR flags in all non-ECN-setup SYN and/or SYN-ACK packets that it sends to indicate this unwillingness. Receivers MUST correctly handle all forms of the non-ECN-setup SYN and SYN-ACK packets.
* TCP接続でECNを使うことを望んでいないホストは、それがこの不本意を示すために送信するすべての非ECN-セットアップSYNおよび/またはSYN-ACKパケットにECEとCWRフラグの両方をクリアする必要があります。レシーバは正しく非ECN-セットアップSYNとSYN-ACKパケットのすべてのフォームを処理する必要があります。
* A host MUST NOT set ECT on SYN or SYN-ACK packets.
*ホストがSYNまたはSYN-ACKパケットにECTを設定してはいけません。
A TCP client enters TIME-WAIT state after receiving a FIN-ACK, and transitions to CLOSED state after a timeout. Many TCP implementations create a new TCP connection if they receive an in-window SYN packet during TIME-WAIT state. When a TCP host enters TIME-WAIT or CLOSED state, it should ignore any previous state about the negotiation of ECN for that connection.
TCPクライアントは、FIN-ACKを受信した後、TIME-WAIT状態に入り、タイムアウト後にCLOSED状態に遷移。彼らはTIME-WAIT状態の間で、窓SYNパケットを受信した場合、多くのTCP実装は、新しいTCP接続を作成します。 TCPホストがTIME-WAITまたはCLOSED状態になると、それは、その接続のためのECNの交渉についての以前の状態を無視する必要があります。
ECN introduces the use of the ECN-Echo and CWR flags in the TCP header (as shown in Figure 3) for initialization. There exist some faulty firewalls, load balancers, and intrusion detection systems in the Internet that either drop an ECN-setup SYN packet or respond with a RST, in the belief that such a packet (with these bits set) is a signature for a port-scanning tool that could be used in a denial-of-service attack. Some of the offending equipment has been identified, and a web page [FIXES] contains a list of non-compliant products and the fixes posted by the vendors, where these are available. The TBIT web page [TBIT] lists some of the web servers affected by this faulty equipment. We mention this in this document as a warning to the community of this problem.
ECNは、初期化のために（図3に示すように）TCPヘッダ内のECN-エコーとCWRフラグの使用を導入します。 （設定され、これらのビットを有する）は、パケットがポートの署名であるという信念に、ECN-セットアップSYNパケットをドロップまたはRSTで応答のいずれか、インターネットの一部の故障ファイアウォール、ロードバランサ、及び侵入検知システムが存在しますDoS攻撃に使用できるツールを-scanning。問題のある設備の一部が確認されており、Webページ[修正は非対応製品およびこれらが利用可能なベンダーによって掲示修正のリストが含まれています。 TBITのWebページ[TBIT]は、この障害のある機器の影響を受けたWebサーバの一部を示します。私たちは、この問題のコミュニティへの警告として、この文書でこれを言及します。
To provide robust connectivity even in the presence of such faulty equipment, a host that receives a RST in response to the transmission of an ECN-setup SYN packet MAY resend a SYN with CWR and ECE cleared. This could result in a TCP connection being established without using ECN.
でも、このような障害のある機器の存在下で、強固な接続性を提供するために、ECN-セットアップSYNパケットの送信に応答してRSTを受信するホストはクリアCWRとECEでSYNを再送信することができます。これは、ECNを使用せずに確立されたTCP接続につながる可能性があります。
A host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval MAY resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared.
通常SYN再送タイムアウト間隔内ECN-セットアップSYNに応答なしホストはSYNとクリアCWRとECEと後続のSYN再送信を再送信することができます。失われ、元のSYN、その結果、通常のパケットロスを克服するために、元ホストはあきらめとCWRとECEビットをクリアしてSYNを再送する前に、一つ以上のECN-setup SYNパケットを再送信することができます。
We note that in this case, the following example scenario is possible:
私たちは、このような場合には、次の例のシナリオが可能であることに注意してください。
(1) Host A: Sends an ECN-setup SYN. (2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or delayed. (3) Host A: Sends a non-ECN-setup SYN. (4) Host B: Sends a non-ECN-setup SYN/ACK.
（1）ホストA：ECN-セットアップSYNを送信します。 （2）ホストBは：ECN-セットアップSYN / ACKを送信し、パケットはドロップ又は遅延されます。 （3）ホストAは：非ECN-セットアップSYNを送信します。 （4）ホストBが：非ECN-セットアップSYN / ACKを送信します。
We note that in this case, following the procedures above, neither Host A nor Host B may set the ECT bit on data packets. Further, an important consequence of the rules for ECN setup and usage in Section 6.1.1 is that a host is forbidden from using the reception of ECT data packets as an implicit signal that the other host is ECN-capable.
私たちは、このような場合には、上記の手順に従って、ホストAやホストBのいずれもデータパケットにECTビットをセットすることができることに注意してください。さらに、ECNセットアップおよびセクション6.1.1で使用するための規則の重要な結果は、ホストが他のホストがECN-可能であることを暗黙の信号としてECTデータパケットの受信を使用してから禁止されていることです。
There is the question of why we chose to have the TCP sending the SYN set two ECN-related flags in the Reserved field of the TCP header for the SYN packet, while the responding TCP sending the SYN-ACK sets only one ECN-related flag in the SYN-ACK packet. This asymmetry is necessary for the robust negotiation of ECN-capability with some deployed TCP implementations. There exists at least one faulty TCP implementation in which TCP receivers set the Reserved field of the TCP header in ACK packets (and hence the SYN-ACK) simply to reflect the Reserved field of the TCP header in the received data packet. Because the TCP SYN packet sets the ECN-Echo and CWR flags to indicate ECN-capability, while the SYN-ACK packet sets only the ECN-Echo flag, the sending TCP correctly interprets a receiver's reflection of its own flags in the Reserved field as an indication that the receiver is not ECN-capable. The sending TCP is not mislead by a faulty TCP implementation sending a SYN-ACK packet that simply reflects the Reserved field of the incoming SYN packet.
我々はSYN-ACKを送信して応答TCPが唯一のECN関連フラグを設定しながら、SYNを送信してTCPは、SYNパケットのTCPヘッダーの予約フィールドに2 ECN関連フラグを設定していることを選んだ理由の質問がありますSYN-ACKパケットインチこの非対称性は、いくつかの展開TCPの実装とECN-機能の強力な交渉のために必要です。少なくとも一つの故障TCP受信機がACKパケットにTCPヘッダのReservedフィールドを設定するTCPの実装（ひいてはSYN-ACK）は、単に受信したデータパケットにTCPヘッダのReservedフィールドを反映するために存在します。 TCP SYNパケットがSYN-ACKパケットのみECN-エコーフラグを設定しながら、ECN-能力を示すために、ECN-エコーとCWRフラグを設定するため、送信側TCPが正しくReservedフィールドように、独自のフラグの受信器の反射を解釈します受信機は、ECN-ことができないことを示します。送信TCPは単に、着信SYNパケットの予約フィールドを反映したSYN-ACKパケットを送信して障害のあるTCP実装によって誤解されていません。
For a TCP connection using ECN, new data packets are transmitted with an ECT codepoint set in the IP header. When only one ECT codepoint is needed by a sender for all packets sent on a TCP connection, ECT(0) SHOULD be used. If the sender receives an ECN-Echo (ECE) ACK packet (that is, an ACK packet with the ECN-Echo flag set in the TCP header), then the sender knows that congestion was encountered in the network on the path from the sender to the receiver. The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh". The sending TCP SHOULD NOT increase the congestion window in response to the receipt of an ECN-Echo ACK packet.
ECNを用いたTCP接続のため、新たなデータパケットがECTコードポイントIPヘッダに設定で送信されます。一つだけECTコードポイントは、TCP接続上で送信されるすべてのパケットの送信者によって必要とされる場合、（0）ECTを使用する必要があります。送信者が（すなわち、TCPヘッダに設定されたECN-エコーフラグとACKパケットである）ECN-エコー（ECE）ACKパケットを受信した場合、送信者は、輻輳が送信者からの経路上のネットワークで発生したことを知ります受信機へ。混雑の表示は、単に非ECN対応のTCPの輻輳損失として扱われるべきです。これは、TCPのソースは、輻輳ウィンドウ「のcwnd」を半分にし、スロースタート閾値「SSTHRESH」を減らす、です。送信TCPは、ECN-エコーACKパケットの受信に応答して混雑ウィンドウを増加させるべきではありません。
TCP should not react to congestion indications more than once every window of data (or more loosely, more than once every round-trip time). That is, the TCP sender's congestion window should be reduced only once in response to a series of dropped and/or CE packets from a single window of data. In addition, the TCP source should not decrease the slow-start threshold, ssthresh, if it has been decreased within the last round trip time. However, if any retransmitted packets are dropped, then this is interpreted by the source TCP as a new instance of congestion.
TCPはデータの回窓以上（またはそれ以上緩く、一回のラウンドトリップ時間以上）混雑指摘に反応すべきではありません。これは、TCPの送信側の輻輳ウィンドウは、データの単一の窓から落下および/またはCE一連のパケットに対応して一度だけ減少させなければならない、です。それが最後のラウンドトリップ時間以内に減少した場合また、TCPのソースは、スロースタートしきい値、SSTHRESHを減少させてはなりません。いずれかの再送パケットが廃棄されている場合は、これは混雑の新しいインスタンスとしてソースTCPによって解釈されます。
After the source TCP reduces its congestion window in response to a CE packet, incoming acknowledgments that continue to arrive can "clock out" outgoing packets as allowed by the reduced congestion window. If the congestion window consists of only one MSS (maximum segment size), and the sending TCP receives an ECN-Echo ACK packet, then the sending TCP should in principle still reduce its congestion window in half. However, the value of the congestion window is bounded below by a value of one MSS. If the sending TCP were to continue to send, using a congestion window of 1 MSS, this results in the transmission of one packet per round-trip time. It is necessary to still reduce the sending rate of the TCP sender even further, on receipt of an ECN-Echo packet when the congestion window is one. We use the retransmit timer as a means of reducing the rate further in this circumstance. Therefore, the sending TCP MUST reset the retransmit timer on receiving the ECN-Echo packet when the congestion window is one. The sending TCP will then be able to send a new packet only when the retransmit timer expires.
ソースTCPは、CEパケットに応答して、その輻輳ウィンドウを減少させた後、到着し続け、着信確認応答は、「クロックアウト」発信パケットをすることができます減少し輻輳ウィンドウによって許可さ。輻輳ウィンドウが唯一のMSS（最大セグメントサイズ）で構成され、送信側TCPは、ECN-エコーACKパケットを受信した場合、送信側TCPは、原理的にはまだ半分にその輻輳ウィンドウを減らす必要があります。しかし、輻輳ウィンドウの値を1 MSSの値によって以下制限されます。送信側TCPは、1 MSSの輻輳ウィンドウを使用して、送信し続けるとしたら、これはラウンドトリップ時間あたり1つのパケットの送信になります。輻輳ウィンドウが1であるとき、まだECN-エコーパケットの受信時に、さらにTCP送信者の送信レートを低減する必要があります。私たちは、この状況で、さらに速度を低下させるための手段として再送信タイマを使用しています。そのため、送信側TCPは輻輳ウィンドウが1のときECN-エコーパケットを受信した上で再送信タイマーをリセットしなければなりません。送信TCPは、再送タイマが満了した場合にのみ、新たなパケットを送信することができます。
When an ECN-Capable TCP sender reduces its congestion window for any reason (because of a retransmit timeout, a Fast Retransmit, or in response to an ECN Notification), the TCP sender sets the CWR flag in the TCP header of the first new data packet sent after the window reduction. If that data packet is dropped in the network, then the sending TCP will have to reduce the congestion window again and retransmit the dropped packet.
ECN対応のTCP送信者が（なぜなら再送タイムアウトの、高速再送信、またはECN通知に応答して）何らかの理由でその輻輳ウィンドウを減少させる場合、TCP送信者は、最初の新しいデータのTCPヘッダにCWRフラグをセット窓の減少の後に送信されたパケット。そのデータパケットがネットワーク内でドロップされた場合、送信側TCPは再び輻輳ウィンドウを縮小し、ドロップされたパケットを再送信する必要があります。
We ensure that the "Congestion Window Reduced" information is reliably delivered to the TCP receiver. This comes about from the fact that if the new data packet carrying the CWR flag is dropped, then the TCP sender will have to again reduce its congestion window, and send another new data packet with the CWR flag set. Thus, the CWR bit in the TCP header SHOULD NOT be set on retransmitted packets.
私たちは、「輻輳ウィンドウの減少」の情報を確実にTCP受信機に配信されていることを確認してください。これは、CWRフラグを運ぶ新しいデータパケットがドロップされた場合、TCPの送信者が再びその輻輳ウィンドウを縮小し、CWRフラグを設定して、別の新しいデータ・パケットを送信する必要があるという事実から約来ます。したがって、TCPヘッダのCWRビットは、再送パケットに設定しないでください。
When the TCP data sender is ready to set the CWR bit after reducing the congestion window, it SHOULD set the CWR bit only on the first new data packet that it transmits.
TCPデータ送信側は輻輳ウィンドウを減少させた後CWRビットを設定する準備ができると、それだけで、それが透過する第1の新たなデータパケットにCWRビットを設定する必要があります。
[Floyd94] discusses TCP's response to ECN in more detail. [Floyd98] discusses the validation test in the ns simulator, which illustrates a wide range of ECN scenarios. These scenarios include the following: an ECN followed by another ECN, a Fast Retransmit, or a Retransmit Timeout; a Retransmit Timeout or a Fast Retransmit followed by an ECN; and a congestion window of one packet followed by an ECN.
[Floyd94]より詳細にECNにTCPの応答について説明します。 【Floyd98] ECNシナリオの広い範囲を示すNSシミュレータで検証テストを論じています。これらのシナリオは、次のものがあります別のECN、高速再送、または再送信タイムアウトが続くECN;再送信タイムアウトまたはECNが続く高速再送。そして1つのパケットの輻輳ウィンドウは、ECNが続きます。
TCP follows existing algorithms for sending data packets in response to incoming ACKs, multiple duplicate acknowledgments, or retransmit timeouts [RFC2581]. TCP also follows the normal procedures for increasing the congestion window when it receives ACK packets without the ECN-Echo bit set [RFC2581].
TCPは、着信のACK、複数の重複確認応答又は再送タイムアウト[RFC2581]に応答してデータパケットを送信するための既存のアルゴリズムに従います。 TCPはまた、セット[RFC2581]ビットがECN-エコーせずにACKパケットを受信する混雑ウィンドウを増加させるための通常の手順に従います。
When TCP receives a CE data packet at the destination end-system, the TCP data receiver sets the ECN-Echo flag in the TCP header of the subsequent ACK packet. If there is any ACK withholding implemented, as in current "delayed-ACK" TCP implementations where the TCP receiver can send an ACK for two arriving data packets, then the ECN-Echo flag in the ACK packet will be set to '1' if the CE codepoint is set in any of the data packets being acknowledged. That is, if any of the received data packets are CE packets, then the returning ACK has the ECN-Echo flag set.
TCP宛先エンドシステムにおけるCEデータパケットを受信すると、TCPデータ受信装置は、後続のACKパケットのTCPヘッダ内のECN-エコーフラグをセットします。 TCP受信機は、2つの到着データパケットのためのACKを送信することができ、現在の「遅延ACK」TCPの実装と同様に、実装任意ACK源泉がある場合ならば、ACKパケット内のECN-エコーフラグが「1」に設定されますCEコードポイントは、認知されているデータパケットのいずれかに設定されています。すなわち、受信したデータパケットのいずれかがCEパケットである場合、戻りACKは、ECN-エコーフラグが設定されている、です。
To provide robustness against the possibility of a dropped ACK packet carrying an ECN-Echo flag, the TCP receiver sets the ECN-Echo flag in a series of ACK packets sent subsequently. The TCP receiver uses the CWR flag received from the TCP sender to determine when to stop setting the ECN-Echo flag.
ECN-エコーフラグを運ぶ滴下ACKパケットの可能性に対するロバスト性を提供するために、TCP受信機はACKパケットの直列ECN-エコーフラグを設定し、その後送ら。 TCP受信機は、ECN-エコーフラグを設定停止する時を決定するためにTCP送信側から受信CWRフラグを使用します。
After a TCP receiver sends an ACK packet with the ECN-Echo bit set, that TCP receiver continues to set the ECN-Echo flag in all the ACK packets it sends (whether they acknowledge CE data packets or non-CE data packets) until it receives a CWR packet (a packet with the CWR flag set). After the receipt of the CWR packet, acknowledgments for subsequent non-CE data packets do not have the ECN-Echo flag set. If another CE packet is received by the data receiver, the receiver would once again send ACK packets with the ECN-Echo flag set. While the receipt of a CWR packet does not guarantee that the data sender received the ECN-Echo message, this does suggest that the data sender reduced its congestion window at some point *after* it sent the data packet for which the CE codepoint was set.
TCP受信機がECN-エコービットがセットされたACKパケットを送信した後、そのTCP受信機は、それまで（これらはCEデータパケットまたは非CEデータパケットを承認するかどうか）は、それが送信するすべてのACKパケットにECN-エコーフラグを設定し続けますCWRパケット（CWRフラグが設定されたパケット）を受信します。 CWRパケットを受信した後、その後の非CEデータパケットの確認応答がECN-エコーフラグが設定されていません。別のCEパケットがデータ受信機によって受信された場合、受信機は再びECN-エコーフラグを設定してACKパケットを送信することになります。 CWRパケットの受信がデータ送信者がECN-エコーメッセージを受信することを保証するものではありませんが、これはデータの送信者がいくつかの点でその輻輳ウィンドウを減少することを示唆しているん*後*それがCEコードポイントが設定されたデータ・パケットを送信し。
We have already specified that a TCP sender is not required to reduce its congestion window more than once per window of data. Some care is required if the TCP sender is to avoid unnecessary reductions of the congestion window when a window of data includes both dropped packets and (marked) CE packets. This is illustrated in [Floyd98].
我々はすでにTCPの送信者が複数回のデータの窓あたりよりもその輻輳ウィンドウを減少させるのに必要とされていないことを指定しています。 TCPの送信側がデータのウィンドウには、両方のパケットと（マーク）CEパケットを落とし含ま輻輳ウィンドウの不要な削減を避けるためであれば、いくつかの注意が必要です。これは、[Floyd98]に示されています。
For the current generation of TCP congestion control algorithms, pure acknowledgement packets (e.g., packets that do not contain any accompanying data) MUST be sent with the not-ECT codepoint. Current TCP receivers have no mechanisms for reducing traffic on the ACK-path in response to congestion notification. Mechanisms for responding to congestion on the ACK-path are areas for current and future research. (One simple possibility would be for the sender to reduce its congestion window when it receives a pure ACK packet with the CE codepoint set). For current TCP implementations, a single dropped ACK generally has only a very small effect on the TCP's sending rate.
TCPの輻輳制御アルゴリズムの現在の世代のために、純粋な肯定応答パケットが（例えば、任意の付随するデータを含まないパケット）がない-ECTコードポイントで送信されなければなりません。現在のTCP受信機は輻輳通知に応じて、ACK-パス上のトラフィックを削減するためのメカニズムを持っていません。 ACK-パスの輻輳に応答するメカニズムは、現在および将来の研究のための領域です。 （一つの簡単な可能性は、それがCEコードポイントを設定して、純粋なACKパケットを受信したときにその輻輳ウィンドウを減らすために、送信者のためになります）。現在のTCP実装では、単一のACKは、一般的にTCPの送信レートにのみ、非常に小さな効果を持つ落としました。
This document specifies ECN-capable TCP implementations MUST NOT set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver SHOULD ignore the ECN field on arriving data packets that are outside of the receiver's current window. This is for greater security against denial-of-service attacks, as well as for robustness of the ECN congestion indication with packets that are dropped later in the network.
この文書では、ECN対応のTCP実装はECTコードポイント（ECT（0）かECT（1））、再送データパケットのIPヘッダ内の、およびTCPデータ受信機はそのデータ・パケットを到着にECNフィールドを無視するべきであることのいずれかを設定してはいけません指定します受信機の現在のウィンドウの外にあります。これは、サービス拒否攻撃に対するセキュリティ強化のため、だけでなく、ネットワークの後半で廃棄されたパケットとのECNの輻輳表示の堅牢性のためです。
First, we note that if the TCP sender were to set an ECT codepoint on a retransmitted packet, then if an unnecessarily-retransmitted packet was later dropped in the network, the end nodes would never receive the indication of congestion from the router setting the CE codepoint. Thus, setting an ECT codepoint on retransmitted data packets is not consistent with the robust delivery of the congestion indication even for packets that are later dropped in the network.
まず、TCPの送信側が再送されたパケットにECTコードポイントを設定した場合、不必要に、再送パケットは後でネットワークで落とされた場合、その後、エンド・ノードは、CEの設定ルータから混雑の指示を受信することはないことに注意してくださいコードポイント。このように、再送データパケットにECTコードポイントを設定することも、後でネットワークにドロップされるパケットの輻輳表示のロバストな配達と一致しません。
In addition, an attacker capable of spoofing the IP source address of the TCP sender could send data packets with arbitrary sequence numbers, with the CE codepoint set in the IP header. On receiving this spoofed data packet, the TCP data receiver would determine that the data does not lie in the current receive window, and return a duplicate acknowledgement. We define an out-of-window packet at the TCP data receiver as a data packet that lies outside the receiver's current window. On receiving an out-of-window packet, the TCP data receiver has to decide whether or not to treat the CE codepoint in the packet header as a valid indication of congestion, and therefore whether to return ECN-Echo indications to the TCP data sender. If the TCP data receiver ignored the CE codepoint in an out-of-window packet, then the TCP data sender would not receive this possibly-legitimate indication of congestion from the network, resulting in a violation of end-to-end congestion control. On the other hand, if the TCP data receiver honors the CE indication in the out-of-window packet, and reports the indication of congestion to the TCP data sender, then the malicious node that created the spoofed, out-of-window packet has successfully "attacked" the TCP connection by forcing the data sender to unnecessarily reduce (halve) its congestion window. To prevent such a denial-of-service attack, we specify that a legitimate TCP data sender MUST NOT set an ECT codepoint on retransmitted data packets, and that the TCP data receiver SHOULD ignore the CE codepoint on out-of-window packets.
また、IPヘッダに設定されたCEのコードポイントと、任意のシーケンス番号を有するデータパケットを送信することができるTCP送信者のIP送信元アドレスを偽装することが可能な攻撃。この偽装されたデータパケットを受信すると、TCPデータ受信機は、データが現在の受信ウィンドウ内に存在し、重複確認応答を返さないことを決定するであろう。私たちは、受信機の現在のウィンドウの外にあるデータパケットとしてTCPデータ受信機における外の窓パケットを定義します。アウト・オブ・ウィンドウのパケットを受信すると、TCPデータ受信装置は、輻輳の有効な指標として、パケットヘッダのCEコードポイントを治療するかどうかを決定しなければならないので、TCPデータ送信者にECN-エコー表示を返すかどうか。 TCPデータ受信装置がアウトウィンドウパケットのCEコードポイントを無視した場合、TCPデータ送信者は、エンドツーエンドの輻輳制御に違反して、その結果、ネットワークから輻輳のこのおそらくは、正当な指示を受信しないであろう。一方、アウトオブウインドウパケットで、TCPデータ受信優等であればCE表示、およびTCPデータ送信側に輻輳の兆候を報告し、偽装され、外の窓パケットを作成した後、悪意のあるノード不必要（半体）その輻輳ウィンドウを減少させるために、データの送信者を強制することで成功し「攻撃」のTCPコネクションを持っています。そのようなサービス拒否攻撃を防ぐために、我々は正当なTCPデータの送信者が再送されたデータパケットにECTコードポイントを設定してはいけないこと、およびTCPデータ受信機は外の窓パケットのCEコードポイントを無視するように指定します。
One drawback of not setting ECT(0) or ECT(1) on retransmitted packets is that it denies ECN protection for retransmitted packets. However, for an ECN-capable TCP connection in a fully-ECN-capable environment with mild congestion, packets should rarely be dropped due to congestion in the first place, and so instances of retransmitted packets should rarely arise. If packets are being retransmitted, then there are already packet losses (from corruption or from congestion) that ECN has been unable to prevent.
再送パケットにECT（0）かECT（1）を設定していないの欠点の1つは、それが再送パケットのためのECN保護を否定するということです。しかし、軽度の輻輳と完全に-ECN対応の環境ではECN対応のTCP接続のために、パケットはめったに最初の場所で輻輳が原因で廃棄されるべきではない、ので、再送パケットのインスタンスはめったに発生しないはずです。パケットが再送されている場合は、ECNを防ぐことができなかったこと（破損からか、混雑から）パケット損失が既に存在しています。
We note that if the router sets the CE codepoint for an ECN-capable data packet within a TCP connection, then the TCP connection is guaranteed to receive that indication of congestion, or to receive some other indication of congestion within the same window of data, even if this packet is dropped or reordered in the network. We consider two cases, when the packet is later retransmitted, and when the packet is not later retransmitted.
私たちは、ルータがTCP接続内ECN-可能なデータパケットのためのCEコードポイントを設定した場合、その後、TCPコネクションが輻輳の指示を受信するために、またはデータの同じウィンドウ内の輻輳の他のいくつかの指示を受信することが保証されていることに注意してくださいこのパケットは、ネットワークに落としたり、並べ替えた場合でも。私たちは、パケットが、後に再送されたときに、2例を検討し、パケットがあるときに、後に再送されません。
In the first case, if the packet is either dropped or delayed, and at some point retransmitted by the data sender, then the retransmission is a result of a Fast Retransmit or a Retransmit Timeout for either that packet or for some prior packet in the same window of data. In this case, because the data sender already has retransmitted this packet, we know that the data sender has already responded to an indication of congestion for some packet within the same window of data as the original packet. Thus, even if the first transmission of the packet is dropped in the network, or is delayed, if it had the CE codepoint set, and is later ignored by the data receiver as an out-of-window packet, this is not a problem, because the sender has already responded to an indication of congestion for that window of data.
最初のケースでは、パケットはドロップ又は遅延、及びデータ送信者が再送かの時点で、再送信のいずれか、そのパケットまたは同じである従来のパケットの高速再送信または再送信タイムアウトの結果であるいずれかの場合データの窓。データ送信側は、すでにこのパケットを再送しているので、この場合は、我々はデータの送信者がすでに元のパケットとしてデータの同じウィンドウ内でいくつかのパケットのための輻輳の表示に対応してきたことを知っています。したがって、パケットの最初の送信は、ネットワーク内でドロップされる、または遅延され、それはCEコードポイントのセットを持っていた場合、以降のアウトウィンドウパケットとしてデータ受信機によって無視され、これは問題ではない場合であっても、送信者は、すでにデータのそのウィンドウの輻輳の表示に対応してきましたので。
In the second case, if the packet is never retransmitted by the data sender, then this data packet is the only copy of this data received by the data receiver, and therefore arrives at the data receiver as an in-window packet, regardless of how much the packet might be delayed or reordered. In this case, if the CE codepoint is set on the packet within the network, this will be treated by the data receiver as a valid indication of congestion.
関係なく、どのように、パケットはデータ送信側によって再送されることはありません場合は、2番目のケースで、このデータパケットは、データ受信機で受信し、このデータのコピーのみであるため、イン・ウィンドウのパケットとしてデータ受信機に到着します多くのパケットが遅延したり、並べ替えることがあります。 CEコードポイントがネットワーク内のパケットに設定されている場合この場合、これは、輻輳の有効な指示として、データ受信機によって扱われます。
When the TCP data receiver advertises a zero window, the TCP data sender sends window probes to determine if the receiver's window has increased. Window probe packets do not contain any user data except for the sequence number, which is a byte. If a window probe packet is dropped in the network, this loss is not detected by the receiver. Therefore, the TCP data sender MUST NOT set either an ECT codepoint or the CWR bit on window probe packets.
TCPデータ受信機はゼロウィンドウをアドバタイズすると、TCPデータ送信側は受信側のウィンドウが増加しているかどうかを判断するために、ウィンドウプローブを送信します。ウィンドウプローブパケットは、バイトシーケンス番号、を除くすべてのユーザー・データを含んでいません。ウィンドウプローブパケットがネットワーク内でドロップされた場合、この損失は、受信機によって検出されません。そのため、TCPデータの送信者は、ECTコードポイントまたはウィンドウプローブパケットのCWRビットのいずれかを設定してはいけません。
However, because window probes use exact sequence numbers, they cannot be easily spoofed in denial-of-service attacks. Therefore, if a window probe arrives with the CE codepoint set, then the receiver SHOULD respond to the ECN indications.
ウィンドウプローブは、正確なシーケンス番号を使用するためしかし、彼らは簡単に、サービス拒否攻撃に詐称することはできません。ウィンドウプローブがCEコードポイントを設定して到着した場合そのため、受信機は、ECNの兆候に応じます。
This section discusses concerns about the vulnerability of ECN to non-compliant end-nodes (i.e., end nodes that set the ECT codepoint in transmitted packets but do not respond to received CE packets). We argue that the addition of ECN to the IP architecture will not significantly increase the current vulnerability of the architecture to unresponsive flows.
このセクションでは、非準拠のエンドノード（送信パケットにECTコードポイントを設定するが、受信CEパケットに応答しない、すなわち、エンドノード）への電子証券取引ネットワークの脆弱性についての懸念を議論します。私たちは、IPアーキテクチャにECNの添加が大幅に無反応流れにアーキテクチャの現在の脆弱性を増加させないと主張しています。
Even for non-ECN environments, there are serious concerns about the damage that can be done by non-compliant or unresponsive flows (that is, flows that do not respond to congestion control indications by reducing their arrival rate at the congested link). For example, an end-node could "turn off congestion control" by not reducing its congestion window in response to packet drops. This is a concern for the current Internet. It has been argued that routers will have to deploy mechanisms to detect and differentially treat packets from non-compliant flows [RFC2309,FF99]. It has also been suggested that techniques such as end-to-end per-flow scheduling and isolation of one flow from another, differentiated services, or end-to-end reservations could remove some of the more damaging effects of unresponsive flows.
でも非ECN環境のために、（つまり、混雑したリンクで彼らの到着率を減らすことによって、輻輳制御の適応症に応答しない流れである）、非準拠または無応答フローによって行うことができる損害について深刻な懸念があります。例えば、エンド・ノードは、パケットドロップに応答して輻輳ウィンドウを減少しないことにより、「輻輳制御をオフにする」ことができました。これは、現在のインターネットの懸念です。ルータが検出し、差動非対応の流れ[RFC2309、FF99]からのパケットを処理するためのメカニズムを展開する必要がありますと主張されてきました。また、エンド・ツー・エンドのフロー単位のスケジューリングとから別の流れの隔離、差別化サービス、またはエンド・ツー・エンドの予約のような技術が応答フローのより有害な影響の一部を取り除くことができることが示唆されています。
It might seem that dropping packets in itself is an adequate deterrent for non-compliance, and that the use of ECN removes this deterrent. We would argue in response that (1) ECN-capable routers preserve packet-dropping behavior in times of high congestion; and (2) even in times of high congestion, dropping packets in itself is not an adequate deterrent for non-compliance.
それ自体でパケットをドロップすると、非遵守のための十分な抑止力であること、およびECNの使用は、この抑止力を取り除くように見えるかもしれません。我々は、（1）ECN対応ルータが高い混雑の時間にパケットドロップ動作を保持することを応答して主張。 （2）も高い混雑の時間で、それ自体にパケットをドロップすると、非遵守のための適切な抑止力ではありません。
First, ECN-Capable routers will only mark packets (as opposed to dropping them) when the packet marking rate is reasonably low. During periods where the average queue size exceeds an upper threshold, and therefore the potential packet marking rate would be high, our recommendation is that routers drop packets rather then set the CE codepoint in packet headers.
まず、ECN対応ルータは、パケットマーキング率が適度に低い場合（それらを落とすとは反対に）パケットをマークのみになります。平均キューサイズが上限閾値を超え、したがって潜在パケットマーキング率が高いであろう期間中、私たちの推薦は、ルータードロップパケットはなく、パケットヘッダ内のCEコードポイントを設定することです。
During the periods of low or moderate packet marking rates when ECN would be deployed, there would be little deterrent effect on unresponsive flows of dropping rather than marking those packets. For example, delay-insensitive flows using reliable delivery might have an incentive to increase rather than to decrease their sending rate in the presence of dropped packets. Similarly, delay-sensitive flows using unreliable delivery might increase their use of FEC in response to an increased packet drop rate, increasing rather than decreasing their sending rate. For the same reasons, we do not believe that packet dropping itself is an effective deterrent for non-compliance even in an environment of high packet drop rates, when all flows are sharing the same packet drop rate.
ECNが展開されるだろうというとき、落下ではなく、それらのパケットをマーキングの無反応流れにほとんど抑止効果があるだろう、低または中程度のパケットマーキング金利の期間中。例えば、信頼性の高い配信を使用して遅延の影響を受けないフローが増加するのではなく破棄されたパケットの存在下で、彼らの送信速度を低下させるためにインセンティブを持っているかもしれません。同様に、信頼性のない配信を使用して、遅延に敏感なフローが増加するのではなく、それらの送信レートを減少、増加パケットドロップ率に応じてFECの使用を増加させるかもしれません。同じ理由から、我々はパケット自体を落とすとは考えていないすべてのフローが同じパケットドロップ率を共有しているとき、高くてもパケットのドロップ率の環境での非遵守のための効果的な抑止力です。
Several methods have been proposed to identify and restrict non-compliant or unresponsive flows. The addition of ECN to the network environment would not in any way increase the difficulty of designing and deploying such mechanisms. If anything, the addition of ECN to the architecture would make the job of identifying unresponsive flows slightly easier. For example, in an ECN-Capable environment routers are not limited to information about packets that are dropped or have the CE codepoint set at that router itself; in such an environment, routers could also take note of arriving CE packets that indicate congestion encountered by that packet earlier in the path.
いくつかの方法が、非準拠または無応答フローを識別して制限するために提案されてきました。ネットワーク環境にECNの追加は、どのような方法で設計すると、このような仕組みを導入することの難しさを増加させないでしょう。どちらかといえば、建築にECNの添加は無反応の流れを特定の仕事が少し楽になります。例えば、ECN対応の環境のルーターに落としたり、そのルータ自体に設定CEコードポイントを持っているパケットに関する情報に限定されるものではありません。このような環境では、ルータは、それ以前のパスでそのパケットが遭遇混雑を示すCEパケット到着のノートを取ることができます。
This section considers the issues when a router is operating, possibly maliciously, to modify either of the bits in the ECN field. We note that in IPv4, the IP header is protected from bit errors by a header checksum; this is not the case in IPv6. Thus for IPv6 the ECN field can be accidentally modified by bit errors on links or in routers without being detected by an IP header checksum.
ルータがECNフィールド内のビットのいずれかを変更するために、おそらく悪意を持って、動作している場合は、このセクションでは、問題を検討します。我々は、IPv4において、IPヘッダは、ヘッダチェックサムによってビットエラーから保護されていることに注意してください。これは、IPv6ではそうではありません。したがってIPv6のECNフィールドが誤ったIPヘッダチェックサムによって検出されることなく、リンク上またはルータのビットエラーによって修正することができます。
By tampering with the bits in the ECN field, an adversary (or a broken router) could do one or more of the following: falsely report congestion, disable ECN-Capability for an individual packet, erase the ECN congestion indication, or falsely indicate ECN-Capability. Section 18 systematically examines the various cases by which the ECN field could be modified. The important criterion considered in determining the consequences of such modifications is whether it is likely to lead to poorer behavior in any dimension (throughput, delay, fairness or functionality) than if a router were to drop a packet.
ECNフィールド内のビット、敵（または壊れたルータ）を改ざんすることにより、以下の一つ以上行うことができます：誤ってレポートの混雑を、ECNの輻輳表示を消去し、個々のパケットのためのECN-機能を無効にする、または誤ってECNを示しています-能力。セクション18は、系統的ECNフィールドを変更することができたことによって、様々なケースを検討します。そのような変更の影響を決定する際に考慮重要な基準は、ルータがパケットをドロップした場合よりも、任意の次元（スループット、遅延、公正性や機能性）で貧しい行動につながる可能性があるかどうかです。
The first two possible changes, falsely reporting congestion or disabling ECN-Capability for an individual packet, are no worse than if the router were to simply drop the packet. From a congestion control point of view, setting the CE codepoint in the absence of congestion by a non-compliant router would be no worse than a router dropping a packet unnecessarily. By "erasing" an ECT codepoint of a packet that is later dropped in the network, a router's actions could result in an unnecessary packet drop for that packet later in the network.
最初の二つの可能な変更を、誤って混雑を報告したり、個々のパケットのためのECN-機能を無効にするには、ルータは単にパケットをドロップした場合よりも悪化していません。ビューの輻輳制御の観点から、非対応ルータで輻輳が存在しない状態でCEコードポイントを設定すると、不必要にパケットを落とすルータよりも悪化しないでしょう。後でネットワークで落とされるパケットのECTコードポイントを「消去」することで、ルータの行動は、後に、ネットワーク内のそのパケットの不要なパケットのドロップにつながる可能性があります。
However, as discussed in Section 18, a router that erases the ECN congestion indication or falsely indicates ECN-Capability could potentially do more damage to the flow that if it has simply dropped the packet. A rogue or broken router that "erased" the CE codepoint in arriving CE packets would prevent that indication of congestion from reaching downstream receivers. This could result in the failure of congestion control for that flow and a resulting increase in congestion in the network, ultimately resulting in subsequent packets dropped for this flow as the average queue size increased at the congested gateway.
第18節で述べたようにしかし、誤ってECNの輻輳表示を消去またはルータがECN-能力が潜在的に、それは単にパケットを落とした場合、その流れに多くのダメージを行うことができますを示しています。不正または「消去」という壊れたルータは、CEパケット到着におけるCEコードポイントは、下流の受信機に到達するの輻輳の表示を防止するであろう。平均キューサイズが輻輳ゲートウェイで増加するにつれて、これは、輻輳そのフローの制御およびネットワークの輻輳中の得られた増加の故障につながる可能性があり、最終的にはその後のパケットが得られると、このフローのためにドロップされました。
Section 19 considers the potential repercussions of subverting end-to-end congestion control by either falsely indicating ECN-Capability, or by erasing the congestion indication in ECN (the CE-codepoint). We observe in Section 19 that the consequence of subverting ECN-based congestion control may lead to potential unfairness, but this is likely to be no worse than the subversion of either ECN-based or packet-based congestion control by the end nodes.
セクション19は、いずれかの誤指示ECN-能力によって、またはECN（CE-コードポイント）に輻輳表示を消去することにより、エンドツーエンドの輻輳制御を破壊するの潜在的な影響を考慮する。私たちは、ECNベースの輻輳制御を破壊するの結果は、潜在的な不公平につながる可能性があること、セクション19で観察するが、これは、エンド・ノードによってECNベースまたはパケットベースの輻輳制御のいずれかの転覆より悪い何のことはないと思われます。
If a router or other network element has access to all of the packets of a flow, then that router could do no more damage to a flow by altering the ECN field than it could by simply dropping all of the packets from that flow. However, in some cases, a malicious or broken router might have access to only a subset of the packets from a flow. The question is as follows: can this router, by altering the ECN field in this subset of the packets, do more damage to that flow than if it has simply dropped that set of the packets?
ルータまたは他のネットワーク要素がフローのパケットのすべてにアクセスしている場合、そのルータは、単にその流れからのパケットをすべてドロップすることにより、それができるよりECNフィールドを変更することによって、フローへのより多くのダメージを与えることができませんでした。しかし、いくつかのケースでは、悪質な、または壊れたルータは、フローからのパケットのサブセットのみにアクセスできる場合があります。次のように質問です：このルータは、パケットのこのサブセットでECNフィールドを変更することによって、そのフローに多くのダメージを行うことができ、それは単にパケットのセットを落とした場合よりも？
This is also discussed in detail in Section 18, which concludes as follows: It is true that the adversary that has access only to a subset of packets in an aggregate might, by subverting ECN-based congestion control, be able to deny the benefits of ECN to the other packets in the aggregate. While this is undesirable, this is not a sufficient concern to result in disabling ECN.
これは、次のように結論付けセクション18に詳細に議論されています。集計にのみパケットのサブセットへのアクセスを持っている敵は、ECNベースの輻輳制御を破壊することで、の恩恵を拒否することができるかもしれないという事実であります集計中の他のパケットにECN。これは望ましくないが、これはECNを無効になるために十分な関心事ではありません。
The encapsulation of IP packet headers in tunnels is used in many places, including IPsec and IP in IP [RFC2003]. This section considers issues related to interactions between ECN and IP tunnels, and specifies two alternative solutions. This discussion is complemented by RFC 2983's discussion of interactions between Differentiated Services and IP tunnels of various forms [RFC 2983], as Differentiated Services uses the remaining six bits of the IP header octet that is used by ECN (see Figure 2 in Section 5).
トンネル内でIPパケットヘッダのカプセル化は、IP [RFC2003]のIPsecおよびIPを含む多くの場所で使用されています。このセクションでは、ECNとIPトンネル間の相互作用に関連する問題を考慮し、2つの代替ソリューションを指定します。差別化サービスは、ECNによって使用されるIPヘッダオクテットの残りの6ビットを使用するように、この議論は（セクション5で図2を参照）、種々の形態の差別化サービスとIPトンネルとの間の相互作用のRFC 2983の議論[RFC 2983]によって補完され。
Some IP tunnel modes are based on adding a new "outer" IP header that encapsulates the original, or "inner" IP header and its associated packet. In many cases, the new "outer" IP header may be added and removed at intermediate points along a connection, enabling the network to establish a tunnel without requiring endpoint participation. We denote tunnels that specify that the outer header be discarded at tunnel egress as "simple tunnels".
いくつかのIPトンネルモードは、元の、又は「内側」IPヘッダとそれに関連するパケットをカプセル化する新しい「外側」IPヘッダを付加することに基づいています。多くの場合、新たな「外部」IPヘッダは、エンドポイントの参加を必要とせずにトンネルを確立するためにネットワークを可能に、接続に沿った中間点で添加し、除去することができます。我々は、外側のヘッダが「単純トンネル」としてトンネル出口で廃棄するように指定トンネルを示します。
ECN uses the ECN field in the IP header for signaling between routers and connection endpoints. ECN interacts with IP tunnels based on the treatment of the ECN field in the IP header. In simple IP tunnels the octet containing the ECN field is copied or mapped from the inner IP header to the outer IP header at IP tunnel ingress, and the outer header's copy of this field is discarded at IP tunnel egress. If the outer header were to be simply discarded without taking care to deal with the ECN field, and an ECN-capable router were to set the CE (Congestion Experienced) codepoint within a packet in a simple IP tunnel, this indication would be discarded at tunnel egress, losing the indication of congestion.
ECNは、ルータと接続エンドポイント間のシグナリングのためのIPヘッダ内のECNフィールドを使用します。 ECNは、IPヘッダ内のECNフィールドの処理に基づいて、IPトンネルと相互作用します。シンプルIPにECNフィールドを含むオクテットがコピーまたはIPトンネル入口で外部IPヘッダに内側IPヘッダーからマッピングされるトンネル、このフィールドの外側のヘッダのコピーがIPトンネル出口で廃棄されます。外側のヘッダは単にECNフィールドに対処するために世話をすることなく破棄することであった場合、およびECN対応ルータは、単純なIPトンネルでパケット内のCE（輻輳経験豊富な）コードポイントを設定していた、この指示がで廃棄されるであろうトンネル出口、輻輳の指標を失います。
Thus, the use of ECN over simple IP tunnels would result in routers attempting to use the outer IP header to signal congestion to endpoints, but those congestion warnings never arriving because the outer header is discarded at the tunnel egress point. This problem was encountered with ECN and IPsec in tunnel mode, and RFC 2481 recommended that ECN not be used with the older simple IPsec tunnels in order to avoid this behavior and its consequences. When ECN becomes widely deployed, then simple tunnels likely to carry ECN-capable traffic will have to be changed. If ECN-capable traffic is carried by a simple tunnel through a congested, ECN-capable router, this could result in subsequent packets being dropped for this flow as the average queue size increases at the congested router, as discussed in Section 8 above.
したがって、単純なIPトンネル上ECNの使用は、エンドポイントに輻輳を通知するために外側のIPヘッダを使用しようとするルータをもたらすであろうが、外部ヘッダは、トンネル出口ポイントで廃棄されるので、それらの混雑警告は決して到達しません。この問題は、トンネルモードでECNとIPsecで発生した、とRFC 2481はECNは、この行動とその結果を避けるために、古いシンプルなIPsecトンネルを使用しないことをお勧めします。 ECNが広く展開になると、その後、ECN対応のトラフィックを伝送する可能性が高い簡単なトンネルを変更する必要があります。 ECN対応のトラフィックが混雑し、ECN対応ルータを介して簡単なトンネルによって実施される場合、これは後続のパケットにつながる可能性上記セクション8で説明したように、輻輳ルータにおける平均キューサイズが増加するにつれて、この流れのためにドロップされます。
From a security point of view, the use of ECN in the outer header of an IP tunnel might raise security concerns because an adversary could tamper with the ECN information that propagates beyond the tunnel endpoint. Based on an analysis in Sections 18 and 19 of these concerns and the resultant risks, our overall approach is to make support for ECN an option for IP tunnels, so that an IP tunnel can be specified or configured either to use ECN or not to use ECN in the outer header of the tunnel. Thus, in environments or tunneling protocols where the risks of using ECN are judged to outweigh its benefits, the tunnel can simply not use ECN in the outer header. Then the only indication of congestion experienced at routers within the tunnel would be through packet loss.
敵対者がトンネルのエンドポイントを超えて伝播ECN情報を改ざん可能性があるため、セキュリティの観点からは、IPトンネルの外側のヘッダーに電子証券取引ネットワークを使用することは、セキュリティ上の問題を提起することがあります。セクション18と、これらの懸念し、得られたリスクの19での分析に基づいて、当社の全体的なアプローチは、IPトンネルを使用するECNを使用するかしないかのどちらかに指定または設定することができるように、ECNのためのIPトンネルのオプションをサポートすることですトンネルの外側のヘッダにECN。したがって、ECNを用いてのリスクがその利点を上回ると判断された環境またはトンネリングプロトコルでは、トンネルは単に外側のヘッダにECNを使用することはできません。その後、トンネル内のルータで経験混雑の唯一の指標はパケット損失によるものであろう。
The result is that there are two viable options for the behavior of ECN-capable connections over an IP tunnel, including IPsec tunnels:
結果は、IPsecトンネルを含むIPトンネルを介しECN可能な接続の動作のための2つの実行可能なオプションが存在することです。
* A limited-functionality option in which ECN is preserved in the inner header, but disabled in the outer header. The only mechanism available for signaling congestion occurring within the tunnel in this case is dropped packets.
* ECNは、内部ヘッダに保存するが、外部ヘッダで無効にされた制限された機能制限オプション。この場合、トンネル内で発生する輻輳をシグナリングするために利用可能な唯一の機構は、ドロップされたパケットです。
* A full-functionality option that supports ECN in both the inner and outer headers, and propagates congestion warnings from nodes within the tunnel to endpoints.
両方の内側と外側のヘッダにECNをサポートし、エンドポイントにトンネル内のノードから輻輳警告を伝播*フル機能のオプション。
Support for these options requires varying amounts of changes to IP header processing at tunnel ingress and egress. A small subset of these changes sufficient to support only the limited-functionality option would be sufficient to eliminate any incompatibility between ECN and IP tunnels.
これらのオプションのためのサポートは、トンネル入口および出口におけるIPヘッダ処理の変更の様々な量を必要とします。限られた機能なオプションをサポートするのに十分なこれらの変化の小さいサブセットは、ECNとIPトンネル間の任意の非互換性を排除するのに十分だろう。
One goal of this document is to give guidance about the tradeoffs between the limited-functionality and full-functionality options. A full discussion of the potential effects of an adversary's modifications of the ECN field is given in Sections 18 and 19.
このドキュメントの目標の1つは、限られた機能性と、フル機能のオプションの間のトレードオフについてのガイダンスを提供することです。 ECNフィールドの敵の変更の潜在的な効果の完全な議論は、セクション18及び19に示されています。
The limited-functionality option for ECN encapsulation in IP tunnels is for the not-ECT codepoint to be set in the outside (encapsulating) header regardless of the value of the ECN field in the inside (encapsulated) header. With this option, the ECN field in the inner header is not altered upon de-capsulation. The disadvantage of this approach is that the flow does not have ECN support for that part of the path that is using IP tunneling, even if the encapsulated packet (from the original TCP sender) is ECN-Capable. That is, if the encapsulated packet arrives at a congested router that is ECN-capable, and the router can decide to drop or mark the packet as an indication of congestion to the end nodes, the router will not be permitted to set the CE codepoint in the packet header, but instead will have to drop the packet.
未ECTコードポイントにかかわらず、内部（カプセル化）ヘッダ内のECNフィールドの値の外側（カプセル化）ヘッダに設定するためのIPトンネル内のECN封止用限られた機能オプションがあります。このオプションでは、内側のヘッダーのECNフィールドは、脱カプセル時に変更されません。このアプローチの欠点は、流れは（オリジナルのTCP送信者からの）カプセル化されたパケットがECN-可能であっても、IPトンネリングを使用している経路のその部分のためのECNをサポートしていないことです。カプセル化されたパケットがECN-可能な輻輳ルータに到着し、ルータはエンドノードに輻輳の指標としてパケットを廃棄またはマークすることを決定することができる場合には、ルータがCEコードポイントを設定することが許可されることはありませんされていますパケットヘッダに、代わりにパケットをドロップする必要があります。
The full-functionality option for ECN encapsulation is to copy the ECN codepoint of the inside header to the outside header on encapsulation if the inside header is not-ECT or ECT, and to set the ECN codepoint of the outside header to ECT(0) if the ECN codepoint of the inside header is CE. On decapsulation, if the CE codepoint is set on the outside header, then the CE codepoint is also set in the inner header. Otherwise, the ECN codepoint on the inner header is left unchanged. That is, for full ECN support the encapsulation and decapsulation processing involves the following: At tunnel ingress, the full-functionality option sets the ECN codepoint in the outer header. If the ECN codepoint in the inner header is not-ECT or ECT, then it is copied to the ECN codepoint in the outer header. If the ECN codepoint in the inner header is CE, then the ECN codepoint in the outer header is set to ECT(0). Upon decapsulation at the tunnel egress, the full-functionality option sets the CE codepoint in the inner header if the CE codepoint is set in the outer header. Otherwise, no change is made to this field of the inner header.
ECNカプセル化のためのフル機能のオプションは、内部ヘッダではなく、ECTまたはECTであればカプセルに外部ヘッダに内部ヘッダのECNコードポイントをコピーすること、およびECTの外部ヘッダのECNコードポイントを設定することである（0）内部ヘッダのECNコードポイントは、CEである場合。 CEコードポイントが外部ヘッダに設定されている場合にデカプセル化、次いでCEコードポイントはまた、内側のヘッダーに設定されています。そうでなければ、内部ヘッダにECNコードポイントは不変のままです。すなわち、完全なECNのカプセル化及びデカプセル化処理は、以下を含むサポート、である：トンネル入口で、フル機能のオプションは、外側のヘッダにECNコードポイントを設定します。インナーヘッダ内のECNコードポイントではなく、ECTまたはECTである場合、それは外側のヘッダ内のECNコードポイントにコピーされます。インナーヘッダ内のECNコードポイントがCEである場合には、アウターヘッダ内のECNコードポイントは、ECT（0）に設定されています。 CEコードポイントは、外側ヘッダに設定されている場合、トンネル出口でデカプセル化の際に、フル機能のオプションは、内部ヘッダ内のCEコードポイントを設定します。そうでなければ、変化は内部ヘッダのこのフィールドには行われません。
With the full-functionality option, a flow can take advantage of ECN in those parts of the path that might use IP tunneling. The disadvantage of the full-functionality option from a security perspective is that the IP tunnel cannot protect the flow from certain modifications to the ECN bits in the IP header within the tunnel. The potential dangers from modifications to the ECN bits in the IP header are described in detail in Sections 18 and 19.
フル機能のオプションを使用すると、流れは、IPトンネリングを使用する場合がありますパスの部分にECNを利用することができます。セキュリティの観点から、フル機能のオプションの欠点は、IPトンネルは、トンネル内のIPヘッダ内のECNビットに特定の修正からの流れを保護することができないことです。 IPヘッダ内のECNビットに変更からの潜在的な危険性は、セクション18及び19に詳細に記載されています。
(1) An IP tunnel MUST modify the handling of the DS field octet at IP tunnel endpoints by implementing either the limited-functionality or the full-functionality option.
（1）IPトンネルは限定機能やフル機能のオプションのいずれかを実装することによって、IPトンネルのエンドポイントでのDSフィールドのオクテットの取り扱いを変更する必要があります。
(2) Optionally, an IP tunnel MAY enable the endpoints of an IP tunnel to negotiate the choice between the limited-functionality and the full-functionality option for ECN in the tunnel.
（2）必要に応じて、IPトンネルは限定機能とトンネル内ECNのフル機能のオプション間の選択を交渉するためにIPトンネルのエンドポイントを可能にすることができます。
The minimum required to make ECN usable with IP tunnels is the limited-functionality option, which prevents ECN from being enabled in the outer header of the tunnel. Full support for ECN requires the use of the full-functionality option. If there are no optional mechanisms for the tunnel endpoints to negotiate a choice between the limited-functionality or full-functionality option, there can be a pre-existing agreement between the tunnel endpoints about whether to support the limited-functionality or the full-functionality ECN option.
IPトンネルとECNを使用可能にするために必要な最小のトンネルの外側のヘッダーで有効にされるのECNを防止する制限された機能がオプションです。 ECNのフルサポートは、フル機能のオプションを使用する必要があります。トンネルエンドポイントは限られた機能や、フル機能のオプションの間の選択を交渉するためのオプションのメカニズムが存在しない場合は、制限された機能や、フル機能をサポートするかどうかについてのトンネルエンドポイント間の既存の合意ができECNオプション。
All IP tunnels MUST implement the limited-functionality option, and SHOULD support the full-functionality option.
すべてのIPトンネルは限られた機能性オプションを実装しなければならない、とフル機能のオプションをサポートする必要があります。
In addition, it is RECOMMENDED that packets with the CE codepoint in the outer header be dropped if they arrive at the tunnel egress point for a tunnel that uses the limited-functionality option, or for a tunnel that uses the full-functionality option but for which the not-ECT codepoint is set in the inner header. This is motivated by backwards compatibility and to ensure that no unauthorized modifications of the ECN field take place, and is discussed further in the next Section (9.1.2).
加えて、それらは限られた機能オプションを使用して、またはフル機能のオプションを使用してトンネルのしかしためのトンネルのトンネル出口点に到着した場合、外部ヘッダのCEコードポイントを持つパケットが廃棄されることが推奨されますこれはない-ECTコードポイントがインナーヘッダに設定されています。これは、後方互換性によって動機付けされ、ECNフィールドのない不正な改変が行われないことを確実にするために、次のセクション（9.1.2）で詳しく説明されています。
The presence of a copy of the ECN field in the inner header of an IP tunnel mode packet provides an opportunity for detection of unauthorized modifications to the ECN field in the outer header. Comparison of the ECT fields in the inner and outer headers falls into two categories for implementations that conform to this document:
IPトンネルモードパケットの内部ヘッダ内のECNフィールドのコピーの存在は、外側のヘッダーの電子証券取引ネットワーク分野への不正変更を検出するための機会を提供します。内側と外側のヘッダーのECTフィールドの比較は、この文書に準拠実装するための2つのカテゴリに分類されます。
* If the IP tunnel uses the full-functionality option, then the not-ECT codepoint should be set in the outer header if and only if it is also set in the inner header.
IPトンネルは、フル機能のオプションを使用する場合*は、未ECTコードポイントがあれば、外ヘッダに設定されるべきであり、また、インナーヘッダに設定されている場合のみ。
* If the tunnel uses the limited-functionality option, then the not-ECT codepoint should be set in the outer header.
トンネルは、限定機能オプションを使用する場合*は、未ECTコードポイントは、外側のヘッダに設定されるべきです。
Receipt of a packet not satisfying the appropriate condition could be a cause of concern.
適切な条件を満たしていないパケットの受信は、懸念の原因である可能性があります。
Consider the case of an IP tunnel where the tunnel ingress point has not been updated to this document's requirements, while the tunnel egress point has been updated to support ECN. In this case, the IP tunnel is not explicitly configured to support the full-functionality ECN option. However, the tunnel ingress point is behaving identically to a tunnel ingress point that supports the full-functionality option. If packets from an ECN-capable connection use this tunnel, the ECT codepoint will be set in the outer header at the tunnel ingress point. Congestion within the tunnel may then result in ECN-capable routers setting CE in the outer header. Because the tunnel has not been explicitly configured to support the full-functionality option, the tunnel egress point expects the not-ECT codepoint to be set in the outer header. When an ECN-capable tunnel egress point receives a packet with the ECT or CE codepoint in the outer header, in a tunnel that has not been configured to support the full-functionality option, that packet should be processed, according to whether the CE codepoint was set, as follows. It is RECOMMENDED that on a tunnel that has not been configured to support the full-functionality option, packets should be dropped at the egress point if the CE codepoint is set in the outer header but not in the inner header, and should be forwarded otherwise.
トンネル出口ポイントがECNをサポートするように更新されているがトンネル入口ポイントは、本文書の要求事項に更新されていないIPトンネルのケースを考えてみましょう。この場合、IPトンネルは、明示的にフル機能のECNオプションをサポートするように設定されていません。しかし、トンネル入口のポイントは、フル機能のオプションをサポートしているトンネル入口ポイントと同一に動作しています。 ECN-可能な接続からのパケットは、このトンネルを使用する場合、ECTコードポイントは、トンネル入口点で外側のヘッダーに設定されます。トンネル内の輻輳は、次いで外側のヘッダーにCEを設定ECN対応ルータをもたらすことができます。トンネルは、明示的フル機能のオプションをサポートするように構成されていないため、トンネル出口ポイントではなく、ECTコードポイントは、外側ヘッダに設定されることを期待します。 ECN対応のトンネル出口ポイントは外側のヘッダーにECTまたはCEコードポイントでパケットを受信した場合、フル機能のオプションをサポートするように構成されていないトンネル内で、そのパケットはCEコードポイントかどうかに応じて、処理されるべきです以下のように、設定されました。 CEコードポイントを外側のヘッダーになく、内側ヘッダに設定され、そうでなければ転送する必要がある場合には、フル機能のオプションをサポートするように構成されていないトンネル上で、パケットが出口点でドロップすることが推奨されています。
An IP tunnel cannot provide protection against erasure of congestion indications based on changing the ECN codepoint from CE to ECT. The erasure of congestion indications may impact the network and other flows in ways that would not be possible in the absence of ECN. It is important to note that erasure of congestion indications can only be performed to congestion indications placed by nodes within the tunnel; the copy of the ECN field in the inner header preserves congestion notifications from nodes upstream of the tunnel ingress (unless the inner header is also erased). If erasure of congestion notifications is judged to be a security risk that exceeds the congestion management benefits of ECN, then tunnels could be specified or configured to use the limited-functionality option.
IPトンネルは、ECTにCEからECNコードポイントの変更に基づいて渋滞表示の消去に対する保護を提供することはできません。輻輳表示の消去は、ECNの非存在下では不可能な方法で、ネットワークや他のフローに影響を与えるかもしれません。輻輳表示の消去だけトンネル内のノードが配置された輻輳指示を行うことができることに留意することが重要です。 （インナーヘッダも消去されない限り）内のヘッダーの電子証券取引ネットワーク分野のコピーは、トンネル入口の上流のノードから輻輳通知を保存します。輻輳通知の消去がECNの輻輳管理の利点を超えて、セキュリティ上のリスクであると判断された場合、トンネルは、指定または限定された機能のオプションを使用するように構成することができます。
IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode, that span a wide range of security requirements and operating environments. Transport mode security protocol header(s) are inserted between the IP (IPv4 or IPv6) header and higher layer protocol headers (e.g., TCP), and hence transport mode can only be used for end-to-end security on a connection. IPsec tunnel mode is based on adding a new "outer" IP header that encapsulates the original, or "inner" IP header and its associated packet. Tunnel mode security headers are inserted between these two IP headers. In contrast to transport mode, the new "outer"
IPsecは、このような中間ルータなどの潜在的に安全でないネットワークコンポーネント上の安全な通信をサポートします。 IPsecプロトコルは、セキュリティ要件及び動作環境の広範囲に及ぶ2つの動作モード、トランスポートモードとトンネルモードをサポートします。トランスポート・モードのセキュリティ・プロトコル・ヘッダ（単数または複数）はIP（IPv4またはIPv6）ヘッダと上位層プロトコルヘッダ（例えば、TCP）の間に挿入され、ひいてはモードのみの接続上のエンドツーエンドのセキュリティのために使用することができる輸送します。 IPsecトンネルモードは、元の、又は「内側」IPヘッダとそれに関連するパケットをカプセル化する新しい「外側」IPヘッダを付加することに基づいています。トンネルモードのセキュリティヘッダは、これらの2つのIPヘッダーの間に挿入されています。モードを輸送するとは対照的に、新しい「外」
IP header and tunnel mode security headers can be added and removed at intermediate points along a connection, enabling security gateways to secure vulnerable portions of a connection without requiring endpoint participation in the security protocols. An important aspect of tunnel mode security is that in the original specification, the outer header is discarded at tunnel egress, ensuring that security threats based on modifying the IP header do not propagate beyond that tunnel endpoint. Further discussion of IPsec can be found in [RFC2401].
IPヘッダとトンネルモードのセキュリティヘッダは、セキュリティプロトコルにおけるエンドポイントの参加を必要とせずに、接続の脆弱な部分を固定するために、セキュリティゲートウェイを可能にする、接続に沿った中間点で添加し、除去することができます。トンネルモードのセキュリティの重要な側面は、元の仕様で、外部ヘッダは、IPヘッダを変更することに基づいて、セキュリティの脅威は、そのトンネルのエンドポイントを超えて伝播しないことを確実にすること、トンネル出口で廃棄されることです。 IPsecのさらなる議論は、[RFC2401]に見出すことができます。
The IPsec protocol as originally defined in [ESP, AH] required that the inner header's ECN field not be changed by IPsec decapsulation processing at a tunnel egress node; this would have ruled out the possibility of full-functionality mode for ECN. At the same time, this would ensure that an adversary's modifications to the ECN field cannot be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, as any such modifications will be discarded at the tunnel endpoint.
元々[ESP、AH]で定義されるIPsecプロトコルは、内部ヘッダのECNフィールドはトンネル出口ノードでのIPsecカプセル化解除処理によって変更されないことが必要。これは、ECNのためのフル機能モードの可能性を除外しているだろう。同時に、これはどのような修正は、トンネルのエンドポイントで廃棄されるように、ECNフィールドに敵の変更は、IPsecトンネルのエンドポイント間でtheft-やサービス拒否攻撃を起動するために使用することができないことを確実にするでしょう。
In principle, permitting the use of ECN functionality in the outer header of an IPsec tunnel raises security concerns because an adversary could tamper with the information that propagates beyond the tunnel endpoint. Based on an analysis (included in Sections 18 and 19) of these concerns and the associated risks, our overall approach has been to provide configuration support for IPsec changes to remove the conflict with ECN.
敵対者がトンネルのエンドポイントを超えて伝播する情報を改ざんする可能性があるため、原理的に、IPsecトンネルの外側のヘッダにECN機能の使用を許可すると、セキュリティ上の懸念を提起します。これらの懸念と関連するリスクの（セクション18及び19に含まれる）の分析に基づいて、当社の全体的なアプローチは、ECNとの競合を除去するためのIPsecの変更のためのコンフィギュレーションのサポートを提供することでした。
In particular, in tunnel mode the IPsec tunnel MUST support the limited-functionality option outlined in Section 9.1.1, and SHOULD support the full-functionality option outlined in Section 9.1.1.
具体的には、トンネルモードでIPsecトンネルは、セクション9.1.1に概説限定機能のオプションをサポートしなければなりません、そして、セクション9.1.1に概説フル機能のオプションをサポートする必要があります。
This makes permission to use ECN functionality in the outer header of an IPsec tunnel a configurable part of the corresponding IPsec Security Association (SA), so that it can be disabled in situations where the risks are judged to outweigh the benefits. The result is that an IPsec security administrator is presented with two alternatives for the behavior of ECN-capable connections within an IPsec tunnel, the limited-functionality alternative and full-functionality alternative described earlier.
これは、リスクが利益を上回ると判断される状況で無効にすることができるように許可が、IPsecトンネル対応のIPsecセキュリティアソシエーション（SA）の設定可能な部分の外側のヘッダにECN機能を使用することができます。結果は、IPsecセキュリティ管理者は、IPsecトンネル、限られた機能の代替と前述したフル機能の代替内のECN-可能な接続の動作のために二つの選択肢が提示されることです。
In addition, this document specifies how the endpoints of an IPsec tunnel could negotiate enabling ECN functionality in the outer headers of that tunnel based on security policy. The ability to negotiate ECN usage between tunnel endpoints would enable a security administrator to disable ECN in situations where she believes the risks (e.g., of lost congestion notifications) outweigh the benefits of ECN.
また、この文書は、IPsecトンネルのエンドポイントがセキュリティポリシーに基づいて、そのトンネルの外側のヘッダにECN機能を有効に交渉することができるかを指定します。トンネルエンドポイント間のECNの使用を交渉する能力は、彼女が（失われた混雑通知の例えば、）リスクがECNの利益を上回ると考えている状況ではECNを無効にするには、セキュリティ管理者を可能にします。
The IPsec protocol, as defined in [ESP, AH], does not include the IP header's ECN field in any of its cryptographic calculations (in the case of tunnel mode, the outer IP header's ECN field is not included). Hence modification of the ECN field by a network node has no effect on IPsec's end-to-end security, because it cannot cause any IPsec integrity check to fail. As a consequence, IPsec does not provide any defense against an adversary's modification of the ECN field (i.e., a man-in-the-middle attack), as the adversary's modification will also have no effect on IPsec's end-to-end security. In some environments, the ability to modify the ECN field without affecting IPsec integrity checks may constitute a covert channel; if it is necessary to eliminate such a channel or reduce its bandwidth, then the IPsec tunnel should be run in limited-functionality mode.
IPsecプロトコルは、[ESP、AH]で定義されるように、その暗号演算（トンネルモードの場合には、外側のIPヘッダのECNフィールドが含まれていない）のいずれかにIPヘッダーのECNフィールドを含んでいません。それはどんなIPsecの整合性チェックが失敗する原因はできませんので、そのためのネットワーク・ノードによってECNフィールドの変更は、IPsecののエンドツーエンドのセキュリティには影響しません。結果として、IPsecは敵の変形例としても、IPsecののエンドツーエンドのセキュリティに影響を与えません、ECNフィールド（すなわち、man-in-the-middle攻撃）の敵の変更に対する任意の防衛を提供していません。いくつかの環境では、IPsecの整合性チェックに影響を与えることなく、ECNフィールドを変更する能力は、隠れチャネルを構成してもよいです。そのようなチャネルを排除またはその帯域幅を低減する必要がある場合、IPsecトンネルは、限られた機能制限モードで実行されなければなりません。
This section describes the detailed changes to enable usage of ECN over IPsec tunnels, including the negotiation of ECN support between tunnel endpoints. This is supported by three changes to IPsec:
このセクションでは、トンネルエンドポイント間のECNサポートのネゴシエーションを含む、IPsecトンネル上ECNの使用を可能にするために、詳細の変更を記載しています。これは、IPsecの3つの変化によってサポートされています。
* An optional Security Association Database (SAD) field indicating whether tunnel encapsulation and decapsulation processing allows or forbids ECN usage in the outer IP header.
*トンネルカプセル化及びデカプセル化処理を許可または外側のIPヘッダ内のECNの使用を禁止するかどうかを示すオプションのセキュリティアソシエーションデータベース（SAD）フィールド。
* An optional Security Association Attribute that enables negotiation of this SAD field between the two endpoints of an SA that supports tunnel mode.
トンネルモードをサポートしているSAの2つのエンドポイント間のこのSAD分野の交渉を可能にします*オプションのセキュリティアソシエーション属性。
* Changes to tunnel mode encapsulation and decapsulation processing to allow or forbid ECN usage in the outer IP header based on the value of the SAD field. When ECN usage is allowed in the outer IP header, the ECT codepoint is set in the outer header for ECN-capable connections and congestion notifications (indicated by the CE codepoint) from such connections are propagated to the inner header at tunnel egress.
*トンネルモードのカプセル化及びデカプセル化処理の変更は許可またはSADフィールドの値に基づいて、外側のIPヘッダ内のECNの使用を禁止します。 ECNの使用は、外側IPヘッダに許可されている場合、ECTコードポイントは、接続から（CEコードポイントによって示される）ECN-可能な接続と、輻輳通知の外側のヘッダーに設定されたトンネル出口における内側のヘッダーに伝播されます。
If negotiation of ECN usage is implemented, then the SAD field SHOULD also be implemented. On the other hand, negotiation of ECN usage is OPTIONAL in all cases, even for implementations that support the SAD field. The encapsulation and decapsulation processing changes are REQUIRED, but MAY be implemented without the other two changes by assuming that ECN usage is always forbidden. The full-functionality alternative for ECN usage over IPsec tunnels consists of the SAD field and the full version of encapsulation and decapsulation processing changes, with or without the OPTIONAL negotiation support. The limited-functionality alternative consists of a subset of the encapsulation and decapsulation changes that always forbids ECN usage.
ECNの使用のネゴシエーションが実装されている場合には、SADフィールドも実装する必要があります。一方、ECNの使用の交渉も、SADフィールドをサポートする実装のために、すべてのケースではオプションです。カプセル化およびカプセル化解除処理の変更が必要であるが、ECNの使用が常に禁止されていると仮定して他の二つの変更を加えることなく実現することができます。 IPsecトンネル経由ECNの使用のためのフル機能を代替して、またはオプション交渉のサポートなしで、SADフィールドとカプセル化とカプセル化解除処理の変更のフルバージョンで構成されています。制限された機能の代替は、常にECNの使用を禁止し、カプセル化及びデカプセル化変更のサブセットから成ります。
These changes are covered further in the following three subsections.
これらの変更は、次の3つのサブセクションでさらに覆われています。
Full ECN functionality adds a new field to the SAD (see [RFC2401]):
全ECN機能は、（[RFC2401]を参照）SADに新しいフィールドを追加します。
ECN Tunnel: allowed or forbidden.
ECNのトンネル：許可または禁止さ。
Indicates whether ECN-capable connections using this SA in tunnel mode are permitted to receive ECN congestion notifications for congestion occurring within the tunnel. The allowed value enables ECN congestion notifications. The forbidden value disables such notifications, causing all congestion to be indicated via dropped packets.
トンネルモードでは、このSAを使用して、ECN-可能な接続が輻輳がトンネル内で発生するためECN輻輳通知を受信することが許可されているかどうかを示します。許容値は、ECNの輻輳通知を可能にします。禁止値が破棄されたパケットを介して示されるすべての混雑を引き起こして、そのような通知を無効にします。
[OPTIONAL. The value of this field SHOULD be assumed to be "forbidden" in implementations that do not support it.]
[オプション。このフィールドの値は、それをサポートしていない実装では「禁じられ」されると仮定するべきです。]
If this attribute is implemented, then the SA specification in a Security Policy Database (SPD) entry MUST support a corresponding attribute, and this SPD attribute MUST be covered by the SPD administrative interface (currently described in Section 4.4.1 of [RFC2401]).
この属性が実装されている場合、セキュリティポリシーデータベース（SPD）エントリで、その後SAの仕様は、対応する属性をサポートしなければならない、とこのSPD属性がSPDの管理インタフェースによって覆われている必要があります（現在のセクション4.4.1で説明した[RFC2401]） 。
A new IPsec Security Association Attribute is defined to enable the support for ECN congestion notifications based on the outer IP header to be negotiated for IPsec tunnels (see [RFC2407]). This attribute is OPTIONAL, although implementations that support it SHOULD also support the SAD field defined in Section 9.2.1.1.
新しいIPsecのセキュリティアソシエーション属性はIPsecトンネル（[RFC2407]を参照）のために交渉する外側IPヘッダに基づいて、ECN輻輳通知のサポートを可能にするために定義されています。それをサポートする実装はまた、セクション9.2.1.1で定義されたSADフィールドをサポートすべきであるが、この属性は、オプションです。
Attribute Type
属性タイプ
class value type
-------------------------------------------------
ECN Tunnel 10 Basic
The IPsec SA Attribute value 10 has been allocated by IANA to indicate that the ECN Tunnel SA Attribute is being negotiated; the type of this attribute is Basic (see Section 4.5 of [RFC2407]). The Class Values are used to conduct the negotiation. See [RFC2407, RFC2408, RFC2409] for further information including encoding formats and requirements for negotiating this SA attribute.
IPsec SAの属性値10は、ECNトンネルSA属性がネゴシエートされていることを示すために、IANAによって割り当てられています。この属性の型は（[RFC2407]のセクション4.5を参照）基本です。クラス値は、交渉を行うために使用されています。エンコーディング形式と、このSA属性を交渉するための要件を含む詳細については、[RFC2407、RFC2408、RFC2409]を参照してください。
Class Values
クラス値
ECN Tunnel
ECNトンネル
Specifies whether ECN functionality is allowed to be used with Tunnel Encapsulation Mode. This affects tunnel encapsulation and decapsulation processing - see Section 9.2.1.3.
ECN機能はトンネルカプセル化モードで使用することを許可するかどうかを指定します。これは、トンネルカプセル化と脱カプセル化処理に影響を与えます - セクション9.2.1.3を参照してください。
RESERVED 0 Allowed 1 Forbidden 2
RESERVED 0 1禁止2可
Values 3-61439 are reserved to IANA. Values 61440-65535 are for private use.
値3から61439は、IANAに予約されています。値は61440から65535は、私的使用のためのものです。
If unspecified, the default shall be assumed to be Forbidden.
指定しない場合、デフォルトでは禁止されると仮定されなければなりません。
ECN Tunnel is a new SA attribute, and hence initiators that use it can expect to encounter responders that do not understand it, and therefore reject proposals containing it. For backwards compatibility with such implementations initiators SHOULD always also include a proposal without the ECN Tunnel attribute to enable such a responder to select a transform or proposal that does not contain the ECN Tunnel attribute. RFC 2407 currently requires responders to reject all proposals if any proposal contains an unknown attribute; this requirement is expected to be changed to require a responder not to select proposals or transforms containing unknown attributes.
ECNのトンネルは、新しいSA属性であるので、それはそれを理解し、したがってそれを含む提案を拒否していないレスポンダに出会うことを期待することができます使用イニシエータ。そのような実装との後方互換性のために開始剤はまた、変換またはECNのトンネル属性が含まれていない提案を選択するためにそのような応答を可能にするために、属性ECNトンネルのない提案を含め、常にべきです。 RFC 2407は、現在どんな提案が不明な属性が含まれている場合は、すべての提案を拒絶するように応答が必要です。この要件は、未知の属性を含む提案または変換を選択していない応答を必要とするように変更されることが予想されます。
For full ECN support, the encapsulation and decapsulation processing for the IPv4 TOS field and the IPv6 Traffic Class field are changed from that specified in [RFC2401] to the following:
完全ECNサポートのために、IPv4のTOSフィールドとIPv6のトラフィッククラスフィールドのカプセル化及びデカプセル化処理は、以下に、[RFC2401]で指定されたものから変更されます。
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
DS Field copied from inner hdr (5) no change
ECN Field constructed (7) constructed (8)
IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field constructed (7) constructed (8)
IPv6のヘッダフィールド：内側HDRからコピーされたDSフィールド（6）は変化ECNフィールドを構築しない（7）を構築（8）
(5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. Also see [RFC 2475] for further information.
（5）（6）パケットを直ちに外部ヘッダのDSCP値が適切ではないされているドメインを入力する場合は、その値がドメイン[RFC 2474]に適した値にマッピングされなければなりません。また、詳細については[RFC 2475]を参照してください。
(7) If the value of the ECN Tunnel field in the SAD entry for this SA is "allowed" and the ECN field in the inner header is set to any value other than CE, copy this ECN field to the outer header. If the ECN field in the inner header is set to CE, then set the ECN field in the outer header to ECT(0).
（7）このSAのためのSADエントリ内のECNトンネルフィールドの値が「許可」され、内部ヘッダ中のECNフィールドがCE以外の値に設定されている場合、外側のヘッダにこのECNフィールドをコピーします。インナーヘッダ内のECNフィールドがCEに設定されている場合は、ECT（0）にアウターヘッダにECNフィールドを設定します。
(8) If the value of the ECN tunnel field in the SAD entry for this SA is "allowed" and the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then copy the ECN field from the outer header to the inner header. Otherwise, make no change to the ECN field in the inner header.
（8）このSAのためのSADエントリ内のECNトンネルフィールドの値が「許可」され、内部ヘッダ中のECNフィールドがECT（0）かECTに設定されている場合（1）と、外側ヘッダ内のECNフィールドインナーヘッダにアウターヘッダからECNフィールドをコピーし、CEに設定されています。それ以外の場合は、内側のヘッダーの電子証券取引ネットワーク分野への変更を行いません。
(5) and (6) are identical to match usage in [RFC2401], although they are different in [RFC2401].
彼らは[RFC2401]に異なるが（5）及び（6）は、[RFC2401]での使用に合わせて同一です。
The above description applies to implementations that support the ECN Tunnel field in the SAD; such implementations MUST implement this processing instead of the processing of the IPv4 TOS octet and IPv6 Traffic Class octet defined in [RFC2401]. This constitutes the full-functionality alternative for ECN usage with IPsec tunnels.
上記の説明は、SADにECNトンネルフィールドをサポートする実装に適用されます。そのような実装は、この処理の代わりに、IPv4のTOSオクテットと[RFC2401]で定義されたIPv6のトラフィッククラスオクテットの処理を実装しなければなりません。これは、IPsecトンネルとECNを使用するためのフル機能の代替手段を構成しています。
An implementation that does not support the ECN Tunnel field in the SAD MUST implement this processing by assuming that the value of the ECN Tunnel field of the SAD is "forbidden" for every SA. In this case, the processing of the ECN field reduces to:
SADにECNトンネルフィールドをサポートしていない実装では、SADのECNのトンネルフィールドの値がすべてのSAのための「禁止」であると仮定して、この処理を実装しなければなりません。この場合、ECNフィールドの処理に削減します。
(7) Set the ECN field to not-ECT in the outer header. (8) Make no change to the ECN field in the inner header.
（7）外ヘッダにECNフィールドにない-ECTを設定します。 （8）内部ヘッダ内のECNフィールドに何も変更を加えません。
This constitutes the limited functionality alternative for ECN usage with IPsec tunnels.
これは、IPsecトンネルとECNの使用のための限られた機能の代替手段を構成しています。
For backwards compatibility, packets with the CE codepoint set in the outer header SHOULD be dropped if they arrive on an SA that is using the limited-functionality option, or that is using the full-functionality option with the not-ECN codepoint set in the inner header.
後方互換性のためにセットコードポイントこれらは限定機能オプションを使用してSAに到着した場合、外ヘッダに設定CEコードポイントを持つパケットは廃棄されるべきであり、またはそれはない、ECNを備えたフル機能のオプションを使用していますインナーヘッダ。
If the ECN Field is changed inappropriately within an IPsec tunnel, and this change is detected at the tunnel egress, then the receipt of a packet not satisfying the appropriate condition for its SA is an auditable event. An implementation MAY create audit records with per-SA counts of incorrect packets over some time period rather than creating an audit record for each erroneous packet. Any such audit record SHOULD contain the headers from at least one erroneous packet, but need not contain the headers from every packet represented by the entry.
ECNフィールドは、IPsecトンネル内に不適切に変化し、この変化はトンネル出口で検出され、そのSAのための適切な条件を満たさないパケットの受信は、監査可能なイベントである場合。実装ではなく、各誤ったパケットのための監査レコードを作成するよりも、ある程度の時間をかけて、誤ったパケットのあたり-SAカウントの監査レコードを作成することもできます。そのような任意の監査レコードは、少なくとも一つの誤ったパケットからヘッダを含有しなければならないが、エントリによって表されるすべてのパケットからヘッダを含む必要はありません。
Substantial comments were received on two areas of this document during review by the IPsec working group. This section describes these comments and explains why the proposed changes were not incorporated.
相当なコメントは、IPsecワーキンググループによる検討の際に、この文書の二つの領域で受信されました。このセクションでは、これらのコメントを説明し、提案された変更が組み込まれていなかった理由を説明します。
The first comment indicated that per-node configuration is easier to implement than per-SA configuration. After serious thought and despite some initial encouragement of per-node configuration, it no longer seems to be a good idea. The concern is that as ECN-awareness is progressively deployed in IPsec, many ECN-aware IPsec implementations will find themselves communicating with a mixture of ECN-aware and ECN-unaware IPsec tunnel endpoints. In such an environment with per-node configuration, the only reasonable thing to do is forbid ECN usage for all IPsec tunnels, which is not the desired outcome.
最初のコメントは、ノードごとの構成ごとのSA構成よりも、実装が容易であることが示されました。真剣に考えた後、およびノード単位の設定のいくつかの初期の励ましにもかかわらず、もはや良いアイデアであると思いません。懸念は、ECN-意識が徐々にIPsecの中で展開されているように、多くのECN対応のIPsec実装自体はECN-意識の混合物とECN非対応のIPsecトンネルのエンドポイントとの通信を見つけることです。ノードごとに構成されたこのような環境では、実行する唯一の合理的な事は望ましい結果ではないすべてのIPsecトンネル用の電子証券取引ネットワークの使用を禁止しています。
In the second area, several reviewers noted that SA negotiation is complex, and adding to it is non-trivial. One reviewer suggested using ICMP after tunnel setup as a possible alternative. The addition to SA negotiation in this document is OPTIONAL and will remain so; implementers are free to ignore it. The authors believe that the assurance it provides can be useful in a number of situations. In practice, if this is not implemented, it can be deleted at a subsequent stage in the standards process. Extending ICMP to negotiate ECN after tunnel setup is more complex than extending SA attribute negotiation. Some tunnels do not permit traffic to be addressed to the tunnel egress endpoint, hence the ICMP packet would have to be addressed to somewhere else, scanned for by the egress endpoint, and discarded there or at its actual destination. In addition, ICMP delivery is unreliable, and hence there is a possibility of an ICMP packet being dropped, entailing the invention of yet another ack/retransmit mechanism. It seems better simply to specify an OPTIONAL extension to the existing SA negotiation mechanism.
第二領域では、いくつかのレビューは、SAネゴシエーションが複雑であり、それに追加することは非自明であると指摘しました。 1人のレビューは、可能な代替としてトンネルのセットアップ後にICMPを使用して提案しました。このドキュメントのSAネゴシエーションの添加は任意であるので、残ります。実装者はそれを無視するのは自由です。著者は、それが提供する保証は多くの状況において有用であることができると信じています。これが実装されていない場合は実際には、それが標準化プロセスにおける次の段階で削除することができます。トンネルセットアップ後にECNを交渉するためにICMPを拡張するSA属性交渉を拡張するよりも複雑です。いくつかのトンネルは、したがってICMPパケットは、どこか別の場所に宛て出口エンドポイントがスキャンすると、そこにまたはその実際の目的地で廃棄しなければならないであろう、トラフィックがトンネル出口のエンドポイントに対処するために許可していません。また、ICMP送達は信頼できない、従って落下ICMPパケットの可能性があり、さらに別のACK /再送機構の発明を伴います。単に既存のSAネゴシエーションメカニズムへの任意の拡張子を指定した方が良いようです。
A different set of issues are raised, relative to ECN, when IP packets are encapsulated in tunnels with non-IP packet headers. This occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP]. For these protocols, there is no conflict with ECN; it is just that ECN cannot be used within the tunnel unless an ECN codepoint can be specified for the header of the encapsulating protocol. Earlier work considered a preliminary proposal for incorporating ECN into MPLS, and proposals for incorporating ECN into GRE, L2TP, or PPTP will be considered as the need arises.
IPパケットが非IPパケットヘッダとトンネルにカプセル化されたときに問題の異なるセットは、ECNに対して、持ち上げられます。これは、MPLS [MPLS]で生じるGRE [GRE]、L2TP [L2TP]、およびPPTP [PPTP]。これらのプロトコルについては、ECNとの競合はありません。それはECNコードポイントは、カプセル化プロトコルのヘッダに指定することができない限り、ECNは、トンネル内で使用することができないだけということです。初期の作品は、MPLSにECNを組み込むための予備的な提案を検討して、必要に応じてGRE、L2TP、またはPPTPにECNを組み込むための提案は考慮されます。
One possibility is that monitoring and policing devices (or more informally, "penalty boxes") will be installed in the network to monitor whether best-effort flows are appropriately responding to congestion, and to preferentially drop packets from flows determined not to be using adequate end-to-end congestion control procedures.
一つの可能性は、モニタリングとポリシング装置（または複数の非公式には、「ペナルティボックス」）はベストエフォートフローが適切輻輳に応答している、優先フローからパケットが十分使用されていないと判定ドロップするかどうかを監視するために、ネットワーク内に設置されることですエンドツーエンドの輻輳制御手順。
We recommend that any "penalty box" that detects a flow or an aggregate of flows that is not responding to end-to-end congestion control first change from marking to dropping packets from that flow, before taking any additional action to restrict the bandwidth available to that flow. Thus, initially, the router may drop packets in which the router would otherwise would have set the CE codepoint. This could include dropping those arriving packets for that flow that are ECN-Capable and that already have the CE codepoint set. In this way, any congestion indications seen by that router for that flow will be guaranteed to also be seen by the end nodes, even in the presence of malicious or broken routers elsewhere in the path. If we assume that the first action taken at any "penalty box" for an ECN-capable flow will be to drop packets instead of marking them, then there is no way that an adversary that subverts ECN-based end-to-end congestion control can cause a flow to be characterized as being non-cooperative and placed into a more severe action within the "penalty box".
私たちは、利用可能な帯域幅を制限するための追加措置をとる前に、流れまたはそのフローからのパケットをドロップするマーキングからへのエンドツーエンドの輻輳制御最初の変更を応答していないフローの集約を検出したすべての「ペナルティ」ことをお勧めしますその流れに。したがって、最初に、ルータは、ルータが他のCEコードポイントを設定しているであろうと思われるにパケットをドロップすることができます。これは、ECN-可能であり、それはすでにCEコードポイントが設定されている、そのフローのためのそれら到着したパケットをドロップ含めることができます。このように、そのフローに対してそのルータによって見られる任意の輻輳表示はまた、他の場所も、パスにおける悪意のある又は壊れたルータの存在下で、エンドノードによって見られることが保証されます。我々はECN対応のフローのために任意の「ペナルティ」で撮影した最初の行動ではなく、それらをマーキングのパケットをドロップするようになると仮定した場合、攻撃者ECNベースのエンドツーエンドの輻輳制御を覆すことはできませんフローは非協力的と「ペナルティ」内のより厳しい行動に配置されるように特徴付けさせることができます。
The monitoring and policing devices that are actually deployed could fall short of the `ideal' monitoring device described above, in that the monitoring is applied not to a single flow, but to an aggregate of flows (e.g., those sharing a single IPsec tunnel). In this case, the switch from marking to dropping would apply to all of the flows in that aggregate, denying the benefits of ECN to the other flows in the aggregate also. At the highest level of aggregation, another form of the disabling of ECN happens even in the absence of monitoring and policing devices, when ECN-Capable RED queues switch from marking to dropping packets as an indication of congestion when the average queue size has exceeded some threshold.
実際に展開されているモニタリングとポリシング装置は、監視は、単一フローに適用されないという点で、上述した `理想」監視装置を下回るが、可能性の流れの集合体（例えば、単一のIPsecトンネルを共有するもの） 。この場合、落下にマーキングからスイッチも集約内の他のフローにECNのメリットを否定し、その集計に流れのすべてに適用されます。 ECN対応REDキューが輻輳の指標としてパケットをドロップするマーキングから切り替えたときの凝集の最高レベルでは、ECNの無効化の別の形態も監視し、デバイスをポリシングの非存在下で起こる、平均キューサイズを超えた場合、いくつかしきい値。
This section discusses some of the related work evaluating the use of ECN. The ECN Web Page [ECN] has pointers to other papers, as well as to implementations of ECN.
このセクションでは、ECNの使用を評価し、関連する作業の一部について説明します。 ECNのWebページ[ECN]は他の論文に、だけでなく、ECNの実装へのポインタを持っています。
[Floyd94] considers the advantages and drawbacks of adding ECN to the TCP/IP architecture. As shown in the simulation-based comparisons, one advantage of ECN is to avoid unnecessary packet drops for short or delay-sensitive TCP connections. A second advantage of ECN is in avoiding some unnecessary retransmit timeouts in TCP. This paper discusses in detail the integration of ECN into TCP's congestion control mechanisms. The possible disadvantages of ECN discussed in the paper are that a non-compliant TCP connection could falsely advertise itself as ECN-capable, and that a TCP ACK packet carrying an ECN-Echo message could itself be dropped in the network. The first of these two issues is discussed in the appendix of this document, and the second is addressed by the addition of the CWR flag in the TCP header.
【Floyd94] TCP / IPアーキテクチャにECNを追加の利点と欠点を考慮しています。シミュレーションベースの比較に示すように、電子証券取引ネットワークの一つの利点は、不要なパケットが短いまたは遅延に敏感なTCP接続のために低下しないようにすることです。 ECNの第2の利点は、TCPで、いくつかの不要な再送タイムアウトを避けることです。本論文では、TCPの輻輳制御メカニズムに詳細にECNの統合について説明します。 ECNの可能な欠点は、紙で議論非準拠TCP接続が誤っECN-可能として自身をアドバタイズし、ECN-エコーメッセージを運ぶTCP ACKパケット自体がネットワークにドロップすることができることができることです。これらの2つの問題の最初のは、この文書の付録で説明され、そして第二は、TCPヘッダーのCWRフラグの添加によって対処されます。
Experimental evaluations of ECN include [RFC2884,K98]. The conclusions of [K98] and [RFC2884] are that ECN TCP gets moderately better throughput than non-ECN TCP; that ECN TCP flows are fair towards non-ECN TCP flows; and that ECN TCP is robust with two-way traffic (with congestion in both directions) and with multiple congested gateways. Experiments with many short web transfers show that, while most of the short connections have similar transfer times with or without ECN, a small percentage of the short connections have very long transfer times for the non-ECN experiments as compared to the ECN experiments.
ECNの実験的評価は、[RFC2884、K98]を含んでいます。 [K98]と[RFC2884]の結論は、ECN TCPは、非ECN TCPよりも適度に優れたスループットを得ることです。 ECN TCPフローは非ECN TCPフローに対する公正であることを。そしてECN TCPは双方向のトラフィックで（両方向で混雑して）と、複数の混雑ゲートウェイと堅牢であること。 ECN実験と比較して短い接続のほとんどはとか、ECNない類似の転送時間を持っていながら、多くの短いウェブ転送を用いた実験では、ことを示し、短い接続の小さな割合は、非ECN実験のための非常に長い転送時間を持っています。
The use of two ECT codepoints, ECT(0) and ECT(1), can provide a one-bit ECN nonce in packet headers [SCWA99]. The primary motivation for this is the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol. This section discusses issues of backwards compatibility with IP ECN implementations in routers conformant with RFC 2481, in which only one ECT codepoint was defined. We do not believe that the incremental deployment of ECN implementations that understand the ECT(1) codepoint will cause significant operational problems. This is particularly likely to be the case when the deployment of the ECT(1) codepoint begins with routers, before the ECT(1) codepoint starts to be used by end-nodes.
2 ECTコードポイント、ECT（0）とECTの使用は、（1）、[SCWA99】パケットヘッダに1ビットECN nonceを提供することができます。このための主な動機は、データ送信側のためのメカニズムにより、必要に応じて、そのネットワーク要素がCEコードポイントを消去されず、そのデータ受信器が適切にCEコードポイントセットで送信側にパケットの受信を報告されていることを確認することを可能にする欲求でありますトランスポートプロトコル。このセクションでは、唯一のECTコードポイントが定義されたRFC 2481に準拠し、ルータでIP ECNの実装との後方互換性の問題について説明します。私たちは、ECTを理解ECN実装の増分の展開（1）コードポイントが重大な操作上の問題を引き起こすだろうとは考えていません。これは、ECT（1）コードポイントは、エンドノードによって使用され始める前に、ECTの配備は、（1）コードポイントは、ルータで始まる場合であることが特にそうです。
ECN has been an Experimental standard since January 1999, and there are already implementations of ECN in routers that do not understand the ECT(1) codepoint. When the use of the ECT(1) codepoint is standardized for TCP or for other transport protocols, this could mean that a data sender is using the ECT(1) codepoint, but that this codepoint is not understood by a congested router on the path.
ECNは、1999年1月以来の実験の標準となっている、とECT（1）コードポイントを理解していないルータにおけるECNの実装が既に存在しています。 ECT（1）コードポイントの使用はTCPまたは他のトランスポートプロトコルのために標準化されている場合、これはデータの送信者がECT（1）コードポイントを使用していることを意味するかもしれないが、このコードポイントは、経路上の混雑ルータによって理解されていないこと。
If allowed by the transport protocol, a data sender would be free not to make use of ECT(1) at all, and to send all ECN-capable packets with the codepoint ECT(0). However, if an ECN-capable sender is using ECT(1), and the congested router on the path did not understand the ECT(1) codepoint, then the router would end up marking some of the ECT(0) packets, and dropping some of the ECT(1) packets, as indications of congestion. Since TCP is required to react to both marked and dropped packets, this behavior of dropping packets that could have been marked poses no significant threat to the network, and is consistent with the overall approach to ECN that allows routers to determine when and whether to mark packets as they see fit (see Section 5).
トランスポート・プロトコルにより許可された場合は、データの送信者は、（1）すべてのECTの使用をしないように自由になり、そしてコードポイントECTを持つすべてのECN対応のパケットを送信する（0）。しかし、ECN対応の送信者がECTを使用している場合（1）、及びECT（1）コードポイントを理解していなかったパス上の混雑ルータは、ルータがECT（0）パケットの一部をマーキング終わるだろう、とドロップ輻輳の兆候としてECT（1）パケットの一部、。 TCPの両方にマークされ、パケットのドロップに反応するように要求されるので、マークされている可能性がパケットをドロップするこの動作は、ネットワークへの重大な脅威をもたらしていない、とするとき、マークするかどうかを決定するためにルータを可能ECNへの全体的なアプローチと一致していますパケットは、彼らが（第5節参照）を合うように。
This document specified two bits in the IP header to be used for ECN. The not-ECT codepoint indicates that the transport protocol will ignore the CE codepoint. This is the default value for the ECN codepoint. The ECT codepoints indicate that the transport protocol is willing and able to participate in ECN.
この文書では、ECNのために使用されるIPヘッダ内の2ビットを指定しました。ない-ECTコードポイントは、トランスポートプロトコルがCEコードポイントを無視することを示しています。これは、ECNコードポイントのデフォルト値です。 ECTコードポイントは、トランスポートプロトコルが喜ん及びECNに参加することが可能であることを示しています。
The router sets the CE codepoint to indicate congestion to the end nodes. The CE codepoint in a packet header MUST NOT be reset by a router.
ルータは、エンドノードへの混雑を示すために、CEコードポイントを設定します。パケットヘッダのCEコードポイントは、ルータがリセットされてはなりません。
TCP requires three changes for ECN, a setup phase and two new flags in the TCP header. The ECN-Echo flag is used by the data receiver to inform the data sender of a received CE packet. The Congestion Window Reduced (CWR) flag is used by the data sender to inform the data receiver that the congestion window has been reduced.
TCPは3つのECNの変更、設定フェーズとTCPヘッダー内の2つの新しいフラグが必要です。 ECN-エコーフラグが受信されたCEパケットのデータ送信側に通知するデータ受信機によって使用されます。 （CWR）フラグ減少輻輳ウィンドウは、輻輳ウィンドウが縮小されたことをデータ受信装置に通知するデータ送信側によって使用されます。
When ECN (Explicit Congestion Notification) is used, it is required that congestion indications generated within an IP tunnel not be lost at the tunnel egress. We specified a minor modification to the IP protocol's handling of the ECN field during encapsulation and de-capsulation to allow flows that will undergo IP tunneling to use ECN.
ECN（明示的輻輳通知）を使用する場合は、IPトンネル内で発生した輻輳表示はトンネル出口で失われないことが必要です。私たちは、ECNを使用するIPトンネリングを受けるフローを許可するようにカプセル化とデカプセル中にECNフィールドのIPプロトコルの処理に若干の変更を指定しました。
Two options for ECN in tunnels were specified:
トンネル内ECNの2つのオプションが指定されました：
1) A limited-functionality option that does not use ECN inside the IP tunnel, by setting the ECN field in the outer header to not-ECT, and not altering the inner header at the time of decapsulation.
1）外側のヘッダにECNフィールドを設定することにより、IPトンネル内ECNを使用していない制限された機能のオプションは、ECTはない、及びデカプセル化の際に内部ヘッダを変更しないように。
2) The full-functionality option, which sets the ECN field in the outer header to either not-ECT or to one of the ECT codepoints, depending on the ECN field in the inner header. At decapsulation, if the CE codepoint is set in the outer header, and the inner header is set to one of the ECT codepoints, then the CE codepoint is copied to the inner header.
2）内側のヘッダーのECNフィールドに応じて、いずれかの未ECTまたはECTコードポイントの一つに外部ヘッダ内のECNフィールドを設定するフル機能のオプション。 CEコードポイントは、外側ヘッダに設定され、内部ヘッダがECTコードポイントのいずれかに設定されている場合デカプセル化では、CEコードポイントは、内部ヘッダにコピーされます。
For IPsec tunnels, this document also defines an optional IPsec Security Association (SA) attribute that enables negotiation of ECN usage within IPsec tunnels and an optional field in the Security Association Database to indicate whether ECN is permitted in tunnel mode on a SA. The required changes to IPsec tunnels for ECN usage modify RFC 2401 [RFC2401], which defines the IPsec architecture and specifies some aspects of its implementation. The new IPsec SA attribute is in addition to those already defined in Section 4.5 of [RFC2407].
IPsecトンネルの場合、この文書はまた、ECNがSAにトンネルモードで許可されているかどうかを示すために、IPsecトンネルとセキュリティアソシエーションデータベース内の任意のフィールド内のECNの使用の交渉を可能にし、オプションのIPsecセキュリティアソシエーション（SA）の属性を定義します。 ECNの使用のためのIPsecトンネルに必要な変更は、IPsecアーキテクチャを定義し、その実装のいくつかの側面を指定するRFC 2401 [RFC2401]を、変更します。新しいIPsec SAの属性がすでに[RFC2407]のセクション4.5で定義されたものに加えています。
This document obsoletes RFC 2481, "A Proposal to add Explicit Congestion Notification (ECN) to IP", which defined ECN as an Experimental Protocol for the Internet Community. The rest of this section describes the relationship between this document and its predecessor.
この文書は、インターネットコミュニティのための実験プロトコルとしてECNを定義し、「IPへの明示的輻輳通知（ECN）を追加するための提案を」RFC 2481を廃止します。このセクションの残りの部分は、このドキュメントとその前身の間の関係を記述します。
RFC 2481 included a brief discussion of the use of ECN with encapsulated packets, and noted that for the IPsec specifications at the time (January 1999), flows could not safely use ECN if they were to traverse IPsec tunnels. RFC 2481 also described the changes that could be made to IPsec tunnel specifications to made them compatible with ECN.
RFC 2481は、カプセル化されたパケットとのECNの使用の簡単な説明が含まれ、それらがIPsecトンネルを通過した場合の時間（1999年1月）でのIPsecの仕様については、フローが安全にECNを使用することができなかったことを指摘しました。 RFC 2481はまた、ECNと互換性行わにIPsecトンネル仕様に行うことができる変更を記載しました。
This document also incorporates work that was done after RFC 2481. First was to describe the changes to IPsec tunnels in detail, and extensively discuss the security implications of ECN (now included as Sections 18 and 19 of this document). Second was to extend the discussion of IPsec tunnels to include all IP tunnels. Because older IP tunnels are not compatible with a flow's use of ECN, the deployment of ECN in the Internet will create strong pressure for older IP tunnels to be updated to an ECN-compatible version, using either the limited-functionality or the full-functionality option.
この文書はまた、最初に詳細にIPsecトンネルへの変更を説明し、広範囲にECNのセキュリティへの影響を議論することでしたRFC 2481.後に行われた仕事を組み込んだ（今のセクション18と、この文書の19として含まれます）。第二に、すべてのIPトンネルを含めるようにIPsecトンネルの議論を拡張しました。古いIPトンネルは、ECNの流れの使用と互換性がありませんので、インターネットにおけるECNの展開は限定機能やフル機能のいずれかを使用して、ECN-互換性のあるバージョンに更新されるように、古いIPトンネルの強い圧力を作成します。オプション。
This document does not address the issue of including ECN in non-IP tunnels such as MPLS, GRE, L2TP, or PPTP. An earlier preliminary document about adding ECN support to MPLS was not advanced.
この文書では、このようなMPLS、GRE、L2TP、またはPPTPなどの非IPトンネルでECNを含むの問題に対処しません。 MPLSにECNのサポートを追加することについて、以前の予備的文書が進んでいませんでした。
A third new piece of work after RFC2481 was to describe the ECN procedure with retransmitted data packets, that an ECT codepoint should not be set on retransmitted data packets. The motivation for this additional specification is to eliminate a possible avenue for denial-of-service attacks on an existing TCP connection. Some prior deployments of ECN-capable TCP might not conform to the (new) requirement not to set an ECT codepoint on retransmitted packets; we do not believe this will cause significant problems in practice.
RFC2481後の作業の3番目の新しい作品は、ECTコードポイントが再送データパケットに設定されるべきではないと、再送されたデータパケットにECNの手順を説明することでした。この追加の仕様のための動機は、既存のTCP接続上のサービス妨害（DoS）攻撃の可能性の道を排除することです。 ECN対応のTCPのいくつかの従来の展開は、再送パケットにECTコードポイントを設定しない（新しい）の要件に適合しない場合があります。私たちは、これは実際には重大な問題を引き起こすだろうとは思いません。
This document also expands slightly on the specification of the use of SYN packets for the negotiation of ECN. While some prior deployments of ECN-capable TCP might not conform to the requirements specified in this document, we do not believe that this will lead to any performance or compatibility problems for TCP connections with a combination of TCP implementations at the endpoints.
また、このドキュメントでは、ECNの交渉のためのSYNパケットの使用の仕様にやや拡大します。 ECN対応のTCPのいくつかの従来の展開は、この文書で指定された要件に適合していないかもしれないが、我々は、これは、エンドポイントでのTCPの実装を組み合わせたTCP接続の任意のパフォーマンスや互換性の問題につながることを信じていません。
This document also includes the specification of the ECT(1) codepoint, which may be used by TCP as part of the implementation of an ECN nonce.
この文書はまた、ECNナンスの実装の一部として、TCPによって使用されてもよいECT（1）コードポイントの仕様を含みます。
Given the current effort to implement AQM, we believe this is the right time to deploy congestion avoidance mechanisms that do not depend on packet drops alone. With the increased deployment of applications and transports sensitive to the delay and loss of a single packet (e.g., realtime traffic, short web transfers), depending on packet loss as a normal congestion notification mechanism appears to be insufficient (or at the very least, non-optimal).
AQMを実装するための現在の努力を考えると、我々はこれだけでは低下し、パケットに依存しない輻輳回避メカニズムを展開するための適切な時期であると信じています。アプリケーションの増加展開をして、通常の輻輳通知メカニズムが不十分（または非常に少なくともように見えるとして、パケット損失に応じて、単一のパケット（例えば、リアルタイムトラフィック、短いウェブ転送）の遅延や損失に敏感な輸送非最適）。
We examined the consequence of modifications of the ECN field within the network, analyzing all the opportunities for an adversary to change the ECN field. In many cases, the change to the ECN field is no worse than dropping a packet. However, we noted that some changes have the more serious consequence of subverting end-to-end congestion control. However, we point out that even then the potential damage is limited, and is similar to the threat posed by end-systems intentionally failing to cooperate with end-to-end congestion control.
私たちは、ECNフィールドを変更するには、敵のためにすべての機会を分析し、ネットワーク内のECNフィールドの変更の結果を検討しました。多くの場合、ECNフィールドへの変更は、パケットを落とすよりも悪いことではありません。しかし、我々はいくつかの変更は、エンドツーエンドの輻輳制御を破壊するのより深刻な結果を持っていることを指摘しました。しかし、その後も潜在的な損傷が制限され、かつ意図的にエンドツーエンドの輻輳制御と協働することができないエンドシステムの脅威に類似していると指摘しています。
Many people have made contributions to this work and this document, including many that we have not managed to directly acknowledge in this document. In addition, we would like to thank Kenjiro Cho for the proposal for the TCP mechanism for negotiating ECN-Capability, Kevin Fall for the proposal of the CWR bit, Steve Blake for material on IPv4 Header Checksum Recalculation, Jamal Hadi-Salim for discussions of ECN issues, and Steve Bellovin, Jim Bound, Brian Carpenter, Paul Ferguson, Stephen Kent, Greg Minshall, and Vern Paxson for discussions of security issues. We also thank the Internet End-to-End Research Group for ongoing discussions of these issues.
多くの人々は、我々が直接この文書で確認するために管理していないことを多く含む、この作品とこの文書への貢献をしました。また、当社はCWRビットの提案のためのECN-能力、ケビン秋を交渉するためのTCPメカニズムの提案のため健次郎趙に感謝したいと思い、スティーブ・ブレイクの議論のためのIPv4ヘッダチェックサムの再計算、ジャマル・ハディ・サリムの材料のためにECNの問題、およびセキュリティ問題の議論のバウンドスティーブBellovin氏、ジム、ブライアン・カーペンター、ポール・ファーガソン、スティーブン・ケント、グレッグMinshall、およびバーン・パクソン。また、これらの問題の継続的な議論のために、インターネットのエンドツーエンドの研究グループに感謝します。
Email discussions with a number of people, including Dax Kelson, Alexey Kuznetsov, Jamal Hadi-Salim, and Venkat Venkatsubra, have addressed the issues raised by non-conformant equipment in the Internet that does not respond to TCP SYN packets with the ECE and CWR flags set. We thank Mark Handley, Jitentra Padhye, and others for discussions on the TCP initialization procedures.
ダックスKelson、アレクセイ・クズネツォフ、ジャマル・ハディ・サリム、およびヴェンカトVenkatsubra含めた人々の数と電子メールの議論は、ECEとCWRでTCP SYNパケットに応答しないインターネットで非準拠の機器が提起した問題に対処していますフラグが設定します。我々はマーク・ハンドリー、Jitentra Padhye、およびTCPの初期化手続き上の議論のための他の人に感謝します。
The discussion of ECN and IP tunnel considerations draws heavily on related discussions and documents from the Differentiated Services Working Group. We thank Tabassum Bint Haque from Dhaka, Bangladesh, for feedback on IP tunnels. We thank Derrell Piper and Kero Tivinen for proposing modifications to RFC 2407 that improve the usability of negotiating the ECN Tunnel SA attribute.
ECNとIPトンネルの考慮事項の議論は、差別化サービスワーキンググループからの関連の議論や文書に大きく描画します。私たちは、IPトンネル上のフィードバックのため、ダッカ、バングラデシュからタバッサムビントHaqueに感謝します。私たちは、ECNトンネルSA属性を交渉の使い勝手を向上RFC 2407への変更を提案するためDerrellパイパーとケロTivinenに感謝します。
We thank David Wetherall, David Ely, and Neil Spring for the proposal for the ECN nonce. We also thank Stefan Savage for discussions on this issue. We thank Bob Briscoe and Jon Crowcroft for raising the issue of fragmentation in IP, on alternate semantics for the fourth ECN codepoint, and several other topics. We thank Richard Wendland for feedback on several issues in the document.
私たちは、ECNナンスのための提案のためのデイビット・ウェザーオール、デビッド・イーリー、とニール春に感謝します。我々はまた、この問題に関する議論のためのステファン・サベージに感謝します。私たちは、第四ECNコードポイント用の代替セマンティクス、および他のいくつかのトピックについて、IPの断片化の問題を提起するためにボブ・ブリスコーとジョン・クロークロフトに感謝します。私たちは、ドキュメントのいくつかの問題についてのフィードバックのためにリチャードWendlandに感謝します。
We also thank the IESG, and in particular the Transport Area Directors over the years, for their feedback and their work towards the standardization of ECN.
我々はまた、彼らのフィードバックやECNの標準化に向けた自分の仕事のために、長年にわたってIESGに感謝し、特に輸送エリアディレクター。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[ECN] "The ECN Web Page", URL "http://www.aciri.org/floyd/ecn.html". Reference for informational purposes only.
[ECN] "ECNのWebページ"、URL "http://www.aciri.org/floyd/ecn.html"。情報提供のみを目的のために参照します。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード"、RFC 2406、1998年11月。
[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/". Reference for informational purposes only.
[解決] ECN-アンダーLinuxの非公式のベンダーサポートページ、URL "http://gtf.org/garzik/ecn/"。情報提供のみを目的のために参照します。
[FJ93] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413.
[FJ93]フロイド、S.、およびヤコブソン、V.、 "輻輳回避のためのランダム早期検出・ゲートウェイ"、ネットワーク上のIEEE / ACM取引、V.1のN.4、1993年8月、P。 397から413まで。
[Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", ACM Computer Communication Review, V. 24 N. 5, October 1994, p. 10-23.
[Floyd94]フロイド、S.、 "TCPおよび明示的輻輳通知"、ACMコンピュータコミュニケーションレビュー、V. 24 N. 5、1994年10月、P。 10-23。
[Floyd98] Floyd, S., "The ECN Validation Test in the NS Simulator", URL "http://www-mash.cs.berkeley.edu/ns/", test tcl/test/test-all- ecn. Reference for informational purposes only.
【Floyd98]フロイド、S.、 "NSシミュレータでECN検証試験"、URL "http://www-mash.cs.berkeley.edu/ns/"、テストTCL /試験/試験オールECN。情報提供のみを目的のために参照します。
[FF99] Floyd, S., and Fall, K., "Promoting the Use of End-to-End Congestion Control in the Internet", IEEE/ACM Transactions on Networking, August 1999.
[FF99]フロイド、S.、および秋、K.、「インターネットにおけるエンドツーエンドの輻輳制御の利用促進」、ネットワーキング、1999年8月にIEEE / ACM取引。
[FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, September 1997.
[FRED]林、D.、および、SIGCOMM '97モリス、R.、 "ランダム早期検出のダイナミクス"、1997年9月。
[GRE] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[GRE]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[Jacobson88] V. Jacobson, "Congestion Avoidance and Control", Proc. ACM SIGCOMM '88, pp. 314-329.
[Jacobson88] V. Jacobson氏、 "輻輳回避とコントロール"、PROC。 ACM SIGCOMM '88、頁314から329まで。
[Jacobson90] V. Jacobson, "Modified TCP Congestion Avoidance Algorithm", Message to end2end-interest mailing list, April 1990. URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt".
[Jacobson90] V. Jacobson氏、 "修飾TCPの輻輳回避アルゴリズム"、メーリングリスト金利end2endするメッセージ、4月1990 URL "ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt"。
[K98] Krishnan, H., "Analyzing Explicit Congestion Notification (ECN) benefits for TCP", Master's thesis, UCLA, 1998. Citation for acknowledgement purposes only.
[K98]クリシュナン、H.、「TCPのための明示的輻輳通知（ECN）の利点を分析」、修士論文、UCLA、確認のみを目的とした1998年の引用。
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TP] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[MJV96] S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven Layered Multicast", SIGCOMM '96, August 1996, pp. 117-130.
【MJV96] S. McCanne、V. Jacobsonの、及びM. Vetterli、 "受信ドリブン階層化マルチキャスト"、SIGCOMM '96、1996年8月、頁117-130。
[MPLS] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702, September 1999.
[MPLS] Awduche、D.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、トラフィックエンジニアリングオーバーMPLS、RFC 2702、1999年9月のための要件。
[PPTP] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[PPTP] Hamzeh、K.、ポール、G.、Verthein、W.、Taarud、J.、リトル、W.およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル（PPTP）"、RFC 2637、1999年7月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, January 1990.
[RFC1141]マロリー、T.とA. Kullberg、 "インターネットチェックサムのインクリメンタル更新"、RFC 1141、1990年1月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P.、 "インターネットプロトコルスイートでサービスの種類"、RFC 1349、1992年7月。
[RFC1455] Eastlake, D., "Physical Link Security Type of Service", RFC 1455, May 1993.
[RFC1455]イーストレイク、D.、 "サービスの物理リンクセキュリティタイプ"、RFC 1455、1993年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[RFC1702]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "IPv4ネットワーク上総称ルーティングカプセル化"、RFC 1702、1994年10月。
[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月。
[RFC2309] Braden, B., et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309]ブレーデン、B.、ら、RFC 2309、1998年4月「キュー管理およびインターネットにおける輻輳回避に関する提言」。
[RFC2401] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、インターネットプロトコルのためのセキュリティー体系、RFC 2401、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2409, November 1998.
[RFC2408]モーガン、D.、Schertler、M.、シュナイダー、M.とJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2409、1998年11月。
[RFC2409] Harkins D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、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月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、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月。
[RFC2581] Alman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Alman、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks", RFC 2884, July 2000.
[RFC2884]ハディサリム、J.およびU.アーメド、 "IPネットワークにおける明示的輻輳通知の性能評価（ECN）"、RFC 2884、2000年7月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000.
[RFC2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC2983、2000年10月。
[RFC2780] Bradner S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]ブラドナーのS.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月。
[RJ90] K. K. Ramakrishnan and Raj Jain, "A Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990.
[RJ90] K. K.ラマクリシュナンとラジ・ジャイン、「コンピュータネットワークにおける輻輳回避のためのバイナリフィードバック方式」、コンピュータシステム、第8巻、第2号、頁158から181まで、1990年5月にACM取引。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[SCWA99]ステファン・サヴェージ、ニールカードウェル、デイビット・ウェザーオール、そしてトム・アンダーソン、ふらちなレシーバーとのTCP輻輳制御、ACMコンピュータコミュニケーションレビュー、1999年10月。
[TBIT] Jitendra Padhye and Sally Floyd, "Identifying the TCP Behavior of Web Servers", ICSI TR-01-002, February 2001. URL "http://www.aciri.org/tbit/".
[TBIT] Jitendra Padhyeとサリーフロイド、 "WebサーバーのTCPの動作の識別"、ICSI TR-01から002、2001年2月URL "http://www.aciri.org/tbit/"。
Security considerations have been discussed in Sections 7, 8, 18, and 19.
セキュリティに関する注意事項については、セクション7、8、18、および19で議論されています。
IPv4 header checksum recalculation is an issue with some high-end router architectures using an output-buffered switch, since most if not all of the header manipulation is performed on the input side of the switch, while the ECN decision would need to be made local to the output buffer. This is not an issue for IPv6, since there is no IPv6 header checksum. The IPv4 TOS octet is the last byte of a 16-bit half-word.
スイッチの入力側で行われるヘッダ操作の全てならない最もためECN決定がローカル作られる必要があるだろうしながら、IPv4のヘッダチェックサムの再計算は、出力バッファ型スイッチを使用して、いくつかのハイエンド・ルータ・アーキテクチャの問題です出力バッファに。何のIPv6ヘッダのチェックサムが存在しないので、これは、IPv6のための問題ではありません。 IPv4のTOSオクテットは、16ビットのハーフワードの最後のバイトです。
RFC 1141 [RFC1141] discusses the incremental updating of the IPv4 checksum after the TTL field is decremented. The incremental updating of the IPv4 checksum after the CE codepoint was set would work as follows: Let HC be the original header checksum for an ECT(0) packet, and let HC' be the new header checksum after the CE bit has been set. That is, the ECN field has changed from '10' to '11'. Then for header checksums calculated with one's complement subtraction, HC' would be recalculated as follows:
TTLフィールドはデクリメントされた後、RFC 1141 [RFC1141]はIPv4のチェックサムの差分更新を論じています。 CEコードポイントが設定された後、次のようにIPv4のチェックサムの増分更新は動作します：HCはECT（0）パケットの元のヘッダのチェックサムとすると、CEビットがセットされた後、HCは「新しいヘッダチェックサムとします。すなわち、ECNフィールドが「11」と「10」から変更されています。次のようにヘッダーの1の補数の減算、HC」で計算チェックサムが再計算されるであろう。
HC' = { HC - 1 HC > 1
{ 0x0000 HC = 1
For header checksums calculated on two's complement machines, HC' would be recalculated as follows after the CE bit was set:
CEビットがセットされた後、次のように2の補数のマシンで計算し、ヘッダのチェックサムの場合、HCは、」再計算されます：
HC' = { HC - 1 HC > 0
{ 0xFFFE HC = 0
A similar incremental updating of the IPv4 checksum can be carried out when the ECN field is changed from ECT(1) to CE, that is, from ' 01' to '11'.
IPv4のチェックサムの同様の増分更新は「11」と「01」から、すなわち、ECNフィールドはCEにECT（1）から変更されたときに行うことができます。
This section discusses in detail possible changes to the ECN field in the network, such as falsely reporting congestion, disabling ECN-Capability for an individual packet, erasing the ECN congestion indication, or falsely indicating ECN-Capability.
このセクションでは、詳細には、このような誤って、個々のパケットのためのECN-機能を無効にする、輻輳を報告ECN輻輳表示を消去、または誤っECN-能力を示すようなネットワーク内のECNフィールドの可能な変更を、説明します。
First, we consider the changes that a router could make that would result in effectively erasing the congestion indication after it had been set by a router upstream. The convention followed is: ECN codepoint of received packet -> ECN codepoint of packet transmitted.
まず、ルータはそれはそれは、上流のルータによって設定された後に効果的に輻輳表示を消すことになる作ることができるの変更を検討してください。受信したパケットのECNコードポイント - > ECNコードポイントパケットの送信：慣例があるが続きます。
Replacing the CE codepoint with the ECT(0) or ECT(1) codepoint effectively erases the congestion indication. However, with the use of two ECT codepoints, a router erasing the CE codepoint has no way to know whether the original ECT codepoint was ECT(0) or ECT(1). Thus, it is possible for the transport protocol to deploy mechanisms to detect such erasures of the CE codepoint.
ECT（0）かECTとCEコードポイントの交換（1）コードポイントを効果的に輻輳表示を消去します。しかし、2つのECTコードポイントを使用して、CEコードポイントを消去ルータがオリジナルECTコードポイントがECT（0）かECT（1）であったかどうかを知る方法がありません。トランスポートプロトコルがCEコードポイントのような消去を検出するためのメカニズムを展開するためにこのように、それが可能です。
The consequence of the erasure of the CE codepoint for the upstream router is that there is a potential for congestion to build for a time, because the congestion indication does not reach the source. However, the packet would be received and acknowledged.
上流のルータのためのCEコードポイントの消去の結果は、輻輳表示が元に達していないため、時間のために構築するための輻輳の可能性があるということです。しかし、パケットが受信され、承認されるでしょう。
The potential effect of erasing the congestion indication is complex, and is discussed in depth in Section 19 below. Note that the effect of erasing the congestion indication is different from dropping a packet in the network. When a data packet is dropped, the drop is detected by the TCP sender, and interpreted as an indication of congestion. Similarly, if a sufficient number of consecutive acknowledgement packets are dropped, causing the cumulative acknowledgement field not to be advanced at the sender, the sender is limited by the congestion window from sending additional packets, and ultimately the retransmit timer expires.
輻輳表示を消去する潜在的な影響は複雑であり、そして以下のセクション19で詳しく説明されています。輻輳表示を消去する効果がネットワークにパケットを落とすとは異なることに留意されたいです。データパケットがドロップされると、ドロップは、TCP送信者によって検出し、輻輳の指標として解釈されます。連続する確認応答パケットの十分な数がドロップされる場合は、同様に、送信側で前進されない累積確認応答フィールドを引き起こし、送信者は、追加パケットを送信輻輳ウィンドウによって制限され、最終的に再送信タイマが満了します。
In contrast, a systematic erasure of the CE bit by a downstream router can have the effect of causing a queue buildup at an upstream router, including the possible loss of packets due to buffer overflow. There is a potential of unfairness in that another flow that goes through the congested router could react to the CE bit set while the flow that has the CE bit erased could see better performance. The limitations on this potential unfairness are discussed in more detail in Section 19 below.
対照的に、下流のルータによってCEビットの体系的消去は、バッファオーバーフローによるパケットの損失の可能性を含む、上流のルータのキューの蓄積を引き起こす効果を有することができます。より良いパフォーマンスを見ることができ、消去CEビットを持って流れている間に設定CEビットに反応する可能性が混雑し、ルータを経由するという別のフローにおける不公平の可能性があります。この潜在的不公平の制限は以下のセクション19で詳しく説明されています。
The last of the three changes is to replace the CE codepoint with the not-ECT codepoint, thus erasing the congestion indication and disabling ECN-Capability at the same time.
3つの変更の最後は、このように輻輳表示を消すと同時に、ECN-機能を無効にし、ない-ECTコードポイントでCEコードポイントを交換することです。
The `erasure' of the congestion indication is only effective if the packet does not end up being marked or dropped again by a downstream router. If the CE codepoint is replaced by an ECT codepoint, the packet remains ECN-Capable, and could be either marked or dropped by a downstream router as an indication of congestion. If the CE codepoint is replaced by the not-ECT codepoint, the packet is no longer ECN-capable, and can therefore be dropped but not marked by a downstream router as an indication of congestion.
パケットが下流ルータによって再びマークまたはドロップされてしまうしない場合は輻輳表示の `消去は」のみ有効です。 CEコードポイントは、ECTコードポイントに置き換えている場合は、パケットはECN対応のままで、マークまたは輻輳の指標として下流のルータによって廃棄される可能性のいずれか。 CEコードポイントがない-ECTコードポイントに置き換えている場合は、パケットはもはやECN-ことができないので、ドロップすることができますが、混雑の指標として下流のルータによってマークされていません。
This change is to set the CE codepoint when an ECT codepoint was already set, even though there was no congestion. This change does not affect the treatment of that packet along the rest of the path. In particular, a router does not examine the CE codepoint in deciding whether to drop or mark an arriving packet.
この変更は、ECTコードポイントは既に輻輳がなかったにも関わらず、設定されたとき、CEコードポイントを設定することです。この変更は、パスの残りの部分に沿ってそのパケットの治療に影響を与えることはありません。具体的には、ルータは、到着したパケットを落としたり、マークするかどうかを決定する際にCEコードポイントを調べていません。
However, this could result in the application unnecessarily invoking end-to-end congestion control, and reducing its arrival rate. By itself, this is no worse (for the application or for the network) than if the tampering router had actually dropped the packet.
しかし、これは、アプリケーションが不必要にエンドツーエンドの輻輳制御を呼び出し、その到着率を減らすことにつながる可能性があります。それ自体で、これは改ざんルータが実際にパケットを落とした場合よりも（アプリケーションまたはネットワーク用）が悪化していません。
This change is to turn off the ECT codepoint of a packet. This means that if the packet later encounters congestion (e.g., by arriving to a RED queue with a moderate average queue size), it will be dropped instead of being marked. By itself, this is no worse (for the application) than if the tampering router had actually dropped the packet. The saving grace in this particular case is that there is no congested router upstream expecting a reaction from setting the CE bit.
この変更は、パケットのECTコードポイントをオフにすることです。これは、パケットが後で渋滞に遭遇した場合（例えば、中等度の平均キューサイズとREDキューに到着して）、それは代わりにマークされずに廃棄されることを意味します。それ自体で、これは改ざんルータが実際にパケットを落とした場合よりも（アプリケーション用）悪くないではありません。この特定のケースでの救いは、上流CEビットをセットからの反応を期待して何の混雑ルーターがないことです。
This change would incorrectly label a packet as ECN-Capable. The packet may have been sent either by an ECN-Capable transport or a transport that is not ECN-Capable.
この変更は、誤っECN対応として、パケットにラベルを付けます。パケットは、いずれかのECN対応の輸送やECN対応ではないトランスポートで送信された可能性があります。
If the packet later encounters moderate congestion at an ECN-Capable router, the router could set the CE codepoint instead of dropping the packet. If the transport protocol in fact is not ECN-Capable, then the transport will never receive this indication of congestion, and will not reduce its sending rate in response. The potential consequences of falsely indicating ECN-capability are discussed further in Section 19 below.
パケットが後にECN対応ルータでの適度な混雑に遭遇した場合、ルータは代わりにパケットを落とすのCEコードポイントを設定することができます。実際には、トランスポートプロトコルがECN対応ではない場合、輸送は混雑のこの指示を受けることはありません、それに応答してその送信レートを減らすことはありません。誤っ示すECN-能力の潜在的影響は、以下のセクション19でさらに議論されています。
If the packet never later encounters congestion at an ECN-Capable router, then the first of these two changes would have no effect, other than possibly interfering with the use of the ECN nonce by the transport protocol. The last change, however, would have the effect of giving false reports of congestion to a monitoring device along the path. If the transport protocol is ECN-Capable, then this change could also have an effect at the transport level, by combining falsely indicating ECN-Capability with falsely reporting congestion. For an ECN-capable transport, this would cause the transport to unnecessarily react to congestion. In this particular case, the router that is incorrectly changing the ECN field could have dropped the packet. Thus for this case of an ECN-capable transport, the consequence of this change to the ECN field is no worse than dropping the packet.
パケットがECN対応ルータで輻輳が発生したことはありません、後で場合は、これら2つの変化の最初のは、おそらくトランスポートプロトコルによってECNナンスの使用を妨害する以外には影響を、持っていないだろう。最後の変更は、しかし、パスに沿って監視装置に輻輳の虚偽の報告を与える効果があります。トランスポートプロトコルは、ECN-可能である場合、この変化はまた、誤って輻輳を報告してECN-能力を示す誤って組み合わせることにより、トランスポートレベルで効果を有することができます。 ECN対応の輸送については、これは輸送が不必要に混雑に反応してしまいます。この特定のケースでは、誤っECNフィールドを変更しているルータは、パケットを落としたかもしれません。したがってECN-可能な輸送のために、この場合、ECNフィールドにこの変更の結果、パケットを落とすよりも悪くはありません。
For TCP, an ECN-capable TCP receiver informs its TCP peer that it is ECN-capable at the TCP level, conveying this information in the TCP header at the time the connection is setup. This document does not consider potential dangers introduced by changes in the transport header within the network. We note that when IPsec is used, the transport header is protected both in tunnel and transport modes [ESP, AH].
TCPは、ECN-可能なTCP受信機は、接続がセットアップされる時にTCPヘッダにこの情報を伝える、それはTCPレベルでECN-可能なそのTCPピアに通知します。この文書では、ネットワーク内のトランスポート・ヘッダーの変化によって導入潜在的な危険性を考慮していません。我々は、IPsecを使用する場合、トランスポート・ヘッダはトンネルおよびトランスポートモード[ESP、AH]の両方で保護されていることに注意してください。
Another issue concerns TCP packets with a spoofed IP source address carrying invalid ECN information in the transport header. For completeness, we examine here some possible ways that a node spoofing the IP source address of another node could use the two ECN flags in the TCP header to launch a denial-of-service attack. However, these attacks would require an ability for the attacker to use valid TCP sequence numbers, and any attacker with this ability and with the ability to spoof IP source addresses could damage the TCP connection without using the ECN flags. Therefore, ECN does not add any new vulnerabilities in this respect.
もう一つの問題は、トランスポート・ヘッダーに無効なECN情報を運ぶ偽装された送信元IPアドレスとTCPパケットに関するものです。完全を期すために、私たちはここで別のノードのIP送信元アドレスを偽装ノードは、サービス拒否攻撃を開始するためにTCPヘッダーで2つのECNフラグを使用することができ、いくつかの可能な方法を検討します。しかし、これらの攻撃は、有効なTCPシーケンス番号を使用する攻撃者のための能力、およびこの能力を持つとECNフラグを使用せずにTCP接続を損傷する可能性があるIP送信元アドレスを偽装する能力を持つ任意の攻撃者を必要とします。そのため、ECNは、この点で任意の新しい脆弱性を追加しません。
An acknowledgement packet with a spoofed IP source address of the TCP data receiver could include the ECE bit set. If accepted by the TCP data sender as a valid packet, this spoofed acknowledgement packet could result in the TCP data sender unnecessarily halving its congestion window. However, to be accepted by the data sender, such a spoofed acknowledgement packet would have to have the correct 32- bit sequence number as well as a valid acknowledgement number. An attacker that could successfully send such a spoofed acknowledgement packet could also send a spoofed RST packet, or do other equally damaging operations to the TCP connection.
TCPデータ受信の偽装されたIPソースアドレスと確認応答パケットはECEビットのセットを含めることができます。有効なパケットとしてTCPデータの送信者が受け入れた場合、この偽装された確認応答パケットはTCPデータの送信者が不必要にその輻輳ウィンドウを半減につながる可能性があります。しかし、データの送信者に受け入れられるためには、そのような偽装された確認応答パケットが正しい32ビットのシーケンス番号だけでなく、有効な確認番号を持っている必要があります。成功したように偽装された確認応答パケットを送信することができ、攻撃者はまた、偽装されたRSTパケットを送ったり、TCP接続に他の同様に有害な操作を行うことができます。
Packets with a spoofed IP source address of the TCP data sender could include the CWR bit set. Again, to be accepted, such a packet would have to have a valid sequence number. In addition, such a spoofed packet would have a limited performance impact. Spoofing a data packet with the CWR bit set could result in the TCP data receiver sending fewer ECE packets than it would otherwise, if the data receiver was sending ECE packets when it received the spoofed CWR packet.
TCPデータ送信元の偽装されたIP送信元アドレスを持つパケットは、CWRビットのセットを含めることができます。ここでも、受け入れられるように、このようなパケットは、有効なシーケンス番号を持っている必要があります。また、このような偽装されたパケットは、限られたパフォーマンスの影響を与えるだろう。それはそうでない場合よりも、それがスプーフィングされたCWRパケットを受信したときにデータ受信がECEパケットを送信した場合CWRビットセットを有するデータパケットを偽装することは、より少ないECEパケットを送信するTCPデータ受信装置につながる可能性があります。
In some cases, a malicious or broken router might have access to only a subset of the packets from a flow. The question is as follows: can this router, by altering the ECN field in this subset of the packets, do more damage to that flow than if it had simply dropped that set of packets?
いくつかのケースでは、悪質な、または壊れたルータは、フローからのパケットのサブセットのみにアクセスできる場合があります。次のように質問です：このルータは、パケットのこのサブセットでECNフィールドを変更することによって、それは単にパケットのセットを落とした場合よりもその流れに多くのダメージを行うことができますか？
We will classify the packets in the flow as A packets and B packets, and assume that the adversary only has access to A packets. Assume that the adversary is subverting end-to-end congestion control along the path traveled by A packets only, by either falsely indicating ECN-Capability upstream of the point where congestion occurs, or erasing the congestion indication downstream. Consider also that there exists a monitoring device that sees both the A and B packets, and will "punish" both the A and B packets if the total flow is determined not to be properly responding to indications of congestion. Another key characteristic that we believe is likely to be true is that the monitoring device, before `punishing' the A&B flow, will first drop packets instead of setting the CE codepoint, and will drop arriving packets of that flow that already have the CE codepoint set. If the end nodes are in fact using end-to-end congestion control, they will see all of the indications of congestion seen by the monitoring device, and will begin to respond to these indications of congestion. Thus, the monitoring device is successful in providing the indications to the flow at an early stage.
私たちは、パケットとBパケットとしてフロー内のパケットを分類し、敵がパケットのみへのアクセス権を持っていることを前提としています。敵対者が誤って輻輳が発生する点の上流ECN-能力を示す、または下流輻輳表示を消去するのいずれかによって、パケットのみが移動する経路に沿ってエンドツーエンドの輻輳制御を打倒されると仮定する。 AとBのパケットの両方を見て、総流量が適切輻輳の指示に応答していないと判定された場合、両方のA及びBのパケットを「罰」であろう監視装置が存在することも考えます。私たちは真である可能性が高いと考えているもう一つの重要な特徴は、監視装置は、 `処罰」A＆Bの流れの前に、まずCEコードポイントを設定するのではなく、パケットをドロップし、すでにCEコードポイントを持っている流れの到着するパケットをドロップしますということですセットする。エンド・ノードは、エンドツーエンドの輻輳制御を使用して、実際にされている場合は、監視装置によって見輻輳の兆候のすべてが表示され、混雑のこれらの表示に対応するために開始されます。これにより、監視装置は、早い段階での流れの表示を提供することに成功しています。
It is true that the adversary that has access only to the A packets might, by subverting ECN-based congestion control, be able to deny the benefits of ECN to the other packets in the A&B aggregate. While this is unfortunate, this is not a reason to disable ECN.
唯一のAパケットへのアクセスを持っている敵は、ECNベースの輻輳制御を破壊することで、A＆B総額で他のパケットにECNの恩恵を拒否することができるかもしれないことは事実です。これは残念なことですが、これはECNを無効にする理由にはなりません。
A variant of falsely reporting congestion occurs when there are two adversaries along a path, where the first adversary falsely reports congestion, and the second adversary `erases' those reports. (Unlike packet drops, ECN congestion reports can be `reversed' later in the network by a malicious or broken router. However, the use of the ECN nonce could help the transport to detect this behavior.) While this would be transparent to the end node, it is possible that a monitoring device between the first and second adversaries would see the false indications of congestion. Keep in mind our recommendation in this document, that before `punishing' a flow for not responding appropriately to congestion, the router will first switch to dropping rather than marking as an indication of congestion, for that flow. When this includes dropping arriving packets from that flow that have the CE codepoint set, this ensures that these indications of congestion are being seen by the end nodes. Thus, there is no additional harm that we are able to postulate as a result of multiple conflicting adversaries.
最初の敵対者が誤って輻輳を報告経路に沿った2人の敵が存在する場合に誤って輻輳報告の変形が発生し、第二の敵は `それらのレポートを消去します。 （パケットドロップとは異なり、ECNの輻輳レポートは `悪意のあるまたは壊れたルータによって、後にネットワークの」逆にすることができる。しかし、ECNナンスの使用は、この動作を検出するための輸送を助けることができる。）これは最後に透明であろうがノード、第1及び第2の敵の間に監視装置が輻輳の誤った表示を見ることが可能です。 `「混雑に適切に応答しないための流れを罰する前に、ルータは最初の落下ではなく、そのフローの輻輳の兆候としてマーキングに切り替えますことを、心の中でこの文書に記載されている私たちの勧告をしてください。これはCEコードポイントのセットを有するそのフローからの到着パケットをドロップ含む場合、これは、輻輳のこれらの指標は、エンドノードによって見られていることを保証します。したがって、我々は競合する複数の敵の結果として仮定することができます追加の害はありません。
This section focuses on the potential repercussions of subverting end-to-end congestion control by either falsely indicating ECN-Capability, or by erasing the congestion indication in ECN (the CE codepoint). Subverting end-to-end congestion control by either of these two methods can have consequences both for the application and for the network. We discuss these separately below.
このセクションでは、いずれかの誤指示ECN-能力によって、またはECNにおける輻輳表示（CEコードポイント）を消去することにより、エンドツーエンドの輻輳制御を破壊するの潜在的な影響に焦点を当てています。これらの2つの方法のいずれかによって、エンドツーエンドの輻輳制御を破壊することは、アプリケーションおよびネットワークの両方に影響を持つことができます。私たちは、別途以下これらを議論します。
The first method to subvert end-to-end congestion control, that of falsely indicating ECN-Capability, effectively subverts end-to-end congestion control only if the packet later encounters congestion that results in the setting of the CE codepoint. In this case, the transport protocol (which may not be ECN-capable) does not receive the indication of congestion from these downstream congested routers.
第一の方法は、誤っECN-能力を示すの有効パケットが後CEコードポイントの設定において生じる輻輳が発生した場合にのみ、エンド・ツー・エンドの輻輳制御を覆すことは、エンドツーエンドの輻輳制御を破壊します。この場合、（ECN-可能でなくてもよい）、トランスポートプロトコルは、これらの下流輻輳ルータから輻輳表示を受信しません。
The second method to subvert end-to-end congestion control, `erasing' the CE codepoint in a packet, effectively subverts end-to-end congestion control only when the CE codepoint in the packet was set earlier by a congested router. In this case, the transport protocol does not receive the indication of congestion from the upstream congested routers.
`消去」、パケット内のCEコードポイントを、エンドツーエンドの輻輳制御を破壊するための第2の方法は、効果的にパケットのCEコードポイントが輻輳ルータによって以前に設定した場合にのみ、エンドツーエンドの輻輳制御を覆します。この場合、トランスポート・プロトコルは、上流輻輳ルータから輻輳通知を受信しません。
Either of these two methods of subverting end-to-end congestion control can potentially introduce more damage to the network (and possibly to the flow itself) than if the adversary had simply dropped packets from that flow. However, as we discuss later in this section and in Section 7, this potential damage is limited.
潜在的に敵対者が単にそのフローからパケットをドロップした場合よりも（フロー自体に、おそらく）複数のネットワークへの損傷を導入することができるエンドツーエンドの輻輳制御を破壊するのこれらの2つの方法のいずれか。私たちは、このセクションでは、セクション7で、後に議論するようしかし、この潜在的な被害は限定的です。
The CE codepoint of the ECN field is only used by routers as an indication of congestion during periods of *moderate* congestion. ECN-capable routers should drop rather than mark packets during heavy congestion even if the router's queue is not yet full. For example, for routers using active queue management based on RED, the router should drop rather than mark packets that arrive while the average queue sizes exceed the RED queue's maximum threshold.
ECNフィールドのCEコードポイントのみ*適度*輻輳の期間中輻輳の指標としてルータによって使用されます。 ECN対応ルータは、ルータのキューがまだ満杯でない場合であっても重い輻輳時ではなく、マークパケットをドロップする必要があります。例えば、REDに基づくアクティブキュー管理を使用してルータに、ルータはドロップではなく、平均キューサイズがREDキューの最大しきい値を超えている間に到着するパケットをマークしなければなりません。
One consequence for the network of subverting end-to-end congestion control is that flows that do not receive the congestion indications from the network might increase their sending rate until they drive the network into heavier congestion. Then, the congested router could begin to drop rather than mark arriving packets. For flows that are not isolated by some form of per-flow scheduling or other per-flow mechanisms, but are instead aggregated with other flows in a single queue in an undifferentiated fashion, this packet-dropping at the congested router would apply to all flows that share that queue. Thus, the consequences would be to increase the level of congestion in the network.
エンドツーエンドの輻輳制御を破壊するのネットワークのための1つの結果は、彼らが重い混雑にネットワークをドライブするまで、ネットワークからの輻輳指示を受信していないフローが自分の送信レートを上げるかもしれないということです。その後、混雑ルータはドロップではなく、到着したパケットをマークするために始めることができます。フロー単位のスケジューリングまたは他のフローごとの機構のいくつかの形態によって単離されていないが、代わりに未分化の様式で単一のキュー内の他のフローに集約されたフローのための、このパケットドロップ輻輳ルータでは、すべてのフローに適用されますキューを共有。したがって、結果は、ネットワーク内の輻輳のレベルを上げることであろう。
In some cases, the increase in the level of congestion will lead to a substantial buffer buildup at the congested queue that will be sufficient to drive the congested queue from the packet-marking to the packet-dropping regime. This transition could occur either because of buffer overflow, or because of the active queue management policy described above that drops packets when the average queue is above RED's maximum threshold. At this point, all flows, including the subverted flow, will begin to see packet drops instead of packet marks, and a malicious or broken router will no longer be able to ` erase' these indications of congestion in the network. If the end nodes are deploying appropriate end-to-end congestion control, then the subverted flow will reduce its arrival rate in response to congestion. When the level of congestion is sufficiently reduced, the congested queue can return from the packet-dropping regime to the packet-marking regime. The steady-state pattern could be one of the congested queue oscillating between these two regimes.
いくつかのケースでは、混雑のレベルの増加は、パケットドロップレジームにパケットマーキングから輻輳キューを駆動するのに十分であろう輻輳キューにおける実質的なバッファの蓄積につながります。この遷移は、平均キューがREDの最大閾値を上回る場合のいずれかであるため、バッファオーバーフロー、またはそのため、上述のアクティブキュー管理ポリシーのパケットをドロップ起こり得ます。この時点で、堕落フローを含むすべてのフローは、パケットがパケットマークの代わりに低下し、悪意のあるまたは壊れたルータは、もはや `「ネットワークの輻輳のこれらの表示を消去することができなくなります見て開始されます。エンドノードが適切なエンドツーエンドの輻輳制御を展開する場合、その後打倒フローが輻輳に応答してその到着率を低下させます。渋滞のレベルが十分に低減されている場合、混雑キューがパケットマーキング政権にパケット・ドロップ政権から戻ることができます。定常状態のパターンは、これら二つの制度間の混雑キュー振動の一つである可能性があります。
In other cases, the consequences of subverting end-to-end congestion control will not be severe enough to drive the congested link into sufficiently-heavy congestion that packets are dropped instead of being marked. In this case, the implications for competing flows in the network will be a slightly-increased rate of packet marking or dropping, and a corresponding decrease in the bandwidth available to those flows. This can be a stable state if the arrival rate of the subverted flow is sufficiently small, relative to the link bandwidth, that the average queue size at the congested router remains under control. In particular, the subverted flow could have a limited bandwidth demand on the link at this router, while still getting more than its "fair" share of the link. This limited demand could be due to a limited demand from the data source; a limitation from the TCP advertised window; a lower-bandwidth access pipe; or other factors. Thus the subversion of ECN-based congestion control can still lead to unfairness, which we believe is appropriate to note here.
他の例では、エンドツーエンドの輻輳制御を破壊するの結果は、パケットが代わりにマークされるので廃棄され、十分に重い渋滞に混雑リンクを駆動するのに十分深刻ではありません。この場合には、ネットワーク内の競合フローの影響は、マーキングまたはドロップパケットのわずかに増加した速度、及びこれらのフローに利用可能な帯域幅の対応する減少であろう。打倒フローの到着レートが輻輳ルータにおける平均キューサイズが制御下のままであることを、リンク帯域幅に対して、十分に小さい場合、これは安定な状態であることができます。まだリンクのその「公正」のシェアよりも多くを取得しながら、具体的には、堕落の流れは、このルータでは、リンク上の限られた帯域幅の需要を持つことができます。この限られた需要は、データ・ソースからの限られた需要によるものである可能性があります。 TCPからの制限は、ウィンドウを宣伝しました。低帯域幅のアクセス管と、またはその他の要因。したがって、ECNベースの輻輳制御の転覆はまだ我々がここで注意することは適切であると考えて不公平につながることができます。
The threat to the network posed by the subversion of ECN-based congestion control in the network is essentially the same as the threat posed by an end-system that intentionally fails to cooperate with end-to-end congestion control. The deployment of mechanisms in routers to address this threat is an open research question, and is discussed further in Section 10.
ネットワーク内のECNベースの輻輳制御の転覆によってもたらされるネットワークへの脅威は、本質的に、意図的に、エンドツーエンドの輻輳制御と協働することができないエンドシステムの脅威と同じです。この脅威に対処するためのルータにおけるメカニズムの展開は、オープン研究課題であり、第10章で詳しく説明されています。
Let us take the example described in Section 18.1.1, where the CE codepoint that was set in a packet is erased: {'11' -> '10' or '11' -> '01'}. The consequence for the congested upstream router that set the CE codepoint is that this congestion indication does not reach the end nodes for that flow. The source (even one which is completely cooperative and not malicious) is thus allowed to continue to increase its sending rate (if it is a TCP flow, by increasing its congestion window). The flow potentially achieves better throughput than the other flows that also share the congested router, especially if there are no policing mechanisms or per-flow queuing mechanisms at that router. Consider the behavior of the other flows, especially if they are cooperative: that is, the flows that do not experience subverted end-to-end congestion control. They are likely to reduce their load (e.g., by reducing their window size) on the congested router, thus benefiting our subverted flow. This results in unfairness. As we discussed above, this unfairness could either be transient (because the congested queue is driven into the packet-marking regime), oscillatory (because the congested queue oscillates between the packet marking and the packet dropping regime), or more moderate but a persistent stable state (because the congested queue is never driven to the packet dropping regime).
{ - >「10」または「11」 - >「01」「11」}：私たちは、パケットに設定されたCEコードポイントが消去され、セクション18.1.1に記載された例を見てみましょう。 CEコードポイントを設定する輻輳上流のルータの結果は、この輻輳表示は、その流れのためのエンドノードに到達しないことです。ソース（完全に協力的で悪意のない場合であっても1は）ので、（それはその輻輳ウィンドウを増やすことで、TCPフローの場合）、その送信レートを高めるために継続することができます。フローは、潜在的に何のポリシング機構またはフローごとのキューイングメカニズムがそのルータに存在しない場合は特に、また、輻輳ルータを共有する他のフローよりも優れたスループットを達成します。彼らは協力している場合は特に、他のフローの動作を考えてみましょう：それは、堕落エンドツーエンドの輻輳制御を経験しない流れです。彼らはこのように私たちの堕落の流れ恩恵を受け、混雑ルータ上で（自分のウィンドウサイズを減らすことによって、例えば）彼らの負荷を軽減する可能性があります。これは不公平になります。我々は上述したように、この不公平は、（混雑キューがパケットマーキング政権に打ち込まれているので）、一過可能性のいずれかの振動（混雑キューがパケットマーキングと政権をドロップするパケットの間で振動するので）、またはそれ以上の緩やかなものの、永続安定した状態（混雑キューがパケットドロップ政権に駆動されることはありませんので）。
The results would be similar if the subverted flow was intentionally avoiding end-to-end congestion control. One difference is that a flow that is intentionally avoiding end-to-end congestion control at the end nodes can avoid end-to-end congestion control even when the congested queue is in packet-dropping mode, by refusing to reduce its sending rate in response to packet drops in the network. Thus the problems for the network from the subversion of ECN-based congestion control are less severe than the problems caused by the intentional avoidance of end-to-end congestion control in the end nodes. It is also the case that it is considerably more difficult to control the behavior of the end nodes than it is to control the behavior of the infrastructure itself. This is not to say that the problems for the network posed by the network's subversion of ECN-based congestion control are small; just that they are dwarfed by the problems for the network posed by the subversion of either ECN-based or other currently known packet-based congestion control mechanisms by the end nodes.
打倒流れを意図的エンドツーエンドの輻輳制御を回避した場合の結果も同様であろう。 1つの違いは混雑キューは、パケット・ドロップモードにあるときでも、意図的にエンドノードでのエンドツーエンドの輻輳制御を回避されたフローがでその送信レートを減らすために拒否することによって、エンドツーエンドの輻輳制御を避けることができるということですパケットに対する応答は、ネットワーク内に落ちます。したがってECNベースの輻輳制御の転覆からネットワークの問題は、エンド・ノードにおけるエンドツーエンドの輻輳制御を意図的に回避することによって引き起こされる問題より少ない厳しいです。それは、インフラストラクチャ自体の動作を制御するよりも、それはエンドノードの動作を制御するためにかなり困難であることも同様です。これは、ECNベースの輻輳制御のネットワークの転覆によってもたらされるネットワークの問題が少ないと言っているわけではありません。それらはエンドノードによってECNベースまたは他のいずれかの現在知られているパケットベースの輻輳制御機構の転覆によってもたらされるネットワークの問題に矮小化されているだけです。
When a source indicates that it is ECN-capable, there is an expectation that the routers in the network that are capable of participating in ECN will use the CE codepoint for indication of congestion. There is the potential benefit of using ECN in reducing the amount of packet loss (in addition to the reduced queuing delays because of active queue management policies). When the packet flows through an IPsec tunnel where the nodes that the tunneled packets traverse are untrusted in some way, the expectation is that IPsec will protect the flow from subversion that results in undesirable consequences.
ソースはそれがECN-可能であることを示す場合、ECNに参加することが可能なネットワーク内のルータが輻輳の指示のCEコードポイントを使用することを期待されています。 （理由は、アクティブキュー管理ポリシーの減少キューイング遅延に加えて）パケット損失の量を減らすことでECNを使用することの潜在的な利点があります。パケットがトンネルパケットが横断するノードは、何らかの形で信頼されていないいるIPsecトンネルを通って流れるときに、期待はIPsecが望ましくない結果をもたらす転覆からの流れを保護することです。
In many cases, a subverted flow will benefit from the subversion of end-to-end congestion control for that flow in the network, by receiving more bandwidth than it would have otherwise, relative to competing non-subverted flows. If the congested queue reaches the packet-dropping stage, then the subversion of end-to-end congestion control might or might not be of overall benefit to the subverted flow, depending on that flow's relative tradeoffs between throughput, loss, and delay.
多くの場合、打倒フローは、非打倒フロー競合に対して、そうでなければなければならないより多くの帯域幅を受信することによって、ネットワーク内のその流れのためのエンドツーエンドの輻輳制御の転覆の恩恵を受ける。輻輳キューは、パケットドロップ段階に達すると、その後のエンドツーエンドの輻輳制御の転覆はまたはスループット、損失、遅延の間のフローの相対的なトレードオフに応じて、打倒流に対する全体的な有益でないかもしれないかもしれません。
One form of subverting end-to-end congestion control is to falsely indicate ECN-capability by setting the ECT codepoint. This has the consequence of downstream congested routers setting the CE codepoint in vain. However, as described in Section 9.1.2, if an ECT codepoint is changed in an IP tunnel, this can be detected at the egress point of the tunnel, as long as the inner header was not changed within the tunnel.
エンドツーエンドの輻輳制御を破壊するの一の形態は、誤ってECTコードポイントを設定することにより、ECN-の能力を示すためです。これは無駄にCEコードポイントを設定する下流の混雑ルータの結果を有します。セクション9.1.2に記載したようにECTコードポイントがIPトンネルに変更された場合は、これがあれば、内部ヘッダは、トンネル内で変更されなかったように、トンネルの出口点で検出することができます。
The second form of subverting end-to-end congestion control is to erase the congestion indication by erasing the CE codepoint. In this case, it is the upstream congested routers that set the CE codepoint in vain.
エンドツーエンドの輻輳制御を打倒の第2の形態はCEコードポイントを消去することにより、輻輳表示を消去することです。この場合には、無駄にCEコードポイントを設定する上流輻輳ルータです。
If an ECT codepoint is erased within an IP tunnel, then this can be detected at the egress point of the tunnel, as long as the inner header was not changed within the tunnel. If the CE codepoint is set upstream of the IP tunnel, then any erasure of the outer header's CE codepoint within the tunnel will have no effect because the inner header preserves the set value of the CE codepoint. However, if the CE codepoint is set within the tunnel, and erased either within or downstream of the tunnel, this is not necessarily detected at the egress point of the tunnel.
ECTコードポイントは、IPトンネル内で消去される場合、これは限り内部ヘッダは、トンネル内で変更されなかったように、トンネルの出口点で検出することができます。 CEコードポイントがIPトンネルの上流に設定されている場合、内部ヘッダがCEコードポイントの設定値を保持するので、その後トンネル内の外部ヘッダのCEコードポイントの任意の消去は効果がありません。 CEコードポイントがトンネル内に設定され、そして内部またはトンネルの下流のいずれか消去された場合は、これは、必ずしもトンネルの出口点で検出されません。
With this subversion of end-to-end congestion control, an end-system transport does not respond to the congestion indication. Along with the increased unfairness for the non-subverted flows described in the previous section, the congested router's queue could continue to build, resulting in packet loss at the congested router - which is a means for indicating congestion to the transport in any case. In the interim, the flow might experience higher queuing delays, possibly along with an increased bandwidth relative to other non-subverted flows. But transports do not inherently make assumptions of consistently experiencing carefully managed queuing in the path. We believe that these forms of subverting end-to-end congestion control are no worse for the subverted flow than if the adversary had simply dropped the packets of that flow itself.
エンドツーエンドの輻輳制御のこのSubversionで、エンド・システムの輸送は混雑指示に応答しません。いずれの場合にトランスポートに輻輳を示すための手段である - 前のセクションで説明した非打倒フローの増加不公平とともに、輻輳ルータのキューが輻輳ルータにパケット損失が生じる構築し続ける可能性があります。暫定では、流れはおそらく他の非堕落フローに対する帯域幅の増加の相対とともに、高いキューイング遅延が発生する可能性があります。しかし、トランスポートは、本質的に一貫して慎重にパスにキューイング管理経験の仮定をしないでください。私たちは、エンドツーエンドの輻輳制御を破壊するこれらの形態は、敵対者が単にその流れ自体のパケットを落とした場合よりも堕落の流れには悪いことではないと信じています。
We have shown that, in many cases, a malicious or broken router that is able to change the bits in the ECN field can do no more damage than if it had simply dropped the packet in question. However, this is not true in all cases, in particular in the cases where the broken router subverted end-to-end congestion control by either falsely indicating ECN-Capability or by erasing the ECN congestion indication (in the CE codepoint). While there are many ways that a router can harm a flow by dropping packets, a router cannot subvert end-to-end congestion control by dropping packets. As an example, a router cannot subvert TCP congestion control by dropping data packets, acknowledgement packets, or control packets.
私たちは、多くの場合、ECNフィールド内のビットを変更することができる悪意のあるまたは壊れたルータが、それは単に問題のパケットを落としていた場合よりも多くのダメージを行うことはできない、ということを示しています。しかし、これは誤っECN-能力や（CEコードポイントで）ECN輻輳表示を消去することによりを示すいずれかによって、エンドツーエンドの輻輳制御壊れたルータが打倒場合には特に、すべての場合に当てはまりません。ルータがパケットをドロップすることで、流れに害を与えることができる多くの方法がありますが、ルータがパケットをドロップすることで、エンドツーエンドの輻輳制御を覆すことはできません。一例として、ルータは、データパケット、確認応答パケット、または制御パケットをドロップすることにより、TCPの輻輳制御を覆すことはできません。
Even though packet-dropping cannot be used to subvert end-to-end congestion control, there *are* non-ECN-based methods for subverting end-to-end congestion control that a broken or malicious router could use. For example, a broken router could duplicate data packets, thus effectively negating the effects of end-to-end congestion control along some portion of the path. (For a router that duplicated packets within an IPsec tunnel, the security administrator can cause the duplicate packets to be discarded by configuring anti-replay protection for the tunnel.) This duplication of packets within the network would have similar implications for the network and for the subverted flow as those described in Sections 18.1.1 and 18.1.4 above.
パケットドロップは、エンドツーエンドの輻輳制御を破壊するために使用することができないにもかかわらず、*破損または悪意のルータが使用することができ、エンドツーエンドの輻輳制御を破壊するための*非ECNベースの方法があります。例えば、壊れたルータは、このように効果的に経路の一部に沿ってエンドツーエンドの輻輳制御の影響を打ち消し、データパケットを複製することができました。 （IPsecトンネル内のパケットを複製し、ルータの場合は、セキュリティ管理者は、重複パケットがトンネルのためのアンチリプレイ保護を構成することによって破棄される可能性があります。）は、ネットワーク内のパケットのこの重複は、ネットワークのためにとのために同様の意味合いを持っているでしょうセクション18.1.1および18.1.4上記で説明したものと打倒フロー。
The need for an ECT codepoint is motivated by the fact that ECN will be deployed incrementally in an Internet where some transport protocols and routers understand ECN and some do not. With an ECT codepoint, the router can drop packets from flows that are not ECN-capable, but can *instead* set the CE codepoint in packets that *are*
ECTコードポイントの必要性は、ECNは、いくつかのトランスポートプロトコルとルータがECNを理解し、一部にはないインターネットでインクリメンタルに展開されるという事実によって動機付けられています。 ECTコードポイントでは、ルータがECN-対応していないフローからのパケットをドロップすることができますが、代わりに* * * *されているパケットでCEコードポイントを設定することができます
ECN-capable. Because an ECT codepoint allows an end node to have the CE codepoint set in a packet *instead* of having the packet dropped, an end node might have some incentive to deploy ECN.
ECN対応。 ECTコードポイントがエンド・ノードがパケットに設定CEコードポイントを持つことができますので、パケットを持つことがドロップの代わりに* *、エンド・ノードは、ECNを展開するためにいくつかのインセンティブを持っているかもしれません。
If there was no ECT codepoint, then the router would have to set the CE codepoint for packets from both ECN-capable and non-ECN-capable flows. In this case, there would be no incentive for end-nodes to deploy ECN, and no viable path of incremental deployment from a non-ECN world to an ECN-capable world. Consider the first stages of such an incremental deployment, where a subset of the flows are ECN-capable. At the onset of congestion, when the packet dropping/marking rate would be low, routers would only set CE codepoints, rather than dropping packets. However, only those flows that are ECN-capable would understand and respond to CE packets. The result is that the ECN-capable flows would back off, and the non-ECN-capable flows would be unaware of the ECN signals and would continue to open their congestion windows.
何ECTコードポイントがなかった場合、ルータがECN対応と非ECN対応のフローの両方からのパケットのためのCEコードポイントを設定する必要があります。この場合、エンドノードは、ECNを展開するためのインセンティブ、およびECN対応の世界への非ECNの世界からの増分展開の無い実行可能なパスはないだろう。フローのサブセットは、ECN-可能であるような増分展開の最初の段階を考慮する。パケット廃棄/マーキング率が低くなるとき輻輳の開始時に、ルータはのみではなく、パケットをドロップするよりも、CEコードポイントを設定します。しかし、ECN-ことができる唯一のこれらのフローを理解し、CEパケットに応答することになります。その結果、ECN対応のフローがバックオフだろう、と非ECN対応のフローはECN信号に気づかないだろうし、その輻輳ウィンドウを開くし続けるだろうということです。
In this case, there are two possible outcomes: (1) the ECN-capable flows back off, the non-ECN-capable flows get all of the bandwidth, and congestion remains mild, or (2) the ECN-capable flows back off, the non-ECN-capable flows don't, and congestion increases until the router transitions from setting the CE codepoint to dropping packets. While this second outcome evens out the fairness, the ECN-capable flows would still receive little benefit from being ECN-capable, because the increased congestion would drive the router to packet-dropping behavior.
この場合、2つの可能な結果が存在する：（1）ECN-可能なフローは、バックオフ、非ECN対応フローは帯域幅の全てを取得し、輻輳が軽度のまま、または（2）ECN対応フローバックオフ非ECN対応フローはなく、ドロップパケットにCEコードポイントを設定することから、ルータ遷移するまで渋滞が増加します。この第二の結果は公平性をならしながら増加した輻輳がパケット・ドロップ動作にルータをドライブになるので、ECN対応のフローは、まだ、ECN-できるものからほとんど利益を受け取ることになります。
A flow that advertised itself as ECN-Capable but does not respond to CE codepoints is functionally equivalent to a flow that turns off congestion control, as discussed earlier in this document.
ECN-可能として自身をアドバタイズが、CEのコードポイントに応答しない流れが早く、この文書で説明したように、輻輳制御をオフ流れと機能的に同等です。
Thus, in a world when a subset of the flows are ECN-capable, but where ECN-capable flows have no mechanism for indicating that fact to the routers, there would be less effective and less fair congestion control in the Internet, resulting in a strong incentive for end nodes not to deploy ECN.
したがって、世界の流れのサブセットは、ECN-可能である場合が、ECN対応フローがルータにその旨を示すための機構を有していない場合、その結果、インターネットにあまり効果的でより少ない公正な輻輳制御が存在するであろうエンドノードのための強力なインセンティブがECNを展開しません。
The primary motivation for the two ECT codepoints is to provide a one-bit ECN nonce. The ECN nonce allows the development of mechanisms for the sender to probabilistically verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set.
2 ECTコードポイントのための主要な動機は、1ビットのECN nonceを提供することです。 ECNナンスは確率そのネットワーク要素がCEコードポイントを消去されず、そのデータ受信器が適切にCEコードポイントセットで送信側にパケットの受信を報告されていることを確認するために、送信者のためのメカニズムの開発を可能にします。
Another possibility for senders to detect misbehaving network elements or receivers would be for the data sender to occasionally send a data packet with the CE codepoint set, to see if the receiver reports receiving the CE codepoint. Of course, if these packets encountered congestion in the network, the router might make no change in the packets, because the CE codepoint would already be set. Thus, for packets sent with the CE codepoint set, the TCP end-nodes could not determine if some router intended to set the CE codepoint in these packets. For this reason, sending packets with the CE codepoint would have to be done sparingly, and would be a less effective check against misbehaving network elements and receivers than would be the ECN nonce.
誤動作のネットワーク要素または受信機を検出するために、送信者のための別の可能性は、受信レポートがCEコードポイントを受け取るかどうかを確認するために、時折CEコードポイントを設定してデータパケットを送信するために、データの送信者のためになります。これらのパケットは、ネットワークの輻輳が発生した場合のCEコードポイントがすでに設定されますので、もちろん、ルータは、パケットには変化をしないかもしれません。一部のルータがこれらのパケットにCEコードポイントを設定することを意図している場合このように、CEコードポイントを設定して送信されたパケットのために、TCPエンドノードは特定できませんでした。このため、CEコードポイントでパケットを送信することは慎重に行わなければならない、とECNナンスだろうよりも誤動作のネットワーク要素と受信機に対してはあまり有効チェックだろう。
The assignment of the fourth ECN codepoint to ECT(1) precludes the use of this codepoint for some other purposes. For clarity, we briefly list other possible purposes here.
ECT（1）第4 ECNコードポイントの割り当ては、いくつかの他の目的のために、このコードポイントの使用を妨げます。明確にするために、我々はここで簡単に他の可能な用途を一覧表示します。
One possibility might have been for the data sender to use the fourth ECN codepoint to indicate an alternate semantics for ECN. However, this seems to us more appropriate to be signaled using a differentiated services codepoint in the DS field.
一つの可能性は、ECNの代替意味を示すために、第四ECNコードポイントを使用するために、データの送信者のためだったかもしれません。しかし、これはDSフィールドに差別化されたサービスコードポイントを使用して合図するために私たちに、より適切と思われます。
A second possible use for the fourth ECN codepoint would have been to give the router two separate codepoints for the indication of congestion, CE(0) and CE(1), for mild and severe congestion respectively. While this could be useful in some cases, this certainly does not seem a compelling requirement at this point. If there was judged to be a compelling need for this, the complications of incremental deployment would most likely necessitate more that just one codepoint for this function.
第ECNコードポイントのための第二の可能な使用は、それぞれ、軽度および重度の輻輳のため、（1）、ルータに輻輳表示するための2つの別々のコードポイントを与えるCE（0）およびCEにあったであろう。これは、いくつかのケースで役に立つかもしれないが、これは確かにこの時点で説得力の要件を思えません。このために魅力的な必要性があると判断した場合は、増分の展開の合併症が最も可能性の高いこの機能のために、よりそのちょうど1コードポイントが必要となります。
A third use that has been informally proposed for the ECN codepoint is for use in some forms of multicast congestion control, based on randomized procedures for duplicating marked packets at routers. Some proposed multicast packet duplication procedures are based on a new ECN codepoint that (1) conveys the fact that congestion occurred upstream of the duplication point that marked the packet with this codepoint and (2) can detect congestion downstream of that duplication point. ECT(1) can serve this purpose because it is both distinct from ECT(0) and is replaced by CE when ECN marking occurs in response to congestion or incipient congestion. Explanation of how this enhanced version of ECN would be used by multicast congestion control is beyond the scope of this document, as are ECN-aware multicast packet duplication procedures and the processing of the ECN field at multicast receivers in all cases (i.e., irrespective of the multicast packet duplication procedure(s) used).
非公式ECNコードポイントのために提案されている第三の使用は、ルータでマーキングされたパケットを複製するための無作為化手順に基づいて、マルチキャスト輻輳制御のいくつかの形態で使用するためのものです。いくつか提案されているマルチキャストパケットの複製手順は、新しいECNに基づいている（1）輻輳がこのコードポイントでパケットをマーク重複点の上流に発生し、（2）その重複点の下流での輻輳を検出することができることを伝えることをコードポイント。それはECT（0）とは別個の両方で、ECNマーキングが輻輳又は初期輻輳に応答して発生した場合にCEによって置換されているため、ECT（1）は、この目的を果たすことができます。 ECN対応のマルチキャストパケットの複製手順と、すべての場合においてマルチキャストレシーバーのECNフィールドの処理（つまりは関係なく、あるとして、ECNのこの強化されたバージョンは、マルチキャスト輻輳制御で使用される方法の説明は、このドキュメントの範囲を超えていますマルチキャストパケット複製手順（複数可）を使用）。
The specification of IP tunnel modifications for ECN in this document assumes that the only change made to the outer IP header's ECN field between tunnel endpoints is to set the CE codepoint to indicate congestion. This is not consistent with some of the proposed uses of ECT(1) by the multicast duplication procedures in the previous paragraph, and such procedures SHOULD NOT be deployed unless this inconsistency between multicast duplication procedures and IP tunnels with full ECN functionality is resolved. Limited ECN functionality may be used instead, although in practice many tunnel protocols (including IPsec) will not work correctly if multicast traffic duplication occurs within the tunnel
この文書に記載されているECNのためのIPトンネル変更の仕様は、トンネルエンドポイント間の外側のIPヘッダのECNフィールドに対して行われた変更のみが輻輳を示すために、CEコードポイントを設定することであることを前提としています。これは、前の段落では、マルチキャスト複製手順によって、（1）ECTの提案用途の一部と一致しないと、完全なECN機能を持つマルチキャスト複製手順およびIPトンネルの間のこの矛盾が解決されない限り、このような手順は配置しないでください。限られたECN機能は、マルチキャストトラフィックの複製がトンネル内で発生した場合に実際多くのトンネルプロトコルは（IPsecを含む）が正しく動作しませんが、代わりに使用することができます
Given the need for an ECT indication in the IP header, there still remains the question of whether the ECT (ECN-Capable Transport) and CE (Congestion Experienced) codepoints should have been overloaded on a single bit. This overloaded-one-bit alternative, explored in [Floyd94], would have involved a single bit with two values. One value, "ECT and not CE", would represent an ECN-Capable Transport, and the other value, "CE or not ECT", would represent either Congestion Experienced or a non-ECN-Capable transport.
IPヘッダ内のECT表示の必要性を考えると、まだECT（ECN-できるTransport）とCE（輻輳経験豊富な）コードポイントは、単一のビットにオーバーロードされている必要があるかどうかの疑問が残されています。 【Floyd94]で検討このオーバーロード-1ビットの代替案は、2つの値を用いて単一ビットを含んでいたであろう。一つの値が、「ECT及びませんCEは」ECN-できるTransportを表し、他の値が、「CEかECT」、輻輳経験者や非ECN対応トランスポートのいずれかを表すことになります。
One difference between the one-bit and two-bit implementations concerns packets that traverse multiple congested routers. Consider a CE packet that arrives at a second congested router, and is selected by the active queue management at that router for either marking or dropping. In the one-bit implementation, the second congested router has no choice but to drop the CE packet, because it cannot distinguish between a CE packet and a non-ECT packet. In the two-bit implementation, the second congested router has the choice of either dropping the CE packet, or of leaving it alone with the CE codepoint set.
1ビットと2ビット実装の違いの1つは、複数の輻輳ルータを通過するパケットに関する。二混雑ルータに到着し、マーキングまたはドロップのいずれかのためにそのルータのアクティブキュー管理によって選択されたCEパケットを考えてみましょう。 1ビットの実装では、第二の混雑ルータはCEパケットと非ECTパケットを区別できないので、CEパケットをドロップするしかありません。 2ビットの実装では、第二の混雑ルータはCEパケットをドロップ、またはCEコードポイントを設定してそれだけを残してのいずれかの選択肢を持っています。
Another difference between the one-bit and two-bit implementations comes from the fact that with the one-bit implementation, receivers in a single flow cannot distinguish between CE and non-ECT packets. Thus, in the one-bit implementation an ECN-capable data sender would have to unambiguously indicate to the receiver or receivers whether each packet had been sent as ECN-Capable or as non-ECN-Capable. One possibility would be for the sender to indicate in the transport header whether the packet was sent as ECN-Capable. A second possibility that would involve a functional limitation for the one-bit implementation would be for the sender to unambiguously indicate that it was going to send *all* of its packets as ECN-Capable or as non-ECN-Capable. For a multicast transport protocol, this unambiguous indication would have to be apparent to receivers joining an on-going multicast session.
1ビットと2ビットの実装のもう1つの違いは、1ビットの実装で、単一のフローにおける受信機はCEと非ECTパケットを区別することができないという事実から来ています。したがって、1ビットの実装でECN-可能なデータ送信者が明確に各パケットがECN対応として、または非ECN-できるように送信されたかどうかを受信機又は受信機に指示しなければなりません。一つの可能性は、パケットがECN可能なように送信されたかどうかをトランスポートヘッダに示すために、送信者のためになります。 1ビットの実装のための機能制限を伴うだろう第二の可能性は、それが*すべて* ECN対応としてそのパケットのか、非ECN対応として送信するつもりだったことを明確に示すために、送信者のためになります。マルチキャストトランスポートプロトコルの場合、この明確な兆候は、受信機は、進行中のマルチキャストセッションに参加に明らかでなければならないであろう。
Another concern that was described earlier (and recommended in this document) is that transports (particularly TCP) should not mark pure ACK packets or retransmitted packets as being ECN-Capable. A pure ACK packet from a non-ECN-capable transport could be dropped, without necessarily having an impact on the transport from a congestion control perspective (because subsequent ACKs are cumulative). An ECN-capable transport reacting to the CE codepoint in a pure ACK packet by reducing the window would be at a disadvantage in comparison to a non-ECN-capable transport. For this reason (and for reasons described earlier in relation to retransmitted packets), it is desirable to have the ECT codepoint set on a per-packet basis.
（本書では、推奨さ）以前に記載されたもう一つの懸念は、トランスポート（特にTCP）がECN-できるものとして、純粋なACKパケットまたは再送パケットをマークべきではないということです。非ECN-可能なトランスポートからの純粋なACKパケットが（その後のACKが累積的であるため）、必ずしも輻輳制御の観点から輸送に影響を与えることなく、ドロップすることができます。ウィンドウを減少させることによって、純粋なACKパケットのCEコードポイントに反応ECN-可能な輸送は、非ECN-可能な輸送と比較して不利であろう。 （およびそれ以前の再送パケットとの関係で説明した理由のために）このような理由から、パケット単位でのECTコードポイントのセットを有することが望ましいです。
Another advantage of the two-bit approach is that it is somewhat more robust. The most critical issue, discussed in Section 8, is that the default indication should be that of a non-ECN-Capable transport. In a two-bit implementation, this requirement for the default value simply means that the not-ECT codepoint should be the default. In the one-bit implementation, this means that the single overloaded bit should by default be in the "CE or not ECT" position. This is less clear and straightforward, and possibly more open to incorrect implementations either in the end nodes or in the routers.
2ビットのアプローチのもう一つの利点は、ややより堅牢であるということです。第8章で説明し、最も重要な問題は、デフォルトの表示は非ECN対応の輸送のことでなければならないことです。 2ビットの実装では、デフォルト値のため、この要件は、単純ではない-ECTコードポイントがデフォルトでなければならないことを意味します。 1ビットの実装では、これは、単一のオーバーロードされたビットは、デフォルトでは「CEかECT」の位置にあるべきであることを意味します。これは、それほど明確で分かりやすい、およびエンド・ノードまたはルータのいずれかで間違った実装におそらくよりオープンです。
In summary, while the one-bit implementation could be a possible implementation, it has the following significant limitations relative to the two-bit implementation. First, the one-bit implementation has more limited functionality for the treatment of CE packets at a second congested router. Second, the one-bit implementation requires either that extra information be carried in the transport header of packets from ECN-Capable flows (to convey the functionality of the second bit elsewhere, namely in the transport header), or that senders in ECN-Capable flows accept the limitation that receivers must be able to determine a priori which packets are ECN-Capable and which are not ECN-Capable. Third, the one-bit implementation is possibly more open to errors from faulty implementations that choose the wrong default value for the ECN bit. We believe that the use of the extra bit in the IP header for the ECT-bit is extremely valuable to overcome these limitations.
1ビットの実装が可能で実装することができるが要約すると、それは2ビット実装に対して以下の重要な制限を有します。まず、1ビットの実装では、第二の輻輳ルータでCEパケットの治療のためのより限定された機能を有しています。第二に、1ビットの実装が必要いずれかの追加情報は、ECN-可能にECN対応フロー（すなわち、トランスポートヘッダに、他の場所で第2のビットの機能を伝えるために）、またはその送信者からのパケットの転送ヘッダで運ばれることフローは、受信機は、パケットがECN-可能であるとECN-できるされていない事前に決定することができなければならない制約を受け入れます。第三に、1ビットの実装では、ECNビットのための間違ったデフォルト値を選択し、故障の実装からエラーの可能性がよりオープンです。私たちは、ECTビットのIPヘッダ内の余分なビットの使用はこれらの制限を克服するために非常に貴重であると考えています。
RFC 791 [RFC791] defined the ToS (Type of Service) octet in the IP header. In RFC 791, bits 6 and 7 of the ToS octet are listed as "Reserved for Future Use", and are shown set to zero. The first two fields of the ToS octet were defined as the Precedence and Type of Service (TOS) fields.
RFC 791は、[RFC791] IPヘッダのToS（サービスのタイプ）オクテットを定義しました。 RFC 791において、ToSのオクテットのビット6と7は、「将来の使用のために予約」として表示され、ゼロに設定示されています。 ToSオクテットの最初の2つのフィールドは、サービスの優先順位とタイプ（TOS）フィールドとして定義しました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | 0 | 0 | RFC 791
+-----+-----+-----+-----+-----+-----+-----+-----+
RFC 1122 included bits 6 and 7 in the TOS field, though it did not discuss any specific use for those two bits:
それは、これら2つのビットのための任意の特定の使用を議論していなかったのにRFC 1122は、TOSフィールドのビット6と7に含ま：
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | RFC 1122
+-----+-----+-----+-----+-----+-----+-----+-----+
The IPv4 TOS octet was redefined in RFC 1349 [RFC1349] as follows:
次のようにIPv4のTOSオクテットは、RFC 1349 [RFC1349]に再定義しました。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ | RFC 1349
+-----+-----+-----+-----+-----+-----+-----+-----+
Bit 6 in the TOS field was defined in RFC 1349 for "Minimize Monetary Cost". In addition to the Precedence and Type of Service (TOS) fields, the last field, MBZ (for "must be zero") was defined as currently unused. RFC 1349 stated that "The originator of a datagram sets [the MBZ] field to zero (unless participating in an Internet protocol experiment which makes use of that bit)."
TOSフィールドのビット6は「金融コストを最小限に抑える」ためのRFC 1349で定義されました。 （「ゼロでなければなりません」など）の優先順位と型サービス（TOS）フィールド、最後のフィールド、MBZに加えて、現在使用されていないと定義しました。 RFC 1349は、「データグラム組の発信者が[MBZ]はフィールド（即ちビットを利用するインターネットプロトコル実験に参加していない限り）がゼロに。」と述べ
RFC 1455 [RFC 1455] defined an experimental standard that used all four bits in the TOS field to request a guaranteed level of link security.
RFC 1455 [RFC 1455]は、リンクのセキュリティの保証レベルを要求するTOSフィールドにすべての4つのビットを使用した実験標準を定義しました。
RFC 1349 and RFC 1455 have been obsoleted by "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] in which bits 6 and 7 of the DS field are listed as Currently Unused (CU). RFC 2780 [RFC2780] specified ECN as an experimental use of the two-bit CU field. RFC 2780 updated the definition of the DS Field to only encompass the first six bits of this octet rather than all eight bits; these first six bits are defined as the Differentiated Services CodePoint (DSCP):
RFC 1349及びRFC 1455は、DSフィールドの6及び7は、現在未使用（CU）として記載されているビットた「IPv4とIPv6ヘッダとの差別化されたサービスフィールド（DSフィールド）の定義」[RFC2474]によって廃止されてきました。 RFC 2780 [RFC2780]は、2ビットのCUフィールドの実験的使用としてECNを指定しました。 RFC 2780には、これだけのオクテットの最初の6ビットではなく、すべての8ビットを包含するDSフィールドの定義を更新。これらの最初の6ビットは、差別化サービスコードポイント（DSCP）のように定義されます。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | CU | RFCs 2474,
+-----+-----+-----+-----+-----+-----+-----+-----+ 2780
Because of this unstable history, the definition of the ECN field in this document cannot be guaranteed to be backwards compatible with all past uses of these two bits.
このため、不安定な歴史を、この文書のECNフィールドの定義は、これら2つのビットのすべての過去の使用との下位互換性を保証することはできません。
Prior to RFC 2474, routers were not permitted to modify bits in either the DSCP or ECN field of packets forwarded through them, and hence routers that comply only with RFCs prior to 2474 should have no effect on ECN. For end nodes, bit 7 (the second ECN bit) must be transmitted as zero for any implementation compliant only with RFCs prior to 2474. Such nodes may transmit bit 6 (the first ECN bit) as one for the "Minimize Monetary Cost" provision of RFC 1349 or the experiment authorized by RFC 1455; neither this aspect of RFC 1349 nor the experiment in RFC 1455 were widely implemented or used. The damage that could be done by a broken, non-conformant router would include "erasing" the CE codepoint for an ECN-capable packet that arrived at the router with the CE codepoint set, or setting the CE codepoint even in the absence of congestion. This has been discussed in the section on "Non-compliance in the Network".
RFC 2474の前に、ルータはそれらを介して転送されるパケットのDSCPまたはECNフィールドのいずれかのビットを変更することは許されないし、従って前2474にRFCにのみ準拠ルータがECNに影響を及ぼさないはずです。エンドノードのために、7（第2のECNビット）が「金融コストを最小限に抑える」提供するための1つとして、ビット6（第ECNビット）を送信することができる前に2474このようなノードにRFCにのみ準拠任意の実装のためにゼロとして送信されなければならないビットRFC 1349やRFC 1455によって認可の実験; RFC 1349のこの局面でもRFC 1455での実験でもないが広く実装または使用されました。壊れた、非準拠のルータによって行うことができるダメージがCEコードポイントを設定してルータに到着したECN対応のパケットのためのCEコードポイントを「消去」、あるいは輻輳のない状態でCEコードポイントの設定が含まれます。これは、「ネットワークでの非準拠」のセクションで議論されています。
The damage that could be done in an ECN-capable environment by a non-ECN-capable end-node transmitting packets with the ECT codepoint set has been discussed in the section on "Non-compliance by the End Nodes".
非ECN対応のエンド・ノードは、ECTコードポイントセットでパケットを送信することにより、ECN対応の環境で行うことができるダメージは「エンド・ノードによる非準拠」のセクションで説明されています。
This section contains the namespaces that have either been created in this specification, or the values assigned in existing namespaces managed by IANA.
このセクションでは、いずれかのこの仕様で作成されている名前空間、またはIANAによって管理され、既存の名前空間に割り当てられた値が含まれています。
The codepoints for the ECN Field of the IP header are specified by the Standards Action of this RFC, as is required by RFC 2780.
RFC 2780によって必要とされるIPヘッダのECNフィールドのためのコードポイントは、このRFCの標準アクションによって指定されます。
When this document is published as an RFC, IANA should create a new registry, "IPv4 TOS Byte and IPv6 Traffic Class Octet", with the namespace as follows:
この文書はRFCとして公開されると、以下のように、IANAは名前空間で、「IPv4のTOSバイトおよびIPv6トラフィッククラスオクテットを」新しいレジストリを作成する必要があります。
IPv4 TOS Byte and IPv6 Traffic Class Octet
IPv4のTOSバイトおよびIPv6トラフィッククラスオクテット
Description: The registrations are identical for IPv4 and IPv6.
説明：登録はIPv4とIPv6のために同じです。
Bits 0-5: see Differentiated Services Field Codepoints Registry (http://www.iana.org/assignments/dscp-registry)
ビット0-5：差別化サービスフィールドコードポイントのレジストリを参照してください（http://www.iana.org/assignments/dscp-registry）
Bits 6-7, ECN Field:
ビット6-7、ECNフィールド：
Binary Keyword References
------ ------- ----------
00 Not-ECT (Not ECN-Capable Transport) [RFC 3168]
01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168]
10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168]
11 CE (Congestion Experienced) [RFC 3168]
The codepoints for the CWR and ECE flags in the TCP header are specified by the Standards Action of this RFC, as is required by RFC 2780.
RFC 2780によって要求されるようにTCPヘッダーのCWRとECEフラグのコードポイントは、このRFCの標準アクションによって指定されます。
When this document is published as an RFC, IANA should create a new registry, "TCP Header Flags", with the namespace as follows:
この文書はRFCとして公開されると、以下のように、IANAは名前空間に、新しいレジストリ、「TCPヘッダーフラグ」を作成する必要があります。
TCP Header Flags
TCPヘッダのフラグ
The Transmission Control Protocol (TCP) included a 6-bit Reserved field defined in RFC 793, reserved for future use, in bytes 13 and 14 of the TCP header, as illustrated below. The other six Control bits are defined separately by RFC 793.
以下に示すように、伝送制御プロトコル（TCP）は、バイト13とTCPヘッダの14に、将来の使用のために予約RFC 793で定義された6ビットのReservedフィールドを含んでいました。他の6つの制御ビットは、RFC 793によって別々に定義されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | U | A | P | R | S | F |
| Header Length | Reserved | R | C | S | S | Y | I |
| | | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
RFC 3168 defines two of the six bits from the Reserved field to be used for ECN, as follows:
次のようにRFC 3168は、ECNのために使用される予約済みフィールドからの6ビットのうちの2つを定義します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | C | E | U | A | P | R | S | F |
| Header Length | Reserved | W | C | R | C | S | S | Y | I |
| | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
TCP Header Flags
TCPヘッダのフラグ
Bit Name Reference
--- ---- ---------
8 CWR (Congestion Window Reduced) [RFC 3168]
9 ECE (ECN-Echo) [RFC 3168]
IANA allocated the IPSEC Security Association Attribute value 10 for the ECN Tunnel use described in Section 9.2.1.2 above at the request of David Black in November 1999. The IANA has changed the Reference for this allocation from David Black's request to this RFC.
IANAはIANAはこのRFCにデビッド・ブラックの要求から、この割り当てのためのリファレンスを変更した1999年11月にデビッド・ブラックの要求に応じて上記セクション9.2.1.2で説明ECNトンネルの使用のためにIPSECセキュリティアソシエーション属性値10を割り当てられます。
K. K. Ramakrishnan TeraOptic Networks, Inc.
K. K.ラマクリシュナンTeraOpticネットワークス株式会社
Phone: +1 (408) 666-8650 EMail: kk@teraoptic.com
電話：+1（408）666-8650 Eメール：kk@teraoptic.com
Sally Floyd ACIRI
フェルドAsiriを祈ります
Phone: +1 (510) 666-2989 EMail: floyd@aciri.org URL: http://www.aciri.org/floyd/
電話：+1（510）666-2989 Eメール：floyd@aciri.org URL：http://www.aciri.org/floyd/
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
デビッドL.ブラックEMCコーポレーション42南セントホプキントン、MA 01748
Phone: +1 (508) 435-1000 x75140 EMail: black_david@emc.com
電話：+1（508）435-1000 x75140メール：black_david@emc.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。