linux-kernel - Re: [PATCH v3] ipv6: add `force_forwarding` sysctl to enable per-interface forwarding

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: <20250702073458.3294b431@kernel.org>
Date: Wed, 2 Jul 2025 07:34:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Gabriel Goller <g.goller@...xmox.com>, Nicolas Dichtel
 <nicolas.dichtel@...nd.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Simon Horman
 <horms@...nel.org>, Jonathan Corbet <corbet@....net>, David Ahern
 <dsahern@...nel.org>, netdev@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ipv6: add `force_forwarding` sysctl to enable
 per-interface forwarding

On Wed,  2 Jul 2025 09:46:18 +0200 Gabriel Goller wrote:
> It is currently impossible to enable ipv6 forwarding on a per-interface
> basis like in ipv4. To enable forwarding on an ipv6 interface we need to
> enable it on all interfaces and disable it on the other interfaces using
> a netfilter rule. This is especially cumbersome if you have lots of
> interface and only want to enable forwarding on a few. According to the
> sysctl docs [0] the `net.ipv6.conf.all.forwarding` enables forwarding
> for all interfaces, while the interface-specific
> `net.ipv6.conf.<interface>.forwarding` configures the interface
> Host/Router configuration.
> 
> Introduce a new sysctl flag `force_forwarding`, which can be set on every
> interface. The ip6_forwarding function will then check if the global
> forwarding flag OR the force_forwarding flag is active and forward the
> packet.

Should we invert the polarity? It appears that the condition below only
let's this setting _disable_ forwarding. IMO calling it "force" suggests
to the user that it will force it to be enabled.

Nicolas, how do you feel about asking for a selftest here? 
The functionality is fairly trivial from datapath PoV, but feels odd 
to merge uAPI these days without a selftest..