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

IPv6 on a home network (Part 4)


By DaveAtFraud - Posted on 20 March 2011

I ended Part 3 of this series stating that I would look into "building my own" version of the Internet Software Consortium (ISC) client for my Ubuntu 10.10 system or just moving to an early version of the next Ubuntu release. Let's just say that building my own DHCP client and integrating it into the Ubuntu network start-up scripts was a bigger undertaking than I had imagined. Instead I pulled down an alpha version of Ubuntu "Natty Narwhal". The Natty release is surprisingly stable for an alpha but, unfortunately, had the same problem as 10.10: I still got the message, "client6_recvreply: unexpected reply."

Somewhere in my many Google searches I ran across a blog that claimed to have gotten DHCP working with IPv6 with both a Ubuntu server and client by back porting the Natty Narwhal DHCP software. This indicated to me that the problem was in having a different client from the server especially since the CentOS 5X DHCP cliwnt successfully interacted with the CentOS DHCP server. Since I wasn't in a position to roll my own collection of clients and server, I decided to see what would happen if both client and server were the same version of ISC DHCP software albeit from different Linux distributions.

The first problem with converging the various systems on the ISC 4.1 DHCP software is that CentOS 6 (which includes both the ISC 4.1 server and client) hasn't been released yet. The work around I cam up with was to download an evaluation copy of Red Hat Enterprise Linux 6 (RHEL 6) and use it as my server operating system. Since I will probably upgrade any of my systems on CentOS 5.X to CentOS 6 when it's released, this would also allow me to determine what other changes are headed my way with CentOS 6. My experience has been that CentOS creates a near perfect clone of RHEL although the only support for CentOS is through "the community."

Once I had RHEL6 installed on a new Virtual Machine (VM) I set about trying to get to the same level of functionality that I had working with my CentOS 5X server. The first problem was getting Domain Name Services (DNS or bind) working. The version of bind included with RHEL 6 in 9.7.0 while CentOS 5.5 uses version 9.3.6. While I'm sure that there are significant internal differences between the two versions the visible difference is that RHEL 6 ships with DNSSEC enabled by default and there appears to have been a tightening of the security features such that I had to add my IPv6 address range to my "trusted" access control list (ACL). I also had to explicitly point my RHEL nameserver at my normal DNS with a "forwarder" statement. Finally, in order to get things working, I turned DNSSEC off but plan to turn it back on and have it working before the end of this project (I also have SELinux set to "permissive" since I don't need to have it stopping things while I'm attempting to debug basic functionality). These changes resulted in a named.conf that looks like:

acl "trusted" {
        localhost;
        192.168.0.0/16;
        172.16.0.0/12;
        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 port 53;
        query-source-v6 port 53;

        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;};

        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; 
        };
};

#        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 port 53;
        query-source-v6 port 53;

        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;};

        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; 
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "vmware.davenjudy.org" IN {
        type master;
        file "vmware.davenjudy.org";
        allow-query {
                trusted;
        };
        allow-update {
                trusted;
        };
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { 
                none; 
        };
};

// 127.0.0.0/24  The loopback network.
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        // Every DNS server should be a master
        // for 127.0.0.0/24.
        allow-transfer {
                none;
        };
        allow-update { 
                none; 
        };
};

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;
        };
};

I had the CentOS 5X server working with keyed updates to the zone files but was only able to get the RHEL 6 server to update the zone files by saying updates are allowed by systems in the "trusted" ACL. Getting this back to working with the more secure keyed updates is another item on my "to do" list.

Obviously, getting DHCP working was the real challenge and it was. This took only some fairly obvious changes to the default dhcpd6.conf file supplied by Red Hat:

#
# 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
#

# 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","davenjudy.org";

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

# Server side command to enable rapid-commit (2 packet exchange)
option dhcp6.rapid-commit;

# The path of the lease file

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

subnet6 2001:5c0:110c:c000::/64 {
#        range 3ffe:ffff:100::40 to 3ffe:ffff:100::c0/64;
         range6 2001:05c0:110c:c000::40 2001:05c0:110c:c000::c0;
}

The changes for the DHCP client were also not extensive but the trick was in figuring out what was needed:

# Configuration file for /sbin/dhclient, which is included in Debian's
#       dhcp3-client package.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
#       man page for more information about the syntax of this file
#       and a more comprehensive list of the parameters understood by
#       dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
#       not leave anything out (like the domain name, for example), then
#       few changes must be made to this file, if any.
#

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

send host-name "natty-alpha3";
send fqdn.fqdn "natty-alpha3.vmware.davenjudy.org";
send fqdn.encoded on;
send fqdn.server-update off;
        also request fqdn, fqdn6.fqdn;
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;

This configuration at least got a forward entry for natty-alpha3 into the appropriate zone file. I don't like the idea that each client has to be individually configured to send its host name in the dhclient.conf file. What also still isn't working is getting the IPv6 nameserver information into the client's resolv.conf and getting a reverse pointer set up. There will also be some clean-up required on the various configuration files but that is a much lower priority.

Cheers,
Dave