IPv6: NAT-PT versus NAT64

with Cisco routers

Gianrico Fichera
Draft: July 2012 Release 0.9

Copyright
Copyright 2012 Gianrico Fichera, gianrico.fichera@itesys.it

This material is not sponsored by, endorsed by, or affiliated with Cisco Systems, Inc., Cisco, Cisco Systems, and the Cisco Systems logo are trademarks or registered trade marks of Cisco Systems, Inc. or its affiliates. All other trademarks are trademarks of their respective owners.

Thanks to ITESYS srl, the best consulting company ever, for lab facilities and technology. Get in touch with them at http://www.itesys.it

Keywords: nat, nat64, nat444, nat-pt, slaac, dhcpv6, itesys srl, gianrico, cisco, catania, itesys, ipv6, internet

IPv6 and SLAAC

The IPv6 protocol has a feature named Stateless Address Autoconfiguration (SLAAC) specified in RFC2462. What is this feature supposed to do? If you have an IPv6 host, it should be able to get an IPv6 address without the use of a DHCP server. This is a new option that the IPv6 protocol has. With IPv4 you can only choose between a DHCP server and a manual address assignment. To begin with, let us consider a small LAN with a Cisco 1800 series (you are free to use a different platform) with IOS 15.1 as the internet gateway. We would like to use SLAAC in our LAN. Let us start with these IOS commands:
ipv6 dhcp pool mydhcpv6 ...dns-server 2001:XXXX:4860::8888 interface FastEthernet0/0 description --- LAN interface --...ipv6 address 2001:XXXX:C89E::1/64 (1) ...ipv6 enable ...ipv6 nd ns-interval 3000 ...ipv6 nd other-config-flag ...ipv6 nd advertisement-interval ...ipv6 nd ra interval 4 (2) (3) (4) (5) (6)

...ipv6 dhcp server mydhcpv6

(7)

Figure 1 - Cisco DHCPv6 and SLAAC configuration

The FastEthernet0/0 has a static IPv6 address (1). Obviously we need to enable the IPv6 protocol on this interface (2). Every 4 seconds (6) the router will send a multicast packet named router advertisement (RA) in LAN to the IPv6 multicast address FF02::1 (this address indicates all LAN node addresses). Row (5) means that the router sends in a RA field the interval indicated in (6). RA packets also contain fields such as MTU and LAN prefixes. If we enable ICMP debug we can see them as shown in Figure 2.
Apr 15 11:44:26.355: ICMPv6-ND: Request to send RA for FE80::21B:2BFF:FE2C:B3A3 Apr 15 11:44:26.355: ICMPv6-ND: Sending RA from FE80::21B:2BFF:FE2C:B3A3 to FF02::1 on fastethernet0/0 Apr 15 11:44:26.355: ICMPv6-ND: Other stateful configuration (8) Apr 15 11:44:26.355: ICMPv6-ND: MTU = 1500 Apr 15 11:44:26.355: ICMPv6-ND: Interval = 4000 Apr 15 11:44:26.355: ICMPv6-ND: prefix = 2001:XXX:C89E::/64 onlink autoconfig Apr 15 11:44:26.355: ICMPv6-ND: 2592000/604800 (valid/preferred) Figure 2 - SLAAC debug

Row (8) is present because of the configuration in row (4). The explanation of row (4) is that the router sends out an RA packet to tell the attached end hosts how they have to set up their network addresses. In our lab test we want the hosts to use SLAAC. The RA packet contains some flags that describe to the client which method to use: DHCPv6, SLAAC, static. Unfortunately the SLAAC is unable to give the DNS address (this is true unless your host supports RFC6106). This was the cause of being unable to browse the web during the first lab test. In Cisco routers the SLAAC configuration is enabled by default. If a bit named "O bits" is set, it tells the hosts to use both SLAAC and DHCPv6. If this bit is set, the client will use RA for IPv6 configuration address and DCHPv6 for other parameters like the DNS configuration. This is why in our example we have a special DHCPv6 server configuration without an IP pool configured (7). This behavior of DHCP is named stateless DHCPv6 (RFC3736). In RFC3315 we find the specification of the stateful DHCPv6 (that we are not using in our lab test) capable of passing configuration parameters to

