NAT64 e DNS64: Conectar Redes IPv6-Only a IPv4

O Futuro IPv6-Only#

Dual-stack — executar IPv4 e IPv6 simultaneamente — é a abordagem de migração padrão. Mas manter duas redes paralelas para sempre não é o objetivo. O ponto final é infraestrutura IPv6-only com IPv4 legado acedido apenas quando necessário.

Esta transição já acontece em redes móveis. Grandes operadoras executam stacks IPv6-only em smartphones. T-Mobile, AT&T e Verizon eliminaram IPv4 das suas redes LTE/5G há anos. O seu telefone tem um endereço IPv6. Quando acede a um website apenas IPv4, NAT64 e DNS64 lidam com a tradução de forma transparente.

Redes empresariais seguem o mesmo caminho. IPv6-only reduz complexidade, elimina preocupações de exaustão de endereços IPv4 e simplifica roteamento. Mas eliminação completa de IPv4 não é realista ainda — muitos serviços permanecem apenas IPv4. NAT64 e DNS64 preenchem esta lacuna, permitindo que redes IPv6-only acedam à Internet IPv4.

Como NAT64 e DNS64 Funcionam Juntos#

NAT64 executa tradução de protocolo na camada de rede. DNS64 sintetiza endereços IPv6 que acionam esta tradução. Funcionam como um par — DNS64 sem NAT64 é inútil, e NAT64 sem DNS64 requer configuração manual.

O Fluxo de Tradução#

Aqui está o que acontece quando um cliente IPv6-only acede a um serviço IPv4-only:

┌─────────────────────────────────────────────────────────────────┐
│ 1. Cliente consulta DNS para www.ipv4only.example.com          │
│    Tipo de consulta: AAAA (endereço IPv6)                      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. Servidor DNS64 consulta DNS upstream                         │
│    Recebe: Registo A → 198.51.100.10 (apenas IPv4)             │
│    Nenhum registo AAAA existe                                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64 sintetiza registo AAAA                                 │
│    Combina prefixo NAT64 + endereço IPv4                        │
│    Resultado: 64:ff9b::198.51.100.10                            │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. Cliente recebe endereço IPv6 sintetizado                     │
│    Envia pacotes para 64:ff9b::198.51.100.10                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. Gateway NAT64 interceta pacotes                              │
│    Reconhece prefixo 64:ff9b::/96                               │
│    Extrai IPv4 embutido: 198.51.100.10                          │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64 traduz IPv6 → IPv4                                     │
│    Muda cabeçalhos de pacote                                    │
│    Executa NAT stateful (rastreia sessão)                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. Pacote IPv4 enviado ao destino                               │
│    Origem: Endereço IPv4 do gateway NAT64                       │
│    Destino: 198.51.100.10                                       │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Tráfego de retorno traduzido de volta                        │
│    NAT64 procura sessão                                         │
│    Traduz IPv4 → IPv6                                           │
│    Encaminha ao cliente                                         │
└─────────────────────────────────────────────────────────────────┘

O cliente vê apenas IPv6. O serviço apenas IPv4 vê apenas IPv4. NAT64 e DNS64 lidam com tradução invisivelmente.

O Prefixo Bem Conhecido#

O prefixo NAT64 padrão é 64:ff9b::/96 (RFC 6052). Este prefixo bem conhecido diz a todos «endereços IPv4 estão embutidos aqui.»

A embutição de endereço IPv4 funciona assim:

Endereço IPv4:   198.51.100.10
Em hex:          C6.33.64.0A
Prefixo NAT64:   64:ff9b::
Combinado:       64:ff9b::c633:640a
Expandido:       64:ff9b::198.51.100.10 (notação comum)

Os últimos 32 bits do endereço IPv6 contêm o endereço IPv4. As aplicações nunca veem isto — é puramente interno à infraestrutura de tradução.

Pode usar prefixos personalizados em vez do prefixo bem conhecido. Escolhas comuns incluem prefixos específicos da organização como 2001:db8:64::/96. Isto permite engenharia de tráfego (rotear tráfego NAT64 diferentemente) mas requer mudanças de configuração DNS64.

DNS64 em Profundidade#

DNS64 é um servidor DNS com lógica de tradução especial. Interceta consultas AAAA e sintetiza respostas quando apenas registos A existem.

Fluxo Lógico DNS64#

Consulta AAAA para example.com
    ↓
Consultar upstream para AAAA
    ↓
Registo AAAA existe? ─ SIM ─→ Retornar registo AAAA (IPv6 nativo)
    │
    NÃO
    ↓
