摘要

  • RFC 3692 选择通用测试值，而非难以收回、重新使用又可能带来风险的临时专用分配。
  • 253 和 254 既不代表某一项实验，也不保证设备互通；安全使用依赖本地约定、明确配置，若要长期使用则须走常规分配流程。

报文先要有号，实验才有入口

工程师写出一项新扩展后，代码可以在本机运行；但一旦它进入报文，接收端就需要某个值来识别字段并决定如何处理。封闭实验室里，这个值可以由参与者私下约定。问题出在实验要经过真实协议栈，却又不能占用已分配的编号，或者向管理方借一个日后还得收回的临时号码。

2004 年 1 月发布的 RFC 3692（BCP 82）解释了临时专用分配留下的尾巴：联系人会失效，实验究竟是否结束难以确认；编号可能随产品流出实验环境，之后重用便可能影响那些历史不可见的设备。回收一个数字，看似简单，真正难的是判断还有没有人依赖它。

RFC 3692 选择了另一种安排：为试验留出通用编号。对于 IP 的 Protocol 字段，IANA 分配了 253 和 254，用于实验与测试。经过相互同意的系统可以用同一个值试验不同功能。这个数字不会为某种协议专属，也不会约束其他实现者。

共用编号，不会自动共用含义

这项设计的关键并非为每项试验制造一个唯一号码，从而彻底消除冲突。它承认冲突可能发生，并把边界放在本地管理：管理员可以在自己的环境里选用某值，并确保那里没有其他用途。离开这个环境，就没有普遍唯一性的保证。

因此，测试结果只能说明特定条件。报文中出现 253，可以证明一对已配置的端点识别了某项扩展；不能证明无关网络也会作同样解释。实验室的一次成功交换，只能支持对那些端点和配置的判断，不能推出广泛互通。若扩展证明有用，RFC 3692 要求再通过常规分配程序取得永久编号。

产品发布也有一道边界：实验识别功能不应默认开启。使用者必须明确启用，并通常要自己配置所用数字。厂商若把共用值写死在产品里，便可能撞上别人的试验，形成互通问题。

RFC 4727 后来把实验值整理到 IPv4、IPv6、ICMP、UDP 和 TCP 的多个头部字段中，并告诫实现者不要随意硬编码，继续遵循 RFC 3692 的谨慎要求。IANA 当前仍把 IPv4 Protocol 值 253 和 254 标为实验与测试用途。这证明保留用途仍在登记册中，不证明有多少产品在使用，更不能证明某项协议已普遍部署。RFC 8126 是后来关于 IANA 考量的通用指导；RFC 3692 引用较早 RFC 2434，是其 2004 年的历史背景，不是当前规则的完整说明。

RFC 3692 的贡献不大，却很明确：预留通用空间，让本地同意可见，要求自愿启用，并把真正持久的方案送回常规分配流程。测试编号打开的是试验入口，不是互通承诺。

来源