hosts as IPv6 addresses. This concept is similar to DHCPv4. Without (7) clients are unable to get a DNS address. In this case you need to manually set set manually a DNS server. In the case of a dual stack host it could have an IPv4 DNS address configured and it will use that for IPv6 too. In fact, without an IPv6 DNS address configured hosts will use IPv4 DNS for AAAA RR requests, if present. Common DNS servers support AAAA records for almost ten years. To disable SLAAC and use only DHCPv6 a line could be aded in the router configuration, as shown in Figure 3.
ipv6 nd prefix 2001:XXXX:C89E::/64 300 300 noautoconfig Figure 3 - How to disable SLAAC for DHCPv6 only use

In this case it is necessary to create a DHCPv6 address pool in the router.

Major operating system and IPv6 behavior

Let us take a look at what happens when this lab configuration is used with different operating systems. Everything works well with Windows 8. It supports SLAAC and DHCPv6 and two DNS servers in a dual-stack configuration can be seen (the command ipconfig /all can be checked). The nslookup command works well with IPv4 and IPv6 domains. With MacOsX Lion 10.7.3, everything also works well, but remember to use ping6 instead of ping. Remember that nslookup does not resolve IPv6 domains if standard command lines are used, as shown in Figure 4. How to use nslookup in an IPv6 envirorment is shown below.
MacBook:~ gian$ nslookup ipv6.cisco.com Server: 2001:4860:4860::8888 Address: 2001:4860:4860::8888#53 Non-authoritative answer: *** Can't find ipv6.cisco.com: No answer If you use manual mode it works: MacBook:~ gian$ nslookup >; set type=AAAA >; ipv6.cisco.com Server: 2001:4860:4860::8888

Address: 2001:4860:4860::8888#53 Non-authoritative answer: ipv6.cisco.com has AAAA address 2001:420:80:1::5 Figure 4 - Mac nslookup behavior in IPv6 environments

Windows XP does not seem to work well with the DHCPv6, which seems to not be supported. Problems may be experienced if using Windows XP without a dual-stack configuration. Windows 7 works as well as Windows 8 with this configuration and the nslookup command works without problems. There is something wrong with iPAD and iPHONE (5.1 iOS). They always wait for an IPv4 address from a DHCPv4 server. The problem is that it is impossible to disable IPv4 in these devices. If they do not have an IPv4 address, they ignore the IPv6 configuration and are unable to connect. However, there is a simple workaround. It involves setting up a manual ip configuration in Wi-Fi for IPv4. In this way the iPAD takes the IPv6 configuration (apps like ipv6 toolkit or ip6config can be used to show the ipv6 configuration) and uses it if there is only IPv6 in the network. These IPv6 web sites can be used for testing: www.ipv6.cisco.com or www.google.com or www.ipv6.apple.com. The web site test-ipv6.com is able to test your PC connectivity. In the case of a

dual-stack configuration, it is possible to reach the maximum score, as shown in Figure 5.

Figure 5 - IPv6 test with dual-stack configuration

10

IPv6 transition strategies: NAT

ISPs are planning to deliver IPv6 services to customers. It would be interesting to know what kind of transition strategy has been chosen for going from IPv4 to IPv6. The first IPv6 specification was published in December, 1995. The document name was RFC1883. In February of 2000, RFC2766 was published that talked about NAT-PT. This method should have been used for connecting the new IPv6 networks with existing IPv4 neworks and permitting bidirectional sessions between them. Seven years later in July of 2007, RFC4966 was published, entitled, "Reason to move NAT-PT to historical status". In April of 2011, RFC6146 was published that talked about a new transition strategy from IPv4 to IPv6 using a different technology named NAT64. The entry level NAT-PT platform was IOS 12.2T with Cisco 2610xm (released in 2003). On November 24, 2010, Cisco released NAT64. Today (June, 2012) only ASR series routers with IOS-XE and CRS series with IOS-XR support NAT64.

11

After seven years with NAT-PT, it seems it is time for a different strategy, one that has been debated for years. NAT64 works only for connections initiated from IPv6 to IPv4, except in the case of static NAT configuration. NAT-PT is bidirectional but this led to some drawbacks that caused it to be discarded. One of the main reasons was the need to introduce a DNS-ALG to make a NAT46 usable. This implied that NAT-PT router had to be on the path of the DNS query (a serious issue for multihoming envirorments such as ISP). Instead, NAT64 is designed to have an external DNS server with a mechanism named DNS64 able to synthesize IPv6 AAAA RR when needed. The good news is that you can put a DNS64 server anywhere in your network. However, NAT64 is not NAT-PT. When an existing IPv4 host needs to set up a session with an IPv6 only host, it is necessary to set up a static association. The only serious issue with NAT64 could be the fact that it requires manual configuration to permit IPv4 networks to reach IPv6 networks due to the absence of the NAT46 function. Someone once said "It's not the quantity but the quality that counts". Therefore it is better to have a solid IPv6 to IPv4 service than a bidirectional restricted IPv4 to IPv6 mechanism. No mistakes are permitted on a worldwide scale migration. So NATPT was deprecated.

12

Two-step migration path to IPv6

The upgrade from IPv4 to IPv6 could be seen as a two step path. In the first phase small IPv6 networks need to adapt to the big IPv4 Internet. IPv4 users cannot be expected to change their ADSL router configuration overnight to reach IPv6 networks. IPv6 only networks, on the other hand, need to be configured properly to enable them to be reached by, and to reach, the existing IPv4 internet. This is done with NAT64. ISP owners with IPv6 addresses who do not want to spend money on Cisco IOS-XE/XR hardware can still give dual-stack access to their new customers, however, they will need NAT64 as soon as they have finished their IPv4 addresses or for customers unable to use dual-stack. It seems that new ISPs with only IPv6 will be obliged to buy an IOS-XE/XR platform. In the second phase there will be a big IPv6 internet with a few IPV4 networks. Do not expect drastic changes overnight. That is a longterm goal and will be a slow process. At that stage something like a better NAT-PT will be useful or in any case a form of NAT46. Realistically we should expect this 5-7 years from now. It is likely that we will still have IPv4 networks for the next 10-15 years.

13

Cisco provides NAT64 only in IOS-XE/XR platforms. What should small ISPs do? Discard Cisco 7200/7600 platforms and buy an ASR1000? How much will IPv6 transition cost? In order to find the correct answers it is necessary to understand the differences between NAT-PT and NAT64. In an unofficial way we can have a "not RFC" NAT64 with DNS64 in every Cisco router by properly configuring NAT-PT. A severe functional limitation of NAT-PT is the absence of CEF support. With CEF, better ALG support and some cosmetic changes, NAT-PT could be useful for transition to IPv6 as NAT64 RFC6146, especially in countries with small ISPs. It is not known if, or when, Cisco will carry out these enhancements.

14

NAT-PT versus NAT64

There are two main different types of NAT44: static and dynamic. There is also PAT. Static NAT is stateless while PAT is stateful: this means that it is necessary for routers to remember translations made in a table. If the IOS release is recent enough, it will have all the NAT-PT commands. Even if NAT-PT was declared obsolete in RFC4966 it is still supported in all recent IOS releases. The NAT46 feature can be deactivated in NAT-PT. DNS-ALG can also be disabled. If NAT46 is removed and DNS-ALG disabled, is it correct to say that what remains is NAT64? The answer is that they are nearly similar, so it could be called NAT64 not RFC 6146 compliant. A DNS64 server needs to be added. In fact without a DNS translator it is not possible to give a working browser service to IPv6 customers. Linux bind can be used as a DNS64 server. Therefore, it is possible to have a solid and working DNS server with DNS64 for free. What consequences are derived for IPv6 customers from having NAT64 in the ISP? Domestic customers are used to having unidirectional internet access because of dynamic IP address assignment and NAT44. With IPv4 in many cases there is a need to ask the provider to have the option to be reached from outside. With NAT64 it is necessary to

15

ask the ISP for external reachability. Advanced users would be well advised to ask for dual-stack. According to RFC4966 an ISP should not use NAT-PT to connect the new IPv6 customer networks to the IPv4 internet. However, for small ISPs or for connecting IPv6 to IPv4 in small offices, or helping small companies to migrate to IPv6, NAT-PT can be useful. RFC4966 declares NAT-PT as "no longer desirable as a transition mechanism" but also that "it is possible that a more limited form of NAT-PT could be defined for use in specific situations". In this lab test a cisco 1841 router with IOS 15.1 is being used so it is not possible to use NAT64 RFC (supported only in carrier-grade Cisco platforms like ASR1000). Let us take a look at the NAT-PT commands available.
r(config)#ipv6 nat ? max-entries Specify maximum number of NAT-PT entries prefix Configure a global NAT-PT prefix service ALG specific translation NATPT translation entry configuration v4v6 v6v4 IPv4 to IPv6 translation IPv6 to IPv4 translation

r(config)#ipv6 nat service ? DNS DNS traffic r(config)#ipv6 nat v4v6 ? pool Configure a IPv6 address pool source Source Address Translation

16

r(config)#ipv6 nat v6v4 ? pool Configure a IPv4 address pool source Source Address Translation

Figure 6 - NAT-PT commands available in IOS

NAT-PT comes with a feature named DNS-ALG that changes DNS zones 'on the fly' by editing DNS records according to the NAT translation. In this way IPv4 hosts can reach any IPv6 host even when IPv4 addresses are dynamically assigned from a pool. Note that this implies that the DNS-ALG needs to operate in the forwarding path. NAT46 is an open issue that will become crucial when IPv6 becomes prevalent over IPv4. The absence of a good NAT46 solution will be a form of incentive to migrate to the IPv6 network for IPv4 only users. NAT64 as RFC6146 does not have a solution to the problem of v4 -> v6 reachability other than 1:1 static stateless NAT association. In order to use the NAT64 subset of NAT-PT, it is necessary to disable DNS-ALG in the Cisco router, as shown in Figure 7.
no ipv6 nat service dns Figure 7 - How to disable DNS-ALG in NAT-PT

17

After this change is NAT-PT now equal to NAT64? No, because NAT-PT has a NAT46 side. This means that a pool of addresses can be dynamically assigned when a request comes from outside (v4) to inside (v6). NAT64 can only have a pool v6v4 for dynamic IP assignment for sessions started from inside IPv6 hosts. This is a key difference between NAT64 and NAT-PT. However, what happens if a v6v4 only pool is configured in NAT-PT? Is that equal to NAT64? If DNS is not used, the answer is yes, but without DNS the network is only useful in a lab. Can DNS64 be used with NAT-PT if we disable DNS ALG and v4v6 dynamic translations? The answer is yes, because DNS64 is independent from NAT64. Therefore: NATPTDNSALG-NAT46 = NAT64 not RFC6146.
ipv6 nat v4v6 <parameters> Figure 8 - Non use of NAT46 side of NAT-PT

This configuration will be a working NAT64. Remember that there are missing features like CEF support or good ALG support. CEF is not supported in NAT-PT. Will there be CEF support for NAT-PT? Cisco says: "Cisco IOS Software Release 12.2(13)T provides a process-switched implementation of the feature. Later revisions of NAT-PT will enable CEF/dCEF switching. The packets that need only the header translations will be processed in CEF/dCEF
18

switching mode. Like the IPv4 NAT, NAT-PT will do all the payload translations in process switching mode" There is a philosophical difference between NATPT and NAT64. NAT-PT is the technique for IPv4 to operate in an IPv6 dominated environment, while NAT64 is meant to make IPv6 operate in an IPv4 dominated internet.

19

20

DNS64 server installation

RFC3596 introduced AAAA DNS records for IPv6 addresses. Recent browsers ask for A and AAAA records when we want to see a web site. This lab test was made with a CentOS 6.0 installation in June, 2012. DNS64 support in bind was introduced with bind 9.8.0 in March, 2011. CentOS 6.2 uses bind 9.7.3 in its distribution. Therefore it is necessary to install it manually to obtain a release with DNS64 support. If not already done, developer tools should be installed in your CentOS:
yum groupinstall Development Tools Figure 9 - DNS64 server installation: prerequisite packages

