Four engines, one datapath.

464XLAT is an excellent architecture — for networks that control the endpoint. On fixed-line access it requires a translator inside every subscriber's home. We put the choice where you can actually deploy it.

translation engines,
one binary

config key
switches them

CPE changes
on maps

XDP

in-driver,
before the stack

The question is not which translation is best. It is which one you can actually deploy against the CPE fleet you already have.

Where the required component lives

464XLAT is two halves. The PLAT sits in your network. The CLAT sits in the customer's equipment — and that is the half you do not own.

Coloured boxes mark what must be provisioned and supported for the architecture to work. In 464XLAT one of them is in the subscriber's home. In maps both are in your rack.

The CLAT problem is not technical, it is logistical. Android and iOS ship a CLAT. Residential routers overwhelmingly do not. On a fixed-line PPPoE network, deploying 464XLAT means either replacing the CPE fleet first, or accepting that IPv4-only LAN devices and IPv4-literal applications stop working behind every router that lacks one.

One config key, four architectures

Every engine is compiled into the same XDP datapath and selected by cgnat.engine. Start where your CPE fleet is today; move as it turns over.

Switching architecture is a configuration change, not a platform migration. The decision stays reversible.

What each architecture asks of you

Requirement	464XLAT	maps · CGNAT	mapt
Works with existing CPE	CLAT requiredMobile OSes ship it; residential routers mostly do not.	Any CPENo customer-side change of any kind.	MAP-T requiredOpenWrt and newer vendor CPE.
IPv4-only LAN devices keep working	Via CLAT onlyBehind a CLAT-less router they break.	Yes	Yes
Per-flow state at the border	Stateful PLATNative IPv6 bypasses it — a real advantage.	Stateful	None — algorithmicNo session table to size, scale or reap.
Subscriber logging burden	Per session	Per port blockOne record per block, not per flow.	DeterministicMapping is computable from the address.
DNS64 dependency	OptionalCLAT handles IPv4 literals — 464XLAT's real win.	None	None
Migration granularity	Per CPEGated on the slowest router in the fleet.	ImmediateDeploy network-side, this week.	Per CPE

State carried at the border

Relative per-flow state the operator must hold and log

maps — stateful CGNATper-flow, port-block logged

FULL SESSION TABLE

464XLAT — stateful PLATIPv4-only destinations

NATIVE v6 BYPASSES

mapt — stateless MAP-Tnone

Illustrative of architecture, not a benchmark. The IPv6-bypass share depends on how much of your traffic already reaches IPv6-capable destinations — for most operators that is now the majority of volume.

Where 464XLAT is the right answer. If you control the endpoint — a mobile network, a managed CPE fleet, an enterprise estate — 464XLAT is excellent and we will help you build it. Native IPv6 bypasses translation entirely, so the border holds state only for genuinely IPv4-only destinations. That is less state than any NAT44 design achieves. We ship the provider half: cgnat.engine = nat64 is a full RFC 6146 stateful NAT64 with RFC 6052 prefixes — it is a PLAT. The argument is not that 464XLAT is wrong. It is that on fixed-line access you should not have to bet the migration on what is inside the customer's router.

The parts that decide whether translation survives real traffic

RFC 6145

ICMP translation

ICMPv6 ↔ ICMPv4 including error-payload rewrite. Without it Path MTU Discovery fails silently and large flows stall.

Fragments

Explicit fragment path

Configurable drop_fragments policy rather than undefined behaviour under load.

RFC 6146

Hairpinning

Subscriber-to-subscriber traffic behind one pool address is translated, not dropped.

Checksums

Incremental update

Checksum fixed up across the v6/v4 boundary without a full per-packet recompute.

MTU

The 1280 floor

IPv6 minimum-MTU handling on the translated path, so real-world MSS behaves.

Filtering

EIF · ADF · APDF

Endpoint-independent, address-dependent and address-and-port-dependent filtering, per deployment.

Choosing, given what you actually have

Mixed, uncontrolled residential CPE

maps — the only option that needs nothing from the customer. Deployable now.

You supply the CPE, or it is turning over

mapt — stateless. Removes the session table, the reaper and most of the logging obligation.

IPv6-only access, endpoints you control

nat64 — the PLAT for a 464XLAT or DNS64 deployment. Native IPv6 never touches it.

Not sure yet

maps today. The engine is a config key, so the decision is reversible and does not strand the platform.