Dear Maintainer,
the bullseye cloud image doesnt run the dhclient for IPv6.

The interfaces are configured correctly, but dhclient is only executed
for IPv4.

On buster on the other hand:

is the dhclient executed for IPv4 and IPv6.

We run an OpenStack platform. The Issue leads to no IPv6 capabilty on the VM until you manually execute a DHCPv6 request.
The tests were conducted on a freshly initialized instance with no prior modification.

On 2021-08-31 10:54:02 +0000 (+0000), Anton Scharnowski wrote:
[...]
[...]

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.

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.

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.

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