After several months of testing I’ve enabled native IPv6 on some of our customer networks. While enabling is rather easy you should take some things in mind that can break things in your network.
Vendor Lock-in with public addresses
With IPv4 most companies have an internal network with private IP addresses (RFC1918). On the edge of their networks they have routers and firewalls which perform NAT for the internal network. The public IP addresses, often assigned from their ISP, are mostly configured on the router and firewalls. When a company changes ISP and thus needs to change the public IP addresses they only need to change the router and firewall configuration.
With IPv6 this is a bit different. When you enable IPv6 on your network, you probably got an IPv6 subnet assigned from your ISP. The big difference with IPv4 is that with IPv6 public” IP addresses are configured on all your devices in your network, not just on the router or firewall. Your routers and firewalls will not perform NAT, so each device will have an IPv6 address which is publicly available on the internet.
When you change ISP all IPv6 addresses which are configured on your servers will not work anymore. These addresses are present in the DNS server and cached on your clients and maybe even hard coded in configuration files on your servers. Changing IPv6 addresses on your servers can cause a disruption in your network.
The solution for this “vendor lock-in” problem is Unique Local, which is like RFC1918 for IPv6. You can configure your network with your generated “Unique Local” IPv6 prefix. A Unique Local address starts with FD. The second part consists of 40 bits which are generated as specified in RFC 4193. Together with FD this will make your Unique Local Prefix, for example FD31:DFC3:E7D9::/48.
Unique Local address will also be added to the DNS server. When clients ask for your server they get multiple AAAA records, one with the public IPv6 address and one with the unique local address. When your clients have an IPv6 address in the unique local prefix, they will automatically use the unique local address to connect. You can also use these unique local addresses in your configuration files. When you change ISP, and your public IP addresses will change, your unique local address stays the same for each device so there is no disruption in your local network.
Because a unique local prefix is ::/48 you can use it at all your (remote) locations throughout your organization. The reason that you need to generate a prefix with a special procedure is to be unique in the world. There are situations where you would want to connect different organizations, for example with an IPSEC site to site tunnel, and would like to use unique local addresses. The benefit of using unique local addresses is that you will be sure it will not be routed over the internet.
I’ve created my own Unique Local GlobalID Generator which you can find here.
IPv6 and IPv6-aware but disabled applications
If you enable IPv6 in your network please note that Windows Vista and above prefer IPv6 over IPv4. This means that when your client asks for a website running on your server and an AAAA record is present your client will try to reach the server over IPv6. When you enabled IPv6 in your network but did not enable IPv6 for all IPv6 aware applications clients can experience time delays or even messages that applications cannot connect.
A good example is a Windows 2003 server with IPv6. When you enable IPv6 on the Windows 2003 server the DNS server will hold an AAAA record for this server. When you connect from a Windows 7 client with remote desktop to the Windows 2003 server it will take a long time to connect. Why? Because the RDP client is an IPv6-aware application and because it gets an IPv6 address in the DNS query result, it expects the server listening on IPv6. After a time out it will know that the server is not listening on IPv6 and will try to connect with IPv4.
What if your client applications take 30 seconds or more to start because of IPv6? Your users will not be happy and complain. The “solution” here is to make your servers and clients prefer IPv4 over IPv6. This way you can enable IPv6 without applications slowing down. When only IPv6 is available IPv6 will be used though.
The reason that IPv6 is prefered over IPv4 is more a political decision then a technical decision. At all our client sites where we have custom applications and a mixed environment of servers (2003, 2008, 2008r2) we have enabled this “fix”.
You can set the following registry entry (which ofcourse can be set in a group policy):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\ DWORD (32-Bit): DisabledComponents VALUE: 0x20
The fix can be found here on the microsoft site: http://support.microsoft.com/kb/929852/en
Enable IPv6 on remote locations and in your tunnels
When IPv6 is enabled your DNS is filled with AAAA records. Clients with IPv6 enabled will by default prefer IPv6 over IPv4. This means that when your organization has multiple remote locations you should be aware that enabling IPv6 can have an impact on the remote locations. With IPv4 a lot of organizations have IPSEC tunnels between locations. When you enable IPv6 in your organization clients will try to use IPv6 to connect to the server. When IPv6 is not properly configured for the IPSEC tunnels the clients will try to connect over the internet.
So, the tip here is to be sure that when you enable IPv6 you should think of each aspect of your network!
Privacy extensions and IP Security
Windows Vista and Windows 7 have privacy extensions enabled by default. This means that a client has multiple IPv6 addresses, one of them being the temporarily address. The client will register its normal IPv6 address in the DNS server but for outbound connections the temporarily address is used. When you rely on logging and/or matching IP address with the DNS name you should disable privacy extensions for your clients (e.g. trough a group policy).