摘要

  • Mark Smith 的个人草案 v03 为要求 DHCPv4 Router Option 3 的客户端增加了替代值：分配给主机自身的 DHCP 地址，或 127.0.0.1。
  • 草案称这两种值应把发往非本地 IPv4 目的地的数据包留在主机内，并触发 ICMP Destination Unreachable。这是提议，不是已公布的互通测试结论。
  • LACNIC 博客 10 月 2 日提到的操作系统测试基于 v02，早于这条新兼容路径。

分析

默认网关通常把流量带往别处。DHCPv4 一份新修订草案提出，对某些旧客户端来说，网关字段也可以指回客户端自身。

Mark Smith 于 10 月 16 日发布了《Nearly IPv6 Only Dual Stack Hosts》v03。v02 已在 6 月 15 日到期。新版本仍保留对接受“不下发 Router Option 3”的客户端省略该选项的做法；但针对那些被认为必须收到它的客户端，草案增加了另一条路：把主机获 DHCP 分配的地址，或 127.0.0.1，作为路由器值返回。

这不是常见的网关配置。RFC 2132 将 DHCP Option 3 定义为服务器提供给主机的路由器列表。草案认为，在 /32 子网掩码下，这两个自指向地址都应让前往非本地 IPv4 地址的数据包留在本机，并立即产生 ICMPv4 Destination Unreachable。关键仍在客户端如何解释这条路由。草案没有公布测试矩阵，无法说明哪些客户端接受这两个值、实际安装了什么路由，或应用是否随后改走 IPv6。

过去公布的测试并不能回答这个问题。Alejandro Acosta 于 10 月 2 日在 LACNIC 博客发表的文章引用的是 v02，列出了 Windows 11、Fedora 43、基于 Debian Trixie 的 Raspberry Pi OS、Chromecast 和 Google Nest。文章也明确表示没有测试智能手机，并认为还需要更多测试。这些观察发生在 v03 之前，不能证明新 Router Option 分支可用。

因此，测试重点不能止于 DHCP 服务器是否能发出这个值。运营团队应把“主机自己的地址”和“127.0.0.1”分成两组，按客户端、操作系统版本和 DHCP 服务器或中继方式分别验证。记录 DHCP ACK、主机实际安装的路由表、发往主机之外 IPv4 目标的抓包，再确认 ICMP 错误是否交给应用、应用是否重试 IPv6。链路内通信也需单独检查：限制经路由器转发的流量，并不能说明本地 IPv4 通信也会消失。

这项草案与 DHCPv4 Option 108 并行存在，而不是取代它。RFC 8925 允许兼容主机声明自己希望在一段时间内采用 IPv6-only。新草案针对的是不支持 Option 108，或仍等待 DHCPv4 响应的设备。v03 带来的新问题是兼容性，而不是一项新标准。

Datatracker 将 v03 列为有效的个人 Internet-Draft，没有 RFC stream，IESG 状态为 “I-D Exists”。文件本身明确说明它不代表 IETF 背书，在 IETF 标准流程中没有正式地位；草案写明目标状态为 Informational，有效期至 2027 年 4 月 19 日。版本更新只说明提案仍在维护，不能证明 IETF 或操作系统厂商已采纳它。

对网络团队来说，这是一条值得小范围验证的兼容分支，还不是可以直接铺开的配置。主机地址和回环地址应分别进入可回滚的试点，先证明实际路由行为和应用 IPv6 回退符合预期。DHCP 成功只说明租约发出；主机如何使用这个“指向自己的网关”，仍需实测。

来源