A idéia é a seguinte: o IP do "servidor" do túnel é sempre 192.88.99.1. Embora este seja um IP privado, na verdade nada impede que IPs privados trafeguem na Internet pública. O problema é que cada provedor de Internet vai rotear IPs privados de um jeito diferente. No caso do 6to4, este problema vira solução: cada provedor roteia 192.88.99.1 para o servidor 6to4 mais próximo do seu usuário.
A faixa IPv6 atribuída ao usuário 6to4 é função do IPv4 público que ele possui. Assim, basta ter um IP público, aquele atribuído a qualquer conexão DSL ou 3G, para conseguir obter uma faixa IPv6 completa e distribuir IPv6 públicos por toda a rede. Quem tem IP fixo, terá uma faixa IPv6 também fixa. Quem ganha IP dinâmico (a maioria), também vai ganhar uma faixa IPv6 diferente a cada conexão. (Quem faz questão de uma faiva IPv6 fixa possuindo IP dinâmico, tem de adotar outro tipo de túnel IPv6).
Naturalmente, o provedor tem de colaborar ao menos com as rotas até o 192.88.99.1 mais próximo para o 6to4 funcionar, e aí mora uma dificuldade. Em se tratando de telecoms brasileiras, sabe Deus quando teremos 6to4. Mas qual não foi minha surpresa quando...
/Users/epx $ ping 192.88.99.1
PING 192.88.99.1 (192.88.99.1): 56 data bytes
64 bytes from 192.88.99.1: icmp_seq=0 ttl=58 time=33.276 ms
64 bytes from 192.88.99.1: icmp_seq=1 ttl=58 time=33.539 ms
64 bytes from 192.88.99.1: icmp_seq=2 ttl=58 time=34.782 ms
A Brasil Telecom roteava 6to4, e ainda por cima com latência boa... Vamos ver por onde o pacote anda:
/Users/epx $ traceroute 192.88.99.1
traceroute to 192.88.99.1 (192.88.99.1), 64 hops max, 40 byte packets
1 router (192.168.141.1) 4.540 ms 2.167 ms 3.521 ms
2 BrT-L10-jvece702.dsl.brasiltelecom.net.br (201.34.149.254) 11.349 ms 11.094 ms 11.657 ms
3 BrT-10G0-0-0-spopn-border.brasiltelecom.net.br (201.10.241.22) 36.212 ms 34.865 ms 53.585 ms
4 as22548.sp.ptt.br (200.219.130.1) 36.975 ms 36.531 ms 38.975 ms
5 192.88.99.1 (192.88.99.1) 31.053 ms 40.719 ms 30.021 ms
Parece que é a ptt.br quem fornece o túnel 6to4, não a própria Brasil Telecom. Esta é outra vantagem do 6to4: o provedor pode delegar a tarefa para um terceiro no início, e depois ir "aproximando" mais o servidor 6to4 do usuário final conforme o interesse em IPv6 for aumentando.
Outra característica do 6to4 é que ele foi pensado para rodar no roteador NAT, não no computador atrás do NAT. A partir do roteador, o IPv6 é distribuído da maneira usual, via DHCP. Por um lado isto é um problema, pois o roteador NAT tem de possuir esta funcionalidade. Por outro lado, todo roteador NAT possui processamento suficiente para tomar conta do 6to4, basta que o fabricante libere uma atualizacão.
Tanto o Mac OS X quanto o roteador AirPort parecem vir com IPv6 e 6to4 habilitados, o que teria sido responsável por um aumento "considerável" no tráfego IPv6 mundial. Entre aspas porque o tráfego IPv6 ainda é apenas 0,6% da Internet. Considerável porque era metade disso há pouco tempo atrás.
Não é fácil usar o 6to4 a partir de um computador atrás do NAT, porque o 6to4 usa o protocol IP 41 (não é nem TCP nem UDP), e dificilmente um roteador NAT repassa este tipo de pacote. Existe uma outra especificação de túnel IPv6, a Teredo, que foi concebida para funcionar sem a colaboração do roteador NAT, mas é consideravelmente menos elegante que 6to4.
Ontem eu flechei meu roteador com o DD-WRT. A boa notícia é que ele tem suporte a 6to4 mediante pouca configuração. A má notícia é que a v24 que estou usando está com problemas no IPv6 :( O jeito é esperar por uma atualização, ou talvez usar a v23.