NAT64 · stateful RFC 6146 · IPv6-only access reaching the IPv4 internet · one inline XDP program

Engineering Brief · IPv6-Only Access & IPv4 Conservation

Run your access network IPv6-only — and stop buying an IPv4 address for every subscriber

IPv4 is a cost line that grows with your subscriber count. Even a “dual-stack” network still hands out — or shares — an IPv4 address per customer. BNGSOFT NAT64 lets you run the access network IPv6-only and still reach the entire IPv4 internet through one small shared IPv4 pool — the same pool your CGNAT already uses. Fewer public IPv4 addresses, a simpler single-stack access network, and IPv4 space freed for reuse or resale. It runs as a single inline XDP/eBPF program on the same box as CGNAT, QoS, firewall and DDoS protection.

IPv6-only

access network

one stack to run and manage — no IPv4 per subscriber

1 shared pool

reaches all IPv4

the same CGNAT public-IP pool serves every IPv6-only sub

1 program

inline XDP/eBPF

on the box you already run — CGNAT, QoS, firewall, DDoS

RFC 6146

stateful, complete

TCP/UDP · ICMP · PMTUD · filtering · hairpin · fragments

Give subscribers IPv6 only. NAT64 translates their traffic to IPv4 at the edge — so a shrinking, shared IPv4 pool carries a growing IPv6-only customer base to the legacy internet. Your IPv4 bill stops tracking your subscriber count.

The problem: IPv4 is the tax on every new subscriber

Runout is real and IPv4 has a price. Whether you buy or lease, every block is a recurring cost — and classic dual-stack doesn’t escape it: each customer still needs a routable IPv4 identity, so the network carries two address plans, two routing tables, two sets of ACLs, and two things to troubleshoot. You pay for IPv4 and for the complexity of running it everywhere.

Dual-stack everywhere (the status quo)

Two stacks, IPv4 grows with the base

Every subscriber needs an IPv4 address — public, or private behind CGNAT — plus IPv6.
Two address plans, two routing/ACL/monitoring surfaces to run and debug.
IPv4 demand keeps climbing exactly as the resource keeps getting scarcer and pricier.

IPv6-only access + NAT64 (this brief)

One stack; a shared pool bridges to IPv4

Subscribers get IPv6 only — the access network is single-stack and simpler to operate.
NAT64 maps IPv6-only traffic onto a small shared IPv4 pool only when it actually leaves for the IPv4 internet.
As the internet keeps moving to IPv6, native v6 traffic bypasses NAT64 entirely — the bridge shrinks over time.

Where the IPv4 addresses go (conceptual — one shared pool serves the whole IPv6-only base)

Native IPv6 destinations never touch the pool. Only traffic bound for the legacy IPv4 internet is translated — so the pool is sized to concurrent IPv4-bound flows, not to your subscriber count.

How it works — NAT64 + DNS64, end to end

An IPv6-only client wants to reach an IPv4-only service. DNS64 hands the client a synthetic IPv6 address that embeds the IPv4 destination inside a well-known prefix (64:ff9b::/96). The client sends IPv6 to that address; it routes to the BNG, where stateful NAT64 translates it to IPv4 out of the shared pool — and translates the return traffic back — keeping per-flow state so replies find their way home.

One box, one data path. The IPv6-only subscriber never sees IPv4; the IPv4 internet only ever sees a pooled address.

What BNGSOFT NAT64 actually does

Real networks are more than TCP and UDP. NAT64 has to carry the awkward protocols correctly — or things quietly break: large downloads stall, traceroute lies, ping fails, peer-to-peer apps can’t connect. BNGSOFT’s NAT64 translates the full set, in both directions.

TCP & UDP

Stateful translation with per-flow session tracking for the return path.

ICMP echo

ping works — the ICMP Identifier is mapped as the session port, both ways.

PMTUD / ICMP errors

“Fragmentation needed” ↔ “Packet Too Big”, translated with the embedded packet — so large flows don’t black-hole.

Endpoint filtering

RFC 4787 return-traffic filtering (endpoint-independent, address- or address+port-dependent).

Hairpin

Two NAT64 subscribers can reach each other through their pooled addresses (RFC 6146 §3.6).

Fragments

Fragmented datagrams translated across the v6↔v4 boundary with identification tracking.

