What's ARP Got to Do with It?

In the two weeks since RIPE Labs published A Farewell to ARPs, the same question came back from every direction: the mailing lists, the article comments, private mail, hallway conversations. It goes roughly like this: "It's only ARP. It has worked for forty years. It still works. How much can it really matter?" It seems people really like ARP, and get very defensive about it.

It's a fair question and it deserves a straight answer.

A tale of two IPv4s

There are two different things we call IPv4, and we have spent four decades pretending they are one.

The first is small-i internet IPv4: reachability to and from everything that lives past your first hop. The public IPv4 internet, certainly, but just as much your own enterprise IT: the ERP system three hops away, the file server in another building, every internal service your applications still open IPv4 sockets to. If it isn't on your wire or WiFi, it belongs here. This is where the demand lives, and the demand is real and durable. Nobody disputes it.

The second is local-network IPv4: the subnet on your segment, the broadcast domain, ARP, a gateway that has to be your on-link neighbour - everything that is on your local wire or WiFi. This is architecture, not demand. And here is the thing: needing to reach IPv4 has always meant having to be on an IPv4 network. That conflation is the actual subject of my draft; everything else is mechanism.

On the segments where most of the public Internet actually lives, the local network never mattered in the first place. Access networks and hosting segments actively suppress lateral traffic: port isolation, split horizon, private VLANs. Subscribers don't talk to subscribers; tenants don't talk to tenants. Only the gateway was ever used. The IPv4 subnet on those segments is an on-link fiction, maintained so that ARP can find the way out, wrapped in an isolation apparatus to make sure the 'on-linkness' is never used for anything else.

The evidence for this is in writing: it has been in the RFC series for a quarter of a century. Every /30 ever deployed admitted that a subnet can contain nothing but the two ends of a wire; RFC 3021 standardised that admission in the year 2000 by deleting the network and broadcast addresses as meaningless. A large access subnet is just the shorthand version: a /24 with port isolation is 254 of those /31s written as one prefix. The netmask was only a compression scheme. ARP was the decompressor.

The layer cake

So what actually stands on a local network? From the bottom up:

1. The subnet. The on-link jurisdiction; the netmask is the decision procedure: ARP or gateway.
2. ARP. The subnet's enforcement mechanism on multi-access links. What's ARP but a second-hand resolution: it acts on the subnet's decision, it doesn't make one.
3. FHRP. The subnet needs a gateway address, and ARP answers with a single owner, so somebody has to win an election in any resilient setup. VRRP, HSRP, CARP and friends exist for exactly this.
4. Carved address pools. Allocation follows the subnetting: pools sized per service area, ahead of demand, renumbered when demand shifts.
5. The IPv4 host. The only layer anyone actually wanted.

Bolted to the side of the cake sits the policing apparatus: DHCP snooping, dynamic ARP inspection, binding tables.

All of it is there because the base layer is an unauthenticated broadcast feeding a lookup table that only allows a single answer to exist. Four layers of scaffolding and a security annex, for one layer of payload.

None of it was bad engineering. ARP was designed on the assumption that it lived in isolation, and of course it was: in 1982 there was no adjacent wire protocol to design against. The remarkable part is what happened when that stopped being true. IPv6 arrived on the same wire carrying a modern resolution service, and IPv4 was never revisited with the new neighbour in mind. Instead, the dual-stack doctrine pushed rather the opposite: two complete stacks running as ships in the night, deliberately blind to each other. Forty years on, IPv4 still resolves as if it were alone on the wire. It hasn't been for decades.

Letting go

Now, what happens if you pull the base layer? Subnet deletion is exactly what providers like Hetzner, OVH and Scaleway did years ago, each in their own way, each documented in a provider wiki and in no RFC.

With the subnet gone, everything is off-link by construction, and ARP degenerates to one vestigial job: finding the gateway. The sentinel address in the draft, 192.0.0.11, deletes the vestige; the host resolves its way out through the IPv6 neighbour cache it already maintains.

No subnet also means no gateway address to elect. Not anycast in the technical sense, but it behaves like it where it counts: the entire FHRP machinery exists to work around ARP answering with a single owner, and the sentinel never touches the ARP layer, which is the one place that bites. So, FHRP vanishes.

No carving means pools go flat: any address works anywhere in the footprint, and nothing is stranded by subnet sizing anymore.

