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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه