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 <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
