[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKD1Yr3ZS8o09k=zFMhuwJueotJ5JzK-BPadm+B3_usDA7d6Og@mail.gmail.com>
Date: Wed, 4 Sep 2019 12:17:05 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: David Ahern <dsahern@...il.com>
Cc: Maciej Żenczykowski <zenczykowski@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Linux NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128
local route (and others)
On Wed, Sep 4, 2019 at 4:45 AM David Ahern <dsahern@...il.com> wrote:
>
> exactly. It was shortsighted of me to add the ADDRCONF flag and removing
> it reverts back to the previous behavior.
>
> When I enable radvd, I do see the flag set when it should be and not for
> other addresses. I believe the patch is correct.
Ah, wait, I was confused. Sorry.
What I was saying is that RTF_ADDRCONF flag should be set on the local
table /128 route for the IPv6 addresses configured by RAs. The way
those are configured is ndisc_router_discovery -> addrconf_prefix_rcv
-> addrconf_prefix_rcv_add_addr -> ipv6_add_addr ->
addrconf_f6i_alloc. Because in this patch, addrconf_f6i_alloc
unconditionally clears RTF_ADDRCONF, I didn't see how the flag could
be set. But I now realize that that was not happening before David's
commit, either: in 5.1 those routes were not created with RTF_ADDRCONF
either.
In other words: before 5.1, the /128 routes in the local table to IPv6
addresses created by SLAAC did not have RTF_ADDRCONF. After David's
commit, they did, because *all* /128 routes to IPv6 addresses had
RTF_ADDRCONF (correct for SLAAC adresses, but definitely incorrect for
manual addresses, loopback, etc.). If this commit is applied, we'll go
back to the 5.1 state. In the future it would be good to ensure that
at least the /128 routes created by SLAAC do have RTF_ADDRCONF, but no
need to do so in this commit.
Powered by blists - more mailing lists