RFC 3115：运行代码如何裁决标准与注册表的冲突

摘要

RFC 3025 把关键厂商/组织扩展 CVSE 写成 37，把普通扩展 NVSE 写成 133；IANA 分配的是 38 与 134。RFC 3115 明言，现有实现遵循 IANA，因此废止前一份 RFC。
编号决定的不只是名称。Mobile IP 遇到 0–127 范围内的未知扩展时，要静默丢弃整条消息；遇到 128–255 的未知扩展时，则可跳过该扩展，继续处理其余内容。

一字节决定整条消息是否还存在

一个移动节点向外地代理发送注册请求。代理读到固定报文之后的第一个扩展，却不认识它。如果类型值落在 127 以下，处理到此为止：整份数据报被丢弃，不向发送方报告错误。若类型值在 128 以上，代理读取长度，跨过不懂的内容，继续寻找下一个扩展。

同样是不理解，协议给出的代价完全不同。前者认为缺少该扩展的语义后，整条消息已不再安全可解读；后者认为私人功能可以失去，但剩余消息仍可能成立。所谓“关键”与“普通”，首先是兼容性合同，不是价值判断。

2001 年 2 月发布的 RFC 3025，正是为了给 Mobile IP 增加两种厂商或组织私有容器。它把 Critical Vendor/Organization-Specific Extension，也就是 CVSE，编号写为 37；把 Normal Vendor/Organization-Specific Extension，NVSE，写为 133。IANA 的 Mobile IP 注册表却记录了 38 与 134。

两个月后，RFC 3115 取代了它。文档开头的编辑说明逐项列出冲突，然后给出罕见而直接的理由：当前实现遵循 IANA 分配，所以新备忘录废止 RFC 3025。

这里的“实现”不是抽象口号。它是标准编辑者引用的运行事实。但证据边界同样清楚：资料没有列出产品、版本或市场份额，也没有证明编号冲突造成过某次事故，更不能推出所有实现都一致。可以确定的是，运行中的选择已经强到足以推动标准记录向注册表靠拢。

37 与 38 都关键，却不能互换

RFC 2002 早已规定两段编号空间的处理方式。0–127 属于不可跳过范围。收到未知类型时，接收者必须静默丢弃包含它的消息。128–255 属于可跳过范围。长度字段告诉解析器应跨过多少字节，后续扩展与消息数据必须继续处理。

因此，RFC 3025 的 37 和 RFC 3115 的 38 虽然都在关键区，仍然不是同一个类型。等待 38 的设备看到 37 时，不会自动猜出发送者意图。对它而言，那是另一个未知的关键扩展，于是整条消息消失。

普通区的 133 与 134 也不能互换，只是失败更隐蔽。等待 134 的接收者看到 133，可以按长度跳过，注册流程或许仍会继续。表面上的注册成功，可能掩盖某项厂商功能根本没有被理解。关键区制造“无回复”，普通区可能制造“缺功能的成功”。两者都不能只靠最终状态解释。

RFC 对“静默丢弃”还作了操作性限定：不得继续处理，也不得向发送方示错；实现却应具备记录事件、保存被丢弃数据报内容并计数的能力。线上沉默与本地无证据不是一回事。若接收端没有这些记录，发送方看到的只是超时，无法区分未知扩展、认证失败、状态不匹配或普通丢包。

协议先识别外壳，再识别私有语义

RFC 3115 还区分了两层“不认识”。第一层是不认识外部类型 38 或 134，解析器连容器格式都无法确认。第二层是认识 CVSE/NVSE 外壳，却不支持其中的 Vendor/Org-ID 或厂商子类型。

这两个失败点的处理不一样。若外部 CVSE 类型不被认识，0–127 的基础规则生效，整条消息静默消失。若接收者认得 38，能够解析长度、组织编号和子类型，却不理解内部私有命名空间，请求消息必须走明确拒绝路径。

回复消息更能体现分布式角色。若不理解 CVSE 的节点还要把回复转发给下一个实体，它必须生成适当的拒绝；若它就是最终接收者，则把这份回复视为拒绝。对于 NVSE，若外壳已识别但组织编号或子类型未知，接收者跳过整个扩展，继续处理。

因此，一条“未知厂商扩展”的日志几乎没有诊断价值。应保存外部类型、解析器版本、外壳是否识别、组织编号、内部子类型、消息方向、当前节点角色、长度校验、采取的丢弃或跳过动作，以及是否产生拒绝码。否则，旧常量造成的协议断裂会被误记成“未安装某个厂商功能”。

企业编号划分命名空间，不授予行动权

两种扩展都有四字节 Vendor/Org-ID。最高字节为零，低三字节携带 SMI Network Management Private Enterprise Code。进入这个组织自己的空间后，两字节子类型与具体值由该组织管理。

这套设计把控制权拆开了。IANA 分配 Mobile IP 外部类型与拒绝码；私有企业编号注册表确定组织命名空间；组织定义内部子类型；发送方决定带哪些扩展；接收方决定实现哪些语义；Mobile IP 的安全关联在必要时认证外层消息；运营者的本地策略最终决定是否接受请求。

没有任何一个编号能代替全部环节。企业编号只说明命名空间归属，不证明报文真的来自该组织。认证通过只能说明受保护交换满足相应安全关联，不能让未知子类型自动获得含义。能够识别也不等于被授权。注册成功更不等于用户数据路径已经可用。

RFC 3115 允许一条消息包含多个 CVSE 与 NVSE，并规定中间节点不应改变它们的顺序。为查询方便而把 TLV 排序，可能破坏原始证据：认证器覆盖的字节次序、发送者的安排以及下游解析器看到的序列都可能因此丢失。

文档的安全章节说，它假定消息使用 Mobile IP 已定义的方法认证，不另加安全要求。那是规范的前提，不是部署证明。审计必须分别保存认证器结果、安全关联、被覆盖字节、私有子类型支持状况与策略结论，不能把一句“消息已认证”扩写成“扩展安全且获准”。

四个错误码保留三方路径

Mobile IP 注册涉及移动节点、外地代理与归属代理。RFC 3115 新增的四个拒绝码，把“谁无法理解谁发来的关键数据”保留下来。

100 与 101 属于外地代理拒绝。100 表示外地代理无法解释移动节点发来的 Vendor-ID 或 CVSE 子类型；101 表示不理解归属代理发来的内容。140 与 141 属于归属代理拒绝，分别区分内容来自移动节点还是外地代理。

这些编号能定位拒绝发生在哪个角色，也保留了一部分来源方向，但仍不是最终业务结论。它们不说明私有值意图是什么，不证明拒绝已经送达移动节点，也不说明之后是否通过别的路径完成注册，更不能证明用户看到的服务结果。

假如外地代理作为中转节点收到归属代理的回复，外壳能解码、内部 CVSE 却不支持，它可能把上游回复变成向移动节点发送的拒绝。只查看归属代理日志，会误以为处理完成；只查看移动节点，又只见到拒绝。证据链必须覆盖每一跳的输入、解析、变换与输出。

IANA 在线注册表正在变成实时基础设施

RFC 1700 是 1994 年出版的 Assigned Numbers 快照。RFC 3232 在 2002 年正式说明：在线 IANA 数据库已经取代这类静态汇编，RFC 1700 不完整，某些数值甚至已经错误。RFC 3115 的冲突发生在这场制度转换之中。

在线注册表能及时记录分配，RFC 则冻结一个出版时点。注册表只有编号，不足以解释全部字段、角色与失败语义；RFC 有完整语义，也可能在一个数字上印错。互操作需要把二者连接起来，而不是宣布某一种载体永远至上。

当前 IANA Mobile IPv4 Numbers 仍把 38 记为 CVSE、134 记为 NVSE，并保留 100、101、140、141 四个拒绝码，引用 RFC 3115。这证明今天的注册状态，却不重建每次历史修改。要解释 2001 年发生了什么，仍须同时保留 RFC 3025、RFC 3115 与注册表证据。

后来的用途不能冒充部署规模

RFC 4332 规定了 Cisco 的 Mobile IPv4 主机配置扩展，用于归属网前缀、默认网关、DNS、DHCP 与配置 URL。RFC 4784 则为 cdma2000 网络中的 Verizon Wireless 动态密钥更新流程定义三个 CVSE，使用外部类型 38 与企业编号 12951。

这些是具体、可核对的规范用途。它们不能证明多少设备上线、多少包成功互通，也不能说明商业服务覆盖。把“标准要求”当成“运行事实”，正是本篇要避免的证据跳跃。

RFC 5612 后来专门分配企业编号 32473 供文档示例使用。即使是假数据，也要避免撞进真实组织的私有空间，因为示例可能进入测试、代码与抓包。RFC 6709 又把问题扩展为一般原则：私有扩展能带来灵活性，但审查不足、未知值处理含糊，会制造互操作、安全与运维风险。

RFC 3115 早已把这种风险写成两个明确后果：不理解关键扩展，整条消息失效；不理解普通扩展，私人功能失效而消息继续。编号纠正，是在恢复所有实现对失败成本的共同理解。

运行代码不是最高法院，而是独立证人

这段历史不支持“代码永远正确”。实现会有漏洞，注册表会更新，RFC 也会修订。RFC 3115 的决定更精确：标准正文与分配机构冲突，而规范自身确认当前实现采用了分配机构的值。因此，替代文本把规范语义、注册编号与线上行为重新合并。

抓包只能证明某个发送方发了什么，不能证明接收方如何解释；解析日志只能证明一台设备的决定，不能证明注册成功；拒绝码只证明协议中的一步，不能证明最终服务。RFC 3115 对“当前实现”的陈述高于设计意图，又低于完整普查。

把这些层次守住，结论反而更有力量：RFC 3025 写了 37 与 133，IANA 分配 38 与 134，运行中的实现选择后者，RFC 3115 随即废止前一份文档。标准没有被运行代码抹掉；它依据运行证据修正了自己。

RFC 写的是 37，运行中的网络却认 38：RFC 3115

为何重要

摘要

一字节决定整条消息是否还存在

37 与 38 都关键，却不能互换

协议先识别外壳，再识别私有语义

企业编号划分命名空间，不授予行动权

四个错误码保留三方路径

IANA 在线注册表正在变成实时基础设施

后来的用途不能冒充部署规模

运行代码不是最高法院，而是独立证人

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报