Mecanismos de Transição (Tunneling, NAT64, DNS64)

A coexistência entre IPv4 e IPv6 durante um longo período é uma realidade inevitável. O IETF padronizou diversos mecanismos de transição que podem ser agrupados em três grandes categorias: Dual Stack (pilhas paralelas), Tunneling (encapsulamento de um protocolo sobre o outro) e Tradução (conversão de cabeçalhos). A escolha depende do cenário - provedor de acesso, datacenter, rede móvel ou corporativo - e do sentido da transição (IPv4 sobre IPv6 ou IPv6 sobre IPv4).

1. Dual Stack (RFC 4213 / RFC 8219)

O Dual Stack é a abordagem mais simples e robusta: equipamentos rodam IPv4 e IPv6 simultaneamente, com pilhas paralelas e independentes. Aplicações que suportam ambos (maioria moderna) consultam o DNS, recebem registros A e AAAA, e o stack escolhe qual usar (geralmente IPv6 é preferido - Happy Eyeballs, RFC 8305).

Vantagens: ausência de overhead, performance nativa, simplicidade conceitual. Desvantagens: requer endereços IPv4 públicos (escassos e caros), duplicação de configuração, manutenção de duas tabelas de roteamento e dois planos de segurança.

Em provedores móveis (4G/5G) o Dual Stack é frequentemente chamado de 464XLAT辅助, mas o conceito puro tende a ser abandonado em redes de acesso devido à escassez de IPv4.

2. Tunneling Manual

6in4 (RFC 4213)

Encapsula IPv6 diretamente sobre IPv4 com número de protocolo IP 41. É ponto a ponto, requer configuração estática nos dois extremos. Muito usado para conectar ilhas IPv6 através de backbones IPv4.

Linux:
ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 203.0.113.5 ttl 255
ip -6 addr add 2001:470:xxxx::2/64 dev he-ipv6
ip link set he-ipv6 up
ip -6 route add ::/0 dev he-ipv6

Cisco:
interface Tunnel0
 ipv6 address 2001:470:xxxx::2/64
 tunnel source GigabitEthernet0/0
 tunnel destination 216.66.84.46
 tunnel mode ipv6ip

GRE over IPv4

Quando se precisa transportar também outros protocolos (MPLS, IS-IS, IPv4 + IPv6 simultaneamente), o GRE (RFC 2784) é mais flexível que o 6in4 puro. Adiciona 4 bytes (ou mais) de overhead, mas é amplamente suportado em roteadores.

3. Tunneling Automático

6to4 (RFC 3056)

O 6to4 permite que um host IPv4 qualquer alcance a Internet IPv6 sem túnel manual. Cada endereço IPv4 público mapeia para um bloco IPv6 2002:xx.xx.xx.xx::/48, onde xx.xx.xx.xx é o IPv4 em hexa. O roteador 6to4 encapsula pacotes IPv6 destinados a 2002::/16 em IPv4 protocolo 41 para o destino IPv4 correspondente.

Para alcançar outros prefixos IPv6 (não-6to4), o roteador envia pacotes para um 6to4 relay (qualquer endereço IPv4 do bloco 192.88.99.0/24, RFC 3068). O relay desencapsula e injeta na Internet IPv6 nativa.

O 6to4 caiu em desuso: muitos relays são instáveis, e a descoberta automática de relay é frágil. Não recomendado para produção desde aproximadamente 2015.

6rd (RFC 5969 - IPv6 rapid deployment)

Variante do 6to4 desenvolvida pela Comcast e padronizada para provedores. O ISP provisiona um 6rd prefix (em vez de 2002::/16 fixo) e um ou mais 6rd BRs (Border Relays). O cálculo do endereço IPv6 do cliente segue:

IPv6 = 6rd_prefix || (IPv4 >> 6rd_prefix_len - IPv4_len) || interface_id

