Hi Nick, Host-side RFC 8950 is a fair one-line summary. On the dependency: the sentinel only gets deployed on segments where every IPv6-based service on the wire already depends on ND working. If ND is broken on such a segment, IPv4 first-hop resolution is the least of your problems. There is no new fate-sharing, and the failure mode is inert: no IPv6, no activation. Speaking of one protocol depending on another: 464XLAT has made IPv4 service completely dependent on correct IPv6 operation on a few billion handsets for over a decade, and I dare say it goes a fair bunch further than simply swapping out a L2 lookup. On "only a problem in specific cases": IPv6-mostly deployment is an active IETF work area. RFC 8925 shipped in Android, iOS and macOS; 6mops and claton are in v6ops right now; the IETF meeting network itself runs this way. This covers enterprise, campus and datacenter alike, not just large hosters. And half a million ARP requests per second across 10k hosts was my daily reality in a previous job; that's a step or two beyond nuisance in my book. On 1925(5): I'd argue the arrow points the other way. The draft is one narrow mechanism for one gap, composable with the existing pieces: 8950 for routing, 8925 for signalling, CLAT where translation fits; rather than replacing any of them. The agglutinated, complex, interdependent solution in this space already exists and we've been running it for 25 years: it's called dual-stack. If we're trading 1925 quotes, I'll raise you (12): perfection is reached not when there is nothing left to add, but when there is nothing left to take away. This takes away ARP, IPv4 subnets and FHRP and leaves an IPv4 address as nothing more than an endpoint identifier. Remco
On 13 Jul 2026, at 12:52, Nick Hilliard <nick@foobar.org> wrote:
Remco van Mook wrote on 13/07/2026 10:49:
the Labs article wasn't quite the place to address this in detail - the current draft has most of the mechanics you're looking for detailed in chapter 4 and 5. https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway...
so generalised RFC 8950 then, with caveats, interface behavioural changes and a dependency on IPv6 ND.
Separately, the draft is proposing a general solution to something which is only a problem in specific cases, for example large hosting providers; and arguably it's not even a problem, just a minor nuisance.
I'm all for fixing problems, but this particular one is a clear case of rfc1925, section 5:
(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
It's a terrible idea to make one protocol reliant on another protocol's correct operation.
Nick