Summary

  • A revisão 10 do rascunho da IETF propõe usar o prefixo NAT64 conhecido para endereços IPv4 privados e compartilhados. O texto está em Last Call do IESG até 23 de novembro de 2026.
  • O CLAT não gerenciado passaria a traduzir esses pacotes por padrão. O PLAT gerenciado precisa oferecer opção para desativar a tradução; a orientação é manter o bloqueio atual durante atualizações.
  • Um prefixo único reduz a confusão dos clientes, mas torna indispensável identificar o domínio de roteamento e escrever permissões de acesso para cada serviço interno.

Há uma regra de segurança escondida em uma norma de endereçamento. A seção 3.1 da RFC 6052 proíbe representar um IPv4 não global com o prefixo 64:ff9b::/96 e manda o tradutor descartar o pacote. Mesmo uma rede sem uma regra explícita de firewall para aquele fluxo pode ter sido protegida por essa proibição. A nova proposta retira o atalho. Quem quiser alcançar o serviço privado terá de dizer por que e de onde.

A cautela antiga fazia sentido. Endereços da RFC 1918 são reutilizados em organizações diferentes. Dois equipamentos podem ser 10.0.0.1 ao mesmo tempo, sem compartilhar identidade ou autoridade. O prefixo IPv6 conhecido não escolhe por magia qual deles é o destino. Por outro lado, o bloqueio absoluto impede um dispositivo só com IPv6 de falar com uma aplicação interna que ainda usa IPv4. A proposta também abrange endereços compartilhados da RFC 6598.

O problema que dois prefixos não resolvem

Uma solução aparente separa os destinos: prefixo conhecido para a Internet, prefixo próprio da rede para o IPv4 interno. Quando o DNS64 sintetiza a resposta, o servidor pode escolher. Mas um aplicativo pode entregar ao CLAT um endereço IPv4 literal. O cliente monta o destino IPv6 localmente; a política do DNS64 sequer entra na conversa.

Segundo o rascunho, a descoberta da RFC 7050 e o anúncio da RFC 8781 informam quais prefixos existem, mas não entregam uma tabela que associe cada faixa IPv4 a um deles. Um cliente que aprende dois prefixos pode sintetizar dois destinos para o mesmo IPv4 público. O operador ganha duas trilhas de log, filtro e diagnóstico. Acrescentar o prefixo local da RFC 8215 ao conhecido preserva essa dificuldade de escolha.

A revisão 10 muda diretamente a ordem da RFC 6052. O prefixo conhecido poderia representar IPv4 não global. Um CLAT não gerenciado traduziria por padrão. O PLAT gerenciado traduziria salvo configuração contrária e deveria ter um controle para desligar o recurso. É uma transferência de poder disfarçada de alteração curta: sai a proibição universal, entra a decisão administrativa de cada rede.

Uma atualização não pode virar passe livre

O próprio rascunho reconhece que administradores podem tratar a queda obrigatória dos pacotes como barreira implícita para sistemas privados. Por isso recomenda preservar o bloqueio padrão nos PLATs existentes ao atualizar o software. Para abrir o caminho de propósito, o operador precisa verificar rota, ACL, firewall ou filtro NAT. A regra deve dizer quais origens chegam a quais destinos e portas. A rota de volta também precisa funcionar.

Imagine duas unidades da mesma empresa, cada uma com um 10.0.0.1. Um tradutor pode converter o pacote corretamente e entregá-lo à unidade errada. Conversão bem-sucedida não prova que houve autorização. O número privado só tem significado completo dentro do seu domínio de administração. Se a organização não sabe mapear esse domínio, o prefixo único vira uma chave mestra sem lista de salas.

As implementações atuais de CLAT tampouco concordam entre si: o rascunho relata aparelhos que descartam e outros que traduzem. Não apresenta uma contagem. O dado que cada rede precisa produzir é próprio: quais clientes fazem síntese local, quais tradutores aceitam tráfego privado, quais serviços correspondem aos endereços e onde estão as regras que permitem acesso. Sem esse levantamento, a discussão sobre a vantagem técnica do novo texto chega antes da discussão sobre controle.

A revisão segue em Last Call e a RFC 6052 continua sendo a norma publicada. O mérito do debate é obrigar o operador a assumir uma escolha antes escondida. Ter o caminho técnico para um serviço interno é útil; conceder a passagem exige dono, rota e regra verificável.

Rascunho da IETF · RFC 6052 · RFC 1918 · RFC 6598