You are hereForums / Computers / CentOS server setup and maintenance notes / IPv6 on a home network (Part 7)

IPv6 on a home network (Part 7)


By DaveAtFraud - Posted on 12 April 2011

W00t!!!!

Yes, you can take that as it's sort of working. It took finding one more level of the systems doing something that wasn't quite what I had in mind. This time it was the "memory" built into the DHCP implementation that meant that changes made by me weren't taking effect. It seems that DHCP lease information is cached on both the client and the server as a means for either to just put things back into place after a reboot. This is great except the check for "is the last set up still good?" failed to take into account the possibility that the configuration had changed. Once I started clearing the client and server leases before testing things became a lot clearer.

Where I left off in Part 5, I was getting DHCP assigned IPv6 addresses and I was even getting dDNS to work sporadically. Unfortunately, I really needed to get dDNS working for IPv6 so sporadically wasn't sufficient. The good news was that since dDNS was working at least some of the time I had more information (like the file permissions and zone update keys were actually working).

The following documents the server configuration that finally worked.

named.conf:

cat /var/named/chroot/etc/named.conf
acl "trusted" {
        127.0.0.1;
        ::1/128;
        192.168.0.0/16;
        172.16.0.0/12;
        68.170.57.104;
        2001:5c0:110c:c000::/64;
        fe80::/16;
};

include "/etc/keys.conf";

// Known fake source addresses shouldn't be replied to.
acl "bogon" {
         0.0.0.0/8;     // Null address
         1.0.0.0/8;     // IANA reserved, popular fakes
         2.0.0.0/8;
         192.0.2.0/24;  // Test address
         224.0.0.0/3;   // Multicast addresses
         // Enterprise networks may or may not be
         // bogus.
         10.0.0.0/8;
};

options {

        directory "/var/named";
        auth-nxdomain no;
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        interface-interval 1; // Check for new/disabled NICs. Default: 1 hour.

        query-source address 172.16.3.2;
        query-source-v6 address 2001:5c0:110c:c000::1;

        forwarders {192.168.0.1;};

        listen-on { 127.0.0.1; 172.16.3.2; 192.168.0.7;};
        listen-on-v6 { ::1; 2001:5c0:110c:c000::1/64; fe80::/16; };

        dnssec-enable no;
        dnssec-validation no;
        dnssec-lookaside auto;

        bindkeys-file "/etc/named.iscdlv.key";

        allow-query-cache { 
                localnets; 
                trusted;
        };
        allow-query {
                trusted;
        };
        allow-transfer { 
                trusted; 
        };
        blackhole { 
                bogon; 
        };
};

I'll leave out a lot of uninteresting stuff and cut to the chase for a couple of zone entries:

zone "3.16.172.in-addr.arpa" IN {
        type master;
        file "172.16.3";
        allow-query {
                trusted;
        };
        allow-update {
                key "vmware.davenjudy.org";
                trusted;
        };
};

zone "0.0.0.c.c.0.1.1.0.c.5.0.1.0.0.2.ip6.arpa" IN {
        type master;
        file "0.0.0.c.c.0.1.1.0.c.5.0.1.0.0.2.ip6.arpa";
        allow-query {
                trusted;
        };
        allow-update {
                key "vmware.davenjudy.org";
                trusted;
        };
};

Note that I still need to back out allowing updates based on IP address. Also note that the "forwarder" entry points to my regular network's internal DNS server at 192.168.0.1.

dhcpd.conf:

cat /etc/dhcp/dhcpd.conf 
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#
ddns-update-style interim;
ignore client-updates;
authoritative;
option domain-name              "davenjudy.org";
option domain-name-servers      172.16.3.2;

key vmware.davenjudy.org {
        algorithm HMAC-MD5;
        secret  *This is supposed to be my very secret key*;
        };

zone 3.16.172.in-addr.arpa. {
        primary 172.16.3.2;
        key vmware.davenjudy.org;
}

zone vmware.davenjudy.org. {
        primary 172.16.3.2;
        key vmware.davenjudy.org;
        }

host gateway.vmware.davenjudy.org {
        next-server gateway.vmware.davenjudy.org;
        fixed-address 172.16.3.2;
        }

subnet 172.16.3.0 netmask 255.255.255.0 {

# --- default gateway
        option routers                  172.16.3.2;
        option subnet-mask              255.255.255.0;

        option nis-domain               "vmware.davenjudy.org";
        option domain-name              "vmware.davenjudy.org";
        option domain-name-servers      172.16.3.2;

        option ntp-servers              192.168.0.1, 65.255.217.202, 66.7.96.1, 128.2.1.21;
        option netbios-name-servers     172.16.3.2;

        range dynamic-bootp 172.16.3.64 172.16.3.192;
        default-lease-time 21600;
        max-lease-time 43200;
        }

This is pretty much what I was previously using for my regular network except I did my experiments on 172.16.3.0/24 and my regular internal network is 192.168.0.0/24.

dhcpd6.conf:

cat /etc/dhcp/dhcpd6.conf 
#
# DHCP for IPv6 Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd6.conf.sample
#   see 'man 5 dhcpd.conf'
#   run 'service dhcpd6 start' or 'dhcpd -6 -cf /etc/dhcp/dhcpd6.conf'
#
#
# ntp-servers support may not be built into the RHEL/CentOS dhcp6s server
#