And finally, the policing annex collapses to a single rule, because the only thing that should ever send an ARP reply is the router.

What remains: IPv6 ND, a flat pool, and the IPv4 address. A /32 standing directly on the IPv6 neighbour discovery the segment already runs.

If that looks radical, consider that you probably use this every day. A VPN connection hands your laptop exactly this: a /32, no subnet, no ARP, no local IPv4 network, a next-hop that is nowhere "on-link" in any classical sense, and nobody has ever thought about it twice. The point-to-point worlds, VPNs, cellular bearers, the whole PPPoE era, all solved this long ago with encapsulation. Take away the encryption and the encapsulation and all that’s left is next-hop selection.

That is the entire draft.

It also settles a worry I heard several times, that host stacks and applications somehow assume subnets: every operating system and every application already runs subnet-less /32 IPv4 daily, on tunnel interfaces, including the closed platforms.

What the lab found

Since the first article, the reference repository has grown from one Linux daemon to five host-side realisations across four operating system families, with prebuilt binaries as release assets.

Failover testing produced the best discovery: because the sentinel is never elected through ARP, it can be configured on every router on a segment with zero coordination between them. No virtual MAC, no election protocol, no keepalives. Each host follows its own IPv6 router selection, exactly as it does for IPv6.

And with route propagation done properly, the return direction gets better than FHRP ever was. Every router can originate each host /32, so any assigned address is ECMP-reachable through every router on the segment. The host picks a single upstream winner; the network picks whatever paths win downstream. Active-active, by standard routing machinery, on the exact same hardware and firmware you have today.

The two directions even heal independently. Downstream failover runs at IGP convergence speed, with the host uninvolved. Upstream failover is paced by IPv6 router selection. Testing on Windows 11 produced the one operational caveat worth knowing: an IPv6 router that leaves silently stays in host router lists until its lifetime expires, so fast failover wants a graceful goodbye, a final Router Advertisement with lifetime zero. Which is precisely how native IPv6 behaves (or should, anyway); the draft adds nothing and takes nothing away.

The closed platforms told their own story. MacOS and Windows have no support for IPv4 routes with IPv6 next-hops, so the implementations there do the nearest equivalent available in user-space: follow the winning IPv6 router and pin its MAC address into a static ARP entry for the sentinel, resetting it whenever the IPv6 router changes. At boot, before the code runs, a few ARP requests can escape. That's not a bug but the design demonstrating itself: before the daemon starts, the machine is simply an unmodified host, and the router's ARP tier catches it. The migration model, running inside a single machine, at every boot.

Where this works

The principle above everything else: you don't need to run an IPv4 network to deliver an IPv4 endpoint. Then, per segment:

Datacentre and hosting. Three of Europe's largest providers have run /32 hosts with off-link gateways for years, each with their own address and their own per-OS recipe. The draft is that practice, standardised, on the IPv6 ND that was already there.

FTTH, DOCSIS and WiFi. A single public IPv4 per subscriber, over an IPv6-only access network, with pools that stop being carved per service area. Same one address per customer, far fewer addresses lost to ritual, and you can independently mix and match in your provisioning whether a customer gets a public IPv4, CGNAT or nothing.

Enterprise and campus. Unlike your home WiFi, this is a managed estate. What actually needs on-link IPv4 can be inventoried rather than guessed at. The genuinely IPv4-only museum pieces were already statically administered islands; a small legacy enclave continues exactly the management model they already have.

Where probably not

Two places to leave alone. Your home WiFi: billions of consumer devices and applications carry unknowable amounts of assumptions about local-network IPv4 reachability, from casting fallbacks to game discovery to that printer, and the home LAN is the one segment class where hosts genuinely do talk to each other over IPv4 in ways nobody can audit.

Anywhere the notion of a default gateway was invalid to begin with, the IXP peering LAN being the canonical example: no default gateway, every destination a peer, all traffic lateral by design. A mechanism built around finding the way out has nothing to offer a segment that is nothing but exits.

Where this stands

The draft was presented at the IntArea working group at IETF 126 in Vienna on 22 July. There was broad agreement in the room on the problem statement; the solution needs further discussion, which is what working groups are for. The chairs are taking the adoption question to the mailing list. If this matters to your network, int-area@ietf.org is where that discussion happens. Installable implementations are here.

The IPv4 Internet is not going away in bounded time, and nobody should pretend otherwise. It's that exact denial that has kept us from moving on.