Bug#993362: cloud.debian.org: cloud-init doesnt run dhclient for IPv6
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
Reply to: