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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQ9kKf42lNRpaaDt@shredder>
Date: Sat, 8 Nov 2025 17:39:21 +0200
From: Ido Schimmel <idosch@...dia.com>
To: David 'equinox' Lamparter <equinox@...c24.net>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
	horms@...nel.org, dsahern@...nel.org, petrm@...dia.com,
	willemb@...gle.com, daniel@...earbox.net, fw@...len.de,
	ishaangandhi@...il.com, rbonica@...iper.net, tom@...bertland.com,
	Justin Iurman <justin.iurman@...ege.be>
Subject: Re: [PATCH net-next v2 0/3] icmp: Add RFC 5837 support

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.