NAT64
Last updated
Last updated
As the world runs out of usable public IPv4 addresses, clients are increasingly being assigned IPv6 addresses. IPv6-only clients cannot natively communicate with IPv4-only resources. NAT64 is a solution to this problem. In NAT64, an IPv6-only client is NATed to a public IPv4 address in order to access IPv4 services.
In my opinion, NAT64 is much better than CGNAT (NAT444), because the service provider is giving the customer a public IPv6 IP address which allows the customer to host services on the IPv6 internet. With CGNAT, a customer is behind a NAT address so there is no way for them to natively host services to allow others on the public internet to connect to them. NAT64 is similar to doing CGNAT but only when necessary (when accessing an IPv4-only service).
NAT64 is almost always stateful, meaning that multiple IPv6 addresses map to a single IPv4 address. Very rarely would you see stateless NAT64, in which a single IPv6 address maps to a single IPv4 address. But you can configure either stateless or stateful NAT64. If you were to do stateless NAT64, it would make much more sense to just dual-stack the client.
Stateful NAT uses port overloading to allow multiple clients to use the same IPv4 address. This means the router must keep state on each NAT translation that is made, so that the reverse traffic can be mapped back to the IPv6 address based on the IPv4 destination port.
NAT64 requires a DNS64 server. This special DNS server, upon receiveing an AAAA query from a client, will first attempt to locate an AAAA record. If none is available the DNS64 server will obtain the A record. However the IPv6-only client cannot accept the A record, as the client is not IPv4-aware. So the DNS64 server maps the A record to an IPv6 address and returns this as the AAAA answer.
The IPv6 address is constructed by the DNS64 server by using a preconfigured IPv6 prefix, and then mapping the IPv4 address to the last 32 bits of the IPv6 address. The client is not aware that the IPv6 address is actually a special NAT64 address. The client simply delivers traffic to this address as if it were a normal IPv6 destiantion address. The NAT64 router matches destination traffic based on the special NAT64 prefix, and translates the IPv6 destination to the IPv4 address by using the last 32 bits of the IPv6 address as the translated IPv4 address. In this way, the DNS64 server and NAT64 work together to enable the IPv6 client to speak to IPv4-only resources.
The NAT64 prefix used by the DNS64 server and NAT64 router can be configurable, or you can use the well-known prefix of 64:FF9B::/96. You can also configure a /32, /40, /48, /56, or /64 prefix for the NAT64 prefix if desired.
We will use the following topology to explore NAT64:
Here are the startup configs. IPv4/v6 addressing and routing is configured. I used BGP to exchange v4 and v6 routes between the two “ISPs.” NAT64-Router is AS 200 and R1 is AS 100.
Currently the client has native accessibility to the IPv6-Server but not the IPv4-Server. Let’s setup NAT64 on the NAT64-Router. We’ll use the prefix 2001:db8:100:100::/96 to match traffic that should be destination NATed to an IPv4 address. In real world this would probably be a prefix that we (the ISP) own, or you would use the well-known prefix 64:FF9B::/96. Notice that a /96 cleanly fits the 32 bits of the IPv4 destination address in the host portion of the IPv6 destination address.
In addition to the v6 to v4 destination NAT, we need to source NAT the client v6 address to a v4 address. The router won’t let us use an existing address that is used by an interface for this, so we will use an address from 100.1.3.0/24 which we will pretend this ISP owns.
Here is a summary of the configuration steps:
Enable nat64 on both the inside and outside interfaces with nat64 enable
Create an IPv6 ACL to match the source IPv6 addresses that the router will preform NAT64 for.
Define the NAT64 prefix. Destination traffic matching this prefix will have the IPv4 address “auto-obtained” from the IPv6 address and used for the destination NAT.
Create a pool for the range of v4 addresses to use when source NATing the v6 client. This cannot be an address on the router itself.
Associate the ACL with the pool using the command nat64 v6v4 acl pool pool overload
To test this, we need to manually convert the IPv4-Server address to hex, so that we can concatenate it with the NAT64 prefix. Normally you would have a DNS64 do this task automatically, and it would happen when the client does a DNS request for an AAAA record that is for an IPv4-only resource.
100.1.2.1 in hex is 0x64010201. So we will use the destination IPv6 address of 2001:db8:100:100::6401:0201 to test reachability.
As an exercise, fill in the blanks below to test your understanding of the NATs that are taking place:
Original Source Address = 2001:db8:1::1
Original Destination Address = 2001:db8:100:100::6401:0201
Modified Source Address = _______________
Modified Destination Address = _______________
The answers are:
Modified Source Address = 100.1.3.1
Modified Destination Address = 100.1.2.1
Examine the nat64 translations on the NAT64-Router:
The output of this show command may be a little tricky to read at first. 2001:db8:100:100::6401:201 is the “translated IPv4 address” because the IPv4 address is translated into this IPv6 address by the DNS64 server (typically). The “original IPv4 address” is 100.1.2.1, which the DNS64 server would have obtained from the A record.
The “original IPv6 address” is a little easier to understand - it is the original source IP of the host, in our case 2001:db8:1::2. The “translated IPv6 address” is the IPv4 address that the host is source NATed to, which is 100.1.3.1.
There are some other show commands you can use to verify NAT64:
To drive home the point that IPv6 services still work natively, you can enable telnet on the client and telnet to the client from the IPv6-Server. You would not be able to do this with a client behind CGNAT.
For more practice, you can configure NAT64 on R1 so that the IPv6-Server can access the IPv4-Server as well.
Try it on your own first, and then scroll down to see the configuration if you get stuck.
NAT64 is a stateful mechanism used to allow IPv6-only clients access to IPv4-only resources. This allows a service provider to serve customers without allocating scarce IPv4 address space.
A DNS64 server synthesizes an A record answer into an AAAA answer, concatenating the defined NAT64 prefix with the IPv4 address found in the A record.
The client sends traffic towards this synthesized IPv6 address, which is routed to the NAT64 router. This router source NATs the client to a shared public IPv4 address, and translates the destination IPv6 address to the corresponding IPv4 address. Return traffic is translated in reverse based on the destination port.
NAT64 is a useful IPv6 transition mechanism. As IPv4 is phased out, clients will gradually rely on the DNS64 server less and less. When IPv4 is finally gone, you simply decommision the DNS64 and NAT64 appliances.
