hostname WAN\r\n!\r\nboot-start-marker\r\nboot-end-marker\r\n!\r\nenable password cisco\r\n!\r\nno aaa new-model\r\nmemory-size iomem 5\r\nip cef\r\n!\r\nip domain name test.com\r\n! \r\nmultilink bundle-name authenticated\r\nusername cisco password 0 cisco\r\narchive\r\n log config\r\n hidekeys\r\n! \r\n!\r\ninterface FastEthernet0\/0\r\n ip address 10.10.1.2 255.255.255.0\r\n duplex auto\r\n speed auto\r\n!\r\ninterface FastEthernet0\/1\r\n no ip address\r\n shutdown\r\n duplex auto\r\n speed auto\r\n!\r\nip forward-protocol nd\r\nip route 10.0.0.0 255.0.0.0 10.10.1.1\r\n!<\/pre>\nTESTING<\/h1>\n
Now that we have the lab setup, let’s test connectivity.<\/p>\n
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,\u00a0 you could have several IPv6 addresses map to an IPv4 network.<\/p>\n
The mappings could be one-to-one, one-to-many, or many-to-one since NAT64 is just another way of doing NAT.<\/p>\n
On R2 (NAT64) issue:<\/p>\n
CSR-100v-R2#sh nat64 mappings static\r\n\r\nStatic mappings configured: 1\r\n\r\nDirection Protocol Address (Port, if any)\r\n Non-key Address (Port, if any)\r\n RG ID Mapping ID Is Valid\r\nv6v4 --- 2001::A00:C\r\n\r\n 10.0.0.16\r\n 0 0 FALSE<\/pre>\nThe output above shows that a static mapping is in place.\u00a0 IPv4 address 10.0.0.16 maps to IPv6 address 2001::A00:C.<\/p>\n
You should be able to ping 10.0.0.16 from R3.<\/p>\n
IPV4_ONLY_R3#ping 10.0.0.16\r\n\r\nType escape sequence to abort.\r\nSending 5, 100-byte ICMP Echos to 10.0.0.16, timeout is 2 seconds:\r\n!!!!!\r\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 12\/14\/20 ms<\/pre>\nOn R2 issue the following:<\/p>\n
CSR-100v-R2#sh nat64 translations\r\n\r\nProto Original IPv4 Translated IPv4\r\n Translated IPv6 Original IPv6 \r\n----------------------------------------------------------------------------\r\n\r\nillegal --- --- \r\n 10.0.0.16 2001::a00:c\r\n\r\nTotal number of translations: 1<\/pre>\nAs you can see the NAT64 now has a translation for\u00a02001::A00:C, allowing you to connect to it.<\/p>\n
You may ask what IPv6 address is used to connect? R3 does not have an IPv6.<\/p>\n
Issue the command debug IP ICMP on R3 and debug IPv6 ICMP on R1.<\/p>\n
Now on R3 ping 10.0.0.16:<\/p>\n
IPV4_ONLY_R3#ping 10.0.0.16\r\n\r\nType escape sequence to abort.\r\nSending 5, 100-byte ICMP Echos to 10.0.0.16, timeout is 2 seconds:\r\n!!!!!\r\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 20\/22\/28 ms\r\nIPV4_ONLY_R3#\r\nIPV4_ONLY_R3#\r\nIPV4_ONLY_R3#\r\n*Mar 1 03:24:02.875: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1\r\n*Mar 1 03:24:02.899: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1\r\n*Mar 1 03:24:02.919: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1\r\n*Mar 1 03:24:02.943: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1\r\n*Mar 1 03:24:02.963: ICMP: echo reply rcvd, src 10.0.0.16, dst 10.0.0.1<\/pre>\nOn R1 you will see:<\/p>\n
IPV6-Only-R1#\r\n*Mar 1 01:43:08.035: ICMPv6: Received echo request from 3001::A00:1\r\n*Mar 1 01:43:08.035: ICMPv6: Sending echo reply to 3001::A00:1\r\n*Mar 1 01:43:08.115: ICMPv6: Received echo request from 3001::A00:1\r\n*Mar 1 01:43:08.115: ICMPv6: Sending echo reply to 3001::A00:1\r\n*Mar 1 01:43:08.191: ICMPv6: Received echo request from 3001::A00:1\r\n*Mar 1 01:43:08.191: ICMPv6: Sending echo reply to 3001::A00:1\r\n*Mar 1 01:43:08.263: ICMPv6: Received echo request from 3001::A00:1\r\n*Mar 1 01:43:08.263: ICMPv6: Sending echo reply to 3001::A00:1\r\n*Mar 1 01:43:08.335: ICMPv6: Received echo request from 3001::A00:1\r\n*Mar 1 01:43:08.335: ICMPv6: Sending echo reply to 3001::A00:1\r\n*Mar 1 01:43:54.479: ICMPv6: Received ICMPv6 packet from FE80::5201:FF:FE02:0, type 134<\/pre>\nAs you can see, when R3 pings 10.0.0.16\u00a0 the packet changes first using the prefix 3001::1 configured on the NAT64 device. In turn, the\u00a0 NAT64 device redirects the packet with the new source and pings the original destination.<\/p>\n
Now let’s take a look at dynamic mapping.<\/p>\n
CSR-100v-R2#show NAT64 mappings dynamic\r\n\r\nDynamic mappings configured: 1\r\n\r\nDirection ID ACL\r\n Pool Flags\r\n RG ID Mapping ID\r\n\r\nv6v4 4 nat64-acl \r\n POOL1 0x00000000 (none)\r\n 0 0\r\n\r\nThis shows you that a dynamic mapping is configured using an access list and POOL1.\r\n\r\nCSR-100v-R2#sh ipv6 access-list \r\nIPv6 access list nat64-acl\r\n permit ipv6 host 2001::A00:A any sequence 10\r\n\r\nCSR-100v-R2#sh nat64 pools \r\n\r\nPools configured: 1\r\n\r\nProtocol HSL ID Name\r\n Is Single Range\r\n Ranges\r\n\r\nIPv4 4 POOL1\r\n TRUE (10.0.0.5 - 10.0.0.15)\r\n 10.0.0.5 - 10.0.0.15<\/pre>\nThus, the IPv6 address on R1 is mapped to a pool of addresses (10.0.0.5-10).<\/p>\n
Of course, the discerning reader would have noticed that the pool is defined for an\u00a0 \/128 address. Yes, you should have at least a network of the same size as the one you are trying to map.<\/p>\n
How do you access an IPV4 address then?<\/p>\n
R1 tries to connect to 10.10.1.2 using the FSDN of the device.\u00a0 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.<\/p>\n
It uses 3001::10.10.1.2\u00a0 or 3001::A0A:102 then it sends the record to R1. R1 then connects using that IPv6 address.<\/p>\n
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.<\/p>\n
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.<\/p>\n
IPV6-Only-R1#ping 3001::A0A:102\r\n\r\nType escape sequence to abort.\r\nSending 5, 100-byte ICMP Echos to 3001::A0A:102, timeout is 2 seconds:\r\n!!!!!\r\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 44\/52\/64 ms<\/pre>\nA DNS64 server will do this conversion automatically if the FQDN resolves only to an A record.<\/p>\n
To simulate this conversion, on R2 issue:<\/p>\n
CSR-100v-R2#ping 3001::10.10.1.2\r\nType escape sequence to abort.\r\nSending 5, 100-byte ICMP Echos to 3001::A0A:102, timeout is 2 seconds:\r\n.....\r\nSuccess rate is 0 percent (0\/5)<\/pre>\nNotice 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.<\/p>\n
This connection is bidirectional. On R3 ping 10.0.0.6, you would get:<\/p>\n
IPV4_ONLY_R3#ping 10.0.0.6\r\n\r\nType escape sequence to abort.\r\nSending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds:\r\n!!!!!\r\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 8\/19\/56 ms<\/pre>\nThis is not surprising at all since R2 is announcing 10.0.0.6 as the source IP address (as any NAT device would regardless).<\/p>\n
REMARKS<\/h1>\n
If you look through the configuration, you will notice that R1 uses IPv6 RIP and R3 uses IPv4 OSPF.<\/p>\n
The reason is so no static routing is configured explicitly.<\/p>\n
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.<\/p>\n
OSPF on the IPv4 side advertises the 10.0.0.0 network.<\/p>\n
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.<\/p>\n
CONCLUSIONS<\/h1>\n
The setup of NAT64 was not as complicated as I thought it would be.<\/p>\n
As usual, Cisco is very\u00a0thorough in its documentation. I was able to dig deep into the different commands to configure pools and observe bidirectional communications.<\/p>\n
In a real implementation, you will need a few things:<\/p>\n
![\"\"](\"https:\/\/blog.miguelsarmiento.com\/wp-content\/uploads\/2020\/05\/NAT64.png\")
<\/a>