Feature Overview

IPv6 was designed some 20 years ago to address the problem of finite IPv4 addresses. To keep it simple, Kubernetes bootstrapped with support for only IPv4, which worked well for simpler deployments and for the majority of the use-cases "then". With Kubernetes gaining massive adoption over time, the number of use-cases had exponentially grown, and so the requirements for IPv6 started to emerge.

To support IPv6, Kubernetes (1.9 alpha) started a transitional step to support "Single Stack IPv6", meaning you can either have IPv6 OR IPv4 in a cluster, can't have them simultaneously. This helped validate IPv6 functionality and move it forward. Single-stack IPv6 was actually fine for the majority of use-cases that "require" IPv6 but again, there is always an exception to the rule, i.e., not all use-cases required ONLY IPv6, some required both. Dual-stack was born, but it was not born as an adult, it was born as a baby that brought in many changes to its parent (Kubernetes), almost in every aspect (see figure below to get an idea). That baby is growing more mature with time, in fact, mature enough to be upstream beta in Kubernetes 1.21.

As a distribution of Kubernetes, Openshift is always on the lead for bringing upstream all the necessary changes required to ensure IPv6 (single and dual) stack compatibility. The below figure shows the progress of IPv6 in OCP:

The efforts to bring-in support for IPv6 reflected in many of the layered offerings [1].

Openshift Sandboxed containers, based on upstream project Katacontainers, follow the same networking model of Kubernetes (after all katacontainers is just another low-level runtime implementation of the well-standardized OCI interface served by the high-level Kubernetes CRI runtime interface) that is basically summarized as:

• Pods on a node can communicate with all pods on all nodes without NAT
• Agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node.

This feature covers the efforts required to qualify IPv6 dual-stack usage with Openshift Sandboxed Containers upstream and downstream.

Background & Strategic Fit

IPv6 can be considered an aged theme for many, but not for Telcos. The adoption of IPv6 started not long after IPv6's birth. Most telco networks run their internal networks and infrastructure on IPv6. With Telco being one of the most important use-cases for Openshift Sandboxed Containers, it's only natural to qualify the use-case.

Goals

• Validate IPv6 with Kata-based pods, reference for validation [2].
• Make sure that Kata with IPv6 integrates well with all the other components (e..g, runtime, Virt, ...)

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content Strategy.
• What concepts do customers need to understand to be successful in [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or Release Note)?

References

1. "https://issues.redhat.com/browse/KNIDEPLOY-1542?jql=issuetype in (Epic%2C Feature) AND text ~ ipv6"
2. https://kubernetes.io/docs/tasks/network/validate-dual-stack/#before-you-begin