Vantagem sobre 6to4: o ISP tem controle, prefixo próprio, relay definido, e o cliente recebe um prefixo /60 ou /56 para sua LAN. Foi amplamente usado por provedores a cabo nos EUA e Europa entre 2010 e 2018.

4. Tunnel Brokers

Um tunnel broker é um serviço que oferece conectividade IPv6 via túnel 6in4 gratuito para qualquer usuário. Os principais historicamente:

• Hurricane Electric (he.net) - Tunnel Broker: ainda ativo, o mais usado mundialmente. Oferece túneis 6in4 gratuitos, /48 de rota e suporte a BGP.
• SixXS: descontinuado em 2017, foi popular na Europa. Usava TIC (Tunnel Information and Control) protocol.
• gogo6 / Freenet6: descontinuado.

Configuração típica via Hurricane Electric envolve registrar um túnel, anotar o IPv4 do servidor (216.66.84.46 etc.), e configurar 6in4 no cliente. Túneis com endpoints dinâmicos usam atualização via API quando o IPv4 muda.

5. Teredo (RFC 4380) - IPv6 sobre UDP através de NAT

O Teredo foi projetado para permitir que hosts atrás de NAT IPv4 (comum em residências) obtenham conectividade IPv6 sem intervenção do roteador. Funciona encapsulando IPv6 em UDP (que atravessa NAT) para um Teredo server que autentica o cliente e ajuda na descoberta de peers.

Componentes:
- Teredo Server: ponto IPv4/IPv6 conhecido, ajuda o cliente a descobrir seu endereço público e o tipo de NAT.
- Teredo Relay: roteador que desencapsula pacotes Teredo e injeta na Internet IPv6.
- Cliente Teredo: host atrás de NAT.

Endereços Teredo têm prefixo 2001:0000::/32 e codificam servidor, flags (tipo de NAT) e porta/MAC mapeado.

Hoje o Teredo é considerado obsoleto: Windows ainda inclui teredo em netsh interface ipv6, mas raramente é necessário pois a maioria dos ISPs já oferece IPv6 nativo. Não é suportado em macOS/Linux por padrão há anos.

6. NAT64 e DNS64 - Tradução

O NAT64 (RFC 6146) permite que um host IPv6-only alcance serviços IPv4-only. O equipamento NAT64 faz tradução stateful de cabeçalhos entre IPv6 e IPv4, mantendo tabela de sessões.

O DNS64 (RFC 6147) é um servidor DNS recursivo que, ao receber uma consulta AAAA de um cliente IPv6-only e perceber que não há registro AAAA real, sintetiza um registro AAAA a partir do registro A: o endereço IPv4 é encapsulado nos últimos 32 bits de um prefixo IPv6 específico (geralmente 64:ff9b::/96, o WKP - Well-Known Prefix).

Fluxo típico:

1. Cliente IPv6-only consulta AAAA example.com ao DNS64.
2. DNS64 consulta o autoritativo: recebe apenas registro A 192.0.2.10.
3. DNS64 sintetiza AAAA 64:ff9b::192.0.2.10 (=64:ff9b::c000:20a).
4. Cliente envia pacote IPv6 para 64:ff9b::c000:20a.
5. NAT64 intercepta, traduz para IPv4 192.0.2.10, com sua fonte sendo o IPv4 público do NAT64.
6. Resposta IPv4 volta, NAT64 traduz para IPv6 e entrega ao cliente.

Limitações: NAT64 não traduz aplicações que embutem IPv4 literalmente (endereços IP em URLs, FTP ativo, SIP, alguns protocolos de gaming). Para esses casos é necessário 464XLAT.

7. DS-Lite (RFC 6333) - IPv4 over IPv6

Cenário dual stack é caro porque exige IPv4 público. O DS-Lite inverte a lógica: o ISP roda apenas IPv6 na rede de acesso, e o tráfego IPv4 dos clientes é encapsulado em túnel DS-Lite (IPv4-in-IPv6) até um AFTR (Address Family Transition Router), que faz CGNAT IPv4.

