Resumo

  • RFC 9872 recomenda obter PREF64 pela opção de Router Advertisement do RFC 8781 quando disponível; RFC 7050 fica como alternativa para ausência do anúncio ou sistemas legados.
  • O estado operacional é a associação temporária entre prefixo, roteador anunciante, origem IPv6, próximo salto e resultado no tradutor, e não apenas uma cadeia de bits válida.

Dois acessos estão ativos. O DNS64 do primeiro entrega um PREF64 correto, mas a política do host escolhe a origem e o gateway do segundo. A síntese funciona e o pacote sai; o tradutor correspondente permanece do outro lado. Um inventário por campo diria que tudo estava configurado. Um inventário por relações mostraria a falha.

RFC 9872, documento Informational de consenso da IETF publicado em setembro de 2025, recomenda que endpoints tentem primeiro a opção PREF64 de RFC 8781. Operadores com NAT64 devem anunciá-la. O método DNS de RFC 7050 continua possível na falta da opção ou para equipamentos antigos.

O PREF64 segue os formatos de RFC 6052 e permite incorporar um IPv4 em um destino IPv6. Ele habilita DNS64 local conforme RFC 6147, CLAT na arquitetura 464XLAT e conversão de literais IPv4 em RFC 8305. Conhecer o formato não prova qual interface leva ao tradutor.

RFC 7050 extrai o prefixo de respostas AAAA sintéticas para ipv4only.arpa.; RFC 8880 exige tratamento especial para esse nome. A descoberta depende do DNS64 fornecido pela rede ou de lógica especial no endpoint. Um resolvedor escolhido pelo usuário ou uma VPN de túnel dividido que substitui DNS pode quebrar o processo, embora parte do tráfego continue na rede local.

No multihoming, dois provedores podem entregar dois PREF64. A resposta DNS não oferece ligação confiável entre cada prefixo, o provedor, o prefixo de origem e o gateway. Escolher um elemento de cada conjunto pode produzir uma rota impossível. O problema não é ausência de dados; é perda de proveniência entre dados válidos.

O Router Advertisement mantém o contexto do primeiro salto. RFC 4861 já usa RA para anunciar roteadores e parâmetros IPv6. RFC 8781 acrescenta o PREF64 e uma vida útil escalada. O host consegue lembrar qual roteador anunciou qual prefixo e parar de usá-lo quando recebe vida zero. Ainda precisa verificar confiança do anúncio, rota e saúde do tradutor.

O mecanismo também devolve ao operador poder de atualização. A consulta DNS ocorre depois da configuração da pilha e fica presa ao TTL; se o DNS64 for externo, o operador talvez não controle esse prazo. Um novo RA pode alterar ou retirar a informação imediatamente. A diferença relevante é quanto tempo um estado incorreto permanece executável.

Evitar a resposta DNS como fonte reduz uma superfície de falsificação, mas desloca segurança para o primeiro salto. RFC 6105 descreve RA-Guard, sem transformar todo anúncio permitido em verdade. RFC 9463 anuncia resolvedores designados e opções de transporte seguro; criptografia não vincula por si só o prefixo à saída.

A migração exige coexistência medida. Endpoints conformes que entendem RFC 8781 devem preferi-lo; legados podem depender de RFC 7050. RFC 9872 reconhece ainda que sistemas móveis suportam a opção enquanto certos equipamentos da rede móvel não conseguem inseri-la. O registro oficial comprova a publicação, não a adoção por uma operadora.

A primazia do código em execução de Heng Lu pede resultado de rota reproduzível. Sua especificação inicial mínima apoia um sinal comum estreito e decisão local. Sua crítica ao imposto dual-stack permanente atribui aos operadores o custo real de manter resolvedor, RA, defesa e tradução simultaneamente.

RFC 9872 melhora a decisão porque reduz a distância entre a informação e seu domínio de validade. O prefixo continua sendo evidência limitada; encaminhamento, tradução e sucesso da aplicação continuam sendo provas diferentes.

Fontes