告别ARP：纯IPv6网络如何承载IPv4服务

背景

在IPv6-only网络架构日益成熟的今天，绝大多数运营商仍然在IPv6基础设施之上保留着一套平行的IPv4架构。这并不是因为IPv6无法胜任工作，而是因为运行在网络之上的应用、设备和遗留系统仍然期望IPv4的存在。因此，网络团队在构建了干净的IPv6-only网络后，不得不持续维护IPv4子网、IPv4网关地址和ARP（地址解析协议）。

ARP是一个为几十台主机设计的广播协议，在现代基础设施中却成为持续痛苦的来源：ARP风暴、缓存投毒、大规模L2段上的表项耗尽、故障切换时的免费ARP竞争，以及在MAC地址不可预测移动的虚拟化环境中调试ARP的噩梦。文章作者在担任CTO期间，曾观察到10000台客户服务器和VM每秒产生50万次ARP请求。正是这个数字催生了本文所介绍的IETF草案。

核心内容

该IETF提案（草案编号：draft-vanmook-intarea-ipv6-resolved-gateway）旨在消除IPv4子网和ARP，使IPv4作为一项服务运行在纯IPv6基础设施之上，无需任何翻译或隧道技术。其核心机制是定义一个特殊用途的IPv4地址——192.0.0.11——作为哨兵值。

工作原理：DHCPv4服务器将192.0.0.11作为普通的Router Option（Option 3）分发给主机，就像分发任何网关地址一样。全球所有DHCP服务器、中继、IPAM和配置系统无需任何修改即可处理这个地址，因为它的格式与它们期望的完全一致。变化仅发生在需要知道的地方：主机端。实现了该草案的主机栈在收到192.0.0.11后，不会发送ARP请求，而是从其IPv6邻居缓存中解析链路层地址——该地址已经通过常规的路由器通告和邻居发现学习到。IPv4数据包被封装在链路层帧中，直接发送到路由器的MAC地址。结果是原生的端到端IPv4，没有ARP，没有IPv4子网，路由器接口上没有IPv4地址，没有隧道，没有翻译。

关键兼容性：未升级的主机会像往常一样对192.0.0.11发送ARP请求，路由器会用自己的MAC地址应答。这意味着该地址在功能上被路由器拥有。已升级和未升级的主机可以在同一网段无限期共存，没有强制切换日，运营商可以自行决定何时彻底关闭ARP。

路由器侧：该机制直接对接RFC 8950（IPv4前缀与IPv6下一跳）——已在全球一些最大网络中部署——以及目前处于IETF Last Call阶段的draft-ietf-intarea-v4-via-v6（处理路由器到路由器侧）。后者明确留下了主机第一跳的缺口，而本提案正好填补了这个缺口。两者结合形成单栈网络架构，服务于双栈端点。

为何不直接修改DHCP：定义一个新的DHCPv4选项来携带IPv6下一跳虽然理论上可行，但困难在于它周围的一切：每个IPAM、每个配置系统、每个计费平台、每个客户门户、每个监控工具、每个NOC运行手册、每本网络教科书都知道IPv4默认网关长什么样——四个八位字节的熟悉字段。这些知识编码在整个OSS/BSS生态系统的验证逻辑中。改变IPv4网关的形态是一个跨行业协调问题，需要以十年计的时间。因此，提案不改变形式，而是改变其含义。

关键要点

• 哨兵地址：192.0.0.11被IANA注册为非转发地址，且在转发数据包中作为源地址无效，因此从链路外不可达，消除了作为远程攻击目标的可能性，也防止了容量滥用。
• 消除ARP：主机不再需要进行ARP请求，ARPs被彻底告别。这消除了ARP风暴、缓存投毒、表项耗尽等运维痛点。
• 地址经济学：主机只需一个IPv4地址（自己的/32），无需网络地址、广播地址和网关地址开销。一个/30点对点链路原本浪费一半地址，现在零浪费。
• 安全提升：传统的/24子网给攻击者提供254个可通过ARP探测的目标，而/32主机网络没有ARP，也就没有子网可供扫描。
• 生产环境已有实践但互不兼容：Hetzner、OVHcloud、Scaleway等大型托管商已经在大规模使用类似方案，但各自使用不同的网关地址和操作系统配置方法。例如：Hetzner使用不同的网关地址，OVHcloud使用不同地址，Scaleway使用不同地址，且各自的配置方式（netplan on-link、post-up host routes、pointopoint）各不相同。这些方案没有遵循任何RFC，导致互操作性缺失。
• 通用网关地址：一旦192.0.0.11成为所有路由器都会应答的知名地址，上述三家提供商的不同网关地址将统一为一个。一个为某提供商构建的服务器镜像可以无缝迁移到另一家。一个IPAM模板、一个配置配方即可通用。

意义与影响

该提案的意义在于将IPv4从一种渗透全网架构的协议，转变为对应用而言始终如一的角色：服务端点标识符。IPv4不再需要子网、ARP和路由器接口地址，而是作为纯IPv6传输上的一个服务层存在。这解决了运营商在双栈维护中面临的隐藏成本：两个地址族、两套ACL、两套监控配置、双倍的状态量，以及持续不断的ARP运维负担。

从行业标准角度看，该提案填补了IETF在主机第一跳上的空白，与RFC 8950和draft-ietf-intarea-v4-via-v6共同构成完整的单栈网络架构。它提供了一条平滑的演进路径：无需强制切换日，已升级和未升级的主机可以长期共存，运营商可以逐步淘汰ARP。

从产业影响看，它终结了大型托管商各自为政的互操作性困局。一个统一的哨兵网关地址意味着服务器镜像的跨提供商迁移、IPAM模板的标准化、运维手册的简化，以及整个行业生态的降本增效。此外，该地址的安全属性——不可转发、不可作为源地址、从链路外不可达——天然消除了远程攻击面和容量滥用风险，为网络防御提供了额外保障。

该提案当前为第三个版本，已在IETF IntArea工作组面前，计划在维也纳的IETF 126会议上进行展示，预计会后将启动采纳流程。如果被采纳，它将为IPv6-only网络如何承载IPv4服务提供一个标准化的、经过生产验证的、可互操作的解决方案。