Bug#827424: systemd-networkd IPv6AcceptRouterAdvertisements doesn't work

[Michael Berg]

My original bug report was against systemd 230.

I believe this issue was fixed as a result of various IPv6
changes somewhere in the development of 231 or 232.

> Try checking /proc/sys/net/ipv6/conf/$INTERFACE/accept_ra
> You'll notice "all" has the system-global setting you're seeing
> with sysctl, but that a particular link/interface has another
> which makes it deviate from the global default.

I fully understand the differences between the `all`, `default`, and
`$INTERFACE` versions of `accept_ra`.

In my original bug report, I demonstrated the incorrect behavior that
I was seeing with `$INTERFACE=br_32` (a bridge interface on my system).

> The systemd networkd has it's own router advertisement implementation
> and doesn't rely on the kernels default. Also I think networkd
> handles things per-link which means that looking at system-global
> settings is probably not very useful.
> 
> If you look at a particular link you'll likely see that it has
> accept_ra=0 (eg. disabled) whenever you use systemd networkd
> to handle RA on that link.

At the time of my bug report, systemd was using and modifying the
kernel `accept_ra` setting for that interface.
You can see `net.ipv6.conf.br_32.accept_ra` (for interface `br_32`)
getting consistently set to 1 by systemd in my original bug report.
And the system's acceptance of RA messages matched the settings of the
respective interface's `accept_ra` sysctl setting (when it was 0, that
interface would never get a routable IPv6 address).

As you can see here, systemd has bounced back and forth between
handling IPv6 network discovery itself and letting the kernel handle it
on at least one occasion due to serious bugs in systemd.
https://github.com/systemd/systemd/commit/fe30727643a7c53faa29f1caa8dcabcb2b6f6fcb

With systemd 232 installed on my system, I currently see the behavior
you describe of systemd setting `net.ipv6.conf.br_32.accept_ra = 0` and
handling IPv6 RA messages itself instead of using the kernel setting.
That wasn't the behavior under the Debian packages of version 230.

This bug can be closed as it was fixed in the packages for either
version 231 or 232.