Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

NAT64/NAT46 with High Performance and Flexibility

Aperta
  • Qualcosa non va?
#126 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@byteocean ci sta già lavorando.

Dal 25/8/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

area/networking kind/roadmap

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
Lingua principale
Shell
Stelle
1
Fork
1
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ironcore-dev/roadmap

Tutte le issue di ironcore-dev/roadmap

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.