I've gone ahead and deployed IPv6 on the server that hosts this site, as well as my desktop. I'm using 6to4 to tunnel IPv6 over the existing IPv4 connection.

Why? Well, I wanted to be able to use SSL on sites, and SSL can only present a single certificate per IP. I only had one IPv4 IP, but I have roughly one septillion two hundred eight sextillion (2^80) IPv6 IP addresses, as a result of the 6to4 system and a single IPv4 address, so now each site can have its own IP. papasian.org has published an AAAA record of 2002:d837:a6fe::4, so if you're using an IPv6-capable machine, you can view this site over IPv6+SSL.

I'm still getting a hang of how 6to4 packets are routed. If I attempt to contact ipv6.google.com (on the 2001 prefix, not using 6to4) from my desktop, it goes out the wire with an IP header with a destination IP address of 192.88.99.1.

192.88.99.1 is a special anycast address for 6to4 gateways, so the packet proceeds until it reaches that gateway (which is a nice 0.7 ms away from me) which I believe then strips off the v4 header and the traffic is normal IPv6 the rest of the way.

When I connect from my desktop to papasian.org, however, it leaves the wire with a destination IPv4 address of the IPv4 address belonging to papasian.org, NOT 192.88.99.1. So somehow, my machine is deciding that the next v4 hop for this traffic isn't the 6to4 gateway but rather the 6to4 host. I suspect that's magic going on with my operating system's routing tables and 6to4 support, so all traffic bound to a 6to4 prefix will leave here with the v4 IP corresponding to the prefix as the next v4-hop.

Which is, in a word, neat. I'm looking forward to pushing v6 adoption on more machines that I administer, and in the future I'll be looking into deploying it at home using a router running OpenWRT.