The IP addressing system is in transition from IPv4 to IPv6. The main reason is the depletion of the IPv4 address space, but IPv6 has some more advantages besides the huge number of available addresses. In this article we’ll examine the possibilities of basic configuration of IPv6 on Cisco and Linux devices and how they can coexist and provide services to each other. We’ll build a simple LAN with the familiar services: DHCPv6 and DNS.

We’ll put a Windows PC also into the topology, which looks like this:

The router platform I used is a 7200 with IOS version 12.4(24)T. It is because previous IOS versions don’t support all of the settings I intend to use (for example stateful DHCPv6). Unfortunately other router platforms in GNS3 doesn’t support this version, therefore we need to use a 7200. Although the topology contains Internet connection, we don’t use it for IPv6 communication. In order to install packages on Debian server we need to set it up as a dual-stack router: it runs both IP addressing system. For IPv4 connectivity we need to configure NAT also.

The first exercise is the configuration of static IPv6 addresses on all devices. Starting with the router, we have two methods to do this: we can give a fully qualified address or we can use EUI-64. I use both as the following figure shows:

The first command is a must if we want to use IPv6 on a Cisco router. On Fa0/1 I set up the prefix and EUI-64 puts an interface ID after it to form a full IPv6 address.I In the second case I specify the full address (using the abbreviation rule of zero fields). We can check the result with the show ipv6 interface brief command. This basic configuration can be saved into startup-config, but from now on I don’t save the configuration to make it easier to revert to this basic one.

On the Linux device the IPv6 configuration is simple. We’ll use the ip command to set up and check the address:

On Windows it’s even simpler as we can configure IPv6 addresses on the GUI (in XP it wasn’t possible, we had to use CLI commands). Configure the Win7 PC with the ::3 interface ID and try to ping the other devices.

We can go one step further and use stateless address autoconfiguration (SLAAC) or autoconfig for short. In this case a router (or similar device) sends special ICMPv6 messages called Router Advertisements (RA) to the network. The clients can use the information packaged into these messages to determine the network prefix, then using EUI-64 (or random generator) they complete it with an interface ID. The default gateway will be the router’s link-local address.

On the Cisco router the sending of RA messages already started. It can be verified by starting a Wireshark capture on the Fa0/0 interface. To use the autoconfig feature on Linux, we need to check some things. The necessary commands are the following:

The autoconfig and accepting the RA messages must be turned on, but the forwarding must be turned off. When I made the previous figure about my Linux box, it was on, therefore only the statically configured address showed up in the output. Now it has two different addresses on the same subnet: it’s not impossible in IPv6. While Windows can automatically get its address, the difference is that it uses random generated interface ID instead of EUI-64.

Now try to use the Linux server as the source of RA messages. First we need to disable RAs on R1 router by issuing the following command:

R1(config-if)#ipv6 nd ra suppress

Here “nd” means Neighbor Discovery, which can be considered as a sub-protocol in ICMPv6.

Next remove the auto-configured address from eth0 on Linux, leaving just one IPv6 address using the ip -6 address delete address dev eth0 command. Now we can install the daemon program which provides the functionality of sending RAs (and many more). It’s called radvd (Router Advertisement Daemon). In order to use it we need a configuration file /etc/radvd.conf, create it and fill in with the following:

Nothing fancy: just enabling the RAs and specifying the prefix. Before starting the service we need one more step: enable the IPv6 forwarding by issuing the sysctl -w net.ipv6.conf.all.forwarding=1 command. Finally start the daemon: service radvd start. The test can be done on R1: when issuing ipv6 address autoconfig command on Fa0/0, the router should get a new address constructed from the advertised prefix and EUI-64. On Windows we can check that now the default gateway is the Linux server.

One can ask: it’s OK, but where’s DNS server information? The answer is not simple, as operating systems differ in this way. We can provide DNS information with RDNSS option (Recursive DNS Server) in radvd, but, for example, Windows 7 doesn’t accept it. It’s better to use another methods (or static configuration), but until we can use IPv4 DNS servers, we can use them for IPv6 address resolution as well.

Autoconfig is not the only way to provide addressing information to hosts. DHCPv6 exists like DHCP in IPv4, but in IPv6 it’s not so simple and straightforward as we have more possibilities. Namely we can use stateless and stateful DHCPv6 (so instead of one method of dynamic addressing we have three). Stateless DHCP means that clients generate some portion of addressing information on their own and there’s no central device which can track these addresses and store in its own database. Stateful means that all the information come from the DHCP server, just like in IPv4.

Let’s begin with stateless DHCPv6 labs and first the server will be our Cisco router. First stop the radvd service on the Linux box, then delete the previous configuration (except the static IPv6 address) from the interface by the default interface f0/0 command on the router. The DHCP server configuration is the following:

We define a pool just like in IPv4 but in this case this pool doesn’t contain addresses, just information about the DNS server(s) and the domain name. The configuration of the server interface contains the reference to this pool and another important thing: the so called “other-config” flag in the advertisements indicates that the client can find more information by stateless DHCPv6. This way the router advertises the prefix, from which the clients can generate full address and gateway as in pure autoconfig, and the remaining information can be acquired through DHCP. It can be clearly seen that the server doesn’t know about the exact addresses of the clients – this is the meaning of stateless mode. Check the addresses on the Linux and Windows clients.