ddns-update-style interim;
ddns-updates on;
ignore client-updates;
authoritative;
option domain-name-servers      gateway.vmware.davenjudy.org;

# option ntp-servers gateway.vmware.davenjudy.org;

default-lease-time 2592000;
preferred-lifetime 604800;
# Enable RFC 5007 support (same than for DHCPv4)
allow leasequery;

# Global definitions for name server address(es) and domain search list
option dhcp6.name-servers 2001:05c0:110c:c000:0000:0000:0000:0001;
option dhcp6.domain-search "vmware.davenjudy.org","local.davenjudy.org","davenjudy.org";

key vmware.davenjudy.org {
        algorithm HMAC-MD5;
        secret  *This is supposed to be my very secret key*;
        };

zone 0.0.0.c.c.0.1.1.0.c.5.0.1.0.0.2.ip6.arpa. {
        primary gateway.vmware.davenjudy.org;
        key vmware.davenjudy.org;
}

zone vmware.davenjudy.org. {
        primary gateway.vmware.davenjudy.org;
        key vmware.davenjudy.org;
        }

host gateway.vmware.davenjudy.org {
        next-server gateway.vmware.davenjudy.org;
        fixed-address6  2001:5c0:110c:c000::1;
        }

# Set preference to 255 (maximum) in order to avoid waiting for
# additional servers when there is only one
option dhcp6.preference 255;

# The path of the lease file

dhcpv6-lease-file-name "/var/lib/dhcpd/dhcpd6.leases";

subnet6 2001:05c0:110c:c000::/64 {
         range6 2001:05c0:110c:c000::2 2001:05c0:110c:c000::ff;
}

About the only item of interest here is the name server (primary) statement. I was unable to get the dhcpd.conf parser to accept a numeric IPv6 address. This seems to work.

That's pretty much it for the server side configuration. I also have an ip6tables ACCEPT rule that allows everything coming in from the internal subnet. This may change in the future but it was nice to know that the firewall wasn't throwing away anything.

The client configuration varied a little for each distro. All of the clients used the same dhclient.conf file for IPv6. As noted in a previous article, this generally meant sticking dhclient.conf in /etc/dhcp and letting the IPv6 instance of dhclient pick it up from the default location. Here is one sample dhclient.conf file:

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name "sl6x";
send fqdn.fqdn "sl6x.vmware.davenjudy.org";
send fqdn.encoded on;
send fqdn.server-update off;

request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, domain-search, host-name,
        netbios-name-servers, netbios-scope, interface-mtu,
        rfc3442-classless-static-routes, ntp-servers;
require subnet-mask, domain-name-servers;

Just a reminder that I disabled NetworkManager (chkconfig NetworkManager off) in order to get the network start up scripts to pick up my dhclient.conf file. NetworkManager dynamically creates it's own dhclient.conf file each time it runs as I described in Part 6.

The other interesting client side file for Red Hat systems is /etc/sysconfig/network-scripts/ifcfg-eth0. This is what finally worked for me for both Scientific Linux 6 (RHEL 6 clone) and Fedora 14:

cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
# NM_CONTROLLED="yes"
ONBOOT=yes
TYPE=Ethernet
BOOTPROTO=dhcp
DHCP_HOSTNAME=sl6x
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=yes
NAME="System eth0"
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
IPV6_AUTOCONF=yes
DHCPV6C=yes
# IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
HWADDR=00:0C:29:2C:3A:9D
PEERDNS=yes
PEERROUTES=yes

Note that I set BOOTPROTO to dhcp and set IPV6_AUTOCONF to yes. This gets me what I understand to be the correct configuration of both the radvd assigned IPv6 address and the IPv6 address assigned by the DHCP server.

Getting the Fedora 14 system to work took one additional step. After configuring it exactly the same way I had configured the Scientific Linux system, it still wouldn't insert it's dDNS entry into the zone file on the server. I finally backed out the dhclient RPM that is used by Fedora 14 and instead installed the dhclient RPM from Fedora 13. This bumped down the dhclient version from 4.2.1 to 4.1.1 which matched both the Scientific Linux 6 and Ubuntu 11 versions. I immediately got a dDNS entry for the Fedora 14 system. I'll have to come up with an exclude rule to keep yum/up2date from updating the dhclient to 4.2.1.

Just for completeness, my Ubuntu 11 virtual machine uses the "same" dhclient.conf file documented above. It still runs NetworkManager but my dhclient.conf file gets used for setting up the IPv6 interface since it's in the default location.

What still isn't working is getting reverse dDNS entries working through DHCP. Both the Natty and Fedora VMs managed to get updates into the reverse zone for IPv6 at one point so I'm not sure why that isn't happening now. At the moment I'm ecstatic that at least forward dDNS is working and somewhat exhausted.

Today also marks 30 days since I downloaded the evaluation copy of Red Hat Enterprise Linux (RHEL) 6. On schedule, updates stopped working. Apparently CentOS 6 should be out shortly or there's always Scientific Linux but I'll need to rebuild the server.

Cheers,
Dave