Internet Engineering Task Force (IETF) M. Konstantynowicz, Ed.
Request for Comments: 8159 G. Heron, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Schatzmayr
Deutsche Telekom AG
W. Henderickx
Alcatel-Lucent, Inc.
May 2017
Internet Engineering Task Force (IETF) M. Konstantynowicz, Ed.
Request for Comments: 8159 G. Heron, Ed.
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Schatzmayr
Deutsche Telekom AG
W. Henderickx
Alcatel-Lucent, Inc.
May 2017
Keyed IPv6 Tunnel
密钥IPv6隧道
Abstract
摘要
This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane.
本文档描述了IPv6上以太网的隧道封装，其中包含一个强制性的64位cookie，用于连接由IPv6地址标识的第2层（L2）以太网连接电路。封装基于IP上的第2层隧道协议版本3（L2TPv3），不使用L2TPv3控制平面。
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/rfc8159.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8159.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Static 1:1 Mapping without a Control Plane . . . . . . . . . 3
3. 64-Bit Cookie . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Fragmentation and Reassembly . . . . . . . . . . . . . . . . 7
6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Static 1:1 Mapping without a Control Plane . . . . . . . . . 3
3. 64-Bit Cookie . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Fragmentation and Reassembly . . . . . . . . . . . . . . . . 7
6. OAM Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
L2TPv3, as defined in [RFC3931], provides a mechanism for tunneling Layer 2 (L2) "circuits" across a packet-oriented data network (e.g., over IP), with multiple attachment circuits multiplexed over a single pair of IP address endpoints (i.e., a tunnel) using the L2TPv3 Session ID as a circuit discriminator.
[RFC3931]中定义的L2TPv3提供了跨面向分组的数据网络（例如，通过IP）的隧道层2（L2）“电路”的机制，其中多个连接电路使用L2TPv3会话ID作为电路鉴别器在一对IP地址端点（即，隧道）上多路复用。
Implementing L2TPv3 over IPv6 [RFC2460] provides the opportunity to utilize unique IPv6 addresses to identify Ethernet attachment circuits directly, leveraging the key property that IPv6 offers -- a vast number of unique IP addresses. In this case, processing of the L2TPv3 Session ID may be bypassed upon receipt, as each tunnel has one and only one associated session. This local optimization does not hinder the ability to continue supporting the multiplexing of circuits via the Session ID on the same router for other L2TPv3 tunnels.
通过IPv6实现L2TPv3[RFC2460]提供了利用唯一IPv6地址直接识别以太网连接电路的机会，利用IPv6提供的关键属性--大量唯一IP地址。在这种情况下，L2TPv3会话ID的处理在接收时可能会被绕过，因为每个隧道都有一个且只有一个关联的会话。这种局部优化不会妨碍通过同一路由器上的会话ID继续支持其他L2TPv3隧道的电路多路复用的能力。
There are various advantages to this approach when compared to the "traditional" L2TPv3 approach of using a loopback address to terminate the tunnel and then carrying multiple sessions over the tunnel. These include better ECMP load balancing (since each tunnel has a unique source/destination IPv6 address pair) and finer-grained control when advertising tunnel endpoints using a routing protocol.
与“传统”的L2TPv3方法相比，这种方法有许多优点，即使用环回地址终止隧道，然后在隧道上承载多个会话。其中包括更好的ECMP负载平衡（因为每个隧道都有一个唯一的源/目标IPv6地址对），以及在使用路由协议公布隧道端点时进行更细粒度的控制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
The L2TPv3 control plane defined in [RFC3931] is not used for this encapsulation. The management plane is used to create and maintain matching configurations at either end of each tunnel. Local configuration by the management plane creates a one-to-one mapping between the access-side L2 attachment circuit and the IP address used in the network-side IPv6 encapsulation.
[RFC3931]中定义的L2TPv3控制平面不用于此封装。管理平面用于在每个通道的任一端创建和维护匹配配置。管理平面的本地配置在接入侧L2连接电路和网络侧IPv6封装中使用的IP地址之间创建一对一映射。
The IPv6 L2TPv3 tunnel encapsulating device uniquely identifies each Ethernet L2 attachment connection by a port ID or a combination of a port ID and VLAN ID(s) on the access side and by a local IPv6 address on the network side. The local IPv6 address also identifies the tunnel endpoint. The local IPv6 addresses identifying L2TPv3 tunnels SHOULD NOT be assigned from connected IPv6 subnets facing towards remote tunnel endpoints, since that approach would result in an IPv6 Neighbor Discovery cache entry per tunnel on the next-hop router towards the remote tunnel endpoint. It is RECOMMENDED that local IPv6 addresses identifying L2TPv3 tunnels are assigned from dedicated subnets used only for such tunnel endpoints.
IPv6 L2TPv3隧道封装设备通过接入侧的端口ID或端口ID和VLAN ID的组合以及网络侧的本地IPv6地址唯一地标识每个以太网L2连接。本地IPv6地址还标识隧道端点。标识L2TPv3隧道的本地IPv6地址不应从面向远程隧道端点的已连接IPv6子网分配，因为这种方法将导致下一跳路由器上每个隧道向远程隧道端点分配IPv6邻居发现缓存条目。建议从仅用于此类隧道端点的专用子网分配标识L2TPv3隧道的本地IPv6地址。
Certain deployment scenarios may require using a single IPv6 address (such as a unicast or anycast address assigned to a specific service instance, for example, a virtual switch) to identify a tunnel endpoint for multiple IPv6 L2TPv3 tunnels. For such cases, the tunnel decapsulating device uses the local IPv6 address to identify the service instance and the remote IPv6 address to identify the individual tunnel within that service instance.
某些部署场景可能需要使用单个IPv6地址（例如分配给特定服务实例的单播或选播地址，例如虚拟交换机）来标识多个IPv6 L2TPv3隧道的隧道端点。对于这种情况，隧道解除封装设备使用本地IPv6地址标识服务实例，使用远程IPv6地址标识该服务实例内的单个隧道。
As mentioned above, Session ID processing is not required, as each keyed IPv6 tunnel has one and only one associated session. However, for compatibility with existing [RFC3931] implementations, the packets need to be sent with the Session ID. Routers implementing L2TPv3 according to [RFC3931] can be configured with multiple L2TPv3 tunnels, with one session per tunnel, to interoperate with routers implementing the keyed IPv6 tunnel as specified by this document. Note that as Session ID processing is not enabled for keyed IPv6 tunnels, there can only be a single keyed IPv6 tunnel between two IPv6 addresses.
如上所述，不需要会话ID处理，因为每个键控IPv6隧道都有且只有一个关联会话。但是，为了与现有[RFC3931]实现兼容，需要使用会话ID发送数据包。根据[RFC3931]实现L2TPv3的路由器可以配置多个L2TPv3隧道，每个隧道一个会话，以便与实现本文档指定的密钥IPv6隧道的路由器进行互操作。请注意，由于未为密钥IPv6隧道启用会话ID处理，因此两个IPv6地址之间只能有一个密钥IPv6隧道。
In line with [RFC3931], the 64-bit cookie is used for an additional tunnel endpoint context check. This is the largest cookie size permitted in [RFC3931]. All packets MUST carry the 64-bit L2TPv3 cookie field. The cookie MUST be 64 bits long in order to provide sufficient protection against spoofing and brute-force blind insertion attacks. The cookie values SHOULD be randomly selected.
根据[RFC3931]，64位cookie用于额外的隧道端点上下文检查。这是[RFC3931]中允许的最大cookie大小。所有数据包必须携带64位L2TPv3 cookie字段。cookie的长度必须为64位，以提供足够的保护，防止欺骗和暴力盲插入攻击。cookie值应随机选择。
In the absence of the L2TPv3 control plane, the L2TPv3 encapsulating router MUST be provided with a local configuration of the 64-bit cookie for each local and remote IPv6 endpoint. Note that cookies are asymmetric, so local and remote endpoints may send different cookie values and, in fact, SHOULD do so. The value of the cookie MUST be able to be changed at any time in a manner that does not drop any legitimate tunneled packets, i.e., the receiver MUST be configurable to accept two discrete cookies for a single tunnel simultaneously. This enables the receiver to hold both the 'old' and 'new' cookie values during a change of cookie value. Cookie values SHOULD be changed periodically by the management plane.
在缺少L2TPv3控制平面的情况下，L2TPv3封装路由器必须为每个本地和远程IPv6端点提供64位cookie的本地配置。请注意，cookie是不对称的，因此本地和远程端点可能发送不同的cookie值，实际上应该这样做。cookie的值必须能够随时以不丢弃任何合法隧道数据包的方式进行更改，即，接收器必须可配置为同时接受单个隧道的两个离散cookie。这使接收方能够在更改cookie值期间同时保存“旧”和“新”cookie值。Cookie值应由管理平面定期更改。
Note that mandating a 64-bit cookie is a change from the optional variable-length cookie of [RFC3931] and that this requirement constrains interoperability with existing [RFC3931] implementations to those supporting a 64-bit cookie. The management plane MUST NOT configure a keyed IP tunnel unless both endpoints support the 64-bit cookie.
请注意，强制使用64位cookie是对[RFC3931]的可选可变长度cookie的更改，并且该要求将现有[RFC3931]实现的互操作性限制为支持64位cookie的实现。除非两个端点都支持64位cookie，否则管理平面不得配置密钥IP隧道。
The ingress router encapsulates the entire Ethernet frame, without the preamble and Frame Check Sequence (FCS) in L2TPv3 as per [RFC4719]. The L2-specific sublayer MAY be carried if Virtual Circuit Connectivity Verification (VCCV) [RFC5085] and/or frame sequencing is required, but it SHOULD NOT be carried otherwise. The L2TPv3 packet is encapsulated directly over IPv6 (i.e., no UDP header is carried).
根据[RFC4719]，入口路由器将整个以太网帧封装在L2TPv3中，没有前导码和帧检查序列（FCS）。如果需要虚拟电路连接验证（VCCV）[RFC5085]和/或帧排序，则可以携带L2特定子层，但不应携带其他子层。L2TPv3数据包直接通过IPv6进行封装（即不携带UDP报头）。
The ingress router MAY retain the FCS as per [RFC4720]. Support for retaining the FCS and for receiving packets with a retained FCS is OPTIONAL and, if present, MUST be configurable. In the absence of the L2TPv3 control plane, such configuration MUST be consistent for the two endpoints of any given tunnel, i.e., if one router is configured to retain the FCS, then the other router MUST be configured to receive packets with the retained FCS. Any router configured to retain FCS for a tunnel MUST retain FCS for all frames
入口路由器可根据[RFC4720]保留FCS。支持保留FCS和使用保留的FCS接收数据包是可选的，如果存在，必须是可配置的。在缺少L2TPv3控制平面的情况下，任何给定隧道的两个端点的此类配置必须一致，即，如果一个路由器配置为保留FCS，则另一个路由器必须配置为接收保留FCS的数据包。任何配置为在隧道中保留FCS的路由器必须在所有帧中保留FCS
sent over that tunnel. All routers implementing this specification MUST support the ability to send frames without retaining the FCS and to receive such frames.
从那条隧道送过去。实施本规范的所有路由器必须支持在不保留FCS的情况下发送帧和接收此类帧的能力。
Any service-delimiting IEEE 802.1Q [IEEE802.1Q] or IEEE 802.1ad [IEEE802.1ad] VLAN IDs -- S-tag, C-tag, or the tuple (S-tag, C-tag) -- are treated with local significance within the Ethernet L2 port and MUST NOT be forwarded over the IPv6 L2TPv3 tunnel.
界定IEEE 802.1Q[IEEE802.1Q]或IEEE 802.1ad[IEEE802.1ad]VLAN ID的任何服务——S-tag、C-tag或元组（S-tag、C-tag）——在以太网L2端口内被视为具有本地意义，不得通过IPv6 L2TPv3隧道转发。
Note that the same approach may be used to transport protocols other than Ethernet, though this is outside the scope of this specification.
请注意，相同的方法可用于传输以太网以外的协议，尽管这不在本规范的范围内。
The full encapsulation is as follows:
完整封装如下所示：
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 (320 bits) +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (0:31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (32:63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional) L2-Specific Sublayer (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Payload (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (320 bits) +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (0:31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (32:63) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Optional) L2-Specific Sublayer (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Payload (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The combined IPv6 and keyed IP tunnel header contains the following fields:
组合的IPv6和密钥IP隧道标头包含以下字段：
o IPv6 Header. Note that:
o IPv6标头。请注意：
* The traffic class may be set by the ingress router to ensure correct Per-Hop Behavior (PHB) treatment by transit routers between the ingress and egress and to correct QoS disposition at the egress router.
* 入口路由器可以设置业务类别，以确保入口和出口之间的传输路由器进行正确的每跳行为（PHB）处理，并在出口路由器处进行正确的QoS配置。
* The flow label, as defined in [RFC6437], may be set by the ingress router to indicate a flow of packets from the client, which may not be reordered by the network (if there is a requirement for finer-grained ECMP load balancing rather than per-circuit load balancing).
* [RFC6437]中定义的流标签可由入口路由器设置，以指示来自客户端的数据包流，该数据包流不可由网络重新排序（如果需要更细粒度的ECMP负载平衡，而不是每电路负载平衡）。
* The next header will be set to 0x73 to indicate that the next header is L2TPv3.
* 下一个标头将设置为0x73，以指示下一个标头是L2TPv3。
* In the "Static 1:1 Mapping" case described in Section 2, the IPv6 source address may correspond to a port or port/VLAN being transported as an L2 circuit, or it may correspond to a virtual interface terminating inside the router (e.g., if L2 circuits are being used within a multipoint VPN or if an anycast address is being terminated on a set of data-center virtual machines.)
* 在第2节中描述的“静态1:1映射”情况下，IPv6源地址可能对应于作为L2电路传输的端口或端口/VLAN，或者可能对应于在路由器内部终止的虚拟接口（例如，如果在多点VPN中使用L2电路，或者如果在一组数据中心虚拟机上终止选播地址。）
* As with the source address, the IPv6 destination address may correspond to a port or port/VLAN being transported as an L2 circuit or to a virtual interface.
* 与源地址一样，IPv6目标地址可能对应于作为L2电路传输的端口或端口/VLAN或虚拟接口。
o Session ID. In the "Static 1:1 Mapping" case described in Section 2, the IPv6 address identifies an L2TPv3 session directly; thus, at endpoints supporting one-stage resolution (IPv6 Address Only), the Session ID SHOULD be ignored upon receipt. It is RECOMMENDED that the remote endpoint is configured to set the Session ID to all ones (0xFFFFFFFF) for easy identification in case of troubleshooting. For compatibility with other tunnel termination platforms supporting only two-stage resolution (IPv6 Address + Session ID), this specification recommends supporting explicit configuration of Session ID to any value other than zero (including all ones). The Session ID of zero MUST NOT be used, as it is reserved for use by L2TP control messages as specified in [RFC3931]. Note that the Session ID is unidirectional; the sent and received Session IDs at an endpoint may be different.
o 会话ID。在第2节描述的“静态1:1映射”情况下，IPv6地址直接标识L2TPv3会话；因此，在支持单阶段解析（仅限IPv6地址）的端点上，在收到会话ID时应忽略该ID。建议将远程端点配置为将会话ID设置为all ones（0xFFFFFFFF），以便在故障排除时易于识别。为了与仅支持两级解析（IPv6地址+会话ID）的其他隧道终端平台兼容，本规范建议支持将会话ID显式配置为零以外的任何值（包括所有值）。不能使用会话ID 0，因为它是为L2TP控制消息保留的，如[RFC3931]中所述。注意，会话ID是单向的；端点处发送和接收的会话ID可能不同。
o Cookie. The 64-bit cookie, configured and described as in Section 3. All packets for a destined L2 circuit (or L2TPv3 Session) MUST match one of the cookie values configured for that circuit. Any packets that do not contain a valid cookie value MUST be discarded (see [RFC3931] for more details).
o 曲奇64位cookie，如第3节所述进行配置和描述。目标L2电路（或L2TPv3会话）的所有数据包必须与为该电路配置的cookie值之一匹配。必须丢弃任何不包含有效cookie值的数据包（有关详细信息，请参阅[RFC3931]）。
o L2-Specific Sublayer (Optional). As noted above, this will be present if VCCV and/or frame sequencing is required. If VCCV is required, then any frames with bit 0 (the "V-bit") set are VCCV messages. If frame sequencing is required, then any frames with bit 1 (the "S-bit") set have a valid frame sequence number in bits 8-31.
o L2特定子层（可选）。如上所述，如果需要VCCV和/或帧排序，则会出现这种情况。如果需要VCCV，则设置了位0（“V位”）的任何帧都是VCCV消息。如果需要帧序列，则设置了位1（“S位”）的任何帧在位8-31中都有一个有效的帧序列号。
o Payload (variable). As noted above, the preamble and any service-delimiting tags MUST be stripped before encapsulation, and the FCS MUST be stripped unless FCS retention is configured at both ingress and egress routers. Since a new FCS is added at each hop when the encapsulating IP packet is transmitted, the payload is protected against bit errors.
o 有效载荷（可变）。如上所述，在封装之前必须剥离前导和任何服务定界标签，并且必须剥离FCS，除非在入口和出口路由器上都配置了FCS保留。由于在传输封装的IP数据包时，在每个跃点添加了一个新的FCS，因此有效负载受到了比特错误的保护。
Using tunnel encapsulation of Ethernet L2 datagrams in IPv6 will reduce the effective MTU allowed for the encapsulated traffic.
在IPv6中使用以太网L2数据报的隧道封装将减少封装流量所允许的有效MTU。
The recommended solution to deal with this problem is for the network operator to increase the MTU size of all the links between the devices acting as IPv6 L2TPv3 tunnel endpoints to accommodate both the IPv6 L2TPv3 encapsulation header and the Ethernet L2 datagram without requiring fragmentation of the IPv6 packet.
处理此问题的建议解决方案是，网络运营商增加作为IPv6 L2TPv3隧道端点的设备之间所有链路的MTU大小，以适应IPv6 L2TPv3封装头和以太网L2数据报，而无需对IPv6数据包进行分段。
It is RECOMMENDED that routers implementing this specification implement IPv6 Path MTU (PMTU) discovery as defined in [RFC1981] to confirm that the path over which packets are sent has sufficient MTU to transport a maximum-length Ethernet frame plus encapsulation overhead.
建议实施本规范的路由器实施[RFC1981]中定义的IPv6路径MTU（PMTU）发现，以确认发送数据包的路径具有足够的MTU来传输最大长度的以太网帧和封装开销。
Routers implementing this specification MAY implement L2TPv3 fragmentation (as defined in Section 5 of [RFC4623]). In the absence of the L2TPv3 control plane, it is RECOMMENDED that fragmentation (if implemented) is locally configured on a per-tunnel basis. Fragmentation configuration MUST be consistent between the two ends of a tunnel.
实现本规范的路由器可实现L2TPv3分段（如[RFC4623]第5节所定义）。在缺少L2TPv3控制平面的情况下，建议在每个隧道的基础上本地配置分段（如果实施）。隧道两端的碎片配置必须一致。
It is NOT RECOMMENDED for routers implementing this specification to enable IPv6 fragmentation (as defined in Section 4.5 of [RFC2460]) for keyed IP tunnels.
不建议实施本规范的路由器为密钥IP隧道启用IPv6分段（定义见[RFC2460]第4.5节）。
Operations, Administration, and Maintenance (OAM) is an important consideration when providing circuit-oriented services such as those described in this document; it is all the more important in the absence of a dedicated tunnel control plane, as OAM becomes the only way to detect failures in the tunnel overlay.
在提供本文件所述的面向电路的服务时，操作、管理和维护（OAM）是一个重要的考虑因素；在没有专用隧道控制平面的情况下，这一点尤为重要，因为OAM成为检测隧道覆盖层故障的唯一方法。
Note that in the context of keyed IP tunnels, failures in the IPv6 underlay network can be detected using the usual methods such as through the routing protocol, including the use of single-hop
请注意，在密钥IP隧道的上下文中，可以使用常规方法（例如通过路由协议）检测IPv6底层网络中的故障，包括使用单跳
Bidirectional Forwarding Detection (BFD) [RFC5881] to rapidly detect link failures. Multihop BFD MAY also be enabled between tunnel endpoints as per [RFC5883].
双向转发检测（BFD）[RFC5881]用于快速检测链路故障。还可以根据[RFC5883]在隧道端点之间启用多跳BFD。
Since keyed IP tunnels always carry an Ethernet payload and since OAM at the tunnel layer is unable to detect failures in the Ethernet service processing at the ingress or egress router or on the Ethernet attachment circuit between the router and the Ethernet client, it is RECOMMENDED that Ethernet OAM as defined in [IEEE802.1ag] and/or [Y.1731] be enabled for keyed IP tunnels. As defined in those specifications, the following Connectivity Fault Management (CFM) and/or Ethernet Continuity Check (ETH-CC) configurations are to be used in conjunction with keyed IPv6 tunnels:
由于键控IP隧道始终携带以太网有效载荷，并且由于隧道层的OAM无法检测入口或出口路由器或路由器与以太网客户端之间的以太网连接电路上的以太网服务处理中的故障，因此建议使用[IEEE802.1ag]和/或[Y.1731]中定义的以太网OAM为密钥IP隧道启用。根据这些规范中的定义，以下连接故障管理（CFM）和/或以太网连续性检查（ETH-CC）配置将与密钥IPv6隧道一起使用：
o Connectivity verification between the tunnel endpoints across the tunnel: Use an Up Maintenance End Point (MEP) located at the tunnel endpoint for transmitting the CFM PDUs towards, and receiving them from, the direction of the tunnel.
o 穿越隧道的隧道端点之间的连接验证：使用位于隧道端点处的向上维护端点（MEP）向隧道方向传输CFM PDU，并从隧道方向接收CFM PDU。
o Connectivity verification from the tunnel endpoint across the local attachment circuit: Use a Down MEP located at the tunnel endpoint for transmitting the CFM PDUs towards, and receiving them from, the direction of the local attachment circuit.
o 通过本地连接电路从隧道端点进行连接验证：使用位于隧道端点的Down MEP向本地连接电路的方向发送CFM PDU，并从本地连接电路的方向接收CFM PDU。
o Intermediate connectivity verification: Use a Maintenance Intermediate Point (MIP) located at the tunnel endpoint to relay CFM PDUs.
o 中间连接验证：使用位于隧道端点的维护中间点（MIP）中继CFM PDU。
In addition, Pseudowire VCCV [RFC5085] MAY be used. Furthermore, BFD MAY be enabled over the VCCV channel [RFC5885].
此外，还可以使用伪导线VCCV[RFC5085]。此外，可通过VCCV通道[RFC5885]启用BFD。
Note that since there is no control plane, it is RECOMMENDED that the management plane take action when attachment circuit failure is detected, for example, by dropping the remote attachment circuit.
注意，由于没有控制平面，因此建议在检测到附件电路故障时，管理平面采取措施，例如，通过放下远程附件电路。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
Packet spoofing for any type of Virtual Private Network (VPN) tunneling protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs.
任何类型的虚拟专用网（VPN）隧道协议的数据包欺骗都是特别值得关注的问题，因为将精心构造的恶意数据包插入VPN传输网络可能会导致违反VPN流量分离，将数据泄漏到客户VPN中。由于VPN的运营商甚至很难意识到它已成为进入客户VPN或在客户VPN之间的中转点，这一事实使情况变得更加复杂。
Keyed IPv6 encapsulation provides traffic separation for its VPNs via the use of separate 128-bit IPv6 addresses to identify the endpoints. The mandatory use of the 64-bit L2TPv3 cookie provides an additional check to ensure that an arriving packet is intended for the identified tunnel.
键控IPv6封装通过使用单独的128位IPv6地址来标识端点，从而为其VPN提供流量分离。强制使用64位L2TPv3 cookie提供了一个额外的检查，以确保到达的数据包用于已识别的隧道。
In the presence of a blind packet-spoofing attack, the 64-bit L2TPv3 cookie provides security against inadvertent leaking of frames into a customer VPN, as documented in Section 8.2 of [RFC3931].
如[RFC3931]第8.2节所述，在存在盲数据包欺骗攻击的情况下，64位L2TPv3 cookie可防止帧意外泄漏到客户VPN中。
For protection against brute-force blind insertion attacks, the 64- bit cookie MUST be used with all tunnels.
为了防止暴力盲插入攻击，所有隧道都必须使用64位cookie。
Note that the cookie provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data between nodes for use in a coordinated attack.
请注意，cookie不提供任何保护，以防老练的中间人攻击者能够嗅探并关联节点之间捕获的数据，以用于协调攻击。
The L2TPv3 64-bit cookie must not be regarded as a substitute for security such as that provided by IPsec when operating over an open or untrusted network where packets may be sniffed, decoded, and correlated for use in a coordinated attack.
L2TPv3 64位cookie不得被视为安全性的替代品，例如在开放或不受信任的网络上操作时，IPsec提供的安全性，在该网络中，数据包可能被嗅探、解码和关联以用于协调攻击。
[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>.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931]Lau，J.，Ed.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 3931，DOI 10.17487/RFC3931，2005年3月<http://www.rfc-editor.org/info/rfc3931>.
[RFC4719] Aggarwal, R., Ed., Townsley, M., Ed., and M. Dos Santos, Ed., "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, DOI 10.17487/RFC4719, November 2006, <http://www.rfc-editor.org/info/rfc4719>.
[RFC4719]Aggarwal，R.，Ed.，Townsley，M.，Ed.，和M.Dos Santos，Ed.，“通过第2层隧道协议版本3（L2TPv3）传输以太网帧”，RFC 4719，DOI 10.17487/RFC4719，2006年11月<http://www.rfc-editor.org/info/rfc4719>.
[IEEE802.1ad] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", IEEE 802.1ad-2005, DOI 10.1109/IEEESTD.2006.216360.
[IEEE802.1ad]IEEE，“局域网和城域网的IEEE标准-虚拟桥接局域网，修改件4：提供商网桥”，IEEE 802.1ad-2005，DOI 10.1109/IEEESTD.2006.216360。
[IEEE802.1ag] IEEE, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management", IEEE 802.1ag-2007, DOI 10.1109/IEEESTD.2007.4431836.
[IEEE802.1ag]IEEE，“局域网和城域网的IEEE标准-虚拟桥接局域网，修改件5：连接故障管理”，IEEE 802.1ag-2007，DOI 10.1109/IEEESTD.2007.4431836。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462.
[IEEE802.1Q]IEEE，“局域网和城域网的IEEE标准-网桥和桥接网络”，IEEE 802.1Q-2014，DOI 10.1109/IEEESTD.2014.6991462。
[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>.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, DOI 10.17487/RFC4623, August 2006, <http://www.rfc-editor.org/info/rfc4623>.
[RFC4623]Malis，A.和M.Townsley，“伪线仿真边到边（PWE3）碎片化和重组”，RFC 4623，DOI 10.17487/RFC4623，2006年8月<http://www.rfc-editor.org/info/rfc4623>.
[RFC4720] Malis, A., Allan, D., and N. Del Regno, "Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention", RFC 4720, DOI 10.17487/RFC4720, November 2006, <http://www.rfc-editor.org/info/rfc4720>.
[RFC4720]Malis，A.，Allan，D.，和N.Del Regno，“伪线仿真边到边（PWE3）帧检查序列保留”，RFC 4720，DOI 10.17487/RFC4720，2006年11月<http://www.rfc-editor.org/info/rfc4720>.
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.
[RFC5085]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，DOI 10.17487/RFC5085，2007年12月<http://www.rfc-editor.org/info/rfc5085>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 5881，DOI 10.17487/RFC5881，2010年6月<http://www.rfc-editor.org/info/rfc5881>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, <http://www.rfc-editor.org/info/rfc5883>.
[RFC5883]Katz，D.和D.Ward，“多跳路径的双向转发检测（BFD）”，RFC 5883，DOI 10.17487/RFC5883，2010年6月<http://www.rfc-editor.org/info/rfc5883>.
[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>.
[RFC5885]Nadeau，T.，Ed.和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 5885，DOI 10.17487/RFC5885，2010年6月<http://www.rfc-editor.org/info/rfc5885>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，DOI 10.17487/RFC6437，2011年11月<http://www.rfc-editor.org/info/rfc6437>.
[Y.1731] ITU-T, "Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", Recommendation ITU-T G.8013/Y.1731, August 2015.
[Y.1731]ITU-T，“基于以太网的网络的操作、管理和维护（OAM）功能和机制”，建议ITU-T G.8013/Y.17312015年8月。
Acknowledgements
致谢
The authors would like to thank Carlos Pignataro, Stewart Bryant, Karsten Thomann, Qi Sun, and Ian Farrer for their insightful suggestions and review.
作者要感谢Carlos Pignataro、Stewart Bryant、Karsten Thomann、Qi Sun和Ian Farrer提出的富有洞察力的建议和评论。
Contributors
贡献者
Peter Weinberger Cisco Systems Email: peweinbe@cisco.com
Peter Weinberger Cisco Systems电子邮件：peweinbe@cisco.com
Michael Lipman Cisco Systems Email: mlipman@cisco.com
Michael Lipman Cisco Systems电子邮件：mlipman@cisco.com
Mark Townsley Cisco Systems Email: townsley@cisco.com
Mark Townsley Cisco Systems电子邮件：townsley@cisco.com
Authors' Addresses
作者地址
Maciek Konstantynowicz (editor) Cisco Systems
Maciek Konstantynowicz（编辑）思科系统
Email: maciek@cisco.com
Email: maciek@cisco.com
Giles Heron (editor) Cisco Systems
Giles Heron（编辑）思科系统
Email: giheron@cisco.com
Email: giheron@cisco.com
Rainer Schatzmayr Deutsche Telekom AG
德国电信公司
Email: rainer.schatzmayr@telekom.de
Email: rainer.schatzmayr@telekom.de
Wim Henderickx Alcatel-Lucent, Inc.
Wim亨德里克斯阿尔卡特朗讯公司。
Email: wim.henderickx@alcatel-lucent.com
Email: wim.henderickx@alcatel-lucent.com