摘要

  • RFC 3145 把 PPP 专属的断线原因放进 L2TP 的 Call-Disconnect-Notify 消息，但规定该属性非强制、可选，而且只用于信息和日志。
  • 原因码必须与控制协议编号、方向和报告端一起解释；合法报文只能证明某个对端作出过这项报告，不能单独证明物理根因或责任。
  • 这项设计提高了跨机构诊断能力，同时拒绝让显示文字、注册编号或受保护信道替代运行事实。

断开已被看见，内部原因却没有跨过隧道

L2TP 把接入集中器 LAC 与网络服务器 LNS 连接起来，在两者之间承载 PPP 会话。这样的分层让隧道控制不用理解 PPP 的每项协商细节。代价是：当会话结束时，远端可能只知道 L2TP 呼叫被拆除，却不知道 PPP 在链路控制、认证或网络控制阶段究竟看见了什么。

RFC 2661 已经给 Call-Disconnect-Notify（CDN）定义了 Result Code 与 Error Code。它们说明的是 L2TP 控制结果。PPP 可能同时经历回声超时、无法协商地址、认证协议互不接受，或正常收到 LCP Terminate-Request。若这些状态只留在一端，另一端便只能从“会话不在了”倒推原因。

RFC 3145 将这个缺口变成一个最小的互操作接口。它定义 PPP Disconnect Cause Code AVP：Vendor ID 为 0，Attribute Type 为 46，只能出现在 CDN 中。值里不只有断线编号，还有 PPP Control Protocol Number、Direction，以及可选的 UTF-8 说明文字。

这并不是用一个新字段取代旧结果。规范明确要求它与 L2TP Result 和 Error Code 一起使用，而不是替代后者。隧道为何结束、PPP 报告了什么，是两个证据层。任何只保留其中一个的事件模型都会在入口处丢失因果结构。

M 位必须为零

该 AVP 的 Mandatory 位必须是零。不了解它的旧端点可以忽略诊断信息，而不必因为无法解析一个附加说明就拒绝整条控制消息。这项兼容规则也界定了权力：诊断字段不能借“必须理解”反过来控制会话终止流程。

RFC 3145 还规定，这个属性只用于信息和日志，不应影响隧道或 PPP 会话的功能。也就是说，执行终止的仍是既有状态机；发出本地观察的是 LAC 或 LNS；判断根因则必须留给能够比较多份记录的后续过程。三个动作不能因为共享一个事件名称就合并。

Hidden 位可以为一，后来 RFC 3193 也讨论了用 IPsec 保护 L2TP。机密性、完整性与对端认证十分重要，但它们只加强“谁通过受保护信道发了哪些字节”。它们不能证明发送端的本地判断完备无误。被认证的陈述，仍然是陈述。

方向不是责任，最近也不是唯一

Direction 的零表示全局错误，一表示在 peer 一侧，二表示在 local 一侧。这里的 local 与 peer 均以生成 AVP 的主机为视角。如果采集器把它们直接翻译成“客户责任”和“供应商责任”，它就制造了线缆上从未出现的结论。

某些原因离不开方向。例如正常 LCP 终止要说明是哪一边发出 Terminate-Request；强制加密或回叫被拒，要区分哪边提出要求、哪边拒绝；认证协议不被接受，也要区分本端能够提供的协议被对端全部拒绝，还是对端要求的协议本端无法接受。动作方向使报告可解释，却不裁定该动作是否合理。

Control Protocol Number 是另一根坐标轴。全局错误用零；LCP 故障对应链路控制协议；认证故障要带所用认证协议编号；NCP 故障通常要指出对应的网络控制协议。若多个 NCP 都失败，可以携带多份 AVP；如果只携带一份，应指向最近一次失败的 NCP。“最近”只是选择记录的规则，不意味着早先故障没有影响。

因此，单独保存“原因 16”远远不够。更完整的收据应写明：哪一 L2TP 对端、哪一隧道和会话、哪条 CDN、哪项控制协议、哪个方向、何时、在何种保护上下文中，报告了该编号。每删掉一个坐标，数字就更容易被误读成全局事实。

