告别ARP：纯IPv6网络上的IPv4服务

# 告别ARP：纯IPv6网络上的IPv4服务 来源：https://labs.ripe.net/author/remco-van-mook/a-farewell-to-arps-ipv4-service-on-ipv6-only-networks/ 纯IPv6网络往往仍依赖IPv4子网和ARP。本文介绍一项IETF提案，旨在消除这两者，使IPv4能在纯IPv6基础设施上作为服务运行，无需翻译或隧道。 --- 本文源自布加勒斯特RIPE 91上的一场闪电演讲，题为《告别ARP》（https://ripe91.ripe.net/programme/meeting-plan/sessions/10/Y8YVLE/）。现场反响和会后的走廊交谈表明，这是运营者社区一眼就能认出的问题。随后提交的互联网草案`draft-vanmook-intarea-ipv6-resolved-gateway`（https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway/）目前已进入第三版，并将在IETF 126维也纳会议上进行演示，预计会后启动工作组的采纳投票。本文讲述了它背后的故事——并解释了为什么如果你运营网络，可能会关心这件事。 ## 纯IPv6，但除IPv4外 对大多数运营者来说，纯IPv6基础设施已经触手可及多年。路由协议有了，地址空间有了，工具也成熟了。许多数据中心网络和接入网现在都运行着纯IPv6的控制平面。但这些网络中，几乎每一个都还拖着一小块1982年的遗留：并行的IPv4架构。不是因为IPv6做不到，而是因为运行在网络之上的应用、设备和遗留系统仍然期望IPv4存在。因此，网络团队构建了完全干净的纯IPv6架构，却发现自己还得同时维护IPv4子网、IPv4网关地址和ARP。永远如此。 ## 双栈的隐性成本 问网络工程师双栈的成本，他们会从显而易见的地方开始：两个地址族、两套ACL、两套监控配置、状态翻倍。这些确实存在，但还低估了问题。 **ARP成为运营负担。** ARP是为只有几十台主机的局域网设计的广播协议，而非数千台主机的环境。在现代基础设施中，它持续带来痛苦：ARP风暴、缓存毒化、大型L2段上的表项耗尽、故障切换时的免费ARP竞争，以及在MAC地址随意移动的虚拟化基础设施上调试ARP的乐趣。在之前担任CTO时，我曾目睹10000台客户服务器和虚拟机每秒产生50万次ARP请求。这个数字正是本草案的由来。 **地址经济学。** IPv4地址在二级市场上单价达数十美元，而运营者实际需要的小段地址更是溢价严重。每个传统的IPv4子网都会在网络、广播和网关开销上浪费地址——一个/30的点对点链路会浪费一半地址。采用本文描述的机制，一台主机只需一个IPv4地址：它自己的/32。不再需要其他任何地址。 **子网蔓延。** 每个IPv4子网都需要分配、记录、路由，最终还要重新编号。若网络只在IPv6基础设施上承载纯/32的IPv4服务，则除了主机地址本身，无需分配任何东西。 **安全态势。** 一个/24段为攻击者提供了254个ARP可探测的目标。而由/32主机组成的网络没有ARP，也就没有可扫描的子网。 ## 已在生产环境中解决——但解决得很糟糕 让标准社区尴尬的是，这个问题已经被大型托管提供商在规模上解决了。问题在于，它们的解决方案互不兼容，恰恰因为没有可遵循的标准。 如果你曾在Hetzner、OVHcloud或Scaleway配置过独立服务器或云实例，你应该见过：服务器得到一个/32（或一个网关明显不在前缀内的地址），提供商的文档会引导你通过特定操作系统的咒语让它工作： | 提供商 | 解决方法 | 配置 | |--------|----------|------| | Hetzner | routes: [ to: 0.0.0.0/0, via: 172.31.1.1, on-link: true ] | | OVHCloud | post-up route add dev eth0 62.210.0.1 | | Scaleway | iface eth0 inet static ... pointopoint 62.210.0.1 | 三家提供商。三个不同的网关地址。三种不同的操作系统特定机制：netplan on-link、post-up主机路由、pointopoint。全部在强制同一件事：让主机为其子网之外的网关进行ARP。 如今，数百万台（虚拟）服务器就这样运行着。这些都没有在任何RFC中记载：RFC 2132（https://datatracker.ietf.org/doc/html/rfc2132）的作者们几乎肯定没有设想过DHCPv4路由器选项的这种用途，但没有任何东西禁止它——这正是它无需制定标准就传播开来的原因。每家提供商自行发明自己的网关地址和配置方法，正是IETF旨在修复的那种互操作性失败。 ## 为什么不直接修复DHCP？ 一个明显的反问：为什么不定义一个新的DHCPv4选项来携带IPv6下一跳，然后恰当地实现？因为DHCPv4选项是简单的部分（即使也需要数年而非数月）。困难的部分是它周围的一切。 每个IPAM、每个配置系统、每个计费平台、每个客户门户、每个监控工具、每个NOC操作手册、每本网络教科书——它们都*知道*IPv4默认网关长什么样：一个熟悉字段中的四个八位组。这种知识编码在整个OSS/BSS生态系统的验证逻辑中。改变IPv4网关的形态是一个整个行业范围内的协调问题，需要数十年时间；每当你改变协议层面的东西，其余软件栈都会反弹，除非它恰好是它们期望的形状。 **所以，不要改变形状：改变它的含义。** ## 机制：一个哨兵值 草案定义了一个特殊的IPv4地址——`192.0.0.11`——作为哨兵。DHCPv4服务器将其作为普通路由器选项（选项3）分配，就像分配其他任何网关地址一样。地球上每个DHCP服务器、中继、IPAM和配置系统都能原封不动地处理它，因为它看起来完全符合它们的预期。 变化存在于唯一需要知道的地方：主机。实现了本草案的主机协议栈会识别该哨兵，并转而从IPv6邻居缓存中解析链路层地址——默认路由器的MAC地址已经在那里，通过通常的路由器通告和邻居发现学习到。IPv4报文以由路由器MAC作为目标地址的链路层帧发送出去。端到端的原生IPv4。没有ARP，没有IPv4子网，没有路由器接口上的IPv4地址，没有隧道，没有转换。 关键是：一台*未更新*的主机会照常为`192.0.0.11`发起ARP，路由器则用自己的MAC应答。路由器在功能上拥有该接口上的那个地址。更新和未更新的主机可以在同一网段上无限共存。没有切换日，没有强制切换点。运营者可以自行决定是否以及何时完全关闭ARP。 在路由器侧，该机制直接适配RFC 8950（https://datatracker.ietf.org/doc/html/rfc8950）——带IPv6下一跳的IPv4前缀——该机制已在全球一些最大的网络中部署生产，并适配当前处于IETF最后呼的`draft-ietf-intarea-v4-via-v6`（https://datatracker.ietf.org/doc/draft-ietf-intarea-v4-via-v6/），该草案处理路由器到路由器的部分。后者明确留下了主机第一跳的缺口，而这个草案补上了。二者共同构成一个单栈网络架构，服务于双栈端点。IPv4不再是你网络中渗透的架构，而成为它一直对应用所起的作用：一个服务端点标识符。只不过现在是在纯IPv6传输上承载。 ## 额外好处：一个通用的网关地址 这个解决方案的形状会带来一个并非设计目标的有用副产品。一旦`192.0.0.11`成为路由器响应的一个众所周知地址，上表中三个提供商特定的网关地址就合并为一个。为一个提供商构建的服务器镜像可以直接在另一家使用。一个IPAM模板，一个配置方案，到处通用。 安全属性随之而来。这个地址不携带任何子网成员信息，也不泄露任何拓扑信息。根据IANA注册，它不可转发，且在被转发报文中不能作为源地址，因此无法从链路外可达——这消除了它作为远程攻击的目标，并排除了对大流量滥用的可能性。毒化它的ARP条目给攻击者带来的好处不会超过恶意的RA，而两者都可以通过现有控制措施缓解。 如果听起来耳熟，确实应该如此：IPv6使用链路本地地址作为与拓扑无关的下一跳已有二十年。没人问`fe80::1`是否“在正确的子网上”。`192.0.0.11`给了IPv4同样的属性。 ## 工作代码 Linux参考实现可在`github.com/remcovanmook/v4-with-v6-nh`（https://github.com/remcovanmook/v4-with-v6-nh）获取：主机侧解析逻辑、发布带有IPv6下一跳的本地/32的Bird2/OSPFv3配置、以及用于部署的systemd单元。无需内核补丁。 回退机制已验证能在路由器通过ARP应答的情况下正常工作，Windows 11及更早版本、macOS、Android、iOS、Linux、FreeBSD和ChromeOS上对操作系统、应用或DHCPv4配置**无需**任何修改。 ## 现状及你可以做什么 该草案目前作为个人提交在IETF IntArea工作组中，版本为revision -01（https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway/）。它在邮件列表中获得了支持——包括David Lamparter，他与Tobias Fiebig（https://labs.ripe.net/author/tfiebig/）一起撤回了他们相邻的*route4via6*（https://datatracker.ietf.org/doc/draft-equinox-intarea-dhcpv4-route4via6/）工作以支持本方法；以及Jordi Palet Martínez（https://labs.ripe.net/author/jordipaletm/），他的术语审阅使文档大为改善。 IntArea主席已邀请在维也纳IETF 126（7月18–24日）上进行演示，预计会后将进行工作组采纳投票。这就是运营者社区发挥作用的地方。IETF工作组采纳由展示的兴趣驱动——而每天感受这个问题的人是阅读RIPE Labs的，而不是int-area列表。 如果消除ARP和IPv4子网对你的网络很重要，请表达意见：向`[email protected]`（mailto:[email protected]）发送简短邮件说明运营兴趣，在采纳投票中具有实际分量。如果你在IETF 126，请参加IntArea会议。 IPv4互联网不会消失，应用在未来的多年内仍会带有IPv4依赖。但承载IPv4流量的基础设施不再需要是双栈了。它从来就不需要：我们只是没有一种标准方式来这样说。