Resumo

  • A IESG aprovou a revisão 16 da especificação de NAT64 stateful como Internet Standard, preservando uma separação explícita entre mapear e filtrar.
  • O comprovante operacional deve registrar a tupla atribuída e a política de entrada em campos distintos, com testes próprios para protocolo, direção e origem.

Uma equipe de homologação abre conexões do mesmo endereço e porta IPv6 para vários servidores IPv4. Enquanto o vínculo existe, o tradutor reutiliza o mesmo endereço e porta IPv4 públicos. A linha “mapeamento independente de endpoint” recebe um resultado verde, corretamente.

O problema aparece na linha seguinte. “Retorno restrito” também fica verde porque a planilha o derivou do teste anterior. Nenhum pacote partiu de uma origem IPv4 que o cliente jamais contatou. A ação padrão não foi consultada e a regra instalada não foi capturada. A planilha confundiu a identidade externa de um fluxo com a autoridade para alcançá-lo.

Em 4 de setembro de 2026, a IESG aprovou a revisão 16 de Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers como Internet Standard. Pediu ainda ao RFC Editor que a colocasse no STD 103. O comunicado diz que a técnica é amplamente implementada e implantada, que o novo texto substitui a RFC 6146 e que o processo não identificou grande controvérsia.

Isso ainda não autoriza citar uma RFC sucessora publicada. No corte desta pesquisa, o Datatracker mantinha a revisão 16 na fila do RFC Editor, bloqueada por uma solicitação de informação aos autores. O histórico do documento comprova a aprovação, não um número final que ainda não apareceu.

Também seria incorreto anunciar uma mudança repentina no protocolo. A mensagem da IESG descreve as erratas 4756 e 8416 como correções editoriais ou esclarecimentos, sem efeito sobre comportamento ou interoperabilidade. O apêndice A da revisão 16 reforça esse limite. A RFC 6146 registra a base anterior. O ganho editorial está em enxergar com mais nitidez uma separação que a operação já deveria respeitar.

O mapeamento escolhe a representação pública

O NAT64 stateful mantém vínculos entre endereços de transporte IPv6 e IPv4. Em TCP e UDP, cada endereço de transporte reúne IP e porta. Quando o fluxo para e o temporizador vence, o vínculo dinâmico libera a combinação IPv4 para novo uso.

No mapeamento independente de endpoint, a mesma origem IPv6 recebe a mesma tupla externa ao conversar com destinos IPv4 diferentes durante a janela do vínculo. A RFC 4787 exige esse comportamento para NAT UDP porque ele favorece aplicações par a par e técnicas de travessia. Ao mesmo tempo, afirma que o tipo de mapeamento não determina as propriedades de segurança; o filtro determina quais pacotes entram.

A RFC 5382 aplica a distinção a TCP. A aplicação consegue aprender e divulgar uma tupla externa previsível, mas o contato do par continua sujeito à política de segurança do NAT. Portanto, o teste de mapeamento responde “qual combinação representa esta origem?”. Não responde “qual remetente externo ganhou acesso?”.

O texto aprovado obriga o tradutor a oferecer mapeamento independente de endpoint e permite suporte adicional a mapeamento dependente de endereço. Uma folha de capacidades pode listar ambos. A evidência de execução precisa identificar o escolhido, mas nem isso revela o filtro ativo.

A filtragem decide quem atravessa o estado

A revisão 16 descreve o contraste. Com um vínculo existente e sem filtragem, pacotes de qualquer nó IPv4 destinados àquela tupla externa podem atravessar a função e seguir para o endereço de transporte IPv6. A abertura resulta da soma entre estado e ausência de filtro, não do nome do mapeamento isolado.

Sem trocar o modo de mapeamento, um filtro dinâmico dependente de endereço pode limitar o retorno às origens IPv4 que o host IPv6 contatou antes. Uma negação explícita ou uma política de negar por padrão elimina as demais. A mesma tupla pública passa a ter outra superfície de entrada.

Há uma escolha legítima. Para UDP, a RFC 4787 recomenda filtragem independente quando a transparência da aplicação é prioritária e filtragem dependente de endereço quando importa maior rigor. O administrador pode configurar a opção. Para TCP, a RFC 5382 permite que o comportamento seja diferente do usado em UDP. Não existe um único adjetivo do equipamento capaz de substituir essas escolhas.

ICMP exige outro cuidado. A RFC 5508 trabalha com identificador de consulta no lugar de porta. Ao resolver a errata 4756, a revisão 16 esclarece que ICMP não possui, naquele ponto, uma regra de filtragem dependente de endereço análoga à de TCP e UDP. Reaproveitar automaticamente o resultado de UDP para ICMP mede uma categoria errada.

Um vínculo estático cobra contexto completo

O capítulo de segurança alerta que um filtro limitado à quíntupla pode ser adivinhável em certos mapeamentos estáticos. A implementação pode acompanhar números de sequência TCP para verificar SYN e FIN, mas essa defesa é opcional. Nem o vínculo estático nem uma tradução bem-sucedida provam que ela foi ativada.

Os recursos do tradutor também acabam: endereços e portas IPv4, tabelas de vínculos e sessões, memória para fragmentos e capacidade de enlace. A especificação trata de limites de armazenamento e da configuração correta da interface que representa o lado externo para algumas defesas de duração. Sem registrar direção, protocolo, temporizadores e a origem estática, dinâmica ou PCP do vínculo, o teste não pode ser auditado depois.

A RFC 7269 discute experiência de implantação, alta disponibilidade e segurança. A RFC 8683 amplia a orientação sobre NAT64/464XLAT. Elas mostram dependências operacionais além do tradutor. Nenhuma transforma reutilização de porta em atestado de firewall.

Um recibo, duas linhas de prova

Daniel Kade propõe um recibo de decisão de mapeamento e filtragem. O cabeçalho identifica tradutor, versão do software, interface, direção e protocolo. Campos independentes guardam o modo de mapeamento, o modo de filtro, a ação padrão, a origem estática, dinâmica ou PCP do estado, temporizadores, versão da política, aprovador, limites de recurso e validade das exceções.

Depois vêm os resultados. Uma família de testes confirma a reutilização da tupla em destinos diferentes. Outra envia pacotes de fontes permitidas e negadas. Regras efetivamente instaladas, contadores, alarmes e uma repetição após failover ligam intenção à execução.

O recibo não certifica o produto inteiro nem promete segurança permanente. Ele sustenta uma afirmação estreita: nesta versão, interface e protocolo, o sistema mapeou assim e filtrou assado. Mudança de software, política, papel da interface, temporizador, vínculo estático ou nó ativo invalida a parte afetada.

The Policy Mirror procura o lugar em que a regra ganha força; alocação e entrada são lugares distintos. Running-Code Primacy pede a observação de ambos. Reality, Not Advocacy impede a extrapolação: a norma descreve escolhas, não comprova a falha de uma rede específica.

Fontes