Internet Engineering Task Force (IETF) L. Yong, Ed.
Request for Comments: 8086 Huawei Technologies
Category: Standards Track E. Crabbe
ISSN: 2070-1721 Oracle
X. Xu
Huawei Technologies
T. Herbert
Facebook
March 2017
Internet Engineering Task Force (IETF) L. Yong, Ed.
Request for Comments: 8086 Huawei Technologies
Category: Standards Track E. Crabbe
ISSN: 2070-1721 Oracle
X. Xu
Huawei Technologies
T. Herbert
Facebook
March 2017
GRE-in-UDP Encapsulation
UDP封装中的GRE
Abstract
摘要
This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field. This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms. There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet.
本文档指定了在GRE和UDP报头中封装网络协议数据包的方法。UDP封装中的GRE允许UDP源端口字段用作熵字段。这可用于使用现有等成本多路径（ECMP）机制的公交网络中GRE流量的负载平衡。UDP中的GRE有两种适用场景，它们具有不同的要求：（1）通用Internet和（2）流量管理控制环境。受控环境的限制性要求低于一般互联网。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8086.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8086.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Applicability Statement .........................................6
2.1. GRE-in-UDP Tunnel Requirements .............................6
2.1.1. Requirements for Default GRE-in-UDP Tunnel ..........7
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel .............8
3. GRE-in-UDP Encapsulation ........................................9
3.1. IP Header .................................................11
3.2. UDP Header ................................................11
3.2.1. Source Port ........................................11
3.2.2. Destination Port ...................................11
3.2.3. Checksum ...........................................12
3.2.4. Length .............................................12
3.3. GRE Header ................................................12
4. Encapsulation Procedures .......................................13
4.1. MTU and Fragmentation .....................................13
4.2. Differentiated Services and ECN Marking ...................14
5. Use of DTLS ....................................................14
6. UDP Checksum Handling ..........................................15
6.1. UDP Checksum with IPv4 ....................................15
6.2. UDP Checksum with IPv6 ....................................15
7. Middlebox Considerations .......................................18
7.1. Middlebox Considerations for Zero Checksums ...............19
8. Congestion Considerations ......................................19
9. Backward Compatibility .........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................27
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Requirements Language ......................................5
2. Applicability Statement .........................................6
2.1. GRE-in-UDP Tunnel Requirements .............................6
2.1.1. Requirements for Default GRE-in-UDP Tunnel ..........7
2.1.2. Requirements for TMCE GRE-in-UDP Tunnel .............8
3. GRE-in-UDP Encapsulation ........................................9
3.1. IP Header .................................................11
3.2. UDP Header ................................................11
3.2.1. Source Port ........................................11
3.2.2. Destination Port ...................................11
3.2.3. Checksum ...........................................12
3.2.4. Length .............................................12
3.3. GRE Header ................................................12
4. Encapsulation Procedures .......................................13
4.1. MTU and Fragmentation .....................................13
4.2. Differentiated Services and ECN Marking ...................14
5. Use of DTLS ....................................................14
6. UDP Checksum Handling ..........................................15
6.1. UDP Checksum with IPv4 ....................................15
6.2. UDP Checksum with IPv6 ....................................15
7. Middlebox Considerations .......................................18
7.1. Middlebox Considerations for Zero Checksums ...............19
8. Congestion Considerations ......................................19
9. Backward Compatibility .........................................20
10. IANA Considerations ...........................................21
11. Security Considerations .......................................21
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................23
Acknowledgements ..................................................25
Contributors ......................................................25
Authors' Addresses ................................................27
This document specifies a generic GRE-in-UDP encapsulation for tunneling network protocol packets across an IP network based on Generic Routing Encapsulation (GRE) [RFC2784] [RFC7676] and User Datagram Protocol (UDP) [RFC768] headers. The GRE header indicates the payload protocol type via an EtherType [RFC7042] in the protocol type field, and the source port field in the UDP header may be used to provide additional entropy.
本文档指定了基于通用路由封装（GRE）[RFC2784][RFC7676]和用户数据报协议（UDP）[RFC768]头的通用GRE in UDP封装，用于在IP网络上隧道传输网络协议数据包。GRE报头通过协议类型字段中的EtherType[RFC7042]指示有效负载协议类型，UDP报头中的源端口字段可用于提供额外的熵。
A GRE-in-UDP tunnel offers the possibility of better performance for load-balancing GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms that use a hash of the five-tuple of source IP address, destination IP address, UDP/TCP source port, UDP/TCP destination port, and protocol number. While such hashing distributes UDP and TCP [RFC793] traffic between a common pair of IP addresses across paths, it uses a single path for corresponding GRE traffic because only the two IP addresses and the Protocol or Next Header field participate in the ECMP hash. Encapsulating GRE in UDP enables use of the UDP source port to provide entropy to ECMP hashing.
UDP隧道中的GRE为使用现有等成本多路径（ECMP）机制的传输网络中的GRE流量负载平衡提供了更好的性能，该机制使用源IP地址、目标IP地址、UDP/TCP源端口、UDP/TCP目标端口和协议号五元组的散列。虽然这种散列将UDP和TCP[RFC793]流量分布在路径上的一对公共IP地址之间，但它使用一条路径来对应GRE流量，因为只有两个IP地址和协议或下一个报头字段参与ECMP散列。在UDP中封装GRE允许使用UDP源端口为ECMP哈希提供熵。
In addition, GRE-in-UDP enables extending use of GRE across networks that otherwise disallow it; for example, GRE-in-UDP may be used to bridge two islands where GRE is not supported natively across the middleboxes.
此外，UDP中的GRE允许在不允许GRE的网络中扩展GRE的使用；例如，UDP中的GRE可用于桥接两个岛，在这两个岛上，本机不支持GRE通过中间盒。
GRE-in-UDP encapsulation may be used to encapsulate already tunneled traffic, i.e., tunnel-in-tunnel traffic. In this case, GRE-in-UDP tunnels treat the endpoints of the outer tunnel as the end hosts; the presence of an inner tunnel does not change the outer tunnel's handling of network traffic.
UDP封装中的GRE可用于封装已经隧道化的流量，即隧道中的流量。在这种情况下，UDP隧道中的GRE将外部隧道的端点视为终端主机；内部隧道的存在不会改变外部隧道对网络流量的处理。
A GRE-in-UDP tunnel is capable of carrying arbitrary traffic and behaves as a UDP application on an IP network. However, a GRE-in-UDP tunnel carrying certain types of traffic does not satisfy the requirements for UDP applications on the Internet [RFC8085]. GRE-in-UDP tunnels that do not satisfy these requirements MUST NOT be deployed to carry such traffic over the Internet. For this reason, this document specifies two deployment scenarios for GRE-in-UDP tunnels with GRE-in-UDP tunnel requirements for each of them: (1) general Internet and (2) a traffic-managed controlled environment (TMCE). Compared to the general Internet scenario, the TMCE scenario has less restrictive technical requirements for the protocol but more restrictive management and operation requirements for the network.
UDP隧道中的GRE能够承载任意流量，并在IP网络上充当UDP应用程序。但是，承载某些类型流量的UDP隧道中的GRE不能满足Internet上UDP应用程序的要求[RFC8085]。UDP隧道中不满足这些要求的GRE不得部署在Internet上承载此类流量。因此，本文档指定了UDP隧道中GRE的两种部署场景，其中每个场景都有GRE-in-UDP隧道要求：（1）通用Internet和（2）流量管理控制环境（TMCE）。与一般互联网场景相比，TMCE场景对协议的技术要求较少，但对网络的管理和操作要求更严格。
To provide security for traffic carried by a GRE-in-UDP tunnel, this document also specifies Datagram Transport Layer Security (DTLS) for GRE-in-UDP tunnels, which SHOULD be used when security is a concern.
为了为UDP隧道中GRE承载的流量提供安全性，本文档还规定了UDP隧道中GRE的数据报传输层安全性（DTLS），在涉及安全性时应使用DTLS。
GRE-in-UDP encapsulation usage requires no changes to the transit IP network. ECMP hash functions in most existing IP routers may utilize and benefit from the additional entropy enabled by GRE-in-UDP tunnels without any change or upgrade to their ECMP implementation. The encapsulation mechanism is applicable to a variety of IP networks including Data Center Networks and Wide Area Networks, as well as both IPv4 and IPv6 networks.
UDP封装使用中的GRE不需要更改传输IP网络。大多数现有IP路由器中的ECMP哈希函数可以利用UDP隧道中GRE启用的附加熵，并从中受益，而无需对其ECMP实现进行任何更改或升级。封装机制适用于各种IP网络，包括数据中心网络和广域网，以及IPv4和IPv6网络。
The terms defined in [RFC768] and [RFC2784] are used in this document. Below are additional terms used in this document.
本文件中使用了[RFC768]和[RFC2784]中定义的术语。以下是本文件中使用的其他术语。
Decapsulator: a component performing packet decapsulation at tunnel egress.
解封器：在隧道出口处执行数据包解封的组件。
ECMP: Equal-Cost Multipath.
ECMP：等成本多路径。
Encapsulator: a component performing packet encapsulation at tunnel egress.
封装器：在隧道出口处执行数据包封装的组件。
Flow Entropy: The information to be derived from traffic or applications and to be used by network devices in the ECMP process [RFC6438].
流熵：从流量或应用程序中获得的信息，以及网络设备在ECMP过程中使用的信息[RFC6438]。
Default GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can apply to the general Internet.
UDP隧道中的默认GRE：可以应用于通用Internet的UDP隧道中的GRE。
TMCE: A traffic-managed controlled environment, i.e., an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion, as defined in Section 2.
TMCE：流量管理的受控环境，即IP网络，通过流量工程和/或其他方式管理（例如，通过使用流量速率限制器）以避免拥塞，如第2节所定义。
TMCE GRE-in-UDP Tunnel: A GRE-in-UDP tunnel that can only apply to a traffic-managed controlled environment that is defined in Section 2.
TMCE GRE in UDP隧道：仅适用于第2节中定义的流量管理受控环境的UDP隧道中的GRE。
Tunnel Egress: A tunnel endpoint that performs packet decapsulation.
隧道出口：执行数据包去封装的隧道端点。
Tunnel Ingress: A tunnel endpoint that performs packet encapsulation.
隧道入口：执行数据包封装的隧道端点。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
GRE-in-UDP encapsulation applies to IPv4 and IPv6 networks; in both cases, encapsulated packets are treated as UDP datagrams. Therefore, a GRE-in-UDP tunnel needs to meet the UDP usage requirements specified in [RFC8085]. These requirements depend on both the delivery network and the nature of the encapsulated traffic. For example, the GRE-in-UDP tunnel protocol does not provide any congestion control functionality beyond that of the encapsulated traffic. Therefore, a GRE-in-UDP tunnel MUST be used only with congestion-controlled traffic (e.g., IP unicast traffic) and/or within a network that is traffic managed to avoid congestion.
UDP封装中的GRE适用于IPv4和IPv6网络；在这两种情况下，封装的数据包都被视为UDP数据报。因此，UDP隧道中的GRE需要满足[RFC8085]中指定的UDP使用要求。这些要求取决于传送网络和封装流量的性质。例如，UDP隧道协议中的GRE不提供任何超出封装流量的拥塞控制功能。因此，UDP隧道中的GRE必须仅与拥塞控制流量（例如，IP单播流量）一起使用和/或在为避免拥塞而进行流量管理的网络内使用。
[RFC8085] describes two applicability scenarios for UDP applications: (1) general internet and (2) a controlled environment. The controlled environment means a single administrative domain or bilaterally agreed connection between domains. A network forming a controlled environment can be managed/operated to meet certain conditions, while the general Internet cannot be; thus, the requirements for a tunnel protocol operating under a controlled environment can be less restrictive than the requirements in the general Internet.
[RFC8085]描述了UDP应用程序的两种适用场景：（1）通用互联网和（2）受控环境。受控环境是指单个管理域或域之间双边商定的连接。形成受控环境的网络可以根据特定条件进行管理/操作，而普通互联网则不能；因此，对在受控环境下运行的隧道协议的要求比一般互联网中的要求限制更少。
For the purpose of this document, a traffic-managed controlled environment (TMCE) is defined as an IP network that is traffic-engineered and/or otherwise managed (e.g., via use of traffic rate limiters) to avoid congestion.
在本文件中，流量管理控制环境（TMCE）定义为IP网络，该网络通过流量工程和/或其他方式管理（例如，通过使用流量速率限制器）以避免拥塞。
This document specifies GRE-in-UDP tunnel usage in the general Internet and GRE-in-UDP tunnel usage in a traffic-managed controlled environment and uses "default GRE-in-UDP tunnel" and "TMCE GRE-in-UDP tunnel" terms to refer to each usage.
本文档指定了通用Internet中的GRE in UDP隧道使用情况和流量管理控制环境中的GRE in UDP隧道使用情况，并使用“UDP隧道中的默认GRE”和“UDP隧道中的TMCE GRE”术语来指代每次使用情况。
NOTE: Although this document specifies two different sets of GRE-in-UDP tunnel requirements based on tunnel usage, the tunnel implementation itself has no ability to detect how and where it is deployed. Therefore, it is the responsibility of the user or operator who deploys a GRE-in-UDP tunnel to ensure that it meets the appropriate requirements.
注意：尽管本文档根据隧道使用情况指定了UDP隧道中的两组不同GRE要求，但隧道实现本身无法检测其部署方式和位置。因此，在UDP隧道中部署GRE的用户或操作员有责任确保其满足适当的要求。
This section states the requirements for a GRE-in-UDP tunnel. Section 2.1.1 describes the requirements for a default GRE-in-UDP tunnel that is suitable for the general Internet; Section 2.1.2 describes a set of relaxed requirements for a TMCE GRE-in-UDP tunnel used in a traffic-managed controlled environment. Both Sections 2.1.1 and 2.1.2 are applicable to an IPv4 or IPv6 delivery network.
本节说明UDP隧道中GRE的要求。第2.1.1节描述了适用于通用互联网的UDP隧道中默认GRE的要求；第2.1.2节描述了在流量管理控制环境中使用的UDP隧道中TMCE GRE的一组宽松要求。第2.1.1节和第2.1.2节均适用于IPv4或IPv6交付网络。
The following is a summary of the default GRE-in-UDP tunnel requirements:
以下是UDP隧道中默认GRE要求的摘要：
1. A UDP checksum SHOULD be used when encapsulating in IPv4.
1. 在IPv4中封装时应使用UDP校验和。
2. A UDP checksum MUST be used when encapsulating in IPv6.
2. 在IPv6中封装时必须使用UDP校验和。
3. GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion controlled. As stated in [RFC8085], IP-based unicast traffic is generally assumed to be congestion controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. A default GRE-in-UDP tunnel is not appropriate for traffic that is not known to be congestion controlled (e.g., most IP multicast traffic).
3. UDP隧道中的GRE不得部署或配置为承载未受拥塞控制的流量。如[RFC8085]中所述，基于IP的单播通信通常被假定为拥塞控制，即，假定在发送方生成基于IP的通信的传输协议已经采用足以解决路径上的拥塞的机制。UDP隧道中的默认GRE不适用于未知的拥塞控制流量（例如，大多数IP多播流量）。
4. UDP source port values that are used as a source of flow entropy SHOULD be chosen from the ephemeral port range (49152-65535) [RFC8085].
4. 用作流熵源的UDP源端口值应从临时端口范围（49152-65535）[RFC8085]中选择。
5. The use of the UDP source port MUST be configurable so that a single value can be set for all traffic within the tunnel (this disables use of the UDP source port to provide flow entropy). When a single value is set, a random port taken from the ephemeral port range SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056].
5. UDP源端口的使用必须是可配置的，以便可以为隧道内的所有流量设置单个值（这将禁用使用UDP源端口来提供流熵）。设置单个值时，应选择临时端口范围内的随机端口，以最大限度地降低对路径外攻击的脆弱性[RFC6056]。
6. For IPv6 delivery networks, the flow entropy SHOULD also be placed in the flow label field for ECMP per [RFC6438].
6. 对于IPv6交付网络，流量熵也应根据[RFC6438]放置在ECMP的流量标签字段中。
7. At the tunnel ingress, any fragmentation of the incoming packet (e.g., because the tunnel has a Maximum Transmission Unit (MTU) that is smaller than the packet) SHOULD be performed before encapsulation. In addition, the tunnel ingress MUST apply the UDP checksum to all encapsulated fragments so that the tunnel egress can validate reassembly of the fragments; it MUST set the same Differentiated Services Code Point (DSCP) value as in the Differentiated Services (DS) field of the payload packet in all fragments [RFC2474]. To avoid unwanted forwarding over multiple paths, the same source UDP port value SHOULD be set in all packet fragments.
7. 在隧道入口处，应在封装之前执行传入分组的任何分段（例如，因为隧道具有小于分组的最大传输单元（MTU））。此外，隧道入口必须对所有封装的片段应用UDP校验和，以便隧道出口能够验证片段的重新组装；它必须设置与所有片段中有效负载数据包的区分服务（DS）字段中相同的区分服务代码点（DSCP）值[RFC2474]。为了避免在多条路径上进行不必要的转发，应在所有数据包片段中设置相同的源UDP端口值。
The section contains the TMCE GRE-in-UDP tunnel requirements. It lists the changed requirements, compared with a Default GRE-in-UDP tunnel, for a TMCE GRE-in-UDP tunnel, which corresponds to requirements 1-3 listed in Section 2.1.1.
本节包含UDP隧道中的TMCE GRE要求。它列出了与UDP隧道中的默认GRE相比，UDP隧道中的TMCE GRE的变更要求，与第2.1.1节中列出的要求1-3相对应。
1. A UDP checksum SHOULD be used when encapsulating in IPv4. A tunnel endpoint sending GRE-in-UDP MAY disable the UDP checksum, since GRE has been designed to work without a UDP checksum [RFC2784]. However, a checksum also offers protection from misdelivery to another port.
1. 在IPv4中封装时应使用UDP校验和。在UDP中发送GRE的隧道端点可能会禁用UDP校验和，因为GRE被设计为在没有UDP校验和的情况下工作[RFC2784]。然而，校验和还提供了防止误发到另一个端口的保护。
2. Use of the UDP checksum MUST be the default when encapsulating in IPv6. This default MAY be overridden via configuration of UDP zero-checksum mode. All usage of UDP zero-checksum mode with IPv6 is subject to the additional requirements specified in Section 6.2.
2. 在IPv6中封装时，必须默认使用UDP校验和。此默认值可以通过配置UDP零校验和模式来覆盖。IPv6中UDP零校验和模式的所有使用均应遵守第6.2节中规定的附加要求。
3. A GRE-in-UDP tunnel MAY encapsulate traffic that is not congestion controlled.
3. UDP隧道中的GRE可能封装不受拥塞控制的流量。
Requirements 4-7 listed in Section 2.1.1 also apply to a TMCE GRE-in-UDP tunnel.
第2.1.1节中列出的要求4-7也适用于UDP隧道中的TMCE GRE。
The GRE-in-UDP encapsulation format contains a UDP header [RFC768] and a GRE header [RFC2890]. The format is shown as follows (presented in bit order):
UDP封装格式的GRE包含UDP头[RFC768]和GRE头[RFC2890]。格式如下所示（按位顺序显示）：
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
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
IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Prot.=17(UDP) | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Prot.=17(UDP) | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy Value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy Value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: UDP + GRE Headers in IPv4
图1:IPv4中的UDP+GRE头
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
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
IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = entropy value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = entropy value | Dest. Port = 4754/4755 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S| Reserved0 | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | Reserved1 (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: UDP + GRE Headers in IPv6
图2:IPv6中的UDP+GRE头
The contents of the IP, UDP, and GRE headers that are relevant in this encapsulation are described below.
与此封装相关的IP、UDP和GRE头的内容如下所述。
An encapsulator MUST encode its own IP address as the source IP address and the decapsulator's IP address as the destination IP address. A sufficiently large value is needed in the IPv4 TTL field or IPv6 Hop Count field to allow delivery of the encapsulated packet to the peer of the encapsulation.
封装器必须将其自己的IP地址编码为源IP地址，将解封装器的IP地址编码为目标IP地址。IPv4 TTL字段或IPv6跃点计数字段中需要足够大的值，以允许将封装的数据包传递到封装的对等方。
GRE-in-UDP permits the UDP source port value to be used to encode an entropy value. The UDP source port contains a 16-bit entropy value that is generated by the encapsulator to identify a flow for the encapsulated packet. The port value SHOULD be within the ephemeral port range, i.e., 49152 to 65535, where the high-order two bits of the port are set to one. This provides fourteen bits of entropy for the inner flow identifier. In the case that an encapsulator is unable to derive flow entropy from the payload header or the entropy usage has to be disabled to meet operational requirements (see Section 7), to avoid reordering with a packet flow, the encapsulator SHOULD use the same UDP source port value for all packets assigned to a flow, e.g., the result of an algorithm that performs a hash of the tunnel ingress and egress IP address.
UDP中的GRE允许使用UDP源端口值对熵值进行编码。UDP源端口包含由封装器生成的16位熵值，用于标识封装数据包的流。端口值应在临时端口范围内，即49152到65535，其中端口的高阶两位设置为1。这为内部流标识符提供了14位熵。如果封装器无法从有效负载报头导出流熵，或者必须禁用熵使用以满足操作要求（参见第7节），为了避免与数据包流重新排序，封装器应为分配给流的所有数据包使用相同的UDP源端口值，例如。，对隧道入口和出口IP地址执行哈希运算的算法的结果。
The source port value for a flow set by an encapsulator MAY change over the lifetime of the encapsulated flow. For instance, an encapsulator may change the assignment for Denial-of-Service (DoS) mitigation or as a means to effect routing through the ECMP network. An encapsulator SHOULD NOT change the source port selected for a flow more than once every thirty seconds.
封装器设置的流的源端口值可能会在封装流的生存期内更改。例如，封装器可能会更改分配以缓解拒绝服务（DoS）问题，或者作为通过ECMP网络实现路由的一种手段。封装器不应每30秒多次更改为流选择的源端口。
An IPv6 GRE-in-UDP tunnel endpoint SHOULD copy a flow entropy value in the IPv6 flow label field (requirement 6). This permits network equipment to inspect this value and utilize it during forwarding, e.g., to perform ECMP [RFC6438].
UDP隧道端点中的IPv6 GRE应复制IPv6流标签字段中的流熵值（要求6）。这允许网络设备检查该值，并在转发期间使用它，例如，执行ECMP[RFC6438]。
This document places requirements on the generation of the flow entropy value [RFC8085] but does not specify the algorithm that an implementation should use to derive this value.
本文件对流量熵值[RFC8085]的生成提出了要求，但未指定实现应使用的算法来推导该值。
The destination port of the UDP header is set to either GRE-in-UDP (4754) or GRE-UDP-DTLS (4755); see Section 5.
UDP报头的目标端口设置为UDP中的GRE（4754）或GRE-UDP-DTLS（4755）；见第5节。
The UDP checksum is set and processed per [RFC768] and [RFC1122] for IPv4 and per [RFC2460] for IPv6. Requirements for checksum handling and use of zero UDP checksums are detailed in Section 6.
UDP校验和是根据[RFC768]和[RFC1122]为IPv4和[RFC2460]为IPv6设置和处理的。第6节详细介绍了校验和处理以及零UDP校验和的使用要求。
The usage of this field is in accordance with the current UDP specification in [RFC768]. This length will include the UDP header (eight bytes), GRE header, and the GRE payload (encapsulated packet).
此字段的使用符合[RFC768]中的当前UDP规范。该长度将包括UDP报头（八个字节）、GRE报头和GRE有效负载（封装的数据包）。
An encapsulator sets the protocol type (EtherType) of the packet being encapsulated in the GRE Protocol Type field.
封装器在GRE协议类型字段中设置要封装的数据包的协议类型（EtherType）。
An encapsulator MAY set the GRE Key Present, Sequence Number Present, and Checksum Present bits and associated fields in the GRE header as defined by [RFC2784] and [RFC2890]. Usage of the reserved bits, i.e., Reserved0, is specified in [RFC2784].
封装器可以在[RFC2784]和[RFC2890]定义的GRE报头中设置GRE密钥存在、序列号存在和校验和存在位以及相关字段。[RFC2784]中规定了保留位的使用，即保留位0。
The GRE checksum MAY be enabled to protect the GRE header and payload. When the UDP checksum is enabled, it protects the GRE payload, resulting in the GRE checksum being mostly redundant. Enabling both checksums may result in unnecessary processing. Since the UDP checksum covers the pseudo-header and the packet payload, including the GRE header and its payload, the UDP checksum SHOULD be used in preference to the GRE checksum.
可以启用GRE校验和以保护GRE报头和有效负载。启用UDP校验和时，它保护GRE有效负载，导致GRE校验和大部分是冗余的。启用这两个校验和可能会导致不必要的处理。由于UDP校验和覆盖伪报头和数据包有效负载，包括GRE报头及其有效负载，因此应优先使用UDP校验和而不是GRE校验和。
An implementation MAY use the GRE Key field to authenticate the encapsulator. (See the Security Considerations section.) In this model, a shared value is either configured or negotiated between an encapsulator and decapsulator. When a decapsulator determines that a presented key is not valid for the source, the packet MUST be dropped.
实现可以使用GRE密钥字段对封装器进行身份验证。（请参阅安全注意事项部分。）在此模型中，在封装器和解封装器之间配置或协商共享值。当解封装器确定提供的密钥对源无效时，必须丢弃该数据包。
Although the GRE-in-UDP encapsulation protocol uses both the UDP header and GRE header, it is one tunnel encapsulation protocol. The GRE and UDP headers MUST be applied and removed as a pair at the encapsulation and decapsulation points. This specification does not support UDP encapsulation of a GRE header where that GRE header is applied or removed at a network node other than the UDP tunnel ingress or egress.
尽管GRE in UDP封装协议同时使用UDP报头和GRE报头，但它是一种隧道封装协议。GRE和UDP报头必须在封装和去封装点成对应用和删除。本规范不支持GRE头的UDP封装，其中GRE头在UDP隧道入口或出口以外的网络节点上应用或删除。
The procedures specified in this section apply to both a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel.
本节中指定的过程适用于UDP隧道中的默认GRE和UDP隧道中的TMCE GRE。
The GRE-in-UDP encapsulation allows encapsulated packets to be forwarded through "GRE-in-UDP tunnels". The encapsulator MUST set the UDP and GRE headers according to Section 3.
UDP封装中的GRE允许通过“UDP隧道中的GRE”转发封装的数据包。封装器必须根据第3节设置UDP和GRE头。
Intermediate routers, upon receiving these UDP encapsulated packets, could load-balance these packets based on the hash of the five-tuple of UDP packets.
中间路由器在接收到这些UDP封装的数据包后，可以基于UDP数据包的五个元组的散列来对这些数据包进行负载平衡。
Upon receiving these UDP encapsulated packets, the decapsulator decapsulates them by removing the UDP and GRE headers and then processes them accordingly.
接收到这些UDP封装的数据包后，解封装器通过移除UDP和GRE头来解封装，然后相应地处理它们。
GRE-in-UDP can encapsulate traffic with unicast, IPv4 broadcast, or multicast (see requirement 3 in Section 2.1.1). However, a default GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion-controlled (see requirement 3 in Section 2.1.1). Entropy may be generated from the header of encapsulated packets at an encapsulator. The mapping mechanism between the encapsulated multicast traffic and the multicast capability in the IP network is transparent and independent of the encapsulation and is otherwise outside the scope of this document.
UDP中的GRE可以使用单播、IPv4广播或多播来封装流量（请参见第2.1.1节中的要求3）。但是，UDP隧道中的默认GRE不得部署或配置为承载非拥塞控制的流量（见第2.1.1节中的要求3）。熵可以从封装器处封装的分组的报头生成。IP网络中封装的多播通信量和多播能力之间的映射机制是透明的，独立于封装，不在本文档的范围之内。
To provide entropy for ECMP, GRE-in-UDP does not rely on GRE keep-alive. It is RECOMMENDED not to use GRE keep-alive in the GRE-in-UDP tunnel. This aligns with middlebox traversal guidelines in Section 3.5 of [RFC8085].
为了为ECMP提供熵，UDP中的GRE不依赖GRE保持活动。建议不要在UDP隧道中的GRE中使用GRE保持活动状态。这与[RFC8085]第3.5节中的中间箱遍历指南一致。
Regarding packet fragmentation, an encapsulator/decapsulator SHOULD perform fragmentation before the encapsulation. The size of fragments SHOULD be less than or equal to the Path MTU (PMTU) associated with the path between the GRE ingress and the GRE egress tunnel endpoints minus the GRE and UDP overhead, assuming the egress MTU for reassembled packets is larger than the PMTU. When applying payload fragmentation, the UDP checksum MUST be used so that the receiving endpoint can validate reassembly of the fragments; the same source UDP port SHOULD be used for all packet fragments to ensure the transit routers will forward the fragments on the same path.
关于数据包分段，封装器/解封装器应在封装之前执行分段。片段的大小应小于或等于与GRE入口和GRE出口隧道端点之间的路径相关联的路径MTU（PMTU）减去GRE和UDP开销，假设重新组装的数据包的出口MTU大于PMTU。应用有效负载碎片时，必须使用UDP校验和，以便接收端点可以验证碎片的重新组装；所有数据包碎片应使用相同的源UDP端口，以确保传输路由器将在相同路径上转发碎片。
If the operator of the transit network supporting the tunnel is able to control the payload MTU size, the MTU SHOULD be configured to avoid fragmentation, i.e., sufficient for the largest supported size of packet, including all additional bytes introduced by the tunnel overhead [RFC8085].
如果支持隧道的传输网络的运营商能够控制有效载荷MTU的大小，则MTU应配置为避免碎片，即足以支持最大的数据包大小，包括隧道开销引入的所有额外字节[RFC8085]。
To ensure that tunneled traffic receives the same treatment over the IP network as traffic that is not tunneled, prior to the encapsulation process, an encapsulator processes the tunneled IP packet headers to retrieve appropriate parameters for the encapsulating IP packet header such as Diffserv [RFC2983]. Encapsulation endpoints that support Explicit Congestion Notification (ECN) must use the method described in [RFC6040] for ECN marking propagation. The congestion control process is outside of the scope of this document.
为了确保隧道传输在IP网络上得到与未隧道传输相同的处理，在封装过程之前，封装器处理隧道传输的IP分组报头，以检索封装IP分组报头的适当参数，例如Diffserv[RFC2983]。支持显式拥塞通知（ECN）的封装端点必须使用[RFC6040]中描述的方法进行ECN标记传播。拥塞控制过程不在本文档的范围内。
Additional information on IP header processing is provided in Section 3.1.
第3.1节提供了有关IP报头处理的其他信息。
Datagram Transport Layer Security (DTLS) [RFC6347] can be used for application security and can preserve network- and transport-layer protocol information. Specifically, if DTLS is used to secure the GRE-in-UDP tunnel, the destination port of the UDP header MUST be set to the IANA-assigned value (4755) indicating GRE-in-UDP with DTLS, and that UDP port MUST NOT be used for other traffic. The UDP source port field can still be used to add entropy, e.g., for load-sharing purposes. DTLS applies to a default GRE-in-UDP tunnel and a TMCE GRE-in-UDP tunnel.
数据报传输层安全性（DTLS）[RFC6347]可用于应用程序安全，并可保留网络和传输层协议信息。具体地说，如果使用DTLS保护UDP隧道中的GRE，则UDP头的目标端口必须设置为IANA分配的值（4755），指示使用DTLS的UDP中的GRE，并且该UDP端口不得用于其他流量。UDP源端口字段仍然可以用于添加熵，例如用于负载共享目的。DTLS应用于UDP隧道中的默认GRE和UDP隧道中的TMCE GRE。
Use of DTLS is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses -- multicast traffic is not supported when DTLS is used. A GRE-in-UDP tunnel decapsulator that supports DTLS is expected to be able to establish DTLS sessions with multiple tunnel encapsulators, and likewise a GRE-in-UDP tunnel encapsulator is expected to be able to establish DTLS sessions with multiple decapsulators. Different source and/or destination IP addresses will be involved; see Section 6.2 for discussion of one situation where use of different source IP addresses is important.
DTLS的使用仅限于任何特定隧道封装器/解封装器对（由源和目标IP地址标识）的单个DTLS会话。两个IP地址都必须是单播地址——使用DTLS时不支持多播通信。支持DTLS的GRE-in-UDP隧道解封器预计能够与多个隧道封装器建立DTLS会话，同样，GRE-in-UDP隧道封装器预计能够与多个解封器建立DTLS会话。将涉及不同的源和/或目标IP地址；有关使用不同源IP地址很重要的一种情况的讨论，请参见第6.2节。
When DTLS is used for a GRE-in-UDP tunnel, if a packet is received from the tunnel and that packet is not protected by the DTLS session or part of DTLS negotiation (e.g., a DTLS handshake message [RFC6347]), the tunnel receiver MUST discard that packet and SHOULD log that discard event and information about the discarded packet.
当DTLS用于UDP隧道中的GRE时，如果从隧道接收到一个数据包，并且该数据包不受DTLS会话或DTLS协商的一部分保护（例如，DTLS握手消息[RFC6347]），则隧道接收器必须丢弃该数据包，并应记录丢弃事件和关于丢弃数据包的信息。
DTLS SHOULD be used for a GRE-in-UDP tunnel to meet security requirements of the original traffic that is delivered by a GRE-in-UDP tunnel. There are cases where no additional security is required, e.g., the traffic to be encapsulated is already encrypted or the tunnel is deployed within an operationally secured network. Use of DTLS for a GRE-in-UDP tunnel requires both tunnel endpoints to configure use of DTLS.
DTL应用于GRE in UDP隧道，以满足GRE in UDP隧道交付的原始流量的安全要求。有些情况下不需要额外的安全性，例如，要封装的流量已经加密，或者隧道部署在操作安全的网络中。在UDP隧道中为GRE使用DTL需要两个隧道端点来配置DTL的使用。
For UDP in IPv4, when a non-zero UDP checksum is used, the UDP checksum MUST be processed as specified in [RFC768] and [RFC1122] for both transmit and receive. The IPv4 header includes a checksum that protects against misdelivery of the packet due to corruption of IP addresses. The UDP checksum potentially provides protection against corruption of the UDP header, GRE header, and GRE payload. Disabling the use of checksums is a deployment consideration that should take into account the risk and effects of packet corruption.
对于IPv4中的UDP，当使用非零UDP校验和时，必须按照[RFC768]和[RFC1122]中的规定处理传输和接收的UDP校验和。IPv4报头包括一个校验和，用于防止由于IP地址损坏而导致的数据包误发。UDP校验和可以防止UDP报头、GRE报头和GRE有效负载损坏。禁用校验和的使用是一个部署考虑事项，应该考虑到数据包损坏的风险和影响。
When a decapsulator receives a packet, the UDP checksum field MUST be processed. If the UDP checksum is non-zero, the decapsulator MUST verify the checksum before accepting the packet. By default, a decapsulator SHOULD accept UDP packets with a zero checksum. A node MAY be configured to disallow zero checksums per [RFC1122]; this may be done selectively, for instance, disallowing zero checksums from certain hosts that are known to be sending over paths subject to packet corruption. If verification of a non-zero checksum fails, a decapsulator lacks the capability to verify a non-zero checksum, or a packet with a zero checksum was received and the decapsulator is configured to disallow, the packet MUST be dropped and an event MAY be logged.
当解封装器接收到数据包时，必须处理UDP校验和字段。如果UDP校验和非零，则解封装器必须在接受数据包之前验证校验和。默认情况下，解封装器应接受校验和为零的UDP数据包。节点可被配置为根据[RFC1122]不允许零校验和；这可以选择性地进行，例如，禁止来自已知通过受到数据包损坏的路径发送的某些主机的零校验和。如果非零校验和验证失败，则解封装器无法验证非零校验和，或者接收到具有零校验和的数据包且解封装器配置为不允许，则必须丢弃该数据包并记录事件。
For UDP in IPv6, the UDP checksum MUST be processed as specified in [RFC768] and [RFC2460] for both transmit and receive.
对于IPv6中的UDP，必须按照[RFC768]和[RFC2460]中的规定对传输和接收的UDP校验和进行处理。
When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption. As such, a default GRE-in-UDP tunnel MUST perform UDP checksum; a TMCE GRE-in-
在IPv6上使用UDP时，UDP校验和可用于保护IPv6和UDP报头不受损坏。因此，UDP隧道中的默认GRE必须执行UDP校验和；一个高中毕业生-
UDP tunnel MAY be configured with UDP zero-checksum mode if the traffic-managed controlled environment or a set of closely cooperating traffic-managed controlled environments (such as by network operators who have agreed to work together in order to jointly provide specific services) meet at least one of the following conditions:
如果流量管理的受控环境或一组密切合作的流量管理的受控环境（例如由同意合作以共同提供特定服务的网络运营商）至少满足以下条件之一，则UDP隧道可配置UDP零校验和模式：
a. It is known (perhaps through knowledge of equipment types and lower-layer checks) that packet corruption is exceptionally unlikely and where the operator is willing to take the risk of undetected packet corruption.
a. 已知（可能通过了解设备类型和较低层检查）数据包损坏的可能性极低，并且操作员愿意承担未检测到的数据包损坏的风险。
b. It is judged through observational measurements (perhaps of historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low and where the operator is willing to take the risk of undetected packet corruption.
b. 通过观察测量（可能是使用非零校验和的历史或当前流量）判断数据包损坏的程度相当低，并且操作员愿意承担未检测到的数据包损坏的风险。
c. Carrying applications that are tolerant of misdelivered or corrupted packets (perhaps through higher-layer checksum, validation, and retransmission or transmission redundancy) where the operator is willing to rely on the applications using the tunnel to survive any corrupt packets.
c. 承载能够容忍误发或损坏的数据包的应用程序（可能通过更高层的校验和、验证和重传或传输冗余），其中运营商愿意依赖使用隧道的应用程序生存任何损坏的数据包。
The following requirements apply to a TMCE GRE-in-UDP tunnel that uses UDP zero-checksum mode:
以下要求适用于使用UDP零校验和模式的UDP隧道中的TMCE GRE：
a. Use of the UDP checksum with IPv6 MUST be the default configuration of all GRE-in-UDP tunnels.
a. 在IPv6中使用UDP校验和必须是UDP隧道中所有GRE的默认配置。
b. The GRE-in-UDP tunnel implementation MUST comply with all requirements specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 5 of [RFC6936].
b. UDP隧道中的GRE实施必须符合[RFC6936]第4节规定的所有要求和[RFC6936]第5节规定的要求1。
c. The tunnel decapsulator SHOULD only allow the use of UDP zero-checksum mode for IPv6 on a single received UDP Destination Port, regardless of the encapsulator. The motivation for this requirement is possible corruption of the UDP Destination Port, which may cause packet delivery to the wrong UDP port. If that other UDP port requires the UDP checksum, the misdelivered packet will be discarded.
c. 隧道解封装器应仅允许在单个接收到的UDP目标端口上对IPv6使用UDP零校验和模式，而不考虑封装器。此要求的动机是UDP目标端口可能损坏，这可能导致数据包传递到错误的UDP端口。如果另一个UDP端口需要UDP校验和，则错误传递的数据包将被丢弃。
d. It is RECOMMENDED that the UDP zero-checksum mode for IPv6 is only enabled for certain selected source addresses. The tunnel decapsulator MUST check that the source and destination IPv6 addresses are valid for the GRE-in-UDP tunnel on which the packet was received if that tunnel uses UDP zero-checksum mode and discard any packet for which this check fails.
d. 建议仅对某些选定的源地址启用IPv6的UDP零校验和模式。隧道解封装器必须检查源和目标IPv6地址是否对接收数据包的UDP隧道中的GRE有效（如果该隧道使用UDP零校验和模式），并丢弃此检查失败的任何数据包。
e. The tunnel encapsulator SHOULD use different IPv6 addresses for each GRE-in-UDP tunnel that uses UDP zero-checksum mode, regardless of the decapsulator, in order to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, independent of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source IPv6 address for as few GRE-in-UDP tunnels that use UDP zero-checksum mode as is feasible.
e. 隧道封装器应为使用UDP零校验和模式的UDP隧道中的每个GRE使用不同的IPv6地址，而不考虑解封装器，以便加强解封装器对IPv6源地址的检查（即，同一IPv6源地址不应与多个IPv6目标地址一起使用，这与该目标地址是单播地址还是多播地址无关）。如果不可能，建议在使用UDP零校验和模式的UDP隧道中为尽可能少的GRE使用每个源IPv6地址。
f. When any middlebox exists on the path of a GRE-in-UDP tunnel, it is RECOMMENDED to use the default mode, i.e., use UDP checksum, to reduce the chance that the encapsulated packets will be dropped.
f. 当UDP隧道中GRE的路径上存在任何中间盒时，建议使用默认模式，即使用UDP校验和，以减少丢弃封装数据包的机会。
g. Any middlebox that allows the UDP zero-checksum mode for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of [RFC6936].
g. 允许IPv6采用UDP零校验和模式的任何中间盒必须符合[RFC6936]第5节中的要求1和8-10。
h. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP checksums from "escaping" to the general Internet; see Section 8 for examples of such measures.
h. 应采取措施防止UDP校验和为零的IPv6流量“逃逸”到通用互联网；此类措施的示例见第8节。
i. IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator. For example, the operator may monitor Ethernet-layer packet error rates.
i. 网络运营商必须主动监控UDP校验和为零的IPv6流量是否存在错误。例如，操作员可以监视以太网层分组错误率。
j. If a packet with a non-zero checksum is received, the checksum MUST be verified before accepting the packet. This is regardless of whether the tunnel encapsulator and decapsulator have been configured with UDP zero-checksum mode.
j. 如果接收到具有非零校验和的数据包，则必须在接受该数据包之前验证校验和。这与隧道封装器和解封装器是否已配置UDP零校验和模式无关。
The above requirements do not change either the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC6936].
上述要求不改变[RFC6935]修改的[RFC2460]中规定的要求或[RFC6936]中规定的要求。
The requirement to check the source IPv6 address in addition to the destination IPv6 address and the strong recommendation against reuse of source IPv6 addresses among GRE-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. A traffic-managed controlled environment that satisfies at least one of three conditions listed at the beginning of this section provides additional assurance.
除了目标IPv6地址之外，还需要检查源IPv6地址，并且强烈建议不要在UDP隧道中的GRE中重用源IPv6地址，这为IPv6报头缺少UDP校验和覆盖提供了一些缓解措施。满足本节开头列出的三个条件中至少一个条件的交通管理受控环境提供了额外的保证。
A GRE-in-UDP tunnel is suitable for transmission over lower layers in the traffic-managed controlled environments that are allowed by the exceptions stated above, and the rate of corruption of the inner IP
UDP隧道中的GRE适用于在流量管理的受控环境中的较低层上进行传输，这些环境是由上述异常和内部IP的损坏率所允许的
packet on such networks is not expected to increase by comparison to GRE traffic that is not encapsulated in UDP. For these reasons, GRE-in-UDP does not provide an additional integrity check except when GRE checksum is used when UDP zero-checksum mode is used with IPv6, and this design is in accordance with requirements 2, 3, and 5 specified in Section 5 of [RFC6936].
与未封装在UDP中的GRE通信量相比，此类网络上的数据包预计不会增加。出于这些原因，UDP中的GRE不提供额外的完整性检查，除非在IPv6中使用UDP零校验和模式时使用GRE校验和，并且此设计符合[RFC6936]第5节中规定的要求2、3和5。
Generic Router Encapsulation (GRE) does not accumulate incorrect transport-layer state as a consequence of GRE header corruption. A corrupt GRE packet may result in either packet discard or packet forwarding without accumulation of GRE state. Active monitoring of GRE-in-UDP traffic for errors is REQUIRED, as the occurrence of errors will result in some accumulation of error information outside the protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936].
通用路由器封装（GRE）不会由于GRE头损坏而累积不正确的传输层状态。损坏的GRE数据包可能导致数据包丢弃或数据包转发而不累积GRE状态。需要主动监控UDP通信中的GRE是否存在错误，因为错误的发生将导致在协议之外积累一些错误信息，用于操作和管理目的。该设计符合[RFC6936]第5节规定的要求4。
The remaining requirements specified in Section 5 of [RFC6936] are not applicable to GRE-in-UDP. Requirements 6 and 7 do not apply because GRE does not include a control feedback mechanism. Requirements 8-10 are middlebox requirements that do not apply to GRE-in-UDP tunnel endpoints. (See Section 7.1 for further middlebox discussion.)
[RFC6936]第5节规定的其余要求不适用于UDP中的GRE。要求6和7不适用，因为GRE不包括控制反馈机制。要求8-10是不适用于UDP隧道端点中GRE的中间盒要求。（有关进一步的中间箱讨论，请参见第7.1节。）
It is worth mentioning that the use of a zero UDP checksum should present the equivalent risk of undetected packet corruption when sending a similar packet using GRE-in-IPv6 without UDP [RFC7676] and without GRE checksums.
值得一提的是，当使用不带UDP[RFC7676]和不带GRE校验和的GRE-in-IPv6发送类似数据包时，使用零UDP校验和应具有同等的未检测到数据包损坏风险。
In summary, a TMCE GRE-in-UDP tunnel is allowed to use UDP zero-checksum mode for IPv6 when the conditions and requirements stated above are met. Otherwise, the UDP checksum needs to be used for IPv6 as specified in [RFC768] and [RFC2460]. Use of GRE checksum is RECOMMENDED when the UDP checksum is not used.
总之，当满足上述条件和要求时，UDP隧道中的TMCE GRE允许在IPv6中使用UDP零校验和模式。否则，需要按照[RFC768]和[RFC2460]中的规定将UDP校验和用于IPv6。当不使用UDP校验和时，建议使用GRE校验和。
Many middleboxes read or update UDP port information of the packets that they forward. Network Address Port Translator (NAPT) is the most commonly deployed Network Address Translation (NAT) device [RFC4787]. A NAPT device establishes a NAT session to translate the {private IP address, private source port number} tuple to a {public IP address, public source port number} tuple, and vice versa, for the duration of the UDP session. This provides a UDP application with the "NAT pass-through" function. NAPT allows multiple internal hosts to share a single public IP address. The port number, i.e., the UDP Source Port number, is used as the demultiplexer of the multiple
许多中间盒读取或更新它们转发的数据包的UDP端口信息。网络地址端口转换器（NAPT）是最常用的部署网络地址转换（NAT）设备[RFC4787]。NAPT设备建立NAT会话，以便在UDP会话期间将{private IP address，private source port number}元组转换为{public IP address，public source port number}元组，反之亦然。这为UDP应用程序提供了“NAT传递”功能。NAPT允许多个内部主机共享一个公共IP地址。端口号，即UDP源端口号，用作多路复用器的解复用器
internal hosts. However, the above NAPT behaviors conflict with the behavior of a GRE-in-UDP tunnel that is configured to use the UDP source port value to provide entropy.
内部主机。但是，上述NAPT行为与配置为使用UDP源端口值提供熵的UDP隧道中GRE的行为冲突。
A GRE-in-UDP tunnel is unidirectional; the tunnel traffic is not expected to be returned back to the UDP source port values used to generate entropy. However, some middleboxes (e.g., firewalls) assume that bidirectional traffic uses a common pair of UDP ports. This assumption also conflicts with the use of the UDP source port field as entropy.
UDP隧道中的GRE是单向的；隧道流量预计不会返回到用于生成熵的UDP源端口值。但是，一些中间盒（例如防火墙）假定双向通信使用一对公用的UDP端口。此假设还与使用UDP源端口字段作为熵相冲突。
Hence, use of the UDP source port for entropy may impact middleboxes' behavior. If a GRE-in-UDP tunnel is expected to be used on a path with a middlebox, the tunnel can be configured either to disable use of the UDP source port for entropy or to enable middleboxes to pass packets with UDP source port entropy.
所以，将UDP源端口用于熵可能会影响中间盒的行为。如果预期UDP隧道中的GRE将在具有中间箱的路径上使用，则可以将隧道配置为禁用UDP源端口的熵使用，或启用中间箱传递具有UDP源端口熵的数据包。
IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that updates the UDP checksum field or simply validates the checksum based on [RFC2460], such as firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums. The GRE-in-UDP encapsulation does not provide a mechanism to safely fall back to using a checksum when a path change occurs that redirects a tunnel over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. In this case, the GRE-in-UDP tunnel will be black-holed by that middlebox.
UDP校验和为零的IPv6数据报将不会通过任何更新UDP校验和字段或基于[RFC2460]验证校验和的中间盒传递，例如防火墙。更改此行为需要更新此类中间盒，以正确处理UDP校验和为零的数据报。UDP封装中的GRE没有提供一种机制，在发生路径更改时，安全地退回到使用校验和，该路径更改将隧道重定向到包含丢弃具有零UDP校验和的IPv6数据报的中间盒的路径上。在这种情况下，UDP隧道中的GRE将被该中间盒屏蔽。
As such, when any middlebox exists on the path of a GRE-in-UDP tunnel, use of the UDP checksum is RECOMMENDED to increase the probability of successful transmission of GRE-in-UDP packets. Recommended changes to allow firewalls and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936].
因此，当UDP隧道中GRE的路径上存在任何中间盒时，建议使用UDP校验和来增加UDP数据包中GRE的成功传输概率。[RFC6936]第5节介绍了允许防火墙和其他中间盒支持使用IPv6零UDP校验和的建议更改。
Section 3.1.9 of [RFC8085] discusses the congestion considerations for design and use of UDP tunnels; this is important because other flows could share the path with one or more UDP tunnels, necessitating congestion control [RFC2914] to avoid destructive interference.
[RFC8085]第3.1.9节讨论了设计和使用UDP隧道时的拥塞注意事项；这很重要，因为其他流可能与一个或多个UDP隧道共享路径，因此需要拥塞控制[RFC2914]以避免破坏性干扰。
Congestion has potential impacts both on the rest of the network containing a UDP tunnel and on the traffic flows using the UDP tunnels. These impacts depend upon what sort of traffic is carried
拥塞对包含UDP隧道的网络的其余部分以及使用UDP隧道的流量都有潜在影响。这些影响取决于所承载的交通类型
over the tunnel, as well as the path of the tunnel. The GRE-in-UDP tunnel protocol does not provide any congestion control and GRE-in-UDP packets are regular UDP packets. Therefore, a GRE-in-UDP tunnel MUST NOT be deployed to carry non-congestion-controlled traffic over the Internet [RFC8085].
隧道上方，以及隧道的路径。UDP隧道协议中的GRE不提供任何拥塞控制，UDP数据包中的GRE是常规UDP数据包。因此，UDP隧道中的GRE不能部署为通过Internet承载非拥塞控制的流量[RFC8085]。
Within a TMCE network, GRE-in-UDP tunnels are appropriate for carrying traffic that is not known to be congestion controlled. For example, a GRE-in-UDP tunnel may be used to carry Multiprotocol Label Switching (MPLS) traffic such as pseudowires or VPNs where specific bandwidth guarantees are provided to each pseudowire or VPN. In such cases, operators of TMCE networks avoid congestion by careful provisioning of their networks, rate-limiting of user data traffic, and traffic engineering according to path capacity.
在TMCE网络中，UDP隧道中的GRE适合承载未知拥塞控制的流量。例如，UDP隧道中的GRE可用于承载多协议标签交换（MPLS）流量，例如伪线或VPN，其中为每个伪线或VPN提供特定带宽保证。在这种情况下，TMCE网络的运营商通过仔细配置其网络、限制用户数据流量的速率以及根据路径容量进行流量工程来避免拥塞。
When a GRE-in-UDP tunnel carries traffic that is not known to be congestion controlled in a TMCE network, the tunnel MUST be deployed entirely within that network, and measures SHOULD be taken to prevent the GRE-in-UDP traffic from "escaping" the network to the general Internet. Examples of such measures are:
当GRE in UDP隧道承载TMCE网络中未知的拥塞控制流量时，该隧道必须完全部署在该网络中，并且应采取措施防止GRE in UDP流量“逃逸”网络到通用Internet。这些措施包括：
o physical or logical isolation of the links carrying GRE-in-UDP from the general Internet,
o UDP中承载GRE的链路与通用Internet的物理或逻辑隔离，
o deployment of packet filters that block the UDP ports assigned for GRE-in-UDP, and
o 部署数据包筛选器，阻止在UDP中为GRE分配的UDP端口，以及
o imposition of restrictions on GRE-in-UDP traffic by software tools used to set up GRE-in-UDP tunnels between specific end systems (as might be used within a single data center) or by tunnel ingress nodes for tunnels that don't terminate at end systems.
o 通过用于在特定终端系统（可能在单个数据中心内使用）之间的UDP隧道中设置GRE的软件工具，或通过不在终端系统终止的隧道的隧道入口节点，对UDP流量中的GRE施加限制。
In general, tunnel ingress routers have to be upgraded in order to support the encapsulations described in this document.
一般来说，隧道入口路由器必须升级以支持本文档中描述的封装。
No change is required at transit routers to support forwarding of the encapsulation described in this document.
传输路由器不需要更改，以支持转发本文档中描述的封装。
If a tunnel endpoint (a host or router) that is intended for use as a decapsulator does not support or enable the GRE-in-UDP encapsulation described in this document, that endpoint will not listen on the destination port assigned to the GRE-encapsulation (4754 and 4755). In these cases, the endpoint will perform normal UDP processing and respond to an encapsulator with an ICMP message indicating "port
如果打算用作解封装器的隧道端点（主机或路由器）不支持或启用本文档中描述的GRE in UDP封装，则该端点将不会侦听分配给GRE封装的目标端口（4754和4755）。在这些情况下，端点将执行正常的UDP处理，并使用指示“端口”的ICMP消息响应封装器
unreachable" according to [RFC792]. Upon receiving this ICMP message, the node MUST NOT continue to use GRE-in-UDP encapsulation toward this peer without management intervention.
根据[RFC792]，不可访问”。收到此ICMP消息后，节点在未经管理干预的情况下，不得继续对此对等方使用UDP封装中的GRE。
IANA has allocated the following UDP destination port number for the indication of GRE:
IANA已为GRE指示分配了以下UDP目标端口号：
Service Name: GRE-in-UDP
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation
Reference: RFC 8086
Port Number: 4754
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
Service Name: GRE-in-UDP
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation
Reference: RFC 8086
Port Number: 4754
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
IANA has allocated the following UDP destination port number for the indication of GRE with DTLS:
IANA已分配以下UDP目标端口号，用于指示DTLS的GRE：
Service Name: GRE-UDP-DTLS
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation with DTLS
Reference: RFC 8086
Port Number: 4755
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
Service Name: GRE-UDP-DTLS
Transport Protocol(s): UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: GRE-in-UDP Encapsulation with DTLS
Reference: RFC 8086
Port Number: 4755
Service Code: N/A
Known Unauthorized Uses: N/A
Assignment Notes: N/A
GRE-in-UDP encapsulation does not affect security for the payload protocol. The security considerations for GRE apply to GRE-in-UDP; see [RFC2784].
UDP封装中的GRE不会影响有效负载协议的安全性。GRE的安全注意事项适用于UDP中的GRE；见[RFC2784]。
To secure traffic carried by a GRE-in-UDP tunnel, DTLS SHOULD be used as specified in Section 5.
为了保护UDP隧道中GRE承载的流量，应按照第5节的规定使用DTL。
In the case that UDP source port for entropy usage is disabled, a random port taken from the ephemeral port range SHOULD be selected in order to minimize the vulnerability to off-path attacks [RFC6056]. The random port may also be periodically changed to mitigate certain DoS attacks as mentioned in Section 3.2.1.
在禁用熵使用的UDP源端口的情况下，应选择临时端口范围内的随机端口，以最大限度地减少对非路径攻击的漏洞[RFC6056]。如第3.2.1节所述，还可以定期更改随机端口以减轻某些DoS攻击。
Using one standardized value as the UDP destination port to indicate an encapsulation may increase the vulnerability to off-path attacks. To overcome this, an alternate port may be agreed upon to use between an encapsulator and decapsulator [RFC6056]. How the encapsulator endpoints communicate the value is outside the scope of this document.
使用一个标准值作为UDP目标端口来指示封装可能会增加对非路径攻击的漏洞。为了克服这一点，可以约定在封装器和去封装器之间使用备用端口[RFC6056]。封装器端点如何传递值超出了本文档的范围。
This document does not require that a decapsulator validate the IP source address of the tunneled packets (with the exception that the IPv6 source address MUST be validated when UDP zero-checksum mode is used with IPv6), but it should be understood that failure to do so presupposes that there is effective destination-based filtering (or a combination of source-based and destination-based filtering) at the boundaries.
本文档不要求解封装器验证隧道数据包的IP源地址（当IPv6使用UDP零校验和模式时，必须验证IPv6源地址除外），但应理解，如果不验证，则前提是存在有效的基于目的地的过滤（或基于源和基于目标的过滤的组合）在边界处。
Corruption of GRE headers can cause security concerns for applications that rely on the GRE Key field for traffic separation or segregation. When the GRE Key field is used for this purpose, such as an application of a Network Virtualization Using Generic Routing Encapsulation (NVGRE) [RFC7637], GRE header corruption is a concern. In such situations, at least one of the UDP and GRE checksums MUST be used for both IPv4 and IPv6 GRE-in-UDP tunnels.
GRE头的损坏可能会导致依赖GRE密钥字段进行流量分离或隔离的应用程序的安全问题。当GRE密钥字段用于此目的时，例如使用通用路由封装（NVGRE）[RFC7637]的网络虚拟化应用程序，GRE头损坏是一个问题。在这种情况下，UDP隧道中的IPv4和IPv6 GRE必须至少使用一个UDP和GRE校验和。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 2784，DOI 10.17487/RFC27842000年3月<http://www.rfc-editor.org/info/rfc2784>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>.
[RFC2890]Dommety，G.，“GRE的密钥和序列号扩展”，RFC 2890，DOI 10.17487/RFC2890，2000年9月<http://www.rfc-editor.org/info/rfc2890>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040]Briscoe，B.，“明确拥塞通知的隧道挖掘”，RFC 6040，DOI 10.17487/RFC6040，2010年11月<http://www.rfc-editor.org/info/rfc6040>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <http://www.rfc-editor.org/info/rfc6438>.
[RFC6438]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，RFC 6438，DOI 10.17487/RFC6438，2011年11月<http://www.rfc-editor.org/info/rfc6438>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, DOI 10.17487/RFC6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935]Eubanks，M.，Chimento，P.，和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，RFC 6935，DOI 10.17487/RFC6935，2013年4月<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 6936，DOI 10.17487/RFC6936，2013年4月<http://www.rfc-editor.org/info/rfc6936>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <http://www.rfc-editor.org/info/rfc8085>.
[RFC8085]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，DOI 10.17487/RFC8085，2017年3月<http://www.rfc-editor.org/info/rfc8085>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，DOI 10.17487/RFC0792，1981年9月<http://www.rfc-editor.org/info/rfc792>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，DOI 10.17487/RFC2914，2000年9月<http://www.rfc-editor.org/info/rfc2914>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 2983，DOI 10.17487/RFC2983，2000年10月<http://www.rfc-editor.org/info/rfc2983>.
[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4787]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，DOI 10.17487/RFC4787，2007年1月<http://www.rfc-editor.org/info/rfc4787>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <http://www.rfc-editor.org/info/rfc6056>.
[RFC6056]Larsen，M.和F.Gont，“运输协议端口随机化建议”，BCP 156，RFC 6056，DOI 10.17487/RFC6056，2011年1月<http://www.rfc-editor.org/info/rfc6056>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<http://www.rfc-editor.org/info/rfc7042>.
[RFC7637] Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>.
[RFC7637]Garg，P.，Ed.，和Y.Wang，Ed.，“NVGRE：使用通用路由封装的网络虚拟化”，RFC 7637，DOI 10.17487/RFC7637，2015年9月<http://www.rfc-editor.org/info/rfc7637>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, <http://www.rfc-editor.org/info/rfc7676>.
[RFC7676]Pignataro，C.，Bonica，R.，和S.Krishnan，“对通用路由封装（GRE）的IPv6支持”，RFC 7676，DOI 10.17487/RFC76762015年10月<http://www.rfc-editor.org/info/rfc7676>.
Acknowledgements
致谢
The authors would like to thank Vivek Kumar, Ron Bonica, Joe Touch, Ruediger Geib, Lars Eggert, Lloyd Wood, Bob Briscoe, Rick Casarez, Jouni Korhonen, Kathleen Moriarty, Ben Campbell, and many others for their reviews and valuable input on this document.
作者要感谢Vivek Kumar、Ron Bonica、Joe Touch、Ruediger Geib、Lars Eggert、Lloyd Wood、Bob Briscoe、Rick Casarez、Jouni Korhonen、Kathleen Moriarty、Ben Campbell和许多其他人对本文件的评论和宝贵意见。
Thanks to Donald Eastlake, Eliot Lear, Martin Stiemerling, and Spencer Dawkins for their detailed reviews and valuable suggestions during WG Last Call and the IESG process.
感谢Donald Eastlake、Eliot Lear、Martin Stiemerling和Spencer Dawkins在工作组最后一次通话和IESG过程中的详细评论和宝贵建议。
Thanks to the design team led by David Black (members: Ross Callon, Gorry Fairhurst, Xiaohu Xu, and Lucy Yong) for efficiently working out the descriptions for the congestion considerations and IPv6 UDP zero checksum.
感谢David Black领导的设计团队（成员：Ross Callon、Gorry Fairhurst、Xiaohu Xu和Lucy Yong）高效地制定了拥塞注意事项和IPv6 UDP零校验和的描述。
Thanks to David Black and Gorry Fairhurst for their great help in document content and editing.
感谢David Black和Gorry Fairhurst在文档内容和编辑方面提供的巨大帮助。
Contributors
贡献者
The following people all contributed significantly to this document and are listed in alphabetical order:
以下人员对本文件做出了重大贡献，并按字母顺序列出：
David Black EMC Corporation 176 South Street Hopkinton, MA 01748 United States of America
David Black EMC Corporation美国马萨诸塞州霍普金顿南街176号01748
Email: david.black@emc.com
Email: david.black@emc.com
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号罗斯卡隆Juniper Networks 01886
Email: rcallon@juniper.net
Email: rcallon@juniper.net
John E. Drake Juniper Networks
约翰·E·德雷克·杜松网络
Email: jdrake@juniper.net
Email: jdrake@juniper.net
Gorry Fairhurst University of Aberdeen
阿伯丁大学
Email: gorry@erg.abdn.ac.uk
Email: gorry@erg.abdn.ac.uk
Yongbing Fan China Telecom Guangzhou China
范永兵中国电信广州分公司
Email: fanyb@gsta.com
Phone: +86 20 38639121
Email: fanyb@gsta.com
Phone: +86 20 38639121
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
Email: adrian@olddog.co.uk
Email: adrian@olddog.co.uk
Vishwas Manral
维什瓦斯·曼拉尔
Email: vishwas@ionosnetworks.com
Email: vishwas@ionosnetworks.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Carlos Pignataro Cisco Systems 7200-12美国北卡罗来纳州Kit Creek Road研究三角公园27709
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Authors' Addresses
作者地址
Lucy Yong Huawei Technologies, USA
美国华为技术有限公司
Email: lucy.yong@huawei.com
Email: lucy.yong@huawei.com
Edward Crabbe Oracle
爱德华·克拉布神谕
Email: edward.crabbe@gmail.com
Email: edward.crabbe@gmail.com
Xiaohu Xu Huawei Technologies Beijing, China
徐晓虎华为技术有限公司中国北京
Email: xuxiaohu@huawei.com
Email: xuxiaohu@huawei.com
Tom Herbert Facebook 1 Hacker Way Menlo Park, CA
汤姆赫伯特脸谱网1黑客路门罗公园，加利福尼亚州
Email: tom@herbertland.com
Email: tom@herbertland.com