linux-kernel - Re: [PATCH] net/ipv6: allow device-only routes via the multipath API

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: <e5e7b1cd-b733-40d5-9e78-b27a1a352cec@kernel.org>
Date: Tue, 18 Nov 2025 09:04:38 -0700
From: David Ahern <dsahern@...nel.org>
To: azey <me@...y.net>, nicolasdichtel <nicolas.dichtel@...nd.com>
Cc: "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 netdev <netdev@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net/ipv6: allow device-only routes via the multipath API

On 11/18/25 4:00 AM, azey wrote:
> On 2025-11-18 10:05:55, +0100 Nicolas Dichtel wrote:
>> If I remember well, it was to avoid merging connected routes to ECMP routes.
>> For example, fe80:: but also if two interfaces have an address in the same
>> prefix. With the current code, the last route will always be used. With this
>> patch, packets will be distributed across the two interfaces, right?
>> If yes, it may cause regression on some setups.
> 
> Thanks! Yes, with this patch routes with the same destination and metric automatically
> become multipath. From my testing, for link-locals this shouldn't make a difference
> as the interface must always be specified with % anyway.
> 
> For non-LL addresses, this could indeed cause a regression in obscure setups. In my
> opinion though, I feel that it is very unlikely anyone who has two routes with the
> same prefix and metric (which AFAIK, isn't really a supported configuration without
> ECMP anyway) relies on this quirk. The most plausible setup relying on this I can
> think of would be a server with two interfaces on the same L2 segment, and a
> firewall somewhere that only allows the source address of one interface through.
> 
> IMO, setups like that are more of a misconfiguration than a "practical use case"
> that'd make this a real regression, but I'd completely understand if it'd be enough
> to block this.

There is really no reason to take a risk of a regression. If someone
wants ecmp with device only nexthops, then use the new nexthop infra to
do it.