Running IPv6 on Linux

IPv6 is still changing and a lot of the applications and procedures
have little or no documentation. Not for the faint hearted.

Requirements

A static IPv4 address.

v6-in-v4 tunnelling requires fixed addresses for both ends of the
tunnel. Does not have to be a permanent link but easier if it is.

Preferably outside a firewall.

If your IPv6 box is behind a firewall or masquerade box, you will
still be able to run IPv6 out (they are just IPv4 packets outside your
box) and other sites can reply. However the rest of the IPv6 world
cannot start sessions to you nor trace any routing problems, better to
use a box outside the firewall.

A working kernel that supports IPv6.

Effectively a 2.1.x kernel. There were some patches for 2.0.30 but
they are well out of date. The IPv6 kernel code changes as the RFCs
and Internet drafts change so use a recent "reliable" kernel. 2.1.35
with some significant kernel patches worked but is getting a bit old.
2.1.42 works well apart from a TCP/IPv6 checksum problem, a small patch
fixes it.

Fetch the latest inet6-apps kit from ftp.inner.net.

Craig Metz runs
inner.net. He dislikes people using a browser to fetch files, he
prefers normal ftp. There are actually two ftp servers,
ftp.ipv6.inner.net will only accept transfers from IPv6 hosts,
ftp.inner.net will accept IPv4 or IPv6. New versions are put on
ftp.ipv6.inner.net first then a week or so later on ftp.inner.net.
Both servers reject transfers unless you have a valid reverse name
delegation in place. You must have an IPv6 setup with a valid address
delegation before you can get IPv6 applications from
ftp.ipv6.inner.net ­ Catch 22. Fortunately he will relax
that rule if you send email and promise to get your address delegation
sorted out "soon".

inet6-apps is required. inner-apps contains utilities like fingerd,
netd and ipfwdump. tcpdump (which needs libpcap), traceroute and
telnet are recommended. Programs such as sendmail, trn, inn are only
required if you want to send mail or news over IPv6.

Where IPv6 programs are not upwards compatible with IPv4, they tend
to install into /usr/inet6/*bin, leaving the IPv4 versions in
/usr/*bin. You need to put the inet6 directories at the front of the
PATH for testing. If you hit problems using an IPv6 utility, try the
IPv4 one with an explicit path.

Compile and install inner-apps if desired.

For libpcap and tcpdump "./configure --prefix=/usr" to replace
the IPv4 tcpdump (it is upwards compatible). Use --prefix=/usr/inet6
to keep them separate.

Install the latest net-tools kit from
http://www.tazenda.demon.co.uk/net-tools-970528.tar.gz.
By default this overwrites the IPv4 versions, no problems so far.

NOTE: The following describes the procedure for RFC 1897.
It is not clear how much longer this will be used before being replaced
with a procedure based on draft-ietf-ipngwg-testv2-addralloc-00.txt.

Compute your prefix using the algorithm in RFC 1897. Read the
document carefully. If you don't know why to do otherwise, compute a
64-bit prefix. To do this you need to know the ASN of your provider
(FYI, Telstra is 1221).

Also have a look at http://www.ibs-us.net/ipv6/. There is a form
which will compute
your prefix in two variations. But you still have to read RFC 1897 to
know what you are filling in.

Tentative new [TEST] process. Based on email from Bob Fink, it
looks like this will be the format of new test 6bone addresses.

"NLA1 would be our TLA equivalent, that is, up to 256 Backbone sites acting
as our version of TLAs. I doubt that we would have more than 256 backbone
sites, but if we got close to that we could practice our implementation of
TLA assignment requirements (see [AGGR]).
The NLA delegation works in the same manner as CIDR delegation in IPv4
[CIDR]. NLA1s are required to assume registry duties for the NLAs below
them, NLA2s for those below them, etc.
At this time I would propose a nominal usage for our current 6bone topology
that only has one level below a backbone site that looks like:

Then the transit (intermediate backbone) site would sequentially assign
Site IDs, or use ASN numbers as long as they are unique in the NLA.
If there was no transit site between the backbone and leaf site, then the
NLA2 field would be set to zeros."

Compute your prefix using one of the above algorithms. Read the
documents carefully. If you don't know why to do otherwise, compute a
64-bit prefix for RFC 1897, compute a 48 bit prefix for [TEST]. For
RFC 1897 you need to know the ASN of your provider.

Once the prefix is known, copy the sample radvd.conf to
/usr/ipv6/etc and change the prefix to match your net.

bb is your backbone site, tt is your transit site (if any), ssss is
the site number within the transit site, cccc is the customer network
number.

Find your connection point. You want somewhere that is the
topologically closest transit site that is clueful enough to be
depended on.

Look at
http://www-cnr.lbl.gov/6bone/6bone-drawing.html for a global
overview of the 6bone structure. You can click on the names in the
drawing to get the RIPE entry of a site. Look at the first field of
the tunnel: lines in the RIPE entries and do some traceroutes to those
addresses. According to IPv4 traceroute, CICNET is my nearest
transit/backbone node, 5 extra hops from
Fddi0-0.lon5.Melbourne.telstra.net. YMMV, depending on your ISP.

Ask them to set you up a tunnel. You will need to provide them
with your IPv6 prefix and the IPv4 address of your IPv6 router.

Install the skeleton rc.inet6 from ftp.inner.net and fill in the
appropriate blanks. router-6.ocs.com.au has the following (still RFC
1897 based) :-