Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Key and Sequence Number Extensions to GRE
GRE的键和序列号扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1].
GRE（通用路由封装）指定一个协议，用于在另一个任意网络层协议上封装任意协议。本文档描述了两个字段（键和序列号）可以选择性地在GRE标题中携带的扩展[1]。
The current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. The Sequence Number field is used to maintain sequence of packets within the GRE Tunnel.
通用路由封装的当前规范[1]指定了一种协议，用于在另一个任意网络层协议上封装任意协议。本文档描述了两个字段（键和序列号）的增强功能，这两个字段可以选择性地携带在GRE标题中[1]。关键字段用于识别隧道内的单个交通流。序列号字段用于维护GRE隧道内的数据包序列。
The keywords "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 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
In addition, the following words are used to signify the requirements of the specification.
此外，以下词语用于表示本规范的要求。
Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
静默放弃实现放弃数据报，无需进一步处理，也无需向发送方指示错误。实现应提供记录错误的能力，包括丢弃数据报的内容，并应在统计计数器中记录事件。
The GRE packet header[1] has the following format:
GRE数据包头[1]具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed GRE header will have the following format:
建议的GRE标题将采用以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Present (bit 2)
钥匙存在（第2位）
If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header.
如果密钥存在位设置为1，则表示GRE报头中存在密钥字段。否则，GRE标题中不存在密钥字段。
Sequence Number Present (bit 3)
序列号存在（第3位）
If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header.
如果序列号存在位设置为1，则表示序列号字段存在。否则，GRE标头中不存在序列号字段。
The Key and the Sequence Present bits are chosen to be compatible with RFC 1701 [2].
选择的密钥和序列存在位与RFC 1701[2]兼容。
The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. For example, packets may need to be routed based on context information not present in the encapsulated data. The Key field provides this context and defines a logical traffic flow between encapsulator and decapsulator. Packets belonging to a traffic flow are encapsulated using the same Key value and the decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key Field value.
密钥字段包含由封装器插入的四个八位组编号。获取此密钥的实际方法超出了本文档的范围。关键字段用于识别隧道内的单个交通流。例如，可能需要基于封装数据中不存在的上下文信息来路由分组。键字段提供此上下文，并定义封装器和解封装器之间的逻辑通信流。属于业务流的分组使用相同的密钥值进行封装，并且解封装隧道端点基于密钥字段值识别属于业务流的分组。
The Sequence Number field is a four byte field and is inserted by the encapsulator when Sequence Number Present Bit is set. The Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Sequence Field is to provide unreliable but in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the traffic flow identified by the Key field. Note that packets without the sequence bit set can be interleaved with packets with the sequence bit set.
序列号字段是一个四字节字段，在设置序列号当前位时由封装器插入。接收器必须使用序列号来确定数据包从封装器传输到接收器的顺序。序列字段的预期用途是提供不可靠但有序的交付。如果设置了密钥存在位（位2），则序列号特定于密钥字段标识的交通流。注意，没有序列位集的分组可以与具有序列位集的分组交织。
The sequence number value ranges from 0 to (2**32)-1. The first datagram is sent with a sequence number of 0. The sequence number is thus a free running counter represented modulo 2**32. The receiver maintains the sequence number value of the last successfully decapsulated packet. Upon establishment of the GRE tunnel, this value should be set to (2**32)-1.
序列号值的范围为0到（2**32）-1。发送第一个数据报时，序列号为0。因此，序列号是以模2**32表示的自由运行计数器。接收器保持最后一个成功解除封装的数据包的序列号值。GRE隧道建立后，该值应设置为（2**32）-1。
When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. A packet is considered an out-of-sequence packet if the sequence number of the received packet is less than or equal to the sequence number of last successfully decapsulated packet. The sequence number of a received message is considered less than or equal to the last successfully received sequence number if its value lies in the range of the last received sequence number and the preceding 2**31-1 values, inclusive.
当解封装器接收到一个无序数据包时，它应该被悄悄地丢弃。如果接收到的数据包的序列号小于或等于最后一个成功解封数据包的序列号，则该数据包被视为无序数据包。如果接收到的消息的序列号的值在上次接收到的序列号和之前的2**31-1值（含）的范围内，则认为其序列号小于或等于上次成功接收到的序列号。
If the received packet is an in-sequence packet, it is successfully decapsulated. An in-sequence packet is one with a sequence number exactly 1 greater than (modulo 2**32) the last successfully decapsulated packet, or one in which the sequence number field is not present (S bit not set).
如果接收到的数据包是序列数据包，则成功地将其解封。序列内数据包是序列号正好大于（模2**32）最后一个成功解封数据包的数据包，或者序列号字段不存在的数据包（未设置S位）。
If the received packet is neither an in-sequence nor an out-of-sequence packet it indicates a sequence number gap. The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number. If an in-sequence packet is received and successfully decapsulated, the receiver should consult the head of this buffer to see if the next in-sequence packet has already been received. If so, the receiver should decapsulate it as well as the following in-sequence packets that may be present in the buffer. The "last successfully decapsulated sequence number" should then be set to the last packet that was decapsulated from the buffer.
如果接收到的数据包既不是顺序内的数据包，也不是顺序外的数据包，则表示序列号间隔。接收机可执行少量缓冲以尝试恢复发送分组的原始序列。在这种情况下，分组可以被放置在按序列号排序的缓冲器中。如果接收到序列中的数据包并成功解除封装，则接收器应咨询该缓冲器的头部，以查看是否已接收到下一个序列中的数据包。如果是这样，接收器应将其以及缓冲区中可能存在的以下按顺序分组解密。“最后一个成功解封的序列号”应设置为从缓冲区解封的最后一个数据包。
Under no circumstances should a packet wait more that OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been waiting that long, the receiver MUST immediately traverse the buffer in sorted order, decapsulating packets (and ignoring any sequence number gaps) until there are no more packets in the buffer that have been waiting longer than OUTOFORDER_TIMER milliseconds. The "last successfully decapsulated sequence number" should then be set to the last packet so decapsulated.
在任何情况下，数据包在缓冲区中的等待时间都不应超过无序计时器毫秒。如果数据包已经等待了那么长的时间，接收器必须立即按排序顺序遍历缓冲区，解除数据包的封装（并忽略任何序列号间隙），直到缓冲区中不再有等待时间超过无序计时器毫秒的数据包。“最后一个成功解封的序列号”应设置为最后一个如此解封的数据包。
The receiver may place a limit on the number of packets in any per-flow buffer (Packets with the same Key Field value belong to a flow). If a packet arrives that would cause the receiver to place more than MAX_PERFLOW_BUFFER packets into a given buffer, then the packet at the head of the buffer is immediately decapsulated regardless of its sequence number and the "last successfully decapsulated sequence number" is set to its sequence number. The newly arrived packet may then be placed in the buffer.
接收机可以对任何每个流缓冲器中的分组数量设置限制（具有相同密钥字段值的分组属于一个流）。如果到达的数据包会导致接收器将超过MAX_PERFLOW_的缓冲数据包放入给定的缓冲区，则缓冲区头部的数据包将立即解封，而不管其序列号如何，并且“最后成功解封的序列号”设置为其序列号。然后，可以将新到达的分组放置在缓冲器中。
Note that the sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. Use of the sequence number option should be used appropriately; in particular, it is a good idea a avoid using when tunneling protocols that have higher layer in-order delivery mechanisms or are tolerant to out-of-order delivery. If only at certain instances the protocol being carried in the GRE tunnel requires in-sequence delivery, only the corresponding packets encapsulated in a GRE header can be sent with the sequence bit set.
请注意，序列号用于检测丢失的数据包和/或恢复传输期间可能已重新排序的原始数据包序列（带缓冲）。应适当使用序列号选项；特别是，当隧道协议具有更高层次的顺序传递机制或容忍无序传递时，最好避免使用。如果只有在某些情况下，GRE隧道中承载的协议需要顺序交付，则只有封装在GRE报头中的相应数据包才能使用序列位集发送。
Reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network. A small amount of reordering buffer (MAX_PERFLOW_BUFFER) may help in improving performance when the higher layer employs stateful compression or encryption. Since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some small amount of
失序分组的重新排序可由去封装器执行，以改进网络中的性能和对重新排序的容忍度。当高层采用有状态压缩或加密时，少量的重新排序缓冲区（MAX_PERFLOW_buffer）可能有助于提高性能。由于有状态压缩或加密的状态会因数据包丢失而重置，因此它可能有助于提高性能以容忍少量的错误
packet reordering in the network by buffering.
通过缓冲在网络中重新排序数据包。
This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. When using the Sequence number field, it is possible to inject packets with an arbitrary Sequence number and launch a Denial of Service attack. In order to protect against such attacks, IP security protocols [4] MUST be used to protect the GRE header and the tunneled payload. Either ESP (Encapsulating Security Payload) [5] or AH (Authentication Header)[6] MUST be used to protect the GRE header. If ESP is used it protects the IP payload which includes the GRE header. If AH is used the entire packet other than the mutable fields are authenticated. Note that Key field is not involved in any sort or security (despite its name).
本文档描述了两个字段（键和序列号）可以选择性地在GRE（通用路由封装）头中携带的扩展[1]。使用序列号字段时，可能会注入具有任意序列号的数据包并发起拒绝服务攻击。为了防止此类攻击，必须使用IP安全协议[4]来保护GRE报头和隧道负载。必须使用ESP（封装安全有效负载）[5]或AH（身份验证头）[6]来保护GRE头。如果使用ESP，它将保护包括GRE报头的IP有效负载。如果使用AH，则对可变字段以外的整个数据包进行身份验证。请注意，密钥字段不涉及任何排序或安全性（尽管其名称）。
This document does not require any allocations by the IANA and therefore does not have any new IANA considerations.
本文件不要求IANA进行任何分配，因此没有任何新的IANA考虑事项。
This document is derived from the original ideas of the authors of RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer, Yingchun Xu, Ajoy Singh and many others provided useful discussion. The author would like to thank all the above people.
本文件来源于RFC1701作者的原始想法。梁建邦、皮特·麦肯、马克·汤斯利、大卫·迈耶、徐迎春、阿霍伊·辛格和许多其他人进行了有益的讨论。作者要感谢上述所有人。
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[1] Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, October 1994.
[2] Hanks，S.，Li，T，Farinaci，D.，和P.Trana，“通用路由封装”，RFC 17011994年10月。
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402, November 1998.
[6] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
Author's Address
作者地址
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Gopal Dommety Cisco Systems，Inc.加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: gdommety@cisco.com
EMail: gdommety@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。