NAT64/NAT46 with High Performance and Flexibility

Summary

Data centers and edge sites increasingly run IPv6-only underlays, but the internet at large is still overwhelmingly IPv4-only. Operators need a way to let IPv6-only workloads reach IPv4 endpoints without giving every host a routable IPv4 address. Existing NAT64 implementations either run in-kernel per-host (Jool, Tundra-nat64) — which does not scale beyond one machine's pool of ports —or as heavy userspace stacks with high per-packet cost, or cumbersome in configurations.

Using ebpf-nat64, operators can deploy a single XDP-based NAT64 gateway on a data-center router or dedicated VM that translates traffic between the 64:ff9b::/96 prefix and a pool of IPv4 addresses/ports with high performance. With only on-demand configuration features and parameters, it overcomes the configuration complexity.

---

Scope

In Scope

• A stateful NAT64 gateway that translates traffic between an IPv6-only network and the IPv4 internet using the well-known 64:ff9b::/96 prefix.
• Translation coverage for the common transport protocols (TCP, UDP) and ICMP / ICMPv6.
• Deployment as a container on a Linux host acting as a NAT64 gateway (a physical router or a dedicated VM), configurable via a config file or command-line flags.
• Observability through a Prometheus-compatible metrics endpoint.
• Automated testing and CI covering the data-plane translation logic.
• Documentation of common deployment scenarios (emulated router in namespaces, NAT64 VM on a router, migration from an existing NAT64 implementation such as Jool).

Out of Scope

• DNS64 — resolvers advertising 64:ff9b:: AAAA records are assumed to exist upstream.
• Stateful HA / cross-node session replication — a single instance owns its pool.
• Integration with control planes for dynamic pool assignment (BGP EVPN, operator CRDs).
• Deep packet inspection / ALGs (FTP, SIP, etc.) — L7-aware translation is not included.

---

Responsible Areas

---

Contributors

• @byteocean

---

Acceptance Criteria

• A NAT64 gateway is available and can be deployed on a Linux host to translate traffic between an IPv6-only network and the IPv4 internet.
• Clear definition of the scope each instance is responsible for (which interfaces, which IPv4 pool, which protocols) via configurations.
• Operators can control the runtime behavior through configuration (address pool, interfaces, protocols, forwarding mode).
• Operational insight into the running gateway is available through metrics and logs.

---

Action Items

• Assign labels (e.g., area/ironcore-api, kind/design)
• Set milestone (e.g., H1/2025)
• Assign dependent sub-issues in each required area
• Assign an owner to the issue using the GitHub "Assignee" field
• List all contributors in the "Contributors" section above
• Add this issue to the Roadmap project board