Network Working Group B. Patel
Request for Comments: 3193 Intel
Category: Standards Track B. Aboba
W. Dixon
Microsoft
G. Zorn
S. Booth
Cisco Systems
November 2001
Network Working Group B. Patel
Request for Comments: 3193 Intel
Category: Standards Track B. Aboba
W. Dixon
Microsoft
G. Zorn
S. Booth
Cisco Systems
November 2001
Securing L2TP using IPsec
使用IPsec保护L2TP
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.
本文档讨论L2TP（第二层隧道协议）如何利用IPsec提供隧道身份验证、隐私保护、完整性检查和重播保护。讨论了自愿和强制隧道工程案例。
Table of Contents
目录
1. Introduction .................................................. 2
1.1 Terminology .................................................. 3
1.2 Requirements language ........................................ 3
2. L2TP security requirements ................................... 4
2.1 L2TP security protocol ....................................... 5
2.2 Stateless compression and encryption ......................... 5
3. L2TP/IPsec inter-operability guidelines ....................... 6
3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6
3.2. Fragmentation Issues ........................................ 6
3.3. Per-packet security checks .................................. 7
4. IPsec Filtering details when protecting L2TP .................. 7
4.1. IKE Phase 1 Negotiations .................................... 8
4.2. IKE Phase 2 Negotiations .................................... 8
5. Security Considerations ....................................... 15
5.1 Authentication issues ........................................ 15
5.2 IPsec and PPP interactions ................................... 18
6. References .................................................... 21
Acknowledgments .................................................. 22
Authors' Addresses ............................................... 23
Appendix A: Example IPsec Filter sets ............................ 24
Intellectual Property Statement .................................. 27
Full Copyright Statement ......................................... 28
1. Introduction .................................................. 2
1.1 Terminology .................................................. 3
1.2 Requirements language ........................................ 3
2. L2TP security requirements ................................... 4
2.1 L2TP security protocol ....................................... 5
2.2 Stateless compression and encryption ......................... 5
3. L2TP/IPsec inter-operability guidelines ....................... 6
3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6
3.2. Fragmentation Issues ........................................ 6
3.3. Per-packet security checks .................................. 7
4. IPsec Filtering details when protecting L2TP .................. 7
4.1. IKE Phase 1 Negotiations .................................... 8
4.2. IKE Phase 2 Negotiations .................................... 8
5. Security Considerations ....................................... 15
5.1 Authentication issues ........................................ 15
5.2 IPsec and PPP interactions ................................... 18
6. References .................................................... 21
Acknowledgments .................................................. 22
Authors' Addresses ............................................... 23
Appendix A: Example IPsec Filter sets ............................ 24
Intellectual Property Statement .................................. 27
Full Copyright Statement ......................................... 28
L2TP [1] is a protocol that tunnels PPP traffic over variety of networks (e.g., IP, SONET, ATM). Since the protocol encapsulates PPP, L2TP inherits PPP authentication, as well as the PPP Encryption Control Protocol (ECP) (described in [10]), and the Compression Control Protocol (CCP) (described in [9]). L2TP also includes support for tunnel authentication, which can be used to mutually authenticate the tunnel endpoints. However, L2TP does not define tunnel protection mechanisms.
L2TP[1]是一种通过各种网络（如IP、SONET、ATM）传输PPP流量的协议。由于协议封装了PPP，L2TP继承了PPP认证，以及PPP加密控制协议（ECP）（如[10]所述）和压缩控制协议（CCP）（如[9]所述）。L2TP还包括对隧道身份验证的支持，可用于相互验证隧道端点。然而，L2TP并未定义隧道保护机制。
IPsec is a protocol suite which is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security Architecture document [6], IKE, described in [7], IPsec AH, described in [3] and IPsec ESP, described in [4]. IKE is the key management protocol while AH and ESP are used to protect IP traffic.
IPsec是一个协议套件，用于在网络层保护两个对等方之间的通信。该协议由IP安全体系结构文档[6]、[7]中描述的IKE、[3]中描述的IPsec AH和[4]中描述的IPsec ESP组成。IKE是密钥管理协议，AH和ESP用于保护IP流量。
This document proposes use of the IPsec protocol suite for protecting L2TP traffic over IP networks, and discusses how IPsec and L2TP should be used together. This document does not attempt to
本文档建议使用IPsec协议套件保护IP网络上的L2TP流量，并讨论IPsec和L2TP应如何一起使用。本文档不尝试
standardize end-to-end security. When end-to-end security is required, it is recommended that additional security mechanisms (such as IPsec or TLS [14]) be used inside the tunnel, in addition to L2TP tunnel security.
标准化端到端安全性。当需要端到端安全性时，除了L2TP隧道安全性之外，建议在隧道内使用其他安全机制（如IPsec或TLS[14]）。
Although L2TP does not mandate the use of IP/UDP for its transport mechanism, the scope of this document is limited to L2TP over IP networks. The exact mechanisms for enabling security for non-IP networks must be addressed in appropriate standards for L2TP over specific non-IP networks.
虽然L2TP不强制使用IP/UDP作为其传输机制，但本文档的范围仅限于IP网络上的L2TP。必须在特定非IP网络上L2TP的适当标准中解决为非IP网络启用安全性的确切机制。
Voluntary Tunneling In voluntary tunneling, a tunnel is created by the user, typically via use of a tunneling client. As a result, the client will send L2TP packets to the NAS which will forward them on to the LNS. In voluntary tunneling, the NAS does not need to support L2TP, and the LAC resides on the same machine as the client. Another example of voluntary tunneling is the gateway to gateway scenario. In this case the tunnel is created by a network device, typically a router or network appliance. In this scenario either side may start the tunnel on demand.
自愿隧道在自愿隧道中，隧道由用户创建，通常通过使用隧道客户端创建。因此，客户端将向NAS发送L2TP数据包，NAS将这些数据包转发到LNS。在自愿隧道中，NAS不需要支持L2TP，LAC与客户端驻留在同一台机器上。自愿隧道的另一个例子是网关到网关场景。在这种情况下，隧道由网络设备创建，通常是路由器或网络设备。在这种情况下，任何一方都可以根据需要启动隧道。
Compulsory Tunneling In compulsory tunneling, a tunnel is created without any action from the client and without allowing the client any choice. As a result, the client will send PPP packets to the NAS/LAC, which will encapsulate them in L2TP and tunnel them to the LNS. In the compulsory tunneling case, the NAS/LAC must be L2TP-capable.
强制隧道在强制隧道中，创建隧道时不需要客户采取任何行动，也不允许客户进行任何选择。因此，客户端将向NAS/LAC发送PPP数据包，NAS/LAC将它们封装在L2TP中，并通过隧道将它们传输到LNS。在强制隧道情况下，NAS/LAC必须具有L2TP能力。
Initiator The initiator can be the LAC or the LNS and is the device which sends the SCCRQ and receives the SCCRP.
启动器启动器启动器可以是LAC或LNS，是发送SCCRQ和接收SCCRP的设备。
Responder The responder can be the LAC or the LNS and is the device which receives the SCCRQ and replies with a SCCRP.
应答器应答器可以是LAC或LNS，是接收SCCRQ并使用SCCRP应答的设备。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[2]所述。
L2TP tunnels PPP traffic over the IP and non-IP public networks. Therefore, both the control and data packets of L2TP protocol are vulnerable to attack. Examples of attacks include:
L2TP隧道通过IP和非IP公共网络传输PPP流量。因此，L2TP协议的控制包和数据包都容易受到攻击。攻击的例子包括：
[1] An adversary may try to discover user identities by snooping data packets.
[1] 对手可能会试图通过窥探数据包来发现用户身份。
[2] An adversary may try to modify packets (both control and data).
[2] 对手可能试图修改数据包（控制和数据）。
[3] An adversary may try to hijack the L2TP tunnel or the PPP connection inside the tunnel.
[3] 敌方可能试图劫持L2TP隧道或隧道内的PPP连接。
[4] An adversary can launch denial of service attacks by terminating PPP connections, or L2TP tunnels.
[4] 对手可以通过终止PPP连接或L2TP隧道发起拒绝服务攻击。
[5] An adversary may attempt to disrupt the PPP ECP negotiation in order to weaken or remove confidentiality protection. Alternatively, an adversary may wish to disrupt the PPP LCP authentication negotiation so as to weaken the PPP authentication process or gain access to user passwords.
[5] 对手可能试图破坏PPP ECP谈判，以削弱或消除保密保护。或者，对手可能希望中断PPP LCP认证协商，以削弱PPP认证过程或获得对用户密码的访问权。
To address these threats, the L2TP security protocol MUST be able to provide authentication, integrity and replay protection for control packets. In addition, it SHOULD be able to protect confidentiality for control packets. It MUST be able to provide integrity and replay protection of data packets, and MAY be able to protect confidentiality of data packets. An L2TP security protocol MUST also provide a scalable approach to key management.
为了应对这些威胁，L2TP安全协议必须能够为控制数据包提供身份验证、完整性和重放保护。此外，它应该能够保护控制数据包的机密性。它必须能够提供数据包的完整性和重放保护，并且可能能够保护数据包的机密性。L2TP安全协议还必须提供可扩展的密钥管理方法。
The L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP. L2TP tunnel authentication provides mutual authentication between the LAC and the LNS at tunnel origination. Therefore, it does not protect control and data traffic on a per packet basis. Thus, L2TP tunnel authentication leaves the L2TP tunnel vulnerable to attacks. PPP authenticates the client to the LNS, but also does not provide per-packet authentication, integrity, or replay protection. PPP encryption meets confidentiality requirements for PPP traffic but does not address authentication, integrity, replay protection and key management requirements. In addition, PPP ECP negotiation, outlined in [10] does not provide for a protected ciphersuite negotiation. Therefore, PPP encryption provides a weak security solution, and in addition does not assist in securing L2TP control channel.
L2TP协议以及PPP身份验证和加密不符合L2TP的安全要求。L2TP隧道身份验证在隧道发起时提供LAC和LN之间的相互身份验证。因此，它不能以每个数据包为基础保护控制和数据流量。因此，L2TP隧道身份验证使L2TP隧道容易受到攻击。PPP向LNS验证客户端，但也不提供每包身份验证、完整性或重播保护。PPP加密满足PPP流量的保密要求，但不满足身份验证、完整性、重播保护和密钥管理要求。此外，[10]中概述的PPP ECP协商未提供受保护的密码套件协商。因此，PPP加密提供了一个弱安全性解决方案，而且不帮助保护L2TP控制通道。
Key management facilities are not provided by the L2TP protocol. However, where L2TP tunnel authentication is desired, it is necessary to distribute tunnel passwords.
L2TP协议不提供密钥管理设施。但是，如果需要L2TP隧道身份验证，则必须分发隧道密码。
Note that several of the attacks outlined above can be carried out on PPP packets sent over the link between the client and the NAS/LAC, prior to encapsulation of the packets within an L2TP tunnel. While strictly speaking these attacks are outside the scope of L2TP security, in order to protect against them, the client SHOULD provide for confidentiality, authentication, replay and integrity protection for PPP packets sent over the dial-up link. Authentication, replay and integrity protection are not currently supported by PPP encryption methods, described in [11]-[13].
请注意，在L2TP隧道中封装包之前，可以对通过客户端和NAS/LAC之间的链路发送的PPP包执行上述几种攻击。严格来说，这些攻击不属于L2TP安全的范围，但为了防止它们，客户端应为通过拨号链路发送的PPP数据包提供机密性、身份验证、重播和完整性保护。[11]-[13]中描述的PPP加密方法目前不支持身份验证、重播和完整性保护。
The L2TP security protocol MUST provide authentication, integrity and replay protection for control packets. In addition, it SHOULD protect confidentiality of control packets. It MUST provide integrity and replay protection of data packets, and MAY protect confidentiality of data packets. An L2TP security protocol MUST also provide a scalable approach to key management.
L2TP安全协议必须为控制数据包提供身份验证、完整性和重播保护。此外，它还应保护控制数据包的机密性。它必须提供数据包的完整性和重放保护，并且可以保护数据包的机密性。L2TP安全协议还必须提供可扩展的密钥管理方法。
To meet the above requirements, all L2TP security compliant implementations MUST implement IPsec ESP for securing both L2TP control and data packets. Transport mode MUST be supported; tunnel mode MAY be supported. All the IPsec-mandated ciphersuites (described in RFC 2406 [4] and RFC 2402 [3]), including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec ciphersuites, it is an operator choice which ones will be used. If confidentiality is not required (e.g., L2TP data traffic), ESP with NULL encryption may be used. The implementations MUST implement replay protection mechanisms of IPsec.
为了满足上述要求，所有L2TP安全兼容实现必须实现IPsec ESP，以保护L2TP控制和数据包。必须支持运输方式；可能支持隧道模式。必须支持所有IPsec授权的密码套件（如RFC 2406[4]和RFC 2402[3]所述），包括空加密。请注意，尽管实现必须支持所有IPsec密码套件，但使用哪种密码套件是运营商的选择。如果不需要保密（例如L2TP数据通信），则可以使用带空加密的ESP。这些实现必须实现IPsec的重播保护机制。
L2TP security MUST meet the key management requirements of the IPsec protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPsec DOI [5].
L2TP安全性必须满足IPsec协议套件的密钥管理要求。应使用IPsec DOI支持IKE进行身份验证、安全关联协商和密钥管理[5]。
Stateless encryption and/or compression is highly desirable when L2TP is run over IP. Since L2TP is a connection-oriented protocol, use of stateful compression/encryption is feasible, but when run over IP, this is not desirable. While providing better compression, when used without an underlying reliable delivery mechanism, stateful methods magnify packet losses. As a result, they are problematic when used over the Internet where packet loss can be significant. Although L2TP [1] is connection oriented, packet ordering is not mandatory,
当L2TP在IP上运行时，无状态加密和/或压缩是非常理想的。由于L2TP是一种面向连接的协议，使用有状态压缩/加密是可行的，但在IP上运行时，这是不可取的。虽然提供了更好的压缩，但在没有底层可靠的传递机制的情况下使用时，有状态方法会放大数据包丢失。因此，在数据包丢失严重的互联网上使用时，它们是有问题的。虽然L2TP[1]是面向连接的，但数据包排序不是强制性的，
which can create difficulties in implementation of stateful compression/encryption schemes. These considerations are not as important when L2TP is run over non-IP media such as IEEE 802, ATM, X.25, or Frame Relay, since these media guarantee ordering, and packet losses are typically low.
这会给有状态压缩/加密方案的实现带来困难。当L2TP在非IP介质（如IEEE 802、ATM、X.25或帧中继）上运行时，这些注意事项就不那么重要了，因为这些介质保证顺序，并且数据包丢失通常很低。
The following guidelines are established to meet L2TP security requirements using IPsec in practical situations.
以下指南旨在满足实际情况下使用IPsec的L2TP安全要求。
Mechanisms within PPP and L2TP provide for both graceful and non-graceful teardown. In the case of PPP, an LCP TermReq and TermAck sequence corresponds to a graceful teardown. LCP keep-alive messages and L2TP tunnel hellos provide the capability to detect when a non-graceful teardown has occurred. Whenever teardown events occur, causing the tunnel to close, the control connection teardown mechanism defined in [1] must be used. Once the L2TP tunnel is deleted by either peer, any phase 1 and phase 2 SA's which still exist as a result of the L2TP tunnel between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs.
PPP和L2TP中的机制提供了优雅和非优雅的拆卸。在PPP的情况下，LCP TermReq和TermAck序列对应于优雅的拆卸。LCP keep alive消息和L2TP tunnel Hello提供了检测何时发生非正常拆卸的功能。每当发生拆卸事件，导致隧道关闭时，必须使用[1]中定义的控制连接拆卸机制。一旦L2TP隧道被任一对等方删除，则应删除由于对等方之间的L2TP隧道而仍然存在的任何阶段1和阶段2 SA。发生这种情况时，应发送阶段1和阶段2删除消息。
When IKE receives a phase 1 or phase 2 delete message, IKE should notify L2TP this event has occurred. If the L2TP state is such that a ZLB ack has been sent in response to a STOPCCN, this can be assumed to be positive acknowledgment that the peer received the ZLB ack and has performed a teardown of any L2TP tunnel state associated with the peer. The L2TP tunnel state and any associated filters can now be safely removed.
当IKE收到阶段1或阶段2删除消息时，IKE应通知L2TP此事件已发生。如果L2TP状态为响应于STOPCCN而发送了ZLB ack，则可以假定这是对等方接收到ZLB ack并且已经执行了与对等方相关联的任何L2TP隧道状态的解除的肯定确认。L2TP隧道状态和任何相关过滤器现在都可以安全移除。
Since the default MRU for PPP connections is 1500 bytes, fragmentation can become a concern when prepending L2TP and IPsec headers to a PPP frame. One mechanism which can be used to reduce this problem is to provide PPP with the MTU value of the ingress/egress interface of the L2TP/IPsec tunnel minus the overhead of the extra headers. This should occur after the L2TP tunnel has been setup and but before LCP negotiations begin. If the MTU value of the ingress/egress interface for the tunnel is less than PPP's default MTU, it may replace the value being used. This value may also be used as the initial value proposed for the MRU in the LCP config req.
由于PPP连接的默认MRU为1500字节，因此在将L2TP和IPsec头预先添加到PPP帧时，碎片可能会成为一个问题。可用于减少此问题的一种机制是为PPP提供L2TP/IPsec隧道的入口/出口接口的MTU值减去额外报头的开销。这应在L2TP隧道设置之后，但LCP谈判开始之前发生。如果隧道入口/出口接口的MTU值小于PPP的默认MTU，则可以替换正在使用的值。该值也可用作LCP config req中MRU的初始建议值。
If an ICMP PMTU is received by IPsec, this value should be stored in the SA as proposed in [6]. IPsec should also provide notification of this event to L2TP so that the new MTU value can be reflected into the PPP interface. Any new PTMU discoveries seen at the PPP interface should be checked against this new value and processed accordingly.
如果IPsec接收到ICMP PMTU，则该值应按照[6]中的建议存储在SA中。IPsec还应向L2TP提供此事件的通知，以便新的MTU值可以反映到PPP接口中。在PPP接口上看到的任何新的PTMU发现都应该对照这个新值进行检查，并进行相应的处理。
When a packet arrives from a tunnel which requires security, L2TP MUST:
当数据包从需要安全性的隧道到达时，L2TP必须：
[1] Check to ensure that the packet was decrypted and/or authenticated by IPsec. Since IPsec already verifies that the packet arrived in the correct SA, L2TP can be assured that the packet was indeed sent by a trusted peer and that it did not arrive in the clear.
[1] 检查以确保数据包已由IPsec解密和/或验证。由于IPsec已经验证数据包到达了正确的SA，L2TP可以确保数据包确实是由受信任的对等方发送的，并且它没有到达clear。
[2] Verify that the IP addresses and UDP port values in the packet match the socket information which was used to setup the L2TP tunnel. This step prevents malicious peers from spoofing packets into other tunnels.
[2] 验证数据包中的IP地址和UDP端口值是否与用于设置L2TP隧道的套接字信息匹配。此步骤可防止恶意对等方将数据包欺骗到其他隧道中。
Since IKE/IPsec is agnostic about the nuances of the application it is protecting, typically no integration is necessary between the application and the IPsec protocol. However, protocols which allow the port number to float during the protocol negotiations (such as L2TP), can cause problems within the current IKE framework. The L2TP specification [1] states that implementations MAY use a dynamically assigned UDP source port. This port change is reflected in the SCCRP sent from the responder to the initiator.
由于IKE/IPsec不知道它所保护的应用程序的细微差别，因此通常不需要在应用程序和IPsec协议之间进行集成。但是，在协议协商期间允许端口号浮动的协议（如L2TP）可能会在当前IKE框架内引起问题。L2TP规范[1]指出，实现可以使用动态分配的UDP源端口。此端口更改反映在从响应程序发送到启动器的SCCRP中。
Although the current L2TP specification allows the responder to use a new IP address when sending the SCCRP, implementations requiring protection of L2TP via IPsec SHOULD NOT do this. To allow for this behavior when using L2TP and IPsec, when the responder chooses a new IP address it MUST send a StopCCN to the initiator, with the Result and Error Code AVP present. The Result Code MUST be set to 2 (General Error) and the Error Code SHOULD be set to 7 (Try Another). If the Error Code is set to 7, then the optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) that the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format for IPv6. The initiator MUST parse the result and error code information and send a new SCCRQ
尽管当前的L2TP规范允许响应者在发送SCCRP时使用新的IP地址，但需要通过IPsec保护L2TP的实现不应该这样做。为了在使用L2TP和IPsec时允许此行为，当响应程序选择新的IP地址时，它必须向启动器发送StopCCN，结果和错误代码为AVP。结果代码必须设置为2（一般错误），错误代码应设置为7（尝试另一个）。如果错误代码设置为7，则必须显示可选错误消息，并且内容必须包含响应者希望用于后续通信的IP地址（ASCII编码）。错误消息中应仅显示ASCII编码的IP地址。对于IPv4，IP地址以点十进制格式编码；对于IPv6，IP地址以RFC 2373[17]格式编码。启动器必须解析结果和错误代码信息，并发送新的SCCRQ
to the new IP address contained in the error message. This approach reduces complexity since now the initiator always knows precisely the IP address of its peer. This also allows a controlled mechanism for L2TP to tie IPsec filters and policy to the same peer.
发送到错误消息中包含的新IP地址。这种方法降低了复杂性，因为现在发起方总是准确地知道其对等方的IP地址。这还允许L2TP的受控机制将IPsec筛选器和策略绑定到同一对等方。
The filtering details required to accommodate this behavior as well as other mechanisms needed to protect L2TP with IPsec are discussed in the following sections.
以下部分将讨论适应此行为所需的过滤细节以及使用IPsec保护L2TP所需的其他机制。
Per IKE [7], when using pre-shared key authentication, a key must be present for each peer to which secure communication is required. When using Main Mode (which provides identity protection), this key must correspond to the IP address for the peer. When using Aggressive Mode (which does not provide identity protection), the pre-shared key must map to one of the valid id types defined in the IPsec DOI [5].
根据IKE[7]，当使用预共享密钥身份验证时，必须为需要安全通信的每个对等方提供密钥。使用主模式（提供身份保护）时，此密钥必须与对等方的IP地址相对应。使用主动模式（不提供身份保护）时，预共享密钥必须映射到IPsec DOI[5]中定义的有效id类型之一。
If the initiator receives a StopCCN with the result and error code AVP set to "try another" and a valid IP address is present in the message, it MAY bind the original pre-shared key used by IKE to the new IP address contained in the error-message.
如果启动器收到StopCCN，其结果和错误代码AVP设置为“尝试另一个”，并且消息中存在有效的IP地址，则它可能会将IKE使用的原始预共享密钥绑定到错误消息中包含的新IP地址。
One may may wish to consider the implications for scalability of using pre-shared keys as the authentication method for phase 1. As the number of LAC and LNS endpoints grow, pre-shared keys become increasingly difficult to manage. Whenever possible, authentication with certificates is preferred.
人们可能希望考虑使用预共享密钥作为阶段1的认证方法的可扩展性的影响。随着LAC和LNS端点数量的增加，预共享密钥变得越来越难以管理。只要可能，最好使用证书进行身份验证。
During the IKE phase 2 negotiations, the peers agree on what traffic is to be protected by the IPsec protocols. The quick mode IDs represent the traffic which the peers agree to protect and are comprised of address space, protocol, and port information.
在IKE第2阶段协商期间，对等方就IPsec协议要保护的通信量达成一致。快速模式ID表示对等方同意保护的通信量，由地址空间、协议和端口信息组成。
When securing L2TP with IPsec, the following cases must be considered:
使用IPsec保护L2TP时，必须考虑以下情况：
Cases:
案例：
+--------------------------------------------------+
| Initiator Port | Responder Addr | Responder Port |
+--------------------------------------------------+
| 1701 | Fixed | 1701 |
+--------------------------------------------------+
| 1701 | Fixed | Dynamic |
+--------------------------------------------------+
| 1701 | Dynamic | 1701 |
+--------------------------------------------------+
| 1701 | Dynamic | Dynamic |
+--------------------------------------------------+
| Dynamic | Fixed | 1701 |
+--------------------------------------------------+
| Dynamic | Fixed | Dynamic |
+--------------------------------------------------+
| Dynamic | Dynamic | 1701 |
+--------------------------------------------------+
| Dynamic | Dynamic | Dynamic |
+--------------------------------------------------+
+--------------------------------------------------+
| Initiator Port | Responder Addr | Responder Port |
+--------------------------------------------------+
| 1701 | Fixed | 1701 |
+--------------------------------------------------+
| 1701 | Fixed | Dynamic |
+--------------------------------------------------+
| 1701 | Dynamic | 1701 |
+--------------------------------------------------+
| 1701 | Dynamic | Dynamic |
+--------------------------------------------------+
| Dynamic | Fixed | 1701 |
+--------------------------------------------------+
| Dynamic | Fixed | Dynamic |
+--------------------------------------------------+
| Dynamic | Dynamic | 1701 |
+--------------------------------------------------+
| Dynamic | Dynamic | Dynamic |
+--------------------------------------------------+
By solving the most general case of the above permutations, all cases are covered. The most general case is the last one in the list. This scenario is when the initiator chooses a new port number and the responder chooses a new address and port number. The L2TP message flow which occurs to setup this sequence is as follows:
通过解决上述排列的最一般情况，涵盖了所有情况。最普遍的情况是列表中的最后一个。这种情况下，发起方选择一个新的端口号，而响应方选择一个新的地址和端口号。设置此序列时出现的L2TP消息流如下所示：
-> IKE Phase 1 and Phase 2 to protect Initial SCCRQ
->IKE阶段1和阶段2用于保护初始SCCRQ
SCCRQ -> (Fixed IP address, Dynamic Initiator Port) <- STOPCCN (Responder chooses new IP address)
SCCRQ->（固定IP地址，动态启动器端口）<-STOPCCN（响应程序选择新IP地址）
-> New IKE Phase 1 and Phase 2 to protect new SCCRQ
->新的IKE阶段1和阶段2保护新的SCCRQ
SCCRQ -> (SCCRQ to Responder's new IP address)
SCCRQ->（SCCRQ到响应者的新IP地址）
<- New IKE Phase 2 to for port number change by the responder
<-响应者更改端口号的新IKE阶段2
<- SCCRP (Responder chooses new port number) SCCCN -> (L2TP Tunnel Establishment completes)
<-SCCRP（响应者选择新端口号）SCCCN->（L2TP隧道建立完成）
Although the Initiator and Responder typically do not dynamically change ports, L2TP security must accommodate emerging applications such as load balancing and QoS. This may require that the port and IP address float during L2TP tunnel establishment.
虽然启动器和响应程序通常不会动态更改端口，但L2TP安全性必须适应负载平衡和QoS等新兴应用程序。这可能要求在L2TP隧道建立期间端口和IP地址浮动。
To support the general case, mechanisms must be designed into L2TP and IPsec which allow L2TP to inject filters into the IPsec filter database. This technique may be used by any application which floats ports and requires security via IPsec, and is described in the following sections.
为了支持一般情况，必须在L2TP和IPsec中设计允许L2TP将筛选器注入IPsec筛选器数据库的机制。任何浮动端口并需要通过IPsec进行安全保护的应用程序都可以使用此技术，以下各节将对此进行描述。
The responder is not required to support the ability to float its IP address and port. However, the initiator MUST allow the responder to float its port and SHOULD allow the responder to choose a new IP address (see section 4.2.3, below).
响应程序不需要支持浮动其IP地址和端口的能力。但是，发起方必须允许响应方浮动其端口，并应允许响应方选择新的IP地址（见下文第4.2.3节）。
Appendix A provides examples of these cases using the process described below.
附录A提供了使用下述流程的这些案例的示例。
I-Port The UDP port number the Initiator chooses to originate/receive L2TP traffic on. This can be a static port such as 1701 or an ephemeral one assigned by the socket.
I-Port启动器选择在其上发起/接收L2TP通信的UDP端口号。这可以是静态端口，如1701，也可以是套接字分配的临时端口。
R-Port The UDP port number the Responder chooses to originate/receive L2TP traffic on. This can be the port number 1701 or an ephemeral one assigned by the socket. This is the port number the Responder uses after receiving the initial SCCRQ.
R-Port响应程序选择在其上发起/接收L2TP通信的UDP端口号。这可以是端口号1701，也可以是套接字分配的临时端口号。这是响应程序在收到初始SCCRQ后使用的端口号。
R-IPAddr1 The IP address the Responder listens on for initial SCCRQ. If the responder does not choose a new IP address, this address will be used for all subsequent L2TP traffic.
R-IPAddr1响应程序侦听初始SCCRQ的IP地址。如果响应者未选择新的IP地址，则该地址将用于所有后续L2TP通信。
R-IPAddr2 The IP address the Responder chooses upon receiving the SCCRQ. This address is used to send the SCCRP and all subsequent L2TP tunnel traffic is sent and received on this address.
R-IPAddr2响应程序在收到SCCRQ时选择的IP地址。此地址用于发送SCCRP，所有后续L2TP隧道流量均在此地址上发送和接收。
R-IPAddr The IP address which the responder uses for sending and receiving L2TP packets. This is either the initial value of R-IPAddr1 or a new value of R-IPAddr2.
R-IPAddr响应程序用于发送和接收L2TP数据包的IP地址。这是R-IPAddr1的初始值或R-IPAddr2的新值。
I-IPAddr The IP address the Initiator uses to communicate with for the L2TP tunnel.
I-IPAddr启动器用于L2TP隧道通信的IP地址。
Any-Addr The presence of Any-Address defines that IKE should accept any single address proposed in the local address of the quick mode IDs sent by the peer during IKE phase 2 negotiations. This single address may be formatted as an
任何地址的存在定义了IKE应接受在IKE第2阶段协商期间对等方发送的快速模式ID的本地地址中提出的任何单个地址。此单个地址可以格式化为
IP Single address, an IP Netmask address with the Netmask set to 255.255.255.255, and IP address Range with the range being 1, or a hostname which can be resolved to one address. Refer to [5] for more information on the format for quick mode IDs.
IP单地址，网络掩码设置为255.255.255.255的IP网络掩码地址，范围为1的IP地址范围，或可解析为一个地址的主机名。有关快速模式ID格式的更多信息，请参阅[5]。
Any-Port The presence of Any-Port defines that IKE should accept a value of 0 or a specific port value for the port value in the port value in the quick mode IDs negotiated during IKE phase 2.
任何端口任何端口的存在都定义了IKE应在IKE阶段2期间协商的快速模式ID的端口值中接受0值或特定端口值作为端口值。
The filters defined in the following sections are listed from highest priority to lowest priority.
以下部分中定义的过滤器从最高优先级到最低优先级列出。
The initial filter set on the initiator and responder is necessary to protect the SCCRQ sent by the initiator to open the L2TP tunnel. Both the initiator and the responder must either be pre-configured for these filters or L2TP must have a method to inject this information into the IPsec filtering database. In either case, this filter MUST be present before the L2TP tunnel setup messages start to flow.
启动器和响应程序上的初始过滤器设置是保护启动器发送的SCCRQ以打开L2TP隧道所必需的。必须为这些筛选器预先配置启动器和响应程序，或者L2TP必须具有将此信息注入IPsec筛选数据库的方法。在任何一种情况下，在L2TP隧道设置消息开始流动之前，必须存在此筛选器。
Responder Filters: Outbound-1: None. They should be be dynamically created by IKE upon successful completion of phase 2.
响应程序筛选器：出站-1:无。在第2阶段成功完成后，IKE应该动态创建它们。
Inbound-1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
Inbound-1：从任意地址到R-IPAddr1、UDP、src任意端口、dst 1701
Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port, dst 1701
启动器筛选器：出站-1:从I-IPAddr到R-IPAddr1，UDP，src I-Port，dst 1701
Inbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-2: From R-IPAddr1, to I-IPAddr, UDP, src Any-Port, dst I-Port
入站-1：从R-IPADR1到I-IPAddr，UDP，src 1701，dst I端口入站-2：从R-IPADR1到I-IPAddr，UDP，src任意端口，dst I端口
When the initiator uses dynamic ports, L2TP must inject the filters into the IPsec filter database, once its source port number is known. If the initiator uses a fixed port of 1701, these filters MAY be statically defined.
当启动器使用动态端口时，L2TP必须在知道其源端口号后将筛选器注入IPsec筛选器数据库。如果启动器使用固定端口1701，则可以静态定义这些过滤器。
The Any-Port definition in the initiator's inbound-2 filter statement is needed to handle the potential port change which may occur as the result of the responder changing its port number.
需要启动器的inbound-2 filter语句中的Any Port定义来处理由于响应程序更改其端口号而可能发生的端口更改。
If a phase 2 SA bundle is not already present to protect the SCCRQ, the sending of a SCCRQ by the initiator SHOULD cause IKE to setup the necessary SAs to protect this packet. Alternatively, L2TP may also request IKE to setup the SA bundle. If the SA cannot be setup for some reason, the packet MUST be dropped.
如果还没有阶段2 SA捆绑包来保护SCCRQ，则发起方发送SCCRQ应导致IKE设置必要的SA来保护此数据包。或者，L2TP也可以请求IKE设置SA包。如果由于某种原因无法设置SA，则必须丢弃数据包。
The port numbers in the Quick Mode IDs sent by the initiator MUST contain the specific port numbers used to identify the UDP socket. The port numbers would be either I-Port/1701 or 1701/1701 for the initial SCCRQ. The quick mode IDs sent by the initiator will be a subset of the Inbound-1 filter at the responder. As a result, the quick mode exchange will finish and IKE should inject a specific filter set into the IPsec filter database and associate this filter set with the phase 2 SA established between the peers. These filters should persist as long as the L2TP tunnel exists. The new filter set at the responder will be:
启动器发送的快速模式ID中的端口号必须包含用于标识UDP套接字的特定端口号。初始SCCRQ的端口号为I-port/1701或1701/1701。发起方发送的快速模式ID将是响应方的入站-1筛选器的子集。因此，快速模式交换将完成，IKE应将特定筛选器集注入IPsec筛选器数据库，并将此筛选器集与对等方之间建立的阶段2 SA关联。只要L2TP隧道存在，这些过滤器就会一直存在。在响应者处设置的新过滤器为：
Responder Filters: Outbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701, dst I-Port
响应程序筛选器：出站-1:从R-IPAddr1到I-IPAddr、UDP、src 1701、dst I端口
Inbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port, dst 1701 Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
入站-1：从I-IPAddr到R-IPAddr1，UDP，src I-Port，dst 1701入站-2：从任意地址到R-IPAddr1，UDP，src任意端口，dst 1701
Mechanisms SHOULD exist between L2TP and IPsec such that L2TP is not retransmitting the SCCRQ while the SA is being established. L2TP's control channel retransmit mechanisms should start once the SA has been established. This will help avoid timeouts which may occur as the result of slow SA establishment.
L2TP和IPsec之间应存在机制，以便在建立SA时L2TP不会重新传输SCCRQ。L2TP的控制信道重传机制应在SA建立后启动。这将有助于避免SA建立缓慢导致的超时。
Once the phase 2 SA has been established between the peers, the SCCRQ should be sent from the initiator to the responder.
在对等方之间建立阶段2 SA后，应将SCCRQ从发起方发送到响应方。
If the responder does not choose a new IP address or a new port number, the L2TP tunnel can now proceed to establish.
如果响应程序没有选择新的IP地址或新的端口号，L2TP隧道现在可以继续建立。
This step describes the process which should be followed when the responder chooses a new IP address. The only opportunity for the responder to change its IP address is after receiving the SCCRQ but before sending a SCCRP.
此步骤描述了响应者选择新IP地址时应遵循的流程。响应者更改其IP地址的唯一机会是在收到SCCRQ之后但在发送SCCRP之前。
The new address the responder chooses to use MUST be reflected in the result and error code AVP of a STOPCCN message. The Result Code MUST be set to 2 (General Error) and the Error Code MUST be set to 7 (Try
响应者选择使用的新地址必须反映在STOPCCN消息的结果和错误代码AVP中。结果代码必须设置为2（一般错误），错误代码必须设置为7（重试）
Another). The optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format for IPv6.
另一个）。可选错误消息必须存在，且内容必须包含响应者希望用于后续通信的IP地址（ASCII编码）。错误消息中应仅显示ASCII编码的IP地址。对于IPv4，IP地址以点十进制格式编码；对于IPv6，IP地址以RFC 2373[17]格式编码。
The STOPCCN Message MUST be sent using the same address and UDP port information which the initiator used to send the SCCRQ. This message will be protecting using the initial SA bundle setup to protect the SCCRQ.
必须使用启动器用于发送SCCRQ的相同地址和UDP端口信息发送STOPCCN消息。此消息将使用初始SA bundle设置来保护SCCRQ。
Upon receiving the STOPCCN, the initiator MUST parse the IP address from the Result and Error Code AVP and perform the necessary sanity checks to verify this is a correctly formatted address. If no errors are found L2TP should inject a new set of filters into the IPsec filter database. If using pre-shared key authentication, L2TP MAY request IKE to bind the new IP address to the pre-shared key which was used for the original IP address.
收到STOPCCN后，启动器必须从结果和错误代码AVP解析IP地址，并执行必要的健全性检查，以验证这是一个格式正确的地址。如果没有发现错误，L2TP应该向IPsec筛选器数据库中注入一组新的筛选器。如果使用预共享密钥身份验证，L2TP可能会请求IKE将新IP地址绑定到用于原始IP地址的预共享密钥。
Since the IP address of the responder changed, a new phase 1 and phase 2 SA must be established between the peers before the new SCCRQ is sent.
由于响应者的IP地址已更改，因此在发送新SCCRQ之前，必须在对等方之间建立新的阶段1和阶段2 SA。
Assuming the initial tunnel has been torn down and the filters needed to create the tunnel removed, the new filters for the initiator and responder will be:
假设初始通道已拆除，且创建通道所需的过滤器已移除，则启动器和响应程序的新过滤器将为：
Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port, dst 1701
启动器筛选器：出站-1:从I-IPAddr到R-IPAddr2、UDP、src I-Port、dst 1701
Inbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-2: From R-IPAddr2, to I-IPAddr, UDP, src Any-Port, dst I-Port
入站-1：从R-IPAddr2到I-IPAddr，UDP，src 1701，dst I端口入站-2：从R-IPAddr2到I-IPAddr，UDP，src任意端口，dst I端口
Once IKE phase 2 completes, the new filter set at the responder will be:
IKE阶段2完成后，响应者处的新过滤器集将为：
Responder Filters: Outbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701, dst I-Port
响应程序筛选器：出站-1:从R-IPAddr2到I-IPAddr、UDP、src 1701、dst I端口
Inbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port, dst 1701 Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
入站-1：从I-IPAddr到R-IPAddr2，UDP，src I-Port，dst 1701入站-2：从任意地址到R-IPAddr1，UDP，src任意端口，dst 1701
If the responder chooses not to move to a new port number, the L2TP tunnel setup can now complete.
如果响应程序选择不移动到新端口号，L2TP隧道设置现在可以完成。
The responder MAY choose a new UDP source port to use for L2TP tunnel traffic. This decision MUST be made before sending the SCCRP. If a new port number is chosen, then L2TP must inject new filters into the IPsec filter database. The responder must start new IKE phase 2 negotiations with the initiator.
响应者可以选择新的UDP源端口用于L2TP隧道通信。必须在发送SCCRP之前做出此决定。如果选择了新端口号，则L2TP必须将新筛选器注入IPsec筛选器数据库。响应者必须与发起者开始新的IKE阶段2协商。
The final filter set at the initiator and responder is as follows.
在发起方和响应方设置的最终过滤器如下所示。
Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst R-Port Outbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst 1701
启动器筛选器：出站-1:从I-IPADR到R-IPADR，UDP，src I-Port，dst R-Port出站-2:从I-IPADR到R-IPADR，UDP，src I-Port，dst 1701
Inbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst I-Port Inbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-3: From R-IPAddr, to I-IPAddr, UDP, src Any-Port, dst I-Port
Inbound-1:从R-IPADR到I-IPADR，UDP，src R-Port，dst I-Port Inbound-2:从R-IPADR到I-IPADR，UDP，src 1701，dst I-Port Inbound-3:从R-IPADR到I-IPADR，UDP，src任意端口，dst I-Port
The Inbound-1 filter for the initiator will be injected by IKE upon successful completion of the phase 2 negotiations initiated by the peer.
在对等方发起的第2阶段协商成功完成后，IKE将注入启动器的入站-1筛选器。
Responder Filters: Outbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst I-Port Outbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst I-Port
响应程序筛选器：出站-1:从R-IPADR到I-IPADR，UDP，src R-Port，dst I-Port出站-2:从R-IPADR到I-IPADR，UDP，src 1701，dst I-Port
Inbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst R-Port Inbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst 1701 Inbound-3: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
入站-1：从I-IPADR到R-IPADR，UDP，src I-Port，dst R-Port入站-2：从I-IPADR到R-IPADR，UDP，src I-Port，dst 1701入站-3：从任意地址到R-IPADR1，UDP，src任意端口，dst 1701
Once the negotiations have completed, the SCCRP is sent and the L2TP tunnel can complete establishment. After the L2TP tunnel has been established, any residual SAs and their associated filters may be deleted.
一旦谈判完成，将发送SCCRP，L2TP隧道即可完成建设。建立L2TP隧道后，可能会删除任何剩余SA及其相关过滤器。
In the gateway-gateway or the L2TP dial-out scenario, either side may initiate L2TP. The process outlined in the previous steps should be followed with one addition. The initial filter set at both sides MUST include the following filter:
在网关或L2TP拨出方案中，任何一方都可以启动L2TP。在前面步骤中概述的过程之后，应添加一项。两侧设置的初始过滤器必须包括以下过滤器：
Inbound Filter: 1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
入站筛选器：1：从任意地址到R-IPAddr1、UDP、src任意端口、dst 1701
When either peer decides to start a tunnel, L2TP should inject the necessary inbound and outbound filters to protect the SCCRQ. Tunnel establishment then proceeds exactly as stated in the previous sections.
当任一对等方决定启动隧道时，L2TP应注入必要的入站和出站筛选器以保护SCCRQ。然后，隧道建设完全按照前面章节的规定进行。
IPsec IKE negotiation MUST negotiate an authentication method specified in the IKE RFC 2409 [7]. In addition to IKE authentication, L2TP implementations utilize PPP authentication methods, such as those described in [15]-[16]. In this section, we discuss authentication issues.
IPsec IKE协商必须协商IKE RFC 2409[7]中指定的身份验证方法。除了IKE身份验证之外，L2TP实现还利用PPP身份验证方法，如[15]-[16]中所述。在本节中，我们将讨论身份验证问题。
While PPP provides initial authentication, it does not provide per-packet authentication, integrity or replay protection. This implies that the identity verified in the initial PPP authentication is not subsequently verified on reception of each packet.
虽然PPP提供初始身份验证，但它不提供每包身份验证、完整性或重播保护。这意味着在初始PPP认证中验证的身份随后不会在接收到每个分组时进行验证。
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet.
对于IPsec，当IKE中声明的身份经过身份验证时，生成的派生密钥用于提供每个数据包的身份验证、完整性和重播保护。结果，随后在接收到每个分组时验证在IKE会话中验证的身份。
Let us assume that the identity claimed in PPP is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way to verify that only the user authenticated within PPP is using the tunnel. In fact, IPsec implementations that only support machine authentication typically have no way to enforce traffic segregation. As a result, where machine authentication is used, once an L2TP/IPsec tunnel is opened, any user on a multi-user machine will typically be able to send traffic down the tunnel.
让我们假设PPP中声明的身份是用户身份，而IKE中声明的身份是机器身份。由于仅在每个数据包的基础上验证机器标识，因此无法验证只有在PPP内经过身份验证的用户在使用隧道。事实上，仅支持计算机身份验证的IPsec实现通常无法强制实施流量隔离。因此，在使用机器身份验证的情况下，一旦L2TP/IPsec隧道被打开，多用户机器上的任何用户通常都能够沿着隧道发送流量。
If the IPsec implementation supports user authentication, this problem can be averted. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between users when user authentication is used, the client MUST ensure that only traffic from that particular user is sent down the L2TP tunnel.
如果IPsec实现支持用户身份验证，则可以避免此问题。在这种情况下，IKE中断言的用户身份将基于每个数据包进行验证。为了在使用用户身份验证时在用户之间提供流量隔离，客户端必须确保只有来自该特定用户的流量沿L2TP隧道发送。
When X.509 certificate authentication is chosen within IKE, the LNS is expected to use an IKE Certificate Request Payload (CRP) to request from the client a certificate issued by a particular certificate authority or may use several CRPs if several certificate authorities are trusted and configured in its IPsec IKE authentication policy.
当在IKE内选择X.509证书身份验证时，LNS预期将使用IKE证书请求有效负载（CRP）向客户端请求由特定证书颁发机构颁发的证书，或者如果在其IPsec IKE身份验证策略中信任并配置了多个证书颁发机构，则可以使用多个CRP。
The LNS SHOULD be able to trust several certificate authorities in order to allow tunnel client end-points to connect to it using their own certificate credential from their chosen PKI. Client and server side certificate revocation list checking MAY be enabled on a per-CA basis, since differences in revocation list checking exist between different PKI providers.
LNS应该能够信任多个证书颁发机构，以便允许隧道客户端端点使用他们自己的证书凭据从他们选择的PKI连接到它。客户端和服务器端证书吊销列表检查可以基于每个CA启用，因为不同PKI提供商之间存在吊销列表检查的差异。
L2TP implementations MAY use dynamically assigned ports for both source and destination ports only if security for each source and destination port combination can be successfully negotiated by IKE.
只有当IKE能够成功协商每个源端口和目标端口组合的安全性时，L2TP实现才能为源端口和目标端口使用动态分配的端口。
The certificate credentials provided by the L2TP client during the IKE negotiation MAY be those of the machine or of the L2TP user. When machine authentication is used, the machine certificate is typically stored on the LAC and LNS during an enrollment process. When user certificates are used, the user certificate can be stored either on the machine or on a smartcard.
IKE协商期间L2TP客户端提供的证书凭证可以是机器的凭证，也可以是L2TP用户的凭证。当使用机器身份验证时，机器证书通常在注册过程中存储在LAC和LN上。使用用户证书时，用户证书可以存储在计算机上或智能卡上。
Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate.
由于机器证书的值与攻击者在虚假情况下获取证书的难易程度成反比，因此建议严格控制机器证书注册过程。例如，只有管理员才能使用计算机证书注册计算机。
While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided
虽然智能卡证书存储减少了私钥泄露的可能性，但并非所有情况下都需要智能卡。例如，一些部署计算机证书的组织使用这些证书来限制使用未经批准的硬件。因为可以提供用户身份验证
within PPP (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user.
在PPP中（请记住前面描述的弱点），IPsec中对机器身份验证的支持使得可以对机器和用户进行身份验证。
In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable.
在这种双重保证被认为是有价值的情况下，如果机器证书存储在智能卡上，则可能不希望机器证书从一台机器移动到另一台机器。
Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired.
同样，在部署用户证书时，建议严格控制用户注册过程。例如，如果可以随时使用用户密码来获取证书（临时证书或长期证书），则该证书的安全值不超过密码。为了限制攻击者从被盗密码获取用户证书的能力，可以限制注册期，注册期过后将关闭密码访问。这样的策略将防止攻击者在注册期到期后获取未使用帐户的密码，从而获取用户证书。
Use of pre-shared keys in IKE main mode is vulnerable to man-in-the-middle attacks when used in remote access situations. In main mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, in remote access situations, dynamic IP address assignment is typical, so that it is often not possible to identify the required pre-shared key based on the IP address.
在IKE主模式下使用预共享密钥在远程访问情况下容易受到中间人攻击。在主模式下，必须在接收识别有效载荷之前使用SKEYID_e。因此，预共享密钥的选择可能仅基于IP报头中包含的信息。然而，在远程访问情况下，动态IP地址分配是典型的，因此通常无法根据IP地址识别所需的预共享密钥。
Thus when pre-shared keys are used in remote access scenarios, the same pre-shared key is shared by a group of users and is no longer able to function as an effective shared secret. In this situation, neither the client nor the server identifies itself during IKE phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre-shared key to act as a man-in-the-middle.
因此，当在远程访问场景中使用预共享密钥时，相同的预共享密钥由一组用户共享，并且不再能够作为有效的共享密钥发挥作用。在这种情况下，客户机和服务器在IKE阶段1期间都不会识别自己；只知道双方都是了解预共享密钥的小组成员。这允许任何有权访问组预共享密钥的人充当中间人。
This vulnerability does not occur in aggressive mode since the identity payload is sent earlier in the exchange, and therefore the pre-shared key can be selected based on the identity. However, when aggressive mode is used the user identity is exposed and this is often considered undesirable.
此漏洞不会在攻击模式下发生，因为身份有效负载在exchange中较早发送，因此可以根据身份选择预共享密钥。然而，当使用攻击模式时，用户身份被暴露，这通常被认为是不可取的。
As a result, where main mode is used with pre-shared keys, unless PPP performs mutual authentication, the server is not authenticated. This enables a rogue server in possession of the group pre-shared key
因此，在主模式与预共享密钥一起使用的情况下，除非PPP执行相互身份验证，否则不会对服务器进行身份验证。这将启用拥有组预共享密钥的恶意服务器
to successfully masquerade as the LNS and mount a dictionary attack on legacy authentication methods such as CHAP [15]. Such an attack could potentially compromise many passwords at a time. This vulnerability is present in some existing IPsec tunnel mode implementations.
要成功伪装成LNS并对CHAP等传统身份验证方法发起字典攻击[15]。这样的攻击可能一次破坏多个密码。某些现有IPsec隧道模式实现中存在此漏洞。
To avoid this problem, L2TP/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication to the LNS. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password used by L2TP.
为避免此问题，L2TP/IPsec实现不应使用组预共享密钥对LNS进行IKE身份验证。IKE预共享身份验证密钥值的保护方式应类似于L2TP使用的用户帐户密码。
When L2TP is protected with IPsec, both PPP and IPsec security services are available. Which services are negotiated depends on whether the tunnel is compulsory or voluntary. A detailed analysis of voluntary and compulsory tunneling scenarios is included below. These scenarios are non-normative and do not create requirements for an implementation to be L2TP security compliant.
当L2TP受IPsec保护时，PPP和IPsec安全服务都可用。谈判哪些服务取决于隧道是强制性的还是自愿的。下文详细分析了自愿和强制隧道方案。这些场景是非规范性的，不要求实现与L2TP安全兼容。
In the scenarios below, it is assumed that both L2TP clients and servers are able to set and get the properties of IPsec security associations, as well as to influence the IPsec security services negotiated. Furthermore, it is assumed that L2TP clients and servers are able to influence the negotiation process for PPP encryption and compression.
在下面的场景中，假设L2TP客户端和服务器都能够设置和获取IPsec安全关联的属性，并影响协商的IPsec安全服务。此外，假设L2TP客户端和服务器能够影响PPP加密和压缩的协商过程。
In the case of a compulsory tunnel, the client sends PPP frames to the LAC, and will typically not be aware that the frames are being tunneled, nor that any security services are in place between the LAC and LNS. At the LNS, a data packet will arrive, which includes a PPP frame encapsulated in L2TP, which is itself encapsulated in an IP packet. By obtaining the properties of the Security Association set up between the LNS and the LAC, the LNS can obtain information about security services in place between itself and the LAC. Thus in the compulsory tunneling case, the client and the LNS have unequal knowledge of the security services in place between them.
在强制隧道的情况下，客户端向LAC发送PPP帧，并且通常不知道帧正在隧道中，也不知道LAC和LN之间存在任何安全服务。在LNS处，数据分组将到达，其中包括封装在L2TP中的PPP帧，其本身封装在IP分组中。通过获取在LNS和LAC之间建立的安全关联的属性，LNS可以获取关于自身和LAC之间的安全服务的信息。因此，在强制隧道案件中，客户和LN对他们之间的安全服务的了解不平等。
Since the LNS is capable of knowing whether confidentiality, authentication, integrity and replay protection are in place between itself and the LAC, it can use this knowledge in order to modify its behavior during PPP ECP [10] and CCP [9] negotiation. Let us assume that LNS confidentiality policy can be described by one of the following terms: "Require Encryption," "Allow Encryption" or "Prohibit Encryption." If IPsec confidentiality services are in place, then an LNS implementing a "Prohibit Encryption" policy will
由于LNS能够知道其与LAC之间是否存在保密性、身份验证、完整性和重播保护，因此LNS可以利用这些知识在PPP ECP[10]和CCP[9]协商期间修改其行为。让我们假设LNS机密性策略可以用以下术语之一来描述：“需要加密”、“允许加密”或“禁止加密”。如果IPsec机密性服务到位，则实现“禁止加密”策略的LNS将
act as though the policy had been violated. Similarly, an LNS implementing a "Require Encryption" or "Allow Encryption" policy will act as though these policies were satisfied, and would not mandate use of PPP encryption or compression. This is not the same as insisting that PPP encryption and compression be turned off, since this decision will depend on client policy.
表现得好像违反了政策一样。类似地，实施“需要加密”或“允许加密”策略的LNS将如同满足这些策略一样，不会强制使用PPP加密或压缩。这与坚持关闭PPP加密和压缩不同，因为这一决定将取决于客户端策略。
Since the client has no knowledge of the security services in place between the LAC and the LNS, and since it may not trust the LAC or the wire between itself and the LAC, the client will typically want to ensure sufficient security through use of end-to-end IPsec or PPP encryption/compression between itself and the LNS.
由于客户端不知道LAC和LNS之间的安全服务，并且可能不信任LAC或其自身和LAC之间的线路，因此客户端通常希望通过在其自身和LNS之间使用端到端IPsec或PPP加密/压缩来确保足够的安全性。
A client wishing to ensure security services over the entire travel path would not modify this behavior even if it had knowledge of the security services in place between the LAC and the LNS. The client negotiates confidentiality services between itself and the LNS in order to provide privacy on the wire between itself and the LAC. The client negotiates end-to-end security between itself and the end-station in order to ensure confidentiality on the portion of the path between the LNS and the end-station.
希望确保整个旅行路线上的安全服务的客户不会修改此行为，即使其了解LAC和LNS之间的安全服务。客户与LNS之间协商保密服务，以便在其与LAC之间的线路上提供隐私。客户端在其自身和终端站之间协商端到端安全性，以确保LNS和终端站之间路径部分的机密性。
The client will typically not trust the LAC and will negotiate confidentiality and compression services on its own. As a result, the LAC may only wish to negotiate IPsec ESP with null encryption with the LNS, and the LNS will request replay protection. This will ensure that confidentiality and compression services will not be duplicated over the path between the LAC and the LNS. This results in better scalability for the LAC, since encryption will be handled by the client and the LNS.
客户通常不信任LAC，并自行协商保密和压缩服务。因此，LAC可能只希望与LNS协商带空加密的IPsec ESP，LNS将请求重播保护。这将确保保密和压缩服务不会在LAC和LN之间的路径上重复。这将为LAC带来更好的可伸缩性，因为加密将由客户端和LN处理。
The client can satisfy its desire for confidentiality services in one of two ways. If it knows that all end-stations that it will communicate with are IPsec-capable (or if it refuses to talk to non-IPsec capable end-stations), then it can refuse to negotiate PPP encryption/compression and negotiate IPsec ESP with the end-stations instead. If the client does not know that all end-stations it will contact are IPsec capable (the most likely case), then it will negotiate PPP encryption/compression. This may result in duplicate compression/encryption which can only be eliminated if PPP compression/encryption can be turned off on a per-packet basis. Note that since the LNS knows that the client's packets are being tunneled but the client does not, the LNS can ensure that stateless compression/encryption is used by offering stateless compression/encryption methods if available in the ECP and CCP negotiations.
客户可以通过以下两种方式之一满足其对保密服务的需求。如果它知道它将与之通信的所有终端站都支持IPsec（或者如果它拒绝与不支持IPsec的终端站通信），那么它可以拒绝协商PPP加密/压缩，并与终端站协商IPsec ESP。如果客户端不知道它将联系的所有终端站都支持IPsec（最有可能的情况），那么它将协商PPP加密/压缩。这可能会导致重复的压缩/加密，只有在每个数据包的基础上关闭PPP压缩/加密时才能消除重复的压缩/加密。注意，由于LNS知道客户端的数据包正在被隧道传输，但客户端不知道，因此LNS可以通过提供无状态压缩/加密方法（如果ECP和CCP协商中可用）来确保使用无状态压缩/加密。
In the case of a voluntary tunnel, the client will be send L2TP packets to the NAS, which will route them to the LNS. Over a dialup link, these L2TP packets will be encapsulated in IP and PPP. Assuming that it is possible for the client to retrieve the properties of the Security Association between itself and the LNS, the client will have knowledge of any security services negotiated between itself and the LNS. It will also have knowledge of PPP encryption/compression services negotiated between itself and the NAS.
在自愿隧道的情况下，客户端将向NAS发送L2TP数据包，NAS将把它们路由到LNS。通过拨号链路，这些L2TP数据包将封装在IP和PPP中。假设客户可以检索其自身与LNS之间的安全关联的属性，则客户将了解其自身与LNS之间协商的任何安全服务。它还将了解自身与NAS之间协商的PPP加密/压缩服务。
From the LNS point of view, it will note a PPP frame encapsulated in L2TP, which is itself encapsulated in an IP packet. This situation is identical to the compulsory tunneling case. If LNS retrieves the properties of the Security Association set up between itself and the client, it can be informed of the security services in place between them. Thus in the voluntary tunneling case, the client and the LNS have symmetric knowledge of the security services in place between them.
从LNS的角度来看，它将注意封装在L2TP中的PPP帧，其本身封装在IP分组中。这种情况与强制隧道工程案相同。如果LNS检索在其自身和客户端之间建立的安全关联的属性，则可以将它们之间的安全服务通知它。因此，在自愿隧道情况下，客户和LN对他们之间的安全服务具有对称的了解。
Since the LNS is capable of knowing whether confidentiality, authentication, integrity check or replay protection is in place between the client and itself, it is able to use this knowledge to modify its PPP ECP and CCP negotiation stance. If IPsec confidentiality is in place, the LNS can behave as though a "Require Encryption" directive had been fulfilled, not mandating use of PPP encryption or compression. Typically the LNS will not insist that PPP encryption/compression be turned off, instead leaving this decision to the client.
由于LNS能够知道客户机与自身之间是否存在保密、认证、完整性检查或重播保护，因此LNS能够利用这些知识修改其PPP ECP和CCP协商立场。如果IPsec保密性已到位，LNS的行为就好像已满足“要求加密”指令，而不是强制使用PPP加密或压缩。通常，LNS不会坚持关闭PPP加密/压缩，而是将此决定留给客户端。
Since the client has knowledge of the security services in place between itself and the LNS, it can act as though a "Require Encryption" directive had been fulfilled if IPsec ESP was already in place between itself and the LNS. Thus, it can request that PPP encryption and compression not be negotiated. If IP compression services cannot be negotiated, it will typically be desirable to turn off PPP compression if no stateless method is available, due to the undesirable effects of stateful PPP compression.
由于客户机了解其自身和LNS之间的安全服务，因此，如果IPsec ESP已在其自身和LNS之间就位，则它可以充当“需要加密”指令已得到满足的角色。因此，它可以请求不协商PPP加密和压缩。如果无法协商IP压缩服务，由于有状态PPP压缩的不良影响，如果没有可用的无状态方法，通常需要关闭PPP压缩。
Thus in the voluntary tunneling case the client and LNS will typically be able to avoid use of PPP encryption and compression, negotiating IPsec Confidentiality, Authentication, and Integrity protection services instead, as well as IP Compression, if available.
因此，在自愿隧道情况下，客户机和LN通常能够避免使用PPP加密和压缩，而是协商IPsec机密性、身份验证和完整性保护服务，以及IP压缩（如果可用）。
This may result in duplicate encryption if the client is communicating with an IPsec-capable end-station. In order to avoid duplicate encryption/compression, the client may negotiate two
如果客户端与支持IPsec的终端站通信，这可能会导致重复加密。为了避免重复加密/压缩，客户端可以协商两个
Security Associations with the LNS, one with ESP with null encryption, and one with confidentiality/compression. Packets going to an IPsec- capable end-station would run over the ESP with null encryption security association, and packets to a non-IPsec capable end-station would run over the other security association. Note that many IPsec implementations cannot support this without allowing L2TP packets on the same tunnel to be originated from multiple UDP ports. This requires modifications to the L2TP specification.
与LNS的安全关联，一个与ESP的空加密关联，另一个与机密性/压缩关联。发送到支持IPsec的终端站的数据包将通过具有空加密安全关联的ESP运行，而发送到不支持IPsec的终端站的数据包将通过其他安全关联运行。请注意，如果不允许同一隧道上的L2TP数据包来自多个UDP端口，许多IPsec实现就无法支持这一点。这需要修改L2TP规范。
Also note that the client may wish to put confidentiality services in place for non-tunneled packets traveling between itself and the NAS. This will protect the client against eavesdropping on the wire between itself and the NAS. As a result, it may wish to negotiate PPP encryption and compression with the NAS. As in compulsory tunneling, this will result in duplicate encryption and possibly compression unless PPP compression/encryption can be turned off on a per-packet basis.
还请注意，客户机可能希望为在其自身和NAS之间传输的非隧道数据包提供保密服务。这将防止客户端在其自身和NAS之间的线路上被窃听。因此，它可能希望与NAS协商PPP加密和压缩。与强制隧道一样，这将导致重复加密和可能的压缩，除非可以在每个数据包的基础上关闭PPP压缩/加密。
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[1] 汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议L2TP”，RFC 26611999年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[3] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[5] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[6] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[6] Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[7] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[8] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[8] 辛普森，W.，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[9] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[9] Rand，D.，“PPP压缩控制协议（CCP）”，RFC 1962，1996年6月。
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[10] Meyer，G.，“PPP加密控制协议（ECP）”，RFC 1968，1996年6月。
[11] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol (DESE)", RFC 1969, June 1996.
[11] Sklower，K.和G.Meyer，“PPP DES加密协议（DESE）”，RFC 1969，1996年6月。
[12] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[12] Sklower，K.和G.Meyer，“PPP DES加密协议，第2版（DESE bis）”，RFC 2419，1998年9月。
[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[13] Hummert，K.，“PPP三重DES加密协议（3DESE）”，RFC2420，1998年9月。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[14] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1998年11月。
[15] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996.
[15] 辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[16] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," RFC 2284, March 1998.
[16] Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[17] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
Acknowledgments
致谢
Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for useful discussions of this problem space.
感谢微软的古尔迪普·辛格·帕尔、大卫·艾特尔巴赫、彼得·福特和桑杰·阿南德、英特尔的约翰·理查森和思科的罗伯·亚当斯对这个问题空间进行了有益的讨论。
Authors' Addresses
作者地址
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
Baiju诉帕特尔英特尔公司案希尔斯博罗东北25大道2511号，或97124
Phone: +1 503 702 2303
EMail: baiju.v.patel@intel.com
Phone: +1 503 702 2303
EMail: baiju.v.patel@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 706-6605
EMail: bernarda@microsoft.com
Phone: +1 425 706-6605
EMail: bernarda@microsoft.com
William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052
William Dixon微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8729
EMail: wdixon@microsoft.com
Phone: +1 425 703 8729
EMail: wdixon@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004
格伦佐恩思科系统有限公司，地址：华盛顿贝尔维尤第108大道500号500室，邮编：98004
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road RTP, NC 27709
跳过展位思科系统7025 Kit Creek Road RTP，北卡罗来纳州27709
Phone: +1 919 392 6951
EMail: ebooth@cisco.com
Phone: +1 919 392 6951
EMail: ebooth@cisco.com
Appendix A: Example IPsec Filter sets for L2TP Tunnel Establishment
附录A：L2TP隧道建立的IPsec筛选器集示例
This section provides examples of IPsec filter sets for L2TP tunnel establishment. While example filter sets are for IPv4, similar examples could just as easily be constructed for IPv6.
本节提供用于L2TP隧道建立的IPsec筛选器集示例。虽然示例筛选器集适用于IPv4，但类似的示例也可以很容易地适用于IPv6。
This is the most simple of the cases since nothing changes during L2TP tunnel establishment. Since the initiator does not know whether the responder will change its port number, it still must be prepared for this case. In this example, the initiator will use an IPv4 address of 1.1.1.1 and the responder will use an IPv4 address of 2.2.2.1.
这是最简单的情况，因为L2TP隧道建立期间没有任何变化。由于启动器不知道响应程序是否会更改其端口号，因此它仍然必须为此情况做好准备。在此示例中，发起方将使用IPv4地址1.1.1.1，响应方将使用IPv4地址2.2.2.1。
The filters for this scenario are:
此场景的过滤器包括：
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
启动器筛选器：出站-1:从1.1.1.1到2.2.2.1，UDP，src 1701，dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
入站-1：从2.2.2.1到1.1.1，UDP，src 1701，dst 1701入站-2：从2.2.2.1到1.1.1，UDP，src任意端口，dst 1701
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
响应程序筛选器：Outbound-1:None，在IKE阶段2完成时动态注入
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
Inbound-1：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKE阶段2完成后，启动器和响应程序处的过滤器将：
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
启动器筛选器：出站-1:从1.1.1.1到2.2.2.1，UDP，src 1701，dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
入站-1：从2.2.2.1到1.1.1，UDP，src 1701，dst 1701入站-2：从2.2.2.1到1.1.1，UDP，src任意端口，dst 1701
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
响应程序筛选器：出站-1：从2.2.2.1到1.1.1.1，UDP，src 1701，dst 1701
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701 Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
入站-1：从1.1.1.1到2.2.2.1，UDP，src 1701，dst 1701入站-2：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
A.2 Gateway to Gateway Scenario where Initiator and Responder use dynamic ports
A.2发起方和响应方使用动态端口的网关到网关场景
In this scenario either side is allowed to initiate the tunnel. Since dynamic ports will be used, an extra phase 2 negotiation must occur to protect the SCCRP sent from the responder to the initiator. Other than the additional phase 2 setup, the only other difference is that L2TP on the responder must inject an additional filter into the IPsec database once the new port number is chosen.
在这种情况下，允许任何一方启动隧道。由于将使用动态端口，因此必须进行额外的阶段2协商，以保护从响应程序发送到启动器的SCCRP。除了附加的第2阶段设置之外，唯一的区别是，一旦选择了新的端口号，响应程序上的L2TP必须向IPsec数据库中注入附加筛选器。
This example also shows the additional filter needed by the initiator which allows either side to start the tunnel. In either the dial-out or the gateway to gateway scenario this additional filter is required.
此示例还显示了启动器所需的附加筛选器，该筛选器允许任何一方启动隧道。在拨出或网关到网关方案中，需要此附加筛选器。
For this example, assume the dynamic port given to the initiator is 5000 and his IP address is 1.1.1.1. The responder will use an IP address of 2.2.2.1 and a port number of 6000.
对于本例，假设提供给启动器的动态端口为5000，其IP地址为1.1.1.1。响应者将使用2.2.2.1的IP地址和6000的端口号。
The filters for this scenario are:
此场景的过滤器包括：
In this case both peers must be able to accept phase 2 negotiations to from L2TP peers. My-IPAddr is defined as whatever IP address the device is willing to accept L2TP negotiations on.
在这种情况下，两个对等方必须能够接受L2TP对等方的第2阶段协商。我的IPAddr定义为设备愿意接受L2TP协商的任何IP地址。
Responder Filters present at both peers: Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701
两个对等点上都存在响应程序筛选器：Inbound-1:从任意地址到我的IPAddr、UDP、src任意端口、dst 1701
Note: The source IP in the inbound-1 filter above for gateway to gateway tunnels can be IP specific, such as 1.1.1.1, not necessarily Any-Addr.
注意：以上网关到网关隧道的入站-1筛选器中的源IP可以是特定于IP的，例如1.1.1.1，不一定是任何Addr。
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
启动器筛选器：出站-1:从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000 Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
Inbound-1：从2.2.2.1到1.1.1，UDP，src 1701，dst 5000 Inbound-2：从2.2.2.1到1.1.1.1，UDP，src任意端口，dst 5000 Inbound-3：从任意地址到1.1.1.1，UDP，src任意端口，dst 1701
Responder Filters: Outbound-1: None, dynamically injected when IKE Phase 2 completes
响应程序筛选器：Outbound-1:None，在IKE阶段2完成时动态注入
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
Inbound-1：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
After IKE Phase 2 completes the filters at the initiator and responder will be:
IKE阶段2完成后，启动器和响应程序处的过滤器将：
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
启动器筛选器：出站-1:从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
入站-1：从2.2.2.1到1.1.1，UDP，src 1701，dst 5000入站-2：从2.2.2.1到1.1.1，UDP，src任意端口，dst 5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
Inbound-3：从任意地址到1.1.1.1，UDP，src任意端口，dst 1701
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
响应程序筛选器：出站-1：从2.2.2.1到1.1.1.1，UDP，src 1701，dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701 Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
入站-1：从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701入站-2：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
At this point the responder knows which port number it is going to use. New filters should be injected by L2TP to reflect this new port assignment.
此时，响应程序知道将使用哪个端口号。L2TP应该注入新的过滤器以反映这种新的端口分配。
The new filter set at the responder is:
响应程序上的新过滤器集为：
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000 Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
响应程序筛选器：出站-1:从2.2.2.1到1.1.1，UDP，src 6000，dst 5000出站-2:从2.2.2.1到1.1.1，UDP，src 1701，dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000 Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701 Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
入站-1：从1.1.1.1到2.2.2.1，UDP，src 5000，dst 6000入站-2：从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701入站-3：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
The second phase 2 will start once L2TP sends the SCCRP. Once the phase 2 negotiations complete, the new filter set at the initiator and the responder will be:
L2TP发送SCCRP后，第二阶段2将启动。一旦阶段2协商完成，在发起方和响应方设置的新过滤器将：
Initiator Filters: Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000 Outbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
启动器筛选器：出站-1:从1.1.1.1到2.2.2.1，UDP，src 5000，dst 6000出站-2:从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000 Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000 Inbound-3: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
入站-1：从2.2.2.1到1.1.1，UDP，src 6000，dst 5000入站-2：从2.2.2.1到1.1.1，UDP，src 1701，dst 5000入站-3：从2.2.2.1到1.1.1，UDP，src任意端口，dst 1701
Responder Filters: Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000 Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
响应程序筛选器：出站-1:从2.2.2.1到1.1.1，UDP，src 6000，dst 5000出站-2:从2.2.2.1到1.1.1，UDP，src 1701，dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000 Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701 Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701
入站-1：从1.1.1.1到2.2.2.1，UDP，src 5000，dst 6000入站-2：从1.1.1.1到2.2.2.1，UDP，src 5000，dst 1701入站-3：从任意地址到2.2.2.1，UDP，src任意端口，dst 1701
Once the L2TP tunnel has been successfully established, the original phase 2 may be deleted. This allows the Inbound-2 and Outbound-2 filter statements to be removed as well.
成功建立L2TP隧道后，可删除原第2阶段。这也允许删除入站-2和出站-2筛选器语句。
Intellectual Property Statement
知识产权声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。