Resumo

  • A correspondência entre a origem IPv4 externa e o valor embutido no endereço 6to4 interno era uma prova limitada de consistência; não identificava o relay, o operador ou o autor, nem provava entrega.
  • Como o cabeçalho externo deixava o caminho normal após o desencapsulamento, a associação entre as duas camadas, a instância concreta e cada veredito precisava ser preservada antes da transformação.

Um relay pode receber a reclamação porque seu endereço aparece perto do incidente. O destino pode apontar para uma origem IPv6. Nenhum dos dois registros, isolado, explica quem entregou o pacote ao túnel ou quem autorizou a ação. RFC 3964 mostrou que essa lacuna era produzida pelo próprio ciclo de vida do encapsulamento.

O ponto de partida foi RFC 3056. Um site com endereço IPv4 global formava 2002:V4ADDR::/48. Para outro site 6to4, o valor embutido indicava o destino IPv4 do pacote de protocolo 41. Para a Internet IPv6 nativa, um relay retirava ou acrescentava a camada IPv4 e anunciava alcance para o prefixo agregado.

A economia de configuração era engenhosa: o endereço levava uma pista de roteamento. Mas também colocava duas afirmações no mesmo objeto. O cabeçalho externo dizia qual endpoint IPv4 foi observado na borda do túnel. O interno dizia qual origem IPv6 o pacote alegava ter. Remover a primeira afirmação não validava a segunda.

O teste de igualdade tinha alcance estreito

Quando a origem interna pertencia a 2002::/16, RFC 3964 mandava comparar o IPv4 incorporado com a origem IPv4 externa. A divergência exigia descarte. Encapsuladores e desencapsuladores também deveriam rejeitar destinos impróprios — multicast, broadcast, loopback, espaço privado e outras faixas especiais — conforme limites de roteadores como RFC 1812 e o atual registro IANA de endereços IPv4 de propósito especial.

Passar nesse teste significava que dois campos concordavam segundo uma regra e um estado locais. Não significava que o endereço ainda pertencia à mesma organização, que o equipamento era um relay autorizado, que a pessoa por trás dele estava identificada ou que o aplicativo tinha permissão para produzir um efeito.

O filtro de origem podia fortalecer a barreira. RFC 2827 / BCP 38 propôs bloquear fontes IPv4 implausíveis perto da origem; RFC 3704 / BCP 84 acomodou redes com múltiplos caminhos. Assim, falsificar determinado prefixo 6to4 também exigia falsificar o IPv4 correspondente e atravessar os filtros. Ainda assim, um pacote aceito pelo filtro era plausível para uma conexão ou tabela de rotas, não uma identidade humana autenticada.

No sentido vindo do IPv6 nativo, a comparação deixava de existir. A origem interna não tinha V4ADDR embutido; a origem externa normalmente era o relay. RFC 3964 observou que o roteador 6to4 não conseguia distinguir facilmente um relay legítimo de um terceiro que fingisse ser um. Receber protocolo 41 era um evento de transporte, não uma credencial de função.

A separação lembra os modelos de ameaça do Neighbor Discovery em RFC 3756: conseguir falar em um enlace não confere autoridade de roteador. O “enlace” lógico de 6to4 abrangia a Internet IPv4, ampliando a diferença entre alcançabilidade e mandato.

O endereço externo era fraco, mas ainda era evidência

O apêndice de RFC 3964 mostra quatro endereços antes do desencapsulamento e apenas os dois IPv6 depois. O texto nota que os endereços IPv4 eram tratados como informação de camada de enlace e, em geral, não eram registrados pelo relay. Um ataque iniciado num nó IPv4 podia, então, prosseguir como pacote IPv6 enquanto o src_v4 desaparecia.

Não se deve superestimar esse campo. Ele poderia ser falso, identificar apenas um relay ou representar várias máquinas sob anycast. Mas descartá-lo não aumentava a veracidade da origem interna. Retirava da investigação a observação que situava a entrega na borda do túnel.

O registro útil precisava unir interface de entrada, instância concreta, par IPv4 externo, par IPv6 interno, instante, protocolo, época de rota e resultado de cada regra. O desencapsulamento gerava outro recibo. Encaminhamento IPv6, recepção remota e efeito de aplicação eram etapas posteriores. Essa cadeia permitia ligar uma queixa do destino à observação do túnel sem transformar o endereço do relay em culpado automático.

RFC 6169 mais tarde generalizou o problema: filtros aplicados à rede portadora não alcançam automaticamente os endereços internos; equipamentos sem consciência do túnel perdem visibilidade; somente as pontas podem restaurar controles equivalentes. O êxito da transformação e a conservação da prova eram resultados separados.

Anycast escolhia uma instância e escondia qual

RFC 3068 reservou 192.88.99.1 como endereço anycast de relay 6to4. O roteamento IPv4 podia escolher uma instância próxima; uma instância quebrada retiraria o anúncio e outra assumiria. Isso dispensava configuração por site. Também tornava difícil identificar o relay específico, como o próprio documento reconheceu.

Uma rota para o anycast provava uma seleção do plano de controle. Não provava que a máquina escolhida aceitava o serviço, tinha conectividade IPv6 nativa, aplicava as verificações, possuía capacidade ou compartilhava o caminho de volta. Disponibilidade tratava a instância como substituível; investigação precisava fixá-la no tempo.

RFC 6343 registrou em 2011 os efeitos operacionais: buracos negros, relays não administrados, anúncios que atraíam tráfego sem encaminhá-lo e trajetos de ida e volta por relays diferentes. Firewalls com estado podiam rejeitar o retorno porque a origem externa mudava. A rota não era comprovante de serviço.

Em 2015, RFC 7526 depreciou formalmente o 6to4 anycast e 192.88.99.1. Não depreciou o mecanismo básico de RFC 3056 nem 2002::/16. A distinção é operacionalmente importante: mudar o status normativo não demonstra que todos os equipamentos, rotas e fluxos residuais desapareceram.

Um túnel concluído não concluía o caso

RFC 3964 separou negação de serviço, reflexão, lavagem de pacotes, broadcast IPv4 local, roubo de serviço e abuso administrativo. Um relay podia parecer a origem de tráfego que só encaminhou. Uma fonte IPv6 forjada podia deslocar respostas para uma vítima. Um log posterior podia conservar somente a afirmação interna.

Por isso a cadeia de evidência precisa distinguir: escolha de rota IPv4; recepção numa interface concreta; observação conjunta das quatro pontas; vereditos de endereço, direção e escopo; desencapsulamento; decisão de encaminhamento IPv6; recepção no destino; efeito do aplicativo; e identificação autorizada do agente. O quinto passo pode ter sucesso sem nenhum dos quatro seguintes.

As fontes centrais são o texto, o registro editorial e as erratas de RFC 3964. Duas erratas técnicas verificadas corrigem o destino de um exemplo e um erro de digitação no prefixo anycast; não documentam um incidente. O contexto vem de RFC 3056, 3068, 2827, 3704, 6343, 7526, 6169, 1812 e 3756. Elas não provam ataque nomeado, falha de fornecedor, vítima, volume, população de relays nem implantação universal de filtros.