O Brasil chegar a 60% na métrica IPv6 Capable não significa consumir 60% dos endereços do IPv6. O marco divulgado pelo NIC.br em 28 de outubro descreve capacidade de acesso entre usuários alcançados pela medição da APNIC, com média de 30 dias. Não mede a parcela do espaço de endereços usada, o volume de tráfego nem os contratos de cada ISP.
A APNIC usa testes disparados por anúncios digitais para observar se o navegador alcança um recurso disponível apenas em IPv6. Há outro indicador para a preferência quando o destino oferece os dois protocolos. É uma amostra, não um censo dos assinantes. Essa distinção explica o número, mas deixa uma pergunta operacional: depois de habilitar IPv6, como depender menos do IPv4 sem interromper o que o cliente usa?
O próximo passo não exige um novo número de versão
Uma evolução já documentada é transportar a conexão de acesso em IPv6 e preservar o acesso aos serviços IPv4 por mecanismos de transição. Essa abordagem é chamada IPv4-as-a-Service. Não significa contratar necessariamente um serviço externo: descreve a entrega da compatibilidade IPv4 sobre uma infraestrutura IPv6.
A RFC 9386 distingue esse cenário do estágio final em que toda a rede e seus serviços dispensariam IPv4. Para o provedor brasileiro, a diferença importa: um trecho de acesso IPv6-only pode coexistir com dispositivos e destinos IPv4. O nome não autoriza retirar IPv4 de qualquer lugar.
A escolha também não é universal. A mesma RFC discute custos de CPE, endereços e operação, e diferentes estratégias para redes fixas e móveis. Manter dual stack — IPv4 e IPv6 simultâneos — pode continuar sendo a decisão adequada enquanto uma alternativa não passar pela avaliação local.
Como o 464XLAT mantém uma ponte com o IPv4
Um exemplo é o 464XLAT, descrito na RFC 6877. No lado do cliente, uma função chamada CLAT traduz pacotes IPv4 para IPv6. No provedor, o PLAT, um tradutor NAT64 com estado, permite chegar aos destinos IPv4. O tráfego IPv6 nativo não precisa fazer essa dupla tradução.
No cenário de banda larga descrito na RFC 8683, o CLAT pode estar no roteador do assinante. Assim, aparelhos IPv4 na rede interna continuam tendo um caminho de saída, enquanto o acesso ao provedor usa IPv6. Isso é diferente de exigir que todos os aparelhos da casa se tornem IPv6-only.
Não é uma garantia de equivalência com toda funcionalidade IPv4. Conexões entrantes, aplicações com particularidades e serviços que dependem de endereço público precisam de tratamento próprio. A arquitetura mantém tradução e uso de endereços IPv4 no lado que conversa com destinos IPv4: não elimina automaticamente NAT, dimensionamento ou operação. Também existem alternativas, como DS-Lite e MAP; a escolha exige projeto, não apenas preferência por uma sigla.
A evolução concreta está na compatibilidade
A indicação genérica “suporta IPv6” no equipamento não comprova suporte a IPv4-as-a-Service. A RFC 8585 acrescenta requisitos para essa continuidade, incluindo a função CLAT no cenário 464XLAT. Compras e engenharia precisam conferir modelo, firmware, configuração e evidência de teste antes de contar com o recurso.
Há avanços recentes nessa base. Publicada em setembro de 2025, a RFC 9872 recomenda informar o prefixo de tradução NAT64 por anúncios do roteador, os Router Advertisements, quando aplicável. A orientação reduz a dependência da descoberta por DNS64; a transição deve considerar equipamentos antigos que ainda precisam do método anterior. É melhoria de configuração e compatibilidade dentro do IPv6, não um protocolo sucessor.
Outro trabalho, o draft-ietf-v6ops-claton-16, trata do comportamento do CLAT. Na consulta de 29 de outubro de 2026, estava na fila editorial de RFCs, em First Edit, com status pretendido Proposed Standard. Ainda não era uma RFC publicada. Já as RFCs 6877, 8585, 8683, 9386 e 9872 citadas aqui são documentos informativos da IETF; não devem ser apresentados como uma obrigação regulatória brasileira.
Há experiência de campo, mas não receita pronta para o Brasil
Um relatório publicado pela APNIC Foundation descreve um projeto de 464XLAT em nove provedores rurais da Indonésia, entre novembro de 2024 e outubro de 2025. O executor relata dificuldades com CPEs compatíveis e um caso de roteamento assimétrico que afetou conexões em Salatiga.
É um relato de implantação pelo próprio responsável pelo projeto, não uma auditoria independente nem um teste de desempenho de ISPs brasileiros. Serve para mostrar que a implementação sai do papel e encontra problemas concretos. Não sustenta transplantar custos, economia ou resultados para outra rede.
Um piloto antes da mudança em escala
Como roteiro editorial, o Entre Redes propõe começar com um ambiente controlado, autorizado e reversível. Primeiro, delimite qual trecho deixará de transportar IPv4 nativamente e quais serviços continuarão dependendo dele. Se a própria entrega de IPv6 ainda falha, essa correção vem antes de ampliar a complexidade.
Registre a combinação de CPE, hardware e firmware; o provisionamento; a delegação de prefixos; a descoberta do tradutor; e o acesso de gestão. Teste os serviços realmente usados pela base, incluindo DNS externo e DNSSEC, VPN corporativa, jogos, voz, câmeras e necessidades de conexão entrante. Não presuma que todos falharão nem que todos funcionarão.
Compare o piloto com a configuração atual: falhas por aplicação, tempo de conexão, latência, perda, carga do tradutor, uso de portas e chamados de suporte. Verifique também segurança, registros necessários à operação, recuperação após falha e retorno à configuração anterior. Critérios de aceitação, responsáveis e janela de teste devem existir antes da expansão.
Para o dono do provedor, a decisão é econômica e operacional: custo de equipamentos e licenças, treinamento, capacidade da tradução e suporte precisam entrar na conta. O próximo nível não é anunciar o fim do IPv4. É saber quanto a rede ainda depende dele e demonstrar, com testes próprios, onde essa dependência pode ser reduzida sem piorar a experiência do assinante.
