Network Working Group W. Palter
Request for Comments: 3437 zev.net
Category: Standards Track W. Townsley
Cisco Systems
December 2002
Network Working Group W. Palter
Request for Comments: 3437 zev.net
Category: Standards Track W. Townsley
Cisco Systems
December 2002
Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
PPP链路控制协议协商的第二层隧道协议扩展
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines extensions to the Layer Two Tunneling Protocol (L2TP) for enhanced support of link-specific Point to Point Protocol (PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options between L2TP endpoints in advance of PPP LCP negotiation at the far end of an L2TP tunnel, as well as a mechanism for communicating the negotiated LCP options back to where the native PPP link resides.
本文档定义了对第二层隧道协议（L2TP）的扩展，以增强对链路特定点对点协议（PPP）选项的支持。PPP端点通常可以直接访问连接它们的公共物理介质，因此对正在使用的介质有详细的了解。当使用L2TP时，两个PPP对等点不再通过相同的物理介质直接连接。相反，L2TP通过在分组交换网络（如IP）上隧道PPP帧，在部分或全部PPP连接上插入虚拟连接。在某些情况下，L2TP端点可能需要在无法访问正确参与LCP协商所需的所有媒体信息的位置协商PPP链路控制协议（LCP）选项。本文档提供了一种机制，用于在L2TP隧道远端的PPP LCP协商之前，在L2TP端点之间传送所需的LCP选项，以及将协商的LCP选项传送回本机PPP链路所在位置的机制。
Table of Contents
目录
1. Introduction............................................... 2
1.1 Specification of Requirements........................... 3
2. LCP Options From LAC to LNS................................ 3
2.1 LCP Want Options (iccn, occn)........................... 4
2.2 LCP Allow Options (iccn, occn).......................... 6
2.3 LCP Options From LNS to LAC............................. 7
3. Security Considerations.................................... 8
4. IANA Considerations........................................ 8
5. Normative References....................................... 8
6. Author's Addresses......................................... 9
7. Full Copyright Statement................................... 10
1. Introduction............................................... 2
1.1 Specification of Requirements........................... 3
2. LCP Options From LAC to LNS................................ 3
2.1 LCP Want Options (iccn, occn)........................... 4
2.2 LCP Allow Options (iccn, occn).......................... 6
2.3 LCP Options From LNS to LAC............................. 7
3. Security Considerations.................................... 8
4. IANA Considerations........................................ 8
5. Normative References....................................... 8
6. Author's Addresses......................................... 9
7. Full Copyright Statement................................... 10
L2TP [RFC2661] provides a very limited amount of guidance to the LNS as to what type of interface a tunneled PPP session arrived on at an LAC. Such information is limited to whether the interface was "synchronous" or "asynchronous", "digital" or "analog." These indications provide some guidance when negotiating PPP LCP at the LNS, but they are not as robust as they could be.
L2TP[RFC2661]为LNS提供了非常有限的指导，说明隧道PPP会话到达LAC的接口类型。此类信息仅限于接口是“同步”还是“异步”、“数字”还是“模拟”。这些指示在LNS协商PPP LCP时提供了一些指导，但它们并不像可能的那样稳健。
This document defines a more robust way to inform the LAC of LCP negotiated options, and provides guidance to the LNS on the limits and values that the LAC requires during LCP negotiation. Deep knowledge of PPP [RFC1661] and L2TP [RFC2661] are expected for the remainder of this document.
本文件定义了一种更为稳健的方式，向LAC告知LCP协商选项，并就LCP协商期间LAC要求的限制和值向LNS提供指导。在本文件的其余部分，我们将深入了解PPP[RFC1661]和L2TP[RFC2661]。
L2TP Proxy LCP allows options to be negotiated where the native PPP link resides, thus circumventing issues with ACCM, Alternate FCS, and other LCP Options that the LNS would not necessarily know how to properly negotiate without access to the physical media for the native PPP connection, interface type, or configuration. However, use of Proxy LCP introduces other problems as well as there are options within LCP PPP negotiation which should be set or adjusted by the LNS, such as the PPP Authentication Type and MRU. Finally, the PPP Client may reinitiate LCP negotiation at any time, and unless the LAC is sniffing every PPP data packet it forwards, it would not be aware that this is even occurring.
L2TP代理LCP允许在本机PPP链路所在的位置协商选项，从而避免了与ACCM、备用FCS和其他LCP选项有关的问题，这些选项是LNS不一定知道如何在不访问本机PPP连接、接口类型或配置的物理介质的情况下正确协商的。然而，使用代理LCP会带来其他问题，并且LCP PPP协商中有一些选项应由LNS设置或调整，例如PPP认证类型和MRU。最后，PPP客户端可以随时重新初始化LCP协商，并且除非LAC嗅探它转发的每个PPP数据包，否则它甚至不会意识到这正在发生。
LCP options may be classified into roughly three different categories with respect to their affect on L2TP; (1) options which affect framing in a way that the LAC may need to know about or handle specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are mostly transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the
LCP选项可根据其对L2TP的影响大致分为三类；（1） 以LAC可能需要了解或专门处理的方式影响帧的选项（例如，ALT-FCS、ACCM、MRU），（2）对LAC最透明的选项（例如，AUH-TYPE），以及（3）LAC可能需要的选项
LAC may wish to influence because they are dependent on the media type (ACFC, PFC). We are most concerned with options that fall into category (1) and (3).
LAC可能希望施加影响，因为它们取决于介质类型（ACFC、PFC）。我们最关心的是属于第（1）类和第（3）类的选项。
This document defines new AVPs to allow the LAC and the LNS to communicate complete LCP information in order to react accordingly. LCP option information is structured in the same way as the Proxy LCP AVPs are in [RFC2661]. This essentially involves encapsulation of a PPP LCP Configure-Request or Configure-Ack packet within an L2TP AVP.
本文件定义了新的AVP，以允许LAC和LN通信完整的LCP信息，以便做出相应的反应。LCP选项信息的结构与[RFC2661]中代理LCP AVP的结构相同。这本质上涉及在L2TP AVP中封装PPP LCP配置请求或配置Ack数据包。
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]中所述进行解释。
The LAC may utilize the following AVPs within an ICCN or OCCN message in order to influence the LNS to negotiate LCP in a specific manner. If these AVPs are supported by the LNS, they should override any suggestions for LCP options implied by the Bearer Type or Framing Type AVPs.
LAC可在ICCN或OCCN消息内利用以下AVP，以影响LN以特定方式协商LCP。如果LNS支持这些AVP，则它们应覆盖承载类型或帧类型AVP暗示的LCP选项建议。
These AVPs may coexist with the Proxy LCP and Proxy Authentication AVPs (Proxy AVPs) defined in the base L2TP specification. If Proxy AVPs are received, the LNS may choose to accept these parameters, or renegotiate LCP with the options suggested by the AVPs defined in this document. If the LAC wishes to force negotiation of LCP by the LNS, it should simply omit all Proxy AVPs during call initialization.
这些AVP可以与基本L2TP规范中定义的代理LCP和代理认证AVP（代理AVP）共存。如果收到代理AVP，LNS可选择接受这些参数，或使用本文件中定义的AVP建议的选项重新协商LCP。如果LAC希望强制LNS协商LCP，则应在呼叫初始化期间忽略所有代理AVP。
By default, the AVPs defined in this document are not mandatory (M-bit is set to zero). However, if an implementation needs to strongly enforce adherence to the options defined within the AVPs, it MAY set the M-bit to 1, thus forcing the peer to discontinue the session if it does not support this AVP. This is NOT recommended unless it is known that the result of operating without these extensions is completely unacceptable.
默认情况下，本文档中定义的AVP不是强制性的（M位设置为零）。然而，如果一个实现需要严格遵守AVP中定义的选项，它可以将M位设置为1，从而迫使对等方在不支持该AVP的情况下中断会话。除非知道在没有这些扩展的情况下运行的结果是完全不可接受的，否则不建议这样做。
If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST be prepared to accept the AVPs as defined in section 2.3.
如果将第2.1节和第2.2节中的AVP发送给LNS，LAC必须准备接受第2.3节中定义的AVP。
The LCP Allow Options AVP, Attribute Type 49, contains a list of options that the LAC wants to be negotiated by the LNS.
LCP Allow Options AVP属性类型49包含LAC希望由LNS协商的选项列表。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Req ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Req (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Req ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Req (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
供应商ID是0的IETF供应商ID。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
该AVP可能被隐藏（H位可能为0或1）。
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
此AVP的M位可设置为0或1。如果此AVP的发送方不希望与不理解此L2TP扩展的对等方建立连接，则应将M位设置为1，否则必须将其设置为0。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
此AVP的长度（隐藏前）为6加上LCP配置请求的长度。
The AVP SHOULD be present in the following messages: ICCN, OCCN
AVP应出现在以下信息中：ICCN、OCCN
The LCP Configure-Req Value for this AVP is identical to the information field of a PPP LCP Configure-Req Packet (much like a Proxy LCP AVP in [RFC2661]). It is sent from the LAC to the LNS, and is intended to guide PPP LCP negotiations at an LNS. In some cases, each individual PPP LCP option carried in this AVP maps to a desired value (e.g., MRU) and in some cases it maps to a specific option that is desired to be enabled (e.g., ACFC). The LNS should use these suggestions when building its initial Configure-Request.
此AVP的LCP Configure Req值与PPP LCP Configure Req数据包的信息字段相同（与[RFC2661]中的代理LCP AVP非常相似）。它从拉丁美洲和加勒比海地区发送至LNS，旨在指导LNS的PPP LCP谈判。在某些情况下，本AVP中包含的每个单独PPP LCP选项映射到所需值（如MRU），在某些情况下，映射到所需启用的特定选项（如ACFC）。LNS在构建其初始配置请求时应使用这些建议。
The following chart defines some of the more common LCP options that may be included in this AVP with guidance on how to handle them at the LAC and LNS. This table is provided for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available.
下表定义了本AVP中可能包含的一些更常见的LCP选项，以及如何在LAC和LN处理这些选项的指导。本表提供了一些更常见或有问题的LCP选项。它并不打算详尽地描述所有可用的LCP选项。
LCP Want Option LAC Action LNS Action
LCP需要选项LAC行动LNS行动
MRU LAC provides a LNS SHOULD begin LCP negotiation maximum value with this value. However, it MAY reduce MRU if necessary.
MRU LAC提供了一个LNS应开始LCP协商的最大值。但是，如有必要，它可能会减少MRU。
ACCM LAC Provides a mask LNS SHOULD begin LCP negotiation with this value. LNS may add bit(s) while negotiating.
ACCM LAC提供了一个掩码，LNS应使用该值开始LCP协商。LNS可在协商时添加位。
PFC LAC provides PFC LNS SHOULD begin LCP on the link type negotiation if it is desired with the link type this value. (e.g. AHDLC)
PFC LAC提供PFC LN应在链路类型协商上开始LCP，如果需要此值的链路类型。（例如AHDLC）
ACFC LAC provides ACCOMP LNS SHOULD begin LCP if it is desired on negotiation with this the link type value. (e.g. AHDLC)
ACFC LAC提供ACCOMP LNS，如果需要与该链路类型值协商，则应开始LCP。（例如AHDLC）
FCS-ALT LAC indicates required LNS SHOULD begin values for the link negotiation with this type value. Note that this value is of no consequence to the LNS as FCS is stripped at the LAC, however some PPP media types require this option.
FCS-ALT LAC指出，所需的LN应开始使用该类型值进行链路协商。请注意，该值对LNS没有影响，因为FCS在LAC剥离，但某些PPP媒体类型需要该选项。
The LCP Allow Options AVP, Attribute Type 50 contains a list of options that the LAC will allow to be negotiated by the LNS.
LCP Allow Options AVP属性类型50包含LAC允许LNS协商的选项列表。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Ack ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Ack (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | LCP Configure-Ack ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... LCP Configure-Ack (continued) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
供应商ID是0的IETF供应商ID。
This AVP MAY be hidden (the H bit MAY be 0 or 1).
该AVP可能被隐藏（H位可能为0或1）。
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
此AVP的M位可设置为0或1。如果此AVP的发送方不希望与不理解此L2TP扩展的对等方建立连接，则应将M位设置为1，否则必须将其设置为0。
The Length (before hiding) of this AVP is 6 plus the length of the LCP Configure Request.
此AVP的长度（隐藏前）为6加上LCP配置请求的长度。
The AVP MAY be present in the following messages: ICCN, OCCN
AVP可能出现在以下消息中：ICCN、OCCN
The LCP Configure-Ack Value for this AVP is identical to the information field of a PPP LCP Configure-Req Packet (much like a Proxy LCP AVP in [RFC2661]). It is sent from the LAC to the LNS, and is intended to guide PPP LCP negotiations at an LNS. In some cases, each individual PPP LCP option carried in this AVP maps to a maximum value (e.g., MRU), while in others it maps to an option that is permitted by the LAC (e.g., ACFC). If the option is not included here, it can be assumed by the LNS that the LAC does not understand how to perform that particular option at the link layer (and would thus Configure-Reject that option). Information in this AVP should be utilized when building PPP Configure-Ack, Configure-Reject and Configure-Nak messages.
此AVP的LCP Configure Ack值与PPP LCP Configure Req数据包的信息字段相同（非常类似于[RFC2661]中的代理LCP AVP）。它从拉丁美洲和加勒比海地区发送至LNS，旨在指导LNS的PPP LCP谈判。在某些情况下，本AVP中的每个单独PPP LCP选项映射到最大值（如MRU），而在其他情况下，它映射到LAC允许的选项（如ACFC）。如果此处未包括该选项，则LNS可以假设LAC不了解如何在链路层执行该特定选项（因此将配置拒绝该选项）。在构建PPP配置Ack、配置拒绝和配置Nak消息时，应使用此AVP中的信息。
The following chart defines some of the more common LCP options that may be included in this AVP with guidance on how to handle them at the LAC and LNS. This table is provided for illustration purposes for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available.
下表定义了本AVP中可能包含的一些更常见的LCP选项，以及如何在LAC和LN处理这些选项的指导。本表用于说明一些更常见或有问题的LCP选项。它并不打算详尽地描述所有可用的LCP选项。
LCP Allow Option LAC Action LNS Action
LCP允许选项LAC操作LNS操作
MRU LAC provides a LNS may accept reduction maximum value MRU as requested.
MRU LAC提供LNS可根据要求接受最大值MRU的减少。
ACCM LAC Provides a mask LNS may accept bit(s) defined here. Note that if ACCM is missing it is assumed that it is not applicable to the link type.
ACCM LAC提供掩码LNS可接受此处定义的位。请注意，如果缺少ACCM，则假定它不适用于链接类型。
PFC LAC provides PFC LNS may accept PFC. if it is allowed on the link type (e.g. AHDLC)
PFC LAC提供PFC LN可接受PFC。如果链路类型（例如AHDLC）上允许PFC
ACFC LAC provides ACFC LNS may accept ACFC. if it is allowed on the link type (e.g. AHDLC)
ACFC LAC提供ACFC LN可接受ACFC。如果允许在链路类型上使用（例如AHDLC）
FCS-ALT LAC indicates valid Negotiation this option values for the link is of no consequence to type the LNS as the FCS is stripped at the LAC. However, the LNS SHOULD only accept FCS-ALT types listed here (more than one value may be present).
FCS-ALT LAC表示有效协商链路的该选项值对LNS类型没有影响，因为FCS在LAC剥离。但是，LN应仅接受此处列出的FCS-ALT类型（可能存在多个值）。
In order to communicate negotiated LCP parameters from the LNS to the LAC, the format of two existing messages in [RFC2661] are used. These are:
为了将协商的LCP参数从LN传送到LAC，使用[RFC2661]中两条现有消息的格式。这些是：
Last Sent LCP Confreq (IETF L2TP Attribute 27) Last Received LCP Confreq (IETF L2TP Attribute 28)
上次发送的LCP Confreq（IETF L2TP属性27）上次接收的LCP Confreq（IETF L2TP属性28）
These AVPs are sent from the LAC to the LNS to support Proxy LCP negotiation. In order to report negotiated LCP parameters from the LNS to the LAC, two messages of precisely the same format are defined:
这些AVP从LAC发送到LNS，以支持代理LCP协商。为了从LN向LAC报告协商的LCP参数，定义了两条格式完全相同的消息：
LNS Last Sent LCP Confreq (IETF L2TP Attribute 51) LNS Last Received LCP Confreq (IETF L2TP Attribute 52)
LNS上次发送的LCP Confreq（IETF L2TP属性51）LNS上次接收的LCP Confreq（IETF L2TP属性52）
When LCP negotiation is completed by the LNS, a Set-Link-Info control message MUST be sent with these AVPs contained within. These AVPs MUST contain the last sent and last received (with respect to the LNS) LCP packets.
当LNS完成LCP协商时，必须发送一条Set Link Info控制消息，其中包含这些AVP。这些AVP必须包含最后发送和最后接收（关于LNS）的LCP数据包。
Rather than simply using the old Attribute values in the SLI Message, new AVP Attribute types are defined for these messages due to the fact that some existing L2TP implementations might check for what could seem like misplacement of known AVP types and generate a false error condition.
不是简单地使用SLI消息中的旧属性值，而是为这些消息定义新的AVP属性类型，因为一些现有L2TP实现可能会检查已知AVP类型的错误位置，并生成错误条件。
There are no known additional significant threats incurred by the mechanisms described in this document.
本文件中所述的机制不存在已知的其他重大威胁。
This document defines additional L2TP AVPs that identify link characteristics and interface information of a tunneled PPP link. If these values were snooped, a rogue individual may have access to more information about a given network or topology. Given that these same values may be negotiated over the tunneled link in PPP LCP packets anyway, this is no more information than is potentially transmitted today, it is just in a different form.
本文件定义了额外的L2TP AVP，用于识别隧道PPP链路的链路特性和接口信息。如果这些值被窥探，流氓个人可能可以访问有关给定网络或拓扑的更多信息。考虑到这些相同的值可能会在PPP LCP数据包的隧道链路上协商，这与今天可能传输的信息一样，只是形式不同而已。
This document requires four new L2TP "AVP Attribute" numbers to be assigned by IANA.
本文件要求IANA分配四个新的L2TP“AVP属性”编号。
49, Section 2.1, LCP Want Options 50, Section 2.2, LCP Allow Options 51, Section 2.3, LNS Last Sent LCP Confreq 52, Section 2.3, LNS Last Received LCP Confreq
49，第2.1节，LCP需要选项50，第2.2节，LCP允许选项51，第2.3节，LNS上次发送的LCP Confreq 52，第2.3节，LNS上次接收的LCP Confreq
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC 2661]Townsley，W.，Valencia，A.，Rubens，A.，Pall，G.，Zorn，G.和B.Palter，“第二层隧道-第二层隧道协议（L2TP）”，RFC 26611999年8月。
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
美国北卡罗来纳州三角研究公园14987号吉特克里克路邮政信箱7025号马克·汤斯利思科系统公司
EMail: mark@townsley.net
EMail: mark@townsley.net
Bill Palter EMail: palter.ietf@zev.net
比尔·帕特电子邮件：帕特。ietf@zev.net
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。