Resumo

  • O RFC 3041 tratou de um problema delimitado de privacidade no IPv6: um identificador de interface derivado da camada de enlace podia continuar visível nos endereços mesmo depois de o dispositivo passar para outro prefixo de rede.
  • Endereços temporários podiam dificultar a correlação direta baseada em endereços, mas não escondiam o prefixo, apagavam identificadores de aplicativos nem tornavam o host anônimo.

A autoconfiguração sem estado do IPv6 (SLAAC) permitia que um host formasse um endereço combinando informações locais com um prefixo anunciado por um roteador. Na arquitetura discutida pelo RFC 3041, o prefixo indicava a localização na rede; o identificador de interface completava o endereço. Os primeiros identificadores podiam derivar de um identificador IEEE ou da camada de enlace. Se esse valor permanecesse fixo, o prefixo mudaria o endereço, mas deixaria uma parte reconhecível.

Isso importava porque o endereço aparece no cabeçalho IP. Mesmo com o conteúdo criptografado, o endereço de origem visível podia ajudar alguém a ligar transações diferentes. Um notebook poderia surgir em redes distintas com prefixos diferentes e ainda conservar em cada endereço um identificador que sugerisse continuidade. O RFC 3041 descrevia um risco de correlação, não uma prova de que o observador identificou uma pessoa nem de que todo dispositivo usava o mesmo método de geração.

A proposta não substituiu a SLAAC por outro sistema de endereçamento. Ela acrescentou endereços temporários de escopo global aos endereços comuns. Ao iniciar uma conexão, o host podia preferir um endereço temporário como origem. Um endereço estável continuava útil para receber conexões, constar no DNS ou oferecer um destino previsível para aplicativos e administradores. Esse modelo de dois endereços fazia da seleção da origem o ponto operacional central: proteger a comunicação de saída e manter a disponibilidade de entrada eram tarefas diferentes.

O RFC 3041 descrevia identificadores de interface aleatorizados a partir de um histórico variável e os usava para criar endereços temporários para os prefixos anunciados. Os padrões sugeridos eram uma vida preferencial de um dia e uma vida válida de uma semana, sujeitas à política do usuário ou da implementação e às durações do prefixo. Um endereço substituto podia ser gerado antes de o anterior ser despreferido. O endereço despreferido podia continuar válido para uma conexão existente, enquanto conexões novas deveriam usar um endereço preferido.

Rotacionar, portanto, era administrar estados de endereço sobrepostos — não trocar a origem de cada pacote.

O projeto mirava uma pista específica de correlação: reutilizar a mesma parte do endereço entre transações separadas. Ele não removia o prefixo de rede, que ainda podia revelar topologia ou agrupar atividades por local. Também não mudava nomes DNS, cookies, contas, comportamento de aplicativos, horários do tráfego ou outros identificadores. Um servidor ainda poderia reconhecer uma conta autenticada; alguém no caminho ainda poderia comparar padrões de tráfego. Uma comunicação também podia revelar um endereço temporário que continuaria acessível durante a validade. Reduzir a reutilização de endereços não é garantir anonimato.

Manter endereços temporários e estáveis também tinha custos. A rotação complica a atribuição em capturas de pacotes, listas de controle de acesso, expectativas de DNS reverso, diagnóstico e algumas conexões longas. Um aplicativo pode precisar de um destino estável, e um administrador pode preferir registros previsíveis. Por isso, o RFC 3041 deixou margem para que aplicativos, implementações e administradores confiáveis influenciassem o uso de endereços temporários. A rede não tomava essa decisão por cada aplicativo.

A história das normas não significa que os detalhes de 2001 continuem atuais. O RFC 4941 substituiu o RFC 3041 em 2007; o RFC 8981 substituiu o RFC 4941 em 2021. A linhagem atual mantém a geração de endereços temporários, mas revisa algoritmos e recomendações. O RFC 7217 e o RFC 8064 tratam de uma escolha próxima, mas distinta: identificadores estáveis que não expõem diretamente um identificador de hardware. Um endereço temporário muda ao longo do tempo; um identificador estável e opaco pode mudar entre redes e permanecer estável dentro de cada rede.

A questão duradoura do RFC 3041 não era “É possível tornar os endereços IPv6 privados?”. Era mais específica: quando o prefixo da rede muda, o que ainda permite ligar atividades dentro do endereço e quem decide qual origem um aplicativo apresenta? Endereços temporários reduziam uma janela de observação. Não resolviam identidade, disponibilidade nem todas as outras formas de associar um dispositivo às suas atividades.

Fontes