Resumo

  • Endereços temporários reduzem a ligação baseada em um IID constante ao limitar por quanto tempo ele é preferido para novas sessões de saída e ao preparar um sucessor antes da depreciação.
  • Um endereço depreciado continua válido e pode sustentar comunicações existentes; só o fim da validade o torna inválido e impróprio como origem ou destino.
  • Rotação não significa anonimato, criptografia ou autenticação. Prefixo, endereço estável, contas, cookies, registros, padrões de tráfego e observação no enlace continuam disponíveis.

O mecanismo começa com uma escolha, não com um desaparecimento. Uma interface pode manter um endereço estável e um endereço temporário preferido. Este último inicia novas comunicações. Pouco antes do fim de sua vida preferida, o host gera outro, executa a detecção de duplicidade e deixa o sucessor pronto. O primeiro passa a depreciado. Ele deixa de ser a escolha normal para trabalho novo, mas ainda pode carregar uma conexão em andamento. Só depois, com o fim da vida válida, deixa de pertencer à interface.

Essa passagem de bastão limita o tempo em que um observador pode usar o mesmo identificador de interface como chave. Ela não apaga as demais chaves.

Quando o identificador atravessava redes

Na autoconfiguração sem estado, o endereço IPv6 combina um prefixo anunciado pelo roteador com um identificador de interface. Quando esse identificador vinha de um identificador IEEE globalmente único, a parte inferior do endereço podia permanecer reconhecível por muito tempo. Um notebook mudava de rede e ganhava outro prefixo, mas carregava um elemento que ajudava a unir observações.

A RFC 3041, publicada em janeiro de 2001, criou endereços globais adicionais a partir de identificadores que mudavam. Eles seriam usados para iniciar sessões de saída durante horas ou dias, depois depreciados e substituídos. Conexões já estabelecidas poderiam continuar no endereço antigo. A proposta preservava a autoconfiguração básica e não prometia remover todo endereço estável.

O ganho dependia da seleção de origem. Gerar um endereço temporário sem escolhê-lo para novas sessões não mudaria o que o par remoto via. Escolhê-lo sem impor um prazo criaria outro identificador duradouro. Geração, preferência e expiração formavam um único controle.

De uma extensão opcional a um ciclo mais rigoroso

A RFC 4941 substituiu a RFC 3041 em setembro de 2007. Passou a exigir Detecção de Endereço Duplicado em todos os endereços temporários, ofereceu controle por prefixo, permitiu IIDs distintos para prefixos distintos e deixou de limitar a geração ao MD5. Ainda recomendava desativar endereços temporários por padrão. A vida preferida sugerida era de um dia; a vida válida, de uma semana.

Além disso, o comportamento padrão podia reutilizar o mesmo IID aleatório em vários prefixos da interface, reduzindo o número de grupos multicast necessários. A economia operacional preservava uma ligação entre endereços que o usuário mais preocupado com privacidade poderia querer separar.

A RFC 8981, de fevereiro de 2021, é a regra atual. Ela removeu a recomendação de desativação por padrão. Exigiu IIDs estatisticamente diferentes entre todos os endereços temporários do host, inclusive em prefixos e interfaces distintos. O fator de dessincronização passou a ser calculado para cada novo endereço, para que a renovação não siga um relógio fixo. A vida válida máxima padrão caiu de sete para dois dias, mantendo um dia como vida preferida padrão.

Essas mudanças mostram que “aleatório” não bastava. Reutilização entre prefixos, cadência previsível e longa sobreposição também produziam evidência. A história do mecanismo é a história de tornar o próprio ciclo menos correlacionável.

A RFC 8981 não obriga a coexistência de um endereço estável. Uma implementação pode usar estáveis e temporários ou apenas temporários. Portanto, um pacote isolado não revela o inventário da interface. A presença de um temporário não prova ausência de estado estável; sua troca não explica, sozinha, o motivo.

Preferido, depreciado, inválido

A RFC 4862 estabelece as três condições. Um endereço preferido pode ser usado sem restrições. Quando sua vida preferida termina, ele se torna depreciado. Seu uso é desencorajado, sobretudo para iniciar nova comunicação, mas ele ainda é válido. Pacotes destinados a ele continuam sendo processados, e uma aplicação pode mantê-lo se a troca interromperia uma atividade existente.

Quando a vida válida termina, a associação com a interface termina. O endereço inválido não pode aparecer como origem e não deve ser reconhecido como destino. Depreciação, portanto, orienta seleção; invalidação encerra usabilidade.

Para evitar um intervalo sem endereço temporário preferido, a RFC 8981 manda começar a regeneração REGEN_ADVANCE antes da depreciação. Geração e detecção de duplicidade podem consumir tempo. Em operação normal, há no máximo um temporário não depreciado por prefixo e interface, exceto no breve período de substituição. Endereços antigos, depreciados mas válidos, podem coexistir até as camadas superiores terminarem.

TEMP_PREFERRED_LIFETIME de um dia e TEMP_VALID_LIFETIME de dois dias são valores padrão ajustáveis. O anúncio do prefixo pode impor limites menores. Um DESYNC_FACTOR próprio de cada endereço reduz aleatoriamente sua vida preferida. Não se deve transformar esses padrões em afirmação sobre todo sistema operacional ou toda implantação.

Ao entrar em um enlace realmente diferente, a interface deve remover os temporários anteriores e criar novos para o novo enlace. Isso evita carregar o mesmo IID aleatório entre locais. Uma implementação pode distinguir mudança real de enlace de uma breve queda e retorno no mesmo enlace, evitando regenerações sem significado de privacidade.

O que a rotação não encobre

O endereço IP fica visível ao par, aos sistemas no caminho e aos serviços que registram conexões. Um IID constante oferece uma chave barata para agrupar transações. Endereços temporários quebram essa chave em períodos menores. Sessões posteriores escolhem sucessores; um endereço revelado também permanece alcançável por menos tempo.

O prefixo, porém, pode continuar estável e identificar uma residência ou rede com poucos hosts. Um endereço estável pode aparecer em outro fluxo. Nome DNS, cookie, conta autenticada e registros do serviço podem unir os períodos. O roteador padrão, como observador no enlace, pode acompanhar todos os endereços. Um observador no caminho pode comparar tamanho e horário dos pacotes mesmo com conteúdo criptografado.

O mecanismo não criptografa cabeçalhos nem dados. Não autentica usuário, host ou interlocutor. Não oferece anonimato e não retira informação já entregue. Se o usuário fizer login, o serviço pode ligar aquela conta ao endereço temporário da sessão. Expiração reduz uma superfície de correlação; não substitui segurança de transporte ou privacidade da aplicação.

A fronteira operacional

Para operações, um host pode surgir como vários registros. Um defeito recorrente pode parecer vários equipamentos. Controles de segurança podem confundir renovação rápida com falsificação de origem. Vários endereços válidos consomem cache de vizinhos e grupos multicast. Aplicações que exigem o mesmo endereço em sessões relacionadas podem falhar quando a seleção muda ou quando o antigo se torna inválido.

A evidência deve ser temporal: endereço, horário, prefixo, interface ou enlace, estado de preferência e, quando necessário, fluxo ou sessão autenticada. Um endereço visto ao meio-dia prova aquela comunicação, não um nome permanente de ativo. Um depreciado ainda em uso não indica falha de rotação; um inválido não prova que a aplicação migrou corretamente.

O roteador controla anúncios de vida do prefixo. O host executa geração, depreciação e invalidação. O administrador define política global ou por prefixo. O sistema e a aplicação influenciam a seleção de origem. Pares e redes mantêm seus próprios registros. A especificação coordena os relógios sem entregar uma visão completa a qualquer ator.

O resultado histórico foi preciso: tornar perecível uma parte visível do endereço. A proteção veio de retirar do identificador antigo o direito de ser a escolha padrão da próxima conexão, não de declarar o usuário invisível.

Fontes