[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180523072634.ir37ska2f7eswznz@salvia>
Date: Wed, 23 May 2018 09:26:34 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Vincent Bernat <vincent@...nat.im>
Cc: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
Florian Westphal <fw@...len.de>,
"David S. Miller" <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1] netfilter: provide input interface for route
lookup for rpfilter
On Sun, May 20, 2018 at 01:03:38PM +0200, Vincent Bernat wrote:
> In commit 47b7e7f82802, this bit was removed at the same time the
> RT6_LOOKUP_F_IFACE flag was removed. However, it is needed when
> link-local addresses are used, which is a very common case: when
> packets are routed, neighbor solicitations are done using link-local
> addresses. For example, the following neighbor solicitation is not
> matched by "-m rpfilter":
>
> IP6 fe80::5254:33ff:fe00:1 > ff02::1:ff00:3: ICMP6, neighbor
> solicitation, who has 2001:db8::5254:33ff:fe00:3, length 32
>
> Commit 47b7e7f82802 doesn't quite explain why we shouldn't use
> RT6_LOOKUP_F_IFACE in the rpfilter case. I suppose the interface check
> later in the function would make it redundant. However, the remaining
> of the routing code is using RT6_LOOKUP_F_IFACE when there is no
> source address (which matches rpfilter's case with a non-unicast
> destination, like with neighbor solicitation).
Applied, thanks Vincent.
Powered by blists - more mailing lists