仅IPv6网络通常仍依赖于IPv4子网和ARP。本文介绍了一个IETF提案，旨在消除这两者，使IPv4能够在仅IPv6的基础设施上作为服务运行，而无需翻译或隧道。本文源于在布加勒斯特RIPE 91会议上进行的主题为《告别ARP》的闪电演讲。来自与会室的反应以及事后的走廊交谈清楚表明，这个问题是运营商社区立即认知的。随后的互联网草案draft-vanmook-intarea-ipv6-resolved-gateway现在已进入IETF IntArea工作组的第三个版本，并计划在维也纳的IETF 126会议上进行演示，并预计在会议后进行采用呼叫。本文讲述了其背后的故事，并解释了为什么如果你经营网络，你可能会想要关心这个问题。除IPv4外的IPv6仅在过去几年中，对于大多数运营商来说，IPv6仅基础设施一直触手可及。路由协议已经到位，地址空间也可用，工具已经成熟。目前，许多数据中心架构和接入网络正运行IPv6仅控制平面。但几乎所有这些网络仍然携带着1982年时代的一丝“行李”：一套平行的IPv4架构。这并不是因为IPv6无法完成工作，而是因为在网络上运行的应用程序、设备和遗留系统仍然希望IPv4存在。因此，网络团队在构建了一个完美干净的IPv6仅架构后，发现自己还需要维护IPv4子网、IPv4网关地址和ARP，永远如此。双栈的隐性成本询问网络工程师双栈的成本时，他们会从显而易见的因素开始：两个地址族，两套ACL，两组监控配置，双倍的状态。这是确实的，但它低估了问题的严重性。ARP作为操作负担。ARP是一种为具有数十个主机的局域网设计的广播协议，而不是数千个。在现代基础设施中，这是一个持续痛苦的来源：ARP风暴、缓存中毒、大型L2段上的表耗尽、故障转移期间的无偿ARP竞争，以及在虚拟化基础设施上调试ARP的乐趣，其中MAC地址的不确定性移动。在我之前的首席技术官角色中，我目睹了1万台客户服务器和虚拟机每秒愉快地生成50万个ARP请求。这个数字就是草案来源的地方。地址经济学。IPv4地址在二级市场上以几十美元的单价交易，小块运营商实际需要的地址则价格更高。每个常规的IPv4子网在网络、广播和网关开销上消耗地址——一个/30的点对点链接浪费了一半的地址。借助本文描述的机制，一个主机只需要一个IPv4地址：它自己的/32。没有其他。子网扩展。每个IPv4子网都需要分配、记录、路由和最终重新编号。在仅IPv6基础设施上作为纯/32服务承载IPv4的网络除了主机地址本身之外，没有其他任何分配。安全态势。/24给攻击者提供了254个通过ARP探测的目标。没有ARP的/32主机网络没有子网可供扫描。已经在生产中解决 - 但做得很糟糕。对标准社区来说，不舒服的部分是，这个问题已经被大规模的托管服务提供商解决了。问题是，他们的解决方案并不能互操作，这正是因为没有可供遵循的标准。如果你曾经在Hetzner、OVHcloud或Scaleway上配置过专用服务器或云实例，你就会看到：你的服务器获得一个/32（或一个网关明显在你的前缀之外的地址），而服务提供商的文档会带你完成让它工作所需的特定于操作系统的咒语：提供商的变通方案提供商配置Hetzner路由:[到:0.0.0.0/0, 通过:172.31.1.1, 链路上: true]OVHCloud post-up route add <x.y.z.254> dev eth0Scaleway iface eth0 inet static ... pointopoint 62.210.0.1 三个提供商。三种不同的网关地址。三种不同的每个操作系统机制：netplan链路，post-up主机路由，pointopoint。所有这些都要求使主机ARP请求一个不在其子网内的网关。今天，数以百万计的（虚拟）服务器以这种方式运行。所有这些都没有在任何RFC中记录：RFC 2132的作者几乎肯定没有考虑过这种DHCPv4路由器选项的用途，但没有任何东西禁止它，这正是为什么它在没有人觉得需要编写标准的情况下蔓延。每个提供商都发明自己网关地址和配置方式，这正是IETF存在的原因 - 解决互操作性故障。为什么不修复DHCP？显而易见的反问：为什么不定义一个新的DHCPv4选项，携带一个IPv6下一跳，并正确地做到这一点？因为DHCPv4选项是简单的部分（即便如此也以年计，而不是月计）。难点在于其周围的一切。每个IPAM，每个配置系统，每个计费平台，每个客户门户，每个监控工具，每个NOC运行手册，每个...