Consultar upstream para A
    ↓
Registo A existe? ─ NÃO ─→ Retornar NXDOMAIN
    │
    SIM
    ↓
Sintetizar AAAA = prefixo + IPv4
    ↓
Retornar AAAA sintetizado

Comportamentos chave:

• IPv6 nativo preferido: Se AAAA existe, DNS64 retorna-o inalterado. Sem síntese. NAT64 não envolvido.
• Fallback IPv4 apenas: Síntese acontece apenas quando AAAA não existe
• Preservação TTL de cache: Registos sintetizados herdam TTL do registo A
• Complexidade DNSSEC: Síntese quebra validação DNSSEC (mais sobre isto depois)

Exemplos de Configuração DNS64#

BIND 9:

options {
    // ... outras opções ...
    dns64 64:ff9b::/96 {
        clients { any; };
        mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
        exclude { 64:ff9b::/96; ::ffff:0:0/96; };
        suffix ::;
    };
};

Parâmetros:

• clients: Quais clientes obtêm DNS64 (geralmente any)
• mapped: Quais endereços IPv4 traduzir (excluir endereços privados RFC 1918)
• exclude: Quais intervalos IPv6 nunca sintetizar
• suffix: Personaliza onde IPv4 embute no endereço (avançado)

Unbound:

server:
    module-config: "dns64 validator iterator"
 
dns64:
    dns64-prefix: 64:ff9b::/96
    dns64-synthall: no

• dns64-synthall: Se sintetizar mesmo quando AAAA existe (geralmente não)

PowerDNS Recursor:

# Em recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

Descoberta DNS64#

Clientes precisam saber qual servidor DNS fornece DNS64. Tipicamente configurado via:

Router Advertisements (SLAAC):

# radvd.conf
interface eth0 {
    RDNSS 2001:db8::53 {
        AdvRDNSSLifetime 300;
    };
};

DHCPv6:

option dhcp6.name-servers 2001:db8::53;

Sistemas operativos modernos aceitam servidores DNS de RA e DHCPv6.

NAT64 em Profundidade#

NAT64 é tradução stateful — mantém estado de sessão como NAT44 tradicional. Cada conexão de cliente obtém um mapeamento na tabela de estado do gateway NAT64.

Tradução Stateful#

O gateway NAT64 rastreia:

• Endereço e porta IPv6 de origem
• Endereço e porta IPv4 de destino
• Endereço e porta IPv4 de origem traduzidos
• Protocolo (TCP/UDP/ICMP)
• Temporizadores de sessão

Entrada de Tabela de Sessão:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Lado Cliente IPv6         │  Lado Servidor IPv4
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234     │  203.0.113.5:6789
  (IPv6:porta cliente)    │    (IPv4:porta NAT)
                          │        ↕
                          │  198.51.100.10:80
                          │  (IPv4:porta destino)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Protocolo: TCP
Estado: ESTABLISHED
Timeout: 7440 segundos

Quando tráfego de retorno chega a 203.0.113.5:6789, NAT64 procura a sessão e traduz de volta para 2001:db8:100::45:1234.

Tradução de Protocolo#

NAT64 traduz mais que endereços — converte entre formatos de pacote IPv4 e IPv6:

Pacote IPv6:

[ Cabeçalho IPv6 | Cabeçalho TCP/UDP/ICMP | Payload ]

Traduzido para IPv4:

[ Cabeçalho IPv4 | Cabeçalho TCP/UDP/ICMP | Payload ]

Tradução inclui:

• TTL/Hop Limit: Decrementado e copiado
• Fragmentação: Fragmentação IPv6 → fragmentação IPv4 (com considerações MTU)
• ICMP: ICMPv6 → ICMPv4 (mapeamento de tipo de mensagem)
• Checksums: Recalculados para novos cabeçalhos de protocolo

Pool de Endereçamento#

NAT64 precisa de endereços IPv4 para conexões de saída. Implementações pequenas usam um único endereço IPv4 com sobrecarga de portas (como routers domésticos). Implementações maiores usam pools.

# Pequeno: IPv4 único
Pool NAT64: 203.0.113.5/32
Máx clientes: ~65.000 sessões concorrentes
 
# Grande: Pool IPv4
Pool NAT64: 203.0.113.0/24
Máx clientes: ~16 milhões de sessões concorrentes

Preocupações de exaustão de endereços aplicam-se — NAT64 enfrenta as mesmas limitações de porta que NAT44.

Opções de Implementação#

