摘要

  • Option 108 让具备 IPv6-only 能力的客户端请求不拿 IPv4；DHCP 服务器只在已配置的 IPv6-mostly 地址池中响应。
  • 草案没有规定统一的能力测试。设备白名单、退出路径，以及过去由 IPv4 掩盖的故障，都要运营者负责。

DHCP 服务器不会检查一台笔记本装了哪些应用，再替用户保证断开 IPv4 后照常工作。Option 108 也不打算做这种事。它只让具备相应能力的客户端表示：自己愿意不拿 IPv4 地址。运营者再决定哪些网络接受这个信号。

这就是IETF IPv6-mostly 草案第 12 版的关键转轴。草案 10 月 29 日更新，目前处于 IESG 最后征求意见阶段，截止 11 月 12 日。它让 IPv4 和 IPv6-only 设备共处同一网段。客户端请求 Option 108，并在 DHCPOFFER 中收到该选项后，不应再请求服务器提供的 IPv4 地址。不会用此选项的设备，仍可从配置为 IPv6-mostly 的地址池拿到 IPv4。

Option 108 是信号，不是兼容性测试。草案明确说，“具备 IPv6-only 能力”没有严格的技术定义，只表示设备能在没有原生 IPv4 的情况下运行，并给用户相同体验。应用可以用 IPv6 套接字，只连接 IPv6 目的地；也可以通过 NAT64 访问 IPv4-only 目的地；还可以由设备运行 CLAT，把旧式 IPv4 应用接入 IPv6 网络。RFC 6877定义了这种客户端侧转换器。RFC 8925早已把接口能否声明为兼容视作一项策略决定。-12 版草案没有改变这点：DHCP 交换本身不会揭示设备是否适合断 IPv4。总要有人决定哪些设备、接口或用户群可以作出这项声明。

服务器的职责很有限。RFC 8925 规定，只有客户端请求了该选项，且所选地址池明确配置为 IPv6-mostly，服务器才发送 Option 108。四字节选项值告诉客户端应停用 DHCPv4 多久。服务器发送已配置的 V6ONLY_WAIT；没有配置时就发送 0。决定地址在哪消失的是地址池策略，不是客户端自信地贴给自己的标签。

IPv4-only 目的地仍需要一条通路。草案依赖 NAT64，也要求通过路由器通告机制 RFC 8781、DNS64 RFC 6147，或两者向客户端传递 NAT64 前缀。应用不支持 IPv6 时，设备可能还要运行 CLAT。设备、DNS、转换器或接入网络只要有一个环节出错，过去掩盖故障的双栈后路就没了。

因此，迁移安排比选项编号更重要。-12 版建议先做自愿参加的试点，再进入可退出阶段，逐步启用 PREF64 通告和 Option 108。草案甚至提出，用户可能要先报告问题才能退出。这确实能给运营者提供故障信号，也把受影响的人变成第一批测试人员。草案把用 ACL 阻断 IPv4 称为过渡办法，因为设备移动后，运营者还得持续维护每台设备该不该被拦的策略。

草案没有部署数量或实测故障数据，因此无法证明节省了多少地址、用户体验如何。它的论点是架构层面的：共享网络可以停止给愿意放弃 IPv4 的客户端分配地址，同时给仍然需要 IPv4 的设备保留这条路。实际运营的问题还没解决：运营者怎样在应用逐个报错、客服逐个记账之前，确认一台设备真的“准备好了”？

Sources · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147