Every time I write about lack of commercial NAT64 products (yeah, I know Juniper had one for a long time and Brocade just rolled out ADX code), someone tells me that company X has field-proven NAT64 product ... only most of them are really 6-to-4 load balancers. Let’s see what the difference is.

6-to-4 load balancer (usually painted with bright fresh-looking Application Delivery Controller colors) is exactly what you’d imagine it to be: a device that can accept incoming TCP (sometimes also UDP) sessions on a single virtual IPv6 address (of course every LB would support more than one virtual IP address) and distribute them according to whatever algorithm it uses to multiple IPv4 servers. Ideally you could have a mix of IPv4 and IPv6 servers sitting behind the virtual IPv6 address.

Depending on its implementation, the 6-to-4 load balancer might not need to employ NAT64. For example, a TCP relay that terminates the inbound TCP session and opens a completely new TCP session to the backend server is not doing NAT (although it might look like NAT from the outside). Most importantly, a TCP relay does not need to perform quite tricky IP header and ICMP error message translations specified in RFC 6145.

However, regardless of what magic it does, 6-to-4 load balancer still has to pick a new source IPv4 address and associated port number from local address pool – the approach usually called source NAT even when no actual NAT is involved.

You’d usually see 6-to-4 load balancers in data center environments and use them whenever you have to make your IPv4-only content available to IPv6 clients.

NAT64 is a totally different beast. It maps the whole IPv4 Internet into a single IPv6 prefix and performs 6-to-4 address translation between IPv6 clients and any IPv4 server. TCP relays would be prohibitively expensive (you have to terminate two TCP sessions for every client session), so a NAT64 device performs much less CPU-intensive (but still quite tricky) IP header translation and ICMP message translation. A stateful NAT64 device also performs TCP/UDP port mapping like well-known IPv4 NAPT devices.

NAT64 devices could be used instead of 6-to-4 load balancers in data center environments, but a NAT64-only device will not give you the load balancing functionality. You might have to use them in series with load balancers if you’re fortunate enough to be endowed with an ace load balancing device from a visionary vendor that forgot IPv6 exists when designing the hardware.

However, I expect to see dedicated NAT64 devices primarily in the Service Provider environment where they’ll give IPv6-only clients access to the legacy IPv4 content.

More information

Check my NAT64 and DNS64 in 30 minutes, Getting Ready for World IPv6 Day ... in 6 Days and Upcoming Internet Challenges presentations.

The need for rapid IPv6 deployment in Service Provider networks (not that it would be news) is described in my Market Trends in Service Provider Networks (buy a recording) and Upcoming Internet Challenges webinars.

Entry-level information for enterprise engineers considering IPv6 deployment in their networks, including the role NAT64 and 6-to-4 load balancing can play in making your IPv4 content accessible to IPv6 clients, is summarized in my Enterprise IPv6 – the first steps webinar (buy the recording).

Recordings of all three webinars are part of the yearly webinar subscription.