Hands-On Lab: Configuring NAT64 for IPv6-to-IPv4 Translation

This hands-on lab configures stateful NAT64 on a router, allowing an IPv6-only client to reach an IPv4-only destination through automatic address translation, verifying the well-known NAT64 prefix correctly embeds the destination's IPv4 address.

Stateful NAT64 ConfigurationWell-Known NAT64 PrefixIPv6-Only Client IPv4 Access

~3 min read · Updated Sep 26, 2026

Lab Objective

Configure stateful NAT64 on a router bridging an IPv6-only client network and an IPv4-only server network, verify the client can reach the IPv4 server using a synthesized IPv6 address, and confirm the well-known NAT64 prefix correctly encodes the destination's actual IPv4 address.

Lab Purpose

The IPv4 NAT/PAT labs covered earlier in this series translate between different IPv4 address spaces, but say nothing about crossing between address families entirely. NAT64 solves the specific transition problem of an IPv6-only client needing to reach IPv4-only content, a common scenario as networks migrate toward IPv6-only access while much of the internet remains IPv4-reachable.

Lab Topology

IPv6Client (IPv6-only) ---- R1 (NAT64) ---- IPv4Server: 203.0.113.50

R1's IPv6-facing interface: 2001:DB8:K:1::1/64
R1's IPv4-facing interface: 203.0.113.1/30

NAT64 well-known prefix: 64:ff9b::/96

Task 1: Configure Basic Addressing

Configure R1's IPv6-facing and IPv4-facing interfaces.

Task 2: Configure the NAT64 Prefix

Configure R1 to use the well-known NAT64 prefix for translation.

Task 3: Enable NAT64 on the Relevant Interfaces

Mark the IPv6-facing interface as NAT64 inside and the IPv4-facing interface as NAT64 outside.

Task 4: Configure the Client to Reach the Server via a Synthesized Address

Construct the synthesized IPv6 address embedding the server's IPv4 address, and have the client connect to it.

Task 5: Verify Translation and Connectivity

Confirm the connection succeeds and examine the NAT64 translation table.

Solution and Verification

R1(config)# ipv6 unicast-routing
R1(config)# interface gigabitethernet0/0
R1(config-if)# ipv6 address 2001:DB8:K:1::1/64
R1(config-if)# nat64 enable
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.1 255.255.255.252
R1(config-if)# nat64 enable

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

-- 64:ff9b::/96 is the IANA-designated
-- well-known prefix specifically reserved
-- for NAT64 use -- using it (rather than a
-- custom prefix) allows any standard
-- IPv6-only client to construct the
-- synthesized address without needing any
-- special configuration of its own

R1(config)# nat64 v6v4 list NAT64-CLIENTS interface gigabitethernet0/1 overload
R1(config)# ipv6 access-list NAT64-CLIENTS
R1(config-ipv6-acl)# permit ipv6 2001:DB8:K:1::/64 any

-- Constructing the synthesized address:
-- 64:ff9b:: + 203.0.113.50 converted to hex
-- (203=CB, 0=00, 113=71, 50=32)

-- Synthesized address: 64:ff9b::cb00:7132

IPv6Client> ping6 64:ff9b::cb00:7132

!!!!!
Success rate is 100 percent (5/5)
-- The IPv6-only client successfully
-- reaches the IPv4-only server using
-- purely an IPv6 destination address

R1# show nat64 translations

Proto  IPv6 Source          IPv6 Destination        IPv4 Source    IPv4 Destination
icmp   2001:DB8:K:1::10     64:ff9b::cb00:7132       203.0.113.1    203.0.113.50
-- Confirms R1 translated the IPv6 session
-- into a genuine IPv4 session toward the
-- actual server address, with the
-- destination portion of the synthesized
-- IPv6 address correctly decoded back into
-- 203.0.113.50

Key Takeaway

The well-known NAT64 prefix 64:ff9b::/96 embeds an IPv4 address directly within the last 32 bits of a synthesized IPv6 address, following a standardized conversion any NAT64-aware component (including many DNS64 resolvers) can construct or decode without prior coordination — this is precisely what allows an IPv6-only client with no special NAT64 configuration of its own to reach IPv4-only content, provided it can obtain or construct the correctly synthesized address for its intended destination.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue