Independent Submission M. Luckie
Request for Comments: 7514 CAIDA
Category: Experimental 1 April 2015
ISSN: 2070-1721
Independent Submission M. Luckie
Request for Comments: 7514 CAIDA
Category: Experimental 1 April 2015
ISSN: 2070-1721
Really Explicit Congestion Notification (RECN)
真正明确的拥塞通知（RECN）
Abstract
摘要
This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).
本文档提出了一种新的ICMP消息，路由器或主机可使用该消息来建议主机在主机忽略数据包丢失和显式拥塞通知（ECN）提供的其他信号的情况下降低其发送速率。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7514.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7514.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. RECN Message Format . . . . . . . . . . . . . . . . . . . . . 2
2.1. Advice to Implementers . . . . . . . . . . . . . . . . . 3
2.2. Relationship to ICMP Source Quench . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. RECN Message Format . . . . . . . . . . . . . . . . . . . . . 2
2.1. Advice to Implementers . . . . . . . . . . . . . . . . . 3
2.2. Relationship to ICMP Source Quench . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
The deployment of Explicit Congestion Notification (ECN) [RFC3168] remains stalled. While most operating systems support ECN, it is currently disabled by default because of fears that enabling ECN will break transport protocols. This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals such as packet loss and ECN. We call this message the "Really Explicit Congestion Notification" (RECN) message because it delivers a less subtle indication of congestion than packet loss and ECN.
显式拥塞通知（ECN）[RFC3168]的部署仍处于暂停状态。虽然大多数操作系统都支持ECN，但由于担心启用ECN会破坏传输协议，目前默认情况下它被禁用。本文档提出了一种新的ICMP消息，路由器或主机可使用该消息来建议主机在主机忽略其他信号（如数据包丢失和ECN）的情况下降低其发送速率。我们将此消息称为“真正明确的拥塞通知”（RECN）消息，因为它提供的拥塞指示没有数据包丢失和ECN那么微妙。
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]中所述进行解释。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Explicit Notification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of the invoking packet as possible |
+ without the ICMP packet exceeding 576 bytes |
| in IPv4 or the minimum MTU in IPv6 |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Explicit Notification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of the invoking packet as possible |
+ without the ICMP packet exceeding 576 bytes |
| in IPv4 or the minimum MTU in IPv6 |
Type
类型
IPv4: 4
IPv4:4
IPv6: 201
IPv6:201
Code
密码
0
0
Checksum
校验和
The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP type field. When an RECN message is encapsulated in an IPv6 packet, the computation includes a "pseudo-header" of IPv6 header fields as specified in Section 8.1 of [RFC2460]. For computing the checksum, the checksum field is first set to zero.
校验和是从ICMP类型字段开始的ICMP消息的16位1的补码和。当RECN消息封装在IPv6数据包中时，计算包括[RFC2460]第8.1节中规定的IPv6报头字段的“伪报头”。为了计算校验和，校验和字段首先设置为零。
Explicit Notification
明确通知
A 4-byte value that conveys an explicit notification in the ASCII format defined in [RFC20]. This field MUST NOT be set to zero.
以[RFC20]中定义的ASCII格式传递显式通知的4字节值。此字段不能设置为零。
Description
描述
An RECN message SHOULD be sent by a router in response to a host that is generating traffic at a rate persistently unfair to other competing flows and that has not reacted to previous packet losses or ECN marks.
路由器应发送RECN消息以响应主机，该主机以对其他竞争流持续不公平的速率生成流量，并且未对以前的数据包丢失或ECN标记做出响应。
The contents of an RECN message MUST be conveyed to the user responsible for the traffic. Precisely how this is accomplished will depend on the capabilities of the host. If text-to-speech capabilities are available, the contents should be converted to sound form and audibly rendered. If the system is currently muted, a pop-up message will suffice.
RECN消息的内容必须传达给负责通信的用户。具体实现方式取决于主机的能力。如果文本到语音功能可用，则应将内容转换为声音形式并以声音呈现。如果系统当前处于静音状态，则弹出消息即可。
As the Explicit Notification field is only 4 bytes, it is not required that the word be null terminated. A client implementation should be careful not to use more than those 4 bytes. If a router chooses a word less than 4 bytes in size, it should null-terminate that word.
由于显式通知字段只有4个字节，因此不需要以null结尾。客户端实现应该小心，不要使用超过这4个字节。如果路由器选择一个小于4字节的字，它应该以null终止该字。
A router should not necessarily send an RECN message every time it discards a packet due to congestion. Rather, a router should send these messages whenever it discards a burst of packets from a single sender. For every packet a router discards in a single burst, it should send an RECN message. A router may form short sentences composed of different 4-byte words, and a host should play these sentences back to the user. A router may escalate the content in the Explicit Notification field if it determines that a sender has not
路由器不必在每次因拥塞而丢弃数据包时发送RECN消息。相反，路由器应该在丢弃来自单个发送方的突发数据包时发送这些消息。对于路由器在一次突发中丢弃的每个数据包，它应该发送一条RECN消息。路由器可以形成由不同的4字节单词组成的短句，主机应该将这些句子播放给用户。如果路由器确定发送方未发送，则可以升级显式通知字段中的内容
adjusted its transmission rate in response to previous RECN messages. There is no upper bound on the intensity of the escalation, either in content or sentence length.
调整其传输速率以响应以前的RECN消息。无论在内容还是句子长度上，升级的强度都没有上限。
The RECN message was inspired by the ICMP Source Quench message, which is now deprecated [RFC6633]. Because the RECN message uses a similar approach, an RECN message uses the same ICMP type when encapsulated in IPv4 as was used by the ICMP Source Quench message.
RECN消息的灵感来自ICMP源猝灭消息，该消息现已被弃用[RFC6633]。因为RECN消息使用类似的方法，所以当封装在IPv4中时，RECN消息使用与ICMP源消息相同的ICMP类型。
This is an Experimental RFC; the experiment will conclude two years after the publication of this RFC. During the experiment, implementers are free to use words of their own choosing (up to four letters) in RECN messages. If RECN becomes a Standard of any kind, a list of allowed words will be maintained in an IANA registry. There are no IANA actions required at this time.
这是一个实验性RFC；实验将在本RFC出版两年后结束。在实验期间，实现者可以在RECN消息中自由使用自己选择的单词（最多四个字母）。如果RECN成为任何类型的标准，IANA注册表中将保留一个允许的单词列表。目前不需要IANA行动。
ICMP messages may be used in various attacks [RFC5927]. An attacker may use the RECN message to cause a host to reduce their transmission rate for no reason. To prevent such an attack, a host must ensure the quoted message corresponds to an active flow on the system, and an attacker MUST set the security flag defined in [RFC3514] to 1 when the RECN message is carried in an IPv4 packet.
ICMP消息可用于各种攻击[RFC5927]。攻击者可以使用RECN消息使主机无故降低其传输速率。为了防止此类攻击，主机必须确保引用的消息对应于系统上的活动流，并且当在IPv4数据包中携带RECN消息时，攻击者必须将[RFC3514]中定义的安全标志设置为1。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003, <http://www.rfc-editor.org/info/rfc3514>.
[RFC3514]Bellovin，S.，“IPv4头中的安全标志”，RFC 3514，2003年4月<http://www.rfc-editor.org/info/rfc3514>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010, <http://www.rfc-editor.org/info/rfc5927>.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月<http://www.rfc-editor.org/info/rfc5927>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012, <http://www.rfc-editor.org/info/rfc6633>.
[RFC6633]Gont，F.，“ICMP源猝灭消息的弃用”，RFC 6633，2012年5月<http://www.rfc-editor.org/info/rfc6633>.
Author's Address
作者地址
Matthew Luckie CAIDA University of California, San Diego 9500 Gilman Drive La Jolla, CA 92093-0505 United States
马修卢基凯达加利福尼亚大学，圣地亚哥9500吉尔曼驱动拉霍拉，加州92093-0505美国
EMail: mjl@caida.org
EMail: mjl@caida.org