摘要

  • RFC 8925 定义 DHCPv4 选项 108，即 “IPv6-Only Preferred”。具备相应能力的客户端主动请求该选项；只有从明确配置为 IPv6-mostly 的地址池回应时，服务器才应返回它，客户端随后放弃所提供的 IPv4 地址。
  • 协议规定的最短等待时间是 300 秒，默认值则是 1800 秒。计时结束或出现新的网络接入事件后，DHCPv4 决策可以重来。因此，五分钟是回退断路器，不是 IPv4 永久退场的宣言。

一份希望被拒绝的 DHCPOFFER

通常，DHCPOFFER 的含义是“这里有一个地址，请来领取”。选项 108 让同一条协议能够表达相反意图。客户端在 DHCPDISCOVER 或 DHCPREQUEST 的 Parameter Request List 中放入代码 108，相当于说：在当前接口上，只要网络具备 IPv6-only 运行所需条件，我可以不要 IPv4 地址。

客户端只发送选项代码，不发送四字节计时值。服务器也不能把沉默当作同意。它必须同时确认两件事：客户端确实请求了选项，命中的地址池也被明确配置为 IPv6-mostly。满足条件后，服务器才返回 V6ONLY_WAIT。

RFC 建议把 0.0.0.0 放在 offered address 字段中。如果服务器或周边基础设施无法这样处理，也可以放入一个真实可用地址，但不应为该客户端预留，因为预期结果本来就是客户端不发 DHCPREQUEST。

这个看似绕路的交换，解决了现实中的混合终端问题。不认识选项 108 的设备继续走普通 DHCPv4，领取 IPv4；具备能力的设备则可以只保留 IPv6。二者共享同一个 SSID、VLAN 或二层网段，无需先由认证系统替每台设备猜测能力，也无需复制一整套网络。

机制的权力因此很小。它不裁决哪种应用“落后”，不规定运营商何时结束过渡，也不惩罚未采用者。它只让一个接口和一个特定地址池交换一次有限声明。

五分钟保护的不是犹豫，而是纠错能力

服务器返回的是 32 位无符号 V6ONLY_WAIT。若值低于协议下限，客户端按 300 秒处理。RFC 8925 的默认值是 1800 秒，不能把“五分钟最短值”误称为默认值。

在等待期间，客户端应停止 DHCPv4 配置过程，也可以在该接口上完全停用 IPv4 栈。状态有两个出口：计时结束，或者发生新的网络接入事件，以先到者为准。换一个 Wi-Fi、重新连接或其他满足定义的链路事件，都会让终端重新判断。

这说明“IPv6-only 能力”不是设备身份证上的永久标签。同一台笔记本可能在企业接口上配置了 CLAT，在另一个接口上没有；一个办公网可能提供 NAT64，而酒店只有 IPv4。把能力限定到接口和接入现场，正是协议避免过度承诺的方式。

2026 年 3 月的 6MOPS 第 07 版草案建议，初期以 300 秒部署，便于快速回滚，稳定后再考虑延长。它仍是 Internet-Draft，是进行中的工作，不是 RFC，也不能当成已经定稿的共识标准。但这条运营建议可以直接接受检验：出现问题后停止发送选项，客户端最迟在计时或重连后重新请求 IPv4。

代价同样可测。大量客户端每五分钟重新发起 DHCP，可能给服务器带来可观负载。短计时缩小故障持续时间，长计时减少控制流量。正确值不来自立场，而来自客户端规模、DHCP 容量、失败频率和真实恢复时间。

不能压成一个开关的六层事实

“已启用选项 108”只是配置标签。要证明网络发生了什么，至少要保留六层记录。

第一层是接口策略。谁把该接口声明为具备 IPv6-only 能力？依据是操作系统默认值、CLAT 可用，还是企业完成了应用测试？RFC 明确把这件事称为策略决定，而不是协议自动扫描出来的事实。

第二层是请求。数据包的 Parameter Request List 是否真的出现代码 108？如果客户端没有请求，服务器返回该选项也不能构成有效同意。

第三层是服务器范围。回应所使用的地址池是否明确配置为 IPv6-mostly？设备级的“功能已开启”不能替代对实际命中地址池的证明。

第四层是 offer。选项长度是否为合法的四字节，计时值是多少，yiaddr 是 0.0.0.0 还是真实但未预留的地址？受控抓包可以给出答案。

第五层是客户端状态。系统是否真的放弃地址、暂停 DHCPv4，并在 INIT-REBOOT、续租或重新接入时按规则行动？服务器发出了消息，不等于终端达到了预期状态。

第六层才是服务结果。终端是否及时获得 PREF64？NAT64 路径是否可达？需要 IPv4 socket 的旧应用是否获得 CLAT？用户真正要完成的业务是否成功？“租约表中没有地址”对这些问题一无所知。

把六层合并成“IPv4 已关闭”，就把可诊断机制变成宣传。更准确的写法是：某接口在某地址池收到某计时值，限时拒绝了一次地址，而哪些应用随后成功、哪些失败。