Existem múltiplas implementações de software NAT64, desde leves a carrier-grade.

TAYGA: Userspace Leve#

TAYGA é um daemon NAT64 userspace simples para Linux. Bom para implementações pequenas e testes.

Instalação:

apt-get install tayga
 
# Criar interface TUN
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64

Configuração (/etc/tayga.conf):

tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga

Iniciar e rotear:

systemctl start tayga
 
# Rotear prefixo NAT64 através de TAYGA
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
 
# Ativar encaminhamento
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

Prós: Simples, leve, configuração fácil Contras: Desempenho limitado (userspace), sem clustering, funcionalidades mínimas

Jool: Módulo de Kernel#

Jool implementa NAT64 como módulo de kernel Linux, oferecendo melhor desempenho.

Instalação:

# Adicionar repositório (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
 
# Carregar módulo
modprobe jool

Configuração:

# Criar instância NAT64
jool instance add "default" --netfilter --pool6 64:ff9b::/96
 
# Adicionar pool de endereços IPv4
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535
 
# Ativar
jool -i "default" global update enabled true

Roteamento:

ip route add 64:ff9b::/96 via 2001:db8::1

Prós: Alto desempenho (kernel space), desenvolvimento ativo, boa documentação Contras: Complexidade de módulo de kernel, problemas ocasionais de compatibilidade com atualizações de kernel

NAT64 de Fornecedor Cloud#

Grandes plataformas cloud oferecem NAT64 gerido:

AWS (NAT64 via Egress-Only Internet Gateway):

AWS não fornece NAT64 nativo, mas pode implementar Jool ou TAYGA em instâncias EC2. Algumas AMIs de terceiros existem.

Alternativa: Use dual-stack com redes internas IPv6-only e IPv4 para acesso externo.

Google Cloud Platform:

GCP fornece Cloud NAT com suporte NAT64 (beta):

# Criar sub-rede NAT64
gcloud compute networks subnets create nat64-subnet \
  --network=my-network \
  --region=us-central1 \
  --range=10.0.0.0/24 \
  --enable-nat64
 
# Configurar Cloud NAT
gcloud compute routers nats create my-nat64 \
  --router=my-router \
  --region=us-central1 \
  --enable-nat64 \
  --nat64-prefix=64:ff9b::/96

Azure:

Azure suporta IPv6 mas não oferece NAT64 gerido. Implemente o seu próprio usando VMs Linux com Jool ou TAYGA.

Prós (serviços geridos): Sem manutenção, escalável, monitorização integrada Contras: Específico de cloud, menos flexibilidade de configuração, custo potencial

NAT64 Carrier-Grade#

Implementações de telecomunicações e grandes ISPs usam soluções comerciais:

• Cisco ASR com CGv6
• Juniper MX Series com serviço NAT64
• A10 Thunder CGN
• F5 BIG-IP com módulo CGNAT

Estes lidam com milhões de sessões simultâneas com alta disponibilidade, logging para conformidade legal e políticas sofisticadas de tráfego.

464XLAT: Ativar Aplicações IPv4-Only#

NAT64/DNS64 funciona transparentemente para aplicações dual-stack. Mas algumas apps codificam endereços IPv4 ou usam protocolos que DNS64 não pode intercetar. 464XLAT resolve isto.

Como 464XLAT Funciona#

464XLAT adiciona tradução do lado do cliente (CLAT) antes de NAT64 (PLAT):

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  App IPv4   │      │              │      │              │
│             │      │ Rede         │      │ Servidor     │
│ 192.0.0.10  │      │ IPv6-Only    │      │ IPv4         │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (local)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── Rede IPv6 ────────────────────┘

Passos:

1. App envia pacote IPv4 para 192.0.0.10 (interface virtual CLAT)
2. CLAT traduz IPv4 → IPv6 usando prefixo local (ex: 64:ff9b::c000:0a)
3. Pacote IPv6 atravessa rede para PLAT (gateway NAT64)
4. PLAT traduz IPv6 → IPv4
5. Pacote IPv4 atinge destino

A app vê conectividade IPv4 local. A rede é IPv6-only. Tradução acontece em ambas as extremidades.

464XLAT em Móvel#

Android e iOS implementam CLAT automaticamente quando conectados a redes IPv6-only com NAT64:

CLAT Android:

• Deteta NAT64 consultando ipv4only.arpa (retorna AAAA sintetizado se NAT64 existe)
• Cria interface clat4 com endereços 192.0.0.0/29
• Rota tráfego de app IPv4 através de CLAT
• Traduz para IPv6 usando prefixo NAT64 detetado

