Migrating the company’s local network to IPv6 will not make much sense in the next few years. The situation is different for leased dedicated servers, or ones that have a genuine IPv4 address and are thus part of the Internet. If you have customers from Asia who use native IPv6 to surf the Internet, it definitely makes sense to prepare the services that you provide on IPv4 for IPv6. It is primarily the 4,000,000,000 inhabitants of this continent who are affected by the scarcity of IPv4 addresses – and who are thus the earliest adopters of IPv6. This situation will mainly relate to your web offerings, possibly followed by your mail server.

In this article, I’ll describe a useful strategy step-by-step – and there are many pitfalls to watch out for. The first step is to ask yourself how many addresses you need and how big your IPv6 network is going to be. If your mail server and web server only have IPv4 addresses, and you just want to make sure they have IPv6 addresses, you will be fine with just one address, or a /64 network.

To test whether your configuration actually works, you also will need a local machine that speaks IPv6. If your ISP doesn’t support IPv6, you can resort to a tunnel broker such as SixXs.net . Alternatively, you can build an IPv6-in-IPv4 tunnel to the server you want to configure, which is possible within an OpenVPN connection. To allow this to happen, you need to ask your provider to give you an IPv6 network of the right size, which you then segment into smaller /64 networks, before configuring one of them for the tunnel.

^{Preparing DNS}

Before you start to configure your new IPv6 addresses on the server, you need to make a few preparations, including creating valid DNS reverse entries for the IPv6 addresses you will be using (Figure 1).

Figure 1: Create DNS reverse entries for your IPv6 addresses at an early stage – the example shows the web hoster Strato, whose customers can create DNS entries themselves or delegate the zone on their own name server.

Because Linux systems prefer IPv6 for outgoing connections, as soon as an IPv6 address is configured locally, your forward and reverse resolution should produce the same results. You should start with lab-friendly, separate DNS names, such as ipv6.Domainname.com .

Consistent DNS records are also mandatory if you will be using SMTP to send mail to some other IPv6 entity that checks the consistency of the DNS record against the transmitting server to prevent spam. Many mail servers are configured to discard mail if the DNS record does not exist or is inconsistent.

^{Firewall Issues}

Once you assign an IPv6 address to your server, the machine is totally exposed in the middle of the web. The reason for this is that the Linux firewall isn’t typically configured for IPv6, which means that the kernel just accepts any connection. The following command line

netstat -anp | grep ":::" | grep LISTEN

shows you which active applications would react to incoming IPv4 and thus automatically to IPv6 connections. You can identify these applications by the three colons (:::) in the IP address, followed by the program name.

Some hard work now lies ahead: all the firewall rules that you created in IPv4 need to be modified for IPv6. Otherwise, you run the risk of internal services being accessible from the web via IPv6. You also need to pay attention to your Linux version. Kernels in older enterprise distributions, in particular, will not have IP6tables support for things like connection tracking. A kernel or distribution upgrade is definitely necessary here.

When you write the rules, make sure that ICMPv6 communication is allowed on the local IP addresses that the system autonomously generates (fe80::/​10) to ensure that neighbor solicitation and neighbor advertisement (a kind of IPv6 ARP) still work properly. Without ICMPv6, there can be no IPv6 data traffic. It is important for the firewall setup on the Linux server that the server accept the router advertisements from the local address of the router (fe80::/​10). The router sends the advertisements to an IPv6 multicast address (ff02::1).

You might find it useful to initially reject all incoming connections. After you have performed tests to make sure that the corresponding application configuration is okay, you can open the required ports on the firewall one by one. In particular, you should add an ACCEPT rule that classifies all the incoming connections from your lab machine’s source address as benevolent, before you add the reject rule. Otherwise you will not be able to use this machine to test your server’s IPv6 functionality.