NAT64 Lab Using Cisco’s ASR and DNS64 (Maybe).

Hello again,

The other day I came across a configuration by Cisco in regard to NAT64.

As you are aware, NAT64 permits IPv6 only networks to access IPv4 networks and vice versa.

Of course, they are not entirely IPv6 only networks since they probably have an IPv4 gateway somewhere allowing them to access IPv4 networks on the Internet.

I decided to do the lab and test it using EVE-NG.

Setup

The original lab is part of the Cisco forums.

I added dynamic mapping and where a DNS64 server will fit in the topology.

Since I did not want to configure a DNS64 server (it can be done of course), I also added a way of showing how DNS64 manipulates IPv4 addresses into IPv6 addresses.

Figure 1. has the topology in use.

Figure 1. Lab Topology.

The lab uses the EVE-NG virtual environment.

It has the following devices:

  • A CSR router 1000 V 16.07.0.1.
  • A 3725 router acting as the IPv6 gateway only to the IPv6 network.
  • A 3725 router acting as the IPv4 gateway.
  • Another 3725 mimicking as an Internet device.
  • A DNS server using BIND.

In this scenario, the CSR router is the NAT64 with two networks terminating on it. The CSR uses the native implementation of NAT64 on it.

As usual, I will only show the relevant parts.

Configurations

NAT64

hostname CSR-100v-R2
!
ipv6 unicast-routing 
!
interface Loopback0
 no ip address
 ipv6 address BB10::1/128
!
interface Loopback1
 ip address 2.2.2.2 255.255.255.255
!
interface GigabitEthernet1
 no ip address
 negotiation auto
 nat64 enable
 ipv6 address 2001::A00:B/128
 ipv6 rip RIP enable
 ipv6 rip RIP default-information only
 no mop enabled
 no mop sysid
!
interface GigabitEthernet2
 ip address 10.0.0.2 255.255.255.0
 negotiation auto
 nat64 enable
 no mop enabled
 no mop sysid
!
interface GigabitEthernet3
 no ip address
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
!
interface GigabitEthernet4
 no ip address
 shutdown
 negotiation auto
 no mop enabled
 no mop sysid
!
router ospf 1
 network 2.2.2.2 0.0.0.0 area 1
 network 10.0.0.0 0.0.0.255 area 0
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip route 0.0.0.0 0.0.0.0 10.0.0.1
!
ipv6 router rip RIP
!
ipv6 access-list nat64-acl
 permit ipv6 host 2001::A00:A any
!
control-plane
!
nat64 prefix stateful 3001::/96
nat64 v4 pool POOL1 10.0.0.5 10.0.0.15
nat64 v6v4 static 2001::A00:C 10.0.0.16
nat64 v6v4 list nat64-acl pool POOL1

IPV6 Only

hostname IPV6-Only-R1
!
ipv6 unicast-routing
ipv6 cef
!
interface Loopback0
 no ip address
 ipv6 address AB00::1/128
 ipv6 rip RIP enable
!
interface Loopback1
 no ip address
 ipv6 address AB01::1/128
 ipv6 rip RIP enable
!
interface Loopback2
 no ip address
 ipv6 address 2001::A00:C/128
 ipv6 rip RIP enable
! 
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001::A00:A/128
 ipv6 rip RIP enable
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
ipv6 router rip RIP

IPv4 Only

hostname IPV4_ONLY_R3
!
ip cef
!
no ip domain lookup
ipv6 unicast-routing
ipv6 cef
!
!
ip ssh version 1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
 ip address 1.1.1.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.10.1.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 1
 network 1.1.1.2 0.0.0.0 area 0
 network 10.0.0.0 0.0.0.255 area 0
!

WAN

hostname WAN
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
memory-size iomem 5
ip cef
!
ip domain name test.com
! 
multilink bundle-name authenticated
username cisco password 0 cisco
archive
 log config
 hidekeys
! 
!
interface FastEthernet0/0
 ip address 10.10.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
ip forward-protocol nd
ip route 10.0.0.0 255.0.0.0 10.10.1.1
!

TESTING

Now that we have the lab setup, let’s test connectivity.

A point to make, the original Cisco setup used a static mapping. While this is fine, a better scenario is to test by using also a dynamic mapping. In this fashion,  you could have several IPv6 addresses map to an IPv4 network.

The mappings could be one-to-one, one-to-many, or many-to-one since NAT64 is just another way of doing NAT.

On R2 (NAT64) issue:

CSR-100v-R2#sh 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::A00:C

 10.0.0.16
 0 0 FALSE

The output above shows that a static mapping is in place.  IPv4 address 10.0.0.16 maps to IPv6 address 2001::A00:C.

You should be able to ping 10.0.0.16 from R3.

IPV4_ONLY_R3#ping 10.0.0.16

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

On R2 issue the following:

CSR-100v-R2#sh nat64 translations

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

illegal --- --- 
 10.0.0.16 2001::a00:c

Total number of translations: 1

As you can see the NAT64 now has a translation for 2001::A00:C, allowing you to connect to it.

You may ask what IPv6 address is used to connect? R3 does not have an IPv6.

Issue the command debug IP ICMP on R3 and debug IPv6 ICMP on R1.

Now on R3 ping 10.0.0.16:

IPV4_ONLY_R3#ping 10.0.0.16

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.16, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/22/28 ms
IPV4_ONLY_R3#
IPV4_ONLY_R3#
IPV4_ONLY_R3#
*Mar 1 03:24:02.875: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1
*Mar 1 03:24:02.899: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1
*Mar 1 03:24:02.919: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1
*Mar 1 03:24:02.943: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1
*Mar 1 03:24:02.963: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1

On R1 you will see:

IPV6-Only-R1#
*Mar 1 01:43:08.035: ICMPv6: Received echo request from 3001::A00:1
*Mar 1 01:43:08.035: ICMPv6: Sending echo reply to 3001::A00:1
*Mar 1 01:43:08.115: ICMPv6: Received echo request from 3001::A00:1
*Mar 1 01:43:08.115: ICMPv6: Sending echo reply to 3001::A00:1
*Mar 1 01:43:08.191: ICMPv6: Received echo request from 3001::A00:1
*Mar 1 01:43:08.191: ICMPv6: Sending echo reply to 3001::A00:1
*Mar 1 01:43:08.263: ICMPv6: Received echo request from 3001::A00:1
*Mar 1 01:43:08.263: ICMPv6: Sending echo reply to 3001::A00:1
*Mar 1 01:43:08.335: ICMPv6: Received echo request from 3001::A00:1
*Mar 1 01:43:08.335: ICMPv6: Sending echo reply to 3001::A00:1
*Mar 1 01:43:54.479: ICMPv6: Received ICMPv6 packet from FE80::5201:FF:FE02:0, type 134

As you can see, when R3 pings 10.0.0.16  the packet changes first using the prefix 3001::1 configured on the NAT64 device. In turn, the  NAT64 device redirects the packet with the new source and pings the original destination.

Now let’s take a look at dynamic mapping.

CSR-100v-R2#show NAT64 mappings dynamic

Dynamic mappings configured: 1

Direction ID ACL
 Pool Flags
 RG ID Mapping ID

v6v4 4 nat64-acl 
 POOL1 0x00000000 (none)
 0 0

This shows you that a dynamic mapping is configured using an access list and POOL1.

CSR-100v-R2#sh ipv6 access-list 
IPv6 access list nat64-acl
 permit ipv6 host 2001::A00:A any sequence 10

CSR-100v-R2#sh nat64 pools 

Pools configured: 1

Protocol HSL ID Name
 Is Single Range
 Ranges

IPv4 4 POOL1
 TRUE (10.0.0.5 - 10.0.0.15)
 10.0.0.5 - 10.0.0.15

Thus, the IPv6 address on R1 is mapped to a pool of addresses (10.0.0.5-10).

Of course, the discerning reader would have noticed that the pool is defined for an  /128 address. Yes, you should have at least a network of the same size as the one you are trying to map.

How do you access an IPV4 address then?

R1 tries to connect to 10.10.1.2 using the FSDN of the device.  It sends a DNS query to the DNS64 server. The DNS server gets an A record as the response of the query. The DNS64 server then converts it to an IPV4.

It uses 3001::10.10.1.2  or 3001::A0A:102 then it sends the record to R1. R1 then connects using that IPv6 address.

The NAT64 device is configured to use the 3001:: for NAT64 conversions, strips the 3001:: part converts the remainder address A0A:102 to 10.10.1.2, and sends the packet.

It also adds a translation using the pool defined. In this case, NAT64 connects to WAN using 10.0.0.6 (2001::A00:A) as the source address.

IPV6-Only-R1#ping 3001::A0A:102

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3001::A0A:102, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/52/64 ms

A DNS64 server will do this conversion automatically if the FQDN resolves only to an A record.

To simulate this conversion, on R2 issue:

CSR-100v-R2#ping 3001::10.10.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3001::A0A:102, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Notice that R2 tried to connect using 3001::A0A:102 which would be the IPv6 address that the DNS64 server would have been given to R1 as a result of the DNS query. Remember the DNS64 server is configured with the same prefix as the NAT64 server will use for NAT64 translations.

This connection is bidirectional. On R3 ping 10.0.0.6, you would get:

IPV4_ONLY_R3#ping 10.0.0.6

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

This is not surprising at all since R2 is announcing 10.0.0.6 as the source IP address (as any NAT device would regardless).

REMARKS

If you look through the configuration, you will notice that R1 uses IPv6 RIP and R3 uses IPv4 OSPF.

The reason is so no static routing is configured explicitly.

On the IPv6 side, RIP is announcing a default route. You do not have to use RIP any other IGP that supports IPv6 would do.

OSPF on the IPv4 side advertises the 10.0.0.0 network.

We also have a default IPv4 route to the Internet on R2, since the WAN router by definition does not take part in any dynamic routing.

CONCLUSIONS

The setup of NAT64 was not as complicated as I thought it would be.

As usual, Cisco is very thorough in its documentation. I was able to dig deep into the different commands to configure pools and observe bidirectional communications.

In a real implementation, you will need a few things:

  • A functional DNS64 server configured accordingly.
  • Your IPv4 router should be a firewall of some sort so you can properly do your static translations to the Internet in addition to your IPv6 network.
  • Above also means that you will be doing double NAT.
  • Finally, your IPv6 servers will need a one-to-one translation to the internal IPv4 address you plan to use if those servers need to be accessed from IPv4 only networks.
  • Above is probably the trickiest part of this since the IPv6 to IPv4 part seems to be straight forward.

I hope you enjoy the lab.

Until we meet again.

Leave a Reply

Your email address will not be published. Required fields are marked *