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.
6to4 has previously been used in production on CoreServer systems and test nodes.
Initial deployment of 6to4 connectivity to test nodes was completed 2007-09-23.
All publication of 6to4 addresses ended 2007-11-17.
Initial testing yielded positive results, but continued deployment soon revealed that most current IPv6 stack implementations do not yet provide adequate support for hosts with multiple IPv6 addresses. Essentially, 6to4 only works correctly if it is being used exclusively.
As time goes on, IPv6 software will continue to improve and eventually all of the important implementations will have reliable support for hosts with multiple addresses. At that point, continued production deployment of 6to4 might be worthy of consideration. See Address selection below for more information about multiple address support.
In terms of basic setup, 6to4 is an icon of simplicity.
DebianLinux breaks it down to 5 lines of configuration.
First, you must 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.
auto sit0 iface sit0 inet6 static address my:pre:fix:: netmask 64 gateway ::18.104.22.168
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!
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 does work. 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.
RFC 3484 defines a reasonable default address selection policy.
This policy 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. The idea is to take full advantage of 6to4 support when it is appropriate, and avoid it entirely when it is not appropriate.
Unfortunately, software implementations of RFC 3484 tend to be incomplete. Any report of a complete, successful implementation would be appreciated...