|IPv6 transition mechanisms|
NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. The NAT64 server is the endpoint for at least one IPv4 address and an IPv6 network segment of 32-bits (for instance
64:ff9b::/96, see RFC 6052, RFC 6146). The IPv6 client embeds the IPv4 address it wishes to communicate with using these bits, and sends its packets to the resulting address. The NAT64 server then creates a NAT-mapping between the IPv6 and the IPv4 address, allowing them to communicate.
Principle of operation
Very simplistic NAT64 setup can be thought as a network device (a router) with at least two interfaces. One of these interfaces is connected to an IPv4 network, and another is connected to an IPv6 network. The network is configured in a way that packets from the IPv6 network to the IPv4 network get routed through this router. The router itself performs all the necessary translations needed to transfer packets from the IPv6 network into the IPv4 network, and vice versa.
The translation is not symmetric, as IPv6 address space is a lot larger than IPv4 address space (compare: 2128 for IPv6 and 232 for IPv4), so no one-to-one address mapping is possible. Therefore, in order to be able to perform the translation, NAT64 is required to keep the IPv6 to IPv4 address mapping. Such an address mapping is either statically configured by the system administrator (stateless translation), or (more frequently) is created automatically when the first packet from IPv6 network reaches NAT64 to be translated (stateful). After this address binding is created, packets can flow in both directions.
Stateless translation is appropriate when NAT64 translator is used in front of legacy IPv4-only servers to allow them to be reached by remote IPv6-only clients. Stateful translation is suitable for deployment at the client side or at the service provider, allowing IPv6-only client hosts to reach remote IPv4-only nodes.
In general, NAT64 is designed to be used when the communications are initiated by IPv6 hosts. Some mechanisms (including static address mapping) exist to allow the reverse.
Not everything is accessible with NAT64, such as SIP, WebSocket, Skype, MSN, and sites with IPv4 literals.[a] However, 464XLAT RFC 6877, which uses NAT64, allows for such protocols over IPv6-only connections.
- Ecdysis, a NAT64 gateway, includes DNS64
- TAYGA, a stateless NAT64 implementation for Linux
- Jool, an implementation for Linux of RFC6146 (stateful NAT64), developed by Monterrey Institute of Technology (ITESM) and NIC Mexico
- OpenBSD 5.1 brings a PF packet filter capable of NAT64 
- Microsoft Forefront Unified Access Gateway, a reverse proxy and VPN solution that implements DNS64 and NAT64
- Stateless Network Address Translation 64 on Cisco ASR 1000
- Stateful NAT64 feature on Juniper MX Series 3D Universal Edge router
- Cisco ASA version 9.0 release brings NAT64 and DNS64 
- experimental public NAT64/DNS64 service at LITNET, implemented by Kaunas University of Technology
- Dual stack architecture that recognizes both IPv4 and IPv6 traffic on Fortinet FortiGate® multi-threat security appliances
- Using a dual-stacked web proxy allows IPv6-only clients to access even web pages with IPv4 literals in URLs.
- RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
- Mavrin, Alex. "NAT64 power and limitations". Blog article. Retrieved 6 January 2014.
- "RFC 6877 - 464XLAT: Combination of Stateful and Stateless Translation". Tools.ietf.org. Retrieved 2014-01-31.
- "[Ecdysis-discuss] NAT64 in OpenBSD". Viagenie.ca. Retrieved 2014-01-31.
- Worldwide. "Release Notes for the Cisco ASA Series, 9.0(x) [Cisco ASA 5500-X Series Next-Generation Firewalls] - Cisco Systems". Cisco.com. Retrieved 2014-01-31.