IPv6 only setup with NAT64

From DocWiki

Jump to: navigation, search
 *** work in progress, feedback -> ayourtch at cisco ***

Contents

Introduction

In this write-up we will discuss the set-up of an IPv6-only segment for checking how your devices work in the post-IPv4 world.

However, despite quite a notable part of content being already available on IPv6, there is still a large portion of it that isn't - and to be able to access that still, we will set up the mechanism to communicate between our IPv6-only network and the legacy IPv4-only world - NAT64, with DNS64 to direct some traffic.

We do not describe the functioning NAT64/DNS64 - for details, please take a look at NAT64 whitepaper, specifically the part titled "Providing IPv4 Internet Access to IPv6-Only Networks" - this is the scenario we will be implementing in this setup.

For implementing NAT64 we will use a CSR1000V, and for running the DNS64 we will use bind9, running on an Ubuntu Server - both running in virtual machines.

Also, note that the configuration of the client-facing router here is aimed at a small to middle scale client segment - up to approximately 300 hosts at once.

Larger scale setups will need modifications on the wireless side similar to those outlined in Wireless High Density Deployment Guides as well as the IPv6 tweaks that are outlined in the CiscoLive session BRKEWN-2666 dedicated to this topic. They are outside of the scope of this document - if you have issues after going through the above resources - please contact me by email at ayourtch at cisco if you need help.

Prerequisites

You need to obtain and install the CSR1000V with 3 interfaces: one for connecting to the IPv6 and IPv4 portions of the internet, one for connecting to the VLAN with the IPv6-only clients, and one for connecting to the DNS64 server.

Note that by default until you license the CSR1000V, it strictly limits its throughput - thus, verify that the CSR1000V instance you are running is properly licensed. Also, of note is that another platform can work for the purpose as well, e.g. an ASR1000 router, or a Cisco IOS router running the version which supports stateful NAT64.

You also need to have a ready VM connected to the "Server" interface of the CSR1000V for DNS64.

We assume that you are getting 192.0.2.129/30 as the interface IPv4 address on the CSR1000V, and that you've been given 192.0.2.1 as the address address to be used for NAT64. We also assume you got two /64 subnets: one for your server segment (2001:db8:5555::/64), and one for the client segment (2001:db8::/64).

We will perform stateful NAT64 from our client prefix 2001:db8::/64 into IPv4 address 192.0.2.1 when they attempt to communicate with the destinations within the prefix 64:ff9b::/96. This prefix is specifically reserved for NAT64.

Topology

NAT64-with-CSR1k-network-diagram.png

CSR1000V setup

The initial configuration of the CSR1000V to verify the NAT64 operation will look as follows:


 !
 !
 ipv6 unicast-routing
 !         
 !
 interface GigabitEthernet1
  description To Internet
  ip address 192.0.2.129 255.255.255.252
  nat64 enable
  ipv6 enable
  ipv6 nd ra suppress all
 !
 interface GigabitEthernet2
  description to Clients
  no ip address
  nat64 enable
  ipv6 address 2001:DB8::1/64  
 !
 interface GigabitEthernet3
  description to DNS64 server
  no ip address
  ipv6 address 2001:DB8:5555::1/64  
 !
 ip route 0.0.0.0 0.0.0.0 192.0.2.130
 !
 ipv6 route ::/0 GigabitEthernet1 FE80::1
 !
 !
 ipv6 access-list NAT64
  permit tcp 2001:DB8::/64 64:FF9B::/64
  permit udp 2001:DB8::/64 64:FF9B::/64
  permit icmp 2001:DB8::/64 64:FF9B::/64
 !
 !
 nat64 v4 pool NAT64-IPv4 192.0.2.1 192.0.2.1
 nat64 v6v4 list NAT64 pool NAT64-IPv4 overload
 !


After completing this basic configuration, we should be able to connect an e.g. linux client directly to the GigabitEthernet2 VLAN and verify that NAT64 works ok, by performing ping6 to the address 64:ff9b::192.0.2.130 - this is our default gateway.

The ping6 should succeed, and we should be able to see the active translations on the router:

 nat64-rtr#show nat64 translations 
 
 Proto  Original IPv4         Translated IPv4
        Translated IPv6       Original IPv6 
 ----------------------------------------------------------------------------
 
 icmp   192.0.2.130:1         [64:ff9b::c000:282]:4039                        
        192.0.2.1:1           [2001:db8::e5dc:91e4:e3b:a862]:4039             
 
 Total number of translations: 1
 
 nat64-rtr#

Bind9 setup

First we need to install bind9 - the DNS server software:

 sudo apt-get install bind9

