The semantics of systemd-networkd-wait-online.service are that the
service is ready when "the Internet" is reachable. In the past, the
implementation of network-online.target has been less correct on Ubuntu,
*because* ipv6 RA was handled asynchronously, and this target did not
block waiting to find out if ipv6 had been configured. That was mostly
ok up until now in an IPv4-dominated world, but over the course of 18.04
LTS's lifetime, I expect we will increasingly see IPv6-enabled
deployments where the default IPv6 route is as important as, or more
important than, the default IPv4 route, and to not block waiting for
SLAAC results in an RFC-compliant manner would make the boot racy. We
cannot regard IPv6 as an afterthought. I agree with systemd upstream's
decision to block on IPv6 results by default.
However, in most environments where cloud-init is running, we shouldn't
need a configurable timeout for SLAAC at all because we know by design
whether or not we can expect ipv6 and if we know that the substrate does
not provide ipv6, the netplan yaml for this provider should specify
'accept-ra: false'. Then the timeout is the correct 0, and there is no
adverse effect on boot speed.
For public clouds that don't provide netplan yaml today and instead have
default netplan yaml generated by cloud-init, this should be included as
part of the default policy in cloud-init.
For any public clouds that are ipv6 opt-in, it is probably still
appropriate to emit accept-ra: false by default in order to ensure a
good default experience; and deal with opt-in ipv6 support via user-
provided (or, preferably: cloud-provided) override cloud config.
For the lxd case, the default should be 'accept-ra: false', with logic
added later in lxd to set 'accept-ra: true' when lxd knows that the
bridge supports ipv6.
I think we will want to extend networkd and netplan to allow expression
of additional network policies beyond the options of 'accept-ra: true'
and 'accept-ra: false'. It should be possible to express that the
kernel should try SLAAC, but that networkd should not block on SLAAC
results for purposes of systemd-networkd-wait-online, while still
blocking on *ipv4* connectivity for this interface. However, this will
take some time to design properly, and I do not think that this should
be the default for networkd+netplan once implemented: the forward-
looking default is still that we should wait for a firm answer from
SLAAC before considering the network up, and that if the user wants a
different policy from this, it should be an override of the default
netplan configuration.
So I believe the quick path for addressing this issue in 18.04 is for
cloud-init to declare 'accept-ra: false' everywhere that this is
reasonable, with a possible relaxation to a future opportunistic accept-
ra policy once this is available in netplan+networkd.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1765173
Title:
networkd waits 10 seconds for ipv6 network discovery by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1765173/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
