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

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.

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

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.

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

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.

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.

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.

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.

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

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.

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:

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 DHCPv4 Router Option but nothing prohibits it, which is precisely why it spread without anyone feeling the need to write a standard. Every provider inventing its own gateway address and its own configuration recipe is exactly the kind of interoperability failure the IETF exists to fix.

Why not just fix DHCP?

The obvious counter-question: why not define a new DHCPv4 option that carries an IPv6 next-hop, and do this properly? Because the DHCPv4 option is the easy part (and even that is measured in years, not months). The hard part is everything around it. Every IPAM, every provisioning system, every billing platform, every customer portal, every monitoring tool, every NOC runbook, and every networking textbook in existence knows what an IPv4 default gateway looks like: four octets in a familiar field. That knowledge is encoded in validation logic across the entire OSS/BSS ecosystem. Changing what an IPv4 gateway looks like is an industry-wide coordination problem measured in decades, and every time you change something at the protocol level, the rest of the software stack bites back if it's not exactly the shape it expects.

So don't change the shape: change what it means.

The mechanism: one sentinel value

The draft defines a single special-purpose IPv4 address - 192.0.0.11 - as a sentinel. A DHCPv4 server hands it out as the ordinary Router Option (Option 3), exactly as it would any gateway address. Every DHCP server, relay, IPAM and provisioning system on the planet handles it today, unchanged, because it looks exactly like what they expect. The change lives in the one place that needs to know: the host. A host stack that implements the draft recognises the sentinel and, instead of sending an ARP request for it, resolves the link-layer address from its IPv6 neighbour cache - where the default router's MAC address already sits, learned through ordinary Router Advertisements and Neighbour Discovery. The IPv4 packet goes out in a link-layer frame addressed to the router's MAC. Native IPv4, end to end. No ARP, no IPv4 subnet, no IPv4 address on any router interface, no tunnelling, no translation. And critically: a host that has not been updated simply ARPs for 192.0.0.11 as it always would, and the router answers with its own MAC. The router functionally owns the address on that interface. Updated and unmodified hosts coexist on the same segment indefinitely. There is no flag day, no mandatory switch-over point. The operator decides if and when to switch off ARP entirely.

On the router side, the mechanism slots directly into RFC 8950 - IPv4 prefixes with IPv6 next-hops - which is already deployed in production in some of the largest networks in the world, and into draft-ietf-intarea-v4-via-v6, currently in IETF Last Call, which handles the router-to-router side. That draft explicitly leaves the host first-hop gap open; this one closes it. Together they form a single-stack network architecture, serving dual-stack endpoints.

IPv4 stops being an architecture that permeates your network and becomes what it always has been to applications: a service endpoint identifier. But carried over an otherwise IPv6-only transport.

A bonus: one universal gateway address

Something useful falls out of the shape of this solution, without being a design goal. Once 192.0.0.11 is a well-known address that routers answer for, the three provider-specific gateway addresses in the table above collapse into one. A server image built for one provider works at the next. One IPAM template, one provisioning recipe, everywhere. The security properties come along for free. The address carries no subnet membership information and reveals nothing about topology. Per its IANA registration it is non-forwardable and invalid as a source address in forwarded packets, so it is unreachable from off-link - eliminating it as a target for remote attack and precluding volumetric abuse. Poisoning its ARP entry gains an attacker nothing a rogue RA wouldn't, and both are mitigated by existing controls. If this sounds familiar, it should: IPv6 has used link-local addresses as topology-independent next-hops for twenty years.

Nobody asks whether fe80::1 is "on the right subnet". 192.0.0.11 gives IPv4 the same property.

Working code

A reference implementation for Linux is available at github.com/remcovanmook/v4-with-v6-nh: host-side resolution logic, Bird2/OSPFv3 configuration advertising local /32s with IPv6 next-hops into the fabric, and systemd units for deployment. No kernel patches.

The fallback mechanism has been verified to work with the router answering ARP, requiring no changes to operating systems, applications or DHCPv4 configuration on Windows 11 and earlier, macOS, Android, iOS, Linux, FreeBSD, and ChromeOS.

Where this stands, and what you can do

The draft is at revision -01 in the IETF IntArea working group as an individual submission. It has picked up support on the list - including from David Lamparter, who together with Tobias Fiebig has withdrawn their adjacent route4via6 work in favour of this approach, and Jordi Palet Martínez, whose terminology review sharpened the document considerably. The IntArea chairs have invited a presentation at IETF 126 in Vienna (18-24 July), with a working group adoption call expected after the meeting.

This is where the operator community comes in. IETF working group adoption is driven by demonstrated interest - and the people who feel this problem daily are reading RIPE Labs, not the int-area list. If eliminating ARP and IPv4 subnets from your infrastructure would matter to your network, say so: a short message to int-area@ietf.org noting operational interest carries real weight in an adoption call. If you are at IETF 126, come to the IntArea session. The IPv4 Internet isn't going away, and applications will carry IPv4 dependencies for years to come. But the infrastructure that carries IPv4 traffic doesn't need to be dual-stack any more. It never did: we just didn't have a standard way to say so.