6to4 is a system that allows ["IPv6"] packets to be transmitted over an IPv4 network (ie. the Internet) without the need to configure explicit tunnels.
One of the most attractive aspects of 6to4 is the potential for experimentation. With nothing more than a single global-scope IPv4 address and a few minutes of free time, you can get a nice chunk of IPv6 Internet to play with.
The CoreServer systems are all configured for 6to4 support; see ["IPv6Addresses"].
Although it might seem appealing, 6to4 is probably not a good solution to provide IPv6 connectivity to nodes. It would work well for a few systems, but those unfortunate successes would then be saddled with yet another burden of inconsistency.
In terms of basic setup, 6to4 is an icon of simplicity.
DebianLinux breaks it down to 5 lines of configuration.
First, you must [http://www.ip-calc.com/ calculate your 6to4 IPv6 prefix] based on the IPv4 address which is being used. (The web-based calculator refers to the relevant value as the Compressed 6to4 Address.)
The following lines should be added at the end of /etc/network/interfaces. Replace my:pre:fix:: with the 6to4 IPv6 prefix you calculated - do not remove the trailing 1.
auto sit0 iface sit0 inet6 static address my:pre:fix::1 netmask 64 gateway ::126.96.36.199
After these lines have been added, 6to4 support will be automatically started at boot. The following command will enable it immediately:
sudo ifup sit0
That's all there is to it.
Apple Mac OS X
OS X makes 6to4 configuration a matter of a few clicks in Network Preferences.
Apple AirPort Extreme
Rumor has it that the latest generation of Apple AirPort Extreme 802.11n base stations are configured by default to advertise an IPv6 prefix to clients configured with 6to4.
Most major operating systems include 6to4 support. Additional documentation is always welcome!
For each global-scope IPv4 address that is assigned to a host, 6to4 allows a valid 48-bit IPv6 prefix to be constructed for use by that host. It is tempting to make use of these prefixes - a /48 gives up 2**80 (1,208,925,819,614,629,174,706,176) addresses, although generally large prefixes like that are divided into /64 subnets, each containing 2**64 (18,446,744,073,709,551,616) addresses. To put this in perspective, IPv4 (ie. the Internet) has only 2**32 (4,294,967,296) addresses total.
At this point, this space is not generally being used, beyond the selection of a single address for each 6to4 host. The reason for this is the possibility of being forced to renumber some 65 thousand subnets due to the loss of a single IPv4 address.
Routing traffic through 6to4 gateways is easy but not necessarily optimal. Related issues are discussed in this section.
6to4 gateways are great
The performance and reliability of communications between 6to4 hosts and native IPv6 hosts are better than ever before; a good 6to4 gateway can sometimes outperform a mediocre link to a TunnelBroker.
If you are a beginner or a casual IPv6 user, 6to4 just might give you everything you need. It's not perfect but it also isn't half bad. That said, if you find yourself using a 6to4 gateway frequently, you're probably going to want something better.
6to4 gateways are evil
Two sites which are both running 6to4 can communicate via IPv6 encapsulated directly over the IPv4 Internet. This type of communication will almost always provide the best possible performance. Similarly, two sites which are both using TunnelBroker configurations can usually communicate effectively over the IPv6 Internet. In counterpoint, two native IPv6 sites might be capable of even better IPv6 performance than 6to4 sites, although they face another set of challenges when trying to reach the IPv4 Internet.
These examples all optimize performance by avoiding the use of 6to4 gateways; traffic is always directed over a consistent path. When using a 6to4 gateway, your router is sending IPv4 packets to a magic anycast address, which is eventually picked up by a router and transformed into an IPv6 packet.
Unless you specify a 6to4 gateway explicitly, there is no guarantee of any consistency in the routes your traffic will take. The opposite sequence occurs for each packet sent back to you, once again using a different set of routes. Worse, it is even more difficult to specify the 6to4 gateway being used by the host you are communicating with, and even if you manage to do so, other problems can then result.
[http://www.ietf.org/rfc/rfc3484.txt RFC 3484] defines a pretty nice default address selection policy. In this section, we'll look at how it works and how we can take advantage of it.
OS support for RFC 3484 is not quite ubiquitous just yet. I've tested a few systems to figure out the details.
This part is included before the parts describing the related cool stuff in hopes of saving you from the frustration of setting it all up only to realize that your operating system doesn't support the features you actually want.
Whether you have good luck or bad, please update this list accordingly if you go all the way through the process with a system which is not yet listed.
- Mac OS 10.4.10 works
Linux with glibc 2.5+ works - http://people.redhat.com/drepper/linux-rfc3484.html
- Linux with glibc pre-2.5: round-robin, evidently no address selection policy support
It is worth pointing out that the worst-case scenario for a host without address selection policy support would be that some traffic might end up going through a 6to4 gateway. Everything will still work, it just won't be optimized in the same way.
The default address selection policy defined in RFC 3484 does a couple of specific things we're interested in: 6to4 destination addresses are always contacted via 6to4 source addresses if possible, and native IPv6 destination addresses are always contacted via native IPv6 source addresses if possible. Also, 6to4 addresses are preferred if it's possible to use them on both sides.
Essentially, the idea is to take advantage of an IPv4 network if and when it's appropriate, while avoiding those 6to4 gateways at all costs.
Follow these steps on your local network router with native IPv4 connectivity. This assumes that the router has no IPv6 support to begin with; simply skip any steps which have already been done.
- Enable 6to4 support.
Assign a 6to4 address with a /64 prefix to your local network interface.
Establish IPv6 Internet connectivity via TunnelBroker; you need at least a /64 prefix delegation.
Assign a tunnel-delegated address with a /64 prefix to your local network interface.
Configure radvd (or something similar) to announce both prefixes over your local network interface.
Before long, IPv6-capable hosts on your local network will set themselves up with a unicast address for each prefix which is now being announced.
Once you've got those unicast addresses, you're done. Go ahead, try it out.
You'll probably want to use something simple, such as traceroute6 or ping6. An ideal tool for this job will tell you the source address being used.
Connect to a couple of 6to4 sites and a couple of native IPv6 sites. It should be telling you that it is automatically selecting the best possible source address to reach each destination; 6to4 for 6to4, native for native.
With all of these perfectly good addresses hanging around, why list only one in DNS?
To allow other hosts the opportunity to consider more than one of your IPv6 addresses during address selection when connecting to you, simply add an AAAA record to your DNS zone for each unicast address you plan on accepting connections with.
For example, donk.personaltelco.net has two IPv6 addresses, 2001:4830:1500:e8::2 and 2002:cea3:7a62::1:
donk AAAA 2001:4830:1500:e8::2 donk AAAA 2002:cea3:7a62::1