[Int-area] Re: Call for adoption: draft-vanmook-intarea-ipv6-resolved-gateway-01 (Ends 2026-08-21)

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

Hi Herbie,

In all honesty I think in a lot of cases it will probably be the access
switch acting as the getaway to begin with - in which case you lose nothing
in terms of performance. But network domains with a lot of lateral traffic
probably aren't the ideal scenario for this - using ipv6 for lateral
traffic of course doesn't have that complication.

Remco

On Sat, 1 Aug 2026, 10:58 Robinson, Herbie, <
[e-mail]> wrote:

> You will note that I threw the MAC address in the redirect proposal.  The
> IPv6 Resolved Gateway is intended to replace ARP with ND to avoid using
> ARP.  But ARP would allow direct communication with other peers on the same
> subnet without the need to get routed through the gateway.  That’s what I
> was going for.
>
>
>
> OTOH, I guess it depends on how efficient the gateway is.  It could be
> just as fast as a switch if enough hardware is thrown at it.
>
>
>
> *From:* Remco van Mook <[e-mail]>
> *Sent:* Saturday, August 1, 2026 4:50 AM
> *To:* Robinson, Herbie <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Int-area] Re: Call for adoption:
> draft-vanmook-intarea-ipv6-resolved-gateway-01 (Ends 2026-08-21)
>
>
>
> Hi Herbie,
>
>
>
> Thanks for the support, and for what is clearly a close
> implementation-level read. Taking your points in turn.
>
>
>
> DHCPv4 client configuration: correct, and taken as an editorial fix.
>
>
>
> On multi-homing: your walkthrough arrives at exactly the intended
> semantics, which tells me the text explains them badly. The sentinel is an
> interface-scoped next-hop token: a route of the form 192.168.2.0/24 via
> 192.0.0.11 dev iface2 resolves against iface2's own IPv6 default router,
> which is precisely what the cross-interface MUST NOT exists to make
> well-defined. And both sides of DHCPv4 can already express all of this,
> unchanged: the server hands out a per-interface default (Option 3) and
> per-interface classless routes (Option 121) with the sentinel as next-hop,
> and clients accept them as-is. The reference implementations at
> https://github.com/remcovanmook/v4-with-v6-nh demonstrate both halves
> working: the dnsmasq-based testbed router on the server side, the host
> realisations on the client side. Source selection follows the egress
> interface as it does today. So nothing new is needed, but the exposition
> clearly is; your algorithm derivation is useful raw material for that, and
> better multi-homing text is noted for the WG revision.
>
>
>
> On PMTUD: I see the appeal, but I want the sentinel to mean exactly one
> thing, the resolution path, and nothing else. Coupling MTU guarantees to it
> would overload the signal, and the first hop cannot vouch for ICMP
> behaviour on a path it does not own; nor can a spec require hardware to
> report arbitrarily oversized frames. MTU and fragmentation behaviour stay
> deliberately untouched by this mechanism.
>
>
>
> On redirects: your analysis is right that classic redirects cannot express
> destination, interface and sentinel together, but I draw the opposite
> conclusion. Redirects are operationally moribund, widely disabled and
> unauthenticated, and this model does not need them: multi-router steering
> lives in Router Advertisement preferences (RFC 4191), on the side that owns
> router selection. A new authenticated redirect would be a different
> document, and I suspect a different decade. The existing redirect mention
> in section 5 will get scoped accordingly.
>
>
>
> Remco
>
>
>
> On Sat, 1 Aug 2026, 07:03 Robinson, Herbie, <
> [e-mail]> wrote:
>
> I think this is a great idea.
>
>
>
> A suggestion: how about requiring routers and hosts that support this to
> send “packet too big” ICMP and ICMPv6 messages no matter how large the
> received datagram is (it is possible to configure receiving hardware to
> report overflowed packets to the driver along with the first part of the
> packet, annoying to implement, but possible).  This would imply that hosts
> would know it’s safe to use path MTU discover when an IP6-Resolved Gateway
> is in use.  This would give end users a huge performance boost and
> encourage adoption of the protocol.
>
>
>
> In the next to the last paragraph, it says “The mechanism has been
> verified to work without changes to applications or DHCPv4 configuration
> on …”.  “DHCPv4 configuration” should be “DHCPv4 client configuration”,
> right?
>
>
>
> I have a minorish kink for you to resolve:
>
>
>
> Bullet 2 in section 4 says:  “…, scoped to the interface on
> which 192.0.0.11 is configured as the IPv4 default gateway. “; however, 3
> paragraphs later is:
>
>
>
> “Cross-interface resolution *MUST NOT* be performed. On multi-homed
> hosts, each interface independently resolves 192.0.0.11 against its own
> IPv6 neighbor cache state.”
>
>
>
> I’m not real clear what that paragraph is intending to convey.
>
>
>
> And now that I am thinking about it more, what about multi-homing…
>
>
>
> What if one has a multi-homed system with 3 interfaces.  All three subnets
> are completely disjoint (no common route between them).  The subnets are
> 192.16.8.1.0/24, 192.16.8.2.0/24 and  192.16.8.3.0/24.   Before conversion
> to IPv6 routing, the host configuration is Interface 1 and 2 are IPv4/IPv6
> and interface 3 is IPv4.  Interface 1 is 192.168.1.1/24 and interface 2
> is 192.168.2.1/24 and  Interface 3 is 192.168.3.1/24.  After conversion,
> interface 1 and 2 are ND and interface 3 is IPv4.  Interface 1 is now
> 192.168.1.1/32 and interface 2 is 192.168.2.1/32.  Interface 3 is still
> 192.168.3.1/24.  Interface 1 is also assigned 192.0.0.11 and the default
> route is set to 192.0.0.11.  That will send all IPv4 traffic over interface
> 1 using ND.  But how do I add routes to send IPv4 traffic over interface 2
> (using ND, of course)?
>
>
>
> The other thing I’m not getting here is that the source address is often
> defaulted based on the destination.  So, before conversion in the above
> example, If my destination is 192.168.2.25, the OS will look up the route
> to interface 192.168.2.1/24 and get 192.168.2.1 for the source address.
> If we convert interfaces 1 and 2 to use ND the lookup will no longer
> match.  I guess this boils down to the same issue.  How do I select the
> second interface?
>
>
>
> So, I’m trying to think how to implement this.  I’m starting with an OS
> that adds to entries to the routing table when you define an interface:  A
> /32 that gets routed to the loopback interface and a /N that routes to the
> real interface with no next hop.  I’m not sure what happens when N==32 (it
> should just add the loopback).
>
>
>
> First, single homed:  Initialize the interface with a new option that adds
> the send route to use a next hop of 192.0.0.11 and point to the interface.
>   So, the difference here is specifying the special next hop and the
> interface when we add the send route.
>
>
>
> For the default route, we add a route with 0.0.0.0/0 source address, a
> next hop of 192.0.0.11 and point to the interface.  So, again, the
> difference is specifying a next hop and an interface for the route.  With a
> default route applied, the send route for the interface becomes redundant,
> but will likely be kept, to keep the algorithm simple.
>
>
>
> When the IP layer gets 192.0.0.11 as the next hop from the routing table,
> it uses ND instead of ARP (as described in the RFC).
>
>
>
> That algorithm for initializing an interface works for multi-homing, too.
>
>
>
> With multi-homing, one would add more routes that specified the subnet
> with both interface and a next hop of 192.0.0.11.
>
>
>
> So, I now see how this will work with multi-homing while degrading to the
> single interface case.  It needs to be explained better.  Preferably
> without getting as close to the implementation details as I did.  Maybe you
> can grab what I wrote and abstract it a little.  However, the
> “cross-interface” resolution sentence makes perfect sense, now.  The
> thought of having to implement anything else is truly scary.
>
>
>
> One multi-home issue that comes it mind is the ICMP redirect message.
> This has the same problem as manually configured routes:  It needs to
> specify a destination, the interface to use and the next hop of
> 192.0.0.11.  The ICMP message can redirect packets for a single destination
> or a network where the definition of network is sketchy (this was defined
> when the IP address determined the subnet mask).  There are 6 bits
> available and one could use 5 of them for the subnet mask width and use the
> remaining bit to indicate that the real next hop is 192.0.0.11 (the next
> hop in the ICMP message would be used to select the interface for the
> route).  Reasons for not doing that:
>
>
>
> ·         I sort of suspect that people will not want to use up those
> bits.
>
> ·         The definition of network is loose:  The host and the router
> may not be using the same subnet mask.
>
> ·         The original spec, RFC-792, doesn’t say what to do if those
> bits are non-zero.  [Drop the packet, one would hope.]
>
> ·         It’s insecure.
>
>
>
> So, maybe a new ICMP redirect would be in order.  The contents would be:
>
>    - Destination specification (address, mask length, port range?)
>    - Interface selector (an address)
>    - Next Hop (or an option bit that says to use 192.0.0.1 instead of the
>    address used to select the interface).
>    - MAC Address
>    - TTL
>    - Large sequence number for security.  Hashed with the contents of the
>    message and optionally a shared secret.
>
>
>
> *From:* Remco van Mook <[e-mail]>
> *Sent:* Friday, July 31, 2026 4:26 PM
> *To:* [e-mail]
> *Cc:* [e-mail];
> [e-mail]
> *Subject:* [Int-area] Re: Call for adoption:
> draft-vanmook-intarea-ipv6-resolved-gateway-01 (Ends 2026-08-21)
>
>
>
> *Penguin Solutions Security Checkpoint:** External email. Please make
> sure you trust this source before clicking links or opening attachments.*
>
> Support.
>
>
>
> As the author, I support adoption and am willing to continue editing the
> document under WG ownership. Tobias Fiebig, co-author of route4via6, which
> was withdrawn in favour of this work, has agreed to join as co-author for
> the WG revision.
>
> For transparency, the known work items for the first WG revision, most of
> them direct results of list and operator review over the past weeks:
>
>    - Correction in Section 7: the -01 text derives the off-link
>    properties from Source=False; the correct basis is the Section 5.2
>    forwarding prohibition (the IANA table was always right). Flagged at the
>    Vienna session.
>    - Per AD guidance received at IETF 126: the next revision replaces the
>    concrete address in normative text with a TBD placeholder (suggested value
>    moving to the IANA Considerations, documentation addresses in examples),
>    with an RFC 7120 early-allocation request to follow adoption so that
>    running code and the registry stay aligned.
>    - From the session and subsequent design discussion: the next revision
>    adds a single normative durability requirement for the router-to-host
>    binding (delivery to each /32 must not depend on opportunistic cache
>    state), and I'm looking into a companion informational draft that will
>    catalogue acceptable router-to-host configurations, several of which are
>    already implemented in the reference repository and suggested during the
>    session.
>    - Deployment Considerations additions from operator review: ND
>    operational-health prerequisites, multi-router and failover guidance from
>    recent interop testing across five host implementations, a DHCPv4 relay
>    note, and sharper scoping of the CLAT relationship.
>
> Remco
>
>
>
> On 31 Jul 2026, at 15:59, Carlos Jesús Bernardos via Datatracker <
> [e-mail]> wrote:
>
>
>
> This message starts a intarea WG Call for Adoption of:
> draft-vanmook-intarea-ipv6-resolved-gateway-01
>
> This Working Group Call for Adoption ends on 2026-08-21
>
> Abstract:
>   This document specifies host behavior enabling IPv4 communication for
>   dual-stack hosts on IPv6-only segments, without subnets, ARP,
>   tunneling, or translation.  Hosts that receive 192.0.0.11/32 as their
>   IPv4 default gateway address resolve the next-hop link-layer address
>   from the IPv6 neighbor cache rather than via ARP.  IPv4 packets are
>   forwarded natively, end-to-end.  The mechanism is incrementally
>   deployable alongside unmodified hosts with no changes to DHCPv4
>   infrastructure.  This document requests the allocation of
>   192.0.0.11/32 in the IANA IPv4 Special-Purpose Address Registry to
>   support this mechanism.
>
> Please reply to this message and indicate whether or not you support
> adoption
> of this Internet-Draft by the intarea WG. Comments to explain your
> preference
> are greatly appreciated. Please reply to all recipients of this message and
> include this message in your response.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
> Appropriate IPR disclosures required for full conformance with the
> provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
>
> https://datatracker.ietf.org/doc/draft-vanmook-intarea-ipv6-resolved-gateway/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-vanmook-intarea-ipv6-resolved-gateway-01.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-vanmook-intarea-ipv6-resolved-gateway-01
>
> _______________________________________________
> Int-area mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>
>