How to Implement NAT64 on Cisco Routers: IPv6 to IPv4 Translation Configuration

There’s a real, practical problem NAT64 solves: an IPv6-only host needs to talk to an IPv4-only resource, and there’s no dual-stack path between them. Rather than forcing dual-stack everywhere forever, NAT64 lets you translate IPv6 traffic into IPv4 traffic (and back) at a translation boundary. This guide covers how NAT64 works conceptually and how to configure it on Cisco IOS/IOS-XE routers, including stateful and stateless variants, DNS64 pairing, and troubleshooting.

Why NAT64 Exists

As IPv6 adoption grows, more networks are moving toward IPv6-only access layers to reduce addressing complexity and operational overhead. But the internet still has a huge amount of IPv4-only content and infrastructure. NAT64 bridges that gap: an IPv6-only client sends a packet to a specially-crafted IPv6 address that represents an IPv4 destination, the NAT64 router translates it into a real IPv4 packet, and the response is translated back.

This is fundamentally different from NAT44 (traditional IPv4 NAT) because it’s not just port/address translation within the same address family — it’s translating between two different protocols with different header formats, entirely different address lengths, and different checksum handling.

NAT64 Variants

• Stateful NAT64 — maintains per-session state, similar to how NAT44/PAT works today. Supports many-to-one translation (many IPv6 clients sharing a pool of IPv4 addresses), which is the most common real-world deployment.
• Stateless NAT64 — performs a 1:1 algorithmic mapping between IPv6 and IPv4 addresses with no session state maintained. Requires a specific addressing scheme and is used in more predictable, often data-center-internal scenarios.

Most enterprise and service provider deployments use stateful NAT64, so this guide focuses primarily there, with stateless covered for completeness.

How Stateful NAT64 Works

1. An IPv6-only client wants to reach an IPv4 destination, e.g., 93.184.216.34.
2. Via DNS64 (paired with NAT64), the client receives a synthesized AAAA record embedding the IPv4 address inside a special IPv6 prefix, e.g., 64:ff9b::93.184.216.34 (using the well-known NAT64 prefix 64:ff9b::/96).
3. The client sends traffic to that synthesized IPv6 address.
4. The NAT64 router recognizes the well-known (or configured) prefix, strips the embedded IPv4 address, and translates the packet to a real IPv4 packet, using an address from its NAT64 IPv4 pool as the source.
5. Return traffic follows the reverse translation using the maintained session state.

Step 1: Enable IPv6 Routing and Assign Addressing

Router(config)# ipv6 unicast-routing
Router(config)# interface GigabitEthernet0/0
Router(config-if)# description IPv6-ONLY-CLIENT-SIDE
Router(config-if)# ipv6 address 2001:db8:1::1/64
Router(config-if)# no shutdown

Router(config)# interface GigabitEthernet0/1
Router(config-if)# description IPV4-SIDE
Router(config-if)# ip address 203.0.113.1 255.255.255.0
Router(config-if)# no shutdown

Step 2: Define the NAT64 Prefix

Using the well-known NAT64 prefix (recommended for standard deployments):

Router(config)# nat64 prefix stateful 64:ff9b::/96

If you need a custom NAT64 prefix (for example, to avoid ambiguity with existing routing), define your own instead:

Router(config)# nat64 prefix stateful 2001:db8:64:ff9b::/96

Step 3: Configure the Stateful IPv4 Pool

Router(config)# nat64 v4 pool NAT64-POOL 203.0.113.10 203.0.113.20

This pool provides the IPv4 addresses used as translated sources for outbound sessions from IPv6 clients.

Step 4: Enable NAT64 on Interfaces

Router(config)# interface GigabitEthernet0/0
Router(config-if)# nat64 enable

Router(config)# interface GigabitEthernet0/1
Router(config-if)# nat64 enable

Step 5: Configure Stateful Translation Rule

Router(config)# nat64 v6v4 list NAT64-ACL pool NAT64-POOL overload

Where NAT64-ACL defines which IPv6 sources are eligible for translation:

Router(config)# ipv6 access-list NAT64-ACL
Router(config-ipv6-acl)# permit ipv6 2001:db8:1::/64 any

The overload keyword enables PAT-style port translation so multiple IPv6 clients can share the same pooled IPv4 addresses — functionally identical in concept to IPv4 PAT.

Full Configuration Example

ipv6 unicast-routing
!
interface GigabitEthernet0/0
 description IPv6 client segment
 ipv6 address 2001:db8:1::1/64
 nat64 enable
 no shutdown
!
interface GigabitEthernet0/1
 description IPv4 uplink
 ip address 203.0.113.1 255.255.255.0
 nat64 enable
 no shutdown
!
ipv6 access-list NAT64-ACL
 permit ipv6 2001:db8:1::/64 any
!
nat64 prefix stateful 64:ff9b::/96
nat64 v4 pool NAT64-POOL 203.0.113.10 203.0.113.20
nat64 v6v4 list NAT64-ACL pool NAT64-POOL overload

Pairing NAT64 with DNS64

NAT64 alone doesn’t help clients discover which IPv6 address to use for a given IPv4 destination — that’s DNS64’s job. DNS64 synthesizes AAAA records for domains that only have A records, embedding the IPv4 address inside the NAT64 prefix.

On IOS-XE devices supporting it, or more commonly via an external DNS64 resolver (such as BIND or Unbound configured for DNS64, or many enterprises use cloud-based recursive resolvers with DNS64 support):

Router(config)# ipv6 access-list DNS64-ACL
Router(config-ipv6-acl)# permit ipv6 any any

