On Wed, Sep 4, 2019 at 4:45 AM David Ahern <dsah...@gmail.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.
