Hi Kevin,
> In the year 2020, IPv6 should be a first class citizen and I should not need
> to provide additional config for it to work right. The issue here is not
> that I can't find a workaround to make my scenarios work. The issue here is
> that I should not need any such workarounds on a modern network.
Thanks. I understand, and in general, agree with the goal. Our challenge is
how to balance default configurations with competing goals. We can enable
lots of default features for maximum compatibility; however there is almost
always a trade-off. The trade off for IPv6 is significant delay during boot
if IPv6 is not present.
Cloud-init blocks during boot to ensure that networking is configured (as
expected) before continuing to boot; later stages of boot can expect that
networking is available for fetching data from the network. In the case of
IPv6, and *blocking* for IPv6 during boot there is a very high cost in
networks where IPv6 is not available. The Ubuntu kernel already accepts
IPV6 Router Advertisements by default, but asynchronously from the systems
network configuration. As mentioned, we can enable blocking on RAs by
default but there is a very large boot time delay for networks without RAs.
As an example, I've two instance differing only in one where I've enabled
blocking for RAs and the boot time is 12 seconds slower due to waiting on RAs.
# default fallback networking (dhcp4 only)
root@g3:~# systemd-analyze
Startup finished in 8.132s (userspace)
graphical.target reached after 7.603s in userspace
# dhcp4 and accept-ra: true
root@g4:~# systemd-analyze
Startup finished in 19.988s (userspace)
graphical.target reached after 19.472s in userspace
# using systemd-analyze critical-chain we can see where the time went
root@g3:~# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @7.603s
└─multi-user.target @7.602s
└─rsyslog.service @2.524s +5.074s
└─basic.target @2.491s
└─sockets.target @2.491s
└─snapd.socket @2.489s +2ms
└─sysinit.target @2.485s
└─cloud-init.service @1.853s +631ms
└─systemd-networkd-wait-online.service @1.608s +243ms
└─systemd-networkd.service @1.326s +279ms
└─network-pre.target @1.325s
└─cloud-init-local.service @747ms +578ms
└─systemd-journald.socket @165ms
└─system.slice @162ms
└─-.slice @162ms
root@g4:~# systemd-analyze
Startup finished in 19.988s (userspace)
graphical.target reached after 19.472s in userspace
root@g4:~# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @19.472s
└─multi-user.target @19.472s
└─rsyslog.service @14.378s +5.092s
└─basic.target @14.338s
└─sockets.target @14.338s
└─snapd.socket @14.333s +4ms
└─sysinit.target @14.329s
└─cloud-init.service @13.686s +642ms
└─systemd-networkd-wait-online.service @1.672s +12.010s
└─systemd-networkd.service @1.376s +290ms
└─network-pre.target @1.375s
└─cloud-init-local.service @781ms +593ms
└─systemd-journald.socket @159ms
└─system.slice @156ms
└─-.slice @156ms
And with debugging on we can see where networkd is sending Router
Solicitations and waiting for a response.
[205653.809964] g4 systemd[1]: Starting Network Service...
...
[205654.706539] g4 systemd-networkd[191]: NDISC: Sent Router Solicitation, next
solicitation in 4s
[205658.783325] g4 systemd-networkd[191]: NDISC: Sent Router Solicitation, next
solicitation in 7s
[205659.231119] g4 systemd-networkd[191]: rtnl: received non-static neighbor,
ignoring.
[205666.110936] g4 systemd-networkd[191]: NDISC: No RA received before link
confirmation timeout
[205666.112556] g4 systemd-networkd[191]: NDISC: Invoking callback for
'timeout' event.
[205666.112822] g4 systemd-networkd[191]: eth0: State changed: configuring ->
configured
[205666.113225] g4 systemd-networkd-wait-online[192]: managing: eth0
[205666.116688] g4 systemd[1]: Finished Wait for Network to be Configured.
If we were to change the default to block for IPv6, and every cloud image boot
were to block 12 seconds waiting for an RA, I'm positive the opposite bug
would be filed requesting that we don't enable ipv6 when it's not widely
deployed.
On clouds where ipv6 is available, those platforms provide cloud-init with
networking configuration indicating that cloud-init should turn on ipv6 and
expect a response. This prevents instances from waiting for ipv6 responses
which will never come and delaying boot.
That said, I do think that cloud-init can make it easier to enable ipv6 where
it's desired (but without having to write your own network config). We're
looking into supporting a kernel parameter or cloud-config option to enable
the default config to block on ipv6 (note, we cannot use user-data to indicate
this preference as user-data is processed after networking is up as user-data
can be fetched via network URL).
I hope that helps explain the current network configuration even if we don't
agree on the current configuration default.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878682
Title:
IPv6 not enabled by default
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1878682/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
