Add dual-stack IPv4/IPv6 support for OpenStack shoots

[axel7born]

• Add SubnetPoolID field to InfrastructureConfig for IPv6 subnet allocation
• Create separate IPv6 subnets for nodes, pods, and services from subnet pool
• Add validation requiring SubnetPoolID for dual-stack configurations
• Update machine classes to support dual subnets and pod network CIDRs

How to categorize this PR?

/area networking
/kind enhancement
/platform openstack

What this PR does / why we need it:
This PR adds dual-stack (IPv4/IPv6) networking support for OpenStack shoots.

The implementation creates separate IPv6 subnets for nodes, pods, and services, allocated from a configurable OpenStack subnet pool. This approach ensures proper address scope management and compatibility with external routing infrastructure.

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Release note:

Add dual-stack (IPv4/IPv6) networking support for OpenStack shoots. Configure `subnetPoolID` in InfrastructureConfig to allocate IPv6 subnets for nodes, pods, and services.

[gardener-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign matthias-horne for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[fzakfeld]

Thanks for implementing this. I'd like to point out that there are setups that don't use subnet pools with IPv6.

We run some internal networks where an IPv6 subnet is routed statically from some firewalls. Currently, we create shoots with a fixed IPv4 CIDR, which is also routed within the broader corporate network:

infrastructureConfig:
  apiVersion: openstack.provider.extensions.gardener.cloud/v1alpha1
  kind: InfrastructureConfig
  networks:
    router:
      id: <existing_router_uuid>
    workers: <worker_network_cidr>

This would work the same with IPv6 subnets, but requiring a subnet pool ID would prevent us from implementing this. It would be great if we can still get support for explicit IPv6 CIDRs.

[axel7born]

Hi @fzakfeld

Thanks for implementing this. I'd like to point out that there are setups that don't use subnet pools with IPv6.

We run some internal networks where an IPv6 subnet is routed statically from some firewalls. Currently, we create shoots with a fixed IPv4 CIDR, which is also routed within the broader corporate network:

infrastructureConfig:
  apiVersion: openstack.provider.extensions.gardener.cloud/v1alpha1
  kind: InfrastructureConfig
  networks:
    router:
      id: <existing_router_uuid>
    workers: <worker_network_cidr>

This would work the same with IPv6 subnets, but requiring a subnet pool ID would prevent us from implementing this. It would be great if we can still get support for explicit IPv6 CIDRs.

By now it's not possible in the Shoot spec to specify IPv4 and IPv6 CIDRs for node, pods and services.
We would need an API change in gardener/gardener to implement this.
@ScheererJ @DockToFuture @domdom82 What do you think?

[ScheererJ]

By now it's not possible in the Shoot spec to specify IPv4 and IPv6 CIDRs for node, pods and services. We would need an API change in gardener/gardener to implement this. @ScheererJ @DockToFuture @domdom82 What do you think?

It was a conscious decision to move away from providing the IP ranges for IPv6 upfront in most cases and let the infrastructure handle it. I would prefer to keep it that way.
However, it could be possible to specify the missing range(s) in the provider configuration. For other infrastructures, e.g. AWS or GCP, the IPv4 ranges are specified as before for dual-stack clusters, but the IPv6 range is provided by the infrastructure. If there is a need to manage IPv6 externally in openstack infrastructures, we can consider adding a new attribute next to workers.

@kon-angelo What do you think?

[axel7born]

Hey @fzakfeld,
Regarding the configuration of IPv6 CIDRs, we could extend the provider config for this. We could add one additional attribute to configure an IPv6 CIDR and split it up for nodes, pods, and services. Would this approach meet your requirements?

[fzakfeld]

Hi @axel7born

split it up for nodes, pods, and services.

Does this mean I'll provide, lets say a /56, and this gets somehow automatically split up in smaller prefixes for nodes, pods and services? Or do I specify them individually like with IPv4 now?
(I think both ways would solve my problem)

[github-actions]

This change implements dual-stack networking support (IPv4/IPv6) for OpenStack Kubernetes clusters, allowing users to deploy clusters with both IPv4 and IPv6 connectivity. The implementation provides two configuration approaches: automatic IPv6 allocation via subnet pools or explicit IPv6 CIDR specification.

Walkthrough

• New Feature: Added dual-stack networking support with two configuration options: subnet pool-based automatic IPv6 allocation and explicit IPv6 CIDR configuration for nodes, pods, and services
• New Feature: Enhanced infrastructure controller to create and manage IPv6 subnets, router interfaces, and security group rules for dual-stack clusters
• Documentation: Added comprehensive usage documentation explaining both IPv6 configuration approaches with examples
• Refactor: Updated machine class templates to support multiple subnet IDs and modified validation logic to require IPv6 configuration for non-single-stack clusters
• Bug Fix: Removed previous restriction that blocked dual-stack networking entirely

_{Model: claude-sonnet-4-20250514 | Prompt Tokens: 17340 | Completion Tokens: 215}