ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Getting Connected with 6to4

by Hubert Feyrer
06/01/2001

This article will concentrate on how to get network connectivity for IPv6 -- as it's still not easy to get native IPv6 connectivity today -- and talk in length about the alternatives to native v6 connectivity as a transitional method until native v6 peers are available.

If you find an ISP that offers IPv6 natively, you are lucky. What you need next is a router that will be able to handle the traffic. To date, not all router manufacturers offer IPv6 support for their machines, and even if they do, it's unlikely that they offer hardware accelerated v6 routing or switching. A rather cheap alternative to the router hardware commonly in use today is a standard PC configured as a router, by using a Linux- or BSD-derived operating system like NetBSD, and using software like Zebra for handling the routing protocols. This solution is rather common today for sites that want IPv6 connectivity. The drawbacks are that you need an ISP that supports IPv6, and that you need dedicated uplink only for IPv6.

If this is not an option for you, you can still get IPv6 connectivity through tunnels. Instead of talking using IPv6 on the wire, the v6 packets are encapsulated in v4 packets. Using the existing infrastructure, the encapsulated packets are sent to a v6-capable uplink that will then remove the encapsulation, and forward the v6 packets via native IPv6.


Diagram of tunneling IPv6 in IPv4 packets.
A frequently used method for transition is tunneling IPv6 in IPv4 packets.

When using tunnels, there are two possibilities. One is to use a so-called "configured" tunnel, the other is called an "automatic" tunnel. A configured tunnel is one that requires preparation from both ends of the tunnel, usually connected with some kind of registration to exchange setup information. An example for such a configured tunnel is the IPv6-over-IPv4 encapsulation described in [RFC1933], and that's implemented by the "gif" device found in the KAME-derived BSD-stacks like NetBSD.

Previously in this series:

Introduction to IPv6

Comment on this articleBased on what you've read in this article, do you think it's time for you to start playing with IPv6? What are your thoughts?
Post your comments

An "automatic" tunnel consists of a public server that has IPv6 connectivity, such as via 6Bone. This type of server has made its connectivity data public, and also runs a tunneling protocol that does not require an explicit registration of the sites using it as an uplink. A well-used example of such a protocol is the 6to4 mechanism described in [RFC3056], and implemented by the "sit" device found in Linux or in "stf" found on KAME-derived BSD stacks. Another mechanism that does not require registration of v6-information is the 6over4 mechanism, which implements transporting of IPv6 over a multicast-enabled IPv4 network, instead of Ethernet or FDDI. 6over4 is documented in [RFC2529]. Its main drawback is that you do need existing multicast infrastructure. If you don't have that, setting it up is about as much effort as setting up a configured v6 tunnel directly, so it's usually not worth bothering in that case.

Getting 6to4 IPv6 up and running

This section will talk in length about setting up a automatic tunnel using 6to4. 6to4 is rather easy to setup, esp. with the background given in the previous sections. Example configurations will be given for RedHat Linux 7.0 and NetBSD 1.5.

6to4 is an easy way to get IPv6 connectivity for hosts that only have an IPv4 uplink. It can be used with static as well as dynamically assigned IPv4 numbers, as found in modem dial-up scenarios today. When using dynamic v4 addresses, note that a dynamic change of IP numbers will be a problem for incoming traffic, you can't run persistent servers.

Obtaining IPv6 address space for 6to4

The 6to4 setup on your side doesn't consist of one single IPv6 number. Instead, you get a whole /48 network! The IPv6 addresses are derived from your (single) IPv4 address. The address prefix "2002:" is reserved for 6to4 based addresses (such as v6 addresses derived from IPv4 addresses). The next 32 bits are your IPv4 address. This results in a /48 network that you can use for your very own purposes. It leaves 16 bits of space for 216 IPv6 subnets, which can take up to 264 nodes each. Thanks to the 6to4 prefix and your worldwide unique IPv4 address, this address block is also unique, and it's mapped to you.

6to4 derives a IPv6 from an IPv4 address
6to4 derives a IPv6 from an IPv4 address.


Related Reading:

DNS and Bind

DNS and Bind, 4th Edition
By Paul Albitz & Cricket Liu
4th Edition April 2001
0-596-00158-4, Order Number: 1584
622 pages, $44.95

How to get connected

In contrast to the classic "IPv6-over-IPv4 tunnel" setup, you do not register at a 6bone-gateway, which will then forward you any v6 traffic (encapsulated in v4). Instead, because your IPv6 address is derived from your IPv4 address, any answers will be sent to you through your nearest 6to4 gateway. De-encapsulation of the packet is done via a 6to4-capable network interface, which then forwards the resulting v6 package according to your routing setup -- in case you have more than one machine connected on your 6to4 assigned network.

For sending out v6 packets, the 6to4-capable network interface will take the v6 packet, and encapsulate it into a v4 packet. You still need a 6bone-connected 6to4-gateway as an uplink that will de-encapsulate your packets, and forward them on over the 6Bone.

Diagram of request and reply routing.
Request and reply can be routed via different gateways in 6to4.

Security considerations

In contrast to the "configured tunnel" setup, you usually can't set up packet filters to block 6to4-packets from unauthorized sources, as this is exactly how (and why) 6to4 works at all. As such, malicious users can send packets with invalid/hazardous IPv6 payloads. If you don't already filter on your border gateways anyway, packets with the following characteristics should not be allowed as valid 6to4 packets, and some firewalling seems to be justified for them:

The NetBSD stf(4) man page documents some common configuration mistakes intercepted by default by the KAME stack as well as some further advice on filtering. Keep in mind that because of the requirement of these filters, 6to4 is not perfectly secure. Still, if forged 6to4 packets become a problem, you can use IPsec authentication to ensure the IPv6 packets are not modified.

Data needed for 6to4 setup

In order to setup and configure IPv6 over 6to4, a few bits of configuration data must be known in advance. These are:

Kernel preparation

To process 6to4 packets, the operating system kernel needs to know about them. to do this, a driver has to be compiled in that knows about 6to4, and how to handle it.

For a BSD/KAME derived kernel, put the following into your kernel configuration file to prepare it for using IPv6 and 6to4. For example, on NetBSD use:

options INET6       # IPv6
pseudo-device stf   # 6to4 IPv6 over IPv4 encapsulation

Note that the stf(4) device is not enabled by default. Please consult these documents on kernel configuration and compilation for assistance.

On Linux, do a make config or make menuconfig, and make sure the following answers are made:

Networking options The IPv6 protocol:	yes
IPv6: enable EUI-64 token format:		yes
IPv6: disable provider based address: 	yes

After these configuration steps, build and install the kernel (and any assorted modules, for Linux), then reboot your system to use the new kernel. Please consult your BSD/Linux flavor's documentation for further information on building and installing a new kernel.

6to4 setup

The following commands are valid for RedHat Linux 7.0 and NetBSD 1.5, but because they don't use any "magic" variables from the OS-specific startup system, this should be widely usable. In short, the steps performed here are:

  1. Configure interface
  2. Set default route
  3. Setup router advertisement, if necessary

The first step in setting up 6to4 is assigning an IPv6 number to the 6to4 interface. This is achieved with the ifconfig(8) command. Assuming the example configuration above, the command for NetBSD is:

ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias # local address

On Linux, two steps are needed to configure the v4 and v6 "layers" of the SIT (Simple Internet Transition) device:

ifconfig sit0 tunnel ::194.95.108.191 up (v4 layer, remote address)
ifconfig sit1 tunnel 2002:3ee0:3972:1::1/64 (v6 layer, local address)

After configuring the 6to4 device with these commands, routing needs to be setup, to forward all IPv6 traffic to the 6to4 (uplink) gateway. The best way to do this is by setting a default route, the command to do so is, for NetBSD:

route add -inet6 default 2002:cdb2:5ac2::1 (remote)

and for Linux:

route -A inet6 add default gw ::194.95.108.191 (remove v4)

Note that the BSD/KAME stf(4) device determines the IPv4-number of the 6to4 uplink from the routing table. Using this feature, it is easy to setup your own 6to4 (uplink) gateway if you have a v6 uplink, for example, via 6Bone.

After these commands, you are connected to the IPv6-enabled world -- Congratulations! Assuming name resolution is still done via IPv4, you can now ping a v6-site like KAME.net or www6.netbsd.org. Note that the syntax for v6-ready ping(8) is different for Linux and BSD. For NetBSD, it is

/sbin/ping6 www.kame.net

while Linux uses

/usr/ipv6/bin/ping -A inet6 www.kame.net

