Overview of UW-Madison 6to4 protocol IPv6 service for both the campus and wan environments.
The 6to4 protocol is a method to tunnel IPv6 packets inside of IPv4 packets. Originally this protocol was developed to connect IPv6 routers together across IPv4-only networks. In IPv4, this 6to4 application is assigned it's own protocol number: 41.
As time progressed, implementations came about allowing the tunnel to originate and terminate directly from personal computers using the same 6to4 protocol. This means that computers that are on IPv4-only networks can talk to computers on IPv6-only networks. It is the mode of 6to4 that we will focus on here.
Two computers using 6to4 can talk to each other using IPv6 by encapsulating that traffic inside of protocol 41 IPv4 packets. However, in order to talk to the "real" IPv6 internet, a relay router is needed to translate or relay tunnel traffic both to and from the native IPv6 internet.
6to4 is easily distinguishable on a network. 6to4 packets in IPv4 are marked with IP protocol 41. 6to4 packets going to or from the native IPv6 network have a source or destination address of 18.104.22.168. A 6to4 packet on the IPv6 network will have an address in the range of 2002::/16.
Another protocol with a similar objective is called Teredo. The main differences between 6to4 and Teredo is that 6to4 is relatively simpler in comparison, but Teredo can work from behind some (most?) kinds of NAT.
If native IPv6 service is not available, a PC running Windows Vista will run 6to4 by default if it has a public (non-rfc1918) IPv4 address. Windows XP and Apple OS X do not run 6to4 by default. In the residential arena, some Apple Airport Express routers run 6to4 on behalf of the hosts connected behind them, and those hosts think they have native IPv6 service via the gateway.
A client computer wants to talk to a server, perhaps a server like ipv6.google.com, using IPv6. The computer has an IPv4 address but not its network is not IPv6 enabled and thus does not have a native IPv6 address.
The client computer now takes it's IPv4 address, converts it to hex, and maps it into a /48 subnet in 2002::/16. For example, my host 22.214.171.124 is translated to 2002:905c:43a1::. So, now the computer has an IPv6 address. It also needs a default gateway to send traffic to. This 6to4 default gateway is called a relay-router.
The client computer will craft an IPv6 packet using it's special 6to4 source address and will put in the IPv6 destination it is trying to reach. Now, the computer will encapsulate the IPv6 packet into an IPv4 packet. The source address of the packet will be the normal IPv4 address of the computer, but the destination address will be set to 126.96.36.199.
188.8.131.52 is a specially assigned globally announced Anycast address of the "nearest" 6to4 relay router. Relay routers handling 6to4 traffic announce 184.108.40.206/24 into the IPv4 internet and process protocol 41 traffic for 220.127.116.11. This is a nice feature. Any computer wanting to send 6to4 packets towards the IPv6 internet always uses 18.104.22.168 as its destination address. Through the use of anycast routing, the nearest router will be used without the client having to configured to know anything else in advance.
The client computer now sends its 6to4 packet to the nearest relay router. The relay router strips off the outer IPv4 packet and puts the inner IPv6 packet onto the wire facing the real IPv6 network. The packet is then natively IPv6 routed to its final destination.
The server in this example processes the native IPv6 packet and sends back a return native IPv6 packet. The source address of the packet is, of course, the native IPv6 address of that server. The destination address is the 6to4 IPv6 address of the client computer, but aside from that address being in the special range of 2002::/16, the server never knows the difference and thinks it is talking to any normal IPv6 host.
Now this native IPv6 packet has to get back to the host. Again, the relay routers come into play. Relay routers announce an anycast route for 2002::/16 into the IPv6 internet. So, the "nearest" relay router will recive the IPv6 packet. Once it does, it will encapsulate it in IPv4 and decode the special 2002:: IPv6 destination address back into the real IPv4 destination address of the client computer. It will then put the encapsulated packet on the wire facing the IPv4 internet and it will travel back to the host.
One thing to point out is that in this example, the client uses the relay router nearest the client to decapsulate. The server uses the relay router nearest the server to encapsulate. In nearly all cases, these will be two different relay routers. This doesn't matter, because 6to4 is stateless.
Since 6to4 uses anycast to find the relay routers to do encapsulating and decapsulating of traffic, for performance reasons it is very important to have them as nearby as possible.
When we started looking into the 6to4 protocol on campus, there was a multitude of traffic found in netflow destined, of course, for 22.214.171.124. At the time, the "nearest" anycast router was at the Pittsburgh supercomputing center. Presumably, all of Internet2 was using just this one relay. A few times it was found to be unavailable, and the next nearest anycast router was in Northern Europe. This was bad.
So, we set out to run a relay router on the UW-Madison campus on an experimental basis. Through a partnership with the CS Department's WAIL lab, a 7301 router was borrowed for this purpose. The most production worthy 6to4 implementations other than *BSD or Linux are in IOS software routers. The 7301 is actually a 7200VXR-NPEG1 (a modestly capable software router) in a 1U disguise.
After running the 6to4 relay router for a number of years, it was of decreasing value as actual native ipv6 deployments have progressed. After seeing the results of 6to4 measurements of brokenness (particularly Goeff Huston's work, it is now UW's opinion that running 6to4 does more harm than good to the internet.
Most notably, 6to4 does not work through a NAT. A NAT device would need have to be able to read far into the packet and manipulate the encapsulated data. The Teredo protocol was developed to work around this, at this expense of complexity. Hosts automatically disable 6to4 if they have a rfc1918 address.
Many firewalls, and perhaps all of them on the UW-Madison campus block IPv4 protocol 41 (by default). The captivators do allow protocol 41, thus 6to4 theoretically works on our wireless networks.
As mentioned above, a client uses its nearest anycast relay and a server uses its nearest anycast relay. These are very rarely the same relay, and clients have no control and no visibility into the return path for their traffic which of course also impedes troubleshooting. We may have a good relay in the Midwest, but a server on the east coast may think a relay in Europe is "closest". This will likely never truly get fixed.
Essentially, 6to4 has been replaced by 6rd, which fixes some of the issues associated with using a defined relay hosted on a service provider network.
IPv6 Address Calculator includes calculating the 6to4 address of an IPv4 address.
Wikipedia page on 6to4
rfc3056 - 6to4 spec
rfc3068 - anycast 6to4 6to4 failure