RFC 2661 - Layer Two Tunneling Protocol "L2TP"

状态: Proposed Standard
发布日期: August 1999
Stream: IETF
勘误: 无勘误

Abstract (摘要)

本文档描述了第二层隧道协议 (Layer Two Tunneling Protocol, L2TP).STD 51, RFC 1661 规定了通过 PPP [RFC1661] 进行多协议访问.L2TP 促进了 PPP 数据包穿越中间网络的隧道传输,以对终端用户和应用程序尽可能透明的方式进行.

Table of Contents (目录)

1. Introduction (简介)

1.0 Introduction - 简介
1.1 Specification of Requirements - 需求规范
1.2 Terminology - 术语

2-3. Topology and Protocol Overview (拓扑与协议概述)

2.0 Topology - 拓扑
3.0 Protocol Overview - 协议概述
- 3.1 L2TP Header Format - L2TP 头部格式
- 3.2 Control Message Types - 控制消息类型

4. Control Message Attribute Value Pairs (控制消息属性值对)

4.0 Control Message Attribute Value Pairs - 控制消息 AVP
- 4.1 AVP Format - AVP 格式
- 4.2 Mandatory AVPs - 强制性 AVP
- 4.3 Hiding of AVP Attribute Values - AVP 属性值隐藏
- 4.4 AVP Summary - AVP 摘要
  - 4.4.1 AVPs Applicable To All Control Messages
  - 4.4.2 Result and Error Codes
  - 4.4.3 Control Connection Management AVPs
  - 4.4.4 Call Management AVPs
  - 4.4.5 Proxy LCP and Authentication AVPs
  - 4.4.6 Call Status AVPs

5. Protocol Operation (协议操作)

5.0 Protocol Operation - 协议操作
- 5.1 Control Connection Establishment - 控制连接建立
- 5.2 Session Establishment - 会话建立
- 5.3 Forwarding PPP Frames - 转发 PPP 帧
- 5.4 Using Sequence Numbers on the Data Channel - 在数据通道上使用序列号
- 5.5 Keepalive (Hello) - 保活
- 5.6 Session Teardown - 会话拆除
- 5.7 Control Connection Teardown - 控制连接拆除
- 5.8 Reliable Delivery of Control Messages - 控制消息的可靠传递

6-7. Control Connection Protocol (控制连接协议)

6.0 Control Connection Protocol Specification - 控制连接协议规范
- 6.1 Start-Control-Connection-Request (SCCRQ)
- 6.2 Start-Control-Connection-Reply (SCCRP)
- 6.3 Start-Control-Connection-Connected (SCCCN)
- 6.4 Stop-Control-Connection-Notification (StopCCN)
- 6.5-6.14 其他控制消息
7.0 Control Connection State Machines - 控制连接状态机
- 7.1 Control Connection Protocol Operation
- 7.2 Control Connection States
- 7.3 Timing considerations
- 7.4 Incoming calls
- 7.5 Outgoing calls
- 7.6 Tunnel Disconnection

8-10. Media, Security and IANA (媒体、安全与 IANA)

8.0 L2TP Over Specific Media - 特定媒体上的 L2TP
- 8.1 L2TP over UDP/IP
- 8.2 IP
9.0 Security Considerations - 安全考虑
- 9.1 Tunnel Endpoint Security
- 9.2 Packet Level Security
- 9.3 End to End Security
- 9.4 L2TP and IPsec
- 9.5 Proxy PPP Authentication
10.0 IANA Considerations - IANA 考虑

11-13. References and Appendices (参考文献与附录)

11.0 References - 参考文献
12.0 Acknowledgments - 致谢
13.0 Authors' Addresses - 作者地址

Appendices (附录)

Appendix A - Control Channel Slow Start and Congestion Avoidance
Appendix B - Control Message Examples
Appendix C - Intellectual Property Notice

核心术语 (Key Terminology)

L2TP (Layer Two Tunneling Protocol): 第二层隧道协议
LAC (L2TP Access Concentrator): L2TP 访问集中器
LNS (L2TP Network Server): L2TP 网络服务器
AVP (Attribute Value Pair): 属性值对
PPP (Point-to-Point Protocol): 点对点协议
NAS (Network Access Server): 网络访问服务器
Tunnel: 隧道 - LAC 和 LNS 之间的控制连接
Session: 会话 - 隧道内的单个 PPP 连接
Control Connection: 控制连接 - 在隧道内运行以控制会话和隧道本身
Call: 呼叫 - 远程系统与 LAC 之间的连接

协议概述

L2TP 扩展了 PPP 模型,允许第二层 (L2) 和 PPP 端点驻留在通过分组交换网络互连的不同设备上.使用 L2TP,用户与访问集中器 (例如调制解调器池、ADSL DSLAM 等) 建立 L2 连接,然后集中器将各个 PPP 帧隧道传输到 NAS.这使得 PPP 数据包的实际处理与 L2 电路的终止分离.

主要优势:

允许 L2 连接在本地电路集中器终止,而不是远程 NAS
解决多链路分组问题
提供透明的 PPP 会话扩展

7. Control Connection State Machines (控制连接状态机)

本章定义了 L2TP 控制连接和会话建立、维护和拆除的状态机.

7.1 Control Connection Protocol Operation (控制连接协议操作)

控制连接状态机描述了隧道建立和拆除的状态转换.每个状态定义了可接受的事件、相应的操作和下一个状态.

7.2 Control Connection States (控制连接状态)

控制连接包含以下状态:

idle: 初始状态,未建立连接
wait-ctl-reply: 等待对等方的控制连接回复
wait-ctl-conn: 等待控制连接完成
established: 控制连接已建立
closing: 正在关闭控制连接

7.2.1 Control Connection Establishment (控制连接建立)

控制连接建立使用三次握手(SCCRQ, SCCRP, SCCCN)完成.状态转换包括:

idle → wait-ctl-reply (发送 SCCRQ)
wait-ctl-reply → wait-ctl-conn (接收 SCCRP)
wait-ctl-conn → established (接收 SCCCN)

7.3 Timing Considerations (时序考虑)

