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

By Remco van Mook (Community Contributor & Technology Executive)

Remco van Mook

Remco is a Netherlands-based tech leader who has spent over 25 years exploring the intricacies of Internet architecture. He is a seasoned policy author, a former chair of the RIPE Connect working group, and served as a RIPE NCC board member from 2010 through 2025.

The Core Premise

Many networks that claim to be "IPv6-only" are actually tethered to the past, relying on legacy IPv4 subnets and the ~~Address Resolution Protocol (ARP)~~.

This article discusses a new IETF proposal designed to excise these dependencies. The goal is to allow IPv4 to function as a service delivered over an IPv6-only foundation, completely bypassing the need for traditional tunneling or translation.

Origin Story: This concept began as a lightning talk at RIPE 91 in Bucharest. The immediate resonance with network operators led to the creation of the Internet-Draft: draft-vanmook-intarea-ipv6-resolved-gateway. Currently in its third iteration, it is being reviewed by the IETF IntArea working group, with a presentation slated for IETF 126 in Vienna.

The "IPv6-Only" Paradox

For many operators, the transition to IPv6-only infrastructure is already a reality for control planes and data center fabrics. However, a "ghost" architecture of IPv4 usually persists.

Why? Because the ecosystem—applications, hardware, and legacy software—still demands IPv4. Consequently, engineers find themselves maintaining a clean IPv6 fabric while simultaneously managing:

IPv4 subnets
IPv4 gateway addresses
The archaic ARP protocol

The Hidden Toll of Dual-Stacking

When you ask a network engineer about the cost of dual-stacking, they will point to the obvious redundancies: double the ACLs, double the monitoring, and double the state. But the deeper pain lies in ARP.

ARP was built for small LANs, not massive modern infrastructures. In high-scale environments, it becomes a liability:

Instability: ARP storms and cache poisoning.
Resource Exhaustion: Table overflows on large Layer 2 segments.
Race Conditions: Gratuitous ARP issues during failover events.
Virtualization Chaos: Debugging MAC addresses that shift unpredictably across virtualized hosts.

Example: In a previous CTO role, I witnessed a deployment of 10,000 VMs generating a staggering $\approx 500,000$ ARP requests per second.

The Economics of Address Waste

IPv4 addresses are now expensive commodities. Traditional subnetting is inherently wasteful. For instance, a point-to-point link using a $/30$ prefix wastes $50\%$ of its addresses on the network and broadcast identifiers.

Using the proposed mechanism:

Traditional: $\text{Subnet} \rightarrow \text{Network ID} + \text{Broadcast} + \text{Gateway} + \text{Hosts}$
Proposed: $\text{Host} \rightarrow \text{Single } /32 \text{ address}$

By treating IPv4 as a $/32$ service, operators eliminate the need to allocate, document, and renumber entire subnets.

Current "Shadow" Solutions

The industry has already tried to solve this, but in a fragmented, non-standardized way. Large-scale hosting providers (like Hetzner, OVHcloud, and Scaleway) use proprietary "hacks" to force hosts to communicate with gateways that exist outside their own subnet.

Provider	Configuration Method	Technical Approach
Hetzner	`routes`	Sets `on-link: true` for the default route
OVHcloud	`post-up`	Adds a specific host route to the gateway
Scaleway	`iface`	Uses point-to-point static configuration

These workarounds are OS-specific and vary by provider. For example, a user might have to apply a specific netplan configuration or a post-up script:

# Example of a provider-specific workaround
post-up route add x.y.z.254 dev eth0

While these methods leverage the DHCPv4 Router Option (RFC 2132) in ways the original authors likely didn't intend, they work. However, the lack of a standard leads to a total failure of interoperability.

Why Not Just Update DHCPv4?

One might ask: Why not simply create a new DHCPv4 option that provides an IPv6 next-hop address?

The answer is ecosystem inertia. The entire OSS/BSS (Operations/Business Support Systems) world is hardcoded to recognize an IPv4 gateway as four octets.

IPAM tools $\checkmark$
Billing platforms $\checkmark$
Customer portals $\checkmark$
NOC runbooks $\checkmark$

Changing the format of a gateway address would require a global coordination effort spanning decades. The software stack "bites back" when the data doesn't fit the expected shape.

The Proposed Solution: The Sentinel Value

Instead of changing the format, the draft proposes a sentinel value.

The address 192.0.0.11 is designated as a special-purpose marker.

How it works:

The DHCPv4 server provides 192.0.0.11 via the standard Option 3 (Router Option).
Because it is a valid IPv4 address, every existing IPAM, relay, and provisioning system accepts it without error.
The "magic" happens at the network layer, where this specific value triggers the resolved gateway behavior.

Project Roadmap

Lightning talk at RIPE 91
Draft creation (draft-vanmook-intarea-ipv6-resolved-gateway)
Presentation at IETF 126 (Vienna)
Formal adoption call