摘要

  • RFC 3355 把 L2TP 映射到 ATM AAL5 虚电路，但要求每个 L2TP PDU 必须完整装入一个 AAL5 PDU；外层 MTU 因而限制隧道和所有共享它的 PPP 会话。
  • 封装选择、虚电路建立、安全与清除仍是承载层事实。成功选择格式不证明内部会话或交付，而 SVC 被清除会终止隧道里的用户会话。

一个 PPP 用户看到的是点到点连接。它不会看到 ATM 交换机怎样建立虚电路，也不会看到 AAL5 怎样把数据排入外层消息。正因为这些细节被隐藏，隧道才有价值。但用户发出的每个完整单元，最后仍必须穿过一个有限的外层孔径。看不见的限制没有消失。

2002 年 8 月发布的 RFC 3355 是 Standards Track 文档，规定 Layer Two Tunnelling Protocol 如何运行在 ATM Adaptation Layer 5 上。L2TP 基础规范称，协议应尽量不依赖隧道媒介的细节，只要求一种面向分组的点到点连接。LAC 与 LNS 之间的 AAL5 虚电路能够提供这种服务。

映射中最关键的句子是：每个 L2TP PDU 必须由一个 AAL5 PDU 传输。按照这份规范，L2TP 单元不能跨多个 AAL5 消息再由上层假装它从未被分开。因此，AAL5 连接的 MTU 会限制 L2TP 隧道的 MTU，并进一步限制所有使用该隧道的 PPP 连接的 MRU。

这条链让共享依赖变得清楚。逻辑上相互独立的多个用户会话，可以各自有认证、地址和状态；物理意义上，它们仍共用同一外层信封。隧道把 ATM 的形状从视野里移走，却不能创造比虚电路更大的空间。

RFC 3355 要求实现至少支持 1500 字节的 PPP MRU，并建议支持把至少 9180 字节的 IP 包放进 PPP PDU。这里的“支持”与“建议”描述实现能力和设计目标，不是某条生产路径的观测收据。PVC 可能按更小参数配置，SVC 可能在建立时获得不同参数，PPP 对端也可能协商更小的 MRU。

因此，“设备支持 9180”不能证明某个 9180 字节包已经通过。还需要知道外层头部、实际 VC 参数、PPP 协商值、中间约束、分片和丢弃情况。小探针成功也不能替大包作证。

RFC 对 AAL5 服务有严格描述：L2TP 把它视为比特同步、全双工、点到点链路；对应 VC 可以是人工配置的永久虚电路，也可以是按需建立的交换虚电路。必须采用非保证模式的 AAL5 message mode，并且不使用损坏数据交付选项。边界只接受和提供完整字节。

这些属性保证了封装语义，却没有提供可靠交付。长度与 CRC 可以确认一个收到的 AAL5 单元在该层符合框架，不能证明发送者身份、机密性、L2TP 控制平面接受或应用接收。信封完好只是一个现实层。

外层怎样说明“里面是什么”，有两条路线。LLC/SNAP 封装在每个 AAL5 PDU 里明确携带 L2TP 的 IANA 标识。VC multiplexing 则省略这段逐包标签，因为两端已经通过配置或控制平面约定该虚电路只承载 L2TP。一个把身份写进包，一个把身份放在连接上下文。

RFC 3355 要求 PVC 必须支持 LLC 封装；SVC 上的 LLC，以及 PVC 或 SVC 上的 VC multiplexing 都是可选能力。使用 PVC 时，两端必须配置成相同方式。两台设备都“支持 L2TP”，也可能因为虚电路上下文不一致而无法解释同一串字节。

SVC 把这项约定交给 ATM 控制平面。呼叫方用 B-LLI 信息元素提出 LLC、VC multiplexing，或按偏好顺序提出两者。若两种方式都被提出且呼叫获接受，被叫方必须只选一种；如果只提出了不受支持的方式，请求必须被拒绝。

成功协商证明的是一个有限事实：这次连接建立选择了哪一种 AAL5 负载解释方式。它没有证明 L2TP 控制连接随后建立、PPP 用户通过认证、包尺寸适配、数据到达或应用成功。外层语法被选中，内部生命周期才刚开始。

重置规则最能说明隐藏承载层仍握有权力。若一个以 SVC 为承载的 L2TP 隧道按基础协议重置，两端都必须清除 SVC，隧道中的所有用户会话都会终止。新客户请求可以触发以后重新建立，但那是新一次尝试，不是旧会话无缝延续。

反方向也一样：收到 AAL5 SVC 已被清除的通知，实现必须拆除 L2TP 隧道，让控制连接回到 idle。底层事件穿透抽象，改变上层状态。承载层不是可以无痕替换的背景。

连接建立失败后，呼叫方可以把对端视为不可达；什么时候这样判断、以后怎样确认恢复，都由实现决定。没有活跃会话时，两端还可以选择清除 SVC。因此“不可达”“空闲”“已清除”必须带来源：哪个状态机观察、哪一事件触发、属于哪一代连接。

服务质量也不能摆脱证据边界。为了给不同客户不同 QoS，可以在 LAC 和 LNS 之间使用多个 AAL5 连接；把同一隧道反向复用到多个 VC 上则留待继续研究。PVC 参数由双方约定，SVC 参数由呼叫方请求。配置或请求是一项意图，不是实际吞吐和时延的证明。

正确封装也不等于安全。RFC 3355 警告，针对 ATM 传输网络的攻击可能损害 L2TP-over-AAL5 隧道，建议使用认证头、加密载荷或 ATM 层安全服务。正确 PID、B-LLI 选择和 CRC 都不能代替加密认证。

相邻规范分别拥有自己的层。RFC 2661 定义 L2TP 隧道与会话；RFC 1661 定义 PPP 及 MRU；RFC 2684 定义 AAL5 上的 LLC/SNAP 与 VC multiplexing；RFC 2364 处理 PPP 直接运行在 AAL5 上；RFC 2331 提供 ATM 信令背景。RFC 3070 是 L2TP over Frame Relay，不能把它的承载细节套进 AAL5。RFC 3193 增加 IPsec 状态，RFC 4459 后来把隧道 MTU 与分片作为更广泛问题讨论。

IANA L2TP 参数注册表保存协调值。值被登记，只证明它有受控含义，不证明任何设备实现、任何 VC 传输或任何会话存活。上述来源也不证明 RFC 3355 的实际部署、规模、事故或性能。

RFC 3355 留下的是抽象工程的诚实版本。抽象能让上层免于处理底层机器，却不能废除底层的有限资源与生命周期。L2TP 可以隐藏 ATM；AAL5 虚电路仍决定一个信封能装多大、两端如何识别它，以及承载消失时哪些会话一起消失。

Sources