Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 7676 Cisco Systems
Category: Standards Track R. Bonica
ISSN: 2070-1721 Juniper Networks
S. Krishnan
Ericsson
October 2015
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 7676 Cisco Systems
Category: Standards Track R. Bonica
ISSN: 2070-1721 Juniper Networks
S. Krishnan
Ericsson
October 2015
IPv6 Support for Generic Routing Encapsulation (GRE)
IPv6支持通用路由封装（GRE）
Abstract
摘要
Generic Routing Encapsulation (GRE) can be used to carry any network-layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.
通用路由封装（GRE）可用于在任何网络层交付协议上承载任何网络层有效负载协议。目前，为IPv4指定了GRE过程，用作有效负载或传递协议。但是，没有为IPv6指定GRE过程。
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.
本文档指定了IPv6的GRE过程，用作有效负载或交付协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7676.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7676.
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 5
3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 5
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5
3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5
4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6
4.1. Next Header Considerations . . . . . . . . . . . . . . . 6
4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6
4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 5
3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 5
3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5
3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5
4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6
4.1. Next Header Considerations . . . . . . . . . . . . . . . 6
4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6
4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used to carry any network-layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4 [RFC791], used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6 [RFC2460].
通用路由封装（GRE）[RFC2784][RFC2890]可用于在任何网络层交付协议上承载任何网络层有效负载协议。目前，为IPv4[RFC791]指定了GRE过程，用作有效负载或传递协议。但是，没有为IPv6[RFC2460]指定GRE过程。
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. Like RFC 2784, this document describes how GRE has been implemented by several vendors.
本文档指定了IPv6的GRE过程，用作有效负载或交付协议。与RFC2784一样，本文档描述了几个供应商是如何实现GRE的。
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]中所述进行解释。
The following terms are used in this document:
本文件中使用了以下术语：
o GRE delivery header: An IPv4 or IPv6 header whose source address represents the GRE ingress node and whose destination address represents the GRE egress node. The GRE delivery header encapsulates a GRE header.
o GRE传递头：IPv4或IPv6头，其源地址表示GRE入口节点，目标地址表示GRE出口节点。GRE交付标头封装GRE标头。
o GRE header: The GRE protocol header. The GRE header is encapsulated in the GRE delivery header and encapsulates the GRE payload.
o GRE头：GRE协议头。GRE报头封装在GRE交付报头中，并封装GRE有效负载。
o GRE payload: A network-layer packet that is encapsulated by the GRE header.
o GRE有效载荷：由GRE报头封装的网络层数据包。
o GRE overhead: The combined size of the GRE delivery header and the GRE header, measured in octets.
o GRE开销：GRE交付头和GRE头的组合大小，以八位字节为单位。
o Path MTU (PMTU): The minimum MTU of all the links in a path between a source node and a destination node. If the source and destination node are connected through Equal-Cost Multipath (ECMP), the PMTU is equal to the minimum link MTU of all links contributing to the multipath.
o 路径MTU（PMTU）：源节点和目标节点之间路径中所有链路的最小MTU。如果源节点和目标节点通过等成本多路径（ECMP）连接，则PMTU等于导致多路径的所有链路的最小链路MTU。
o Path MTU Discovery (PMTUD): A procedure for dynamically discovering the PMTU between two nodes on the Internet. PMTUD procedures for IPv6 are defined in [RFC1981].
o 路径MTU发现（PMTUD）：在Internet上的两个节点之间动态发现PMTU的过程。[RFC1981]中定义了IPv6的PMTUD过程。
o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a GRE tunnel without fragmentation of any kind. The GMTU is equal to the PMTU associated with the path between the GRE ingress and the GRE egress, minus the GRE overhead.
o GRE MTU（GMTU）：最大传输单元，即以八位字节为单位的最大数据包大小，可在GRE隧道上传输，而不会产生任何碎片。GMTU等于与GRE入口和GRE出口之间的路径相关联的PMTU减去GRE开销。
This document does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890.
本文档不会更改GRE标题格式或RFC 2784或RFC 2890指定的任何行为。
The GRE ingress node SHOULD set the Checksum Present field in the GRE header to zero. However, implementations MAY support a configuration option that causes the GRE ingress node to set the Checksum Present field to one.
GRE入口节点应将GRE标头中的校验和存在字段设置为零。然而，实现可能支持一个配置选项，该选项使GRE入口节点将校验和当前字段设置为1。
As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum Present field to calculate the length of the GRE header. If the Checksum Present field is set to one, the GRE egress node MUST use the GRE Checksum to verify the integrity of the GRE header and payload.
根据RFC 2784第2.2节，GRE出口节点使用校验和当前字段来计算GRE报头的长度。如果校验和存在字段设置为1，则GRE出口节点必须使用GRE校验和来验证GRE报头和有效负载的完整性。
Setting the Checksum Present field to zero reduces the computational cost of GRE encapsulation and decapsulation. In many cases, the GRE Checksum is partially redundant with other checksums. For example:
将校验和当前字段设置为零可降低GRE封装和去封装的计算成本。在许多情况下，GRE校验和与其他校验和部分冗余。例如：
o If the payload protocol is IPv4, the IPv4 header is protected by both the GRE Checksum and the IPv4 Checksum.
o 如果有效负载协议是IPv4，则IPv4报头受GRE校验和和IPv4校验和的保护。
o If the payload carries TCP [RFC793], the TCP pseudo header, TCP header, and TCP payload are protected by both the GRE Checksum and TCP Checksum.
o 如果有效负载携带TCP[RFC793]，则TCP伪报头、TCP报头和TCP有效负载受GRE校验和和和TCP校验和的保护。
o If the payload carries UDP [RFC768], the UDP pseudo header, UDP header, and UDP payload are protected by both the GRE Checksum and UDP Checksum.
o 如果有效负载携带UDP[RFC768]，UDP伪报头、UDP报头和UDP有效负载受GRE校验和和UDP校验和的保护。
However, if the GRE Checksum Present field is set to zero, the GRE header is not protected by any checksum. Furthermore, depending on which of the above-mentioned conditions are true, selected portions of the GRE payload will not be protected by any checksum.
但是，如果GRE校验和当前字段设置为零，则GRE标头不受任何校验和保护。此外，根据上述条件中的哪一个为真，GRE有效载荷的选定部分将不受任何校验和的保护。
Network operators should evaluate risk factors in their networks and configure GRE ingress nodes appropriately.
网络运营商应评估其网络中的风险因素，并适当配置GRE入口节点。
The following considerations apply to GRE tunnels that carry an IPv6 payload.
以下注意事项适用于承载IPv6有效负载的GRE隧道。
The Protocol Type field in the GRE header MUST be set to Ether Type [RFC7042] 0x86DD (IPv6).
GRE标头中的协议类型字段必须设置为以太类型[RFC7042]0x86DD（IPv6）。
A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from ingress to egress, without fragmenting the payload packet. All GRE tunnels with a GMTU of 1280 octets or greater satisfy this requirement. GRE tunnels that can fragment and reassemble delivery packets also satisfy this requirement, regardless of their GMTU. However, the ability to fragment and reassemble delivery packets is not a requirement of this specification. This specification requires only that GRE ingress nodes refrain from activating GRE tunnels that do not satisfy the above-mentioned requirement.
GRE隧道必须能够将1280个八位组的IPv6数据包从入口传送到出口，而不会对有效负载数据包进行碎片化。GMTU为1280个八位字节或更大的所有GRE隧道均满足此要求。可以分割和重组交付数据包的GRE隧道也满足这一要求，不管它们的GMTU如何。然而，本规范并不要求能够对交付数据包进行分段和重新组装。本规范仅要求GRE入口节点避免激活不满足上述要求的GRE隧道。
Before activating a GRE tunnel and periodically thereafter, the GRE ingress node MUST verify the tunnel's ability to carry a 1280-octet IPv6 payload packet from ingress to egress, without fragmenting the payload. Having executed those procedures, the GRE ingress node MUST activate or deactivate the tunnel accordingly.
在激活GRE隧道之前以及之后的定期，GRE入口节点必须验证隧道是否能够在不破坏有效负载的情况下，将1280个八位组的IPv6有效负载数据包从入口传送到出口。执行这些过程后，GRE入口节点必须相应地激活或停用隧道。
Implementation details regarding the above-mentioned verification procedures are beyond the scope of this document. However, a GRE ingress node can verify tunnel capabilities by sending a 1280-octet IPv6 packet addressed to itself through the tunnel under test.
有关上述验证程序的实施细节超出了本文件的范围。然而，GRE入口节点可以通过发送一个1280个八位组的IPv6数据包，通过测试中的隧道发送给自己，从而验证隧道能力。
Many existing implementations [RFC7588] do not support the above-mentioned verification procedures. Unless deployed in environments where the GMTU is guaranteed to be greater than 1280, these implementations MUST be configured so that the GRE endpoints can fragment and reassemble the GRE delivery packet.
许多现有实现[RFC7588]不支持上述验证过程。除非部署在保证GMTU大于1280的环境中，否则必须配置这些实现，以便GRE端点可以分割和重新组装GRE交付数据包。
When the GRE ingress receives an IPv6 payload packet whose length is less than or equal to the GMTU, it can encapsulate and forward the packet without fragmentation of any kind. In this case, the GRE ingress router MUST NOT fragment the payload or delivery packets.
当GRE入口接收到长度小于或等于GMTU的IPv6有效负载数据包时，它可以封装并转发该数据包，而不会出现任何形式的碎片。在这种情况下，GRE入口路由器不得对有效负载或传送数据包进行分段。
When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is greater than or equal to 1280 octets, the GRE ingress router MUST:
当GRE入口接收到长度大于GMTU的IPv6有效负载数据包，且GMTU大于或等于1280个八位字节时，GRE入口路由器必须：
o discard the IPv6 payload packet
o 丢弃IPv6有效负载数据包
o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 payload packet source. The MTU field in the ICMPv6 PTB message is set to the GMTU.
o 向IPv6有效负载数据包源发送ICMPv6数据包太大（PTB）[RFC4443]消息。ICMPv6 PTB消息中的MTU字段设置为GMTU。
When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is less than 1280 octets, the GRE ingress router MUST:
当GRE入口接收到长度大于GMTU的IPv6有效负载数据包，且GMTU小于1280个八位字节时，GRE入口路由器必须：
o encapsulate the entire IPv6 packet in a single GRE header and IP delivery header
o 将整个IPv6数据包封装在单个GRE报头和IP传送报头中
o fragment the delivery header, so that it can be reassembled by the GRE egress
o 将交付标头分段，以便可以由GRE出口重新组装
The following considerations apply when the delivery protocol is IPv6.
当传递协议为IPv6时，以下注意事项适用。
When the GRE delivery protocol is IPv6, the GRE header MAY immediately follow the GRE delivery header. Alternatively, IPv6 extension headers MAY be inserted between the GRE delivery header and the GRE header.
当GRE传递协议为IPv6时，GRE头可以紧跟在GRE传递头之后。或者，可以在GRE传递头和GRE头之间插入IPv6扩展头。
If the GRE header immediately follows the GRE delivery header, the Next Header field in the IPv6 header of the GRE delivery packet MUST be set to 47. If extension headers are inserted between the GRE delivery header and the GRE header, the Next Header field in the last IPv6 extension header MUST be set to 47.
如果GRE头紧跟在GRE传递头之后，则GRE传递数据包的IPv6头中的下一个头字段必须设置为47。如果在GRE传递标头和GRE标头之间插入扩展标头，则最后一个IPv6扩展标头中的下一个标头字段必须设置为47。
As stated in [RFC2784], the GRE header can contain a checksum. If present, the GRE header checksum can be used to detect corruption of the GRE header and GRE payload.
如[RFC2784]所述，GRE标头可以包含校验和。如果存在，GRE报头校验和可用于检测GRE报头和GRE有效负载的损坏。
The GRE header checksum cannot be used to detect corruption of the IPv6 delivery header. Furthermore, the IPv6 delivery header does not contain a checksum of its own. Therefore, no available checksum can be used to detect corruption of the IPv6 delivery header.
GRE标头校验和不能用于检测IPv6传递标头的损坏。此外，IPv6传递标头不包含其自身的校验和。因此，没有可用的校验和可用于检测IPv6传递头的损坏。
In one failure scenario, the destination address in the IPv6 delivery header is corrupted. As a result, the IPv6 delivery packet is delivered to a node other than the intended GRE egress node. Depending upon the state and configuration of that node, it will either:
在一种故障场景中，IPv6传递标头中的目标地址已损坏。结果，IPv6递送分组被递送到预定GRE出口节点以外的节点。根据该节点的状态和配置，它将：
a. Drop the packet
a. 丢包
b. Decapsulate the payload and forward it to its intended destination
b. 解除有效负载的封装并将其转发到其预期目的地
c. Decapsulate the payload and forward it to a node other than its intended destination.
c. 解除有效负载的封装并将其转发到预期目标以外的节点。
Behaviors a) and b) are acceptable. Behavior c) is not acceptable.
行为a）和b）是可接受的。行为c）是不可接受的。
Behavior c) is possible only when the following conditions are true:
行为c）仅在以下条件为真时才可能：
1. The intended GRE egress node is a Virtual Private Network (VPN) Provider Edge (PE) router.
1. 预期的GRE出口节点是虚拟专用网络（VPN）提供商边缘（PE）路由器。
2. The node to which the GRE delivery packet is mistakenly delivered is also a VPN PE router.
2. GRE传送包被错误传送到的节点也是VPN PE路由器。
3. VPNs are attached to both of the above-mentioned nodes. At least two of these VPN's number hosts are from a non-unique (e.g., [RFC1918]) address space.
3. VPN连接到上述两个节点。这些VPN的数字主机中至少有两个来自非唯一（例如[RFC1918]）地址空间。
4. The intended GRE egress node maintains state that causes it to decapsulate the packet and forward the payload to its intended destination
4. 预期GRE出口节点保持使其解除分组封装并将有效负载转发到其预期目的地的状态
5. The node to which the GRE delivery packet is mistakenly delivered maintains state that causes it to decapsulate the packet and forward the payload to an identically numbered host in another VPN.
5. GRE传递数据包被错误传递到的节点保持使其解除数据包封装并将有效负载转发到另一个VPN中编号相同的主机的状态。
While the failure scenario described above is extremely unlikely, a single misdelivered packet can adversely impact applications running on the node to which the packet is misdelivered. Furthermore, leaking packets across VPN boundaries also constitutes a security breach. The risk associated with behavior c) could be mitigated with end-to-end authentication of the payload.
虽然上述故障场景极不可能发生，但单个错误交付的数据包可能会对数据包错误交付到的节点上运行的应用程序产生不利影响。此外，跨VPN边界泄漏数据包也构成了安全漏洞。与行为c）相关的风险可以通过有效负载的端到端认证来缓解。
Before deploying GRE over IPv6, network operators should consider the likelihood of behavior c) in their network. GRE over IPv6 MUST NOT be deployed other than where the network operator deems the risk associated with behavior c) to be acceptable.
在将GRE部署到IPv6之前，网络运营商应该考虑在其网络中行为C的可能性。除非网络运营商认为与行为（c）相关的风险可接受，否则不得通过IPv6部署GRE。
By default, the GRE ingress node cannot fragment the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE ingress node can fragment the IPv6 delivery header.
默认情况下，GRE入口节点无法对IPv6传递头进行分段。然而，实现可能支持可选配置，其中GRE入口节点可以对IPv6交付报头进行分段。
Also by default, the GRE egress node cannot reassemble the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE egress node can reassemble the IPv6 delivery header.
此外，默认情况下，GRE出口节点无法重新组装IPv6传递头。然而，实现可能支持可选配置，其中GRE出口节点可以重新组装IPv6交付报头。
The Security Considerations section of [RFC4023] identifies threats encountered when MPLS is delivered over GRE. These threats apply to any GRE payload. As stated in RFC 4023, these various threats can be mitigated through options such as authenticating and/or encrypting the delivery packet using IPsec [RFC4301]. Alternatively, when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPsec, instead of the delivery packet. Otherwise, the current specification introduces no security considerations beyond those mentioned in RFC 2784.
[RFC4023]的安全注意事项部分确定了通过GRE交付MPLS时遇到的威胁。这些威胁适用于任何GRE有效载荷。如RFC 4023中所述，可以通过使用IPsec[RFC4301]验证和/或加密传送包等选项来缓解这些各种威胁。或者，当有效负载为IPv6时，也可以通过使用IPsec（而不是传递数据包）对有效负载进行身份验证和/或加密来缓解这些威胁。否则，除了RFC2784中提到的安全注意事项外，当前规范没有引入其他安全注意事项。
More generally, security considerations for IPv6 are discussed in [RFC4942]. Operational security for IPv6 is discussed in [OPSEC-V6], and security concerns for tunnels in general are discussed in [RFC6169].
更一般地说，IPv6的安全注意事项在[RFC4942]中进行了讨论。[OPSEC-V6]中讨论了IPv6的操作安全性，而[RFC6169]中讨论了一般隧道的安全问题。
[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>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，DOI 10.17487/RFC19811996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[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>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，DOI 10.17487/RFC4023，2005年3月<http://www.rfc-editor.org/info/rfc4023>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，DOI 10.17487/RFC4443，2006年3月<http://www.rfc-editor.org/info/rfc4443>.
[OPSEC-V6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", Work in Progress, draft-ietf-opsec-v6-07, September 2015.
[OPSEC-V6]Chittimaneni，K.，Kaeo，M.，和E.Vyncke，“IPv6网络的运营安全注意事项”，正在进行的工作，草案-ietf-OPSEC-V6-07，2015年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, DOI 10.17487/RFC4942, September 2007, <http://www.rfc-editor.org/info/rfc4942>.
[RFC4942]Davies，E.，Krishnan，S.，和P.Savola，“IPv6过渡/共存安全考虑”，RFC 4942，DOI 10.17487/RFC4942，2007年9月<http://www.rfc-editor.org/info/rfc4942>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, DOI 10.17487/RFC6169, April 2011, <http://www.rfc-editor.org/info/rfc6169>.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 6169，DOI 10.17487/RFC6169，2011年4月<http://www.rfc-editor.org/info/rfc6169>.
[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>.
[RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem", RFC 7588, DOI 10.17487/RFC7588, July 2015, <http://www.rfc-editor.org/info/rfc7588>.
[RFC7588]Bonica，R.，Pignataro，C.，和J.Touch，“通用路由封装（GRE）碎片问题的广泛部署解决方案”，RFC 7588，DOI 10.17487/RFC7588，2015年7月<http://www.rfc-editor.org/info/rfc7588>.
Acknowledgements
致谢
The authors would like to thank Fred Baker, Stewart Bryant, Benoit Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins, Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko, and Lucy Yong for their thorough review and useful comments.
作者要感谢弗雷德·贝克、斯图尔特·布莱恩特、贝诺特·克莱斯、本·坎贝尔、卡洛斯·耶稣·伯纳多斯·卡诺、斯宾塞·道金斯、迪诺·法里纳奇、大卫·法默、布赖恩·哈伯曼、汤姆·赫伯特、凯瑟琳·莫里亚蒂、弗雷德·坦普林、乔·图奇、安德鲁·尤琴科和露西·杨，感谢他们的全面评论和有用的评论。
Authors' Addresses
作者地址
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, North Carolina 27709 United States
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia United States
Ron Bonica Juniper Networks 2251美国弗吉尼亚州赫恩顿市企业园大道
Email: rbonica@juniper.net
Email: rbonica@juniper.net
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com