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

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

Hi Kevin,

On focusing the draft on just the new part: that's fair feedback and something I'm already planning to address in -01. The Introduction needs to be sharper about what's new versus what's inherited from RFC 8950 and v4-via-v6.

On the DHCP client implementation suggestion: this change doesn't belong in the DHCP stack at all. The purpose of DHCPv4 - client _and_ server - is to hand configuration details such as the gateway address to the host networking stack, unchanged. You're right that the DHCP client does add a host route to an off-link gateway to the configuration set it passes to the networking stack; and that behaviour is exactly what hosting providers like Hetzner, OVH, and Scaleway have been relying on to deploy /32 host addresses with off-link gateways to millions of servers for years. The authors of RFC 2132 almost certainly never contemplated this use case, but it doesn't prohibit it either: which is precisely why it has been widely deployed without anyone feeling the need to write an RFC about it until now. All this draft requires is an incremental change to the host networking stack to recognise the 192.0.0.11 sentinel for what it is.

On updated hosts still needing ARP: they don't, which is the point of the two-tier model. Updated hosts resolve 192.0.0.11 via the IPv6 neighbor cache and never send an ARP request. Unmodified hosts ARP and get a response from the router. Both work simultaneously on the same segment, and it is then up to the operator to decide at which point to switch off ARP entirely.

Remco


> On 9 May 2026, at 08:54, Kevin Tillery <[e-mail]> wrote:
> 
> 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]