Network Working Group M. Townsley
Request for Comments: 4817 C. Pignataro
Category: Standards Track S. Wainner
Cisco Systems
T. Seely
Sprint Nextel
J. Young
March 2007
Network Working Group M. Townsley
Request for Comments: 4817 C. Pignataro
Category: Standards Track S. Wainner
Cisco Systems
T. Seely
Sprint Nextel
J. Young
March 2007
Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
在第2层隧道协议版本3上封装MPLS
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead.
第2层隧道协议版本3（L2TPv3）定义了一个协议，用于通过IP网络隧道传输各种有效负载类型。本文档定义了如何在L2TPv3数据封装上携带MPLS标签堆栈及其有效负载。这使得传统上需要支持MPLS的核心网络的应用程序能够利用IP网络上的L2TPv3封装。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. MPLS over L2TPv3 Encoding .......................................2
3. Assigning the L2TPv3 Session ID and Cookie ......................4
4. Applicability ...................................................4
5. Congestion Considerations .......................................6
6. Security Considerations .........................................6
6.1. In the Absence of IPsec ....................................7
6.2. Context Validation .........................................7
6.3. Securing the Tunnel with IPsec .............................8
7. Acknowledgements ................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. MPLS over L2TPv3 Encoding .......................................2
3. Assigning the L2TPv3 Session ID and Cookie ......................4
4. Applicability ...................................................4
5. Congestion Considerations .......................................6
6. Security Considerations .........................................6
6.1. In the Absence of IPsec ....................................7
6.2. Context Validation .........................................7
6.3. Securing the Tunnel with IPsec .............................8
7. Acknowledgements ................................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
This document defines how to encapsulate an MPLS label stack and its payload inside the L2TPv3 tunnel payload. After defining the MPLS over L2TPv3 encapsulation procedure, other MPLS over IP encapsulation options, including IP, Generic Routing Encapsulation (GRE), and IPsec are discussed in context with MPLS over L2TPv3 in an Applicability section. This document only describes encapsulation and does not concern itself with all possible MPLS-based applications that may be enabled over L2TPv3.
本文档定义了如何将MPLS标签堆栈及其有效负载封装在L2TPv3隧道有效负载中。在定义了MPLS over L2TPv3封装过程之后，其他MPLS over IP封装选项，包括IP、通用路由封装（GRE）和IPsec，将在适用性部分中与MPLS over L2TPv3一起讨论。本文档仅描述封装，不涉及所有可能通过L2TPv3启用的基于MPLS的应用程序。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]中所述进行解释。
MPLS over L2TPv3 allows tunneling of an MPLS stack [RFC3032] and its payload over an IP network, utilizing the L2TPv3 encapsulation defined in [RFC3931]. The MPLS Label Stack and payload are carried in their entirety following IP (either IPv4 or IPv6) and L2TPv3 headers.
L2TPv3上的MPLS允许利用[RFC3931]中定义的L2TPv3封装在IP网络上对MPLS堆栈[RFC3032]及其有效负载进行隧道传输。MPLS标签堆栈和有效负载在IP（IPv4或IPv6）和L2TPv3报头之后全部携带。
+-+-+-+-+-+-+-+-+-+-+
| IP |
+-+-+-+-+-+-+-+-+-+-+
| L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+
| IP |
+-+-+-+-+-+-+-+-+-+-+
| L2TPv3 |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Label Stack |
+-+-+-+-+-+-+-+-+-+-+
| MPLS Payload |
+-+-+-+-+-+-+-+-+-+-+
Figure 2.1 MPLS Packet over L2TPv3/IP
图2.1 L2TPv3/IP上的MPLS数据包
The L2TPv3 encapsulation carrying a single MPLS label stack entry is as follows:
携带单个MPLS标签堆栈项的L2TPv3封装如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Figure 2.2 MPLS over L2TPv3 encapsulation
图2.2 L2TPv3封装上的MPLS
When encapsulating MPLS over L2TPv3, the L2TPv3 L2-Specific Sublayer MAY be present. It is generally not present; hence, it is not included in Figure 2.2. The L2TPv3 Session ID MUST be present. The Cookie MAY be present.
在L2TPv3上封装MPLS时，可能存在L2TPv3 L2特定子层。它通常不存在；因此，它不包括在图2.2中。L2TPv3会话ID必须存在。饼干可能存在。
Session ID
会话ID
The L2TPv3 Session ID is a 32-bit identifier field locally selected as a lookup key for the context of an L2TP Session. An L2TP Session contains necessary context for processing a received L2TP packet. At a minimum, such context contains whether the Cookie (see description below) is present, the value it was assigned, the presence and type of an L2TPv3 L2-Specific Sublayer, as well as what type of tunneled encapsulation follows (i.e., Frame Relay, Ethernet, MPLS, etc.)
L2TPv3会话ID是本地选择的32位标识符字段，作为L2TP会话上下文的查找键。L2TP会话包含处理接收到的L2TP数据包所需的上下文。这种上下文至少包含Cookie（见下面的描述）是否存在、分配给它的值、L2TPv3 L2特定子层的存在和类型，以及随后的隧道封装类型（即帧中继、以太网、MPLS等）
Cookie
曲奇
The L2TPv3 Cookie field contains a variable-length (maximum 64 bits), randomly assigned value. It is intended to provide an additional level of guarantee that a data packet has been directed to the proper L2TP session by the Session ID. While the Session ID may be encoded and assigned any value (perhaps optimizing for local lookup capabilities, redirection in a distributed forwarding architecture, etc.), the Cookie MUST be selected as a cryptographically random value [RFC4086], with the added restriction that it not be the same as a recently used value for a given Session ID. A well-chosen Cookie will prevent inadvertent misdirection of a stray packet containing a recently reused Session ID, a Session ID that is subject to packet corruption, and protection against some specific malicious packet insertion attacks, as described in more detail in Section 4 of this document.
L2TPv3 Cookie字段包含一个随机分配的可变长度（最大64位）。它旨在提供额外级别的保证，即通过会话ID将数据分组定向到适当的L2TP会话。虽然会话ID可以被编码并分配任何值（可能优化本地查找功能、分布式转发体系结构中的重定向等），Cookie必须选择为加密随机值[RFC4086]，并附加限制，即它与给定会话ID的最近使用的值不同。精心选择的Cookie将防止无意中误导包含最近重用的会话ID（一个易受数据包损坏的会话ID）的杂散数据包，以及针对某些特定恶意数据包插入攻击的保护，如本文档第4节所述。
Label Stack Entry
标签堆栈项
An MPLS label stack entry as defined in [RFC3032].
[RFC3032]中定义的MPLS标签堆栈项。
The optional L2-Specific Sublayer (defined in [RFC3931]) is generally not present for MPLS over L2TPv3.
L2TPv3上的MPLS通常不存在可选的L2特定子层（在[RFC3931]中定义）。
Generic IP encapsulation procedures, such as fragmentation and MTU considerations, handling of Time to Live (TTL), EXP, and Differentiated Services Code Point (DSCP) bits, etc. are the same as the "Common Procedures" for IP encapsulation of MPLS defined in Section 5 of [RFC4023] and are not reiterated here.
通用IP封装程序，如碎片和MTU注意事项、生存时间（TTL）、EXP和区分服务代码点（DSCP）位的处理等，与[RFC4023]第5节中定义的MPLS IP封装的“通用程序”相同，此处不再重复。
Much like an MPLS label, the L2TPv3 Session ID and Cookie must be selected and exchanged between participating nodes before L2TPv3 can operate. These values may be configured manually, or distributed via a signaling protocol. This document concerns itself only with the encapsulation of MPLS over L2TPv3; thus, the particular method of assigning the Session ID and Cookie (if present) is out of scope.
与MPLS标签非常相似，L2TPv3会话ID和Cookie必须在参与节点之间进行选择和交换，然后L2TPv3才能运行。这些值可以手动配置，或者通过信令协议分发。本文件仅涉及L2TPv3上MPLS的封装；因此，分配会话ID和Cookie（如果存在）的特定方法超出了范围。
The methods defined in [RFC4023], [MPLS-IPSEC], and this document all describe methods for carrying MPLS over an IP network. Cases where MPLS over L2TPv3 is comparable to other alternatives are discussed in this section.
[RFC4023]、[MPLS-IPSEC]和本文档中定义的方法都描述了通过IP网络承载MPLS的方法。本节将讨论L2TPv3上的MPLS与其他备选方案类似的情况。
It is generally simpler to have one's border routers refuse to accept an MPLS packet than to configure a router to refuse to accept certain MPLS packets carried in IP or GRE to or from certain IP sources or destinations. Thus, the use of IP or GRE to carry MPLS packets increases the likelihood that an MPLS label-spoofing attack will succeed. L2TPv3 provides an additional level of protection against packet spoofing before allowing a packet to enter a Virtual Private Network (VPN) (much like IPsec provides an additional level of protection at a Provider Edge (PE) router rather than relying on Access Control List (ACL) filters). Checking the value of the L2TPv3 Cookie is similar to any sort of ACL that inspects the contents of a packet header, except that we give ourselves the luxury of "seeding" the L2TPv3 header with a value that is very difficult to spoof.
通常，让一个人的边界路由器拒绝接受MPLS数据包比配置路由器拒绝接受IP或GRE中携带的特定MPLS数据包到或来自特定IP源或目的地要简单。因此，使用IP或GRE来承载MPLS数据包会增加MPLS标签欺骗攻击成功的可能性。L2TPv3在允许数据包进入虚拟专用网络（VPN）之前提供额外级别的数据包欺骗保护（很像IPsec在提供商边缘（PE）路由器上提供额外级别的保护，而不是依赖访问控制列表（ACL）过滤器）。检查L2TPv3 Cookie的值类似于检查数据包头内容的任何类型的ACL，不同的是我们给自己提供了一种奢侈的方式，用一个很难欺骗的值“播种”L2TPv3头。
MPLS over L2TPv3 may be advantageous compared to [RFC4023], if:
与[RFC4023]相比，L2TPv3上的MPLS可能具有优势，如果：
Two routers are already "adjacent" over an L2TPv3 tunnel established for some other reason, and wish to exchange MPLS packets over that adjacency.
两个路由器已经在基于其他原因建立的L2TPv3隧道上“相邻”，并且希望在该相邻上交换MPLS数据包。
Implementation considerations dictate the use of MPLS over L2TPv3. For example, a hardware device may be able to take advantage of the L2TPv3 encapsulation for faster or distributed processing.
实施方面的考虑决定了在L2TPv3上使用MPLS。例如，硬件设备可能能够利用L2TPv3封装来实现更快或分布式处理。
Packet spoofing and insertion, service integrity and resource protection are of concern, especially given the fact that an IP tunnel potentially exposes the router to rogue or inappropriate IP packets from unknown or untrusted sources. IP Access Control Lists (ACLs) and numbering methods may be used to protect the PE routers from rogue IP sources, but may be subject to error and cumbersome to maintain at all edge points at all times. The L2TPv3 Cookie provides a simple means of validating the source of an L2TPv3 packet before allowing processing to continue. This validation offers an additional level of protection over and above IP ACLs, and a validation that the Session ID was not corrupted in transit or suffered an internal lookup error upon receipt and processing. If the Cookie value is assigned and distributed automatically, it is less subject to operator error, and if selected in a cryptographically random nature, less subject to blind guesses than source IP addresses (in the event that a hacker can insert packets within a core network).
数据包欺骗和插入、服务完整性和资源保护令人担忧，特别是考虑到IP隧道可能使路由器暴露于来自未知或不可信来源的恶意或不适当的IP数据包。IP访问控制列表（ACL）和编号方法可用于保护PE路由器免受流氓IP源的攻击，但可能会出现错误，并且在任何时候都要在所有边缘点进行维护。L2TPv3 Cookie提供了一种在允许处理继续之前验证L2TPv3数据包源的简单方法。此验证在IP ACL之上提供了额外的保护级别，并验证会话ID在传输过程中未损坏或在接收和处理时未遇到内部查找错误。如果Cookie值是自动分配和分发的，那么它就不会受到操作员错误的影响，如果是以加密随机的方式选择的，那么与源IP地址相比，它也不会受到盲目猜测的影响（如果黑客可以在核心网络中插入数据包）。
(The first two of the above applicability statements were adopted from [RFC4023].)
（上述适用性声明中的前两项采用自[RFC4023]。）
In summary, L2TPv3 can provide a balance between the limited security against IP spoofing attacks offered by [RFC4023] vs. the greater security and associated operational and processing overhead offered
总之，L2TPv3可以在[RFC4023]提供的针对IP欺骗攻击的有限安全性与提供的更高安全性以及相关操作和处理开销之间取得平衡
by [MPLS-IPSEC]. Further, MPLS over L2TPv3 may be faster in some hardware, particularly if that hardware is already optimized to classify incoming L2TPv3 packets carrying IP framed in a variety of ways. For example, IP encapsulated by High-Level Data Link Control (HDLC) or Frame Relay over L2TPv3 may be equivalent in complexity to IP encapsulated by MPLS over L2TPv3.
通过[MPLS-IPSEC]。此外，在某些硬件中，L2TPv3上的MPLS可能更快，特别是如果该硬件已经优化，以分类以各种方式承载IP帧的传入L2TPv3分组。例如，通过L2TPv3上的高级数据链路控制（HDLC）或帧中继封装的IP在复杂性上可能与通过L2TPv3上的MPLS封装的IP等效。
This document specifies an encapsulation method for MPLS inside the L2TPv3 tunnel payload. MPLS can carry a number of different protocols as payloads. When an MPLS/L2TPv3 flow carries IP-based traffic, the aggregate traffic is assumed to be TCP friendly due to the congestion control mechanisms used by the payload traffic. Packet loss will trigger the necessary reduction in offered load, and no additional congestion avoidance action is necessary.
本文档指定了L2TPv3隧道负载内MPLS的封装方法。MPLS可以携带许多不同的协议作为有效负载。当MPLS/L2TPv3流承载基于IP的流量时，由于有效负载流量使用的拥塞控制机制，聚合流量被认为是TCP友好的。数据包丢失将触发所提供负载的必要减少，并且不需要额外的拥塞避免操作。
When an MPLS/L2TPv3 flow carries payload traffic that is not known to be TCP friendly and the flow runs across an unprovisioned path that could potentially become congested, the application that uses the encapsulation specified in this document MUST employ additional mechanisms to ensure that the offered load is reduced appropriately during periods of congestion. The MPLS/L2TPv3 flow should not exceed the average bandwidth that a TCP flow across the same network path and experiencing the same network conditions would achieve, measured on a reasonable timescale. This is not necessary in the case of an unprovisioned path through an over-provisioned network, where the potential for congestion is avoided through the over-provisioning of the network.
当MPLS/L2TPv3流承载未知TCP友好的有效负载流量，并且该流运行在可能出现拥塞的未预见路径上时，使用本文档中指定的封装的应用程序必须采用其他机制，以确保在拥塞期间适当减少提供的负载。MPLS/L2TPv3流不应超过TCP流通过相同网络路径并经历相同网络条件所能达到的平均带宽（在合理的时间尺度上测量）。在通过过度配置网络的未配置路径的情况下，这是不必要的，通过过度配置网络可以避免拥塞的可能性。
The comparison to TCP cannot be specified exactly but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the roundtrip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application using the encapsulation specified in this document on the best-effort Internet, which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. One method of determining an acceptable bandwidth is described in [RFC3448]. Other methods exist, but are outside the scope of this document.
无法准确指定与TCP的比较，但其目的是在时间尺度和吞吐量方面进行“数量级”比较。测量TCP吞吐量的时间尺度是连接的往返时间。本质上，该要求表明，在尽力而为的Internet上使用本文档中指定的封装部署应用程序是不可接受的，该Internet任意消耗带宽，并且在一个数量级内无法与TCP公平竞争。[RFC3448]中描述了一种确定可接受带宽的方法。存在其他方法，但不在本文档范围内。
There are three main concerns when transporting MPLS-labeled traffic between PEs using IP tunnels. The first is the possibility that a third party may insert packets into a packet stream between two PEs. The second is that a third party might view the packet stream between two PEs. The third is that a third party may alter packets in a
在使用IP隧道在PE之间传输MPLS标记的流量时，有三个主要问题。第一种是第三方可能会将数据包插入两个PE之间的数据包流中。第二，第三方可能会查看两个PE之间的数据包流。第三种是第三方可以更改网络中的数据包
stream between two PEs. The security requirements of the applications whose traffic is being sent through the tunnel characterizes how significant these issues are. Operators may use multiple methods to mitigate the risk, including access lists, authentication, encryption, and context validation. Operators should consider the cost to mitigate the risk.
两个PEs之间的流。通过隧道发送流量的应用程序的安全性要求说明了这些问题的重要性。运营商可以使用多种方法来降低风险，包括访问列表、身份验证、加密和上下文验证。运营商应考虑降低风险的成本。
Security is also discussed as part of the applicability discussion in Section 4 of this document.
安全性也是本文件第4节适用性讨论的一部分。
If the tunnels are not secured with IPsec, then some other method should be used to ensure that packets are decapsulated and processed by the tunnel tail only if those packets were encapsulated by the tunnel head. If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside.
如果隧道未使用IPsec进行保护，则应使用某些其他方法确保仅当隧道头封装了数据包时，数据包才由隧道尾进行解封和处理。如果隧道完全位于单个管理域内，则可以使用边界处的地址过滤来确保具有隧道端点的IP源地址或隧道端点的IP目标地址的数据包不能从外部进入域。
However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet.
然而，当隧道头和隧道尾不在同一管理域中时，这可能变得困难，并且如果包必须穿越公共因特网，则基于目的地地址的过滤甚至可能变得不可能。
Sometimes, only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of MPLS over L2TPv3 validates the IP source address of the packet.
有时，在管理域的边界上只进行源地址筛选（而不进行目标地址筛选）。如果是这种情况，则过滤根本无法提供有效的保护，除非L2TPv3上的MPLS解封装器验证数据包的IP源地址。
Additionally, the "Data Packet Spoofing" considerations in Section 8.2 of [RFC3931] and the "Context Validation" considerations in Section 6.2 of this document apply. Those two sections highlight the benefits of the L2TPv3 Cookie.
此外，[RFC3931]第8.2节中的“数据包欺骗”注意事项和本文件第6.2节中的“上下文验证”注意事项也适用。这两部分重点介绍L2TPv3 Cookie的好处。
The L2TPv3 Cookie does not provide protection via encryption. However, when used with a sufficiently random, 64-bit value that is kept secret from an off-path attacker, the L2TPv3 Cookie may be used as a simple yet effective packet source authentication check which is quite resistant to brute force packet-spoofing attacks. It also alleviates the need to rely solely on filter lists based on a list of valid source IP addresses, and thwarts attacks that could benefit by spoofing a permitted source IP address. The L2TPv3 Cookie provides a means of validating the currently assigned Session ID on the packet
L2TPv3 Cookie不通过加密提供保护。然而，当与对非路径攻击者保密的足够随机的64位值一起使用时，L2TPv3 Cookie可被用作简单但有效的数据包源身份验证检查，该检查相当抵抗暴力数据包欺骗攻击。它还减轻了仅依赖基于有效源IP地址列表的筛选器列表的需要，并阻止了可能通过欺骗允许的源IP地址而受益的攻击。L2TPv3 Cookie提供了一种验证数据包上当前分配的会话ID的方法
flow, providing context protection, and may be deemed complimentary to securing the tunnel utilizing IPsec. In the absence of cryptographic security on the data plane (such as that provided by IPsec), the L2TPv3 Cookie provides a simple method of validating the Session ID lookup performed on each L2TPv3 packet. If the Cookie is sufficiently random and remains unknown to an attacker (that is, the attacker has no way to predict Cookie values or monitor traffic between PEs), then the Cookie provides an additional measure of protection against malicious spoofed packets inserted at the PE over and above that of typical IP address and port ACLs.
流，提供上下文保护，并可被视为对利用IPsec保护隧道的补充。在数据平面上没有加密安全性（如IPsec提供的加密安全性）的情况下，L2TPv3 Cookie提供了一种简单的方法来验证在每个L2TPv3数据包上执行的会话ID查找。如果Cookie具有足够的随机性，并且攻击者仍然未知（即，攻击者无法预测Cookie值或监视PE之间的通信量），则Cookie提供了额外的保护措施，以防止插入PE的恶意伪造数据包超过典型IP地址和端口ACL。
L2TPv3 tunnels may also be secured using IPsec, as specified in Section 4.1.3 of [RFC3931]. IPSec may provide authentication, privacy protection, integrity checking, and replay protection. These functions may be deemed necessary by the operator. When using IPsec, the tunnel head and the tunnel tail should be treated as the endpoints of a Security Association. A single IP address of the tunnel head is used as the source IP address, and a single IP address of the tunnel tail is used as the destination IP address. The means by which each node knows the proper address of the other is outside the scope of this document. However, if a control protocol is used to set up the tunnels, such control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's Message Digest 5 (MD5)-based authentication mechanism can serve this purpose.
L2TPv3隧道也可以使用IPsec进行保护，如[RFC3931]第4.1.3节所述。IPSec可以提供身份验证、隐私保护、完整性检查和重播保护。操作员可能认为这些功能是必要的。使用IPsec时，应将隧道头和隧道尾视为安全关联的端点。隧道头的单个IP地址用作源IP地址，隧道尾的单个IP地址用作目标IP地址。每个节点知道另一个节点正确地址的方法不在本文档的范围内。但是，如果使用控制协议来设置隧道，则此类控制协议必须具有身份验证机制，并且在设置隧道时必须使用该机制。例如，如果隧道是根据BGP分发的信息自动设置的，那么使用BGP的基于消息摘要5（MD5）的身份验证机制可以达到这一目的。
The MPLS over L2TPv3 encapsulated packets should be considered as originating at the tunnel head and being destined for the tunnel tail; IPsec transport mode SHOULD thus be used.
L2TPv3封装包上的MPLS应被视为源于隧道头，目的地为隧道尾；因此，应使用IPsec传输模式。
Note that the tunnel tail and the tunnel head are Label Switched Path (LSP) adjacencies (for label distribution adjacencies, see [RFC3031]), which means that the topmost label of any packet sent through the tunnel must be one that was distributed by the tunnel tail to the tunnel head. The tunnel tail MUST know precisely which labels it has distributed to the tunnel heads of IPsec-secured tunnels. Labels in this set MUST NOT be distributed by the tunnel tail to any LSP adjacencies other than those that are tunnel heads of IPsec-secured tunnels. If an MPLS packet is received without an IPsec encapsulation, and if its topmost label is in this set, then the packet MUST be discarded.
请注意，隧道尾部和隧道头部是标签交换路径（LSP）邻接（有关标签分发邻接，请参阅[RFC3031]），这意味着通过隧道发送的任何数据包的最顶端标签必须是由隧道尾部分发给隧道头部的标签。隧道尾部必须准确地知道它已将哪些标签分发给IPsec安全隧道的隧道头部。此集合中的标签不得由隧道尾部分发到任何LSP邻接，IPsec安全隧道的隧道头除外。如果接收到的MPLS数据包没有IPsec封装，并且其最上面的标签在此集合中，则必须丢弃该数据包。
Securing L2TPv3 using IPsec MUST provide authentication and integrity. (Note that the authentication and integrity provided will apply to the entire MPLS packet, including the MPLS label stack.)
使用IPsec保护L2TPv3必须提供身份验证和完整性。（请注意，提供的身份验证和完整性将应用于整个MPLS数据包，包括MPLS标签堆栈。）
Consequently, the implementation MUST support Encapsulating Security Payload (ESP) with null encryption. ESP with encryption MAY be supported if a source requires confidentiality. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given Security Association (SA) is the one expected.
因此，实现必须支持使用空加密封装安全有效负载（ESP）。如果源需要保密，则可能支持带加密的ESP。如果使用ESP，则隧道尾部必须检查给定安全关联（SA）上接收的任何数据包的源IP地址是否为预期的IP地址。
Key distribution may be done either manually or automatically by means of the Internet Key Exchange (IKE) Protocol [RFC2409] or IKEv2 [RFC4306]. Manual keying MUST be supported. If automatic keying is implemented, IKE in main mode with preshared keys MUST be supported. A particular application may escalate this requirement and request implementation of automatic keying. Manual key distribution is much simpler, but also less scalable, than automatic key distribution. If replay protection is regarded as necessary for a particular tunnel, automatic key distribution should be configured.
密钥分发可以通过互联网密钥交换（IKE）协议[RFC2409]或IKEv2[RFC4306]手动或自动完成。必须支持手动键控。如果实现了自动键控，则必须支持主模式下带有预共享键的IKE。特定应用程序可能会升级此要求，并请求实现自动键控。手动密钥分发比自动密钥分发简单得多，但可扩展性也较差。如果认为特定隧道需要重播保护，则应配置自动密钥分发。
Thanks to Robert Raszuk, Clarence Filsfils, and Eric Rosen for their review of this document. Some text was adopted from [RFC4023].
感谢Robert Raszuk、Clarence Filsfils和Eric Rosen对本文件的审阅。部分文本取自[RFC4023]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[MPLS-IPSEC] Rosen, E., De Clercq, J., Paridaens, O., T'Joens, Y., and C. Sargor, "Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs", Work in Progress, August 2005.
[MPLS-IPSEC]Rosen，E.，De Clercq，J.，Paridaens，O.，T'Joens，Y.，和C.Sargor，“在BGP/MPLS IP VPN中使用PE-PE IPSEC隧道的体系结构”，正在进行的工作，2005年8月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[RFC3448]Handley，M.，Floyd，S.，Padhye，J.，和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，RFC 3448，2003年1月。
Authors' Addresses
作者地址
W. Mark Townsley Cisco Systems USA
W.马克·汤斯利思科系统美国公司
Phone: +1-919-392-3741
EMail: mark@townsley.net
Phone: +1-919-392-3741
EMail: mark@townsley.net
Carlos Pignataro Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems 7025 Kit Creek Road邮政信箱14987美国北卡罗来纳州三角研究公园27709
Phone: +1-919-392-7428
EMail: cpignata@cisco.com
Phone: +1-919-392-7428
EMail: cpignata@cisco.com
Scott Wainner Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 USA
Scott Wainner思科系统13600美国弗吉尼亚州赫恩登杜勒斯技术大道20171
EMail: swainner@cisco.com
EMail: swainner@cisco.com
Ted Seely Sprint Nextel 12502 Sunrise Valley Drive Reston, VA 20196 USA
Ted Seely Sprint Nextel 12502日出谷大道雷斯顿，弗吉尼亚州，邮编：20196
Phone: +1-703-689-6425
EMail: tseely@sprint.net
Phone: +1-703-689-6425
EMail: tseely@sprint.net
Jeff Young
杨杰夫
EMail: young@jsyoung.net
EMail: young@jsyoung.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。