Hi Nick, TL;DR - I think we don't disagree all that much. I fully agree with your analysis that IPv6 NDP/RA is a steaming pile (my summary, not your words, to be clear) - but it's fundamentally not MY steaming pile. If someone else would like to step up in the IETF to go in and clean that up, I think that will be gratefully received by a large number of people. Most of the reason why my I-D doesn't fit in 3 pages is exactly because of all the corner cases that IPv6 NDP already created. But we are where we are, and I don't think anyone on this list disagrees with the longer term goal of only having an IPv6-based network architecture and waving a fond goodbye to dual stack. Which leaves us with, pardon the pun, the leaves. Neither RFC8950 nor v4-via-v6 address how a host can participate in the migration to that single architecture while still keeping the option to have an IPv4 endpoint in the way routers would. Giving hosts that IPv4 endpoint is, correct me if I'm mistaken, the entire point of those efforts. Now, we can keep messing with per-segment IPv4 subnets and ARP, or we carve ourselves one opt-in where a host can bypass all of that. Because that's what this is, an opt-in sentinel that says 'you could do something wicked smart here' to the hosts that understand - and the ones that don't, ARP. Best Remco
On 13 Jul 2026, at 18:53, Nick Hilliard <nick@foobar.org> wrote:
Hi Remco,
tl;dr: the further down the protocol stack you go, the simpler you want things to be. Link layer forwarding is about as close to the bottom of the forwarding stack as you can get, so your proposal adds complexity in exactly the location where you desperately need things to be simple.
Remco van Mook wrote on 13/07/2026 12:08:
Host-side RFC 8950 is a fair one-line summary.
The phrase I used was "generalised RFC 8950, with caveats, interface behavioural changes and a dependency on IPv6 ND". Forgive my directness, but that is not the same as the benign-sounding "host side RFC 8950" :)
On the dependency: the sentinel only gets deployed on segments where every IPv6-based service on the wire already depends on ND working.
You mean "ND working and continuing to work". It isn't necessarily the case that activation implies continuously working ND, and if you make this assumption - which you have - you add fragility to your proposal.
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.
There are lots of reasons that ND can break, either on startup or during operation. E.g. everything from people blocking icmp6 on their host level firewalls to MAC filters on switches, to broken mcast forwarding on switches, to simply deconfiguring (temporarily or permanently) ipv6 for some reason which is unrelated to ipv4. These things will cause ipv6 failure, but will not impact ipv4. If you make your ipv4 connectivity contingent on ipv6, then you've unnecessarily shot your foot off.
Generalising, the set of failure modes for ipv6 is different than for ipv4, and much wider because the ipv6 protocol is more complex than ipv4 at that layer. By combining the failure modes of ipv4 and ipv6 link-layer packet forwarding, you're combining the fragility of both. This is, imo, unwise as a general principle.
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.
The ID is clear that this isn't just a matter of 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.
500kpps arp over 10k hosts is 50 arp requests per second per host and on the face of it, that sounds like a lot. Overlooking the fact that it would be the same for ND, it also sounds like a specialist situation which would require specialised network design. Without more details, it's impossible to give any assessment about the extent to which this proposal would fix anything here, not least because this sounds more like a problem which would be better handled by a different style of network design.
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.
Dual-stack is two separate protocols, not two interdependent protocols.
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.
We're not trading rfc1925 quotes, but I'm truly scratching my head at this one. Have you actually read the full specification for ND? Here's a summary of the RFCs:
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/NEEBC5FV...
ND is a ridiculously complex protocol.
Nick