IPv6 on a home network (Part 3)
My ultimate goal in this endeavor is to have my real home network running on IPv6 with no loss of functionality as compared to how I have things working now with IPv4. In particular, I want to be able to configure tools like amanda or use ssh using host names; not IPv6 addresses. Since I currently accomplish this functionality with tools like DHCP and dynamic DNS updates, I wasn't expecting to encounter any problems. It turns out that this functionality is still somewhat in flux when it comes to IPv6.
The first thing to understand about IPv6 on an internal network is that the kludges needed to make IPv4 work with private addresses aren't needed with IPv6. Since there are literally billions of possible addresses, there is no need for a private subnet like 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 and routers that do network address translation (NAT). Instead, internal subnets self-assemble with each node listening for, getting and utilising an IPv6 address and routing information from the router advertising daemon process (radvd). This approach works great as far as it goes and this was the next logical step after getting a single host connected to the IPv6 Internet as described in Part 2 of this series.
The second thing to understand is that DHCP on an IPv4 network does a lot more than just manage the assignment of addresses on the private network. It also provides critical information like the address of the name server, the sub-net name (e.g., local.davenjudy.org), address(es) of any network time protocol (NTP) servers, etc. It also provides the host name and assigned address of each client system to the domain name server (DNS) so that the client systems are then accessible by name and not just IPv4 address. The DNS can implement dynamic updates to its host database and provide DNS services for the clients.
There are quite a few postings to various blogs and how-to articles that describe how to get around the lack of dynamic DNS (DDNS) with IPv6 implementations by using nsupdate. This was the route I originally took and I managed to get nsupdate configured on each of my clients such that the client host name got dynamically inserted into the local zone file for my IPv6 test network. The problem is that this requires hard coding the address of the name server into each nsupdate script as well as editing the script to include the IPv6 address of the network interface associated with the host. Even if this only needs to be done once for each client, it is an error prone, manual operation that will likely be very cumbersome on a network of any size. This becomes completely unrealistic if a separate update key is used for each client system as some articles implied was "good practice."
This left me with trying to get DHCP working with IPv6. The first problem I ran into was the clients for both CentOS 5.X and Ubuntu 10.10 failed when run from the command line. The somewhat inscrutable error message was, "bind: address already in use." I checked every address I could think of looking for a way that some address was being used more than once. I looked at port assignments and looked for ways to configure either DHCP for IPv4 or DHCP for IPv6 to use different ports and I ran innumerable Google searches for the error message as it related to IPv6 DHCP. I finally struck pay dirt on a Google search that suggested checking for an already running instance and that's what I found. That at least got me to the next error message.
I started by attempting to get the Ubuntu 10.10 client system working first since it had been the easiest to get connected to the IPv6 Internet. Once I had killed the existing instance of the dhcp client, I was able to execute it from the command line with debug turned on. This got me a lot of output and the error message, "client6_recvreply: unexpected reply." This was even more inscrutable than the "address already in use" message. Again, I did Google searches and turned off various "requests" in the client configuration file.
I finally gave up on the Ubuntu system and moved to the CentOS client box. Again, I killed the existing instance of the client and commenced debugging the configuration by running the client from the command line. In this case the problems were easy to spot based on diagnostic messages and thus easy to resolve.
The CentOS DHCP client (dhcp6c) is now working and I'm only left with trying to figure out what's wrong with the Ubuntu client. Another round of Google searches brought up some archived bug reports indicating that the "unexpected reply" is a known bug. Unfortunately, it appears that the IPv6 DHCP server and client used for Ubuntu 10.10 is no longer being developed and is about to be replaced by the Internet Software Consortium (ISC) version in the next Ubuntu release (Natty Narwhal). I have posted to the Ubuntu support forum to see if it's possible to back port the natty narwhal stuff but have not received a reply as of the time I'm writing this post.
I have built the ISC DHCP stuff from source and am now attempting to swap it for the standard DHCP client on my Ubuntu VM. This isn't trivial since the client is deeply integrated with the network start-up scripts (go figure). It may be easier to pull down a beta of Natty Narwhal and go that route instead. Of course that commits me to upgrading to Natty Narwhal before I roll out IPv6 on the home network.