Bind can be downloaded from ISC web site http://www.isc.org/software/bind. At the time of writing (June, 2012) the latest production release is 9.9.1-P1; Untar and proceed to install bind as shown in Figure 10.
[root@lab]# tar xvfz bind-9.9.1-P1.tar.gz [root@lab]# cd bind-9.9.1-P1 [root@lab]# ./configure;make;make install

21

Figure 10 - Bind installation in CentOS

The binary installation can be found in the /usr/local/sbin folder. The most important configuration file in bind is stored in /etc directory and is called named.conf. Bind should be configured as cache-only name server, with recursive look-up. This is because it is irrelevant to be authoritative in a lab envirorment. The named.conf file will be as follows:
[root@lab]# cat /etc/named.conf options { directory "/tmp"; auth-nxdomain no; listen-on-v6 {any;}; allow-query {any;}; dns64 64:ff9b::/96 { clients {any;}; mapped { any;}; suffix ::; }; }; Figure 11 - Bind named.conf configuration

The meaning of the parameters will be discussed later in this article in more detail. This is now a working basic configuration for a DNS server with DNS64 capability.

22

For beginners with IPv6, remember that there are two firewall services in CentOS. The first one for IPv4 and the second one for IPv6. They are named iptables and ip6tables. The 53 udp/tcp port may need to be manually opened in both of them. In any case, for a lab test, both services can be stopped as shown in Figure 12.
service iptables stop service ip6tables stop Figure 12 - Firewall services and IPv6

Now bind service can be started. For debugging purposes it is better to launch it in debug mode and in foreground mode as shown in Figure 13.
/usr/local/sbin/named -g -d 1 Figure 13 - Starting named in debug mode

The debugging level can be tuned in order to see more or less information based on requirements.

23

DNS64 server test

At this point it is a working DNS64 server. Once bind is started it can be tested by using the dig tool. Get a CLI console on the DNS server and try to resolve localhost using @::1 as name server to query. If it works, then the DNS server is ready.
[root@lab]# dig localhost @::1 ; <<>> DiG 9.9.1-P1 <<>> localhost @::1 ... ;; QUESTION SECTION: ;localhost. ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012060900 1800 900 604800 86400 ;; Query time: 265 msec ;; SERVER: ::1#53(::1) ... Figure 14 - Test bind with IPv6 DNS request IN A

Now use the dig tool to resolve an IPv4 host in an IPv6 only PC host. Remember that the DNS64 server is a dual-stack host in order to be able to reach both IPv4-only or IPv6 DNS servers. The PC host represents an IPv6 only user that has to reach both IPv4 and IPv6 hosts. In this scenario (NAT64) the aim is to give full IPv4 access to IPv6 users

24

without using methods like dual-stack or 6to4 tunnels. The PC DNS configured address is an IPv6 address of the DNS64 server. Therefore, if command tools like dig or dnslookup are used, the system will automatically use this DNS. In this example the query is itesys.it that is an IPv4 only zone. Take a look at Figure 15. Mac$ dig www.itesys.it
; <<>> DiG 9.7.3-P3 <<>> www.itesys.it ... ;; QUESTION SECTION: ;www.itesys.it. ;; ANSWER SECTION: www.itesys.it. itesys.it. itesys.it. 1571 IN A NS NS 82.XX.14.71 dns2.nic.it. dns1.itesys.it. ;; AUTHORITY SECTION: 10571 IN 10571 IN IN A

;; ADDITIONAL SECTION: dns1.itesys.it. 86358 ;; Query time: 0 msec ;; SERVER: 2001:XXX:c89e::10#53(2001:XXX:c89e::10) ... Figure 15 - Bind: IPv4 request in IPv6 envirorment IN A 82.XX.14.70

25

As you can see, although the host is IPv6 only, the query answer contains an IPv4 address. The host is unable to use this data. The reason is that the default setting on the dig tool is IPv4 also in an only IPv6 only envirorment. It is likely that this behavior will change in the next releases. We need to explicitly ask to get AAAA RR to be sure about the IPv6 functionality of our DNS server. Let us see what happens if an AAAA RR is asked for in an IPv4 only DNS zone.
Mac$ dig www.itesys.it aaaa ;; QUESTION SECTION: ;www.itesys.it. ;; ANSWER SECTION: www.itesys.it. itesys.it. itesys.it. 1562 IN AAAA 64:ff9b::5255:e47 10562 10562 IN IN NS NS dns1.itesys.it. dns2.nic.it. ;; AUTHORITY SECTION: IN AAAA

