Sie sind auf Seite 1von 40

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

2
3
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 (2)
...ipv6 nd ns-interval 3000 (3)
...ipv6 nd other-config-flag (4)
...ipv6 nd advertisement-interval (5)
...ipv6 nd ra interval 4 (6)

4
...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

5
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

6
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 no-


autoconfig

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.

7
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

8
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

9
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 NAT-
PT 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 long-
term 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 NAT-
PT translation entry configuration
v4v6 IPv4 to IPv6 translation
v6v4 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: NATPT-
DNSALG-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 NAT-


PT 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. IN A

;; 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

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. IN A
;; ANSWER SECTION:
www.itesys.it. 1571 IN A 82.XX.14.71
;; AUTHORITY SECTION:
itesys.it. 10571 IN NS dns2.nic.it.
itesys.it. 10571 IN NS dns1.itesys.it.

;; ADDITIONAL SECTION:
dns1.itesys.it. 86358 IN A 82.XX.14.70
;; Query time: 0 msec
;; SERVER:
2001:XXX:c89e::10#53(2001:XXX:c89e::10)
...

Figure 15 - Bind: IPv4 request in IPv6 envirorment

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. IN AAAA
;; ANSWER SECTION:
www.itesys.it. 1562 IN AAAA 64:ff9b::5255:e47
;; AUTHORITY SECTION:
itesys.it. 10562 IN NS dns1.itesys.it.
itesys.it. 10562 IN NS dns2.nic.it.

;; 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: 2001:XXX:c89e::10
Address: 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 www.itesys.it


Server: 2001:XXX:c89e::10
Address: 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 nameserver = dns1.itesys.it.
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? s-
static.ak.fbcdn.net. (39)
05:40:12.746025 IP6 2001:XXX:c89e::3.61479 >
2001:XXX:c89e::10.domain: 33464+ AAAA? s-
static.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"; (1)
auth-nxdomain no; (2)
listen-on-v6 {any;}; (3)
allow-query {any;}; (4)

28
dns64 64:ff9b::/96 { (5)
clients {any;}; (6)
mapped { any;}; (7)
suffix ::;
};
};

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. IN AAAA
;; ANSWER SECTION:
www.itesys.it. 1800 IN AAAA 64:ff9b::5255:e47
;; AUTHORITY SECTION:
itesys.it. 10799 IN NS dns2.itesys.com.
itesys.it. 10799 IN NS ns1.h4u.it.
;; Query time: 966 msec

30
;; SERVER: ::1#53(::1)
;; WHEN: Sat Jun 9 10:19:22 2012
;; MSG SIZE 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 (2)
!
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 --- Access to IPv4 Internet ---
!
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

33
ipv6 nd advertisement-interval
ipv6 nd ra interval 4
ipv6 nat (3)
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 (6)
!
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

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 DNS-
ALG 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 IPv4 source IPv6 source
IPv4 destination IPv6 destination
tcp 62.XXX.101.12,58963 2001:XXX:C89E::3,58963
17.172.232.137,443 64:FF9B::11AC:E889,443

tcp 62.XXX.101.12,59060 2001:XXX:C89E::3,59060


194.242.61.188,80 64:FF9B::C2F2:3DBC,80

tcp 62.XXX.101.12,59062 2001:XXX:C89E::3,59062


194.242.61.188,80 64:FF9B::C2F2:3DBC,80

tcp 62.XXX.101.12,59063 2001:XXX:C89E::3,59063


194.242.61.188,80 64:FF9B::C2F2:3DBC,80

tcp 62.XXX.101.12,59064 2001:XXX:C89E::3,59064


194.242.61.188,80 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 192.168.50.1 (192.168.50.1) 3.748 ms 4.411 ms 5.170 ms
2 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 cost-
effective 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