This Mini-HOWTO is a very brief discussion of what I had to do to get ipv6
working on my internal lan so that everybody could access outside ipv6
addresses, yet prevent people from outside being able to connect back in
to our internal network. It works by having one Linux box act as the
ipv6 gateway and tunnel ipv6 traffic to a tunnel broker (several free
ones are available), and it can tunnel with either a direct internet
connection, a firewalled internet connection, or a NAT'ed internet
connection, and it will handle all of these automatically. This
Mini-HOWTO discusses using CentOS, Mandriva, and Gentoo as both the
gateway and as clients.

Register an account at go6.net. (There are several
ipv6 tunnel brokers out there that will give you a free ip or netblock,
but I chose to use go6.net and this Mini-HOWTO is based on that assumption.)
There was no rocket science in my choice for go6.net over, for example,
sixxs.net. It was simply the first one I stumbled upon when I Googled
for ipv6 broker. They all seem to be equal in terms of what they offer,
differing only slightly in how they go about offering it to you.

Decide which machine is going to be the gateway machine. There are
some very specific requirements. First, it must have a fairly recent
kernel and iptables. At one location I'm using a Gentoo box with kernel 2.6.23 and
iptables 1.4.0. At another location I'm using a Mandriva box with kernel 2.6.22 and
iptables 1.3.7. It should also work with the latest Fedora Core
release, as well as the latest CentOS 5 or RedHat EL 5 release. This
machine will need to have ipv6 support enabled and ipv6
autoconfiguration enabled. In the case of my Ubuntu box, this results
in an eth0 interface that looks like this:

The "Scope:Link" address is an automatically generated ipv6 address that
is designed to work ONLY on the local LAN. (network fe80::/16) Step 14
shows what the ethernet IPs will look like once this procedure is
finished.

Install the radvd package. For Gentoo, 'emerge radvd'. For CentOS,
configure and enable the DAG repo and 'yum install radvd'. For Mandriva, it takes
a few extra steps.

Mandriva:

useradd radvd
mkdir /var/run/radvd
chown radvd:radvd /var/run/radvd

Download the source for gw6c from go6.net (aka freenet6.net). At the
time of this writing (Jan 2008), the current version of gw6c is 5.1.
gw6c is an abbreviation for Gateway 6 Client, the name of the software
we'll be using. Gentoo users can 'emerge freenet6' if you choose, but
you'll have to know where your config files are because they'll be
different than what I describe here.

When you extract gw6c tarball, it will extract into the current
directory, so force it to extract into a subdirectory to keep the
current directory clean:

userid -> the user you registered at go6.net
passwd -> and the password for that user
server=broker.freenet6.net
auth_method=any
host_type=router
if_prefix -> the ethernet interface facing your local LAN
log_file=2
log_filename=/usr/local/gw6c/logs/gw6c.log

Create an init script for the gw6c service in /etc/init.d/gw6c or use
one of the following init scripts (current as of Jan 2008). These init
scripts take into account that the radvd service will be started by
gw6c, and shuts it down. You do *NOT* want to start the radvd service
from the init script nor at boot time automatically. The gw6c will
handle starting radvd if you have gw6c configured to get a network
(instead of a single IP) from go6.net.

Note the new address with the 2001::/16 prefix. That is the new
ipv6 address that has been automatically created on the
interface using the 2001:9999:8888::/64 network which was
assigned to us by the gw6c client. Per convention, 2001:9999:8888::/64
is shorthand for 2001:9999:8888:0000::/64. Additionally, much
like an ipv4 network where people typically put 192.168.0.1 as
the default gateway for the 192.168.0.0/24 network, the gw6c
client automatically assigns 2001:9999:8888::1/128 to the gateway
interface (if_prefix=eth0). I have not seen this convention in
any RFC, but this is the way gw6c does it.

If you configured your machine as 'host_type=router', then gw6c
did a second step for you as it started. It created a temporary config file for radvd
at /usr/local/gw6c/radvd-gw6c.cfg. If for some reason it cannot start radvd, then the
gw6c startup will fail. So if gw6c fails to start, one of the things to check is if
radvd has some kind of error condition that causes it to fail its startup. In my
tests where radvd failed to start, gw6c logged a message saying that it started up ok
and assigned an ip, but then radvd logged an error (at that point both daemons died
with no further logging). What's misleading is the init script said that it started ok.
You must pay attention to the previous step for the sequence to verify that everything
started up properly.

Turn off the service because currently it's not firewalled and
anybody can ping/ssh to your machine, even if you're behind an ipv6 NAT
gateway. Why? Because you're tunnelling to go6.net and getting
globally reachable IP addresses. The next step will take care of that.

You can uncomment the line with ipv6-icmp if you choose. This line
allows all ping6 and tracepath6/traceroute6 tests to work both inbound
and outbound. If commented, ping6 and tracepath6/traceroute6 only work
from the inside. PAY ATTENTION: People can ping your
internal hosts from the outside with that line enabled. They can't ssh
or browse to it, but they'll be able to ping it, so they will know
things like when employees are at work (when not to try to break in to
some machine or when they're not at home) and other social engineering
type things like that.

Stateless autoconfiguration is the end goal of this
whole procedure. The gist of stateless autoconfiguration is that the
radvd process advertises a /64 network (the first 64 bits). The ipv6
enabled host will see this advertisement and the host generates the
last 64 bits of the host address. Here's how to make sure that your
host is ipv6 enabled.

CentOS: If you didn't specifically disable ipv6 during the installation
or at any time during the gui/ncurses configuration step, ipv6 should be
enabled. Here's how to check:

Again, this is stateless autoconfiguration at work.
Your server is advertising 2001:9999:8888::/64 as a valid network, but
where did the second 64 bits of address come from? (the
21d:9ff:fe76:f558 portion). It is automatically generated using what's
called EUI-64. It's based upon your 48 bit MAC address. Look at the
MAC above and compare to the last 64 bits of the ipv6 address you'll see
that it is very similar. The exact generation formula is described in
Appendix A of RFC 4291.

Test to see if you can ping6 www.kame.net or some other known ipv6
site. It should all be working now.

Add a little bit of resiliency by making a quick
cronjob that will test if the daemon is still running and restart it
if it is not. Like any service which is tunnelled, occassional
disconnects happen and this is a simple way of correcting it. I
achieve this using this:

Test from somewhere outside and make sure that your
hosts are not reachable from the outside (several webbased ipv6
testers are available if you google for it). Note that if you allowed
icmpv6 in the firewall by uncommenting that icmpv6 line, you'll be able
to ping the host, but you won't be able to connect to anything via tcp
or udp. If you specifically blocked icmpv6 by leaving that line
commented, then you won't be able to ping the host either. In this
example, I allowed ping:

Also interesting is 4193
if you choose to implement a local subnet that you manually create,
do dns for, and maintain (it can still generate automatically the
second 64 bits of space, same as is done here.) There is a webbased
form that will do the autogeneration of your own unique local subnet
that is supposed to be globally unique, but since it's not a routable
prefix, it is relatively safe (think 192.168.*.* or 10.*.*.* in the
ipv4 world but without NAT capability, you'd use your globally unique
public routable IP instead and rely on the firewall to keep anything
you don't want from penetrating to your box).

I try to keep up with everything that's happening in the
ipv6 world. See what things I have been reading when it comes to ipv6 on my
Del.icio.us bookmark page.