编号描述观察类别，而不是法院结论

最初的代码从 0 到 20，覆盖无可用信息、管理性断开、正常终止、有限状态机超时、未收到可识别 LCP 报文、可能的链路回环、Echo Request 超时、多链路参数不一致、强制回叫或加密被拒、认证失败、所有 NCP 都不可用、地址无法收敛，以及用户没有获准使用任何地址。

这些统一术语让不同厂商能够交换可比较的观察。但“Echo 超时”只证明某个观察点在期限内没有收到预期回声，它不能在拥塞、丢包、返回路径被阻断、远端故障或本地进程失灵之间自动选择。认证失败也只说明协议状态，不应进一步暴露用户名正确而口令错误之类的区别。

RFC 3145 对后一点给出了罕见而清晰的警告：未来扩展不应提供能帮助攻击者判断用户名是否正确的区分。更细并不总是更真；过度细分会改变攻击者的查询能力。诊断的最小规格，既是互操作边界，也是信息泄露边界。

可选 UTF-8 文字同样需要克制。字符可显示，不等于内容获得权威；写进消息，不等于用户真正看见；来自已认证对端，也不等于适合出现在客服界面。原始文字应带来源与隐私策略保存，翻译后的用户提示则应作为另一个产物，不能覆盖结构化代码。

跨机构接口的真正价值

RFC 特别指出，当 LAC 与 LNS 不归同一主体管理时，缺少 PPP 断线信息尤其棘手。在单一团队内部，人们尚可凭内部日志与口头约定拼接事件；跨机构时，每一方拥有不同观察面，也承担不同激励。共同编号提供了可核对的收据，却没有要求双方假装共享同一现实。

文档预期它在强制隧道场景中由 LNS 向 LAC 发送最有用，但允许两边使用。LNS 可能最了解服务端 PPP 状态，LAC 可能最了解接入侧链路。这种知识不对称不能被固化为永久权威；一次调查可能需要两端各自提供证据。

标准化之前的草案使用 3Com Vendor ID 43。RFC 3145 允许接收端把旧形式当作等价输入，却要求发送端不要继续使用。这样做既保留历史互操作，又把未来语义收拢到 IETF 分配。注册表告诉实现者“如何读”，不会证明“谁部署了”，更不会保证“某一报告为真”。

账务、数据面与用户界面各有收据

该原因码可帮助调试与计费，但“帮助”不是“结算”。RFC 2867 的 RADIUS 隧道计费属性可以关联隧道与计费会话，记录开始、中间更新、停止和计数。PPP 原因码可说明停止为何可能发生，却不能证明停止记录已到达、计数完整或账单正确。反过来，一条格式正确的 Stop 也不能认证 PPP 原因。

数据面也不能被一枚代码代替。回声超时要与收发包计数、链路告警和独立可达性观测比较；认证原因要与状态转换核对，同时避免把凭据或敏感自由文本扩散到普通日志；正常终止要与实际 LCP 交换对应。原因码是调查入口，不是调查终点。

用户界面则需要另一次证明。系统可能从代码生成自然语言提示，但“已生成”与“已送达并被看见”不同。若翻译抹掉方向或把“不接受协议”写成“口令错误”，友好文案反而扩大了协议没有作出的事实承诺。

让运行事实保留上诉权

RFC 3145 展示了互联网设计中很耐久的一条路线：把最小可互操作事实标准化，把未来决策留在本地，再让运行证据约束机构对编号的解释。编号属于符号层，CDN 属于执行记录，PPP 与数据包属于运行层，计费和用户体验属于后果层。它们互相关联，却不能互相冒充。

现代可观测系统仍经常重复旧错误：摄取一个组件提供的 reason，删掉报告者和方向，将其翻译成一句顺口的话，再把它提升为全局 incident cause。RFC 3145 已经给出更稳健的办法。原因可以跨越隧道；对现实的裁决权不会随字段一同传输。

来源