netdev - Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0 locally

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56CB2564.9030003@stressinduktion.org>
Date:	Mon, 22 Feb 2016 16:12:36 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Marc Haber <mh+netdev@...schlus.de>
Cc:	netdev@...r.kernel.org
Subject: Re: IPv6 route to gateway on fe80::1%eth0 when I have fe80::1%br0
 locally

Hi Marc,

On 22.02.2016 16:04, Marc Haber wrote:
> In prose:
>
> The host is a host for KVM VMs. It receives IPv6 connectivity via RA
> on eth0, where the default gateway announces its address as fe80::1.
> It also provides IPv6 connectivity to the VMs via the br0 interface.
> It is running radvd on br0, and for statically configured VMs it has
> also fe80::1 on br0.
>
> If accept_ra_from_local on eth0 were 0, the system would not accept
> the RA from the default gateway and and up with no IPv6 since fe80::1
> is locally configured with br0.

Isn't this behavior fixed with

commit c1a9a291cee0890eb0f435243f3fb84fefb04348
Author: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date:   Wed Dec 23 22:44:37 2015 +0100

     ipv6: honor ifindex in case we receive ll addresses in router 
advertisements

$ git describe --contains c1a9a291cee0890eb0f435243f3fb84fefb04348
v4.4-rc8~5^2~10

?

If you don't have fe80::1%br0 bound on exactly that interface, it should 
work, no? So, no need for accept_ra_from_local, which has dubious 
semantics anyway.

> If accept_ra_from_local on eth0 is 1, the system accepts both the RA
> from the default gateway on eth0 _AND_ its own RA sent out and
> received on br0, and, making things worse, is setting the IP address
> and default route not on br0, but on eth0.

Understood. Thanks, I was just able to easily reproduce it. Was already 
wondering why someone would enable accept_ra_from_local besides only 
testing. I check it out, thanks!

Thanks,
Hannes