After the installation, we need to edit the configuration file to enable DNS64 and allow the queries and recursion from indirectly connected clients (doing so for everyone will create an open resolver, you definitely do not want that).

The additions will need to be done to the file /etc/bind/named.conf.options, and will look as follows:

       forwarders {
               2001:db8:1234::1;
       };
       allow-query { localnets; localhost; 2001:db8::/64; }
       allow-recursion { localnets; localhost; 2001:db8::/64; }
       dns64 64:ff9b::/96 {
               clients { any; };
       };

Here the 2001:db8:1234::1 is the IPv6 address of your existing dual-stack recursive resolver which already exists in your organization. The reason for configuring the DNS64 resolver in such a way is that this way you will be able to enjoy low-latency responses for those destinations that are frequently used and may be already in the cache of the main DNS resolvers. If you do not have your local resolver and are using e.g. Google public DNS, then you might put the IPv6 version of it here - 2001:4860:4860::8888, or any other IPv6-reachable resolver that the rest of the network already uses.

After changing the configuration, it is always a good idea to check that our configuration is good:

 sudo named-checkconf 

After that we can reload the configuration:

 sudo rndc reload

If for whatever reason the server stops, you can restart using "service" command:

 sudo service bind9 restart

Now we should be able to test that our DNS64 configuration works correctly:

 test@dns64:~$ dig +short AAAA ipv4only.arpa. @::1
 64:ff9b::c000:aa
 64:ff9b::c000:ab

If you see these two IPv6 addresses, then your DNS64 configuration is correct.

Why did we use the domain ipv4only.arpa. for this test ? It is a special-purpose domain, reserved precisely for NAT64 detection by RFC7050 - so, it is guaranteed to remain IPv4-only.

Putting it all together

We are almost there - the only thing that is missing is a need to tell the clients the address of our DNS server to use.

If your MAC address on the VM is stable, for short-lived setups you can use SLAAC address of the server:

 test@dns64:~$ ip -6 addr
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
     inet6 ::1/128 scope host 
        valid_lft forever preferred_lft forever
 3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qlen 1000
     inet6 2001:db8:5555:0:8956:52b4:6e38:d35b/64 scope global temporary dynamic 
        valid_lft 603033sec preferred_lft 84033sec
     inet6 2001:db8:5555:0:ea:68ff:fe9a:1/64 scope global dynamic 
        valid_lft 2591950sec preferred_lft 604750sec
     inet6 fe80::ea:68ff:fe9a:1/64 scope link 
        valid_lft forever preferred_lft forever
 test@dns64:~$ 

The EUI-64 address is relatively easy to see by "ff:fe" signature in the middle, also it does not have the "temporary" designation next to it. (The reason using SLAAC for long-term setups may need extra consideration is that there is no guarantee that SLAAC remains the default stable address assignment mechanism).

So, we for our case, we need to supply the address of 2001:db8:5555:0:ea:68ff:fe9a:1 to the clients.

We can do it by configuring the stateless DHCPv6 pool on the CSR1000V (and setting the "other" flag), and adding the RDNSS option:

 nat64-rtr(config)#ipv6 dhcp pool DHCPv6-stateless
 nat64-rtr(config-dhcpv6)#domain
 nat64-rtr(config-dhcpv6)#domain-name example.com
 nat64-rtr(config-dhcpv6)#dns
 nat64-rtr(config-dhcpv6)#dns-server 2001:db8:5555:0:ea:68ff:fe9a:1
 nat64-rtr(config-dhcpv6)#
 nat64-rtr(config-dhcpv6)#interface gigabit2
 nat64-rtr(config-if)#ipv6 nd other-config-flag 
 nat64-rtr(config-if)#ipv6 nd ra dns server 2001:db8:5555:0:ea:68ff:fe9a:1 86400 

So the resulting configuration will look like this:

 nat64-rtr#sh run | sec ipv6 dhcp
 ipv6 dhcp pool DHCPv6-stateless
  dns-server 2001:DB8:5555:0:EA:68FF:FE9A:1
  domain-name example.com
 nat64-rtr#sh run int g2
 Building configuration...
 
 Current configuration : 221 bytes
 !
 interface GigabitEthernet2
  description to Clients
  no ip address
  negotiation auto
  nat64 enable
  ipv6 address 2001:DB8::1/64
  ipv6 nd other-config-flag
  ipv6 nd ra dns server 2001:DB8:5555:0:EA:68FF:FE9A:1 86400
 end
 
 nat64-rtr#

Testing

You can test the setup by running IPv6 ping to a hostname that is IPv4-only, e.g. ipv4.google.com. If this ping succeeds, then your setup is working.

Rating: 4.8/5 (4 votes cast)

Personal tools