The FreeBSD Diary

The FreeBSD Diary (TM) Remember
I remember
[ HOME | TOPICS | INDEX | WEB RESOURCES | BOOKS | CONTRIBUTE | SEARCH | FEEDBACK | FAQ | FORUMS ]

Things look quiet here. But I've been doing a lot of blogging at dan.langille.org because I prefer WordPress now. Not all my posts there are FreeBSD related. I am in the midst of migrating The FreeBSD Diary over to WordPress (and you can read about that here). Once the migration is completed, I'll move the FreeBSD posts into the new FreeBSD Diary website.

IPv6 - getting your LAN connected 5 February 2006
Need more help on this topic? Click here
This article has 2 comments
Show me similar articles

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<UP,POINTOPOINT,RUNNING,MULTICAST> 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.


Share
Need more help on this topic? Click here
This article has 2 comments
Show me similar articles