选项 108 无法替网络完成翻译

RFC 8925 假定 IPv6-only 主机通过 NAT64 访问仅有 IPv4 的目的地，但它并不协商采用哪种翻译技术，也不传递 NAT64 前缀，更不证明翻译器可达。

这正是 Linkova 参与的相关标准需要接续之处。RFC 8781 定义路由器通告中的 PREF64 选项，让主机随 IPv6 配置一起获得 NAT64 前缀。2025 年发布的 RFC 9872 建议新部署优先使用这条 RA 路径；如果网络不提供或客户端不支持，再以 DNS 发现作为后备。RFC 9872 还明确提醒：在取得 PREF64 之前，仅支持 IPv4 的应用和目的地通信会受损。

464XLAT 则照顾只能打开 IPv4 socket 的程序。终端侧 CLAT 把这些流量转换为 IPv6，再送往网络侧翻译器。不过 RFC 6877 从未承诺完全复制 IPv4。它提供的是有限 IPv4 连接，不覆盖入站 IPv4，也不能满足所有点对点模式。

因此，选项 108 正常工作而业务失败，并不矛盾。客户端正确拒绝了地址，但 RA 没有 PREF64；前缀正确，但 NAT64 路由中断；翻译可用，但 VPN 丢弃 IPv6 扩展头；浏览器通过原生 IPv6 成功，旧程序因 CLAT 未激活而失败。

事故复盘必须指出具体断点。若把所有失败统称为“IPv6 问题”，既无法判断选项是否守约，也无法定位需要修复的控制面。

双栈成功可能是一张假健康证明

双栈网络的宽容性很高。Happy Eyeballs 可以绕开有问题的 IPv6 路径，迅速改走 IPv4，用户甚至感觉不到异常。这保护了体验，却可能长期隐藏 IPv6 缺陷。拿走 IPv4 地址后，过去被掩盖的问题才成为唯一现实。

6MOPS 草案因此提出分阶段推进：先发布 PREF64，再在 DHCPv4 服务器端启用选项 108；若终端受管理，再做逐设备激活和回滚。草案特别提醒，部分操作系统默认已经处理选项 108，也没有关闭旋钮。对这些系统而言，服务器一开选项，它们就立即转为 IPv6-only；看似单点的服务器改动可能成为全网段事件。

Jen Linkova 在 IETF 118 的演示文稿中描述过 Google 办公网的试点、跨地点扩展以及从较小比例逐步提高到全量的过程。幻灯片报告了 DHCP 使用下降和预计可回收地址数量。这些是特定演示和特定环境中的运营主张，不是独立审计的全球基准，必须保留归属。

真正可复用的不是某个百分比，而是试验结构：小规模开启，观察失败，扩大范围，保留回退。运行结果反过来审查文档，而不是文档一经发布就替运行结果背书。

“没领地址”究竟证明多少需求

客户端拒绝一次租约，地址便可留给其他设备。在终端直接使用公网 IPv4 的网络中，这可能减少公网地址占用；在 RFC 1918 私网中，它可能缓解私网空间耗尽，避免再叠一层 NAT。新网段可以一开始就配置更小的 IPv4 池，旧网段则可能需要重新编号，释放空间才能真正变成可复用块。

但这个需求信号带着一长串条件：这台设备、这个接口、这版软件、这份策略、这个网络、这些翻译服务，在这段时间里没有领取 IPv4。它不能证明所有应用成功，也不能证明设备换到另一张网仍会拒绝，更不能证明剩余终端的 IPv4 需求不合理。

它也没有消灭稀缺性。相反，地址使用可能更集中到确实无法退出的场景。选项的经济价值，是把“默认分配”与“实际条件需求”拆开，而不是宣布 IPv4 已失去价值。

应同时观察：请求选项的客户端数、合法返回数、实际拒绝的租约、后续重试和返场、NAT64/CLAT 健康、按应用分类的失败，以及最终完成缩池或再分配的地址数量。只有地址真正能被重新部署，账面上的“少一个租约”才转化为资产效率。

五分钟计时器让分析不必押注终局。网络先记录一次“不要”，观察后果，然后允许下一次回答不同。

人物贡献与运行权威必须分开

RFC 8925 署名 Lorenzo Colitti、Jen Linkova、Michael C. Richardson 和 Tomek Mrugalski。RFC 8781、RFC 9872 与现行 6MOPS 草案中，Linkova 也与其他作者共同出现。这足以证明她持续参与了相互衔接的 IPv6 运营机制，但不能证明个人独占发明，更不能赋予她对实现、厂商或部署的控制权。

这种边界与协议本身一致。文档负责定义互操作语义，客户端决定是否请求，运营商决定哪个池响应，真实代码给出结果。不采用的设备继续走普通 DHCPv4，不会因“未跟上”而被某个机构判为无效。

选项 108 最值得保留的思想，不是给 IPv4 安排退役日期，而是把宏大判断缩成一次有限请求：当前条件下，这个地址能否暂时不发？五分钟以后，系统仍有权重新提问。

来源