摘要

  • RFC 2153 预留了共同的专有扩展外壳，避免厂商私自占用普通 PPP Code 或配置选项 Type 而相互冲突。
  • OUI 只指出谁管理含义；Kind 没有统一标准，Values 由实现自行定义，格式正确的报文仍可能无人理解或被本地策略禁止。
  • Configure-Ack 只证明一端接受了当次请求中的精确选项集合；功能启用、双向使用、安全性和业务结果仍要另行留证。

报文已经归档，字典却不在场

抓包工具可以把字段画得整整齐齐：Code 0、合法 Length、三字节 OUI、一字节 Kind。此时唯一可以确定的是，这些字节落进了某个组织管理的命名空间。接收端是否装有对应解释模块、是否认识这一版 Values、管理员是否准许它运行，都还没有答案。

RFC 2153 的价值正来自这种克制。1997 年发布的 Informational 文档没有公开厂商算法，而是给专有机制一个不占用公共普通编号的外壳。其理由很直接：避免厂商秘密自分配 LCP、NCP Code 或配置选项 Type，最终造成碰撞。

它定义了两条路径。Vendor Specific 控制报文使用 Code 0，包含每个新报文都应变化的 Identifier、Magic-Number、OUI、Kind 和可选 Values。它甚至可以在 LCP 尚未进入 Opened 前发送。接收只触发 PPP 状态机的 RXR 或 RUC；如何响应由厂商决定。若收到 Code-Reject，应产生允许继续的 RXJ+。这些都是状态机事实，不是成功凭证。

Vendor-Specific 配置选项使用 Type 0。规范在这里设了一道明确门槛：接受前，实现必须确认 OUI 与 Kind 对应已知机制，并且完全理解所有专有协商值。结构解析、语义理解和接受决定因此不能合并。

OUI 是字典索引，不是字典本身

OUI 标识管理消息含义的组织。Kind 是该 OUI 下的一字节子类型，没有跨组织的统一标准；后续 Values 也完全取决于实现。通用解析器能够准确显示 OUI 与 Kind，却仍无法解释值的含义。

OUI 更不是身份凭证。它不能认证发送者，不能证明发送者属于登记组织，也不代表许可证或运营方授权。RFC 1661 把可选的对端认证放在链路建立之后，而 RFC 2153 允许控制报文在 Opened 之前到达；RFC 2153 的安全考虑还明确没有讨论安全问题。

注册表历史也说明编号与实现是两层事实。RFC 2153 曾为没有 IEEE OUI 的软件厂商设计 CF0000 系列。RFC 5342 随后停止新增分配，RFC 7042 保留了这一结论，同时强调没有修改技术格式。现行 IANA PPP 注册表 保存少量历史条目并把余下范围标为关闭。它能证明号码来源，不能证明任何当前设备装了对应代码。

Ack、Nak 与 Reject 不能涂成同一种绿色

RFC 1661 要求：所有配置选项都可识别且值可接受时，才能发送 Configure-Ack，而且返回内容必须与请求精确一致。选项可识别但值不可接受时是 Configure-Nak；选项不可识别，或管理员不允许协商时，是 Configure-Reject。

因此证据应分层保存。Length 合法只证明成帧正确；识别 OUI/Kind 只证明解码器声称有字典；理解 Values 才说明语义版本匹配；本地策略决定是否允许；Ack 则记录某一代协商中一端接受了精确请求。之后仍要证明参数真正安装、机制开始工作、相关方向出现有效流量。

后来 RFC 3772 为专有 PPP 协议增加专用 Protocol 编号，同时指出安全性仍取决于具体私有协议。编号空间不会替算法做安全审查。

六份收据比一个“已接受”可靠

第一份是成帧收据：控制协议、Code/Type、Identifier、Length、Magic-Number、OUI、Kind、Values 哈希、方向、时间与链路代次。第二份是含义收据：具体规范或解释模块及版本。第三份记录授权它运行的本地配置或管理员。第四份保存精确 Configure-Request 与对应 Ack、Nak 或 Reject。第五份证明参数已安装，并出现首个机制专属报文。最后才是 NCP Opened、网络层流量和关联应用结果。

RFC Editor 记录、IETF Datatracker 与 勘误页 维护的是文档事实。Heng Lu 的 Running-Code Primacy 要求运行系统回答实际发生了什么；Minimum Initial Specification 支持窄而清楚的共同外壳；Reality Layers 则提醒我们，不要把符号层标签冒充运行结果。

来源