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

IPv6 on a home network (Part 2)

By DaveAtFraud - Posted on 02 March 2011

Part 1 described the preliminaries of just getting an IPv4 network set up using virtual machines (VMs) under VMware ESXi. This included configuring the CentOS 5.X VM as a server/router and establishing two more client VMs, one running Ubuntu and the other also running CentOS 5.X. The Ubuntu VM was upgraded from 9.04 to 10.04 once connectivity was established. Once the VMs were all functioning and stable, it was time to start playing with IPv6.

While getting the initial IPv4 configuration of the VMs established, I was reading the IPv6 Deployment Guide. This gave me some excellent background and a desire to actually see how things worked.

My first step was to simply establish IPv6 connectivity between the various VMs. This was fairly simple since I had already installed radvd on the server/router. I then configured radvd using an example I ran across on the Internet. radvd then supplied routing information to the other VMs which then requested and were provided with IPv6 addresses by radvd. These addresses consisted of the prefix that radvd was configured to use followed by the MAC address for each VM's virtual NIC with ff:fe inserted into the middle of the MAC address. One thing nice about doing this work on a VM under ESXi is that I knew that none of my IPv6 tests could "leak out" onto the Internet until I found a way to establish IPv6 connectivity.

The next step after getting simple connectivity established was to actually get an IPv6 connection to the Internet. Unfortunately, my ISP hasn't even begun any sort of IPv6 roll-out. Luckily, some of my searches led me to GoGo6 and FreeNet6.

I downloaded, built and installed the GoGo6 client software (gogoc) on the server/router and fired it up. As per their advertisements, I was immediately on-line to the IPv6 Internet. A useful site for confirming this and doing additional testing is gogoc connects a host to the IPv6 Internet by establishing a "tunnel" connection that tunnels IPv6 traffic through your existing IPv4 Internet connection to a GoGo6 server that routes the traffic to the IPv6 Internet. IPv6 traffic goes through the tunnel while IPv4 traffic makes its way to the Internet using your existing connection and, what's nice is, this all happens transparently.

Configuring gogoc is really simple and is well documented on both the GoGo6 web site and in the configuration file itself. Mentioned in the documentation but very important if you want to keep the same IPv6 address is to change the server selection to a specific server.

The next step was to get the server/router actually working as a router. GoGo6 also offers a full /56 IPv6 address allocation which is obtained by running a different client, gw6c. This can be a little hard to find but comes as a pre-built binary. You simply download it, unpack it and run it. This is where things got interesting for me.

The first problem was that running gw6c didn't appear to do anything (no errors, no warnings, no output). I finally decided to turn on console logging in the configuration file. This resulted in a bunch of status type output and the following:

RUDP packet 0, RTO 2.512928, sequence 0xf00000f4 timestamp 1321.
Reply: RUDP packet 0, RTO 2.512928, sequence 0xf00000f4 timestamp 1321.
Received: '200 Success
<tunnel action="info" type="v6udpv4" lifetime="604800">
    <address type="ipv4"></address>
    <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:8f60</address>
    <address type="ipv4"></address>
    <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:8f61</address>
    <address type="dn"></address>
      <prefix length="56">2001:05c0:110c:c100:0000:0000:0000:0000</prefix>
    <keepalive interval="30">
      <address type="ipv6">2001:05c0:1000:000b:0000:0000:0000:8f60</address>

The next problem was to figure out how to "integrate" this new information both into my network and into how the server/router connected to GoGo6. After lots of trials and lots of errors what I finally came up with was configuring radvd (in /etc/radvd.conf) as follows:

interface eth1
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix 2001:05c0:110c:c100:0000:0000:0000:0000/64
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;


The "prefix" setting comes from the <router> tag in the gw6c output shown above. The goofy part of getting this working was I flailed at trying various combinations of settings but could not establish at IPv6 connection from my clients through the router to the IPv6 Internet. After posting some inquiries about what I was missing, I finally decided to reboot the server/router VM and start clean. When the VM came back up, it just worked. I hate it when that happen but the only thing worse is when that doesn't happen and you're left with a system that still doesn't work.

A few other things that had to be set up were turning on IPv6 forwarding and turning off any firewalling of packets coming in from the clients. Turning on IPv6 forwarding is accomplished using a sysctl command which I included in /etc/rc.d/rc.local:

# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl -w net.ipv6.conf.all.forwarding=1

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to --destination \! --source

setenforce 0

You will note that I also turned off SELinux and included the commands for IPv4 NAT and forwarding. Turning off firewalling of packets from the internal network was accomplished by just adding an accept command to /etc/sysconfig/ip6tables:

:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT

Both clients and the server/router test IPv6 clean at The one thing I didn't have working was the ability to use node names for IPv6 access. That is, the only way I could ping6 the client VMs was to actually enter the client's full IPv6 address. Research to this point indicates that dynamic DNS updating is NOT included in the CentOS DHCP server for IPv6 (dhcp6s). At some point I will look into crafting a perl script to perform the function using nsupdate.

Besides getting dynamic DNS updates going, the next task (to be documented in Part 3 of this series) is to find out which services work and which have "issues" with IPv6. This will include both internal services such as dovecot IMAP and external services such as Apache HTTPd and Sendmail.