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
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)
拥塞暴露的IPv6目标选项（ConEx）
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.
拥塞暴露（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.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
拥塞暴露（ConEx）[RFC7713]是一种机制，发送方通过该机制向网络通知相同流中先前的数据包遇到的拥塞。本文档指定了一个IPv6目标选项[RFC2460]，可用于在IPv6数据报中执行ConEx标记。
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 wire协议。ConEx信息可由路径上的任何网络元件使用，例如，进行流量管理或出口管制。此外，该信息可能会被检查发送方信号完整性的审计功能使用。此外，支持ConEx信令的每个传输协议将需要精确指定传输设置ConEx标记的时间（例如，[RFC7786]中指定了TCP的行为）。
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.
由于需要建立基础设施以确定本实验的结果，本实验的持续时间预计不少于本文件出版后两年。试验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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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:
[RFC7713]中给出了理想的具体ConEx有线协议的一组要求。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可以通过Internet增量部署。
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标记的数据包不会因选择不当的机制而面临任何不适当的延迟或丢弃。
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信息的四种解决方案：逐跳选项、目标选项、使用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意识的网络设备，包括策略或审计设备，可能必须遵循将（扩展）头链接到内部IP头的方式来查找ConEx信息。如第5节所述，这种选择是ConEx感知网络节点的快速路径性能和可见性之间的折衷。
Please note that the IPv6 specification [RFC2460] does not require or expect intermediate nodes to inspect destination options such as the
请注意，IPv6规范[RFC2460]不要求或期望中间节点检查目标选项，例如
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.
ConEx目的地选项（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意识的发送方发送的IPv6数据报中，以便通知路径上具有ConEx意识的节点相同流量中较早时遇到的拥塞或将来遇到拥塞的预期风险。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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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位标识符。设置为分配给实验工作的值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
电子钻头
When this bit is set, the transport sender has experienced congestion signaled using Explicit Congestion Notification (ECN) [RFC3168].
设置此位时，传输发送方经历了使用显式拥塞通知（ECN）[RFC3168]发出的拥塞信号。
C Bit
钻头
When this bit is set, the transport sender is building up congestion credit in the audit function.
设置此位后，传输发送方将在审核功能中建立拥塞信用。
Reserved (res)
保留（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.
当前规范中未使用这四位。发送方将它们设置为零，接收方将忽略它们。
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位（第三高阶位）设置为零，这意味着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]（如果存在）之前的第一个选项。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位为零，则所有其他三位都未定义，因此必须忽略，并由网络节点不变地转发。X位设置为零意味着连接具有ConEx功能，但在审计功能中确定ConEx信息时，不得对该数据包进行计数。如果（当前）没有可用的拥塞反馈，则可能出现这种情况，例如，在TCP中，如果一个端点在一段时间内一直在接收数据，但只发送纯ACK（无用户数据），则会出现这种情况。这是因为纯ACK不会提前序列号，因此接收它们的TCP端点无法可靠地判断是否有任何ACK由于拥塞而丢失。纯TCP确认也不能被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位，则可以设置其他三位（L、E或C）中的任何一位。无论何时设置这些位中的一位，都应计算该IP数据包（包括直接封装CDO的IP报头和IP报头封装的所有内容）所承载的字节数，以确定拥塞或信用信息。在IPv6中，通过将数字40（IPv6报头的长度，以字节为单位）与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
信用信号表示可能出现拥堵。如果发生拥塞事件，将消耗[RFC7713]中所述的相应数量的信用。因此，启用ConEx的发送方应在任何拥塞事件之前发出足够的信用信号，以覆盖可能发生的丢失或CE标记字节的（估计最大）数量
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].
在这种拥挤事件中发生。此估计取决于在决定适当的发送速率（拥塞控制）时使用的启发式和发送方的攻击性。请注意，最大的拥塞风险是飞行中的所有数据包丢失或带有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.
原则上，这三个位（L、E或C）都可以设置在同一个数据包中。在这种情况下，必须为每个相应的ConEx信息计数器计算一次数据包大小。
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中的所有剩余位保留供将来使用（当前为八位选项空间的最后四位）。ConEx发送方应将CDO中的保留位设置为零。其他节点必须忽略这些位，而ConEx感知的中间节点必须不变地转发它们，不管它们的值是什么。它们可以记录非零保留字段的存在。
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的数据包发送到多播地址。具有ConEx功能的网络节点必须将设置了X标志的多播数据包视为没有CDO的等效数据包，并且它们应原封不动地转发该数据包。
As stated in [RFC7713] (see Section 3.3, item N on network-layer requirements), protocol specs should describe any warning or error
如[RFC7713]所述（见第3.3节，网络层要求中的第N项），协议规范应描述任何警告或错误
messages relevant to the encoding. There are no warnings or error messages associated with the CDO.
与编码相关的消息。没有与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放置在一个相当确定的位置。为了便于在支持ConEx的路由器上进行转发，使用CDO发送IPv6数据报的支持ConEx的发送方应将CDO作为第一个目标选项放置在目标选项标头中。
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复制到外部标头，因为这会更改将要计数的字节数。然而，如果协调隧道入口和ConEx节点的配置，则它可以将CDO复制到外部报头，以便通过后续路径上的ConEx功能促进可见性。这就权衡了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。任何内部CDO中的信息始终被认为是正确的，即使它与任何外部CDO不同。因此，去封装器可以剥离外部CDO，而无需与内部CDO进行比较。去封装器可对两者进行比较，并可记录它们不同的任何情况。然而，如果外部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信息的网络节点应搜索封装的IP头，直到找到CDO。在任何特定网络位置，对于给定隧道端点集之间的所有数据包，搜索的最大必要深度可能相同。
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审计会无声地丢弃），并且可追踪性更低（因为TTL是要更改的，而CDO不是）。
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节规定，如果ESP用于在传输模式下对其他传输信息进行加密，则CDO将被置于AH和/或ESP报头之前的目的地选项报头中，以便ConEx信息保持在清除状态[RFC4301]。一般来说，IPv6数据包内的目的地选项报头可以放置在两个可能的位置，即[RFC2460]第4.1节所述的路由报头之前或ESP/AH报头之后。如果CDO被放置在后一个位置，并且ESP报头与加密一起使用，则ConEx感知的中间节点将无法查看和解释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。CDO仍然必须转发到目标IP堆栈，因为目标可能会检查整个数据包的完整性，而不管它是否理解ConEx。
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
请注意，ConEx是一个实验性协议，任何对ConEx协议提供的信息作出反应的机制都需要在实验中进行评估。这是
also true, or especially true, for the preferential drop mechanism described below.
对于下文所述的优先下降机制也是如此，或尤其如此。
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:
优先丢弃不支持ConEx或不带有ConEx标记的数据包有助于缓解泛洪攻击，因为可以假设ConEx标记的数据包已经受到ConEx入口策略的限制，如[RFC7713]中进一步描述的。因此，建议采用以下基于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中给出的优先顺序（1表示先丢弃），优先丢弃相同DiffServ每跳行为（PHB）内的数据包。此外，如果路由器基于ConEx实现优先丢弃，它还应该支持ECN标记。即使在某些硬件上很难实现优先丢包，如果没有其他硬件，网络出口处的路由器也应该基于ConEx标记实现优先丢包（比上面的5月更强）。
+----------------------+----------------+
| | Preference |
+----------------------+----------------+
| Not-ConEx or no CDO | 1 (drop first) |
| X (but not L,E or C) | 2 |
| X and L,E or C | 3 |
+----------------------+----------------+
+----------------------+----------------+
| | 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].
因此，如[RFC7713]所述，如果作为整体警务框架的一部分进行，则如上所述的基于ConEx的优先丢弃会歧视攻击流量。
[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选项类型定义为chg位设置为零，如第4节所述。如果使用IPsec AH，零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中的保留字段不包含全零，也必须忽略该字段，并以不变方式转发。保留字段也必须位于封装安全有效负载（ESP）之外，至少在传输模式下（见第7节）。这允许发送方将保留字段用作每包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标记。本文档使用实验选项类型0x1E（在IANA的“目的地选项和逐跳选项”注册表中分配），act位设置为00，chg位设置为0，以实现此选项。目前不需要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]Ramakrishnan，K.，Floyd，S.，和D.Black，“向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]Kent，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]Kent，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，“拥堵暴露（ConEx）概念、抽象机制和要求”，RFC 7713，DOI 10.17487/RFC7713，2015年12月<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，“拥堵暴露（CONEX）信号的审计”，正在进行的工作，草稿-Wagner-CONEX-AUDIT-022016年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]Baker，F.，“IPv6逐跳选项扩展头”，正在进行中，草稿-ietf-6man-HBH-HEADER-handling-03，2016年3月。
[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]Kuehlewind，M.，Ed.和R.Scheffenegger，“拥塞暴露的TCP修改（ConEx）”，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加拿大魁北克皇家山Decarie镇8400大道
Email: suresh.krishnan@ericsson.com
Email: suresh.krishnan@ericsson.com
Mirja Kuehlewind ETH Zurich
苏黎世米尔贾·库勒温德酒店
Email: mirja.kuehlewind@tik.ee.ethz.ch
Email: mirja.kuehlewind@tik.ee.ethz.ch
Bob Briscoe Simula Research Laboratory
鲍勃·布里斯科Simula研究实验室
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/
Carlos Ralli Ucendo Telefonica
卡洛斯·拉利·乌森多电视台
Email: ralli@tid.es
Email: ralli@tid.es