On Tue, Aug 31, 2021 at 12:20:31PM +0000, Jeremy Stanley wrote: > On 2021-08-31 10:54:02 +0000 (+0000), Anton Scharnowski wrote: > [...] > > We run an OpenStack platform. The Issue leads to no IPv6 capabilty > > on the VM until you manually execute a DHCPv6 request. > [...] > > As an aside, do note that whether IPv6 connectivity requires DHCPv6 > depends on how OpenStack is configured to deliver it. Not all > OpenStack deployments rely on DHCPv6 to configure IPv6 addresses. It > could instead communicate them to cloud-init via network_data.json > in a configdrive, for example.
There are known issues with IPv6 configuration in the bullseye generic cloud images. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991613 and the attempted solution to it in https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/262 and the subsequent revert commit in https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/265 Part of the issue is that the network configuration framework used in the cloud images (ifupdown) isn't very good at handling the various different combinations of possible configurations options (IPv4-only, dualstack, v6-only). See #804396 ("if IPv6 configuration fails, then IPv4 is not configured"), which is tagged wontfix, for example. > Also this is probably not an OpenStack-specific problem, and would > likely arise in other environments expecting to configure IPv6 via > DHCP with the Bullseye cloud images. It sort of is specific to OpenStack, at least within the context of the cloud images. The reason for that is that our OpenStack users expect to be able to pass network configuration to instances via config drives, which involves cloud-init. In order to facilitate this, we let cloud-init handle network configuration. In other cloud environments, network configuration is always provided by DHCP, and cloud-init is not involved in network configuration. This has let us implement a workaround for ifupdown's inflexibility using some custom udev event handlers. A possible near-term solution to this situation might be to teach cloud-init to generate interface config fragments with the "try_dhcp" option that we use in other environments. That would let cloud-init continue to handle network configuration while also ensuring that the right thing happens in various different environments. Longer term, the solution is to stop relying on ifupdown. noah
