Network Working Group W. Townsley
Request for Comments: 2661 A. Valencia
Category: Standards Track cisco Systems
A. Rubens
Ascend Communications
G. Pall
G. Zorn
Microsoft Corporation
B. Palter
Redback Networks
August 1999
Network Working Group W. Townsley
Request for Comments: 2661 A. Valencia
Category: Standards Track cisco Systems
A. Rubens
Ascend Communications
G. Pall
G. Zorn
Microsoft Corporation
B. Palter
Redback Networks
August 1999
Layer Two Tunneling Protocol "L2TP"
第二层隧道协议“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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes the Layer Two Tunneling Protocol (L2TP). STD 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.
本文档描述了第二层隧道协议（L2TP）。STD 51，RFC 1661规定了通过PPP的多协议访问[RFC1661]。L2TP以对最终用户和应用程序尽可能透明的方式促进PPP数据包在中间网络上的隧道传输。
Table of Contents
目录
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2.0 Topology.............................................. 8
3.0 Protocol Overview..................................... 9
3.1 L2TP Header Format.................................... 9
3.2 Control Message Types................................. 11
4.0 Control Message Attribute Value Pairs................. 12
4.1 AVP Format............................................ 13
4.2 Mandatory AVPs........................................ 14
4.3 Hiding of AVP Attribute Values........................ 14
1.0 Introduction.......................................... 3
1.1 Specification of Requirements......................... 4
1.2 Terminology........................................... 4
2.0 Topology.............................................. 8
3.0 Protocol Overview..................................... 9
3.1 L2TP Header Format.................................... 9
3.2 Control Message Types................................. 11
4.0 Control Message Attribute Value Pairs................. 12
4.1 AVP Format............................................ 13
4.2 Mandatory AVPs........................................ 14
4.3 Hiding of AVP Attribute Values........................ 14
4.4 AVP Summary........................................... 17
4.4.1 AVPs Applicable To All Control Messages.......... 17
4.4.2 Result and Error Codes........................... 18
4.4.3 Control Connection Management AVPs............... 20
4.4.4 Call Management AVPs............................. 27
4.4.5 Proxy LCP and Authentication AVPs................ 34
4.4.6 Call Status AVPs................................. 39
5.0 Protocol Operation.................................... 41
5.1 Control Connection Establishment...................... 41
5.1.1 Tunnel Authentication............................ 42
5.2 Session Establishment................................. 42
5.2.1 Incoming Call Establishment...................... 42
5.2.2 Outgoing Call Establishment...................... 43
5.3 Forwarding PPP Frames................................. 43
5.4 Using Sequence Numbers on the Data Channel............ 44
5.5 Keepalive (Hello)..................................... 44
5.6 Session Teardown...................................... 45
5.7 Control Connection Teardown........................... 45
5.8 Reliable Delivery of Control Messages................. 46
6.0 Control Connection Protocol Specification............. 48
6.1 Start-Control-Connection-Request (SCCRQ).............. 48
6.2 Start-Control-Connection-Reply (SCCRP)................ 48
6.3 Start-Control-Connection-Connected (SCCCN)............ 49
6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
6.5 Hello (HELLO)......................................... 49
6.6 Incoming-Call-Request (ICRQ).......................... 50
6.7 Incoming-Call-Reply (ICRP)............................ 51
6.8 Incoming-Call-Connected (ICCN)........................ 51
6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.10 Outgoing-Call-Reply (OCRP)........................... 53
6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.12 Call-Disconnect-Notify (CDN)......................... 53
6.13 WAN-Error-Notify (WEN)............................... 54
6.14 Set-Link-Info (SLI).................................. 54
7.0 Control Connection State Machines..................... 54
7.1 Control Connection Protocol Operation................. 55
7.2 Control Connection States............................. 56
7.2.1 Control Connection Establishment................. 56
7.3 Timing considerations................................. 58
7.4 Incoming calls........................................ 58
7.4.1 LAC Incoming Call States......................... 60
7.4.2 LNS Incoming Call States......................... 62
7.5 Outgoing calls........................................ 63
7.5.1 LAC Outgoing Call States......................... 64
7.5.2 LNS Outgoing Call States......................... 66
7.6 Tunnel Disconnection.................................. 67
8.0 L2TP Over Specific Media.............................. 67
8.1 L2TP over UDP/IP...................................... 68
4.4 AVP Summary........................................... 17
4.4.1 AVPs Applicable To All Control Messages.......... 17
4.4.2 Result and Error Codes........................... 18
4.4.3 Control Connection Management AVPs............... 20
4.4.4 Call Management AVPs............................. 27
4.4.5 Proxy LCP and Authentication AVPs................ 34
4.4.6 Call Status AVPs................................. 39
5.0 Protocol Operation.................................... 41
5.1 Control Connection Establishment...................... 41
5.1.1 Tunnel Authentication............................ 42
5.2 Session Establishment................................. 42
5.2.1 Incoming Call Establishment...................... 42
5.2.2 Outgoing Call Establishment...................... 43
5.3 Forwarding PPP Frames................................. 43
5.4 Using Sequence Numbers on the Data Channel............ 44
5.5 Keepalive (Hello)..................................... 44
5.6 Session Teardown...................................... 45
5.7 Control Connection Teardown........................... 45
5.8 Reliable Delivery of Control Messages................. 46
6.0 Control Connection Protocol Specification............. 48
6.1 Start-Control-Connection-Request (SCCRQ).............. 48
6.2 Start-Control-Connection-Reply (SCCRP)................ 48
6.3 Start-Control-Connection-Connected (SCCCN)............ 49
6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
6.5 Hello (HELLO)......................................... 49
6.6 Incoming-Call-Request (ICRQ).......................... 50
6.7 Incoming-Call-Reply (ICRP)............................ 51
6.8 Incoming-Call-Connected (ICCN)........................ 51
6.9 Outgoing-Call-Request (OCRQ).......................... 52
6.10 Outgoing-Call-Reply (OCRP)........................... 53
6.11 Outgoing-Call-Connected (OCCN)....................... 53
6.12 Call-Disconnect-Notify (CDN)......................... 53
6.13 WAN-Error-Notify (WEN)............................... 54
6.14 Set-Link-Info (SLI).................................. 54
7.0 Control Connection State Machines..................... 54
7.1 Control Connection Protocol Operation................. 55
7.2 Control Connection States............................. 56
7.2.1 Control Connection Establishment................. 56
7.3 Timing considerations................................. 58
7.4 Incoming calls........................................ 58
7.4.1 LAC Incoming Call States......................... 60
7.4.2 LNS Incoming Call States......................... 62
7.5 Outgoing calls........................................ 63
7.5.1 LAC Outgoing Call States......................... 64
7.5.2 LNS Outgoing Call States......................... 66
7.6 Tunnel Disconnection.................................. 67
8.0 L2TP Over Specific Media.............................. 67
8.1 L2TP over UDP/IP...................................... 68
8.2 IP.................................................... 69
9.0 Security Considerations............................... 69
9.1 Tunnel Endpoint Security.............................. 70
9.2 Packet Level Security................................. 70
9.3 End to End Security................................... 70
9.4 L2TP and IPsec........................................ 71
9.5 Proxy PPP Authentication.............................. 71
10.0 IANA Considerations.................................. 71
10.1 AVP Attributes....................................... 71
10.2 Message Type AVP Values.............................. 72
10.3 Result Code AVP Values............................... 72
10.3.1 Result Code Field Values........................ 72
10.3.2 Error Code Field Values......................... 72
10.4 Framing Capabilities & Bearer Capabilities........... 72
10.5 Proxy Authen Type AVP Values......................... 72
10.6 AVP Header Bits...................................... 73
11.0 References........................................... 73
12.0 Acknowledgments...................................... 74
13.0 Authors' Addresses................................... 75
Appendix A: Control Channel Slow Start and Congestion
Avoidance..................................... 76
Appendix B: Control Message Examples...................... 77
Appendix C: Intellectual Property Notice.................. 79
Full Copyright Statement.................................. 80
8.2 IP.................................................... 69
9.0 Security Considerations............................... 69
9.1 Tunnel Endpoint Security.............................. 70
9.2 Packet Level Security................................. 70
9.3 End to End Security................................... 70
9.4 L2TP and IPsec........................................ 71
9.5 Proxy PPP Authentication.............................. 71
10.0 IANA Considerations.................................. 71
10.1 AVP Attributes....................................... 71
10.2 Message Type AVP Values.............................. 72
10.3 Result Code AVP Values............................... 72
10.3.1 Result Code Field Values........................ 72
10.3.2 Error Code Field Values......................... 72
10.4 Framing Capabilities & Bearer Capabilities........... 72
10.5 Proxy Authen Type AVP Values......................... 72
10.6 AVP Header Bits...................................... 73
11.0 References........................................... 73
12.0 Acknowledgments...................................... 74
13.0 Authors' Addresses................................... 75
Appendix A: Control Channel Slow Start and Congestion
Avoidance..................................... 76
Appendix B: Control Message Examples...................... 77
Appendix C: Intellectual Property Notice.................. 79
Full Copyright Statement.................................. 80
PPP [RFC1661] defines an encapsulation mechanism for transporting multiprotocol packets across layer 2 (L2) point-to-point links. Typically, a user obtains a L2 connection to a Network Access Server (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN, ADSL, etc.) and then runs PPP over that connection. In such a configuration, the L2 termination point and PPP session endpoint reside on the same physical device (i.e., the NAS).
PPP[RFC1661]定义了一种封装机制，用于跨第2层（L2）点到点链路传输多协议数据包。通常，用户使用多种技术（例如，拨号POTS、ISDN、ADSL等）之一获得到网络接入服务器（NAS）的L2连接，然后通过该连接运行PPP。在这种配置中，二级终止点和PPP会话端点位于同一物理设备（即NAS）上。
L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched network. With L2TP, a user has an L2 connection to an access concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the NAS. This allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit.
L2TP通过允许L2和PPP端点驻留在由分组交换网络互连的不同设备上，扩展了PPP模型。使用L2TP，用户与接入集中器（例如，调制解调器银行、ADSL DSLAM等）建立L2连接，然后集中器通过隧道将各个PPP帧传输到NAS。这使得PPP数据包的实际处理与L2电路的终端分离。
One obvious benefit of such a separation is that instead of requiring the L2 connection terminate at the NAS (which may require a long-distance toll charge), the connection may terminate at a (local) circuit concentrator, which then extends the logical PPP session over
这种分离的一个明显好处是，不需要L2连接在NAS处终止（这可能需要长途长途收费），连接可以在（本地）电路集中器处终止，然后该集中器将逻辑PPP会话扩展到NAS上
a shared infrastructure such as frame relay circuit or the Internet. From the user's perspective, there is no functional difference between having the L2 circuit terminate in a NAS directly or using L2TP.
共享基础设施，如帧中继电路或互联网。从用户的角度来看，让L2电路直接在NAS中终止与使用L2TP之间没有功能上的区别。
L2TP may also solve the multilink hunt-group splitting problem. Multilink PPP [RFC1990] requires that all channels composing a multilink bundle be grouped at a single Network Access Server (NAS). Due to its ability to project a PPP session to a location other than the point at which it was physically received, L2TP can be used to make all channels terminate at a single NAS. This allows multilink operation even when the calls are spread across distinct physical NASs.
L2TP还可以解决多链路搜索组分裂问题。多链路PPP[RFC1990]要求组成多链路捆绑包的所有信道在单个网络访问服务器（NAS）上分组。由于L2TP能够将PPP会话投影到物理接收点以外的位置，因此可以使用L2TP使所有通道在单个NAS上终止。这允许多链路操作，即使调用分布在不同的物理NAS上。
This document defines the necessary control protocol for on-demand creation of tunnels between two nodes and the accompanying encapsulation for multiplexing multiple, tunneled PPP sessions.
本文件定义了在两个节点之间按需创建隧道所需的必要控制协议，以及用于多路复用多个隧道PPP会话的随附封装。
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]中所述进行解释。
Analog Channel
模拟通道
A circuit-switched communication path which is intended to carry 3.1 kHz audio in each direction.
一种电路交换通信路径，用于在每个方向上传输3.1 kHz音频。
Attribute Value Pair (AVP)
属性值对（AVP）
The variable length concatenation of a unique Attribute (represented by an integer) and a Value containing the actual value identified by the attribute. Multiple AVPs make up Control Messages which are used in the establishment, maintenance, and teardown of tunnels.
唯一属性（由整数表示）和包含该属性标识的实际值的值的可变长度串联。多个AVP组成控制消息，用于隧道的建立、维护和拆除。
Call
呼叫
A connection (or attempted connection) between a Remote System and LAC. For example, a telephone call through the PSTN. A Call (Incoming or Outgoing) which is successfully established between a Remote System and LAC results in a corresponding L2TP Session within a previously established Tunnel between the LAC and LNS. (See also: Session, Incoming Call, Outgoing Call).
远程系统和LAC之间的连接（或尝试的连接）。例如，通过PSTN的电话呼叫。在远程系统和LAC之间成功建立的呼叫（传入或传出）会导致在LAC和LN之间先前建立的隧道内产生相应的L2TP会话。（另请参见：会话、传入呼叫、传出呼叫）。
Called Number
被叫号码
An indication to the receiver of a call as to what telephone number the caller used to reach it.
向呼叫接收者发出的关于呼叫者拨打的电话号码的指示。
Calling Number
主叫号码
An indication to the receiver of a call as to the telephone number of the caller.
对来电接受者的来电号码的指示。
CHAP
小伙子
Challenge Handshake Authentication Protocol [RFC1994], a PPP cryptographic challenge/response authentication protocol in which the cleartext password is not passed over the line.
质询握手认证协议[RFC1994]，一种PPP加密质询/响应认证协议，其中明文密码不通过线路传递。
Control Connection
控制连接
A control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself.
控制连接在隧道上带内运行，以控制会话和隧道本身的建立、释放和维护。
Control Messages
控制消息
Control messages are exchanged between LAC and LNS pairs, operating in-band within the tunnel protocol. Control messages govern aspects of the tunnel and sessions within the tunnel.
控制消息在LAC和LNS对之间交换，在隧道协议的频带内运行。控制消息控制隧道和隧道内会话的各个方面。
Digital Channel
数字频道
A circuit-switched communication path which is intended to carry digital information in each direction.
一种电路交换通信路径，用于在每个方向上传送数字信息。
DSLAM
DSLAM
Digital Subscriber Line (DSL) Access Module. A network device used in the deployment of DSL service. This is typically a concentrator of individual DSL lines located in a central office (CO) or local exchange.
数字用户线（DSL）接入模块。用于部署DSL服务的网络设备。这通常是位于中央局（CO）或本地交换机中的单个DSL线路的集中器。
Incoming Call
来电
A Call received at an LAC to be tunneled to an LNS (see Call, Outgoing Call).
在LAC接收到的呼叫，通过隧道传输到LNS（参见呼叫，传出呼叫）。
L2TP Access Concentrator (LAC)
L2TP接入集中器（LAC）
A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Network Server (LNS). The LAC sits between an LNS and a remote system and forwards packets to and from each. Packets sent from the LAC to the LNS requires tunneling with the L2TP protocol as defined in this document. The connection from the LAC to the remote system is either local (see: Client LAC) or a PPP link.
充当L2TP隧道端点一侧的节点，是L2TP网络服务器（LNS）的对等节点。LAC位于LNS和远程系统之间，向每个LNS和远程系统转发数据包。从LAC发送到LNS的数据包需要使用本文件中定义的L2TP协议进行隧道传输。从LAC到远程系统的连接可以是本地（请参阅：客户端LAC）或PPP链路。
L2TP Network Server (LNS)
L2TP网络服务器（LNS）
A node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Access Concentrator (LAC). The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC.
充当L2TP隧道端点一侧的节点，是L2TP访问集中器（LAC）的对等节点。LNS是由LAC从远程系统通过隧道传输的PPP会话的逻辑终止点。
Management Domain (MD)
管理域（MD）
A network or networks under the control of a single administration, policy or system. For example, an LNS's Management Domain might be the corporate network it serves. An LAC's Management Domain might be the Internet Service Provider that owns and manages it.
在单一管理、政策或系统控制下的一个或多个网络。例如，LNS的管理域可能是它所服务的公司网络。拉丁美洲和加勒比海地区的管理域可能是拥有和管理该域的互联网服务提供商。
Network Access Server (NAS)
网络访问服务器（NAS）
A device providing local network access to users across a remote access network such as the PSTN. An NAS may also serve as an LAC, LNS or both.
通过远程访问网络（如PSTN）向用户提供本地网络访问的设备。NAS也可以用作LAC、LNS或两者。
Outgoing Call
去话呼叫
A Call placed by an LAC on behalf of an LNS (see Call, Incoming Call).
LAC代表LNS发出的呼叫（参见呼叫，传入呼叫）。
Peer
同龄人
When used in context with L2TP, peer refers to either the LAC or LNS. An LAC's Peer is an LNS and vice versa. When used in context with PPP, a peer is either side of the PPP connection.
当在L2TP上下文中使用时，peer指LAC或LN。LAC的对等方是LNS，反之亦然。在PPP上下文中使用时，对等方是PPP连接的任一侧。
POTS
壶
Plain Old Telephone Service.
普通的老式电话服务。
Remote System
远程系统
An end-system or router attached to a remote access network (i.e. a PSTN), which is either the initiator or recipient of a call. Also referred to as a dial-up or virtual dial-up client.
连接到远程接入网络（即PSTN）的终端系统或路由器，它是呼叫的发起方或接收方。也称为拨号或虚拟拨号客户端。
Session
一场
L2TP is connection-oriented. The LNS and LAC maintain state for each Call that is initiated or answered by an LAC. An L2TP Session is created between the LAC and LNS when an end-to-end PPP connection is established between a Remote System and the LNS. Datagrams related to the PPP connection are sent over the Tunnel between the LAC and LNS. There is a one to one relationship between established L2TP Sessions and their associated Calls. (See also: Call).
L2TP是面向连接的。LNS和LAC为LAC发起或应答的每个呼叫保持状态。在远程系统和LNS之间建立端到端PPP连接时，在LAC和LNS之间创建L2TP会话。与PPP连接相关的数据报通过LAC和LN之间的隧道发送。已建立的L2TP会话与其关联的调用之间存在一对一关系。（另见：电话）。
Tunnel
地下通道
A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a Control Connection and zero or more L2TP Sessions. The Tunnel carries encapsulated PPP datagrams and Control Messages between the LAC and the LNS.
LAC-LNS对之间存在隧道。隧道由一个控制连接和零个或多个L2TP会话组成。隧道在LAC和LN之间传输封装的PPP数据报和控制消息。
Zero-Length Body (ZLB) Message
零长度正文（ZLB）消息
A control packet with only an L2TP header. ZLB messages are used for explicitly acknowledging packets on the reliable control channel.
只有L2TP报头的控制数据包。ZLB消息用于明确确认可靠控制通道上的数据包。
The following diagram depicts a typical L2TP scenario. The goal is to tunnel PPP frames between the Remote System or LAC Client and an LNS located at a Home LAN.
下图描述了一个典型的L2TP场景。目标是在远程系统或LAC客户端和位于家庭LAN的LNS之间传输PPP帧。
[Home LAN]
[LAC Client]----------+ |
____|_____ +--[Host]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN]
|___________| |
| ______________ +---[Host]
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :
[Home LAN]
[LAC Client]----------+ |
____|_____ +--[Host]
| | |
[LAC]---------| Internet |-----[LNS]-----+
| |__________| |
_____|_____ :
| |
| PSTN |
[Remote]--| Cloud |
[System] | | [Home LAN]
|___________| |
| ______________ +---[Host]
| | | |
[LAC]-------| Frame Relay |---[LNS]-----+
| or ATM Cloud | |
|______________| :
The Remote System initiates a PPP connection across the PSTN Cloud to an LAC. The LAC then tunnels the PPP connection across the Internet, Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is obtained. The Remote System is provided addresses from the HOME LAN
远程系统通过PSTN云向LAC发起PPP连接。LAC然后通过互联网、帧中继或ATM云将PPP连接隧道至LNS，从而获得对家庭LAN的访问。远程系统由家庭局域网提供地址
via PPP NCP negotiation. Authentication, Authorization and Accounting may be provided by the Home LAN's Management Domain as if the user were connected to a Network Access Server directly.
通过PPP NCP谈判。认证、授权和记帐可以由家庭LAN的管理域提供，就好像用户直接连接到网络访问服务器一样。
A LAC Client (a Host which runs L2TP natively) may also participate in tunneling to the Home LAN without use of a separate LAC. In this case, the Host containing the LAC Client software already has a connection to the public Internet. A "virtual" PPP connection is then created and the local L2TP LAC Client software creates a tunnel to the LNS. As in the above case, Addressing, Authentication, Authorization and Accounting will be provided by the Home LAN's Management Domain.
LAC客户端（本机运行L2TP的主机）也可以在不使用单独LAC的情况下参与到家庭LAN的隧道。在这种情况下，包含LAC客户端软件的主机已经连接到公共Internet。然后创建“虚拟”PPP连接，本地L2TP LAC客户端软件创建到LNS的隧道。在上述情况下，寻址、身份验证、授权和记帐将由家庭LAN的管理域提供。
L2TP utilizes two types of messages, control messages and data messages. Control messages are used in the establishment, maintenance and clearing of tunnels and calls. Data messages are used to encapsulate PPP frames being carried over the tunnel. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery (see section 5.1 for details). Data messages are not retransmitted when packet loss occurs.
L2TP使用两种类型的消息，控制消息和数据消息。控制信息用于建立、维护和清除隧道和呼叫。数据消息用于封装通过隧道传输的PPP帧。控制信息利用L2TP内的可靠控制通道来保证传输（详见第5.1节）。发生数据包丢失时，数据消息不会重新传输。
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
+-------------------+
| PPP Frames |
+-------------------+ +-----------------------+
| L2TP Data Messages| | L2TP Control Messages |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+------------------------------------------------+
| Packet Transport (UDP, FR, ATM, etc.) |
+------------------------------------------------+
Figure 3.0 L2TP Protocol Structure
图3.0 L2TP协议结构
Figure 3.0 depicts the relationship of PPP frames and Control Messages over the L2TP Control and Data Channels. PPP Frames are passed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, ATM, etc. Control messages are sent over a reliable L2TP Control Channel which transmits packets in-band over the same Packet Transport.
图3.0描述了L2TP控制和数据信道上PPP帧和控制消息的关系。PPP帧通过不可靠的数据通道传递，该通道首先由L2TP报头封装，然后是数据包传输，如UDP、帧中继、ATM等。控制消息通过可靠的L2TP控制通道发送，该通道通过相同的数据包传输在带内传输数据包。
Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the Control Channel. Data Messages may use sequence numbers to reorder packets and detect lost packets.
序列号要求出现在所有控制信息中，并用于在控制通道上提供可靠的传输。数据消息可以使用序列号来重新排列数据包并检测丢失的数据包。
All values are placed into their respective fields and sent in network order (high order octets first).
所有值都放在各自的字段中，并按网络顺序发送（首先是高阶八位字节）。
L2TP packets for the control channel and data channel share a common header format. In each case where a field is optional, its space does not exist in the message if the field is marked not present. Note that while optional on data messages, the Length, Ns, and Nr fields marked as optional below, are required to be present on all control messages.
控制通道和数据通道的L2TP数据包共享一个共同的报头格式。在每个字段为可选字段的情况下，如果字段标记为not present，则消息中不存在其空格。请注意，尽管数据消息是可选的，但下面标记为可选的长度、Ns和Nr字段必须出现在所有控制消息中。
This header is formatted:
此标题的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns (opt) | Nr (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset Size (opt) | Offset pad... (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3.1 L2TP Message Header
图3.1 L2TP消息头
The Type (T) bit indicates the type of message. It is set to 0 for a data message and 1 for a control message.
类型（T）位表示消息的类型。数据消息设置为0，控制消息设置为1。
If the Length (L) bit is 1, the Length field is present. This bit MUST be set to 1 for control messages.
如果长度（L）位为1，则存在长度字段。对于控制消息，此位必须设置为1。
The x bits are reserved for future extensions. All reserved bits MUST be set to 0 on outgoing messages and ignored on incoming messages.
x位保留用于将来的扩展。传出消息的所有保留位必须设置为0，传入消息的所有保留位必须忽略。
If the Sequence (S) bit is set to 1 the Ns and Nr fields are present. The S bit MUST be set to 1 for control messages.
如果序列位设置为1，则存在Ns和Nr字段。控制消息的S位必须设置为1。
If the Offset (O) bit is 1, the Offset Size field is present. The O bit MUST be set to 0 (zero) for control messages.
如果偏移（O）位为1，则存在偏移大小字段。对于控制消息，O位必须设置为0（零）。
If the Priority (P) bit is 1, this data message should receive preferential treatment in its local queuing and transmission. LCP echo requests used as a keepalive for the link, for instance, should generally be sent with this bit set to 1. Without it, a temporary interval of local congestion could result in interference with keepalive messages and unnecessary loss of the link. This feature is only for use with data messages. The P bit MUST be set to 0 for all control messages.
如果优先级（P）位为1，则此数据消息在其本地排队和传输中应得到优先处理。例如，用作链路保留期的LCP回显请求通常应在该位设置为1的情况下发送。如果没有它，临时的本地拥塞间隔可能会导致对keepalive消息的干扰和不必要的链路丢失。此功能仅用于数据消息。对于所有控制消息，P位必须设置为0。
Ver MUST be 2, indicating the version of the L2TP data message header described in this document. The value 1 is reserved to permit detection of L2F [RFC2341] packets should they arrive intermixed with L2TP packets. Packets received with an unknown Ver field MUST be discarded.
Ver必须为2，表示本文档中描述的L2TP数据消息头的版本。保留值1以允许在L2F[RFC2341]数据包与L2TP数据包混合到达时检测它们。必须丢弃使用未知版本字段接收的数据包。
The Length field indicates the total length of the message in octets.
长度字段以八位字节表示消息的总长度。
Tunnel ID indicates the identifier for the control connection. L2TP tunnels are named by identifiers that have local significance only. That is, the same tunnel will be given different Tunnel IDs by each end of the tunnel. Tunnel ID in each message is that of the intended recipient, not the sender. Tunnel IDs are selected and exchanged as Assigned Tunnel ID AVPs during the creation of a tunnel.
隧道ID表示控制连接的标识符。L2TP隧道由仅具有局部意义的标识符命名。也就是说，同一条隧道的每一端将被赋予不同的隧道ID。每个邮件中的隧道ID都是预期收件人的ID，而不是发件人的ID。在创建隧道期间，隧道ID作为指定的隧道ID AVP进行选择和交换。
Session ID indicates the identifier for a session within a tunnel. L2TP sessions are named by identifiers that have local significance only. That is, the same session will be given different Session IDs by each end of the session. Session ID in each message is that of the intended recipient, not the sender. Session IDs are selected and exchanged as Assigned Session ID AVPs during the creation of a session.
会话ID表示隧道内会话的标识符。L2TP会话由仅具有本地意义的标识符命名。也就是说，同一个会话在会话的每个结尾都会被赋予不同的会话ID。每个邮件中的会话ID都是预期收件人的会话ID，而不是发件人的会话ID。会话ID在创建会话期间被选择并交换为分配的会话ID AVP。
Ns indicates the sequence number for this data or control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 5.8 and 5.4 for more information on using this field.
Ns表示此数据或控制消息的序列号，从零开始，每发送一条消息递增一（模2**16）。有关使用此字段的更多信息，请参见第5.8节和第5.4节。
Nr indicates the sequence number expected in the next control message to be received. Thus, Nr is set to the Ns of the last in-order message received plus one (modulo 2**16). In data messages, Nr is reserved and, if present (as indicated by the S-bit), MUST be ignored upon receipt. See section 5.8 for more information on using this field in control messages.
Nr表示下一条控制消息中预期接收的序列号。因此，Nr被设置为接收到的最后一条顺序消息的Ns加1（模2**16）。在数据消息中，Nr是保留的，如果存在（由S位指示），则在收到时必须忽略。有关在控制消息中使用此字段的更多信息，请参见第5.8节。
The Offset Size field, if present, specifies the number of octets past the L2TP header at which the payload data is expected to start. Actual data within the offset padding is undefined. If the offset field is present, the L2TP header ends after the last octet of the offset padding.
偏移量大小字段（如果存在）指定经过L2TP报头的八位字节数，有效负载数据预计从该报头开始。偏移填充中的实际数据未定义。如果存在偏移量字段，L2TP报头将在偏移量填充的最后八位字节之后结束。
The Message Type AVP (see section 4.4.1) defines the specific type of control message being sent. Recall from section 3.1 that this is only for control messages, that is, messages with the T-bit set to 1.
消息类型AVP（见第4.4.1节）定义了所发送控制消息的具体类型。回想第3.1节，这仅适用于控制消息，即T位设置为1的消息。
This document defines the following control message types (see Section 6.1 through 6.14 for details on the construction and use of each message):
本文件定义了以下控制消息类型（有关每条消息的构造和使用的详细信息，请参见第6.1节至第6.14节）：
Control Connection Management
控制连接管理
0 (reserved)
0（保留）
1 (SCCRQ) Start-Control-Connection-Request 2 (SCCRP) Start-Control-Connection-Reply 3 (SCCCN) Start-Control-Connection-Connected 4 (StopCCN) Stop-Control-Connection-Notification 5 (reserved) 6 (HELLO) Hello
1（SCCRQ）启动控制连接请求2（SCCRP）启动控制连接回复3（SCCCN）启动控制连接已连接4（StopCCN）停止控制连接通知5（保留）6（您好）您好
Call Management
呼叫管理
7 (OCRQ) Outgoing-Call-Request 8 (OCRP) Outgoing-Call-Reply 9 (OCCN) Outgoing-Call-Connected 10 (ICRQ) Incoming-Call-Request 11 (ICRP) Incoming-Call-Reply 12 (ICCN) Incoming-Call-Connected 13 (reserved) 14 (CDN) Call-Disconnect-Notify
7（OCRQ）呼出呼叫请求8（OCRP）呼出呼叫应答9（OCCN）呼出呼叫连接10（ICRQ）呼入呼叫请求11（ICRP）呼入呼叫应答12（ICCN）呼入呼叫连接13（保留）14（CDN）呼叫断开通知
Error Reporting
错误报告
15 (WEN) WAN-Error-Notify
15（文）WAN错误通知
PPP Session Control
PPP会话控制
16 (SLI) Set-Link-Info
16（SLI）设置链接信息
To maximize extensibility while still permitting interoperability, a uniform method for encoding message types and bodies is used throughout L2TP. This encoding will be termed AVP (Attribute-Value Pair) in the remainder of this document.
为了在允许互操作性的同时最大限度地提高可扩展性，L2TP中使用了统一的消息类型和正文编码方法。在本文档的其余部分中，这种编码将被称为AVP（属性-值对）。
Each AVP is encoded as:
每个AVP编码为：
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 | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[until Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits are a bit mask, describing the general attributes of the AVP.
前六位是位掩码，描述AVP的一般属性。
Two bits are defined in this document, the remaining are reserved for future extensions. Reserved bits MUST be set to 0. An AVP received with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
本文档中定义了两个位，其余为将来的扩展保留。保留位必须设置为0。接收到的保留位设置为1的AVP必须视为无法识别的AVP。
Mandatory (M) bit: Controls the behavior required of an implementation which receives an AVP which it does not recognize. If the M bit is set on an unrecognized AVP within a message associated with a particular session, the session associated with this message MUST be terminated. If the M bit is set on an unrecognized AVP within a message associated with the overall tunnel, the entire tunnel (and all sessions within) MUST be terminated. If the M bit is not set, an unrecognized AVP MUST be ignored. The control message must then continue to be processed as if the AVP had not been present.
强制（M）位：控制接收不识别的AVP的实现所需的行为。如果在与特定会话关联的消息中未识别的AVP上设置了M位，则必须终止与此消息关联的会话。如果在与整个隧道相关联的消息中的未识别AVP上设置了M位，则必须终止整个隧道（以及其中的所有会话）。如果未设置M位，则必须忽略无法识别的AVP。然后必须继续处理控制消息，就像AVP不存在一样。
Hidden (H) bit: Identifies the hiding of data in the Attribute Value field of an AVP. This capability can be used to avoid the passing of sensitive data, such as user passwords, as cleartext in an AVP. Section 4.3 describes the procedure for performing AVP hiding.
隐藏（H）位：标识AVP属性值字段中数据的隐藏。此功能可用于避免在AVP中以明文形式传递敏感数据，如用户密码。第4.3节描述了执行AVP隐藏的程序。
Length: Encodes the number of octets (including the Overall Length and bitmask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets. The field itself is 10 bits, permitting a maximum of 1023 octets of data in a single AVP. The minimum Length of an AVP is 6. If the length is 6, then the Attribute Value field is absent.
长度：编码此AVP中包含的八位字节数（包括总长度和位掩码字段）。长度可以计算为6+属性值字段的长度（以八位字节为单位）。该字段本身为10位，允许单个AVP中最多有1023个八位字节的数据。AVP的最小长度为6。如果长度为6，则属性值字段不存在。
Vendor ID: The IANA assigned "SMI Network Management Private Enterprise Codes" [RFC1700] value. The value 0, corresponding to IETF adopted attribute values, is used for all AVPs defined within this document. Any vendor wishing to implement their own L2TP extensions can use their own Vendor ID along with private Attribute
供应商ID:IANA分配的“SMI网络管理私有企业代码”[RFC1700]值。值0对应于IETF采用的属性值，用于本文档中定义的所有AVP。任何希望实现自己的L2TP扩展的供应商都可以使用自己的供应商ID和私有属性
values, guaranteeing that they will not collide with any other vendor's extensions, nor with future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this feature to the first 65,535 enterprises.
值，保证它们不会与任何其他供应商的扩展冲突，也不会与未来的IETF扩展冲突。请注意，为供应商ID分配了16位，因此此功能仅限于前65535个企业。
Attribute Type: A 2 octet value with a unique interpretation across all AVPs defined under a given Vendor ID.
属性类型：在给定供应商ID下定义的所有AVP中具有唯一解释的2个八位组值。
Attribute Value: This is the actual value as indicated by the Vendor ID and Attribute Type. It follows immediately after the Attribute Type field, and runs for the remaining octets indicated in the Length (i.e., Length minus 6 octets of header). This field is absent if the Length is 6.
属性值：由供应商ID和属性类型指示的实际值。它紧跟在属性类型字段之后，并针对长度中指示的剩余八位字节（即长度减去头的6个八位字节）运行。如果长度为6，则此字段不存在。
Receipt of an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it is associated with. Thus, the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Further, in the case where the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility of the peer sending the Mandatory AVP to accept fault for causing an non-interoperable situation. Before defining an AVP with the M-bit set, particularly a vendor-specific AVP, be sure that this is the intended consequence.
接收到具有M位集的未知AVP对与其关联的会话或隧道来说是灾难性的。因此，仅应为AVP定义M位，AVP对会话或隧道的正确操作至关重要。此外，在LAC或LNS接收到设置了M位的未知AVP并相应地关闭会话或隧道的情况下，发送强制AVP的对等方完全负责接受导致不可互操作情况的故障。在使用M位集定义AVP之前，尤其是特定于供应商的AVP，请确保这是预期结果。
When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M-bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message.
当存在使用M位的适当替代方案时，应使用M位。例如，不是简单地发送设置了M位的AVP以确定是否存在特定扩展，而是可以通过在请求消息中发送AVP并在应答消息中期望相应的AVP来识别可用性。
Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set.
将M位与新AVP（本文档中未定义的AVP）一起使用时，必须能够将相关功能配置为关闭，以便AVP不发送，或在未设置M位的情况下发送。
The H bit in the header of each AVP provides a mechanism to indicate to the receiving peer whether the contents of the AVP are hidden or present in cleartext. This feature can be used to hide sensitive control message data such as user passwords or user IDs.
每个AVP的报头中的H位提供了一种机制，用于向接收对等方指示AVP的内容是隐藏的还是以明文形式存在的。此功能可用于隐藏敏感的控制消息数据，如用户密码或用户ID。
The H bit MUST only be set if a shared secret exists between the LAC and LNS. The shared secret is the same secret that is used for tunnel authentication (see Section 5.1.1). If the H bit is set in any
仅当LAC和LN之间存在共享机密时，才必须设置H位。共享秘密与用于隧道身份验证的秘密相同（见第5.1.1节）。如果H位设置在任何
AVP(s) in a given control message, a Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1.
AVP在给定的控制消息中，随机向量AVP也必须出现在消息中，并且必须位于H位为1的第一个AVP之前。
Hiding an AVP value is done in several steps. The first step is to take the length and value fields of the original (cleartext) AVP and encode them into a Hidden AVP Subformat as follows:
隐藏AVP值分几个步骤完成。第一步是获取原始（明文）AVP的长度和值字段，并将其编码为隐藏的AVP子格式，如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: This is length of the Original Attribute Value to be obscured in octets. This is necessary to determine the original length of the Attribute Value which is lost when the additional Padding is added.
原始属性值的长度：这是要隐藏的原始属性值的长度，以八位字节为单位。这对于确定添加额外填充时丢失的属性值的原始长度是必需的。
Original Attribute Value: Attribute Value that is to be obscured.
原始属性值：要遮挡的属性值。
Padding: Random additional octets used to obscure length of the Attribute Value that is being hidden.
填充：用于隐藏属性值长度的随机附加八位字节。
To mask the size of the data being hidden, the resulting subformat MAY be padded as shown above. Padding does NOT alter the value placed in the Length of Original Attribute Value field, but does alter the length of the resultant AVP that is being created. For example, If an Attribute Value to be hidden is 4 octets in length, the unhidden AVP length would be 10 octets (6 + Attribute Value length). After hiding, the length of the AVP will become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length will be 6 + 4 + 2 + 12 = 24 octets.
为了掩盖隐藏数据的大小，可以如上所示填充生成的子表单。填充不会改变“原始属性值的长度”字段中的值，但会改变正在创建的结果AVP的长度。例如，如果要隐藏的属性值的长度为4个八位字节，则未隐藏的AVP长度将为10个八位字节（6+属性值长度）。隐藏后，AVP的长度将变为6+属性值长度+原始属性值字段长度的大小+填充。因此，如果填充为12个八位字节，AVP长度将为6+4+2+12=24个八位字节。
Next, An MD5 hash is performed on the concatenation of:
接下来，对以下各项的串联执行MD5哈希：
+ the 2 octet Attribute number of the AVP + the shared secret + an arbitrary length random vector
+ AVP的2个八位组属性数+共享秘密+任意长度的随机向量
The value of the random vector used in this hash is passed in the value field of a Random Vector AVP. This Random Vector AVP must be placed in the message by the sender before any hidden AVPs. The same random vector may be used for more than one hidden AVP in the same
此散列中使用的随机向量的值在随机向量AVP的值字段中传递。此随机向量AVP必须由发送方置于任何隐藏AVP之前的消息中。同一随机向量可用于同一区域中的多个隐藏AVP
message. If a different random vector is used for the hiding of subsequent AVPs then a new Random Vector AVP must be placed in the command message before the first AVP to which it applies.
消息如果使用不同的随机向量隐藏后续AVP，则必须将新的随机向量AVP放置在其应用的第一个AVP之前的命令消息中。
The MD5 hash value is then XORed with the first 16 octet (or less) segment of the Hidden AVP Subformat and placed in the Attribute Value field of the Hidden AVP. If the Hidden AVP Subformat is less than 16 octets, the Subformat is transformed as if the Attribute Value field had been padded to 16 octets before the XOR, but only the actual octets present in the Subformat are modified, and the length of the AVP is not altered.
然后，MD5散列值与隐藏AVP子表单的前16个八位字节（或更少）段异或，并放置在隐藏AVP的属性值字段中。如果隐藏的AVP子格式小于16个八位字节，则将对子格式进行转换，就像在XOR之前已将属性值字段填充到16个八位字节一样，但仅修改子格式中的实际八位字节，并且不会更改AVP的长度。
If the Subformat is longer than 16 octets, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first XOR. That hash is XORed with the second 16 octet (or less) segment of the Subformat and placed in the corresponding octets of the Value field of the Hidden AVP.
如果子格式的长度超过16个八位字节，则在由共享密钥和第一个异或结果组成的八位字节流上计算第二个单向MD5哈希。该散列与子表单的第二个16个八位字节（或更少）段异或，并放置在隐藏AVP的值字段的相应八位字节中。
If necessary, this operation is repeated, with the shared secret used along with each XOR result to generate the next hash to XOR the next segment of the value with.
如有必要，将重复此操作，并将共享机密与每个XOR结果一起使用，以生成下一个散列，以与值的下一段进行XOR。
The hiding method was adapted from RFC 2138 [RFC2138] which was taken from the "Mixing in the Plaintext" section in the book "Network Security" by Kaufman, Perlman and Speciner [KPS]. A detailed explanation of the method follows:
隐藏方法改编自RFC 2138[RFC2138]，该方法取自Kaufman、Perlman和Speciner[KPS]的《网络安全》一书中的“纯文本混合”部分。该方法的详细说明如下：
Call the shared secret S, the Random Vector RV, and the Attribute Value AV. Break the value field into 16-octet chunks p1, p2, etc. with the last one padded at the end with random data to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We will also define intermediate values b1, b2, etc.
调用共享秘密S、随机向量RV和属性值AV。将值字段分为16个八位字节块p1、p2等，最后一个在末尾用随机数据填充到16个八位字节的边界。调用密文块c（1）、c（2）等。我们还将定义中间值b1、b2等。
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation.
字符串将包含c（1）+c（2）+…+c（i），其中+表示串联。
On receipt, the random vector is taken from the last Random Vector AVP encountered in the message prior to the AVP to be unhidden. The above process is then reversed to yield the original value.
接收时，随机向量取自要取消隐藏的AVP之前消息中遇到的最后一个随机向量AVP。然后将上述过程反向，以产生原始值。
The following sections contain a list of all L2TP AVPs defined in this document.
以下部分包含本文档中定义的所有L2TP AVP的列表。
Following the name of the AVP is a list indicating the message types that utilize each AVP. After each AVP title follows a short description of the purpose of the AVP, a detail (including a graphic) of the format for the Attribute Value, and any additional information needed for proper use of the avp.
AVP名称后面是一个列表，指示使用每个AVP的消息类型。在每个AVP标题之后，都有AVP用途的简短说明、属性值格式的详细信息（包括图形）以及正确使用AVP所需的任何附加信息。
Message Type (All Messages)
消息类型（所有消息）
The Message Type AVP, Attribute Type 0, identifies the control message herein and defines the context in which the exact meaning of the following AVPs will be determined.
消息类型AVP，属性类型0，标识此处的控制消息，并定义将在其中确定以下AVP的确切含义的上下文。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Type is a 2 octet unsigned integer.
消息类型为2个八位无符号整数。
The Message Type AVP MUST be the first AVP in a message, immediately following the control message header (defined in section 3.1). See Section 3.2 for the list of defined control message types and their identifiers.
消息类型AVP必须是消息中的第一个AVP，紧跟在控制消息头之后（定义见第3.1节）。有关定义的控制消息类型及其标识符的列表，请参见第3.2节。
The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication as to whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. Thus, if the M-bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the tunnel MUST be cleared. If the M-bit is not set, then the implementation may ignore an unknown message type. The M-bit MUST be set to 1 for all message types defined in this document. This AVP may not be hidden (the H-bit MUST be 0). The Length of this AVP is 8.
消息类型AVP中的强制（M）位具有特殊含义。它不是指示如果无法识别是否应忽略AVP本身，而是指示是否应忽略控制消息本身。因此，如果M位设置在消息类型AVP内，并且消息类型对于实现是未知的，则必须清除隧道。如果未设置M位，则实现可能忽略未知消息类型。对于本文档中定义的所有消息类型，M位必须设置为1。此AVP不能隐藏（H位必须为0）。这个AVP的长度是8。
Random Vector (All Messages)
随机向量（所有消息）
The Random Vector AVP, Attribute Type 36, is used to enable the hiding of the Attribute Value of arbitrary AVPs.
属性类型36的随机向量AVP用于使得能够隐藏任意AVP的属性值。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String may be of arbitrary length, although a random vector of at least 16 octets is recommended. The string contains the random vector for use in computing the MD5 hash to retrieve or hide the Attribute Value of a hidden AVP (see Section 4.2).
尽管建议使用至少16个八位字节的随机向量，但随机八位字节字符串可以具有任意长度。该字符串包含用于计算MD5散列以检索或隐藏隐藏的AVP属性值的随机向量（参见第4.2节）。
More than one Random Vector AVP may appear in a message, in which case a hidden AVP uses the Random Vector AVP most closely preceding it. This AVP MUST precede the first AVP with the H bit set.
消息中可能出现多个随机向量AVP，在这种情况下，隐藏AVP使用最接近其前面的随机向量AVP。此AVP必须位于设置了H位的第一个AVP之前。
The M-bit for this AVP MUST be set to 1. This AVP MUST NOT be hidden (the H-bit MUST be 0). The Length of this AVP is 6 plus the length of the Random Octet String.
此AVP的M位必须设置为1。不得隐藏此AVP（H位必须为0）。这个AVP的长度是6加上随机八位字节字符串的长度。
Result Code (CDN, StopCCN)
结果代码（CDN、StopCCN）
The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control channel or session.
结果代码AVP属性类型1指示终止控制通道或会话的原因。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message (opt) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Result Code is a 2 octet unsigned integer. The optional Error Code is a 2 octet unsigned integer. An optional Error Message can follow the Error Code field. Presence of the Error Code and
结果代码是2个八位无符号整数。可选错误代码为2个八位无符号整数。错误代码字段后面可以显示可选的错误消息。是否存在错误代码，以及
Message are indicated by the AVP Length field. The Error Message contains an arbitrary string providing further (human readable) text associated with the condition. Human readable text in all error messages MUST be provided in the UTF-8 charset using the Default Language [RFC2277].
消息由AVP长度字段指示。错误消息包含一个任意字符串，提供与条件相关的更多（人类可读）文本。必须使用默认语言[RFC2277]在UTF-8字符集中提供所有错误消息中的人类可读文本。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length is 8 if there is no Error Code or Message, 10 if there is an Error Code and no Error Message or 10 + the length of the Error Message if there is an Error Code and Message.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。如果没有错误代码或消息，则长度为8；如果有错误代码和错误消息，则长度为10；如果有错误代码和消息，则长度为10+错误消息的长度。
Defined Result Code values for the StopCCN message are:
StopCCN消息的定义结果代码值为：
0 - Reserved 1 - General request to clear control connection 2 - General error--Error Code indicates the problem 3 - Control channel already exists 4 - Requester is not authorized to establish a control channel 5 - The protocol version of the requester is not supported Error Code indicates highest version supported 6 - Requester is being shut down 7 - Finite State Machine error
0-保留1-清除控制连接的一般请求2-一般错误-错误代码表示问题3-控制通道已存在4-请求者无权建立控制通道5-请求者的协议版本不受支持错误代码表示支持的最高版本6-请求者正在关闭7-有限状态机错误
Defined Result Code values for the CDN message are:
CDN消息的定义结果代码值为：
0 - Reserved 1 - Call disconnected due to loss of carrier 2 - Call disconnected for the reason indicated in error code 3 - Call disconnected for administrative reasons 4 - Call failed due to lack of appropriate facilities being available (temporary condition) 5 - Call failed due to lack of appropriate facilities being available (permanent condition) 6 - Invalid destination 7 - Call failed due to no carrier detected 8 - Call failed due to detection of a busy signal 9 - Call failed due to lack of a dial tone 10 - Call was not established within time allotted by LAC 11 - Call was connected but no appropriate framing was detected
0-保留1-呼叫因载波丢失而断开2-呼叫因错误代码3中指示的原因而断开-呼叫因管理原因而断开4-呼叫因缺少可用的适当设施而失败（临时条件）5-呼叫因缺少可用的适当设施而失败（永久性条件）6-无效目的地7-未检测到运营商导致呼叫失败8-检测到忙信号导致呼叫失败9-缺少拨号音导致呼叫失败10-在LAC分配的时间内未建立呼叫11-呼叫已连接，但未检测到适当的帧
The Error Codes defined below pertain to types of errors that are not specific to any particular L2TP request, but rather to protocol or message format errors. If an L2TP reply indicates in
下面定义的错误代码与不特定于任何特定L2TP请求的错误类型有关，而与协议或消息格式错误有关。如果L2TP应答指示
its Result Code that a general error occurred, the General Error value should be examined to determine what the error was. The currently defined General Error codes and their meanings are:
其结果代码表明发生了一般错误，应检查一般错误值以确定错误是什么。当前定义的一般错误代码及其含义如下：
0 - No general error 1 - No control connection exists yet for this LAC-LNS pair 2 - Length is wrong 3 - One of the field values was out of range or reserved field was non-zero 4 - Insufficient resources to handle this operation now 5 - The Session ID is invalid in this context 6 - A generic vendor-specific error occurred in the LAC 7 - Try another. If LAC is aware of other possible LNS destinations, it should try one of them. This can be used to guide an LAC based on LNS policy, for instance, the existence of multilink PPP bundles. 8 - Session or tunnel was shutdown due to receipt of an unknown AVP with the M-bit set (see section 4.2). The Error Message SHOULD contain the attribute of the offending AVP in (human readable) text form.
0-无常规错误1-此LAC-LNS对尚不存在控制连接2-长度错误3-一个字段值超出范围或保留字段非零4-资源不足，无法立即处理此操作5-会话ID在此上下文中无效6-LAC 7中发生一般供应商特定错误-重试另一个如果LAC知道其他可能的LNS目的地，则应尝试其中一个。这可用于指导基于LNS策略的LAC，例如，多链路PPP捆绑包的存在。8-会话或隧道由于接收到带有M位集的未知AVP而关闭（见第4.2节）。错误消息应该以（人类可读的）文本形式包含有问题的AVP的属性。
When a General Error Code of 6 is used, additional information about the error SHOULD be included in the Error Message field.
当使用一般错误代码6时，有关错误的附加信息应包含在错误消息字段中。
Protocol Version (SCCRP, SCCRQ)
协议版本（SCCRP、SCCRQ）
The Protocol Version AVP, Attribute Type 2, indicates the L2TP protocol version of the sender.
协议版本AVP属性类型2表示发送方的L2TP协议版本。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Rev |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Ver field is a 1 octet unsigned integer containing the value 1. Rev field is a 1 octet unsigned integer containing 0. This pertains to L2TP protocol version 1, revision 0. Note this is not the same version number that is included in the header of each message.
Ver字段是一个包含值1的八位无符号整数。Rev字段是包含0的1个八位无符号整数。这与L2TP协议版本1，版本0有关。注意：这与每条消息的标题中包含的版本号不同。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。这个AVP的长度是8。
Framing Capabilities (SCCRP, SCCRQ)
成帧能力（SCCRP、SCCRQ）
The Framing Capabilities AVP, Attribute Type 3, provides the peer with an indication of the types of framing that will be accepted or requested by the sender.
帧功能AVP属性类型3向对等方提供发送方将接受或请求的帧类型指示。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future framing type definitions |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future framing type definitions |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attribute Value field is a 32-bit mask, with two bits defined. If bit A is set, asynchronous framing is supported. If bit S is set, synchronous framing is supported.
属性值字段是一个32位掩码，定义了两位。如果设置了位A，则支持异步帧。如果设置了位S，则支持同步成帧。
A peer MUST NOT request an incoming or outgoing call with a Framing Type AVP specifying a value not advertised in the Framing Capabilities AVP it received during control connection establishment. Attempts to do so will result in the call being rejected.
对等方不得请求具有帧类型AVP的传入或传出呼叫，该帧类型AVP指定了在控制连接建立期间接收到的帧功能AVP中未公布的值。尝试这样做将导致呼叫被拒绝。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。长度（隐藏前）为10。
Bearer Capabilities (SCCRP, SCCRQ)
承载能力（SCCRP、SCCRQ）
The Bearer Capabilities AVP, Attribute Type 4, provides the peer with an indication of the bearer device types supported by the hardware interfaces of the sender for outgoing calls.
承载能力AVP属性类型4向对等方提供由发送方的硬件接口支持的用于传出呼叫的承载设备类型的指示。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future bearer type definitions |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future bearer type definitions |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a 32-bit mask, with two bits defined. If bit A is set, analog access is supported. If bit D is set, digital access is supported.
这是一个32位掩码，定义了两位。如果设置了位A，则支持模拟访问。如果设置了位D，则支持数字访问。
An LNS should not request an outgoing call specifying a value in the Bearer Type AVP for a device type not advertised in the Bearer Capabilities AVP it received from the LAC during control connection establishment. Attempts to do so will result in the call being rejected.
在控制连接建立期间，LNS不应请求在承载类型AVP中为其从LAC接收的未在承载能力AVP中通告的设备类型指定值的传出呼叫。尝试这样做将导致呼叫被拒绝。
This AVP MUST be present if the sender can place outgoing calls when requested.
如果发送方可以在请求时拨出电话，则必须存在此AVP。
Note that an LNS that cannot act as an LAC as well will not support hardware devices for handling incoming and outgoing calls and should therefore set the A and D bits of this AVP to 0, or should not send the AVP at all. An LNS that can also act as an LAC and place outgoing calls should set A or D as appropriate. Presence of this message is not a guarantee that a given outgoing call will be placed by the sender if requested, just that the physical capability exists.
请注意，不能同时充当LAC的LN不支持用于处理传入和传出呼叫的硬件设备，因此应将此AVP的A和D位设置为0，或者根本不应发送AVP。也可作为LAC并拨打外呼的LNS应适当设置A或D。此消息的存在并不能保证发送方会在收到请求时拨打给定的传出呼叫，而只能保证物理功能的存在。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。长度（隐藏前）为10。
Tie Breaker (SCCRQ)
联络断路器（SCCRQ）
The Tie Breaker AVP, Attribute Type 5, indicates that the sender wishes a single tunnel to exist between the given LAC-LNS pair.
Tie Breaker AVP属性类型5表示发送方希望给定LAC-LNS对之间存在一个隧道。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Break Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tie Break Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...(64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tie Breaker Value is an 8 octet value that is used to choose a single tunnel where both LAC and LNS request a tunnel concurrently. The recipient of a SCCRQ must check to see if a SCCRQ has been sent to the peer, and if so, must compare its Tie Breaker value with the received one. The lower value "wins", and the "loser" MUST silently discard its tunnel. In the case where a tie breaker is present on both sides, and the value is equal, both sides MUST discard their tunnels.
联络断路器值是8个八位组的值，用于选择LAC和LN同时请求隧道的单个隧道。SCCRQ的接收方必须检查SCCRQ是否已发送给对等方，如果已发送，则必须将其断开连接的值与接收到的断开连接的值进行比较。较低的值“获胜”，而“失败者”必须默默地放弃它的通道。如果两侧都有一个连接断路器，且该值相等，则两侧必须丢弃其隧道。
If a tie breaker is received, and an outstanding SCCRQ had no tie breaker value, the initiator which included the Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate tunnels are opened.
如果收到平局破坏者，且未完成的SCCRQ没有平局破坏者值，则包含平局破坏者AVP的发起人“获胜”。如果任何一方均未发布平局断路器，则打开两个单独的隧道。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 0. The Length of this AVP is 14.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为0。这个AVP的长度是14。
Firmware Revision (SCCRP, SCCRQ)
固件版本（SCCRP、SCCRQ）
The Firmware Revision AVP, Attribute Type 6, indicates the firmware revision of the issuing device.
固件版本AVP属性类型6表示发布设备的固件版本。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Firmware Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Firmware Revision is a 2 octet unsigned integer encoded in a vendor specific format.
固件版本是以供应商特定格式编码的2个八位无符号整数。
For devices which do not have a firmware revision (general purpose computers running L2TP software modules, for instance), the revision of the L2TP software module may be reported instead.
对于没有固件版本的设备（例如，运行L2TP软件模块的通用计算机），可以报告L2TP软件模块的版本。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。长度（隐藏前）为8。
Host Name (SCCRP, SCCRQ)
主机名（SCCRP、SCCRQ）
The Host Name AVP, Attribute Type 7, indicates the name of the issuing LAC or LNS.
主机名AVP属性类型7表示发出LAC或LN的名称。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Host Name is of arbitrary length, but MUST be at least 1 octet.
主机名具有任意长度，但必须至少为1个八位字节。
This name should be as broadly unique as possible; for hosts participating in DNS [RFC1034], a hostname with fully qualified domain would be appropriate.
该名称应尽可能具有广泛的唯一性；对于参与DNS[RFC1034]的主机，具有完全限定域的主机名是合适的。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6 plus the length of the Host Name.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。此AVP的长度为6加上主机名的长度。
Vendor Name (SCCRP, SCCRQ)
供应商名称（SCCRP、SCCRQ）
The Vendor Name AVP, Attribute Type 8, contains a vendor specific (possibly human readable) string describing the type of LAC or LNS being used.
供应商名称AVP属性类型8包含一个特定于供应商（可能是人类可读的）字符串，描述所使用的LAC或LN的类型。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Name ...(arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Name ...(arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor Name is the indicated number of octets representing the vendor string. Human readable text for this AVP MUST be provided in the UTF-8 charset using the Default Language [RFC2277].
供应商名称是表示供应商字符串的指定八位字节数。必须使用默认语言[RFC2277]在UTF-8字符集中提供此AVP的人类可读文本。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Vendor Name.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上供应商名称的长度。
Assigned Tunnel ID (SCCRP, SCCRQ, StopCCN)
指定的隧道ID（SCCRP、SCCRQ、StopCCN）
The Assigned Tunnel ID AVP, Attribute Type 9, encodes the ID being assigned to this tunnel by the sender.
分配的隧道ID AVP属性类型9对发送方分配给该隧道的ID进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Tunnel ID is a 2 octet non-zero unsigned integer.
分配的隧道ID是一个2个八位组的非零无符号整数。
The Assigned Tunnel ID AVP establishes a value used to multiplex and demultiplex multiple tunnels between the LNS and LAC. The L2TP peer MUST place this value in the Tunnel ID header field of all
分配的隧道ID AVP建立用于在LNS和LAC之间复用和解复用多个隧道的值。L2TP对等方必须将此值放在所有
control and data messages that it subsequently transmits over the associated tunnel. Before the Assigned Tunnel ID AVP is received from a peer, messages MUST be sent to that peer with a Tunnel ID value of 0 in the header of all control messages.
随后通过相关隧道传输的控制和数据消息。在从对等方接收分配的隧道ID AVP之前，必须将所有控制消息的标头中隧道ID值为0的消息发送给该对等方。
In the StopCCN control message, the Assigned Tunnel ID AVP MUST be the same as the Assigned Tunnel ID AVP first sent to the receiving peer, permitting the peer to identify the appropriate tunnel even if a StopCCN is sent before an Assigned Tunnel ID AVP is received.
在StopCCN控制消息中，分配的隧道ID AVP必须与首先发送给接收对等方的分配的隧道ID AVP相同，从而允许对等方识别适当的隧道，即使在接收到分配的隧道ID AVP之前发送了StopCCN。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为8。
Receive Window Size (SCCRQ, SCCRP)
接收窗口大小（SCCRQ、SCCRP）
The Receive Window Size AVP, Attribute Type 10, specifies the receive window size being offered to the remote peer.
接收窗口大小AVP属性类型10指定提供给远程对等方的接收窗口大小。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Window Size is a 2 octet unsigned integer.
窗口大小为2个八位无符号整数。
If absent, the peer must assume a Window Size of 4 for its transmit window. The remote peer may send the specified number of control messages before it must wait for an acknowledgment.
如果不存在，对等方必须假定其传输窗口的窗口大小为4。在必须等待确认之前，远程对等方可以发送指定数量的控制消息。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 8.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。这个AVP的长度是8。
Challenge (SCCRP, SCCRQ)
挑战（SCCRP、SCCRQ）
The Challenge AVP, Attribute Type 11, indicates that the issuing peer wishes to authenticate the tunnel endpoints using a CHAP-style authentication mechanism.
质询AVP属性类型11表示发出请求的对等方希望使用CHAP样式的身份验证机制对隧道端点进行身份验证。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is one or more octets of random data.
挑战是一个或多个八位字节的随机数据。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Challenge.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。这个AVP的长度（隐藏前）是6加上挑战的长度。
Challenge Response (SCCCN, SCCRP)
挑战响应（SCCCN、SCCRP）
The Response AVP, Attribute Type 13, provides a response to a challenge received.
响应AVP属性类型13提供对接收到的质询的响应。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a 16 octet value reflecting the CHAP-style [RFC1994] response to the challenge.
响应是16个八位组的值，反映了CHAP样式[RFC1994]对质询的响应。
This AVP MUST be present in an SCCRP or SCCCN if a challenge was received in the preceding SCCRQ or SCCRP. For purposes of the ID value in the CHAP response calculation, the value of the Message Type AVP for this message is used (e.g. 2 for an SCCRP, and 3 for an SCCCN).
如果在前面的SCCRQ或SCCRP中收到质询，则此AVP必须存在于SCCRP或SCCCN中。为了计算CHAP响应中的ID值，使用该消息的消息类型AVP的值（例如，2表示SCCRP，3表示SCCCN）。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 22.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为22。
Q.931 Cause Code (CDN)
Q.931原因代码（CDN）
The Q.931 Cause Code AVP, Attribute Type 12, is used to give additional information in case of unsolicited call disconnection.
Q.931原因代码AVP，属性类型12，用于在未经请求的呼叫断开情况下提供附加信息。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Msg | Advisory Msg...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code is the returned Q.931 Cause code, and Cause Msg is the returned Q.931 message code (e.g., DISCONNECT) associated with the Cause Code. Both values are returned in their native ITU encodings [DSS1]. An additional ASCII text Advisory Message may also be included (presence indicated by the AVP Length) to further explain the reason for disconnecting.
原因代码是返回的Q.931原因代码，原因消息是返回的与原因代码相关的Q.931消息代码（例如，断开连接）。这两个值都以其本机ITU编码[DSS1]返回。还可能包括一条额外的ASCII文本提示消息（存在由AVP长度指示），以进一步解释断开连接的原因。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 9, plus the size of the Advisory Message.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。此AVP的长度为9，加上建议消息的大小。
Assigned Session ID (CDN, ICRP, ICRQ, OCRP, OCRQ)
分配的会话ID（CDN、ICRP、ICRQ、OCRP、OCRQ）
The Assigned Session ID AVP, Attribute Type 14, encodes the ID being assigned to this session by the sender.
分配的会话ID AVP属性类型14对发送方分配给该会话的ID进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Session ID is a 2 octet non-zero unsigned integer.
分配的会话ID是2个八位字节的非零无符号整数。
The Assigned Session ID AVP is establishes a value used to multiplex and demultiplex data sent over a tunnel between the LNS and LAC. The L2TP peer MUST place this value in the Session ID header field of all control and data messages that it subsequently transmits over the tunnel that belong to this session. Before the
分配的会话ID AVP建立用于复用和解复用通过LNS和LAC之间的隧道发送的数据的值。L2TP对等方必须将该值放在所有控制和数据消息的会话ID头字段中，该消息随后通过属于该会话的隧道传输。在
Assigned Session ID AVP is received from a peer, messages MUST be sent to that peer with a Session ID of 0 in the header of all control messages.
如果从对等方接收到分配的会话ID AVP，则必须在所有控制消息的标头中将会话ID为0的消息发送到该对等方。
In the CDN control message, the same Assigned Session ID AVP first sent to the receiving peer is used, permitting the peer to identify the appropriate tunnel even if CDN is sent before an Assigned Session ID is received.
在CDN控制消息中，使用首先发送给接收对等方的相同分配的会话ID AVP，允许对等方识别适当的隧道，即使在接收分配的会话ID之前发送CDN。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为8。
Call Serial Number (ICRQ, OCRQ)
呼叫序列号（ICRQ、OCRQ）
The Call Serial Number AVP, Attribute Type 15, encodes an identifier assigned by the LAC or LNS to this call.
呼叫序列号AVP属性类型15编码LAC或LN分配给该呼叫的标识符。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Call Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Call Serial Number is a 32 bit value.
呼叫序列号是一个32位的值。
The Call Serial Number is intended to be an easy reference for administrators on both ends of a tunnel to use when investigating call failure problems. Call Serial Numbers should be set to progressively increasing values, which are likely to be unique for a significant period of time across all interconnected LNSs and LACs.
呼叫序列号是为了方便隧道两端的管理员在调查呼叫失败问题时使用。呼叫序列号应设置为递增值，在所有互联的LNS和LAC中，该值可能在相当长的一段时间内是唯一的。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Minimum BPS (OCRQ)
最低基准点（OCRQ）
The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable line speed for this call.
最小BPS AVP属性类型16编码此呼叫可接受的最低线路速度。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Minimum BPS is a 32 bit value indicates the speed in bits per second.
最小BPS是一个32位的值，表示以位/秒为单位的速度。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Maximum BPS (OCRQ)
最大BPS（OCRQ）
The Maximum BPS AVP, Attribute Type 17, encodes the highest acceptable line speed for this call.
最大BPS AVP属性类型17编码此呼叫的最高可接受线路速度。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Maximum BPS is a 32 bit value indicates the speed in bits per second.
最大BPS是一个32位的值，表示以位/秒为单位的速度。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Bearer Type (ICRQ, OCRQ)
承载类型（ICRQ、OCRQ）
The Bearer Type AVP, Attribute Type 18, encodes the bearer type for the incoming or outgoing call.
承载类型AVP，属性类型18，对传入或传出呼叫的承载类型进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Bearer Types |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Bearer Types |A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bearer Type is a 32-bit bit mask, which indicates the bearer capability of the call (ICRQ) or required for the call (OCRQ). If set, bit A indicates that the call refers to an analog channel. If set, bit D indicates that the call refers to a digital channel. Both may be set, indicating that the call was either indistinguishable, or can be placed on either type of channel.
承载类型是32位掩码，表示呼叫的承载能力（ICRQ）或呼叫所需的承载能力（OCRQ）。如果设置，位A表示呼叫指的是模拟信道。如果设置，则位D表示呼叫指向数字频道。两者都可以设置，表示呼叫无法区分，或者可以放在任一类型的频道上。
Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Bearer Capabilities AVP received from the LAC during control connection establishment.
如果在控制连接建立期间从LAC接收的承载能力AVP中设置了OCRQ，则该AVP的值字段中的位只能由LNS设置。
It is valid to set neither the A nor D bits in an ICRQ. Such a setting may indicate that the call was not received over a physical link (e.g if the LAC and PPP are located in the same subsystem).
在ICRQ中既不设置A位也不设置D位是有效的。这样的设置可以指示没有通过物理链路接收呼叫（例如，如果LAC和PPP位于同一子系统中）。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Framing Type (ICCN, OCCN, OCRQ)
框架类型（ICCN、OCCN、OCRQ）
The Framing Type AVP, Attribute Type 19, encodes the framing type for the incoming or outgoing call.
帧类型AVP属性类型19对传入或传出呼叫的帧类型进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Framing Types |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for future Framing Types |A|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Framing Type is a 32-bit mask, which indicates the type of PPP framing requested for an OCRQ, or the type of PPP framing negotiated for an OCCN or ICCN. The framing type MAY be used as an indication to PPP on the LNS as to what link options to use for LCP negotiation [RFC1662].
帧类型是32位掩码，表示OCRQ请求的PPP帧类型，或OCCN或ICCN协商的PPP帧类型。帧类型可用作LNS上PPP的指示，指示LCP协商使用何种链路选项[RFC1662]。
Bit A indicates asynchronous framing. Bit S indicates synchronous framing. For an OCRQ, both may be set, indicating that either type of framing may be used.
位A表示异步帧。位S表示同步帧。对于OCRQ，两者都可以设置，表示可以使用任一类型的帧。
Bits in the Value field of this AVP MUST only be set by the LNS for an OCRQ if it was set in the Framing Capabilities AVP received from the LAC during control connection establishment.
如果在控制连接建立期间从LAC接收的帧功能AVP中设置了OCRQ，则该AVP的值字段中的位只能由LNS设置。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Called Number (ICRQ, OCRQ)
被叫号码（ICRQ、OCRQ）
The Called Number AVP, Attribute Type 21, encodes the telephone number to be called for an OCRQ, and the Called number for an ICRQ.
被叫号码AVP属性类型21对OCRQ要呼叫的电话号码和ICRQ的被叫号码进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Called Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value needed in this AVP.
被叫号码是ASCII字符串。可能需要LAC管理员和LNS之间的联系，以协调本AVP中所需值的解释。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Called Number.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。这个AVP的长度（隐藏前）是6加上被叫号码的长度。
Calling Number (ICRQ)
呼叫号码（ICRQ）
The Calling Number AVP, Attribute Type 22, encodes the originating number for the incoming call.
主叫号码AVP，属性类型22，对传入呼叫的始发号码进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Number... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calling Number is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP.
主叫号码是一个ASCII字符串。可能需要LAC管理员和LNS之间的联系，以协调本AVP中数值的解释。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Calling Number.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。这个AVP的长度（隐藏前）是6加上主叫号码的长度。
Sub-Address (ICRQ, OCRQ)
子地址（ICRQ、OCRQ）
The Sub-Address AVP, Attribute Type 23, encodes additional dialing information.
属性类型23的子地址AVP对附加拨号信息进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Address ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-Address is an ASCII string. Contact between the administrator of the LAC and the LNS may be necessary to coordinate interpretation of the value in this AVP.
子地址是一个ASCII字符串。可能需要LAC管理员和LNS之间的联系，以协调本AVP中数值的解释。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 plus the length of the Sub-Address.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为6加上子地址的长度。
(Tx) Connect Speed (ICCN, OCCN)
（Tx）连接速度（ICCN、OCCN）
The (Tx) Connect Speed BPS AVP, Attribute Type 24, encodes the speed of the facility chosen for the connection attempt.
（Tx）连接速度BPS AVP属性类型24对为连接尝试选择的设施的速度进行编码。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The (Tx) Connect Speed BPS is a 4 octet value indicating the speed in bits per second.
（Tx）连接速度BPS是一个4个八位组的值，表示以位/秒为单位的速度。
When the optional Rx Connect Speed AVP is present, the value in this AVP represents the transmit connect speed, from the perspective of the LAC (e.g. data flowing from the LAC to the remote system). When the optional Rx Connect Speed AVP is NOT present, the connection speed between the remote system and LAC is assumed to be symmetric and is represented by the single value in this AVP.
当存在可选的Rx连接速度AVP时，该AVP中的值从LAC的角度表示传输连接速度（例如，从LAC流向远程系统的数据）。当可选的Rx连接速度AVP不存在时，远程系统和LAC之间的连接速度假定为对称的，并由该AVP中的单个值表示。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为10。
Rx Connect Speed (ICCN, OCCN)
接收连接速度（ICCN、OCCN）
The Rx Connect Speed AVP, Attribute Type 38, represents the speed of the connection from the perspective of the LAC (e.g. data flowing from the remote system to the LAC).
Rx Connect Speed AVP属性类型38从LAC的角度表示连接速度（例如，从远程系统到LAC的数据流）。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPS (H) | BPS (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BPS is a 4 octet value indicating the speed in bits per second.
BPS是一个4个八位字节的值，表示以比特/秒为单位的速度。
Presence of this AVP implies that the connection speed may be asymmetric with respect to the transmit connect speed given in the (Tx) Connect Speed AVP.
该AVP的存在意味着连接速度可能与（Tx）连接速度AVP中给出的传输连接速度不对称。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 10.
此AVP可能被隐藏（H位可能为1或0）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为10。
Physical Channel ID (ICRQ, OCRP)
物理通道ID（ICRQ、OCRP）
The Physical Channel ID AVP, Attribute Type 25, encodes the vendor specific physical channel number used for a call.
物理信道ID AVP属性类型25编码用于呼叫的特定于供应商的物理信道号。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Physical Channel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Physical Channel ID is a 4 octet value intended to be used for logging purposes only.
物理通道ID是一个4个八位字节的值，仅用于记录目的。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为10。
Private Group ID (ICCN)
专用组ID（ICCN）
The Private Group ID AVP, Attribute Type 37, is used by the LAC to indicate that this call is to be associated with a particular customer group.
LAC使用私有组ID AVP（属性类型37）来指示该呼叫将与特定客户组相关联。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Group ID ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Private Group ID is a string of octets of arbitrary length.
私有组ID是任意长度的八位字节字符串。
The LNS MAY treat the PPP session as well as network traffic through this session in a special manner determined by the peer. For example, if the LNS is individually connected to several private networks using unregistered addresses, this AVP may be included by the LAC to indicate that a given call should be associated with one of the private networks.
LNS可以以对等方确定的特殊方式处理PPP会话以及通过该会话的网络流量。例如，如果LNS使用未注册的地址单独连接到多个专用网络，则LAC可包括该AVP以指示给定呼叫应与专用网络之一相关联。
The Private Group ID is a string corresponding to a table in the LNS that defines the particular characteristics of the selected group. A LAC MAY determine the Private Group ID from a RADIUS response, local configuration, or some other source.
专用组ID是与LNS中定义所选组的特定特征的表相对应的字符串。LAC可以从RADIUS响应、本地配置或某些其他源确定专用组ID。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Private Group ID.
此AVP可能被隐藏（H位可能为1或0）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上专用组ID的长度。
Sequencing Required (ICCN, OCCN)
需要排序（ICCN、OCCN）
The Sequencing Required AVP, Attribute Type 39, indicates to the LNS that Sequence Numbers MUST always be present on the data channel.
序列所需AVP属性类型39向LNS指示序列号必须始终存在于数据通道上。
This AVP has no Attribute Value field.
此AVP没有属性值字段。
This AVP MUST NOT be hidden (the H-bit MUST be 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 6.
不得隐藏此AVP（H位必须为0）。此AVP的M位必须设置为1。这个AVP的长度是6。
The LAC may have answered the call and negotiated LCP with the remote system, perhaps in order to establish the system's apparent identity. In this case, these AVPs may be included to indicate the
LAC可能已经应答呼叫并与远程系统协商LCP，可能是为了确定系统的表面身份。在这种情况下，可以包括这些avp以指示
link properties the remote system initially requested, properties the remote system and LAC ultimately negotiated, as well as PPP authentication information sent and received by the LAC. This information may be used to initiate the PPP LCP and authentication systems on the LNS, allowing PPP to continue without renegotiation of LCP. Note that the LNS policy may be to enter an additional round of LCP negotiation and/or authentication if the LAC is not trusted.
远程系统最初请求的链路属性、远程系统和LAC最终协商的属性，以及LAC发送和接收的PPP认证信息。该信息可用于启动LNS上的PPP LCP和认证系统，允许PPP在不重新协商LCP的情况下继续。注意，如果LAC不受信任，LNS策略可能会进入另一轮LCP协商和/或身份验证。
Initial Received LCP CONFREQ (ICCN)
初始收到的LCP确认请求（ICCN）
In the Initial Received LCP CONFREQ AVP, Attribute Type 26, provides the LNS with the Initial CONFREQ received by the LAC from the PPP Peer.
在初始接收的LCP CONFREQ AVP中，属性类型26向LN提供LAC从PPP对等方接收的初始CONFREQ。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCP CONFREQ is a copy of the body of the initial CONFREQ received, starting at the first option within the body of the LCP message.
LCP CONFREQ是收到的初始CONFREQ正文的副本，从LCP消息正文内的第一个选项开始。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上CONFREQ的长度。
Last Sent LCP CONFREQ (ICCN)
上次发送的LCP确认请求（ICCN）
In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS with the Last CONFREQ sent by the LAC to the PPP Peer.
在最后发送的LCP CONFREQ AVP中，属性类型27向LNS提供LAC向PPP对等方发送的最后一个CONFREQ。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ sent to the client to complete LCP negotiation, starting at the first option within the body of the LCP message.
LCP CONFREQ是发送给客户机以完成LCP协商的最终CONFREQ主体的副本，从LCP消息主体内的第一个选项开始。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上CONFREQ的长度。
Last Received LCP CONFREQ (ICCN)
上次收到的LCP确认请求（ICCN）
The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the LNS with the Last CONFREQ received by the LAC from the PPP Peer.
最后接收到的LCP CONFREQ AVP属性类型为28，为LNS提供LAC从PPP对等方接收到的最后一个CONFREQ。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LCP CONFREQ... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LCP CONFREQ is a copy of the body of the final CONFREQ received from the client to complete LCP negotiation, starting at the first option within the body of the LCP message.
LCP CONFREQ是从客户端接收的最终CONFREQ主体的副本，用于完成LCP协商，从LCP消息主体内的第一个选项开始。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the CONFREQ.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上CONFREQ的长度。
Proxy Authen Type (ICCN)
代理授权类型（ICCN）
The Proxy Authen Type AVP, Attribute Type 29, determines if proxy authentication should be used.
代理身份验证类型AVP属性类型29确定是否应使用代理身份验证。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Type is a 2 octet unsigned integer, holding:
Authen类型是2个八位无符号整数，包含：
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为8。
Defined Authen Type values are: 0 - Reserved 1 - Textual username/password exchange 2 - PPP CHAP 3 - PPP PAP 4 - No Authentication 5 - Microsoft CHAP Version 1 (MSCHAPv1)
定义的身份验证类型值为：0-保留1-文本用户名/密码交换2-PPP CHAP 3-PPP PAP 4-无身份验证5-Microsoft CHAP版本1（MSCHAPv1）
This AVP MUST be present if proxy authentication is to be utilized. If it is not present, then it is assumed that this peer cannot perform proxy authentication, requiring a restart of the authentication phase at the LNS if the client has already entered this phase with the LAC (which may be determined by the Proxy LCP AVP if present).
如果要使用代理身份验证，则必须存在此AVP。如果不存在，则假定该对等方无法执行代理身份验证，如果客户端已使用LAC进入该阶段（如果存在，可由代理LCP AVP确定），则需要在LNS处重新启动身份验证阶段。
Associated AVPs for each type of authentication follow.
以下是每种认证类型的关联AVP。
Proxy Authen Name (ICCN)
代理作者名称（ICCN）
The Proxy Authen Name AVP, Attribute Type 30, specifies the name of the authenticating client when using proxy authentication.
代理身份验证名称AVP属性类型30指定使用代理身份验证时身份验证客户端的名称。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authen Name... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authen Name is a string of octets of arbitrary length. It contains the name specified in the client's authentication response.
Authen Name是任意长度的八位字节字符串。它包含客户端身份验证响应中指定的名称。
This AVP MUST be present in messages containing a Proxy Authen Type AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to employ AVP hiding for obscuring the cleartext name.
此AVP必须出现在包含Authen类型为1、2、3或5的代理Authen类型AVP的邮件中。可能需要使用AVP隐藏来隐藏明文名称。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) is 6 plus the length of the cleartext name.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。长度（隐藏前）是6加上明文名称的长度。
Proxy Authen Challenge (ICCN)
代理授权挑战（ICCN）
The Proxy Authen Challenge AVP, Attribute Type 31, specifies the challenge sent by the LAC to the PPP Peer, when using proxy authentication.
代理身份验证质询AVP属性类型31指定使用代理身份验证时LAC向PPP对等方发送的质询。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Challenge is a string of one or more octets.
挑战是一个由一个或多个八位字节组成的字符串。
This AVP MUST be present for Proxy Authen Types 2 and 5. The Challenge field contains the CHAP challenge presented to the client by the LAC.
对于代理身份验证类型2和5，必须存在此AVP。质询字段包含LAC提交给客户端的CHAP质询。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6, plus the length of the Challenge.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6，加上挑战的长度。
Proxy Authen ID (ICCN)
代理作者ID（ICCN）
The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of the PPP Authentication that was started between the LAC and the PPP Peer, when proxy authentication is being used.
代理身份验证ID AVP属性类型32指定在使用代理身份验证时在LAC和PPP对等方之间启动的PPP身份验证的ID值。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID is a 2 octet unsigned integer, the most significant octet MUST be 0.
ID是2个八位无符号整数，最高有效八位必须为0。
The Proxy Authen ID AVP MUST be present for Proxy authen types 2, 3 and 5. For 2 and 5, the ID field contains the byte ID value presented to the client by the LAC in its Challenge. For 3, it is the Identifier value of the Authenticate-Request.
代理身份验证类型2、3和5必须存在代理身份验证ID AVP。对于2和5，ID字段包含LAC在其质询中提供给客户端的字节ID值。对于3，它是身份验证请求的标识符值。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。
Proxy Authen Response (ICCN)
代理授权响应（ICCN）
The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP Authentication response received by the LAC from the PPP Peer, when proxy authentication is used.
当使用代理身份验证时，代理身份验证响应AVP属性类型33指定LAC从PPP对等方接收的PPP身份验证响应。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response... (arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Response is a string of octets.
响应是一串八位字节。
This AVP MUST be present for Proxy authen types 1, 2, 3 and 5. The Response field contains the client's response to the challenge. For Proxy authen types 2 and 5, this field contains the response value received by the LAC. For types 1 or 3, it contains the clear text password received from the client by the LAC. In the case of cleartext passwords, AVP hiding is recommended.
对于代理身份验证类型1、2、3和5，必须存在此AVP。响应字段包含客户端对质询的响应。对于代理身份验证类型2和5，此字段包含LAC接收的响应值。对于类型1或3，它包含LAC从客户端接收的明文密码。对于明文密码，建议使用AVP隐藏。
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 plus the length of the Response.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。此AVP的长度（隐藏前）为6加上响应的长度。
Call Errors (WEN)
呼叫错误（文）
The Call Errors AVP, Attribute Type 34, is used by the LAC to send error information to the LNS.
LAC使用呼叫错误AVP属性类型34向LNS发送错误信息。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CRC Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors (L) | Framing Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors (L) | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CRC Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC Errors (L) | Framing Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Framing Errors (L) | Hardware Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns (L) | Buffer Overruns (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns (L) | Time-out Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-out Errors (L) | Alignment Errors (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
定义了以下字段：
Reserved - Not used, MUST be 0 CRC Errors - Number of PPP frames received with CRC errors since call was established Framing Errors - Number of improperly framed PPP packets received Hardware Overruns - Number of receive buffer over-runs since call was established Buffer Overruns - Number of buffer over-runs detected since call was established Time-out Errors - Number of time-outs since call was established Alignment Errors - Number of alignment errors since call was established
保留-未使用，必须为0 CRC错误-自呼叫建立以来接收到的带有CRC错误的PPP帧数帧错误-接收到的不正确帧PPP数据包数硬件溢出-自呼叫建立以来接收缓冲区溢出数缓冲区溢出-自呼叫建立超时错误以来检测到的缓冲区溢出数-自呼叫建立以来的超时数校准错误-自呼叫建立以来的校准错误数
This AVP may be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 32.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为1。此AVP的长度（隐藏前）为32。
ACCM (SLI)
会计科目经理（SLI）
The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of the ACCM negotiated with the PPP Peer by the LNS.
LNS使用属性类型为35的ACCM AVP通知LAC LNS与PPP对等方协商的ACCM。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Send ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Send ACCM (L) | Receive ACCM (H) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive ACCM (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Send ACCM and Receive ACCM are each 4 octet values preceded by a 2 octet reserved quantity. The send ACCM value should be used by the LAC to process packets it sends on the connection. The receive ACCM value should be used by the LAC to process incoming packets on the connection. The default values used by the LAC for both these fields are 0xFFFFFFFF. The LAC should honor these fields unless it has specific configuration information to indicate that the requested mask must be modified to permit operation.
Send ACCM和Receive ACCM各为4个八位字节值，前面有2个八位字节的保留数量。LAC应使用send ACCM值来处理其在连接上发送的数据包。LAC应使用receive ACCM值来处理连接上的传入数据包。LAC对这两个字段使用的默认值均为0xFFFFFF。LAC应遵守这些字段，除非其具有特定的配置信息，表明必须修改请求的掩码以允许操作。
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST be set to 1. The Length of this AVP is 16.
此AVP可能被隐藏（H位可能为1或0）。此AVP的M位必须设置为1。这个AVP的长度是16。
The necessary setup for tunneling a PPP session with L2TP consists of two steps, (1) establishing the Control Connection for a Tunnel, and (2) establishing a Session as triggered by an incoming or outgoing call request. The Tunnel and corresponding Control Connection MUST be established before an incoming or outgoing call is initiated. An L2TP Session MUST be established before L2TP can begin to tunnel PPP frames. Multiple Sessions may exist across a single Tunnel and multiple Tunnels may exist between the same LAC and LNS.
使用L2TP隧道PPP会话的必要设置包括两个步骤，（1）建立隧道的控制连接，（2）建立由传入或传出呼叫请求触发的会话。在发起传入或传出呼叫之前，必须建立隧道和相应的控制连接。在L2TP可以开始隧道PPP帧之前，必须建立L2TP会话。单个隧道中可能存在多个会话，同一LAC和LN之间可能存在多个隧道。
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
+-----+ +-----+
| |~~~~~~~~~~L2TP Tunnel~~~~~~~~~~| |
| LAC | | LNS |
| #######Control Connection######## |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
[Remote] | | | |
[System]------Call----------*============L2TP Session=============* |
PPP +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| | | |
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| |
+-----+ +-----+
Figure 5.1 Tunneling PPP
图5.1隧道PPP
The Control Connection is the initial connection that must be achieved between an LAC and LNS before sessions may be brought up. Establishment of the control connection includes securing the identity of the peer, as well as identifying the peer's L2TP version, framing, and bearer capabilities, etc.
控制连接是在启动会话之前必须在LAC和LN之间实现的初始连接。控制连接的建立包括保护对等方的身份，以及识别对等方的L2TP版本、帧和承载能力等。
A three message exchange is utilized to setup the control connection. Following is a typical message exchange:
三条消息交换用于设置控制连接。以下是典型的消息交换：
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
LAC or LNS LAC or LNS
---------- ----------
SCCRQ ->
<- SCCRP
SCCCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
如果队列中没有其他消息等待该对等方，则发送ZLB ACK。
L2TP incorporates a simple, optional, CHAP-like [RFC1994] tunnel authentication system during control connection establishment. If an LAC or LNS wishes to authenticate the identity of the peer it is contacting or being contacted by, a Challenge AVP is included in the SCCRQ or SCCRP message. If a Challenge AVP is received in an SCCRQ or SCCRP, a Challenge Response AVP MUST be sent in the following SCCRP or SCCCN, respectively. If the expected response and response received from a peer does not match, establishment of the tunnel MUST be disallowed.
L2TP在控制连接建立过程中集成了一个简单、可选、类似CHAP的[RFC1994]隧道身份验证系统。如果LAC或LNS希望验证其正在联系或正在联系的对等方的身份，则SCCRQ或SCCRP消息中包含质询AVP。如果在SCCRQ或SCCRP中收到质询AVP，则质询响应AVP必须分别在以下SCCRP或SCCCN中发送。如果预期响应与从对等方收到的响应不匹配，则必须禁止建立隧道。
To participate in tunnel authentication, a single shared secret MUST exist between the LAC and LNS. This is the same shared secret used for AVP hiding (see Section 4.3). See Section 4.4.3 for details on construction of the Challenge and Response AVPs.
要参与隧道身份验证，LAC和LN之间必须存在单个共享密钥。这与用于AVP隐藏的共享秘密相同（参见第4.3节）。有关挑战和响应AVP构建的详细信息，请参见第4.4.3节。
After successful control connection establishment, individual sessions may be created. Each session corresponds to single PPP stream between the LAC and LNS. Unlike control connection establishment, session establishment is directional with respect to the LAC and LNS. The LAC requests the LNS to accept a session for an incoming call, and the LNS requests the LAC to accept a session for placing an outgoing call.
成功建立控制连接后，可以创建单独的会话。每个会话对应于LAC和LN之间的单个PPP流。与控制连接建立不同，会话建立相对于LAC和LN是定向的。LAC请求LNS接受用于传入呼叫的会话，LNS请求LAC接受用于放置传出呼叫的会话。
A three message exchange is employed to setup the session. Following is a typical sequence of events:
使用三条消息交换来设置会话。以下是一系列典型的事件：
LAC LNS
--- ---
(Call
Detected)
LAC LNS
--- ---
(Call
Detected)
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
ICRQ ->
<- ICRP
ICCN ->
<- ZLB ACK
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
如果队列中没有其他消息等待该对等方，则发送ZLB ACK。
A three message exchange is employed to setup the session. Following is a typical sequence of events:
使用三条消息交换来设置会话。以下是一系列典型的事件：
LAC LNS
--- ---
<- OCRQ
OCRP ->
LAC LNS
--- ---
<- OCRQ
OCRP ->
(Perform Call Operation)
（执行呼叫操作）
OCCN -> <- ZLB ACK
OCCN-><-ZLB确认
The ZLB ACK is sent if there are no further messages waiting in queue for that peer.
如果队列中没有其他消息等待该对等方，则发送ZLB ACK。
Once tunnel establishment is complete, PPP frames from the remote system are received at the LAC, stripped of CRC, link framing, and transparency bytes, encapsulated in L2TP, and forwarded over the appropriate tunnel. The LNS receives the L2TP packet, and processes the encapsulated PPP frame as if it were received on a local PPP interface.
隧道建立完成后，LAC接收来自远程系统的PPP帧，去除CRC、链路帧和透明字节，封装在L2TP中，并通过适当的隧道转发。LNS接收L2TP数据包，并处理封装的PPP帧，就好像它是在本地PPP接口上接收的一样。
The sender of a message associated with a particular session and tunnel places the Session ID and Tunnel ID (specified by its peer) in the Session ID and Tunnel ID header for all outgoing messages. In this manner, PPP frames are multiplexed and demultiplexed over a single tunnel between a given LNS-LAC pair. Multiple tunnels may exist between a given LNS-LAC pair, and multiple sessions may exist within a tunnel.
与特定会话和隧道关联的消息的发送方将会话ID和隧道ID（由其对等方指定）放置在所有传出消息的会话ID和隧道ID标头中。以这种方式，PPP帧通过给定LNS-LAC对之间的单个隧道被多路复用和解多路复用。给定LNS-LAC对之间可能存在多个隧道，并且隧道内可能存在多个会话。
The value of 0 for Session ID and Tunnel ID is special and MUST NOT be used as an Assigned Session ID or Assigned Tunnel ID. For the cases where a Session ID has not yet been assigned by the peer (i.e., during establishment of a new session or tunnel), the Session ID field MUST be sent as 0, and the Assigned Session ID AVP within the message MUST be used to identify the session. Similarly, for cases where the Tunnel ID has not yet been assigned from the peer, the Tunnel ID MUST be sent as 0 and Assigned Tunnel ID AVP used to identify the tunnel.
会话ID和隧道ID的值0是特殊的，不得用作分配的会话ID或分配的隧道ID。对于对等方尚未分配会话ID的情况（即，在建立新会话或隧道期间），会话ID字段必须作为0发送，必须使用消息中分配的会话ID AVP来标识会话。类似地，对于尚未从对等方分配隧道ID的情况，必须将隧道ID作为0发送，并分配用于识别隧道的隧道ID AVP。
Sequence numbers are defined in the L2TP header for control messages and optionally for data messages (see Section 3.1). These are used to provide a reliable control message transport (see Section 5.8) and optional data message sequencing. Each peer maintains separate sequence numbers for the control connection and each individual data session within a tunnel.
L2TP报头中定义了控制消息和数据消息的序列号（可选）（见第3.1节）。这些用于提供可靠的控制消息传输（见第5.8节）和可选的数据消息顺序。每个对等方为控制连接和隧道内的每个单独数据会话维护单独的序列号。
Unlike the L2TP control channel, the L2TP data channel does not use sequence numbers to retransmit lost data messages. Rather, data messages may use sequence numbers to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. The LAC may request that sequence numbers be present in data messages via the Sequencing Required AVP (see Section 4.4.6). If this AVP is present during session setup, sequence numbers MUST be present at all times. If this AVP is not present, sequencing presence is under control of the LNS. The LNS controls enabling and disabling of sequence numbers by sending a data message with or without sequence numbers present at any time during the life of a session. Thus, if the LAC receives a data message without sequence numbers present, it MUST stop sending sequence numbers in future data messages. If the LAC receives a data message with sequence numbers present, it MUST begin sending sequence numbers in future outgoing data messages. If the LNS enables sequencing after disabling it earlier in the session, the sequence number state picks up where it left off before.
与L2TP控制信道不同，L2TP数据信道不使用序列号来重新传输丢失的数据消息。相反，数据消息可以使用序列号来检测丢失的分组和/或恢复在传输期间可能已重新排序的分组的原始序列。LAC可通过排序要求的AVP（见第4.4.6节）请求在数据消息中显示序号。如果会话设置期间存在此AVP，则序列号必须始终存在。如果该AVP不存在，则序列存在由LNS控制。LNS通过在会话期间的任何时间发送带有或不带序列号的数据消息来控制序列号的启用和禁用。因此，如果LAC接收到不存在序列号的数据消息，它必须在未来的数据消息中停止发送序列号。如果LAC接收到序列号存在的数据消息，则必须在未来传出的数据消息中开始发送序列号。如果LNS在会话早期禁用序列号后启用序列号，则序列号状态将在之前停止的位置出现。
The LNS may initiate disabling of sequencing at any time during the session (including the first data message sent). It is recommended that for connections where reordering or packet loss may occur, sequence numbers always be enabled during the initial negotiation stages of PPP and disabled only when and if the risk is considered acceptable. For example, if the PPP session being tunneled is not utilizing any stateful compression or encryption protocols and is only carrying IP (as determined by the PPP NCPs that are established), then the LNS might decide to disable sequencing as IP is tolerant to datagram loss and reordering.
LNS可在会话期间的任何时间（包括发送的第一条数据消息）启动序列禁用。建议对于可能发生重新排序或数据包丢失的连接，在PPP的初始协商阶段始终启用序列号，并且只有在认为风险可接受时才禁用序列号。例如，如果正在隧道中的PPP会话未使用任何有状态压缩或加密协议，并且仅承载IP（由建立的PPP NCP确定），则LNS可能决定禁用排序，因为IP容忍数据报丢失和重新排序。
A keepalive mechanism is employed by L2TP in order to differentiate tunnel outages from extended periods of no control or data activity on a tunnel. This is accomplished by injecting Hello control messages (see Section 6.5) after a specified period of time has elapsed since the last data or control message was received on a tunnel. As for any other control message, if the Hello message is not reliably delivered then the tunnel is declared down and is reset. The transport reset
L2TP采用keepalive机制，以区分隧道中断和隧道上长时间无控制或数据活动。这是通过在隧道上接收到最后一个数据或控制消息后的指定时间段后注入Hello控制消息（见第6.5节）来实现的。对于任何其他控制消息，如果Hello消息没有可靠地传递，那么隧道将被声明为关闭并重置。传输重置
mechanism along with the injection of Hello messages ensures that a connectivity failure between the LNS and the LAC will be detected at both ends of a tunnel.
机制以及Hello消息的注入确保在隧道的两端检测到LNS和LAC之间的连接故障。
Session teardown may be initiated by either the LAC or LNS and is accomplished by sending a CDN control message. After the last session is cleared, the control connection MAY be torn down as well (and typically is). Following is an example of a typical control message exchange:
会话拆卸可由LAC或LN启动，并通过发送CDN控制消息来完成。在最后一个会话被清除后，控制连接也可能被断开（通常是断开）。以下是典型控制消息交换的示例：
LAC or LNS LAC or LNS
LAC或LNS LAC或LNS
CDN -> (Clean up)
CDN->（清理）
<- ZLB ACK (Clean up)
<-ZLB确认（清理）
Control connection teardown may be initiated by either the LAC or LNS and is accomplished by sending a single StopCCN control message. The receiver of a StopCCN MUST send a ZLB ACK to acknowledge receipt of the message and maintain enough control connection state to properly accept StopCCN retransmissions over at least a full retransmission cycle (in case the ZLB ACK is lost). The recommended time for a full retransmission cycle is 31 seconds (see section 5.8). Following is an example of a typical control message exchange:
控制连接断开可由LAC或LNS启动，并通过发送单个StopCCN控制消息来完成。StopCCN的接收器必须发送ZLB ACK以确认消息的接收，并保持足够的控制连接状态，以便在至少一个完整的重传周期内（在ZLB ACK丢失的情况下）正确接受StopCCN重传。完整重传周期的建议时间为31秒（见第5.8节）。以下是典型控制消息交换的示例：
LAC or LNS LAC or LNS
LAC或LNS LAC或LNS
StopCCN -> (Clean up)
StopCCN->（清理）
<- ZLB ACK (Wait) (Clean up)
<-ZLB确认（等待）（清理）
An implementation may shut down an entire tunnel and all sessions on the tunnel by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole tunnel.
实现可以通过发送StopCCN关闭整个隧道和隧道上的所有会话。因此，在拆除整个隧道时，无需单独清除每个会话。
L2TP provides a lower level reliable transport service for all control messages. The Nr and Ns fields of the control message header (see section 3.1) belong to this transport. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control message is a sliding window transport that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for the control connection within a tunnel.
L2TP为所有控制消息提供较低级别的可靠传输服务。控制消息头的Nr和Ns字段（见第3.1节）属于此传输。L2TP的上层功能与控制消息的重传或排序无关。可靠控制消息是提供控制消息重传和拥塞控制的滑动窗口传输。每个对等方为隧道内的控制连接维护单独的序列号状态。
The message sequence number, Ns, begins at 0. Each subsequent message is sent with the next increment of the sequence number. The sequence number is thus a free running counter represented modulo 65536. The sequence number in the header of a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32767 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered a duplicate of a message already received and ignored from processing. However, in order to ensure that all messages are acknowledged properly (particularly in the case of a lost ZLB ACK message), receipt of duplicate messages MUST be acknowledged by the reliable transport. This acknowledgement may either piggybacked on a message in queue, or explicitly via a ZLB ACK.
消息序列号Ns从0开始。每个后续消息都会随序列号的下一个增量一起发送。因此，序列号是以65536模表示的自由运行计数器。如果接收到的消息头中的序列号的值位于上次接收的序列号和之前的32767值（包括）的范围内，则认为该序列号小于或等于上次接收的序列号。例如，如果最后收到的序列号是15，则序列号为0到15以及32784到65535的消息将被视为小于或等于。这样的消息将被视为已接收消息的副本，并在处理过程中被忽略。但是，为了确保正确确认所有消息（特别是在ZLB ACK消息丢失的情况下），可靠传输必须确认收到重复消息。该确认可以在队列中的消息上进行，也可以显式地通过ZLB确认。
All control messages take up one slot in the control message sequence number space, except the ZLB acknowledgement. Thus, Ns is not incremented after a ZLB message is sent.
除ZLB确认外，所有控制消息占用控制消息序列号空间中的一个插槽。因此，在发送ZLB消息后，Ns不会增加。
The last received message number, Nr, is used to acknowledge messages received by an L2TP peer. It contains the sequence number of the message the peer expects to receive next (e.g. the last Ns of a non-ZLB message received plus 1, modulo 65536). While the Nr in a received ZLB is used to flush messages from the local retransmit queue (see below), Nr of the next message sent is not be updated by the Ns of the ZLB.
最后接收到的消息编号Nr用于确认L2TP对等方接收到的消息。它包含对等方预期下一次接收的消息的序列号（例如，接收到的非ZLB消息的最后N加1，模65536）。虽然接收到的ZLB中的Nr用于刷新来自本地重传队列的消息（见下文），但ZLB的Ns不会更新下一条发送的消息的Nr。
The reliable transport at a receiving peer is responsible for making sure that control messages are delivered in order and without duplication to the upper level. Messages arriving out of order may be queued for in-order delivery when the missing messages are received, or they may be discarded requiring a retransmission by the peer.
接收端的可靠传输负责确保控制消息按顺序传递，并且不会复制到上层。当接收到丢失的消息时，无序到达的消息可能会排队等待顺序传递，或者它们可能会被丢弃，需要对等方重新传输。
Each tunnel maintains a queue of control messages to be transmitted to its peer. The message at the front of the queue is sent with a given Ns value, and is held until a control message arrives from the peer in which the Nr field indicates receipt of this message. After a period of time (a recommended default is 1 second) passes without acknowledgement, the message is retransmitted. The retransmitted message contains the same Ns value, but the Nr value MUST be updated with the sequence number of the next expected message.
每个隧道维护一个控制消息队列，以将其传输到对等方。队列前端的消息以给定的Ns值发送，并一直保持，直到来自对等方的控制消息到达，其中Nr字段表示收到该消息。在经过一段时间（建议默认值为1秒）而没有确认后，消息将被重新传输。重新传输的消息包含相同的Ns值，但Nr值必须用下一个预期消息的序列号更新。
Each subsequent retransmission of a message MUST employ an exponential backoff interval. Thus, if the first retransmission occurred after 1 second, the next retransmission should occur after 2 seconds has elapsed, then 4 seconds, etc. An implementation MAY place a cap upon the maximum interval between retransmissions. This cap MUST be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions, (a recommended default is 5, but SHOULD be configurable), the tunnel and all sessions within MUST be cleared.
消息的每个后续重传必须采用指数退避间隔。因此，如果第一次重传发生在1秒之后，那么下一次重传应该发生在2秒之后，然后是4秒，以此类推。一个实现可以对重传之间的最大间隔设置上限。每次重传的上限不得小于8秒。如果在多次重新传输后未检测到对等响应（建议默认值为5，但应可配置），则必须清除隧道和其中的所有会话。
When a tunnel is being shut down for reasons other than loss of connectivity, the state and reliable delivery mechanisms MUST be maintained and operated for the full retransmission interval after the final message exchange has occurred.
当隧道因连接丢失以外的原因关闭时，必须在发生最终消息交换后的整个重传间隔内维护和运行状态和可靠传递机制。
A sliding window mechanism is used for control message transmission. Consider two peers A & B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP messages. B is now allowed to have up to N outstanding control messages. Once N have been sent, it must wait for an acknowledgment that advances the window before sending new control messages. An implementation may support a receive window of only 1 (i.e., by sending out a Receive Window Size AVP with a value of 1), but MUST accept a window of up to 4 from its peer (e.g. have the ability to send 4 messages before backing off). A value of 0 for the Receive Window Size AVP is invalid.
滑动窗口机构用于控制信息传输。考虑两个对等点A和B。假设A指定一个接收窗口大小的AVP，该值在SCCRQ或SCCRP消息中具有N值。B现在最多允许有N条未完成的控制消息。一旦N被发送，它必须在发送新的控制消息之前等待提前窗口的确认。一个实现可能只支持1的接收窗口（即，通过发送值为1的接收窗口大小AVP），但必须从其对等方接受最多4个窗口（例如，能够在后退之前发送4条消息）。接收窗口大小AVP的值0无效。
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. The recommended procedure for this is described in Appendix A.
在重新传输控制消息时，应使用慢速启动和拥塞避免窗口调整程序。附录A中描述了推荐的程序。
A peer MUST NOT withhold acknowledgment of messages as a technique for flow controlling control messages. An L2TP implementation is expected to be able to keep up with incoming control messages, possibly responding to some with errors reflecting an inability to honor the requested action.
对等方不得保留消息确认作为流控制消息的技术。L2TP实现预计能够跟上传入的控制消息，可能会响应一些错误，反映出无法执行请求的操作。
Appendix B contains examples of control message transmission, acknowledgement, and retransmission.
附录B包含控制消息传输、确认和重传的示例。
The following control connection messages are used to establish, clear and maintain L2TP tunnels. All data is sent in network order (high order octets first). Any "reserved" or "empty" fields MUST be sent as 0 values to allow for protocol extensibility.
以下控制连接消息用于建立、清除和维护L2TP隧道。所有数据以网络顺序发送（高阶八位字节优先）。任何“保留”或“空”字段必须作为0值发送，以允许协议扩展。
Start-Control-Connection-Request (SCCRQ) is a control message used to initialize a tunnel between an LNS and an LAC. It is sent by either the LAC or the LNS to being the tunnel establishment process.
启动控制连接请求（SCCRQ）是用于初始化LNS和LAC之间隧道的控制消息。LAC或LNS将其发送至隧道建立过程。
The following AVPs MUST be present in the SCCRQ:
以下AVP必须存在于SCCRQ中：
Message Type AVP Protocol Version Host Name Framing Capabilities Assigned Tunnel ID
已分配隧道ID的消息类型AVP协议版本主机名成帧功能
The Following AVPs MAY be present in the SCCRQ:
SCCRQ中可能存在以下AVP：
Bearer Capabilities Receive Window Size Challenge Tie Breaker Firmware Revision Vendor Name
承载能力接收窗口大小挑战绑定断路器固件版本供应商名称
Start-Control-Connection-Reply (SCCRP) is a control message sent in reply to a received SCCRQ message. SCCRP is used to indicate that the SCCRQ was accepted and establishment of the tunnel should continue.
启动控制连接回复（SCCRP）是一条为回复收到的SCCRQ消息而发送的控制消息。SCCRP用于表明SCCRQ已被接受，隧道应继续修建。
The following AVPs MUST be present in the SCCRP:
SCCRP中必须存在以下AVP：
Message Type Protocol Version Framing Capabilities Host Name Assigned Tunnel ID
消息类型协议版本成帧功能主机名分配的隧道ID
The following AVPs MAY be present in the SCCRP:
SCCRP中可能存在以下AVP：
Bearer Capabilities Firmware Revision Vendor Name Receive Window Size Challenge Challenge Response
承载能力固件版本供应商名称接收窗口大小挑战响应
Start-Control-Connection-Connected (SCCCN) is a control message sent in reply to an SCCRP. SCCCN completes the tunnel establishment process.
已连接的启动控制连接（SCCCN）是为响应SCCRP而发送的控制消息。SCCCN完成隧道建立过程。
The following AVP MUST be present in the SCCCN:
以下AVP必须存在于SCCCN中：
Message Type
消息类型
The following AVP MAY be present in the SCCCN:
SCCCN中可能存在以下AVP：
Challenge Response
挑战响应
Stop-Control-Connection-Notification (StopCCN) is a control message sent by either the LAC or LNS to inform its peer that the tunnel is being shutdown and the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit call control messages). The reason for issuing this request is indicated in the Result Code AVP. There is no explicit reply to the message, only the implicit ACK that is received by the reliable control message transport layer.
停止控制连接通知（StopCCN）是由LAC或LNS发送的控制消息，用于通知其对等方隧道正在关闭且控制连接应关闭。此外，隐式清除所有活动会话（不发送任何显式呼叫控制消息）。发出此请求的原因在结果代码AVP中指明。没有对消息的显式回复，只有可靠控制消息传输层接收的隐式ACK。
The following AVPs MUST be present in the StopCCN:
StopCCN中必须存在以下AVP：
Message Type Assigned Tunnel ID Result Code
消息类型分配的隧道ID结果代码
The Hello (HELLO) message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a "keepalive" for the tunnel.
Hello（Hello）消息是由LAC-LNS控制连接的任一对等方发送的L2TP控制消息。此控制消息用作隧道的“keepalive”。
The sending of HELLO messages and the policy for sending them are left up to the implementation. A peer MUST NOT expect HELLO messages at any time or interval. As with all messages sent on the control connection, the receiver will return either a ZLB ACK or an (unrelated) message piggybacking the necessary acknowledgement information.
HELLO消息的发送和发送策略由实现决定。对等方在任何时间或间隔都不能期望收到HELLO消息。与控制连接上发送的所有消息一样，接收器将返回ZLB ACK或（不相关的）消息，其中包含必要的确认信息。
Since a HELLO is a control message, and control messages are reliably sent by the lower level transport, this keepalive function operates by causing the transport level to reliably deliver a message. If a media interruption has occurred, the reliable transport will be unable to deliver the HELLO across, and will clean up the tunnel.
由于HELLO是一条控制消息，并且控制消息由较低级别的传输可靠地发送，因此此keepalive函数通过使传输级别可靠地发送消息来运行。如果发生媒体中断，可靠的传输将无法传递HELLO，并将清理隧道。
Keepalives for the tunnel MAY be implemented by sending a HELLO if a period of time (a recommended default is 60 seconds, but SHOULD be configurable) has passed without receiving any message (data or control) from the peer.
如果一段时间（建议的默认值为60秒，但应可配置）已经过去而没有从对等方接收任何消息（数据或控制），则可以通过发送HELLO来实现隧道的Keepalives。
HELLO messages are global to the tunnel. The Session ID in a HELLO message MUST be 0.
HELLO消息是隧道的全局消息。HELLO消息中的会话ID必须为0。
The Following AVP MUST be present in the HELLO message:
以下AVP必须出现在HELLO消息中：
Message Type
消息类型
Incoming-Call-Request (ICRQ) is a control message sent by the LAC to the LNS when an incoming call is detected. It is the first in a three message exchange used for establishing a session within an L2TP tunnel.
传入呼叫请求（ICRQ）是当检测到传入呼叫时，LAC向LNS发送的控制消息。它是用于在L2TP隧道中建立会话的三条消息交换中的第一条。
ICRQ is used to indicate that a session is to be established between the LAC and LNS for this call and provides the LNS with parameter information for the session. The LAC may defer answering the call until it has received an ICRP from the LNS indicating that the session should be established. This mechanism allows the LNS to obtain sufficient information about the call before determining whether it should be answered or not. Alternatively, the LAC may answer the call, negotiate LCP and PPP authentication, and use the information gained to choose the LNS. In this case, the call has already been answered by the time the ICRP message is received; the LAC simply spoofs the "call indication" and "call answer" steps in this case.
ICRQ用于指示将在LAC和LNS之间为此呼叫建立会话，并向LNS提供会话的参数信息。拉丁美洲和加勒比海地区委员会可推迟接听电话，直到其收到来自LNS的ICRP指示应建立会话。此机制允许LN在确定是否应应答呼叫之前获取有关呼叫的充分信息。或者，LAC可以应答呼叫，协商LCP和PPP认证，并使用获得的信息来选择ln。在这种情况下，在收到ICRP电文时，呼叫已经应答；在这种情况下，LAC只是欺骗“呼叫指示”和“呼叫应答”步骤。
The following AVPs MUST be present in the ICRQ:
ICRQ中必须有以下AVP：
Message Type Assigned Session ID Call Serial Number
消息类型分配的会话ID呼叫序列号
The following AVPs MAY be present in the ICRQ:
ICRQ中可能存在以下AVP：
Bearer Type Physical Channel ID Calling Number Called Number Sub-Address
承载类型物理信道ID呼叫号码被叫号码子地址
Incoming-Call-Reply (ICRP) is a control message sent by the LNS to the LAC in response to a received ICRQ message. It is the second in the three message exchange used for establishing sessions within an L2TP tunnel.
传入呼叫应答（ICRP）是LNS向LAC发送的控制消息，以响应接收到的ICRQ消息。它是用于在L2TP隧道中建立会话的三种消息交换中的第二种。
ICRP is used to indicate that the ICRQ was successful and for the LAC to answer the call if it has not already done so. It also allows the LNS to indicate necessary parameters for the L2TP session.
ICRP用于表示ICRQ成功，如果LAC尚未接听电话，则由LAC接听。它还允许LN指示L2TP会话的必要参数。
The following AVPs MUST be present in the ICRP:
ICRP中必须有以下AVP：
Message Type Assigned Session ID
消息类型分配的会话ID
Incoming-Call-Connected (ICCN) is a control message sent by the LAC to the LNS in response to a received ICRP message. It is the third message in the three message exchange used for establishing sessions within an L2TP tunnel.
已连接的传入呼叫（ICCN）是LAC向LNS发送的控制消息，以响应收到的ICRP消息。它是三条消息交换中的第三条消息，用于在L2TP隧道中建立会话。
ICCN is used to indicate that the ICRP was accepted, the call has been answered, and that the L2TP session should move to the established state. It also provides additional information to the LNS about parameters used for the answered call (parameters that may not always available at the time the ICRQ is issued).
ICCN用于表示ICRP已被接受，呼叫已应答，L2TP会话应移到已建立状态。它还向LNS提供有关应答呼叫所用参数的附加信息（ICRQ发出时可能不总是可用的参数）。
The following AVPs MUST be present in the ICCN:
以下AVP必须存在于ICCN中：
Message Type (Tx) Connect Speed Framing Type
消息类型（Tx）连接速度帧类型
The following AVPs MAY be present in the ICCN:
以下AVP可能存在于ICCN中：
Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response Private Group ID Rx Connect Speed Sequencing Required
初始接收LCP CONFREQ上次发送LCP CONFREQ上次接收LCP CONFREQ代理验证类型代理验证名称代理验证质询代理验证ID代理验证响应专用组ID Rx连接速度排序必需
Outgoing-Call-Request (OCRQ) is a control message sent by the LNS to the LAC to indicate that an outbound call from the LAC is to be established. It is the first in a three message exchange used for establishing a session within an L2TP tunnel.
传出呼叫请求（OCRQ）是由LNS发送到LAC的控制消息，用于指示将建立来自LAC的出站呼叫。它是用于在L2TP隧道中建立会话的三条消息交换中的第一条。
OCRQ is used to indicate that a session is to be established between the LNS and LAC for this call and provides the LAC with parameter information for both the L2TP session, and the call that is to be placed
OCRQ用于指示将在LNS和LAC之间为此呼叫建立会话，并为LAC提供L2TP会话和将要进行的呼叫的参数信息
An LNS MUST have received a Bearer Capabilities AVP during tunnel establishment from an LAC in order to request an outgoing call to that LAC.
LNS必须在隧道建立期间从LAC接收到承载能力AVP，以便向该LAC请求传出呼叫。
The following AVPs MUST be present in the OCRQ:
OCRQ中必须存在以下AVP：
Message Type Assigned Session ID Call Serial Number Minimum BPS Maximum BPS Bearer Type Framing Type Called Number
消息类型分配的会话ID呼叫序列号最小BPS最大BPS承载类型帧类型呼叫号码
The following AVPs MAY be present in the OCRQ:
OCRQ中可能存在以下AVP：
Sub-Address
子地址
Outgoing-Call-Reply (OCRP) is a control message sent by the LAC to the LNS in response to a received OCRQ message. It is the second in a three message exchange used for establishing a session within an L2TP tunnel.
传出呼叫应答（OCRP）是LAC向LNS发送的控制消息，以响应接收到的OCRQ消息。它是用于在L2TP隧道内建立会话的三条消息交换中的第二条。
OCRP is used to indicate that the LAC is able to attempt the outbound call and returns certain parameters regarding the call attempt.
OCRP用于指示LAC能够尝试出站呼叫，并返回有关呼叫尝试的某些参数。
The following AVPs MUST be present in the OCRP:
OCRP中必须存在以下AVP：
Message Type Assigned Session ID
消息类型分配的会话ID
The following AVPs MAY be present in the OCRP:
OCRP中可能存在以下AVP：
Physical Channel ID
物理通道ID
Outgoing-Call-Connected (OCCN) is a control message sent by the LAC to the LNS following the OCRP and after the outgoing call has been completed. It is the final message in a three message exchange used for establishing a session within an L2TP tunnel.
已连接的传出呼叫（OCCN）是LAC在OCRP之后和传出呼叫完成后向LNS发送的控制消息。它是用于在L2TP隧道内建立会话的三条消息交换中的最后一条消息。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LNS about the particular parameters obtained after the call was established.
OCCN用于表示请求的传出呼叫的结果是成功的。它还向LNS提供关于建立呼叫后获得的特定参数的信息。
The following AVPs MUST be present in the OCCN:
以下AVP必须出现在OCCN中：
Message Type (Tx) Connect Speed Framing Type
消息类型（Tx）连接速度帧类型
The following AVPs MAY be present in the OCCN:
OCCN中可能存在以下AVP：
Rx Connect Speed Sequencing Required
需要Rx连接速度排序
The Call-Disconnect-Notify (CDN) message is an L2TP control message sent by either the LAC or LNS to request disconnection of a specific call within the tunnel. Its purpose is to inform the peer of the
呼叫断开通知（CDN）消息是由LAC或LNS发送的L2TP控制消息，用于请求断开隧道内特定呼叫的连接。其目的是通知同行
disconnection and the reason why the disconnection occurred. The peer MUST clean up any resources, and does not send back any indication of success or failure for such cleanup.
断开以及发生断开的原因。对等方必须清理任何资源，并且不会返回此类清理成功或失败的任何指示。
The following AVPs MUST be present in the CDN:
CDN中必须存在以下AVP：
Message Type Result Code Assigned Session ID
消息类型结果代码分配的会话ID
The following AVPs MAY be present in the CDN:
CDN中可能存在以下AVP：
Q.931 Cause Code
Q.931原因代码
The WAN-Error-Notify message is an L2TP control message sent by the LAC to the LNS to indicate WAN error conditions (conditions that occur on the interface supporting PPP). The counters in this message are cumulative. This message should only be sent when an error occurs, and not more than once every 60 seconds. The counters are reset when a new call is established.
WAN错误通知消息是LAC发送给LNS的L2TP控制消息，用于指示WAN错误情况（在支持PPP的接口上发生的情况）。此消息中的计数器是累积的。仅当发生错误时才应发送此消息，且每60秒发送一次。当建立新呼叫时，计数器被重置。
The following AVPs MUST be present in the WEN:
以下AVP必须出现在WEN中：
Message Type Call Errors
消息类型调用错误
The Set-Link-Info message is an L2TP control message sent by the LNS to the LAC to set PPP-negotiated options. These options can change at any time during the life of the call, thus the LAC MUST be able to update its internal call information and behavior on an active PPP session.
Set Link Info消息是LNS发送给LAC的L2TP控制消息，用于设置PPP协商选项。这些选项可以在通话期间随时更改，因此LAC必须能够在活动PPP会话上更新其内部通话信息和行为。
The following AVPs MUST be present in the SLI:
SLI中必须存在以下AVP：
Message Type ACCM
消息类型ACCM
The control messages defined in section 6 are exchanged by way of state tables defined in this section. Tables are defined for incoming call placement, outgoing call placement, as well as for initiation of
第6节中定义的控制消息通过本节中定义的状态表进行交换。定义了用于传入呼叫放置、传出呼叫放置以及启动呼叫的表
the tunnel itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying semantics defined in Section 5.8.
隧道本身。状态表不编码超时和重传行为，因为这是在第5.8节定义的底层语义中处理的。
This section describes the operation of various L2TP control connection functions and the Control Connection messages which are used to support them.
本节介绍各种L2TP控制连接功能的操作以及用于支持这些功能的控制连接消息。
Receipt of an invalid or unrecoverable malformed control message should be logged appropriately and the control connection cleared to ensure recovery to a known state. The control connection may then be restarted by the initiator.
应适当记录收到的无效或不可恢复的格式错误的控制消息，并清除控制连接，以确保恢复到已知状态。然后，启动器可以重新启动控制连接。
An invalid control message is defined as a message which contains a Message Type that is marked mandatory (see Section 4.4.1) and is unknown to the implementation, or a control message that is received in an improper sequence (e.g. an SCCCN sent in reply to an SCCRQ).
无效控制消息定义为包含标记为强制的消息类型（见第4.4.1节）且实施未知的消息，或以不正确顺序接收的控制消息（例如，为回复SCCRQ而发送的SCCCN）。
Examples of a malformed control message include one that has an invalid value in its header, contains an AVP that is formatted incorrectly or whose value is out of range, or a message that is missing a required AVP. A control message with a malformed header should be discarded. A control message with an invalid AVP should look to the M-bit for that AVP to determine whether the error is recoverable or not.
格式错误的控制消息的示例包括标头中的值无效、包含格式不正确或值超出范围的AVP或缺少所需AVP的消息。应丢弃标题格式不正确的控制消息。具有无效AVP的控制消息应查看该AVP的M位，以确定错误是否可恢复。
A malformed yet recoverable non-mandatory (M-bit is not set) AVP within a control message should be treated in a similar manner as an unrecognized non-mandatory AVP. Thus, if a malformed AVP is received with the M-bit set, the session or tunnel should be terminated with a proper Result or Error Code sent. If the M-bit is not set, the AVP should be ignored (with the exception of logging a local error message) and the message accepted.
控制消息中格式错误但可恢复的非强制性（未设置M位）AVP应以与未识别的非强制性AVP类似的方式处理。因此，如果使用M位集接收到格式错误的AVP，则会话或隧道应终止，并发送正确的结果或错误代码。如果未设置M位，则应忽略AVP（记录本地错误消息除外），并接受消息。
This MUST NOT be considered a license to send malformed AVPs, but simply a guide towards how to handle an improperly formatted message if one is received. It is impossible to list all potential malformations of a given message and give advice for each. That said, one example of a recoverable, malformed AVP might be if the Rx Connect Speed AVP, attribute 38, is received with a length of 8 rather than 10 and the BPS given in 2 octets rather than 4. Since the Rx Connect Speed is non-mandatory, this condition should not be considered catastrophic. As such, the control message should be accepted as if the AVP had not been received (with the exception of a local error message being logged).
这不能被视为发送格式不正确的AVP的许可证，而只是一个指南，指导如何处理收到的格式不正确的消息。不可能列出给定消息的所有潜在畸形，并为每个畸形提供建议。也就是说，如果接收到的Rx连接速度AVP属性38的长度为8而不是10，并且BPS以2个八位字节而不是4个字节给出，则可恢复的、格式错误的AVP的一个示例可能是。由于Rx连接速度是非强制性的，因此这种情况不应被视为灾难性的。因此，应接受控制消息，如同未收到AVP一样（记录的本地错误消息除外）。
In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that regardless of the initiator of the tunnel destruction, the reliable delivery mechanism must be allowed to run (see Section 5.8) before destroying the tunnel. This permits the tunnel management messages to be reliably delivered to the peer.
在下表中的几种情况下，发送协议消息，然后进行“清理”。注意，无论隧道破坏的始作俑者是谁，在破坏隧道之前，必须允许可靠的输送机制运行（见第5.8节）。这允许将隧道管理消息可靠地传递给对等方。
Appendix B.1 contains an example of lock-step tunnel establishment.
附录B.1包含了一个建立锁步隧道的示例。
The L2TP control connection protocol is not distinguishable between the LNS and LAC, but is distinguishable between the originator and receiver. The originating peer is the one which first initiates establishment of the tunnel (in a tie breaker situation, this is the winner of the tie). Since either LAC or LNS can be the originator, a collision can occur. See the Tie Breaker AVP in Section 4.4.3 for a description of this and its resolution.
L2TP控制连接协议在LNS和LAC之间无法区分，但在发送方和接收方之间可以区分。发起对等方是首先发起建立隧道的对等方（在平局破坏情况下，这是平局的赢家）。由于LAC或LNS都可能是发起人，因此可能会发生冲突。有关这一点及其解决方案的说明，请参见第4.4.3节中的联络断路器AVP。
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
State Event Action New State
----- ----- ------ ---------
idle Local Send SCCRQ wait-ctl-reply
Open request
idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable
空闲接收SCCRQ，发送SCCRP等待控制连接可接受
idle Receive SCCRQ, Send StopCCN, idle not acceptable Clean up
空闲接收SCCRQ，发送StopCCN，空闲不可接受清理
idle Receive SCCRP Send StopCCN idle Clean up
空闲接收SCCRP发送StopCCN空闲清理
idle Receive SCCCN Clean up idle
空闲接收SCCCN清除空闲
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable Send tunnel-open event to waiting sessions
等待ctl回复接收SCCRP，发送SCCCN，向等待会话发送可接受的发送隧道打开事件
wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable Clean up
等待ctl回复接收SCCRP，发送StopCCN，空闲不可接受清理
wait-ctl-reply Receive SCCRQ, Clean up, idle lose tie-breaker Re-queue SCCRQ for idle state
等待ctl回复接收SCCRQ、清理、空闲丢失连接断路器重新排队SCCRQ以获得空闲状态
wait-ctl-reply Receive SCCCN Send StopCCN idle Clean up
等待ctl应答接收SCCCN发送StopCCN空闲清理
wait-ctl-conn Receive SCCCN, Send tunnel-open established acceptable event to waiting sessions
等待ctl conn接收SCCCN，向等待会话发送隧道打开已建立的可接受事件
wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable Clean up
等待ctl conn接收SCCCN，发送StopCCN，空闲不可接受清理
wait-ctl-conn Receive SCCRP, Send StopCCN, idle SCCRQ Clean up
等待ctl conn接收SCCRP，发送StopCCN，空闲SCCRQ清理
established Local Send tunnel-open established Open request event to waiting (new call) sessions
已建立本地发送隧道打开已建立打开请求事件到等待（新呼叫）会话
established Admin Send StopCCN idle Tunnel Close Clean up
已建立管理员发送StopCCN空闲隧道关闭清理
established Receive SCCRQ, Send StopCCN idle SCCRP, SCCCN Clean up
已建立接收SCCRQ，发送StopCCN空闲SCCRP，SCCCN清理
idle Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established
空闲接收StopCCN清除空闲等待控制应答，等待控制连接，已建立
The states associated with the LNS or LAC for control connection establishment are:
与LNS或LAC相关的控制连接建立状态为：
idle Both initiator and recipient start from this state. An initiator transmits an SCCRQ, while a recipient remains in the idle state until receiving an SCCRQ.
发起方和接收方都从该状态开始空闲。发起方发送SCCRQ，而接收方在收到SCCRQ之前保持空闲状态。
wait-ctl-reply The originator checks to see if another connection has been requested from the same peer, and if so, handles the collision situation described in Section 5.8.
wait ctl reply发起者检查是否已从同一对等方请求另一个连接，如果是，则处理第5.8节中描述的冲突情况。
When an SCCRP is received, it is examined for a compatible version. If the version of the reply is lower than the version sent in the request, the older (lower) version should be used provided it is supported. If the version in the reply is earlier and supported, the originator moves to the established state. If
收到SCCRP后，将检查其是否有兼容版本。如果回复的版本低于请求中发送的版本，则应使用较旧（较低）的版本，前提是该版本受支持。如果回复中的版本更早且受支持，则发起者将移动到已建立状态。如果
the version is earlier and not supported, a StopCCN MUST be sent to the peer and the originator cleans up and terminates the tunnel.
如果版本较早且不受支持，则必须向对等方发送StopCCN，并且发起者将清理并终止隧道。
wait-ctl-conn This is where an SCCCN is awaited; upon receipt, the challenge response is checked. The tunnel either is established, or is torn down if an authorization failure is detected.
等待ctl conn这是等待SCCCN的地方；收到后，将检查质询响应。隧道要么建立，要么在检测到授权失败时被拆除。
established An established connection may be terminated by either a local condition or the receipt of a Stop-Control-Connection-Notification. In the event of a local termination, the originator MUST send a Stop-Control-Connection-Notification and clean up the tunnel.
已建立的连接可以通过本地条件或接收到停止控制连接通知来终止。在本地终止的情况下，发起人必须发送停止控制连接通知并清理隧道。
If the originator receives a Stop-Control-Connection-Notification it MUST also clean up the tunnel.
如果发起人收到停止控制连接通知，则还必须清理隧道。
Due to the real-time nature of telephone signaling, both the LNS and LAC should be implemented with multi-threaded architectures such that messages related to multiple calls are not serialized and blocked. The call and connection state figures do not specify exceptions caused by timers. These are addressed in Section 5.8.
由于电话信令的实时性，LNS和LAC都应采用多线程体系结构来实现，以便与多个呼叫相关的消息不会被序列化和阻止。调用和连接状态图未指定计时器引起的异常。第5.8节对这些问题进行了说明。
An Incoming-Call-Request message is generated by the LAC when an incoming call is detected (for example, an associated telephone line rings). The LAC selects a Session ID and serial number and indicates the call bearer type. Modems should always indicate analog call type. ISDN calls should indicate digital when unrestricted digital service or rate adaption is used and analog if digital modems are involved. Calling Number, Called Number, and Subaddress may be included in the message if they are available from the telephone network.
当检测到传入呼叫时（例如，相关电话线响起），LAC生成传入呼叫请求消息。LAC选择会话ID和序列号，并指示呼叫承载类型。调制解调器应始终指示模拟呼叫类型。当使用不受限制的数字服务或速率自适应时，ISDN呼叫应指示数字，如果涉及数字调制解调器，则应指示模拟。如果可以从电话网络获得主叫号码、被叫号码和子地址，则消息中可能包含这些号码。
Once the LAC sends the Incoming-Call-Request, it waits for a response from the LNS but it does not necessarily answer the call from the telephone network yet. The LNS may choose not to accept the call if:
一旦LAC发送传入呼叫请求，它将等待LNS的响应，但它不一定应答来自电话网络的呼叫。在以下情况下，LNS可选择不接受呼叫：
- No resources are available to handle more sessions - The dialed, dialing, or subaddress fields do not correspond to an authorized user - The bearer service is not authorized or supported
- 没有资源可用于处理更多会话-拨号、拨号或子地址字段与授权用户不对应-承载服务未授权或不受支持
If the LNS chooses to accept the call, it responds with an Incoming-Call-Reply. When the LAC receives the Incoming-Call-Reply, it attempts to connect the call. A final call connected message from the LAC to the LNS indicates that the call states for both the LAC and the LNS should enter the established state. If the call terminated before the LNS could accept it, a Call-Disconnect-Notify is sent by the LAC to indicate this condition.
如果LNS选择接受呼叫，它将以传入呼叫应答进行响应。当LAC收到来电应答时，它会尝试连接呼叫。从LAC到LNS的最终呼叫连接消息表明LAC和LNS的呼叫状态都应进入已建立状态。如果呼叫在LNS可以接受之前终止，LAC将发送呼叫断开通知以指示此情况。
When the dialed-in client hangs up, the call is cleared normally and the LAC sends a Call-Disconnect-Notify message. If the LNS wishes to clear a call, it sends a Call-Disconnect-Notify message and cleans up its session.
当拨入客户端挂断时，呼叫将正常清除，LAC将发送呼叫断开通知消息。如果LNS希望清除呼叫，它将发送呼叫断开通知消息并清除其会话。
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
State Event Action New State
----- ----- ------ ---------
idle Bearer Ring or Initiate local wait-tunnel
Ready to indicate tunnel open
incoming conn.
idle Receive ICCN, Clean up idle ICRP, CDN
空闲接收ICCN，清除空闲ICRP，CDN
wait-tunnel Bearer line drop Clean up idle or local close request
等待隧道承载线下降清理空闲或本地关闭请求
wait-tunnel tunnel-open Send ICRQ wait-reply
等待隧道打开发送ICRQ等待回复
wait-reply Receive ICRP, Send ICCN established acceptable
等待回复接收ICRP，发送ICCN建立可接受
wait-reply Receive ICRP, Send CDN, idle Not acceptable Clean up
等待回复接收ICRP，发送CDN，空闲不可接受清理
wait-reply Receive ICRQ Send CDN idle Clean up
等待应答接收ICRQ发送CDN空闲清理
wait-reply Receive CDN Clean up idle ICCN
等待应答接收CDN清除空闲ICCN
wait-reply Local Send CDN, idle close request or Clean up Bearer line drop
等待应答本地发送CDN、空闲关闭请求或清除承载线路丢弃
established Receive CDN Clean up idle
已建立接收CDN清除空闲
established Receive ICRQ, Send CDN, idle ICRP, ICCN Clean up
已建立接收ICRQ、发送CDN、空闲ICRP、ICCN清理
established Bearer line Send CDN, idle drop or local Clean up close request
已建立的承载线路发送CDN、空闲丢弃或本地清理关闭请求
The states associated with the LAC for incoming calls are:
与LAC关联的来电状态为：
idle The LAC detects an incoming call on one of its interfaces. Typically this means an analog line is ringing or an ISDN TE has detected an incoming Q.931 SETUP message. The LAC initiates its tunnel establishment state machine, and moves to a state waiting for confirmation of the existence of a tunnel.
空闲LAC在其一个接口上检测到传入呼叫。通常这意味着模拟线路正在振铃，或者ISDN TE检测到传入的Q.931设置消息。LAC启动其隧道建立状态机，并移动到等待隧道存在确认的状态。
wait-tunnel In this state the session is waiting for either the control connection to be opened or for verification that the tunnel is already open. Once an indication that the tunnel has/was opened, session control messages may be exchanged. The first of these is the Incoming-Call-Request.
等待隧道在此状态下，会话正在等待打开控制连接或验证隧道是否已打开。一旦指示隧道已经/已经打开，就可以交换会话控制消息。第一个是来电请求。
wait-reply The LAC receives either a CDN message indicating the LNS is not willing to accept the call (general error or don't accept) and moves back into the idle state, or an Incoming-Call-Reply message indicating the call is accepted, the LAC sends an Incoming-Call-Connected message and enters the established state.
等待回复LAC收到CDN消息，指示LNS不愿意接受呼叫（一般错误或不接受）并返回空闲状态，或收到来电回复消息，指示呼叫已接受，LAC发送来电连接消息并进入已建立状态。
established Data is exchanged over the tunnel. The call may be cleared following: + An event on the connected interface: The LAC sends a Call-Disconnect-Notify message + Receipt of a Call-Disconnect-Notify message: The LAC cleans up, disconnecting the call. + A local reason: The LAC sends a Call-Disconnect-Notify message.
已建立的数据通过隧道进行交换。可在以下情况下清除呼叫：+连接接口上的事件：LAC发送呼叫断开通知消息+收到呼叫断开通知消息：LAC清除，断开呼叫本地原因：LAC发送呼叫断开通知消息。
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
State Event Action New State
----- ----- ------ ---------
idle Receive ICRQ, Send ICRP wait-connect
acceptable
idle Receive ICRQ, Send CDN, idle not acceptable Clean up
空闲接收ICRQ，发送CDN，空闲不可接受清理
idle Receive ICRP Send CDN idle Clean up
空闲接收ICRP发送CDN空闲清理
idle Receive ICCN Clean up idle
空闲接收ICCN清除空闲
wait-connect Receive ICCN Prepare for established acceptable data
等待连接接收ICCN准备建立可接受的数据
wait-connect Receive ICCN Send CDN, idle not acceptable Clean up
等待连接接收ICCN发送CDN，空闲不可接受清理
wait-connect Receive ICRQ, Send CDN idle ICRP Clean up
等待连接接收ICRQ，发送CDN空闲ICRP清理
idle, Receive CDN Clean up idle wait-connect, established
空闲，接收CDN清除空闲等待连接，已建立
wait-connect Local Send CDN, idle established Close request Clean up
等待连接本地发送CDN，空闲已建立关闭请求清理
established Receive ICRQ, Send CDN idle ICRP, ICCN Clean up
建立接收ICRQ，发送CDN空闲ICRP，ICCN清理
The states associated with the LNS for incoming calls are:
与传入呼叫的LNS关联的状态为：
idle An Incoming-Call-Request message is received. If the request is not acceptable, a Call-Disconnect-Notify is sent back to the LAC and the LNS remains in the idle state. If the Incoming-Call-Request message is acceptable, an Incoming-Call-Reply is sent. The session moves to the wait-connect state.
idle接收到来电请求消息。如果请求不可接受，则会将呼叫断开通知发送回LAC，LNS保持空闲状态。如果传入呼叫请求消息可接受，则发送传入呼叫应答。会话移动到等待连接状态。
wait-connect If the session is still connected on the LAC, the LAC sends an Incoming-Call-Connected message to the LNS which then moves into established state. The LAC may send a Call-Disconnect-Notify to indicate that the incoming caller could not be connected. This
等待连接如果会话仍在LAC上连接，LAC将向LNS发送传入呼叫连接消息，然后LNS进入已建立状态。LAC可发送呼叫断开通知，以指示传入呼叫者无法连接。这
could happen, for example, if a telephone user accidentally places a standard voice call to an LAC resulting in a handshake failure on the called modem.
例如，如果电话用户意外地向LAC发出标准语音呼叫，导致被呼叫调制解调器上的握手失败，则可能发生这种情况。
established The session is terminated either by receipt of a Call-Disconnect-Notify message from the LAC or by sending a Call-Disconnect-Notify. Clean up follows on both sides regardless of the initiator.
通过从LAC接收呼叫断开通知消息或通过发送呼叫断开通知来终止会话。无论是哪种启动器，两侧都会进行清理。
Outgoing calls are initiated by an LNS and instruct an LAC to place a call. There are three messages for outgoing calls: Outgoing-Call-Request, Outgoing-Call-Reply, and Outgoing-Call-Connected. The LNS sends an Outgoing-Call-Request specifying the dialed party phone number, subaddress and other parameters. The LAC MUST respond to the Outgoing-Call-Request message with an Outgoing-Call-Reply message once the LAC determines that the proper facilities exist to place the call and the call is administratively authorized. For example, is this LNS allowed to dial an international call? Once the outbound call is connected, the LAC sends an Outgoing-Call-Connected message to the LNS indicating the final result of the call attempt:
传出呼叫由LNS发起，并指示LAC进行呼叫。传出呼叫有三条消息：传出呼叫请求、传出呼叫应答和传出呼叫已连接。LNS发送一个传出呼叫请求，指定拨号方电话号码、子地址和其他参数。一旦LAC确定存在适当的设施进行呼叫，并且呼叫得到管理授权，LAC必须使用呼出呼叫回复消息来响应呼出呼叫请求消息。例如，是否允许该LNS拨打国际电话？连接出站呼叫后，LAC向LNS发送出站呼叫连接消息，指示呼叫尝试的最终结果：
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Open bearer
idle Receive OCRQ, Send CDN, idle not acceptable Clean up
空闲接收OCRQ，发送CDN，空闲不可接受清理
idle Receive OCRP Send CDN idle Clean up
空闲接收OCRP发送CDN空闲清理
idle Receive OCCN, Clean up idle CDN
空闲接收OCCN，清除空闲CDN
wait-cs-answer Bearer answer, Send OCCN established framing detected
等待cs应答承载应答，发送OCCN已建立帧检测
wait-cs-answer Bearer failure Send CDN, idle Clean up
等待cs应答承载失败发送CDN，空闲清理
wait-cs-answer Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
等待cs应答接收OCRQ，发送CDN空闲OCRP，OCCN清理
established Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
建立接收OCRQ，发送CDN空闲OCRP，OCCN清理
wait-cs-answer, Receive CDN Clean up idle established
等待cs应答，接收CDN清除空闲建立
established Bearer line drop, Send CDN, idle Local close Clean up request
建立承载线路丢弃、发送CDN、空闲本地关闭清理请求
The states associated with the LAC for outgoing calls are:
与LAC相关的拨出呼叫状态为：
idle If Outgoing-Call-Request is received in error, respond with a Call-Disconnect-Notify. Otherwise, allocate a physical channel and send an Outgoing-Call-Reply. Place the outbound call and move to the wait-cs-answer state.
空闲-如果错误地接收到传出呼叫请求，则使用呼叫断开通知进行响应。否则，请分配一个物理通道并发送传出呼叫应答。拨打出站呼叫并转到等待cs应答状态。
wait-cs-answer If the call is not completed or a timer expires waiting for the call to complete, send a Call-Disconnect-Notify with the appropriate error condition set and go to idle state. If a circuit
wait cs answer如果呼叫未完成或等待呼叫完成的计时器过期，则发送呼叫断开通知，并设置相应的错误条件，然后进入空闲状态。如果是电路
switched connection is established and framing is detected, send an Outgoing-Call-Connected indicating success and go to established state.
建立交换连接并检测到帧，发送一个已连接的传出呼叫，指示成功并进入已建立状态。
established If a Call-Disconnect-Notify is received by the LAC, the telco call MUST be released via appropriate mechanisms and the session cleaned up. If the call is disconnected by the client or the called interface, a Call-Disconnect-Notify message MUST be sent to the LNS. The sender of the Call-Disconnect-Notify message returns to the idle state after sending of the message is complete.
如果LAC收到呼叫断开通知，则必须通过适当的机制释放电信公司呼叫，并清理会话。如果客户端或被调用接口断开了呼叫，则必须向LNS发送呼叫断开通知消息。消息发送完成后，Call Disconnect Notify消息的发送方将返回空闲状态。
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
State Event Action New State
----- ----- ------ ---------
idle Local Initiate local wait-tunnel
open request tunnel-open
idle Receive OCCN, Clean up idle OCRP, CDN
空闲接收OCCN，清除空闲OCRP，CDN
wait-tunnel tunnel-open Send OCRQ wait-reply
等待隧道打开发送OCRQ等待回复
wait-reply Receive OCRP, none wait-connect acceptable
等待回复接收OCRP，无可接受的等待连接
wait-reply Receive OCRP, Send CDN idle not acceptable Clean up
等待回复接收OCRP，发送CDN空闲不可接受清理
wait-reply Receive OCCN, Send CDN idle OCRQ Clean up
等待回复接收OCCN，发送CDN空闲OCRQ清理
wait-connect Receive OCCN none established
等待连接接收OCCN未建立
wait-connect Receive OCRQ, Send CDN idle OCRP Clean up
等待连接接收OCRQ，发送CDN空闲OCRP清理
idle, Receive CDN, Clean up idle wait-reply, wait-connect, established
空闲，接收CDN，清除空闲等待应答，等待连接，已建立
established Receive OCRQ, Send CDN idle OCRP, OCCN Clean up
建立接收OCRQ，发送CDN空闲OCRP，OCCN清理
wait-reply, Local Send CDN idle wait-connect, Close request Clean up established
等待应答，本地发送CDN空闲等待连接，关闭请求清除已建立
wait-tunnel Local Clean up idle Close request
等待隧道本地清理空闲关闭请求
The states associated with the LNS for outgoing calls are:
与传出呼叫的LNS相关的状态为：
idle, wait-tunnel When an outgoing call is initiated, a tunnel is first created, much as the idle and wait-tunnel states for an LAC incoming call. Once a tunnel is established, an Outgoing-Call-Request message is sent to the LAC and the session moves into the wait-reply state.
空闲、等待隧道当传出呼叫启动时，首先创建一个隧道，就像LAC传入呼叫的空闲和等待隧道状态一样。一旦建立了隧道，将向LAC发送传出呼叫请求消息，会话将进入等待-应答状态。
wait-reply If a Call-Disconnect-Notify is received, an error occurred, and the session is cleaned up and returns to idle. If an Outgoing-Call-Reply is received, the call is in progress and the session moves to the wait-connect state.
等待应答如果收到呼叫断开通知，则会发生错误，会话将被清除并返回空闲状态。如果收到传出呼叫应答，则呼叫正在进行，会话将移至等待连接状态。
wait-connect If a Call-Disconnect-Notify is received, the call failed; the session is cleaned up and returns to idle. If an Outgoing-Call-Connected is received, the call has succeeded and the session may now exchange data.
等待连接如果收到呼叫断开通知，则呼叫失败；会话被清理并返回空闲状态。如果收到已连接的传出呼叫，则呼叫已成功，会话现在可以交换数据。
established If a Call-Disconnect-Notify is received, the call has been terminated for the reason indicated in the Result and Cause Codes; the session moves back to the idle state. If the LNS chooses to terminate the session, it sends a Call-Disconnect-Notify to the LAC and then cleans up and idles its session.
如果收到呼叫断开通知，则呼叫已因结果和原因代码中所示的原因终止；会话将移回空闲状态。如果LNS选择终止会话，它将向LAC发送呼叫断开通知，然后清理并空闲其会话。
The disconnection of a tunnel consists of either peer issuing a Stop-Control-Connection-Notification. The sender of this Notification should wait a finite period of time for the acknowledgment of this message before releasing the control information associated with the tunnel. The recipient of this Notification should send an acknowledgment of the Notification and then release the associated control information.
隧道的断开包括任一对等方发出停止控制连接通知。此通知的发送方应在释放与隧道关联的控制信息之前，等待有限时间以确认此消息。此通知的收件人应发送通知确认，然后释放相关的控制信息。
When to release a tunnel is an implementation issue and is not specified in this document. A particular implementation may use whatever policy is appropriate for determining when to release a control connection. Some implementations may leave a tunnel open for a period of time or perhaps indefinitely after the last session for that tunnel is cleared. Others may choose to disconnect the tunnel immediately after the last user connection on the tunnel disconnects.
何时释放隧道是一个实施问题，本文档中没有规定。特定的实现可以使用任何适当的策略来确定何时释放控制连接。某些实现可能会在隧道的最后一个会话被清除后一段时间或无限期地保持隧道打开。其他人可以选择在隧道上的最后一个用户连接断开后立即断开隧道。
L2TP is self-describing, operating at a level above the media over which it is carried. However, some details of its connection to media are required to permit interoperable implementations. The following sections describe details needed to permit interoperability over specific media.
L2TP是自描述的，在承载它的介质之上的级别上运行。然而，为了实现可互操作性，需要一些与媒体连接的细节。以下各节描述了允许在特定介质上进行互操作所需的详细信息。
L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator of an L2TP tunnel picks an available source UDP port (which may or may not be 1701), and sends to the desired destination address at port 1701. The recipient picks a free port on its own system (which may or may not be 1701), and sends its reply to the initiator's UDP port and address, setting its own source port to the free port it found. Once the source and destination ports and addresses are established, they MUST remain static for the life of the tunnel.
L2TP使用注册的UDP端口1701[RFC1700]。整个L2TP数据包（包括有效负载和L2TP报头）在UDP数据报中发送。L2TP隧道的启动器拾取可用的源UDP端口（可能是1701，也可能不是1701），并发送到端口1701处的所需目标地址。接收方在自己的系统上选择一个自由端口（可能是1701，也可能不是1701），并将其应答发送到发起方的UDP端口和地址，将自己的源端口设置为找到的自由端口。一旦建立了源和目标端口和地址，它们必须在隧道的生命周期内保持静态。
It has been suggested that having the recipient choose an arbitrary source port (as opposed to using the destination port in the packet initiating the tunnel, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementors should consider the potential implication of this before before choosing an arbitrary source port.
有人建议，让接收者选择任意源端口（与在发起隧道的分组中使用目的端口相反，即1701）可能使L2TP更难穿越一些NAT设备。在选择任意源端口之前，实现者应该考虑这一点的潜在含义。
IP fragmentation may occur as the L2TP packet travels over the IP substrate. L2TP makes no special efforts to optimize this. A LAC implementation MAY cause its LCP to negotiate for a specific MRU, which could optimize for LAC environments in which the MTU's of the path over which the L2TP packets are likely to travel have a consistent value.
当L2TP分组在IP基板上移动时，可能会发生IP碎片。L2TP不做任何特别的努力来优化这一点。LAC实现可使其LCP协商特定MRU，这可优化L2TP数据包可能通过的路径的MTU具有一致值的LAC环境。
The default for any L2TP implementation is that UDP checksums MUST be enabled for both control and data messages. An L2TP implementation MAY provide an option to disable UDP checksums for data messages. It is recommended that UDP checksums always be enabled on control packets.
任何L2TP实现的默认值都是必须为控制消息和数据消息启用UDP校验和。L2TP实现可以提供一个选项来禁用数据消息的UDP校验和。建议始终在控制数据包上启用UDP校验和。
Port 1701 is used for both L2F [RFC2341] and L2TP packets. The Version field in each header may be used to discriminate between the two packet types (L2F uses a value of 1, and the L2TP version described in this document uses a value of 2). An L2TP implementation running on a system which does not support L2F MUST silently discard all L2F packets.
端口1701用于L2F[RFC2341]和L2TP数据包。每个报头中的版本字段可用于区分两种数据包类型（L2F使用值1，本文档中描述的L2TP版本使用值2）。在不支持L2F的系统上运行的L2TP实现必须以静默方式丢弃所有L2F数据包。
To the PPP clients using an L2TP-over-UDP/IP tunnel, the PPP link has the characteristic of being able to reorder or silently drop packets. The former may break non-IP protocols being carried by PPP, especially LAN-centric ones such as bridging. The latter may break protocols which assume per-packet indication of error, such as TCP header compression. Sequencing may be handled by using L2TP data message sequence numbers if any protocol being transported by the PPP
对于使用L2TP over UDP/IP隧道的PPP客户端，PPP链路具有能够重新排序或静默丢弃数据包的特性。前者可能破坏PPP承载的非IP协议，尤其是以LAN为中心的协议，如桥接。后者可能破坏假定每个数据包都有错误指示的协议，例如TCP报头压缩。如果PPP传输任何协议，则可以使用L2TP数据消息序列号处理排序
tunnel cannot tolerate reordering. The sequence dependency characteristics of individual protocols are outside the scope of this document.
隧道不能容忍重新排序。单个协议的序列依赖特性不在本文档的范围内。
Allowing packets to be dropped silently is perhaps more problematic with some protocols. If PPP reliable delivery [RFC1663] is enabled, no upper PPP protocol will encounter lost packets. If L2TP sequence numbers are enabled, L2TP can detect the packet loss. In the case of an LNS, the PPP and L2TP stacks are both present within the LNS, and packet loss signaling may occur precisely as if a packet was received with a CRC error. Where the LAC and PPP stack are co-resident, this technique also applies. Where the LAC and PPP client are physically distinct, the analogous signaling MAY be accomplished by sending a packet with a CRC error to the PPP client. Note that this would greatly increase the complexity of debugging client line problems, since the client statistics could not distinguish between true media errors and LAC-initiated ones. Further, this technique is not possible on all hardware.
在某些协议中，允许数据包以静默方式丢弃可能会有更大的问题。如果启用PPP可靠传递[RFC1663]，则上层PPP协议将不会遇到丢失的数据包。如果启用L2TP序列号，L2TP可以检测数据包丢失。在LNS的情况下，PPP和L2TP堆栈都存在于LNS内，并且分组丢失信令可以精确地发生，就像接收到带有CRC错误的分组一样。在LAC和PPP堆栈共存的情况下，此技术也适用。在LAC和PPP客户端物理上不同的情况下，可以通过向PPP客户端发送具有CRC错误的分组来实现模拟信令。请注意，这将大大增加调试客户机线路问题的复杂性，因为客户机统计数据无法区分真正的媒体错误和LAC引发的错误。此外，这种技术不可能在所有硬件上实现。
If VJ compression is used, and neither PPP reliable delivery nor sequence numbers are enabled, each lost packet results in a 1 in 2**16 chance of a TCP segment being forwarded with incorrect contents [RFC1144]. Where the combination of the packet loss rate with this statistical exposure is unacceptable, TCP header compression SHOULD NOT be used.
如果使用VJ压缩，并且既不启用PPP可靠传递也不启用序列号，则每个丢失的数据包都会导致TCP段被转发的几率为1/2**16，且内容不正确[RFC1144]。如果丢包率与此统计暴露的组合不可接受，则不应使用TCP报头压缩。
In general, it is wise to remember that the L2TP/UDP/IP transport is an unreliable transport. As with any PPP media that is subject to loss, care should be taken when using protocols that are particularly loss-sensitive. Such protocols include compression and encryption protocols that employ history.
通常，明智的做法是记住L2TP/UDP/IP传输是不可靠的传输。与任何可能丢失的PPP媒体一样，在使用对丢失特别敏感的协议时应小心。此类协议包括采用历史的压缩和加密协议。
When operating in IP environments, L2TP MUST offer the UDP encapsulation described in 8.1 as its default configuration for IP operation. Other configurations (perhaps corresponding to a compressed header format) MAY be defined and made available as a configurable option.
在IP环境中运行时，L2TP必须提供8.1中描述的UDP封装，作为其IP操作的默认配置。可以定义其他配置（可能对应于压缩头格式），并将其作为可配置选项提供。
L2TP encounters several security issues in its operation. The general approach of L2TP to these issues is documented here.
L2TP在运行中遇到了几个安全问题。L2TP解决这些问题的一般方法记录在这里。
The tunnel endpoints may optionally perform an authentication procedure of one another during tunnel establishment. This authentication has the same security attributes as CHAP, and has reasonable protection against replay and snooping during the tunnel establishment process. This mechanism is not designed to provide any authentication beyond tunnel establishment; it is fairly simple for a malicious user who can snoop the tunnel stream to inject packets once an authenticated tunnel establishment has been completed successfully.
隧道端点可以可选地在隧道建立期间执行彼此的认证过程。此身份验证具有与CHAP相同的安全属性，并且在隧道建立过程中具有防止重播和窥探的合理保护。该机制的设计目的不是提供隧道建立以外的任何身份验证；一旦通过身份验证的隧道建立成功完成，恶意用户就可以窥探隧道流来注入数据包，这是相当简单的。
For authentication to occur, the LAC and LNS MUST share a single secret. Each side uses this same secret when acting as authenticatee as well as authenticator. Since a single secret is used, the tunnel authentication AVPs include differentiating values in the CHAP ID fields for each message digest calculation to guard against replay attacks.
要进行身份验证，LAC和LN必须共享一个秘密。双方在充当身份验证人和身份验证人时使用相同的秘密。由于使用了单个秘密，隧道身份验证AVP在每个消息摘要计算的CHAP ID字段中包括区分值，以防止重播攻击。
The Assigned Tunnel ID and Assigned Session ID (See Section 4.4.3) SHOULD be selected in an unpredictable manner rather than sequentially or otherwise. Doing so will help deter hijacking of a session by a malicious user who does not have access to packet traces between the LAC and LNS.
应以不可预测的方式选择分配的隧道ID和分配的会话ID（见第4.4.3节），而不是顺序或其他方式。这样做将有助于阻止无法访问LAC和LN之间的数据包跟踪的恶意用户劫持会话。
Securing L2TP requires that the underlying transport make available encryption, integrity and authentication services for all L2TP traffic. This secure transport operates on the entire L2TP packet and is functionally independent of PPP and the protocol being carried by PPP. As such, L2TP is only concerned with confidentiality, authenticity, and integrity of the L2TP packets between its tunnel
保护L2TP需要底层传输为所有L2TP通信提供加密、完整性和身份验证服务。这种安全传输在整个L2TP数据包上运行，在功能上独立于PPP和PPP承载的协议。因此，L2TP只关心其隧道之间L2TP数据包的机密性、真实性和完整性
endpoints (the LAC and LNS), not unlike link-layer encryption being concerned only about protecting the confidentiality of traffic between its physical endpoints.
端点（LAC和LN），与链路层加密不同，链路层加密只关心保护其物理端点之间通信的机密性。
Protecting the L2TP packet stream via a secure transport does, in turn, also protect the data within the tunneled PPP packets while transported from the LAC to the LNS. Such protection should not be considered a substitution for end-to-end security between communicating hosts or applications.
通过安全传输保护L2TP数据包流反过来也会在从LAC传输到LNS时保护隧道PPP数据包内的数据。这种保护不应被视为是对通信主机或应用程序之间端到端安全性的替代。
When running over IP, IPsec provides packet-level security via ESP and/or AH. All L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP data packets to the IPsec system.
在IP上运行时，IPsec通过ESP和/或AH提供数据包级别的安全性。特定隧道的所有L2TP控制和数据包显示为IPsec系统的同质UDP/IP数据包。
In addition to IP transport security, IPsec defines a mode of operation that allows tunneling of IP packets. The packet level encryption and authentication provided by IPsec tunnel mode and that provided by L2TP secured with IPsec provide an equivalent level of security for these requirements.
除了IP传输安全之外，IPsec还定义了一种允许IP数据包隧道传输的操作模式。IPsec隧道模式提供的数据包级加密和身份验证以及由IPsec保护的L2TP提供的数据包级加密和身份验证为这些要求提供了同等的安全级别。
IPsec also defines access control features that are required of a compliant IPsec implementation. These features allow filtering of packets based upon network and transport layer characteristics such as IP address, ports, etc. In the L2TP tunneling model, analogous filtering is logically performed at the PPP layer or network layer above L2TP. These network layer access control features may be handled at the LNS via vendor-specific authorization features based upon the authenticated PPP user, or at the network layer itself by using IPsec transport mode end-to-end between the communicating hosts. The requirements for access control mechanisms are not a part of the L2TP specification and as such are outside the scope of this document.
IPsec还定义了兼容IPsec实现所需的访问控制功能。这些特性允许基于网络和传输层特性（如IP地址、端口等）过滤数据包。在L2TP隧道模型中，类似过滤在L2TP之上的PPP层或网络层逻辑上执行。这些网络层访问控制功能可以通过基于认证的PPP用户的特定于供应商的授权功能在LNS处处理，或者通过在通信主机之间使用端到端的IPsec传输模式在网络层本身处处理。访问控制机制的要求不是L2TP规范的一部分，因此不在本文件的范围内。
L2TP defines AVPs that MAY be exchanged during session establishment to provide forwarding of PPP authentication information obtained at the LAC to the LNS for validation (see Section 4.4.5). This implies a direct trust relationship of the LAC on behalf of the LNS. If the LNS chooses to implement proxy authentication, it MUST be able to be configured off, requiring a new round a PPP authentication initiated by the LNS (which may or may not include a new round of LCP negotiation).
L2TP定义了可在会话建立期间交换的AVP，以将在LAC获得的PPP认证信息转发给LNS进行验证（见第4.4.5节）。这意味着LAC代表LNS建立了直接信任关系。如果LNS选择实施代理身份验证，则必须能够将其配置为关闭，要求LNS发起新一轮PPP身份验证（可能包括也可能不包括新一轮LCP协商）。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document.
本文件定义了IANA需要维护的一些“神奇”数字。本节解释IANA在每个列表中分配额外编号时使用的标准。以下小节描述了本文档其他地方定义的命名空间的分配策略。
As defined in Section 4.1, AVPs contain vendor ID, Attribute and Value fields. For vendor ID value of 0, IANA will maintain a registry
如第4.1节所定义，AVP包含供应商ID、属性和值字段。对于供应商ID值0，IANA将维护一个注册表
of assigned Attributes and in some case also values. Attributes 0-39 are assigned as defined in Section 4.4. The remaining values are available for assignment through IETF Consensus [RFC 2434].
指定的属性，在某些情况下还包括值。按照第4.4节的定义分配属性0-39。剩余值可通过IETF共识[RFC 2434]分配。
As defined in Section 4.4.1, Message Type AVPs (Attribute Type 0) have an associated value maintained by IANA. Values 0-16 are defined in Section 3.2, the remaining values are available for assignment via IETF Consensus [RFC 2434]
如第4.4.1节所定义，消息类型AVP（属性类型0）具有由IANA维护的关联值。值0-16在第3.2节中定义，剩余值可通过IETF共识[RFC 2434]分配
As defined in Section 4.4.2, Result Code AVPs (Attribute Type 1) contain three fields. Two of these fields (the Result Code and Error Code fields) have associated values maintained by IANA.
如第4.4.2节所定义，结果代码AVP（属性类型1）包含三个字段。其中两个字段（结果代码和错误代码字段）具有IANA维护的关联值。
The Result Code AVP may be included in CDN and StopCCN messages. The allowable values for the Result Code field of the AVP differ depending upon the value of the Message Type AVP. For the StopCCN message, values 0-7 are defined in Section 4.4.2; for the StopCCN message, values 0-11 are defined in the same section. The remaining values of the Result Code field for both messages are available for assignment via IETF Consensus [RFC 2434].
结果代码AVP可能包含在CDN和StopCCN消息中。AVP结果代码字段的允许值取决于消息类型AVP的值。对于StopCCN消息，第4.4.2节定义了值0-7；对于StopCCN消息，在同一节中定义了值0-11。两条消息的结果代码字段的剩余值可通过IETF共识[RFC 2434]进行分配。
Values 0-7 are defined in Section 4.4.2. Values 8-32767 are available for assignment via IETF Consensus [RFC 2434]. The remaining values of the Error Code field are available for assignment via First Come First Served [RFC 2434].
第4.4.2节定义了值0-7。值8-32767可通过IETF共识[RFC 2434]分配。错误代码字段的剩余值可通过先到先得[RFC 2434]分配。
The Framing Capabilities AVP and Bearer Capabilities AVPs (defined in Section 4.4.3) both contain 32-bit bitmasks. Additional bits should only be defined via a Standards Action [RFC 2434].
帧能力AVP和承载能力AVP（定义见第4.4.3节）均包含32位位位掩码。附加位只能通过标准操作[RFC 2434]定义。
The Proxy Authen Type AVP (Attribute Type 29) has an associated value maintained by IANA. Values 0-5 are defined in Section 4.4.5, the remaining values are available for assignment via First Come First Served [RFC 2434].
代理身份验证类型AVP（属性类型29）具有由IANA维护的关联值。值0-5在第4.4.5节中定义，剩余值可通过先到先得[RFC 2434]分配。
There are four remaining reserved bits in the AVP header. Additional bits should only be assigned via a Standards Action [RFC 2434].
AVP报头中还有四个剩余保留位。附加位只能通过标准操作[RFC 2434]分配。
[DSS1] ITU-T Recommendation, "Digital subscriber Signaling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Rec. Q.931(I.451), May 1998
[DSS1]ITU-T建议，“数字用户信令系统第1号（DSS1）-ISDN用户网络接口层3基本呼叫控制规范”，Rec.Q.931（I.451），1998年5月
[KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1
[KPS]Kaufman，C.，Perlman，R.，和Speciner，M.，“网络安全：公共世界中的私人通信”，Prentice Hall，1995年3月，ISBN 0-13-061466-1
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]辛普森，W，“HDLC类框架中的PPP”，标准51，RFC1662，1994年7月。
[RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[RFC1663]兰德博士，“PPP可靠传输”，RFC1663，1994年7月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。另见：http://www.iana.org/numbers.html [RFC1990]K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[RFC2138]Rigney，C.，Rubens，A.，Simpson，W.和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 21381997年4月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341]Valencia，A.，Littlewood，M.和T.Kolar，“思科第二层转发（协议）L2F”，RFC 23411998年5月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.和G.Zorn，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9
[STEVENS]STEVENS，W.Richard，“TCP/IP图解，第一卷协议”，Addison-Wesley出版公司，1996年3月，ISBN 0-201-63346-9
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [PPTP]. Authors of these are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
L2TP的基本概念及其许多协议结构都采用了L2F[RFC2341]和PPTP[PPTP]。这些报告的作者是A.瓦伦西亚、M.利特尔伍德、T.科拉尔、K.哈姆泽、G.帕尔、W.维特海因、J.塔鲁德、W.利特尔和G.佐恩。
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of this document.
Dory Leifer对L2TP的协议定义进行了有价值的改进，并对本文件的编辑做出了贡献。
Steve Cobb and Evan Caves redesigned the state machine tables.
Steve Cobb和Evan Caves重新设计了状态机表。
Barney Wolff provided a great deal of design input on the endpoint authentication mechanism.
Barney Wolff为端点身份验证机制提供了大量的设计输入。
John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL., which led to improvement of the overall readability and clarity of this document.
John Bray、Greg Burns、Rich Garrett、Don Grosser、Matt Holdrege、Terry Johnson、Dory Leifer和Rich Shea在佛罗里达州奥兰多举行的第43届IETF上提供了宝贵的意见和评论，从而提高了本文件的整体可读性和清晰度。
Gurdeep Singh Pall Microsoft Corporation Redmond, WA
格迪普·辛格·帕尔微软公司，华盛顿州雷德蒙
EMail: gurdeep@microsoft.com
EMail: gurdeep@microsoft.com
Bill Palter RedBack Networks, Inc 1389 Moffett Park Drive Sunnyvale, CA 94089
Bill Palter RedBack Networks，Inc.加利福尼亚州桑尼维尔莫菲特公园大道1389号，邮编94089
EMail: palter@zev.net
EMail: palter@zev.net
Allan Rubens Ascend Communications 1701 Harbor Bay Parkway Alameda, CA 94502
美国加利福尼亚州阿拉米达港湾公园路1701号艾伦·鲁本斯·阿森德通信公司，邮编94502
EMail: acr@del.com
EMail: acr@del.com
W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
美国北卡罗来纳州三角研究公园14987号吉特克里克路邮政信箱7025号马克·汤斯利思科系统公司
EMail: townsley@cisco.com
EMail: townsley@cisco.com
Andrew J. Valencia cisco Systems 170 West Tasman Drive San Jose CA 95134-1706
Andrew J.Valencia cisco Systems 170加利福尼亚州圣何塞西塔斯曼大道95134-1706
EMail: vandys@cisco.com
EMail: vandys@cisco.com
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052
格伦·佐恩微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: gwz@acm.org
EMail: gwz@acm.org
Appendix A: Control Channel Slow Start and Congestion Avoidance
附录A：控制通道慢启动和拥塞避免
Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS].
尽管每一方都指出了其接收窗口的最大大小，但建议使用慢速启动和拥塞避免方法来传输控制数据包。此处描述的方法基于W.Richard Stevens[Stevens]在第一卷TCP/IP说明的第21.6节中描述的TCP拥塞避免算法。
Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP (in the text below, it is assumed any increase will be limited by the Receive Window Size). The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH.
慢启动和拥塞避免利用了几个变量。拥塞窗口（CWND）定义了发送方在等待确认之前可以发送的数据包数量。CWND的大小如下所述进行扩展和收缩。但是请注意，CWND绝不允许超过从接收窗口AVP获得的播发窗口的大小（在下面的文本中，假设任何增加都将受到接收窗口大小的限制）。变量SSTHRESH确定发送方何时从慢速启动切换到拥塞避免。当CWND小于SSHTRESH时，使用慢启动。
A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgement (either explicit or piggybacked). When the acknowledgement is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ZLB or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins.
发送器在慢启动阶段启动。CWND初始化为一个数据包，SSHTRESH初始化为播发窗口（从接收窗口AVP获得）。然后，发送方发送一个数据包并等待它的确认（显式或背驮式）。当收到确认时，拥塞窗口从1增加到2。在慢启动期间，每次接收到ACK（显式ZLB或搭载）时，CWND增加一个数据包。在每个ACK上增加一个CWND具有在每次往返时将CWND加倍的效果，从而导致指数增长。当CWND的值达到SSHTRESH时，慢启动阶段结束，拥塞避免阶段开始。
During congestion avoidance, CWND expands more slowly. Specifically, it increases by 1/CWND for every new ACK received. That is, CWND is increased by one packet after CWND new ACKs have been received. Window expansion during the congestion avoidance phase is effectively linear, with CWND increasing by one packet each round trip.
在避免拥塞期间，CWND扩展得更慢。具体地说，每接收一个新的ACK，它就增加1/CWND。也就是说，在接收到CWND新ACK之后，CWND增加一个数据包。拥塞避免阶段的窗口扩展实际上是线性的，CWND每往返增加一个数据包。
When congestion occurs (indicated by the triggering of a retransmission) one half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase.
当发生拥塞时（通过触发重传指示），CWND的一半保存在SSTHRESH中，并且CWND设置为1。然后发送器重新进入慢速启动阶段。
Appendix B: Control Message Examples
附录B：控制消息示例
B.1: Lock-step tunnel establishment
B.1：锁定台阶隧道的建立
In this example, an LAC establishes a tunnel, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within a ZLB ACK message. An alternative would be to piggyback the acknowledgement within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the tunnel.
在本例中，LAC建立了一个隧道，交换涉及到每一方交替发送消息。此示例显示在ZLB ACK消息中显式发送的最终确认。另一种方法是，在作为ICRQ或OCRQ回复发送的消息中携带确认信息，该消息可能来自启动隧道的一方。
LAC or LNS LNS or LAC
---------- ----------
LAC or LNS LNS or LAC
---------- ----------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ZLB
Nr: 2, Ns: 1
B.2: Lost packet with retransmission
B.2：具有重传的丢失数据包
An existing tunnel has a new session requested by the LAC. The ICRP is lost and must be retransmitted by the LNS. Note that loss of the ICRP has two impacts: not only does it keep the upper level state machine from progressing, but it also keeps the LAC from seeing a timely lower level acknowledgment of its ICRQ.
现有隧道有LAC要求的新会话。ICRP丢失，必须由LNS重新传输。请注意，ICRP的丢失有两个影响：它不仅使上层状态机无法运行，而且还使LAC无法看到及时的下层ICRQ确认。
LAC LNS
--- ---
LAC LNS
--- ---
ICRQ ->
Nr: 1, Ns: 2
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP Nr: 3, Ns: 1
（数据包丢失）<-ICRP编号：3，Ns:1
(pause; LAC's timer started first, so fires first)
（暂停；LAC的计时器先启动，所以先触发）
ICRQ ->
Nr: 1, Ns: 2
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet, the LNS discards the packet and sends a ZLB)
（LNS意识到已经看到该数据包，因此丢弃该数据包并发送ZLB）
<- ZLB Nr: 3, Ns: 2
<-ZLB编号：3，Ns:2
(LNS's retransmit timer fires)
（LNS的重传定时器触发）
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ZLB Nr: 4, Ns: 2
<-ZLB编号：4，Ns:2
Appendix C: Intellectual Property Notice
附录C：知识产权公告
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 implementers 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执行董事。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。