IPv6 on a home network (Part 5)
Success (sort of)!!!!!
As I mentioned in Part 4, I pulled down an evaluation copy of Red Hat Enterprise Linux (RHEL) 6 and made that my new server. That was an interesting adventure but all I had to show for my efforts was DHCP dynamically creating the DNS forward entry for my Ubuntu Natty Narwhal test system. I attempted to debug the problem (no reverse DNS entry) using nsupdate which at least let me know that there was some sort of "authorization" problem. The interesting quirk of the problem was that IPv4 DHCP was working flawlessly for both forward and reverse DDNS and was also successfully updating resolv.conf.
After hitting Google yet again and coming up empty, I decided to see what would happen if I set up an RHEL 6 client. One thing nice about doing all of this using Virtual Machines (VMs) under VMware ESXi is that I don't have to keep finding new hardware for each different Operating System I want to use. I created the new VM with the only issue being that I only have one "channel" for updates so I'm stuck with the versions of software that shipped with RHEL 6 for my client (Come on CentOS 6!).
I fired up the new VM and, almost as expected, didn't get DDNS entries for IPv6. This time the /var/log/messages entry was at least a little illuminating in that I again got an authorization problem for the error message. I checked all of the file permissions and came up with no reason why the IPv4 DNS entries were being successfully created but the IPv6 entries were not.
Since the IPv4 entries were getting into the server, I had good reason to believe that the server's IP tables firewall was not the problem. This left the client firewall as suspect. The easy test was to simply stop both iptables and ip6tables and restart network services on the client (service network restart). This worked but still left me with a mystery since IPv4 DHCP was working but IPv6 DHCP wasn't.
The next step was to just enable iptables and repeat the test. This worked as expected. Enabling ip6tables brought me back to things not working. After considering different ways of debugging the problem I decided to just add logging to ip6tables so that any packets that were going to be rejected were first logged. The eureka moment was a message that indicated that ip6tables was dropping UDP packets. I then added accept rules for UDP packets on ports 546 and 547. This seems to have solved the problem.
Zone file for "private network" on VMware box:
cat /tmp/vmware.davenjudy.org $ORIGIN . $TTL 259200 ; 3 days vmware.davenjudy.org IN SOA vmware.davenjudy.org. root.fraud.davenjudy.org. ( 2009091742 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 minutes) 1209600 ; expire (2 weeks) 43200 ; minimum (12 hours) ) NS gateway.vmware.davenjudy.org. MX 10 mail.davenjudy.org. MX 20 fraud.davenjudy.org. TXT "Dave and Judy Miller's VMware Network" $ORIGIN vmware.davenjudy.org. gateway A 172.16.3.2 MX 5 mail.davenjudy.org. MX 10 fraud.davenjudy.org. AAAA 2001:5c0:110c:c000::1 $TTL 10800 ; 3 hours natty-alpha3 A 172.16.3.188 $TTL 300 ; 5 minutes TXT "026f7d3a8370f11de2266a87f73b67f132" TXT "31406a42e7260b498dde2f4f75d5cc76ef" $TTL 86400 ; 1 day AAAA 2001:5c0:110c:c000::72 $TTL 300 ; 5 minutes rhel-60-client TXT "02a28c4bb46fca690cf2c4b7a8c3208a62" AAAA 2001:5c0:110c:c000::62 $TTL 10800 ; 3 hours ubuntu-904-1 A 172.16.3.192 TXT "31b96091f9a5c144e67626ab490d16672e"
One oddity in the above file is that rhel-60-client doesn't have an IPv4 address; just an IPv6 entry. Examination of /var/log/messages for rhel-60-client indicate that it got an IPv4 address via DHCP so something is still not right.
Reverse look up zone file for "private network":
cat /tmp/0.0.0.c.c.0.1.1.0.c.184.108.40.206.0.2.ip6.arpa $ORIGIN . $TTL 259200 ; 3 days 0.0.0.c.c.0.1.1.0.c.220.127.116.11.0.2.ip6.arpa IN SOA 0.0.0.c.c.0.1.1.0.c.18.104.22.168.0.2.ip6.arpa. root.davenjudy.org. ( 2011030203 ; serial 86400 ; refresh (1 day) 1800 ; retry (30 minutes) 172800 ; expire (2 days) 259200 ; minimum (3 days) ) NS gateway.vmware.davenjudy.org. NS rhel-60.local.davenjudy.org. $ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.c.0.1.1.0.c.22.214.171.124.0.2.ip6.arpa. 1.0 PTR gateway.0.0.0.c.c.0.1.1.0.c.126.96.36.199.0.2.ip6.arpa. $ORIGIN 188.8.131.52.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.c.0.1.1.0.c.184.108.40.206.0.2.ip6.arpa. $TTL 3600 ; 1 hour 0 PTR rhel-60-client.vmware.davenjudy.org. 2 PTR rhel-60-client.vmware.davenjudy.org.
The oddity here is that rhel-60-client has two entries and only one is valid. Again, more to investigate.
Given the oddities in the above zone files I decided to shut down the clients, stop named on the server, clean out both the .jnl files and the various DDNS entries for the clients and then reboot the server to get everything back to a nice, known condition and then restart the clients. Once I did that I was back to no DDNS updates getting to the server's DNS zone files and no IPv6 addresses assigned to the clients. Looks like a lot more investigating to do.