Shared CGNAT pool

NAT64 draws from the same public-IP pool as CGNAT — one address plan, one thing to size.

Flow logging

Per-translation records for the same compliance/observability path as CGNAT.

Why it’s cost-effective

Cost driver	Dual-stack today	IPv6-only + BNGSOFT NAT64
Public IPv4 per subscriber	One per sub (or CGNAT-shared) — scales with the base	None — a shared pool sized to concurrent IPv4-bound flows
Access-network stacks to run	Two (IPv4 + IPv6): dual routing, ACLs, monitoring	One (IPv6): single address plan and troubleshooting surface
Extra hardware / middlebox	Often a separate CGNAT/NAT64 appliance	None — runs inline on the BNG you already have
Trend over time	IPv4 demand keeps rising as IPv4 gets scarcer	Native IPv6 bypasses NAT64 — the translated share shrinks
IPv4 you already hold	Locked to per-subscriber assignment	Consolidated into a pool — the surplus is freed to reuse or lease out

The strategic shape: NAT64 turns IPv4 from a per-subscriber cost into a per-flow, shared one — and puts you on the IPv6 side of the transition, where the industry is already heading. The IPv4 you free up is an asset, not a growing liability.

Built for the data path — not bolted on

NAT64 lives in the same XDP/eBPF fast path as everything else on a BNGSOFT BNG. It is a single translation program that handles both directions and branches on IP version — deliberately built to minimise tail-calls, because every extra hop on a per-packet path is latency. The same box does CGNAT, QoS/shaping, firewall, and DDoS protection on the same packet — no extra appliance, no traffic hair-pinned out to a middlebox and back.

One data plane

NAT64 + CGNAT + QoS + firewall

The subscriber’s packet is classified, policed, translated and forwarded in one pass on one box.

Engine-selected

A config switch, not a rebuild

NAT64 is chosen per box as the translation engine; the shared pool and tooling are the ones your operators already know.

Standards-based

RFC 6146 · 6052 · 7915 · DNS64

Interoperates with standard IPv6-only clients and DNS64 resolvers — no proprietary client software.

“The cheapest IPv4 address is the one you never had to assign. NAT64 lets the access network be the thing it’s becoming anyway — IPv6 — while a shared pool quietly handles what’s left of the IPv4 world.”— BNGSOFT engineering

The honest state of play packet-proven · in bring-up

NAT64 is implemented and packet-proven in the lab: the full translation set above — TCP/UDP, ICMP echo, PMTUD and ICMP-error handling both directions, endpoint filtering, hairpin and fragments — passes end-to-end round-trip tests on a lab node. It is selected behind an explicit engine switch and is in bring-up validation, not yet a general-availability production default.

What is real today: the architecture, the complete RFC 6146 translation feature set, and the shared-pool integration with the existing CGNAT. What is next: at-scale soak with real IPv6-only subscribers and a production DNS64 resolver — DNS64 is a standard, separate component and part of the deployment design we’ll plan with you.

Want the deep dive? We’ll walk your team through the translation path, the addressing plan, the DNS64 design, and a staged migration from dual-stack — on a node running real traffic.

Sources & honest framing: This is an engineering brief, not a benchmark report, and no throughput, latency, memory, or session-count figures are claimed. BNGSOFT NAT64 implements stateful NAT64 per RFC 6146 with RFC 6052 addressing and RFC 7915 (SIIT) header translation, as a single inline XDP/eBPF program that handles both directions and shares the CGNAT public-IP pool; the feature set described (TCP/UDP, ICMP echo, PMTUD / ICMP-error translation both directions with embedded-packet rewrite, RFC 4787 EIF/ADF/APDF endpoint filtering, hairpin, and fragment handling) is implemented and validated with synthetic end-to-end round-trip packet tests on a lab node. NAT64 is selected behind an explicit engine configuration switch and is in bring-up validation, not general availability; the map-based CGNAT engine remains the shipping production default. DNS64 is a standard, separate component required for the IPv6-only-client use case and is part of deployment design, not part of the BNG data plane described here. Diagrams are conceptual illustrations of the architecture, not measured results, and address-count depictions are schematic. Related per-topic briefs — CGNAT, CGNAT Arena Engine, Edge DDoS Protection, Flow Intelligence — are available alongside this guide.