[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Tue, Sep 01, 2020 at 08:27:47AM +0000, Cedric Bosdonnat wrote:
> So the hypervisor has at least one (Router Advertised) RA route.
> After defining a network like the following, the RA route is removed if
> accept_ra isn't set to 2.
> 
> <network ipv6="yes">
>   <name>test5</name>
>   <forward mode="nat"/>
>   <bridge name="708837c1d27-br0" stp="off"/>
>   <mac address="52:54:00:45:5f:27"/>
>   <ip
>      family="ipv6"
>      address="fc00:0000:0000:000f:0000:0000:0000:0001"
>      prefix="64"/>
> </network>
> 
> The RA route was removed in networkEnableIPForwarding() when
> setting /proc/sys/net/ipv6/conf/all/forwarding to 1.
> 
> Me not being a network expert (and even less on ipv6) doesn't help.
> 
> I hope this explanation will help you better see the use case I had.

So it seems to be the intention of the kernel that when you enable
forwarding your routes are flushed; changing the sysctl gets into
addrconf_fixup_forwarding() [1] which then calls
rt6_purge_dflt_routers() when the forwarding status is changed.  That
then purges default routes, unless accept_ra == 2; that was introduced
with [3].

I guess the idea is that a router should not accept
auto-configuration?

HOWEVER ...

               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;
                }

I feel like this is checking the RTF_ADDRCONF flag before it flushes
any routes.  Checking that flag ...

 #define RTF_ADDRCONF    0x00040000

which I do not have set at all, from :

 $ cat /proc/net/ipv6_route | awk  '{print $1 " " and(strtonum("0x"$9),strtonum("0x40000"))}'

Based on this, I'm concluding that the userspace tools do not set this
flag on their routes, and so they are never flushed.  Empirically,
fiddling forwarding on and off I don't see any routes flushed.

So, I do not think that enabling forwarding will remove routes on the
most common "sitting in-front of the computer" cases where you're
using NetworkManager/systemd userspace magic.

Given this, I'd propose we revert the check?

-i

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c#n840
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/route.c#n4282
[3] https://lkml.org/lkml/2013/3/26/745


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]