Five Migrations Reshaping Infrastructure Teams in 2026

Networking in 2026 isn’t being driven by a single trend — it’s being driven by deadlines. A widely used ingress controller was retired. A major TLS library changed its defaults. A decade-old proxy method finally has production traction. A service mesh replaced its own extensibility API. And IPv4 exhaustion turned from a talking point into an actual migration project at organizations with federal mandates behind them. None of these are speculative — they’re already forcing infrastructure and platform teams to act. Here’s where each one actually stands.

1. Ingress-NGINX Is Retired — Here’s the Real Gateway API Migration Path

The headline claim is accurate, but it’s worth being precise about what actually happened, because the terminology has caused real confusion on migration timelines.

What ended. The community-maintained kubernetes/ingress-nginx controller — governed by Kubernetes SIG Network — hit best-effort-only maintenance in March 2026, and the repository was formally archived and made read-only on March 24, 2026. The retirement was first announced by the Security Response Committee on November 11, 2025, and reinforced in a blunt joint statement from the Kubernetes Steering Committee and Security Response Committee on January 29, 2026, which put the number of affected cloud-native environments at roughly half. The core driver wasn’t a single architectural flaw — it was years of maintainer burnout (the project ran on one or two volunteers) combined with technical debt, most notably the arbitrary NGINX-configuration “snippets” annotations, which the maintainers came to view as an unfixable security liability rather than a feature.

What did not end. Two distinctions matter and are frequently blurred: - The Kubernetes Ingress API itself is not deprecated or being removed — it’s feature-frozen, with active development now happening in Gateway API. - NGINX Ingress Controller (nginxinc/kubernetes-ingress), maintained commercially and as open source by F5/NGINX Inc., is a completely different codebase and is unaffected by this retirement.

Existing ingress-nginx deployments keep running; nothing breaks overnight. What stops is new releases, bugfixes, and — critically — CVE patches. That’s already showing up as a real risk: four high-severity CVEs were disclosed simultaneously on February 2, 2026, and a critical heap buffer overflow (“NGINX Rift,” CVE-2026-42945) followed in May, with no upstream fix coming. In compliance-heavy environments, “EOL software in the L7 request path” is now a routine SOC 2 / PCI-DSS / ISO 27001 audit finding. Some managed platforms (Azure AKS Application Routing, some GKE ingress configurations) have committed to vendor-extended patching only through November 2026 — that’s a bridge, not a fix.

Where Gateway API actually is right now. The original framing of “migrate to Gateway API v1.4” is already out of date. v1.4.0 reached GA on October 6, 2025, adding BackendTLSPolicy and GA TLSRoute. Since then: - v1.5 shipped February 27, 2026 — the biggest release yet, promoting six previously-experimental features (including ListenerSet and full TLSRoute graduation) to the Standard/GA channel, and introducing a release-train model modeled on Kubernetes’ own SIG Release process. - v1.6 is the current release as of mid-2026, with standard and experimental install manifests published at github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/.

The actual migration tool. ingress2gateway, maintained by SIG Network, reached 1.0 on March 20, 2026 — timed deliberately with the EOL. The pre-1.0 tool only understood three ingress-nginx annotations; 1.0 supports 30+ common annotations (CORS, backend TLS, regex matching, path rewrites) and each is backed by controller-level integration tests that compare live runtime behavior, not just YAML shape. It also introduced a pluggable emitter architecture so you can target implementation-specific extensions:

# Install
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0

# Dry-run conversion of everything in a namespace, ingress-nginx annotations
ingress2gateway print --providers ingress-nginx --namespace production > gwapi.yaml

# Target a specific implementation's extensions (e.g. Envoy Gateway)
ingress2gateway print --providers ingress-nginx --emitter envoy-gateway > envoy-gwapi.yaml

The tool will warn on anything it can’t translate faithfully (e.g. nginx.ingress.kubernetes.io/proxy-body-size has no direct Gateway API equivalent) rather than silently dropping behavior — always review its warnings before cutover, and validate in a non-production cluster first. Seven-plus implementations (Cilium, Contour, Envoy Gateway, GKE Gateway, Istio, and others) are already conformant with the current Standard channel, so there’s real vendor choice on the other end of the migration.

2. Post-Quantum TLS Moved From Draft to Default

This one holds up well against the “harvest now, decrypt later” framing — traffic encrypted with classical key exchange today can be captured and stored now, then decrypted retroactively once a cryptographically relevant quantum computer exists. What’s changed is that the fix is no longer experimental plumbing.

OpenSSL 3.5 (released April 2025) was the inflection point: it made a hybrid key-exchange group — combining classical X25519 elliptic-curve Diffie–Hellman with the NIST-standardized ML-KEM-768 post-quantum KEM — the default TLS 1.3 keyshare, not an opt-in flag. The IANA-registered name is X25519MLKEM768 (codepoint 0x11ec); a FIPS-oriented alternative, SecP256r1MLKEM768 (codepoint 0x11eb), pairs ML-KEM-768 with the P-256 curve instead. Because it’s a hybrid, the session stays safe as long as either half holds — a break of ML-KEM or a future break of X25519 alone isn’t enough to compromise the session key. This is the construction specified in the IETF’s draft-ietf-tls-hybrid-design.

The practical concerns for anyone terminating TLS at the edge:

• Overhead is negligible for the exchange itself. Hybrid key exchange runs in the same order of magnitude as classical X25519 — tens of thousands of operations per second on a single core — so CPU cost isn’t the bottleneck.
• Payload size is the real cost. ML-KEM-768 public keys run around 1.2 KB, which increases ClientHello/ServerHello size. If a server’s preferred group requires a key share the client didn’t pre-send, you get a HelloRetryRequest and an extra round trip. Chrome and Firefox avoid this by pre-computing key shares for both X25519MLKEM768 and plain X25519; not every client does. Watch P99 handshake latency after you enable PQC preference — that’s where a regression would show up.
• Adoption is already broad. Chrome (v131, November 2024) and Firefox (v135, February 2025) both support the hybrid scheme; the JDK added it in early-access builds in 2026; and any NGINX or HAProxy build compiled against OpenSSL 3.5+ inherits it.

The compliance pressure is real and dated: the US CNSA 2.0 suite sets a hard deadline for national-security systems, and the EU’s coordinated PQC roadmap targets high-risk sectors on a similar timeline. For a Layer-7 proxy, the practical migration is closer to “recompile against OpenSSL 3.5+ and monitor” than a rip-and-replace project — which is a much smaller lift than the framing of “quantum-proofing your edge” usually implies.

3. MASQUE and CONNECT-UDP: The Standard Is Older Than You’d Think, the Deployments Are New

Worth correcting up front: CONNECT-UDP isn’t an emerging concept — it’s been a finished IETF standard, RFC 9298, since August 2022. What’s actually new in 2026 is production-scale deployment and the extensions being layered on top of it.

MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a family of specs, not one RFC. The dependency chain: RFC 9000 (QUIC transport) → RFC 9221 (unreliable QUIC datagrams) → RFC 9114 (HTTP/3, which retrofits the Extended CONNECT method) → RFC 9297 (HTTP Datagrams and the Capsule Protocol — the actual mechanism for carrying multiplexed data inside an HTTP connection) → RFC 9298 (CONNECT-UDP itself) → RFC 9484 (CONNECT-IP, October 2023, extending the model to full IP tunneling). A client opens an Extended CONNECT request with :protocol: connect-udp, and the proxy relays UDP datagrams to the target, wrapped as HTTP Datagrams on an already-encrypted QUIC connection. Because it rides on port 443 alongside ordinary HTTPS, tunneled traffic — WebRTC, gaming, WireGuard, whatever — is structurally indistinguishable from normal browsing to any middlebox that hasn’t broken TLS.

This isn’t theoretical: MASQUE already underpins Apple’s iCloud Private Relay and Cloudflare’s WARP fleet, and it’s an active option in enterprise Zero Trust products.

Where the standard is still moving: - draft-ietf-masque-connect-udp-listen (currently draft -13, published June 30, 2026) extends CONNECT-UDP to server-initiated UDP — useful for peer-to-peer protocols like WebRTC that CONNECT-UDP alone doesn’t cleanly support, effectively giving MASQUE proxies a path to replace STUN/TURN relays. - draft-ietf-httpbis-connect-tcp proposes a template-driven alternative to classic CONNECT for TCP, addressing gaps like the inability to host multiple distinct proxy services behind one HTTP server. - Open-source implementations are maturing fast: masque-go (built on quic-go) provides both client and proxy support for RFC 9298, and general-purpose tunneling tools like gost have open community requests to add MASQUE support specifically to carry protocols like WireGuard through HTTP/3.

For infrastructure teams, the practical takeaway is less “adopt a bleeding-edge protocol” and more “budget for the fact that enterprise firewalls built around ‘block non-standard UDP ports’ assumptions are becoming less effective by design” — which cuts both ways depending on whether you’re the one building the tunnel or the one trying to see through it.

4. Proxy Extensibility: WasmPlugin Is Being Superseded, Not Just Popularized

This is the one place where the original framing needs the most correction — not because the technology is wrong, but because “hot-swappable Wasm filters” describes 2021–2025, not the current state of the art, and the landscape shifted again very recently.

Istio introduced Wasm extensibility with the WasmPlugin CRD back in Istio 1.12 (2021), replacing the older, fragile EnvoyFilter patches for adding custom logic to the Envoy data plane. The core mechanics are genuinely still accurate: a plugin is a sandboxed WebAssembly module (compiled from Rust, Go/TinyGo, C++, or AssemblyScript against the Proxy-Wasm SDK), distributed via an OCI registry, and Envoy’s Extension Configuration Discovery Service (ECDS) hot-loads a new version without restarting the proxy or dropping connections — bump an OCI tag and Envoy fetches and swaps the module live.

What’s changed is the API surface sitting on top of that mechanism. Istio 1.30 introduced the TrafficExtension API, which unifies Wasm and Lua extensibility under one resource and is now the recommended extensibility mechanism — WasmPlugin still works (Istio internally converts existing WasmPlugin resources into TrafficExtension before generating Envoy config), but new work should target the new API:

apiVersion: extensions.istio.io/v1alpha1
kind: TrafficExtension
metadata:
  name: basic-auth-gateway
spec:
  targetRefs:
    - kind: Gateway
      group: gateway.networking.k8s.io
      name: bookinfo-gateway
  phase: AUTHN
  wasm:
    url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
    pluginConfig:
      basic_auth_rules:
        - prefix: "/productpage"
          request_methods: ["GET", "POST"]

TrafficExtension also formalizes Lua as a first-class, lighter-weight option for simple cases — inline scripts with no module-distribution step, HTTP-only (Layer 7), and a meaningfully smaller memory footprint than Wasm (roughly 20–26 MiB regardless of concurrency, versus Wasm’s ~110–290 MiB depending on load). The practical guidance that falls out of this: reach for Lua for straightforward header manipulation, logging, or conditional routing, and reserve Wasm for extensions that need real testing, versioning, and cross-Envoy-version portability — custom auth flows, complex rate-limiting logic, payload transformation.

One editorial note worth flagging: this topic overlaps substantially with ground already covered in earlier proxy-extensibility and Istio ambient mesh pieces on this blog. The angle that’s genuinely new and hasn’t been published here yet is specifically the TrafficExtension API and its supersession of WasmPlugin — worth leading with that framing rather than reintroducing Wasm-in-proxies as a novel concept.

5. IPv6-Only Kubernetes Clusters: NAT64/DNS64 Goes From Lab Exercise to Production Requirement

The dual-stack fatigue described here is accurate and, in at least one well-documented case, no longer optional. ESnet — the US Department of Energy’s science network — has published its own transition to IPv6-only Kubernetes using Cilium, driven by a federal mandate to phase out IPv4. Their biggest practical obstacle wasn’t the network layer itself — it was hardcoded IPv4 addresses buried in application code that only surfaced once IPv4 was actually gone. They used Cilium’s Multi-pool IPAM to hand each namespace its own /64 prefix, which gave them clean micro-segmentation without needing masquerading.

The core mechanism hasn’t changed conceptually, but tooling has matured:

• NAT64 does stateful translation between IPv6-only pods and the IPv4 internet, using the well-known 64:ff9b::/96 prefix (RFC 6052). Jool remains the most common open-source, production-grade NAT64 kernel module implementation.
• DNS64 synthesizes AAAA records for domains that only publish A records, by prefixing the IPv4 address with the NAT64 prefix — so an IPv6-only client can resolve and reach an IPv4-only service transparently. CoreDNS ships a DNS64 plugin; Unbound and BIND are also common choices.
• A newer option worth watching: kubernetes-sigs/nat64, an experimental project exploring an eBPF-based, in-cluster NAT64 agent — aiming to avoid the operational overhead of standing up a separate external NAT64/DNS64 gateway, which is currently the more common (if clunkier) pattern.

# Example: DNS64-capable resolver as a cluster add-on
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dns64
  namespace: network-services
spec:
  replicas: 3
  selector:
    matchLabels: { app: dns64 }
  template:
    metadata:
      labels: { app: dns64 }
    spec:
      containers:
        - name: unbound
          image: mvance/unbound:latest
          ports:
            - containerPort: 53
              protocol: UDP
            - containerPort: 53
              protocol: TCP

A cloud-specific caveat worth keeping in the article: on EKS, the cluster API endpoint itself is reachable over IPv4 only, even for an otherwise IPv6-only cluster — so “IPv6-only” in practice still means “IPv6-only for pod-to-pod and pod-to-internet traffic,” with a NAT64/DNS64 transition mechanism required at the boundary, not a complete elimination of IPv4 from the stack. That nuance matters for anyone writing a “go IPv6-only” migration guide — the pods can be IPv6-only; the control plane typically can’t be, yet.

The Common Thread

None of these five are hype topics — they’re each backed by a hard external forcing function: a retired controller with a fixed EOL date, a cryptographic default that already shipped, a decade-old RFC finally seeing real deployment, an API replacing its own predecessor inside a major service mesh, and a federal mandate driving a real production migration. That’s a useful filter for what to cover next: not “what’s technically interesting” but “what has a deadline attached to it.”

---

Sources

Ingress-NGINX EOL / Gateway API - Kubernetes Steering + Security Response Committees, joint statement — https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/ - kubernetes/ingress-nginx release/archive history — https://github.com/kubernetes/ingress-nginx/releases - Ingress2Gateway 1.0 announcement — https://kubernetes.io/blog/2026/03/20/ingress2gateway-1-0-release/ - Gateway API v1.4 release notes — https://kubernetes.io/blog/2025/11/06/gateway-api-v1-4/ - Gateway API v1.5 release notes — https://kubernetes.io/blog/2026/04/21/gateway-api-v1-5/ - Gateway API repository (current v1.6.0 status) — https://github.com/kubernetes-sigs/gateway-api - Ingress-NGINX EOL CVE tracking — https://www.herodevs.com/blog-posts/ingress-nginx-end-of-life-2026-migration-and-support

Post-Quantum TLS - OpenSSL Corporation, post-quantum readiness overview — https://openssl-corporation.org/post-quantum.html - OpenSSL 3.5 hybrid PQC defaults — https://faisalyahya.com/access-control/openssl-3-5-entering-the-post-quantum-era/ - Production PQC TLS deployment patterns — https://www.systemshardening.com/articles/network/tls-post-quantum-hybrid-deployment/ - Post-Quantum Cryptography in Kubernetes — https://kubernetes.io/blog/2025/07/18/pqc-in-k8s/

MASQUE / CONNECT-UDP - MASQUE protocol explainer — https://http.dev/masque - MASQUE architecture and RFC dependency chain — https://instatunnel.substack.com/p/masque-the-http3-tunneling-protocol - draft-ietf-masque-connect-udp-listen — https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp-listen/

Proxy Extensibility - Istio TrafficExtension API introduction — https://istio.io/latest/blog/2026/traffic-extension-api/ - Istio extensibility concepts (Wasm vs. Lua) — https://istio.io/latest/docs/concepts/extensibility/ - WasmPlugin reference — https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/

IPv6-Only Clusters / NAT64 - Cilium IPv6-native networking (ESnet case study) — https://cilium.io/use-cases/ipv6/ - kubernetes-sigs/nat64 (eBPF NAT64 agent) — https://github.com/kubernetes-sigs/nat64 - EKS IPv6 cluster networking constraints — https://aws.github.io/aws-eks-best-practices/networking/ipv6/

---

Changelog

Removed: SEO title/target-keyword/hook metadata blocks and the promotional “editorial insight” framing from the source draft — none of that is article content.

Corrected: - “Gateway API v1.4” updated throughout — v1.4 was the state as of the original ingress-nginx EOL announcement, but the API has since moved through v1.5 (Feb 27, 2026) to v1.6 (current). The article now reflects the current version and cites the specific features each release added. - Clarified that ingress-nginx’s EOL was driven primarily by maintainer burnout and accumulated technical debt (specifically the “snippets” annotation mechanism), not a single “architectural security constraint” as the draft implied. - Explicitly distinguished the retired kubernetes/ingress-nginx project from the unaffected, commercially maintained F5/NGINX Inc. nginxinc/kubernetes-ingress controller — these are frequently and incorrectly conflated. - Corrected the MASQUE/CONNECT-UDP framing: CONNECT-UDP has been a finished standard (RFC 9298) since August 2022, not an emerging mechanism — reframed the section around 2026’s actual news, which is deployment scale and active extension drafts, not the base protocol’s novelty. - Added the exact IANA codepoints for the PQC hybrid groups (X25519MLKEM768 = 0x11ec, SecP256r1MLKEM768 = 0x11eb) and named the specific IETF draft (draft-ietf-tls-hybrid-design) defining the hybrid construction.

Flagged for editorial judgment: Section 4 (proxy extensibility / WasmPlugin) overlaps substantially with prior coverage of Proxy-Wasm and WASI-based edge proxies on this blog. Kept in this piece but reframed specifically around Istio 1.30’s TrafficExtension API, which is genuinely new and supersedes WasmPlugin — recommend leading with that angle if this section runs, or cutting it in favor of a sixth, less-covered topic if you’d rather avoid the overlap entirely. Happy to swap in an alternative (e.g., a deeper NAT64/eBPF piece, or a dedicated MASQUE-extension-drafts deep dive) if you want a clean fifth topic instead.

Added: Concrete CLI/YAML examples for ingress2gateway, TrafficExtension, and a DNS64 deployment; specific CVE identifiers and dates for the ingress-nginx EOL security risk; the ESnet/Cilium real-world IPv6-only migration case study; the EKS IPv4-only control-plane caveat.