摘要

  • RFC 3573 允许 L2TP Access Concentrator 报告 V.92 调制解调器已经进入保持、协商出的最长保持时间，以及它何时重新上线；这些字段描述接入侧状态，并不规定 L2TP Network Server 必须采取什么策略。
  • 最危险的误读来自时序：恢复通知与客户端恢复后的首个有效报文走不同通道。控制面的描述可能晚于数据面的事实，不能因为数据库里仍是“保持”就丢掉已经回来的流量。

下载还没有结束，电话却响了。V.92 调制解调器可以先把数据呼叫置于保持，让同一条普通电话线接听语音，随后无需重新拨号就回到原来的连接。调制解调器旁边的设备知道发生了什么，远端承载 PPP 会话的服务器却看不见这段物理变化。

RFC 3573 正是为这道断层补上一条很小的消息。在 L2TP 拨入拓扑中，服务器侧调制解调器连接 LAC，PPP 会话则由跨越分组网络的 LNS 处理。LAC 掌握接入媒介的现场，LNS 掌握定时器、流量处置和计费。任何一端都没有完整事实。

这份 2003 年 7 月发布、目前仍列为 Proposed Standard 的 RFC 没有把信息扩张成权力。它只传递能力、状态和时间上限，并反复声明：收到信息之后做什么，由 LNS 自己决定。

先证明会听，再允许发送

支持该扩展的 LNS 必须在建立控制连接时，通过 SCCRQ 或 SCCRP 携带 Modem On-Hold Capable AVP。没有看到这项能力，LAC 就不得发送 Modem-Status（MDMST）控制消息。

这只能证明对端宣称能解析消息。它不证明今后一定能收到通知，不证明处理及时，更不证明计费、排队和上层协议按预期运行。能力声明是证据链的起点，不是结果。

MDMST 也不能脱离会话生命周期。只有在会话成功建立之后、LAC 认为会话结束之前才能发送。如果 LNS 已经发出 Call-Disconnect-Notify，随后到达的状态消息必须忽略。一个迟到的接入状态，不能复活已经关闭的会话。

一位状态，四位上限

客户端请求保持时，LAC 应发送 H=1，并带上协商出的最长保持时间。调制解调器恢复在线后，LAC 应发送 H=0；如果此前发过 H=1，这条清除消息就是强制性的。

状态 AVP 一共 16 位：一位表示 Hold，四位编码 V.92 的 Timeout，其余为保留位。Timeout 从 10 秒到 16 分钟，还包括“无上限”，但只在 H=1 时有效；H=0 时必须忽略。

“最长”很容易被系统写成“实际”。其实它不是已经过去的时长，不是 LNS 必定执行的截止点，也不是物理线路必定可恢复的承诺。它只是调制解调器层协商的上限，由 LAC 转述给 LNS。

可审计记录应保留原始编码与当时的解释，还要包括隧道和会话标识、端点、序列、发送与接收时间、消息是否重复、是否成功送达，以及前后是否发生断开。一个 on_hold=true 字段，会把最重要的边界全部压平。

接收方拥有后果，也承担后果

RFC 给出一些可选动作。LNS 可以暂停 LCP Echo、Link Quality Monitoring 或 Multilink PPP 轮询；可以丢弃发往暂离客户端的报文；也可以另开计费会话、暂停计费，或者单独计算保持时间。这些动作互不等价，有些甚至互相排斥。

规范对三种看似体贴的做法更谨慎。为客户端缓存数据没有天然安全的容量和时间预算，恢复时突然释放还可能破坏 TCP。代替客户端回答 TCP keepalive 是伪造在场，可能干扰真正恢复。因为“仍在保持”就停止处理从 LAC 到达的有效数据，则明确不可取。

最后一点揭示了真正的时序风险。恢复状态与第一个客户端报文走不同通道，报文完全可能先到。如果实现必须等到 H=0 才放行数据，它会丢掉“客户端已经回来”这条最直接的证据。保守的控制策略反而制造了恢复失败。

控制消息完美，业务仍可能失败

完整、按序、经过保护的 MDMST 轨迹，也无法替上层给出结论。调制解调器离开期间，TCP 可能超时，应用可能放弃传输，LNS 可能按本地策略丢掉下行流量。计费可以连续、暂停或拆分，用户的数据连接却未必恢复。

反过来，首个有效数据报文已经出现时，控制面保存的状态仍可能是保持。只相信状态库的监控会把真实流量标成异常；只相信流量的监控又解释不了中断。正确做法不是选一边，而是分别保存调制解调器协商、LAC 观察、消息送达、LNS 策略、双向报文、重连、PPP/TCP 状态、应用结果与计费，再用稳定会话标识和可解释的时钟把它们连接起来。

加密保护报文，不替报文赋予真相

RFC 3573 依赖底层 L2TP 安全机制保障完整性和保密性，新 AVP 也可以隐藏。RFC 3193 进一步给出 L2TP over IPsec。它们可以加强“某个受认证对端通过受保护通道发送了这些字节”的证据，却不能证明调制解调器的物理状态准确、LAC 没有误判、LNS 策略正确，或应用完成了工作。

IANA 当前仍保留消息类型 17 和 AVP 属性 53、54。编号被稳定登记，只证明名称空间得到协调，不证明现在有人部署。RFC 附录记载早期实现使用过厂商私有编号，并明确说明那只是历史、不是规范。登记与历史都不能代替运行证据。

证据边界

本文不指认任何 ISP、LAC、LNS、调制解调器厂商、用户、电话运营者、会话、事故、计费结果或部署比例。它只分析规范明确给出的协议边界。

RFC 2661 提供 L2TP 基础模型，RFC 1661 提供 PPP 背景，RFC 1989 与 RFC 1990 解释文中提到的轮询机制，RFC 2865、2866、2869 提供认证和计费背景，RFC 3193 划定传输保护边界。RFC 3931 只是后来的 L2TPv3 语境。IANA 与 ITU-T V.92 页面证明编号和被引用建议书的存在，不证明运行结果。

卢恒的 Running-Code Primacy 与 Minimum Initial Specification 只作为公开说明的编辑视角：声明必须交给运行结果检验，共同协议应小于本地决策权。它们不是 RFC 作者意图或现实部署的证据。

结论并不是泛泛的“状态可能过期”。临时状态之所以有用，恰恰因为它不是命令，也不是结果。保留状态，保留本地决策，保留随后报文和用户结果，任何一层都不得替下一层说话。

来源