O terceiro de uma série de blogs ao longo de 2025 destacando o estado do IPv6 em todo o setor, as melhores práticas a serem consideradas e como a Cisco está ajudando os clientes em suas jornadas com seus produtos e serviços.
A transição para o IPv6 está em curso há quase 30 anos, com o tráfego IPv6 na Web ultrapassando agora os 50% em todas as medidas (1). A maioria dos aplicativos e pilhas de rede agora prefere IPv6 por padrão e, graças a tecnologias como Pleased Eyeballs (2), os usuários finais em um ambiente de pilha dupla raramente percebem se o IPv6 faz failover para IPv4. Felizmente, esse cenário de falha está se tornando menos comum à medida que a robustez da Web IPv6 melhora e as redes dos usuários finais são implantadas com grande confiança.
Dois amplos estágios
A jornada para o IPv6 normalmente ocorre em dois estágios amplos: primeiro, passando de um mundo somente IPv4 para um mundo de pilha dupla, onde ativamos o IPv6 e executamos os dois protocolos simultaneamente; e então aposentar gradualmente o IPv4. As implantações tradicionais de pilha dupla geralmente são concluídas no que é comumente chamado de método “Inside Out”, em que o núcleo da rede será empilhado primeiro. Depois que o roteamento e a experiência operacional estiverem estabelecidos na infraestrutura de rede e todo o resto estiver em vigor (veja abaixo), os switches e APs de acesso de borda finalmente habilitarão o IPv6 em seus segmentos voltados para o usuário, fornecendo aos usuários finais conectividade IPv6. Posteriormente, a transição de pilha dupla para somente IPv6 ocorre aproximadamente na ordem inversa. 
Web Edge e information facilities
Antes de podermos empilhar duplamente nossos usuários, devemos empilhar duplamente nosso Web Edge com o suporte de nossa equipe de segurança (que deve estar envolvida desde o início!). Assim que o Web Edge suportar IPv6, o foco mudará para os information facilities; o empilhamento duplo dos servidores nos permite começar a verificar o acesso dos aplicativos através do IPv6, enquanto a maioria dos usuários continua a utilizar o IPv4 (com usuários de teste específicos sendo empilhados duplamente). A equipe de rede e o suporte técnico devem estar divididos em duas camadas para que possam começar a vivenciar a transição em primeira mão. (Em uma observação relacionada, eventualmente todas as funções do plano de gerenciamento das operações de rede podem migrar para IPv6 somente enquanto o plano de dados permanece empilhado duplamente). Em seguida, a DMZ pode ser transferida e as entradas DNS fornecidas para construir uma presença na Web com IPv6. E, finalmente, o IPv6 pode ser implantado em VLANs voltadas para o usuário.
NetFlow e monitoramento de tráfego
Idealmente, 100% de nossos aplicativos internos serão habilitados e preferidos para IPv6. A coleta de tráfego interno do NetFlow ajuda a monitorar isso, identificando rapidamente aplicativos legados para correção (por meio de atualizações, substituições ou front-end com dispositivos de pilha dupla). O objetivo é que o único tráfego IPv4 restante na rede seja vinculado à Web. O NetFlow deve mostrar que o tráfego IPv6 vinculado à Web está aumentando constantemente à medida que outras organizações concluem deles própria transição IPv6.
DNS64 e NAT64
Assim que a transição de pilha dupla for concluída e qualquer falha ocultada pelo Pleased Eyeballs tiver sido identificada e corrigida proativamente, é hora de remover gradativamente o IPv4 da rede. Felizmente, os órgãos de padronização definiram NAT64 (3) e DNS64 (4) apenas para este caso de uso. Estas tecnologias complementares permitem que um cliente somente IPv6 alcance conteúdo somente IPv4, permitindo o uso do IPv6 como protocolo único dentro da rede (5). Embora DNS64 e NAT64 possam ser implantados antes da remoção completa do IPv4 para ganhar familiaridade e experiência, a verdadeira mágica acontece quando o IPv4 desaparece.
Principalmente IPv6 e CLAT
Com o dual-stack e o NAT64 implementados, o próximo passo é avançar para uma implementação predominantemente IPv6, um novo paradigma construído sobre um conjunto de tecnologias (6)(7) que proporciona um caminho mais fácil para um futuro apenas IPv6. Principalmente no IPv6, o sistema operacional cliente fornece seu próprio tradutor de IPv4 para IPv6, conhecido como CLAT (tradutor do lado do cliente) para aplicativos que ainda possuem dependências de IPv4. Quer o destino seja somente IPv4 ou o código do aplicativo use literais IPv4 incorporados, esse tráfego é traduzido em pacotes IPv6 através da rede corporativa somente IPv6 e, em seguida, de volta para IPv4 na borda through NAT64. Os clientes são sinalizados para utilizar IPv6 principalmente em segmentos de acesso de pilha dupla por meio da Opção DHCP 108, uma opção DHCPv4 que informa ao cliente que é seguro renunciar a um endereço IPv4 e executar apenas IPv6. Como o IPv4 ainda está sendo oferecido, uma rede predominantemente IPv6 continua atendendo clientes que não suportam tradução native through CLAT. Agora clientes podem escolher o protocolo a ser usado com base em suas capacidades, em vez de serem forçados pelo rede.
Futuro somente IPv6
À medida que continuamos monitorando o tráfego de rede com o NetFlow, devemos esperar ver o tráfego IPv6 continuar aumentando constantemente e, eventualmente, validarmos que não há mais utilização de IPv4 em determinadas VLANs de usuários. Essa é a hora de remover o IPv4 desses segmentos de rede. À medida que mais IPv4 é desligado, ele também pode ser removido dos equipamentos de infraestrutura de rede. Um dia, num futuro não muito distante, 100% de utilização do IPv6 será visto no Web Edge e na DMZ. Até então, NAT64, DNS64 e CLAT continuarão a nos servir bem.
Referências
(1) https://blogs.cisco.com/industries/ipv6-in-2025-where-are-we
(2) https://datatracker.ietf.org/doc/html/rfc8305
(3) https://datatracker.ietf.org/doc/html/rfc6146
(4) https://datatracker.ietf.org/doc/html/rfc6147
(5) https://www.youtube.com/watch?v=_GkynY809eg