[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANn89iK-YDrmLdJKANDkb6WVSZdiPOYf3e18Hzx6xBk8cAgeUA@mail.gmail.com>
Date: Mon, 27 Oct 2025 01:39:03 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: Ido Schimmel <idosch@...dia.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
pabeni@...hat.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
Subject: Re: [PATCH net-next v2 2/3] ipv6: icmp: Add RFC 5837 support
On Mon, Oct 27, 2025 at 1:24 AM Ido Schimmel <idosch@...dia.com> wrote:
>
> Add the ability to append the incoming IP interface information to
> ICMPv6 error messages in accordance with RFC 5837 and RFC 4884. This is
> required for more meaningful traceroute results in unnumbered networks.
>
> The feature is disabled by default and controlled via a new sysctl
> ("net.ipv6.icmp.errors_extension_mask") which accepts a bitmask of ICMP
> extensions to append to ICMP error messages. Currently, only a single
> value is supported, but the interface and the implementation should be
> able to support more extensions, if needed.
>
> Clone the skb and copy the relevant data portions before modifying the
> skb as the caller of icmp6_send() still owns the skb after the function
> returns. This should be fine since by default ICMP error messages are
> rate limited to 1000 per second and no more than 1 per second per
> specific host.
>
> Trim or pad the packet to 128 bytes before appending the ICMP extension
> structure in order to be compatible with legacy applications that assume
> that the ICMP extension structure always starts at this offset (the
> minimum length specified by RFC 4884).
>
> Since commit 20e1954fe238 ("ipv6: RFC 4884 partial support for SIT/GRE
> tunnels") it is possible for icmp6_send() to be called with an skb that
> already contains ICMP extensions. This can happen when we receive an
> ICMPv4 message with extensions from a tunnel and translate it to an
> ICMPv6 message towards an IPv6 host in the overlay network. I could not
> find an RFC that supports this behavior, but it makes sense to not
> overwrite the original extensions that were appended to the packet.
> Therefore, avoid appending extensions if the length field in the
> provided ICMPv6 header is already filled.
>
> Export netdev_copy_name() using EXPORT_IPV6_MOD_GPL() to make it
> available to IPv6 when it is built as a module.
>
> Reviewed-by: Petr Machata <petrm@...dia.com>
> Reviewed-by: David Ahern <dsahern@...nel.org>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
Same small remark about consume_skb().
Reviewed-by: Eric Dumazet <edumazet@...gle.com>
Powered by blists - more mailing lists