[PATCH] network: allow accept_ra == 0 when enabling ipv6 forwarding

[Cedric Bosdonnat]

Hi Ian,

On Thu, 2020-09-10 at 09:48 +1000, Ian Wienand wrote:
> On Wed, Sep 09, 2020 at 06:38:04AM +0000, Cedric Bosdonnat wrote:
> > The check didn't involve any NetworkManager at all, but a network with
> > RA route for the default route. Completely removing the check is rather
> > likely to introduce a regression on that side.
> 
> Thanks for putting up with my bumbling about here :)
> 
> So firstly; I think we can state the big picture original problem as
> "the kernel was seen to flush existing ipv6 routes when ipv6
> forwarding is enabled, unless accept_ra==2 is set, which
> <may|probably|does> break peoples networking"?

That is right

> If that premise is correct, then I also think I'm correct in saying
> from ~[1] that the kernel will only flush routes with RTF_ADDRCONF
> set?
> 
>   if (rt->fib6_flags & (RTF_DEFAULT | RTF_ADDRCONF) &&
>                  (!idev || idev->cnf.accept_ra != 2) &&
>                    fib6_info_hold_safe(rt)) {
>                         rcu_read_unlock();
>                         ip6_del_rt(net, rt);
>                         goto restart;
>   }
> 
> If that premise is correct, then I also think that userspace tools do
> not set this flag on routes they setup when they handle RA's in
> userspace.  I couldn't see it set on any of my routes on my laptop,
> and enabling/disabling forwarding didn't seem to flush any routes.
> 
> If *that* premise is correct too, then as I understand the current
> code it queries netlink for all the routes, checks if they have
> RTPROT_RA set, and if accept_ra != 2 gives the error.
> 
> If **that** premise is correct, then I think that just checking
> RTPROT_RA is too strict -- per the prior steps the route will only be
> flushed by the kernel if it has RTF_ADDRCONF set on it, and for many
> people using userspace tools their routing is not affected by enabling
> forwarding at all.

After reproducing here, I see the RTF_ADDRCONF flag set on those routes
in /proc/net/ipv6_route. Looks like your theory fits with the use case.

> If ***that*** premise is correct -- what to do about it?  I don't
> think netlink exposes RTF_ADDRCONF?  It can be seen via the flags dump
> in /proc/net/ipv6_route however (maybe that's a field in netlink?).
> But there may be room for conversation on how much this warning helps
> v hinders in 2020; it's not like it fixes the problem for you.

You surely know more netlink than I do ;)

--
Cédric