Hi,
The purpose of DHCP is not for a DHCP client process to hand
configuration details to a host networking stack.
The purpose of DHCP is for a host to configure itself. The
implementation details you mention are irrelevant.
I just checked my Hetzner cloud server and it does have an off-link
gateway address. So that's good to know - that will work fine.
Updated hosts still need ARP because they have to work with unmodified
routers. So I don't really see the benefit of switching off ARP. It's
not a complicated protocol.
On 09/05/2026 20:07, Remco van Mook wrote:
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 <[email protected]> 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 <[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]
