I posted this on the Linux Beer Hike list this evening, its probably of interest to a wider audience..
I’ve been working with IPv6 a bit recently and have been discovering lots of interesting implementation issues with both Windows and Linux. Generally dual stack where interfaces have both IPv4 and IPv6 enabled works fine on most systems. However running on a pure IPv6 network with NAT64 and DNS64 shows a few issues with several operating systems. I’ve focused on stateless autoconfiguration for the moment, DHCPv6 is on my todo list
Windows XP is the worst offender on pure IPv6 networks because it appears to be impossible to get the DNS resolver to query non-IPv4 DNS servers. I’ve seen several ‘fixes’ which involve manually configuring the DNS but they have failed to work on the XP systems I’ve had the misfortune to encounter, maybe a different set of updates and service packs are required. XP comes with a set of site-local IPv6 addresses preconfigured for the DNS resolver but it doesn’t appear to be able to query them either. I’m of the opinion that the only way to get XP to work properly on pure IPv6 networks is to install an IPv6 capable DNS server on each machine and point the XP DNS resolver at the IPv4 localhost (127.0.0.1). Its certainly the approach I’m going to be exploring in the future.
Windows Vista and Windows 7 both appear to behave reasonably well on pure IPv6 networks, all machines appear to stateless autoconfigure reasonably well and pick up the router advertisements. Some systems don’t pick up the DNS and I’m still trying to work out the conditions under which this happens. However it can always be fixed by a quick manual setting in the interface IPv6 configuration.
In the Debian Linux world things are generally much better apart from the Debian squeeze installer which is unable to pickup any networking from IPv6. The only way I’ve managed to install successfully on a pure IPv6 network is to do a non-networking install, bring up the system then configure networking, set the aptitude repositories followed by a quick “apt-get update”, “apt-get upgrade”. After this everything works just fine. I’ve not tested the Ubuntu installer on a pure IPv6 network but I expect it to be the same story.
Getting access to the IPv4 world from an IPv6 only network is best achieved using NAT64 and DNS64. Once it is properly setup things work smoothly and completely transparently to the user. The only times they will notice the difference is when they want to go to a system which is not in DNS and they try to type the IPv4 address in the form 192.168.0.1. The problem is their machine will try to open an IPv4 connection and discovers that there are no network interfaces configured with IPv4. This is easily rectified by either putting the target host into DNS or prefixing the IPv4 address with the 96 bit IPv6 prefix for the NAT64. Its a little annoying at first but becomes second nature after a while.
Both NAT64 and DNS64 are very new and implementations are still trying to catch up with the recommendations. For NAT64 I’ve settled on Tayga which is easy to compile and doesn’t require any kernel hacking. DNS64 is best done using Bind 9.8 or later. In both cases with Debian stable you have to manually build them from sources. To get your gateway system to transmit IPv6 router advertisements you need to install and configure radvd. Again the Debian stable version is a little out of date and if you want the client machines to pickup the DNS server information you will have to upgrade radvd to a later version (Debian testing). Make sure you install rdnssd on your client Linux systems if you want them to pick up DNS from the radvd advertisements.
Getting an IPv6 connection from your ISP is a little harder, in my case in Qatar it is impossible, so I am using the Hurricane Electric tunnelbroker service. They offer a free 6 in 4 connection where IPv6 is delivered over the normal IPv4 connection but uses protocol 41 instead of TCP/UDP etc. I’ve configured my home gateway machine to DNAT any packets with protocol 41 to a VirtualBox VM on my home network which does all the IPv4 tunnel, NAT64 and DNS64 stuff. I now have a home LAN which runs dual stack on 192.168.1.0/24 and Ipv6 only on a VLAN. Hurricane Electric will delegate a /48 address block to you so you can setup the rest of your IPv6 network and make it properly routable which is what I did. 64K subnets of /64 should be enough for (almost) anyone!
During testing with Oracle VirtualBox I noticed a strange thing when I tried to bridge the raw Ethernet device into the VM and setup VLANs within the VM. This was that the radvd IPv6 advertisements did not get the VLAN packet headers attached and they were all coming out as untagged (native) packets. Other IPv6 traffic behaved as expected. I solved this by creating the VLAN interfaces in the host machine and bridging them to the VM which then saw them as eth0, eth1 etc. I’ll have to investigate this later when I get time, something very strange was going on.
Once you have your IPv6 connectivity up and going your entire network is fully accessible to the rest of the IPv6 world, this includes your printers and your NAS box with those compromising photographs. Fortunately ip6tables is fully developed and it is an easy matter to control incoming connections on your IPv6 gateway. Its prudent to check incoming traffic from the Internet to ensure that it doesn’t have a source address within your delegated address block (spoofing) and to add a blackhole route for your delegated address block to prevent you sending your internal traffic up the link back to your provider.
If you are wanting to use QOS on your IPv6 interfaces don’t be fooled into thinking that the U32 classifier only supports IPv4. I went digging into the IPROUTE2 code for tc and found complete, but undocumented support. If you want to know how to use it with IPv6 see my last posting on this blog on IPROUTE2. Please let me know if you find any errors.
I’ll write this up properly when I get some time along with details about ip6tables, NAT64 and DNS64.