CLAT iOS:

• Mecanismo de deteção semelhante
• Transparente para apps e utilizadores

É por isso que apps apenas IPv4 funcionam em T-Mobile, AT&T e outras redes móveis IPv6-only.

Linux 464XLAT com Clatd#

Para sistemas Linux em redes IPv6-only:

# Instalar
apt-get install clatd
 
# Configurar /etc/clatd.conf
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96
 
# Iniciar
systemctl enable --now clatd
 
# Verificar
ip addr show clat
ping -4 8.8.8.8  # Deve funcionar mesmo em rede IPv6-only

Use 464XLAT quando:

• Tem aplicações IPv4-only que não podem ser atualizadas
• Aplicações contornam DNS (IPs codificados)
• Precisa de suporte IPv4 transparente em infraestrutura IPv6-only

Cenários de Implementação#

NAT64/DNS64 serve casos de uso específicos. Compreender quando implementá-lo evita erros arquiteturais.

Cenário 1: Redes Móveis#

Situação: Operadora 5G/LTE com milhões de subscritores, endereços IPv4 limitados

Solução: Rede IPv6-only com NAT64/DNS64 + 464XLAT

Benefícios:

• Elimina IPv4 da rede de rádio e core
• Roteamento simplificado (protocolo único)
• Escala sem restrições de endereço IPv4
• Suporta apps legadas via 464XLAT

Implementação:

• PLAT (NAT64) no core da operadora
• DNS64 em servidores DNS da operadora
• CLAT em dispositivos (automático)

Esta é a arquitetura móvel dominante globalmente.

Cenário 2: Redes Empresariais IPv6-Only#

Situação: Novo data center, quer IPv6-only para evitar complexidade dual-stack

Solução: Rede interna IPv6-only, NAT64 para aceder a serviços IPv4 externos

Benefícios:

• Endereçamento simplificado (sem DHCP IPv4, NAT, etc.)
• Arquitetura moderna
• Força aplicações a suportar IPv6

Desafios:

• Algumas apps empresariais permanecem IPv4-only
• Interfaces de gestão frequentemente IPv4-only
• Compatibilidade de hardware legado

Recomendação: Dual-stack geralmente mais fácil para empresa. IPv6-only faz sentido para ambientes greenfield, cloud-native.

Cenário 3: Microserviços Cloud-Native#

Situação: Cluster Kubernetes, serviços comunicam internamente via IPv6

Solução: Cluster IPv6-only com NAT64 para dependências de API IPv4 externas

Benefícios:

• Service mesh simplificado
• Sem exaustão de endereços IPv4 em clusters grandes
• IPv6 nativo para rede de contêineres

Implementação:

• Modo IPv6-only do Kubernetes
• Gateway NAT64 para egress
• DNS64 via DNS de cluster (CoreDNS suporta-o)

# ConfigMap CoreDNS com DNS64
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        dns64 64:ff9b::/96
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Caso de uso crescente à medida que IPv6 se torna padrão em orquestração de contêineres.

Limitações e Problemas#

NAT64/DNS64 não é perfeito. Compreender limitações previne falhas de implementação.

1. DNSSEC Quebra#

DNS64 sintetiza registos AAAA que não existem na zona autoritativa. Assinaturas DNSSEC não cobrem estes registos sintéticos, então validação falha.

Soluções:

• Desativar validação DNSSEC no resolvedor DNS64 (não ideal)
• Usar DNS64 que suporte tratamento DNSSEC RFC 6147 (implementação limitada)
• Aceitar que domínios apenas IPv4 assinados DNSSEC não validarão

Este é o maior desafio operacional com DNS64.

2. Endereços IPv4 Codificados#

Aplicações com IPs codificados contornam DNS, então DNS64 nunca vê a consulta. NAT64 não pode ajudar porque apenas reconhece o prefixo NAT64.

Soluções:

• Implementar 464XLAT (lida com todo o tráfego IPv4)
• Atualizar aplicações para usar nomes DNS
• Usar gateways de camada de aplicação (raro, complexo)

3. Literais IPv4 em URLs#

Apps web passando http://192.0.2.1/api em URLs ou configuração. Browsers não executam lookups DNS para literais IP, então DNS64 não sintetiza.

Soluções:

• Usar hostnames em vez de literais IP
• Proxies de camada de aplicação que reescrevem literais
• 464XLAT

4. FTP e Outros ALGs#

Protocolos que embutem endereços IP em dados de aplicação (modo ativo FTP, SIP, etc.) frequentemente falham através de NAT64. O endereço no payload não corresponde ao cabeçalho de pacote.

Solução:

• Usar modo passivo FTP (sem endereços embutidos)
• Implementar NAT64 consciente de protocolo com suporte ALG (complexo)
• Mover para protocolos modernos que não embutem IPs

5. Problemas de Fragmentação#

Diferenças de MTU de caminho entre IPv4 e IPv6 podem causar problemas de fragmentação. IPv6 tem MTU mínimo de 1280 bytes; IPv4 permite 576 bytes.

Solução:

• Assegurar que MTU é consistente através da infraestrutura
• Ativar Path MTU Discovery (PMTUD)
• Monitorizar e alertar em mensagens ICMP Packet Too Big

6. DNS Reverso#

Registos PTR para endereços traduzidos NAT64 não existirão. Aplicações que requerem DNS reverso (alguns servidores de mail, controlos de acesso) podem falhar.

Solução:

• Criar registos PTR para pool NAT64
• Configurar serviços para não requerer DNS reverso
• Usar IPv6 nativamente onde DNS reverso importa

Monitorização e Resolução de Problemas#

NAT64/DNS64 adiciona camadas de tradução que podem obscurecer problemas. Monitorização adequada é essencial.

Verificação DNS64#

Teste se DNS64 funciona:

# Consultar para domínio conhecido apenas IPv4
dig AAAA ipv4.google.com @2001:db8::53
 
# Deve retornar AAAA sintetizado com prefixo NAT64
# Exemplo: 64:ff9b::8.8.8.8

Se não obtém registo AAAA, DNS64 não está a funcionar.

Teste de Conectividade NAT64#

Use o domínio de teste especial ipv4only.arpa:

# De cliente IPv6-only
ping6 ipv4only.arpa
 
# Deve receber resposta via NAT64
# O domínio resolve para 192.0.0.170, sintetizado para 64:ff9b::192.0.0.170

Se ping falha, gateway NAT64 não está alcançável ou não está a traduzir.

Inspeção de Tabela de Sessão#

Verifique estado de sessão NAT64:

Jool:

jool -i "default" session display
 
# Mostra sessões ativas
# Procurar: IPv6 cliente, IPv4 traduzido, destino

TAYGA:

cat /var/lib/tayga/dynamic.map
 
# Mostra mapeamentos de endereços

Contagens altas de sessão indicam uso pesado ou problemas potenciais (vazamentos de conexão).

Análise de Tráfego#

Capture tráfego antes e depois da tradução:

# Capturar tráfego IPv6 para prefixo NAT64
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'
 
# Capturar tráfego IPv4 traduzido
tcpdump -i eth1 -n 'ip and src 203.0.113.5'
 
# Comparar para verificar tradução

Procurar:

• Pacotes chegando a NAT64 mas não sendo traduzidos
• Tradução a acontecer mas pacotes não encaminhados
• Roteamento assimétrico (tráfego de retorno não atinge NAT64)

Problemas Comuns#

Sintoma: DNS64 retorna AAAA sintetizado, mas conexão falha

Causas:

• Gateway NAT64 inalcançável
• Firewall bloqueando prefixo NAT64
• Problema de roteamento (pacotes para prefixo NAT64 vão direção errada)

Debug:

traceroute6 64:ff9b::198.51.100.1
# Deve rotear para gateway NAT64

Sintoma: Alguns sites funcionam, outros não

Causas:

• Sites com IPv6 nativo funcionam (sem NAT64 envolvido)
• Sites apenas IPv4 com requisitos especiais falham
• Problemas de fragmentação ou MTU

Debug:

# Testar com diferentes MTUs
ping6 -M do -s 1400 64:ff9b::198.51.100.1

Sintoma: Conexões lentas ou timeout

Causas:

• Gateway NAT64 sobrecarregado
• Tabela de sessão cheia
• Roteamento assimétrico

Debug:

# Verificar CPU NAT64 e contagem de sessão
# Monitorizar tempo de estabelecimento de conexão
time curl -6 http://ipv4-only-site.example.com

Considerações de Segurança#

NAT64 introduz implicações de segurança além de NAT típico.

Varrimento de Espaço de Endereços#

O prefixo NAT64 torna endereços IPv4 previsíveis em IPv6. Atacantes podem varrer 64:ff9b::/96 para descobrir que serviços IPv4 está a aceder.

Mitigação: Use prefixos NAT64 específicos de rede em vez de prefixo bem conhecido, limitando exposição.

Contornar Controlos de Acesso#

Controlos de acesso IPv4 (regras de firewall, ACLs) podem não ter em conta tráfego traduzido NAT64 chegando de origens IPv6 inesperadas.

Mitigação: Aplicar políticas de segurança ao gateway NAT64, não apenas endpoints.

NAT64 como Amplificador de Ataque#

Atacantes em redes IPv6-only podem usar NAT64 para lançar ataques contra alvos IPv4, potencialmente contornando limitação de taxa baseada em IPv4 ou blacklists.

Mitigação:

• Limitar taxa de sessões NAT64 por origem
• Registar todas as traduções NAT64 para investigação de abuso
• Aplicar mesmas políticas de segurança que NAT IPv4

Envenenamento de Cache DNS64#

Se servidor DNS64 é comprometido, atacantes podem sintetizar registos AAAA maliciosos apontando para endereços IPv4 controlados por atacante via NAT64.

Mitigação:

• Proteger servidores DNS64 (igual a qualquer infraestrutura DNS)
• Usar DNSSEC onde possível (apesar de problemas de compatibilidade)
• Monitorizar DNS64 para padrões de síntese invulgares

Quando Usar NAT64/DNS64 vs. Dual-Stack#

Framework de decisão:

┌─────────────────────────────────────────────────┐
│ Pode executar dual-stack?                       │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         SIM                    NÃO
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Use         │     │ Por que não?        │
   │ Dual-Stack  │     │                     │
   │             │     │ • Exaustão IPv4     │
   │ (mais       │     │ • Simplificação     │
   │  simples,   │     │   arquitetural      │
   │  menos      │     │ • Rede móvel        │
   │  problemas) │     │ • Cloud native      │
   └─────────────┘     └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Use NAT64/DNS64    │
                         │                    │
                         │ Adicione 464XLAT   │
                         │ se:                │
                         │ • Apps IPv4-only   │
                         │ • IPs codificados  │
                         └────────────────────┘

NAT64/DNS64 faz sentido quando:

• Exaustão de endereços IPv4 é uma restrição real
• Está a construir nova infraestrutura (greenfield)
• Rede móvel ou arquitetura cloud-native
• Benefícios operacionais de single-stack superam complexidade de tradução

Dual-stack faz sentido quando:

• Endereços IPv4 estão disponíveis
• Infraestrutura legada e moderna mista
• Compatibilidade é prioridade máxima
• Familiaridade da equipa com dual-stack

O Futuro do NAT64#

A adoção de NAT64 cresce à medida que redes IPv6-only se tornam mais comuns:

Tendências:

• Operadoras móveis quase universalmente implementado
• Fornecedores cloud adicionando opções NAT64 geridas
• IoT e edge computing usando IPv6-only + NAT64
• Data centers experimentando IPv6-only para custo/simplicidade

Desafios remanescentes:

• Compatibilidade DNSSEC ainda não resolvida elegantemente
• Problemas de protocolo de camada de aplicação persistem
• Expertise operacional ainda em desenvolvimento

Longo prazo: À medida que Internet IPv4 encolhe e IPv6 se torna ubíquo, o uso de NAT64 pode diminuir — a maioria dos destinos terá IPv6 nativo, não requerendo tradução. Mas isso está a anos de distância. Por agora, NAT64/DNS64 é a tecnologia chave permitindo redes IPv6-only.

Comece Pequeno e Teste#

Não implemente NAT64/DNS64 em produção sem testes completos:

1. Ambiente de laboratório: Configure TAYGA ou Jool em rede de teste
2. Configure DNS64: Use BIND ou Unbound
3. Teste aplicações: Verifique que as suas apps específicas funcionam através de tradução
4. Monitorize desempenho: Meça latência e overhead de throughput
5. Documente problemas: Note quais apps ou serviços têm problemas
6. Planeie workarounds: Dual-stack para serviços problemáticos, 464XLAT para outros

Apenas após testes bem-sucedidos deve considerar implementação em produção, e mesmo assim, comece com redes não críticas ou segmentos de utilizadores.

NAT64/DNS64 é poderoso mas adiciona complexidade. Use-o onde resolve problemas reais, não porque é tecnologia novel.

Artigos Relacionados#

• Estratégias de Migração IPv6 - Escolher a abordagem de migração certa
• Implementação Dual-Stack IPv6 - Executar IPv4 e IPv6 juntos
• Configuração DNS IPv6 - Configurar DNS para IPv6

Perguntas Frequentes#