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.
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:
| Provider | Configuration |
|---|---|
| Hetzner | routes: [ to: 0.0.0.0/0, via: 172.31.1.1, on-link: true ] |
| OVHCloud | post-up route add <x.y.z.254> 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 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.
Comments 9
Nick Hilliard •
fe80::1 is only "on the right subnet" because it's an interface-scoped address. When you reference it from an arbitrary host, potentially with multiple interfaces, you also specify the interface identifier in the address, e.g. fe80::1%eth0. We were able to implement interface identification in the IPv6 addressing model because it was a green-field protocol. We don't have that luxury in ipv4 which is at this stage the ultimate brown-field protocol. So, it's not accurate to say "192.0.0.11 gives IPv4 the same property", and it won't be accurate until "192.0.0.11%eth0" is generally accepted as an addressable destination in an arbitrary context in IPv4.
Remco van Mook •
Hi Nick, you are correct in pointing out that the analogy as written in the article is too much of a shortcut. fe80 gets its interface disambiguation from the addressing model itself, and that was a greenfield luxury. There will never be a 192.0.0.11%eth0. The mechanism doesn't need one though. The sentinel only appears in contexts that are already bound to an interface: the DHCPv4 lease arrives on an interface, the default route it produces is bound to that interface, and resolution happens there. It never appears in forwarded packets, so it's never an addressable destination in an arbitrary context, which is the ambiguity zone identifiers were invented to resolve. A multihomed host ends up with one interface-bound route per interface, much like its routing table already stores fe80 next-hops with an ifindex next to them. For diagnostics on a multihomed host, ping 192.0.0.11 follows the routing table and forcing an interface is ping -I or SO_BINDTODEVICE. Not pretty, but that's brownfield for you. The draft itself makes the narrower claim: topology independence, a value that works on any segment without carrying subnet membership information. The compression to "the same property" happened in this article, and that one's on me. Remco
Roman •
My five cents: Router ID: A Router ID is a 32-bit identifier conventionally represented in IPv4 dotted-decimal notation; it is not necessarily an IPv4 address assigned to an interface. It cannot be used as an ICMPv4 source address unless it is configured as an address—for example, on a loopback interface—and the router is configured to use it for ICMPv4 messages. Forwarding: The fast path normally does not query ARP/ND tables for every packet. ARP/ND resolves a neighbor and installs an adjacency/rewrite entry; the forwarding plane then uses FIB and adjacency entries, typically programmed in hardware/forwarding cache. DHCPv4 relay: How can an IPv4-unaddressed router interface relay DHCPv4? What value is used for giaddr, and how does the DHCP server select the correct client subnet or address pool? DHCPv4 service: If DHCPv4 relay is not possible, does this model require a local DHCPv4 server on the first-hop router? Rather than introducing a new provisioning mechanism and adding workarounds to DHCPv4, could DHCPv6 Prefix Delegation be extended to delegate an IPv4 prefix to a VM or bare-metal server? The delegated IPv4 prefix could then be routed via the client’s IPv6 link-local address. RFC 9663 already describes per-client IPv6 prefix delegation in large broadcast networks. A similar model for IPv4 prefixes might provide a cleaner provisioning approach, although it would require new DHCPv6 options and clearly defined IPv4-specific semantics.
Remco van Mook •
Hi Roman, Good points, all five. In order: Router ID: agreed, it's a 32-bit identifier and nothing more. The concern underneath, where router-originated ICMPv4 comes from on an unaddressed router, has two answers. On-link, the draft has the first-hop router source ICMP from 192.0.0.11 itself (section 5.2). For transit routers deeper in an IPv6-only core, that's v4-via-v6 territory, and the registry already holds the answer: 192.0.0.8, the IPv4 dummy address from RFC 7600, registered precisely as a placeholder source for routers with no IPv4 address of their own. It sits three doors down from the address this draft requests. Forwarding: exactly right, and it's how the mechanism works. Resolution binds when the adjacency is installed, not per packet. The IPv4 route's rewrite comes from the same adjacency object the IPv6 entry uses; NUD maintains it; nothing consults the ND table in the forwarding path. This is why RFC 8950 deployments needed no silicon changes, and it's arguably a simplification: one adjacency table serving two FIBs. Relay and giaddr: the relaying interface needs no address, giaddr needs a routable IPv4 address, and one loopback per relay router is enough. Where per-segment distinction matters, RFC 3527's link-selection sub-option decouples giaddr as return address from pool selection. But note that in this model the pool-selection problem largely dissolves: there are no per-segment subnets, so any /32 from the pool works anywhere, with Option 82 circuit-id carrying segment identity where policy wants it. A local DHCPv4 server on the first hop works too, but nothing requires it. On DHCPv6-PD for IPv4: it's a reasonable design, and the family exists (RFC 7341 does DHCPv4 transport over DHCPv6). Two things stop it in practice. New DHCPv6 options mean updating every DHCPv6 client and teaching the entire IPv4 provisioning ecosystem to speak DHCPv6, which puts you a decade out before meaningful coverage. And the largest host population there is, Android, has no DHCPv6 client at all, by explicit design choice. The sentinel works with every DHCPv4 client, server and relay that exists today, unchanged. That makes adoption before my retirement feasible. The relay/giaddr point deserves a sentence in the draft's deployment considerations; it'll go in the next revision. Remco
Roman •
RFC 9663 was authored by Google, and Google has published a post describing an Android implementation of a DHCPv6 client based on this approach: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1. There are also implementations available for Linux. Moreover, the following statement leaves the issue of how the network learns the return path unresolved. Therefore, it cannot be considered a complete solution to the problem. In contrast, the new DHCPv6 Prefix Delegation option conveys this information to the network natively: DRAFT text: For return traffic to reach end hosts, operators MUST ensure that host /32 routes with an IPv6 next-hop per [RFC8950] are present in the routing infrastructure, allowing routers to forward IPv4 traffic toward the correct first-hop without requiring IPv4 addresses on any router interface. The mechanism by which the routing infrastructure learns these host routes is outside the scope of this document.
Remco van Mook •
Hi Roman, Thanks for the pointer: as of September, Android ships a DHCPv6 client, for Prefix Delegation specifically (still no IA_NA; the post is explicit about why). What the post also does is date-stamp the deployment argument better than I ever could. DHCPv6-PD was standardised in RFC 3633 in December 2003; the first Android client arrived in 2025, twenty-two years later. A new DHCPv6 option carrying IPv4 semantics starts that clock again: today's PD clients, including Android's new one, wouldn't parse it, so every DHCPv6 client needs another update, and this time the entire IPv4 provisioning ecosystem needs to learn DHCPv6 as well. The sentinel needs none of that, which is the whole design. On the return path: it isn't in the draft because it isn't what was missing. RFC 8950 and v4-via-v6 already carry IPv4 routes with IPv6 next-hops through the routing infrastructure, and originating them from subscriber state is existing practice under both: the first-hop router is, or snoops, the DHCPv4 relay, lease state gives it the /32-to-interface binding, ND gives it the client's link-local, and it originates the route the way BNGs install subscriber routes today, tens of millions of times over. This draft deliberately covers the one thing that had no standard: the host's first hop. Note also that PD has the same second half: the delegated prefix is natively known at the delegating router, but beyond it the route is redistributed like any other. Both models reduce to the first hop learning a binding from DHCP state. Completeness is a property of the stack, and the stack is 8950 plus v4-via-v6 plus this. Worth adding: RFC 9663 and this draft are fighting the same war, per-device accountability and state that scales in large broadcast domains, just in different address families. I don't read them as competitors. You're clearly reading the draft closely, and this is exactly the kind of review it needs. The right places for it are the GitHub repo (github.com/remcovanmook/draft-ipv6-resolved-gateway) or the int-area list, where the adoption discussion will happen after Vienna. I'd genuinely welcome your comments there. Remco
Nico Declerck •
I'm trying to teach students your routers must always have one interface in your own network. Luckily I also teach them the only reason why is to have its MAC address. If I have to explain this, it'll be funny to say the least. But I like this idea.
Antonio Prado •
Excellent thread: the fe80 and DHCPv6-PD exchanges cover the control-plane side thoroughly. Two operational points from the access/data-centre side that haven't come up yet. Both are about the shared-L2 segment the article leads with (Hetzner/OVH-style VLANs, enterprise access), not the routed-to-the-host fabric, where they don't apply because there is no east-west on the wire to begin with. East-west hairpinning. Once every host is a /32 with no on-link IPv4 subnet, two hosts on the same segment no longer have an on-link path to each other. A→B IPv4 now goes host → 192.0.0.11 → router → back out the same interface → B. On a shared broadcast domain that turns a one-L2-hop intra-segment flow into a router hairpin: roughly double the segment traffic for east-west IPv4, plus load on the first-hop router. For the IPv4-heavy east-west workloads that still live on legacy segments (clustering, storage, backup), that is a real cost the /32 model introduces quietly. Worth a line in deployment considerations, even if only to say "keep east-west-heavy IPv4 segments dual-stack for now." L2 integrity and first-hop redundancy. DHCP snooping, Dynamic ARP Inspection and IP Source Guard build bindings from DHCP state and validate against subnet-and-binding assumptions. A gateway deliberately off-subnet plus /32 leases sits outside the envelope these features were written for, so operators running them will need to validate behaviour and likely add explicit permits for the sentinel, mildly ironic for a mechanism whose headline is "no host changes," since on a DAI-enabled access network the no-change fallback path may need a switch-side change. Related: with redundant first-hops, the draft should say which MAC answers for 192.0.0.11 across a failover: a shared/virtual MAC, or you trade ARP churn for neighbour-cache churn. thanks
Remco van Mook •
Hi Antonio, Thanks very much for your insights. Some good points that will probably need some further clarification. East-west: yes, and deliberately so. The /32 model prices intra-segment IPv4 as a routed service, so a one-L2-hop lateral flow becomes a hairpin. On the segments the article leads with that cost rounds to zero, as you note, because the lateral traffic is already suppressed or absent. Where it doesn't round to zero, storage, clustering and backup on legacy segments, the segment should simply not opt in: keep it dual-stack, or move that east-west to IPv6 first and let the /32s follow. The mechanism is opt-in per segment precisely so this decision stays with the operator. A deployment-considerations line saying exactly that goes into the next revision. Or do opt in and choose to use IPv6 for your on-net east-west traffic; the link-local/ULA/GUA prefix is there without any of the restrictions. On the L2 integrity features: agreed, snooping, DAI and IP Source Guard were written against subnet-and-binding assumptions, and nobody should assume behaviour without validating. Two things soften it in practice. The switch-side change for the transition tier is one static, universal permit: the sentinel is the same well-known address on every segment on earth, so the ARP ACL entry is identical everywhere and known in advance, which is a different beast from the per-subnet gateway entries these features juggle today. And the direction of travel is that the apparatus becomes unnecessary for IPv4 as a segment finishes migrating: once the router is the only thing that ever legitimately answers ARP, inspection collapses to one port rule, and at the end of the ramp the operator switches the ARP tier off entirely. Nothing left to validate. On the failover MAC; for updated hosts there is nothing to elect: failover rides the neighbour cache and RA lifetimes exactly as native IPv6, which is convergence rather than churn. For unmodified hosts during the transition the operator either accepts ordinary re-ARP timing on failure or keeps conventional FHRP with its virtual MAC in front of the ARP tier. The adoption discussion moves to the int-area list and the GitHub repo after this week; operational review of this quality is highly welcome there. Remco