I disagree that SLAAC is something that we should by default block reaching network-online.target. In general we cannot know in advance whether or not another system in the same subnet is providing Router Advertisements to other instances.
If one instance in my VPC is running radvd, ec2 has no knowledge of this meaning that if cloud-init sets accept-ra: false; that disables accepting RAs and that breaks this use-case; this is similar for LXD as well. Additionally, accept-ra:false doesn't mean networkd doesn't handle RA, it also disables accept-ra in the kernel as well; I believe that *IF* you are running an instance where you expect to use SLAAC and know that you won't use other means of network configuration then that instance should set some sort of flag to indicate that you want network-online.target to wait for a SLAAC response. No matter how forward looking we want to be; it doesn't make sense to punish the majority of boots today with a 10 second timeout. -- 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
