6to4 addressing is a type of ipv6 address created by your IPv4 address. It allows you to set up tunnels over the IPv4 Internet automatically.
The range for this is 2002:<first two bytes of an ipv4 address>:<second two bytes of an ipv4 address>::/16.
This gives you a /48 to play around with, great if you have to put up with NAT, now all the boxes behind your firewall will have realworld IPv6 addresses at no extra cost!
Why would you want to use 6to4 instead of FreeNet addresses? The major advantage is that 6to4 addresses will set up tunnels automagically to other 6to4 addresses. This means you don't have to be constrained to the 6bone routing which can be rather inefficient (especially from NewZealand). The advantage of using FreeNet addresses is that they are static even if your IPv4 address is dynamic.
If you exclusively use 6to4 addresses, then you can use the 192.88.99.1 AnyCast address to get onto the 6bone which is probably far more efficient than using a 6bone tunnel, as the AnyCast address is likely to be far closer to you than FreeNet. (In fact, in NewZealand this isn't true, the nearest AnyCast is in gemany, and FreeNet is "only" in America) (If you're in Australia or NewZealand, you could try AARNET's endpoint, at 192.231.212.5. Sometimes the routing tables seem to direct 192.88.99.1 to this address, but more often than not they're broken at the moment).
The idea is that you create an IPv6 tunnel, (in these examples we call it tun6to4) where you route all your 6to4 packets to. This tunnel has a "remote" of "any" which means that the kernel will figure out the remote point by looking at the 6to4 address, it will encapsulate the packet and send it to the IPv4 address embedded in the packet.
Packets that arrive at your machine that are encapsulated arrive through that tunnel and are deencapsulated.
Apparently you need a 2002:ip:v4::1 address somewhere on your gateway, although I'm not sure why.
Packets that transverse your machine are normally not deencapsulated. You need a tunnel with "remote any local any". sit0 exists and has these charactoristics, but it's not up. If you want packets to transverse your machine you should bring this tunnel up.
You don't need to 'get' one - if you have an IPv4 addresss (even a dynamic one) you can get a 6to4 address.
There are two cases for setting this up under linux: if your IPv4 address is a static IP, or if its dynamic. In either case you'll need to know what your 6to4 address is. The script mentioned above will help here.
See 
http://www.be.itu.edu.tr/LDP/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html for more information.
Static IP is obviously preferable, as you can set up DNS properly for it. Thats another issue entirely however :)
192.88.99.1 is an AnyCast address for places that provide connectivity to non-6to4 addresses to 6to4 hosts.
To take the tunnel down again, run
/sbin/ip -6 route flush dev tun6to4 /sbin/ip link set dev tun6to4 down /sbin/ip tunnel del tun6to4
Add the following stanza to /etc/network/interfaces, making obvious substitutions. It should "just" work.
If you are using woody (stable) then you'll need a backport of ifupdown from testing/unstable; available from http://debian.zugschlus.de/zg/pool/main/ifupdown/ifupdown_0.6.4-4.5zg6_i386.deb
auto tun6to4 iface tun6to4 inet6 v4tunnel
address your-6to4-address netmask 16 endpoint any local your-ipv4-address up ip -6 route add ::/96 dev tun6to4 metric 1 up ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 down ip -6 route flush dev tun6to4 mtu 1472 ttl 255
This is a bit of a hassle. You need to update your 6to4 configuration every time you change IP. If your dynamic IP address isn't terminated on your Linux box (that is, you have a DSL router or similar, which handles NAT and so on for you), this might be tricky.
The best way to do this is to put a script in /etc/ppp/ip-up.d/ or whatever is most appropriate for your system
An example ip-up.d script.
/sbin/ip -6 route flush dev tun6to4 /sbin/ip link set dev tun6to4 down /sbin/ip tunnel del tun6to4
- Create the new tunnel
ip tunnel add tun6to4 mode sit remote any local $4 ip link set dev tun6to4 mtu 1472 up
- Route outgoing 6to4 addresses out via the tunnel
ip -6 route add 2002::/16 dev tun6to4
- Add an IPv6 address to eth0
ip -6 addr add $(printf "2002:%02x%02x:%02x%02x::1/64" $(echo $4 | tr '.' ' ')) dev eth0
- Uncomment the following lines if you want non 6to4 IPv6 addresses to be routed over
- the 6to4 anycast address
#
- You DO want this if this is your only connection to the IPv6 backbone
- You DO NOT want this if you have some other way of connecting to the IPv6 backbone (eg: Freenet6)
- ip -6 route add ::/96 dev tun6to4 metric 1 # This line seems necessary, but I've never
- found documented anywhere. Try without if you can.
- ip -6 route add 2000::/3 via ::192.88.91.1 dev tun6to4 metric 1
- Restart radvd (if you have it running)
killall -1 radvd
I have prepared a (hackish, I'll admit) init script for Debian.
this init script to /etc/init.d/6to4this default config to /etc/default/6to4 and then edit it appropriately. (Like using 192.88.99.1 as the default router as stated higher up)ip-up and ip-down fragments to /etc/ppp/ip-up.d/ and /etc/ppp/ip-down.d/, respectivelyip-down as well. It doesn't do this by default, but I suspect it causes issues.To start your 6to4 tunnel, run /etc/init.d/6to4 start, to stop it run /etc/init.d/6to4 stop. These should be run automatically whenever your ppp connection starts and stops.
If you don't use freenet6, then make sure that ONLYCONN in /etc/default/6to4 is set to 'yes' - this will enable a gateway route for non-6to4 addresses out via your 6to4 tunnel.
First you need to configure radvd. Zebra is not recommended as it cannot handle dynamic 6to4 address advertising (as radvd can) and also has a bug where it will write out a configuration to it's file that is invalid and then die when it tries to reload it again.
interface eth0 {
AdvSendAdvert? on;
prefix fec0::/64 {
}; prefix 3ffe:your-freenet-allocation:1::/64 { }; prefix 0:0:0:0::/64 {
Base6to4Interface ppp0;
}; prefix 0:0:0:0::/64 {
Base6to4Interface lo:1;
};
};
You can ommit any of the prefix stanza's you don't like. In the config above the timers have been turned down in anticipation that you are advertising a 6to4 address generated from a dynamic IP on ppp0. Note that if you do this you must turn down the retransmit time on the unsolicited announcements. In particular ensure that !MaxRtrAdvInterval? and !AdvPreferredLifetime? are less than !AdvValidLifetime?. If you don't understand why this is important then you can just go with what is shown above.
You also need at least one SIT tunnel with a "remote any local any". It doesn't need an ipv6 (or ipv4) address associated with it. This is used for transpanret deencapsulation of IPv6 packets that are forwarded to your internal network.
If you've done all this, it should just work. In practise, it requires some tinkering.
See also 
RFC:3056 (Connection of IPv6 Domains via IPv4 Clouds), RFC:3068 (An Anycast Prefix for 6to4 Relay Routers)
Don't forget also RFC:3964 (Security Considerations for 6to4)
For information about setting up 6to4 under FreeBSD see http://www.nevada.net.nz/pmurray/6to4.html (someone feel free to import that if you want to comment about it)
For information about setting up windows see http://research.microsoft.com/msripv6/docs/6to4.htm
Instead of using the 6to4 anycast address, you can use one of the addresses listed on http://www.kfu.com/nsayer/6to4/ (the aarnet relay is highly recommended)
An howto on how to get this working under Fedora Core 2 is available here: http://yyz.us/ipv6-fc2-howto.html
You're using a non-2002 space address as your source address so the return route is going via freenet and adding 350ms to your RTT. This seems to occur semi-randomly, and is probably to do with the order in which your machine obtains its 6to4 and freenet6 addresses.
This almost definitely means you have an MTU issue. If you can ping to a site (such as hoiho.wlug.org.nz) and can get a small file via HTTP (eg, GET /robots.txt HTTP/1.0) but not the main index page, then your MTU is wrong. I'm pretty sure this can be fixed by making sure the MTU on tun6to4 is set to 1472 bytes. I tested this on my link at home, where I was seeing this, and it worked fine (after I changed hoiho's MTU as well)
This means you don't have a gateway for 6to4 to non-6to4 addresses set up. You need to add a route for one of the AnyCast gateways. Re-read the above notes on 6to4 to see which lines you missed.
9 pages link to 6to4:
