摘要

  • PPP 的 LCP 可以处于 Opened 状态，而某个具体网络层协议仍不受对端支持；未知 Protocol 字段会触发 LCP Code 8 Protocol-Reject。
  • 拒绝报文携带两字节的 Rejected-Protocol，并在对端 MRU 允许的范围内带回原报文信息，使发送方能够停止被点名的协议。
  • 拒绝普通 NCP 可以属于正常运行，拒绝 LCP 本身却是灾难性错误；局部失败能否被隔离，取决于承载拒绝的共同控制层是否仍然存在。

开放链路并不等于开放所有协议

1989 年的 RFC 1134 把 PPP 描述为在点对点链路上传送多种网络层数据报的方法。它没有把“链路”和“在链路上运行的每一种协议”混成一个状态：LCP 负责建立、配置和测试共同链路，一组 NCP 分别管理具体网络层协议。多个协议可以同时复用同一承载，因此其中一个协议的失败不必自动否定其余协议。

这也制造了一个很实际的矛盾。两端已经同意链路开放，一端却发来另一个端点不认识的 PPP Protocol 值。早期规范没有让接收方用沉默代表一切，也没有要求它立刻拆掉链路。若 LCP 处于 Open 状态，接收方必须发出 Code 8 Protocol-Reject，明确指出不能处理的是哪一种协议。

1992 年的 RFC 1331 又把两类看似相近的报文分开。一个协议可能本来受支持，但对应的 NCP 尚未 Opened；这种报文应被静默丢弃。另一种情况是 Protocol 字段根本未知，这才是 Protocol-Reject 所表达的支持边界。看见丢包，不能反推出不支持；看见拒绝，也不能把它误读为整个物理连接损坏。

Code 8 返回的是足够定位的证据

1994 年的 RFC 1661 固化了报文结构。Code 是 8。Identifier 每发出一个新的 Protocol-Reject 都必须变化。随后是恰好两个字节的 Rejected-Protocol，它复制被拒绝报文的 PPP Protocol 字段。

后面的 Rejected-Information 从原报文的 Information 字段开始，不包括数据链路头，也不包括 FCS。它还必须截断到对端已经建立的 MRU 以内。拒绝者因此返回足以辨认诱因的上下文，却不能为了诊断而构造一份超过已协商接收上限的回信。

这不是完整帧取证，也不是永久事件编号。Identifier 只属于这一个 LCP 控制报文；Returned Information 可能被截断；二字节字段只点名 PPP 协议。它提供的是有限、可操作的故障归属，而不是对整条路径的全量证明。

这种限制也保护了错误路径本身。若接收方可以把整份未知报文不受约束地塞回控制通道，一个很大的诱发分组就可能放大成另一个过大的分组。MRU 把“说明发生了什么”的成本纳入双方已经接受的边界。返回内容越短，取证细节越少；但 Rejected-Protocol 仍然保留最低限度的类型归属。大小约束和类型字段分别回答“最多返回多少”与“至少必须指出什么”。

被点名的一方必须停止那一种流量

收到 Protocol-Reject 后，RFC 1661 要求实现“在最早机会”停止发送被指出协议的分组。措辞承认实现中可能已有排队或在途工作，但不允许发送方把明确的能力否定当作普通丢包并无限重试。

这个动作只关闭被点名协议的入口。比如 RFC 1332 定义的 IPCP 是配置 IP over PPP 的 NCP，RFC 5072 定义 IPv6CP。它们说明 PPP 为什么需要一族独立控制协议，却不能证明某条现实链路使用了其中任何一个。若一个 NCP 被拒绝，对应网络层服务不能假装已经配置成功；其他协议只有在分别受支持并完成自身配置时才可能继续。

Protocol-Reject 只能在 LCP Opened 状态发送。在其他状态收到它，应静默丢弃。状态条件防止一封脱离共同上下文的拒绝信获得控制权：双方还没有共同认可链路时，报文无法可靠地改变协议运行状态。

同一种拒绝有两种严重性

RFC 1331 用 RXJ+ 和 RXJ- 表示接收拒绝后的两条路径。Protocol-Reject 指向普通 NCP 时，可以是 RXJ+：这是正常运行范围内的能力不匹配，实现停止相应类型，LCP 仍可保持开放。

但若被拒绝的是 LCP，结果是 RXJ-。规范把它称为灾难性、不可恢复并终止连接。原因不是 Code 8 突然改变了格式，而是共同控制语言本身遭到否定。一个 NCP 可以失去服务而不摧毁承载它的控制层；LCP 若被判为不受支持，连表达、配置和维持这条共享链路的基础都不再一致。

1993 年的 RFC 1548 与随后的 RFC 1661 保留这套机制，显示它不是一次性的草案特征。后来的 RFC 3818 讨论 PPP 编号空间的分配治理，则说明可扩展协议族需要持续管理命名空间。治理成熟不等于部署普遍。

机制还揭示了三种负面信息的差别。Configure-Reject 在协商期间拒绝一个 LCP 配置选项；Code-Reject 表示无法解释某个 LCP Code；Protocol-Reject 则针对 PPP Protocol 字段。三者都带有“拒绝”，却不能在告警里合并成同一种事件。若只记录一个笼统 reject 计数，运营者会丢掉决定严重性与后续动作的那层类型。

注册表能解释编号，不能证明能力

IANA PPP 编号注册表 目前把 LCP Code 8 列为 Protocol-Reject，并列出 PPP Protocol 字段的分配。注册表回答“这个数字被分配给什么”，不回答某台设备是否实现、某条链路是否启用、NCP 是否已经开放，也不证明这项协议今天承载多少流量。

同样，沉默也不是支持证据。LCP 可能尚未 Opened，受支持协议的 NCP 可能尚未开放，报文或回应可能丢失，实现也可能不合规。可靠判断需要把 Protocol 字段、LCP/NCP 状态、拒绝内容和拒绝后的发送行为放在同一条时间线上。

来源