A Farewell to ARPs: IPv4 Service on IPv6-Only Networks | RIPE Labs

Remco van Mook

A Farewell to ARPs: IPv4 Service on IPv6-Only Networks

Remco van Mook(community contributor)

Remco van Mook

Based in The Netherlands

Technology executive with a passion for Internet and how the pieces come together - going down that rabbit hole for 25+ years. Prolific policy author, former chair of the Connect working group in the RIPE community and board member of RIPE NCC from 2010 to 2025. More

9 min read — 13 Jul 2026

ipv6

events

25

Click to like, and right click to unlike this article.

Share

Share

X/Twitter<br>LinkedIn<br>Facebook<br>Mastodon<br>Vkontacte<br>Telegram<br>Whatsapp<br>Email<br>Copy link

More

IPv6-only networks often still depend on IPv4 subnets and ARP. This article introduces an IETF proposal to eliminate both, allowing IPv4 to operate as a service over IPv6-only infrastructure without translation or tunnelling.

This article grew out of a lightning talk at RIPE 91 in Bucharest, titled A Farewell to ARPs. The reaction from the room and the hallway conversations afterwards made it clear this is a problem the operator community recognises immediately.<br>The Internet-Draft that followed, draft-vanmook-intarea-ipv6-resolved-gateway, is now in front of the IETF IntArea working group in its third version, with a presentation scheduled at IETF 126 in Vienna and an adoption call expected after the meeting. This article tells the story behind it - and explains why, if you operate a network, you might want to care.

IPv6-only, except for IPv4<br>For most operators, IPv6-only infrastructure has been within reach for years. The routing protocols are there. The address space is there. The tooling has matured. Plenty of datacentre fabrics and access networks run IPv6-only control planes right now.<br>But almost every one of those networks still carries a quiet piece of 1982-era baggage: a parallel IPv4 architecture. Not because IPv6 can't do the job, but because the applications, devices, and legacy systems riding on top of the network still expect IPv4 to be there. So the network team, having built a perfectly clean IPv6-only fabric, finds itself maintaining IPv4 subnets, IPv4 gateway addresses, and ARP alongside it. Forever.

The hidden cost of dual-stack<br>Ask a network engineer what dual-stack costs and they'll start with the obvious: two address families, two sets of ACLs, two monitoring configurations, double the state. That's real, but it understates the problem.<br>ARP as an operational liability. ARP is a broadcast protocol designed for LANs with dozens of hosts, not thousands. In modern infrastructure it is a source of continuous pain: ARP storms, cache poisoning, table exhaustion on large L2 segments, gratuitous ARP races during failover, and the joys of debugging ARP on virtualised infrastructure where MAC addresses move unpredictably. In a previous CTO role, I watched 10,000 customer servers and VMs happily generate half a million ARP requests per second. That number is where this draft comes from.<br>Address economics. IPv4 addresses trade on the secondary market at tens of dollars apiece, with the small blocks operators actually need commanding a premium. Every conventional IPv4 subnet burns addresses on network, broadcast, and gateway overhead - a /30 point-to-point link wastes half its addresses. With the mechanism described here, a host needs exactly one IPv4 address: its own /32. Nothing else.<br>Subnet sprawl. Every IPv4 subnet needs to be allocated, documented, routed, and eventually renumbered. A network that carries IPv4 as a pure /32 service on IPv6 infrastructure has nothing to allocate except the host address itself.<br>Security posture. A /24 gives an attacker 254 targets to probe via ARP. A network of /32 hosts with no ARP has no subnet to scan.

Already solved in production - badly<br>The uncomfortable part for the standards community is that the problem is already being solved, at scale, by large hosting providers. The problem is, their solutions are just not interoperable, exactly because there's no standard they could follow.<br>If you have ever provisioned a dedicated server or cloud instance at Hetzner, OVHcloud, or Scaleway, you have seen it: your server gets a /32 (or an address with a gateway conspicuously outside your prefix), and the provider's documentation walks you through the OS-specific incantation to make it work:

Provider workarounds

Provider

Configuration

Hetzner

routes: [ to: 0.0.0.0/0, via: 172.31.1.1, on-link: true ]

OVHCloud

post-up route add dev eth0

Scaleway

iface eth0 inet static ... pointopoint 62.210.0.1

Three providers. Three different gateway addresses. Three different per-OS mechanisms: netplan on-link, post-up host routes, pointopoint. All forcing the same thing: make the host ARP for a gateway that isn't on its subnet. Millions of (virtual) servers run this way today. None of it is documented in any RFC: the authors of RFC 2132 almost certainly never contemplated this use of the...