Dual stack é rodar IPv4 e IPv6 lado a lado na mesma rede, e é o caminho padrão de transição para ISPs. A técnica é madura, e os projetos que dão errado quase sempre erram na ordem das etapas. O projeto que começa "vamos ativar v6 no PPPoE e ver o que acontece" descobre em produção que o DNS interno não resolve AAAA, que a monitoração não enxerga a metade nova da rede e que o suporte não tem procedimento. Aí o IPv6 ganha fama interna de instável e volta para a gaveta por mais dois anos.
A sequência abaixo deixa o assinante para a última etapa.
Etapa 0 · plano de endereçamento no papel
Um ISP recebe tipicamente um /32 da LACNIC. É espaço para estruturar a rede inteira com folga, desde que a divisão seja hierárquica e escrita antes do primeiro comando:
2804:db8::/32 alocação LACNIC (exemplo)
2804:db8:0000::/40 pop-01
2804:db8:0100::/40 pop-02
2804:db8:ff00::/40 infraestrutura (loopbacks, enlaces, serviços)
/56 por assinante → 65 536 assinantes por /40
O /56 delegado por assinante dá a ele 256 redes /64, o que atende qualquer residência ou empresa pequena e segue a recomendação do Registro.br. Delegar um /64 único é o erro que custa caro corrigir depois, porque impede o roteador do cliente de segmentar a rede interna. Prefixo estático por assinante simplifica log, suporte e rastreabilidade; a economia de renumerar dinamicamente não paga o transtorno.
Etapa 1 · borda e core
Sessões BGP IPv6 com os trânsitos e no IX.br, anúncio do /32, e o prefixo visível de fora (teste por looking glass externo, porque o teste de dentro da própria rede engana). Depois, IPv6 nos enlaces internos e nos loopbacks. Nada disso toca o assinante; se algo der errado nesta etapa, nenhum cliente percebe, e essa é a vantagem de começar por dentro.
Assine o ROA do prefixo v6 já nesta etapa, no portal do Registro.br. Trânsitos e route servers que validam RPKI descartam anúncio sem ROA, e é melhor descobrir isso antes do primeiro cliente reclamar.
Etapa 2 · monitoração enxergando v6
Antes de qualquer serviço, a monitoração precisa medir IPv6 como mede IPv4: gráfico de tráfego por família, teste de alcançabilidade externa, alarme de sessão BGP v6. Regra prática: se a queda do IPv6 não dispara alarme, o IPv6 ainda não existe operacionalmente, porque vai quebrar em silêncio e minar a confiança no projeto.
Etapa 3 · serviços internos
DNS recursivo respondendo em transporte v6, site e portal do assinante com AAAA, e-mail, servidores de atualização de CPE. Aqui aparecem os defeitos reais: firewall interno sem regra v6, aplicação que loga só o campo de IPv4. Melhor achá-los com a equipe interna como usuária do que com 40 mil assinantes.
Etapa 4 · piloto controlado
Um POP pequeno ou um grupo de clientes conhecidos, com PPPoE ou DHCPv6 entregando o /56 via delegação de prefixo (IA_PD). Duas a quatro semanas medindo: percentual de tráfego em v6 (a referência é 40–60% do tráfego doméstico migrar quase de imediato, puxado por vídeo e redes sociais), chamados abertos, comportamento dos CPEs. O CPE é a variável menos controlada do projeto, e o piloto existe principalmente para descobrir quais modelos da sua base precisam de firmware novo ou de troca.
Etapa 5 · ativação por POP
Com o piloto medido, a ativação segue POP a POP, cada um com critério de sucesso definido (tráfego v6 dentro da faixa esperada, chamados estáveis) e reversão simples: desativar a delegação devolve o assinante ao estado anterior sem visita técnica.
O efeito colateral mais rentável aparece no CGNAT: cada ponto percentual de tráfego que migra para v6 nativo sai do tradutor. Dual stack bem feito adia a expansão de pool público por anos; a conta de dimensionamento está no artigo sobre CGNAT aqui do blog.
Se o seu IPv6 está "no planejamento" desde antes da pandemia, o custo de destravar é menor do que parece: contato@castelapi.com.br.