重传计时器: 用于可靠传输的控制消息重传
Hello 间隔: 定期发送 Hello 消息的间隔
超时检测: 检测隧道故障的超时机制

7.4 Incoming Calls (传入呼叫)

传入呼叫的建立涉及 LAC 和 LNS 的协调状态转换.

7.4.1 LAC Incoming Call States (LAC 传入呼叫状态)

LAC 端的传入呼叫状态:

idle: 无活动呼叫
wait-reply: 等待 LNS 的 ICRP
wait-connect: 等待呼叫连接
established: 会话已建立

7.4.2 LNS Incoming Call States (LNS 传入呼叫状态)

LNS 端的传入呼叫状态:

idle: 无活动呼叫
wait-connect: 等待 LAC 的 ICCN
established: 会话已建立

7.5 Outgoing Calls (传出呼叫)

传出呼叫由 LNS 发起,LAC 执行实际的呼叫操作.

7.5.1 LAC Outgoing Call States (LAC 传出呼叫状态)

LAC 端的传出呼叫状态:

idle: 无活动呼叫
wait-reply: 等待对 OCRQ 的响应
wait-cs-answer: 等待呼叫应答
established: 会话已建立

7.5.2 LNS Outgoing Call States (LNS 传出呼叫状态)

LNS 端的传出呼叫状态:

idle: 无活动呼叫
wait-reply: 等待 LAC 的 OCRP
wait-connect: 等待 OCCN
established: 会话已建立

7.6 Tunnel Disconnection (隧道断开)

隧道断开可以由 LAC 或 LNS 通过发送 StopCCN 消息启动.接收到 StopCCN 后,对等方应确认消息并清理所有相关资源.

注:完整的状态转换表和详细的状态机图请参考 RFC 2661 原文.本章提供了状态机的概述和主要状态转换流程.

8. L2TP Over Specific Media (特定媒体上的 L2TP)

本章描述 L2TP 在特定媒体类型上的实现细节.L2TP 被设计为可以在多种数据包传输媒体上运行,包括 UDP/IP、帧中继、ATM 等.

8.1 L2TP over UDP/IP

L2TP 使用注册的 UDP 端口 1701 用于隧道端点之间的通信.UDP 为 L2TP 控制消息和数据消息提供数据包传输服务.

端口分配 (Port Assignment):

源端口 (Source Port): 发送端可以使用任何可用的 UDP 端口作为源端口.
目标端口 (Destination Port): 必须使用 UDP 端口 1701.

数据包封装 (Packet Encapsulation):

L2TP 数据包在 UDP/IP 上的封装格式如下:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    IP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   UDP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   L2TP Header                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              L2TP Control Message or                |
|                  PPP Payload                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP 校验和 (UDP Checksum):

UDP 校验和应该被计算并包含在所有 L2TP 数据包中.接收端必须验证校验和(如果存在).如果校验和验证失败,数据包必须被丢弃.

MTU 考虑 (MTU Considerations):

由于 L2TP 添加了额外的封装层(L2TP 头部 + UDP 头部 + IP 头部),实现必须考虑路径 MTU.典型的封装开销:

IP 头部:20 字节(IPv4)或 40 字节(IPv6)
UDP 头部:8 字节
L2TP 头部:至少 6 字节(可能更多,取决于选项)

分片 (Fragmentation):

建议 L2TP 实现避免 IP 分片.可以通过以下方式实现:

路径 MTU 发现(Path MTU Discovery)
在隧道建立时协商 MRU(Maximum Receive Unit)
在 PPP 层进行分片而不是 IP 层

8.2 IP

L2TP 数据包使用 IP 作为其数据包传输协议.IP 为 L2TP 提供端到端的数据包传输服务.

IP 版本支持 (IP Version Support):

L2TP 被设计为可以在 IPv4 [RFC791] 和 IPv6 [RFC2460] 上运行.实现应该支持至少一种 IP 版本,并可以选择支持两者.

IPv4 特定考虑 (IPv4-Specific Considerations):

协议类型 (Protocol Type): 当使用 UDP 封装时,IP 协议字段设置为 17(UDP).
服务类型 (Type of Service, TOS): L2TP 实现可以设置 IP TOS 字段以指示服务质量要求.控制消息可能需要比数据消息更高的优先级.
生存时间 (Time to Live, TTL): 应该设置合适的 TTL 值以防止数据包在网络中无限循环.

IPv6 特定考虑 (IPv6-Specific Considerations):

下一个头部 (Next Header): 当使用 UDP 封装时,设置为 17(UDP).
流标签 (Flow Label): 可以使用 IPv6 流标签来识别属于同一隧道的数据包流,以便进行 QoS 处理.
跳数限制 (Hop Limit): 相当于 IPv4 的 TTL.

地址选择 (Address Selection):

LAC 和 LNS 必须能够确定对端的 IP 地址.这可以通过以下方式实现:

静态配置
DNS 解析
动态发现机制

多宿主考虑 (Multi-homing Considerations):

如果隧道端点有多个 IP 地址(多宿主),实现必须确保隧道的所有数据包都使用一致的源地址.这对于保持隧道状态和防止混淆至关重要.

安全性 (Security):

当 L2TP 在 IP 上运行时,强烈建议使用 IPsec [RFC2401] 来保护隧道流量.IPsec 可以提供:

机密性 (Confidentiality): 通过 ESP 加密
完整性 (Integrity): 通过 AH 或 ESP 认证
端点认证 (Endpoint Authentication): 通过 IKE

详细的安全考虑请参见第 9 章.

实现注意事项 (Implementation Notes):

端口复用 (Port Multiplexing): 多个隧道可以在同一对 IP 地址之间建立,通过 Tunnel ID 进行区分.
NAT 穿越 (NAT Traversal): 当 L2TP 需要穿越 NAT 设备时,可能需要额外的机制(如 L2TP/IPsec NAT-T).
防火墙考虑 (Firewall Considerations): 防火墙必须允许 UDP 端口 1701 的双向通信以支持 L2TP.
QoS 映射 (QoS Mapping): 实现可以将 PPP 层的 QoS 要求映射到 IP 层的 DSCP 或 TOS 字段.

