Bug#815884: does not retry IPv6 router solicitations

[Marc Haber]

Package: systemd
Version: 229-1
Severity: important

Hi,

systemd 229 has taken over the code to send and accept router
solicitations in IPv6. Unfortunately, it does only send a single RS
immediately after the link comes up, and does not retry if no RA comes
in.

Unfortunately, bigger switches do not immediately begin forwarding
packets after a link was brought up but take a few seconds before the
port actually enters forwarding state. On Cisco Catalyst Switches in
default configuration, this typically takes 30 seconds until the port
is set to spanning-tree portfast. On HP ProCurve switches, it takes 6
to 10 seconds unless LACP and STP negotiation is completed. LACP can
be turned off, STP cannot.

When a system running IPv6 with systemd 229 is connected to such a
switch, the system doesn't get IPv6 on startup, and it doesn't acquire
IPv6 on the next regular RA because of #815793. This makes IPv6
completely unuseable.

Going back to systemd 226 fixes the issue.

With systemd 229, if one forces the switch port in the forwarding
state by inserting a dumb switch between the "big" switch and the
Linux system, one sees the RA sent by systemd, and IPv6 works. But one
cannot possible use dumb switches just to fix systemd's shortcomings.

This is a showstopper for IPv6 with systemd. I would like to ask the
Debian systemd maintainers to use their discretion to set either this
or #815793's severity to any RC value, as both behavioral anomalities
of systemd are blatant violations of the IPv6 RFCs.

systemd should only migrate to testing when it doesn't break IPv6 any
more.

Greetings
Marc