Router(config)# ipv6 dns view-list DNS64-VIEW
Router(config)# dns64 mapping DNS64-MAP

In practice, many enterprise NAT64 deployments delegate DNS64 to a dedicated DNS server pair rather than running DNS64 on the router itself, since dedicated DNS platforms typically offer better performance and easier maintenance for this function. Point client DHCPv6/RA DNS options at the DNS64-capable resolver.

Stateless NAT64 (Brief)

Stateless NAT64 requires a fixed, algorithmic address mapping and no session table, useful in data center or service provider scenarios needing predictable, symmetric translation:

Router(config)# nat64 prefix stateless 2001:db8:64::/96
Router(config)# interface GigabitEthernet0/0
Router(config-if)# nat64 enable

Stateless NAT64 typically requires IPv4-embedded IPv6 addresses to already be assigned to hosts directly, making it less common outside specific data center or telecom deployments compared to stateful NAT64.

Verification Commands

Router# show nat64 translations
Router# show nat64 statistics
Router# show nat64 prefix stateful

Sample output:

Router# show nat64 translations
Proto  IPv6 Source                    IPv4 Source     IPv6 Destination                     IPv4 Destination   Ports
TCP    2001:DB8:1::100:53211          203.0.113.10:53211  64:FF9B::5DB8:D822                93.184.216.34    443/443

Router# show nat64 statistics
NAT64 Statistics
 Total active translations: 42
 Total translations created: 5109
 Total translations expired: 5067
 Dropped packets: 12

Common Configuration Mistakes

• Forgetting nat64 enable on both interfaces — translation requires it on both the IPv6-facing and IPv4-facing interfaces, not just one side.
• Not scoping the IPv6 ACL tightly enough, resulting in unintended traffic attempting translation and consuming pool resources.
• Running out of pool addresses/ports under overload — monitor show nat64 statistics for exhaustion signs under heavy client counts.
• Deploying NAT64 without DNS64, leaving clients with no way to discover the synthesized IPv6 addresses in the first place — the two almost always need to be deployed together.
• Assuming NAT64 handles IPv4-embedded literal addresses in application payloads — like traditional NAT, NAT64 does not fix up application-layer references to IP addresses (e.g., FTP’s PORT command, SIP payloads) without additional ALG support, which has limited coverage on NAT64 platforms.

Best Practices

1. Use the well-known 64:ff9b::/96 prefix unless you have a specific routing reason to use a custom prefix — it maximizes compatibility with off-the-shelf DNS64 resolvers and clients.
2. Size the IPv4 pool based on expected concurrent session counts, accounting for PAT overload ratios, similar to capacity planning for NAT44/PAT.
3. Monitor show nat64 statistics regularly as part of standard health checks, especially translation drops and pool exhaustion.
4. Pair with a dedicated, redundant DNS64 resolver pair rather than a single point of failure.
5. Scope IPv6 ACLs for translation eligibility tightly to the specific subnets that legitimately need IPv4 reachability, reducing unnecessary load on the NAT64 process.

Troubleshooting Checklist

• Confirm nat64 enable is present on both interfaces.
• Confirm the IPv6 client actually received a synthesized AAAA record (nslookup/dig AAAA on the client, checking for a 64:ff9b:: or custom-prefix response).
• Check show nat64 translations for an active session matching the client’s traffic.
• Check show nat64 statistics for drops or pool exhaustion.
• Validate basic IPv4 reachability from the router’s IPv4-side interface to the actual destination, ruling out non-NAT64 connectivity issues.
• If DNS resolution works but connections fail, suspect ACL scoping or pool exhaustion rather than DNS64.

FAQs

Is NAT64 a permanent solution or a transition mechanism? It’s officially a transition mechanism intended to bridge IPv6-only networks to the still-substantial IPv4 internet, though many networks run it long-term as a practical necessity.

Do I need DNS64 if all my clients use literal IPv4-embedded IPv6 addresses? No — if clients or applications already target IPv4-embedded IPv6 addresses directly (common in some stateless or data center scenarios), DNS64 isn’t required. Most general-purpose client environments do need DNS64, however.

Can NAT64 handle UDP as well as TCP? Yes, stateful NAT64 supports both TCP and UDP session translation, along with ICMP translation between ICMPv6 and ICMPv4.

Does NAT64 work with IPsec or encrypted traffic? Standard end-to-end IPsec generally breaks with any form of NAT, including NAT64, since payload integrity checks or encryption prevent the necessary header/address rewriting. Plan encrypted traffic paths around this limitation.

What administrative distance or routing considerations apply to NAT64? NAT64 doesn’t participate in routing decisions directly — it operates on the forwarding path after routing has already determined the packet should go through the NAT64-enabled interfaces. Standard IPv6 and IPv4 routing configuration still applies independently on each side.

Summary

NAT64 is the practical bridge that lets IPv6-only clients reach the still-large IPv4 internet without requiring dual-stack everywhere. Configuring it on a Cisco router means defining a NAT64 prefix, an IPv4 pool, enabling translation on both interfaces, and scoping which IPv6 sources are eligible — and, critically, pairing it with DNS64 so clients actually know which synthesized addresses to use. Done well, NAT64 lets an organization simplify its access-layer addressing to IPv6-only while preserving full reachability to the legacy IPv4 internet during the transition period.

References

• Configuring NAT64: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-16/nat-xe-16-book/iadnat-addr-consv.html
• IPv6 Transition Technologies: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/xe-16/ip6b-xe-16-book/ip6-nat64-xe.html
• RFC 6146 – Stateful NAT64: https://datatracker.ietf.org/doc/html/rfc6146