With the latest software release (12.3.01) the ServerIron ADX, Brocade’s load balancer product, supports the real NAT64 (not 6-to-4 load balancing). Even more, it supports all of the features I would like to see in a NAT64 box plus a few more:
True NAT64 support, mapping the whole IPv4 address space into an IPv6 prefix that can be reached by IPv6 clients. One would truly hope the implementation is conformant with RFC 6146, but the RFC is not mentioned in the documentation and I had no means of checking the actual behavior. DNS64 is not included, but that’s not a major omission as BIND 9.8.0 supports it.
Route injection. The NAT64 prefix can be injected into the IPv6 routing protocol (OSPFv3, IS-IS or BGP) and the prefix for the IPv4 pool can be injected into the IPv4 routing protocol (OSPF, IS-IS or BGP). Obviously you can do the same thing with static routes and route redistribution on almost any device available today, but it’s nice to have the feature integrated into the NAT64 configuration commands.
High-availability operation. Two ADX boxes can work in active-active HA mode, exchanging session information to ensure no client sessions are lost after a box failure. When you configure the route injection, a box with a failed interface can revoke its static route(s) to ensure it’s no longer attracting traffic.
Connection logging. A feature that generates gigabytes of useless information, but also allows service providers to keep address mapping logs ... which might become useful if the law enforcement people drop by equipped with proper papers.
The rest of the NAT64 features show the true load balancing heart of the ADX:
Sticky session support. Multiple sessions from the same IPv6 client could use different IPv4 addresses out of the same IPv4 PAT pool, which might confuse some poorly-written server applications. The session stickiness ensures an IPv6 client always gets the same IPv4 address ... unless, of course, that IPv4 address has run out of port numbers, in which case you can decide to stick the client with another IPv4 address or drop the new session.
Client address insertion. Modification of application data stream is not part of RFC 6146, but like any good load balancer, ADX can insert X-forwarded-for header in HTTP requests.
NAT46 – accessing IPv6 servers from IPv4 clients
While I can’t vouch for ADX’s compliance with RFC 6146 (stateful NAT64), the NAT46 is definitely not the reverse stateless NAT 64 (as described in Section 2.2 of RFC 6144) which is (in my personal opinion) quite useless. The NAT46 part of the NAT64 functionality is a stateless translator, but does not use the algorithmic IPv4-to-IPv6 mapping algorithm defined in RFC 6052, but more pragmatic static 4-to-6 maps.
They even added a dynamic twist to the NAT46 functionality: ADX sends a PTR DNS query for the pre-translation destination IPv4 address to get the target server host name, an AAAA query to get the server’s IPv6 address, and builds a dynamic 4-to-6 mapping entry. Even more, the mapping can be done in advance (prefetching), allowing you to configure IPv4-to-IPv6 server mappings purely in DNS.
If you have hands-on experience with ADX boxes and the new software release, please let me know. Based purely on the documentation, I have to say: great job! (and you know I’m not always sympathetic to Brocade’s experiments).
Entry-level information for enterprise engineers considering IPv6 deployment in their networks, including the role NAT64 can play in making your IPv4 content accessible to IPv6 clients, is summarized in my Enterprise IPv6 – the first steps webinar (buy the recording or a yearly webinar subscription).
We migrated our blog a few days ago, and the commenting functionality is not there yet. In the meantime please find our content on LinkedIn and comment there.