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

[Kevin Tillery <[e-mail]>]

Hi Remco,

The v4-over-v6 mechanism is draft-ietf-intarea-v4-via-v6 which is 
hopefully soon about to become an RFC. Perhaps you were unaware of it (I 
became aware of it just now as I joined the mailing list).
Your draft doesn't need to go over it again, except briefly in the 
introduction if you want. The details of ARP and NDP and lladdr caches 
and so on are already all worked out.

What's new in your draft is the sentinel value for the router address 
that causes a host to turn the feature on. I think you should succinctly 
explain just the new part, instead of repeating how v4-via-v6 works.


I also think your draft should describe the behaviour as if it's being 
implemented in a host's DHCP client software, which would be the 
simplest place to add this feature. The draft should get the point 
across in the simplest way possible.
If some operating systems choose to implement this feature by adding a 
pile of hacks to their kernel routing subsystem, just to avoid having to 
update the DHCP client software, they're allowed to do that, because the 
IETF isn't the implementation police, but I think it's a bad design. 
It's also a bad way to explain the feature because it's much more 
complicated than necessary.


The backwards compatibility described in section 5.3 is a good idea. But 
it makes me wonder how all the stuff described in this draft is really 
different from just... assigning 192.0.0.11 to the router's interface?
Well, in your proposal the host selects the router from all known IPv6 
routers, not just the one that advertised 192.0.0.11, but is that really 
a good idea? What if some of them can't route IPv4 packets?


What's the overall point of the proposal? It doesn't make hosts or 
routers simpler.
They both still have to support ARP because they don't know if their 
counterpart supports this new standard, and they both still have to 
process IPv4 packets.


How does an unmodified host behave if it gets a DHCP router address 
outside of its own subnet? This is what would happen in the backwards 
compatibility mode of your proposal.
Would the client assume the router is on-link, or would it get confused 
and fail to send anything? I didn't notice anything about this in the 
DHCP standard.


Regards, Kevin


On 08/05/2026 10:32, Remco van Mook wrote:
> 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]