;; SERVER: 2001:XXX:c89e::10#53(2001:XXX:c89e::10) ... Figure 16 - Bind: IPv6 record request

As you can see, the DNS64 mechanism synthesizes an AAAA record in respect to named.conf configuration file. In the samples, the IPv6 address 64:ff9b::5255:e47 is returned. This is because of the absence of an AAAA record in itesys.it zone.

26

Addresses with 64:ff9b::/96 prefix (rfc 6052) are used for automatic IPv4/IPv6 translation. This prefix is named well-know prefix and is not a globally routable prefix. With this latest test we can be sure that the DNS64 server is working well. Notice that the nslookup tool normally uses IPv4 as default also in IPv6 only. Remember to explicitly ask for AAAA RR with the option "-q".
Mac$ nslookup www.itesys.it Server: Address: 2001:XXX:c89e::10 2001:XXX:c89e::10#53

Non-authoritative answer: Name: www.itesys.it Address: 82.XX.14.71 Figure 17 - nslookup and IPv4 query Mac$ nslookup -q=aaaa Server: Address: www.itesys.it

2001:XXX:c89e::10 2001:XXX:c89e::10#53

Non-authoritative answer: www.itesys.it has AAAA address 64:ff9b::5255:e47 Authoritative answers can be found from: itesys.it itesys.it nameserver = dns1.itesys.it. nameserver = dns2.nic.it.

Figure 18 - nslookup and IPv6 query

27

Recent browsers query for A and AAAA DNS records simultaneously as you can see easily with software like wireshark or tcpdump.
05:40:12.745768 IP6 2001:XXX:c89e::3.53932 > 2001:XXX:c89e::10.domain: 4084+ A? sstatic.ak.fbcdn.net. (39) 05:40:12.746025 IP6 2001:XXX:c89e::3.61479 > 2001:XXX:c89e::10.domain: 33464+ AAAA? sstatic.ak.fbcdn.net. (39) Figure 19 - nslookup and IPv4 query

Let us take a better look at the named.conf configuration file.

dns64 IPv6_prefix { [clients {address_match_list };] [mapped {address_match_list };] [exclude {address_match_list };] [suffix IPv6_addr;] [recursive-only (yes|no);] [break-dnssec (yes|no);] }; Figure 20 - named.conf dns64 configuration syntax [root@lab]# cat /etc/named.conf options { directory "/tmp"; auth-nxdomain no; allow-query {any;}; (1) (2) (3) (4)

listen-on-v6 {any;};

28

dns64 64:ff9b::/96 { clients {any;}; mapped { any;}; suffix ::; }; };

(5) (6) (7)

Figure 21 - Bind: named.conf configuration

(1) This is the working directory. Useful when you have zone files. Here it is a caching only nameserver so it is irrelevant; (2) In case the domain referenced in the query does not exist, bind marks the answer with the non-authoritative flag. This is irrelevant in a lab envirorment; (3) Bind listens to all available interfaces. In a production envirorment only the IPv6 address that provides the DNS service should be listened for; (4) These are the IP addresses allowed to query the DNS service. There is no reason to put limits in a lab envirorment; (5) This is the DNS64 configuration. You can see the prefix that the server uses for converting IPv4 addresses to IPv6 addresses in case of absence of AAAA RR in a query answer. As seen before with the query answer for www.itesys.it RR was 64:ff9b::5255:e47, therefore the PC
29

tried to contact the server with the address 64:ff9b::5255:e47. The 64:ff9b::/96 prefix is not routable in the big internet so without any changes, the backbone gateway will discard the packet. If the gateway is configured with NAT64 it will detect this special address translating it to the original IPv4 address. Both sender and destination IPv4 addresses will be translated by NAT64 in accordance with its configuration. (6) These are host IP addresses enabled to use this service; (7) This indicates which IPv4 addresses with A records shall be translated to AAAA records; It is important that recursive queries are allowed because this is a cache-only DNS. In any case they are enabled by default.

