Resumo

  • Em 4 de setembro de 2026, o IESG aprovou a revisão do NAT64 stateful como Internet Standard. A decisão reconhece uma tecnologia madura e amplamente implementada, mas não certifica produto, configuração, capacidade ou continuidade operacional.
  • Cada cliente IPv6 recebe por algum tempo uma reivindicação sobre endereço e porta IPv4 escassos. BIB, sessão, filtro, timer, réplica e comprovante da aplicação precisam continuar separados para que capacidade e atribuição sejam demonstráveis.

O anúncio do IESG aprovou draft-ietf-v6ops-rfc6146-bis-16 como Internet Standard. O texto deverá substituir o RFC 6146 e entrar no STD 103. O Datatracker registra que o anúncio foi enviado e que a ação da IANA segue em andamento. As fontes consultadas ainda não apresentavam o número final do novo RFC.

O marco é importante: a decisão técnica foi tomada. Também tem limite: a publicação editorial ainda percorre suas últimas etapas. Essa diferença impede tanto reduzir a notícia a uma proposta quanto atribuir ao documento um número que ainda não apareceu.

O status mudou; a prova local não mudou com ele

A versão 16 aprovada resolve duas erratas sem mudar o protocolo, atualiza referências, esclarece a preservação da paridade de portas e acrescenta considerações operacionais não normativas. O RFC 6146 permanece como base histórica do comportamento, dentro do quadro de tradução do RFC 6144.

A lista de implementações inclui produtos, nuvens, sistemas e projetos abertos. O próprio documento informa que ela foi montada com dados públicos, não é endosso da IETF e não foi formalmente confirmada por testes de interoperabilidade específicos para esta publicação. O RFC 7942 trata essas listas como auxílio ao processo, não como selo de conformidade.

Logo, o nome de um fornecedor não comprova versão, filtro, pool, relógio, réplica ou registro. A ideia de Running-Code Primacy dá a hierarquia correta: o padrão define o que comparar; o código em execução e o resultado observado dizem o que aquela instalação realizou.

O recurso é uma tupla temporária

O NAT64 stateful permite que clientes apenas IPv6 falem com servidores IPv4 por UDP, TCP ou ICMP. Um conjunto pequeno de endereços públicos é dividido entre muitos clientes. A unidade alocada é endereço IPv4 mais porta, ou endereço mais identificador ICMP.

Essa combinação vale durante um intervalo e pode mudar de dono depois. Registrar apenas o IPv4 público não identifica uma sessão. Mesmo endereço e porta, sem protocolo, tempo, incerteza do relógio e geração do tradutor, podem apontar para a pessoa errada.

O tradutor tenta preservar faixa e paridade de porta. Se não houver uma tupla adequada, pode retornar ICMPv6; a política local pode suprimir a mensagem. Assim, o timeout do usuário não comprova exaustão. O ponto final pode estar na política de alocação, no filtro, na rota, no tradutor, no servidor ou no aplicativo.

O ganho de eficiência traz custo de evidência. O RFC 6269 descreve problemas do compartilhamento de endereços. O RFC 6888 reúne requisitos de logging para tradutores de grande escala. A versão 16 observa que maximizar portas por endereço reduz o pool necessário, mas aumenta os arquivos de log.

O registro mínimo contém tupla externa, protocolo, tupla IPv6 interna, início e fim, precisão temporal, instância, geração do pool e regra aplicada. A reivindicação não é “usar o IP”; é usar aquele transporte naquele intervalo sob aquela autoridade.

A BIB e a sessão não são o mesmo estoque

O protocolo mantém BIBs separadas para UDP, TCP e consultas ICMP. Uma BIB associa um transporte IPv6 a um transporte IPv4. Tabelas de sessão distintas registram os pares que efetivamente conversam e seus estados.

Uma associação independente do destino pode sustentar várias sessões. Uma associação manual pode ficar sem sessão e exigir remoção explícita. Uma sessão pode terminar enquanto a BIB permanece. No TCP, estados transitórios, estabelecidos e de encerramento usam relógios diferentes.

Por isso, o painel precisa preservar identidade e vínculo de cada camada: quando a BIB nasceu, de qual geração veio, quais sessões usaram a tupla, qual pacote renovou o prazo e por que foi removida. Depois de failover, uma entrada reconstruída deve aparecer como sucessora, não como testemunha original.

A disciplina das camadas de realidade evita a falsa soma. “NAT64 habilitado” é configuração; BIB é direito interno; sessão é relação protocolar; pacote traduzido é observação; compra concluída é efeito do aplicativo.