Now configure stateful server on the router. Remove the previous configuration (again, except the static address) and apply the following:

The pool definition includes the address prefix to be advertised. The interface configuration is extended by the setting so called “managed config flag” which instructs the clients to use the stateful method to obtain addressing information, while the line begins with ipv6 nd prefix instructs the hosts that they don’t use the RAs for automatic configuration (the keywords infinite means valid and preferred lifetimes).

During my tests I discovered that Debian gets all information but DNS address. This information should go to /etc/resolv.conf but it doesn’t appear after issuing dhclient -6 eth0. On the other hand, under Windows we should configure the host for stateful DHCP by the following command in the Command Prompt:

netsh interface ipv6 set interface nn advertise=enable managed=enable routerdiscovery=disable

where nn is the interface number of the NIC which can be discovered by the following (look at the Idx column):

netsh interface ipv6 show interface

After issuing the ipconfig /renew6 command the host should get all information. Now go on with stateful DHCPv6.

First we need to remove the configuration from the router to make it a DHCP client and we need to suppress the RAs on its interface. Revert to the basic configuration and issue the ipv6 nd ra suppress command on Fa0/0.

Next install a DHCPv6 server on the Linux server. There exists more than one, I’ll use the wide-dhcpv6-server package. We’ll use this in combination with radvd to provide DHCPv6 service. First try stateless DHCPv6. We need to edit /etc/radvd.conf according to this:

I used a slightly different prefix (just to easily recognize if we really get information from this server – of course we need to modify the IPv6 address of the server to 2001:db8:1::2 as well). Another important thing is the line saying AdvOtherConfigFlag on. This tells the clients that some other information can be acquired by asking DHCP servers. Restart the radvd service (make sure that IPv6 forwarding is enabled as stated before) then edit the configuration of wide-dhcpv6-server. We need to edit the /etc/wide-dhcpv6/dhcp6s.conf file and put in the following:

If we edited the widely used ISC DHCP server configuration before, then it’s not a big surprise: the two option lines tell the value of the DNS server and the domain name, and now we don’t put any special information into the interface section. Now restart the server by the service wide-dhcpv6-server restart command, and go to our two clients.

On the router issue the ipv6 address autoconfig default command. This instructs the interface to get the addressing information as we saw before but now it additionally asks DNS and domain information as well. The default keyword instructs the router to put a static default route into the IPv6 routing table pointing to the link-local address of the Linux server’s interface. Check the settings by the following commands:

  • show ipv6 interface brief
  • show ipv6 route
  • show hosts

On Windows we just have to do an ipconfig /renew6 command followed by an ipconfig /all and everything can be seen.

Finally try to provide the addressing information by stateful DHCPv6. We need some modifications in the radvd configuration first:

The new line (AdvManagedFlag on) instructs the clients that the process of getting addressing information is now configured by stateful method. As all the necessary information is provided by the DHCPv6 server, we don’t need to specify the prefix. Now go on to the DHCPv6 server configuration in /etc/wide-dhcpv6/dhcp6s.conf:

In this case the interface section contains a reference to the pool named pool1 with a 3600 second preferred lifetime. The pool section contains a range of addresses – this method is the most similar to what is in IPv4, and in my humble opinion in well controlled environments this is the most useable. Restart both services and do an address renewing on Windows first. We should see all parameters correctly defined. On the router we need to set back the Fa0/0 interface to its default configuration then issue the following two commands: ipv6 enable; ipv6 address dhcp. The device should get addressing information.

Now that the addressing can be done, another basic service needs to be installed: DNS. IPv6 addresses are much more complex than IPv4 addresses (although there are some exceptions, like ::1, the loopback address), so we need DNS more than ever. Fortunately the actual configuration is not so difficult, and we can use the BIND name server which can be familiar to many administrators. We’ll use this one in our last lab, so install it by the apt-get install bind9. We can install the dnsutils package also for testing.

BIND uses databases called zone files for name resolution and they are in /etc/bind directory. We have to make a new zone for our network and create separate zone files for forward and reverse lookup. First enter the data about the new zone files into /etc/bind/named.conf.local:

We have to define the type of the zones and the location of the data files themselves. With the forward zone we define the domain part, but with the reverse zone it’s a bit trickier. First we have to write down the network portion in reverse order, all digits separated by a dot, then complete it by the TLD of (all IPv6 addresses belong to this special domain). Both sections contain an important setting: we allow the lookups from anywhere on the network.

Next create the zone file for the forward lookups containing this information:

The IPv6 specific data here are the AAAA address records. (You can read about the format of the zone files in the link below.)

The reverse zone file is like this:

The header is almost the same except the ORIGIN directive which defines the domain part (or more precisely, the network part) of the addresses. The PTR (pointer) records contain the interface IDs in reverse format. Reload the server by service bind9 restart and check it on the server first:

So far so good. We can test the lookups on the Windows client by nslookup command and it should work also.

At this point we have a network with basic IPv6 services, but of course this is just the beginning: IPv6 has a lot of new things to learn for network technicians!

Useful links:

Implementing DHCP for IPv6 on Cisco devices:

OS support for IPv6 DNS:

BIND configuration and zone files: