O Google acaba de ultrapassar 50% do tráfego servido sobre IPv6. Se você ainda está somente em IPv4, está escolhendo maior latência de cauda, fragilidade de CGNAT e allowlists frágeis para metade dos seus usuários — especialmente no mobile. IPv6 não é mais um upgrade de vaidade; é uma decisão de confiabilidade e custo. A boa notícia: dá para implementar com segurança em semanas, não em trimestres, se você escopar corretamente.
O que 50% de IPv6 realmente significa para o seu roadmap
Nas redes de consumo (e em Brazil em particular), IPv6 agora é o caminho padrão. As operadoras preferem porque reduz a contenção de NAT e a dor operacional. Para você, isso se traduz em três efeitos tangíveis:
- Menor latência de cauda no mobile: Happy Eyeballs (RFC 8305) vai competir A vs AAAA. Onde as operadoras otimizam v6, você verá melhorias de 5–25 ms nos tempos de conexão e menos timeouts de NAT sob carga.
- Menos quedas misteriosas: modos de falha de CGNAT (exaustão de estado, roteamento assimétrico) afetam desproporcionalmente o IPv4. Dual‑stack dá ao cliente um segundo caminho, frequentemente mais limpo.
- Pressão por consistência de segurança e operações: se seu WAF, rate‑limits, logs e allowlists não suportam IPv6 plenamente, você criou um caminho de bypass ou um ponto cego. Os atacantes percebem primeiro.
Coloque a economia na conta: endereços IPv4 públicos têm sido negociados a cerca de US$ 45–60 cada nos últimos anos, e alugueis mensais costumam ficar em US$ 1–2 por endereço. Enquanto isso, todo grande CDN e cloud oferece IPv6 sem ágio. Ficar só em IPv4 é um imposto que você não precisa mais pagar.
Você precisa de IPv6 neste trimestre? Um framework simples de decisão
Priorize dual‑stack nos próximos 90 dias se dois ou mais itens forem verdade:
- Mobile >50% do tráfego ou presença significativa em LATAM/Ásia. Os ISPs de consumo do Brazil são v6‑forward há anos.
- Seu app é sensível a latência: dados ao vivo, streaming, colaboração em tempo real, respostas de IA com streaming de tokens.
- Você faz controles baseados em IP: regras de WAF, rate‑limits, heurísticas de abuso ou allowlists de parceiros indexadas por IP.
- Você já sentiu dor com CGNAT: reclamações de usuários que somem no Wi‑Fi, picos de 522/524 (CDN) ou 502/504 (origem) durante picos de tráfego.
Se você é puro B2B atrás de VPNs corporativas, v6 pode ter menor urgência — mas você ainda vai querer paridade antes de 2027, à medida que mais redes corporativas adotam dual‑stack por padrão.
Onde IPv6 morde: impacto na arquitetura e no modelo de dados
1) DNS e edge
- Suporte de CDN: CloudFront, Fastly e Cloudflare suportam AAAA no edge há anos. Habilite v6 por distribuição/zona.
- Evite bypass da origem: se seu CDN/WAF é seu escudo, garanta que não exista AAAA direto para a origem que o contorne. Trave security groups, regras de firewall e DNS para que somente o CDN alcance a origem tanto por v4 quanto por v6.
2) Balanceadores de Carga e Origens
- AWS: ALB e NLB suportam IPv6 para LBs voltados à internet; o Route 53 suporta alias AAAA. Coloque sites em S3 atrás do CloudFront para obter IPv6.
- GCP/Azure: os LBs Global HTTP(S) e o Front Door suportam IPv6. Valide a paridade de health checks para ambas as famílias.
3) Kubernetes e serviços
- K8s dual‑stack tem sido estável há várias releases. EKS/GKE/AKS oferecem suporte com CNI dual‑stack.
- Service meshes: confirme se Envoy/NGINX Ingress e seu mesh (Istio/Linkerd) anunciam e roteiam v6 corretamente. Teste mTLS em ambas as famílias.
4) Modelo de dados e logging
- Pare de armazenar IPs em VARCHAR(15). Use inet/cidr do Postgres, VARBINARY(16) ou ao menos VARCHAR(39) com formatação canônica (RFC 5952).
- Parsing: X‑Forwarded‑For e cabeçalhos similares incluirão IPv6 e potencialmente múltiplos endereços. Seu pipeline de logs e o SIEM devem fazer parsing de ambas as famílias sem truncar.
5) Rate‑limiting e controles de abuso
- Per‑IP é mais fraco em v6. Extensões de privacidade e alocações das operadoras fazem com que um único usuário possa rotacionar /128s. Use agregação por /64 ou combine IP com conta, cookie, dispositivo e sinais de comportamento.
- Matemática de quotas: revise limites puramente por IP para evitar folga a abusadores e falsos positivos em rotações legítimas.
6) Chamadas de saída e allowlists
- Egress: se parceiros colocam seus IPs em allowlist, mantenha o egresso v4 estável. Adicione egresso v6 somente após confirmar que o parceiro suporta — e que não rejeitará seu tráfego devido à ausência de AAAA do lado deles.
- Bibliotecas cliente: elimine literais IPv4. Use getaddrinfo e resolução com hostname‑first em todos os lugares. URLs com literais IPv6 devem estar entre colchetes (exemplo: http://[2001:db8::1]/path).
Seu rollout dual‑stack em 4 etapas (com kill switches)
Este plano mantém o risco no edge até que seus internos estejam prontos. Cada etapa tem um kill switch e critérios de saída claros.
Etapa 1: IPv6 apenas no edge (1–2 semanas)
- Habilite IPv6 no CDN, mantenha a origem apenas IPv4. O CDN termina v6 e encaminha para sua origem via v4.
- Exponha registros AAAA no DNS para hostnames públicos atrás do CDN.
- Kill switch: desabilite AAAA no CDN e remova AAAA no DNS. Tempo de rollback: minutos.
- Métrica de sucesso: ≥30% dos requests no edge sobre v6 sem novos deltas de 4xx/5xx e melhoria de ≥5 ms no tempo de conexão P95 em redes móveis.
Etapa 2: Colocar os balanceadores em dual‑stack (1–3 semanas)
- Habilite IPv6 em ALB/NLB e nos security groups. Mantenha instâncias e pods acessíveis por v4 enquanto você valida.
- Health checks e WAF: garanta que health checks L7 funcionem para ambas as famílias; confirme que o WAF enxerga o IP real do cliente via cabeçalhos do CDN.
- Kill switch: remova AAAA no Route 53/Cloud DNS; mantenha o CDN em pass‑through v4.
- Métrica de sucesso: sem aumento de 502/504 nos LBs; logs de origem mostram IPs reais de cliente (não só o PoP do CDN) quando desejado.
Etapa 3: Serviço‑a‑serviço (2–4 semanas)
- Ative dual‑stack no K8s e suporte de mesh em um namespace não crítico. Valide o comportamento de DNS64/Happy Eyeballs dentro do cluster.
- Passada nas bibliotecas: substitua código de rede apenas IPv4, atualize resolvers DNS e corrija quaisquer problemas de construção de URL com literais IPv6.
- Kill switch: feature flag no nível de namespace ou serviço para forçar upstreams IPv4.
- Métrica de sucesso: serviços conseguem discar ambas as famílias; sem regressão em churn de conexões ou nos error budgets.
Etapa 4: Egresso e parceiros (2–6 semanas, em paralelo)
- Estabilize NAT/egresso de saída com endereços v6 conhecidos. Documente para os parceiros; não remova v4 até que todas as allowlists de parceiros aceitem v6.
- E‑mail, pagamentos, analytics: valide a política de v6 de cada fornecedor. Alguns ainda preferem v4 para aceitação SMTP; escolha suas batalhas.
- Kill switch: roteie a saída pelo NAT gateway v4; mantenha caminhos duplos pré‑configurados.
Paridade de segurança ou não embarque
A maioria dos riscos de IPv6 são, na verdade, riscos de “configuration drift”. Corrija isso antes de adicionar AAAA.
- Cobertura de WAF e DDoS: confirme que seu provedor mitiga ataques volumétricos e L7 em v6 nos mesmos níveis de v4. Leia as letras miúdas.
- Regras de firewall: atualize security groups e ACLs de rede para incluir IPv6. Não deixe um ::/0 totalmente aberto enquanto suas regras de v4 estão apertadas.
- Rate‑limits e fraude: abandone limites puros em /128. Agregue em /64 quando apropriado e misture sinais de usuário/conta/dispositivo.
- Logging e forense: garanta que SIEM, feeds de threat intel e dashboards customizados lidem com IPv6 sem truncamento ou parsing incorreto. Treine para novos indicadores: colchetes em URLs, nuances de notação comprimida.
Observabilidade: meça por família de endereços
Trate IPv6 como uma dimensão de primeira classe nos seus SLOs e dashboards por pelo menos um trimestre.
- Separe métricas por v4 vs v6 para tempo de conexão, handshake TLS, latência P50/P95/P99, taxas de erro e contagem de retries.
- Acompanhe a adoção por país e rede: use os logs do seu CDN para ver onde v6 é dominante (Brazil, US mobile) e onde fica atrás. Isso guia rollouts regionais.
- Alertas: alertas dedicados para regressão em v6 evitam degradações silenciosas mascaradas por tráfego v4 saudável.
Limpeza do modelo de dados que você não pode pular
- Schema: migre colunas de IP para inet/cidr do Postgres ou VARBINARY(16). Faça backfill e dual‑write por um release antes do cutover.
- Indexação: crie índices que suportem consultas por intervalo (por exemplo, inet_ops) para que a agregação por /64 e heurísticas de abuso sejam rápidas.
- Serialização: padronize a forma textual canônica para logs (RFC 5952). Consistência importa para deduplicação e joins.
Modos comuns de falha (para você não aprender do jeito difícil)
- Bypass da origem: publicar AAAA em um hostname de origem que não está preso ao caminho do CDN/WAF. Corrija com origens privadas e security groups rígidos.
- IPv4 hard‑coded em config ou código. Faça grep por dotted quads; adicione linting para bloquear merges que os introduzam.
- Bugs de parsing de URL: clientes esquecem os colchetes em torno de literais IPv6 em URLs, quebrando cabeçalhos HTTP Host e TLS SNI.
- Logs truncados: endereços IPv6 de 39 caracteres (ou cadeias XFF separadas por vírgula) são cortados em colunas de 32 caracteres e quebram analytics.
- Limites desbalanceados: rate limits por IP permitem tentativas ilimitadas para abusadores com /128s rotativos, enquanto usuários legítimos são estrangulados atrás de /64s corporativos.
Quanto tempo isso leva? Quanto vai custar?
Para um SaaS típico com CDN e LBs gerenciados:
- Etapa 1 (apenas edge): 1–2 semanas, 1 engenheiro, custo de infra desprezível.
- Etapa 2 (LBs): 1–3 semanas, 1–2 engenheiros, mudanças em security groups e health checks.
- Etapa 3 (serviço‑a‑serviço): 2–4 semanas, 2 engenheiros, algumas atualizações de bibliotecas e validação de mesh.
- Etapa 4 (egresso): 2–6 semanas, majoritariamente coordenação com parceiros e atualização de políticas.
Conte de 4–10 semanas‑engenheiro para um caminho dual‑stack limpo até o edge e a origem, mais um trimestre para absorver nos serviços internos. Dual‑stack adiciona uma sobrecarga operacional modesta (pense em 5–10% mais métricas, regras e testes) que diminui à medida que seu tooling acompanha.
Testes: não embarque sem estas verificações
- Rede apenas IPv6: configure NAT64/DNS64 em uma VPC de teste e em um SSID de Wi‑Fi local. A Apple exige testes de apps apenas IPv6 há anos; use o mesmo padrão para seus backends.
- Comportamento de Happy Eyeballs: force ambas as famílias de endereços para validar que o fallback funciona e quantificar o delta de latência que você realmente está obtendo.
- Harness de abuso: simule /128s rotativos e grandes alocações /64 para testar seus rate‑limits e regras de WAF.
- Traços fim a fim: confirme que atribuição de IP de cliente e geolocalização funcionam com IPv6 nos seus analytics e modelos de fraude.
Checklist de prontidão de fornecedores
- CDN/WAF: IPv6 habilitado, paridade de DDoS, logs incluem v6, sem bypass de origem.
- DNS: AAAA com failover validado por health check. Weighted routing permite fazer canary de v6 por região (por exemplo, 10% de AAAA em um POP).
- Load balancers: listeners dual‑stack, security groups v6, health checks correspondentes.
- Kubernetes: cluster e CNI dual‑stack, suporte a service/ingress, paridade de políticas no mesh.
- Observability: log shipper e SIEM fazem parsing de IPv6; dashboards segmentam por família.
- Terceiros: pagamentos, auth, analytics, e‑mail — documente quem suporta v6 e quem precisa ficar apenas v4 por enquanto.
Por que isso importa para times nearshore
As operadoras de Brazil estão à frente de muitos mercados na implantação de IPv6. Um time nearshore em Brazil pode exercitar caminhos IPv6 do mundo real diariamente, não setups sintéticos de laboratório. Isso significa feedback mais rápido sobre mudanças de latência, padrões de erro e comportamento do WAF nas redes de onde vem o seu crescimento. Espere 6–8 horas de sobreposição de fuso com times dos US e custo 20–30% menor do que equipes equivalentes nos US para conduzir essa migração sem desacelerar a velocidade de produto.
Resumo
Metade dos seus usuários já escolhe IPv6 quando você oferece. Dual‑stack não vai te render um press release, mas vai fazer seu app parecer mais rápido e mais confiável onde importa — nas redes que seus clientes de fato usam. Lance primeiro no edge, proteja como v4, arrume seu modelo de dados e meça como um cidadão de primeira classe.
Principais aprendizados
- O Google reporta ~50% do tráfego sobre IPv6; usuários mobile e Brazil puxam ainda mais para cima. IPv6 agora é o básico.
- Comece no CDN: habilite IPv6 e AAAA com um kill switch rápido; mantenha origens IPv4 até endurecer a segurança.
- Paridade de segurança é inegociável: WAF, regras de firewall e DDoS devem igualar as capacidades de v4.
- Corrija seu modelo de dados: use inet/cidr ou armazenamento de 16 bytes; pare de guardar IPs em VARCHAR(15).
- Faça rate‑limit de forma mais inteligente: combine sinais de conta/dispositivo; agregue IPv6 por /64 quando apropriado.
- Meça por família: crie SLOs e alertas dedicados para v4 vs v6 por pelo menos um trimestre.
- Planeje 4–10 semanas‑engenheiro para dual‑stack no edge e na origem; um trimestre para completar a adoção interna.
- Times nearshore em Brazil podem validar rapidamente e com bom custo caminhos IPv6 do mundo real.