Mapeamento não substitui política de entrada

O padrão exige mapeamento independente do endpoint. Enquanto a associação existe, o mesmo transporte externo pode ser usado para destinos diferentes. A propriedade de segurança, porém, depende do filtro.

Sem filtragem, uma origem IPv4 que alcance a associação ativa pode atravessá-la. Com filtro dependente de endereço, a volta pode ser limitada aos endereços antes contatados pelo cliente IPv6. O RFC 4787 estabelece os conceitos de UDP; o RFC 5382 cobre TCP e os timers correspondentes.

Uma linha “endpoint-independent” não informa quem pode retornar. É preciso anexar modo de mapeamento, filtro, regra padrão, exceções, BIBs estáticas, versão da configuração e testes vindos de origens permitidas e bloqueadas.

Também importa definir o lado externo. A especificação permite impedir que pacotes vindos desse lado renovem a sessão, reduzindo a retenção hostil. Se o papel da interface estiver errado, a regra age contra o lado errado. O caminho real precisa confirmar o rótulo.

O timer distribui continuidade e escassez

UDP e ICMP têm vidas úteis. O TCP passa por estados com prazos próprios. Fragmentos ocupam memória por tempo limitado. Quando a entrada expira, porta e memória voltam ao conjunto comum.

Um timer curto derruba fluxos legítimos em silêncio; um timer longo conserva experiência, mas segura recursos e pode favorecer abuso. A seção operacional observa que QUIC depende de prazos UDP razoáveis e que Connection IDs do QUIC não devem virar chaves de estado do NAT.

Medir apenas a ocupação média apaga essa decisão. É necessário separar criação, origem da renovação, idade, expiração prevista, remoção prematura, falha de alocação, erro silencioso, estado TCP e memória de fragmentos por geração de política.

O ponto de concentração precisa de capacidade demonstrada

O texto reconhece recursos finitos: endereços e portas IPv4, memória, CPU e link. Origens IPv6 variadas podem consumir associações; fragmentos e SYNs podem ocupar memória; tráfego periódico pode tentar manter estado.

Isso é um modelo de risco, não notícia de ataque. As fontes não mostram falha de um operador específico. Elas justificam medir pool livre, portas por protocolo, BIBs, sessões, memória, latência e recusas separadamente.

O RFC 9693 define uma metodologia de benchmark para gateways NAT com estado. O resultado pertence ao equipamento, versão, configuração, mistura de tráfego, tamanho dos pacotes e método. Não é uma promessa transportável.

A especificação inicial mínima explica por que o padrão não deve impor um tamanho universal de pool. Interoperabilidade fica no núcleo comum; topologia, capacidade e tolerância a falhas permanecem locais. A decisão local, contudo, precisa de dono.

Failover de processo não é failover de direito

O RFC 7269 e o RFC 8683 reúnem experiência operacional, inclusive alta disponibilidade. Nenhum comprova que um cluster específico copiou todas as BIBs, sessões e expirações.

Antes da troca, guardar geração ativa e reserva, watermark, atraso, entradas ausentes, diferença de relógio e dono do pool. Depois, observar fluxos UDP, TCP e ICMP já abertos: quais continuam, renascem ou falham.

Há também risco de dupla autoridade. Dois nós vivos podem acreditar que possuem o mesmo pool e emitir tuplas conflitantes. Um reserva conservador evita a colisão descartando estado não replicado, mas derruba sessões. Continuidade e unicidade precisam de uma regra de negócio explícita.

Atribuição começa pelo relógio, não pelo nome

O RFC 8158 fornece elementos IPFIX para monitorar recursos NAT. Eles mostram consumo e eventos, mas não unem automaticamente BIB, sessão, usuário, pacote e auditoria de aplicação.

Uma amostra deve ser reconstruída nos dois sentidos. Da tupla externa e do horário até instância, pool, BIB, sessão e contexto IPv6; do cliente até a tupla externa válida naquele intervalo. Cada junção carrega desvio e incerteza de relógio. Divergência deve permanecer divergência, não virar identificação forçada.

Internet Standard normaliza comportamento de tradução. Não dá autoridade absoluta aos logs, não resolve a lei de retenção, não identifica um humano, não comprova uma ordem aplicada e não atribui responsabilidade.

O avanço é valioso porque deixa essa fronteira nítida. A IETF estabeleceu um mecanismo comum maduro. O operador continua controlando pool, filtros, timers, redundância e registros. Onde o controle permanece, a obrigação de prestar contas também permanece.

Fontes