Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

6-to-4 load balancing is not NAT64

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.


  1. Amos Rosenboim29 June, 2011 21:03


    Usually I really like your posts but this time I'll have to disagree with you.
    I've just finished a proof of concept of deploying LSN that also included NAT64 using an F5 viprion platform which went very well.
    The F5 implementation is a true NAT64 with the required DNS64 implementation as well (no need for external DNS64 device).
    The implementation works just as you describe, with the /96 NAT64 prefix and mapping the entire IPv4 address space into the remaining bits of the /96.
    Of course the device also supports the kind of NAT you describe which is more suitable for a server side.
    Just my two cents.


  2. Ivan Pepelnjak01 July, 2011 17:53

    Just found out F5 has NAT64-like solution a few days ago. It gives you almost the same functionality (need to run a few tests) using wildcard servers and iRules. Will definitely blog about that.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.