Going full IPv6 in Kubernetes: No limits, just 128 bits!#

Ole Mathias Heggem (Redpill Linpro)

• Why: IPv4 scarcity is now a cost line item (AWS public IPv4 charges, RIPE waiting list, CGNAT). IPv6-only Kubernetes with Cilium is newly practical, and this is a practitioner's account including the failure modes.
• What: The current state of K8s IPv6 (IPv6-only since 1.9, dual-stack GA since 1.23), a production IPv6-only deployment on Cilium, and the honest challenges: organizational readiness, apps/libraries that assume IPv4, managed services (LBs, storage, monitoring) that are IPv4-only, and lagging tooling.
• How: Concrete design choices — public prefix (requires ISP/cloud allocation and BGP to route to the cluster; per-node /64s from a pod /60; hardening via ACLs since pods are globally addressable) vs. ULA private prefixes (NAT66 or proxies for egress). Cilium 1.18 supports IPv6 underlay (example Helm/k3s config given: ipam: kubernetes, ipv6.enabled, underlayProtocol: ipv6, masquerade settings). IPv4-only services are reached via NAT64 + DNS64 or pull-through caches.
• Where applicable: Greenfield clusters, internal/server-facing estates, and anyone paying real money for IPv4. Client-facing services still need dual-stack; cloud provider maturity is mixed (Azure AKS uses NAT66). The numbers are operational guidance rather than benchmarks.