[Int-area] Re: Comments on draft-vanmook-intarea-ipv6-resolved-gateway

[Remco van Mook <[e-mail]>]

Hi Kevin,

Thanks for the feedback; you've actually identified both the problem and the solution in your message, which suggests the draft needs to be clearer about the distinction it's drawing.

The mechanism you describe, using an IPv6 address as the next-hop for an IPv4 default route, is precisely what this draft standardises for the host side. The issue is not whether it can be done manually on Linux today; it clearly can. The issue is that without a standard, every operator implements it differently, no DHCPv4 server can signal it automatically, and no host OS does it by default. Hosting providers like Hetzner, OVH, and Scaleway all solve this problem in production today using different per-OS workarounds that are undocumented in any RFC and not interoperable across providers.

On your suggested alternatives: a new DHCP option or implicit behaviour when no router is specified both require DHCPv4 client changes across every OS implementation. Given typical deployment timescales for changes to that layer of the stack, we would be looking at a decade before meaningful coverage -- if it ever reached full deployment at all. The sentinel address approach requires no changes to DHCPv4 clients or servers. Any existing DHCPv4 infrastructure can advertise 192.0.0.11 as the router option today. The change is solely in how host stacks interpret one well-known address: a far smaller, and more importantly incremental implementation surface.

Happy to discuss further.

Remco

> On 7 May 2026, at 06:15, Kevin Tillery <[e-mail]> wrote:
> 
> Hi,
> It's not clear to me what problem is meant to be solved by draft-vanmook-intarea-ipv6-resolved-gateway.
> IPv4 routes with IPv6 next hop are supported on at least some equipment, and do not require a special address allocation, or any other standards action.
> You can simply place an IPv6 address in the next-hop field of a route and it already works. For example on Linux: ip route add 0.0.0.0/0 via 2001:db8:1::1
> 
> This is fairly trivial because IP forwarding doesn't actually use the next-hop IP address. It only gets used to look up the egress interface and the layer-2 address (very often an Ethernet MAC address) of the next hop. Those are the parameters that are actually needed when forwarding. It's trivial to use the lookup result from one IP version to forward packets from the other IP version. It's only a matter of whether the software supports it. No silicon changes are needed since this is generally not done by ASICs AFAIK.
> 
> The draft mentions a desire to completely eliminate IPv4 subnetting and ARP in the local segment - this can already be done with the existing mechanism.
> 
> I'm not sure if this behaviour is standard. If not, it might be useful to publish an RFC describing it anyway. But there would be no need for any number allocations.
> 
> The only real use I can see for the address allocation in the draft is to automatically configure DHCP clients to use their IPv6 default gateway for IPv4 packets. Are we sure that a special sentinel address is the right way to signal this? It could be a new DHCP option (although unused codes appear to be scarce), or a behaviour of dual-stack DHCP clients whenever DHCP doesn't specify an IPv4 router but there is an IPv6 router.
> 
> Kevin
> 
> 
> _______________________________________________
> Int-area mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]