[root@localhost network-scripts]# dig www.itesys.it @::1 aaaa

; <<>> DiG 9.9.1-P1 <<>> www.itesys.it @::1 aaaa ... ;; QUESTION SECTION: ;www.itesys.it. ;; ANSWER SECTION: www.itesys.it. itesys.it. itesys.it. 1800 IN AAAA 64:ff9b::5255:e47 10799 IN 10799 IN NS NS dns2.itesys.com. ns1.h4u.it. ;; AUTHORITY SECTION: IN AAAA

;; Query time: 966 msec

30

;; SERVER: ::1#53(::1) ;; WHEN: Sat Jun ;; MSG SIZE 9 10:19:22 2012 rcvd: 121

Figure 22 - dig tool and AAAA query

31

Cisco NAT64 configuration

In this section a working configuration of NAT64 built from a NAT-PT enabled IOS can be seen. This is the most elementary NAT64 configuration. It can be tried on a Cisco 800 series too. It only depends on IOS release. Check on IOS Feature Navigator on the Cisco web site for a detailed list of IOS releases with NAT-PT. DNS64 is useless if used alone. It needs to have a NAT64 device able to recognize the packets with 64:ff9b::/96 prefixes generated by a DNS64 server. The working configuration presented has everything needed to set up IPv6 only hosts and incorporates SLACC, DHCPv6, and NAT64. This means that it is possible to have a working NAT64 configuration on an non IOS-XR platform although with some restrictions. At the time of writing this document, CEF has to be disabled to make the system work. Another restriction is that ALG support is not provided for many protocols. How much of a restriction this really is may be questionable, because many protocols are not programmed with NAT in mind, and in any case, with any technology, there will be some restrictions for customers if NAT is used.

32

! no ip cef no ipv6 cef (1) ip name-server 8.8.8.8 ip name-server 2001:4860:4860::8888 ipv6 nd route-owner ipv6 unicast-routing ! ipv6 dhcp pool miodhcpv6 dns-server 2001:XXX:C89E::2 ! interface Tunnel0 description --- Access to IPv6 Internet --ipv6 address 2001:XXX:1F12:26::2/64 ipv6 enable tunnel source 62.XXX.101.12 tunnel mode ipv6ip tunnel destination 216.XX.84.42 ! interface ATM0 description ! interface FastEthernet 0 description --- Remember to use /64 otherwise you could have a RA ignored from hosts --ip address 192.168.1.249 255.255.255.0 ip nat inside ipv6 address 2001:XXX:C89E::1/64 ipv6 enable ipv6 nd ns-interval 3000 ipv6 nd other-config-flag --- Access to IPv4 Internet --(2)

33

ipv6 nd advertisement-interval ipv6 nd ra interval 4 ipv6 nat ipv6 dhcp server miodhcpv6 ! ip route 0.0.0.0 0.0.0.0 ATM0.1 ipv6 route ::/0 Tunnel0 ipv6 nat v6v4 source list mialista interface atm0.1 overload. (4) ipv6 nat prefix 64:FF9B::/96 v4-mapped aclv4map (5) no ipv6 nat service dns ! ipv6 access-list mialist permit ipv6 2001:XXX:C89E::/64 any ! ipv6 access-list aclv4map permit ipv6 2001:XXX:C89E::/96 64:FF9B::/96 Figure 23 - NAT64 Cisco router configuration (6) (3)

With (1) CEF is disabled. With (2) IPv6 routing is enabled. With (3) NAT-PT is enabled. With (4) NAT64 is configured with overload (stateful NAT64) in a similar way to an ordinary NAT44. Row (5) is very important because it is related to the translation of the destination IPv6 addresses. A destination IPv6 address with prefix 64:FF9B::/96 will receive special treatment and will be translated considering that there is an IPv4 embedded IPv6 address (rfc 6052). The well-know prefix is configured in the DNS64 server that generates this

34

kind of destination address. With (6) NAT-PT DNSALG is disabled. Remember that IPv6 routing could be disabled in your router. Remember to use ipv6 unicast-routing (2).