9. Security Considerations (安全性考虑)

L2TP 协议本身并不提供加密或强认证服务.本章讨论 L2TP 部署中的安全性考虑以及可用的安全机制.

9.1 Tunnel Endpoint Security (隧道端点安全)

隧道端点之间的信任关系是 L2TP 安全性的基础.

端点认证 (Endpoint Authentication):

LAC 和 LNS 必须能够验证对端的身份.L2TP 提供了一个可选的隧道认证机制:

Challenge AVP: 发起方在 SCCRQ(Start-Control-Connection-Request)中发送一个随机挑战值.
Challenge Response AVP: 响应方计算基于共享密钥的响应并在 SCCRP(Start-Control-Connection-Reply)中返回.
响应计算: 使用 MD5 哈希函数:MD5(Message Type + shared_secret + Challenge + Session_ID)

共享密钥管理 (Shared Secret Management):

共享密钥应该具有足够的熵(建议至少 128 位).
共享密钥应该安全存储(加密存储).
应该定期更换共享密钥.
不同的隧道对应该使用不同的共享密钥.

隧道授权 (Tunnel Authorization):

除了认证之外,还应该实施授权机制:

验证对端是否被允许建立隧道.
检查对端是否有权限访问特定的资源或服务.
使用访问控制列表(ACL)限制哪些对端可以建立隧道.

漏洞和缓解措施 (Vulnerabilities and Mitigations):

中间人攻击 (Man-in-the-Middle Attack):
- 风险: L2TP 隧道认证基于共享密钥,容易受到中间人攻击.
- 缓解: 使用 IPsec 提供端到端的加密和认证.
重放攻击 (Replay Attack):
- 风险: 攻击者可能重放捕获的控制消息.
- 缓解: 使用序列号和 ZLB ACK 机制来检测和防止重放攻击.
拒绝服务攻击 (Denial of Service Attack):
- 风险: 攻击者可能发送大量的隧道建立请求.
- 缓解:
  - 限制每个源地址的并发隧道数量.
  - 实施速率限制.
  - 使用 Cookie 机制(类似 TCP SYN Cookie).

9.2 Packet Level Security (数据包级安全)

L2TP 本身不提供数据包加密或完整性保护.

明文传输的风险 (Risks of Cleartext Transmission):

窃听 (Eavesdropping): 攻击者可以拦截和读取 PPP 数据包内容,包括用户凭证和应用数据.
篡改 (Tampering): 攻击者可以修改传输中的数据包.
注入 (Injection): 攻击者可以向隧道注入恶意数据包.

AVP 隐藏机制 (AVP Hiding Mechanism):

L2TP 提供了一个 AVP 隐藏机制来保护敏感的控制信息:

隐藏过程 (Hiding Process):
1. 使用共享密钥和随机向量(Random Vector)生成 MD5 哈希.
2. 将哈希值与 AVP 值进行 XOR 运算.
3. 如果 AVP 值长度超过 16 字节,重复上述过程.
限制 (Limitations):
- AVP 隐藏只是混淆(obfuscation),不是真正的加密.
- 不保护数据通道,只保护控制通道中的特定 AVP.
- 容易受到字典攻击(如果共享密钥弱).

建议 (Recommendations):

不要依赖 AVP 隐藏作为唯一的安全机制.
使用 IPsec 或其他隧道级加密技术.

9.3 End to End Security (端到端安全)

即使 L2TP 隧道本身受到保护,端到端安全仍然很重要.

PPP 层认证 (PPP-Level Authentication):

远程系统和 LNS 之间应该进行独立的认证:

PAP (Password Authentication Protocol):
- 简单的明文密码认证.
- 不建议使用,因为密码以明文传输(即使在加密的 L2TP 隧道内也应避免).
CHAP (Challenge Handshake Authentication Protocol):
- 基于挑战-响应的认证机制.
- 密码不以明文传输.
- 定期重新认证以防止重放攻击.
EAP (Extensible Authentication Protocol):
- 支持多种认证方法(EAP-TLS, EAP-TTLS, PEAP 等).
- 可以提供双向认证和密钥协商.
- 推荐使用 EAP-TLS 提供最强的安全性.

端到端加密 (End-to-End Encryption):

应用层加密提供了额外的安全层:

TLS/SSL: 用于保护应用数据(如 HTTPS).
VPN 客户端软件: 在 PPP 之上提供额外的加密层.

多层防御策略 (Defense in Depth):

远程系统 &lt;--PPP认证/加密--> LNS
    |                           |
    +--&lt;L2TP隧道>--LAC--------+
              |
         &lt;IPsec保护>

第1层: PPP 层认证(CHAP/EAP)
第2层: L2TP 隧道认证
第3层: IPsec 加密和认证
第4层: 应用层加密(TLS/SSL)

9.4 L2TP and IPsec (L2TP 与 IPsec)

强烈建议将 L2TP 与 IPsec 结合使用,这种组合通常称为 L2TP/IPsec.

IPsec 提供的安全服务 (Security Services Provided by IPsec):

机密性 (Confidentiality):
- 通过 ESP(Encapsulating Security Payload)提供加密.
- 支持多种加密算法:AES, 3DES, ChaCha20 等.
完整性 (Integrity):
- 通过 AH(Authentication Header)或 ESP 认证提供.
- 使用 HMAC(如 HMAC-SHA256)验证数据完整性.
源认证 (Source Authentication):
- 验证数据包来源的真实性.
- 防止 IP 欺骗攻击.
防重放 (Anti-Replay):
- 使用序列号防止重放攻击.

L2TP/IPsec 架构 (L2TP/IPsec Architecture):

+-------------------+
|   PPP Payload     |
+-------------------+
|   L2TP Header     |
+-------------------+
|   UDP Header      |
+-------------------+
|   ESP Header      | &lt;-- IPsec 加密和认证
+-------------------+
|   IP Header       |
+-------------------+

IPsec 配置选项 (IPsec Configuration Options):

