[要約] RFC 7837は、Congestion Exposure（ConEx）のためのIPv6宛先オプションに関する規格です。その目的は、ネットワークの混雑状況を明示的に示すための手段を提供することです。
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 7837 Ericsson
Category: Experimental M. Kuehlewind
ISSN: 2070-1721 ETH Zurich
B. Briscoe
Simula Research Laboratory
C. Ralli
Telefonica
May 2016
IPv6 Destination Option for Congestion Exposure (ConEx)
輻輳露出（ConEx）のIPv6宛先オプション
Abstract
概要
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.
Congestion Exposure（ConEx）は、同じフローの早い段階でパケットが遭遇した輻輳について送信者がネットワークに通知するメカニズムです。このドキュメントは、IPv6データグラムでConExマーキングを運ぶことができるIPv6宛先オプションを指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7837.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7837で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Requirements for the Coding of ConEx in IPv6 . . . . . . . . 4
4. ConEx Destination Option (CDO) . . . . . . . . . . . . . . . 5
5. Implementation in the Fast Path of ConEx-Aware Routers . . . 8
6. Tunnel Processing . . . . . . . . . . . . . . . . . . . . . . 8
7. Compatibility with Use of IPsec . . . . . . . . . . . . . . . 9
8. Mitigating Flooding Attacks by Using Preferential Drop . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Congestion Exposure (ConEx) [RFC7713] is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option [RFC2460] that can be used for performing ConEx markings in IPv6 datagrams.
Congestion Exposure（ConEx）[RFC7713]は、同じフローの早い段階でパケットが遭遇した輻輳について送信者がネットワークに通知するメカニズムです。このドキュメントでは、IPv6データグラムでConExマーキングを実行するために使用できるIPv6宛先オプション[RFC2460]を指定しています。
This document specifies the ConEx wire protocol in IPv6. The ConEx information can be used by any network element on the path to, for example, do traffic management or egress policing. Additionally, this information will potentially be used by an audit function that checks the integrity of the sender's signaling. Further, each transport protocol that supports ConEx signaling will need to precisely specify when the transport sets ConEx markings (e.g., the behavior for TCP is specified in [RFC7786]).
このドキュメントでは、IPv6のConExワイヤプロトコルを指定します。 ConEx情報は、パス上の任意のネットワーク要素で使用でき、たとえば、トラフィック管理や出力ポリシングを実行できます。さらに、この情報は、送信者のシグナリングの整合性をチェックする監査機能によって潜在的に使用されます。さらに、ConExシグナリングをサポートする各トランスポートプロトコルは、トランスポートがいつConExマーキングを設定するかを正確に指定する必要があります（たとえば、TCPの動作は[RFC7786]で指定されています）。
This document specifies ConEx for IPv6 only. Due to space limitations in the IPv4 header and the risk of options that might be stripped by a middlebox in IPv4, the primary goal of the working group was to specify ConEx in IPv6 for experimentation.
このドキュメントでは、IPv6のConExのみを指定しています。 IPv4ヘッダーのスペース制限とIPv4のミドルボックスによって削除される可能性のあるオプションのリスクにより、ワーキンググループの主な目標は、実験のためにIPv6でConExを指定することでした。
This specification is experimental to allow the IETF to assess whether the decision to implement the ConEx Signal as a destination option fulfills the requirements stated in this document, as well as to evaluate the proposed encoding of the ConEx Signals as described in [RFC7713].
この仕様は実験的なものであり、IETFが宛先オプションとしてConEx信号を実装する決定がこのドキュメントで述べられている要件を満たすかどうかを評価し、[RFC7713]で説明されているように提案されたConEx信号のエンコーディングを評価します。
The duration of this experiment is expected to be no less than two years from publication of this document as infrastructure is needed to be set up to determine the outcome of this experiment. Experimenting with ConEx requires IPv6 traffic. Even though the amount of IPv6 traffic is growing, the traffic mix carried over IPv6 is still very different than over IPv4. Therefore, it might take longer to find a suitable test scenario where only IPv6 traffic is managed using ConEx.
この実験の結果を決定するにはインフラストラクチャを設定する必要があるため、この実験の期間は、このドキュメントの公開から2年以上になると予想されます。 ConExの実験にはIPv6トラフィックが必要です。 IPv6トラフィックの量は増加していますが、IPv6を介して伝送されるトラフィックの混合は、IPv4を介した場合とは非常に異なります。したがって、ConExを使用してIPv6トラフィックのみを管理する適切なテストシナリオを見つけるには、時間がかかる場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
A set of requirements for an ideal concrete ConEx wire protocol is given in [RFC7713]. The ConEx working group recognized that it will be difficult to find an encoding in IPv6 that satisfies all requirements. The choice in this document to implement the ConEx information in a destination option aims to satisfy those requirements that constrain the placement of ConEx information:
理想的な具体的なConExワイヤプロトコルの一連の要件が[RFC7713]に示されています。 ConExワーキンググループは、すべての要件を満たすIPv6のエンコーディングを見つけるのは難しいことを認識していました。このドキュメントで宛先オプションにConEx情報を実装する選択は、ConEx情報の配置を制約する要件を満たすことを目的としています。
R-1: The marking mechanism needs to be visible to all ConEx-capable nodes on the path.
R-1：マーキングメカニズムは、パス上のすべてのConEx対応ノードから見える必要があります。
R-2: The mechanism needs to be able to traverse nodes that do not understand the markings. This is required to ensure that ConEx can be incrementally deployed over the Internet.
R-2：メカニズムは、マーキングを理解しないノードをトラバースできる必要があります。これは、ConExをインターネット経由で段階的に展開できるようにするために必要です。
R-3: The presence of the marking mechanism should not significantly alter the processing of the packet. This is required to ensure that ConEx-Marked packets do not face any undue delays or drops due to a badly chosen mechanism.
R-3：マーキングメカニズムの存在により、パケットの処理が大幅に変更されることはありません。これは、不適切に選択されたメカニズムが原因で、ConEx-Markedパケットが過度の遅延やドロップに直面しないようにするために必要です。
R-4: The markings should be immutable once set by the sender. At the very least, any tampering should be detectable.
R-4：送信者が設定したマーキングは不変である必要があります。少なくとも、改ざんは検出可能でなければなりません。
Based on these requirements, four solutions to implement the ConEx information in the IPv6 header have been investigated: hop-by-hop options, destination options, using IPv6 header bits (from the flow label), and new extension headers. After evaluating the different solutions, the ConEx working group concluded that the use of a destination option would best address these requirements.
これらの要件に基づいて、IPv6ヘッダーにConEx情報を実装する4つのソリューションが調査されました：ホップバイホップオプション、宛先オプション、（フローラベルからの）IPv6ヘッダービットの使用、および新しい拡張ヘッダー。さまざまなソリューションを評価した後、ConExワーキンググループは、宛先オプションの使用がこれらの要件に最もよく対処すると結論付けました。
Hop-by-hop options would have been the best solution for carrying ConEx markings if they had met requirement R-3. There is currently some work ongoing in the 6MAN working group to address this very issue [HBH-HEADER]. This new behavior would address R-3 and would make hop-by-hop options the preferred solution for carrying ConEx markings.
ホップバイホップオプションは、要件R-3を満たしていれば、ConExマーキングを伝送するための最良のソリューションでした。現在、この問題に対処するために、6MANワーキンググループでいくつかの作業が進行中です[HBH-HEADER]。この新しい動作はR-3に対処し、ホップバイホップオプションをConExマーキングを伝送するための推奨ソリューションにします。
Choosing to use a destination option does not necessarily satisfy the requirement for on-path visibility, because it can be encapsulated by additional IP header(s). Therefore, ConEx-aware network devices, including policy or audit devices, might have to follow the chaining (extension-) headers into inner IP headers to find ConEx information. This choice was a compromise between fast-path performance of ConEx-aware network nodes and visibility, as discussed in Section 5.
宛先オプションを使用することを選択しても、追加のIPヘッダーによってカプセル化できるため、パス上での可視性の要件を満たすとは限りません。したがって、ポリシーまたは監査デバイスを含むConEx対応ネットワークデバイスは、ConEx情報を見つけるために、チェーン（拡張）ヘッダーを内部IPヘッダーに追跡する必要がある場合があります。この選択は、セクション5で説明したように、ConEx対応ネットワークノードの高速パスパフォーマンスと可視性の間の妥協点でした。
Please note that the IPv6 specification [RFC2460] does not require or expect intermediate nodes to inspect destination options such as the ConEx Destination Option (CDO). This implies that ConEx-aware intermediate nodes following this specification need updated extension header processing code to be able read the destination options.
IPv6仕様[RFC2460]では、中間ノードがConEx Destination Option（CDO）などの宛先オプションを検査することを要求または期待していないことに注意してください。これは、この仕様に従うConEx対応の中間ノードが、宛先オプションを読み取ることができるように更新された拡張ヘッダー処理コードを必要とすることを意味します。
The CDO is a destination option that can be included in IPv6 datagrams that are sent by ConEx-aware senders in order to inform ConEx-aware nodes on the path about the congestion encountered by packets earlier in the same flow or the expected risk of encountering congestion in the future. The CDO does not have any alignment requirements.
CDOは、同じフローの早い段階でパケットが遭遇した輻輳または輻輳が発生することが予想されるリスクについてパス上のConEx対応ノードに通知するために、ConEx対応送信者が送信するIPv6データグラムに含めることができる宛先オプションです。将来は。 CDOには調整要件はありません。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |X|L|E|C| res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ConEx Destination Option Layout
図1：ConEx宛先オプションのレイアウト
Option Type
オプションタイプ
8-bit identifier of the type of option. Set to the value 30 (0x1E) allocated for experimental work.
オプションのタイプの8ビットID。実験的作業に割り当てられた値30（0x1E）に設定します。
Option Length
オプションの長さ
8-bit unsigned integer. The length of the option in octets (excluding the Option Type and Option Length fields). Set to the value 1.
8ビットの符号なし整数。オクテット単位のオプションの長さ（[オプションタイプ]および[オプションの長さ]フィールドを除く）。値1に設定します。
X Bit
Xビット
When this bit is set, the transport sender is using ConEx with this packet. If it is not set, the sender is not using ConEx with this packet.
このビットが設定されている場合、トランスポート送信者はこのパケットでConExを使用しています。設定されていない場合、送信者はこのパケットでConExを使用していません。
L Bit
Lビット
When this bit is set, the transport sender has experienced a loss.
このビットが設定されている場合、トランスポート送信者は損失を経験しています。
E Bit
Eビット
When this bit is set, the transport sender has experienced congestion signaled using Explicit Congestion Notification (ECN) [RFC3168].
このビットが設定されている場合、トランスポート送信側は、明示的輻輳通知（ECN）[RFC3168]を使用して通知された輻輳を経験しています。
C Bit
Cビット
When this bit is set, the transport sender is building up congestion credit in the audit function.
このビットが設定されている場合、トランスポート送信側は監査機能で輻輳クレジットを構築しています。
Reserved (res)
予約済み（解像度）
These four bits are not used in the current specification. They are set to zero by the sender and are ignored by the receiver.
これらの4ビットは現在の仕様では使用されていません。それらは送信側によってゼロに設定され、受信側によって無視されます。
All packets sent over a ConEx-capable TCP connection or belonging to the same ConEx-capable flow MUST carry the CDO. The chg bit (the third-highest-order bit) in the CDO Option Type field is set to zero, meaning that the CDO option is immutable. Network devices with ConEx-aware functions read the flags, but all network devices MUST forward the CDO unaltered.
ConEx対応のTCP接続を介して送信される、または同じConEx対応のフローに属するすべてのパケットは、CDOを伝送する必要があります。 CDOオプションタイプフィールドのchgビット（3番目に上位のビット）はゼロに設定されます。これは、CDOオプションが不変であることを意味します。 ConEx対応の機能を持つネットワークデバイスはフラグを読み取りますが、すべてのネットワークデバイスはCDOを変更せずに転送する必要があります。
The CDO SHOULD be placed as the first option in the Destination Option header before the AH [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] (if present). The IPsec Authentication Header (AH) MAY be used to verify that the CDO has not been modified.
CDOは、AH [RFC4302]および/またはカプセル化セキュリティペイロード（ESP）[RFC4303]（存在する場合）の前の宛先オプションヘッダーの最初のオプションとして配置する必要があります（SHOULD）。 IPsec認証ヘッダー（AH）を使用して、CDOが変更されていないことを確認できます。
If the X bit is zero, all the other three bits are undefined and thus MUST be ignored and forwarded unchanged by network nodes. The X bit set to zero means that the connection is ConEx-capable but that this packet MUST NOT be counted when determining ConEx information in an audit function. This can be the case if no congestion feedback is (currently) available, e.g., in TCP if one endpoint has been receiving data but sending nothing but pure ACKs (no user data) for some time. This is because pure ACKs do not advance the sequence number, so the TCP endpoint receiving them cannot reliably tell whether any have been lost due to congestion. Pure TCP ACKs cannot be ECN-marked either [RFC3168].
Xビットがゼロの場合、他の3つのビットはすべて未定義であるため、ネットワークノードによって無視され、変更されずに転送される必要があります。ゼロに設定されたXビットは、接続がConEx対応であることを意味しますが、監査機能でConEx情報を決定するときにこのパケットをカウントしてはなりません（MUST NOT）。これは、たとえば、1つのエンドポイントがしばらくデータを受信しているが、純粋なACK（ユーザーデータなし）しか送信していない場合など、（現在）TCPで輻輳フィードバックが利用できない場合に当てはまります。これは、純粋なACKはシーケンス番号を進めないため、それらを受信するTCPエンドポイントは、輻輳が原因で失われたかどうかを確実に判断できないためです。純粋なTCP ACKにもECNマークを付けることはできません[RFC3168]。
If the X bit is set, any of the other three bits (L, E, or C) might be set. Whenever one of these bits is set, the number of bytes carried by this IP packet (including the IP header that directly encapsulates the CDO and everything that IP header encapsulates) SHOULD be counted to determine congestion or credit information. In IPv6, the number of bytes can easily be calculated by adding the number 40 (length of the IPv6 header in bytes) to the value present in the Payload Length field in the IPv6 header.
Xビットが設定されている場合、他の3つのビット（L、E、またはC）のいずれかが設定されている可能性があります。これらのビットの1つが設定されている場合は常に、このIPパケット（CDOを直接カプセル化するIPヘッダーとIPヘッダーがカプセル化するすべてを含む）によって伝送されるバイト数をカウントして、輻輳またはクレジット情報を決定する必要があります。 IPv6では、バイト数は、IPv6ヘッダーのペイロード長フィールドに存在する値に40（IPv6ヘッダーの長さ（バイト））を追加することで簡単に計算できます。
The credit signal represents potential for congestion. If a congestion event occurs, a corresponding amount of credit is consumed as outlined in [RFC7713]. A ConEx-enabled sender SHOULD, therefore, signal sufficient credit in advance of any congestion event to cover the (estimated maximum) amount of lost or CE-marked bytes that could occur in such a congestion event. This estimation depends on the heuristics used and aggressiveness of the sender when deciding the appropriate sending rate (congestion control). Note that the maximum congestion risk is that all packets in flight get lost or CE-marked; therefore, this would be the most conservative estimation for the congestion risk. After a congestion event, if the sender intends to take the same risk again, it just needs to replace the consumed credit as non-consumed credit does not expire. For the case of TCP, this is described in detail in [RFC7786].
クレジット信号は、混雑の可能性を表しています。輻輳イベントが発生すると、[RFC7713]で概説されているように、対応する量のクレジットが消費されます。したがって、ConEx対応の送信者は、そのような輻輳イベントで発生する可能性のある失われた、またはCEマークされたバイトの（推定最大）量をカバーするために、輻輳イベントの前に十分なクレジットを通知する必要があります（SHOULD）。この推定は、適切な送信レート（輻輳制御）を決定する際の、使用されるヒューリスティックと送信者の積極性に依存します。最大の輻輳リスクは、飛行中のすべてのパケットが失われるか、CEマークが付けられることです。したがって、これは輻輳リスクの最も保守的な見積もりになります。輻輳イベントの後、送信者が同じリスクを取りたい場合は、消費されていないクレジットが期限切れにならないため、消費されたクレジットを置き換えるだけです。 TCPの場合、これは[RFC7786]で詳細に説明されています。
If the L or E bit is set, a congestion signal in the form of a loss or an ECN mark, respectively, was previously experienced by the same connection.
LビットまたはEビットが設定されている場合、同じ接続で以前にそれぞれ損失またはECNマークの形の輻輳信号が発生していました。
In principle, all of these three bits (L, E, or C) might be set in the same packet. In this case, the packet size MUST be counted once for each respective ConEx information counter.
原則として、これら3つのビット（L、E、またはC）はすべて同じパケットに設定される可能性があります。この場合、パケットサイズは、それぞれのConEx情報カウンターごとに1回カウントする必要があります。
If a network node extracts the ConEx information from a connection, it is expected to hold this information in bytes, e.g., comparing the total number of bytes sent with the number of bytes sent with ConEx congestion marks (L or E) to determine the current whole path congestion level. Therefore, a ConEx-aware node that processes the CDO MUST use the Payload Length field of the preceding IPv6 header for byte-based counting. When a ratio is measured and equally sized packets can be assumed, counting the number of packets (instead of the number of bytes) should deliver the same result. But an audit function must be aware that this estimation can be quite wrong if, for example, different sized packed are sent; thus, it is not reliable.
ネットワークノードが接続からConEx情報を抽出する場合、この情報をバイト単位で保持することが期待されます。たとえば、送信された総バイト数とConEx輻輳マーク（LまたはE）で送信されたバイト数を比較して、現在のパス全体の輻輳レベル。したがって、CDOを処理するConEx対応ノードは、バイトベースのカウントに先行するIPv6ヘッダーのペイロード長フィールドを使用する必要があります。比率が測定され、同じサイズのパケットを想定できる場合、（バイト数ではなく）パケット数をカウントしても同じ結果が得られます。しかし、監査機能は、たとえば、異なるサイズのパックが送信された場合、この見積もりはかなり間違っている可能性があることを認識している必要があります。したがって、それは信頼できません。
All remaining bits in the CDO are reserved for future use (which are currently the last four bits of the eight bit option space). A ConEx sender SHOULD set the reserved bits in the CDO to zero. Other nodes MUST ignore these bits and ConEx-aware intermediate nodes MUST forward them unchanged, whatever their values. They MAY log the presence of a non-zero Reserved field.
CDOの残りのすべてのビットは、将来の使用のために予約されています（現在、8ビットオプション空間の最後の4ビットです）。 ConEx送信者は、CDOの予約ビットをゼロに設定する必要があります（SHOULD）。他のノードはこれらのビットを無視する必要があり、ConEx対応の中間ノードは、それらの値が何であれ、変更せずに転送する必要があります。ゼロ以外の予約フィールドの存在をログに記録してもよい（MAY）。
The CDO is only applicable on unicast or anycast packets (for reasoning, see the note regarding item J on multicast at the end of Section 3.3 of [RFC7713]). A ConEx sender MUST NOT send a packet with the CDO to a multicast address. ConEx-capable network nodes MUST treat a multicast packet with the X flag set the same as an equivalent packet without the CDO, and they SHOULD forward it unchanged.
CDOはユニキャストまたはエニーキャストパケットにのみ適用されます（理由については、[RFC7713]のセクション3.3の最後にあるマルチキャストのアイテムJに関する注記を参照してください）。 ConEx送信者は、CDOを含むパケットをマルチキャストアドレスに送信してはなりません（MUST NOT）。 ConEx対応ネットワークノードは、Xフラグが設定されたマルチキャストパケットをCDOなしの同等のパケットと同じように処理しなければならず（MUST）、それらは変更せずに転送する必要があります（SHOULD）。
As stated in [RFC7713] (see Section 3.3, item N on network-layer requirements), protocol specs should describe any warning or error messages relevant to the encoding. There are no warnings or error messages associated with the CDO.
[RFC7713]で述べられているように（セクション3.3、ネットワーク層要件の項目Nを参照）、プロトコル仕様は、エンコーディングに関連する警告またはエラーメッセージを記述する必要があります。 CDOに関連する警告やエラーメッセージはありません。
The ConEx information is being encoded into a destination option so that it does not impact forwarding performance in the non-ConEx-aware nodes on the path. Since destination options are not usually processed by routers, the existence of the CDO does not affect the fast-path processing of the datagram on non-ConEx-aware routers, i.e., they are not pushed into the slow path towards the control plane for exception processing.
パス上のConEx対応でないノードでの転送パフォーマンスに影響を与えないように、ConEx情報は宛先オプションにエンコードされます。宛先オプションは通常ルーターで処理されないため、CDOの存在は、ConEx非対応ルーターでのデータグラムの高速パス処理に影響を与えません。つまり、例外のためにコントロールプレーンに向かう低速パスにプッシュされません。処理。
ConEx-aware nodes still need to process the CDO without severely affecting forwarding. For this to be possible, the ConEx-aware routers need to quickly ascertain the presence of the CDO and process the option if it is present. To efficiently perform this, the CDO needs to be placed in a fairly deterministic location. In order to facilitate forwarding on ConEx-aware routers, ConEx-aware senders that send IPv6 datagrams with the CDO SHOULD place the CDO as the first destination option in the Destination Option header.
ConEx対応ノードは、転送に深刻な影響を与えずにCDOを処理する必要があります。これを可能にするには、ConEx対応ルーターがCDOの存在をすばやく確認し、CDOが存在する場合はオプションを処理する必要があります。これを効率的に実行するには、CDOをかなり確定的な場所に配置する必要があります。 ConEx対応ルーターでの転送を容易にするために、CDOでIPv6データグラムを送信するConEx対応送信者は、CDOを宛先オプションヘッダーの最初の宛先オプションとして配置する必要があります（SHOULD）。
As with any destination option, an ingress tunnel endpoint will not normally copy the CDO when adding an encapsulating outer IP header. In general, an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would change the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is coordinated. This trades off the performance of ConEx functions against that of tunnel processing.
他の宛先オプションと同様に、カプセル化外部IPヘッダーを追加するときに、通常、入力トンネルエンドポイントはCDOをコピーしません。一般的に、入力トンネルは、カウントされるバイト数を変更するため、CDOを外部ヘッダーにコピーするべきではありません（SHOULD NOT）。ただし、トンネルの進入とConExノードの構成が調整されている場合は、後続のオンパスConEx関数による可視性を高めるために、CDOを外部ヘッダーにコピーする場合があります。これにより、ConEx関数のパフォーマンスとトンネル処理のパフォーマンスがトレードオフになります。
An egress tunnel endpoint SHOULD ignore any CDO in the outer header on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. A decapsulator MAY compare the two and MAY log any case where they differ. However, the packet MUST be forwarded irrespective of any such anomaly, given an outer CDO is only a performance optimization.
出力トンネルエンドポイントは、外部IPヘッダーのカプセル化解除時に、外部ヘッダーのCDOを無視する必要があります（SHOULD）。内部CDOの情報は、外部CDOと異なっていても、常に正しいと見なされます。したがって、カプセル開放装置は、内側と比較することなく、外側のCDOを取り除くことができます。カプセル開放装置は2つを比較してもよく、それらが異なる場合はログに記録してもよい（MAY）。ただし、外部CDOはパフォーマンスの最適化に過ぎないため、パケットはこのような異常に関係なく転送される必要があります。
A network node that assesses ConEx information SHOULD search for encapsulated IP headers until a CDO is found. At any specific network location, the maximum necessary depth of search is likely to be the same for all packets between a given set of tunnel endpoints.
ConEx情報を評価するネットワークノードは、CDOが見つかるまでカプセル化されたIPヘッダーを検索する必要があります（SHOULD）。特定のネットワークロケーションでは、特定のトンネルエンドポイントセット間のすべてのパケットに対して、必要な最大の検索深度が同じになる可能性があります。
A network-based attacker could alter ConEx information to fool an audit function in a downstream network into discarding packets. If the endpoints are using the IPsec Authentication Header (AH) [RFC2460] to detect alteration of IP headers along the path, AH will also detect alteration of the CDO header. Nonetheless, AH protection will rarely need to be introduced for ConEx, because attacks by one network on another are rare if they are traceable. Other known attacks from one network on another, such as TTL expiry attacks, are more damaging to the innocent network (because the ConEx audit discards silently) and less traceable (because TTL is meant to change, whereas CDO is not).
ネットワークベースの攻撃者は、ConEx情報を変更して、ダウンストリームネットワークの監査機能をだましてパケットを破棄する可能性があります。エンドポイントがIPsec認証ヘッダー（AH）[RFC2460]を使用してパスに沿ったIPヘッダーの変更を検出している場合、AHはCDOヘッダーの変更も検出します。それでも、追跡可能な場合、ネットワーク間の攻撃はまれであるため、ConExにAH保護を導入する必要はほとんどありません。 TTL期限切れ攻撃など、あるネットワークから別のネットワークへの既知の攻撃は、無害なネットワークへのダメージが大きく（ConEx監査がサイレントに破棄するため）、追跡可能性が低くなります（CDOは変更しないのにTTLが意図されているため）。
Section 4 specifies that the CDO is placed in the Destination Option header before the AH and/or ESP headers so that ConEx information remains in the clear if ESP is being used to encrypt other transmitted information in transport mode [RFC4301]. In general, a Destination Option header inside an IPv6 packet can be placed in two possible positions, either before the Routing header or after the ESP/AH headers as described in Section 4.1 of [RFC2460]. If the CDO was placed in the latter position and an ESP header was used with encryption, ConEx-aware intermediate nodes would not be able to view and interpret the CDO, effectively rendering it useless.
セクション4では、CDOがAHヘッダーまたはESPヘッダー、あるいはその両方の前の宛先オプションヘッダーに配置されることを指定しているため、ESPがトランスポートモードで他の送信情報を暗号化するために使用されている場合、ConEx情報はクリアなままです[RFC4301]。一般に、[RFC2460]のセクション4.1で説明されているように、IPv6パケット内の宛先オプションヘッダーは、ルーティングヘッダーの前またはESP / AHヘッダーの後の2つの可能な位置に配置できます。 CDOが後者の位置に配置され、ESPヘッダーが暗号化とともに使用された場合、ConEx対応の中間ノードはCDOを表示および解釈できなくなり、効果的にCDOが役に立たなくなります。
The IPv6 protocol architecture currently does not provide a mechanism for new headers to be copied to the outer IP header. Therefore, if IPsec encryption is used in tunnel mode, ConEx information cannot be accessed over the extent of the ESP tunnel.
IPv6プロトコルアーキテクチャは現在、新しいヘッダーを外部IPヘッダーにコピーするメカニズムを提供していません。したがって、トンネルモードでIPsec暗号化が使用されている場合、ESPトンネルの範囲を介してConEx情報にアクセスできません。
The destination IP stack will not usually process the CDO; therefore, the sender can send a CDO without checking if the receiver will understand it. The CDO MUST still be forwarded to the destination IP stack, because the destination might check the integrity of the whole packet, irrespective of whether it understands ConEx.
通常、宛先IPスタックはCDOを処理しません。したがって、送信者は、受信者が理解できるかどうかを確認せずにCDOを送信できます。宛先はConExを理解しているかどうかに関係なく、宛先がパケット全体の整合性をチェックする可能性があるため、CDOは宛先IPスタックに転送される必要があります。
The ideas in this section are aspirational, not being essential to the use of ConEx for more general traffic management. However, once CDO information is present, the CDO header could optionally also be used in the data plane of any IP-aware forwarding node to mitigate flooding attacks.
このセクションのアイデアは志願であり、より一般的なトラフィック管理のためのConExの使用に不可欠ではありません。ただし、CDO情報が存在する場合は、CDOヘッダーをIP対応の転送ノードのデータプレーンでオプションで使用して、フラッディング攻撃を緩和することもできます。
Please note that ConEx is an experimental protocol and that any kind of mechanism that reacts to information provided by the ConEx protocol needs to be evaluated in experimentation as well. This is also true, or especially true, for the preferential drop mechanism described below.
ConExは実験的なプロトコルであり、ConExプロトコルによって提供される情報に反応するあらゆる種類のメカニズムも実験で評価する必要があることに注意してください。これは、以下で説明する優先ドロップメカニズムにも当てはまります。
Dropping packets preferentially that are not ConEx-capable or do not carry a ConEx mark can be beneficial to mitigate flooding attacks as ConEx-Marked packets can be assumed to be already restricted by a ConEx ingress policer as further described in [RFC7713]. Therefore, the following ConEx-based preferential dropping scheme is proposed:
[RFC7713]で詳しく説明されているように、ConExマーキングされたパケットはConEx入力ポリサーによってすでに制限されていると想定できるため、ConEx対応ではない、またはConExマークを持たないパケットを優先的にドロップすることは、フラッディング攻撃を軽減するのに役立ちます。したがって、次のConExベースの優先ドロップスキームが提案されています。
If a router queue experiences a very high load so that it has to drop arriving packets, it MAY preferentially drop packets within the same DiffServ Per-Hop Behavior (PHB) using the preference order given in Table 1 (1 means drop first). Additionally, if a router implements preferential drop based on ConEx, it SHOULD also support ECN marking. Even though preferential dropping can be difficult to implement on some hardware, if nowhere else, routers at the egress of a network SHOULD implement preferential drop based on ConEx markings (stronger than the MAY above).
ルーターキューに非常に高い負荷がかかって到着パケットをドロップしなければならない場合、表1に示す優先順位を使用して、同じDiffServ Per-Hop Behavior（PHB）内のパケットを優先的にドロップできます（1は最初にドロップを意味します）。さらに、ルーターがConExに基づく優先ドロップを実装する場合、ECNマーキングもサポートする必要があります（SHOULD）。一部のハードウェアで優先ドロップを実装するのは難しい場合がありますが、他にない場合でも、ネットワークの出口にあるルーターは、ConExマーキング（上記のMAYよりも強い）に基づいて優先ドロップを実装する必要があります（SHOULD）。
+----------------------+----------------+
| | Preference |
+----------------------+----------------+
| Not-ConEx or no CDO | 1 (drop first) |
| X (but not L,E or C) | 2 |
| X and L,E or C | 3 |
+----------------------+----------------+
Table 1: Drop Preference for ConEx Packets
表1：ConExパケットのドロップ設定
A flooding attack is inherently about congestion of a resource. As load focuses on a victim, upstream queues grow, requiring honest sources to pre-load packets with a higher fraction of ConEx marks.
フラッディング攻撃は、本質的にリソースの輻輳に関するものです。負荷が被害者に焦点を合わせると、上流のキューが大きくなり、正直なソースがConExマークの割合が高いパケットを事前にロードする必要があります。
If ECN marking is supported by downstream queues, preferential dropping provides the most benefits because, if the queue is so congested that it drops traffic, it will be CE-marking 100% of any forwarded traffic. Honest sources will therefore be sending 100% ConEx E-marked packets (and subject to rate-limiting at an ingress policer).
ECNマーキングがダウンストリームキューでサポートされている場合、優先ドロップは、キューが輻輳してトラフィックをドロップする場合、転送されたトラフィックの100％をCEマーキングするため、最もメリットがあります。したがって、正直な送信元は、100％のConEx Eマーク付きパケットを送信します（入力ポリサーでのレート制限の対象となります）。
Senders under malicious control can either do the same as honest sources and be rate-limited at ingress, or they can understate congestion and not set the E bit.
悪意のある制御下にある送信者は、正直な送信元と同じことを行い、入力時にレート制限されるか、輻輳を過小評価してEビットを設定しない場合があります。
If the preferential drop ranking is implemented on queues, these queues will reserve E/L-marked traffic until last. So, the traffic from malicious sources will all be automatically dropped first. Either way, malicious sources cannot send more than honest sources.
優先ドロップランキングがキューに実装されている場合、これらのキューは最後までE / Lマークされたトラフィックを予約します。したがって、悪意のあるソースからのトラフィックはすべて最初に自動的にドロップされます。いずれにせよ、悪意のあるソースは正直なソース以上のものを送信することはできません。
Therefore, ConEx-based preferential dropping as described above discriminates against attack traffic if done as part of the overall policing framework as described in [RFC7713].
したがって、上記で説明したConExベースの優先ドロップは、[RFC7713]で説明されているように、全体的なポリシングフレームワークの一部として行われた場合、攻撃トラフィックを識別します。
[RFC7713] describes the overall audit framework for assuring that ConEx markings truly reflect actual path congestion and [CONEX-AUDIT] provides further details on the handling of audit signals. This section focuses purely on the security of the encoding chosen for ConEx markings.
[RFC7713]は、ConExマーキングが実際のパスの輻輳を本当に反映していることを保証するための監査フレームワーク全体を説明し、[CONEX-AUDIT]は監査信号の処理に関する詳細を提供します。このセクションでは、ConExマーキング用に選択されたエンコーディングのセキュリティにのみ焦点を当てています。
The CDO Option Type is defined with a chg bit set to zero as described in Section 4. If IPsec AH is used, a zero chg bit causes AH to cover the CDO option so that its end-to-end integrity can be verified, as explained in Section 4.
CDOオプションタイプは、セクション4で説明されているように、chgビットがゼロに設定されて定義されます。IPsecAHが使用される場合、0のchgビットにより、AHはCDOオプションをカバーし、エンドツーエンドの整合性を検証できます。セクション4で説明します。
This document specifies that the Reserved field in the CDO must be ignored and forwarded unchanged even if it does not contain all zeroes. The Reserved field is also required to sit outside the Encapsulating Security Payload (ESP), at least in transport mode (see Section 7). This allows the sender to use the Reserved field as a 4-bit-per-packet covert channel to send information to an on-path node outside the control of IPsec. However, a covert channel is only a concern if it can circumvent IPsec in tunnel mode and, in the tunnel mode case, ESP would close the covert channel as outlined in Section 7.
このドキュメントでは、CDOのReservedフィールドはすべてゼロでなくても、無視して変更せずに転送する必要があることを規定しています。予約フィールドは、少なくともトランスポートモードでは、カプセル化セキュリティペイロード（ESP）の外側に配置することも必要です（セクション7を参照）。これにより、送信者はReservedフィールドをパケットあたり4ビットの秘密チャネルとして使用して、IPsecの制御外のパス上のノードに情報を送信できます。ただし、隠れチャネルは、トンネルモードでIPsecを回避できる場合にのみ問題となり、トンネルモードの場合、ESPはセクション7で概説されているように隠れチャネルを閉じます。
The IPv6 ConEx destination option is used for carrying ConEx markings. This document uses the experimental option type 0x1E (as assigned in IANA's "Destination Options and Hop-by-Hop Options" registry) with the act bits set to 00 and the chg bit set to 0 for realizing this option. No further allocation action is required from IANA at this time.
IPv6 ConEx宛先オプションは、ConExマーキングを伝送するために使用されます。このドキュメントでは、このオプションを実現するために、actビットを00に設定し、chgビットを0に設定して、実験的なオプションタイプ0x1E（IANAの「宛先オプションとホップバイホップオプション」レジストリで割り当てられている）を使用します。現時点では、IANAからの追加の割り当てアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<http：// www。 rfc-editor.org/info/rfc3168>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<http://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements", RFC 7713, DOI 10.17487/RFC7713, December 2015, <http://www.rfc-editor.org/info/rfc7713>.
[RFC7713] Mathis、M。、およびB. Briscoe、「Congestion Exposure（ConEx）Concepts、Abstract Mechanism、and Requirements」、RFC 7713、DOI 10.17487 / RFC7713、December 2015、<http://www.rfc-editor.org / info / rfc7713>。
[CONEX-AUDIT] Wagner, D. and M. Kuehlewind, "Auditing of Congestion Exposure (ConEx) signals", Work in Progress, draft-wagner-conex-audit-02, April 2016.
[CONEX-AUDIT] Wagner、D。、およびM. Kuehlewind、「Congestion Exposure（ConEx）信号の監査」、Work in Progress、draft-wagner-conex-audit-02、2016年4月。
[HBH-HEADER] Baker, F., "IPv6 Hop-by-Hop Options Extension Header", Work in Progress, draft-ietf-6man-hbh-header-handling-03, Marcy 2016.
[HBH-HEADER]ベイカー、F。、「IPv6ホップバイホップオプション拡張ヘッダー」、作業中、draft-ietf-6man-hbh-header-handling-03、Marcy 2016。
[RFC7786] Kuehlewind, M., Ed. and R. Scheffenegger, "TCP Modifications for Congestion Exposure (ConEx)", RFC 7786, DOI 10.17487/RFC7786, May 2016, <http://www.rfc-editor.org/info/rfc7786>.
[RFC7786]キュールウィンド、M。、エド。およびR. Scheffenegger、「輻輳露出（ConEx）のTCP変更」、RFC 7786、DOI 10.17487 / RFC7786、2016年5月、<http://www.rfc-editor.org/info/rfc7786>。
Acknowledgements
謝辞
The authors would like to thank David Wagner, Marcelo Bagnulo, Ingemar Johansson, Joel Halpern, John Leslie, Martin Stiemerling, Robert Sparks, Ron Bonica, Brian Haberman, Kathleen Moriarty, Bob Hinden, Ole Troan, and Brian Carpenter for the discussions that made this document better.
著者は、議論を行ったDavid Wagner、Marcelo Bagnulo、Ingemar Johansson、Joel Halpern、John Leslie、Martin Stiemerling、Robert Sparks、Ron Bonica、Brian Haberman、Kathleen Moriarty、Bob Hinden、Ole Troan、およびBrian Carpenterに感謝します。このドキュメントの方が優れています。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal、Quebec Canada
Email: suresh.krishnan@ericsson.com
Mirja Kuehlewind ETH Zurich
私があなたを訪問するときにカーランドをお願いします
Email: mirja.kuehlewind@tik.ee.ethz.ch
Bob Briscoe Simula Research Laboratory
ボブ・ブリスコ・シムラ研究所
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Carlos Ralli Ucendo Telefonica
カルロス・ラリ・ウセンド・テレフォニカ
Email: ralli@tid.es