35

Notes
NAT can now be configured with a pool using these commands:
ipv6 nat v6v4 source list mialista pool GIANRICO overload ipv6 nat v6v4 pool GIANRICO 62.XXX.101.12 62.XXX.101.12 prefix-length 30 Figure 24 - NAT64 with PAT

An error was experienced with the configuration lines above, as shown in Figure 25. Future releases of this document will look at this in more depth. Any comments or help regarding this particular error would be appreciated.
Jun 18 20:58:55.143: IPv6 NAT: Dropping v6tov4 packet Jun 18 20:58:55.143: IPv6-Fwd: Packet dropped by output feature 'NAT_PT' Jun 18 20:58:55.187: IPv6 NAT: Found prefix 64:FF9B::/96 all Figure 25 - NAT64 error

Here is the NAT debug output from the working NAT64 configuration presented in this article.
Jun 18 22:14:06.953: IPV6: source 2001:XXX:C89E::3 (Vlan1) Jun 18 22:14:06.953: dest 64:FF9B::5058:F22C (NVI0)
36

Jun 18 22:14:06.953: traffic class 0, flow 0x0, len 72+14, prot 6, hops 63, forwarding Jun 18 22:14:06.953: IPv6-Fwd: Packet consumed by output feature 'NAT_PT'

Figure 26 - NAT64 debug output

giahouse#show ipv6 nat translations Prot tcp IPv4 source IPv4 destination 62.XXX.101.12,58963 17.172.232.137,443 tcp 62.XXX.101.12,59060 194.242.61.188,80 tcp 62.XXX.101.12,59062 194.242.61.188,80 tcp 62.XXX.101.12,59063 194.242.61.188,80 tcp 62.XXX.101.12,59064 194.242.61.188,80 IPv6 source IPv6 destination 2001:XXX:C89E::3,58963 64:FF9B::11AC:E889,443 2001:XXX:C89E::3,59060 64:FF9B::C2F2:3DBC,80 2001:XXX:C89E::3,59062 64:FF9B::C2F2:3DBC,80 2001:XXX:C89E::3,59063 64:FF9B::C2F2:3DBC,80 2001:XXX:C89E::3,59064 64:FF9B::C2F2:3DBC,80

Figure 27 - NAT64 translation table

IPv6 only hosts behind NAT64 will show IPv4 addresses in the case of IPv4 answers from DNS. As shown in Figure 28 and Figure 29, a host with an IPv6 only network LAN behind NAT64 can return IPv4 addresses on the screen. For example: nslookup or traceroute showed IPv4 addresses also in the IPv6 only host.

37

[root@onlyipv6 ~]# nslookup www.google.com Server: 82.85.XX.70 Non-authoritative answer: www.google.com canonical name = www.l.google.com. Name: www.l.google.com Address: 173.194.35.147 Name: www.l.google.com Address: 173.194.35.148 Name: www.l.google.com Address: 173.194.35.144 Name: www.l.google.com Address: 173.194.35.145 Name: www.l.google.com Address: 173.194.35.146 Figure 28 - Nslookup behind NAT64

[root@mailinglist ~]# traceroute www.itesys.it traceroute to www.itesys.it (82.85.14.71), 30 hops max, 60 byte packets 1 2 192.168.50.1 (192.168.50.1) 3.748 ms 4.411 ms 5.170 ms 71it.itesys.it (82.85.14.71) 1.779 ms 1.573 ms 1.542 ms

Figure 29 - A traceroute output behind NAT64

38

Figure 30 - IPv6 test results if behind NAT64

39

Conclusion
There are other mechanisms that can help in the process of migrating from IPv4 to IPv6. If there is a lack of IPv4 addresses and it is necessary to extend the life of the address space, technologies like NAT444 or CGN (Carrier grade NAT) can be used. Providing dual-stack services without NAT64 can be a good transition strategy and may be costeffective to obtain new addresses with CGN. In addition, these addresses can be used until old existing end users equipment, lacking IPv6 support, ages out of the internet and is replaced.

Copyright 2012 - Gianrico Fichera gianrico@gianrico.com

40