摘要

  • RFC 7710 曾把 DHCPv4 选项 160 分配给强制门户发现。IETF 106 的网络实验发现，现场部分 Polycom 设备已把 160 用作其他用途；当该选项承载标准规定的门户 API URL 时，这些设备未能按预期运行。
  • RFC 8910 把 DHCPv4 的这项功能迁到 114。IANA 如今把 160 标为未分配，却保留其曾由 RFC 7710 分配、也已知被 Polycom 使用的备注；当前登记状态不能替代装机兼容性验证。

一次实验让“空位”接受了执行

2019 年在新加坡举行的 IETF 106 设置了一项会议网络实验：支持 Captive Portal API 的客户端可以发现 venue-info-url。当时，2015 年发布的 RFC 7710 已为 DHCPv4 指定选项码 160，网络按这个标准发送数据，本身并不是格式错误。

问题出现在混合设备环境里。RFC 8910 附录 B 记载，现场有部分 Polycom 设备把 160 用于其他目的。它们收到装有门户 API URL 的 160 后，没有按预期工作。

公开文本到此为止，没有设备型号、固件版本、数量、另一种载荷格式，也没有细化“未按预期工作”究竟是哪项功能。文章若替来源补上电话注册失败、重启循环或特定漏洞，看似具体，实际是在制造证据。能够成立的判断是：同一 DHCP 域里确有两种解释相遇，结果足以推动标准换号。

RFC 8910 的作者是 Warren Kumari 与 Erik Kline；被取代的 RFC 7710 则由 Kumari、Olafur Gudmundsson、Paul Ebersman 和 Steve Sheng 共同完成。这不是某位个人纠正另一人的故事。Kline 在这里的重要性，是他参与的修订没有把失败压缩成一句模糊的“兼容性考虑”，而是保留了地点、有限的设备范围、结果和处置。

注册表回答权属，固件回答动作

DHCPv4 的选项码只有一个八位字节。IANA 维护共同编号空间，让服务器与客户端能够约定含义。没有这项权威，稀缺的数字很快会碎成私有方言。因此，160 一度分配给 RFC 7710，是一个真实而有效的标准事实。

但终端解析 DHCP 报文时，不会临时访问 IANA 网站。它运行固件里的分支：见到 160，按已写入的结构读取并执行后续动作。CAPPORT 客户端期待 URI；另一套解析器若期待不同内容，相同字节便会进入不相容的状态机。

这揭示了两类问题。“标准认可哪一种含义”由注册表回答；“这个网段上的设备实际上会做什么”必须靠清点与实验回答。前者是规范权威，后者是经验事实。把前者当成后者，就会把正式分配误读为全球所有二进制文件都保持沉默。

RFC 3679 早已展示 DHCP 编号治理为何需要这种区分。它把从未形成标准、也未进入普遍使用的若干号码退回 IANA 以供重新分配；同时保留一些虽无正式 RFC、却已被设备使用的号码。纸面上没有规范，不等于线上没有实现。

114 是新归宿，160 仍有履历

RFC 8910 于 2020 年 9 月作为 IETF 标准轨文档发布，取代 RFC 7710，并更新 RFC 3679。它为 DHCPv4 强制门户选项指定 114。IANA 当前的 BOOTP 与 DHCP 参数注册表把 114 列为 DHCP Captive-Portal，引用 RFC 8910。

160 的当前状态是 Unassigned。如果只读这个词，容易把它想成洁净空白；完整记录却注明，它曾由 RFC 7710 分配，也已知被 Polycom 使用。这条备注没有声称相关设备今天仍在运行，而是提醒下一位分配者：未分配描述的是当前标准登记，不是对全球固件的扫描结果。

迁移只发生在 DHCPv4 编号空间。DHCPv6 的强制门户选项仍是 103，IPv6 路由器通告中的相应选项仍是 37。三者属于不同注册空间。叙述 160→114 时若省略 DHCPv4，反而会把标准努力维持的边界重新揉在一起。

换号也不是远程修复。DHCP 服务器要改为发出 114，relay 与接入控制设备要正确传递，客户端要实现新号。过渡网络可能同时存在理解 114 的客户端、会被 160 触发的旧设备，以及完全不识别 CAPPORT 的设备。为了“兼容”而同时发 160 与 114，可能正好再次伤害旧设备群。

最后一张回执来自业务功能

安全发布从设备清单开始，应按硬件、固件和用途划分，而不是只看在线总数。实验室需要复现准确的选项码、长度和代表性载荷，再把变更放到范围受控、但设备类型刻意多样的 canary 网段。

监测不能停在地址获取与续租。还要看启动是否完成、业务是否注册、连通是否建立、设备承担的任务是否成功。一个终端可以拿到 lease，却在稍后的状态分支失败。只显示 ACK 成功率的仪表盘会给出正确但不完整的结论。

回滚也应事先验证。服务端必须能迅速、可审计地撤掉 114。若某类旧设备无法升级，独立网段或明确的 DHCP 策略可能比全网统一更便宜。公开管理例外，总好过把未知设备宣布为兼容，然后等事故替系统做资产发现。

负面结果也是标准资产

这次碰撞不意味着私自占用者先到先得，否则共同编号空间会奖励沉默占号。它同样不意味着正式登记能命令已部署固件忘掉过去。可行治理把两种权威接起来：注册表定义共同目标，受控实验检验装机现实。

发现冲突后，标准可以保留功能、替换机制。114 的选择没有放弃强制门户发现，而是减少了已知碰撞。更重要的是，RFC 8910 和 IANA 都没有抹去 160 的旧记录。换号解决未来趋同，历史备注保护下一次分配。

一项成功实验只能说明受测群体通过；一项被准确记录的失败，则能指出哪个假设必须重做。Kline 与共同作者留下的价值，正是把“已经分配”与“现实无人使用”拆成两项必须分别举证的命题。

来源