Network Working Group J. Lau, Ed.
Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
Network Working Group J. Lau, Ed.
Request for Comments: 3931 M. Townsley, Ed.
Category: Standards Track Cisco Systems
I. Goyret, Ed.
Lucent Technologies
March 2005
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
第二层隧道协议-版本3（L2TPv3）
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes "version 3" of the Layer Two Tunneling Protocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between two IP nodes. Additional documents detail the specifics for each data link type being emulated.
本文档描述了第二层隧道协议（L2TPv3）的“版本3”。L2TPv3定义了用于在两个IP节点之间通过隧道传输多个第2层连接的基本控制协议和封装。其他文档详细说明了所模拟的每种数据链路类型的细节。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Changes from RFC 2661. . . . . . . . . . . . . . . . . . 4
1.2. Specification of Requirements. . . . . . . . . . . . . . 4
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Control Message Types. . . . . . . . . . . . . . . . . . 10
3.2. L2TP Header Formats. . . . . . . . . . . . . . . . . . . 11
3.2.1. L2TP Control Message Header. . . . . . . . . . . 11
3.2.2. L2TP Data Message. . . . . . . . . . . . . . . . 12
3.3. Control Connection Management. . . . . . . . . . . . . . 13
3.3.1. Control Connection Establishment . . . . . . . . 14
3.3.2. Control Connection Teardown. . . . . . . . . . . 14
3.4. Session Management . . . . . . . . . . . . . . . . . . . 15
3.4.1. Session Establishment for an Incoming Call . . . 15
3.4.2. Session Establishment for an Outgoing Call . . . 15
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
3.4.3. Session Teardown . . . . . . . . . . . . . . . . 16
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
4.1. L2TP Over Specific Packet-Switched Networks (PSNs) . . . 16
4.1.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 17
4.1.2. L2TP over UDP. . . . . . . . . . . . . . . . . . 18
4.1.3. L2TP and IPsec . . . . . . . . . . . . . . . . . 20
4.1.4. IP Fragmentation Issues. . . . . . . . . . . . . 21
4.2. Reliable Delivery of Control Messages. . . . . . . . . . 23
4.3. Control Message Authentication . . . . . . . . . . . . . 25
4.4. Keepalive (Hello). . . . . . . . . . . . . . . . . . . . 26
4.5. Forwarding Session Data Frames . . . . . . . . . . . . . 26
4.6. Default L2-Specific Sublayer . . . . . . . . . . . . . . 27
4.6.1. Sequencing Data Packets. . . . . . . . . . . . . 28
4.7. L2TPv2/v3 Interoperability and Migration . . . . . . . . 28
4.7.1. L2TPv3 over IP . . . . . . . . . . . . . . . . . 29
4.7.2. L2TPv3 over UDP. . . . . . . . . . . . . . . . . 29
4.7.3. Automatic L2TPv2 Fallback. . . . . . . . . . . . 29
5. Control Message Attribute Value Pairs. . . . . . . . . . . . . 30
5.1. AVP Format . . . . . . . . . . . . . . . . . . . . . . . 30
5.2. Mandatory AVPs and Setting the M Bit . . . . . . . . . . 32
5.3. Hiding of AVP Attribute Values . . . . . . . . . . . . . 33
5.4. AVP Summary. . . . . . . . . . . . . . . . . . . . . . . 36
5.4.1. General Control Message AVPs . . . . . . . . . . 36
5.4.2. Result and Error Codes . . . . . . . . . . . . . 40
5.4.3. Control Connection Management AVPs . . . . . . . 43
5.4.4. Session Management AVPs. . . . . . . . . . . . . 48
5.4.5. Circuit Status AVPs. . . . . . . . . . . . . . . 57
6. Control Connection Protocol Specification. . . . . . . . . . . 59
6.1. Start-Control-Connection-Request (SCCRQ) . . . . . . . . 60
6.2. Start-Control-Connection-Reply (SCCRP) . . . . . . . . . 60
6.3. Start-Control-Connection-Connected (SCCCN) . . . . . . . 61
6.4. Stop-Control-Connection-Notification (StopCCN) . . . . . 61
6.5. Hello (HELLO). . . . . . . . . . . . . . . . . . . . . . 61
6.6. Incoming-Call-Request (ICRQ) . . . . . . . . . . . . . . 62
6.7. Incoming-Call-Reply (ICRP) . . . . . . . . . . . . . . . 63
6.8. Incoming-Call-Connected (ICCN) . . . . . . . . . . . . . 63
6.9. Outgoing-Call-Request (OCRQ) . . . . . . . . . . . . . . 64
6.10. Outgoing-Call-Reply (OCRP) . . . . . . . . . . . . . . . 65
6.11. Outgoing-Call-Connected (OCCN) . . . . . . . . . . . . . 65
6.12. Call-Disconnect-Notify (CDN) . . . . . . . . . . . . . . 66
6.13. WAN-Error-Notify (WEN) . . . . . . . . . . . . . . . . . 66
6.14. Set-Link-Info (SLI). . . . . . . . . . . . . . . . . . . 67
6.15. Explicit-Acknowledgement (ACK) . . . . . . . . . . . . . 67
7. Control Connection State Machines. . . . . . . . . . . . . . . 68
7.1. Malformed AVPs and Control Messages. . . . . . . . . . . 68
7.2. Control Connection States. . . . . . . . . . . . . . . . 69
7.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 71
7.3.1. ICRQ Sender States . . . . . . . . . . . . . . . 72
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
7.3.2. ICRQ Recipient States. . . . . . . . . . . . . . 73
7.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 74
7.4.1. OCRQ Sender States . . . . . . . . . . . . . . . 75
7.4.2. OCRQ Recipient (LAC) States. . . . . . . . . . . 76
7.5. Termination of a Control Connection. . . . . . . . . . . 77
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 78
8.1. Control Connection Endpoint and Message Security . . . . 78
8.2. Data Packet Spoofing . . . . . . . . . . . . . . . . . . 78
9. Internationalization Considerations. . . . . . . . . . . . . . 79
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 80
10.1. Control Message Attribute Value Pairs (AVPs) . . . . . . 80
10.2. Message Type AVP Values. . . . . . . . . . . . . . . . . 81
10.3. Result Code AVP Values . . . . . . . . . . . . . . . . . 81
10.4. AVP Header Bits. . . . . . . . . . . . . . . . . . . . . 82
10.5. L2TP Control Message Header Bits . . . . . . . . . . . . 82
10.6. Pseudowire Types . . . . . . . . . . . . . . . . . . . . 83
10.7. Circuit Status Bits. . . . . . . . . . . . . . . . . . . 83
10.8. Default L2-Specific Sublayer bits. . . . . . . . . . . . 84
10.9. L2-Specific Sublayer Type. . . . . . . . . . . . . . . . 84
10.10 Data Sequencing Level. . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 85
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 87
Appendix A: Control Slow Start and Congestion Avoidance. . . . . . 89
Appendix B: Control Message Examples . . . . . . . . . . . . . . . 90
Appendix C: Processing Sequence Numbers. . . . . . . . . . . . . . 91
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 94
The Layer Two Tunneling Protocol (L2TP) provides a dynamic mechanism for tunneling Layer 2 (L2) "circuits" across a packet-oriented data network (e.g., over IP). L2TP, as originally defined in RFC 2661, is a standard method for tunneling Point-to-Point Protocol (PPP) [RFC1661] sessions. L2TP has since been adopted for tunneling a number of other L2 protocols. In order to provide greater modularity, this document describes the base L2TP protocol, independent of the L2 payload that is being tunneled.
第二层隧道协议（L2TP）为跨面向分组的数据网络（例如，通过IP）隧道第二层（L2）“电路”提供了一种动态机制。L2TP最初在RFC 2661中定义，是隧道点对点协议（PPP）[RFC1661]会话的标准方法。L2TP已经被用于隧道传输许多其他L2协议。为了提供更大的模块化，本文档描述了基本L2TP协议，该协议独立于正在进行隧道传输的L2有效负载。
The base L2TP protocol defined in this document consists of (1) the control protocol for dynamic creation, maintenance, and teardown of L2TP sessions, and (2) the L2TP data encapsulation to multiplex and demultiplex L2 data streams between two L2TP nodes across an IP network. Additional documents are expected to be published for each L2 data link emulation type (a.k.a. pseudowire-type) supported by L2TP (i.e., PPP, Ethernet, Frame Relay, etc.). These documents will
本文档中定义的基本L2TP协议包括（1）用于动态创建、维护和拆除L2TP会话的控制协议，以及（2）用于在IP网络上的两个L2TP节点之间复用和解复用L2TP数据流的L2TP数据封装。对于L2TP支持的每种L2数据链路仿真类型（也称为伪线类型）（即PPP、以太网、帧中继等），预计将发布其他文档。这些文件将
contain any pseudowire-type specific details that are outside the scope of this base specification.
包含超出本基本规范范围的任何特定于伪导线类型的详细信息。
When the designation between L2TPv2 and L2TPv3 is necessary, L2TP as defined in RFC 2661 will be referred to as "L2TPv2", corresponding to the value in the Version field of an L2TP header. (Layer 2 Forwarding, L2F, [RFC2341] was defined as "version 1".) At times, L2TP as defined in this document will be referred to as "L2TPv3". Otherwise, the acronym "L2TP" will refer to L2TPv3 or L2TP in general.
当L2TPv2和L2TPv3之间需要指定时，RFC 2661中定义的L2TP将被称为“L2TPv2”，对应于L2TP标头版本字段中的值。（第二层转发，L2F，[RFC2341]被定义为“版本1”。）有时，本文件中定义的L2TP将被称为“L2TPv3”。否则，缩写词“L2TP”通常指L2TPv3或L2TP。
Many of the protocol constructs described in this document are carried over from RFC 2661. Changes include clarifications based on years of interoperability and deployment experience as well as modifications to either improve protocol operation or provide a clearer separation from PPP. The intent of these modifications is to achieve a healthy balance between code reuse, interoperability experience, and a directed evolution of L2TP as it is applied to new tasks.
本文档中描述的许多协议结构都是从RFC 2661继承而来的。变化包括基于多年互操作性和部署经验的澄清，以及改进协议操作或提供与PPP的更清晰分离的修改。这些修改的目的是在代码重用、互操作性体验和L2TP应用于新任务时的定向演进之间实现健康的平衡。
Notable differences between L2TPv2 and L2TPv3 include the following:
L2TPv2和L2TPv3之间的显著差异包括：
Separation of all PPP-related AVPs, references, etc., including a portion of the L2TP data header that was specific to the needs of PPP. The PPP-specific constructs are described in a companion document.
分离所有与PPP相关的AVP、参考等，包括L2TP数据头中特定于PPP需求的一部分。PPP特定结构在配套文件中进行了描述。
Transition from a 16-bit Session ID and Tunnel ID to a 32-bit Session ID and Control Connection ID, respectively.
分别从16位会话ID和隧道ID转换为32位会话ID和控制连接ID。
Extension of the Tunnel Authentication mechanism to cover the entire control message rather than just a portion of certain messages.
扩展隧道身份验证机制，以覆盖整个控制消息，而不仅仅是某些消息的一部分。
Details of these changes and a recommendation for transitioning to L2TPv3 are discussed in Section 4.7.
第4.7节讨论了这些更改的详细信息以及向L2TPv3过渡的建议。
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]中所述进行解释。
Attribute Value Pair (AVP)
属性值对（AVP）
The variable-length concatenation of a unique Attribute (represented by an integer), a length field, and a Value containing the actual value identified by the attribute. Zero or more AVPs make up the body of control messages, which are used in the establishment, maintenance, and teardown of control connections. This basic construct is sometimes referred to as a Type-Length-Value (TLV) in some specifications. (See also: Control Connection, Control Message.)
唯一属性（由整数表示）、长度字段和包含属性标识的实际值的值的可变长度串联。零个或多个AVP构成控制消息体，用于建立、维护和断开控制连接。在某些规范中，这种基本构造有时称为类型长度值（TLV）。（另请参见：控制连接，控制消息。）
Call (Circuit Up)
呼叫（电路接通）
The action of transitioning a circuit on an L2TP Access Concentrator (LAC) to an "up" or "active" state. A call may be dynamically established through signaling properties (e.g., an incoming or outgoing call through the Public Switched Telephone Network (PSTN)) or statically configured (e.g., provisioning a Virtual Circuit on an interface). A call is defined by its properties (e.g., type of call, called number, etc.) and its data traffic. (See also: Circuit, Session, Incoming Call, Outgoing Call, Outgoing Call Request.)
将L2TP接入集中器（LAC）上的电路转换为“启动”或“激活”状态的动作。呼叫可以通过信令属性（例如，通过公共交换电话网（PSTN）的传入或传出呼叫）动态地建立，或者静态地配置（例如，在接口上提供虚拟电路）。呼叫由其属性（例如呼叫类型、被叫号码等）及其数据流量定义。（另请参见：电路、会话、传入呼叫、传出呼叫、传出呼叫请求。）
Circuit
环行
A general term identifying any one of a wide range of L2 connections. A circuit may be virtual in nature (e.g., an ATM PVC, an IEEE 802 VLAN, or an L2TP session), or it may have direct correlation to a physical layer (e.g., an RS-232 serial line). Circuits may be statically configured with a relatively long-lived uptime, or dynamically established with signaling to govern the establishment, maintenance, and teardown of the circuit. For the purposes of this document, a statically configured circuit is considered to be essentially the same as a very simple, long-lived, dynamic circuit. (See also: Call, Remote System.)
一个通用术语，用于识别各种L2连接中的任何一个。电路本质上可能是虚拟的（例如，ATM PVC、IEEE 802 VLAN或L2TP会话），或者它可能与物理层（例如，RS-232串行线）直接相关。电路可以用相对较长的正常运行时间静态地配置，或者用信令动态地建立，以控制电路的建立、维护和拆卸。在本文档中，静态配置电路与非常简单、长寿命的动态电路基本相同。（另请参见：呼叫、远程系统。）
Client
客户
(See Remote System.)
（请参阅远程系统。）
Control Connection
控制连接
An L2TP control connection is a reliable control channel that is used to establish, maintain, and release individual L2TP sessions as well as the control connection itself. (See also: Control Message, Data Channel.)
L2TP控制连接是一个可靠的控制通道，用于建立、维护和释放各个L2TP会话以及控制连接本身。（另请参见：控制信息，数据通道。）
Control Message
控制信息
An L2TP message used by the control connection. (See also: Control Connection.)
控制连接使用的L2TP消息。（另请参见：控制连接。）
Data Message
数据电文
Message used by the data channel. (a.k.a. Data Packet, See also: Data Channel.)
数据通道使用的消息。（又称数据包，另见：数据通道。）
Data Channel
数据通道
The channel for L2TP-encapsulated data traffic that passes between two LCCEs over a Packet-Switched Network (i.e., IP). (See also: Control Connection, Data Message.)
L2TP封装数据通信的信道，通过分组交换网络（即IP）在两个LCCE之间传输。（另请参见：控制连接，数据消息。）
Incoming Call
来电
The action of receiving a call (circuit up event) on an LAC. The call may have been placed by a remote system (e.g., a phone call over a PSTN), or it may have been triggered by a local event (e.g., interesting traffic routed to a virtual interface). An incoming call that needs to be tunneled (as determined by the LAC) results in the generation of an L2TP ICRQ message. (See also: Call, Outgoing Call, Outgoing Call Request.)
在LAC上接收呼叫（电路启动事件）的动作。呼叫可能是由远程系统发出的（例如，通过PSTN的电话呼叫），也可能是由本地事件触发的（例如，路由到虚拟接口的有趣流量）。需要通过隧道传输的传入呼叫（由LAC确定）会生成L2TP ICRQ消息。（另请参见：呼叫、传出呼叫、传出呼叫请求。）
L2TP Access Concentrator (LAC)
L2TP接入集中器（LAC）
If an L2TP Control Connection Endpoint (LCCE) is being used to cross-connect an L2TP session directly to a data link, we refer to it as an L2TP Access Concentrator (LAC). An LCCE may act as both an L2TP Network Server (LNS) for some sessions and an LAC for others, so these terms must only be used within the context of a given set of sessions unless the LCCE is in fact single purpose for a given topology. (See also: LCCE, LNS.)
如果L2TP控制连接端点（LCCE）用于将L2TP会话直接交叉连接到数据链路，我们将其称为L2TP访问集中器（LAC）。LCCE可以作为某些会话的L2TP网络服务器（LNS）和其他会话的LAC，因此这些术语只能在给定会话集的上下文中使用，除非LCCE实际上是用于给定拓扑的单一用途。（另见：LCCE，LNS）
L2TP Control Connection Endpoint (LCCE)
L2TP控制连接端点（LCCE）
An L2TP node that exists at either end of an L2TP control connection. May also be referred to as an LAC or LNS, depending on whether tunneled frames are processed at the data link (LAC) or network layer (LNS). (See also: LAC, LNS.)
存在于L2TP控制连接两端的L2TP节点。也可称为LAC或LNS，这取决于是在数据链路（LAC）还是网络层（LNS）处处理隧道帧。（另见拉丁美洲和加勒比海地区，LNS）
L2TP Network Server (LNS)
L2TP网络服务器（LNS）
If a given L2TP session is terminated at the L2TP node and the encapsulated network layer (L3) packet processed on a virtual interface, we refer to this L2TP node as an L2TP Network Server
如果给定的L2TP会话在L2TP节点终止，并且封装的网络层（L3）数据包在虚拟接口上处理，则我们将此L2TP节点称为L2TP网络服务器
(LNS). A given LCCE may act as both an LNS for some sessions and an LAC for others, so these terms must only be used within the context of a given set of sessions unless the LCCE is in fact single purpose for a given topology. (See also: LCCE, LAC.)
（LNS）。给定LCCE可能同时充当某些会话的LN和其他会话的LAC，因此这些术语只能在给定会话集的上下文中使用，除非LCCE实际上是用于给定拓扑的单一用途。（另见LCCE，拉丁美洲和加勒比海）
Outgoing Call
去话呼叫
The action of placing a call by an LAC, typically in response to policy directed by the peer in an Outgoing Call Request. (See also: Call, Incoming Call, Outgoing Call Request.)
LAC发出呼叫的动作，通常是响应呼出呼叫请求中对等方指示的策略。（另请参见：呼叫、传入呼叫、传出呼叫请求。）
Outgoing Call Request
外呼请求
A request sent to an LAC to place an outgoing call. The request contains specific information not known a priori by the LAC (e.g., a number to dial). (See also: Call, Incoming Call, Outgoing Call.)
向LAC发出的拨出电话的请求。请求包含LAC事先不知道的特定信息（例如，要拨打的号码）。（另请参见：呼叫、传入呼叫、传出呼叫。）
Packet-Switched Network (PSN)
分组交换网络（PSN）
A network that uses packet switching technology for data delivery. For L2TPv3, this layer is principally IP. Other examples include MPLS, Frame Relay, and ATM.
使用分组交换技术进行数据传送的网络。对于L2TPv3，该层主要是IP。其他示例包括MPLS、帧中继和ATM。
Peer
同龄人
When used in context with L2TP, Peer refers to the far end of an L2TP control connection (i.e., the remote LCCE). An LAC's peer may be either an LNS or another LAC. Similarly, an LNS's peer may be either an LAC or another LNS. (See also: LAC, LCCE, LNS.)
在L2TP上下文中使用时，对等方指L2TP控制连接的远端（即远程LCCE）。LAC的对等方可以是LNS或其他LAC。类似地，LNS的对等方可以是LAC或另一LNS。（另见拉丁美洲和加勒比海地区、拉丁美洲和加勒比海地区、拉丁美洲和加勒比海地区。）
Pseudowire (PW)
伪导线（PW）
An emulated circuit as it traverses a PSN. There is one Pseudowire per L2TP Session. (See also: Packet-Switched Network, Session.)
通过PSN时的模拟电路。每个L2TP会话有一个伪线。（另请参见：分组交换网络，会话。）
Pseudowire Type
假丝型
The payload type being carried within an L2TP session. Examples include PPP, Ethernet, and Frame Relay. (See also: Session.)
L2TP会话中承载的有效负载类型。示例包括PPP、以太网和帧中继。（另见：会议。）
Remote System
远程系统
An end system or router connected by a circuit to an LAC.
通过电路连接到LAC的终端系统或路由器。
Session
一场
An L2TP session is the entity that is created between two LCCEs in order to exchange parameters for and maintain an emulated L2 connection. Multiple sessions may be associated with a single Control Connection.
L2TP会话是在两个LCCE之间创建的实体，用于为模拟L2连接交换参数并维护该连接。多个会话可能与单个控制连接相关联。
Zero-Length Body (ZLB) Message
零长度正文（ZLB）消息
A control message with only an L2TP header. ZLB messages are used only to acknowledge messages on the L2TP reliable control connection. (See also: Control Message.)
仅具有L2TP头的控制消息。ZLB消息仅用于确认L2TP可靠控制连接上的消息。（另请参见：控制消息。）
L2TP operates between two L2TP Control Connection Endpoints (LCCEs), tunneling traffic across a packet network. There are three predominant tunneling models in which L2TP operates: LAC-LNS (or vice versa), LAC-LAC, and LNS-LNS. These models are diagrammed below. (Dotted lines designate network connections. Solid lines designate circuit connections.)
L2TP在两个L2TP控制连接端点（LCCE）之间运行，通过数据包网络隧道传输流量。L2TP运行的主要隧道模型有三种：LAC-LNS（或反之亦然）、LAC-LAC和LNS-LNS。这些模型如下图所示。（虚线表示网络连接。实线表示电路连接。）
Figure 2.0: L2TP Reference Models
图2.0:L2TP参考模型
(a) LAC-LNS Reference Model: On one side, the LAC receives traffic from an L2 circuit, which it forwards via L2TP across an IP or other packet-based network. On the other side, an LNS logically terminates the L2 circuit locally and routes network traffic to the home network. The action of session establishment is driven by the LAC (as an incoming call) or the LNS (as an outgoing call).
(a) LAC-LNS参考模型：一方面，LAC接收来自L2电路的流量，通过L2TP在IP或其他基于分组的网络上转发。另一方面，LNS在逻辑上本地终止L2电路，并将网络流量路由到归属网络。会话建立的操作由LAC（作为传入呼叫）或LN（作为传出呼叫）驱动。
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
+-----+ L2 +-----+ +-----+
| |------| LAC |.........[ IP ].........| LNS |...[home network]
+-----+ +-----+ +-----+
remote
system
|<-- emulated service -->|
|<----------- L2 service ------------>|
(b) LAC-LAC Reference Model: In this model, both LCCEs are LACs. Each LAC forwards circuit traffic from the remote system to the peer LAC using L2TP, and vice versa. In its simplest form, an LAC acts as a simple cross-connect between a circuit to a remote system and an L2TP session. This model typically involves symmetric establishment; that is, either side of the connection may initiate a session at any time (or simultaneously, in which a tie breaking mechanism is utilized).
(b) LAC-LAC参考模型：在该模型中，两个LCCE均为LAC。每个LAC使用L2TP将电路通信量从远程系统转发到对等LAC，反之亦然。在最简单的形式中，LAC充当远程系统电路和L2TP会话之间的简单交叉连接。该模型通常涉及对称建立；也就是说，连接的任一侧可以在任何时间（或同时，其中使用了断开连接机制）发起会话。
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
+-----+ L2 +-----+ +-----+ L2 +-----+
| |------| LAC |........[ IP ]........| LAC |------| |
+-----+ +-----+ +-----+ +-----+
remote remote
system system
|<- emulated service ->|
|<----------------- L2 service ----------------->|
(c) LNS-LNS Reference Model: This model has two LNSs as the LCCEs. A user-level, traffic-generated, or signaled event typically drives session establishment from one side of the tunnel. For example, a tunnel generated from a PC by a user, or automatically by customer premises equipment.
(c) LNS-LNS参考模型：该模型有两个LNS作为LCCE。用户级、生成的流量或发出信号的事件通常从隧道的一侧驱动会话建立。例如，由用户从PC生成的隧道，或由客户设备自动生成的隧道。
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
+-----+ +-----+
[home network]...| LNS |........[ IP ]........| LNS |...[home network]
+-----+ +-----+
|<- emulated service ->|
|<---- L2 service ---->|
Note: In L2TPv2, user-driven tunneling of this type is often referred to as "voluntary tunneling" [RFC2809]. Further, an LNS acting as part of a software package on a host is sometimes referred to as an "LAC Client" [RFC2661].
注：在L2TPv2中，这种类型的用户驱动隧道通常被称为“自愿隧道”[RFC2809]。此外，作为主机上软件包一部分的LNS有时被称为“LAC客户端”[RFC2661]。
L2TP is comprised of two types of messages, control messages and data messages (sometimes referred to as "control packets" and "data packets", respectively). Control messages are used in the establishment, maintenance, and clearing of control connections and sessions. These messages utilize a reliable control channel within L2TP to guarantee delivery (see Section 4.2 for details). Data messages are used to encapsulate the L2 traffic being carried over the L2TP session. Unlike control messages, data messages are not retransmitted when packet loss occurs.
L2TP由两类消息组成，即控制消息和数据消息（有时分别称为“控制包”和“数据包”）。控制消息用于建立、维护和清除控制连接和会话。这些消息利用L2TP内的可靠控制通道来保证传输（详见第4.2节）。数据消息用于封装L2TP会话上承载的L2通信量。与控制消息不同，数据消息在发生数据包丢失时不会重新传输。
The L2TPv3 control message format defined in this document borrows largely from L2TPv2. These control messages are used in conjunction with the associated protocol state machines that govern the dynamic setup, maintenance, and teardown for L2TP sessions. The data message format for tunneling data packets may be utilized with or without the L2TP control channel, either via manual configuration or via other signaling methods to pre-configure or distribute L2TP session information. Utilization of the L2TP data message format with other signaling methods is outside the scope of this document.
本文档中定义的L2TPv3控制消息格式主要借鉴L2TPv2。这些控制消息与控制L2TP会话的动态设置、维护和拆卸的相关协议状态机一起使用。隧道数据分组的数据消息格式可以通过手动配置或通过其他信令方法在有或没有L2TP控制信道的情况下使用，以预配置或分发L2TP会话信息。L2TP数据消息格式与其他信令方法的使用不在本文件范围内。
Figure 3.0: L2TPv3 Structure
图3.0:L2TPv3结构
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
+-------------------+ +-----------------------+
| Tunneled Frame | | L2TP Control Message |
+-------------------+ +-----------------------+
| L2TP Data Header | | L2TP Control Header |
+-------------------+ +-----------------------+
| L2TP Data Channel | | L2TP Control Channel |
| (unreliable) | | (reliable) |
+-------------------+----+-----------------------+
| Packet-Switched Network (IP, FR, MPLS, etc.) |
+------------------------------------------------+
Figure 3.0 depicts the relationship of control messages and data messages over the L2TP control and data channels, respectively. Data messages are passed over an unreliable data channel, encapsulated by an L2TP header, and sent over a Packet-Switched Network (PSN) such as IP, UDP, Frame Relay, ATM, MPLS, etc. Control messages are sent over a reliable L2TP control channel, which operates over the same PSN.
图3.0分别描述了L2TP控制通道和数据通道上控制消息和数据消息的关系。数据消息通过不可靠的数据通道传递，由L2TP报头封装，并通过分组交换网络（PSN）发送，如IP、UDP、帧中继、ATM、MPLS等。控制消息通过可靠的L2TP控制通道发送，该控制通道在同一PSN上运行。
The necessary setup for tunneling a session with L2TP consists of two steps: (1) Establishing the control connection, and (2) establishing a session as triggered by an incoming call or outgoing call. An L2TP session MUST be established before L2TP can begin to forward session frames. Multiple sessions may be bound to a single control connection, and multiple control connections may exist between the same two LCCEs.
使用L2TP隧道会话的必要设置包括两个步骤：（1）建立控制连接，（2）建立由传入呼叫或传出呼叫触发的会话。L2TP开始转发会话帧之前，必须先建立L2TP会话。多个会话可以绑定到单个控制连接，并且同两个LCCE之间可能存在多个控制连接。
The Message Type AVP (see Section 5.4.1) defines the specific type of control message being sent.
消息类型AVP（见第5.4.1节）定义了所发送控制消息的具体类型。
This document defines the following control message types (see Sections 6.1 through 6.15 for details on the construction and use of each message):
本文件定义了以下控制消息类型（有关每条消息的构造和使用的详细信息，请参见第6.1节至第6.15节）：
Control Connection Management
控制连接管理
0 (reserved) 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 20 (ACK) Explicit Acknowledgement
0（保留）1（SCCRQ）启动控制连接请求2（SCCRP）启动控制连接回复3（SCCCN）启动控制连接已连接4（StopCCN）停止控制连接通知5（保留）6（你好）你好20（确认）明确确认
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错误通知
Link Status Change Reporting
链接状态更改报告
16 (SLI) Set-Link-Info
16（SLI）设置链接信息
This section defines header formats for L2TP control messages and L2TP data messages. All values are placed into their respective fields and sent in network order (high-order octets first).
本节定义L2TP控制消息和L2TP数据消息的标题格式。所有值都放在各自的字段中，并按网络顺序发送（首先是高阶八位字节）。
The L2TP control message header provides information for the reliable transport of messages that govern the establishment, maintenance, and teardown of L2TP sessions. By default, control messages are sent over the underlying media in-band with L2TP data messages.
L2TP控制消息头提供可靠传输消息的信息，这些消息控制L2TP会话的建立、维护和拆卸。默认情况下，控制消息与L2TP数据消息一起通过底层带内媒体发送。
The L2TP control message header is formatted as follows:
L2TP控制消息头的格式如下：
Figure 3.2.1: L2TP Control Message Header
图3.2.1:L2TP控制消息头
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|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 1, indicating that this is a control message.
T位必须设置为1，表示这是一条控制消息。
The L and S bits MUST be set to 1, indicating that the Length field and sequence numbers are present.
L和S位必须设置为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，传入消息的所有保留位必须忽略。
The Ver field indicates the version of the L2TP control message header described in this document. On sending, this field MUST be set to 3 for all messages (unless operating in an environment that includes L2TPv2 [RFC2661] and/or L2F [RFC2341] as well, see Section 4.1 for details).
Ver字段表示本文档中描述的L2TP控制消息头的版本。发送时，必须将所有消息的此字段设置为3（除非在包含L2TPv2[RFC2661]和/或L2F[RFC2341]的环境中运行，详细信息请参见第4.1节）。
The Length field indicates the total length of the message in octets, always calculated from the start of the control message header itself (beginning with the T bit).
长度字段以八位字节表示消息的总长度，始终从控制消息头本身的开头（以T位开始）开始计算。
The Control Connection ID field contains the identifier for the control connection. L2TP control connections are named by identifiers that have local significance only. That is, the same control connection will be given unique Control Connection IDs by each LCCE from within each endpoint's own Control Connection ID number space. As such, the Control Connection ID in each message is that of the intended recipient, not the sender. Non-zero Control Connection IDs are selected and exchanged as Assigned Control Connection ID AVPs during the creation of a control connection.
控制连接ID字段包含控制连接的标识符。L2TP控制连接由仅具有本地意义的标识符命名。也就是说，相同的控制连接将由每个LCCE从每个端点自己的控制连接ID号空间中提供唯一的控制连接ID。因此，每条消息中的控制连接ID是预期收件人的ID，而不是发件人的ID。在创建控制连接期间，选择非零控制连接ID并将其交换为分配的控制连接ID AVP。
Ns indicates the sequence number for this control message, beginning at zero and incrementing by one (modulo 2**16) for each message sent. See Section 4.2 for more information on using this field.
Ns表示此控制消息的序列号，从零开始，每发送一条消息递增一（模2**16）。有关使用此字段的更多信息，请参见第4.2节。
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). See Section 4.2 for more information on using this field.
Nr表示下一条控制消息中预期接收的序列号。因此，Nr被设置为接收到的最后一条顺序消息的Ns加1（模2**16）。有关使用此字段的更多信息，请参见第4.2节。
In general, an L2TP data message consists of a (1) Session Header, (2) an optional L2-Specific Sublayer, and (3) the Tunnel Payload, as depicted below.
通常，L2TP数据消息由（1）会话头、（2）可选的L2特定子层和（3）隧道有效负载组成，如下所示。
Figure 3.2.2: L2TP Data Message Header
图3.2.2:L2TP数据消息头
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2TP Session Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TP Session Header is specific to the encapsulating PSN over which the L2TP traffic is delivered. The Session Header MUST provide (1) a method of distinguishing traffic among multiple L2TP data sessions and (2) a method of distinguishing data messages from control messages.
L2TP会话头特定于封装PSN，L2TP通信通过该PSN进行传输。会话头必须提供（1）区分多个L2TP数据会话之间通信量的方法和（2）区分数据消息和控制消息的方法。
Each type of encapsulating PSN MUST define its own session header, clearly identifying the format of the header and parameters necessary to setup the session. Section 4.1 defines two session headers, one for transport over UDP and one for transport over IP.
每种类型的封装PSN必须定义自己的会话头，明确标识头的格式和设置会话所需的参数。第4.1节定义了两个会话头，一个用于UDP传输，另一个用于IP传输。
The L2-Specific Sublayer is an intermediary layer between the L2TP session header and the start of the tunneled frame. It contains control fields that are used to facilitate the tunneling of each frame (e.g., sequence numbers or flags). The Default L2-Specific Sublayer for L2TPv3 is defined in Section 4.6.
L2特定子层是L2TP会话头和隧道帧开始之间的中间层。它包含用于促进每个帧的隧道传输的控制字段（例如，序列号或标志）。L2TPv3的默认L2特定子层在第4.6节中定义。
The Data Message Header is followed by the Tunnel Payload, including any necessary L2 framing as defined in the payload-specific companion documents.
数据消息头后面是隧道有效载荷，包括有效载荷特定配套文档中定义的任何必要的L2帧。
The L2TP control connection handles dynamic establishment, teardown, and maintenance of the L2TP sessions and of the control connection itself. The reliable delivery of control messages is described in Section 4.2.
L2TP控制连接处理L2TP会话和控制连接本身的动态建立、拆卸和维护。第4.2节描述了控制信息的可靠传递。
This section describes typical control connection establishment and teardown exchanges. It is important to note that, in the diagrams that follow, the reliable control message delivery mechanism exists independently of the L2TP state machine. For instance, Explicit Acknowledgement (ACK) messages may be sent after any of the control messages indicated in the exchanges below if an acknowledgment is not piggybacked on a later control message.
本节介绍典型的控制连接建立和拆卸交换。需要注意的是，在下面的图中，可靠的控制消息传递机制独立于L2TP状态机。例如，如果确认没有在后面的控制消息上进行，则显式确认（ACK）消息可以在下面的交换中指示的任何控制消息之后发送。
LCCEs are identified during control connection establishment either by the Host Name AVP, the Router ID AVP, or a combination of the two (see Section 5.4.3). The identity of a peer LCCE is central to selecting proper configuration parameters (i.e., Hello interval, window size, etc.) for a control connection, as well as for determining how to set up associated sessions within the control connection, password lookup for control connection authentication, control connection level tie breaking, etc.
LCCE在控制连接建立期间通过主机名AVP、路由器ID AVP或两者的组合进行标识（见第5.4.3节）。对等LCCE的标识对于为控制连接选择适当的配置参数（即，Hello间隔、窗口大小等）以及确定如何在控制连接内设置关联会话、控制连接身份验证的密码查找、控制连接级别断开连接等至关重要。
Establishment of the control connection involves an exchange of AVPs that identifies the peer and its capabilities.
控制连接的建立涉及到AVP的交换，AVP识别对等方及其能力。
A three-message exchange is used to establish the control connection. The following is a typical message exchange:
三条消息交换用于建立控制连接。以下是典型的消息交换：
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
LCCE A LCCE B
------ ------
SCCRQ ->
<- SCCRP
SCCCN ->
Control connection teardown may be initiated by either LCCE and is accomplished by sending a single StopCCN control message. As part of the reliable control message delivery mechanism, the recipient of a StopCCN MUST send an ACK message 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 ACK message is lost). The recommended time for a full retransmission cycle is at least 31 seconds (see Section 4.2). The following is an example of a typical control message exchange:
控制连接断开可由任一LCCE启动，并通过发送单个StopCCN控制消息来完成。作为可靠控制消息传递机制的一部分，StopCCN的接收者必须发送ACK消息以确认消息的接收，并保持足够的控制连接状态，以便在至少一个完整的重传周期内（在ACK消息丢失的情况下）正确接受StopCCN重传。完整重传周期的建议时间至少为31秒（见第4.2节）。以下是典型控制消息交换的示例：
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
LCCE A LCCE B
------ ------
StopCCN ->
(Clean up)
(Wait) (Clean up)
（等待）（清理）
An implementation may shut down an entire control connection and all sessions associated with the control connection by sending the StopCCN. Thus, it is not necessary to clear each session individually when tearing down the whole control connection.
实现可以通过发送StopCCN来关闭整个控制连接以及与该控制连接相关联的所有会话。因此，在断开整个控制连接时，不必单独清除每个会话。
After successful control connection establishment, individual sessions may be created. Each session corresponds to a single data stream between the two LCCEs. This section describes the typical call establishment and teardown exchanges.
成功建立控制连接后，可以创建单独的会话。每个会话对应于两个LCCE之间的单个数据流。本节介绍典型的呼叫建立和拆卸交换。
A three-message exchange is used to establish the session. The following is a typical sequence of events:
三条消息交换用于建立会话。以下是一系列典型的事件：
LCCE A LCCE B
------ ------
(Call
Detected)
LCCE A LCCE B
------ ------
(Call
Detected)
ICRQ -> <- ICRP (Call Accepted)
ICRQ-><-ICRP（接受呼叫）
ICCN ->
ICCN->
A three-message exchange is used to set up the session. The following is a typical sequence of events:
三个消息交换用于设置会话。以下是一系列典型的事件：
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
LCCE A LCCE B
------ ------
<- OCRQ
OCRP ->
(Perform Call Operation)
（执行呼叫操作）
OCCN ->
OCCN->
(Call Operation Completed Successfully)
（呼叫操作已成功完成）
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). The following is an example of a typical control message exchange:
会话拆卸可由LAC或LN启动，并通过发送CDN控制消息来完成。在最后一个会话被清除后，控制连接也可能被断开（通常是断开）。以下是典型控制消息交换的示例：
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
LCCE A LCCE B
------ ------
CDN ->
(Clean up)
(Clean up)
（清理）
L2TP may operate over a variety of PSNs. There are two modes described for operation over IP, L2TP directly over IP (see Section 4.1.1) and L2TP over UDP (see Section 4.1.2). L2TPv3 implementations MUST support L2TP over IP and SHOULD support L2TP over UDP for better NAT and firewall traversal, and for easier migration from L2TPv2.
L2TP可以在各种PSN上运行。IP上的操作有两种模式，L2TP直接通过IP（见第4.1.1节）和L2TP通过UDP（见第4.1.2节）。L2TPv3实现必须支持IP上的L2TP，并且应该支持UDP上的L2TP，以便更好地穿越NAT和防火墙，并更容易从L2TPv2迁移。
L2TP over other PSNs may be defined, but the specifics are outside the scope of this document. Examples of L2TPv2 over other PSNs include [RFC3070] and [RFC3355].
可以定义其他PSN上的L2TP，但具体内容不在本文档范围内。其他PSN上的L2TPv2示例包括[RFC3070]和[RFC3355]。
The following field definitions are defined for use in all L2TP Session Header encapsulations.
定义了以下字段定义，以便在所有L2TP会话头封装中使用。
Session ID
会话ID
A 32-bit field containing a non-zero identifier for a session. L2TP sessions are named by identifiers that have local significance only. That is, the same logical session will be given different Session IDs by each end of the control connection for the life of the session. When the L2TP control connection is used for session establishment, Session IDs are selected and exchanged as Local Session ID AVPs during the creation of a session. The Session ID alone provides the necessary context for all further packet processing, including the presence, size, and value of the Cookie, the type of L2-Specific Sublayer, and the type of payload being tunneled.
包含会话非零标识符的32位字段。L2TP会话由仅具有本地意义的标识符命名。也就是说，在会话的生命周期内，控制连接的每一端都将为同一逻辑会话提供不同的会话ID。当L2TP控制连接用于会话建立时，会话ID在会话创建期间被选择并交换为本地会话ID AVP。会话ID本身为所有进一步的数据包处理提供了必要的上下文，包括Cookie的存在、大小和值、L2特定子层的类型以及正在隧道传输的有效负载的类型。
Cookie
曲奇
The optional Cookie field contains a variable-length value (maximum 64 bits) used to check the association of a received data message with the session identified by the Session ID. The Cookie MUST be set to the configured or signaled random value for this session. The Cookie provides an additional level of guarantee that a data message has been directed to the proper session by the Session ID. A well-chosen Cookie may prevent inadvertent misdirection of stray packets with recently reused Session IDs, Session IDs subject to packet corruption, etc. The Cookie may also provide protection against some specific malicious packet insertion attacks, as described in Section 8.2.
可选Cookie字段包含一个可变长度值（最大64位），用于检查接收到的数据消息与会话ID标识的会话的关联。必须将Cookie设置为该会话的已配置或已发信号的随机值。Cookie提供了额外级别的保证，即会话ID已将数据消息定向到正确的会话。精心选择的Cookie可防止无意中误传具有最近重用的会话ID、易受数据包损坏的会话ID的杂散数据包，如第8.2节所述，Cookie还可以针对某些特定的恶意数据包插入攻击提供保护。
When the L2TP control connection is used for session establishment, random Cookie values are selected and exchanged as Assigned Cookie AVPs during session creation.
当L2TP控制连接用于会话建立时，随机Cookie值将被选择，并在会话创建期间作为分配的Cookie AVP进行交换。
L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol ID 115.
L2TPv3 over IP（两个版本）利用IANA分配的IP协议ID 115。
Unlike L2TP over UDP, the L2TPv3 session header over IP is free of any restrictions imposed by coexistence with L2TPv2 and L2F. As such, the header format has been designed to optimize packet processing. The following session header format is utilized when operating L2TPv3 over IP:
与UDP上的L2TP不同，IP上的L2TPv3会话头不受L2TPv2和L2F共存所施加的任何限制。因此，报头格式设计用于优化数据包处理。通过IP操作L2TPv3时使用以下会话头格式：
Figure 4.1.1.1: L2TPv3 Session Header Over IP
图4.1.1.1:IP上的L2TPv3会话头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session ID and Cookie fields are as defined in Section 4.1. The Session ID of zero is reserved for use by L2TP control messages (see Section 4.1.1.2).
会话ID和Cookie字段如第4.1节所定义。会话ID为零保留供L2TP控制消息使用（参见第4.1.1.2节）。
Unlike L2TP over UDP, which uses the T bit to distinguish between L2TP control and data packets, L2TP over IP uses the reserved Session ID of zero (0) when sending control messages. It is presumed that checking for the zero Session ID is more efficient -- both in header size for data packets and in processing speed for distinguishing between control and data messages -- than checking a single bit.
与UDP上的L2TP使用T位区分L2TP控制和数据包不同，IP上的L2TP在发送控制消息时使用保留会话ID零（0）。据推测，检查零会话ID比检查单个位更有效——无论是在数据包的报头大小方面，还是在区分控制消息和数据消息的处理速度方面。
The entire control message header over IP, including the zero session ID, appears as follows:
整个IP控制消息头（包括零会话ID）显示如下：
Figure 4.1.1.2: L2TPv3 Control Message Header Over IP
图4.1.1.2:L2TPv3 IP控制消息头
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (32 bits of zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|x|x|x|x|x|x| Ver | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ns | Nr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Named fields are as defined in Section 3.2.1. Note that the Length field is still calculated from the beginning of the control message header, beginning with the T bit. It does NOT include the "(32 bits of zeros)" depicted above.
命名字段的定义见第3.2.1节。请注意，长度字段仍然从控制消息头的开头开始计算，从T位开始。它不包括上面描述的“（32位零）”。
When operating directly over IP, L2TP packets lose the ability to take advantage of the UDP checksum as a simple packet integrity check, which is of particular concern for L2TP control messages. Control Message Authentication (see Section 4.3), even with an empty password field, provides for a sufficient packet integrity check and SHOULD always be enabled.
当直接通过IP操作时，L2TP数据包失去了利用UDP校验和作为简单数据包完整性检查的能力，这是L2TP控制消息特别关注的问题。控制消息身份验证（见第4.3节），即使密码字段为空，也可提供足够的数据包完整性检查，并且应始终启用。
L2TPv3 over UDP must consider other L2 tunneling protocols that may be operating in the same environment, including L2TPv2 [RFC2661] and L2F [RFC2341].
在UDP上的L2TPV3必须考虑可能在相同环境中操作的其他L2隧道协议，包括L2TPV2[RCF2661]和L2F[RCF23 41]。
While there are efficiencies gained by running L2TP directly over IP, there are possible side effects as well. For instance, L2TP over IP is not as NAT-friendly as L2TP over UDP.
直接在IP上运行L2TP可以提高效率，但也有可能产生副作用。例如，IP上的L2TP不像UDP上的L2TP那样对NAT友好。
The following session header format is utilized when operating L2TPv3 over UDP:
通过UDP操作L2TPv3时使用以下会话头格式：
Figure 4.1.2.1: L2TPv3 Session Header over UDP
图4.1.2.1:UDP上的L2TPv3会话头
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional, maximum 64 bits)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The T bit MUST be set to 0, indicating that this is a data message.
T位必须设置为0，表示这是一条数据消息。
The x bits and Reserved field are reserved for future extensions. All reserved values MUST be set to 0 on outgoing messages and ignored on incoming messages.
x位和保留字段保留用于将来的扩展。传出消息的所有保留值必须设置为0，传入消息的所有保留值必须忽略。
The Ver field MUST be set to 3, indicating an L2TPv3 message.
Ver字段必须设置为3，表示L2TPv3消息。
Note that the initial bits 1, 4, 6, and 7 have meaning in L2TPv2 [RFC2661], and are deprecated and marked as reserved in L2TPv3. Thus, for UDP mode on a system that supports both versions of L2TP, it is important that the Ver field be inspected first to determine the Version of the header before acting upon any of these bits.
注意，初始位1、4、6和7在L2TPv2[RFC2661]中具有含义，并且在L2TPv3中被弃用并标记为保留。因此，对于支持两个版本的L2TP的系统上的UDP模式，在对这些位中的任何一个进行操作之前，首先检查Ver字段以确定报头的版本是很重要的。
The Session ID and Cookie fields are as defined in Section 4.1.
会话ID和Cookie字段如第4.1节所定义。
The method for UDP Port Selection defined in this section is identical to that defined for L2TPv2 [RFC2661].
本节中定义的UDP端口选择方法与L2TPv2[RFC2661]中定义的方法相同。
When negotiating a control connection over UDP, control messages MUST be sent as UDP datagrams using the registered UDP port 1701 [RFC1700]. The initiator of an L2TP control connection 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.
通过UDP协商控制连接时，必须使用注册的UDP端口1701[RFC1700]将控制消息作为UDP数据报发送。L2TP控制连接的发起方选择可用的源UDP端口（可能是1701，也可能不是1701），并发送到端口1701处的所需目标地址。接收方在其自己的系统上选择一个自由端口（可能是1701，也可能不是1701），并将其应答发送到发起方的UDP端口和地址，将其自己的源端口设置为找到的自由端口。
Any subsequent traffic associated with this control connection (either control traffic or data traffic from a session established through this control connection) must use these same UDP ports.
与此控制连接关联的任何后续通信（来自通过此控制连接建立的会话的控制通信或数据通信）必须使用这些相同的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 control connection, i.e., 1701) may make it more difficult for L2TP to traverse some NAT devices. Implementations should consider the potential implication of this capability before choosing an arbitrary source port. A NAT device that can pass TFTP traffic with variant UDP ports should be able to pass L2TP UDP traffic since both protocols employ similar policies with regard to UDP port selection.
有人建议，让接收者选择任意源端口（与在发起控制连接的分组中使用目的端口相反，即1701）可能使L2TP更难穿越一些NAT设备。在选择任意源端口之前，实现应该考虑这种能力的潜在含义。可以通过具有不同UDP端口的TFTP通信的NAT设备应该能够通过L2TP UDP通信，因为这两个协议在UDP端口选择方面采用类似的策略。
The tunneled frames that L2TP carry often have their own checksums or integrity checks, rendering the UDP checksum redundant for much of the L2TP data message contents. Thus, UDP checksums MAY be disabled in order to reduce the associated packet processing burden at the L2TP endpoints.
L2TP承载的隧道帧通常有自己的校验和或完整性检查，这使得UDP校验和对于许多L2TP数据消息内容来说是冗余的。因此，可以禁用UDP校验和，以减少L2TP端点处的相关分组处理负担。
The L2TP header itself does not have its own checksum or integrity check. However, use of the L2TP Session ID and Cookie pair guards against accepting an L2TP data message if corruption of the Session ID or associated Cookie has occurred. When the L2-Specific Sublayer is present in the L2TP header, there is no built-in integrity check for the information contained therein if UDP checksums or some other integrity check is not employed. IPsec (see Section 4.1.3) may be used for strong integrity protection of the entire contents of L2TP data messages.
L2TP标头本身没有自己的校验和或完整性检查。但是，使用L2TP会话ID和Cookie对可以防止在会话ID或相关Cookie发生损坏时接受L2TP数据消息。当L2TP报头中存在L2特定子层时，如果未使用UDP校验和或其他完整性检查，则不会对其中包含的信息进行内置完整性检查。IPsec（见第4.1.3节）可用于L2TP数据消息整个内容的强完整性保护。
UDP checksums MUST be enabled for L2TP control messages.
L2TP控制消息必须启用UDP校验和。
The L2TP data channel does not provide cryptographic security of any kind. If the L2TP data channel operates over a public or untrusted IP network where privacy of the L2TP data is of concern or sophisticated attacks against L2TP are expected to occur, IPsec [RFC2401] MUST be made available to secure the L2TP traffic.
L2TP数据通道不提供任何类型的加密安全性。如果L2TP数据通道在公共或不受信任的IP网络上运行，其中L2TP数据的隐私受到关注，或者预计会发生针对L2TP的复杂攻击，则必须提供IPsec[RFC2401]来保护L2TP流量。
Either L2TP over UDP or L2TP over IP may be secured with IPsec. [RFC3193] defines the recommended method for securing L2TPv2. L2TPv3 possesses identical characteristics to IPsec as L2TPv2 when running over UDP and implementations MUST follow the same recommendation. When operating over IP directly, [RFC3193] still applies, though references to UDP source and destination ports (in particular, those
UDP上的L2TP或IP上的L2TP都可以使用IPsec进行保护。[RFC3193]定义了保护L2TPv2的推荐方法。L2TPv3在UDP上运行时具有与L2TPv2相同的IPsec特性，实现必须遵循相同的建议。直接在IP上操作时，[RFC3193]仍然适用，尽管引用UDP源端口和目标端口（特别是
in Section 4, "IPsec Filtering details when protecting L2TP") may be ignored. Instead, the selectors used to identify L2TPv3 traffic are simply the source and destination IP addresses for the tunnel endpoints together with the L2TPv3 IP protocol type, 115.
在第4节中，“保护L2TP时的IPsec过滤详细信息”）可以忽略。相反，用于识别L2TPv3通信量的选择器只是隧道端点的源和目标IP地址以及L2TPv3 IP协议类型115。
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 may be performed at the network layer above L2TP. These network layer access control features may be handled at an LCCE via vendor-specific authorization features, 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之上的网络层执行类似过滤。这些网络层访问控制功能可以通过特定于供应商的授权功能在LCCE上处理，也可以通过在通信主机之间使用端到端的IPsec传输模式在网络层本身上处理。访问控制机制的要求不是L2TP规范的一部分，因此不在本文件的范围内。
Protecting the L2TP packet stream with IPsec does, in turn, also protect the data within the tunneled session packets while transported from one LCCE to the other. Such protection must not be considered a substitution for end-to-end security between communicating hosts or applications.
使用IPsec保护L2TP数据包流反过来也会在从一个LCCE传输到另一个LCCE时保护隧道会话数据包中的数据。这种保护不能被认为是对通信主机或应用程序之间的端到端安全的替代。
Fragmentation and reassembly in network equipment generally require significantly greater resources than sending or receiving a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes among the Remote System, the LCCE, and the IP network, as well as adaptive measures that operate with the originating host (e.g., [RFC1191], [RFC1981]) to reduce the packet sizes at the source.
网络设备中的碎片和重组通常需要比作为单个单元发送或接收数据包多得多的资源。因此，应尽可能避免碎片和重新组装。避免碎片化的理想解决方案包括在远程系统、LCCE和IP网络之间正确配置和管理MTU大小，以及使用发起主机（例如，[RFC1191]、[RFC1981]）来减少源位置的数据包大小的自适应措施。
An LCCE MAY fragment a packet before encapsulating it in L2TP. For example, if an IPv4 packet arrives at an LCCE from a Remote System that, after encapsulation with its associated framing, L2TP, and IP, does not fit in the available path MTU towards its LCCE peer, the local LCCE may perform IPv4 fragmentation on the packet before tunnel encapsulation. This creates two (or more) L2TP packets, each
LCCE可以在将数据包封装到L2TP之前对其进行分段。例如，如果IPv4数据包从远程系统到达LCCE，而该远程系统在封装其相关帧、L2TP和IP后，不适合其LCCE对等方的可用路径MTU，则本地LCCE可在隧道封装之前对该数据包执行IPv4分段。这将创建两个（或更多）L2TP数据包，每个数据包
carrying an IPv4 fragment with its associated framing. This ultimately has the effect of placing the burden of fragmentation on the LCCE, while reassembly occurs on the IPv4 destination host.
携带IPv4片段及其相关帧。这最终会在IPv4目标主机上重新组装时，将碎片负担放到LCCE上。
If an IPv6 packet arrives at an LCCE from a Remote System that, after encapsulation with associated framing, L2TP and IP, does not fit in the available path MTU towards its L2TP peer, the Generic Packet Tunneling specification [RFC2473], Section 7.1 SHOULD be followed. In this case, the LCCE should either send an ICMP Packet Too Big message to the data source, or fragment the resultant L2TP/IP packet (for reassembly by the L2TP peer).
如果IPv6数据包从远程系统到达LCCE，在封装相关帧、L2TP和IP后，不适合其L2TP对等的可用路径MTU，则应遵循通用数据包隧道规范[RFC2473]第7.1节。在这种情况下，LCCE应该向数据源发送一个ICMP数据包太大的消息，或者对结果L2TP/IP数据包进行分段（以便L2TP对等方重新组装）。
If the amount of traffic requiring fragmentation and reassembly is rather light, or there are sufficiently optimized mechanisms at the tunnel endpoints, fragmentation of the L2TP/IP packet may be sufficient for accommodating mismatched MTUs that cannot be managed by more efficient means. This method effectively emulates a larger MTU between tunnel endpoints and should work for any type of L2- encapsulated packet. Note that IPv6 does not support "in-flight" fragmentation of data packets. Thus, unlike IPv4, the MTU of the path towards an L2TP peer must be known in advance (or the last resort IPv6 minimum MTU of 1280 bytes utilized) so that IPv6 fragmentation may occur at the LCCE.
如果需要分段和重新组装的业务量相当小，或者在隧道端点处存在充分优化的机制，则L2TP/IP分组的分段可能足以容纳不能通过更有效的方式管理的不匹配mtu。这种方法有效地模拟了隧道端点之间更大的MTU，应该适用于任何类型的L2封装数据包。请注意，IPv6不支持数据包的“正在运行”分段。因此，与IPv4不同，必须提前知道通向L2TP对等方的路径的MTU（或使用的最后一种IPv6最小MTU为1280字节），以便在LCCE处发生IPv6分段。
In summary, attempting to control the source MTU by communicating with the originating host, forcing that an MTU be sufficiently large on the path between LCCE peers to tunnel a frame from any other interface without fragmentation, fragmenting IP packets before encapsulation with L2TP/IP, or fragmenting the resultant L2TP/IP packet between the tunnel endpoints, are all valid methods for managing MTU mismatches. Some are clearly better than others depending on the given deployment. For example, a passive monitoring application using L2TP would certainly not wish to have ICMP messages sent to a traffic source. Further, if the links connecting a set of LCCEs have a very large MTU (e.g., SDH/SONET) and it is known that the MTU of all links being tunneled by L2TP have smaller MTUs (e.g., 1500 bytes), then any IP fragmentation and reassembly enabled on the participating LCCEs would never be utilized. An implementation MUST implement at least one of the methods described in this section for managing mismatched MTUs, based on careful consideration of how the final product will be deployed.
总之，试图通过与发起主机通信来控制源MTU，强制LCCE对等点之间的路径上的MTU足够大，以便在没有碎片的情况下从任何其他接口隧道帧，在使用L2TP/IP封装之前对IP数据包进行碎片化，或者在隧道端点之间分割生成的L2TP/IP数据包，都是管理MTU不匹配的有效方法。根据给定的部署，有些明显优于其他。例如，使用L2TP的被动监视应用程序肯定不希望将ICMP消息发送到流量源。此外，如果连接一组lcce的链路具有非常大的MTU（例如，SDH/SONET），并且已知由L2TP隧道的所有链路的MTU具有较小的MTU（例如，1500字节），则在参与的lcce上启用的任何IP分段和重新组装将永远不会被利用。在仔细考虑最终产品将如何部署的基础上，实现必须实现本节中描述的用于管理不匹配MTU的至少一种方法。
L2TP-specific fragmentation and reassembly methods, which may or may not depend on the characteristics of the type of link being tunneled (e.g., judicious packing of ATM cells), may be defined as well, but these methods are outside the scope of this document.
也可以定义L2TP特定的分段和重新组装方法，这些方法可能取决于或可能不取决于所隧道链路类型的特征（例如，ATM信元的明智包装），但这些方法不在本文件的范围内。
L2TP provides a lower level reliable delivery service for all control messages. The Nr and Ns fields of the control message header (see Section 3.2.1) belong to this delivery mechanism. The upper level functions of L2TP are not concerned with retransmission or ordering of control messages. The reliable control messaging mechanism is a sliding window mechanism that provides control message retransmission and congestion control. Each peer maintains separate sequence number state for each control connection.
L2TP为所有控制消息提供较低级别的可靠传递服务。控制消息头的Nr和Ns字段（见第3.2.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 ACK message), receipt of duplicate messages MUST be acknowledged by the reliable delivery mechanism. This acknowledgment may either piggybacked on a message in queue or sent explicitly via an ACK message.
消息序列号Ns从0开始。每个后续消息都会随序列号的下一个增量一起发送。因此，序列号是以65536模表示的自由运行计数器。如果接收到的消息头中的序列号的值位于上次接收的序列号和之前的32767值（包括）的范围内，则认为该序列号小于或等于上次接收的序列号。例如，如果最后收到的序列号是15，则序列号为0到15以及32784到65535的消息将被视为小于或等于。这样的消息将被视为已接收消息的副本，并在处理过程中被忽略。但是，为了确保正确确认所有消息（特别是在ACK消息丢失的情况下），必须通过可靠传递机制确认重复消息的接收。此确认可以通过队列中的消息进行确认，也可以通过确认消息显式发送。
All control messages take up one slot in the control message sequence number space, except the ACK message. Thus, Ns is not incremented after an ACK message is sent.
除ACK消息外，所有控制消息占用控制消息序列号空间中的一个插槽。因此，在发送ACK消息之后，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-ACK message received plus 1, modulo 65536). While the Nr in a received ACK message is used to flush messages from the local retransmit queue (see below), the Nr of the next message sent is not updated by the Ns of the ACK message. Nr SHOULD be sanity-checked before flushing the retransmit queue. For instance, if the Nr received in a control message is greater than the last Ns sent plus 1 modulo 65536, the control message is clearly invalid.
最后接收到的消息编号Nr用于确认L2TP对等方接收到的消息。它包含对等方预期下一次接收的消息的序列号（例如，接收到的非ACK消息的最后N加1，模65536）。虽然接收到的ACK消息中的Nr用于刷新来自本地重传队列的消息（见下文），但ACK消息的Ns不会更新下一条发送的消息的Nr。刷新重传队列之前，应检查Nr是否正常。例如，如果控制消息中接收的Nr大于最后发送的Ns加上1模65536，则控制消息显然无效。
The reliable delivery mechanism 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. Alternatively, they may be discarded, thus requiring a retransmission by the peer. When dropping out-of-order control packets, Nr MAY be updated before the packet is discarded.
收到了。或者，它们可能被丢弃，因此需要对等方重新传输。当丢弃无序控制分组时，可以在丢弃分组之前更新Nr。
Each control connection 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 but SHOULD be configurable) passes without acknowledgment, 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 SHOULD be no less than 8 seconds per retransmission. If no peer response is detected after several retransmissions (a recommended default is 10, but MUST be configurable), the control connection and all associated sessions MUST be cleared. As it is the first message to establish a control connection, the SCCRQ MAY employ a different retransmission maximum than other control messages in order to help facilitate failover to alternate LCCEs in a timely fashion.
消息的每个后续重传必须采用指数退避间隔。因此，如果第一次重传发生在1秒之后，那么下一次重传应该发生在2秒之后，然后是4秒，以此类推。一个实现可以对重传之间的最大间隔设置上限。每次重传时，该上限应不小于8秒。如果在多次重新传输后未检测到对等响应（建议默认值为10，但必须可配置），则必须清除控制连接和所有相关会话。由于SCCRQ是建立控制连接的第一条消息，因此SCCRQ可以采用与其他控制消息不同的最大重发次数，以帮助及时地故障切换到备用LCCE。
When a control connection 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 StopCCN message has been sent (e.g., 1 + 2 + 4 + 8 + 8... seconds), or until the StopCCN message itself has been acknowledged.
当控制连接因连接丢失以外的原因关闭时，在发送最终消息StopCCN消息后的整个重传间隔内（例如，1+2+4+8+8…秒），必须保持和运行状态和可靠的传递机制，或者直到StopCCN消息本身被确认。
A sliding window mechanism is used for control message transmission and retransmission. Consider two peers, A and B. Suppose A specifies a Receive Window Size AVP with a value of N in the SCCRQ or SCCRP message. B is now allowed to have a maximum of N outstanding (i.e., unacknowledged) control messages. Once N messages have been sent, B must wait for an acknowledgment from A that advances the window before sending new control messages. An implementation may advertise a non-zero receive window as small or as large as it wishes, depending on its own ability to process incoming messages before sending an acknowledgement. Each peer MUST limit the number of unacknowledged messages it will send before receiving an acknowledgement by this Receive Window Size. The actual internal
滑动窗口机制用于控制消息的传输和重传。考虑两个对等点A和B。假设A指定一个在SCCRQ或SCCRP消息中具有N值的接收窗口大小AVP。B现在最多允许有N条未完成（即未确认）的控制消息。一旦发送了N条消息，B必须等待A的确认，该确认会在发送新的控制消息之前进入窗口。一个实现可以根据其自身在发送确认之前处理传入消息的能力来公布一个非零接收窗口，该窗口可以是它所希望的大小。每个对等方必须限制在接收到该接收窗口大小的确认之前发送的未确认消息的数量。实际内部
unacknowledged message send-queue depth may be further limited by local resource allocation or by dynamic slow-start and congestion-avoidance mechanisms.
未确认的消息发送队列深度可能进一步受到本地资源分配或动态慢启动和拥塞避免机制的限制。
When retransmitting control messages, a slow start and congestion avoidance window adjustment procedure SHOULD be utilized. A recommended procedure is described in Appendix A. A peer MAY drop messages, but MUST NOT actively delay acknowledgment of messages as a technique for flow control of control messages. Appendix B contains examples of control message transmission, acknowledgment, and retransmission.
在重新传输控制消息时，应使用慢速启动和拥塞避免窗口调整程序。附录A中描述了推荐的程序。对等方可以丢弃消息，但不得主动延迟消息确认，作为控制消息流控制的一种技术。附录B包含控制消息传输、确认和重传的示例。
L2TP incorporates an optional authentication and integrity check for all control messages. This mechanism consists of a computed one-way hash over the header and body of the L2TP control message, a pre-configured shared secret, and a local and remote nonce (random value) exchanged via the Control Message Authentication Nonce AVP. This per-message authentication and integrity check is designed to perform a mutual authentication between L2TP nodes, perform integrity checking of all control messages, and guard against control message spoofing and replay attacks that would otherwise be trivial to mount.
L2TP为所有控制消息合并了可选的身份验证和完整性检查。该机制包括L2TP控制消息头和消息体上的计算单向散列、预配置的共享机密以及通过控制消息身份验证nonce AVP交换的本地和远程nonce（随机值）。此每条消息的身份验证和完整性检查旨在执行L2TP节点之间的相互身份验证，执行所有控制消息的完整性检查，并防止控制消息欺骗和重放攻击，否则这些攻击很容易装载。
At least one shared secret (password) MUST exist between communicating L2TP nodes to enable Control Message Authentication. See Section 5.4.3 for details on calculation of the Message Digest and construction of the Control Message Authentication Nonce and Message Digest AVPs.
通信L2TP节点之间必须至少存在一个共享密钥（密码），以启用控制消息身份验证。有关消息摘要的计算以及控制消息认证Nonce和消息摘要avp的构造的详细信息，请参见第5.4.3节。
L2TPv3 Control Message Authentication is similar to L2TPv2 [RFC2661] Tunnel Authentication in its use of a shared secret and one-way hash calculation. The principal difference is that, instead of computing the hash over selected contents of a received control message (e.g., the Challenge AVP and Message Type) as in L2TPv2, the entire message is used in the hash in L2TPv3. In addition, instead of including the hash digest in just the SCCRP and SCCCN messages, it is now included in all L2TP messages.
L2TPv3控制消息身份验证与L2TPv2[RFC2661]隧道身份验证在使用共享秘密和单向散列计算方面类似。主要区别在于，与在L2TPv2中一样，在接收到的控制消息的选定内容（例如，质询AVP和消息类型）上计算散列不同，在L2TPv3中的散列中使用整个消息。此外，哈希摘要不再只包含在SCCRP和SCCCN消息中，而是包含在所有L2TP消息中。
The Control Message Authentication mechanism is optional, and may be disabled if both peers agree. For example, if IPsec is already being used for security and integrity checking between the LCCEs, the function of the L2TP mechanism becomes redundant and may be disabled.
控制消息身份验证机制是可选的，如果双方同意，则可以禁用该机制。例如，如果IPsec已用于LCCE之间的安全性和完整性检查，L2TP机制的功能将变得冗余，并可能被禁用。
Presence of the Control Message Authentication Nonce AVP in an SCCRQ or SCCRP message serves as indication to a peer that Control Message Authentication is enabled. If an SCCRQ or SCCRP contains a Control Message Authentication Nonce AVP, the receiver of the message MUST
SCCRQ或SCCRP消息中控制消息认证Nonce AVP的存在用作向对等方指示控制消息认证已启用。如果SCCRQ或SCCRP包含控制消息身份验证Nonce AVP，则消息的接收方必须
respond with a Message Digest AVP in all subsequent messages sent. Control Message Authentication is always bidirectional; either both sides participate in authentication, or neither does.
在随后发送的所有消息中使用消息摘要AVP进行响应。控制消息认证总是双向的；双方都参与身份验证，或者双方都不参与。
If Control Message Authentication is disabled, the Message Digest AVP still MAY be sent as an integrity check of the message. The integrity check is calculated as in Section 5.4.3, with an empty zero-length shared secret, local nonce, and remote nonce. If an invalid Message Digest is received, it should be assumed that the message has been corrupted in transit and the message dropped accordingly.
如果禁用控制消息身份验证，消息摘要AVP仍可作为消息的完整性检查发送。完整性检查的计算如第5.4.3节所述，使用空的零长度共享密钥、本地nonce和远程nonce。如果收到无效的消息摘要，则应假定该消息在传输过程中已损坏，并相应地丢弃该消息。
Implementations MAY rate-limit control messages, particularly SCCRQ messages, upon receipt for performance reasons or for protection against denial of service attacks.
由于性能原因或为了防止拒绝服务攻击，在收到控制消息时，实现可能会对其进行速率限制，特别是SCCRQ消息。
L2TP employs a keepalive mechanism to detect loss of connectivity between a pair of LCCEs. This is accomplished by injecting Hello control messages (see Section 6.5) after a period of time has elapsed since the last data message or control message was received on an L2TP session or control connection, respectively. As with any other control message, if the Hello message is not reliably delivered, the sending LCCE declares that the control connection is down and resets its state for the control connection. This behavior ensures that a connectivity failure between the LCCEs is detected independently by each end of a control connection.
L2TP采用keepalive机制来检测一对LCCE之间的连接丢失。这是通过在L2TP会话或控制连接上分别收到最后一条数据消息或控制消息后经过一段时间后注入Hello控制消息（见第6.5节）来实现的。与任何其他控制消息一样，如果Hello消息没有可靠地传递，则发送LCCE将声明控制连接已关闭，并重置其控制连接的状态。此行为确保LCCE之间的连接故障由控制连接的每一端独立检测。
Since the control channel is operated in-band with data traffic over the PSN, this single mechanism can be used to infer basic data connectivity between a pair of LCCEs for all sessions associated with the control connection.
由于控制信道在PSN上的数据业务带内运行，因此该单一机制可用于推断与控制连接相关联的所有会话的一对LCCE之间的基本数据连接。
Periodic keepalive for the control connection MUST be implemented by sending a Hello if a period of time (a recommended default is 60 seconds, but MUST be configurable) has passed without receiving any message (data or control) from the peer. An LCCE sending Hello messages across multiple control connections between the same LCCE endpoints MUST employ a jittered timer mechanism to prevent grouping of Hello messages.
如果一段时间（建议的默认值为60秒，但必须是可配置的）已经过去而没有从对等方接收任何消息（数据或控制），则必须通过发送Hello来实现控制连接的定期keepalive。在同一LCCE端点之间跨多个控制连接发送Hello消息的LCCE必须采用抖动计时器机制，以防止Hello消息分组。
Once session establishment is complete, circuit frames are received at an LCCE, encapsulated in L2TP (with appropriate attention to framing, as described in documents for the particular pseudowire type), and forwarded over the appropriate session. For every
一旦会话建立完成，在LCCE接收电路帧，封装在L2TP中（适当注意帧，如特定伪线类型的文档中所述），并通过适当的会话转发。每
outgoing data message, the sender places the identifier specified in the Local Session ID AVP (received from peer during session establishment) in the Session ID field of the L2TP data header. In this manner, session frames are multiplexed and demultiplexed between a given pair of LCCEs. Multiple control connections may exist between a given pair of LCCEs, and multiple sessions may be associated with a given control connection.
传出数据消息时，发送方将本地会话ID AVP（会话建立期间从对等方接收）中指定的标识符放置在L2TP数据头的会话ID字段中。以这种方式，会话帧在给定的一对lcce之间被多路复用和解多路复用。给定的一对lce之间可能存在多个控制连接，并且多个会话可能与给定的控制连接相关联。
The peer LCCE receiving the L2TP data packet identifies the session with which the packet is associated by the Session ID in the data packet's header. The LCCE then checks the Cookie field in the data packet against the Cookie value received in the Assigned Cookie AVP during session establishment. It is important for implementers to note that the Cookie field check occurs after looking up the session context by the Session ID, and as such, consists merely of a value match of the Cookie field and that stored in the retrieved context. There is no need to perform a lookup across the Session ID and Cookie as a single value. Any received data packets that contain invalid Session IDs or associated Cookie values MUST be dropped. Finally, the LCCE either forwards the network packet within the tunneled frame (e.g., as an LNS) or switches the frame to a circuit (e.g., as an LAC).
接收L2TP数据分组的对等LCCE通过数据分组的报头中的会话ID来识别与分组相关联的会话。LCCE然后根据会话建立期间分配的Cookie AVP中接收的Cookie值检查数据包中的Cookie字段。对于实现者来说，重要的是要注意，Cookie字段检查是在通过会话ID查找会话上下文之后进行的，因此，它仅由Cookie字段和存储在检索到的上下文中的值匹配组成。不需要作为单个值跨会话ID和Cookie执行查找。必须丢弃包含无效会话ID或关联Cookie值的任何接收到的数据包。最后，LCCE或者转发隧道帧内的网络分组（例如，作为LNS）或者将帧切换到电路（例如，作为LAC）。
This document defines a Default L2-Specific Sublayer format (see Section 3.2.2) that a pseudowire may use for features such as sequencing support, L2 interworking, OAM, or other per-data-packet operations. The Default L2-Specific Sublayer SHOULD be used by a given PW type to support these features if it is adequate, and its presence is requested by a peer during session negotiation. Alternative sublayers MAY be defined (e.g., an encapsulation with a larger Sequence Number field or timing information) and identified for use via the L2-Specific Sublayer Type AVP.
本文档定义了一种默认的L2特定子层格式（见第3.2.2节），伪线可用于序列支持、L2互通、OAM或其他每数据包操作等功能。给定的PW类型应该使用默认的L2特定子层来支持这些功能（如果它足够），并且对等方在会话协商期间请求它的存在。可定义备选子层（例如，具有较大序列号字段或定时信息的封装）并经L2特定子层类型AVP识别以供使用。
Figure 4.6: Default L2-Specific Sublayer Format
图4.6：默认L2特定子层格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|x|x|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S (Sequence) bit is set to 1 when the Sequence Number contains a valid number for this sequenced frame. If the S bit is set to zero, the Sequence Number contents are undefined and MUST be ignored by the receiver.
当序列号包含此序列帧的有效数字时，S（序列）位设置为1。如果S位设置为零，则序列号内容未定义，接收器必须忽略。
The Sequence Number field contains a free-running counter of 2^24 sequence numbers. If the number in this field is valid, the S bit MUST be set to 1. The Sequence Number begins at zero, which is a valid sequence number. (In this way, implementations inserting sequence numbers do not have to "skip" zero when incrementing.) 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 (2^23-1) values, inclusive.
序列号字段包含2^24个序列号的自由运行计数器。如果此字段中的数字有效，则S位必须设置为1。序列号从零开始，这是一个有效的序列号。（通过这种方式，插入序列号的实现不必在递增时“跳过”零。）如果接收到的消息头中的序列号的值位于上次接收的序列号和之前（2^23-1）的值（包括）的范围内，则认为该序列号小于或等于上次接收的序列号。
The Sequence Number field may be used to detect lost, duplicate, or out-of-order packets within a given session.
序列号字段可用于检测给定会话内的丢失、重复或无序分组。
When L2 frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP data channel, this part of the link has the characteristic of being able to reorder, duplicate, or silently drop packets. Reordering may break some non-IP protocols or L2 control traffic being carried by the link. Silent dropping or duplication of packets may break protocols that assume per-packet indications of error, such as TCP header compression. While a common mechanism for packet sequence detection is provided, the sequence dependency characteristics of individual protocols are outside the scope of this document.
当L2帧通过L2TP over IP或L2TP over UDP/IP数据通道传输时，链路的这一部分具有能够重新排序、复制或静默丢弃数据包的特性。重新排序可能会破坏某些非IP协议或链路承载的L2控制流量。数据包的静默丢弃或复制可能会破坏假定每个数据包都有错误指示的协议，例如TCP报头压缩。虽然提供了用于数据包序列检测的通用机制，但各个协议的序列依赖性特征不在本文档的范围内。
If any protocol being transported by over L2TP data channels cannot tolerate misordering of data packets, packet duplication, or silent packet loss, sequencing may be enabled on some or all packets by using the S bit and Sequence Number field defined in the Default L2- Specific Sublayer (see Section 4.6). For a given L2TP session, each LCCE is responsible for communicating to its peer the level of sequencing support that it requires of data packets that it receives. Mechanisms to advertise this information during session negotiation are provided (see Data Sequencing AVP in Section 5.4.4).
如果通过L2TP数据通道传输的任何协议不能容忍数据包的乱序、数据包重复或无提示数据包丢失，则可通过使用默认L2特定子层中定义的S位和序列号字段对部分或所有数据包启用排序（见第4.6节）。对于给定的L2TP会话，每个LCCE负责向其对等方传达其接收的数据包所需的排序支持级别。提供了在会话协商期间公布此信息的机制（见第5.4.4节中的数据排序AVP）。
When determining whether a packet is in or out of sequence, an implementation SHOULD utilize a method that is resilient to temporary dropouts in connectivity coupled with high per-session packet rates. The recommended method is outlined in Appendix C.
当确定一个数据包是否处于序列中时，一个实现应该使用一种方法，该方法能够适应连接中的临时丢失以及高的每会话数据包速率。附录C中概述了推荐的方法。
L2TPv2 and L2TPv3 environments should be able to coexist while a migration to L2TPv3 is made. Migration issues are discussed for each media type in this section. Most issues apply only to implementations that require both L2TPv2 and L2TPv3 operation.
L2TPv2和L2TPv3环境应该能够在迁移到L2TPv3时共存。本节将讨论每种介质类型的迁移问题。大多数问题仅适用于同时需要L2TPv2和L2TPv3操作的实现。
However, even L2TPv3-only implementations must at least be mindful of these issues in order to interoperate with implementations that support both versions.
然而，即使只有L2TPv3的实现也必须至少注意这些问题，以便与支持这两个版本的实现进行互操作。
L2TPv3 implementations running strictly over IP with no desire to interoperate with L2TPv2 implementations may safely disregard most migration issues from L2TPv2. All control messages and data messages are sent as described in this document, without normative reference to RFC 2661.
严格在IP上运行的L2TPv3实现不希望与L2TPv2实现互操作，因此可以安全地忽略L2TPv2中的大多数迁移问题。所有控制信息和数据信息均按本文件所述发送，无需参考RFC 2661标准。
If one wishes to tunnel PPP over L2TPv3, and fallback to L2TPv2 only if it is not available, then L2TPv3 over UDP with automatic fallback (see Section 4.7.3) MUST be used. There is no deterministic method for automatic fallback from L2TPv3 over IP to either L2TPv2 or L2TPv3 over UDP. One could infer whether L2TPv3 over IP is supported by sending an SCCRQ and waiting for a response, but this could be problematic during periods of packet loss between L2TP nodes.
如果希望通过L2TPv3对PPP进行隧道传输，并且仅在L2TPv2不可用时才回退到L2TPv2，则必须使用UDP上的L2TPv3以及自动回退（见第4.7.3节）。没有确定的方法可以通过IP将L2TPv3自动回退到L2TPv2或UDP上的L2TPv3。可以通过发送SCCRQ并等待响应来推断是否支持IP上的L2TPv3，但这在L2TP节点之间的数据包丢失期间可能会出现问题。
The format of the L2TPv3 over UDP header is defined in Section 4.1.2.1.
L2TPv3 over UDP报头的格式在第4.1.2.1节中定义。
When operating over UDP, L2TPv3 uses the same port (1701) as L2TPv2 and shares the first two octets of header format with L2TPv2. The Ver field is used to distinguish L2TPv2 packets from L2TPv3 packets. If an implementation is capable of operating in L2TPv2 or L2TPv3 modes, it is possible to automatically detect whether a peer can support L2TPv2 or L2TPv3 and operate accordingly. The details of this fallback capability is defined in the following section.
当通过UDP操作时，L2TPv3使用与L2TPv2相同的端口（1701），并与L2TPv2共享头格式的前两个八位字节。Ver字段用于区分L2TPv2数据包和L2TPv3数据包。如果实现能够在L2TPv2或L2TPv3模式下运行，则可以自动检测对等方是否支持L2TPv2或L2TPv3并相应地运行。此回退功能的详细信息将在下一节中定义。
When running over UDP, an implementation may detect whether a peer is L2TPv3-capable by sending a special SCCRQ that is properly formatted for both L2TPv2 and L2TPv3. This is accomplished by sending an SCCRQ with its Ver field set to 2 (for L2TPv2), and ensuring that any L2TPv3-specific AVPs (i.e., AVPs present within this document and not defined within RFC 2661) in the message are sent with each M bit set to 0, and that all L2TPv2 AVPs are present as they would be for L2TPv2. This is done so that L2TPv3 AVPs will be ignored by an L2TPv2-only implementation. Note that, in both L2TPv2 and L2TPv3, the value contained in the space of the control message header utilized by the 32-bit Control Connection ID in L2TPv3, and the 16- bit Tunnel ID and
在UDP上运行时，实现可以通过发送针对L2TPv2和L2TPv3正确格式化的特殊SCCRQ来检测对等方是否支持L2TPv3。这是通过发送一个SCCRQ，其Ver字段设置为2（对于L2TPv2），并确保消息中的任何L2TPv3特定AVP（即，本文档中存在且未在RFC 2661中定义的AVP）在每个M位设置为0的情况下发送，并且所有L2TPv2 AVP都与L2TPv2相同。这样做是为了L2TPv3 AVP将被仅L2TPv2实现忽略。注意，在L2TPv2和L2TPv3中，包含在L2TPv3中的32位控制连接ID和16位隧道ID使用的控制消息头空间中的值，以及
16-bit Session ID in L2TPv2, are always 0 for an SCCRQ. This effectively hides the fact that there are a pair of 16-bit fields in L2TPv2, and a single 32-bit field in L2TPv3.
L2TPv2中的16位会话ID对于SCCRQ始终为0。这实际上隐藏了这样一个事实：L2TPv2中有一对16位字段，L2TPv3中有一个32位字段。
If the peer implementation is L2TPv3-capable, a control message with the Ver field set to 3 and an L2TPv3 header and message format will be sent in response to the SCCRQ. Operation may then continue as L2TPv3. If a message is received with the Ver field set to 2, it must be assumed that the peer implementation is L2TPv2-only, thus enabling fallback to L2TPv2 mode to safely occur.
如果对等实现支持L2TPv3，则将发送一条控制消息，其中Ver字段设置为3，L2TPv3头和消息格式将响应SCCRQ。然后，操作可以作为L2TPv3继续。如果接收到的消息的Ver字段设置为2，则必须假定对等实现仅为L2TPv2，从而允许安全地回滚到L2TPv2模式。
Note Well: The L2TPv2/v3 auto-detection mode requires that all L2TPv3 implementations over UDP be liberal in accepting an SCCRQ control message with the Ver field set to 2 or 3 and the presence of L2TPv2- specific AVPs. An L2TPv3-only implementation MUST ignore all L2TPv2 AVPs (e.g., those defined in RFC 2661 and not in this document) within an SCCRQ with the Ver field set to 2 (even if the M bit is set on the L2TPv2-specific AVPs).
请注意：L2TPv2/v3自动检测模式要求所有通过UDP的L2TPv3实现可以自由地接受SCCRQ控制消息，其中Ver字段设置为2或3，并且存在L2TPv2特定的AVP。仅L2TPv3的实现必须忽略SCCRQ中的所有L2TPv2 AVP（例如，RFC 2661中定义的AVP，而不是本文档中定义的AVP），且Ver字段设置为2（即使在L2TPv2特定AVP上设置了M位）。
To maximize extensibility while permitting interoperability, a uniform method for encoding message types is used throughout L2TP. This encoding will be termed AVP (Attribute Value Pair) for the remainder of this document.
为了在允许互操作性的同时最大限度地提高可扩展性，L2TP中使用了统一的消息类型编码方法。对于本文档的其余部分，此编码将被称为AVP（属性值对）。
Each AVP is encoded as follows:
每个AVP编码如下：
Figure 5.1: AVP Format
图5.1: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 comprise a bit mask that describes the general attributes of the AVP. Two bits are defined in this document; the remaining bits are reserved for future extensions. Reserved bits MUST be set to 0 when sent and ignored upon receipt.
前六位包括描述AVP的一般属性的位掩码。本文件中定义了两个位；剩余的位保留用于将来的扩展。发送时保留位必须设置为0，接收时忽略。
Mandatory (M) bit: Controls the behavior required of an implementation that receives an unrecognized AVP. The M bit of a given AVP MUST only be inspected and acted upon if the AVP is unrecognized (see Section 5.2).
强制（M）位：控制接收未识别AVP的实现所需的行为。只有当AVP未被识别时，才能对给定AVP的M位进行检查和操作（见第5.2节）。
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 5.3 describes the procedure for performing AVP hiding.
隐藏（H）位：标识AVP属性值字段中数据的隐藏。此功能可用于避免在AVP中以明文形式传递敏感数据，如用户密码。第5.3节描述了执行AVP隐藏的程序。
Length: Contains the number of octets (including the Overall Length and bit mask fields) contained in this AVP. The Length may be calculated as 6 + the length of the Attribute Value field in octets.
长度：包含此AVP中包含的八位字节数（包括总长度和位掩码字段）。长度可以计算为6+属性值字段的长度（以八位字节为单位）。
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.
该字段本身为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 its own L2TP extensions can use its own Vendor ID along with private Attribute values, guaranteeing that they will not collide with any other vendor's extensions or future IETF extensions. Note that there are 16 bits allocated for the Vendor ID, thus limiting this feature to the first 65,535 enterprises.
供应商ID:IANA分配的“SMI网络管理私有企业代码”[RFC1700]值。值0对应于IETF采用的属性值，用于本文档中定义的所有AVP。任何希望实现自己的L2TP扩展的供应商都可以使用自己的供应商ID和私有属性值，确保它们不会与任何其他供应商的扩展或未来的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，则此字段不存在。
In the event that the 16-bit Vendor ID space is exhausted, vendor-specific AVPs with a 32-bit Vendor ID MUST be encapsulated in the following manner:
如果16位供应商ID空间用尽，则必须以以下方式封装具有32位供应商ID的供应商特定AVP：
Figure 5.2: Extended Vendor ID AVP Format
图5.2：扩展供应商ID 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 58 | 32-bit 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 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 58 | 32-bit Vendor ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(until Length is reached) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP encodes a vendor-specific AVP with a 32-bit Vendor ID space within the Attribute Value field. Multiple AVPs of this type may exist in any message. The 16-bit Vendor ID MUST be 0, indicating that this is an IETF-defined AVP, and the Attribute Type MUST be 58, indicating that what follows is a vendor-specific AVP with a 32-bit Vendor ID code. 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 of the AVP is 12 plus the length of the Attribute Value.
此AVP使用属性值字段中的32位供应商ID空间对特定于供应商的AVP进行编码。任何消息中都可能存在此类型的多个AVP。16位供应商ID必须为0，表示这是一个IETF定义的AVP，属性类型必须为58，表示下面是一个具有32位供应商ID代码的供应商特定AVP。该AVP可能被隐藏（H位可能为0或1）。此AVP的M位必须设置为0。AVP的长度为12加上属性值的长度。
If the M bit is set on an AVP that is unrecognized by its recipient, the session or control connection associated with the control message containing the AVP MUST be shut down. If the control message containing the unrecognized AVP is associated with a session (e.g., an ICRQ, ICRP, ICCN, SLI, etc.), then the session MUST be issued a CDN with a Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the control message containing the unrecognized AVP is associated with establishment or maintenance of a Control Connection (e.g., SCCRQ, SCCRP, SCCCN, Hello), then the associated Control Connection MUST be issued a StopCCN with Result Code of 2 and Error Code of 8 (as defined in Section 5.4.2) and shut down. If the M bit is not set on an unrecognized AVP, the AVP MUST be ignored when received, processing the control message as if the AVP were not present.
如果在其收件人无法识别的AVP上设置了M位，则必须关闭与包含AVP的控制消息相关联的会话或控制连接。如果包含未识别AVP的控制消息与会话（例如，ICRQ、ICRP、ICCN、SLI等）关联，则必须向会话发送一个CDN，结果代码为2，错误代码为8（如第5.4.2节所定义），然后关闭会话。如果包含未识别AVP的控制消息与控制连接的建立或维护（例如，SCCRQ、SCCRP、SCCCN、Hello）相关，则必须向相关控制连接发出结果代码为2、错误代码为8的StopCCN（如第5.4.2节所定义）并关闭。如果未在无法识别的AVP上设置M位，则在接收到AVP时必须忽略该AVP，将控制消息当作AVP不存在来处理。
Receipt of an unrecognized AVP that has the M bit set is catastrophic to the session or control connection with which it is associated. Thus, the M bit should only be set for AVPs that are deemed crucial to proper operation of the session or control connection by the sender. AVPs that are considered crucial by the sender may vary by application and configured options. In no case shall a receiver of
接收到设置了M位的未识别AVP对与其关联的会话或控制连接来说是灾难性的。因此，仅应为被认为对发送方会话或控制连接的正确操作至关重要的avp设置M位。发送方认为至关重要的AVP可能因应用程序和配置选项而异。在任何情况下，不得将
an AVP "validate" if the M bit is set on a recognized AVP. If the AVP is recognized (as all AVPs defined in this document MUST be for a compliant L2TPv3 specification), then by definition, the M bit is of no consequence.
如果M位设置在可识别的AVP上，则AVP“验证”。如果AVP被识别（因为本文档中定义的所有AVP都必须符合L2TPv3规范），那么根据定义，M位不重要。
The sender of an AVP is free to set its M bit to 1 or 0 based on whether the configured application strictly requires the value contained in the AVP to be recognized or not. For example, "Automatic L2TPv2 Fallback" in Section 4.7.3 requires the setting of the M bit on all new L2TPv3 AVPs to zero if fallback to L2TPv2 is supported and desired, and 1 if not.
AVP的发送方可以根据配置的应用程序是否严格要求识别AVP中包含的值，将其M位自由设置为1或0。例如，第4.7.3节中的“自动L2TPv2回退”要求将所有新L2TPv3 AVP上的M位设置为零（如果支持并需要回退到L2TPv2），如果不支持，则设置为1。
The M bit is useful as extra assurance for support of critical AVP extensions. However, more explicit methods may be available to determine support for a given feature rather than using the M bit alone. For example, if a new AVP is defined in a message for which there is always a message reply (i.e., an ICRQ, ICRP, SCCRQ, or SCCRP message), rather than simply sending an AVP in the message with the M bit set, availability of the extension may be identified by sending an AVP in the request message and expecting a corresponding AVP in a reply message. This more explicit method, when possible, is preferred.
M位可作为支持关键AVP扩展的额外保证。然而，可以使用更明确的方法来确定对给定特征的支持，而不是单独使用M位。例如，如果在始终有消息回复的消息（即ICRQ、ICRP、SCCRQ或SCCRP消息）中定义了新的AVP，而不是简单地在设置了M位的消息中发送AVP，可以通过在请求消息中发送AVP并在应答消息中期望相应的AVP来识别扩展的可用性。在可能的情况下，首选这种更明确的方法。
The M bit also plays a role in determining whether or not a malformed or out-of-range value within an AVP should be ignored or should result in termination of a session or control connection (see Section 7.1 for more details).
M位在确定是否应忽略AVP内格式错误或超出范围的值或是否应导致会话或控制连接终止方面也起到了作用（有关更多详细信息，请参阅第7.1节）。
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, IDs, or other vital information.
每个AVP的报头中的H位提供了一种机制，用于向接收对等方指示AVP的内容是隐藏的还是以明文形式存在的。此功能可用于隐藏敏感的控制消息数据，如用户密码、ID或其他重要信息。
The H bit MUST only be set if (1) a shared secret exists between the LCCEs and (2) Control Message Authentication is enabled (see Section 4.3). If the H bit is set in any AVP(s) in a given control message, at least one Random Vector AVP must also be present in the message and MUST precede the first AVP having an H bit of 1.
仅当（1）LCCE之间存在共享机密且（2）启用控制消息身份验证时，才必须设置H位（见第4.3节）。如果在给定控制消息中的任何AVP中设置了H位，则消息中还必须至少存在一个随机向量AVP，并且必须位于H位为1的第一个AVP之前。
The shared secret between LCCEs is used to derive a unique shared key for hiding and unhiding calculations. The derived shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with the key consisting of the shared secret, and with the data being hashed consisting of a single octet containing the value 1.
LCCE之间的共享密钥用于导出用于隐藏和取消隐藏计算的唯一共享密钥。派生的共享密钥通过HMAC-MD5密钥散列[RFC2104]获得，密钥由共享密钥组成，数据散列由包含值1的单个八位字节组成。
shared_key = HMAC_MD5 (shared_secret, 1)
共享密钥=HMAC\U MD5（共享密钥，1）
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 the Hidden AVP Subformat, which appears as follows:
隐藏AVP值分几个步骤完成。第一步是获取原始（明文）AVP的长度和值字段，并将其编码到隐藏的AVP子格式中，如下所示：
Figure 5.3: Hidden AVP Subformat
图5.3：隐藏的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 that 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 would become 6 + Attribute Value length + size of the Length of Original Attribute Value field + Padding. Thus, if Padding is 12 octets, the AVP length would be 6 + 4 + 2 + 12 = 24 octets.
为了掩盖隐藏数据的大小，可以如上所示填充生成的子表单。填充不会改变“原始属性值的长度”字段中的值，但会改变正在创建的结果AVP的长度。例如，如果要隐藏的属性值的长度为4个八位字节，则未隐藏的AVP长度将为10个八位字节（6+属性值长度）。隐藏后，AVP的长度将变为6+属性值长度+原始属性值字段长度的大小+填充。因此，如果填充为12个八位字节，AVP长度将为6+4+2+12=24个八位字节。
Next, an MD5 [RFC1321] hash is performed (in network byte order) on the concatenation of the following:
接下来，对以下内容的串联执行MD5[RFC1321]哈希（以网络字节顺序）：
+ the 2-octet Attribute number of the AVP + the shared key + an arbitrary length random vector
+ AVP的2-octet属性数+共享密钥+任意长度的随机向量
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 message, but not for hiding two or more instances of an AVP with the same Attribute Type unless the Attribute Values in the two AVPs are also identical. When a different random vector is used for the hiding of subsequent AVPs, a new Random Vector AVP MUST be placed in the control message before the first AVP to which it applies.
此散列中使用的随机向量的值在随机向量AVP的值字段中传递。此随机向量AVP必须由发送方置于任何隐藏AVP之前的消息中。同一随机向量可用于同一消息中的多个隐藏AVP，但不用于隐藏具有相同属性类型的AVP的两个或多个实例，除非两个AVP中的属性值也相同。当使用不同的随机向量隐藏后续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. 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 key 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 key 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 [RFC2865], 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:
隐藏方法改编自[RFC2865]，该方法取自Kaufman、Perlman和Speciner[KPS]在《网络安全》一书中的“明文混合”部分。该方法的详细说明如下：
Call the shared key S, the Random Vector RV, and the Attribute Type A. Break the value field into 16-octet chunks p_1, p_2, 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 b_1, b_2, etc.
调用共享键S、随机向量RV和属性类型A。将值字段分为16个八位字节块p_1、p_2等，最后一个块在末尾用随机数据填充到16个八位字节的边界。调用密文块c_1、c_2等。我们还将定义中间值b_1、b_2等。
b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1
b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2
. .
. .
. .
b_i = MD5 (S + c_i-1) c_i = p_i xor b_i
b_1 = MD5 (A + S + RV) c_1 = p_1 xor b_1
b_2 = MD5 (S + c_1) c_2 = p_2 xor b_2
. .
. .
. .
b_i = MD5 (S + c_i-1) c_i = p_i xor b_i
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.2.1). See Section 3.1 for the list of defined control message types and their identifiers.
消息类型AVP必须是消息中的第一个AVP，紧跟在控制消息头之后（定义见第3.2.1节）。有关定义的控制消息类型及其标识符的列表，请参见第3.1节。
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. If the M bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the control connection 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 MUST 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。
A vendor-specific control message may be defined by setting the Vendor ID of the Message Type AVP to a value other than the IETF Vendor ID of 0 (see Section 5.1). The Message Type AVP MUST still be the first AVP in the control message.
可通过将消息类型AVP的供应商ID设置为IETF供应商ID以外的值0（参见第5.1节）来定义供应商特定控制消息。消息类型AVP必须仍然是控制消息中的第一个AVP。
Message Digest (All Messages)
消息摘要（所有消息）
The Message Digest AVP, Attribute Type 59 is used as an integrity and authentication check of the L2TP Control Message header and body.
消息摘要AVP属性类型59用作L2TP控制消息头和消息体的完整性和身份验证检查。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest Type | Message Digest ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 or 20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (16 or 20 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Digest Type is a one-octet integer indicating the Digest calculation algorithm:
摘要类型是一个八位整数，表示摘要计算算法：
0 HMAC-MD5 [RFC2104] 1 HMAC-SHA-1 [RFC2104]
0 HMAC-MD5[RFC2104]1 HMAC-SHA-1[RFC2104]
Digest Type 0 (HMAC-MD5) MUST be supported, while Digest Type 1 (HMAC-SHA-1) SHOULD be supported.
必须支持摘要类型0（HMAC-MD5），而应支持摘要类型1（HMAC-SHA-1）。
The Message Digest is of variable length and contains the result of the control message authentication and integrity calculation. For Digest Type 0 (HMAC-MD5), the length of the digest MUST be 16
消息摘要长度可变，包含控制消息身份验证和完整性计算的结果。对于摘要类型0（HMAC-MD5），摘要的长度必须为16
bytes. For Digest Type 1 (HMAC-SHA-1) the length of the digest MUST be 20 bytes.
字节。对于摘要类型1（HMAC-SHA-1），摘要的长度必须为20字节。
If Control Message Authentication is enabled, at least one Message Digest AVP MUST be present in all messages and MUST be placed immediately after the Message Type AVP. This forces the Message Digest AVP to begin at a well-known and fixed offset. A second Message Digest AVP MAY be present in a message and MUST be placed directly after the first Message Digest AVP.
如果启用了控制消息身份验证，则所有消息中必须至少有一个消息摘要AVP，并且必须紧跟在消息类型AVP之后。这将强制消息摘要AVP以众所周知的固定偏移量开始。第二消息摘要AVP可以存在于消息中，并且必须直接置于第一消息摘要AVP之后。
The shared secret between LCCEs is used to derive a unique shared key for Control Message Authentication calculations. The derived shared key is obtained via an HMAC-MD5 keyed hash [RFC2104], with the key consisting of the shared secret, and with the data being hashed consisting of a single octet containing the value 2.
LCCE之间的共享密钥用于导出用于控制消息身份验证计算的唯一共享密钥。派生的共享密钥通过HMAC-MD5密钥散列[RFC2104]获得，密钥由共享密钥组成，数据散列由包含值2的单个八位字节组成。
shared_key = HMAC_MD5 (shared_secret, 2)
共享密钥=HMAC\U MD5（共享密钥，2）
Calculation of the Message Digest is as follows for all messages other than the SCCRQ (where "+" refers to concatenation):
除SCCRQ外的所有消息的消息摘要计算如下（其中“+”表示串联）：
Message Digest = HMAC_Hash (shared_key, local_nonce + remote_nonce + control_message)
消息摘要=HMAC\u散列（共享密钥、本地\u当前+远程\u当前+控制\u消息）
HMAC_Hash: HMAC Hashing algorithm identified by the Digest Type (MD5 or SHA1)
HMAC_散列：由摘要类型（MD5或SHA1）标识的HMAC散列算法
local_nonce: Nonce chosen locally and advertised to the remote LCCE.
local_nonce：本地选择并播发给远程LCCE的nonce。
remote_nonce: Nonce received from the remote LCCE
远程\u nonce：从远程LCCE接收的nonce
(The local_nonce and remote_nonce are advertised via the Control Message Authentication Nonce AVP, also defined in this section.)
（本地和远程消息通过控制消息身份验证nonce AVP（也在本节中定义）发布。）
shared_key: Derived shared key for this control connection
共享密钥：此控制连接的派生共享密钥
control_message: The entire contents of the L2TP control message, including the control message header and all AVPs. Note that the control message header in this case begins after the all-zero Session ID when running over IP (see Section 4.1.1.2), and after the UDP header when running over UDP (see Section 4.1.2.1).
控制消息：L2TP控制消息的全部内容，包括控制消息头和所有AVP。请注意，在这种情况下，当通过IP运行时，控制消息头在全零会话ID之后开始（参见第4.1.1.2节），当通过UDP运行时，控制消息头在UDP头之后开始（参见第4.1.2.1节）。
When calculating the Message Digest, the Message Digest AVP MUST be present within the control message with the Digest Type set to its proper value, but the Message Digest itself set to zeros.
计算消息摘要时，消息摘要AVP必须存在于控制消息中，摘要类型设置为其正确值，但消息摘要本身设置为零。
When receiving a control message, the contents of the Message Digest AVP MUST be compared against the expected digest value based on local calculation. This is done by performing the same digest calculation above, with the local_nonce and remote_nonce reversed. This message authenticity and integrity checking MUST be performed before utilizing any information contained within the control message. If the calculation fails, the message MUST be dropped.
接收控制消息时，必须根据本地计算将消息摘要AVP的内容与预期摘要值进行比较。这是通过执行上面相同的摘要计算来完成的，本地和远程的摘要计算是相反的。在使用控制消息中包含的任何信息之前，必须执行此消息真实性和完整性检查。如果计算失败，则必须删除该消息。
The SCCRQ has special treatment as it is the initial message commencing a new control connection. As such, there is only one nonce available. Since the nonce is present within the message itself as part of the Control Message Authentication Nonce AVP, there is no need to use it in the calculation explicitly. Calculation of the SCCRQ Message Digest is performed as follows:
SCCRQ有特殊处理，因为它是开始新控制连接的初始消息。因此，只有一个nonce可用。由于nonce作为控制消息身份验证nonce AVP的一部分存在于消息本身中，因此无需在计算中明确使用它。SCCRQ消息摘要的计算如下所示：
Message Digest = HMAC_Hash (shared_key, control_message)
消息摘要=HMAC_散列（共享_键、控制_消息）
To allow for graceful switchover to a new shared secret or hash algorithm, two Message Digest AVPs MAY be present in a control message, and two shared secrets MAY be configured for a given LCCE. If two Message Digest AVPs are received in a control message, the message MUST be accepted if either Message Digest is valid. If two shared secrets are configured, each (separately) MUST be used for calculating a digest to be compared to the Message Digest(s) received. When calculating a digest for a control message, the Value field for both of the Message Digest AVPs MUST be set to zero.
为了允许优雅地切换到新的共享秘密或散列算法，控制消息中可以存在两个消息摘要avp，并且可以为给定LCCE配置两个共享秘密。如果在控制消息中接收到两个消息摘要AVP，则如果任一消息摘要有效，则必须接受该消息。如果配置了两个共享机密，则每个（单独）都必须用于计算摘要，以便与接收到的消息摘要进行比较。计算控制消息摘要时，两个消息摘要AVP的值字段必须设置为零。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length is 23 for Digest Type 1 (HMAC-MD5), and 27 for Digest Type 2 (HMAC-SHA-1).
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。消化类型1（HMAC-MD5）的长度为23，消化类型2（HMAC-SHA-1）的长度为27。
Control Message Authentication Nonce (SCCRQ, SCCRP)
控制消息身份验证Nonce（SCCRQ、SCCRP）
The Control Message Authentication Nonce AVP, Attribute Type 73, MUST contain a cryptographically random value [RFC1750]. This value is used for Control Message Authentication.
控制消息身份验证Nonce AVP属性类型73必须包含加密随机值[RFC1750]。此值用于控制消息身份验证。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce is of arbitrary length, though at least 16 octets is recommended. The Nonce contains the random value for use in the Control Message Authentication hash calculation (see Message Digest AVP definition in this section).
Nonce具有任意长度，但建议至少有16个八位字节。Nonce包含用于控制消息身份验证哈希计算的随机值（请参阅本节中的消息摘要AVP定义）。
If Control Message Authentication is enabled, this AVP MUST be present in the SCCRQ and SCCRP messages.
如果启用了控制消息身份验证，则此AVP必须出现在SCCRQ和SCCRP消息中。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Nonce.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度为6加上Nonce的长度。
Random Vector (All Messages)
随机向量（所有消息）
The Random Vector AVP, Attribute Type 36, MUST contain a cryptographically random value [RFC1750]. This value is used for AVP Hiding.
属性类型为36的随机向量AVP必须包含加密随机值[RFC1750]。此值用于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 ... (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Random Octet String is of arbitrary length, though 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 5.3).
随机八位字节字符串具有任意长度，但建议至少有16个八位字节。该字符串包含用于计算MD5散列以检索或隐藏隐藏的AVP属性值的随机向量（参见第5.3节）。
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. As such, at least one Random Vector AVP MUST precede the first AVP with the H bit set.
消息中可能出现多个随机向量AVP，在这种情况下，隐藏AVP使用最接近其前面的随机向量AVP。因此，至少一个随机向量AVP必须位于设置了H位的第一个AVP之前。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Random Octet String.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。这个AVP的长度是6加上随机八位字节字符串的长度。
Result Code (StopCCN, CDN)
结果代码（StopCCN、CDN）
The Result Code AVP, Attribute Type 1, indicates the reason for terminating the control connection 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 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Error Code (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Message ... (optional, arbitrary number of octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Message is 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 [RFC3629] using the Default Language [RFC2277].
结果代码是一个2-octet无符号整数。可选错误代码是2个八位无符号整数。错误代码字段后面可以显示可选的错误消息。AVP长度字段指示存在错误代码和消息。错误消息包含一个任意字符串，提供与条件相关的更多（人类可读）文本。必须使用默认语言[RFC2277]在UTF-8字符集[RFC3629]中提供所有错误消息中的人类可读文本。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). 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 plus the length of the Error Message if there is an Error Code and Message.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。如果没有错误代码或消息，则长度为8；如果有错误代码和错误消息，则长度为10；如果有错误代码和消息，则长度为10加上错误消息的长度。
Defined Result Code values for the StopCCN message are as follows:
StopCCN消息的定义结果代码值如下：
0 - Reserved. 1 - General request to clear control connection. 2 - General error, Error Code indicates the problem. 3 - Control connection already exists. 4 - Requester is not authorized to establish a control connection. 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 or timeout
0-保留。1-清除控制连接的一般请求。2-一般错误，错误代码表示问题。3-控制连接已存在。4-请求者无权建立控制连接。5-不支持请求程序的协议版本，错误代码表示支持的最高版本。6-请求程序正在关闭。7-有限状态机错误或超时
General Result Code values for the CDN message are as follows:
CDN消息的一般结果代码值如下：
0 - Reserved. 1 - Session disconnected due to loss of carrier or circuit disconnect. 2 - Session disconnected for the reason indicated in Error Code. 3 - Session disconnected for administrative reasons. 4 - Session establishment failed due to lack of appropriate facilities being available (temporary condition).
0-保留。1-由于载波丢失或电路断开，会话断开。2-由于错误代码中指示的原因，会话已断开。3-由于管理原因，会话已断开。4-由于缺乏可用的适当设施（临时条件），会话建立失败。
5 - Session establishment failed due to lack of appropriate facilities being available (permanent condition). 13 - Session not established due to losing tie breaker. 14 - Session not established due to unsupported PW type. 15 - Session not established, sequencing required without valid L2-Specific Sublayer. 16 - Finite state machine error or timeout.
5-由于缺乏可用的适当设施（永久条件），会话建立失败。13-由于失去联络断路器，会话未建立。14-由于不支持的PW类型，未建立会话。15-未建立会话，没有有效的L2特定子层，需要排序。16-有限状态机错误或超时。
Additional service-specific Result Codes are defined outside this document.
其他特定于服务的结果代码在本文档之外定义。
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 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 as follows:
下面定义的错误代码与不特定于任何特定L2TP请求的错误类型有关，而与协议或消息格式错误有关。如果L2TP应答在其结果代码中指出发生了一般错误，则应检查一般错误值以确定错误是什么。目前定义的一般错误代码及其含义如下：
0 - No General Error. 1 - No control connection exists yet for this pair of LCCEs. 2 - Length is wrong. 3 - One of the field values was out of range. 4 - Insufficient resources to handle this operation now. 5 - Invalid Session ID. 6 - A generic vendor-specific error occurred. 7 - Try another. If initiator is aware of other possible responder destinations, it should try one of them. This can be used to guide an LAC or LNS based on policy. 8 - The session or control connection was shut down due to receipt of an unknown AVP with the M bit set (see Section 5.2). The Error Message SHOULD contain the attribute of the offending AVP in (human-readable) text form. 9 - Try another directed. If an LAC or LNS is aware of other possible destinations, it should inform the initiator of the control connection or session. The Error Message MUST contain a comma-separated list of addresses from which the initiator may choose. If the L2TP data channel runs over IPv4, then this would be a comma-separated list of IP addresses in the canonical dotted-decimal format (e.g., "192.0.2.1, 192.0.2.2, 192.0.2.3") in the UTF-8 charset [RFC3629] using the Default Language [RFC2277]. If there are no servers for the LAC or LNS to suggest, then Error Code 7 should be used. For IPv4, the delimiter between addresses MUST be precisely a single comma and a single space. For IPv6, each literal address MUST be enclosed in "[" and "]" characters, following the encoding described in [RFC2732].
0-无常规错误。1-此对LCCE尚不存在控制连接。2-长度错误。3-其中一个字段值超出范围。4-资源不足，无法立即处理此操作。5-会话ID无效。6-发生一般供应商特定错误。7-试试另一个。如果发起方知道其他可能的响应方目的地，则应尝试其中一个目的地。这可用于根据策略指导LAC或LN。8-会话或控制连接因接收到设置了M位的未知AVP而关闭（见第5.2节）。错误消息应该以（人类可读的）文本形式包含有问题的AVP的属性。9-尝试另一种定向。如果LAC或LNS知道其他可能的目的地，则应将控制连接或会话通知启动器。错误消息必须包含一个逗号分隔的地址列表，发起者可以从中进行选择。如果L2TP数据通道在IPv4上运行，那么这将是一个使用默认语言[RFC2277]的UTF-8字符集[RFC3629]中标准点十进制格式（例如，“192.0.2.1、192.0.2.2、192.0.2.3”）的以逗号分隔的IP地址列表。如果没有LAC或LN建议的服务器，则应使用错误代码7。对于IPv4，地址之间的分隔符必须正好是一个逗号和一个空格。对于IPv6，每个文本地址必须按照[RFC2732]中描述的编码用“[”和“]”字符括起来。
When a General Error Code of 6 is used, additional information about the error SHOULD be included in the Error Message field. A vendor-specific AVP MAY be sent to more precisely detail a vendor-specific problem.
当使用一般错误代码6时，有关错误的附加信息应包含在错误消息字段中。可以发送特定于供应商的AVP，以更精确地详细说明特定于供应商的问题。
Control Connection Tie Breaker (SCCRQ)
控制连接接头断路器（SCCRQ）
The Control Connection Tie Breaker AVP, Attribute Type 5, indicates that the sender desires a single control connection to exist between a given pair of LCCEs.
控制连接断开器AVP属性类型5表示发送方希望在给定的一对LCCE之间存在单个控制连接。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Connection Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Connection Tie Breaker Value is an 8-octet random value that is used to choose a single control connection when two LCCEs request a control connection concurrently. The recipient of a SCCRQ must check to see if a SCCRQ has been sent to the peer; if so, a tie has been detected. In this case, the LCCE must compare its Control Connection Tie Breaker value with the one received in the SCCRQ. The lower value "wins", and the "loser" MUST discard its control connection. A StopCCN SHOULD be sent by the winner as an explicit rejection for the losing SCCRQ. In the case in which a tie breaker is present on both sides and the value is equal, both sides MUST discard their control connections and restart control connection negotiation with a new, random tie breaker value.
控制连接连接断路器值是8个八位组的随机值，当两个LCCE同时请求控制连接时，用于选择单个控制连接。SCCRQ的接收者必须检查SCCRQ是否已发送给对等方；如果是，则已检测到平局。在这种情况下，LCCE必须将其控制连接接头断路器值与SCCRQ中接收到的值进行比较。较低的值“wins”，而“lower”必须放弃其控制连接。胜利者应发送StopCCN，作为对失败SCCRQ的明确拒绝。如果两侧都存在一个连接断路器，且该值相等，则两侧必须放弃其控制连接，并使用新的随机连接断路器值重新启动控制连接协商。
If a tie breaker is received and an outstanding SCCRQ has no tie breaker value, the initiator that included the Control Connection Tie Breaker AVP "wins". If neither side issues a tie breaker, then two separate control connections are opened.
如果收到连接断路器且未完成的SCCRQ没有连接断路器值，则包含控制连接连接连接断路器AVP的启动器“获胜”。如果任何一方均未发出联络断路器，则打开两个单独的控制连接。
Applications that employ a distinct and well-known initiator have no need for tie breaking, and MAY omit this AVP or disable tie breaking functionality. Applications that require tie breaking also require that an LCCE be uniquely identifiable upon receipt of an SCCRQ. For L2TP over IP, this MUST be accomplished via the Router ID AVP.
使用独特且众所周知的启动器的应用程序不需要中断连接，并且可能会忽略此AVP或禁用中断连接功能。需要断开连接的应用程序还要求LCCE在收到SCCRQ后能够唯一识别。对于IP上的L2TP，这必须通过路由器ID AVP完成。
Note that in [RFC2661], this AVP is referred to as the "Tie Breaker AVP" and is applicable only to a control connection. In L2TPv3, the AVP serves the same purpose of tie breaking, but is applicable to a control connection or a session. The Control Connection Tie Breaker AVP (present only in Control Connection messages) and Session Tie Breaker AVP (present only in Session messages), are described separately in this document, but share the same Attribute type of 5.
注意，在[RFC2661]中，该AVP被称为“联络断路器AVP”，仅适用于控制连接。在L2TPv3中，AVP的作用与断开连接相同，但适用于控制连接或会话。控制连接中断器AVP（仅出现在控制连接消息中）和会话中断器AVP（仅出现在会话消息中）在本文档中分别描述，但共享相同的属性类型5。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The length of this AVP is 14.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。这个AVP的长度是14。
Host Name (SCCRQ, SCCRP)
主机名（SCCRQ、SCCRP）
The Host Name AVP, Attribute Type 7, indicates the name of the issuing LAC or LNS, encoded in the US-ASCII charset.
主机名AVP属性类型7表示发出LAC或LN的名称，以US-ASCII字符集编码。
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 host name with fully qualified domain would be appropriate. The Host Name AVP and/or Router ID AVP MUST be used to identify an LCCE as described in Section 3.3.
该名称应尽可能具有广泛的唯一性；对于参与DNS[RFC1034]的主机，具有完全限定域的主机名是合适的。主机名AVP和/或路由器ID AVP必须用于识别LCCE，如第3.3节所述。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 6 plus the length of the Host Name.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度为6加上主机名的长度。
Router ID (SCCRQ, SCCRP)
路由器ID（SCCRQ、SCCRP）
The Router ID AVP, Attribute Type 60, is an identifier used to identify an LCCE for control connection setup, tie breaking, and/or tunnel authentication.
路由器ID AVP（属性类型60）是一个标识符，用于标识用于控制连接设置、断开连接和/或隧道身份验证的LCCE。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router Identifier is a 4-octet unsigned integer. Its value is unique for a given LCCE, per Section 8.1 of [RFC2072]. The Host Name AVP and/or Router ID AVP MUST be used to identify an LCCE as described in Section 3.3.
路由器标识符是一个4八位无符号整数。根据[RFC2072]第8.1节，其值对于给定LCCE是唯一的。主机名AVP和/或路由器ID AVP必须用于识别LCCE，如第3.3节所述。
Implementations MUST NOT assume that Router Identifier is a valid IP address. The Router Identifier for L2TP over IPv6 can be obtained from an IPv4 address (if available) or via unspecified implementation-specific means.
实现不能假定路由器标识符是有效的IP地址。IPv6上L2TP的路由器标识符可以从IPv4地址（如果可用）或通过未指定的具体实现方式获得。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 10.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。这个AVP的长度是10。
Vendor Name (SCCRQ, SCCRP)
供应商名称（SCCRQ、SCCRP）
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 US-ASCII charset [RFC1958, RFC2277].
供应商名称是表示供应商字符串的指定八位字节数。此AVP的人类可读文本必须以US-ASCII字符集[RFC1958，RFC2277]提供。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Vendor Name.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为6加上供应商名称的长度。
Assigned Control Connection ID (SCCRQ, SCCRP, StopCCN)
分配的控制连接ID（SCCRQ、SCCRP、StopCCN）
The Assigned Control Connection ID AVP, Attribute Type 61, contains the ID being assigned to this control connection by the sender.
分配的控制连接ID AVP属性类型61包含发送方分配给该控制连接的ID。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Control Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Control Connection ID is a 4-octet non-zero unsigned integer.
分配的控制连接ID是4个八位字节的非零无符号整数。
The Assigned Control Connection ID AVP establishes the identifier used to multiplex and demultiplex multiple control connections between a pair of LCCEs. Once the Assigned Control Connection ID AVP has been received by an LCCE, the Control Connection ID specified in the AVP MUST be included in the Control Connection ID field of all control packets sent to the peer for the lifetime of the control connection. Before the Assigned Control Connection ID AVP is received from a peer, all control messages MUST be sent to that peer with a Control Connection ID value of 0 in the header. Because a Control Connection ID value of 0 is used in this special manner, the zero value MUST NOT be sent as an Assigned Control Connection ID value.
分配的控制连接ID AVP建立用于在一对lcce之间多路复用和多路解复用多个控制连接的标识符。一旦LCCE接收到分配的控制连接ID AVP，AVP中指定的控制连接ID必须包含在控制连接生存期内发送给对等方的所有控制数据包的控制连接ID字段中。在从对等方接收分配的控制连接ID AVP之前，必须将所有控制消息发送到该对等方，且头中的控制连接ID值为0。因为控制连接ID值0是以这种特殊方式使用的，所以零值不能作为分配的控制连接ID值发送。
Under certain circumstances, an LCCE may need to send a StopCCN to a peer without having yet received an Assigned Control Connection ID AVP from the peer (i.e., SCCRQ sent, no SCCRP received yet). In this case, the Assigned Control Connection ID AVP that had been sent to the peer earlier (i.e., in the SCCRQ) MUST be sent as the Assigned Control Connection ID AVP in the StopCCN. This policy allows the peer to try to identify the appropriate control connection via a reverse lookup.
在某些情况下，LCCE可能需要向对等方发送StopCCN，而没有从对等方接收到分配的控制连接ID AVP（即，发送了SCCRQ，没有接收到SCCRP）。在这种情况下，先前发送给对等方（即在SCCRQ中）的分配控制连接ID AVP必须作为StopCCN中的分配控制连接ID AVP发送。此策略允许对等方通过反向查找尝试识别适当的控制连接。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为10。
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.
如果不存在，对等方必须假定其传输窗口的窗口大小为4。
The remote peer may send the specified number of control messages before it must wait for an acknowledgment. See Section 4.2 for more information on reliable control message delivery.
在必须等待确认之前，远程对等方可以发送指定数量的控制消息。有关可靠控制消息传递的更多信息，请参见第4.2节。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 8.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。这个AVP的长度是8。
Pseudowire Capabilities List (SCCRQ, SCCRP)
伪线能力列表（SCCRQ、SCCRP）
The Pseudowire Capabilities List (PW Capabilities List) AVP, Attribute Type 62, indicates the L2 payload types the sender can support. The specific payload type of a given session is identified by the Pseudowire Type AVP.
伪线能力列表（PW能力列表）AVP属性类型62表示发送方可以支持的L2有效负载类型。给定会话的特定有效负载类型由伪线类型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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type 0 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | PW Type N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined PW types that may appear in this list are managed by IANA and will appear in associated pseudowire-specific documents for each PW type.
此列表中可能出现的已定义PW类型由IANA管理，并将出现在每个PW类型的相关伪导线特定文档中。
If a sender includes a given PW type in the PW Capabilities List AVP, the sender assumes full responsibility for supporting that particular payload, such as any payload-specific AVPs, L2-Specific Sublayer, or control messages that may be defined in the appropriate companion document.
如果发送方在PW能力列表AVP中包括给定的PW类型，则发送方承担支持该特定有效负载的全部责任，例如任何特定于有效负载的AVP、特定于L2的子层或可能在相应的配套文档中定义的控制消息。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8 octets with one PW type specified, plus 2 octets for each additional PW type.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为8个八位字节，指定了一种PW类型，每增加一种PW类型加上2个八位字节。
Preferred Language (SCCRQ, SCCRP)
首选语言（SCCRQ、SCCRP）
The Preferred Language AVP, Attribute Type 72, provides a method for an LCCE to indicate to the peer the language in which human-readable messages it sends SHOULD be composed. This AVP contains a single language tag or language range [RFC3066].
属性类型72的优选语言AVP为LCCE提供了一种方法，用于向对等方指示其发送的人类可读消息应使用的语言。此AVP包含单个语言标记或语言范围[RFC3066]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Language... (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Language... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Preferred Language is the indicated number of octets representing the language tag or language range, encoded in the US-ASCII charset.
首选语言是表示语言标记或语言范围的指定八位字节数，以US-ASCII字符集编码。
It is not required to send a Preferred Language AVP. If (1) an LCCE does not signify a language preference by the inclusion of this AVP in the SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.
无需发送首选语言AVP。如果（1）通过在SCCRQ或SCCRP中包含此AVP，LCCE不表示语言偏好，（2）首选语言AVP无法识别，或（3）对等LCCE不支持请求的语言，则对等方发送的所有国际化字符串必须使用默认语言[RFC2277]。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Preferred Language.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为6加上首选语言的长度。
Local Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
本地会话ID（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、WEN、SLI）
The Local Session ID AVP (analogous to the Assigned Session ID in L2TPv2), Attribute Type 63, contains the identifier being assigned to this session by the sender.
本地会话ID AVP（类似于L2TPv2中分配的会话ID）属性类型63包含发送方分配给该会话的标识符。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Session 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Local Session ID is a 4-octet non-zero unsigned integer.
本地会话ID是一个4-octet非零无符号整数。
The Local Session ID AVP establishes the two identifiers used to multiplex and demultiplex sessions between two LCCEs. Each LCCE chooses any free value it desires, and sends it to the remote LCCE using this AVP. The remote LCCE MUST then send all data packets associated with this session using this value. Additionally, for all session-oriented control messages sent after this AVP is received (e.g., ICRP, ICCN, CDN, SLI, etc.), the remote LCCE MUST echo this value in the Remote Session ID AVP.
本地会话ID AVP建立用于在两个lcce之间复用和解复用会话的两个标识符。每个LCCE选择它想要的任何自由值，并使用此AVP将其发送到远程LCCE。然后，远程LCCE必须使用此值发送与此会话关联的所有数据包。此外，对于接收到此AVP后发送的所有面向会话的控制消息（例如ICRP、ICCN、CDN、SLI等），远程LCCE必须在远程会话ID AVP中回显此值。
Note that a Session ID value is unidirectional. Because each LCCE chooses its Session ID independent of its peer LCCE, the value does not have to match in each direction for a given session.
请注意，会话ID值是单向的。由于每个LCCE独立于其对等LCCE选择其会话ID，因此该值不必在给定会话的每个方向上匹配。
See Section 4.1 for additional information about the Session ID.
有关会话ID的更多信息，请参见第4.1节。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be 1 set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1到1，但可能会有所不同（见第5.2节）。此AVP的长度（隐藏前）为10。
Remote Session ID (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, CDN, WEN, SLI)
远程会话ID（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、CDN、WEN、SLI）
The Remote Session ID AVP, Attribute Type 64, contains the identifier that was assigned to this session by the peer.
远程会话ID AVP属性类型64包含对等方分配给该会话的标识符。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote Session ID is a 4-octet non-zero unsigned integer.
远程会话ID是一个4-octet非零无符号整数。
The Remote Session ID AVP MUST be present in all session-level control messages. The AVP's value echoes the session identifier advertised by the peer via the Local Session ID AVP. It is the same value that will be used in all transmitted data messages by
远程会话ID AVP必须出现在所有会话级控制消息中。AVP的值与对等方通过本地会话ID AVP通告的会话标识符相呼应。该值与将由用户在所有传输的数据消息中使用的值相同
this side of the session. In most cases, this identifier is sufficient for the peer to look up session-level context for this control message.
会议的这一部分。在大多数情况下，该标识符足以让对等方查找该控制消息的会话级上下文。
When a session-level control message must be sent to the peer before the Local Session ID AVP has been received, the value of the Remote Session ID AVP MUST be set to zero. Additionally, the Local Session ID AVP (sent in a previous control message for this session) MUST be included in the control message. The peer must then use the Local Session ID AVP to perform a reverse lookup to find its session context. Session-level control messages defined in this document that might be subject to a reverse lookup by a receiving peer include the CDN, WEN, and SLI.
当必须在收到本地会话ID AVP之前向对等方发送会话级控制消息时，远程会话ID AVP的值必须设置为零。此外，本地会话ID AVP（在此会话的前一个控制消息中发送）必须包含在控制消息中。然后，对等方必须使用本地会话ID AVP执行反向查找以查找其会话上下文。本文档中定义的会话级控制消息可能会由接收对等方进行反向查找，包括CDN、WEN和SLI。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为10。
Assigned Cookie (ICRQ, ICRP, OCRQ, OCRP)
分配的Cookie（ICRQ、ICRP、OCRQ、OCRP）
The Assigned Cookie AVP, Attribute Type 65, contains the Cookie value being assigned to this session by the sender.
分配的Cookie AVP属性类型65包含发送方分配给该会话的Cookie值。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Cookie (32 or 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Cookie (32 or 64 bits) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Assigned Cookie is a 4-octet or 8-octet random value.
分配的Cookie是4个八位字节或8个八位字节的随机值。
The Assigned Cookie AVP contains the value used to check the association of a received data message with the session identified by the Session ID. All data messages sent to a peer MUST use the Assigned Cookie sent by the peer in this AVP. The value's length (0, 32, or 64 bits) is obtained by the length of the AVP.
分配的Cookie AVP包含用于检查接收到的数据消息与会话ID标识的会话的关联的值。发送给对等方的所有数据消息必须使用该AVP中对等方发送的分配的Cookie。值的长度（0、32或64位）由AVP的长度获得。
A missing Assigned Cookie AVP or Assigned Cookie Value of zero length indicates that the Cookie field should not be present in any data packets sent to the LCCE sending this AVP.
缺少分配的Cookie AVP或分配的Cookie值为零表示发送到发送此AVP的LCCE的任何数据包中不应存在Cookie字段。
See Section 4.1 for additional information about the Assigned Cookie.
有关指定Cookie的更多信息，请参见第4.1节。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP may be 6, 10, or 14 octets.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。该AVP的长度（隐藏前）可以是6、10或14个八位字节。
Serial Number (ICRQ, OCRQ)
序列号（ICRQ、OCRQ）
The Serial Number AVP, Attribute Type 15, contains an identifier assigned by the LAC or LNS to this session.
序列号AVP属性类型15包含LAC或LNS分配给该会话的标识符。
The Attribute Value field for this AVP has the following format:
此AVP的属性值字段具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Serial Number is a 32-bit value.
序列号是一个32位的值。
The Serial Number is intended to be an easy reference for administrators on both ends of a control connection to use when investigating session failure problems. 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中，该值可能在相当长的一段时间内是唯一的。
Note that in RFC 2661, this value was referred to as the "Call Serial Number AVP". It serves the same purpose and has the same attribute value and composition.
注意，在RFC 2661中，该值被称为“呼叫序列号AVP”。它具有相同的目的，具有相同的属性值和组成。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为10。
Remote End ID (ICRQ, OCRQ)
远程端ID（ICRQ、OCRQ）
The Remote End ID AVP, Attribute Type 66, contains an identifier used to bind L2TP sessions to a given circuit, interface, or bridging instance. It also may be used to detect session-level ties.
远程端ID AVP属性类型66包含用于将L2TP会话绑定到给定电路、接口或桥接实例的标识符。它还可用于检测会话级别的联系。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote End Identifier ... (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote End Identifier ... (arbitrary number of octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote End Identifier field is a variable-length field whose value is unique for a given LCCE peer, as described in Section 3.3.
远程端标识符字段是一个可变长度字段，其值对于给定LCCE对等方是唯一的，如第3.3节所述。
A session-level tie is detected if an LCCE receives an ICRQ or OCRQ with an End ID AVP whose value matches that which was just sent in an outgoing ICRQ or OCRQ to the same peer. If the two values match, an LCCE recognizes that a tie exists (i.e., both LCCEs are attempting to establish sessions for the same circuit). The tie is broken by the Session Tie Breaker AVP.
如果LCCE接收到一个ICRQ或OCRQ，且该ICRQ或OCRQ的端ID为AVP，其值与刚刚在传出ICRQ或OCRQ中发送给同一对等方的值相匹配，则会检测到会话级tie。如果两个值匹配，LCCE将识别出存在平局（即，两个LCCE都试图为同一电路建立会话）。连接被会话连接断开器AVP断开。
By default, the LAC-LAC cross-connect application (see Section 2(b)) of L2TP over an IP network MUST utilize the Router ID AVP and Remote End ID AVP to associate a circuit to an L2TP session. Other AVPs MAY be used for LCCE or circuit identification as specified in companion documents.
默认情况下，IP网络上L2TP的LAC-LAC交叉连接应用程序（参见第2（b）节）必须利用路由器ID AVP和远程端ID AVP将电路与L2TP会话相关联。其他AVP可用于配套文件中规定的LCCE或电路识别。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 6 plus the length of the Remote End Identifier value.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为6加上远端标识符值的长度。
Session Tie Breaker (ICRQ, OCRQ)
会话连接断路器（ICRQ、OCRQ）
The Session Tie Breaker AVP, Attribute Type 5, is used to break ties when two peers concurrently attempt to establish a session for the same circuit.
会话连接断路器AVP（属性类型5）用于在两个对等方同时尝试为同一电路建立会话时断开连接。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Tie Breaker 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Tie Breaker Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session Tie Breaker Value is an 8-octet random value that is used to choose a session when two LCCEs concurrently request a session for the same circuit. A tie is detected by examining the peer's identity (described in Section 3.3) plus the per-session shared value communicated via the End ID AVP. In the case of a tie, the recipient of an ICRQ or OCRQ must compare the received tie breaker value with the one that it sent earlier. The LCCE with the lower value "wins" and MUST send a CDN with result code set to 13 (as defined in Section 5.4.2) in response to the losing ICRQ or OCRQ. In the case in which a tie is detected, tie
会话连接断路器值是8个八位组的随机值，用于在两个LCCE同时请求同一电路的会话时选择会话。通过检查对等方的身份（如第3.3节所述）加上通过终端ID AVP传输的每会话共享值，可以检测到平局。在平局的情况下，ICRQ或OCRQ的接收者必须将收到的平局断路器值与其先前发送的值进行比较。具有较低值“wins”的LCCE必须发送结果代码设置为13（如第5.4.2节所定义）的CDN，以响应丢失的ICRQ或OCRQ。在检测到领带的情况下，领带
breakers are sent by both sides, and the tie breaker values are equal, both sides MUST discard their sessions and restart session negotiation with new random tie breaker values.
如果双方都发送断开器，并且断开器的值相等，则双方必须放弃其会话，并使用新的随机断开器值重新启动会话协商。
If a tie is detected but only one side sends a Session Tie Breaker AVP, the session initiator that included the Session Tie Breaker AVP "wins". If neither side issues a tie breaker, then both sides MUST tear down the session.
如果检测到平局，但只有一方发送会话平局中断器AVP，则包含会话平局中断器AVP的会话发起方“获胜”。如果任何一方都没有发布平局决胜票，那么双方都必须取消该会议。
This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length of this AVP is 14.
不得隐藏此AVP（H位必须为0）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。这个AVP的长度是14。
Pseudowire Type (ICRQ, OCRQ)
伪线类型（ICRQ、OCRQ）
The Pseudowire Type (PW Type) AVP, Attribute Type 68, indicates the L2 payload type of the packets that will be tunneled using this L2TP session.
伪线类型（PW类型）AVP属性类型68表示将使用此L2TP会话进行隧道传输的数据包的L2有效负载类型。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A peer MUST NOT request an incoming or outgoing call with a PW Type AVP specifying a value not advertised in the PW Capabilities List AVP it received during control connection establishment. Attempts to do so MUST result in the call being rejected via a CDN with the Result Code set to 14 (see Section 5.4.2).
对等方不得使用PW类型AVP请求传入或传出呼叫，该AVP指定了在控制连接建立期间接收到的PW能力列表AVP中未公布的值。尝试这样做必须导致通过CDN拒绝呼叫，结果代码设置为14（见第5.4.2节）。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为8。
L2-Specific Sublayer (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
L2特定子层（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The L2-Specific Sublayer AVP, Attribute Type 69, indicates the presence and format of the L2-Specific Sublayer the sender of this AVP requires on all incoming data packets for this L2TP session.
L2特定子层AVP属性类型69表示此AVP的发送方在此L2TP会话的所有传入数据包上要求的L2特定子层的存在和格式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-Specific Sublayer Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2-Specific Sublayer Type is a 2-octet unsigned integer with the following values defined in this document:
L2特定子层类型是一个2-octet无符号整数，具有本文档中定义的以下值：
0 - There is no L2-Specific Sublayer present. 1 - The Default L2-Specific Sublayer (defined in Section 4.6) is used.
0-不存在L2特定的子层。1-使用默认的L2特定子层（定义见第4.6节）。
If this AVP is received and has a value other than zero, the receiving LCCE MUST include the identified L2-Specific Sublayer in its outgoing data messages. If the AVP is not received, it is assumed that there is no sublayer present.
如果接收到该AVP且其值不是零，则接收LCCE必须在其传出数据消息中包括识别的L2特定子层。如果未接收到AVP，则假定不存在子层。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为8。
Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
数据排序（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Data Sequencing AVP, Attribute Type 70, indicates that the sender requires some or all of the data packets that it receives to be sequenced.
属性类型70的数据排序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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Sequencing Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data Sequencing Level is a 2-octet unsigned integer indicating the degree of incoming data traffic that the sender of this AVP wishes to be marked with sequence numbers.
数据序列级别是一个2-octet无符号整数，表示此AVP的发送方希望用序列号标记的传入数据流量的程度。
Defined Data Sequencing Levels are as follows:
定义的数据排序级别如下：
0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
0-没有需要排序的传入数据包。1-只有非IP数据包需要排序。2-所有传入数据包都需要排序。
If a Data Sequencing Level of 0 is specified, there is no need to send packets with sequence numbers. If sequence numbers are sent, they will be ignored upon receipt. If no Data Sequencing AVP is received, a Data Sequencing Level of 0 is assumed.
如果指定的数据序列级别为0，则无需发送带有序列号的数据包。如果序列号已发送，则在收到时将忽略它们。如果未收到数据排序AVP，则假定数据排序级别为0。
If a Data Sequencing Level of 1 is specified, only non-IP traffic carried within the tunneled L2 frame should have sequence numbers applied. Non-IP traffic here refers to any packets that cannot be
如果指定的数据顺序级别为1，则只有隧道L2帧内承载的非IP通信才应应用序列号。此处的非IP流量指的是无法访问的任何数据包
classified as an IP packet within their respective L2 framing (e.g., a PPP control packet or NETBIOS frame encapsulated by Frame Relay before being tunneled). All traffic that can be classified as IP MUST be sent with no sequencing (i.e., the S bit in the L2- Specific Sublayer is set to zero). If a packet is unable to be classified at all (e.g., because it has been compressed or encrypted at layer 2) or if an implementation is unable to perform such classification within L2 frames, all packets MUST be provided with sequence numbers (essentially falling back to a Data Sequencing Level of 2).
在其各自的L2帧内被分类为IP分组（例如，PPP控制分组或在被隧道化之前由帧中继封装的NETBIOS帧）。所有可归类为IP的流量都必须不按顺序发送（即，L2特定子层中的S位设置为零）。如果数据包根本无法分类（例如，因为它在第2层被压缩或加密），或者如果实现无法在L2帧内执行此类分类，则必须为所有数据包提供序列号（基本上返回到2的数据排序级别）。
If a Data Sequencing Level of 2 is specified, all traffic MUST be sequenced.
如果指定的数据排序级别为2，则必须对所有流量进行排序。
Data sequencing may only be requested when there is an L2-Specific Sublayer present that can provide sequence numbers. If sequencing is requested without requesting a L2-Specific Sublayer AVP, the session MUST be disconnected with a Result Code of 15 (see Section 5.4.2).
仅当存在可提供序列号的L2特定子层时，才可请求数据排序。如果在未请求L2特定子层AVP的情况下请求排序，则必须断开会话，结果代码为15（见第5.4.2节）。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为8。
Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
发送连接速度（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Tx Connect Speed BPS AVP, Attribute Type 74, contains the speed of the facility chosen for the connection attempt.
Tx Connect Speed BPS AVP属性类型74包含为连接尝试选择的设施的速度。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tx Connect Speed BPS is an 8-octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable or that there is no physical point-to-point link.
Tx Connect Speed BPS是一个8位字节的值，表示以位/秒为单位的速度。值为零表示速度不确定或没有物理点对点链接。
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 (i.e., 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
当存在可选的Rx连接速度AVP时，该AVP中的值从LAC的角度表示传输连接速度（即，从LAC到远程系统的数据流）。当可选的Rx连接速度AVP不存在时，远程系统和LAC之间的连接速度为
assumed to be symmetric and is represented by the single value in this AVP.
假设是对称的，并由该AVP中的单个值表示。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 14.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为14。
Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)
接收连接速度（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN）
The Rx Connect Speed AVP, Attribute Type 75, represents the speed of the connection from the perspective of the LAC (i.e., data flowing from the remote system to the LAC).
Rx Connect Speed AVP属性类型75从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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connect Speed in bps...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Connect Speed in bps (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Connect Speed BPS is an 8-octet value indicating the speed in bits per second. A value of zero indicates that the speed is indeterminable or that there is no physical point-to-point link.
连接速度BPS是一个8字节的值，表示速度（以位/秒为单位）。值为零表示速度不确定或没有物理点对点链接。
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 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 14.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为14。
Physical Channel ID (ICRQ, ICRP, OCRP)
物理通道ID（ICRQ、ICRP、OCRP）
The Physical Channel ID AVP, Attribute Type 25, contains 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-octet值，仅用于记录目的。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 10.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为10。
Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)
电路状态（ICRQ、ICRP、ICCN、OCRQ、OCRP、OCCN、SLI）
The Circuit Status AVP, Attribute Type 71, indicates the initial status of or a status change in the circuit to which the session is bound.
电路状态AVP属性类型71表示会话绑定到的电路的初始状态或状态变化。
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 |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The A (Active) bit indicates whether the circuit is up/active/ready (1) or down/inactive/not-ready (0).
A（活动）位指示电路是向上/活动/就绪（1）还是向下/非活动/未就绪（0）。
The N (New) bit indicates whether the circuit status indication is for a new circuit (1) or an existing circuit (0). Links that have a similar mechanism available (e.g., Frame Relay) MUST map the setting of this bit to the associated signaling for that link. Otherwise, the New bit SHOULD still be set the first time the L2TP session is established after provisioning.
N（新）位表示电路状态指示是针对新电路（1）还是针对现有电路（0）。具有类似可用机制（例如，帧中继）的链路必须将该位的设置映射到该链路的相关信令。否则，在设置后第一次建立L2TP会话时，仍应设置新位。
The remaining bits are reserved for future use. Reserved bits MUST be set to 0 when sending and ignored upon receipt.
其余的位保留供将来使用。发送时保留位必须设置为0，接收时忽略。
The Circuit Status AVP is used to advertise whether a circuit or interface bound to an L2TP session is up and ready to send and/or receive traffic. Different circuit types have different names for status types. For example, HDLC primary and secondary stations refer to a circuit as being "Receive Ready" or "Receive Not Ready", while Frame Relay refers to a circuit as "Active" or "Inactive". This AVP adopts the latter terminology, though the concept remains the same regardless of the PW type for the L2TP session.
电路状态AVP用于通告绑定到L2TP会话的电路或接口是否已启动并准备好发送和/或接收通信量。不同的回路类型具有不同的状态类型名称。例如，HDLC主站和副站将电路称为“接收就绪”或“接收未就绪”，而帧中继将电路称为“活动”或“非活动”。该AVP采用后一种术语，尽管无论L2TP会话的PW类型如何，概念都保持不变。
In the simplest case, the circuit to which this AVP refers is a single physical interface, port, or circuit, depending on the application and the session setup. The status indication in this AVP may then be used to provide simple ILMI interworking for a variety of circuit types. For virtual or multipoint interfaces, the Circuit Status AVP is still utilized, but in this case, it refers to the state of an internal structure or a logical set of circuits. Each PW-specific companion document MUST specify precisely how this AVP is translated for each circuit type.
在最简单的情况下，此AVP所指的电路是单个物理接口、端口或电路，具体取决于应用程序和会话设置。该AVP中的状态指示可用于为各种电路类型提供简单的ILMI互通。对于虚拟或多点接口，仍然使用电路状态AVP，但在这种情况下，它指的是内部结构或电路逻辑集的状态。每个特定于PW的配套文件必须明确说明如何针对每种电路类型翻译此AVP。
If this AVP is received with a Not Active notification for a given L2TP session, all data traffic for that session MUST cease (or not begin) in the direction of the sender of the Circuit Status AVP until the circuit is advertised as Active.
如果接收到该AVP时，给出L2TP会话的非活动通知，则该会话的所有数据通信必须在电路状态AVP发送方的方向上停止（或不开始），直到电路被公告为活动。
The Circuit Status MUST be advertised by this AVP in ICRQ, ICRP, OCRQ, and OCRP messages. Often, the circuit type will be marked Active when initiated, but subsequently MAY be advertised as Inactive. This indicates that an L2TP session is to be created, but that the interface or circuit is still not ready to pass traffic. The ICCN, OCCN, and SLI control messages all MAY contain this AVP to update the status of the circuit after establishment of the L2TP session is requested.
此AVP必须在ICRQ、ICRP、OCRQ和OCRP消息中公布电路状态。通常，电路类型在启动时会被标记为激活，但随后可能会被公告为非激活。这表示将创建L2TP会话，但接口或电路仍未准备好传递流量。ICCN、OCCN和SLI控制消息都可以包含该AVP，以在请求建立L2TP会话后更新电路的状态。
If additional circuit status information is needed for a given PW type, any new PW-specific AVPs MUST be defined in a separate document. This AVP is only for general circuit status information generally applicable to all circuit/interface types.
如果给定PW类型需要额外的电路状态信息，则必须在单独的文件中定义任何新的PW特定AVP。本AVP仅适用于一般适用于所有电路/接口类型的一般电路状态信息。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 1, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 8.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为1，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为8。
Circuit Errors (WEN)
电路错误（WEN）
The Circuit Errors AVP, Attribute Type 34, conveys circuit error information to the peer.
属性类型34的电路错误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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Overruns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alignment Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined:
定义了以下字段：
Reserved: 2 octets of Reserved data is present (providing longword alignment within the AVP of the following values). Reserved data MUST be zero on sending and ignored upon receipt. Hardware Overruns: Number of receive buffer overruns since call was established. Buffer Overruns: Number of buffer overruns detected since call was established. Timeout Errors: Number of timeouts since call was established. Alignment Errors: Number of alignment errors since call was established.
保留：存在2个八位字节的保留数据（在AVP中提供以下值的长字对齐）。保留数据在发送时必须为零，在接收时必须忽略。硬件溢出：自呼叫建立以来接收缓冲区溢出的数量。缓冲区溢出：自建立调用以来检测到的缓冲区溢出数。超时错误：自建立调用后超时的次数。对齐错误：自建立调用以来的对齐错误数。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0, but MAY vary (see Section 5.2). The Length (before hiding) of this AVP is 32.
该AVP可能被隐藏（H位可能为0或1）。此AVP的M位应设置为0，但可能有所不同（见第5.2节）。此AVP的长度（隐藏前）为32。
The following control messages are used to establish, maintain, and tear down L2TP control connections. All data packets are 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值发送，以允许协议扩展。
The exchanges in which these messages are involved are outlined in Section 3.3.
第3.3节概述了涉及这些信息的交换。
Start-Control-Connection-Request (SCCRQ) is a control message used to initiate a control connection between two LCCEs. It is sent by either the LAC or the LNS to begin the control connection establishment process.
启动控制连接请求（SCCRQ）是用于在两个LCCE之间启动控制连接的控制消息。它由LAC或LNS发送，以开始控制连接建立过程。
The following AVPs MUST be present in the SCCRQ:
以下AVP必须存在于SCCRQ中：
Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List
消息类型主机名路由器ID分配的控制连接ID伪线功能列表
The following AVPs MAY be present in the SCCRQ:
SCCRQ中可能存在以下AVP：
Random Vector Control Message Authentication Nonce Message Digest Control Connection Tie Breaker Vendor Name Receive Window Size Preferred Language
随机向量控制消息身份验证Nonce消息摘要控制连接断开器供应商名称接收窗口大小首选语言
Start-Control-Connection-Reply (SCCRP) is the control message sent in reply to a received SCCRQ message. The SCCRP is used to indicate that the SCCRQ was accepted and that establishment of the control connection should continue.
启动控制连接回复（SCCRP）是为回复收到的SCCRQ消息而发送的控制消息。SCCRP用于表明SCCRQ已被接受，并且应继续建立控制连接。
The following AVPs MUST be present in the SCCRP:
SCCRP中必须存在以下AVP：
Message Type Host Name Router ID Assigned Control Connection ID Pseudowire Capabilities List
消息类型主机名路由器ID分配的控制连接ID伪线功能列表
The following AVPs MAY be present in the SCCRP:
SCCRP中可能存在以下AVP：
Random Vector Control Message Authentication Nonce Message Digest Vendor Name Receive Window Size Preferred Language
随机向量控制消息身份验证Nonce消息摘要供应商名称接收窗口大小首选语言
Start-Control-Connection-Connected (SCCCN) is the control message sent in reply to an SCCRP. The SCCCN completes the control connection establishment process.
Start Control Connection Connected（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：
Random Vector Message Digest
随机向量消息摘要
Stop-Control-Connection-Notification (StopCCN) is the control message sent by either LCCE to inform its peer that the control connection is being shut down and that the control connection should be closed. In addition, all active sessions are implicitly cleared (without sending any explicit session 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 delivery layer.
停止控制连接通知（StopCCN）是由任一LCCE发送的控制消息，用于通知其对等方控制连接正在关闭且控制连接应关闭。此外，隐式清除所有活动会话（不发送任何显式会话控制消息）。发出此请求的原因在结果代码AVP中指明。没有对消息的显式回复，只有可靠控制消息传递层接收的隐式ACK。
The following AVPs MUST be present in the StopCCN:
StopCCN中必须存在以下AVP：
Message Type Result Code
消息类型结果代码
The following AVPs MAY be present in the StopCCN:
StopCCN中可能存在以下AVP：
Random Vector Message Digest Assigned Control Connection ID
随机向量消息摘要分配的控制连接ID
Note that the Assigned Control Connection ID MUST be present if the StopCCN is sent after an SCCRQ or SCCRP message has been sent.
请注意，如果在发送SCCRQ或SCCRP消息后发送StopCCN，则必须存在分配的控制连接ID。
The Hello (HELLO) message is an L2TP control message sent by either peer of a control connection. This control message is used as a "keepalive" for the control connection. See Section 4.2 for a description of the keepalive mechanism.
Hello（Hello）消息是由控制连接的任一对等方发送的L2TP控制消息。此控制消息用作控制连接的“keepalive”。有关keepalive机制的说明，请参见第4.2节。
HELLO messages are global to the control connection. The Session ID in a HELLO message MUST be 0.
HELLO消息对于控制连接是全局的。HELLO消息中的会话ID必须为0。
The following AVP MUST be present in the HELLO:
以下AVP必须出现在HELLO中：
Message Type
消息类型
The following AVP MAY be present in the HELLO:
以下AVP可能出现在HELLO中：
Random Vector Message Digest
随机向量消息摘要
Incoming-Call-Request (ICRQ) is the control message sent by an LCCE to a peer when an incoming call is detected (although the ICRQ may also be sent as a result of a local event). It is the first in a three-message exchange used for establishing a session via an L2TP control connection.
传入呼叫请求（ICRQ）是LCCE在检测到传入呼叫时向对等方发送的控制消息（尽管ICRQ也可能因本地事件而发送）。它是用于通过L2TP控制连接建立会话的三条消息交换中的第一条。
The ICRQ is used to indicate that a session is to be established between an LCCE and a peer. The sender of an ICRQ provides the peer with parameter information for the session. However, the sender makes no demands about how the session is terminated at the peer (i.e., whether the L2 traffic is processed locally, forwarded, etc.).
ICRQ用于指示将在LCCE和对等方之间建立会话。ICRQ的发送方向对等方提供会话的参数信息。但是，发送方不要求如何在对等方终止会话（即，L2通信是否在本地处理、转发等）。
The following AVPs MUST be present in the ICRQ:
ICRQ中必须有以下AVP：
Message Type Local Session ID Remote Session ID Serial Number Pseudowire Type Remote End ID Circuit Status
消息类型本地会话ID远程会话ID序列号伪线类型远程端ID电路状态
The following AVPs MAY be present in the ICRQ:
ICRQ中可能存在以下AVP：
Random Vector Message Digest Assigned Cookie Session Tie Breaker L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Physical Channel ID
随机向量消息摘要分配的Cookie会话连接断路器L2特定子层数据排序Tx连接速度Rx连接速度物理通道ID
Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in response to a received ICRQ. It is the second in the three-message exchange used for establishing sessions within an L2TP control connection.
传入呼叫应答（ICRP）是LCCE为响应接收到的ICRQ而发送的控制消息。它是用于在L2TP控制连接中建立会话的三个消息交换中的第二个。
The ICRP is used to indicate that the ICRQ was successful and that the peer should establish (i.e., answer) the incoming call if it has not already done so. It also allows the sender to indicate specific parameters about the L2TP session.
ICRP用于表明ICRQ成功，并且对等方应建立（即应答）传入呼叫（如果尚未建立）。它还允许发送方指示L2TP会话的特定参数。
The following AVPs MUST be present in the ICRP:
ICRP中必须有以下AVP：
Message Type Local Session ID Remote Session ID Circuit Status
消息类型本地会话ID远程会话ID电路状态
The following AVPs MAY be present in the ICRP:
ICRP中可能存在以下AVP：
Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Physical Channel ID
随机向量消息摘要指定Cookie L2特定子层数据排序Tx连接速度Rx连接速度物理通道ID
Incoming-Call-Connected (ICCN) is the control message sent by the LCCE that originally sent an ICRQ upon receiving an ICRP from its peer. It is the final message in the three-message exchange used for establishing L2TP sessions.
已连接的传入呼叫（ICCN）是LCCE发送的控制消息，该LCCE最初在从其对等方接收ICRP时发送ICRQ。它是用于建立L2TP会话的三条消息交换中的最后一条消息。
The ICCN is used to indicate that the ICRP was accepted, that the call has been established, and that the L2TP session should move to the established state. It also allows the sender to indicate specific parameters about the established call (parameters that may not have been available at the time the ICRQ was issued).
ICCN用于表示ICRP已被接受，呼叫已建立，L2TP会话应移到已建立状态。它还允许发送方指示有关已建立呼叫的特定参数（在发出ICRQ时可能不可用的参数）。
The following AVPs MUST be present in the ICCN:
以下AVP必须存在于ICCN中：
Message Type Local Session ID Remote Session ID
消息类型本地会话ID远程会话ID
The following AVPs MAY be present in the ICCN:
以下AVP可能存在于ICCN中：
Random Vector Message Digest L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Circuit Status
随机向量消息摘要L2特定子层数据排序Tx连接速度Rx连接速度电路状态
Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE to an LAC to indicate that an outbound call at the LAC is to be established based on specific destination information sent in this message. It is the first in a three-message exchange used for establishing a session and placing a call on behalf of the initiating LCCE.
传出呼叫请求（OCRQ）是LCCE向LAC发送的控制消息，用于指示将基于该消息中发送的特定目的地信息在LAC建立出站呼叫。它是三条消息交换中的第一条，用于建立会话并代表发起LCCE进行呼叫。
Note that a call may be any L2 connection requiring well-known destination information to be sent from an LCCE to an LAC. This call could be a dialup connection to the PSTN, an SVC connection, the IP address of another LCCE, or any other destination dictated by the sender of this message.
注意，呼叫可以是要求从LCCE向LAC发送已知目的地信息的任何L2连接。此呼叫可以是到PSTN的拨号连接、SVC连接、另一个LCCE的IP地址或此消息的发件人指定的任何其他目的地。
The following AVPs MUST be present in the OCRQ:
OCRQ中必须存在以下AVP：
Message Type Local Session ID Remote Session ID Serial Number Pseudowire Type Remote End ID Circuit Status
消息类型本地会话ID远程会话ID序列号伪线类型远程端ID电路状态
The following AVPs MAY be present in the OCRQ:
OCRQ中可能存在以下AVP：
Random Vector Message Digest Assigned Cookie Tx Connect Speed Rx Connect Speed Session Tie Breaker L2-Specific Sublayer Data Sequencing
随机向量消息摘要分配Cookie Tx连接速度Rx连接速度会话连接断路器L2特定子层数据排序
Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to an LCCE in response to a received OCRQ. It is the second in a three-message exchange used for establishing a session within an L2TP control connection.
传出呼叫应答（OCRP）是LAC向LCCE发送的控制消息，以响应接收到的OCRQ。它是用于在L2TP控制连接中建立会话的三条消息交换中的第二条。
OCRP is used to indicate that the LAC has been able to attempt the outbound call. The message returns any relevant parameters regarding the call attempt. Data MUST NOT be forwarded until the OCCN is received, which indicates that the call has been placed.
OCRP用于指示LAC已经能够尝试出站呼叫。该消息返回有关呼叫尝试的任何相关参数。在收到OCCN之前，不得转发数据，因为OCCN表示呼叫已发出。
The following AVPs MUST be present in the OCRP:
OCRP中必须存在以下AVP：
Message Type Local Session ID Remote Session ID Circuit Status
消息类型本地会话ID远程会话ID电路状态
The following AVPs MAY be present in the OCRP:
OCRP中可能存在以下AVP：
Random Vector Message Digest Assigned Cookie L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Physical Channel ID
随机向量消息摘要指定Cookie L2特定子层Tx连接速度Rx连接速度数据排序物理通道ID
Outgoing-Call-Connected (OCCN) is the control message sent by an LAC to another LCCE after 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.
已连接的传出呼叫（OCCN）是在OCRP和传出呼叫完成后，LAC向另一个LCCE发送的控制消息。它是用于建立会话的三条消息交换中的最后一条消息。
OCCN is used to indicate that the result of a requested outgoing call was successful. It also provides information to the LCCE who requested the call about the particular parameters obtained after the call was established.
OCCN用于表示请求的传出呼叫的结果是成功的。它还向请求呼叫的LCCE提供有关呼叫建立后获得的特定参数的信息。
The following AVPs MUST be present in the OCCN:
以下AVP必须出现在OCCN中：
Message Type Local Session ID Remote Session ID
消息类型本地会话ID远程会话ID
The following AVPs MAY be present in the OCCN:
OCCN中可能存在以下AVP：
Random Vector Message Digest L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Circuit Status
随机向量消息摘要L2特定子层Tx连接速度Rx连接速度数据排序电路状态
The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE to request disconnection of a specific session. Its purpose is to inform the peer of the disconnection and the reason for the disconnection. The peer MUST clean up any resources, and does not send back any indication of success or failure for such cleanup.
呼叫断开通知（CDN）是LCCE发送的控制消息，用于请求断开特定会话。其目的是通知对等方断开连接以及断开原因。对等方必须清理任何资源，并且不会返回此类清理成功或失败的任何指示。
The following AVPs MUST be present in the CDN:
CDN中必须存在以下AVP：
Message Type Result Code Local Session ID Remote Session ID
消息类型结果代码本地会话ID远程会话ID
The following AVP MAY be present in the CDN:
CDN中可能存在以下AVP：
Random Vector Message Digest
随机向量消息摘要
The WAN-Error-Notify (WEN) is a control message sent from an LAC to an LNS to indicate WAN error conditions. 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错误通知（WEN）是从LAC发送到LNS的控制消息，用于指示WAN错误情况。此消息中的计数器是累积的。仅当发生错误时才应发送此消息，且每60秒发送一次。当建立新呼叫时，计数器被重置。
The following AVPs MUST be present in the WEN:
以下AVP必须出现在WEN中：
Message Type Local Session ID Remote Session ID Circuit Errors
消息类型本地会话ID远程会话ID电路错误
The following AVP MAY be present in the WEN:
以下AVP可能出现在WEN中：
Random Vector Message Digest
随机向量消息摘要
The Set-Link-Info control message is sent by an LCCE to convey link or circuit status change information regarding the circuit associated with this L2TP session. For example, if PPP renegotiates LCP at an LNS or between an LAC and a Remote System, or if a forwarded Frame Relay VC transitions to Active or Inactive at an LAC, an SLI message SHOULD be sent to indicate this event. Precise details of when the SLI is sent, what PW type-specific AVPs must be present, and how those AVPs should be interpreted by the receiving peer are outside the scope of this document. These details should be described in the associated pseudowire-specific documents that require use of this message.
设置链路信息控制消息由LCCE发送，以传达与此L2TP会话相关的电路的链路或电路状态更改信息。例如，如果PPP在LNS或LAC与远程系统之间重新协商LCP，或者如果转发帧中继VC在LAC转换为活动或非活动，则应发送SLI消息以指示此事件。发送SLI的时间、必须提供哪些PW类型特定AVP以及接收对等方应如何解释这些AVP的准确细节不在本文件范围内。这些详细信息应在需要使用此消息的相关伪线特定文档中描述。
The following AVPs MUST be present in the SLI:
SLI中必须存在以下AVP：
Message Type Local Session ID Remote Session ID
消息类型本地会话ID远程会话ID
The following AVPs MAY be present in the SLI:
SLI中可能存在以下AVP：
Random Vector Message Digest Circuit Status
随机向量消息摘要电路状态
The Explicit Acknowledgement (ACK) message is used only to acknowledge receipt of a message or messages on the control connection (e.g., for purposes of updating Ns and Nr values). Receipt of this message does not trigger an event for the L2TP protocol state machine.
显式确认（ACK）消息仅用于确认收到控制连接上的一条或多条消息（例如，为了更新Ns和Nr值）。收到此消息不会触发L2TP协议状态机的事件。
A message received without any AVPs (including the Message Type AVP), is referred to as a Zero Length Body (ZLB) message, and serves the same function as the Explicit Acknowledgement. ZLB messages are only permitted when Control Message Authentication defined in Section 4.3 is not enabled.
在没有任何AVP（包括消息类型AVP）的情况下接收的消息称为零长度正文（ZLB）消息，其功能与显式确认相同。仅当未启用第4.3节中定义的控制消息身份验证时，才允许使用ZLB消息。
The following AVPs MAY be present in the ACK message:
ACK消息中可能存在以下AVP：
Message Type Message Digest
消息类型消息摘要
The state tables defined in this section govern the exchange of control messages defined in Section 6. Tables are defined for incoming call placement and outgoing call placement, as well as for initiation of the control connection itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying reliable control message delivery mechanism (see Section 4.2).
本节中定义的状态表控制第6节中定义的控制消息的交换。表是为传入呼叫放置和传出呼叫放置以及控制连接本身的启动而定义的。状态表不编码超时和重传行为，因为这是在底层可靠控制消息传递机制中处理的（参见第4.2节）。
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 (1) a message that contains a Message Type marked as mandatory (see Section 5.4.1) but that is unknown to the implementation, or (2) a control message that is received in the wrong state.
无效控制消息定义为（1）包含标记为强制的消息类型（见第5.4.1节）但实施未知的消息，或（2）在错误状态下接收的控制消息。
Examples of malformed control messages include (1) a message that has an invalid value in its header, (2) a message that contains an AVP that is formatted incorrectly or whose value is out of range, and (3) a message that is missing a required AVP. A control message with a malformed header MUST be discarded.
格式错误的控制消息示例包括：（1）消息头中的值无效；（2）包含格式错误或值超出范围的AVP的消息；（3）缺少所需AVP的消息。必须丢弃标题格式不正确的控制消息。
When possible, a malformed AVP should be treated as an unrecognized AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD be made to determine the importance of the malformed AVP, and thus, the severity of the malformation to the entire control message. If the M bit can be reasonably inspected within the malformed AVP and is determined to be set, then as with an unrecognized AVP, the associated session or control connection MUST be shut down. If the M bit is inspected and is found to be 0, the AVP MUST be ignored (assuming recovery from the AVP malformation is indeed possible).
如果可能，应将畸形AVP视为未识别的AVP（见第5.2节）。因此，应尝试检查M位，以确定畸形AVP的重要性，从而确定畸形对整个控制信息的严重程度。如果可以在格式错误的AVP中合理地检查M位并确定要设置，则与未识别的AVP一样，必须关闭相关的会话或控制连接。如果检查M位发现为0，则必须忽略AVP（假设AVP畸形确实可以恢复）。
This policy must not be considered as a license to send malformed AVPs, but rather, as 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. One example of a malformed AVP situation that should be recoverable
此策略不得被视为发送格式错误的AVP的许可证，而是在收到格式错误的消息时如何处理的指南。不可能列出给定消息的所有潜在畸形，并为每个畸形提供建议。应可恢复的畸形AVP情况的一个示例
is if the Rx Connect Speed AVP is received with a length of 10 rather than 14, implying that the connect speed bits-per-second is being formatted in 4 octets rather than 8. If the AVP does not have its M bit set (as would typically be the case), this condition is not considered catastrophic. As such, the control message should be accepted as though the AVP were not present (though a local error message may be logged).
如果接收到长度为10而不是14的Rx连接速度AVP，则表示每秒连接速度位的格式为4个八位字节，而不是8个八位字节。如果AVP未设置其M位（通常情况下），则不认为这种情况是灾难性的。因此，应接受控制消息，如同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 control connection destruction, the reliable delivery mechanism must be allowed to run (see Section 4.2) before destroying the control connection. This permits the control connection management messages to be reliably delivered to the peer.
在下表中的几种情况下，发送协议消息，然后进行“清理”。注意，无论控制连接破坏的发起人是谁，在破坏控制连接之前，必须允许可靠的传递机制运行（见第4.2节）。这允许将控制连接管理消息可靠地传递给对等方。
Appendix B.1 contains an example of lock-step control connection establishment.
附录B.1包含一个锁步控制连接建立的示例。
The L2TP control connection protocol is not distinguishable between the two LCCEs but is distinguishable between the originator and receiver. The originating peer is the one that first initiates establishment of the control connection. (In a tie breaker situation, this is the winner of the tie.) Since either the LAC or the LNS can be the originator, a collision can occur. See the Control Connection Tie Breaker AVP in Section 5.4.3 for a description of this and its resolution.
L2TP控制连接协议在两个LCCE之间不可区分，但在发起方和接收方之间可区分。发起对等方是首先发起建立控制连接的对等方。（在平局破坏情况下，这是平局的赢家。）由于LAC或LN可以是发起人，因此可能发生碰撞。参见第5.4.3节中的控制连接接头断路器AVP，了解其说明及其解决方案。
State Event Action New State
----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply
request
State Event Action New State
----- ----- ------ ---------
idle Local open Send SCCRQ wait-ctl-reply
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 Send StopCCN, idle clean up
空闲接收SCCCN发送停止CCN，空闲清理
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable send control-conn 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, Send SCCRP, wait-ctl-conn lose tie breaker, Clean up losing SCCRQ acceptable connection
等待ctl回复接收SCCRQ，发送SCCRP，等待ctl连接断开，清理断开的SCCRQ可接受连接
wait-ctl-reply Receive SCCRQ, Send StopCCN, idle lose tie breaker, Clean up losing SCCRQ unacceptable connection
等待ctl回复接收SCCRQ，发送StopCCN，空闲丢失连接断路器，清除丢失的SCCRQ不可接受连接
wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply win tie breaker losing connection
等待ctl回复接收SCCRQ，发送StopCCN以等待ctl回复win tie breaker断开连接
wait-ctl-reply Receive SCCCN Send StopCCN, idle clean up
等待控制应答接收SCCCN发送StopCCN，空闲清理
wait-ctl-conn Receive SCCCN, Send control-conn established acceptable open event to waiting sessions
等待ctl conn接收SCCCN，将控制conn建立的可接受打开事件发送到等待会话
wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable clean up
等待ctl conn接收SCCCN，发送StopCCN，空闲不可接受清理
wait-ctl-conn Receive SCCRQ, Send StopCCN, idle SCCRP clean up
等待ctl conn接收SCCRQ，发送StopCCN，空闲SCCRP清除
established Local open Send control-conn established request open event to (new call) waiting sessions
已建立本地打开发送控制连接已建立请求打开事件到（新呼叫）等待会话
established Administrative Send StopCCN, idle control-conn clean up close event
已建立管理发送停止CCN、空闲控制连接清理关闭事件
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 an LCCE for control connection establishment are as follows:
与LCCE相关的控制连接建立状态如下：
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.4.3.
wait ctl reply发起人检查是否已从同一对等方请求另一个连接，如果是，则处理第5.4.3节中描述的冲突情况。
wait-ctl-conn Awaiting an SCCCN. If the SCCCN is valid, the control connection is established; otherwise, it is torn down (sending a StopCCN with the proper result and/or error code).
等待ctl conn等待SCCCN。如果SCCCN有效，则建立控制连接；否则，它将被拆除（发送带有正确结果和/或错误代码的StopCCN）。
established An established connection may be terminated by either a local condition or the receipt of a StopCCN. In the event of a local termination, the originator MUST send a StopCCN and clean up the control connection. If the originator receives a StopCCN, it MUST also clean up the control connection.
已建立的连接可以通过本地条件或接收StopCCN来终止。在本地终止的情况下，发端人必须发送StopCCN并清理控制连接。如果发端人收到StopCCN，它还必须清理控制连接。
An ICRQ is generated by an LCCE, typically in response to an incoming call or a local event. Once the LCCE sends the ICRQ, it waits for a response from the peer. However, it may choose to postpone establishment of the call (e.g., answering the call, bringing up the circuit) until the peer has indicated with an ICRP that it will accept the call. The peer may choose not to accept the call if, for instance, there are insufficient resources to handle an additional session.
ICRQ由LCCE生成，通常用于响应传入呼叫或本地事件。LCCE发送ICRQ后，将等待对等方的响应。但是，它可以选择推迟建立呼叫（例如，接听呼叫、接通电路），直到对等方向ICRP表示它将接受呼叫。例如，如果没有足够的资源来处理额外的会话，对等方可以选择不接受呼叫。
If the peer chooses to accept the call, it responds with an ICRP. When the local LCCE receives the ICRP, it attempts to establish the call. A final call connected message, the ICCN, is sent from the local LCCE to the peer to indicate that the call states for both LCCEs should enter the established state. If the call is terminated before the peer can accept it, a CDN is sent by the local LCCE to indicate this condition.
如果对等方选择接受呼叫，它将使用ICRP进行响应。当本地LCCE收到ICRP时，它会尝试建立呼叫。最后一条连接呼叫的消息ICCN从本地LCCE发送到对等方，以指示两个LCCE的呼叫状态应进入已建立状态。如果呼叫在对等方可以接受之前终止，则本地LCCE将发送CDN以指示此情况。
When a call transitions to a "disconnected" or "down" state, the call is cleared normally, and the local LCCE sends a CDN. Similarly, if the peer wishes to clear a call, it sends a CDN and cleans up its session.
当呼叫转换到“断开连接”或“关闭”状态时，呼叫正常清除，本地LCCE发送CDN。类似地，如果对等方希望清除呼叫，它将发送CDN并清除其会话。
State Event Action New State
----- ----- ------ ---------
State Event Action New State
----- ----- ------ ---------
idle Call signal or Initiate local wait-control-conn ready to receive control-conn incoming conn open
空闲呼叫信号或启动本地等待控制连接准备接收控制连接输入连接打开
idle Receive ICCN, Clean up idle ICRP, CDN
空闲接收ICCN，清除空闲ICRP，CDN
wait-control- Bearer line drop Clean up idle conn or local close request
等待控制-承载线路下降清理空闲连接或本地关闭请求
wait-control- control-conn-open Send ICRQ wait-reply conn
等待控制-控制连接打开发送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, Process as idle lose tie breaker ICRQ Recipient (Section 7.3.2)
等待回复接收ICRQ，作为空闲失去联络断路器ICRQ接收者处理（第7.3.2节）
wait-reply Receive ICRQ, Send CDN wait-reply win tie breaker for losing session
等待回复接收ICRQ，发送CDN等待回复赢平局断路器以断开会话
wait-reply Receive CDN, Clean up idle ICCN
等待应答接收CDN，清除空闲ICCN
wait-reply Local close Send CDN, idle request clean up
等待应答本地关闭发送CDN，空闲请求清理
established Receive CDN Clean up idle
已建立接收CDN清除空闲
established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up
已建立接收ICRQ、发送CDN、空闲ICRP、ICCN清理
established Local close Send CDN, idle request clean up
已建立本地关闭发送CDN，空闲请求清理
The states associated with the ICRQ sender are as follows:
与ICRQ发送方相关的状态如下：
idle The LCCE detects an incoming call on one of its interfaces (e.g., an analog PSTN line rings, or an ATM PVC is provisioned), or a local event occurs. The LCCE initiates its control connection establishment state machine and moves to a state waiting for confirmation of the existence of a control connection.
空闲LCCE在其一个接口上检测到传入呼叫（例如，模拟PSTN线路环，或提供ATM PVC），或发生本地事件。LCCE启动其控制连接建立状态机，并移动到等待确认控制连接存在的状态。
wait-control-conn In this state, the session is waiting for either the control connection to be opened or for verification that the control connection is already open. Once an indication that the control connection has been opened is received, session control messages may be exchanged. The first of these messages is the ICRQ.
等待控制连接在此状态下，会话正在等待打开控制连接或验证控制连接是否已打开。一旦接收到控制连接已打开的指示，就可以交换会话控制消息。这些信息中的第一条是ICRQ。
wait-reply The ICRQ sender receives either (1) a CDN indicating the peer is not willing to accept the call (general error or do not accept) and moves back into the idle state, or (2) an ICRP indicating the call is accepted. In the latter case, the LCCE sends an ICCN and enters the established state.
等待回复ICRQ发送方收到（1）表示对等方不愿意接受呼叫的CDN（一般错误或不接受）并返回空闲状态，或（2）表示接受呼叫的ICRP。在后一种情况下，LCCE发送ICCN并进入已建立状态。
established Data is exchanged over the session. The call may be cleared by any of the following: + An event on the connected interface: The LCCE sends a CDN. + Receipt of a CDN: The LCCE cleans up, disconnecting the call. + A local reason: The LCCE sends a CDN.
已建立的数据在会话中交换。该调用可通过以下任一方式清除：+连接接口上的事件：LCCE发送CDN。+接收CDN：LCCE清理，断开呼叫连接。+本地原因：LCCE发送CDN。
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 close Send CDN, idle established request clean up
等待连接本地关闭发送CDN，空闲已建立请求清理
established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up
已建立接收ICRQ、发送CDN、空闲ICRP、ICCN清理
The states associated with the ICRQ recipient are as follows:
与ICRQ接受者有关的国家如下：
idle An ICRQ is received. If the request is not acceptable, a CDN is sent back to the peer LCCE, and the local LCCE remains in the idle state. If the ICRQ is acceptable, an ICRP is sent. The session moves to the wait-connect state.
接收到ICRQ。如果请求不可接受，则将CDN发送回对等LCCE，并且本地LCCE保持空闲状态。如果ICRQ可接受，则发送ICRP。会话移动到等待连接状态。
wait-connect The local LCCE is waiting for an ICCN from the peer. Upon receipt of the ICCN, the local LCCE moves to established state.
等待连接本地LCCE正在等待来自对等方的ICCN。收到ICCN后，本地LCCE将进入已建立状态。
established The session is terminated either by sending a CDN or by receiving a CDN from the peer. Clean up follows on both sides regardless of the initiator.
通过发送CDN或从对等方接收CDN来终止会话。无论是哪种启动器，两侧都会进行清理。
Outgoing calls instruct an LAC to place a call. There are three messages for outgoing calls: OCRQ, OCRP, and OCCN. An LCCE first sends an OCRQ to an LAC to request an outgoing call. The LAC MUST respond to the OCRQ with an OCRP once it determines that the proper facilities exist to place the call and that the call is administratively authorized. Once the outbound call is connected, the LAC sends an OCCN to the peer indicating the final result of the call attempt.
传出呼叫指示LAC拨打电话。传出呼叫有三条消息：OCRQ、OCRP和OCCN。LCCE首先向LAC发送OCRQ以请求传出呼叫。一旦拉丁美洲和加勒比海地区委员会确定有适当的设施进行呼叫，并且呼叫已获得行政授权，则必须使用OCRP对OCRQ作出响应。连接出站呼叫后，LAC向对等方发送OCCN，指示呼叫尝试的最终结果。
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
State Event Action New State
----- ----- ------ ---------
idle Local open Initiate local wait-control-conn
request control-conn-open
idle Receive OCCN, Clean up idle OCRP
空闲接收OCCN，清除空闲OCRP
wait-control- control-conn-open Send OCRQ wait-reply conn
等待控制-控制连接打开发送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 clean up
等待回复接收OCCN发送CDN，空闲清理
wait-reply Receive OCRQ, Process as idle lose tie breaker OCRQ Recipient (Section 7.4.2)
等待回复接收OCRQ，作为空闲失去联络断路器OCRQ接收者处理（第7.4.2节）
wait-reply Receive OCRQ, Send CDN wait-reply win tie breaker for losing session
等待回复接收OCRQ，发送CDN等待回复赢取失败会话的平局断路器
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 close Send CDN, idle wait-connect, request clean up established
等待应答，本地关闭发送CDN，空闲等待连接，请求清除已建立
wait-control- Local close Clean up idle conn request
等待控制-本地关闭清理空闲连接请求
The states associated with the OCRQ sender are as follows:
与OCRQ发送器关联的状态如下：
idle, wait-control-conn When an outgoing call request is initiated, a control connection is created as described above, if not already present. Once the control connection is established, an OCRQ is sent to the LAC, and the session moves into the wait-reply state.
空闲，等待控制连接当发出呼叫请求时，如果尚未建立控制连接，则如上所述创建控制连接。一旦建立了控制连接，OCRQ将被发送到LAC，会话将进入等待-应答状态。
wait-reply If a CDN is received, the session is cleaned up and returns to idle state. If an OCRP is received, the call is in progress, and the session moves to the wait-connect state.
等待答复如果收到CDN，会话将被清除并返回空闲状态。如果收到OCRP，则呼叫正在进行，会话将移至等待连接状态。
wait-connect If a CDN is received, the session is cleaned up and returns to idle state. If an OCCN is received, the call has succeeded, and the session may now exchange data.
等待连接如果接收到CDN，会话将被清除并返回空闲状态。如果收到OCCN，则呼叫成功，会话现在可以交换数据。
established If a CDN is received, the session is cleaned up and returns to idle state. Alternatively, if the LCCE chooses to terminate the session, it sends a CDN to the LAC, cleans up the session, and moves the session to idle state.
如果接收到CDN，会话将被清除并返回空闲状态。或者，如果LCCE选择终止会话，它将向LAC发送CDN，清理会话，并将会话移动到空闲状态。
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
State Event Action New State
----- ----- ------ ---------
idle Receive OCRQ, Send OCRP, wait-cs-answer
acceptable Place call
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 Call placement Send OCCN established successful
等待cs应答呼叫放置发送OCCN成功建立
wait-cs-answer Call placement Send CDN, idle failed 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清除空闲建立
wait-cs-answer, Local close Send CDN, idle established request clean up
等待cs应答，本地关闭发送CDN，空闲建立请求清理
The states associated with the LAC for outgoing calls are as follows:
与LAC有关的拨出电话状态如下：
idle If the OCRQ is received in error, respond with a CDN. Otherwise, place the call, send an OCRP, and move to the wait-cs-answer state.
空闲如果OCRQ接收错误，请使用CDN响应。否则，拨打电话，发送OCRP，并进入等待cs应答状态。
wait-cs-answer If the call is not completed or a timer expires while waiting for the call to complete, send a CDN with the appropriate error condition set, and go to idle state. If a circuit-switched connection is established, send an OCCN indicating success, and go to established state.
wait cs answer如果在等待呼叫完成时呼叫未完成或计时器过期，则发送设置了相应错误条件的CDN，然后进入空闲状态。如果建立了电路交换连接，则发送OCCN指示成功，并进入已建立状态。
established If the LAC receives a CDN from the peer, the call MUST be released via appropriate mechanisms, and the session cleaned up. If the call is disconnected because the circuit transitions to a "disconnected" or "down" state, the LAC MUST send a CDN to the peer and return to idle state.
如果LAC从对等方接收到CDN，则必须通过适当的机制释放呼叫，并清理会话。如果由于电路转换到“断开”或“关闭”状态而导致呼叫断开，LAC必须向对等方发送CDN并返回空闲状态。
The termination of a control connection consists of either peer issuing a StopCCN. The sender of this message SHOULD wait a full control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ... seconds) for the acknowledgment of this message before releasing the control information associated with the control connection. The recipient of this message should send an acknowledgment of the message to the peer, then release the associated control information.
控制连接的终止包括任一对等方发出StopCCN。在释放与控制连接相关的控制信息之前，此消息的发送方应等待一个完整的控制消息重传周期（例如，1+2+4+8…秒）以确认此消息。此消息的收件人应向对等方发送消息确认，然后释放相关的控制信息。
When to release a control connection 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 control connection open for a period of time or perhaps indefinitely after
何时释放控制连接是一个实现问题，本文档中未指定。特定的实现可以使用任何适当的策略来确定何时释放控制连接。一些实现可能会在一段时间内或之后无限期地保持控件连接打开
the last session for that control connection is cleared. Others may choose to disconnect the control connection immediately after the last call on the control connection disconnects.
该控制连接的最后一个会话被清除。其他人可能会选择在控制连接的最后一次调用断开后立即断开控制连接。
This section addresses some of the security issues that L2TP encounters in its operation.
本节介绍L2TP在运行中遇到的一些安全问题。
If a shared secret (password) exists between two LCCEs, it may be used to perform a mutual authentication between the two LCCEs, and construct an authentication and integrity check of arriving L2TP control messages. The mechanism provided by L2TPv3 is described in Section 4.3 and in the definition of the Message Digest and Control Message Authentication Nonce AVPs in Section 5.4.1.
如果两个LCCE之间存在共享秘密（密码），则可使用该共享秘密（密码）在两个LCCE之间执行相互认证，并对到达的L2TP控制消息构造认证和完整性检查。L2TPv3提供的机制在第4.3节和第5.4.1节中的消息摘要和控制消息认证Nonce AVP定义中进行了描述。
This control message security mechanism provides for (1) mutual endpoint authentication, and (2) individual control message integrity and authenticity checking. Mutual endpoint authentication ensures that an L2TPv3 control connection is only established between two endpoints that are configured with the proper password. The individual control message and integrity check guards against accidental or intentional packet corruption (i.e., those caused by a control message spoofing or man-in-the-middle attack).
此控制消息安全机制提供（1）相互端点身份验证和（2）单个控制消息完整性和真实性检查。相互端点身份验证确保仅在使用正确密码配置的两个端点之间建立L2TPv3控制连接。单个控制消息和完整性检查可防止意外或故意的数据包损坏（即，由控制消息欺骗或中间人攻击引起的损坏）。
The shared secret that is used for all control connection, control message, and AVP security features defined in this document never needs to be sent in the clear between L2TP tunnel endpoints.
本文档中定义的用于所有控制连接、控制消息和AVP安全功能的共享机密永远不需要在L2TP隧道端点之间以明文形式发送。
Packet spoofing for any type of Virtual Private Network (VPN) protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs.
任何类型的虚拟专用网（VPN）协议的数据包欺骗都是特别值得关注的问题，因为将精心构造的恶意数据包插入VPN传输网络可能会导致违反VPN流量分离，将数据泄漏到客户VPN中。由于VPN的运营商甚至很难意识到它已成为进入客户VPN或在客户VPN之间的中转点，这一事实使情况变得更加复杂。
L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit.
L2TPv3通过L2TPv3数据头中的32位会话ID为其VPN提供流量分离。L2TPv3 Cookie（如第4.1节所述）在存在时提供额外的检查，以确保到达的数据包用于已识别的会话。因此，使用具有会话ID的Cookie可以额外保证会话ID查找正确执行，并且会话ID本身在传输过程中没有损坏。
In the presence of a blind packet spoofing attack, the Cookie may also provide security against inadvertent leaking of frames into a customer VPN. To illustrate the type of security that it is provided in this case, consider comparing the validation of a 64-bit Cookie in the L2TPv3 header to the admission of packets that match a given source and destination IP address pair. Both the source and destination IP address pair validation and Cookie validation consist of a fast check on cleartext header information on all arriving packets. However, since L2TPv3 uses its own value, it removes the requirement for one to maintain a list of (potentially several) permitted or denied IP addresses, and moreover, to guard knowledge of the permitted IP addresses from hackers who may obtain and spoof them. Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address," and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address.
在存在盲数据包欺骗攻击的情况下，Cookie还可以提供安全性，防止帧意外泄漏到客户VPN中。为了说明在这种情况下提供的安全性类型，考虑比较L2TPV3报头中的64位Cookie的验证与匹配给定源和目的IP地址对的分组的接纳。源和目标IP地址对验证和Cookie验证都包括对所有到达数据包的明文头信息的快速检查。但是，由于L2TPv3使用自己的值，因此它不再需要维护一个（可能有几个）允许或拒绝的IP地址列表，而且还可以防止黑客获取和欺骗允许的IP地址。此外，更改受损的L2TPv3 Cookie比更改受损的IP地址要容易得多，”与IP地址相比，暴力攻击发现加密随机[RFC1750]值的可能性要小得多。
For protection against brute-force, blind, insertion attacks, a 64- bit Cookie MUST be used with all sessions. A 32-bit Cookie is vulnerable to brute-force guessing at high packet rates, and as such, should not be considered an effective barrier to blind insertion attacks (though it is still useful as an additional verification of a successful Session ID lookup). The Cookie provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data between nodes for use in a coordinated attack.
为了防止暴力、盲、插入攻击，所有会话都必须使用64位Cookie。32位Cookie在高数据包速率下容易受到暴力猜测的攻击，因此，不应将其视为盲插入攻击的有效屏障（尽管它仍然可用作成功会话ID查找的附加验证）。Cookie无法防止复杂的中间人攻击者，该攻击者可以在节点之间嗅探并关联捕获的数据，以用于协同攻击。
The Assigned Cookie AVP is used to signal the value and size of the Cookie that must be present in all data packets for a given session. Each Assigned Cookie MUST be selected in a cryptographically random manner [RFC1750] such that a series of Assigned Cookies does not provide any indication of what a future Cookie will be.
分配的Cookie AVP用于表示给定会话的所有数据包中必须存在的Cookie的值和大小。必须以加密随机方式[RFC1750]选择每个分配的Cookie，以便一系列分配的Cookie不会提供未来Cookie的任何指示。
The L2TPv3 Cookie must not be regarded as a substitute for security such as that provided by IPsec when operating over an open or untrusted network where packets may be sniffed, decoded, and correlated for use in a coordinated attack. See Section 4.1.3 for more information on running L2TP over IPsec.
L2TPv3 Cookie不得被视为安全性的替代品，如在开放或不受信任的网络上操作时，IPsec提供的安全性，在该网络中，数据包可能被嗅探、解码和关联以用于协调攻击。有关通过IPsec运行L2TP的更多信息，请参阅第4.1.3节。
The Host Name and Vendor Name AVPs are not internationalized. The Vendor Name AVP, although intended to be human-readable, would seem to fit in the category of "globally visible names" [RFC2277] and so is represented in US-ASCII.
主机名和供应商名AVP未国际化。供应商名称AVP虽然旨在为人类可读，但似乎符合“全球可见名称”[RFC2277]的类别，因此以US-ASCII表示。
If (1) an LCCE does not signify a language preference by the inclusion of a Preferred Language AVP (see Section 5.4.3) in the
如果（1）LCCE未通过将首选语言AVP（见第5.4.3节）包含在
SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.
SCCRQ或SCCRP，（2）首选语言AVP无法识别，或（3）对等LCCE不支持请求的语言，对等发送的所有国际化字符串必须使用默认语言[RFC2277]。
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria 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在每个列表中分配额外编号时使用的标准。以下小节描述了本文档其他地方定义的命名空间的分配策略。
Sections 10.1 through 10.3 are requests for new values already managed by IANA according to [RFC3438].
第10.1节至第10.3节是对IANA已根据[RFC3438]管理的新值的请求。
The remaining sections are for new registries that have been added to the existing L2TP registry and are maintained by IANA accordingly.
其余部分用于已添加到现有L2TP注册中心并由IANA相应维护的新注册中心。
This number space is managed by IANA as per [RFC3438].
IANA根据[RFC3438]管理此数字空间。
A summary of the new AVPs follows:
新AVP概述如下：
Control Message Attribute Value Pairs
控制消息属性值对
Attribute
Type Description
--------- ------------------
Attribute
Type Description
--------- ------------------
58 Extended Vendor ID AVP 59 Message Digest 60 Router ID 61 Assigned Control Connection ID 62 Pseudowire Capabilities List 63 Local Session ID 64 Remote Session ID 65 Assigned Cookie 66 Remote End ID 68 Pseudowire Type 69 L2-Specific Sublayer 70 Data Sequencing 71 Circuit Status 72 Preferred Language 73 Control Message Authentication Nonce 74 Tx Connect Speed 75 Rx Connect Speed
58扩展供应商ID AVP 59消息摘要60路由器ID 61分配的控制连接ID 62伪线功能列表63本地会话ID 64远程会话ID 65分配的Cookie 66远程端ID 68伪线类型69 L2特定子层70数据排序71电路状态72首选语言73控制消息身份验证Nonce 74 Tx连接速度75 Rx连接速度
This number space is managed by IANA as per [RFC3438]. There is one new message type, defined in Section 3.1, that was allocated for this specification:
IANA根据[RFC3438]管理此数字空间。第3.1节中定义了一种新的消息类型，该类型已分配给本规范：
Message Type AVP (Attribute Type 0) Values
------------------------------------------
Message Type AVP (Attribute Type 0) Values
------------------------------------------
Control Connection Management
控制连接管理
20 (ACK) Explicit Acknowledgement
20（确认）明确确认
This number space is managed by IANA as per [RFC3438].
IANA根据[RFC3438]管理此数字空间。
New Result Code values for the CDN message are defined in Section 5.4. The following is a summary:
CDN消息的新结果代码值在第5.4节中定义。以下是总结：
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
Result Code AVP (Attribute Type 1) Values
-----------------------------------------
General Error Codes
一般错误代码
13 - Session not established due to losing tie breaker (L2TPv3). 14 - Session not established due to unsupported PW type (L2TPv3). 15 - Session not established, sequencing required without valid L2-Specific Sublayer (L2TPv3). 16 - Finite state machine error or timeout.
13-由于失去联络断路器（L2TPv3），会话未建立。14-由于不支持的PW类型（L2TPv3），未建立会话。15-未建立会话，在没有有效的L2特定子层（L2TPv3）的情况下需要排序。16-有限状态机错误或超时。
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
Leading Bits of the L2TP AVP Header
-----------------------------------
Leading Bits of the L2TP AVP Header
-----------------------------------
There six bits at the beginning of the L2TP AVP header. New bits are assigned via Standards Action [RFC2434].
L2TP AVP报头的开头有六位。通过标准操作[RFC2434]分配新位。
Bit 0 - Mandatory (M bit) Bit 1 - Hidden (H bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved
位0-强制（M位）位1-隐藏（H位）位2-保留位3-保留位4-保留位5-保留
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
Leading Bits of the L2TP Control Message Header
-----------------------------------------------
Leading Bits of the L2TP Control Message Header
-----------------------------------------------
There are 12 bits at the beginning of the L2TP Control Message Header. Reserved bits should only be defined by Standard Action [RFC2434].
L2TP控制消息头的开头有12位。保留位只能由标准操作[RFC2434]定义。
Bit 0 - Message Type (T bit) Bit 1 - Length Field is Present (L bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Sequence Numbers Present (S bit) Bit 5 - Reserved Bit 6 - Offset Field is Present [RFC2661] Bit 7 - Priority Bit (P bit) [RFC2661] Bit 8 - Reserved Bit 9 - Reserved Bit 10 - Reserved Bit 11 - Reserved
位0-消息类型（T位）位1-存在长度字段（L位）位2-保留位3-保留位4-存在序号（S位）位5-保留位6-存在偏移字段[RFC2661]位7-优先级位（P位）[RFC2661]位8-保留位9-保留位10-保留位11-保留
This is a new registry for IANA to maintain, there are no values assigned within this document to maintain.
这是IANA要维护的新注册表，此文档中没有指定要维护的值。
L2TPv3 Pseudowire Types
-----------------------
L2TPv3 Pseudowire Types
-----------------------
The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review [RFC2434], while 32768 to 65535 are assigned by a First Come First Served policy [RFC2434]. There are no specific pseudowire types assigned within this document. Each pseudowire-specific document must allocate its own PW types from IANA as necessary.
伪线类型（PW类型，见第5.4节）是在第5.4.3节中定义的伪线类型AVP和伪线能力列表AVP中使用的2-octet值。0到32767由专家评审[RFC2434]分配，而32768到65535由先到先得政策[RFC2434]分配。此文档中没有指定特定的伪导线类型。每个特定于伪线的文档必须根据需要从IANA分配自己的PW类型。
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
Circuit Status Bits
-------------------
Circuit Status Bits
-------------------
The Circuit Status field is a 16-bit mask, with the two low order bits assigned. Additional bits may be assigned by IETF Consensus [RFC2434].
电路状态字段是一个16位掩码，分配了两个低位。附加位可由IETF协商一致[RFC2434]分配。
Bit 14 - New (N bit) Bit 15 - Active (A bit)
位14-新（N位）位15-激活（A位）
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
Default L2-Specific Sublayer Bits
---------------------------------
Default L2-Specific Sublayer Bits
---------------------------------
The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. Reserved bits may be assigned by IETF Consensus [RFC2434].
默认的L2特定子层在报头的低阶部分包含8位。保留位可由IETF协商一致[RFC2434]分配。
Bit 0 - Reserved Bit 1 - Sequence (S bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved Bit 6 - Reserved Bit 7 - Reserved
位0-保留位1-序列（S位）位2-保留位3-保留位4-保留位5-保留位6-保留位7-保留
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
L2-Specific Sublayer Type
-------------------------
L2-Specific Sublayer Type
-------------------------
The L2-Specific Sublayer Type is a 2-octet unsigned integer. Additional values may be assigned by Expert Review [RFC2434].
L2特定的子层类型是一个2-octet无符号整数。专家评审[RFC2434]可指定其他值。
0 - No L2-Specific Sublayer 1 - Default L2-Specific Sublayer present
0-无L2特定子层1-默认存在L2特定子层
This is a new registry for IANA to maintain.
这是IANA需要维护的新注册表。
Data Sequencing Level
---------------------
Data Sequencing Level
---------------------
The Data Sequencing Level is a 2-octet unsigned integer Additional values may be assigned by Expert Review [RFC2434].
数据排序级别为2-octet无符号整数。专家评审可分配额外值[RFC2434]。
0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
0-没有需要排序的传入数据包。1-只有非IP数据包需要排序。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月。
[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月。
[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月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999.
[RFC2661]Townsley，W.，Valencia，A.，Rubens，A.，Pall，G.，Zorn，G.，和Palter，B.，“第二层隧道-第二层隧道协议（L2TP）”，RFC 26611999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193]Patel，B.，Aboba，B.，Dixon，W.，Zorn，G.，和Booth，S.，“使用IPsec保护L2TP”，RFC 3193，2001年11月。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[RFC3438]汤斯利，W.“第二层隧道协议（L2TP）互联网分配号码管理局（IANA）注意事项更新”，BCP 68，RFC 3438，2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和Postel，J.，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750]Eastlake，D.，Crocker，S.，和Schiller，J.，“安全性的随机性建议”，RFC 1750，1994年12月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，Ed.“互联网的架构原则”，RFC19581996年6月。
[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和Mogul，J.，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]Berkowitz，H.，“路由器重新编号指南”，RFC 2072，1997年1月。
[RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和Canetti，R.，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998.
[RFC2341]Valencia，A.，Littlewood，M.，和Kolar，T.，“思科第二层转发（协议）L2F”，RFC 23411998年5月。
[RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和Atkinson，R.，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.，和Stevens，W.，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.
[RFC2637]Hamzeh，K.，Pall，G.，Verthein，W.，Taarud，J.，Little，W.，和Zorn，G.，“点对点隧道协议（PPTP）”，RFC 2637，1999年7月。
[RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC2732]Hinden，R.，Carpenter，B.，和Masinter，L.，“URL中文字IPv6地址的格式”，RFC 2732，1999年12月。
[RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000.
[RFC2809]Aboba，B.和Zorn，G.“通过半径实施L2TP强制隧道”，RFC 2809，2000年4月。
[RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two Tunneling Protocol (L2TP) over Frame Relay", RFC 3070, February 2001.
[RFC3070]Rawat，V.，Tio，R.，Nanji，S.，和Verma，R.，“帧中继上的第二层隧道协议（L2TP）”，RFC 30702001年2月。
[RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)", RFC 3355, August 2002.
[RFC3355]Singh，A.，Turner，R.，Tio，R.，和Nanji，S.，“ATM适配层5（AAL5）上的第二层隧道协议（L2TP）”，RFC 33552002年8月。
[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。
[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。
Many of the protocol constructs were originally defined in, and the text of this document began with, RFC 2661, "L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and B. Palter.
许多协议结构最初是在RFC 2661“L2TPv2”中定义的，本文档的文本以RFC 2661“L2TPv2”开头。RFC 2661的作者是W.汤斯利、A.瓦伦西亚、A.鲁本斯、G.帕尔、G.佐恩和B.帕尔特。
The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn.
L2TP的基本概念及其许多协议结构都采用了L2F[RFC2341]和PPTP[RFC2637]。这些版本的作者是A.瓦伦西亚、M.利特尔伍德、T.科拉尔、K.哈姆泽、G.帕尔、W.维特海因、J.塔鲁德、W.利特尔和G.佐恩。
Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay).
Danny Mcpherson和Suhail Nanji发布了第一个“L2TP服务类型”版本，该版本定义了L2TP用于各种L2有效负载类型（最初为以太网和帧中继）的隧道传输。
The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment.
将RFC 2661拆分为本基础文件和配套PPP文件的团队由Ignacio Goyret、Jed Lau、Bill Palter、Mark Townsley和Madhvi Verma组成。Skip Booth还提供了非常有用的评论。
Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates.
L2TPv3的一些结构部分基于UTI（通用传输接口），UTI最初由Peter Lothberg和Tony Bates构思。
Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header.
Stewart Bryant和Simon Barber为L2TPv3 over IP报头提供了有价值的输入。
Juha Heinanen provided helpful review in the early stages of this effort.
Juha Heinanen在这项工作的早期阶段提供了有益的回顾。
Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
Jan Vilhuber、Scott Fluhrer、David McGrew、Scott Wainner、Skip Booth和Maria Dos Santos对控制消息身份验证机制以及安全性的一般性讨论做出了贡献。
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted Hardie, and Pekka Savola provided very helpful review of the final versions of text.
詹姆斯·卡尔森、托马斯·纳滕、玛丽亚·多斯桑托斯、史蒂文·贝洛文、泰德·哈迪和佩卡·萨沃拉为文本的最终版本提供了非常有用的评论。
Russ Housley provided valuable review and comment on security, particularly with respect to the Control Message Authentication mechanism.
Russ Housley提供了关于安全性的宝贵评论，特别是关于控制消息身份验证机制。
Pekka Savola contributed to proper alignment with IPv6 and inspired much of Section 4.1.4 on fragmentation.
Pekka Savola为与IPv6的正确结合做出了贡献，并启发了第4.1.4节关于碎片化的大部分内容。
Aside of his original influence and co-authorship of RFC 2661, Glen Zorn helped get all of the language and character references straight in this document.
除了他最初的影响力和RFC2661的合著者外，格伦·佐恩（Glen Zorn）还帮助我们在本文档中直接获得了所有语言和人物的参考资料。
A number of people provided valuable input and effort for RFC 2661, on which this document was based:
许多人为RFC 2661提供了宝贵的投入和努力，本文件以此为基础：
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 RFC 2661.
John Bray、Greg Burns、Rich Garrett、Don Grosser、Matt Holdrege、Terry Johnson、Dory Leifer和Rich Shea在佛罗里达州奥兰多举行的第43届IETF上提供了宝贵的意见和评论，从而提高了RFC 2661的整体可读性和清晰度。
Thomas Narten provided a great deal of critical review and formatting. He wrote the first version of the IANA Considerations section.
Thomas Narten提供了大量的批判性评论和格式。他编写了IANA考虑事项部分的第一个版本。
Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early versions leading to RFC 2661.
Dory Leifer对L2TP的协议定义进行了有价值的改进，并对导致RFC 2661的早期版本的编辑做出了贡献。
Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the original endpoint authentication mechanism.
Steve Cobb和Evan Caves重新设计了状态机表。Barney Wolff为原始端点身份验证机制提供了大量设计输入。
Appendix A: Control 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] (this algorithm is also described in [RFC2581]).
尽管每一方都指出了其接收窗口的最大大小，但建议使用慢速启动和拥塞避免方法来传输控制数据包。此处描述的方法基于W.Richard Stevens[Stevens]在第一卷所示TCP/IP第21.6节中描述的TCP拥塞避免算法（该算法也在[RFC2581]中描述）。
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 acknowledgment (either explicit or piggybacked). When the acknowledgment 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 ACK message 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（显式ACK消息或搭载）时，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 Control Connection Establishment
B.1：锁定步进控制连接建立
In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection.
在本例中，LCCE建立了一个控制连接，交换双方轮流发送消息。此示例显示在ACK消息中显式发送的最终确认。另一种方法是，在作为ICRQ或OCRQ的回复发送的消息中携带确认，该消息可能来自发起控制连接的一方。
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ACK
Nr: 2, Ns: 1
LCCE A LCCE B
------ ------
SCCRQ ->
Nr: 0, Ns: 0
<- SCCRP
Nr: 1, Ns: 0
SCCCN ->
Nr: 1, Ns: 1
<- ACK
Nr: 2, Ns: 1
B.2: Lost Packet with Retransmission
B.2：具有重传的丢失数据包
An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ.
现有控制连接有LCCE a请求的新会话。ICRP丢失，必须由LCCE B重新传输。请注意，ICRP丢失有两个影响：它不仅使上层状态机无法运行，而且使LCCE a无法及时看到其ICRQ的下层确认。
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
LCCE A LCCE B
------ ------
ICRQ ->
Nr: 1, Ns: 2
(packet lost) <- ICRP
Nr: 3, Ns: 1
(pause; LCCE A's timer started first, so fires first)
（暂停；LCCE A的计时器先启动，所以先触发）
ICRQ ->
Nr: 1, Ns: 2
ICRQ ->
Nr: 1, Ns: 2
(Realizing that it has already seen this packet, LCCE B discards the packet and sends an ACK message)
（LCCE B意识到已经看到该数据包，因此丢弃该数据包并发送ACK消息）
<- ACK Nr: 3, Ns: 2
<-确认编号：3，Ns:2
(LCCE B's retransmit timer fires)
（LCCE B的重传定时器触发）
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ACK Nr: 4, Ns: 2
<-确认编号：4，Ns:2
Appendix C: Processing Sequence Numbers
附录C：处理序列号
The Default L2-Specific Sublayer, defined in Section 4.6, provides a 24-bit field for sequencing of data packets within an L2TP session. L2TP data packets are never retransmitted, so this sequence is used only to detect packet order, duplicate packets, or lost packets.
第4.6节中定义的默认L2特定子层提供了一个24位字段，用于L2TP会话中数据包的排序。L2TP数据包永远不会重新传输，因此此序列仅用于检测数据包顺序、重复数据包或丢失数据包。
The 24-bit Sequence Number field of the Default L2-Specific Sublayer contains a packet sequence number for the associated session. Each sequenced data packet that is sent must contain the sequence number, incremented by one, of the previous sequenced packet sent on a given L2TP session. Upon receipt, any packet with a sequence number equal to or greater than the current expected packet (the last received in-order packet plus one) should be considered "new" and accepted. All other packets are considered "old" or "duplicate" and discarded. Note that the 24-bit sequence number space includes zero as a valid sequence number (as such, it may be implemented with a masked 32-bit counter if desired). All new sessions MUST begin sending sequence numbers at zero.
默认L2特定子层的24位序列号字段包含关联会话的数据包序列号。发送的每个序列数据包必须包含在给定L2TP会话上发送的前一个序列数据包的序列号（递增1）。收到后，序列号等于或大于当前预期数据包（订单数据包中最后一个收到的数据包加上一个）的任何数据包都应被视为“新的”并被接受。所有其他数据包都被视为“旧”或“重复”，并被丢弃。注意，24位序列号空间包括零作为有效序列号（因此，如果需要，可以使用屏蔽32位计数器实现）。所有新会话必须从零开始发送序列号。
Larger or smaller sequence number fields are possible with L2TP if an alternative format to the Default L2-Specific Sublayer defined in this document is used. While 24 bits may be adequate in a number of circumstances, a larger sequence number space will be less susceptible to sequence number wrapping problems for very high session data rates across long dropout periods. The sequence number processing recommendations below should hold for any size sequence number field.
如果使用本文档中定义的默认L2特定子层的替代格式，则L2TP可以使用较大或较小的序列号字段。虽然在许多情况下24位可能足够，但较大的序列号空间将不太容易受到序列号包装问题的影响，因为在较长的退出周期中，会话数据率非常高。以下序列号处理建议适用于任何大小的序列号字段。
When detecting whether a packet sequence number is "greater" or "less" than a given sequence number value, wrapping of the sequence number must be considered. This is typically accomplished by keeping a window of sequence numbers beyond the current expected sequence number for determination of whether a packet is "new" or not. The window may be sized based on the link speed and sequence number space and SHOULD be configurable with a default equal to one half the size of the available number space (e.g., 2^(n-1), where n is the number of bits available in the sequence number).
当检测数据包序列号是否比给定序列号值“大”或“小”时，必须考虑序列号的包装。这通常是通过将序列号窗口保持在当前预期序列号之外以确定数据包是否为“新”来实现的。该窗口的大小可基于链路速度和序列号空间，并且应可配置为默认值等于可用序列号空间大小的一半（例如，2^（n-1），其中n是序列号中可用的比特数）。
Upon receipt, packets that exactly match the expected sequence number are processed immediately and the next expected sequence number incremented. Packets that fall within the window for new packets may either be processed immediately and the next expected sequence number updated to one plus that received in the new packet, or held for a very short period of time in hopes of receiving the missing packet(s). This "very short period" should be configurable, with a default corresponding to a time lapse that is at least an order of magnitude less than the retransmission timeout periods of higher layer protocols such as TCP.
收到后，立即处理与预期序列号完全匹配的数据包，并增加下一个预期序列号。落在新分组窗口内的分组可以立即被处理，并且下一个预期序列号被更新为新分组中接收到的1加1，或者被保持很短的时间以希望接收丢失的分组。这个“非常短的时间段”应该是可配置的，默认值对应于至少比高层协议（如TCP）的重传超时时间短一个数量级的时间间隔。
For typical transient packet mis-orderings, dropping out-of-order packets alone should suffice and generally requires far less resources than actively reordering packets within L2TP. An exception is a case in which a pair of packet fragments are persistently retransmitted and sent out-of-order. For example, if an IP packet has been fragmented into a very small packet followed by a very large packet before being tunneled by L2TP, it is possible (though admittedly wrong) that the two resulting L2TP packets may be consistently mis-ordered by the PSN in transit between L2TP nodes. If sequence numbers were being enforced at the receiving node without any buffering of out-of-order packets, then the fragmented IP packet may never reach its destination. It may be worth noting here that this condition is true for any tunneling mechanism of IP packets that includes sequence number checking on receipt (i.e., GRE [RFC2890]).
对于典型的瞬态数据包错误排序，仅丢弃无序数据包就足够了，并且通常比L2TP中主动重新排序数据包所需的资源少得多。例外情况是一对数据包片段被持续地重新传输并无序发送的情况。例如，如果一个IP分组在被L2TP隧道化之前已经被分割成一个非常小的分组，接着是一个非常大的分组，那么两个产生的L2TP分组可能在L2TP节点之间传输时被PSN一致地错序（尽管承认是错误的）。如果在接收节点强制执行序列号，而没有对无序数据包进行任何缓冲，则碎片化的IP数据包可能永远不会到达其目的地。这里可能值得注意的是，该条件适用于包括接收时序列号检查（即GRE[RFC2890]）的任何IP数据包隧道机制。
Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only non-IP data packets require sequencing) allows IP data packets being tunneled by L2TP to not utilize sequence numbers, while utilizing sequence numbers and enforcing packet order for any remaining non-IP data packets. Depending on the requirements of the link layer being tunneled and the network data traversing the data link, this is sufficient in many cases to enforce packet order on frames that require it (such as end-to-end data link control messages), while not on IP packets that are known to be resilient to packet reordering.
利用1的数据排序级别（见第5.4.3节）（只有非IP数据包需要排序）允许L2TP隧道传输的IP数据包不使用序列号，同时利用序列号并对任何剩余的非IP数据包强制执行数据包顺序。根据被隧道化的链路层的要求和穿过数据链路的网络数据，在许多情况下，这足以在需要分组顺序的帧（例如端到端数据链路控制消息）上强制分组顺序，而不是在已知具有分组重排序弹性的IP分组上。
If a large number of packets (i.e., more than one new packet window) are dropped due to an extended outage or loss of sequence number state on one side of the connection (perhaps as part of a forwarding plane reset or failover to a standby node), it is possible that a large number of packets will be sent in-order, but be wrongly detected by the peer as out-of-order. This can be generally characterized for a window size, w, sequence number space, s, and number of packets lost in transit between L2TP endpoints, p, as follows:
如果大量数据包（即，多个新数据包窗口）由于连接一侧的延长中断或序列号状态丢失而被丢弃（可能作为转发平面重置或故障切换到备用节点的一部分），则可能会按顺序发送大量数据包，但被同伴误认为是不正常的。这通常可以针对窗口大小w、序列号空间s和在L2TP端点p之间传输中丢失的分组数p来表征，如下所示：
If s > p > w, then an additional (s - p) packets that were otherwise received in-order, will be incorrectly classified as out-of-order and dropped. Thus, for a sequence number space, s = 128, window size, w = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional packets would be dropped after the outage until the sequence number wrapped back to the current expected next sequence number.
如果s>p>w，则以其他方式按顺序接收的附加（s-p）数据包将被错误地归类为无序并丢弃。因此，对于序列号空间，s＝128，窗口大小，w＝64，以及丢失分组的数目，p＝70；128-70=58个额外的数据包将在中断后丢弃，直到序列号包装回当前预期的下一个序列号。
To mitigate this additional packet loss, one MUST inspect the sequence numbers of packets dropped due to being classified as "old" and reset the expected sequence number accordingly. This may be accomplished by counting the number of "old" packets dropped that were in sequence among themselves and, upon reaching a threshold, resetting the next expected sequence number to that seen in the arriving data packets. Packet timestamps may also be used as an indicator to reset the expected sequence number by detecting a period of time over which "old" packets have been received in-sequence. The ideal thresholds will vary depending on link speed, sequence number space, and link tolerance to out-of-order packets, and MUST be configurable.
为了减轻这种额外的数据包丢失，必须检查由于被分类为“旧”而丢弃的数据包的序列号，并相应地重置预期序列号。这可以通过计算在它们之间按顺序丢弃的“旧”分组的数量来实现，并且在达到阈值时，将下一个预期序列号重置为在到达的数据分组中看到的序列号。分组时间戳也可用作指示符，通过检测序列中接收到“旧”分组的时间段来重置预期序列号。理想的阈值将根据链路速度、序列号空间和对无序数据包的链路容差而变化，并且必须是可配置的。
Editors' Addresses
编辑地址
Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134
Jed Lau cisco Systems 170 W.塔斯曼大道圣何塞，加利福尼亚州95134
EMail: jedlau@cisco.com
EMail: jedlau@cisco.com
W. Mark Townsley cisco Systems
W.马克·汤斯利思科系统公司
EMail: mark@townsley.net
EMail: mark@townsley.net
Ignacio Goyret Lucent Technologies
伊格纳西奥·戈雷特·朗讯科技公司
EMail: igoyret@lucent.com
EMail: igoyret@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。