Feature Overview (aka. Goal Summary)  

Provide single stack IPv6 support across the Openshift Update Service (OSUS) and its Cincinnati operand to meet or exceed the CY2025 U.S. Federal mandate.

Goals (aka. expected user outcomes)

Ensure the Openshift Update Service (OSUS) and its Cincinnati operand can communicate over a single stack IPv6 network.

Requirements (aka. Acceptance Criteria):

Ensure the Openshift Update Service (OSUS) and its Cincinnati operand have CI and QE coverage for single stack IPv6 networking in at least one cluster configuration (e.g. self-manged Metal IPv6-only coverage is sufficient).

Use Cases (Optional):

IPv6-only clusters that install OSUS as a workload to serve local OpenShift Update Service advice.

Questions to Answer (Optional):

None at the moment.

Out of Scope

• The hosted OpenShift Update Service in api.openshift.com is out of scope, and depends on OCM-15917.
• OpenPGP/GPG signature access from storage.googleapis.com and mirror.openshift.com is out of scope, with no known tracker.
• Quay.io image access is untested (by OTA), and is out of scope, with no known tracker.
• The cluster-version operator. We already perform some CVO testing in IPv6-only clusters, e.g. we run 4.20 serial tests run on IPv6-only clusters, and since origin#30260, that coverage includes update-recommendation retrieval and PromQL evaluation. We also have longstanding testing of cluster updates in IPv6-only CI, although as with all update CI, we're running those before releases are signed, so they are not excercising signature-retrieval (but see the OpenPGP/GPG signature access entry above setting that out of scope).
• Comprehensive testing of OSUS advice-retrieval, signature retrieval, and updates in any particular environment (connected AWS HyperShift IPv6-only clusters, or disconnected, standalone metal IPv6-only clusters, etc.) is out of scope, due to the diversity of possible configurations, and no clear target for primary focus, with no known tracker.

Background

The CY2025 U.S. Federal mandate is driving increased interest in IPv6, and we want to make clear progress in that direction. But we want to avoid making the OTA team responsible for driving the overall effort, due to the number of possible environments that could theoretically be IPv6 and the number of components and teams that could be involved in that process.

Customer Considerations

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

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, 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.

<your text here>