As a final step in setting up IPv6 via 6to4, you will want to setup router advertisement if you have several hosts on your network. While it is possible to setup 6to4 on each node, doing so will result in very expensive routing from one node to the other -- packets will be sent to the remote 6to4 gateway, which will then route the packets back to the neighbor node. Instead, setting up 6to4 on one machine and talking native IPv6 locally is the preferred method of handling things.

The first step is to assign a IPv6-address to your Ethernet. In the following example, we will assume subnet "2" of the IPv6-net is used for the local Ethernet and the MAC address of the Ethernet interface is 12:34:56:78:9a:bc, which means your local gateway's Ethernet interface's IP address will be 2002:3ee0:3972:2:1234:56ff:fe78:9abc. Assign this address to your Ethernet interface:

ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc

Here, ne0 is an example for your Ethernet card interface. This will most likely be different for your setup, depending on what kind of card is used. On Linux, the Ethernet interface is usually eth0.

To setup router advertisement on BSD, the file /etc/rtadvd.conf needs to be checked. It allows configuration of many things, but usually the default configuration of not containing any data is OK. With that default, IPv6 addresses found on all of the router's network interfaces will be advertised.

On Linux, the same file is called /etc/radvd.conf, an example is:

interface eth0
{  AdvSendAdvert on;

  prefix 2002:3ee0:3972:2::/64
  { AdvOnLink on;
    AdvRouterAddr on;
  };
};

Next thing that needs to be ensured to set up the router is that it will actually forward packets from the local 6to4 device to the Ethernet device and back. To enable IPv6 packet-forwarding, set "ip6mode=router" in NetBSD's /etc/rc.conf, which will result in the net.inet6.ip6.forwarding sysctl being set to "1" -- this works the same on all BSD flavors. On Linux, make sure that /proc/sys/net/ipv6/ip_forward is set to "1":

BSD:   sysctl -w net.inet6.ip6.forwarding=1
Linux: echo 1 >/proc/sys/net/ipv6/ip_forward

Enabling packet forwarding is needed for a 6to4 router.
You must enable packet-forwarding if you are using a 6to4 router.

After checking that the router advertisement configuration is correct and IPv6 forwarding is turned on, the daemon handling it can be started. Under NetBSD, it is called rtadvd, in Linux it's called radvd. Start it up either manually (for testing it the first time) or via the system's startup scripts, and see all your local nodes automagically configure the advertised subnet address in addition to their already-existing link local address.

Known 6to4 gateway

There are not many public 6to4 gateways available today, and from the few available, you will want to choose the one closest to you, netwise. A list of known working 6to4 gateways is available at http://www.kfu.com/~nsayer/6to4/. In tests, only 6to4.kfu.com and 6to4.ipv6.microsoft.com were found working. Cisco has another one that you have to register to before using it, see http://www.cisco.com/ipv6/.

There's also an experimental 6to4 server located in Germany, 6to4.ipv6.fh-regensburg.de. This server runs under NetBSD 1.5 and was setup using the configuration steps described above. The complete configuration of the machine can be seen here.

Conclusion and further reading

Compared to where IPv4 is today, IPv6 is still in its early steps. It is working, there are all sort of services and clients available, only the user base is missing. I hope the information provided here will help you better understand what IPv6 is, and to start playing with it.

A few links should be mentioned here for further reading:

References

RFC2401
Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT=168162 bytes) (Obsoletes RFC1825) (Status: PROPOSED STANDARD)

RFC2411
IP Security Document Roadmap. R. Thayer, N. Doraswamy, R. Glenn. November 1998. (Format: TXT=22983 bytes) (Status: INFORMATIONAL)

RFC2529
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels. B. Carpenter, C. Jung. March 1999. (Format: TXT=21049 bytes) (Status: PROPOSED STANDARD)

RFC3024
Reverse Tunneling for Mobile IP, revised. G. Montenegro, Editor. January 2001. (Format: TXT=63929 bytes) (Obsoletes RFC2344) (Status: PROPOSED STANDARD)

RFC3027
Protocol Complications with the IP Network Address Translator. M. Holdrege, P. Srisuresh. January 2001. (Format: TXT=48662 bytes) (Status: INFORMATIONAL)

RFC3056
Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT=54902 bytes) (Status: PROPOSED STANDARD)

Hubert Feyrer works on operating systems, databases, and artificial intelligence at the Fachhochschule Regensburg.


Return to ONLamp.com.

Copyright © 2009 O'Reilly Media, Inc.