Re: [PATCH net-next] ipv4: add ip_process_options sysctl

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Nov 02, 2026 at 04:59:58PM +0100, Ricardo Branco wrote:
> Add net.ipv4.ip_process_options to control handling of IP options in
> received packets, modelled after FreeBSD's net.inet.ip.process_options:
> 
>   0 - ignore options; the packet is handled as if it had none, and
>       forwarded packets keep their options unmodified
>   1 - process options (default, current behaviour)
>   2 - drop packets carrying options and send an ICMP "packet filtered"
>       error, as FreeBSD does
> 
> Most IP options are obsolete or rarely needed, and are commonly filtered
> (RFC 7126), yet the only existing knob, accept_source_route, covers just
> the source routing options; record route, timestamp and the rest are
> always processed. Netfilter can match and drop such packets, but unlike
> TCP options it has no way to strip or neutralise IPv4 options while
> still accepting the packet. A sysctl gives a simple switch with the same
> semantics as the FreeBSD one, which also eases porting existing
> configurations.
> 
> The check is done first in ip_rcv_options(), so it takes precedence over
> accept_source_route and skips the skb_cow() and option parsing.
> Ignoring options is safe because IPCB(skb) is zeroed in ip_rcv_core().
> 
> Note that mode 2 also drops packets whose only option is Router Alert,
> e.g. IGMP, which can break multicast on routers.

Ease of porting from FreeBSD is not a good enough reason to add a new
sysctl that we will never be able to remove, especially when almost all
of the functionality is already covered by netfilter and in a better
way.

Netfilter already covers option 2 and it can match on specific options,
thereby avoiding the IGMP breakage.

Regarding option 0, assuming it's actually needed (beyond feature
parity), why not add "reset ip option <name>" similar to "reset tcp
option <name>" that was implemented in commit 7890cbea66e7 ("netfilter:
exthdr: add support for tcp option removal")?