Cilium 1.20 widens the Gateway API, enables ENI IPv6 on AWS, and opens the datapath to plugins
Cilium 1.20, released on September 14, 2026, turns the Gateway API into a full traffic-management layer and finally closes the IPv6 gap in ENI mode on AWS. Teams migrating off ingress-nginx or extending their CNI now have a concrete reason to move.
September 14, 2026. The Cilium team ships version 1.20, its second major release of the year. The Gateway API jumps from v1.4 to v1.6 and gains ExternalAuth, TCP/UDP routes, and ListenerSets. IPv6 finally arrives in ENI IPAM mode on AWS. Why it matters: the CNI you already run can now absorb your north-south traffic layer, at exactly the moment ingress-nginx enters retirement.
The Gateway API grows into a real routing layer
The most visible jump is the Gateway API. Cilium 1.20 moves from v1.4 to v1.6 and adds three building blocks that change the game for platform teams. ExternalAuth offloads authentication and authorization before a request reaches the application — work previously delegated to dedicated ingress controllers. CORS filters and ListenerSets pull the Gateway API closer to a genuine entry frontend. Most importantly, TCPRoute and UDPRoute extend management to non-HTTP traffic, where ingress-nginx could only do L7.
The release note is explicit: if you still run Ingress NGINX, the CNI you already operate can take that traffic back. This is a consolidation play — one network building block instead of two — but also a calendar issue. We covered the ingress-nginx retirement on this blog: the project is no longer actively maintained, and the Gateway API is the exit path.
ENI IPv6 on AWS, four years after the request
The second major announcement is technical and long overdue. In ENI IPAM mode — the AWS-specific mode that hands pods real VPC addresses — Cilium only supported IPv4. Cilium 1.20 enables IPv6 as a beta feature, four years after the original request. The operator attaches a /80 prefix to each node’s ENI through Prefix Delegation, and the agent assigns pod addresses from it.
The configuration is three lines:
ipam:
mode: eni
eni:
enabled: true
ipv6:
enabled: truePods then boot dual-stack with a VPC-routable IPv6 address:
NAME IPS
dualstack-demo-7f8876746b-5xvnk 192.168.128.71,2a05:d01c:38d:4c02:909e::e771Credit goes to Datadog, which built ENI IPv6 support and closed what remained of the IPv4/IPv6 parity gap in Cilium. For EKS platforms approaching private IPv4 address exhaustion, this is the exit door without migrating to another CNI.
Automatic netkit: performance without the headache
Cilium 1.20 also adds bpf.datapathMode=auto for netkit, the pod network device that replaces the veth pair and brings throughput to host level. The catch until now: netkit required a 6.8 kernel or newer, forcing heterogeneous fleets to split nodes by kernel version. With auto, each agent probes its host at startup, uses netkit when the kernel allows, and falls back to veth otherwise.
$ cilium-dbg status | grep Device
Device Mode: netkit [Configured: auto]The stakes are not theoretical. Meta rolled netkit out across millions of containers, and ByteDance at a comparable scale, with a measured 10% improvement in its tests. One setting across a mixed fleet, and you inherit that performance as nodes refresh.
Datapath Plugins: Cilium becomes a network operating system
The most structural announcement is datapath plugins (beta). Until now, extending Cilium’s eBPF datapath meant two options: contribute upstream, or maintain a fork. Google, which ran its own fork, built the third way: third-party code instruments itself as a plugin, runs in a separate process that Cilium reaches out to, and evolves on its own release cadence.
apiVersion: cilium.io/v2alpha1
kind: CiliumDatapathPlugin
metadata:
name: example
spec:
attachmentPolicy: Always
version: 0.0.1The maintainers’ metaphor is deliberate: Cilium looks less like a sealed network appliance and more like a network operating system — a stable core that cloud providers extend with their own eBPF programs. A crashing plugin does not take the agent down with it, and its image is versioned independently of Cilium.
The rest: fine-grained anti-spoofing, stable MCS, and BGP
Two other changes deserve attention. Source IP verification — which stops a compromised pod from spoofing a neighbour’s address — becomes per-pod disableable rather than cluster-wide. NAT appliances, firewalls, and VPN/Tailscale gateways can emit packets with a foreign source without weakening anti-spoofing everywhere else. On the standardization front, the Multi-Cluster Services API reaches stable and ClusterNetworkPolicy aligns with the Kubernetes API: Cilium keeps offering its native CRDs alongside portable resources.
BGP is not left out, with a migration notice: the on-agent cilium-dbg bgp subcommands and the local REST BGP API are deprecated in favour of the cilium-dbg shell equivalents. The user-facing cilium bgp CLI is unchanged.
Verdict
Cilium 1.20 is the release that turns a CNI upgrade into an architecture decision. If you are still on ingress-nginx, the Gateway API v1.6 with ExternalAuth and TCP/UDP routes is reason enough to plan the switch — especially since the ingress-nginx project is retiring. If you run EKS and are nearing IPv4 exhaustion, enable ENI IPv6 in beta rather than layering on complicated NAT. If you are a cloud provider or a large fleet, datapath plugins remove the maintenance cost of a fork. Either way, the move stays incremental: the default remains veth, and nothing changes until you enable the new options.