[要約] RFC 3168は、IPに明示的な輻輳通知（ECN）を追加するための規格です。その目的は、ネットワークの輻輳を効果的に制御し、パフォーマンスを向上させることです。
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
IPに明示的な混雑通知（ECN）の追加
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.
Copyright（c）The Internet Society（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.
このメモは、ECN（明示的な混雑通知）のTCPおよびIPへの組み込みを指定します。これには、ECNがIPヘッダーに2つのビットを使用しています。
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のパケットドロップの使用を混雑の兆候として説明することから始めます。次に、インターネットインフラストラクチャにアクティブキュー管理（赤）を追加することで、キューがオーバーフローする前にルーターが混雑を検出するため、ルーターは混雑の兆候としてパケットドロップに限定されなくなりました。代わりに、RouterはECN対応トランスポートのパケットのIPヘッダーに経験豊富な（CE）コードポイントを設定できます。CE CodePointをルーターに設定する時期を説明し、ECN対応にするためにTCPに必要な変更を説明します。他の輸送プロトコルの変更（たとえば、信頼性の低いユニキャストまたはマルチキャスト、信頼性の高いマルチキャスト、その他の信頼できるユニキャスト輸送プロトコルなど）は、それらのプロトコルが開発され、標準プロセスを通じて前進するため、考慮することができます。また、このドキュメントでは、IPトンネル内および特にIPSECトンネル内でのECNの使用に関する問題についても説明します。
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つは、可能な限り、ここで指定されているメカニズムが段階的に展開できることです。増分展開の原則に対する課題の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.
このドキュメントは、RFC 2481を廃止し、「IPに明示的な輻輳通知（ECN）を追加する提案」であり、ECNはインターネットコミュニティの実験プロトコルとして定義しました。このドキュメントは、RFC 2474、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」を更新し、IPヘッダーのECNフィールド、RFC 2401のECNフィールドを定義し、「インターネットプロトコルのセキュリティアーキテクチャ」を変更します。TCPヘッダーの2つの新しいフラグを定義する際に、ECNおよびRFC 793「トランスミッションコントロールプロトコル」の使用と互換性があるため、トンネルモードヘッダー構造のIPv4 TOSバイトとIPv6トラフィッククラスの処理。
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、Webブラウジング、オーディオおよびビデオデータの転送などのインタラクティブなトラフィックは、パケット損失（特に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.
アクティブなキュー管理メカニズムは、NODESから雑誌を示すためにいくつかの方法のいずれかを使用する場合があります。1つは、現在行われているように、パケットドロップを使用することです。ただし、アクティブなキュー管理により、ルーターは、混雑を示すために、キューイングまたはパケットのドロップをポリシーから分離することができます。したがって、アクティブキュー管理により、ルーターはパケットドロップのみに依存するのではなく、混雑の表示として、パケットヘッダーで経験豊富な（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]に記載されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
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]を検出するために提案されており、現在インターネットに展開されているアクティブキュー管理（AQM）のメカニズムの1つです[RFC2309]。AQMは、うっ血指示のためのいくつかの代替案の1つを使用した一般的なメカニズムであることを意図していますが、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 CodePointを使用すると、受信機はパケットを受信でき、パケット損失後の再送信による過度の遅延の可能性を回避できます。「CEパケット」という用語を使用して、CE CodePointセットを備えたパケットを示します。
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.
このドキュメントは、インターネットが、ドロップするのではなくパケットをマークすることを通じて通知が時々ある場合がある、初期の混雑（赤と初期の作業[RJ90]のように）の混雑の兆候を提供することを指定しています。これは、2ビットのIPヘッダーのECNフィールドを使用して、4つのECNコードポイント「00」から「11」を作成します。ECN対応トランスポート（ECT）CodePoints '10'および '01'は、データ送信者によって設定され、輸送プロトコルのエンドポイントがECN対応であることを示します。それらをそれぞれECT（0）とECT（1）と呼びます。このドキュメントの「ECT CodePoint」というフレーズは、2つのECT CODEPOINTSのいずれかを指します。ルーターは、ECT（0）とECT（1）のコードポイントを同等のものとして処理します。送信者は、パケットごとにECTを示すためにECT（0）またはECT（1）CodePointのいずれかを無料で使用できます。
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の2つのコードポイント、ECT（0）、およびECT（1）の両方の使用は、主にデータ送信者がネットワーク要素がCEコードポイントを消去しておらず、データ受信者がトランスポートプロトコルで要求されているように、CE CodePointセットを使用してパケットの受領を送信者に適切に報告します。送信者と受信者がECT（0）とECT（1）コードポイントを区別するガイドラインは、各輸送プロトコルについて個別のドキュメントで扱われます。特に、このドキュメントでは、TCPエンドノードのメカニズムは、ECT（0）とECT（1）コードポイントを区別するためのメカニズムには対応していません。単一のECT CodePointのみを必要とするプロトコルと送信者は、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.
非接続コードポイント「00」は、ECNを使用していないパケットを示します。CE CodePoint '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 CodePoint [SCWA99]を設定すると、必然的に非CEを「消去」します。たとえば、CEコードポイントを消去したルーターは、元のノンセの再構築にさらに困難に直面するため、CEコードポイントの消去が繰り返されると、エンドノードによって検出される可能性が高くなります。また、ECN Nonceは、CEコードポイントがパケットに設定されているかどうかについて、輸送送信者に横たわっている輸送受信者を誤動作するという問題に対処できます。2つのECTコードポイントを使用する動機については、セクション20で詳細に説明し、4番目のECT CodePoint（つまり、CodePoint '01'）の代替可能性について説明します。ECT（1）CodePointを理解していない以前のECN実装との後方互換性については、セクション11で説明します。
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 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 [RFC2481]では、ECNフィールドはECN対応輸送（ECT）ビットとCEビットに分割されました。RFC 2481に設定されたECN対応輸送（ECT）ビットのみを備えたECNフィールドは、このドキュメントのECT（0）コードポイントに対応し、RFC 2481のECTとCEビットの両方のECNフィールドは、CEコードポイントのCEコードポイントに対応しています。このドキュメント。「01」コードポイントはRFC 2481で未定義のままでした。これが、単一のECT CodePointのみが必要な場合にECT（0）の使用を推奨する理由です。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint ECN: Explicit Congestion Notification
DSCP：差別化されたサービスCodePoint 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のトラフィッククラスOctetに対応し、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の場合、パケットドロップまたはECN表示のいずれかを含むデータのウィンドウに対して、うっ血ウィンドウを半分にするためにソースTCPが必要です。
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パケットに対する混雑制御応答が、ドロップされたパケットへの応答と本質的に同じであることを要求する理由の1つは、エンドシステムとルーターの両方でECNの増分展開に対応することです。一部のルーターは、ECN対応のパケットをドロップする場合があります（たとえば、輻輳検出に同じAQMポリシーを使用して）、他のルーターは同等のレベルの混雑のためにCEコードポイントを設定します。同様に、ルーターは非ECN対応パケットをドロップする可能性がありますが、同等のレベルの混雑のために、CE CodePointをECN対応パケットに設定する場合があります。パケットドロップよりも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.
追加の目標は、往復時間内に複数回の輻輳の適応症に複数回反応することを避けるために、最終システムがデータのウィンドウごとに最大1回（つまり、往復時間ごとに最大1回）反応する必要があることです。
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コードポイントは、ルーターがエンドノードへの輻輳の兆候としてパケットを削除した場合にのみ設定する必要があります。ルーターのバッファーがまだ満たされておらず、ルーターがパケットをドロップして初期輻輳のエンドノードを通知するために準備されている場合、ルーターは最初にそのパケットのIPヘッダーにECT CodePointが設定されているかどうかを確認する必要があります。もしそうなら、パケットをドロップする代わりに、ルーターは代わりにCEコードポイントをIPヘッダーに設定することができます。
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 CodePointセットがあるパケット）がルーターによって受信されると、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 Edgeノードは、特定のクラスの特定のクラスのドロップするように構成されます。それらが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]で提案されている赤いアルゴリズムを使用して、平均キューサイズで示されるように、ルーターが初期の混雑に応じてCEコードポイントを設定することを期待しています。私たちの知る限り、これは、バッファがオーバーフローする前に、ルーターがパケットを積極的にドロップするためのIETFで現在議論中の唯一の提案です。ただし、このドキュメントでは、アクティブキュー管理のための特定のメカニズムを指定しようとするものではなく、必要に応じてIETFの他の領域にその努力を残します。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 CodePointセットを使用した *単一 *パケットは、パケットドロップのように、渋滞制御の観点から、輸送層が応答することを強調します。瞬間的なキューサイズは、ルーターが永続的な混雑を経験していない場合でも、かなりの変動を見る可能性があります。そのため、ルーターでの一時的な混雑は、輸送層での反応をトリガーしないで、キューの容量よりもはるかに小さいしきい値に達する瞬間キューサイズに到達することに反映されることが重要です。したがって、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 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.
ECNを活用するために、レイヤー2（たとえば、ATMスイッチまたはフレームリレースイッチ）の技術の実験を奨励し続けます。たとえば、赤（パケットマーキングがしきい値を超える平均キューの長さに基づいている場合）などのスキームを使用すると、レイヤー2デバイスは、混雑の合理的に信頼できる兆候を提供する可能性があります。パスセットのすべてのレイヤー2デバイスが、レイヤー自身の混雑を経験した場合（たとえば、ATMのEFCIビット、フレームリレーのFECNビット）、この信頼できる方法で、レイヤー2ネットワークへのインターフェイスルーターが状態をコピーできる場合そのレイヤーのうち、2つの混雑は、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 CodePointの輻輳指示の信頼できる配信を確保するには、ネットワーク内のパケットの損失が終了ノードによって検出され、輻輳の兆候として解釈されない限り、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 CodePointセットがある場合、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 CodePointを設定します。ただし、この再組み立てに寄与する他のフラグメントのいずれかが非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）、および/または非eCTコードポイントの混合物を運ぶ可能性があります。上記の再組み立て仕様は、この場合のフラグメントの再組み立てに関する要件を掲載していません。より正確な再組み立て挙動が必要な状況では、プロトコル仕様では、プロトコルによって送信されるすべてのECN対応パケットでDFを設定する必要があることを指定する必要があります。
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フィールドによって与えられた機能に加えて、トランスポートプロトコルからのサポートが必要です。トランスポートプロトコルは、セットアップ中のエンドポイント間の交渉が必要になる場合があり、すべてのエンドポイントがECN対応であることを判断して、送信者が送信パケットにECT CodePointを設定できるようにします。第二に、トランスポートプロトコルは、CEパケットの受領に適切に対応できる必要があります。この反応は、受信したCEパケット（TCPなどの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.
このドキュメントは、TCPへのECN機能の追加のみに対処し、他の輸送プロトコルにECNの問題をさらすために残します。TCPの場合、ECNには3つの新しい機能が必要です。接続セットアップ中のエンドポイント間のネゴシエーションは、両方ともECN対応かを判断します。TCPヘッダーにECN-ECHO（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ヘッダーの予約済みフィールドに2つの新しいフラグを指定します。ECNキャピールを交渉するためのTCPメカニズムは、TCPヘッダーのECNエコー（ECE）フラグを使用します。TCPヘッダーの予約フィールドのビット9は、ECNエコーフラグとして指定されています。TCPヘッダーの6ビット予約フィールドの位置は、RFC 793 [RFC793]の図4に示されています（完全性のために以下に再現されています）。ECNフィールドのこの仕様は、ビット4〜7を使用して4ビットフィールドとして予約フィールドを残します。
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.
TCPレシーバーがECNエコーフラグの設定を停止するタイミングを決定できるようにするために、TCPヘッダーであるCWRフラグに2番目の新しいフラグを導入します。CWRフラグは、TCPヘッダーの予約済みフィールドのビット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：TCPヘッダーのバイト13および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：TCPヘッダーのバイト13および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は、ルーターと接続エンドポイント間のシグナル伝達にIPヘッダーのECTフラグとCEフラグ（図1を参照）を使用し、TCPのTCPヘッダー（図4を参照）のECN-ECHOおよびCWRフラグを使用します。-TCPエンドポイントシグナル伝達へのエンドポイント。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 CodePointは、送信者によって送信されたパケットに設定され、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対応のルーターは、差し迫った混雑を検出し、DOPETのECT CodePointがドロップしようとしているパケットに設定されていることを検出します。パケットをドロップする代わりに、ルーターは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 CodePointセットでパケットを受信し、送信者に送信される次のTCP ACKにECN-ECHOフラグを設定します。
* 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.
* 送信者は、受信者に送信された次のパケットのTCPヘッダーにCWRフラグを設定し、ECNエコーフラグの受領と反応を確認します。
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を使用するための交渉とECNエコーおよびCWRフラグの使用については、以下のセクションで詳しく説明します。
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接続セットアップフェーズでは、ソースと宛先TCPSがECNを使用する意欲について情報を交換します。このネゴシエーションが完了した後、TCP送信者はデータパケットのIPヘッダーにECT CODEPOINTを設定して、このパケットのECNに輸送が能力があり、ECNに参加することをいとわないことをネットワークに示します。これは、混雑通知の方法としてそれを使用したい場合、CEコードポイントでこのパケットをマークする可能性があることをルーターに示します。TCP接続が特定のパケットにECN通知を使用したくない場合、送信TCPは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として指定します。ECEとのsynパケットを「ECN-Setup synパケット」を設定し、少なくともsynパケットを呼び出します。ECEおよびCWRフラグの1つは、「非ECNセットアップSynパケット」を設定していません。同様に、ECEフラグセットのみを備えたsyn-ackパケットを呼び出しますが、CWRフラグは「ECN-Setup syn-ackパケット」を設定していません。「非ECN-Setup 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を使用する前に、Host AがECNセットアップSynパケットを送信し、Host BはECNセットアップSyn-ackパケットを送信します。Synパケットの場合、ECNセットアップSynパケットにおけるECEとCWRの両方の設定は、送信TCPが輻輳や輻輳に対する反応の兆候としてではなく、ECN対応であることを示すこととして定義されます。より正確には、ECNセットアップSynパケットは、Synパケットを送信するTCP実装が送信者と受信機の両方としてECNに参加することを示しています。具体的には、レシーバーとして、ECEを発信TCP確認（ACK）パケットに設定することにより、CE CodePointがIPヘッダーに設定された着信データパケットに応答します。送信者として、混雑ウィンドウを減らしてCWRを必要に応じて設定することにより、ECEが設定された着信パケットに応答します。ECNセットアップSynパケットは、TCP送信者に、送信される可能性のあるパケットのいずれかまたはすべてのパケットにECT CodePointを設定するようにコミットしません。ただし、CE CodePointセットを使用して着信パケットに適切に対応するというコミットメントは、この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-Setup syn-ackパケットを送信すると、CWRフラグはECEフラグではなく設定します。ECNセットアップSyn-ackパケットは、Syn-ackパケットを送信するTCPがECN対応であることを示すこととして定義されます。Synパケットと同様に、ECNセットアップSyn-ackパケットは、TCPホストに送信されたパケットにECT CodePointを設定することではありません。
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接続内のECNセットアップパケットの送信に適用されます。TCP接続は、TCP接続の確立と終了の標準ルールによって定義されます。
* 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-Setup 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.
* ホストは、少なくとも1つのECNセットアップSynまたはECNセットアップSyn-ackパケットを送信し、少なくとも1つのECNセットアップSynまたはECNセットアップSyn-ackパケットを受け取っていない限り、データパケットにECTを設定してはなりません。非ECN-Setup 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 CodePointを設定した場合、そのホストは、接続内の後続のすべてのパケットで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.
* ホストが少なくとも1つのECNセットアップSynまたはECNセットアップSyn-ackパケットを送信し、非ECNセットアップSynまたは非ECNセットアップSyn-ackパケットを受け取っていない場合、そのホストがTCPデータパケットを受信した場合IPヘッダーにECTおよびCEコードポイントが設定されている場合、そのホストはECN対応接続用に指定されているようにこれらのパケットを処理する必要があります。
* 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を受け取った後に時間型の状態に入り、タイムアウト後に閉じた状態に移行します。多くのTCP実装は、時間待合状態でウィンドウsynパケットを受け取った場合、新しいTCP接続を作成します。TCPホストがタイムウェイトまたはクローズド状態に入ると、その接続の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は、初期化のためにTCPヘッダー（図3を参照）にECN-ECHOおよびCWRフラグの使用を導入します。このようなパケット（これらのビットセットを使用）がポートの署名であると信じて、ECNセットアップSynパケットをドロップするか、RSTで応答するか、RESTをドロップするか、インターネットに誤ったファイアウォール、ロードバランサー、侵入検知システムが存在します。-Serial-of-Serial-of-Serial Attackで使用できるスキャンツール。問題のある機器の一部が特定されており、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とその後のSynの再送信をCWRとECEを除去することができます。元のSynが失われる通常のパケット損失を克服するために、発信元のホストは、CWRおよびECEビットをgivingめて再送信する前に、1つまたは複数のECNセットアップ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-Setup 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ビットを設定することはできないことに注意してください。さらに、セクション6.1.1のECNセットアップと使用に関するルールの重要な結果は、HostがECTデータパケットの受信を他のホストがECN対応であるという暗黙の信号として使用することを禁じられていることです。
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パケットのTCPヘッダーの予約済みフィールドにSynセットの2つのECN関連フラグをSynセットに送信することを選択した理由の問題がありますが、Syn-ackを送信する応答TCPはECN関連フラグのみをセットします。syn-ackパケット。この非対称性は、展開されたTCP実装を使用したECNキャピールの堅牢な交渉に必要です。少なくとも1つの故障したTCP実装が存在します。これにより、TCP受信機は、受信したデータパケットのTCPヘッダーの予約フィールドを反映するために、単にACKパケット（したがってSyn-ack）にTCPヘッダーの予約フィールドを設定します。TCP synパケットはECNエコーとCWRフラグを設定してECNの能力を示しているため、Syn-ackパケットはECNエコーフラグのみを設定します。受信機がECN対応ではないことを示しています。送信TCPは、障害のあるTCP実装によって誤解を招くことはありません。これは、着信Synパケットの予約済みフィールドを単純に反映するSyn-ackパケットを送信します。
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接続の場合、新しいデータパケットはIPヘッダーにECT CodePointセットで送信されます。TCP接続で送信されたすべてのパケットに対して送信者が必要なECT CodePointのみが1つだけである場合、ECT（0）を使用する必要があります。送信者がECNエコー（ECE）ACKパケット（つまり、TCPヘッダーに設定されたECNエコーフラグを備えた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パケットに応じて1回だけ削減する必要があります。さらに、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パケットに応じて輻輳ウィンドウを減らすと、到着し続ける承認は、緩和ウィンドウで許可されているように、発信パケットを「クロックアウト」することができます。輻輳ウィンドウが1つのMSS（最大セグメントサイズ）のみで構成され、送信TCPがECNエコーACKパケットを受信している場合、送信TCPは原則として輻輳ウィンドウを半分に減らす必要があります。ただし、輻輳ウィンドウの値は、1つのMSSの値によって下に制限されます。送信TCPが1ミリ秒のうっ血ウィンドウを使用して送信を続ける場合、これにより、往復時間ごとに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 Flagセットで別の新しいデータパケットを送信する必要があるという事実に起因します。したがって、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ビットを設定する準備ができたら、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]は、NSシミュレーターの検証テストについて説明します。これは、幅広いECNシナリオを示しています。これらのシナリオには、次のものが含まれます。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は、ECN-ECHOビットセット[RFC2581]なしで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-ECHOフラグを設定します。TCPレシーバーが2つの到着データパケットのACKを送信できる現在の「遅延ack」TCP実装のように、ACK源泉徴収が実装されている場合、ACKパケットのECNエコーフラグは「1」に設定されます。CE CodePointは、確認されているデータパケットのいずれかに設定されています。つまり、受信したデータパケットのいずれかが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レシーバーは、TCP送信者から受信したCWRフラグを使用して、ECN-Echoフラグの設定を停止するタイミングを決定します。
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-ECHOビットセットでACKパケットを送信した後、TCPレシーバーは、送信するすべてのACKパケット（CEデータパケットまたは非CEデータパケットを認めているかどうか）にECN-Echoフラグを設定し続けています。CWRパケット（CWRフラグセットのパケット）を受信します。CWRパケットを受け取った後、後続の非CEデータパケットの謝辞にはECNエコーフラグがセットされていません。別のCEパケットがデータレシーバーによって受信された場合、受信機は再びECN-ECHOフラグセットでACKパケットを送信します。CWRパケットの受領は、データ送信者がECNエコーメッセージを受信したことを保証するものではありませんが、これは、データのコードポイントが設定されたデータパケットを送信した後、ある時点でデータ送信者が渋滞ウィンドウを減らしたことを示唆しています。。
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送信者が輻輳ウィンドウを1回以上削減する必要がないことをすでに指定しています。データのウィンドウにドロップされたパケットと（マーク付き）CEパケットの両方が含まれる場合、TCP送信者が輻輳ウィンドウの不必要な削減を避けるためにある場合、ある程度の注意が必要です。これは[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輻輳制御アルゴリズムの場合、純粋な確認パケット（例：添付データを含まないパケット）は、非codePointで送信する必要があります。現在のTCPレシーバーには、輻輳通知に応じてACKパスのトラフィックを減らすためのメカニズムはありません。ACKパスの混雑に対応するためのメカニズムは、現在および将来の研究の領域です。（1つの簡単な可能性は、送信者がCE CodePointセットで純粋な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実装を指定して、再送信データパケットのIPヘッダーにECT CodePoint（ECT（0）またはECT（1））を設定してはなりません。受信機の現在のウィンドウの外側にあります。これは、サービス拒否攻撃に対するセキュリティの向上と、ネットワークの後半にドロップされたパケットによる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 CodePointを設定する場合、その後ネットワークで不必要に再送信されたパケットが後でドロップされた場合、エンドノードはルーターからの輻輳の兆候をCEを設定することを決して受け取らないことに注意してください。CodePoint。したがって、再送信されたデータパケットにECT CodePointを設定することは、後でネットワークでドロップされたパケットの場合でも、渋滞表示の堅牢な配信と一致しません。
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.
さらに、TCP送信者のIPソースアドレスをスプーフィングできる攻撃者は、CE CodePointがIPヘッダーに設定された任意のシーケンス番号を持つデータパケットを送信できます。このスプーフィングされたデータパケットを受信すると、TCPデータ受信機は、データが現在の受信ウィンドウにあることはないと判断し、重複した確認を返します。TCPデータレシーバーのウィンドウ外パケットを、受信機の現在のウィンドウの外側にあるデータパケットとして定義します。ウィンドウ外のパケットを受信すると、TCPデータレシーバーは、パケットヘッダーのCEコードポイントを輻輳の有効な表示として扱うかどうかを決定する必要があります。。TCPデータレシーバーがウィンドウ外パケットのCEコードポイントを無視した場合、TCPデータ送信者はネットワークからのこの可能性のある輻輳の兆候を受け取らず、エンドツーエンドの輻輳制御に違反します。一方、TCPデータレシーバーがウィンドウ外パケットのCEの表示を尊重し、TCPデータ送信者への輻輳の表示を報告する場合、スプーフィングされたウィンドウのパケットを作成した悪意のあるノードデータ送信者に不必要に（半分）その混雑ウィンドウを強制することにより、TCP接続を「攻撃」しました。このようなサービス拒否攻撃を防ぐために、正当なTCPデータ送信者が再送信されたデータパケットにECT CodePointを設定してはならず、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 CodePointセットがあり、後でデータレシーバーがウィンドウ外パケットとして無視された場合でも、これは問題ではありません。、送信者は、そのデータウィンドウの輻輳の兆候にすでに対応しているためです。
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 CodePointがネットワーク内のパケットに設定されている場合、これは輻輳の有効な表示としてデータ受信機によって扱われます。
6.1.6. TCP Window Probes.
6.1.6. TCPウィンドウプローブ。
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 CodePointまたはWindowプローブパケットの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.
ただし、Windowプローブは正確なシーケンス番号を使用するため、サービス拒否攻撃で簡単にスプーフィングすることはできません。したがって、WindowプローブがCE CodePointセットで到着すると、受信機は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.
このセクションでは、ECNの非準拠エンドノードに対する脆弱性に関する懸念について説明します（つまり、送信されたパケットにECT CodePointを設定するが、受信CEパケットに応答しないENDノード）について説明します。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パケットの到着に注意することもできます。
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.
このセクションでは、Routerが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フィールドのビットを改ざんすることにより、敵（または壊れたルーター）が次の1つ以上を実行できます。誤って混雑を報告し、個々のパケットの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キャピールを誤って報告したり、誤って報告したりする最初の2つの変更は、ルーターが単にパケットをドロップする場合よりも悪いことではありません。輻輳制御の観点から、非準拠のルーターによる混雑がない場合に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-CodePoint）。セクション19では、ECNベースの混雑制御を破壊した結果は潜在的な不公平につながる可能性があることを観察しますが、これは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つの代替ソリューションを指定します。この議論は、差別化されたサービスとさまざまな形式の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.
セキュリティの観点から、IPトンネルの外側ヘッダーでのECNの使用は、敵がトンネルエンドポイントを越えて伝播するECN情報を改ざんする可能性があるため、セキュリティ上の懸念を引き起こす可能性があります。これらの懸念のセクション18および19の分析と結果としてのリスクに基づいて、私たちの全体的なアプローチは、ECNのサポートをIPトンネルのオプションにすることであり、IPトンネルをECNを使用するか、使用しないように指定または構成できるようにすることです。トンネルの外側ヘッダーの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.
IPトンネルでのECNカプセル化の限られた機能オプションは、内側（カプセル化）ヘッダーのECNフィールドの値に関係なく、外部（カプセル化）ヘッダーに非接続コードポイントが設定されるためです。このオプションでは、内側のヘッダーのECNフィールドは、脱カプセル化時に変更されません。このアプローチの欠点は、カプセル化されたパケット（元のTCP送信者から）がECN対応であっても、FlowがIPトンネリングを使用しているパスのその部分に対してECNサポートを持っていないことです。つまり、カプセル化されたパケットがECN対応の混雑したルーターに到着し、ルーターがパケットをエンドノードへの輻輳の兆候としてドロップまたはマークすることを決定できる場合、ルーターはCE CodePointを設定することは許可されません。パケットヘッダーでは、代わりにパケットをドロップする必要があります。
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カプセル化のフル機能性オプションは、内部ヘッダーがnot-ectまたはectである場合、内側ヘッダーのECNコードポイントをカプセル化の外側ヘッダーにコピーし、外側ヘッダーのECNコードポイントをECT（0）に設定することです。内部ヘッダーのECNコードポイントがCEの場合。脱カプセル化では、CEコードポイントが外側のヘッダーに設定されている場合、CE CodePointも内側のヘッダーに設定されます。それ以外の場合、内側のヘッダーのECNコードポイントは変更されていません。つまり、完全なECNサポートの場合、カプセル化と脱カプセル化処理には以下が含まれます。TunnelIngressでは、フル機能性オプションは外側ヘッダーのECNコードポイントを設定します。内側のヘッダーのECNコードポイントがそれほど効果的ではない場合、それは外側ヘッダーの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.
フル機能オプションを使用すると、Flowは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トンネルは、IPトンネルのエンドポイントが、トンネル内のECNの限られた機能性とフル機能性オプションの選択を交渉できるようにする場合があります。
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コードポイントがあるパケットは、限られた機能オプションを使用するトンネル、またはフル機能性オプションを使用するトンネルの場合、これは、not-ect-codepointが内側のヘッダーに設定されています。これは、逆方向の互換性によって動機付けられ、ECNフィールドの不正な変更が行われないようにし、次のセクション（9.1.2）でさらに説明します。
9.1.2. Changes to the ECN Field within an IP Tunnel.
9.1.2. IPトンネル内のECNフィールドに変更します。
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フィールドのコピーが存在することは、外側ヘッダーの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トンネルがフル機能性オプションを使用する場合、内側のヘッダーにも設定されている場合にのみ、外部ヘッダーに非接続コードポイントを設定する必要があります。
* If the tunnel uses the limited-functionality option, then the not-ECT codepoint should be set in the outer header.
* トンネルが限られた機能オプションを使用している場合、非接続コードポイントを外側のヘッダーに設定する必要があります。
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コードポイントはトンネルイングレスポイントの外側ヘッダーに設定されます。トンネル内の混雑により、外側ヘッダーにECN対応ルーターがCEを設定する可能性があります。トンネルは、フル機能性オプションをサポートするように明示的に構成されていないため、トンネル出力ポイントは、非ectコードポイントが外側ヘッダーに設定されることを期待しています。ECNで利用可能なトンネル出力ポイントが、外側のヘッダーにECTまたはCEコードポイントを備えたパケットを受け取った場合、フル機能性オプションをサポートするように構成されていないトンネルで、CEDEPOINTに従ってパケットを処理する必要があります。次のように設定されました。フル機能オプションをサポートするように構成されていないトンネルでは、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トンネルは、ECNコードポイントをCEからECTに変更することに基づいて、うっ血の兆候に対する保護を提供することはできません。鬱血指示の消去は、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" 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].
IPSECは、中間ルーターなどの潜在的に不安定なネットワークコンポーネントを介した安全な通信をサポートしています。IPSECプロトコルは、幅広いセキュリティ要件とオペレーティング環境にまたがる2つの動作モード、トランスポートモードとトンネルモードをサポートしています。トランスポートモードのセキュリティプロトコルヘッダーは、IP（IPv4またはIPv6）ヘッダーと高レイヤープロトコルヘッダー（TCPなど）の間に挿入されるため、接続のエンドツーエンドセキュリティにはトランスポートモードのみが使用できます。IPSECトンネルモードは、元の、または「内部」IPヘッダーとその関連パケットをカプセル化する新しい「外側」IPヘッダーの追加に基づいています。トンネルモードのセキュリティヘッダーは、これら2つのIPヘッダーの間に挿入されます。トランスポートモードとは対照的に、新しい「外側」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プロトコルは、トンネル出口ノードでのIPSEC脱カプセル化処理によって内部ヘッダーのECNフィールドを変更しないことを要求しました。これは、ECNのフル機能モードの可能性を排除していたでしょう。同時に、これにより、ECNフィールドへの敵の変更を使用して、IPSECトンネルエンドポイント全体で盗難またはサービス拒否攻撃を開始できないことが保証されます。このような変更はトンネルエンドポイントで廃棄されるためです。
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トンネルの外側ヘッダーでECN機能を使用する許可が、対応するIPSECセキュリティ協会（SA）の構成可能な部分であるため、リスクが利点を上回ると判断される状況で無効にすることができます。その結果、IPSECセキュリティ管理者には、IPSECトンネル内のECN対応接続の動作に関する2つの代替案が表示されます。
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.
[ESP、AH]で定義されているIPSECプロトコルには、暗号化計算のいずれにもIPヘッダーのECNフィールドが含まれていません（トンネルモードの場合、外部IPヘッダーのECNフィールドは含まれていません）。したがって、ネットワークノードによるECNフィールドの変更は、IPSECのエンドツーエンドセキュリティに影響を与えません。これは、IPSECの整合性チェックを失敗させることができないためです。結果として、IPSECは、敵の修正もIPSECのエンドツーエンドのセキュリティに影響を与えないため、敵のECNフィールドの修正（つまり、中間攻撃）に対する敵の修正に対する防御を提供しません。一部の環境では、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.
* オプションのセキュリティ協会データベース（SAD）フィールドトンネルのカプセル化と脱カプセル化処理により、外部IPヘッダーでのECNの使用が許可または禁止されています。
* 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つのエンドポイント間のこの悲しいフィールドの交渉を可能にするオプションのセキュリティ協会属性。
* 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コードポイントは、そのような接続からのECN対応接続と輻輳通知（CEコードポイントで示される）の外側ヘッダーに設定されます。
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使用の交渉は、悲しい分野をサポートする実装であっても、すべての場合においてオプションです。カプセル化および脱カプセル化処理の変更が必要ですが、ECNの使用が常に禁止されていると仮定することにより、他の2つの変更なしで実装される場合があります。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機能は、新しいフィールドをSADに追加します（[RFC2401]を参照）：
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管理インターフェイス（現在[RFC2401]のセクション4.4.1で説明されています）でカバーする必要があります。。
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トンネルと交渉する外部IPヘッダーに基づくECN輻輳通知のサポートを有効にするために定義されています（[RFC2407]を参照）。この属性はオプションですが、それをサポートする実装は、セクション9.2.1.1で定義されている悲しいフィールドをサポートする必要があります。
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を参照）。クラスの値は、交渉を実施するために使用されます。[RFC2407、RFC2408、RFC2409]を参照してください。このSA属性を交渉するためのエンコード形式や要件を含む詳細については、参照してください。
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
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の悲しいエントリのECNトンネルフィールドの値が「許可」され、内側のヘッダーのECNフィールドがCE以外の任意の値に設定されている場合は、このECNフィールドを外側ヘッダーにコピーします。内側のヘッダーのECNフィールドがCEに設定されている場合、外側ヘッダーのECNフィールドをECT（0）に設定します。
(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フィールドがに設定されている場合CE、次に、ECNフィールドを外側ヘッダーから内側ヘッダーにコピーします。それ以外の場合は、内側ヘッダーのECNフィールドに変更を加えません。
(5) and (6) are identical to match usage in [RFC2401], although they are different in [RFC2401].
(5) （6）は[RFC2401]の使用法と一致するのと同じですが、[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トンネルフィールドをサポートする実装に適用されます。このような実装は、[RFC2401]で定義されているIPv4 TOSオクテットと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フィールドを外側のヘッダーで非表示に設定します。（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.
逆方向の互換性の場合、外側ヘッダーにCE CodePointセットを備えたパケットは、限られた機能オプションを使用しているSAに到着する場合、または非機能性オプションを使用している場合は、削除する必要があります。内側のヘッダー。
9.2.2. Changes to the ECN Field within an IPsec Tunnel.
9.2.2. IPSECトンネル内の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.
IPSECトンネル内でECNフィールドが不適切に変更され、この変更がトンネルエッセージで検出された場合、SAの適切な条件を満たさないパケットの受領は監査可能なイベントです。実装は、誤ったパケットごとに監査レコードを作成するのではなく、ある期間にわたって誤ったパケットの1回のカウントを含む監査レコードを作成する場合があります。このような監査記録には、少なくとも1つの誤ったパケットのヘッダーを含める必要がありますが、エントリで表されるすべてのパケットのヘッダーを含める必要はありません。
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ワーキンググループによるレビュー中に、このドキュメントの2つの領域について実質的なコメントを受け取りました。このセクションでは、これらのコメントについて説明し、提案された変更が組み込まれていない理由について説明します。
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トンネルのECN使用を禁止することです。これは望ましい結果ではありません。
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.
2番目の領域では、数人のレビュアーがSAの交渉が複雑であり、それを追加することは自明ではないと指摘しました。あるレビュアーは、トンネルのセットアップ後にICMPを使用することを可能な代替手段として使用することを提案しました。このドキュメントのSA交渉への追加はオプションであり、そのままです。実装者は自由に無視できます。著者は、それが提供する保証は多くの状況で有用であると考えています。実際には、これが実装されていない場合、標準プロセスのその後の段階で削除できます。ICMPを拡張してトンネルのセットアップ後にECNをネゴシエートすることは、SA属性のネゴシエーションを拡張するよりも複雑です。一部のトンネルでは、トラフィックにトンネル出力エンドポイントに対処することを許可していないため、ICMPパケットは他のどこかにアドレス指定し、出口エンドポイントによってスキャンされ、そこにまたは実際の目的地で廃棄する必要があります。さらに、ICMPの配信は信頼できないため、ICMPパケットがドロップされ、さらに別のACK/再送信メカニズムの発明が伴う可能性があります。既存のSA交渉メカニズムのオプションの拡張機能を指定する方が良いようです。
9.3. IP packets encapsulated in non-IP Packet Headers.
9.3. IPパケットが非IPパケットヘッダーにカプセル化されています。
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をトンネル内で使用できないということです。以前の研究では、ECNをMPLSに組み込むための予備的な提案を検討し、ECNをGRE、L2TP、またはPPTPに組み込むための提案は、必要に応じて考慮されます。
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.
1つの可能性は、監視およびポリシングデバイス（またはより非公式に、「ペナルティボックス」）がネットワークにインストールされ、最高のエフォルトフローが輻輳に適切に応答しているかどうか、および適切な使用がないと判断されたフローから優先的にドロップするかどうかを監視することです。エンドツーエンドの混雑制御手順。
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 CodePointセットを持っているフローのために到着するパケットをドロップすることが含まれます。このようにして、その流れのルーターが見た渋滞の兆候は、パスの他の場所に悪意のあるまたは壊れたルーターが存在する場合でも、エンドノードによっても見られることが保証されます。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が利用できる赤いキューがマークからパケットのドロップに切り替わると、監視およびポリシングデバイスがない場合でも、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]は、ECNをTCP/IPアーキテクチャに追加することの利点と欠点を考慮します。シミュレーションベースの比較に示されているように、ECNの利点の1つは、短いまたは遅延に敏感なTCP接続の不必要なパケットドロップを回避することです。ECNの2番目の利点は、TCPで不必要な再送信タイムアウトを回避することです。このペーパーでは、ECNのTCPの混雑制御メカニズムへの統合について詳しく説明します。論文で議論されているECNの欠点は、非準拠TCP接続がECN対応として誤って宣伝できる可能性があり、ECNエコーメッセージを運ぶTCP ACKパケット自体がネットワークでドロップできることです。これら2つの問題の最初の問題は、このドキュメントの付録で説明されており、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は双方向のトラフィック（両方向に輻輳があり、複数の混雑したゲートウェイ）で堅牢です。多くの短いWeb転送を使用した実験では、短い接続のほとんどはECNの有無にかかわらず類似した転送時間を持っているが、短い接続のわずかな割合では、ECN実験と比較して非ECN実験で非常に長い転送時間があることを示しています。
11.2. A Discussion of the ECN nonce.
11.2. ECN Nonceの議論。
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 CodePointを消去していないことを確認し、データ受信機が必要に応じてCECodePointセットを使用してPacketの受信を送信者に適切に報告していることを確認したいという要望です。トランスポートプロトコル。このセクションでは、RFC 2481に準拠したルーターのIP ECN実装との後方互換性の問題について説明します。このコードポイントのみが定義されています。ECT（1）CodePointを理解するECN実装の増分展開が重大な運用上の問題を引き起こすとは考えていません。これは、ECT（1）CodePointの展開がエンドノードで使用される前に、ECT（1）CodePointの展開がルーターから始まる場合に特に当てはまる可能性があります。
11.2.1. The Incremental Deployment of ECT(1) in Routers.
11.2.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）CodePointを理解していないルーターにECNの実装が既にあります。ECT（1）CodePointの使用がTCPまたは他の輸送プロトコルに対して標準化されている場合、これはデータ送信者がECT（1）CodePointを使用しているが、このコードポイントはパス上の混雑したルーターによって理解されないことを意味する可能性があります。。
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).
トランスポートプロトコルで許可されている場合、データ送信者はECT（1）をまったく使用せず、CodePoint ECT（0）ですべてのECN対応パケットを送信するために無料になります。ただし、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つのビットを指定しました。非接続コードポイントは、トランスポートプロトコルがCEコードポイントを無視することを示しています。これは、ECN CodePointのデフォルト値です。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 CodePointを設定して、終了ノードへの輻輳を示すように設定します。パケットヘッダーの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には、ECNの3つの変更、セットアップフェーズ、およびTCPヘッダーの2つの新しいフラグが必要です。ECN-Echoフラグは、データ受信者がデータ送信者に受信したCEパケットを通知するために使用されます。Data Senderが縮小した輻輳ウィンドウ（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トンネル内で生成されたうっ血指示は、トンネルの出口で失われないことが必要です。IPプロトコルのカプセル化および脱カプセル化中のECNフィールドの取り扱いに軽微な変更を指定し、IPトンネリングを受けるECNを使用するフローを可能にしました。
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) IPトンネル内でECNを使用しない限られた機能オプションは、外側ヘッダーのECNフィールドを非それに設定し、脱カプセル化時に内側のヘッダーを変更しません。
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フィールドに応じて、外側ヘッダーのECNフィールドを外部ヘッダーのECNコードポイントのいずれかに設定するフル機能オプション。脱カプセル化では、CEコードポイントが外側ヘッダーに設定され、内側のヘッダーがECTコードポイントの1つに設定されている場合、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トンネルの場合、このドキュメントでは、IPSECトンネル内のECN使用の交渉を可能にするオプションのIPSECセキュリティ協会（SA）属性と、SAのトンネルモードでECNが許可されているかどうかを示すセキュリティ協会データベース内のオプションのフィールドも定義します。ECN使用に必要なIPSECトンネルに必要な変更は、RFC 2401 [RFC2401]を変更し、IPSECアーキテクチャを定義し、その実装のいくつかの側面を指定します。新しい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.
このドキュメントは、RFC 2481を廃止し、「IPに明示的な輻輳通知（ECN）を追加する提案」であり、ECNはインターネットコミュニティの実験プロトコルとして定義しました。このセクションの残りの部分では、このドキュメントとその前任者との関係について説明します。
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の使用に関する簡単な議論が含まれており、その時点（1999年1月）のIPSEC仕様では、IPSecトンネルを横断する場合、フローはECNを安全に使用できないことに注意してください。RFC 2481は、IPSECトンネル仕様に加えてECNと互換性のある変更を加えることができる変更についても説明しました。
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.
このドキュメントには、RFC 2481の後に行われた作業も組み込まれています。最初に、IPSECトンネルの変更を詳細に説明し、ECNのセキュリティへの影響について広く議論することでした（現在はこのドキュメントのセクション18および19として含まれています）。2番目は、すべてのIPトンネルを含めるためにIPSECトンネルの議論を拡張することでした。古いIPトンネルはFlowのECNの使用と互換性がないため、インターネットでのECNの展開は、限られた機能性またはフル機能性を使用して、古いIPトンネルがECN互換バージョンに更新されるように強い圧力をかけます。オプション。
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番目の新しい作業は、再送信されたデータパケットを使用したECN手順を説明することでした。これは、ECT CodePointを再送信データパケットに設定しないでください。この追加仕様の動機は、既存のTCP接続に対するサービス拒否攻撃の可能性のある道を排除することです。ECN対応TCPの事前の展開には、再送信パケットにECT CodePointを設定しない（新しい）要件に準拠していない場合があります。これが実際に重大な問題を引き起こすとは考えていません。
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 Nonceの実装の一部としてTCPが使用できるECT（1）CodePointの仕様も含まれています。
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を実装するための現在の取り組みを考えると、これはパケットドロップのみに依存しない混雑回避メカニズムを展開するのに適切な時期だと考えています。通常の輻輳通知メカニズムとしてのパケットの損失に応じて、単一のパケットの遅延と損失（例：リアルタイムトラフィック、短いWeb転送）に敏感なアプリケーションと輸送の展開が増加すると、（または少なくとも、少なくとも、少なくとも、非最適）。
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.
多くの人々がこの作業とこの文書に貢献してきました。多くの人々は、この文書で直接認められていないことを含めています。さらに、ECNキャピールを交渉するためのTCPメカニズムの提案についてケンジロチョーに感謝したいと思います。ケビンは、CWRビットの提案にfall落します。ECN Issues、およびSteve Bellovin、Jim Bound、Brian Carpenter、Paul Ferguson、Stephen Kent、Greg Minshall、およびVern Paxsonのセキュリティ問題の議論について。また、これらの問題について継続的に議論してくれたインターネットエンドツーエンドの研究グループにも感謝します。
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.
Dax Kelson、Alexey Kuznetsov、Jamal Hadi-Salim、Venkat Venkatsubraを含む多くの人々とのメールディスカッションは、ECEとCWRを使用してTCP Synパケットに応答しないインターネットで提起された問題に対処しています。フラグが設定されています。Mark Handley、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トンネルに関するフィードバックについて、バングラデシュのダッカのTabassum Bint Haqueに感謝します。Derrell PiperとKero Tivinenに、ECN Tunnel SA属性の交渉の使いやすさを改善するRFC 2407への変更を提案してくれたことに感謝します。
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.
David Wetherall、David Ely、およびNeil Springに、ECN Nonceの提案に感謝します。また、この問題に関する議論をしてくれたStefan Savageにも感謝します。IPの断片化の問題を提起してくれたBob BriscoeとJon Crowcroft、4番目のECNコードポイントの代替セマンティクス、およびその他のトピックについて感謝します。ドキュメントのいくつかの問題に関するフィードバックについて、リチャードウェンドランドに感謝します。
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.
また、IESG、特に長年にわたる輸送エリアディレクターに、フィードバックとECNの標準化に向けた作業に感謝します。
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH] Kent、S。およびR. Atkinson、「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] Kent、S。およびR. Atkinson、「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-under-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] Floyd、S。、「TCPおよび明示的な混雑通知」、ACMコンピューター通信レビュー、V。24N。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] Floyd、S。、「NSシミュレータでのECN検証テスト」、url "http://www-mash.cs.berkeley.edu/ns/"、test tcl/test/test-all- 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] Floyd、S。、およびFall、K。、「インターネットでのエンドツーエンドの混雑制御の使用を促進する」、1999年8月、ネットワーキングに関するIEEE/ACMトランザクション。
[FRED] Lin, D., and Morris, R., "Dynamics of Random Early Detection", SIGCOMM '97, September 1997.
[フレッド]リン、D。、およびモリス、R。、「ランダムアーリー検出のダイナミクス」、Sigcomm '97、1997年9月。
[GRE] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[GRE] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「Generic Routing Cancapsulation（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、pp。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.ジェイコブソン、「修正されたTCP混雑回避アルゴリズム」、1990年4月、End2end-Interestメーリングリストへのメッセージ、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] Krishnan、H。、「TCPの明示的な混雑通知（ECN）利益の分析」、Master's Thesis、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、「Layer Two Tunneling Protocol "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月、pp。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.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、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.、Pall、G.、Verthein、W.、Taarud、J.、Little、W。and G. Zorn、「ポイントツーポイントトンネルプロトコル（PPTP）」、RFC 2637、1999年7月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, January 1990.
[RFC1141] Mallory、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] Eastlake、D。、「物理リンクセキュリティタイプのサービス」、RFC 1455、1993年5月。
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1701] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「Generic Routing Cancapstulation（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] Hanks、S.、Li、T.、Farinacci、D。、およびP. Traina、「IPv4ネットワーク上の一般的なルーティングカプセル化」、RFC 1702、1994年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2309] Braden, B., et al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[RFC2309] Braden、B.、et al。、「インターネットにおけるキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2401] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、インターネットプロトコルのセキュリティアーキテクチャ、RFC 2401、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、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] Maughan、D.、Schertler、M.、Schneider、M.、J。Turner、「インターネットセキュリティ協会および主要管理プロトコル（ISAKMP）」、RFC 2409、1998年11月。
[RFC2409] Harkins D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins D.およびD. Carrel、「The Internet Key Exchange（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] Nichols、K.、Blake、S.、Baker、F。およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Ramakrishnan K.およびS. Floyd、「IPに明示的な混雑通知（ECN）を追加する提案」、RFC 2481、1999年1月。
[RFC2581] Alman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Alman、M.、Paxson、V。and W. Stevens、「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] Hadi Salim、J。およびU. Ahmed、「IPネットワークにおける明示的な混雑通知（ECN）のパフォーマンス評価」、RFC 2884、2000年7月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC2983, October 2000.
[RFC2983] Black、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] Bradner S.およびV. Paxson、「インターネットプロトコルおよび関連するヘッダーの価値に関する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. RamakrishnanおよびRaj Jain、「コンピューターネットワークにおける混雑回避のためのバイナリフィードバックスキーム」、コンピューターシステムに関するACMトランザクション、Vol.8、No.2、pp。158-181、1990年5月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, October 1999.
[SCWA99] Stefan Savage、Neal Cardwell、David Wetherall、およびTom Anderson、TCP混雑コントロールによる誤った受信機、ACM Computer Communications Review、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とSally Floyd、「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.
IPv4ヘッダーチェックサムの再計算は、出力バッファスイッチを使用したハイエンドルーターアーキテクチャの問題です。これは、すべてではないにしても、ヘッダー操作のすべてがスイッチの入力側で実行され、ECNの決定をローカルにする必要があるため出力バッファーに。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:
RFC 1141 [RFC1141] TTLフィールドが減少した後のIPv4チェックサムの増分更新について説明します。CE CodePointが設定された後のIPv4チェックサムの増分更新は次のように機能します。HCをECT（0）パケットの元のヘッダーチェックサムとし、CEビットが設定された後にHC 'を新しいヘッダーチェックサムとします。つまり、ECNフィールドは「10」から「11」に変更されました。次に、補完的な減算で計算されたヘッダーチェックサムの場合、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:
2つの補完マシンで計算されたヘッダーチェックサムの場合、CEビットが設定された後、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'.
ECNフィールドがECT（1）からCE、つまり「01」から「11」に変更されたときに、IPv4チェックサムの同様の増分更新を実行できます。
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 codepoint。
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.
CE CodePointをECT（0）またはECT（1）CodePointに置き換えると、渋滞の表示が効果的に消去されます。ただし、2つのECTコードポイントを使用すると、CE CodePointを消去するルーターは、元のECT CodePointが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つの変更の最後は、CE CodePointを非接続コードポイントに置き換えることであり、混雑の表示を消去し、同時にECNの能力を無効にします。
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 CodePointがECT CodePointに置き換えられた場合、パケットはECN対応のままであり、輻輳の兆候として下流のルーターによってマークまたはドロップされる可能性があります。CE CodePointがNot-ect CodePointに置き換えられている場合、パケットは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 CodePointが既に設定されている場合にCE CodePointを設定することです。この変更は、パスの残りの部分に沿ったそのパケットの処理に影響しません。特に、ルーターは、到着パケットをドロップするかマークするかを決定する際に、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コードポイントをオフにすることです。これは、パケットが後で混雑に遭遇する場合（たとえば、中程度の平均キューサイズの赤いキューに到着することにより）、マークされる代わりに削除されることを意味します。それ自体では、これは（アプリケーションの場合）改ざんするルーターが実際にパケットを削除した場合よりも悪いことではありません。この特定のケースの節約の恵みは、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レベルでECN対応であることをTCPピアに通知し、接続のセットアップ時に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シーケンス番号を使用する能力が必要であり、この能力とIPソースアドレスをスプーフィングする能力を備えた攻撃者は、ECNフラグを使用せずにTCP接続に損傷を与える可能性があります。したがって、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ビットセットでスプーフィングすると、データ受信機がスプーフィングされたCWRパケットを受け取ったときにECEパケットを送信していた場合、TCPデータレシーバーがECEパケットを送信するよりも少ないECEパケットを送信する可能性があります。
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の両方のパケットを「罰する」ことを考えてください。私たちが真実であると思われるもう1つの重要な特徴は、A＆Bフローを「罰する」前の監視デバイスが、CEコードポイントを設定する代わりに最初にパケットをドロップし、既にCE CodePointを持っているそのフローの到着パケットをドロップすることです。セット。エンドノードが実際にエンドツーエンドの輻輳制御を使用している場合、監視デバイスで見られる混雑のすべての兆候が表示され、これらの輻輳の兆候に応答し始めます。したがって、監視デバイスは、初期段階での流れの適応を提供することに成功しています。
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人の敵がいる場合に発生し、最初の敵が誤って輻輳を報告し、2番目の敵がこれらの報告を「消去」します。（パケットドロップとは異なり、ECN混雑レポートは、悪意のあるまたは壊れたルーターによってネットワークの後半に「逆転」する可能性があります。ただし、ECN Nonceの使用は、この動作を検出するための輸送に役立ちます。）ノード、第1敵と2番目の敵の間の監視装置が渋滞の誤った兆候を見る可能性があります。このドキュメントでの推奨事項に留意してください。混雑に適切に応答しないためのフローを「罰する」前に、ルーターはその流れに対して輻輳の兆候としてマークするのではなく、ドロップに切り替えます。これには、CE CodePointセットを備えたフローから到着するパケットを削除することが含まれる場合、これにより、これらの混雑の兆候がエンドノードによって見られることが保証されます。したがって、複数の矛盾する敵の結果として私たちが仮定できるという追加の害はありません。
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 CodePoint）の輻輳表示を消去することにより、エンドツーエンドの混雑制御を破壊する潜在的な影響に焦点を当てています。これら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の能力を誤って示すエンドツーエンドの混雑制御を覆す最初の方法は、パケットが後でCEDopointの設定をもたらす混雑に遭遇した場合にのみ、エンドツーエンドの混雑制御を効果的に破壊します。この場合、トランスポートプロトコル（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コードポイントは、ルーターが *中程度の *輻輳の期間中の輻輳の兆候としてのみ使用されます。Routerのキューがまだ満たされていなくても、ECN対応のルーターは、重い輻輳中にマークパケットではなくドロップする必要があります。たとえば、赤に基づいたアクティブキュー管理を使用するルーターの場合、平均キューサイズが赤いキューの最大しきい値を超えている間、到着するマークパケットではなく、ルーターがドロップする必要があります。
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.
場合によっては、混雑のレベルの増加は、混雑したキューに大きなバッファーの蓄積につながり、混雑したキューをパケットマークからパケットドロップ体制まで駆動するのに十分なものになります。この遷移は、バッファオーバーフローのために、または平均キューが赤の最大しきい値を上回るときにパケットをドロップする上記のアクティブなキュー管理ポリシーのために発生する可能性があります。この時点で、破壊された流れを含むすべてのフローは、パケットマークの代わりにパケットドロップを見始め、悪意のあるまたは壊れたルーターは、ネットワーク内のこれらの混雑の兆候を「消去」することができなくなります。エンドノードが適切なエンドツーエンドの輻輳制御を展開している場合、埋め尽くされた流れは輻輳に応じて到着率を低下させます。輻輳のレベルが十分に低下すると、混雑したキューがパケットドロップ体制からパケットマーク体制に戻ることができます。定常状態のパターンは、これら2つの体制の間で振動する混雑したキューの1つである可能性があります。
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).
セクション18.1.1で説明されている例を見てみましょう。ここでは、パケットに設定されたCEコードポイントが消去されます：{'11' - > '10'または '11' - > '01'}。CEコードポイントを設定する混雑したアップストリームルーターの結果は、この混雑の表示がそのフローのエンドノードに到達しないことです。したがって、ソース（完全に協力的で悪意ではないものでも）は、送信率を増加させ続けることができます（混雑ウィンドウを増やすことにより、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ベースまたは他の既知のパケットベースの輻輳制御メカニズムのいずれかの端末によってもたらされるネットワークの問題によって、それらがwarります。
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 CodePointを使用してうっ血を示すことを期待しています。パケット損失の量を減らす際に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.
エンドツーエンドの混雑制御を破壊する1つの形式は、ECT CodePointを設定することにより、ECNキャピールを誤って示すことです。これは、下流の混雑したルーターがCEコードポイントを無駄に設定することの結果です。ただし、セクション9.1.2で説明されているように、IPトンネルでECTコードポイントが変更された場合、トンネル内で内側のヘッダーが変更されない限り、トンネルの出口点でこれを検出できます。
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.
IPトンネル内でECT CodePointが消去された場合、トンネル内で内側のヘッダーが変更されない限り、トンネルの出力点でこれを検出できます。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.
エンドツーエンドの混雑制御のこの転覆により、エンドシステム輸送は輻輳の表示に反応しません。前のセクションで説明されている非抑制フローの不公平の増加に加えて、混雑したルーターのキューが構築され続ける可能性があり、その結果、混雑したルーターでのパケット損失が発生する可能性があります。暫定的には、フローは、おそらく他の非微分フローと比較して帯域幅の増加とともに、より高いキューイングの遅延を経験する可能性があります。しかし、トランスポートは、パスで一貫して慎重に管理されたキューイングを経験しているという仮定を本質的に行うものではありません。敵がその流れ自体のパケットを単純に落とした場合よりも、これらの形式の絡み合い端から端への混雑制御の形態は、覆われた流れの場合よりも悪化していないと考えています。
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キャピールを誤って示すか、ECNの輻輳表示を消去することにより（CE CodePointで）、エンドツーエンドの混雑制御を破壊した場合です。ルーターがパケットをドロップすることでフローに害を与える可能性のある多くの方法がありますが、ルーターはパケットをドロップすることでエンドツーエンドの混雑制御を破壊することはできません。例として、ルーターは、データパケット、確認パケット、またはコントロールパケットを削除して、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で説明されているように、破壊された流れ。
20. The Motivation for the ECT Codepoints.
20. ECTコードポイントの動機。
20.1. The Motivation for an ECT Codepoint.
20.1. ECT CodePointの動機。
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* 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.
ECT CodePointの必要性は、ECNがインターネットに段階的に展開されるという事実によって動機付けられています。ECT CodePointを使用すると、RouterはECN対応ではないフローからパケットをドロップできますが、代わりに * ecn対応のパケットにCEコードポイントを *設定できます。ECT CodePointを使用すると、エンドノードがパケットをドロップする代わりに *代わりにパケット *にCE CodePointを設定できるようにするため、エンドノードには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 CodePointがなかった場合、Routerは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対応フローがすべての帯域幅を取得し、うっ血は軽度のままです。、非ECN対応フローはありません。また、ルーターがCE CodePointの設定からドロップパケットに移行するまで混雑が増加します。この2番目の結果は公平性を明らかにしますが、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.
このドキュメントで前述したように、CEコードポイントに自らを宣伝したが、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を展開しないためのエンドノードの強力なインセンティブ。
20.2. The Motivation for two ECT Codepoints.
20.2. 2つのECTコードポイントの動機。
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 NonCeは、送信者がネットワーク要素がCEコードポイントを消去していないこと、およびデータレシーバーがCE CodePointセットを使用してパケットの受領を送信者に適切に報告していることを確率的に検証するためのメカニズムの開発を可能にします。
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.
送信者がネットワーク要素または受信機の誤動作を検出するもう1つの可能性は、データ送信者がCE CodePointセットでデータパケットを時々送信して、受信者がCE CodePointを受信するかどうかを確認することです。もちろん、これらのパケットがネットワークで混雑に遭遇した場合、CE CodePointがすでに設定されているため、ルーターはパケットを変更しない可能性があります。したがって、CE CodePointセットで送信されたパケットの場合、TCPエンドノードは、一部のルーターがこれらのパケットにCEコードポイントを設定することを意図しているかどうかを判断できませんでした。このため、CE CodePointでパケットを送信することは控えめに行われなければならず、ECN Nonceよりも誤動作ネットワーク要素や受信機に対する効果的ではないチェックになります。
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.
4番目のECNコードポイントのECT（1）への割り当ては、他の目的でこのコードポイントの使用を排除します。明確にするために、ここに他の可能な目的を簡単にリストします。
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.
データ送信者が4番目のECNコードポイントを使用してECNの代替セマンティクスを示す可能性が1つある可能性があります。ただし、これは、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.
4番目のECN CodePointの2番目の使用は、それぞれ軽度および重度の輻輳のために、それぞれ混雑（CE（0）とCE（1）を示すために、ルーターに2つの別々のコードポイントを与えることでした。これは場合によっては役立つ可能性がありますが、これは確かにこの時点で説得力のある要件ではないようです。これに対して説得力のある必要性があると判断された場合、漸進的な展開の複雑さは、この関数のコードポイントを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 CodePointに対して非公式に提案されている3番目の使用は、ルーターでマークされたパケットを複製するためのランダム化手順に基づいて、ある形式のマルチキャスト輻輳制御で使用するためです。提案されているマルチキャストパケットの重複手順の中には、（1）このコードポイントでパケットをマークした重複ポイントの上流で、（2）その重複ポイントの下流の輻輳を検出できるという事実を伝える新しいECNコードポイントに基づいているものがあります。ECT（1）は、ECT（0）とは異なり、うっ血または初期の混雑に応じてECNマーキングが発生した場合にCEに置き換えられるため、この目的を果たすことができます。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フィールドに加えられた唯一の変更は、CEDopointを設定して輻輳を示すことであると仮定しています。これは、前の段落のマルチキャスト重複手順によるECT（1）の提案された使用の一部と一致しておらず、マルチキャスト複製手順と完全な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対応輸送）とCE（混雑経験のある）コードポイントが1ビットで過負荷になっている必要があるかどうかの問題はまだ残っています。[floyd94]で探索されたこの過負荷の1つのビットの代替品は、2つの値を持つ一つのビットを含んでいたでしょう。1つの値「ECTおよびCEではなく」は、ECN対応輸送を表し、もう1つの値「CEまたはnot 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つの違いは、複数の混雑したルーターを通過するパケットに関するものです。2番目の混雑したルーターに到着し、そのルーターのアクティブキュー管理によって選択されたCEパケットを考えてみてください。1ビットの実装では、2番目の混雑したルーターには、CEパケットと非効果パケットを区別できないため、CEパケットをドロップする以外に選択肢がありません。2ビットの実装では、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と非効果パケットを区別できないという事実に起因します。したがって、1ビットの実装では、ECN対応のデータ送信者は、各パケットがECN対応として送信されたのか、非ECN対応として送信されたかどうかをレシーバーまたは受信機に明確に示す必要があります。1つの可能性は、送信者がパケットがECN対応として送信されたかどうかを輸送ヘッダーに示すことです。1ビットの実装の機能的制限を伴う2番目の可能性は、送信者がそのすべてのパケットを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.
前に説明したもう1つの懸念（およびこのドキュメントで推奨されている）は、輸送（特にTCP）が純粋なACKパケットまたは再送信パケットをECN対応としてマークするべきではないことです。ECN対応の輸送からの純粋なACKパケットは、渋滞制御の観点から輸送に影響を与えることなく、削除することができます（後続のACKは累積的であるため）。ウィンドウを減らすことにより、純粋なACKパケットのCEコードポイントに反応するECN対応トランスポートは、ECNで利用できない輸送と比較して不利になります。このため（および再送信パケットに関連して前述の理由により）、PacketごとにECT CodePointを設定することが望ましいです。
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ビットアプローチのもう1つの利点は、やや堅牢であることです。セクション8で説明されている最も重要な問題は、デフォルトの兆候が非ECN対応輸送の兆候であるべきであるということです。2ビットの実装では、デフォルト値のこの要件は、単に非接続コードポイントがデフォルトであることを意味します。ワンビットの実装では、これは、単一のオーバーロードされたビットがデフォルトで「CEまたはnot 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ビットの実装は、2番目の混雑したルーターでのCEパケットの処理のためのより限られた機能を備えています。第二に、1ビットの実装では、ECN対応フローからのパケットのトランスポートヘッダーに追加の情報を掲載する必要があります（他の場所で2番目のビットの機能を伝えるため、つまりトランスポートヘッダーで）、またはECN対応の送信者フローは、受信者がどのパケットが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（サービスのタイプ）Octetを定義しました。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:
RFC 1122には、TOSフィールドにビット6と7が含まれていましたが、これらの2つのビットの特定の使用については議論していませんでした。
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で定義されました。最後のフィールドであるMBZ（「ゼロでなければならない」）が現在使用されていないと定義されている、最先端と種類のサービス（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は、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」[RFC2474]によって廃止されました。RFC 2780 [RFC2780]は、2ビットCUフィールドの実験的使用としてECNを指定しました。RFC 2780は、DSフィールドの定義を更新して、8ビットすべてではなく、このオクテットの最初の6ビットのみを網羅しました。これらの最初の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フィールドのビットを介して転送したビットを変更することは許可されていませんでした。エンドノードの場合、ビット7（2番目のECNビット）は、2474年以前にRFCに準拠している実装においてゼロとしてゼロとして送信する必要があります。そのようなノードは、「金融コストを最小限に抑える」規定のビット6（最初のECNビット）を送信することができます。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".
ECT CodePointセットを使用して、ECN対応のエンドノード送信パケットによってECN対応環境で発生する可能性のある損害については、「End Nodesによるコンプライアンス違反」に関するセクションで説明されています。
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.
IPヘッダーのECNフィールドのコードポイントは、RFC 2780で必要とされるように、この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 BYTEおよびIPv6 TrafficクラスOctet」を作成する必要があります。名前空間は次のとおりです。
IPv4 TOS Byte and IPv6 Traffic Class Octet
IPv4 TOS BYTEおよびIPv6トラフィッククラスOctet
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：差別化されたサービスフィールドCodePointsレジストリ（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.
TCPヘッダーのCWRフラグとECEフラグのコードポイントは、RFC 2780で必要とされるように、この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）には、以下に示すように、TCPヘッダーのバイト13および14の将来の使用のために予約されたRFC 793で定義された6ビット予約フィールドが含まれています。他の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
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は、1999年11月のDavid Blackの要請で、上記のセクション9.2.1.2で説明されているECNトンネルの使用にIPSECセキュリティ協会の属性値10を割り当てました。IANAは、この割り当てのリファレンスをこのRFCへのデビッドブラックの要求から変更しました。
K. K. Ramakrishnan TeraOptic Networks, Inc.
K. K. Ramakrishnan Teraoptic Networks、Inc。
Phone: +1 (408) 666-8650
EMail: kk@teraoptic.com
Sally Floyd ACIRI
サリー・フロイド・アシリ
Phone: +1 (510) 666-2989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
デビッドL.ブラックEMCコーポレーション42サウスセントホプキントン、マサチューセッツ州01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。