摘要

  • RFC 3070 要让 PPP 会话经由帧中继传输，就必须明确 L2TP 的协议识别方式、隧道与 PVC 或 SVC 的对应关系、电路端点以及可容纳的报文尺寸。
  • 规范把可移植的隧道和会话，与真正承载它们的电路分成两种事实；开通、服务质量、安全和用户结果仍分别由其他主体掌握。

一份短规范揭开的“大独立”错觉

2001 年 2 月发布的 RFC 3070，规定了如何在帧中继上承载第二层隧道协议 L2TP。它篇幅不长，主题也带有拨号接入和运营商虚电路时代的色彩。然而它提出的问题并未过时：所谓“与介质无关”，到底独立到了哪一层？

L2TP 可以让一条 PPP 会话从靠近用户的 L2TP 接入集中器（LAC）出发，在逻辑上终止于 L2TP 网络服务器（LNS）。隧道让会话不必理解中间网络的所有细节。但真实报文不会因为上层宣称自己不依赖介质，就自动跨过帧中继。仍然要有人建立虚电路、确定两端、指定封装方法，并保证帧足够大。

所以 RFC 3070 证明的不是介质已经消失，而是一种介质如何履行支撑抽象层的契约。

会话标识不是电路凭证

RFC 2661 已经区分了 L2TP 控制连接与隧道内复用的各条会话。隧道标识和会话标识属于 LAC 与 LNS 之间的协议关系。帧中继却有另一套对象：永久虚电路 PVC 通常在本地由数据链路连接标识符 DLCI 识别；交换虚电路 SVC 则通过信令建立，并可能使用 X.121 或 E.164 地址。

这些身份可以建立关联，却不能互相代替。L2TP 隧道号不会替运营商开通电路；一个 DLCI 不说明电路里承载的是哪位用户的 PPP 会话；能被 SVC 呼叫的地址，也不证明远端 LNS 获得了接收该用户流量的授权。

RFC 3070 对两类映射的处理把差别写得很清楚。对于 SVC，创建 L2TP 隧道会触发建立帧中继电路，但具体触发机制由实现决定，原有帧中继信令流程也不被这份 RFC 重写。对于 PVC，L2TP 两端之间的电路需要预先进行管理配置。DLCI 可以来自本地配置，也可以由授权系统提供，其中包括 RFC 2868 所定义的 RADIUS 隧道属性。

“隧道已经起来了”只是一个便于交流的简写。完整事实至少包括一次控制动作、一项授权判断，以及它们与某条承载电路的对应关系。

介质无关，要靠一个高度介质相关的编号

L2TP 必须能与其他协议共享同一条帧中继虚电路，因此接收方需要无歧义地识别到来的数据。RFC 3070 规定使用 Q.922 地址，随后是 SNAP 头：NLPID 为 0x80，IANA 的组织唯一标识为 0x00-00-5E，L2TP 的协议标识为 0x0007。

这些数字不只是注册表里的小知识，而是两套系统之间公开且可检验的接缝。缺少它们，承载层当然仍能搬运字节，却无法可靠地区分同一电路上的 L2TP 与其他协议。上层之所以显得可移植，正是因为下层获得了一个精确而且专属于该介质的标签。

RFC 1490 及其后继 RFC 2427 提供了更广泛的多协议封装框架。RFC 3070 没有替代那套机制，而是在其中占据一个被登记的位置。这是互联网架构里反复出现的模式：上层通过依赖一个更窄、更稳定的下层接口获得自由。依赖被缩小、被看见、被测试，但并没有归零。

被剥掉的链路外壳也带走了证据

PPP 帧进入 L2TP 之前，物理层成帧、透明传输机制和帧校验序列都会被移除，然后才封装 PPP 载荷。远端无需复现接入链路上的每个电气或链路标记，这正是抽象的价值。不过，之后看到的 L2TP 报文也不再保存完整的物理经历。

运维人员可以核验还留在报文和状态中的隧道与会话信息，却不能仅凭这些内容推断原始接入线质量、具体成帧方式，或封装之前发生过什么差错。抽象边界不仅改变执行方式，也改变了可获得的证据。

报文尺寸是另一项无法消失的后果。RFC 3070 计算出：如果帧中继不做分片，为承载最低合规的 L2TP 数据报，网络至少需要支持 1,526 字节；如果 PPP 对端采用常见的 1,500 字节最大接收单元，则建议支持 1,564 字节。至于实现怎样协商或强制这些限制，规范留给了具体产品。

于是控制面可以显示隧道成功，而真实用户报文仍因 MTU 失败。协议设计上的独立，并不是端到端送达的证明。

规范在服务质量与信任之前停下

RFC 3070 没有为这项映射制定服务质量标准。它承认厂商存在专有方案，也提到未来的通用标准可能适用。安全方面，它指出当时帧中继没有适用于此场景的标准机制，并把读者引回 L2TP 自身的安全考虑。

这两处留白是诚实的权限边界，并不表示时延、丢包、拥塞、隔离和保密性不重要。运营商可以开通电路，设备商可以提供优先级功能，L2TP 部署可以选择认证或 IP 层保护，服务团队可以测量实际结果。SNAP 中的协议编号并没有把这些能力和责任一并授予任何一方。

控制权始终分散。IANA 管理登记值，IETF 规定互操作的格式与行为，帧中继运营者掌握电路的可用性和特性，LAC 与 LNS 管理员配置隧道，授权服务可以下发属性，实现者决定触发时机和限制执行方式。最终感受服务的是用户，但用户通常不掌握路径，也看不到足以独立诊断路径的全部证据。

后继协议不会自动改造旧电路

RFC 3931 后来把 L2TP 第三版扩展为可以承载更多二层业务的伪线机制。它说明把被仿真的服务与下方分组网络分离仍有价值，却不能证明 RFC 3070 的部署自动迁移，也不能证明旧依赖已经被新设计吸收。

协议文档的更替不等于基础设施的更替。一份 RFC 可以进入历史状态，而某条电路仍在运行；运营商也可能已经退役承载网络，配置备份、RADIUS 属性和排障习惯却继续存在。书写这段历史，不能只问当时哪份 RFC 有效，还要问究竟哪些可执行和管理依赖在控制一项具体服务。

Lu Heng 关于 running code 的原则正好帮助确定证据边界。能运行的软件证明一个定义清楚的接口能够被实现，却不能证明电路正确开通、端点合法获权、MTU 覆盖所有流量，也不能证明用户得到了承诺的体验。他的现实分层方法还要求把隧道标识、已配置的 DLCI、一次成功信令、一个送达的报文和一项可用服务视为相互关联但彼此不同的事实。

RFC 3070 的历史价值正在于它没有遮蔽这种差别。L2TP 之所以能够“与介质无关”，是因为规范明确说出了帧中继仍须承担什么。隧道借用了一条电路；只有保留借用关系的证据，这项抽象才不会变成失责的幻觉。

来源