Feature Overview (aka. Goal Summary)  

This feature focuses on enabling the Cloud Controller Manager (CCM) within OpenShift clusters to properly manage and configure network resources for dual stack (IPv4 and IPv6) operations on major cloud providers. The CCM's role is critical for ensuring that Node IP addresses are correctly configured for dual stack and that cloud provider load balancers, where supported, can expose services with both IPv4 and IPv6 frontends. This is a foundational piece for OpenShift to comply with evolving federal mandates, such as FedRAMP, and broader Department of Defense initiatives requiring comprehensive IPv6 support while maintaining IPv4 compatibility.

Analysis - https://docs.google.com/document/d/1A50hW_cwPEt7lkIoTiYXnQlqBvUDME-tjisHjfRHEac/edit?tab=t.0#heading=h.l1bbay57nfgr 

Goals (aka. expected user outcomes)

Upon completion of this feature, users should be able to:
• Observe OpenShift cluster nodes obtaining and utilizing both IPv4 and IPv6 addresses, managed by the CCM.
• Successfully deploy OpenShift services that are exposed via cloud provider load balancers managed by the CCM, supporting dual stack where the cloud provider's load balancer type and the CCM's capabilities allow.
• Leverage the CCM's capabilities to contribute to the overall dual stack readiness of OpenShift clusters on AWS, Azure, and GCP.

Requirements (aka. Acceptance Criteria):

This feature specifically outlines changes and expected behaviors for the Cloud Controller Manager and its associated operator (CCMO) across supported cloud providers.
• Cloud Controller Manager Operator (CCMO) Enhancements:
    ◦ The CCMO must be updated to correctly configure the NodeIPFamilies option within the cloud provider configuration for the CCM. This setting is essential for enabling dual stack support for Node IP addresses.
    ◦ The CCMO should be capable of automatically sourcing the required IP stack information from the underlying cloud infrastructure to configure NodeIPFamilies for the cluster, especially on AWS and GCP, where this is not yet implemented.
• AWS Cloud Controller Manager (CCM) Specifics:
    ◦ Node IP Addresses: The AWS CCM already manages Node IP addresses. The primary requirement is for the CCMO to correctly configure the NodeIPFamilies option within the CCM's cloud configuration to enable dual stack node addressing.
    ◦ Classic Load Balancers (CLB): While the IP family for CLBs is determined by attached subnets, the AWS CCM does not directly support a special configuration for dual stack CLBs that exposes both IPv4 and IPv6 frontends. If this is required, it implies a limitation of the current CCM implementation, potentially necessitating manual workarounds on the AWS side.
    ◦ Network Load Balancers (NLB): IPv6 frontend support for NLBs is not implemented in the AWS CCM. The current approach to provide this functionality relies on the separate AWS Load Balancer Controller (LBC). For customers requiring IPv6 NLB frontends, this feature does not entail implementing that capability directly within the AWS CCM; instead, it acknowledges the existing limitation and suggests reliance on the LBC (via ALBO).
• Azure Cloud Controller Manager (CCM) Specifics:
    ◦ The Azure CCM already inherently supports both single stack IPv6 and dual stack clusters, with successful end-to-end demonstrations.
    ◦ It supports annotations for services to configure front-end IPs for IPv4, IPv6, and dual stack.
    ◦ No new work is required for the Azure CCM itself beyond ensuring sufficient installation testing confirms its existing dual stack capabilities.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

Hosted control planes

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

Customers, especially those in government or regulated sectors, critically need IPv6 support to meet compliance mandates. The CCM's ability to facilitate dual stack for Node IPs and cloud load balancers is key to their adoption of OpenShift. On AWS, customers seeking IPv6 NLB support will need to use the ALBO, which implies a distinct implementation from the CCM's NLB. The fact that there is no migration path between CCM and LBC implementations for NLBs means customers might need to delete and recreate load balancers if they switch to ALBO for IPv6, which could be a disruptive process for existing deployments. However, for new dual stack deployments, this might be less of an issue.

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  Initial completion during Refinement status.
• CCM Configuration: Detail the specific NodeIPFamilies configuration for Node IP addresses and how the CCM leverages it.
• Cloud Provider Specifics: Provide explicit documentation on the varying levels of dual stack support and specific configurations or limitations for AWS, Azure, and GCP load balancers managed by the CCM. This should highlight which load balancer types support IPv6 frontends via the CCM and which do not.
• Workarounds/Alternatives: Document recommended approaches for scenarios where the CCM itself does not provide IPv6 frontend support, such as leveraging ALBO for IPv6 NLBs on AWS.

Interoperability Considerations

Which other projects and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.