传输模式 (Transport Mode):
- 只加密和认证 IP 载荷.
- 适用于端到端通信.
- 推荐用于 L2TP/IPsec.
隧道模式 (Tunnel Mode):
- 加密和认证整个 IP 数据包.
- 添加新的外部 IP 头部.
- 适用于网关到网关通信.

密钥管理 (Key Management):

IKE (Internet Key Exchange):
- IKEv1: 原始版本,两阶段协商.
- IKEv2: 改进版本,更简洁和高效.
- 推荐使用 IKEv2 进行密钥协商.
预共享密钥 vs 证书:
- 预共享密钥 (PSK): 配置简单,但密钥分发困难.
- 证书 (Certificates): 更安全,支持大规模部署,强烈推荐.

NAT 穿越 (NAT Traversal - NAT-T):

当 L2TP/IPsec 需要穿越 NAT 设备时:

使用 UDP 封装 ESP(UDP port 4500).
定期发送 NAT keepalive 数据包.
IKEv2 内置 NAT-T 支持.

性能考虑 (Performance Considerations):

IPsec 加密会增加 CPU 开销.
考虑使用硬件加速(AES-NI 等).
MTU 减少需要考虑(ESP 头部 + ESP 尾部 + 认证数据).

9.5 Proxy PPP Authentication (代理 PPP 认证)

L2TP 允许 LAC 代表 LNS 进行初始的 PPP 认证.

代理认证机制 (Proxy Authentication Mechanism):

LAC 可以在转发呼叫到 LNS 之前与远程系统协商 LCP 和进行认证:

LAC 执行 PPP 认证:
- LAC 与远程系统协商 LCP.
- LAC 执行 PAP 或 CHAP 认证.
- LAC 收集认证信息(用户名、密码哈希等).
LAC 转发认证信息到 LNS:
- 使用代理 AVP 传递认证信息:
  - Proxy Authen Type AVP (29): 认证类型(PAP, CHAP, etc.)
  - Proxy Authen Name AVP (30): 用户名
  - Proxy Authen Challenge AVP (31): CHAP 挑战值
  - Proxy Authen Response AVP (33): 认证响应
LNS 验证认证信息:
- LNS 根据 LAC 提供的信息验证用户.
- LNS 可以接受或拒绝会话.

安全风险 (Security Risks):

LAC 妥协 (LAC Compromise):
- 如果 LAC 被攻破,攻击者可以获取用户凭证.
- 缓解: 使用 IPsec 保护 LAC 和 LNS 之间的通信.
密码明文传输 (Cleartext Password Transmission):
- PAP 密码以明文形式从 LAC 传到 LNS(在 AVP 中).
- 缓解: 使用 AVP 隐藏机制或 IPsec 加密.
信任边界 (Trust Boundary):
- LNS 必须完全信任 LAC 提供的认证信息.
- 恶意的 LAC 可以伪造认证信息.
- 缓解:
  - 只在受信任的管理域之间使用代理认证.
  - 考虑要求端到端的重新认证.

最佳实践 (Best Practices):

避免代理 PAP 认证:
- PAP 密码即使被隐藏也容易受到攻击.
- 如果必须使用,确保使用 IPsec 保护.
优先使用端到端认证:
- 让远程系统直接与 LNS 进行认证(不通过代理).
- 使用 EAP 方法提供更强的安全性.
限制代理认证的使用场景:
- 仅在必要时使用(如快速呼叫建立).
- 在受信任的网络环境中使用.
结合使用多种认证方法:
- LAC 进行初步认证(用于快速筛选).
- LNS 进行二次认证(端到端验证).

代理认证与 RADIUS 集成 (Proxy Authentication with RADIUS):

远程系统 &lt;--PAP/CHAP--> LAC &lt;--RADIUS--> RADIUS服务器
                         |
                         |
                         v
                   (转发认证信息)
                         |
                         v
                        LNS &lt;--RADIUS--> RADIUS服务器

LAC 可以使用 RADIUS 验证用户凭证.
LNS 也可以独立地使用 RADIUS 验证.
双重验证提供了额外的安全层.

安全配置检查清单 (Security Configuration Checklist):

10. IANA Considerations (IANA 考虑事项)

本章定义了 L2TP 协议需要 IANA(Internet Assigned Numbers Authority,互联网号码分配机构)分配和管理的各种参数.

10.1 AVP Attributes (AVP 属性)

IANA 负责维护 L2TP AVP 属性类型注册表.AVP 属性类型是一个 16 位字段.

注册要求 (Registration Requirements):

值范围 0-1023: 由 IETF 共识分配(需要发布 RFC).
值范围 1024-65535: 采用"先到先得"(First Come First Served)策略分配.

已分配的标准 AVP 属性类型 (Assigned Standard AVP Attribute Types):

属性类型	AVP 名称	引用
0	Message Type	RFC 2661 Section 4.4.1
1	Result Code	RFC 2661 Section 4.4.2
2	Protocol Version	RFC 2661 Section 4.4.3
3	Framing Capabilities	RFC 2661 Section 4.4.3
4	Bearer Capabilities	RFC 2661 Section 4.4.3
5	Tie Breaker	RFC 2661 Section 4.4.3
6	Firmware Revision	RFC 2661 Section 4.4.3
7	Host Name	RFC 2661 Section 4.4.3
8	Vendor Name	RFC 2661 Section 4.4.3
9	Assigned Tunnel ID	RFC 2661 Section 4.4.3
10	Receive Window Size	RFC 2661 Section 4.4.3
11	Challenge	RFC 2661 Section 4.4.3
12	Q.931 Cause Code	RFC 2661 Section 4.4.4
13	Challenge Response	RFC 2661 Section 4.4.3
14	Assigned Session ID	RFC 2661 Section 4.4.4
15	Call Serial Number	RFC 2661 Section 4.4.4
16	Minimum BPS	RFC 2661 Section 4.4.4
17	Maximum BPS	RFC 2661 Section 4.4.4
18	Bearer Type	RFC 2661 Section 4.4.4
19	Framing Type	RFC 2661 Section 4.4.4
20	Packet Processing Delay	RFC 2661 Section 4.4.6
21	Called Number	RFC 2661 Section 4.4.4
22	Calling Number	RFC 2661 Section 4.4.4
23	Sub-Address	RFC 2661 Section 4.4.4
24	(Tx) Connect Speed	RFC 2661 Section 4.4.4
25	Physical Channel ID	RFC 2661 Section 4.4.4
26	Initial Received LCP CONFREQ	RFC 2661 Section 4.4.5
27	Last Sent LCP CONFREQ	RFC 2661 Section 4.4.5
28	Last Received LCP CONFREQ	RFC 2661 Section 4.4.5
29	Proxy Authen Type	RFC 2661 Section 4.4.5
30	Proxy Authen Name	RFC 2661 Section 4.4.5
31	Proxy Authen Challenge	RFC 2661 Section 4.4.5
32	Proxy Authen ID	RFC 2661 Section 4.4.5
33	Proxy Authen Response	RFC 2661 Section 4.4.5
34	Call Errors	RFC 2661 Section 4.4.6
35	ACCM	RFC 2661 Section 4.4.6
36	Random Vector	RFC 2661 Section 4.3
37	Private Group ID	RFC 2661 Section 4.4.4
38	(Rx) Connect Speed	RFC 2661 Section 4.4.4
39	Sequencing Required	RFC 2661 Section 4.4.4

