摘要

  • RFC 3679 将可以回收的提议编号，与已经用于 PXE 和 Apple、但没有公开 RFC 说明的编号区别开来。
  • RFC 3942 为私用范围编号建立了过渡程序。后来，RFC 8910 在一次试验发现 Polycom 对编号 160 有其他用途后，将门户信号迁至编号 114。注册表记录的是协调状态，不是已部署设备的普查。

书目为空，不代表网络也为空

DHCP 在配置地址时传送小型参数，例如子网掩码、路由器地址或其他服务信息。选项编号属于共享命名空间：如果已经废弃的提案永久占着编号，后来的工作就少了空间；如果一个确实已部署的编号被重新分配，不同设备就可能对同一字段作出不同解释。

2004 年 1 月，RFC 3679 同时处理了这两种风险。它列出一些旧分配：对应提案已经过期、从未形成公开定义，或已不再用于当时的故障切换协议。这些编号可以退回 IANA 的可用池。但另一节说明，PXE 选项 93、94 和 97 虽没有出现在已发布 RFC 中，却已被广泛使用；它还列出 Apple 对 95 及 112–114 的用途，这些用途也没有 RFC 文档。文件要求先保留这些分配，由 DHC 工作组决定后续安排。关键依据并非是否出版，而是已有使用的报告。RFC 3679

这种区分并不是说所有未文档化用途都应永久获得公开编号。RFC 3679 逐项列出回收理由，并将已知的 PXE、Apple 情况另行处理。对于可回收的编号，它要求 IANA 在从未分配或此前已退回的编号用尽后，再把这些编号放回可用池。它是一份信息性备忘录，不能证明每种被提及的实现至今仍存在，也不能证明现实部署中的每项分配都已解决。RFC 3679 状态

从清单到过渡程序

同年稍晚，RFC 3942 将公开定义的 DHCPv4 选项空间从 1–127 扩展到 1–223，对原本保留作私用的上半区重新分类。但新分类无法抹去已经存在的本地配置。标准因此规定了过渡方式：对已知存在私用的编号，可先标为不可用，留出时间让厂商通知工作组和 IANA；临时公开分配设有六个月的通知期，之后有十八个月提交 Internet-Draft。网站则被建议迁移到剩余私用范围。RFC 3942

冲突规则更为明确：如果多个厂商证明同一编号已被相当广泛地使用，谁也不能仅凭私下使用就保留该编号；每一方都必须按正常程序申请公开分配。这并非宣布私用不正当，而是承认一个编号无法协调两个互不兼容的含义。RFC 3942 也没有采用 16 位扩展，因为它会给早期采用者增加负担；也没有另起新格式或魔术 cookie，因为那会增加兼容和发现成本。

后来的冲突让差异变得具体

RFC 4578 后来称 PXE 选项 93、94 和 97 已被广泛使用，同时指出 PXE 客户端还会请求 128–135；这些编号并未正式分配给 PXE，在同一网络中可能与其他用途冲突。这提醒我们：客户端请求某编号，不会因此自动取得正式分配。

门户网络提供了更明确的案例。RFC 7710 最初使用 DHCPv4 选项 160 发布门户 URI。IETF 106 网络试验发现，一些 Polycom 设备把 160 用于其他功能；门户 URI 放在该选项中时，这些设备无法按预期工作。因此 RFC 8910 将信号改用选项 114，更新 RFC 3679，并把 160 退回“未分配”，同时记录已知的 Polycom 用途。作者描述的是该次试验观察到的冲突，并没有声称它在所有网络中的发生率。RFC 7710 RFC 8910

当前 IANA 表可以看到若干编号此后的状态：83 后来用于 iSNS，88 和 89 用于 BCMCS，114 用于 Captive-Portal，而 96 仍未分配；126 和 127 也处于未分配状态。这些是注册表状态，不是活跃网络中没有设备发送这些值的证据。后续分配也不能证明此前的所有实现都已消失。IANA BOOTP/DHCP 参数注册表 RFC 4174 RFC 4280

卢恒后来在 Note 72 中提出的一个有限分析视角，是将协调记录与运行现实视为不同类型的证据。该文讨论互联网编号唯一性协调，而非 DHCP 选项分配；它没有促成或背书这些 RFC 决策。实际教训来自 DHCP 文档本身：回收编号前要查明用途，重新分配是一项过渡工作，而非一次账面修改。Note 72

资料来源

补充协议背景