IPv6 para ISPs na América Latina: por que não há mais desculpa para esperar
O esgotamento do espaço IPv4 não é uma previsão: é um fato consumado. A IANA alocou seu último bloco /8 em 2011. A LACNIC —o registro de endereços de internet para a América Latina— esgotou suas reservas para novas alocações diretas há anos. Hoje, um ISP que precisa de espaço IPv4 adicional tem de comprá-lo no mercado secundário a custos que crescem a cada ano.
Enquanto isso, o IPv6 está pronto para produção há mais de uma década. A maioria dos sistemas operacionais modernos o suporta por padrão. Grandes CDNs, nuvens públicas e plataformas de conteúdo têm IPv6 nativo há tempo. E ainda assim, muitos ISPs na América Latina continuam operando exclusivamente sobre IPv4 com CGNAT como solução de curto prazo que se estendeu indefinidamente.
Este artigo não é um evangelho tecnológico. É uma análise prática de por que o momento de implementar IPv6 já passou, e como fazê-lo sem interromper o serviço aos seus clientes atuais.
O problema real com CGNAT
CGNAT (Carrier-Grade NAT) foi concebido como solução transitória para esticar o espaço IPv4 enquanto se completava a migração para IPv6. Na prática, tornou-se solução permanente em muitas redes, com custos que costumam ser subestimados:
Custo operacional: Um equipamento CGNAT com capacidade adequada para um ISP médio (50.000–200.000 assinantes) tem custo significativo em hardware e licenças. Esse custo escala com o crescimento da base de clientes.
Problemas de aplicações: CGNAT quebra aplicações que assumem um endereço IP público único por sessão. VPNs IPsec, alguns jogos online, aplicações de videoconferência e serviços P2P têm problemas frequentes em ambientes CGNAT. Esses problemas geram chamados de suporte difíceis de diagnosticar e resolver.
Rastreabilidade e conformidade legal: Em vários países da América Latina, as regulamentações exigem que os ISPs possam identificar o assinante associado a um IP em um dado momento. Com CGNAT, essa rastreabilidade exige guardar logs de tradução (source IP + port + timestamp) em volumes que podem superar 100GB diários para ISPs grandes. O custo de armazenamento e a complexidade do sistema de logs são um overhead permanente.
Latência agregada: Cada pacote passa por uma camada adicional de tradução. Na prática o impacto na latência média é baixo, mas em conexões sensíveis (gaming, VoIP, trading) pode ser mensurável.
CGNAT não é o problema em si: é um sintoma de não ter investido em IPv6 a tempo. A cada ano que passa, o custo de eliminar CGNAT cresce porque a infraestrutura construída em torno dele fica mais complexa.
Por que IPv6 é melhor para sua rede (não só para seus clientes)
A narrativa habitual do IPv6 centra-se em “mais endereços”. Mas para um operador de rede, os benefícios mais relevantes são outros:
Fim do NAT na rede de clientes: Cada assinante recebe um prefixo IPv6 próprio (tipicamente um /56 ou /48). As aplicações funcionam ponto a ponto sem tradução, o que elimina toda uma classe de problemas de conectividade.
Roteamento mais limpo: O IPv6 foi desenhado com roteamento hierárquico eficiente desde o início. A ausência de NAT e endereços mais estruturados simplificam as tabelas de roteamento e o debug de tráfego.
Melhor suporte a multicast: O IPv6 usa multicast extensivamente (substitui broadcast de ARP por Neighbor Discovery). Para ISPs com serviços IPTV ou multicast, isso é relevante.
Preparação para IoT e 5G: Dispositivos IoT —medidores inteligentes, câmeras, sensores— são implantados em quantidades que tornam CGNAT insustentável. O modelo correto para IoT em escala é IPv6 com prefixo próprio por dispositivo ou por residência.
Eliminação do mercado secundário de IPv4: Quando a maior parte do tráfego dos seus clientes roda sobre IPv6, a dependência de IPv4 cai drasticamente. O espaço IPv4 que você já tem alcança para o tráfego residual por muito tempo.
Modelos de transição: qual se aplica à sua rede
Não existe uma única forma de implantar IPv6. Os três modelos mais usados em ISPs são:
Dual Stack
O modelo mais simples conceitualmente: cada dispositivo tem endereço IPv4 e IPv6. O tráfego flui por IPv6 quando o destino tem IPv6, e por IPv4 quando não.
Vantagens: Compatível com toda a infraestrutura existente, sem necessidade de tunelização. Desvantagem: Requer IPv4 simultaneamente, portanto não elimina CGNAT imediatamente.
Recomendado para: Início da implantação, redes que não podem fazer mudanças bruscas.
464XLAT (CLAT + PLAT)
O modelo recomendado por operadores móveis e cada vez mais por ISPs de banda larga fixa. A rede do operador é apenas IPv6. Os clientes rodam um tradutor local (CLAT) que converte o tráfego IPv4 das aplicações para IPv6, e na borda da rede um PLAT (geralmente PNAT64) converte de volta para IPv4 para alcançar destinos apenas IPv4.
Vantagens: Elimina CGNAT centralizado, reduz o parque de equipamentos no core, IPv6-only na rede de distribuição. Desvantagem: Requer CPEs compatíveis com CLAT (todos os Android modernos e iOS 12+ suportam nativamente; CPEs domésticos requerem firmware atualizado).
Recomendado para: ISPs com base de clientes modernos (smartphones, roteadores atualizados) e disposição para uma mudança de arquitetura mais profunda.
IPv6-mostly (RFC 8925)
IPv6-mostly é um dos modelos de transição mais práticos para ISPs com base mista de dispositivos modernos e legados, e representa o caminho mais direto para eliminar CGNAT sem forçar mudanças disruptivas.
O problema que resolve: Em Dual Stack, o ISP atribui um endereço IPv4 a todos os clientes embora a maior parte do tráfego já vá por IPv6. Isso significa que CGNAT continua necessário para todos. IPv6-mostly resolve isso separando os clientes segundo a capacidade real: dispositivos modernos que podem operar sem IPv4 não a solicitam, e o pool de IPv4 fica reservado para quem genuinamente precisa.
Como funciona — DHCP Option 108 (RFC 8925):
A chave é a DHCP Option 108, também chamada “IPv6-Only Preferred”. Quando um cliente envia um DHCPREQUEST com essa opção, está dizendo ao servidor: “Prefiro operar sem IPv4 — não me atribua um endereço IPv4 se não for necessário”.
O servidor DHCP pode responder de duas formas:
- Se suporta Option 108: responde com um tempo de espera (em segundos) que indica ao cliente por quanto tempo pode operar sem IPv4. O cliente aceita e opera só em IPv6 nesse período.
- Se não suporta Option 108: ignora a opção e atribui IPv4 normalmente. O dispositivo moderno recebe IPv4 como fallback e opera em Dual Stack.
Isso torna IPv6-mostly totalmente retrocompatível: dispositivos que não entendem Option 108 (equipamentos antigos, Windows 7, IoT legado) simplesmente recebem IPv4 como sempre.
Conectividade IPv4 para dispositivos apenas IPv6:
Clientes que operam sem endereço IPv4 atribuído precisam de um mecanismo para alcançar destinos apenas IPv4 na internet. Isso se resolve com o par NAT64 + DNS64:
- DNS64: O resolvedor do ISP sintetiza registros AAAA (IPv6) para domínios que só têm registros A (IPv4). Converte o endereço IPv4 de destino em um IPv6 com um prefixo reservado (tipicamente
64:ff9b::/96). - NAT64: Um gateway na borda da rede traduz o tráfego IPv6 com esse prefixo para o destino IPv4 real.
O resultado: o dispositivo apenas IPv6 pode alcançar qualquer destino na internet sem ter endereço IPv4 público nem passar por CGNAT.
Dispositivo (IPv6-only)
│
├── Destino IPv6 nativo: tráfego direto IPv6 ──────────────────► internet IPv6
│
└── Destino IPv4-only:
DNS64 gera AAAA sintética
Pacote sai por 64:ff9b::/96
NAT64 traduz → ──────────────────────────────────────────► internet IPv4
Benefícios operacionais para o ISP:
- Redução imediata da carga CGNAT: Em redes com alta penetração de smartphones (Android/iOS) e roteadores modernos, 60–80% dos dispositivos podem qualificar-se para operar apenas IPv6. Isso reduz proporcionalmente o número de conexões IPv4 que o CGNAT precisa tratar.
- Transição gradual sem risco: O ISP habilita IPv6-mostly progressivamente. Dispositivos que não qualificam permanecem em Dual Stack. Não há data de corte forçada.
- Sem mudanças em CPEs do cliente: Option 108 é uma opção DHCP padrão. Sistemas operacionais modernos (Android 10+, iOS 14+, Windows 11, macOS Monterey+) já a suportam de fábrica. Não requer atualização de firmware do CPE do cliente.
- Mede a maturidade da rede: A proporção de dispositivos que “escolhem” IPv6-only é um indicador direto de quão pronta está a base instalada do ISP para uma eventual migração completa.
O que os ISPs devem preparar:
- Suporte à Option 108 no servidor DHCP: Os principais servidores DHCP (ISC DHCP 4.4.3+, Kea 2.0+, e a maioria dos BRAS/BNG modernos) já suportam.
- Infraestrutura NAT64 + DNS64: Pode ser implementada com soluções open source (TAYGA para NAT64, BIND 9.8+ ou Unbound para DNS64) ou em equipamentos de rede existentes que suportem a função.
- Prefixo NAT64 anunciado por RA: O roteador de acesso deve anunciar o prefixo NAT64 via Router Advertisement para que clientes apenas IPv6 saibam como alcançar destinos IPv4.
- Exceção para aplicações que não usam DNS: Algumas aplicações (poucos casos hoje) usam IPs IPv4 fixos no código. Para esses casos, o prefixo NAT64 não ajuda e o dispositivo precisaria de IPv4. São casos excepcionais mas devem ser mapeados antes da implantação.
IPv6-mostly no roteiro:
IPv6-mostly não exclui os outros modelos — de fato, é complementar. Um ISP pode:
- Começar com Dual Stack (Fase 3 do roteiro anterior).
- Habilitar Option 108 e NAT64/DNS64 em paralelo.
- Monitorar a porcentagem de clientes que escolhem IPv6-only (começa baixa, cresce a cada CPE atualizado).
- Eventualmente migrar para IPv6-mostly como modo padrão, com IPv4 só para quem solicitar explicitamente.
Esse caminho permite ao ISP reduzir a exposição ao CGNAT de forma contínua e mensurável, sem uma migração big-bang que possa afetar clientes.
Recomendado para: ISPs com alta penetração de smartphones e roteadores modernos, que querem reduzir CGNAT sem migração disruptiva. É o modelo de transição com melhor relação risco/resultado em médio prazo.
MAP-E / MAP-T
Permite encapsular tráfego IPv4 de clientes dentro de IPv6 usando regras determinísticas (sem estado no operador). É tecnicamente elegante e escala bem, mas a configuração de CPEs é mais complexa.
Recomendado para: Operadores com engenharia avançada e controle total sobre os CPEs do cliente.
Roteiro prático para ISPs
Uma implantação de IPv6 que não interrompa o serviço existente tipicamente segue estas fases:
Fase 1 — Auditoria e alocação (1-2 meses)
- Verificar quais equipamentos do core e distribuição suportam IPv6 na versão de firmware atual.
- Solicitar à LACNIC um bloco IPv6 próprio se não houver. O processo é simples e o espaço é gratuito (sem custo por tamanho do bloco).
- Definir o plano de numeração: prefixos para infraestrutura de rede, prefixos para clientes (política de atribuição de /56 ou /48 por assinante).
Fase 2 — Core e upstream (2-3 meses)
- Habilitar IPv6 nos equipamentos de core e nas sessões BGP com upstreams/trânsito.
- Configurar anúncios BGP IPv6 com os peers de peering (IX locais como NAP.BR, CABASE, LACIX, etc.).
- Validar que o tráfego IPv6 flui corretamente entre o core e o uplink.
Fase 3 — Distribuição e BRAS/BNG (2-4 meses)
- Habilitar DHCPv6-PD (Prefix Delegation) no BRAS/BNG para atribuir prefixos aos clientes.
- Configurar RA (Router Advertisement) ou SLAAC conforme o modelo de CPE.
- Piloto em um segmento de clientes voluntários: validar aplicações, latência, rastreabilidade.
Fase 4 — Implantação em massa e redução de CGNAT (6-12 meses)
- Rollout de Dual Stack ou 464XLAT para a base de clientes progressivamente.
- Monitorar a razão IPv6/IPv4 do tráfego de saída para confirmar a adoção.
- À medida que o tráfego IPv4 cai, avaliar a redução da capacidade CGNAT instalada.
Erros comuns que travam a implantação
Bloquear ICMPv6: O protocolo Neighbor Discovery do IPv6 depende de ICMPv6. Filtrá-lo com as mesmas regras de firewall usadas para ICMP em IPv4 quebra a conectividade IPv6 de formas difíceis de diagnosticar. Tipos ICMPv6 133–137 (ND) devem estar sempre permitidos.
Não atribuir prefixos suficientemente grandes: Atribuir um /64 a cada cliente em vez de /56 ou /48 limita a capacidade de ter múltiplas sub-redes na residência (algo cada vez mais comum com IoT e segmentação de redes domésticas). A prática recomendada atual é /56 por site residencial e /48 por site empresarial.
Esquecer o DNS: Muitas implantações configuram conectividade IPv6 mas esquecem que os resolvedores DNS devem ser acessíveis por IPv6. Se o resolvedor da sua rede só responde em IPv4, clientes em redes apenas IPv6 não conseguem resolver nomes.
Não atualizar o sistema de rastreabilidade: Com IPv6, o endereço do cliente pode ser o prefixo atribuído mais o endereço gerado por SLAAC (privacidade de extensões). Os sistemas de logs de autenticação e RADIUS devem registrar o prefixo atribuído para manter a rastreabilidade.
O momento é agora
“Faremos quando for urgente” é a lógica que levou à situação atual: redes que dependem de CGNAT para funcionar, dívida técnica que cresce, e custo de migração que aumenta a cada ano.
Na Ayuda.LA acompanhamos ISPs no desenho e na implementação de migrações IPv6, desde a auditoria inicial até a implantação em produção. O processo é gradual e não exige interromper o serviço existente.
Conheça mais sobre nossos serviços de networking e consultoria para ISPs.
Quer avaliar o estado IPv6 da sua rede?
Podemos fazer um diagnóstico rápido da sua arquitetura atual e identificar o caminho mais direto para implementar IPv6 sem risco operacional.
Tem dúvidas sobre IPv6 para sua rede? Escreva para [email protected] — respondemos todas as mensagens.