IPv6 – getting your LAN connected
This article describes how I got my gateway and LAN operating with IPv6. What is IPv6?
Ask Google with this
query. In short, IPv6 avoids
the problems you solve with NAT today. IPv6 is a bigger address space. It means each
of your computers can have their own public IP address. Compare that to what you are
using now, IPv4. You probably use NAT (Network Address Translation) because your ISP
gives you only one IP address. NAT traditionally causes communication problems with
many common protocols. These can be worked around, but it is much easier if you
don’t have to do NAT.
For more background information on IPv6, try these references:
IPv6 is not widely deployed. It is a rare ISP that offers IPv6 connections. And the
number of services (websites, etc) available on IPv6 is lower. So why use IPv6? To
learn more about it. Plus, there’s the coolness factor of having your webserver
accessible via IPv6.
You need a tunnel
IPv6 is still fringe. However, it is gainly in popularity. The most popular way to
get IPv6 connectivity is through a tunnel broker. A tunnel broker will allocate you
a block of IPv6 addresses and set up a tunnel through which your IPv6 communications
will be transported over traditional TCP/IP.
There are a large number of organizations that offer IPv6 tunnels.
In fact, finding a tunnel broker
is easy. If you just want to play and see if you can get things going, then forget
about it, any tunnel broker will do. If you get serious, and actually start using
IPv6 in anger, you will want to choose your tunnel broker with care. Ask around.
See what others are using. Go by their recommendations.
For me, I went with Hurricane Electric. Why?
Because the sysadmin at work went with them. So that’s who I used. That may not
be who I stick with, but that’s who I got started with.
Regardless of your choice of tunnel broker, the basic information you get from
them should be the same. Therefore, this article will not be specific to any
one tunnel broker.
Configuring FreeBSD
FreeBSD has supported IPv6 since version 4.0; all you need to do is configure it.
This is pretty easy, once you know what to do. For this article, I used FreeBSD 4.11
and 4.10. The methods should be similar for 5.* and 6.*.
I’ll start by giving you the basic commands, and then show you how to configure your
system to establish the same setup after booting up.
In the following example, assume these definitions (none of these are my IP addresses;
in fact, I’ve converted all my real IP addresses to something in the 2001:0DB8:0:8002:/64
range – these are allocated for example purposes — not that I could find an actual
reference to this – I relied upon third party information):
- 10.10.10.10 – Your IP address, most likely that of your gateway. It’s the
address your ISP gives you. This IP address will be one end of the tunnel. - 10.20.20.20 – The address of your tunnel broker’s server. This will be the
other end of the tunnel. - 2001:0DB8:0:8002:EAF – The IPv6 address assigned to your end of the tunnel.
- 2001:0DB8:0:8002:EAE – The IPv6 address of the other end of the tunnel.
- 2001:0DB8:0:8002:F00:: – Your prefix allocation, provided by your tunnel broker.
There. That is it. That is everything you need to create your tunnel. And here are
the commands you issue:
ifconfig gif0 create ifconfig gif0 tunnel 10.10.10.10 10.20.20.20 ifconfig gif0 inet6 2001:0DB8:0:8002:EAF 2001:0DB8:0:8002:EAE prefixlen 128 route -n add -inet6 default 2001:0DB8:0:8002:EAE ifconfig gif0 up
Try making the appropriate substitutions in the above commands and issue them on
your gateway. Your interfaces should now look similar to this:
$ ifconfig fxp0
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::204:acff:fea3:74af%fxp0 prefixlen 64 scopeid 0x1
inet 10.10.10.10 netmask 0xffffff80 broadcast 70.26.229.255
ether 00:04:ac:a3:74:af
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
$ ifconfig gif0
gif0: flags=8051 mtu 1280
tunnel inet 10.10.10.10 --> 10.20.20.20
inet6 fe80::204:acff:fea3:74af%gif0 prefixlen 64 scopeid 0x8
inet6 2001:0db8:0:8002:eaf --> 2001:0db8:0:8002:eae prefixlen 128
In the above, I have highlighted the public IP address provided by my
ISP (and yes, I’ve used 10.10.10.10 only as an example; it’s not my
real IP address).
Try pinging an IPv6 address, such as your tunnel broker’s server.
You should see something like this:
$ ping6 2001:0DB8:0:8002:EAE PING6(56=40+8+8 bytes) 2001:0db8:0:8002:eaf --> 2001:0db8:0:8002:eae 16 bytes from 2001:0db8:0:8002:eae, icmp_seq=0 hlim=64 time=313.243 ms 16 bytes from 2001:0db8:0:8002:eae, icmp_seq=1 hlim=64 time=321.113 ms 16 bytes from 2001:0db8:0:8002:eae, icmp_seq=2 hlim=64 time=321.065 ms 16 bytes from 2001:0db8:0:8002:eae, icmp_seq=3 hlim=64 time=313.711 ms ^C --- 2001:0DB8:0:8002:EAE ping6 statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/std-dev = 313.243/317.283/321.113/3.810 ms
If that works, you’re connected! Now you can try accessing something out there…
I suggest the KAME Project, the home of BSD IPv6.
If you see an animated turtle, you’ve reached it via IPv6. If not, you’re using IPv4.
lynx is an IPv6-aware browser.
Here is a screen shot of what I see via IPv6 when I issue this command
lynx http://www.kame.net/:
Webpage of Kame Project (p1 of 4)
KAME Project
[kame-anime-small.gif]
dancing kame by atelier momonga
KAME Project is a joint effort of six companies in Japan
to provide a free IPv6 and IPsec (for both IPv4 and IPv6) stack for BSD variants
to the world.
* 7th Nov. 2005: An announcement of conclusion of the KAME project
+ An announcement from the WIDE project
+ An announcement from the KAME project
* Newsflash! New!
+ Nov 17, 2005: KAME snap releases will not follow *BSD releases toward
the project conclusion (Please see this message for further detail)
+ Oct 8, 2005: mcast-tools project will maintain/develop/release our
multicast-related programs. (Please see this mail for further detail)
+ July 19, 2005: OS upgrade is recommended for SNAP users using IPsec-AH.
(Please see this page for further detail).
+ July 11, 2005: Newsletter: "SHISA How To"
+ May 16, 2005: OS upgrade is recommended for KAME-FreeBSD users. (Please
see this page for further detail).
+ Past newsflash
* Latest releases
+ KAME SNAP (weekly)
o List of mirror servers
o Supported platforms: FreeBSD 5.4-RELEASE, NetBSD 2.0, and OpenBSD
3.6.
+ Platforms with KAME code merged in:
o FreeBSD 4.0 and beyond
o OpenBSD 2.7 and beyond
o NetBSD 1.5 and beyond
-- press space for next page --
Arrow keys: Up and Down to move. Right to follow a link; Left to go back.
H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=history list
Near the top of the page you will notice [kame-anime-small.gif]. That means
you’re using IPv6. Congratulations!
Making it happen every time!
This section will detail how to configure your gateway so that it sets up your
IPv6 tunnel every time it boots. Here are the directives I added to
/etc/rc.conf:
# our IPv6 tunnel ipv6_enable="YES" gif_interfaces="gif0" gifconfig_gif0="10.10.10.10 10.20.20.20" ipv6_ifconfig_gif0="2001:0DB8:0:8002:EAF 2001:0DB8:0:8002:EAE prefixlen 128"
With that, your IPv6 should be automagically established for you after every boot.
Personally, when I add such critical entries to my configuration files, I like to test
them. So I rebooted the gateway. After the reboot, your ping6 should still work as
described above.
OK, the gateway works. Now what about the rest of my LAN?
What you have achieved so far is sufficient if all you have is one computer. If you have
other systems inside your gateway, this section will show you how I set up my LAN so that
my workstation could also use IPv6.
IPv6 comes with automatic route advertising. This allows systems to easily find the
gateway without being told where it is. Of course, you can still see the gateway
manually. Automatic is good enough for most situations. rtadvd is what
is used on FreeBSD to advertise such routes. It should run on your gateway and can
be started at boot time with these directive in your /etc/rc.conf file:
ipv6_gateway_enable="YES" rtadvd_enable="YES" # let our LAN know the IPv6 default route rtadvd_interfaces="fxp1" # our private LAN
The first directive indicates that this computer should forward IPv6 packets, much like
your gateway already does for IPv4. The next two lines indicate that the route
advertising daemon should be run, and it should broadcast only on the inside interface.
In this case, fxp1 is the NIC connected to our private LAN.
You don’t want to advertise publicly. Only your LAN cares about your gateway. The world
does not need to know about it.
You also need to tell rtadvd just what it is that it should be advertising.
This is done with the following entries in /etc/rtadvd.conf:
fxp1:\
:addrs#1:addr="2001:0DB8:0:8002:F00::":prefixlen#64:tc=ether:
In the above, you’ll see that the NIC is in bold. You’ll want to change
that to the same NIC you specified in /etc/rc.conf. The other bit in bold
is your prefix allocation. Change both to suit your tunnel broker.
As previously mentioned, I like to fully test such configuration changes, so I rebooted
the box. After start up, I verified that the right things were running:
$ ps auwx | grep rtadvd root 165 0.0 0.1 948 544 ?? Ss Sat01PM 0:00.43 rtadvd fxp1
Yep, there it is. running. Now let’s set up the client machine with this simple
entry in /etc/rc.conf:
ipv6_enable="YES"
Yes, I know I don’t have to reboot, but I did reboot the client. After that, here’s
what I found on the NIC:
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::204:acff:fed3:7823%fxp0 prefixlen 64 scopeid 0x1
inet 10.55.0.23 netmask 0xffffff00 broadcast 10.55.0.255
inet6 2001:0db8:0:8002:f00:204:acff:fed3:7823 prefixlen 64 autoconf
ether 00:04:ac:d3:78:23
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
This is good. Good. It has an IPv6 address in the right range. If you also looked at
the output of netstat -nr, you would see a default route to the gateway.
That would look something like this:
Internet6: Destination Gateway Flags Netif Expire 2001:0db8:0:8002:f00::/64 link#1 UC fxp0
Now, from the workstation try pinging the end point of our tunnel. I warn you, it will fail! Why?
The gateway doesn’t know about the LAN yet (from an IPv6 perspective). The ping reply
will go out through your tunnel. But let’s proceed anyway. Here’s the ping on the
workstation on my LAN:
$ ping6 2001:0db8:0:8002:eaf PING6(56=40+8+8 bytes) 2001:0db8:0:8002:f00:204:acff:fed3:7823 --> 2001:0db8:0:8002:eaf ^C --- 2001:0db8:0:8002:eaf ping6 statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
And here is the tcpdump output on the fxp1 NIC on the gateway:
# tcpdump -ni fxp1 icmp6 tcpdump: listening on fxp1 14:07:39.958704 2001:0db8:0:8002:f00:204:acff:fed3:7823 > 2001:0db8:0:8002:eaf: icmp6: echo request 14:07:40.958906 2001:0db8:0:8002:f00:204:acff:fed3:7823 > 2001:0db8:0:8002:eaf: icmp6: echo request 14:07:41.959097 2001:0db8:0:8002:f00:204:acff:fed3:7823 > 2001:0db8:0:8002:eaf: icmp6: echo request 14:07:42.959313 2001:0db8:0:8002:f00:204:acff:fed3:7823 > 2001:0db8:0:8002:eaf: icmp6: echo request 14:07:43.959506 2001:0db8:0:8002:f00:204:acff:fed3:7823 > 2001:0db8:0:8002:eaf: icmp6: echo request ^C 61 packets received by filter 0 packets dropped by kernel
Where are the ping replies going? Out the tunnel. It took me a while to realize this, but trial
and error, plus sudden inspiration found the answer:
# tcpdump -ni gif0 icmp6
tcpdump: WARNING: gif0: no IPv4 address assigned
tcpdump: listening on gif0
14:10:32.956333 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:33.630833 fe80::4047:8052 > 2001:0db8:0:8002:eaf: icmp6:
redirect 2001:0db8:0:8002:f00:204:acff:fed3:7823
to 2001:0db8:0:8002:f00:204:acff:fed3:7823 [class 0xe0]
14:10:33.630910 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:33.956530 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:34.650356 fe80::4047:8052 > 2001:0db8:0:8002:eaf: icmp6:
redirect 2001:0db8:0:8002:f00:204:acff:fed3:7823
to 2001:0db8:0:8002:f00:204:acff:fed3:7823 [class 0xe0]
14:10:34.650438 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:34.956701 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:35.649427 fe80::4047:8052 > 2001:0db8:0:8002:eaf: icmp6:
redirect 2001:0db8:0:8002:f00:204:acff:fed3:7823
to 2001:0db8:0:8002:f00:204:acff:fed3:7823 [class 0xe0]
14:10:35.649862 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:35.956923 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
14:10:36.638624 fe80::4047:8052 > 2001:0db8:0:8002:eaf: icmp6:
redirect 2001:0db8:0:8002:f00:204:acff:fed3:7823
to 2001:0db8:0:8002:f00:204:acff:fed3:7823 [class 0xe0]
14:10:36.638706 2001:0db8:0:8002:eaf > 2001:0db8:0:8002:f00:204:acff:fed3:7823: icmp6: echo reply
^C
15 packets received by filter
0 packets dropped by kernel
How do we solve this? Give the gateway an IPv6 address on fxp1. That will set up the correct
default route and the ping reply will work.
Making the gateway function like a gateway
Here are the additional /etc/rc.conf entries
on the gateway:
ipv6_ifconfig_fxp1="2001:0DB8:0:8002:F00::1 prefixlen 64"
After a reboot, not strictly necessary, you can set this IPv6 address by hand, but I like to be sure
it’s working correctly, this is what I found on fxp1:
$ ifconfig fxp1
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.55.0.1 netmask 0xffffff00 broadcast 10.55.0.255
inet6 fe80::204:acff:fed3:7012%fxp1 prefixlen 64 scopeid 0x2
inet6 2001:0db8:0:8002:f00::1 prefixlen 64
ether 00:04:ac:d3:70:12
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Once that is set, netstat -nr will show a default route for your prefix. Try it for yourself.
Now your pings will work:
$ ping6 2001:0db8:0:8002:eaf
PING6(56=40+8+8 bytes) 2001:0db8:0:8002:f00:204:acff:fed3:7823 --< 2001:0db8:0:8002:eaf
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=0 hlim=64 time=341.415 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=1 hlim=64 time=0.223 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=2 hlim=64 time=0.232 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=3 hlim=64 time=0.217 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=4 hlim=64 time=0.223 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=5 hlim=64 time=0.200 ms
16 bytes from 2001:0db8:0:8002:eaf, icmp_seq=6 hlim=64 time=0.223 ms
^C
--- 2001:0db8:0:8002:eaf ping6 statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.200/48.962/341.415/119.393 ms
Once that works, you should be able to get to anywhere on the IPv6 network from your workstation.
You should also be able to repeat the client configuration on any of the computers on your LAN
IPv6: OK, so now what?
Now that I have IPv6 up and running, what will I be doing with it? Well, for starters, I've deployed
a mirror of FreshPorts that is available only via IPv6. As
a bonus, the website is also running PostgreSQL 8.1 instead of
7.4.7, which is what I run everywhere else. You can access this website through
http://pg8.freshports.org/. That hostname resolves only to an IPv6
address, so if you can view that website, you're seeing it over IPv6.
Now that I have access to the IPv6 world, I plan to start making use of the services available through
IPv6. For starters, I'd like to use a cvsup server over IPv6. From what I can tell, cvsup does not
support IPv6 natively.
With the above instructions, you too should be able to get into IPv6 and see how easy it is to configure
and use. If you find that I've overlooked something or that the instructions don't work for you, please
let me know.
This is an excellent article about setting up an ipv6 tunnel with
Hurricane Electric.
As per the article, setup the default route as follows:
route -n add -inet6 default 2001:0DB8:0:8002:EAE
One important entry was omitted from the rc.conf:
ipv6_defaultrouter="2001:0DB8:0:8002:EAE"
Add that line along with the others otherwise the default route won’t be set at boot.
Thanks for a great how-to 🙂
[%sig%]
Thank you, for the praise, and the additional information.
—
The Man Behind The Curtain