Remco van Mook

“Thanks for this follow-up. I asked under the previous article which MAC answers for the sentinel across a failover, and this article answers it: none, because nothing is ever elected. Fair enough, the question simply goes away. The two-IPv4s framing also works much better than the fe80 analogy did, and the VPN /32 example is the right one, every OS already does subnet-less IPv4 on tunnel interfaces every day. Two things I would still want to see addressed before this goes much further. First, the failover story is only complete for the planned case. The RA with lifetime zero works when you decommission a router on purpose. When the first hop dies silently (PSU, linecard, kernel panic) nobody says goodbye. RFC 4861 has NUD for exactly this: unreachability of the next-hop in use should trigger selection of another router, well before the lifetime expires. So the Windows 11 observation is actually the interesting part. If the dead router stayed in the list until lifetime expiry, either NUD did not kick in on that stack, or the test had no active flows through it at that moment. I'd really like to know which, and more generally to see measured reconvergence times for silent failure next to VRRP with aggressive timers. "FHRP vanishes" is a strong claim and that number is what backs it or not. Second, migration on policed segments. The end state (only the router ever answers ARP) is clean, agreed. But during coexistence, on access networks running DHCP snooping, DAI and IP source guard, you have a router answering ARP for an address that appears in no binding table. That is precisely the pattern those features were built to catch. Anyone running them will have to touch switch config to let the fallback path work, which slightly undercuts "no changes needed" for the transition period. Not a blocker at all, but worth a paragraph in deployment considerations before someone finds out in production. Neither of these makes me less interested in the mechanism. Good luck with the adoption discussion.”

Hi Antonio, Glad the anycast framing dissolved the MAC question. On silent failure: your option (b). NUD is traffic-driven; the test path was idle, so the entry aged out on lifetime exactly as 4861 says it should. With active flows it's DELAY, PROBE, FAILED, next router: single-digit seconds, VRRP-default class. Sub-second stays engineered territory, with BFD, same as it does for VRRP. Measuring this properly in the lab, per stack, next to VRRP is a fair ask. On policed segments: DAI validates replies from untrusted ports, and the first-hop router already sits on a trusted port in any correct deployment, so the sentinel's reply passes unchanged today. Host ARP requests validate against the sender's own binding, which the /32 lease provides. The rest, routers on untrusted ports and vendor variance on target inspection, is validate-per-platform territory: one static permit where needed, and the apparatus retires with the ARP tier. The adoption discussion runs on int-area@ietf.org shortly; a voice like yours counts there. Remco

“Thanks for proposing this! The /32 approach is a good one. If we're backporting, I would have preferred to use IPv4 link-locals as next-hops. Instead of the magic sentinel. I think you are overselling IPv6 ND over ARP. ND makes the same assumptions that ARP does, that everything is trusted and broadcast(-ish). Just at an even higher expense in terms of chattiness. It also requires VRRP for fast fail-overs. I have heard discussions of running IPv6 ND-less, to avoid having to deal with all the ND issues. Implementing IPv6 ARP support is after all trivial. :-) I have thought about implementing IPv6 support in ARP for some use cases. Allowing IPv6 to operate without the ND protocol stack.”

Hi Ole, On link-locals: that forks into two designs. Resolved classically, ARP stays forever; Calico has run 169.254.1.1 that way for a decade, per-vendor and interoperable with nothing, which is the status quo I'm trying to standardise away. Resolved as a token via the neighbour cache, it's the same mechanism with a collision-prone space: hosts self-assign from 169.254/16, and per-router link-locals put gateway election straight back. One well-known value buys universality and nothing to elect. On ND: no defence offered. It isn't perfect, it's what IPv6 comes with, and if we keep IPv6 we're stuck with it regardless of what this draft does. The goal is the upgrade path away from IPv4 subnets and ARP, not a verdict on ND. Failover numbers next to VRRP are queued in the lab rather than argued about. And if you ever ship IPv6-over-ARP: section 4 consults whatever resolution state the segment's IPv6 keeps, and doesn't care how it got there. The sentinel would ride it unchanged. :-) Remco

“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”

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

“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.”

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

“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.”

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