The FreeBSD Diary |
|
(TM) | Providing practical examples since 1998If you buy from Amazon USA, please support us by using this link. |
|
IPv6 - getting your LAN connected
5 February 2006
|
|
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):
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: 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
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
# 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. 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,ipv6_gateway_enable="YES" rtadvd_enable="YES" # let our LAN know the IPv6 default route rtadvd_interfaces="fxp1" # our private LAN 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 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 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 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:ipv6_enable="YES"
This is good. Good. It has an IPv6 address in the right range. If you also looked at
the output of 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:Internet6: Destination Gateway Flags Netif Expire 2001:0db8:0:8002:f00::/64 link#1 UC fxp0 And here is the tcpdump output on the fxp1 NIC on the gateway:$ 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 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 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 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:
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 onipv6_ifconfig_fxp1="2001:0DB8:0:8002:F00::1 prefixlen 64" fxp1:
Once that is set, 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.
|