New on RIPE Labs: A Farewell to ARPs - IPv4 Service on IPv6-Only Networks
Dear colleagues, This new article from Remco van Mook explores an IETF proposal that would allow IPv4 to operate over IPv6-only infrastructure without ARP, IPv4 subnets, tunnelling or translation: https://labs.ripe.net/author/remco-van-mook/a-farewell-to-arps-ipv4-service-... Comments and feedback are very welcome as always! Kind regards, Alun Davies RIPE Labs Editor RIPE NCC
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.
How is that handled if multiple IPv6 default routes exist? For me it looks like all of them must be capable of forwarding the IPv4 package. How is that handled if they also should support legacy ARP for this address? HSRP etc.? -- kind regards Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Hi Marco, 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... Kind regards, Remco
On 13 Jul 2026, at 11:45, Marco Moock <mm@dorfdsl.de> wrote:
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.
How is that handled if multiple IPv6 default routes exist?
For me it looks like all of them must be capable of forwarding the IPv4 package. How is that handled if they also should support legacy ARP for this address? HSRP etc.?
-- kind regards Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Am 13.07.26 um 11:49 schrieb Remco van Mook:
https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway... Thanks for the pointer.
This mechanism applies granularly at the segment level. A network may contain a mix of IPv4-only, dual-stack, and IPv6-only segments; this mechanism is applicable specifically to IPv6-only segments carrying dual-stack hosts and does not affect other segment types.
What does segment mean in this context? Same as Ethernet link? -- kind regards Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
Hi Marco, yes - same segment = same L2 domain, so typically same ethernet link.
On 13 Jul 2026, at 12:04, Marco Moock <mm@dorfdsl.de> wrote:
Am 13.07.26 um 11:49 schrieb Remco van Mook:
https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway... Thanks for the pointer.
This mechanism applies granularly at the segment level. A network may contain a mix of IPv4-only, dual-stack, and IPv6-only segments; this mechanism is applicable specifically to IPv6-only segments carrying dual-stack hosts and does not affect other segment types.
What does segment mean in this context? Same as Ethernet link?
-- kind regards Marco
Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ipv6-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Am 13.07.26 um 12:24 schrieb Remco van Mook:
yes - same segment = same L2 domain, so typically same ethernet link. Is the term "segment" defined at any place?
IIRC the RFCs for IPv6 use the term link. -- kind regards Marco Junk-Mail bitte an trashcan@stinkedores.dorfdsl.de
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
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
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
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
Remco van Mook wrote on 13/07/2026 20:17:
Because that's what this is, an opt-in sentinel that says 'you could do something wicked smart here' to the hosts that understand
So, "hold my beer" ipv4 connectivity then. Nick
participants (4)
-
Alun Davies -
Marco Moock -
Nick Hilliard -
Remco van Mook