464XLAT
termIPv4 access across an IPv6-only network by translating twice: statelessly on the device, statefully at the provider.
464XLAT (RFC 6877) keeps IPv4-only applications and IPv4 literals working on IPv6-only networks, notably cellular ones, by pairing a translator on the device (CLAT) with a NAT64 in the network (PLAT). It translates and does not encapsulate: nothing is tunnelled.
The CLAT gives local applications a private IPv4 address and a default route, from the 192.0.0.0/29 range reserved for systems that need IPv4 addresses but emit no IPv4 packets, and translates their packets one to one into IPv6. The PLAT, an ordinary stateful NAT64, translates them back and shares global IPv4 addresses among many clients. IPv4 exists only inside the device.
Most traffic never touches the CLAT. The CLAT translates only when an IPv4 literal or an IPv4-only socket requires it; applications that use names get synthesised AAAA records from DNS64 and go straight to the NAT64, and native IPv6 needs no translation. RFC 9313 cites a cellular deployment where, to the end of 2018, 75% of traffic was IPv6 end to end, 24% went through DNS64 and NAT64, and under 1% used the CLAT as well.
It is not full IPv4. It supports only clients reaching servers with global IPv4 addresses, so IPv4 peer-to-peer and inbound connections do not work. The provider side keeps per-flow state, and where data-retention laws apply each PLAT entry must be logged, as at any carrier-grade NAT.
Also known as: 464 xlat, clat, plat, rfc 6877
Sources
- RFC 6877, 464XLAT: Combination of Stateful and Stateless Translation, April 2013: abstract and sections 1, 2 and 5.2 (read 2026-10-18)
- RFC 7335, IPv4 Service Continuity Prefix, August 2014: section 1 (read 2026-10-18)
- RFC 9313, Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS), October 2022: sections 3.3, 4.4.2, 4.5.2 and 4.7 (read 2026-10-18)