NAT-PT versus NAT64, DNS64 server installation, Cisco NAT64 configuration, SLAAC and DHCPv6
IPv6: NAT-PT versus NAT64with Cisco routers
Gianrico FicheraDraft: July 2012 Release 0.9
CopyrightCopyright 2012 Gianrico Fichera, email@example.com
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 SLAACThe 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
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 behaviorLet 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
IPv6 transition strategies: NATISPs 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.
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.
Two-step migration path to IPv6The 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 n