Cisco NAT64 Static Configuration

In this lesson we’ll take a look how to configure NAT64 so that an IPv4 host can communicate with an IPv6 host. Here’s the topology I will use:

On the left side we have R1 where we use IPv4, on the right side we use R3 which only uses IPv6.

R2 in the middle will be configured for static NAT64 so that these two routers can communicate with each other.

NAT64 is a bit more complicated than “regular” NAT that you know from IPv4. When we use IPv4 NAT for internet connectivity then you only need to translate the source address, with NAT64 we have to translate everything.

When we send a packet from R1 to R3, what destination address will we use? R1 only understands IPv4 and R3 only understands IPv6.

To make this work, R1 needs to think it’s talking to an IPv4 address and R3 needs to think it’s talking with an IPv6 address. We’ll need some “mapping” between addresses and protocols on our NAT64 router.

Let’s take a look how it works…

Configuration

I will configure everything from scratch, let’s start with the interfaces:

R1(config)#interface FastEthernet 0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0

R2(config)#interface FastEthernet 0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0

R2(config)#interface FastEthernet 1/0
R2(config-if)#ipv6 address 2001:DB8:2323:2323::2/64

R3(config)#interface FastEthernet 0/0
R3(config-if)#ipv6 address 2001:DB8:2323:2323::3/64

That’s all we need. R2 will require unicast routing or it won’t do any NAT64 at all:

R2(config)#ipv6 unicast-routing

R3 will require a default route to R2, you’ll see why when we configure NAT64:

R3(config)#ipv6 route ::/0 2001:DB8:2323:2323::2

Before we configure NAT64, let’s do a quick test to make sure R2 can reach both routers:

R2#ping 192.168.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms

R2#ping 2001:DB8:2323:2323::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2323:2323::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/2 ms

So far so good, now we can enable NAT64. First we have to enable it on the interfaces:

R2(config)#interface FastEthernet 0/0
R2(config-if)#nat64 enable

R2(config)#interface FastEthernet 1/0
R2(config-if)#nat64 enable 

Once you enable this you will see a syslog message that tells us that a virtual interface has been created:

%LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up

Now we can configure the actual translation rules. We will use a fake IPv4 address that R1 can use as its destination and a fake IPv6 address that R3 can use as its destination.

IANA has allocated prefix 64:FF9B::/96 for NAT64 translations. When R2 receives anything that starts with this prefix then it will be processed by NAT64. We can use this prefix or we can use another one, I’ll show you how to choose your own prefix:

R2(config)#nat64 prefix stateful 3001::/96

Now we can use prefix 3001::/96 for our translation.

Let’s configure the actual translation rule:

R2(config)#nat64 v6v4 static 2001:DB8:2323:2323::3 192.168.12.3

This tells R2 that whenever we receive an IPv4 packet with destination address 192.168.12.3 that it has to be translated and forwarded to 2001:DB8:2323:2323::3. Let’s see if this works…

Verification

Before I try some pings, let’s enable a debug. This allows us to see what source and destination addresses are used:

R1#debug ip icmp 
ICMP packet debugging is on

R3#debug ipv6 icmp 
  ICMP Packet debugging is on

Now let’s send a ping from R1 to our fake IPv4 destination address:

R1#ping 192.168.12.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/5/16 ms

Great it’s working, the debugs tell us what addresses were used:

R1#
ICMP: echo reply rcvd, src 192.168.12.3, dst 192.168.12.1, topology BASE, dscp 0 topoid 0

R1 thinks it received a packet from 192.168.12.3. What about R3?

R3#
ICMPv6: Received echo request, Src=3001::C0A8:C01, Dst=2001:DB8:2323:2323::3
ICMPv6: Sent echo reply, Src=2001:DB8:2323:2323::3, Dst=3001::C0A8:C01

R3 thinks it’s talking with 3001::C0A8:C01. Where did this address come from? The first part looks familiar, that’s the 3001::/96 prefix that we configured. The last part is the IPv4 address of R1 in hexadecimal:

• C0 = 192
• A8 = 168
• C = 12
• 1 = 1

In case you are wondering, this works in both directions:

R3#ping 3001::C0A8:C01
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3001::C0A8:C01, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

We can also use some show commands on R2 to verify things:

R2#show nat64 mappings static  

Static mappings configured: 1

Direction Protocol Address (Port, if any)
   Non-key Address (Port, if any)
   RG ID Mapping ID Is Valid

v6v4      ---      2001:DB8:2323:2323::3
   192.168.12.3
   0     0          FALSE

Above you can see what we have configured. The next show command is a bit more interesting:

R2#show nat64 statistics 
NAT64 Statistics

Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Sessions found: 90
Sessions created: 13
Expired translations: 13
Global Stats:
   Packets translated (IPv4 -> IPv6)
      Stateless: 0
      Stateful: 63
      MAP-T: 0
   Packets translated (IPv6 -> IPv4)
      Stateless: 0
      Stateful: 40
      MAP-T: 0

Interface Statistics
   FastEthernet0/0 (IPv4 configured, IPv6 not configured):
      Packets translated (IPv4 -> IPv6)
         Stateless: 0
         Stateful: 63
         MAP-T: 0
      Packets translated (IPv6 -> IPv4)
         Stateless: 0
         Stateful: 0
         MAP-T: 0
      Packets dropped: 0
   FastEthernet1/0 (IPv4 not configured, IPv6 configured):
      Packets translated (IPv4 -> IPv6)
         Stateless: 0
         Stateful: 0
         MAP-T: 0
      Packets translated (IPv6 -> IPv4)
         Stateless: 0
         Stateful: 40
         MAP-T: 0
      Packets dropped: 10
Dynamic Mapping Statistics
   v6v4
Limit Statistics

The output above shows us how many translations were done and in what direction. The last show command is the most interesting one:

R2#show nat64 translations 

Proto  Original IPv4         Translated IPv4
       Translated IPv6       Original IPv6 
----------------------------------------------------------------------------

---    ---                   ---                                             
       192.168.12.3          2001:db8:2323:2323::3                           
icmp   192.168.12.1:15       [3001::c0a8:c01]:15                             
       192.168.12.3:15       [2001:db8:2323:2323::3]:15                      

Total number of translations: 2

Above you can see the dynamically created 3001::C0A8:C01 address that was created.

Conclusion

NAT64 can be pretty complex and this is one of those “last resort” methods. You should probably always use dual stack and/or tunneling instead of trying to translate entire protocols.

hostname R1
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
 duplex auto
 speed auto
!
end

hostname R2
!
ipv6 unicast-routing
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 negotiation auto
 nat64 enable
!
interface FastEthernet1/0
 no ip address
 negotiation auto
 nat64 enable
 ipv6 address 2001:DB8:2323:2323::2/64
!
nat64 prefix stateful 3001::/96
nat64 v6v4 static 2001:DB8:2323:2323::3 192.168.12.3
!
end

hostname R3
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:DB8:2323:2323::3/64
!         
ipv6 route ::/0 2001:DB8:2323:2323::2
!
end

If you have any questions, feel free to leave a comment!