Vendor-Specific AVPs:

供应商特定的 AVP 使用 Vendor ID 字段(基于 SMI 网络管理私有企业代码)来区分不同供应商的扩展.

10.2 Message Type AVP Values (消息类型 AVP 值)

消息类型 AVP(属性类型 0)的值用于标识 L2TP 控制消息的类型.

已分配的消息类型值 (Assigned Message Type Values):

值	消息类型	缩写	引用
0	(Reserved)
1	Start-Control-Connection-Request	SCCRQ	RFC 2661 Section 6.1
2	Start-Control-Connection-Reply	SCCRP	RFC 2661 Section 6.2
3	Start-Control-Connection-Connected	SCCCN	RFC 2661 Section 6.3
4	Stop-Control-Connection-Notification	StopCCN	RFC 2661 Section 6.4
5	(Reserved)
6	Hello	HELLO	RFC 2661 Section 6.5
7	Outgoing-Call-Request	OCRQ	RFC 2661 Section 6.9
8	Outgoing-Call-Reply	OCRP	RFC 2661 Section 6.10
9	Outgoing-Call-Connected	OCCN	RFC 2661 Section 6.11
10	Incoming-Call-Request	ICRQ	RFC 2661 Section 6.6
11	Incoming-Call-Reply	ICRP	RFC 2661 Section 6.7
12	Incoming-Call-Connected	ICCN	RFC 2661 Section 6.8
13	(Reserved)
14	Call-Disconnect-Notify	CDN	RFC 2661 Section 6.12
15	WAN-Error-Notify	WEN	RFC 2661 Section 6.13
16	Set-Link-Info	SLI	RFC 2661 Section 6.14

注册策略 (Registration Policy):

新的消息类型值的分配需要发布 IETF 标准轨道 RFC 或经过 IESG 批准的信息性 RFC.

10.3 Result Code AVP Values (结果代码 AVP 值)

Result Code AVP(属性类型 1)用于指示控制连接或会话终止的原因.

10.3.1 Result Code Field Values (结果代码字段值)

通用结果代码 (General Result Codes):

值	含义	适用范围
0	Reserved
1	General request to clear control connection	StopCCN
2	General error	StopCCN, CDN
3	Control channel already exists	StopCCN
4	Requester is not authorized	StopCCN
5	Protocol version not supported	StopCCN
6	Requester is being shut down	StopCCN
7	Finite State Machine error	StopCCN

呼叫断开结果代码 (Call Disconnect Result Codes):

值	含义	适用范围
1	Lost carrier	CDN
2	General error	CDN
3	Administrative reason	CDN
4	Temporary lack of appropriate facilities	CDN
5	Permanent lack of appropriate facilities	CDN
6	Invalid destination	CDN
7	No carrier detected	CDN
8	Busy signal	CDN
9	No dial tone	CDN
10	Timeout waiting for carrier	CDN
11	No framing detected	CDN

10.3.2 Error Code Field Values (错误代码字段值)

错误代码字段提供了关于错误的额外细节信息.

值	错误消息
0	No general error
1	No control connection exists yet for this pair
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 (LNS/LAC)
8	Session or tunnel was shutdown due to receipt of an unknown AVP with M-bit set

注册策略:

新的结果代码值和错误代码值需要通过 IETF 共识(需要发布 RFC)进行分配.

10.4 Framing Capabilities & Bearer Capabilities (帧能力和承载能力)

Framing Capabilities AVP(属性类型 3)和 Bearer Capabilities AVP(属性类型 4)使用位掩码来指示支持的能力.

Framing Capabilities 位定义 (Framing Capabilities Bit Definitions):

位	含义
0	Asynchronous Framing supported
1	Synchronous Framing supported
2-31	Reserved

Bearer Capabilities 位定义 (Bearer Capabilities Bit Definitions):

位	含义
0	Analog access supported
1	Digital access supported
2-31	Reserved

注册策略:

新的能力位的分配需要通过 IETF 共识(需要发布 RFC)进行分配.

10.5 Proxy Authen Type AVP Values (代理认证类型 AVP 值)

Proxy Authen Type AVP(属性类型 29)用于指示 LAC 使用的认证类型.

已分配的认证类型值 (Assigned Authen Type Values):

值	认证类型	引用
0	Reserved
1	Textual username/password exchange	RFC 1334 (PAP)
2	PPP CHAP	RFC 1994
3	PPP PAP	RFC 1334
4	No Authentication
5	Microsoft CHAP Version 1	RFC 2433
6	Reserved
7	Microsoft CHAP Version 2	RFC 2759

注册策略:

新的认证类型值的分配采用"先到先得"(First Come First Served)策略.

10.6 AVP Header Bits (AVP 头部位)

AVP 头部的前 6 位用作位掩码来控制 AVP 的行为.

已定义的 AVP 头部位 (Defined AVP Header Bits):

位	名称	含义	引用
0	M (Mandatory)	必须理解此 AVP	RFC 2661 Section 4.1
1	H (Hidden)	AVP 值被隐藏	RFC 2661 Section 4.3
2-5	Reserved	保留,必须设置为 0	RFC 2661 Section 4.1

注册策略:

保留位的分配需要通过标准行动(Standards Action)- 即发布 IETF 标准轨道 RFC.

10.7 L2TP UDP Port (L2TP UDP 端口)

已分配端口 (Assigned Port):

端口号: 1701
协议: UDP
用途: L2TP
引用: RFC 2661

IANA 已经为 L2TP 分配了 UDP 端口 1701 用于控制连接和数据会话.

10.8 L2TP Protocol Number (L2TP 协议号)

虽然当前规范定义 L2TP 在 UDP 上运行,但 L2TP 也可以直接在其他数据包传输协议上运行.

IP 协议号:

L2TP 协议号: 115
名称: L2TP
引用: RFC 3931(L2TPv3,直接在 IP 上)

IANA 注册表维护 (IANA Registry Maintenance):

IANA 维护以下 L2TP 相关的注册表:

L2TP AVP Attributes Registry
- URL: https://www.iana.org/assignments/l2tp-parameters/
L2TP Message Types Registry
- 包含所有控制消息类型
L2TP Result Codes Registry
- 包含结果代码和错误代码
L2TP Proxy Authen Types Registry
- 包含认证类型值
L2TP Ports and Protocol Numbers
- UDP 端口和 IP 协议号分配

更新和扩展 (Updates and Extensions):

后续的 RFC 可能会定义新的 AVP、消息类型或其他参数.所有新的分配必须遵循本节定义的注册策略.

重要的扩展包括:

RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
RFC 4591: Frame Relay over L2TP
RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration

11. References (参考文献)

本节列出了 RFC 2661 中引用的所有规范性和参考性文献.

11.1 Normative References (规范性参考文献)

规范性参考文献是实现 L2TP 协议所必需的文档.

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

中文标题: 点对点协议(PPP)
说明: 定义了 L2TP 隧道传输的 PPP 帧的基本格式和协商过程.

[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

中文标题: HDLC 类帧格式中的 PPP
说明: 定义了 PPP 帧在 HDLC 类链路上的封装方法.

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

中文标题: 已分配的号码
说明: IANA 号码分配参考(已被在线 IANA 注册表取代).

[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

中文标题: PPP 多链路协议(MP)
说明: 定义了多个物理链路捆绑为单个逻辑链路的机制.

[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

中文标题: PPP 挑战握手认证协议(CHAP)
说明: L2TP 代理认证中使用的认证协议.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

中文标题: RFC 中用于指示需求级别的关键词
说明: 定义了 "MUST"、"SHOULD"、"MAY" 等关键词的含义.

[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

中文标题: Cisco 第二层转发协议(L2F)
说明: L2TP 的前身协议,用于版本检测.

11.2 Informative References (参考性参考文献)

参考性参考文献提供了背景信息和相关协议的说明.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

中文标题: 互联网协议(IPv4)
说明: 定义了 IPv4 协议,L2TP 可以在其上运行.

[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.

中文标题: PPP 认证协议
说明: 定义了 PAP(密码认证协议).

[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

中文标题: 远程认证拨号用户服务(RADIUS)
说明: 用于集中式认证、授权和计费的协议.

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

中文标题: IETF 字符集和语言政策
说明: 关于国际化文本处理的指导方针.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

中文标题: 互联网协议安全架构
说明: 定义了 IPsec 架构,推荐与 L2TP 结合使用.

[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.

中文标题: Microsoft PPP CHAP 扩展
说明: MS-CHAPv1 协议定义.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

中文标题: 互联网协议版本 6(IPv6)规范
说明: 定义了 IPv6 协议,L2TP 可以在其上运行.

[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.

中文标题: Microsoft PPP CHAP 扩展版本 2
说明: MS-CHAPv2 协议定义.

[KPS] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: Private Communication in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.

中文标题: 网络安全:公共世界中的私密通信
说明: AVP 隐藏机制的密码学基础参考书籍.

以下是与 L2TP 相关但不直接引用的重要标准:

L2TP 演进版本:

RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
- L2TP 的第三版,支持非 PPP 数据帧的隧道传输
RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration
- L2TP 访问集中器配置协议

IPsec 相关:

RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409: The Internet Key Exchange (IKE)
RFC 4306: Internet Key Exchange (IKEv2) Protocol
RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE)

PPP 扩展:

RFC 2637: Point-to-Point Tunneling Protocol (PPTP)
RFC 3748: Extensible Authentication Protocol (EAP)
RFC 5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

QoS 和流量管理:

RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2475: An Architecture for Differentiated Services

11.4 Standards Organizations (标准组织)

IETF (Internet Engineering Task Force)

Website: https://www.ietf.org/
L2TP Working Group Archive: https://datatracker.ietf.org/wg/l2tpext/

IANA (Internet Assigned Numbers Authority)

Website: https://www.iana.org/
L2TP Parameters Registry: https://www.iana.org/assignments/l2tp-parameters/

IEEE (Institute of Electrical and Electronics Engineers)

Standards related to Layer 2 technologies

ITU-T (International Telecommunication Union - Telecommunication Standardization Sector)

Q.931: ISDN signaling (referenced in Q.931 Cause Code AVP)

11.5 Historical Context (历史背景)

L2TP 协议是以下两个协议的融合:

L2F (Layer 2 Forwarding Protocol) - Cisco Systems 开发
- RFC 2341
PPTP (Point-to-Point Tunneling Protocol) - Microsoft 等公司开发
- RFC 2637

L2TP 结合了这两个协议的优点,成为 IETF 标准轨道协议.

11.6 Further Reading (延伸阅读)

技术书籍:

"VPN and NAT Traversal" by Gurdeep Singh Pall and Glen Zorn
"Understanding Virtual Private Networks" by Rod Rhoton
"Virtual Private Networks: Technologies and Solutions" by Ruixi Yuan and W. Timothy Strayer

在线资源:

IETF L2TP Charter: https://datatracker.ietf.org/wg/l2tpext/charter/
L2TP/IPsec Configuration Guides (vendor-specific)
Network Security Best Practices Documentation

引用格式说明 (Citation Format Notes):

在本文档中,对 RFC 的引用使用 [RFCXXXX] 格式,其中 XXXX 是 RFC 编号.对其他文档的引用使用方括号中的简短标识符(如 [KPS]).

完整的 RFC 文档可以从以下来源获取:

IETF RFC Editor: https://www.rfc-editor.org/
IETF Datatracker: https://datatracker.ietf.org/

12. Acknowledgments (致谢)

RFC 2661 的作者感谢 IETF L2TP 工作组的所有成员对本规范开发所做的贡献.

主要贡献者 (Major Contributors)

本协议的开发得益于许多个人和组织的技术贡献,特别感谢以下贡献者:

Cisco Systems 的工程团队,特别是 L2F 协议的原始开发者
Microsoft Corporation 的工程团队,特别是 PPTP 协议的贡献者
Ascend Communications 和 Redback Networks 的技术专家

工作组成员 (Working Group Members)

L2TP 工作组的讨论和技术审查对本规范的质量至关重要.特别感谢参与邮件列表讨论、提供实现反馈和进行互操作性测试的所有成员.

技术审查 (Technical Review)

感谢以下人员对本文档草案的详细技术审查和建设性意见:

网络安全专家对安全性章节的审查
PPP 和隧道协议专家的协议设计建议
IANA 代表对参数分配章节的指导

编辑支持 (Editorial Support)

感谢 RFC 编辑团队在文档格式、术语一致性和技术表述清晰度方面提供的专业支持.

注释: 完整的贡献者名单和组织列表可参见 RFC 2661 原始文档的致谢章节.

13. Authors' Addresses (作者地址)

本节列出了 RFC 2661 的主要作者及其联系信息(截至文档发布时).

W. Mark Townsley

Cisco Systems

Email: [email protected]
Website: https://www.townsley.net/

贡献: 主要编辑和技术协调

Allan Valencia

Cisco Systems

Email: [email protected]

贡献: 协议设计和 L2F 集成

Ascend Communications 代表

Andrew Rubens

Email: [email protected]

贡献: 控制协议和 AVP 设计

Microsoft Corporation 代表

Gurdeep Singh Pall

Email: [email protected]

贡献: PPTP 协议集成和安全机制

Microsoft Corporation 代表

Glen Zorn

Email: [email protected]

贡献: 认证协议和安全性设计

Redback Networks 代表

Bernard Palter

Email: [email protected]

贡献: 协议实现和互操作性测试

注意事项 (Notes):

上述联系信息为文档发布时(1999年8月)的信息.
某些电子邮件地址可能已失效.
有关 L2TP 协议的最新问题和讨论,请参考 IETF L2TP 工作组邮件列表.
当前的 L2TP 标准维护和扩展工作由 IETF 继续进行.

联系方式更新:

如需了解 L2TP 协议的最新信息或报告问题,请访问:

IETF Datatracker: https://datatracker.ietf.org/doc/rfc2661/
L2TP 工作组: https://datatracker.ietf.org/wg/l2tpext/

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 概述 (Overview)

L2TP 控制通道采用可靠的消息传输机制.为了防止网络拥塞,建议实现类似 TCP 的慢启动和拥塞避免算法.

A.2 慢启动算法 (Slow Start Algorithm)

初始参数:

初始拥塞窗口 (cwnd): 1 个消息
慢启动阈值 (ssthresh): 接收窗口大小

算法步骤:

每收到一个 ACK,cwnd 增加 1
当 cwnd >= ssthresh 时,进入拥塞避免阶段
发送的未确认消息数不超过 min(cwnd, 接收窗口)

A.3 拥塞避免 (Congestion Avoidance)

退避策略:

检测到超时时:ssthresh = max(cwnd/2, 2)
重置 cwnd = 1,重新开始慢启动

往返时间估计 (RTT Estimation):

采用 Jacobson/Karels 算法计算重传超时 (RTO)
平滑 RTT = (1-α) × 平滑RTT + α × 测量RTT
RTO = 平滑RTT + 4 × RTT偏差

Appendix C: Intellectual Property Notice

C.1 知识产权声明 (IP Statement)

IETF 对本文档中描述的技术的任何知识产权或其他权利的有效性或范围,以及这些权利下的任何许可可能或可能不可用的程度不持任何立场;它也不表示它已经做出任何努力来识别任何此类权利.

C.2 专利声明 (Patent Disclosure)

根据 RFC 2026 第 10.4 节的要求,已披露的与本规范相关的知识产权信息可在 IETF 网站上查询.

C.3 许可信息 (Licensing Information)

实现者应注意,某些 L2TP 功能可能受到专利保护.IETF 不负责识别此类专利或评估任何专利声明的有效性或范围.

相关链接:

IETF IPR Disclosures: https://datatracker.ietf.org/ipr/
RFC 2026 Section 10: https://www.rfc-editor.org/rfc/rfc2026.html

Abstract (摘要)​

Table of Contents (目录)​

1. Introduction (简介)​

2-3. Topology and Protocol Overview (拓扑与协议概述)​

4. Control Message Attribute Value Pairs (控制消息属性值对)​

5. Protocol Operation (协议操作)​

6-7. Control Connection Protocol (控制连接协议)​

8-10. Media, Security and IANA (媒体、安全与 IANA)​

11-13. References and Appendices (参考文献与附录)​

Appendices (附录)​

核心术语 (Key Terminology)​

协议概述​

相关资源​

7. Control Connection State Machines (控制连接状态机)​

7.1 Control Connection Protocol Operation (控制连接协议操作)​

7.2 Control Connection States (控制连接状态)​

7.2.1 Control Connection Establishment (控制连接建立)​

7.3 Timing Considerations (时序考虑)​

7.4 Incoming Calls (传入呼叫)​

7.4.1 LAC Incoming Call States (LAC 传入呼叫状态)​

7.4.2 LNS Incoming Call States (LNS 传入呼叫状态)​

7.5 Outgoing Calls (传出呼叫)​

7.5.1 LAC Outgoing Call States (LAC 传出呼叫状态)​

7.5.2 LNS Outgoing Call States (LNS 传出呼叫状态)​

7.6 Tunnel Disconnection (隧道断开)​

8. L2TP Over Specific Media (特定媒体上的 L2TP)​

8.1 L2TP over UDP/IP​

8.2 IP​

9. Security Considerations (安全性考虑)​

9.1 Tunnel Endpoint Security (隧道端点安全)​

9.2 Packet Level Security (数据包级安全)​

9.3 End to End Security (端到端安全)​

9.4 L2TP and IPsec (L2TP 与 IPsec)​

9.5 Proxy PPP Authentication (代理 PPP 认证)​

10. IANA Considerations (IANA 考虑事项)​

10.1 AVP Attributes (AVP 属性)​

10.2 Message Type AVP Values (消息类型 AVP 值)​

10.3 Result Code AVP Values (结果代码 AVP 值)​

10.3.1 Result Code Field Values (结果代码字段值)​

10.3.2 Error Code Field Values (错误代码字段值)​

10.4 Framing Capabilities & Bearer Capabilities (帧能力和承载能力)​

10.5 Proxy Authen Type AVP Values (代理认证类型 AVP 值)​

10.6 AVP Header Bits (AVP 头部位)​

10.7 L2TP UDP Port (L2TP UDP 端口)​

10.8 L2TP Protocol Number (L2TP 协议号)​

11. References (参考文献)​

11.1 Normative References (规范性参考文献)​

11.2 Informative References (参考性参考文献)​

11.3 Related Standards (相关标准)​

11.4 Standards Organizations (标准组织)​

11.5 Historical Context (历史背景)​

11.6 Further Reading (延伸阅读)​

12. Acknowledgments (致谢)​

主要贡献者 (Major Contributors)​

工作组成员 (Working Group Members)​

技术审查 (Technical Review)​

编辑支持 (Editorial Support)​

13. Authors' Addresses (作者地址)​

W. Mark Townsley​

Allan Valencia​

Ascend Communications 代表​

Microsoft Corporation 代表​

Microsoft Corporation 代表​

Redback Networks 代表​

Appendix A: Control Channel Slow Start and Congestion Avoidance​

A.1 概述 (Overview)​

A.2 慢启动算法 (Slow Start Algorithm)​

A.3 拥塞避免 (Congestion Avoidance)​

Appendix C: Intellectual Property Notice​

C.1 知识产权声明 (IP Statement)​

C.2 专利声明 (Patent Disclosure)​

C.3 许可信息 (Licensing Information)​

Abstract (摘要)

Table of Contents (目录)

1. Introduction (简介)

2-3. Topology and Protocol Overview (拓扑与协议概述)

4. Control Message Attribute Value Pairs (控制消息属性值对)

5. Protocol Operation (协议操作)

6-7. Control Connection Protocol (控制连接协议)

8-10. Media, Security and IANA (媒体、安全与 IANA)

11-13. References and Appendices (参考文献与附录)

Appendices (附录)

核心术语 (Key Terminology)

协议概述

相关资源

7. Control Connection State Machines (控制连接状态机)

7.1 Control Connection Protocol Operation (控制连接协议操作)

7.2 Control Connection States (控制连接状态)

7.2.1 Control Connection Establishment (控制连接建立)

7.3 Timing Considerations (时序考虑)

7.4 Incoming Calls (传入呼叫)

7.4.1 LAC Incoming Call States (LAC 传入呼叫状态)

7.4.2 LNS Incoming Call States (LNS 传入呼叫状态)

7.5 Outgoing Calls (传出呼叫)

7.5.1 LAC Outgoing Call States (LAC 传出呼叫状态)

7.5.2 LNS Outgoing Call States (LNS 传出呼叫状态)

7.6 Tunnel Disconnection (隧道断开)

8. L2TP Over Specific Media (特定媒体上的 L2TP)

8.1 L2TP over UDP/IP

8.2 IP

9. Security Considerations (安全性考虑)

9.1 Tunnel Endpoint Security (隧道端点安全)

9.2 Packet Level Security (数据包级安全)

9.3 End to End Security (端到端安全)

9.4 L2TP and IPsec (L2TP 与 IPsec)

9.5 Proxy PPP Authentication (代理 PPP 认证)

10. IANA Considerations (IANA 考虑事项)

10.1 AVP Attributes (AVP 属性)

10.2 Message Type AVP Values (消息类型 AVP 值)

10.3 Result Code AVP Values (结果代码 AVP 值)

10.3.1 Result Code Field Values (结果代码字段值)

10.3.2 Error Code Field Values (错误代码字段值)

10.4 Framing Capabilities & Bearer Capabilities (帧能力和承载能力)

10.5 Proxy Authen Type AVP Values (代理认证类型 AVP 值)

10.6 AVP Header Bits (AVP 头部位)

10.7 L2TP UDP Port (L2TP UDP 端口)

10.8 L2TP Protocol Number (L2TP 协议号)

11. References (参考文献)

11.1 Normative References (规范性参考文献)

11.2 Informative References (参考性参考文献)

11.3 Related Standards (相关标准)

11.4 Standards Organizations (标准组织)

11.5 Historical Context (历史背景)

11.6 Further Reading (延伸阅读)

12. Acknowledgments (致谢)

主要贡献者 (Major Contributors)

工作组成员 (Working Group Members)

技术审查 (Technical Review)

编辑支持 (Editorial Support)

13. Authors' Addresses (作者地址)

W. Mark Townsley

Allan Valencia

Ascend Communications 代表

Microsoft Corporation 代表

Microsoft Corporation 代表

Redback Networks 代表

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 概述 (Overview)

A.2 慢启动算法 (Slow Start Algorithm)

A.3 拥塞避免 (Congestion Avoidance)

Appendix C: Intellectual Property Notice

C.1 知识产权声明 (IP Statement)

C.2 专利声明 (Patent Disclosure)

C.3 许可信息 (Licensing Information)