Implantação de NAT64: guia prático para provedores

Como funciona a implantação de NAT64?

O NAT64 trabalha em dupla com o DNS64: um fabrica o endereço IPv6 de destino, o outro traduz os pacotes desse endereço para IPv4. Sem as duas peças, o cliente só IPv6 não chega a um site que não tem IPv6.

O cliente pergunta ao DNS o endereço de um site. Se o site só tem registro A, o DNS64 responde com um registro AAAA formado pelo prefixo do NAT64 mais o IPv4 do site. O aparelho manda o tráfego para esse endereço, e o NAT64 faz a tradução com estado, guardando a associação entre o cliente e a porta IPv4 usada.

Com esse arranjo, a rede de acesso pode rodar só IPv6, e o IPv4 fica concentrado num ponto da rede. É uma das peças possíveis do dual stack e da transição para provedores, quase sempre usada depois que a base já navega nos dois protocolos.

Como o DNS64 monta o endereço sintetizado

Com o prefixo padrão, os últimos 32 bits do endereço IPv6 carregam o IPv4 do destino escrito em hexadecimal. A tabela mostra a conta feita para um IPv4 de documentação.

O tradutor faz o caminho inverso: lê os 32 bits finais, recupera 192.0.2.33 e abre a conexão IPv4 a partir de um dos endereços do seu pool, como faria um NAT comum.

Onde o NAT64 fica na rede do provedor

O tradutor costuma ficar entre o concentrador e a borda, no mesmo lugar onde hoje roda o CGNAT. Em muitos provedores, o mesmo equipamento ou servidor faz as duas funções, com pools IPv4 separados.

O tráfego IPv6 nativo, para destinos que já têm IPv6, não passa pelo tradutor. Só o que vai para o prefixo do NAT64 é roteado até ele, o que mantém a carga proporcional ao que ainda depende de IPv4.

Quando vale implantar NAT64 no provedor?

Vale quando o provedor quer entregar redes ou planos só IPv6 e manter o acesso aos sites IPv4 por um ponto central. Para a base residencial comum, ele raramente entra sozinho.

O NAT64 é uma de quatro formas de conviver com o IPv4 na transição. A diferença está no que o assinante recebe e em quem faz a tradução, e a escolha muda o trabalho no concentrador, no BNG e no roteador do cliente.

Na prática, o NAT64 quase nunca chega sozinho à casa do assinante, porque o roteador doméstico e os aparelhos antigos ainda dependem de IPv4. O caminho comum é implantar o NAT64 junto com a implantação de 464XLAT, que acrescenta a tradução do lado do cliente.

Sinais de que o NAT64 faz sentido agora

Alguns cenários pedem NAT64 antes do resto da base. Se dois ou mais aparecem no seu provedor, vale montar o tradutor em laboratório:

• Wi-Fi público ou eventos: redes com muitos aparelhos modernos e poucos IPv4 disponíveis.
• Planos corporativos só IPv6: clientes que pediram rede nova sem IPv4 interno.
• Preparação para 464XLAT: o tradutor central é pré-requisito para tirar o IPv4 da CPE.
• Pool IPv4 no limite: cada assinante que sai do CGNAT para o NAT64 libera endereço e porta.

Implantação de NAT64 passo a passo

A implantação de NAT64 exige quatro decisões antes do primeiro comando: prefixo, onde roda o DNS64, pool IPv4 do tradutor e quais logins recebem o serviço. Depois vem a configuração e o teste com um grupo pequeno.

1. Prefixo: escolha entre o padrão 64:ff9b::/96 e um /96 tirado do bloco IPv6 do provedor.
2. DNS64: decida qual resolvedor fará a síntese e para quais clientes ele será entregue.
3. Pool IPv4: separe os endereços públicos do tradutor, sem misturar com o pool do CGNAT.
4. Roteamento: anuncie o prefixo do NAT64 na rede interna até o equipamento tradutor.
5. Perfil do plano: crie um perfil só IPv6 no concentrador, com o DNS64 como resolvedor.
6. Grupo de teste: ligue o perfil em logins da equipe antes de qualquer assinante.

O exemplo abaixo usa o Unbound como DNS64 e o Jool, em Linux, como NAT64. Fabricantes de roteadores e de concentradores também oferecem NAT64 em hardware, com a mesma lógica de prefixo e pool.

# /etc/unbound/unbound.conf
server:
    module-config: "dns64 validator iterator"
    dns64-prefix: 64:ff9b::/96

# NAT64 com Jool
modprobe jool
jool instance add "nat64" --netfilter --pool6 64:ff9b::/96

Prefixo padrão ou prefixo próprio?

O prefixo padrão 64:ff9b::/96 não pode representar endereços IPv4 privados. Se o cliente só IPv6 precisa alcançar um servidor interno em 10.0.0.0/8 ou 172.16.0.0/12, use um prefixo próprio do provedor.

O prefixo próprio também deixa claro, em qualquer captura ou log, que o tráfego passou pelo seu tradutor. Em troca, DNS públicos com DNS64 não vão conhecer esse prefixo, e o cliente precisa usar o seu resolvedor.

O pool IPv4 do tradutor

O NAT64 compartilha portas IPv4 entre clientes do mesmo jeito que o CGNAT, então o tamanho do pool segue a mesma conta de portas por assinante. Sem um pool definido, o Jool usa os endereços do próprio servidor [CONFIRMAR na documentação do Jool].

Reserve endereços exclusivos para o NAT64 e acompanhe o uso de portas desde o primeiro grupo. Se o mesmo equipamento roda CGNAT e NAT64, pools separados facilitam achar quem usou cada IP numa consulta.

Como entregar o DNS64 só a quem precisa

O DNS64 deve chegar apenas aos logins só IPv6. O jeito mais limpo é amarrar o resolvedor ao perfil do plano no concentrador ou devolvê-lo pelo RADIUS junto com o prefixo do login.

Na sessão PPPoE só IPv6, o IPCP não sobe e o cliente recebe apenas o prefixo e o servidor DNS IPv6. Um resolvedor separado para esses logins evita que o restante da base receba respostas sintetizadas.

O que o NAT64 não resolve sozinho

O NAT64 só funciona quando o aplicativo pergunta ao DNS antes de conectar. Tudo que usa endereço IPv4 escrito direto no código ou na configuração passa ao largo do DNS64 e falha.

Essa é a principal razão para o NAT64 puro ficar restrito a redes controladas. Numa casa comum, sempre aparece algum aparelho ou aplicativo que tenta abrir um IPv4 literal.

• Jogos e aplicativos: alguns trazem endereço IPv4 fixo no código para servidores e matchmaking.
• Equipamentos antigos: câmeras, DVRs, impressoras e TVs que só falam IPv4.
• DNS do cliente: quem configura um resolvedor próprio, sem DNS64, perde os sites só IPv4.
• Validação DNSSEC no aparelho: o registro sintetizado não tem assinatura válida e pode ser recusado.

Para cobrir esses casos, o 464XLAT põe um tradutor pequeno na CPE, que entrega IPv4 à rede da casa. Quem prefere túnel a tradução pode comparar com a implantação de DS-Lite, que leva o IPv4 do cliente encapsulado até o provedor.

MTU e fragmentação na tradução

O cabeçalho IPv6 tem 40 bytes e o IPv4 tem 20 bytes, então o pacote cresce no sentido IPv4 para IPv6. Se o ICMPv6 de pacote grande for bloqueado em algum ponto, páginas e downloads travam no meio.

Deixe o ICMPv6 passar na borda e no tradutor, e teste downloads grandes além da navegação simples. Problema de MTU costuma aparecer como site que abre o texto e não carrega as imagens.

Erros comuns na implantação de NAT64

Os erros mais frequentes vêm de misturar clientes dual stack com clientes só IPv6 e de tratar o tradutor como peça secundária. Os dois aparecem nas primeiras semanas, quando a base cresce.

O primeiro erro é o mais traiçoeiro, porque nada quebra: o cliente dual stack apenas passa a usar a tradução em vez do IPv4 nativo. O sintoma é o tradutor com carga alta e um número de usuários que não bate com os logins só IPv6.

Redundância do tradutor

Com o NAT64 fora do ar, o cliente só IPv6 perde todos os sites que não têm IPv6. Por isso o tradutor merece o mesmo cuidado de alta disponibilidade dado ao CGNAT.

Dois tradutores anunciando o mesmo prefixo com métricas diferentes resolvem a maior parte dos casos. A sincronização de sessões entre eles evita que as conexões caiam na troca, mas exige teste antes de ir para a base.

Checklist de validação do NAT64

Valide sempre a partir de um login só IPv6, porque um cliente dual stack esconde as falhas da tradução. O teste vale para o grupo inicial e para cada mudança no tradutor.

O registro das traduções segue a mesma lógica dos logs do CGNAT, porque o NAT64 também divide um IPv4 público entre vários clientes. A forma e o prazo de guarda dependem da regra aplicável ao provedor [CONFIRMAR na norma].

A Táquion Tech implanta o NAT64 e o DNS64 com redundância e registro das traduções, e testa com logins da sua equipe antes de ligar qualquer assinante.

Perguntas frequentes sobre NAT64

Thiago Manoel

Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]

Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.

A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.

Conheça a equipe da Táquion Tech