IPv6 foi criado para permitir que a internet continue atribuindo endereços a redes e dispositivos em uma escala muito maior. A implantação, porém, não acontece com uma atualização simultânea de todos os roteadores, servidores, sistemas operacionais e provedores. A internet opera durante uma coexistência prolongada de IPv4 e IPv6, e cada organização precisa escolher como fazer seus equipamentos conversarem com os dois mundos.
Dual stack mantém os dois protocolos disponíveis
O RFC 8200 especifica IPv6, incluindo seu cabeçalho e regras de processamento. Um servidor ou roteador pode implementar IPv4 e IPv6 ao mesmo tempo: essa estratégia é chamada dual stack. O dispositivo recebe endereços de cada versão e pode conversar com destinos compatíveis. O DNS também publica registros distintos: A para endereços IPv4 e AAAA para IPv6.
O RFC 4213 descreve mecanismos básicos de transição para hosts e roteadores, incluindo dual stack e túneis configurados. Um túnel encapsula pacotes IPv6 dentro de IPv4 para atravessar uma infraestrutura que ainda não encaminha IPv6 nativamente. Essa solução pode resolver conectividade entre segmentos, mas adiciona configuração e riscos operacionais. Um túnel esquecido ou mal monitorado pode virar dependência invisível e complicar a investigação de falhas.
Aplicações precisam escolher sem travar
Um cliente que recebe endereços IPv4 e IPv6 pode tentar uma conexão e lidar com o resultado. A RFC 8305, conhecida como Happy Eyeballs Version 2, descreve estratégias para reduzir atrasos quando uma das famílias de endereços não funciona bem. A ideia é testar caminhos de forma coordenada e iniciar a conexão que responde, sem deixar a aplicação esperando por um timeout longo em uma rota defeituosa.
Isso não conserta uma rede quebrada. Se o anúncio IPv6 parece funcional, mas o roteador descarta pacotes ou o firewall não permite respostas, algumas tentativas podem atrasar. As equipes precisam testar DNS, roteamento, MTU, regras de segurança e serviços de entrada e saída por cada família. Um site pode abrir porque o navegador recorreu ao IPv4 enquanto uma API ou e-mail falha por causa de configuração parcial de IPv6.
NAT não é plano de transição completo
A tradução de endereços e os compartilhamentos de IPv4 ajudam provedores a usar blocos escassos, mas não tornam todo serviço acessível de qualquer lado. Carrier-grade NAT, firewalls e mapeamentos de porta afetam conexões iniciadas de fora. IPv6 oferece endereçamento próprio em redes compatíveis, mas endereços globais continuam protegidos por políticas de firewall. Ter endereço público não significa deixar um dispositivo exposto sem controle.
Um plano de implantação começa com inventário: equipamentos, hospedagem, DNS, monitoramento, sistemas legados, fornecedores e requisitos de segurança. Depois, a equipe ativa IPv6 em ambientes de teste, mede falhas por família de protocolo e atualiza procedimentos de resposta. Logs e painéis precisam registrar qual endereço e caminho foram usados, senão um incidente pode parecer aleatório quando ocorre apenas por IPv6.
Compatibilidade deve fazer parte do produto
Aplicações que gravam endereços IP em bancos de dados precisam suportar o formato maior de IPv6 sem truncar campos ou presumir que todo endereço tem quatro octetos. Listas de permissão, trilhas de auditoria, regras de rate limit e ferramentas de administração também podem conter pressupostos IPv4. Testes precisam cobrir parsing, normalização e comparação de endereços, incluindo IPv4 mapeado em IPv6 quando a biblioteca usada oferece essa representação.
Na borda, confirme que os nomes DNS publicados correspondem a serviços que realmente aceitam conexões IPv6. Um registro AAAA incorreto pode desviar clientes para um caminho sem servidor funcional. Documente como voltar atrás em cada etapa e monitore taxas de erro, latência e timeouts separados por família. Uma migração com rollout progressivo é mais fácil de diagnosticar do que uma alteração ampla sem métricas.
O IPv6 não exige desligar a infraestrutura IPv4 de uma vez. A coexistência funciona melhor quando as organizações planejam a transição por serviço, verificam a rede ponta a ponta e removem mecanismos temporários quando já não são necessários. O objetivo técnico é que um usuário alcance o destino sem precisar saber qual versão transportou cada pacote.
Fontes: RFC 8200 — especificação IPv6 · RFC 4213 — mecanismos básicos de transição · RFC 8305 — Happy Eyeballs v2