Vantagens: ISP opera apenas IPv6 no core, economia de IPv4 público, cliente mantém comportamento IPv4 nativo (sem precisar de NAT64). Desvantagem: o cliente ainda precisa de NAT64/DNS64 para alcançar serviços IPv6-only... não, wait, é o oposto: o cliente tem IPv6 nativo via SLAAC/DHCPv6 e usa túnel DS-Lite apenas para o tráfego IPv4 residual.

Amplamente usado por ISPs a cabo na Europa (Comcast EUA, Orange, Swisscom).

8. MAP-E e MAP-T (RFC 7597 / RFC 7599)

MAP (Mapping of Address and Port) foi projetado para permitir que um ISP distribua IPv4 público para milhares de clientes usando apenas IPv6 na rede de acesso, sem estado stateful no CGN. Cada cliente recebe um bloco de portas IPv4 (ex: portas 1024-2047 do endereço IPv4 compartilhado), mapeadas a partir de um algoritmo determinístico.

• MAP-E: encapsula IPv4 em IPv6 (IPv4-in-IPv6, protocolo IP 4) até o gateway MAP. Mais simples, mas acrescenta overhead de cabeçalho.
• MAP-T: traduz cabeçalho IPv4 para IPv6 (stateless NAT46) usando prefixo MAP. Sem overhead de encapsulamento, mas requer suporte a tradução em ambos os lados.

Vantagem sobre DS-Lite: escala melhor (stateless no núcleo) e o cliente recebe portas IPv4 determinísticas, permitindo algumas aplicações de servidor. Usado principalmente por ISPs japoneses (NTT, SoftBank) e na Europa.

9. 464XLAT (RFC 6877) - Cenário Móvel

O 464XLAT é o mecanismo dominante em redes móveis (4G/5G) para permitir que aplicativos IPv4-only funcionem em redes IPv6-only. Combina dois elementos:

• CLAT (Customer-side Translator): roda no dispositivo do cliente (ex: smartphone). Faz NAT44 do tráfego IPv4 privado do app para um endereço IPv4 próprio do CLAT, depois encapsula em IPv6 e envia para o PLAT.
• PLAT (Provider-side Translator): é um NAT64 no core do provedor. Traduz o tráfego IPv6 de volta para IPv4 e faz CGN.

Resultado: o aplicativo pensa que está em rede IPv4; a operadora roda apenas IPv6; e o alcance a serviços IPv4 e IPv6 (via DNS64) é transparente. É o modelo padrão em T-Mobile EUA, Reliance Jio (Índia), e muitos provedores móveis europeus.

10. Estratégias de Migração por Cenário

11. Boas Práticas e Diagnóstico

• Priorize Dual Stack onde houver IPv4 disponível - é o caminho de menor atrito.
• Em ISPs de acesso, desligue o Dual Stack assim que possível e migre para 464XLAT ou DS-Lite para economizar IPv4 público.
• Configure DNS64 com prefixo WKP 64:ff9b::/96 apenas se não houver NAT64 próprio; caso contrário use prefixo específico.
• Habilite Happy Eyeballs (RFC 8305) em aplicações para evitar timeouts em cenários de falha de um dos protocolos.
• Verifique MTU em túneis: 6in4 adiciona 20 bytes, GRE 24 bytes, MAP-T nenhum. Ajuste MTU/MSS para evitar fragmentação.
• Comandos úteis:
• ping6, traceroute6 para validar IPv6 nativo.
• tcpdump -i eth0 ip6 para inspecionar tráfego IPv6.
• show platform hardware qfp active feature nat64 datapath em Cisco ASR para sessões NAT64.
• rdisc6 eth0 para solicitar RA manualmente.
• Teste de IPv6 readiness: curl -6 https://ipv6.google.com, curl -4 https://ipv4.google.com.
• Monitore métricas de tráfego IPv4 vs IPv6 por interface para acompanhar a migração. Em ambientes Google, já passamos de 40% de tráfego IPv6 a nível mundial em 2024.