Summary

  • Remco van Mook's active INTAREA working-group draft proposes 192.0.0.11/32 as a sentinel IPv4 default gateway: an updated host must not ARP for it, but uses the link-layer address of a selected IPv6 default router.
  • The packet remains native IPv4. There is no tunnel or translation, yet the return path is a separate obligation: the host's IPv4 /32 must be reachable through a routable IPv6 next hop.
  • The simplification joins two control planes. DHCP configuration, Router Advertisement selection, neighbour reachability, IPv4 forwarding, return routing and legacy ARP fallback are different receipts and can fail independently.

The address that is an instruction

The neatest part of the proposal is also the easiest to misread. 192.0.0.11 looks like the address of a router. Under the draft, it is not. It is a sentinel placed in an IPv4 routing table to say: for this route, obtain the Ethernet destination from IPv6.

The host still owns an IPv4 address. Applications still open IPv4 sockets. Routers still forward ordinary IPv4 packets. What disappears from the updated host is the usual question, “Who has my IPv4 gateway?” It does not broadcast ARP for 192.0.0.11. Instead, it looks at the IPv6 default-router list on the same interface, chooses a router, and uses the corresponding link-layer address from the IPv6 neighbour cache.

That distinction matters. This is not NAT64, because no address family is translated. It is not a tunnel, because the IPv4 packet is not wrapped in IPv6. It is not an IPv4 subnet stretched across an IPv6 link. The design changes only the resolution of the first link-layer hop.

Van Mook's draft reached the INTAREA working-group track in August 2026. It reports that the behaviour has been verified without application or DHCPv4 changes on Windows 11, macOS, Android, iOS, Linux, FreeBSD and ChromeOS. Those are the author's cross-platform findings, not an independent certification programme. The document remains an Internet-Draft and may change; 192.0.0.11 should not be described as an already assigned, universal gateway.

One packet, several receipts

A DHCP lease containing the sentinel proves only that configuration arrived. It does not prove that an IPv6 Router Advertisement has arrived, that the selected router is reachable, or that the device behind its MAC address will forward IPv4.

The draft therefore relies on a working IPv6 first-hop control plane. Before the first Router Advertisement, there is no legitimate IPv6 default router from which to borrow a neighbour. An implementation must bound any queuing rather than leave packets waiting indefinitely. Once routers are known, selection follows the preference mechanism in RFC 4191, then reachability, with implementation-defined choice among otherwise equal candidates. If the selected router changes, the IPv4 route must be reevaluated. Existing sessions may not survive the change.

The neighbour-cache entry is another receipt. RFC 4861's reachable, stale, delay and probe states are not identical, but each can represent a usable neighbour while detection proceeds. A MAC address that remains cached after the router has stopped forwarding IPv4 is weaker evidence. Conversely, a forwarding router can be unusable if RA or Neighbor Discovery state has expired. The design's simplicity is not one Boolean; it is a composition of states.

The outgoing and returning directions are also asymmetric. For the host's first hop, an IPv6 link-local router address can be enough. Beyond that link, a link-local next hop cannot identify a route across the network. The operator must advertise a host-specific IPv4 /32 back toward the access segment with a routable IPv6 GUA or ULA next hop. RFC 8950 standardises carrying IPv4 reachability with an IPv6 next hop in BGP, and the complementary v4-via-v6 work develops the router-to-router part of the model.

So a successful ping sent outward is not the whole test. The access node needs proof that the lease was accepted, the RA selected the intended router, the neighbour entry points to the intended MAC, the router forwards native IPv4, and the rest of the network has the correct /32 return route. Each item can be green while another is missing.

Why /32 is part of the mechanism

The host address should be configured with a /32 mask. A broader IPv4 prefix would tell the host that other addresses are on-link. It could then ARP for those destinations, recreating the very adjacency the proposal is designed to remove. The special address must not be redistributed as a real route, used as a source or destination in forwarded packets, or tested as if it were a living router interface. It is a local instruction with deliberately narrow scope.

The draft connects this idea to a practice already familiar in hosting networks: customers receive individual IPv4 addresses and use an off-link gateway. It cites Hetzner, OVH and Scaleway as production examples that currently require operating-system-specific workarounds. That history supports the demand for a common behaviour, but it does not prove that the sentinel design itself has run at those providers. The attribution must stay with the draft.

RFC 8925 supplies another useful context. A network can tell capable clients to prefer IPv6-only operation. The sentinel offers a different bargain for dual-stack hosts that still need native IPv4: keep the IPv4 service, but remove IPv4 subnetting and ordinary ARP from the access segment. The two mechanisms can meet in an IPv6-mostly design, but neither is a substitute for testing the other.

Compatibility is a second path, not magic

An old host will not understand the sentinel. It will treat 192.0.0.11 as an ordinary gateway and send ARP. The draft says a router should answer that request with its own MAC. That permits updated zero-ARP hosts and legacy ARP hosts to coexist.

This is operationally helpful and diagnostically dangerous. Seeing the old host work proves that the compatibility responder works. It does not prove that an updated host selected the correct IPv6 router. Seeing an updated host work proves that the borrowed neighbour path works for that stack. It does not prove that the legacy tier is available. The two populations need separate counters and test clients.

At IETF 126, the discussion exposed this boundary. Lorenzo Colitti asked whether the host must follow IPv6 routing changes and warned that an incorrect implementation could break IPv4. Van Mook answered yes: the dependency is intentional. Tobias Fiebig described the approach as elegant compared with carrying DHCPv4 inside DHCPv6. Elegance here means fewer moving parts on the wire, not fewer states to observe.

The implementation is evidence with edges

The public v4-with-v6-nh repository makes the proposal more than paper. Its Linux user-space daemon notices the sentinel, chooses an IPv6 router using RFC 4191 information, installs an IPv4 default route via an IPv6 next hop, follows router changes and withdraws the route when the prerequisite disappears. Linux has supported IPv4 routes with IPv6 next hops since kernel 5.2.

The repository is equally valuable for what it does not claim. It says the daemon cannot queue individual packets while waiting for the first RA, so its startup behaviour is an approximation. A systemd-networkd change is a patch rather than an ordinary release. FreeBSD syntax was validated but not tested, commercial configurations were not verified on hardware, and the repository has no tagged release. A demonstration can validate the control-plane idea without establishing production maturity.

The draft repository and conformance material should therefore be read as the beginning of a test contract. The decisive cases are not only steady-state success. They include DHCP expiry, first-RA delay, preferred-router withdrawal, stale neighbour state, equal-preference routers choosing differently, loss of the /32 return route, and a mixed segment containing both updated and unmodified hosts.

The security boundary moves

Removing ARP removes an old source of spoofing and operational clutter from updated hosts. It does not remove first-hop trust. IPv4 availability now depends on IPv6 Router Advertisements and Neighbor Discovery. A malicious or mistaken RA can influence which router supplies the MAC used for IPv4; a broken ND path can interrupt two protocol families at once.

That makes RA Guard, trusted attachment points, neighbour-state inspection and controlled router preference part of the IPv4 security posture. A network with two routers of equal preference also needs to decide whether inconsistent host choice is acceptable. Explicit preferences may be safer than assuming that every stack will make the same tie-break.

The proposal's most serious failure is quiet. If a DHCP service offers the sentinel on a segment where neither the host nor the router supports the intended behaviour, IPv4 can simply stop. Some DHCP implementations may reject an off-link gateway during validation before that point. Both failures are useful: they show that configuration acceptance and forwarding readiness must not be collapsed into a single rollout flag.

Sources