IPv6 on a home network (Part 6)
I ended Part 5 of this saga with the observation that I needed to do more investigating to find out why I could get IPv4 DDNS entries and I was somehow able to force some IPv6 DDNS entries but these entries weren't apparently getting created by the network initialization scripts. My suspicion soon fell on NetworkManager (a.k.a. network-manager). I attempted to force Network Manager to use the dhclient.conf file that worked for me from the command line only to find out the NetworkManager dynamically creates its own dhclinet configuration file (in /var/run/nm-dhclient-ethX.conf). So what was happening was dhclient was sort of doing the right thing when I ran it from the command line but was not doing the right thing when run by NetworkManager. This mean that NetworkManager had to go at least until I found a working configuration for dhclient.
I knew from my many years of running Red Hat products that Linux network set up wasn't dependent on a graphical tool like NetworkManager. I just set the default run level in /etc/inittab to "3" and disabled NetworkManager using chkconfig to run my RHEL client without the GUI. Big surprise (NOT!), making changes to various network configuration files suddenly started producing predictable results on my RHEL 6 client (by the way, I quietly shifted to Scientific Linux, another RHEL clone, for the client since I didn't like the idea that the client wasn't getting updates on a X.0 release). Ubuntu wasn't as easy to get into text mode.
As usual, I went to Google since the use of a Graphical User Interface (GUI) on Linux is typically handled by a trivial entry in /etc/inittab. Ubuntu doesn't do it this way. I tried solutions from a couple of different people but the best I was able to do was get a blank screen instead of the Ubuntu GUI. The easy solution to this problem was to just download and install the server versions of Ubuntu 10 and 11. I made sure that network-manager wasn't going to be playing tricks on me again with this new configuration and, low and behold, I got IPv4 DDNS working with almost no effort on my part. Of course this just meant that I was back to where I was when I started this project since I already had IPv4 DDNS working for Ubuntu, CentOS, Backtrack, and Windoze XP clients on my home network.
I first tried one of the fairly simple dhclient.conf files that I had tried once before (and which was ignored by NetworkManager) on the RHEL 6 client. Unfortunately, I kept getting an error response from my DHCP server of, "Address not for use on this network." This kicked off another round of Google searches which led nowhere. After pondering the lack of results for a little while, I decided that the error was legitimate and the reason I was getting it was the address my client was trying to use really was invalid for my network set up. The only problem with this diagnosis was that the address was exactly what I expected the DHCP server to offer.
This meant that there was something wrong with my dhcpd6 server configuration. Again, a little more Googling but the configuration I was trying to use was really simple so I just searched for another example of a dhcpd6.conf file. I found a good example that I thought I had tried and rejected because dhcpd6 didn't like it but this time it worked. I restarted the network on the RHEL 6 client and this time it worked.
At this point I have the following results (by client):
RHEL 6/Scientific Linux 6:
Client IPv6 address is exactly what I expect. The client has three different IPv6 addresses plus an IPv4 address for eth0:
eth0 Link encap:Ethernet HWaddr 00:0C:29:2C:3A:9D inet addr:172.16.3.66 Bcast:172.16.3.255 Mask:255.255.255.0 inet6 addr: 2001:5c0:110c:c000:20c:29ff:fe2c:3a9d/64 Scope:Global inet6 addr: fe80::20c:29ff:fe2c:3a9d/64 Scope:Link inet6 addr: 2001:5c0:110c:c000::5b/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1998 errors:0 dropped:0 overruns:0 frame:0 TX packets:1193 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:180131 (175.9 KiB) TX bytes:89883 (87.7 KiB) Interrupt:18 Base address:0x2000
The first IPv6 address is assigned by radvd and is based on my network prefix (2001:5c0:110c:c000::/64) and the MAC address for the NIC. The second IPv6 address is created by the host and uses the private network prefix (fe80::/16) followed again by the MAC address. Both this address and the previous address have "ff:fe" inserted into the middle of the MAC address as expected. The final IPv6 address is assigned by dhcpd6 on the server and again has my allocated prefix (2001:5c0:110c:c000::/64) but this time followed by an address allocated from the pool I set up when I configured dhcpd6.
Ubuntu Servers 10 and 11:
At least these two systems come up and can get onto the IPv6 Internet. Both currently only get the host generated IPv6 address and the IPv6 address assigned by radvd based on my prefix and their MAC addresses.
Ubuntu Natty Narwhal (alpha 3):
This system only gets an IPv6 address assigned by my DHCP server (it also still gets an IPv4 address) as well as its host generated IPv6 address:
eth0 Link encap:Ethernet HWaddr 00:0c:29:ea:26:b3 inet addr:172.16.3.188 Bcast:172.16.3.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:feea:26b3/64 Scope:Link inet6 addr: 2001:5c0:110c:c000::72/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:57779 errors:0 dropped:0 overruns:0 frame:0 TX packets:35389 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:85360396 (85.3 MB) TX bytes:2799588 (2.7 MB) Interrupt:18 Base address:0x2000
It also manages to get a forward entry into the DDNS server. I seem to remember setting "autoconf" to off for this system since getting a DHCP assigned address seemed to have been implemented as an exclusive or with getting a radvd (autoconf) address. This isn't correct but may have been what was implemented.
My next step is to attempt to achieve consistency and/or explain away any differences. The Ubuntu 10 boxes represent a way to check for the previous generation of DHCP clients to see if they can correctly attach to a correctly configured IPv6 network. I can also resurrect my CentOS 5.X client when that time comes. On the other hand, I may end up just upgrading all of my systems to Ubuntu 11 and RHEL 6 clones.