Resumo

  • Renumerar IPv6 é estabelecer antes de retirar, não executar um único comando: os prefixos antigo e novo precisam coexistir enquanto rotas, filtros, endereços, DNS e dependências avançam em ritmos diferentes.
  • Inferência operacional: vidas preferencial e válida, prazos de prefixos delegados e de resolvedores, caches DNS positivos e negativos, seleção de origem e sessões longas formam uma fronteira única de mudança.
  • A reversão não é uma transação atômica do protocolo. Precisa ser exercitada enquanto o operador ainda controla o prefixo antigo, a zona reversa e os dois caminhos de tráfego.

A mudança que já se dividiu

Numa filial, o novo agregado já aparece a montante e a zona autoritativa publica o novo AAAA. Uma sonda chega ao serviço pelo endereço novo. Mesmo assim, o roteador local conserva o prefixo delegado anterior, um resolvedor recursivo serve a resposta antiga em cache e uma sessão de banco de dados continua presa ao endereço anterior. Novos fluxos evitam esse endereço quando ele se torna depreciado; a sessão existente não migra sozinha.

Cada subsistema pode estar dizendo a verdade: a rota subiu, o DNS mudou, o cliente recebeu outro endereço e o serviço responde. O conjunto ainda pode ser inseguro porque essas afirmações pertencem a relógios diferentes.

O RFC 4192 descreve a renumeração sem uma parada geral: instalar o novo prefixo mantendo o antigo, alcançar um estado estável com os dois, transferir o uso e só então retirar o anterior. O documento oferece um esqueleto adaptável, não uma automação universal. Os mecanismos existem; a prova operacional continua sendo responsabilidade do operador.

Um prefixo está em muito mais lugares que a rota

Endereços IPv6 aparecem no plano de enlaces, interfaces, Router Advertisements, DHCPv6, delegação de prefixos, filtros de entrada e saída, ACLs, configuração de serviços, DNS direto e reverso, listas de permissão, monitoramento e caches de aplicações. O RFC 6879 acrescenta configurações manuais, sessões duradouras e sistemas fora do controle direto da equipe.

O inventário faz parte da evidência. Uma busca sem literais ajuda, mas não basta: o endereço pode ser derivado, permanecer na memória de um processo, ter sido copiado para o filtro de um parceiro ou estar numa filial desligada durante toda a sobreposição. O recibo precisa registrar superfície, versão, responsável e exceções.

Preferencial, válido e em uso não são sinônimos

O RFC 4862 dá dois relógios a um endereço autoconfigurado. Ao terminar a vida preferencial, ele fica depreciado. Ao terminar a vida válida, fica inválido. O RFC 6724 orienta a seleção de origem a evitar um endereço depreciado quando há alternativa preferencial.

A depreciação muda novas comunicações; não comprova o fim de sessões antigas, a atualização de um par salvo nem o desaparecimento do AAAA antigo em clientes externos. Manter o endereço válido preserva recuperação, mas pode esconder dependências se o tráfego não for medido por prefixo e idade do fluxo.

A regra de duas horas do RFC 4862 também limita a redução abrupta da vida válida por um Router Advertisement não autenticado. Essa defesa evita invalidação maliciosa, mas significa que um comando emergencial não é necessariamente um desligamento universal. O procedimento deve refletir o comportamento do host, e não só a intenção do controlador.

Filial e resolvedor usam relógios próprios

O RFC 8415 transporta vidas preferencial e válida para endereços e prefixos delegados, além de renovação e rebinding. Um roteador de borda pode manter um IA_PD antigo quando a rota superior, um host SLAAC e a zona autoritativa já mudaram. Uma filial desligada durante a sobreposição pode voltar com estado local nunca testado.

O RFC 8978 mostra que prefixos SLAAC obsoletos podem persistir após uma renumeração rápida. O RFC 9096 recomenda coordenar as vidas anunciadas por Router Advertisement com a validade restante do prefixo delegado. São considerações operacionais, não garantia de comportamento idêntico em todo roteador de borda. O RFC 4472 observa ainda que aplicações de longa duração podem reter resultados DNS além do TTL do registro; isso exige medição da aplicação, não define uma duração universal de cache.

O DNS adiciona outros relógios. TTLs governam AAAA e PTR em cache. A publicação entre servidores autoritativos tem seu prazo. Endereços de resolvedores e listas de busca aprendidos por Router Advertisement têm vidas RDNSS e DNSSL próprias no RFC 8106. Renumerar o serviço e renumerar o resolvedor usado para encontrá-lo são transições diferentes.

Respostas positivas não esgotam o problema. O RFC 2308 define cache negativo. Um resolvedor que perguntou por um registro antes de sua criação pode continuar respondendo negativamente depois da publicação. Registrar só o TTL do AAAA não limita essa falha.

O RFC 4861 completa a superfície local: hosts interpretam ao longo do tempo as informações de roteador e prefixo nos anúncios. É preciso observar o que aprenderam, não apenas o que o roteador foi configurado para enviar.

Convergência é o máximo, não a média

Inferência operacional: o modelo útil toma o máximo dos relógios ainda abertos de rota, filtro, PIO, IA_PD, RDNSS, cache positivo, cache negativo, aplicação e sessão, somado a toda exceção estática sem temporizador.

Uma média esconde a filial desligada, o resolvedor com cache negativo mais longo, a ACL de parceiro alterada por chamado e o equipamento que só resolve o servidor na inicialização. O denominador certo contém toda dependência e ponto de observação declarado, não só os dispositivos que responderam na janela.

Uma sonda prova alcance no prefixo novo. Uma consulta DNS prova a resposta atual de um resolvedor. Um registro de fluxo prova uso observado. Nenhum autoriza isoladamente a retirada. A evidência decide quando tudo está ligado à mesma versão e ao mesmo livro de exceções.

Fontes