Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 6040 BT
Updates: 3168, 4301, 4774 November 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Briscoe
Request for Comments: 6040 BT
Updates: 3168, 4301, 4774 November 2010
Category: Standards Track
ISSN: 2070-1721
Tunnelling of Explicit Congestion Notification
显式拥塞通知的隧道传输
Abstract
摘要
This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing. On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues.
本文档重新定义了IP头的显式拥塞通知（ECN）字段在进入和退出IP隧道中的任何IP时的构造方式。在封装方面，它更新RFC 3168，使IP隧道（v4或v6）中的所有IP符合RFC 4301 IPsec ECN处理。在脱封时，它更新RFC 3168和RFC 4301，以便为以前未使用的内外头组合添加新行为。新规则确保ECN字段在隧道中正确传播，无论它是用来表示一个或两个严重程度的拥塞；而以前，只支持一种严重性级别。隧道端点可以按任何顺序更新，而不会影响ECN字段的现有使用，从而确保向后兼容性。尽管如此，想要支持两个严重级别（例如，拥塞前通知——PCN）的运营商可能需要遵守此新规范。其中包括对这些变化的原因及其影响的透彻分析。在新规则不符合特定需求的情况下，RFC 4774给出了设计备用ECN语义的指南，本文档将其扩展到包括隧道问题。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6040.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6040.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Terminology .....................................................6
3. Summary of Pre-Existing RFCs ....................................7
3.1. Encapsulation at Tunnel Ingress ............................7
3.2. Decapsulation at Tunnel Egress .............................8
4. New ECN Tunnelling Rules ........................................9
4.1. Default Tunnel Ingress Behaviour ..........................10
4.2. Default Tunnel Egress Behaviour ...........................10
4.3. Encapsulation Modes .......................................12
4.4. Single Mode of Decapsulation ..............................14
5. Updates to Earlier RFCs ........................................15
5.1. Changes to RFC 4301 ECN Processing ........................15
5.2. Changes to RFC 3168 ECN Processing ........................16
5.3. Motivation for Changes ....................................17
5.3.1. Motivation for Changing Encapsulation ..............17
5.3.2. Motivation for Changing Decapsulation ..............18
6. Backward Compatibility .........................................21
6.1. Non-Issues Updating Decapsulation .........................21
6.2. Non-Update of RFC 4301 IPsec Encapsulation ................21
6.3. Update to RFC 3168 Encapsulation ..........................22
7. Design Principles for Alternate ECN Tunnelling Semantics .......22
8. Security Considerations ........................................24
9. Conclusions ....................................................26
10. Acknowledgements ..............................................26
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................27
Appendix A. Early ECN Tunnelling RFCs ............................29
Appendix B. Design Constraints ...................................29
B.1. Security Constraints ......................................29
B.2. Control Constraints .......................................31
B.3. Management Constraints ....................................32
Appendix C. Contribution to Congestion across a Tunnel ...........33
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer ................................................34
Appendix E. Open Issues ..........................................35
1. Introduction ....................................................4
1.1. Scope ......................................................5
2. Terminology .....................................................6
3. Summary of Pre-Existing RFCs ....................................7
3.1. Encapsulation at Tunnel Ingress ............................7
3.2. Decapsulation at Tunnel Egress .............................8
4. New ECN Tunnelling Rules ........................................9
4.1. Default Tunnel Ingress Behaviour ..........................10
4.2. Default Tunnel Egress Behaviour ...........................10
4.3. Encapsulation Modes .......................................12
4.4. Single Mode of Decapsulation ..............................14
5. Updates to Earlier RFCs ........................................15
5.1. Changes to RFC 4301 ECN Processing ........................15
5.2. Changes to RFC 3168 ECN Processing ........................16
5.3. Motivation for Changes ....................................17
5.3.1. Motivation for Changing Encapsulation ..............17
5.3.2. Motivation for Changing Decapsulation ..............18
6. Backward Compatibility .........................................21
6.1. Non-Issues Updating Decapsulation .........................21
6.2. Non-Update of RFC 4301 IPsec Encapsulation ................21
6.3. Update to RFC 3168 Encapsulation ..........................22
7. Design Principles for Alternate ECN Tunnelling Semantics .......22
8. Security Considerations ........................................24
9. Conclusions ....................................................26
10. Acknowledgements ..............................................26
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................27
Appendix A. Early ECN Tunnelling RFCs ............................29
Appendix B. Design Constraints ...................................29
B.1. Security Constraints ......................................29
B.2. Control Constraints .......................................31
B.3. Management Constraints ....................................32
Appendix C. Contribution to Congestion across a Tunnel ...........33
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0)
Outer ................................................34
Appendix E. Open Issues ..........................................35
Explicit congestion notification (ECN [RFC3168]) allows a forwarding element (e.g., a router) to notify the onset of congestion without having to drop packets. Instead, it can explicitly mark a proportion of packets in the two-bit ECN field in the IP header (Table 1 recaps the ECN codepoints).
显式拥塞通知（ECN[RFC3168]）允许转发元件（例如路由器）在不必丢弃数据包的情况下通知拥塞的开始。相反，它可以在IP报头的两位ECN字段中显式标记一定比例的数据包（表1重述了ECN代码点）。
The outer header of an IP packet can encapsulate one or more IP headers for tunnelling. A forwarding element using ECN to signify congestion will only mark the immediately visible outer IP header. When a tunnel decapsulator later removes this outer header, it follows rules to propagate congestion markings by combining the ECN fields of the inner and outer IP header into one outgoing IP header.
IP包的外部报头可以封装一个或多个用于隧道的IP报头。使用ECN表示拥塞的转发元素将只标记立即可见的外部IP头。当隧道解封装器稍后删除此外部标头时，它将遵循规则，通过将内部和外部IP标头的ECN字段组合到一个传出IP标头中来传播拥塞标记。
This document updates those rules for IPsec [RFC4301] and non-IPsec [RFC3168] tunnels to add new behaviours for previously unused combinations of inner and outer headers. It also updates the ingress behaviour of RFC 3168 tunnels to match that of RFC 4301 tunnels. Tunnel endpoints complying with the updated rules will be backward compatible when interworking with tunnel endpoints complying with RFC 4301, RFC 3168, or any earlier specification.
本文档更新了IPsec[RFC4301]和非IPsec[RFC3168]隧道的规则，以便为以前未使用的内部和外部头的组合添加新行为。它还更新了RFC 3168隧道的入口行为，以匹配RFC 4301隧道的入口行为。当与符合RFC 4301、RFC 3168或任何早期规范的隧道端点交互时，符合更新规则的隧道端点将向后兼容。
When ECN and its tunnelling was defined in RFC 3168, only the minimum necessary changes to the ECN field were propagated through tunnel endpoints -- just enough for the basic ECN mechanism to work. This was due to concerns that the ECN field might be toggled to communicate between a secure site and someone on the public Internet -- a covert channel. This was because a mutable field like ECN cannot be protected by IPsec's integrity mechanisms -- it has to be able to change as it traverses the Internet.
当在RFC3168中定义ECN及其隧道时，只有对ECN字段的最小必要更改通过隧道端点传播——刚好足以使基本ECN机制工作。这是因为担心ECN字段可能被切换到安全站点和公共互联网上的某个人之间的通信——一个隐蔽通道。这是因为像ECN这样的可变字段不能受到IPsec完整性机制的保护——它必须能够在穿越Internet时进行更改。
Nonetheless, the latest IPsec architecture [RFC4301] considered a bandwidth limit of two bits per packet on a covert channel to be a manageable risk. Therefore, for simplicity, an RFC 4301 ingress copied the whole ECN field to encapsulate a packet. RFC 4301 dispensed with the two modes of RFC 3168, one which partially copied the ECN field, and the other which blocked all propagation of ECN changes.
尽管如此，最新的IPsec体系结构[RFC4301]认为隐蔽通道上每个数据包两位的带宽限制是一个可管理的风险。因此，为简单起见，rfc4301入口复制整个ECN字段以封装分组。RFC 4301省去了RFC 3168的两种模式，一种是部分复制ECN字段，另一种是阻止ECN更改的所有传播。
Unfortunately, this entirely reasonable sequence of standards actions resulted in a perverse outcome; non-IPsec tunnels (RFC 3168) blocked the two-bit covert channel, while IPsec tunnels (RFC 4301) did not -- at least not at the ingress. At the egress, both IPsec and non-IPsec tunnels still partially restricted propagation of the full ECN field.
不幸的是，这种完全合理的标准行动顺序导致了反常的结果；非IPsec隧道（RFC 3168）阻止了两位隐蔽通道，而IPsec隧道（RFC 4301）没有阻止——至少在入口没有。在出口处，IPsec和非IPsec隧道仍然部分限制整个ECN字段的传播。
The trigger for the changes in this document was the introduction of pre-congestion notification (PCN [RFC5670]) to the IETF Standards Track. PCN needs the ECN field to be copied at a tunnel ingress and it needs four states of congestion signalling to be propagated at the egress, but pre-existing tunnels only propagate three in the ECN field.
本文件中更改的触发因素是将拥塞前通知（PCN[RFC5670]）引入IETF标准轨道。PCN需要在隧道入口复制ECN字段，并且需要在出口传播四种拥塞信号状态，但现有隧道在ECN字段中仅传播三种。
This document draws on currently unused (CU) combinations of inner and outer headers to add tunnelling of four-state congestion signalling to RFC 3168 and RFC 4301. Operators of tunnels who specifically want to support four states can require that all their tunnels comply with this specification. However, this is not a fork in the RFC series. It is an update that can be deployed first by those that need it, and subsequently by all tunnel endpoint implementations (RFC 4301, RFC 3168, RFC 2481, RFC 2401, RFC 2003), which can safely be updated to this new specification as part of general code maintenance. This will gradually add support for four congestion states to the Internet. Existing three state schemes will continue to work as before.
本文件利用当前未使用的（CU）内部和外部头的组合，将四状态拥塞信号的隧道传输添加到RFC 3168和RFC 4301。特别希望支持四个州的隧道运营商可要求其所有隧道符合本规范。但是，这不是RFC系列中的fork。它是一个更新，可以首先由需要它的人部署，然后由所有隧道端点实现（RFC 4301、RFC 3168、RFC 2481、RFC 2401、RFC 2003）部署，作为一般代码维护的一部分，它可以安全地更新到此新规范。这将逐渐增加对互联网四个拥塞状态的支持。现有的三州计划将一如既往地发挥作用。
In fact, this document is the opposite of a fork. At the same time as supporting a fourth state, the opportunity has been taken to draw together divergent ECN tunnelling specifications into a single consistent behaviour, harmonising differences such as perverse covert channel treatment. Then, any tunnel can be deployed unilaterally, and it will support the full range of congestion control and management schemes without any modes or configuration. Further, any host or router can expect the ECN field to behave in the same way, whatever type of tunnel might intervene in the path.
事实上，此文档与fork相反。在支持第四个国家的同时，利用这个机会将不同的ECN隧道规范整合成一个单一的一致行为，协调不同之处，如反常的隐蔽通道处理。然后，任何隧道都可以单方面部署，它将支持全方位的拥塞控制和管理方案，而无需任何模式或配置。此外，任何主机或路由器都可以期望ECN字段以相同的方式运行，不管路径中可能存在何种类型的隧道。
This document only concerns wire protocol processing of the ECN field at tunnel endpoints and makes no changes or recommendations concerning algorithms for congestion marking or congestion response.
本文档仅涉及隧道端点处ECN字段的有线协议处理，未对拥塞标记或拥塞响应算法进行任何更改或建议。
This document specifies common ECN field processing at encapsulation and decapsulation for any IP-in-IP tunnelling, whether IPsec or non-IPsec tunnels. It applies irrespective of whether IPv4 or IPv6 is used for either the inner or outer headers. It applies for packets with any destination address type, whether unicast or multicast. It applies as the default for all Diffserv per-hop behaviours (PHBs), unless stated otherwise in the specification of a PHB (but Section 4 strongly deprecates such exceptions). It is intended to be a good trade off between somewhat conflicting security, control, and management requirements.
本文档为IP隧道中的任何IP（无论是IPsec隧道还是非IPsec隧道）指定封装和解封时的通用ECN字段处理。无论内部报头或外部报头使用IPv4还是IPv6，它都适用。它适用于任何目的地址类型的数据包，无论是单播还是多播。除非PHB规范中另有规定（但第4节强烈反对此类例外），否则它将作为所有区分服务每跳行为（PHB）的默认设置。它的目的是在一些相互冲突的安全、控制和管理需求之间进行良好的权衡。
[RFC2983] is a comprehensive primer on differentiated services and tunnels. Given ECN raises similar issues to differentiated services when interacting with tunnels, useful concepts introduced in RFC 2983 are used throughout, with brief recaps of the explanations where necessary.
[RFC2983]是关于差异化服务和隧道的全面入门。鉴于ECN在与隧道交互时会对差异化服务提出类似的问题，RFC 2983中引入的有用概念贯穿始终，并在必要时简要回顾解释。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Table 1 recaps the names of the ECN codepoints [RFC3168].
表1概括了ECN代码点的名称[RFC3168]。
+------------------+----------------+---------------------------+
| Binary codepoint | Codepoint name | Meaning |
+------------------+----------------+---------------------------+
| 00 | Not-ECT | Not ECN-capable transport |
| 01 | ECT(1) | ECN-capable transport |
| 10 | ECT(0) | ECN-capable transport |
| 11 | CE | Congestion experienced |
+------------------+----------------+---------------------------+
+------------------+----------------+---------------------------+
| Binary codepoint | Codepoint name | Meaning |
+------------------+----------------+---------------------------+
| 00 | Not-ECT | Not ECN-capable transport |
| 01 | ECT(1) | ECN-capable transport |
| 10 | ECT(0) | ECN-capable transport |
| 11 | CE | Congestion experienced |
+------------------+----------------+---------------------------+
Table 1: Recap of Codepoints of the ECN Field [RFC3168] in the IP Header
表1:IP报头中ECN字段[RFC3168]的代码点概述
Further terminology used within this document:
本文件中使用的其他术语：
Encapsulator: The tunnel endpoint function that adds an outer IP header to tunnel a packet (also termed the 'ingress tunnel endpoint' or just the 'ingress' where the context is clear).
封装器：隧道端点函数，用于将外部IP头添加到数据包隧道中（也称为“入口隧道端点”或上下文清晰的“入口”）。
Decapsulator: The tunnel endpoint function that removes an outer IP header from a tunnelled packet (also termed the 'egress tunnel endpoint' or just the 'egress' where the context is clear).
Decapsulator：隧道端点函数，用于从隧道数据包（也称为“出口隧道端点”或上下文清晰的“出口”）中删除外部IP头。
Incoming header: The header of an arriving packet before encapsulation.
传入报头：封装前到达数据包的报头。
Outer header: The header added to encapsulate a tunnelled packet.
外部报头：为封装隧道包而添加的报头。
Inner header: The header encapsulated by the outer header.
内部收割台：由外部收割台封装的收割台。
Outgoing header: The header constructed by the decapsulator using logic that combines the fields in the outer and inner headers.
传出标头：由decapsulator使用组合外部标头和内部标头中的字段的逻辑构造的标头。
Copying ECN: On encapsulation, setting the ECN field of the new outer header to be a copy of the ECN field in the incoming header.
复制ECN：封装时，将新外部标头的ECN字段设置为传入标头中ECN字段的副本。
Zeroing ECN: On encapsulation, clearing the ECN field of the new outer header to Not-ECT ("00").
将ECN归零：封装时，将新外部标头的ECN字段清除为Not ECT（“00”）。
Resetting ECN: On encapsulation, setting the ECN field of the new outer header to be a copy of the ECN field in the incoming header except the outer ECN field is set to the ECT(0) codepoint if the incoming ECN field is CE.
重置ECN：封装时，将新外部标头的ECN字段设置为传入标头中ECN字段的副本，但如果传入ECN字段为CE，则将外部ECN字段设置为ECT（0）代码点。
This section is informative not normative, as it recaps pre-existing RFCs. Earlier relevant RFCs that were either Experimental or incomplete with respect to ECN tunnelling (RFC 2481, RFC 2401, and RFC 2003) are briefly outlined in Appendix A. The question of whether tunnel implementations used in the Internet comply with any of these RFCs is not discussed.
本节是信息性的而非规范性的，因为它概述了先前存在的RFC。关于ECN隧道（RFC 2481、RFC 2401和RFC 2003）的试验性或不完整的早期相关RFC在附录A中作了简要概述。未讨论互联网中使用的隧道实施是否符合任何这些RFC的问题。
At the encapsulator, the controversy has been over whether to propagate information about congestion experienced on the path so far into the outer header of the tunnel.
在封装商，争论的焦点在于是否将目前为止在路径上经历的拥塞信息传播到隧道的外部标头中。
Specifically, RFC 3168 says that, if a tunnel fully supports ECN (termed a 'full-functionality' ECN tunnel in [RFC3168]), the encapsulator must not copy a CE marking from the incoming header into the outer header that it creates. Instead, the encapsulator must set the outer header to ECT(0) if the ECN field is marked CE in the arriving IP header. We term this 'resetting' a CE codepoint.
具体而言，RFC 3168规定，如果隧道完全支持ECN（在[RFC3168]中称为“完整功能”ECN隧道），则封装器不得将CE标记从传入标头复制到其创建的外部标头中。相反，如果到达的IP报头中的ECN字段标记为CE，则封装器必须将外部报头设置为ECT（0）。我们称之为“重置”CE码点。
However, the new IPsec architecture in [RFC4301] reverses this rule, stating that the encapsulator must simply copy the ECN field from the incoming header to the outer header.
然而，[RFC4301]中的新IPsec架构推翻了这一规则，指出封装器必须简单地将ECN字段从传入报头复制到外部报头。
RFC 3168 also provided a Limited Functionality mode that turns off ECN processing over the scope of the tunnel by setting the outer header to Not-ECT ("00"). Then, such packets will be dropped to indicate congestion, rather than marked with ECN. This is necessary for the ingress to interwork with legacy decapsulators ([RFC2481], [RFC2401], and [RFC2003]) that do not propagate ECN markings added to the outer header. Otherwise, such legacy decapsulators would throw away congestion notifications before they reached the transport layer.
RFC 3168还提供了一种有限功能模式，通过将外部标头设置为Not ECT（“00”）来关闭隧道范围内的ECN处理。然后，这些数据包将被丢弃以指示拥塞，而不是用ECN标记。这是入口与传统去封装器（[RFC2481]、[RFC2401]和[RFC2003]）互通所必需的，这些去封装器不会传播添加到外部标头的ECN标记。否则，这种传统的去封装器将在拥塞通知到达传输层之前丢弃它们。
Neither Limited Functionality mode nor Full Functionality mode are used by an RFC 4301 IPsec encapsulator, which simply copies the incoming ECN field into the outer header. An earlier key-exchange phase ensures an RFC 4301 ingress will not have to interwork with a legacy egress that does not support ECN.
RFC 4301 IPsec封装器既不使用限制功能模式也不使用完全功能模式，它只是将传入的ECN字段复制到外部报头中。较早的密钥交换阶段确保RFC 4301入口不必与不支持ECN的传统出口互通。
These pre-existing behaviours are summarised in Figure 1.
图1总结了这些预先存在的行为。
+-----------------+-----------------------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+---------------+
| departing Inner | RFC 3168 ECN | RFC 3168 ECN | RFC 4301 IPsec|
| Header) | Limited | Full | |
| | Functionality | Functionality | |
+-----------------+---------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) | ECT(1) |
| CE | Not-ECT | ECT(0) | CE |
+-----------------+---------------+---------------+---------------+
+-----------------+-----------------------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+---------------+
| departing Inner | RFC 3168 ECN | RFC 3168 ECN | RFC 4301 IPsec|
| Header) | Limited | Full | |
| | Functionality | Functionality | |
+-----------------+---------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) | ECT(1) |
| CE | Not-ECT | ECT(0) | CE |
+-----------------+---------------+---------------+---------------+
Figure 1: IP-in-IP Encapsulation: Recap of Pre-Existing Behaviours
图1:IP-in-IP封装：先前存在的行为概述
RFC 3168 and RFC 4301 specify the decapsulation behaviour summarised in Figure 2. The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column).
RFC 3168和RFC 4301规定了图2中总结的脱封行为。传出报头中的ECN字段设置为相应到达的内部报头（行）和到达的外部报头（列）交叉处的代码点。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
RFC 3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
RFC 4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
| ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
| CE | CE | CE | CE | CE |
+---------+---------+------------+------------+------------+
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
RFC 3168->| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
RFC 4301->| Not-ECT | Not-ECT |Not-ECT |Not-ECT |Not-ECT |
| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
| ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE |
| CE | CE | CE | CE | CE |
+---------+---------+------------+------------+------------+
In pre-existing RFCs, the ECN field in the outgoing header was set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet was dropped where indicated.
在预先存在的RFC中，传出报头中的ECN字段设置为相应到达的内部报头（行）和到达的外部报头（列）交叉处的代码点，或者在指示的位置丢弃数据包。
Figure 2: IP in IP Decapsulation; Recap of Pre-Existing Behaviour
图2:IP-in-IP脱封；重述先前存在的行为
The behaviour in the table derives from the logic given in RFC 3168 and RFC 4301, briefly recapped as follows:
表中的行为源自RFC 3168和RFC 4301中给出的逻辑，简要概述如下：
o On decapsulation, if the inner ECN field is Not-ECT the outer is ignored. RFC 3168 (but not RFC 4301) also specified that the decapsulator must drop a packet with a Not-ECT inner and CE in the outer.
o 在解除封装时，如果内部ECN场不为ECT，则忽略外部ECN场。RFC 3168（但不是RFC 4301）还规定，去封装器必须丢弃内部为not ECT且外部为CE的数据包。
o In all other cases, if the outer is CE, the outgoing ECN field is set to CE; otherwise, the outer is ignored and the inner is used for the outgoing ECN field.
o 在所有其他情况下，如果外部为CE，则传出ECN字段设置为CE；否则，外部将被忽略，内部将用于传出ECN字段。
Section 9.2.2 of RFC 3168 also made it an auditable event for an IPsec tunnel "if the ECN Field is changed inappropriately within an IPsec tunnel...". Inappropriate changes were not specifically enumerated. RFC 4301 did not mention inappropriate ECN changes.
RFC 3168的第9.2.2节还将其作为IPsec隧道的可审核事件“如果IPsec隧道中的ECN字段被不适当地更改…”。未具体列举不适当的变更。RFC 4301未提及不适当的ECN变更。
The standards actions below in Section 4.1 (ingress encapsulation) and Section 4.2 (egress decapsulation) define new default ECN tunnel processing rules for any IP packet (v4 or v6) with any Diffserv codepoint.
下面第4.1节（入口封装）和第4.2节（出口去封装）中的标准操作为具有任何Diffserv码点的任何IP数据包（v4或v6）定义了新的默认ECN隧道处理规则。
If these defaults do not meet a particular requirement, an alternate ECN tunnelling scheme can be introduced as part of the definition of an alternate congestion marking scheme used by a specific Diffserv PHB (see [RFC4774] and Section 5 of [RFC3168]). When designing such alternate ECN tunnelling schemes, the principles in Section 7 should
如果这些默认值不满足特定要求，则可以引入备用ECN隧道方案，作为特定Diffserv PHB使用的备用拥塞标记方案定义的一部分（参见[RFC4774]和[RFC3168]第5节）。在设计此类备用ECN隧道方案时，应遵循第7节中的原则
be followed. However, alternate ECN tunnelling schemes SHOULD be avoided whenever possible as the deployment burden of handling exceptional PHBs in implementations of all affected tunnels should not be underestimated. There is no requirement for a PHB definition to state anything about ECN tunnelling behaviour if the default behaviour in the present specification is sufficient.
被跟踪。然而，应尽可能避免备用ECN隧道方案，因为不应低估在所有受影响隧道实施过程中处理异常PHB的部署负担。如果当前规范中的默认行为足够，则PHB定义无需说明ECN隧道行为。
Two modes of encapsulation are defined here; a REQUIRED 'normal mode' and a 'compatibility mode', which is for backward compatibility with tunnel decapsulators that do not understand ECN. Note that these are modes of the ingress tunnel endpoint only, not the whole tunnel. Section 4.3 explains why two modes are necessary and specifies the circumstances in which it is sufficient to solely implement normal mode.
这里定义了两种封装模式；所需的“正常模式”和“兼容模式”，用于与不理解ECN的隧道去封装器向后兼容。请注意，这些只是入口隧道端点的模式，而不是整个隧道。第4.3节解释了为什么需要两种模式，并规定了仅实施正常模式就足够的情况。
Whatever the mode, an encapsulator forwards the inner header without changing the ECN field.
无论采用何种模式，封装器都会在不更改ECN字段的情况下转发内部标头。
In normal mode, an encapsulator compliant with this specification MUST construct the outer encapsulating IP header by copying the two-bit ECN field of the incoming IP header. In compatibility mode, it clears the ECN field in the outer header to the Not-ECT codepoint (the IPv4 header checksum also changes whenever the ECN field is changed). These rules are tabulated for convenience in Figure 3.
在正常模式下，符合此规范的封装器必须通过复制传入IP头的两位ECN字段来构造外部封装IP头。在兼容模式下，它会将外部标头中的ECN字段清除为Not ECT代码点（每当更改ECN字段时，IPv4标头校验和也会更改）。为了方便起见，在图3中列出了这些规则。
+-----------------+-------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+
| departing Inner | Compatibility | Normal |
| Header) | Mode | Mode |
+-----------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE |
+-----------------+---------------+---------------+
+-----------------+-------------------------------+
| Incoming Header | Departing Outer Header |
| (also equal to +---------------+---------------+
| departing Inner | Compatibility | Normal |
| Header) | Mode | Mode |
+-----------------+---------------+---------------+
| Not-ECT | Not-ECT | Not-ECT |
| ECT(0) | Not-ECT | ECT(0) |
| ECT(1) | Not-ECT | ECT(1) |
| CE | Not-ECT | CE |
+-----------------+---------------+---------------+
Figure 3: New IP in IP Encapsulation Behaviours
图3:IP封装中的新IP行为
To decapsulate the inner header at the tunnel egress, a compliant tunnel egress MUST set the outgoing ECN field to the codepoint at the intersection of the appropriate arriving inner header (row) and outer header (column) in Figure 4 (the IPv4 header checksum also changes
要在隧道出口处解除内部报头的封装，兼容隧道出口必须将传出ECN字段设置为图4中相应到达的内部报头（行）和外部报头（列）交叉处的代码点（IPv4报头校验和也会更改）
whenever the ECN field is changed). There is no need for more than one mode of decapsulation, as these rules cater for all known requirements.
无论何时更改ECN字段）。由于这些规则满足所有已知要求，因此无需采用一种以上的脱封模式。
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
+---------+------------------------------------------------+
|Arriving | Arriving Outer Header |
| Inner +---------+------------+------------+------------+
| Header | Not-ECT | ECT(0) | ECT(1) | CE |
+---------+---------+------------+------------+------------+
| Not-ECT | Not-ECT |Not-ECT(!!!)|Not-ECT(!!!)| <drop>(!!!)|
| ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
| ECT(1) | ECT(1) | ECT(1) (!) | ECT(1) | CE |
| CE | CE | CE | CE(!!!)| CE |
+---------+---------+------------+------------+------------+
The ECN field in the outgoing header is set to the codepoint at the intersection of the appropriate arriving inner header (row) and arriving outer header (column), or the packet is dropped where indicated. Currently unused combinations are indicated by '(!!!)' or '(!)'
传出报头中的ECN字段设置为相应到达的内部报头（行）和到达的外部报头（列）交叉处的代码点，或者在指示的位置丢弃数据包。当前未使用的组合由“（！！！）”或“（！）”表示
Figure 4: New IP in IP Decapsulation Behaviour
图4：新IP-in-IP脱封行为
This table for decapsulation behaviour is derived from the following logic:
此脱封行为表源自以下逻辑：
o If the inner ECN field is Not-ECT, the decapsulator MUST NOT propagate any other ECN codepoint onwards. This is because the inner Not-ECT marking is set by transports that rely on dropped packets as an indication of congestion and would not understand or respond to any other ECN codepoint [RFC4774]. Specifically:
o 如果内部ECN字段不是ECT，则解封装器不得向前传播任何其他ECN代码点。这是因为内部Not ECT标记由依赖丢弃的数据包作为拥塞指示的传输设置，并且不会理解或响应任何其他ECN码点[RFC4774]。明确地：
* If the inner ECN field is Not-ECT and the outer ECN field is CE, the decapsulator MUST drop the packet.
* 如果内部ECN字段不是ECT，而外部ECN字段是CE，则解封装器必须丢弃数据包。
* If the inner ECN field is Not-ECT and the outer ECN field is Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the outgoing packet with the ECN field cleared to Not-ECT.
* 如果内部ECN字段不是ECT，而外部ECN字段不是ECT、ECT（0）或ECT（1），则解封装器必须转发ECN字段清除为Not ECT的传出数据包。
o In all other cases where the inner supports ECN, the decapsulator MUST set the outgoing ECN field to the more severe marking of the outer and inner ECN fields, where the ranking of severity from highest to lowest is CE, ECT(1), ECT(0), Not-ECT. This in no way precludes cases where ECT(1) and ECT(0) have the same severity;
o 在内部支持ECN的所有其他情况下，除封装器必须将传出ECN字段设置为外部和内部ECN字段的更严重标记，其中从高到低的严重性等级为CE、ECT（1）、ECT（0），而不是ECT。这并不排除ECT（1）和ECT（0）具有相同严重性的情况；
o Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are
o 内部和外部ECN字段的某些组合不能由任何当前或以前的ECN隧道规范中的任何转换产生。这些当前未使用的（CU）组合是
indicated in Figure 4 by '(!!!)' or '(!)', where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous. In these cases, particularly the more dangerous ones, the decapsulator SHOULD log the event and MAY also raise an alarm.
在图4中用“（！！！）”或“（！”）表示，其中“（！！！）”表示组合为CU且始终具有潜在危险，而“（！”表示组合为CU且可能具有危险性。在这些情况下，尤其是更危险的情况下，去封装器应记录事件并可能发出警报。
Just because the highlighted combinations are currently unused, does not mean that all the other combinations are always valid. Some are only valid if they have arrived from a particular type of legacy ingress, and dangerous otherwise. Therefore, an implementation MAY allow an operator to configure logging and alarms for such additional header combinations known to be dangerous or CU for the particular configuration of tunnel endpoints deployed at run-time.
仅因为高亮显示的组合当前未使用，并不意味着所有其他组合始终有效。一些只有在它们来自特定类型的遗留入口时才有效，否则是危险的。因此，一种实现可允许操作员为已知危险的此类附加报头组合配置日志记录和警报，或为在运行时部署的隧道端点的特定配置配置CU。
Alarms SHOULD be rate-limited so that the anomalous combinations will not amplify into a flood of alarm messages. It MUST be possible to suppress alarms or logging, e.g., if it becomes apparent that a combination that previously was not used has started to be used for legitimate purposes such as a new standards action.
警报应限制速率，以便异常组合不会放大为大量警报消息。必须能够抑制报警或日志记录，例如，如果很明显以前未使用的组合已开始用于合法目的，如新的标准行动。
The above logic allows for ECT(0) and ECT(1) to both represent the same severity of congestion marking (e.g., "not congestion marked"). But it also allows future schemes to be defined where ECT(1) is a more severe marking than ECT(0), in particular, enabling the simplest possible encoding for PCN [PCN3in1] (see Section 5.3.2). Treating ECT(1) as either the same as ECT(0) or as a higher severity level is explained in the discussion of the ECN nonce [RFC3540] in Section 8, which in turn refers to Appendix D.
上述逻辑允许ECT（0）和ECT（1）都表示相同严重程度的拥塞标记（例如，“未标记拥塞”）。但它也允许定义未来的方案，其中ECT（1）是比ECT（0）更严重的标记，特别是，允许对PCN[PCN3in1]进行最简单的编码（见第5.3.2节）。将ECT（1）视为与ECT（0）相同或更高的严重程度，在第8节中的ECN nonce[RFC3540]讨论中进行了解释，这又参考了附录D。
Section 4.1 introduces two encapsulation modes: normal mode, and compatibility mode, defining their encapsulation behaviour (i.e., header copying or zeroing, respectively). Note that these are modes of the ingress tunnel endpoint only, not the tunnel as a whole.
第4.1节介绍了两种封装模式：正常模式和兼容性模式，分别定义了它们的封装行为（即，头复制或归零）。请注意，这些只是入口隧道端点的模式，而不是整个隧道。
To comply with this specification, a tunnel ingress MUST at least implement normal mode. Unless it will never be used with legacy tunnel egress nodes (RFC 2003, RFC 2401, or RFC 2481 or the limited functionality mode of RFC 3168), an ingress MUST also implement compatibility mode for backward compatibility with tunnel egresses that do not propagate explicit congestion notifications [RFC4774].
为了符合本规范，隧道入口必须至少实现正常模式。除非它永远不会与传统的隧道出口节点（RFC 2003、RFC 2401或RFC 2481或RFC 3168的有限功能模式）一起使用，否则入口还必须实现兼容模式，以便与不传播显式拥塞通知的隧道出口向后兼容[RFC4774]。
We can categorise the way that an ingress tunnel endpoint is paired with an egress as either static or dynamically discovered:
我们可以将入口隧道端点与出口配对的方式分类为静态或动态发现：
Static: Tunnel endpoints paired together by prior configuration.
静态：通过先前的配置将隧道端点配对在一起。
Some implementations of encapsulator might always be statically deployed, and constrained to never be paired with a legacy decapsulator (RFC 2003, RFC 2401 or RFC 2481 or the limited functionality mode of RFC 3168). In such a case, only normal mode needs to be implemented.
封装器的一些实现可能总是静态部署的，并且被限制为永远不会与传统的去封装器配对（RFC 2003、RFC 2401或RFC 2481或RFC 3168的有限功能模式）。在这种情况下，只需要实现正常模式。
For instance, IPsec tunnel endpoints compatible with RFC 4301 invariably use Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] for key exchange, the original specification of which was introduced alongside RFC 4301. Therefore, both endpoints of an RFC 4301 tunnel can be sure that the other end is compatible with RFC 4301, because the tunnel is only formed after IKEv2 key management has completed, at which point both ends will be compliant with RFC 4301 by definition. Therefore an IPsec tunnel ingress does not need compatibility mode, as it will never interact with legacy ECN tunnels. To comply with the present specification, it only needs to implement the required normal mode, which is identical to the pre-existing RFC 4301 behaviour.
例如，与RFC 4301兼容的IPsec隧道端点总是使用Internet密钥交换协议版本2（IKEv2）[RFC5996]进行密钥交换，其原始规范是与RFC 4301一起引入的。因此，RFC 4301隧道的两个端点可以确保另一端与RFC 4301兼容，因为该隧道仅在IKEv2密钥管理完成后形成，此时，根据定义，两端都将与RFC 4301兼容。因此，IPsec隧道入口不需要兼容模式，因为它永远不会与传统ECN隧道交互。为了符合当前规范，它只需要实现所需的正常模式，这与先前存在的RFC 4301行为相同。
Dynamic Discovery: Tunnel endpoints paired together by some form of tunnel endpoint discovery, typically finding an egress on the path taken by the first packet.
动态发现：隧道端点通过某种形式的隧道端点发现配对在一起，通常在第一个数据包所采用的路径上查找出口。
This specification does not require or recommend dynamic discovery and it does not define how dynamic negotiation might be done, but it recognises that proprietary tunnel endpoint discovery protocols exist. It therefore sets down some constraints on discovery protocols to ensure safe interworking.
本规范不要求或建议动态发现，也不定义如何进行动态协商，但它承认存在专有的隧道端点发现协议。因此，它对发现协议设置了一些约束，以确保安全互通。
If dynamic tunnel endpoint discovery might pair an ingress with a legacy egress (RFC 2003, RFC 2401, or RFC 2481 or the limited functionality mode of RFC 3168), the ingress MUST implement both normal and compatibility mode. If the tunnel discovery process is arranged to only ever find a tunnel egress that propagates ECN (RFC 3168 full functionality mode, RFC 4301, or this present specification), then a tunnel ingress can be compliant with the present specification without implementing compatibility mode.
如果动态隧道端点发现可能将入口与传统出口配对（RFC 2003、RFC 2401或RFC 2481或RFC 3168的有限功能模式），则入口必须实现正常模式和兼容模式。如果隧道发现过程被安排为仅找到传播ECN的隧道出口（RFC 3168全功能模式、RFC 4301或本规范），则隧道入口可符合本规范而不实施兼容模式。
While a compliant tunnel ingress is discovering an egress, it MUST send packets in compatibility mode in case the egress it discovers is a legacy egress. If, through the discovery protocol, the egress indicates that it is compliant with the present specification, with RFC 4301 or with RFC 3168 full functionality mode, the ingress can switch itself into normal mode. If the egress denies compliance with any of these or returns an error
当兼容隧道入口发现出口时，它必须以兼容模式发送数据包，以防它发现的出口是遗留出口。如果通过发现协议，出口指示其符合当前规范、RFC 4301或RFC 3168全功能模式，则入口可以将自身切换到正常模式。如果出口拒绝遵守其中任何一项或返回错误
that implies it does not understand a request to work to any of these ECN specifications, the tunnel ingress MUST remain in compatibility mode.
这意味着它不理解按照这些ECN规范工作的请求，隧道入口必须保持兼容模式。
If an ingress claims compliance with this specification, it MUST NOT permanently disable ECN processing across the tunnel (i.e., only using compatibility mode). It is true that such a tunnel ingress is at least safe with the ECN behaviour of any egress it may encounter, but it does not meet the central aim of this specification: introducing ECN support to tunnels.
如果入口声称符合本规范，则不得永久禁用隧道中的ECN处理（即，仅使用兼容模式）。的确，这种隧道入口至少在其可能遇到的任何出口的ECN行为下是安全的，但它不符合本规范的中心目标：将ECN支持引入隧道。
Instead, if the ingress knows that the egress does support propagation of ECN (full functionality mode of RFC 3168 or RFC 4301 or the present specification), it SHOULD use normal mode, in order to support ECN where possible. Note that this section started by saying an ingress "MUST implement" normal mode, while it has just said an ingress "SHOULD use" normal mode. This distinction is deliberate, to allow the mode to be turned off in exceptional circumstances but to ensure all implementations make normal mode available.
相反，如果入口知道出口确实支持ECN的传播（RFC 3168或RFC 4301的全功能模式或本规范），则其应使用正常模式，以便在可能的情况下支持ECN。请注意，本节以入口“必须实现”正常模式开始，而它刚刚说入口“应使用”正常模式。这种区别是故意的，以允许在异常情况下关闭模式，但确保所有实现使正常模式可用。
Implementation note: If a compliant node is the ingress for multiple tunnels, a mode setting will need to be stored for each tunnel ingress. However, if a node is the egress for multiple tunnels, none of the tunnels will need to store a mode setting, because a compliant egress only needs one mode.
实施说明：如果兼容节点是多个隧道的入口，则需要为每个隧道入口存储模式设置。但是，如果一个节点是多个隧道的出口，则所有隧道都不需要存储模式设置，因为兼容出口只需要一种模式。
A compliant decapsulator only needs one mode of operation. However, if a compliant egress is implemented to be dynamically discoverable, it may need to respond to discovery requests from various types of legacy tunnel ingress. This specification does not define how dynamic negotiation might be done by (proprietary) discovery protocols, but it sets down some constraints to ensure safe interworking.
兼容的去封装器只需要一种操作模式。然而，如果兼容出口被实现为可动态发现，则它可能需要响应来自各种类型的遗留隧道入口的发现请求。本规范未定义（专有）发现协议如何进行动态协商，但规定了一些约束条件以确保安全互通。
Through the discovery protocol, a tunnel ingress compliant with the present specification might ask if the egress is compliant with the present specification, with RFC 4301 or with RFC 3168 full functionality mode. Or an RFC 3168 tunnel ingress might try to negotiate to use limited functionality or full functionality mode [RFC3168]. In all these cases, a decapsulating tunnel egress compliant with this specification MUST agree to any of these requests, since it will behave identically in all these cases.
通过发现协议，符合本规范的隧道入口可能会询问出口是否符合本规范、RFC 4301或RFC 3168全功能模式。或者RFC 3168隧道入口可能尝试协商使用有限功能或全功能模式[RFC3168]。在所有这些情况下，符合本规范的脱封隧道出口必须同意任何这些要求，因为在所有这些情况下，其行为相同。
If no ECN-related mode is requested, a compliant tunnel egress MUST continue without raising any error or warning, because its egress behaviour is compatible with all the legacy ingress behaviours that do not negotiate capabilities.
如果未请求与ECN相关的模式，则必须在不引发任何错误或警告的情况下继续进行符合要求的隧道出口，因为其出口行为与不协商能力的所有传统入口行为兼容。
A compliant tunnel egress SHOULD raise a warning alarm about any requests to enter modes it does not recognise but, for 'forward compatibility' with standards actions possibly defined after it was implemented, it SHOULD continue operating.
合规隧道出口应发出警告警报，警告其任何进入其无法识别的模式的请求，但为了与实施后可能定义的标准措施“向前兼容”，应继续运行。
Ingress: An RFC 4301 IPsec encapsulator is not changed at all by the present specification. It uses the normal mode of the present specification, which defines packet encapsulation identically to RFC 4301.
入口：RFC 4301 IPsec封装器完全不受当前规范的影响。它使用本规范的正常模式，该模式定义的数据包封装与RFC 4301相同。
Egress: An RFC 4301 egress will need to be updated to the new decapsulation behaviour in Figure 4, in order to comply with the present specification. However, the changes are backward compatible; combinations of inner and outer that result from any protocol defined in the RFC series so far are unaffected. Only combinations that have never been used have been changed, effectively adding new behaviours to RFC 4301 decapsulation without altering existing behaviours. The following specific updates to Section 5.1.2 of RFC 4301 have been made:
出口：RFC 4301出口需要更新为图4中的新脱封行为，以符合当前规范。然而，这些变化是向后兼容的；到目前为止，由RFC系列中定义的任何协议产生的内部和外部组合不受影响。仅更改了从未使用过的组合，有效地增加了RFC 4301脱封的新行为，而不改变现有行为。对RFC 4301第5.1.2节进行了以下具体更新：
* The outer, not the inner, is propagated when the outer is ECT(1) and the inner is ECT(0);
* 当外部为ECT（1）且内部为ECT（0）时，传播外部而非内部；
* A packet with Not-ECT in the inner and an outer of CE is dropped rather than forwarded as Not-ECT;
* 在CE的内部和外部具有Not ECT的分组被丢弃，而不是作为Not ECT转发；
* Certain combinations of inner and outer ECN field have been identified as currently unused. These can trigger logging and/or raise alarms.
* 内部和外部ECN字段的某些组合已被确定为当前未使用。这些可以触发日志记录和/或发出警报。
Modes: RFC 4301 tunnel endpoints do not need modes and are not updated by the modes in the present specification. Effectively, an RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of encapsulation, which is unchanged from RFC 4301 encapsulation. It will never need the OPTIONAL compatibility mode as explained in Section 4.3.
模式：RFC 4301隧道端点不需要模式，并且不由本规范中的模式更新。实际上，RFC 4301 IPsec入口仅使用所需的正常封装模式，与RFC 4301封装模式相同。它永远不需要第4.3节中解释的可选兼容性模式。
Ingress: On encapsulation, the new rule in Figure 3 that a normal mode tunnel ingress copies any ECN field into the outer header updates the full functionality behaviour of an RFC 3168 ingress (Section 9.1.1 of [RFC3168]). Nonetheless, the new compatibility mode encapsulates packets identically to the limited functionality mode of an RFC 3168 ingress.
入口：在封装方面，图3中的新规则，即正常模式隧道入口将任何ECN字段复制到外部报头，更新RFC 3168入口的完整功能行为（RFC3168的第9.1.1节）。尽管如此，新的兼容模式封装的数据包与RFC3168入口的有限功能模式相同。
Egress: An RFC 3168 egress will need to be updated to the new decapsulation behaviour in Figure 4, in order to comply with the present specification. However, the changes are backward compatible; combinations of inner and outer that result from any protocol defined in the RFC series so far are unaffected. Only combinations that have never been used have been changed, effectively adding new behaviours to RFC 3168 decapsulation without altering existing behaviours. The following specific updates to Section 9.1.1 of RFC 3168 have been made:
出口：RFC 3168出口需要更新为图4中的新脱封行为，以符合当前规范。然而，这些变化是向后兼容的；到目前为止，由RFC系列中定义的任何协议产生的内部和外部组合不受影响。仅更改了从未使用过的组合，有效地增加了RFC 3168脱封的新行为，而不改变现有行为。对RFC 3168第9.1.1节进行了以下具体更新：
* The outer, not the inner, is propagated when the outer is ECT(1) and the inner is ECT(0);
* 当外部为ECT（1）且内部为ECT（0）时，传播外部而非内部；
* Certain combinations of inner and outer ECN field have been identified as currently unused. These can trigger logging and/or raise alarms.
* 内部和外部ECN字段的某些组合已被确定为当前未使用。这些可以触发日志记录和/或发出警报。
Modes: An RFC 3168 ingress will need to be updated if it is to comply with the present specification, whether or not it implemented the optional full functionality mode of Section 9.1.1 of RFC 3168.
模式：如果要符合当前规范，则需要更新RFC 3168入口，无论其是否实现RFC 3168第9.1.1节中的可选全功能模式。
Section 9.1 of RFC 3168 defined a (required) limited functionality mode and an (optional) full functionality mode for a tunnel. In RFC 3168, modes applied to both ends of the tunnel, while in the present specification, modes are only used at the ingress -- a single egress behaviour covers all cases.
RFC 3168第9.1节定义了隧道的（必需）有限功能模式和（可选）全功能模式。在RFC 3168中，模式应用于隧道两端，而在本规范中，模式仅用于入口——单一出口行为涵盖所有情况。
The normal mode of encapsulation is an update to the encapsulation behaviour of the full functionality mode of an RFC 3168 ingress. The compatibility mode of encapsulation is identical to the encapsulation behaviour of the limited functionality mode of an RFC 3168 ingress, except it is not always obligatory.
正常封装模式是对RFC 3168入口全功能模式封装行为的更新。封装的兼容性模式与RFC 3168入口的有限功能模式的封装行为相同，但并不总是强制性的。
The constraints on how tunnel discovery protocols set modes in Sections 4.3 and 4.4 are an update to RFC 3168, but they are unlikely to require code changes as they document existing safe practice.
第4.3节和第4.4节中关于隧道发现协议如何设置模式的限制是对RFC 3168的更新，但它们不太可能需要更改代码，因为它们记录了现有的安全实践。
An overriding goal is to ensure the same ECN signals can mean the same thing whatever tunnels happen to encapsulate an IP packet flow. This removes gratuitous inconsistency, which otherwise constrains the available design space and makes it harder to design networks and new protocols that work predictably.
一个压倒一切的目标是确保相同的ECN信号可以意味着相同的事情，无论发生什么隧道来封装IP数据包流。这消除了不必要的不一致性，否则会限制可用的设计空间，并使设计网络和新协议变得更加难以预测。
The normal mode in Section 4 updates RFC 3168 to make all IP-in-IP encapsulation of the ECN field consistent -- consistent with the way both RFC 4301 IPsec [RFC4301] and IP-in-MPLS or MPLS-in-MPLS encapsulation [RFC5129] construct the ECN field.
第4节中的正常模式更新RFC 3168，使ECN字段的所有IP-in-IP封装一致——与RFC 4301 IPsec[RFC4301]和IP-in-MPLS或MPLS-in-MPLS封装[RFC5129]构造ECN字段的方式一致。
Compatibility mode has also been defined so that an ingress compliant with a version of IPsec prior to RFC 4301 can still switch to using drop across a tunnel for backward compatibility with legacy decapsulators that do not propagate ECN.
还定义了兼容模式，以便与RFC 4301之前的IPsec版本兼容的入口仍然可以切换到通过隧道使用drop，以向后兼容不传播ECN的传统去封装器。
The trigger that motivated this update to RFC 3168 encapsulation was a Standards-Track proposal for pre-congestion notification (PCN [RFC5670]). PCN excess-traffic-marking only works correctly if the ECN field is copied on encapsulation (as in RFC 4301 and RFC 5129); it does not work if ECN is reset (as in RFC 3168). This is because PCN excess-traffic-marking depends on the outer header revealing any congestion experienced so far on the whole path, not just since the last tunnel ingress.
促使RFC 3168封装更新的触发因素是拥塞前通知（PCN[RFC5670]）的标准跟踪建议。只有在封装时复制ECN字段（如RFC 4301和RFC 5129），PCN过量流量标记才能正常工作；如果重置ECN（如RFC 3168中所示），它将不起作用。这是因为PCN过量交通标志取决于外部报头，该报头显示了迄今为止在整个路径上经历的任何拥堵，而不仅仅是自上次隧道进入以来。
PCN allows a network operator to add flow admission and termination for inelastic traffic at the edges of a Diffserv domain, but without any per-flow mechanisms in the interior and without the generous provisioning typical of Diffserv, aiming to significantly reduce costs. The PCN architecture [RFC5559] states that RFC 3168 IP-in-IP tunnelling of the ECN field cannot be used for any tunnel ingress in a PCN domain. Prior to the present specification, this left a stark choice between not being able to use PCN for inelastic traffic control or not being able to use the many tunnels already deployed for Mobile IP, VPNs, and so forth.
PCN允许网络运营商为Diffserv域边缘的非弹性流量添加流量准入和终止，但内部没有任何每流机制，也没有Diffserv典型的慷慨供应，旨在显著降低成本。PCN体系结构[RFC5559]规定，ECN字段的RFC 3168 IP in IP隧道不能用于PCN域中的任何隧道入口。在本规范之前，这留下了一个严峻的选择，要么不能使用PCN进行非弹性流量控制，要么不能使用已经部署用于移动IP、VPN等的许多隧道。
The present specification provides a clean solution to this problem, so that network operators who want to use both PCN and tunnels can specify that every tunnel ingress in a PCN region must comply with this latest specification.
本规范为该问题提供了一个干净的解决方案，因此，希望同时使用PCN和隧道的网络运营商可以指定PCN区域中的每个隧道入口必须符合本最新规范。
Rather than allow tunnel specifications to fragment further into one for PCN, one for IPsec, and one for other tunnels, the opportunity has been taken to consolidate the diverging specifications back into
不允许隧道规范进一步细分为一个用于PCN、一个用于IPsec和一个用于其他隧道，而是利用这个机会将分散的规范整合回
a single tunnelling behaviour. Resetting ECN was originally motivated by a covert channel concern that has been deliberately set aside in RFC 4301 IPsec. Therefore, the reset behaviour of RFC 3168 is an anomaly that we do not need to keep. Copying ECN on encapsulation is simpler than resetting. So, as more tunnel endpoints comply with this single consistent specification, encapsulation will be simpler as well as more predictable.
单隧道掘进行为。重置ECN最初是由RFC 4301 IPsec中故意搁置的隐蔽通道问题引起的。因此，RFC 3168的重置行为是一种我们不需要保留的异常现象。封装时复制ECN比重置简单。因此，随着越来越多的隧道端点符合这一一致性规范，封装将变得更简单，也更可预测。
Appendix B assesses whether copying rather than resetting CE on ingress will cause any unintended side effects, from the three perspectives of security, control, and management. In summary, this analysis finds that:
附录B从安全、控制和管理三个角度评估了在进入时复制而不是重置CE是否会导致任何意外的副作用。总之，该分析发现：
o From the control perspective, either copying or resetting works for existing arrangements, but copying has more potential for simplifying control and resetting breaks at least one proposal that is already on the Standards Track.
o 从控制角度来看，复制或重置对现有安排有效，但复制在简化控制和重置方面有更大的潜力，至少有一项提案已经进入标准轨道。
o From the management and monitoring perspective, copying is preferable.
o 从管理和监控的角度来看，最好是复制。
o From the traffic security perspective (enforcing congestion control, mitigating denial of service, etc.), copying is preferable.
o 从流量安全的角度（实施拥塞控制、缓解拒绝服务等），复制是可取的。
o From the information security perspective, resetting is preferable, but the IETF Security Area now considers copying acceptable given the bandwidth of a two-bit covert channel can be managed.
o 从信息安全的角度来看，重置是可取的，但IETF安全领域现在认为，如果可以管理两位隐蔽通道的带宽，复制是可以接受的。
Therefore, there are two points against resetting CE on ingress while copying CE causes no significant harm.
因此，有两点反对在入口重置CE，而复制CE不会造成重大损害。
The specification for decapsulation in Section 4 fixes three problems with the pre-existing behaviours found in both RFC 3168 and RFC 4301:
第4节中的脱封规范修复了RFC 3168和RFC 4301中已有行为的三个问题：
1. The pre-existing rules prevented the introduction of alternate ECN semantics to signal more than one severity level of congestion [RFC4774], [RFC5559]. The four states of the two-bit ECN field provide room for signalling two severity levels in addition to not-congested and not-ECN-capable states. But, the pre-existing rules assumed that two of the states (ECT(0) and ECT(1)) are always equivalent. This unnecessarily restricts the use of one of four codepoints (half a bit) in the IP (v4 and v6) header. The new rules are designed to work in either case; whether ECT(1) is more severe than or equivalent to ECT(0).
1. 预先存在的规则阻止引入备用ECN语义来表示一个以上的拥塞严重程度[RFC4774]，[RFC5559]。两位ECN字段的四种状态提供了发送两种严重性级别信号的空间，以及非拥塞和不支持ECN的状态。但是，先前存在的规则假设两个状态（ECT（0）和ECT（1））总是等价的。这不必要地限制了IP（v4和v6）报头中四个代码点（半位）之一的使用。新规则设计为在任何情况下都适用；ECT（1）是否比ECT（0）更严重或等效。
As explained in Appendix B.1, the original reason for not forwarding the outer ECT codepoints was to limit the covert channel across a decapsulator to 1 bit per packet. However, now that the IETF Security Area has deemed that a two-bit covert channel through an encapsulator is a manageable risk, the same should be true for a decapsulator.
如附录B.1所述，不转发外部ECT代码点的最初原因是将通过去封装器的隐蔽通道限制为每个数据包1位。然而，既然IETF安全区域认为通过封装器的两位隐蔽通道是可管理的风险，那么对于去封装器也是如此。
As well as being useful for general future-proofing, this problem is immediately pressing for standardisation of pre-congestion notification (PCN), which uses two severity levels of congestion. If a congested queue used ECT(1) in the outer header to signal more severe congestion than ECT(0), the pre-existing decapsulation rules would have thrown away this congestion signal, preventing tunnelled traffic from ever knowing that it should reduce its load.
这一问题不仅有助于一般的未来验证，而且也迫切需要对拥堵前通知（PCN）进行标准化，PCN使用两种严重程度的拥堵。如果拥塞队列在外部报头中使用ECT（1）发出比ECT（0）更严重的拥塞信号，则预先存在的解除封装规则将丢弃此拥塞信号，从而阻止隧道传输的流量知道它应该减少其负载。
Before the present specification was written, the PCN working group had to consider a number of wasteful or convoluted work-rounds to this problem. Without wishing to disparage the ingenuity of these work-rounds, none were chosen for the Standards Track because they were either somewhat wasteful, imprecise, or complicated. Instead, a baseline PCN encoding was specified [RFC5696] that supported only one severity level of congestion but allowed space for these work-rounds as experimental extensions.
在编写本说明书之前，PCN工作组不得不考虑一些浪费或复杂的工作循环来解决这个问题。在不想贬低这些工作循环的独创性的情况下，没有一个被选为标准轨道，因为它们要么有点浪费，要么不精确，要么复杂。相反，指定了基准PCN编码[RFC5696]，该编码只支持一种严重程度的拥塞，但允许将这些工作循环作为实验扩展。
By far the simplest approach is that taken by the current specification: just to remove the covert channel blockages from tunnelling behaviour -- now deemed unnecessary anyway. Then, network operators that want to support two congestion severity levels for PCN can specify that every tunnel egress in a PCN region must comply with this latest specification. Having taken this step, the simplest possible encoding for PCN with two severity levels of congestion [PCN3in1] can be used.
到目前为止，最简单的方法是当前规范所采用的方法：只是从隧道行为中移除隐蔽通道阻塞——现在被认为是不必要的。然后，希望为PCN支持两个拥塞严重程度级别的网络运营商可以指定PCN区域中的每个隧道出口必须符合此最新规范。采取这一步骤后，可以使用具有两种严重程度拥塞的PCN的最简单编码[PCN3in1]。
Not only does this make two congestion severity levels available for PCN, but also for other potential uses of the extra ECN codepoint (e.g., [VCP]).
这不仅使PCN具有两个拥塞严重程度级别，而且还可用于额外ECN码点（例如[VCP]）的其他潜在用途。
2. Cases are documented where a middlebox (e.g., a firewall) drops packets with header values that were currently unused (CU) when the box was deployed, often on the grounds that anything unexpected might be an attack. This tends to bar future use of CU values. The new decapsulation rules specify optional logging and/or alarms for specific combinations of inner and outer headers that are currently unused. The aim is to give implementers a recourse other than drop if they are concerned about the security of CU values. It recognises legitimate
2. 记录了中间盒（如防火墙）丢弃当前未使用（CU）报头值的数据包的情况，通常是因为任何意外情况都可能是攻击。这往往会阻止将来使用CU值。新的解除封装规则为当前未使用的内部和外部标头的特定组合指定可选日志记录和/或警报。其目的是，如果实施者担心CU值的安全性，则为他们提供除drop之外的追索权。它承认合法性
security concerns about CU values, but still eases their future use. If the alarms are interpreted as an attack (e.g., by a management system) the offending packets can be dropped. However, alarms can be turned off if these combinations come into regular use (e.g., through a future standards action).
对CU值的安全性表示担忧，但仍会简化其未来的使用。如果报警被解释为攻击（例如，由管理系统），则会丢弃有问题的数据包。但是，如果这些组合正常使用（例如，通过未来的标准行动），则可以关闭警报。
3. While reviewing currently unused combinations of inner and outer headers, the opportunity was taken to define a single consistent behaviour for the three cases with a Not-ECT inner header but a different outer. RFC 3168 and RFC 4301 had diverged in this respect and even their common behaviours had never been justified.
3. 在审查当前未使用的内部和外部集管组合时，利用这个机会为三种情况定义了一个单一的一致行为，即不使用ECT内部集管，而是使用不同的外部集管。RFC 3168和RFC 4301在这方面存在分歧，甚至他们的共同行为也从未得到证明。
None of these combinations should result from Internet protocols in the RFC series, but future standards actions might put any or all of them to good use. Therefore, it was decided that a decapsulator must forward a Not-ECT inner header unchanged when the arriving outer header is ECT(0) or ECT(1). For safety, it must drop a combination of Not-ECT inner and CE outer headers. Then, if some unfortunate misconfiguration resulted in a congested router marking CE on a packet that was originally Not-ECT, drop would be the only appropriate signal for the egress to propagate -- the only signal a non-ECN-capable transport (Not-ECT) would understand.
这些组合都不应来自RFC系列中的互联网协议，但未来的标准行动可能会充分利用其中的任何或所有协议。因此，决定当到达的外部报头为ECT（0）或ECT（1）时，解封装器必须转发未更改的非ECT内部报头。为安全起见，它必须放下非ECT内集管和CE外集管的组合。然后，如果一些不幸的错误配置导致拥塞路由器在最初不是ECT的数据包上标记CE，drop将是出口传播的唯一合适信号——不支持ECN的传输（非ECT）将理解的唯一信号。
It may seem contradictory that the same argument has not been applied to the ECT(1) codepoint, given it is being proposed as an intermediate level of congestion in a scheme progressing through the IETF [PCN3in1]. Instead, a decapsulator must forward a Not-ECT inner unchanged when its outer is ECT(1). The rationale for not dropping this CU combination is to ensure it will be usable if needed in the future. If any misconfiguration led to ECT(1) congestion signals with a Not-ECT inner, it would not be disastrous for the tunnel egress to suppress them, because the congestion should then escalate to CE marking, which the egress would drop, thus at least preventing congestion collapse.
鉴于ECT（1）码点被提议作为通过IETF[PCN3in1]的方案中的中间拥塞水平，同样的论点没有应用于ECT（1）码点似乎是矛盾的。相反，当外部为ECT（1）时，去封装器必须转发一个未更改的ECT内部。不放弃该CU组合的理由是确保其在未来需要时可用。如果任何错误配置导致ECT（1）拥塞信号具有非ECT内部，则隧道出口抑制这些信号不会带来灾难性后果，因为拥塞应升级至CE标记，出口将下降，从而至少防止拥塞崩溃。
Problems 2 and 3 alone would not warrant a change to decapsulation, but it was decided they are worth fixing and making consistent at the same time as decapsulation code is changed to fix problem 1 (two congestion severity levels).
仅问题2和问题3不足以保证对解封进行更改，但在解封代码更改为修复问题1（两个拥塞严重程度级别）的同时，确定它们值得修复并保持一致。
A tunnel endpoint compliant with the present specification is backward compatible when paired with any tunnel endpoint compliant with any previous tunnelling RFC, whether RFC 4301, RFC 3168 (see Section 3), or the earlier RFCs summarised in Appendix A (RFC 2481, RFC 2401, and RFC 2003). Each case is enumerated below.
符合本规范的隧道端点与符合任何先前隧道RFC（无论是RFC 4301、RFC 3168（见第3节）或附录A（RFC 2481、RFC 2401和RFC 2003）中总结的早期RFC）的任何隧道端点配对时向后兼容。下文列举了每种情况。
At the egress, this specification only augments the per-packet calculation of the ECN field (RFC 3168 and RFC 4301) for combinations of inner and outer headers that have so far not been used in any IETF protocols.
在出口处，本规范仅增加了ECN字段（RFC 3168和RFC 4301）的每包计算，用于迄今为止尚未在任何IETF协议中使用的内部和外部报头的组合。
Therefore, all other things being equal, if an RFC 4301 IPsec egress is updated to comply with the new rules, it will still interwork with any ingress compliant with RFC 4301 and the packet outputs will be identical to those it would have output before (fully backward compatible).
因此，在所有其他条件相同的情况下，如果更新RFC 4301 IPsec出口以符合新规则，则它仍将与任何符合RFC 4301的入口互通，并且数据包输出将与它之前的输出相同（完全向后兼容）。
And, all other things being equal, if an RFC 3168 egress is updated to comply with the same new rules, it will still interwork with any ingress complying with any previous specification (both modes of RFC 3168, both modes of RFC 2481, RFC 2401, and RFC 2003) and the packet outputs will be identical to those it would have output before (fully backward compatible).
并且，在所有其他条件相同的情况下，如果RFC 3168出口被更新以符合相同的新规则，则其仍将与符合任何先前规范（RFC 3168的两种模式、RFC 2481的两种模式、RFC 2401和RFC 2003的两种模式）的任何入口互通，并且数据包输出将与之前的输出相同（完全向后兼容）。
A compliant tunnel egress merely needs to implement the one behaviour in Section 4 with no additional mode or option configuration at the ingress or egress nor any additional negotiation with the ingress. The new decapsulation rules have been defined in such a way that congestion control will still work safely if any of the earlier versions of ECN processing are used unilaterally at the encapsulating ingress of the tunnel (any of RFC 2003, RFC 2401, either mode of RFC 2481, either mode of RFC 3168, RFC 4301, and this present specification).
合规隧道出口仅需实施第4节中的一种行为，在入口或出口处无额外模式或选项配置，也无需与入口进行任何额外协商。新的去封装规则的定义方式是，如果在隧道的封装入口单方面使用任何早期版本的ECN处理（RFC 2003、RFC 2401、RFC 2481的任一模式、RFC 3168的任一模式、RFC 4301和本规范的任一模式），则拥塞控制仍将安全工作。
An RFC 4301 IPsec ingress can comply with this new specification without any update and it has no need for any new modes, options, or configuration. So, all other things being equal, it will continue to interwork identically with any egress it worked with before (fully backward compatible).
RFC 4301 IPsec入口无需任何更新即可符合此新规范，且无需任何新模式、选项或配置。因此，在所有其他条件相同的情况下，它将继续与以前使用过的任何出口进行相同的互通（完全向后兼容）。
The encapsulation behaviour of the new normal mode copies the ECN field, whereas an RFC 3168 ingress in full functionality mode reset it. However, all other things being equal, if an RFC 3168 ingress is updated to the present specification, the outgoing packets from any tunnel egress will still be unchanged. This is because all variants of tunnelling at either end (RFC 4301, both modes of RFC 3168, both modes of RFC 2481, RFC 2401, RFC 2003, and the present specification) have always propagated an incoming CE marking through the inner header and onward into the outgoing header; whether the outer header is reset or copied. Therefore, if the tunnel is considered a black box, the packets output from any egress will be identical with or without an update to the ingress. Nonetheless, if packets are observed within the black box (between the tunnel endpoints), CE markings copied by the updated ingress will be visible within the black box, whereas they would not have been before. Therefore, the update to encapsulation can be termed 'black-box backward compatible' (i.e., identical unless you look inside the tunnel).
新正常模式的封装行为复制ECN字段，而RFC 3168进入全功能模式时会重置它。然而，在所有其他条件相同的情况下，如果将RFC 3168入口更新为当前规范，则来自任何隧道出口的传出分组仍将保持不变。这是因为两端隧道的所有变体（RFC 4301、RFC 3168的两种模式、RFC 2481、RFC 2401、RFC 2003和当前规范的两种模式）始终通过内部标头传播传入CE标记，并向前传播到传出标头中；是否重置或复制外部标题。因此，如果隧道被视为黑盒，则从任何出口输出的包将与入口更新或不更新入口的包相同。尽管如此，如果在黑匣子内（隧道端点之间）观察到数据包，则更新入口复制的CE标记将在黑匣子内可见，而之前不会出现。因此，对封装的更新可以称为“黑盒向后兼容”（即，相同，除非您查看通道内部）。
This specification introduces no new backward compatibility issues when a compliant ingress talks with a legacy egress, but it has to provide similar safeguards to those already defined in RFC 3168. RFC 3168 laid down rules to ensure that an RFC 3168 ingress turns off ECN (limited functionality mode) if it is paired with a legacy egress (RFC 2481, RFC 2401, or RFC 2003), which would not propagate ECN correctly. The present specification carries forward those rules (Section 4.3). It uses compatibility mode whenever RFC 3168 would have used limited functionality mode, and their per-packet behaviours are identical. Therefore, all other things being equal, an ingress using the new rules will interwork with any legacy tunnel egress in exactly the same way as an RFC 3168 ingress (still black-box backward compatible).
当兼容入口与传统出口对话时，本规范不会引入新的向后兼容性问题，但它必须提供与RFC 3168中已定义的类似的保护措施。RFC 3168制定了规则，以确保RFC 3168入口在与无法正确传播ECN的旧出口（RFC 2481、RFC 2401或RFC 2003）配对时关闭ECN（有限功能模式）。本规范继承了这些规则（第4.3节）。只要RFC3168使用有限功能模式，它就会使用兼容模式，并且它们的每包行为是相同的。因此，在所有其他条件相同的情况下，使用新规则的入口将以与RFC 3168入口完全相同的方式与任何传统隧道出口互通（仍然是黑盒向后兼容）。
This section is informative, not normative.
本节内容丰富，不规范。
Section 5 of RFC 3168 permits the Diffserv codepoint (DSCP)[RFC2474] to 'switch in' alternative behaviours for marking the ECN field, just as it switches in different per-hop behaviours (PHBs) for scheduling. [RFC4774] gives best current practice for designing such alternative ECN semantics and very briefly mentions in Section 5.4 that tunnelling needs to be considered. The guidance below complements and extends RFC 4774, giving additional guidance on designing any alternate ECN semantics that would also require alternate tunnelling semantics.
RFC 3168的第5节允许Diffserv代码点（DSCP）[RFC2474]在标记ECN字段时“切换”替代行为，就像它在调度时切换不同的每跳行为（PHB）一样。[RFC4774]给出了设计此类替代ECN语义的最佳当前实践，并在第5.4节中非常简要地提到了需要考虑的隧道挖掘。下面的指南是对RFC 4774的补充和扩展，提供了关于设计任何替代ECN语义（也需要替代隧道语义）的额外指南。
The overriding guidance is: "Avoid designing alternate ECN tunnelling semantics, if at all possible". If a scheme requires tunnels to implement special processing of the ECN field for certain DSCPs, it will be hard to guarantee that every implementer of every tunnel will have added the required exception or that operators will have ubiquitously deployed the required updates. It is unlikely a single authority is even aware of all the tunnels in a network, which may include tunnels set up by applications between endpoints, or dynamically created in the network. Therefore, it is highly likely that some tunnels within a network or on hosts connected to it will not implement the required special case.
最重要的指导是：“尽可能避免设计备用ECN隧道语义”。如果方案要求隧道为某些DSCP实施ECN字段的特殊处理，则很难保证每个隧道的每个实施者都会添加所需的异常，或者运营商会普遍部署所需的更新。单个机构甚至不可能知道网络中的所有隧道，其中可能包括应用程序在端点之间建立的隧道，或在网络中动态创建的隧道。因此，网络内或连接到网络的主机上的某些隧道很可能无法实现所需的特殊情况。
That said, if a non-default scheme for tunnelling the ECN field is really required, the following guidelines might prove useful in its design:
这就是说，如果确实需要一个非默认方案来挖掘ECN油田，那么以下指南在其设计中可能会很有用：
On encapsulation in any alternate scheme:
在任何替代方案中封装时：
1. The ECN field of the outer header ought to be cleared to Not-ECT ("00") unless it is guaranteed that the corresponding tunnel egress will correctly propagate congestion markings introduced across the tunnel in the outer header.
1. 外部集管的ECN字段应清除为Not ECT（“00”），除非保证相应的隧道出口将正确传播通过外部集管中的隧道引入的拥挤标记。
2. If it has established that ECN will be correctly propagated, an encapsulator also ought to copy incoming congestion notification into the outer header. The general principle here is that the outer header should reflect congestion accumulated along the whole upstream path, not just since the tunnel ingress (Appendix B.3 on management and monitoring explains).
2. 如果已确定将正确传播ECN，则封装器还应将传入的拥塞通知复制到外部报头中。此处的一般原则是，外部集管应反映沿整个上游路径累积的拥塞，而不仅仅是隧道入口（关于管理和监控的附录B.3解释）。
In some circumstances (e.g., PCN [RFC5559] and perhaps some pseudowires [RFC5659]), the whole path is divided into segments, each with its own congestion notification and feedback loop. In these cases, the function that regulates load at the start of each segment will need to reset congestion notification for its segment. Often, the point where congestion notification is reset will also be located at the start of a tunnel. However, the resetting function can be thought of as being applied to packets after the encapsulation function -- two logically separate functions even though they might run on the same physical box. Then, the code module doing encapsulation can keep to the copying rule and the load regulator module can reset congestion, without any code in either module being conditional on whether the other is there.
在某些情况下（例如，PCN[RFC5559]和可能的一些伪线[RFC5659]），整个路径被分成若干段，每个段都有自己的拥塞通知和反馈回路。在这些情况下，在每个网段开始时调节负载的功能需要重置其网段的拥塞通知。通常，重置拥塞通知的点也将位于隧道的起点。然而，重置函数可以被认为是应用于封装函数之后的数据包——两个逻辑上独立的函数，即使它们可能在同一个物理盒上运行。然后，进行封装的代码模块可以遵循复制规则，负载调节器模块可以重置拥塞，而两个模块中的任何代码都不以另一个模块是否存在为条件。
On decapsulation in any alternate scheme:
在任何替代方案中进行脱封时：
1. If the arriving inner header is Not-ECT, the transport will not understand other ECN codepoints. If the outer header carries an explicit congestion marking, the alternate scheme would be expected to drop the packet -- the only indication of congestion the transport will understand. If the alternate scheme recommends forwarding rather than dropping such a packet, it will need to clearly justify this decision. If the inner is Not-ECT and the outer carries any other ECN codepoint that does not indicate congestion, the alternate scheme can forward the packet, but probably only as Not-ECT.
1. 如果到达的内部报头不是ECT，则传输将无法理解其他ECN代码点。如果外部报头带有明确的拥塞标记，则替代方案将丢弃数据包——这是传输能够理解的唯一拥塞指示。如果备用方案建议转发而不是丢弃这样的数据包，则需要明确证明这一决定的合理性。如果内部不是ECT，而外部携带任何其他不表示拥塞的ECN码点，则替代方案可以转发数据包，但可能仅作为Not ECT转发。
2. If the arriving inner header is one other than Not-ECT, the ECN field that the alternate decapsulation scheme forwards ought to reflect the more severe congestion marking of the arriving inner and outer headers.
2. 如果到达的内部报头不是ECT，则备用去封装方案转发的ECN字段应该反映到达的内部报头和外部报头的更严重的拥塞标记。
3. Any alternate scheme will need to define a behaviour for all combinations of inner and outer headers, even those that would not be expected to result from standards known at the time and even those that would not be expected from the tunnel ingress paired with the egress at run-time. Consideration should be given to logging such unexpected combinations and raising an alarm, particularly if there is a danger that the invalid combination implies congestion signals are not being propagated correctly. The presence of currently unused combinations may represent an attack, but the new scheme should try to define a way to forward such packets, at least if a safe outgoing codepoint can be defined.
3. 任何替代方案都需要为内外集管的所有组合定义一个行为，即使是那些在当时已知的标准中预计不会产生的行为，甚至是那些在运行时隧道入口与出口配对时预计不会产生的行为。应考虑记录此类意外组合并发出警报，特别是如果存在无效组合意味着拥塞信号未正确传播的危险。当前未使用的组合的存在可能表示攻击，但新方案应尝试定义转发此类数据包的方式，至少在可以定义安全传出代码点的情况下。
Raising an alarm allows a management system to decide whether the anomaly is indeed an attack, in which case it can decide to drop such packets. This is a preferable approach to hard-coded discard of packets that seem anomalous today, but may be needed tomorrow in future standards actions.
发出警报允许管理系统确定异常是否确实是攻击，在这种情况下，它可以决定丢弃此类数据包。这是一种更好的硬编码丢弃数据包的方法，这些数据包今天看起来异常，但明天在未来的标准操作中可能需要。
Appendix B.1 discusses the security constraints imposed on ECN tunnel processing. The new rules for ECN tunnel processing (Section 4) trade-off between information security (covert channels) and traffic security (congestion monitoring and control). Ensuring congestion markings are not lost is itself an aspect of security, because if we allowed congestion notification to be lost, any attempt to enforce a response to congestion would be much harder.
附录B.1讨论了对ECN隧道处理施加的安全约束。ECN隧道处理新规则（第4节）在信息安全（隐蔽通道）和交通安全（拥堵监控）之间进行了权衡。确保拥塞标记不会丢失本身就是安全的一个方面，因为如果我们允许丢失拥塞通知，那么任何强制执行拥塞响应的尝试都将更加困难。
Security issues in unlikely, but possible, scenarios:
不太可能但可能出现的场景中的安全问题：
Tunnels intersecting Diffserv regions with alternate ECN semantics: If alternate congestion notification semantics are defined for a certain Diffserv PHB, the scope of the alternate semantics might typically be bounded by the limits of a Diffserv region or regions, as envisaged in [RFC4774] (e.g., the pre-congestion notification architecture [RFC5559]). The inner headers in tunnels crossing the boundary of such a Diffserv region but ending within the region can potentially leak the external congestion notification semantics into the region, or leak the internal semantics out of the region. [RFC2983] discusses the need for Diffserv traffic conditioning to be applied at these tunnel endpoints as if they are at the edge of the Diffserv region. Similar concerns apply to any processing or propagation of the ECN field at the endpoints of tunnels with one end inside and the other outside the domain. [RFC5559] gives specific advice on this for the PCN case, but other definitions of alternate semantics will need to discuss the specific security implications in each case.
与具有备用ECN语义的区分服务区域相交的隧道：如果为特定区分服务PHB定义了备用拥塞通知语义，则备用语义的范围通常可能受到区分服务区域或区域的限制的限制，如[RFC4774]中所设想的（例如，预拥塞通知架构）[RFC5559]）。隧道中的内部标头跨越此类区分服务区域的边界，但在该区域内结束，可能会将外部拥塞通知语义泄漏到该区域，或将内部语义泄漏到该区域之外。[RFC2983]讨论在这些隧道端点处应用区分服务流量调节的必要性，就像它们位于区分服务区域的边缘一样。类似的问题适用于隧道端点处ECN字段的任何处理或传播，一端在域内，另一端在域外。[RFC5559]针对PCN案例给出了具体的建议，但替代语义的其他定义需要讨论每种情况下的具体安全含义。
ECN nonce tunnel coverage: The new decapsulation rules improve the coverage of the ECN nonce [RFC3540] relative to the previous rules in RFC 3168 and RFC 4301. However, nonce coverage is still not perfect, as this would have led to a safety problem in another case. Both are corner-cases, so discussion of the compromise between them is deferred to Appendix D.
ECN nonce隧道覆盖率：与RFC 3168和RFC 4301中以前的规则相比，新的去封装规则提高了ECN nonce[RFC3540]的覆盖率。然而，目前的覆盖范围还不完善，因为这在另一种情况下会导致安全问题。这两种情况都是极端情况，因此关于它们之间折衷的讨论推迟到附录D。
Covert channel not turned off: A legacy (RFC 3168) tunnel ingress could ask an RFC 3168 egress to turn off ECN processing as well as itself turning off ECN. An egress compliant with the present specification will agree to such a request from a legacy ingress, but it relies on the ingress always sending Not-ECT in the outer header. If the egress receives other ECN codepoints in the outer it will process them as normal, so it will actually still copy congestion markings from the outer to the outgoing header. Referring, for example, to Figure 5 (Appendix B.1), although the tunnel ingress 'I' will set all ECN fields in outer headers to Not-ECT, 'M' could still toggle CE or ECT(1) on and off to communicate covertly with 'B', because we have specified that 'E' only has one mode regardless of what mode it says it has negotiated. We could have specified that 'E' should have a limited functionality mode and check for such behaviour. However, we decided not to add the extra complexity of two modes on a compliant tunnel egress merely to cater for an historic security concern that is now considered manageable.
隐蔽通道未关闭：传统（RFC 3168）隧道入口可能要求RFC 3168出口关闭ECN处理以及自身关闭ECN。符合本规范的出口将同意来自遗留入口的此类请求，但它依赖于入口始终在外部报头中不发送ECT。如果出口在外部接收到其他ECN代码点，它将正常处理这些代码点，因此它实际上仍然会将拥塞标记从外部复制到输出报头。例如，参考图5（附录B.1），尽管隧道入口“I”将外部报头中的所有ECN字段设置为Not ECT，但“M”仍然可以打开和关闭CE或ECT（1）以与“B”进行隐蔽通信，因为我们已经指定“E”只有一种模式，而不管它表示已协商的模式是什么。我们可以指定“E”应该具有有限的功能模式，并检查这种行为。然而，我们决定不在符合要求的隧道出口上增加两种模式的额外复杂性，仅仅是为了满足目前认为可以管理的历史安全问题。
This document allows tunnels to propagate an extra level of congestion severity. It uses previously unused combinations of inner and outer headers to augment the rules for calculating the ECN field when decapsulating IP packets at the egress of IPsec (RFC 4301) and non-IPsec (RFC 3168) tunnels.
本文档允许隧道传播额外级别的拥塞严重性。当在IPsec（RFC 4301）和非IPsec（RFC 3168）隧道的出口处解封装IP数据包时，它使用以前未使用的内部和外部头的组合来扩充计算ECN字段的规则。
This document also updates the ingress tunnelling encapsulation of RFC 3168 ECN to bring all IP-in-IP tunnels into line with the new behaviour in the IPsec architecture of RFC 4301, which copies rather than resets the ECN field when creating outer headers.
本文档还更新了RFC 3168 ECN的入口隧道封装，以使IP隧道中的所有IP符合RFC 4301 IPsec体系结构中的新行为，该行为在创建外部标头时复制而不是重置ECN字段。
The need for both these updated behaviours was triggered by the introduction of pre-congestion notification (PCN) onto the IETF Standards Track. Operators wanting to support PCN or other alternate ECN schemes that use an extra severity level can require that their tunnels comply with the present specification. This is not a fork in the RFC series, it is an update that can be deployed first by those that need it, and subsequently by all tunnel endpoint implementations during general code maintenance. It is backward compatible with all previous tunnelling behaviours, so existing single severity level schemes will continue to work as before, but support for two severity levels will gradually be added to the Internet.
在IETF标准轨道上引入拥塞前通知（PCN）引发了对这两种更新行为的需求。希望支持PCN或其他使用额外严重级别的备用ECN方案的运营商可要求其隧道符合当前规范。这不是RFC系列中的一个分支，它是一个更新，可以首先由需要它的人部署，然后在一般代码维护期间由所有隧道端点实现部署。它与以前的所有隧道行为向后兼容，因此现有的单一严重性级别方案将继续像以前一样工作，但对两个严重性级别的支持将逐渐添加到互联网上。
The new rules propagate changes to the ECN field across tunnel endpoints that previously blocked them to restrict the bandwidth of a potential covert channel. Limiting the channel's bandwidth to two bits per packet is now considered sufficient.
新规则通过先前阻止ECN字段的隧道端点将更改传播到ECN字段，以限制潜在隐蔽通道的带宽。现在，将信道带宽限制在每个数据包两个比特就足够了。
At the same time as removing these legacy constraints, the opportunity has been taken to draw together diverging tunnel specifications into a single consistent behaviour. Then, any tunnel can be deployed unilaterally, and it will support the full range of congestion control and management schemes without any modes or configuration. Further, any host or router can expect the ECN field to behave in the same way, whatever type of tunnel might intervene in the path. This new certainty could enable new uses of the ECN field that would otherwise be confounded by ambiguity.
在消除这些遗留约束的同时，利用这个机会将不同的隧道规范整合成一个统一的行为。然后，任何隧道都可以单方面部署，它将支持全方位的拥塞控制和管理方案，而无需任何模式或配置。此外，任何主机或路由器都可以期望ECN字段以相同的方式运行，不管路径中可能存在何种类型的隧道。这一新的确定性可以使ECN字段有新的用途，否则就会被歧义所混淆。
Thanks to David Black for his insightful reviews and patient explanations of better ways to think about function placement and alarms. Thanks to David and to Anil Agarwal for pointing out cases where it is safe to forward CU combinations of headers. Also, thanks to Arnaud Jacquet for the idea for Appendix C. Thanks to Gorry Fairhurst, Teco Boot, Michael Menth, Bruce Davie, Toby Moncaster,
感谢David Black，他对思考功能放置和警报的更好方法进行了富有洞察力的评论和耐心的解释。感谢David和Anil Agarwal指出了转发页眉组合是安全的情况。同时，感谢Arnaud Jacquet提出附录C的想法。感谢Gorry Fairhurst、Teco Boot、Michael Meth、Bruce Davie、Toby Moncaster、，
Sally Floyd, Alfred Hoenes, Gabriele Corliano, Ingemar Johansson, Philip Eardley, and David Harrington for their thoughts and careful review comments, and to Stephen Hanna, Ben Campbell, and members of the IESG for respectively conducting the Security Directorate, General Area, and IESG reviews.
萨利·弗洛伊德、阿尔弗雷德·霍恩斯、加布里埃尔·科里亚诺、英格马尔·约翰逊、菲利普·埃尔德利和大卫·哈林顿，感谢他们的想法和仔细的审查意见，感谢斯蒂芬·汉纳、本·坎贝尔和IESG成员分别进行安全理事会、总区和IESG审查。
Bob Briscoe is partly funded by Trilogy, a research project (ICT-216372) supported by the European Community under its Seventh Framework Programme.
Bob Briscoe的部分资金来自Trilogy，该研究项目（ICT-216372）由欧洲共同体在其第七个框架计划下支持。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[PCN3in1] Briscoe, B., Moncaster, T., and M. Menth, "Encoding 3 PCN-States in the IP header using a single DSCP", Work in Progress, July 2010.
[PCN3in1]Briscoe，B.，Moncaster，T.，和M.Minth，“使用单个DSCP在IP报头中编码3个PCN状态”，正在进行的工作，2010年7月。
[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月。
[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月。
[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月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces", RFC 3540, June 2003.
[RFC3540]Spring，N.，Weterral，D.，和D.Ely，“带有nonce的鲁棒显式拥塞通知（ECN）信令”，RFC 35402003年6月。
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field", BCP 124, RFC 4774, November 2006.
[RFC4774]Floyd，S.，“为显式拥塞通知（ECN）字段指定替代语义”，BCP 124，RFC 4774，2006年11月。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, January 2008.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，2008年1月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559]Eardley，P.，“拥塞前通知（PCN）体系结构”，RFC555592009年6月。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659]Bocci，M.和S.Bryant，“多段伪线边到边仿真的体系结构”，RFC 5659，2009年10月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670]Eardley，P.，“PCN节点的计量和标记行为”，RFC 56702009年11月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696]Moncaster，T.，Briscoe，B.，和M.Minth，“拥堵前信息的基线编码和传输”，RFC 56962009年11月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[VCP] Xia, Y., Subramanian, L., Stoica, I., and S. Kalyanaraman, "One more bit is enough", Proc. SIGCOMM'05, ACM CCR 35(4)37--48, 2005, <http://doi.acm.org/10.1145/1080091.1080098>.
[VCP]Xia，Y.，Subramanian，L.，Stoica，I.，和S.Kalyanaraman，“多一点就够了”，Proc。SIGCOMM'05，ACM CCR 35（4）37-482005<http://doi.acm.org/10.1145/1080091.1080098>.
IP-in-IP tunnelling was originally defined in [RFC2003]. On encapsulation, the incoming header was copied to the outer and on decapsulation, the outer was simply discarded. Initially, IPsec tunnelling [RFC2401] followed the same behaviour.
IP隧道中的IP最初在[RFC2003]中定义。在封装时，传入的头被复制到外部，而在解除封装时，外部被简单地丢弃。最初，IPsec隧道[RFC2401]遵循相同的行为。
When ECN was introduced experimentally in [RFC2481], legacy (RFC 2003 or RFC 2401) tunnels would have discarded any congestion markings added to the outer header, so RFC 2481 introduced rules for calculating the outgoing header from a combination of the inner and outer on decapsulation. RFC 2481 also introduced a second mode for IPsec tunnels, which turned off ECN processing (Not-ECT) in the outer header on encapsulation because an RFC 2401 decapsulator would discard the outer on decapsulation. For RFC 2401 IPsec, this had the side effect of completely blocking the covert channel.
当在[RFC2481]中通过实验引入ECN时，传统（RFC 2003或RFC 2401）隧道将丢弃添加到外部标头的任何拥塞标记，因此RFC 2481引入了从内部和外部去封装组合计算输出标头的规则。RFC 2481还为IPsec隧道引入了第二种模式，该模式在封装时关闭外部标头中的ECN处理（非ECT），因为RFC 2401解封装器将在解封装时丢弃外部标头。对于RFC 2401 IPsec，这会产生完全阻塞隐蔽通道的副作用。
In RFC 2481, the ECN field was defined as two separate bits. But when ECN moved from Experimental to Standards Track [RFC3168], the ECN field was redefined as four codepoints. This required a different calculation of the ECN field from that used in RFC 2481 on decapsulation. RFC 3168 also had two modes; a 'full functionality mode' that restricted the covert channel as much as possible but still allowed ECN to be used with IPsec, and another that completely turned off ECN processing across the tunnel. This 'limited functionality mode' both offered a way for operators to completely block the covert channel and allowed an RFC 3168 ingress to interwork with a legacy tunnel egress (RFC 2481, RFC 2401, or RFC 2003).
在RFC2481中，ECN字段定义为两个独立的位。但当ECN从实验轨道移到标准轨道[RFC3168]时，ECN场被重新定义为四个码点。这需要对ECN场进行不同于RFC 2481中关于脱封的计算。RFC3168也有两种模式；一种“全功能模式”，尽可能限制隐蔽通道，但仍允许ECN与IPsec一起使用，另一种完全关闭隧道中的ECN处理。这种“有限功能模式”为操作员提供了一种完全阻断隐蔽通道的方法，并允许RFC 3168入口与传统隧道出口（RFC 2481、RFC 2401或RFC 2003）互通。
The present specification includes a similar compatibility mode to interwork safely with tunnels compliant with any of these three earlier RFCs. However, unlike RFC 3168, it is only a mode of the ingress, as decapsulation behaviour is the same in either case.
本规范包括一个类似的兼容模式，用于与符合这三个早期RFC中任何一个的隧道安全互通。然而，和RFC3168不同的是，它只是一种进入模式，因为在这两种情况下，脱封行为是相同的。
Tunnel processing of a congestion notification field has to meet congestion control and management needs without creating new information security vulnerabilities (if information security is required). This appendix documents the analysis of the trade-offs between these factors that led to the new encapsulation rules in Section 4.1.
拥塞通知字段的隧道处理必须满足拥塞控制和管理需求，而不会产生新的信息安全漏洞（如果需要信息安全）。本附录记录了导致第4.1节中新封装规则的这些因素之间的权衡分析。
Information security can be assured by using various end-to-end security solutions (including IPsec in transport mode [RFC4301]), but a commonly used scenario involves the need to communicate between two
可以通过使用各种端到端安全解决方案（包括传输模式下的IPsec[RFC4301]）来确保信息安全，但通常使用的场景涉及到需要在两个服务器之间进行通信
physically protected domains across the public Internet. In this case, there are certain management advantages to using IPsec in tunnel mode solely across the publicly accessible part of the path. The path followed by a packet then crosses security 'domains'; the ones protected by physical or other means before and after the tunnel and the one protected by an IPsec tunnel across the otherwise unprotected domain. The scenario in Figure 5 will be used where endpoints 'A' and 'B' communicate through a tunnel. The tunnel ingress 'I' and egress 'E' are within physically protected edge domains, while the tunnel spans an unprotected internetwork where there may be 'men in the middle', M.
公共Internet上的物理保护域。在这种情况下，在隧道模式下仅跨路径的公共可访问部分使用IPsec具有某些管理优势。然后，数据包后面的路径穿过安全“域”；在隧道前后通过物理或其他方式保护的，以及通过IPsec隧道跨其他未受保护的域保护的。图5中的场景将用于端点“A”和“B”通过隧道进行通信的情况。隧道入口“I”和出口“E”位于物理保护的边缘域内，而隧道跨越未受保护的互联网络，其中可能有“中间人”，M。
physically unprotected physically
<-protected domain-><--domain--><-protected domain->
+------------------+ +------------------+
| | M | |
| A-------->I=========>==========>E-------->B |
| | | |
+------------------+ +------------------+
<----IPsec secured---->
tunnel
physically unprotected physically
<-protected domain-><--domain--><-protected domain->
+------------------+ +------------------+
| | M | |
| A-------->I=========>==========>E-------->B |
| | | |
+------------------+ +------------------+
<----IPsec secured---->
tunnel
Figure 5: IPsec Tunnel Scenario
图5:IPsec隧道场景
IPsec encryption is typically used to prevent 'M' seeing messages from 'A' to 'B'. IPsec authentication is used to prevent 'M' masquerading as the sender of messages from 'A' to 'B' or altering their contents. 'I' can use IPsec tunnel mode to allow 'A' to communicate with 'B', but impose encryption to prevent 'A' leaking information to 'M'. Or 'E' can insist that 'I' uses tunnel mode authentication to prevent 'M' communicating information to 'B'.
IPsec加密通常用于防止“M”看到从“A”到“B”的消息。IPsec身份验证用于防止“M”冒充从“A”到“B”的消息的发件人或更改其内容I'可以使用IPsec隧道模式允许'A'与'B'通信，但强制加密以防止'A'向'M'泄漏信息。或者“E”可以坚持“I”使用隧道模式身份验证来阻止“M”将信息传递给“B”。
Mutable IP header fields such as the ECN field (as well as the Time to Live (TTL) / Hop Limit and DS fields) cannot be included in the cryptographic calculations of IPsec. Therefore, if 'I' copies these mutable fields into the outer header that is exposed across the tunnel it will have allowed a covert channel from 'A' to 'M' that bypasses its encryption of the inner header. And if 'E' copies these fields from the outer header to the outgoing, even if it validates authentication from 'I', it will have allowed a covert channel from 'M' to 'B'.
可变IP头字段，如ECN字段（以及生存时间（TTL）/跃点限制和DS字段）不能包含在IPsec的加密计算中。因此，如果“I”将这些可变字段复制到通过隧道公开的外部报头中，它将允许从“a”到“M”的隐蔽通道绕过内部报头的加密。如果“E”将这些字段从外部报头复制到传出报头，即使它验证了来自“I”的身份验证，它也将允许从“M”到“B”的隐蔽通道。
ECN at the IP layer is designed to carry information about congestion from a congested resource towards downstream nodes. Typically, a downstream transport might feed the information back somehow to the point upstream of the congestion that can regulate the load on the congested resource, but other actions are possible [RFC3168], Section 6. In terms of the above unicast scenario, ECN effectively intends
IP层的ECN设计用于将拥塞信息从拥塞资源传送到下游节点。通常，下游传输可能以某种方式将信息反馈到拥塞上游的点，该点可以调节拥塞资源上的负载，但也可能采取其他措施[RFC3168]，第6节。就上述单播场景而言，ECN有效地
to create an information channel (for congestion signalling) from 'M' to 'B' (for 'B' to feed back to 'A'). Therefore, the goals of IPsec and ECN are mutually incompatible, requiring some compromise.
创建从“M”到“B”的信息通道（用于拥塞信令），“B”反馈到“A”）。因此，IPsec和ECN的目标互不兼容，需要一些折衷。
With respect to using the DS or ECN fields as covert channels, Section 5.1.2 of RFC 4301 says, "controls are provided to manage the bandwidth of this channel". Using the ECN processing rules of RFC 4301, the channel bandwidth is two bits per datagram from 'A' to 'M' and one bit per datagram from 'M' to 'B' (because 'E' limits the combinations of the 2-bit ECN field that it will copy). In both cases, the covert channel bandwidth is further reduced by noise from any real congestion marking. RFC 4301 implies that these covert channels are sufficiently limited to be considered a manageable threat. However, with respect to the larger (six-bit) DS field, the same section of RFC 4301 says not copying is the default, but a configuration option can allow copying "to allow a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying". Of course, an administrator who plans to copy the DS field has to take into account that it could be concatenated with the ECN field, creating a covert channel with eight bits per datagram.
关于使用DS或ECN字段作为隐蔽信道，RFC 4301第5.1.2节说，“提供控制以管理该信道的带宽”。使用RFC 4301的ECN处理规则，信道带宽是从“A”到“M”的每个数据报两位，从“M”到“B”的每个数据报一位（因为“E”限制它将复制的2位ECN字段的组合）。在这两种情况下，任何真实拥塞标记的噪声都会进一步降低隐蔽信道带宽。RFC 4301意味着这些隐蔽通道受到足够的限制，被视为可管理的威胁。然而，对于较大的（六位）DS字段，RFC 4301的同一部分表示默认情况下不复制，但配置选项可以允许复制“以允许本地管理员决定复制这些位所提供的隐蔽通道是否超过复制的好处”。当然，计划复制DS字段的管理员必须考虑到它可以与ECN字段连接，从而创建一个每个数据报8位的隐蔽通道。
For tunnelling the six-bit Diffserv field, two conceptual models have had to be defined so that administrators can trade off security against the needs of traffic conditioning [RFC2983]:
对于六位Diffserv字段的隧道传输，必须定义两个概念模型，以便管理员可以根据流量调节的需要权衡安全性[RFC2983]：
The uniform model: where the Diffserv field is preserved end-to-end by copying into the outer header on encapsulation and copying from the outer header on decapsulation.
统一模型：其中，通过在封装时复制到外部报头，并在解除封装时从外部报头复制，端到端保留Diffserv字段。
The pipe model: where the outer header is independent of that in the inner header so it hides the Diffserv field of the inner header from any interaction with nodes along the tunnel.
管道模型：其中外部报头独立于内部报头中的报头，因此它隐藏了内部报头的Diffserv字段，以防与隧道沿线的节点发生任何交互。
However, for ECN, the new IPsec security architecture in RFC 4301 only standardised one tunnelling model equivalent to the uniform model. It deemed that simplicity was more important than allowing administrators the option of a tiny increment in security, especially given not copying congestion indications could seriously harm everyone's network service.
然而，对于ECN，RFC 4301中新的IPsec安全体系结构仅标准化了一个隧道模型，相当于统一模型。它认为简单性比允许管理员选择安全性的微小提高更重要，特别是考虑到不复制拥塞指示可能严重损害每个人的网络服务。
Congestion control requires that any congestion notification marked into packets by a resource will be able to traverse a feedback loop back to a function capable of controlling the load on that resource. To be precise, rather than calling this function the data source, it will be called the 'Load Regulator'. This allows for exceptional
拥塞控制要求由资源标记为数据包的任何拥塞通知都能够穿过反馈回路返回到能够控制该资源负载的函数。准确地说，它将被称为“负载调节器”，而不是将此函数称为数据源。这就考虑到了特殊情况
cases where load is not regulated by the data source, but usually the two terms will be synonymous. Note the term "a function _capable of_ controlling the load" deliberately includes a source application that doesn't actually control the load but ought to (e.g., an application without congestion control that uses UDP).
负载不受数据源调节，但这两个术语通常是同义词的情况。注意术语“能够控制负载的函数”故意包括一个源应用程序，该源应用程序实际上并不控制负载，但应该控制（例如，一个没有使用UDP的拥塞控制的应用程序）。
A--->R--->I=========>M=========>E-------->B
A--->R--->I=========>M=========>E-------->B
Figure 6: Simple Tunnel Scenario
图6：简单隧道场景
A similar tunnelling scenario to the IPsec one just described will now be considered, but without the different security domains, because the focus now shifts to whether the control loop and management monitoring work (Figure 6). If resources in the tunnel are to be able to explicitly notify congestion and the feedback path is from 'B' to 'A', it will certainly be necessary for 'E' to copy any CE marking from the outer header to the outgoing header for onward transmission to 'B'; otherwise, congestion notification from resources like 'M' cannot be fed back to the Load Regulator ('A'). But it does not seem necessary for 'I' to copy CE markings from the incoming to the outer header. For instance, if resource 'R' is congested, it can send congestion information to 'B' using the congestion field in the inner header without 'I' copying the congestion field into the outer header and 'E' copying it back to the outgoing header. 'E' can still write any additional congestion marking introduced across the tunnel into the congestion field of the outgoing header.
现在将考虑与刚才描述的IPsec类似的隧道场景，但不考虑不同的安全域，因为现在的焦点转移到控制循环和管理监视是否工作（图6）。如果隧道中的资源能够明确通知拥塞，并且反馈路径是从“B”到“A”，则“E”肯定有必要将任何CE标记从外部报头复制到输出报头，以便向前传输到“B”；否则，来自“M”等资源的拥塞通知无法反馈给负载调节器（“A”）。但“I”似乎没有必要将CE标记从输入端复制到外部标题。例如，如果资源“R”拥塞，它可以使用内部报头中的拥塞字段向“B”发送拥塞信息，而无需“I”将拥塞字段复制到外部报头中，“E”将其复制回传出报头E'仍然可以将通过隧道引入的任何附加拥塞标记写入传出报头的拥塞字段。
All this shows that 'E' can preserve the control loop irrespective of whether 'I' copies congestion notification into the outer header or resets it.
所有这些都表明，无论“I”是将拥塞通知复制到外部报头还是重置它，“E”都可以保留控制循环。
That is the situation for existing control arrangements but, because copying reveals more information, it would open up possibilities for better control system designs. For instance, resetting CE marking on encapsulation breaks the Standards-Track PCN congestion marking scheme [RFC5670]. It ends up removing excessive amounts of traffic unnecessarily (Section 5.3.1). Whereas copying CE markings at ingress leads to the correct control behaviour.
这是现有控制安排的情况，但由于复制会揭示更多信息，因此将为更好的控制系统设计提供可能性。例如，在封装上重置CE标记会破坏标准轨道PCN拥塞标记方案[RFC5670]。它最终不必要地消除了过多的交通量（第5.3.1节）。然而，在入口复制CE标记可导致正确的控制行为。
As well as control, there are also management constraints. Specifically, a management system may monitor congestion markings in passing packets, perhaps at the border between networks as part of a service level agreement. For instance, monitors at the borders of
除了控制，还有管理方面的限制。具体地说，作为服务水平协议的一部分，管理系统可以监控传送分组中的拥塞标记，可能在网络之间的边界处。例如，在国家边界进行监视
autonomous systems may need to measure how much congestion has accumulated so far along the path, perhaps to determine between them how much of the congestion is contributed by each domain.
自治系统可能需要测量迄今为止在路径上累积了多少拥塞，也许是为了确定它们之间每个域贡献了多少拥塞。
In this document, the baseline of congestion marking (or the Congestion Baseline) is defined as the source of the layer that created (or most recently reset) the congestion notification field. When monitoring congestion, it would be desirable if the Congestion Baseline did not depend on whether or not packets were tunnelled. Given some tunnels cross domain borders (e.g., consider 'M' in Figure 6 is monitoring a border), it would therefore be desirable for 'I' to copy congestion accumulated so far into the outer headers, so that it is exposed across the tunnel.
在本文档中，拥塞标记基线（或拥塞基线）定义为创建（或最近重置）拥塞通知字段的层的源。在监控拥塞时，如果拥塞基线不依赖于是否对数据包进行隧道传输，那么这将是可取的。给定一些隧道跨域边界（例如，考虑图6中的M’正在监视边界），因此，“I”需要复制迄今累积到外部标头中的拥塞，从而使其暴露在隧道中。
For management purposes, it might be useful for the tunnel egress to be able to monitor whether congestion occurred across a tunnel or upstream of it. Superficially, it appears that copying congestion markings at the ingress would make this difficult, whereas it was straightforward when an RFC 3168 ingress reset them. However, Appendix C gives a simple and precise method for a tunnel egress to infer the congestion level introduced across a tunnel. It works irrespective of whether the ingress copies or resets congestion markings.
出于管理目的，隧道出口能够监控隧道或其上游是否发生拥堵可能是有用的。从表面上看，似乎在入口复制拥塞标记会使这变得困难，而当RFC3168入口重置它们时，这是很简单的。然而，附录C给出了隧道出口的一种简单而精确的方法，以推断隧道中引入的拥挤程度。无论入口是否复制或重置拥塞标记，它都可以工作。
This specification mandates that a tunnel ingress determines the ECN field of each new outer tunnel header by copying the arriving header. Concern has been expressed that this will make it difficult for the tunnel egress to monitor congestion introduced only along a tunnel, which is easy if the outer ECN field is reset at a tunnel ingress (RFC 3168 full functionality mode). However, in fact copying CE marks at ingress will still make it easy for the egress to measure congestion introduced across a tunnel, as illustrated below.
本规范要求隧道入口通过复制到达的报头来确定每个新外部隧道报头的ECN字段。有人担心，这将使隧道出口难以监控仅沿隧道引入的拥堵，如果在隧道入口重置外部ECN字段（RFC 3168全功能模式），这很容易。然而，事实上，在入口复制CE标记仍将使出口更容易测量穿过隧道引入的拥堵，如下所示。
Consider 100 packets measured at the egress. Say it measures that 30 are CE marked in the inner and outer headers and 12 have additional CE marks in the outer but not the inner. This means packets arriving at the ingress had already experienced 30% congestion. However, it does not mean there was 12% congestion across the tunnel. The correct calculation of congestion across the tunnel is p_t = 12/ (100-30) = 12/70 = 17%. This is easy for the egress to measure. It is simply the proportion of packets not marked in the inner header (70) that have a CE marking in the outer header (12). This technique works whether the ingress copies or resets CE markings, so it can be used by an egress that is not sure with which RFC the ingress complies.
考虑在出口处测量的100个数据包。假设它测量了30个在内部和外部标题中有CE标记，12个在外部有额外的CE标记，但在内部没有。这意味着到达入口的数据包已经经历了30%的拥塞。然而，这并不意味着整个隧道有12%的拥堵。隧道拥堵的正确计算方法为p_t=12/（100-30）=12/70=17%。这对于出口来说很容易测量。这仅仅是未在内部报头（70）中标记的分组在外部报头（12）中具有CE标记的比例。无论入口是否复制或重置CE标记，该技术都有效，因此不确定入口是否符合RFC的出口可以使用该技术。
Figure 7 illustrates this in a combinatorial probability diagram. The square represents 100 packets. The 30% division along the bottom represents marking before the ingress, and the p_t division up the side represents marking introduced across the tunnel.
图7用组合概率图说明了这一点。正方形代表100个数据包。沿底部的30%分区表示入口前的标记，沿侧面的p_t分区表示穿过隧道引入的标记。
^ outer header marking
|
100% +-----+---------+ The large square
| | | represents 100 packets
| 30 | |
| | | p_t = 12/(100-30)
p_t + +---------+ = 12/70
| | 12 | = 17%
0 +-----+---------+--->
0 30% 100% inner header marking
^ outer header marking
|
100% +-----+---------+ The large square
| | | represents 100 packets
| 30 | |
| | | p_t = 12/(100-30)
p_t + +---------+ = 12/70
| | 12 | = 17%
0 +-----+---------+--->
0 30% 100% inner header marking
Figure 7: Tunnel Marking of Packets Already Marked at Ingress
图7：入口已标记的包的隧道标记
Appendix D. Compromise on Decap with ECT(1) Inner and ECT(0) Outer
附录D.带内部ECT（1）和外部ECT（0）的德卡普折衷方案
A packet with an ECT(1) inner and an ECT(0) outer should never arise from any known IETF protocol. Without giving a reason, RFC 3168 and RFC 4301 both say the outer should be ignored when decapsulating such a packet. This appendix explains why it was decided not to change this advice.
具有ECT（1）内部和ECT（0）外部的数据包不应来自任何已知的IETF协议。在没有给出原因的情况下，RFC3168和RFC4301都表示，在对这样的数据包进行去封装时，应该忽略外部。本附录解释了决定不更改此建议的原因。
In summary, ECT(0) always means 'not congested' and ECT(1) may imply the same [RFC3168] or it may imply a higher severity congestion signal [RFC4774], [PCN3in1], depending on the transport in use. Whether or not they mean the same, at the ingress the outer should have started the same as the inner, and only a broken or compromised router could have changed the outer to ECT(0).
总之，ECT（0）始终表示“未拥塞”，ECT（1）可能表示相同的[RFC3168]，也可能表示更严重的拥塞信号[RFC4774]，[PCN3in1]，具体取决于使用的传输。无论它们的意思是否相同，在入口处，外部应该与内部启动相同，并且只有损坏或受损的路由器才能将外部更改为ECT（0）。
The decapsulator can detect this anomaly. But the question is, should it correct the anomaly by ignoring the outer, or should it reveal the anomaly to the end-to-end transport by forwarding the outer?
去封装器可以检测到这种异常。但问题是，它应该通过忽略外部来纠正异常，还是应该通过转发外部来向端到端传输揭示异常？
On balance, it was decided that the decapsulator should correct the anomaly, but log the event and optionally raise an alarm. This is the safe action if ECT(1) is being used as a more severe marking than ECT(0), because it passes the more severe signal to the transport. However, it is not a good idea to hide anomalies, which is why an optional alarm is suggested. It should be noted that this anomaly may be the result of two changes to the outer: a broken or compromised router within the tunnel might be erasing congestion markings introduced earlier in the same tunnel by a congested router.
总的来说，决定去封装器应纠正异常，但应记录事件并选择性地发出警报。如果ECT（1）被用作比ECT（0）更严重的标记，这是安全的操作，因为它将更严重的信号传递给运输。然而，隐藏异常不是一个好主意，这就是为什么建议使用可选报警的原因。应该注意的是，这种异常可能是对外部的两个更改的结果：隧道内的损坏或受损路由器可能正在擦除拥塞路由器先前在同一隧道中引入的拥塞标记。
In this case, the anomaly would be losing congestion signals, which needs immediate attention.
在这种情况下，异常情况将丢失拥塞信号，这需要立即注意。
The original reason for defining ECT(0) and ECT(1) as equivalent was so that the data source could use the ECN nonce [RFC3540] to detect if congestion signals were being erased. However, in this case, the decapsulator does not need a nonce to detect any anomalies introduced within the tunnel, because it has the inner as a record of the header at the ingress. Therefore, it was decided that the best compromise would be to give precedence to solving the safety issue over revealing the anomaly, because the anomaly could at least be detected and dealt with internally.
将ECT（0）和ECT（1）定义为等效的最初原因是，数据源可以使用ECN nonce[RFC3540]来检测拥塞信号是否被擦除。然而，在这种情况下，去封装器不需要一个nonce来检测隧道内引入的任何异常，因为它在入口处具有作为报头记录的内部数据。因此，决定最好的折衷办法是优先解决安全问题，而不是揭露异常，因为异常至少可以在内部检测和处理。
Superficially, the opposite case where the inner and outer carry different ECT values, but with an ECT(1) outer and ECT(0) inner, seems to require a similar compromise. However, because that case is reversed, no compromise is necessary; it is best to forward the outer whether the transport expects the ECT(1) to mean a higher severity than ECT(0) or the same severity. Forwarding the outer either preserves a higher value (if it is higher) or it reveals an anomaly to the transport (if the two ECT codepoints mean the same severity).
从表面上看，内部和外部具有不同的ECT值，但外部具有ECT（1）和内部具有ECT（0）的相反情况似乎需要类似的折衷。然而，由于情况正好相反，因此不需要妥协；无论传输预期ECT（1）的严重性高于ECT（0）还是相同的严重性，最好转发外部消息。转发外部数据或保留较高的值（如果较高），或显示传输异常（如果两个ECT代码点表示相同的严重性）。
The new decapsulation behaviour defined in Section 4.2 adds support for propagation of two severity levels of congestion. However, transports have no way to discover whether there are any legacy tunnels on their path that will not propagate two severity levels. It would have been nice to add a feature for transports to check path support, but this remains an open issue that will have to be addressed in any future standards action to define an end-to-end scheme that requires two severity levels of congestion. PCN avoids this problem because it is only for a controlled region, so all legacy tunnels can be upgraded by the same operator that deploys PCN.
第4.2节中定义的新去封装行为增加了对两种严重程度拥塞传播的支持。但是，传输无法发现其路径上是否存在不会传播两个严重级别的遗留隧道。为传输添加一个检查路径支持的功能本来是不错的，但这仍然是一个有待解决的问题，必须在未来的任何标准行动中加以解决，以定义需要两个严重程度拥塞的端到端方案。PCN避免了这个问题，因为它只适用于控制区域，所以所有传统隧道都可以由部署PCN的同一运营商升级。
Author's Address
作者地址
Bob Briscoe BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK
Bob Briscoe BT B54/77，英国阿达斯特拉尔公园马特勒沙姆希思伊普斯维奇IP5 3RE
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/