摘要

  • Remco van Mook 的 INTAREA 工作组草案提出把 192.0.0.11/32 用作哨兵式默认网关；支持该机制的主机不得为它发送 ARP，而要采用所选 IPv6 默认路由器的 MAC。
  • 数据包仍是原生 IPv4，不经过隧道或地址翻译；但回程需要把该主机的 IPv4 /32 指向一个可路由的 IPv6 GUA 或 ULA 下一跳。
  • 省掉一套邻居发现并不等于省掉状态。DHCP 配置、RA 选路、NUD 可达性、IPv4 转发、回程路由与旧主机兼容各自都可能失败。

这个地址不是一台设备

理解方案的第一步，是拒绝按字面理解“网关地址”。192.0.0.11 不用被 ping 通，不应被当成路由接口，更不能在网络里重新发布。它只在主机本地表达一个动作：这条 IPv4 默认路由的二层目的地址，去 IPv6 控制平面查。

主机仍然拥有 IPv4 地址，应用仍然使用 IPv4 socket，路由器仍然转发普通 IPv4 包。改变的只有第一跳解析。主机先从同一接口的 IPv6 默认路由器列表里选出一台设备，再从 IPv6 邻居缓存取得其 MAC，把原生 IPv4 包交给它。

因此它不是 NAT64：地址族没有转换。它不是隧道：IPv4 外面没有再套 IPv6。它也没有偷偷恢复一个 IPv4 子网。真正被移除的是更新后主机发出的那句“谁拥有我的 IPv4 网关”。

2026 年 8 月，这份文档进入 INTAREA 工作组轨道。草案称，无须改动应用或 DHCPv4 配置，它已经在 Windows 11、macOS、Android、iOS、Linux、FreeBSD 和 ChromeOS 上得到验证。这个结论应准确归因于草案作者，而不是写成独立认证。文档仍是会变化的 Internet-Draft，哨兵地址也不能被当作已经普遍部署的既成标准。

出站和回程不是一张收据

DHCP 租约里出现哨兵，只证明配置已送达。主机还要收到 IPv6 Router Advertisement，才能得到可借用的默认路由器。第一份 RA 到达前，任何等待都必须有边界，不能让 IPv4 数据包无限排队。

出现多台路由器时，主机先按 RFC 4191 的 preference 选择，再参考可达状态；其他条件相同，最终决定可能因实现而异。首选路由器改变时，IPv4 路由也必须重新评估，既有连接可能中断。IETF 126 会议上，Lorenzo Colitti 正是针对这点发问：若实现没有正确跟随 IPv6 路由变化，会不会把 IPv4 一并弄坏？Van Mook 的回答是肯定的——这种关联不是偶然副作用，而是设计本身。

邻居缓存是另一张收据。RFC 4861 的 reachable、stale、delay、probe 状态各有含义，均可能在探测过程中继续被使用。但缓存里还有 MAC，不代表对端此刻一定转发 IPv4；反过来，设备会转发，也不代表主机拥有仍然有效的 RA 与 NUD 状态。

方向差异更容易造成误判。出站第一跳可以只使用 IPv6 link-local 地址。回程跨过路由器时，link-local 不能作为远端下一跳。运营者必须把主机的 IPv4 /32 连同一个可路由的 IPv6 GUA 或 ULA 下一跳向网络发布。RFC 8950 已规定 BGP 携带“IPv4 可达性、IPv6 下一跳”的方式，配套的 v4-via-v6 草案则继续处理路由器之间的转发模型。

于是，主机成功发出一个 ping 仍不足以证明业务完整。最少需要分别看到：租约被接受、RA 选中了预期设备、ND 得到了正确 MAC、该设备确实转发原生 IPv4，以及远端存在回到这台主机 /32 的路由。

/32 阻止旧邻接偷偷回来

如果给主机一个更宽的 IPv4 前缀，它就会把部分目标判断为同链路地址，继而重新发送 ARP。/32 不是地址节约技巧，而是机制边界。哨兵也不得成为转发包的源或目的地址；一旦它被当作真正网络对象，设计就被误读了。

草案把这一思想与托管网络中的 off-link gateway 实践相连，并列举 Hetzner、OVH 与 Scaleway 的单主机 IPv4 配置。这些例子说明运营者长期需要绕开子网邻接，但现有做法常依赖各操作系统的特殊设置。它们不是三家企业已经部署新哨兵方案的证明，相关说法必须保留“草案称”的边界。

RFC 8925 从另一方向减少 IPv4：支持的终端可以优先采用 IPv6-only。哨兵解决的则是仍要保留原生 IPv4 的双栈终端。两者可以出现在同一个 IPv6-mostly 网络，却不能互相代替验证。

旧主机走的是另一条路

不认识哨兵的系统会把它当成普通网关并发送 ARP。草案建议路由器用自己的 MAC 回答，从而让新旧两类主机共享网段。兼容性很实用，也可能掩盖问题。

旧主机能通信，只说明兼容 ARP 应答器有效，并未证明新主机从 IPv6 选对了路由器。新主机能通信，也不能证明旧主机仍有服务。两类路径应有独立测试客户端、计数器和服务承诺。

IETF 126 的讨论还给出了另一种比较。Tobias Fiebig 认为，相比把 DHCPv4 放进 DHCPv6，这个方案很优雅。所谓优雅，是线上的协议动作更少，而不是状态更少。状态从重复的 IPv4 邻居发现，转移到既有的 IPv6 路由器与邻居管理。

运行代码同时展示了缺口

公开仓库 v4-with-v6-nh 提供了 Linux 用户态守护进程。它识别哨兵，依据 RFC 4191 选择路由器，安装“IPv4 路由经 IPv6 下一跳”的内核项，在路由器变化时更新，并在前提消失时撤回。Linux 从 5.2 起已能表达这种路由。

仓库对边界的记录同样重要。守护进程无法在第一份 RA 之前逐包排队，因此启动行为只是对规范的近似；systemd-networkd 支持仍是一份补丁；FreeBSD 语法经过检查却没有实际测试；商用设备配置没有硬件验证；仓库也没有正式版本标签。

这足以证明控制平面思路可执行，却不足以证明全面生产成熟。真正的合规实验要主动制造变化：DHCP 到期、首份 RA 迟到、首选路由器撤回、邻居状态老化、回程 /32 消失、同优先级路由器竞争，以及新旧主机混合。

取消 ARP 只是移动信任边界

对支持方案的主机而言，少掉 ARP 可以减少欺骗面和运营噪声。但第一跳信任并未消失，它进入 IPv6 RA 与 ND。错误或恶意 RA 可能改变 IPv4 使用的 MAC；ND 故障也可能同时切断两种地址族。

因此，RA Guard、可信接入口、邻居状态检查和明确的路由器 preference 都成了 IPv4 可用性控制。最危险的情况没有明显报错：DHCP 在一个只实现了半套机制的网段发出哨兵，IPv4 静默停止。部分 DHCP 服务器或 relay 还可能因为“网关不在链路内”的校验先行拒绝配置。这两种失败共同说明，“成功配置”和“能够转发”必须分开记录。

来源