Re: [PATCH net-next v2 0/3] icmp: Add RFC 5837 support

[Ido Schimmel <idosch@nvidia.com>]

On Fri, Nov 07, 2025 at 06:20:57PM +0100, David 'equinox' Lamparter wrote:
> The IETF is in fact doing draft-ietf-intarea-extended-icmp-nodeid, which
> is past last call.  The good news is that it's extremely similar,
> different class value but same C-Type bitmask, the main distinction is
> that 5837 had forbidden the use of "cross-address-family" addresses.

I mentioned the node ID extension in both the cover letter and in my
reply to Willem:

https://lore.kernel.org/netdev/20251027082232.232571-1-idosch@nvidia.com/
https://lore.kernel.org/netdev/aPnw2PkF3ZMP9EJr@shredder/

> Note that for unnumbered networks, 5837 is wrong - it's
> interface/nexthop information.  But the interface has no address, the
> node does.  draft-ietf-intarea-extended-icmp-nodeid is about node
> information and the correct thing to use for that case.

RFC 5837 and draft-ietf-intarea-extended-icmp-nodeid solve different
problems.

The motivating use case for this work is a deployment where router /
infrastructure interfaces are only assigned IPv6 link-local addresses
and the loopback devices are assigned global IPv4 and IPv6 addresses. As
such, each node will generate ICMPv4 error messages with a source IP
that uniquely identifies the node.

draft-ietf-intarea-extended-icmp-nodeid is needed in cases where nodes
completely lack IPv4 addresses. In these cases all the nodes will
generate ICMPv4 error messages with the same source IP of 192.0.0.8
("IPv4 dummy address").

While this patchset does not add support for the node ID extension (as I
don't currently have a use case for it), the implementation does not
preclude it. After it is implemented, an administrator can then choose
to include both the incoming interface information and the node
identification in ICMP error messages.