Resumo

  • Em 2001, o 6to4 permitiu derivar de um endereço IPv4 globalmente único um prefixo IPv6 em 2002::/16 e atravessar redes IPv4 sem negociar antecipadamente cada túnel.
  • O anycast fez o relay parecer automático, mas ida e volta podiam depender de operadores diferentes, sem responsabilidade comum. Filtros, rotas ruins e ativação por padrão transformaram conveniência em falha recorrente.
  • A RFC 7526 descontinuou em 2015 o mecanismo de relay anycast. Ela não descontinuou o 6to4 unicast básico nem removeu 2002::/16, distinção que ainda importa na leitura do registro.

Um endereço antes de um acordo

A parte mais marcante do 6to4 é uma operação simples. Tomam-se os 32 bits de um endereço IPv4 globalmente único, eles são colocados após o prefixo 2002 e o site obtém um /48. A RFC 3056 representou o resultado como 2002:V4ADDR::/48. Uma rede ainda sem IPv6 nativo podia distribuir endereços desse prefixo internamente. Na borda, um roteador 6to4 encapsulava diretamente o pacote IPv6 em IPv4, usando o protocolo 41.

Publicada em fevereiro de 2001, a RFC 3056 chamou o 6to4 de mecanismo provisório e opcional, não de arquitetura permanente do IPv6. A proposta era mais específica: conectar sites pela Internet IPv4 sem configurar um túnel para cada interlocutor e sem antes obter, para esse fim, um prefixo IPv6 convencional. O endereço IPv4 funcionava ao mesmo tempo como matéria-prima e localizador.

A facilidade tinha limites desde o início. Um endereço IPv4 privado não podia produzir um prefixo 6to4 com significado global. Se o IPv4 mudasse, o prefixo IPv6 derivado também mudaria. E ainda era preciso que alguém transportasse os pacotes entre o mundo 6to4 e o IPv6 nativo. A geração do endereço havia sido automatizada; a conectividade universal, não.

O relay que sumiu de vista

Entre dois sites 6to4, o IPv4 incorporado ao prefixo indicava ao outro lado para onde enviar o túnel. Entre um site 6to4 e um destino IPv6 nativo, porém, era necessário um relay capaz de entender os dois mundos.

A RFC 3068 apresentou uma solução extremamente simples: dar aos roteadores de relay o mesmo endereço IPv4 anycast, 192.88.99.1. O roteador 6to4 enviava o tráfego para esse endereço, e o roteamento IPv4 comum escolhia um relay que anunciasse a rota. O usuário deixava de descobrir ou configurar um gateway específico. Um mecanismo que exigia algum arranjo operacional passou a parecer uma chave liga-desliga.

Essa chave escondia uma assimetria. O relay escolhido na ida não precisava ser usado na volta. Uma rede IPv6 nativa que enviasse para 2002::/16 podia escolher outro relay, de outro operador e sob outra política de roteamento. Os dois nem precisavam saber da existência um do outro. O sucesso dependia de serviços compatíveis de várias organizações, mas o mecanismo não criava contrato entre elas nem um responsável único pela viagem completa.

O problema não aparecia no formato do endereço. Um endereço 6to4 perfeitamente válido podia encontrar um firewall que descartasse o protocolo 41, um anúncio de relay ausente, um relay mal localizado ou uma rota de retorno que terminasse em um buraco negro. O prefixo podia estar correto e a experiência ainda falhar.

Quando o fallback escondia a conta

A RFC 3964, publicada em 2004, concentrou-se em segurança. Um relay deveria verificar se a origem IPv4 do túnel correspondia ao IPv4 incorporado à origem 6to4. Sem filtragem, tráfego forjado poderia ser refletido, “lavado” pelo sistema de transição ou ficar mais difícil de atribuir. O documento não dizia que todo relay era hostil; mostrava que o encapsulamento automático cruzava fronteiras de confiança que o endereço sozinho não conseguia controlar.

Em 2011, a RFC 6343 já descrevia um histórico operacional mais amplo: filtros bloqueando o protocolo 41, relays ausentes ou inalcançáveis e caminhos que funcionavam em uma direção, mas não na outra. Ela citava experimentos da época com taxas de falha de conexão 6to4 de aproximadamente 9% a 20%. Não era um censo mundial, mas bastava para transformar uma ajuda de transição em problema visível de confiabilidade.

O custo muitas vezes era escondido, não eliminado. Um aplicativo dual stack podia tentar IPv6, esperar a falha do caminho 6to4 e depois voltar ao IPv4. Para o usuário, a página apenas parecia lenta. Fornecedores de software tinham motivo para preferir caminhos nativos funcionais e disputar alternativas em paralelo, como fizeram estratégias posteriores do tipo Happy Eyeballs. Cada camada reduzia seu próprio sintoma, mas a falta de um dono para o sistema de relays permanecia.

A ativação por padrão prolongou o padrão. Um usuário que jamais solicitara 6to4 podia receber do sistema operacional ou do equipamento de borda um endereço derivado e uma aparente rota IPv6. A RFC 6343 classificou isso como má prática e recomendou desabilitar 6to4 por padrão. A inversão era significativa: o recurso atraente por exigir pouca coordenação passava a requerer uma decisão informada para ser ativado.

Descontinuar o atalho sem reescrever o passado

A RFC 7526 formalizou o recuo em maio de 2015. Ela descontinuou o mecanismo anycast do 6to4, transferiu as RFCs 3068 e 6732 para o estado Historic e pediu o fim do anúncio da rota anycast e do serviço de relay 192.88.99.1. Implementações deveriam desabilitar o 6to4 por padrão. O atalho público deixava de ser infraestrutura de transição recomendada.

É fácil confundir o alcance da decisão. A RFC 7526 afirmou expressamente que não descontinuava o mecanismo unicast básico da RFC 3056 nem o prefixo 2002::/16. O registro atual de endereços IPv6 de finalidade especial da IANA continua listando esse bloco como 6to4. A presença no registro documenta uma alocação arquitetônica; não promete que haja um caminho público de relay disponível ou recomendável.

Por isso, a história não termina com uma exclusão. O processo de padronização podia retirar uma recomendação operacional e preservar o vocabulário necessário para reconhecer endereços antigos, arranjos gerenciados e sistemas residuais. Encontrar 2002::/16 hoje é evidência do mecanismo, não de que o serviço anycast tenha sobrevivido à revisão.