IPv6 em redes móveis: 464XLAT, NAT64 e DNS64 em palavras simples

Imagine uma cena estranha. Você abre no celular um serviço de verificação de IP e ele mostra um endereço IPv4. Mas, se olhar nas configurações da interface de rede do mesmo dispositivo, vai encontrar um longo endereço IPv6. Como assim? O dispositivo vive no mundo IPv6, mas o site registra com segurança quatro números decimais separados por pontos. Onde ocorreu a troca?

Isso não é um bug nem mágica. É um sistema de tradução cuidadosamente projetado, que as operadoras de telecom implantam ao redor do mundo há mais de uma década. E se você trabalha com proxies móveis, scraping, múltiplas contas ou simplesmente quer entender o que acontece com seu tráfego, é fundamental compreender essa mecânica.

Neste guia, vamos percorrer todo o caminho do pacote, desde o aplicativo no celular até o site de destino. Vamos detalhar o 464XLAT por componentes, entender o papel do NAT64 e DNS64, ver exatamente onde nasce o endereço IPv4 de saída e aprender a diagnosticar a pilha de conexão com as próprias mãos. Não é uma visão superficial. É um mergulho profundo para quem quer saber não só o que acontece, mas como e por quê.

Introdução: por que o telefone recebe IPv6 e o site vê IPv4

Vamos começar pela essência do paradoxo. Um smartphone moderno em uma rede móvel de uma grande operadora quase certamente está conectado via IPv6. Mais do que isso, muitas vezes ele nem tem um endereço IPv4 real na interface de rádio. A operadora simplesmente não o fornece. E essa é uma decisão consciente, motivada pela escassez severa de espaço de endereçamento.

Mas a internet não é homogênea. Uma quantidade enorme de sites, APIs e serviços ainda só são acessíveis via IPv4. Eles não têm registro AAAA no DNS, seus servidores não escutam IPv6. Se o telefone só falasse IPv6, ele não conseguiria abrir metade da internet. Surge então uma contradição: o dispositivo fala um novo idioma, mas o interlocutor só entende o antigo.

A solução dessa contradição é o tema principal da nossa conversa. A tecnologia chamada 464XLAT, junto com os mecanismos NAT64 e DNS64, cria uma ponte invisível. O dispositivo envia pacotes em IPv6 e, em algum lugar na profundez da rede da operadora, esses pacotes se transformam em IPv4 e seguem para o servidor de destino com um endereço IPv4 real. O servidor responde, e o caminho de volta passa pela mesma transformação em ordem inversa.

É por isso que o site de destino vê IPv4. É por isso que um proxy móvel, construído a partir de um telefone real ou modem da operadora, exibe um endereço IPv4 para fora, embora internamente o dispositivo seja IPv6. A troca não ocorre no telefone nem no site. Ela ocorre em um nó intermediário da rede da operadora, chamado PLAT.

O que você vai aprender ao ler até o final:

• Como é a escassez de endereços IPv4 e por que ela forçou as operadoras a migrar para IPv6
• O que são os tipos de APN e como IPv4v6 difere de IPv6 puro
• Como o 464XLAT funciona passo a passo, onde vive o CLAT e onde vive o PLAT
• Como NAT64 e DNS64 tornam acessível um site sem registro AAAA
• De onde vem o endereço IPv4 de saída de um proxy móvel
• Como o happy eyeballs faz o serviço de verificação mostrar às vezes IPv4, às vezes IPv6
• Comandos práticos para diagnosticar a pilha de conexão
• Por que a sub-rede /64 é percebida como um único cliente e o que isso significa para contas

Combinamos desde já os limites. Estamos falando exclusivamente de mecânica de rede. Não discutimos o que é mais vantajoso comprar nem qual protocolo é melhor do ponto de vista comercial. Este é um guia de engenharia, não uma análise de mercado.

Fundamentos: escassez de IPv4, migração para IPv6 e tipos de APN

Para entender toda a estrutura, começamos pela base. E a base aqui é uma só: a catastrófica falta de endereços IPv4.

Por que o IPv4 acabou

O protocolo IPv4 usa endereços de 32 bits. Isso dá cerca de 4,3 bilhões de combinações únicas. Em 1981, quando o protocolo foi padronizado, isso parecia um número astronômico. Quem poderia imaginar que haveria mais dispositivos do que pessoas no planeta?

A realidade se mostrou cruel. Smartphones, tablets, relógios inteligentes, geladeiras, câmeras, carros – tudo precisa de endereço. No início dos anos 2010, os registros regionais de internet começaram a esgotar os blocos disponíveis. Hoje, obter um grande bloco de endereços IPv4 públicos é praticamente impossível, e no mercado secundário eles são negociados a dezenas de dólares cada.

Para uma operadora móvel com dezenas de milhões de assinantes, isso é um problema fundamental. Dar a cada smartphone um IPv4 público individual é fisicamente irreal. Simplesmente não há endereços suficientes.

Como o IPv6 resolve o problema

O protocolo IPv6 usa endereços de 128 bits. O número de combinações possíveis é tão grande que a mente humana se recusa a compreendê-lo – são aproximadamente 340 undecilhões de endereços. Em termos simples, dá para atribuir vários endereços para cada átomo na superfície da Terra e ainda sobrar.

A operadora recebe do registro um enorme bloco IPv6 e distribui para os assinantes com uma folga colossal. A prática típica é atribuir a cada dispositivo de assinante uma sub-rede inteira /64. Isso são, imagine só, 18 quintilhões de endereços para um único telefone. Guarde esse fato; ele terá um papel importante na seção sobre múltiplas contas.

O que é APN e por que seus tipos são importantes

APN significa Access Point Name, ou nome do ponto de acesso. É um perfil de configuração que informa ao telefone como se conectar à rede de pacotes da operadora. Quando o smartphone estabelece a transmissão de dados, ele solicita à rede a criação de uma sessão com um determinado tipo de protocolo.

Existem três tipos principais de contexto PDN ou PDP:

• IPv4 – o dispositivo recebe apenas um endereço IPv4. Esquema clássico e ultrapassado. Funciona, mas exige endereços que não existem.
• IPv6 – o dispositivo recebe apenas um prefixo IPv6. Nenhum IPv4 na interface. Máximo de economia para a operadora.
• IPv4v6 – pilha dupla. O dispositivo solicita ambos os tipos de endereço em uma mesma sessão.

Aqui surge uma sutileza. Mesmo que o telefone solicite IPv4v6, a operadora pode entregar apenas a parte IPv6 e, na parte IPv4, negar ou fornecer um endereço privado por meio de um mecanismo de tradução. Muitas grandes operadoras estão configuradas de forma que o assinante recebe por padrão IPv6 puro, e a compatibilidade com a internet IPv4 é garantida pela tecnologia 464XLAT já descrita.

Uma analogia que ajuda. Imagine que o mundo inteiro mudou para um novo idioma de comunicação, mas muitas instituições antigas só aceitam documentos no idioma antigo. O governo não pode dar a cada cidadão um passaporte antigo individual – eles não são suficientes. Então, ele entrega a todos documentos novos e coloca um tradutor na entrada das instituições antigas. Esse tradutor é o 464XLAT.

Aprofundamento: 464XLAT por componentes

Agora estamos prontos para dissecar a tecnologia em si. O nome 464XLAT se lê como four-six-four translation. Os números refletem a essência: o pacote começa a vida como IPv4 dentro do aplicativo, viaja pela rede como IPv6 e depois se torna IPv4 novamente na saída. XLAT é abreviação de translation, tradução.

A base é o padrão de tradução de endereços entre protocolos descrito nas especificações da IETF. Mas o 464XLAT adiciona uma arquitetura de dois componentes que trabalham em par.

CLAT – tradutor no dispositivo

CLAT significa Customer-side translator, ou tradutor do lado do cliente. Ele mora diretamente no seu smartphone, embutido no sistema operacional. No Android, essa função é executada por um daemon especial; em outros sistemas, por módulos análogos.

A tarefa do CLAT é única, mas importante. Quando um aplicativo no telefone quer enviar um pacote via IPv4 – por exemplo, se ele usa rigidamente um socket IPv4 ou se conecta diretamente a um endereço IP – o CLAT intercepta esse pacote IPv4 e o encapsula em IPv6. Tecnicamente, ele realiza a tradução de cabeçalhos conforme o algoritmo de tradução stateless, convertendo os endereços IPv4 de origem e destino em endereços IPv6 correspondentes usando um prefixo conhecido previamente.

O CLAT cria no dispositivo uma interface de rede virtual, à qual é atribuído um endereço IPv4 privado. Os aplicativos enxergam esse endereço e pensam que estão em um ambiente IPv4 normal. Eles nem desconfiam que, nos bastidores, tudo já migrou para IPv6.

PLAT – tradutor na rede da operadora

PLAT significa Provider-side translator, tradutor do lado do provedor. É um nó poderoso em algum lugar no núcleo da rede da operadora, que implementa a função NAT64. É aqui que ocorre a transformação final.

O PLAT recebe os pacotes IPv6 que vieram do dispositivo e extrai deles a informação sobre o destino IPv4 original. Em seguida, realiza uma tradução stateful: transforma o pacote IPv6 de volta em IPv4, substitui o endereço de origem por um dos endereços IPv4 públicos da operadora de seu pool e envia o pacote para a internet IPv4 comum.

A palavra-chave é stateful, ou seja, com manutenção de estado. O PLAT mantém uma tabela de correspondências para que os pacotes de resposta do servidor retornem corretamente ao dispositivo que iniciou a conexão. É basicamente o mesmo princípio do NAT clássico, só que entre protocolos diferentes.

Por que exatamente dois tradutores

Surge uma pergunta legítima: para que serve o CLAT no dispositivo se o PLAT vai traduzir tudo de qualquer forma? A resposta está nos aplicativos que não sabem lidar com IPv6.

Muitos aplicativos foram escritos com uso rígido de IPv4. Eles solicitam sockets IPv4, trabalham com literais de endereço IPv4, alguns protocolos antigos transmitem endereços IP dentro da carga útil. Se no dispositivo houvesse apenas IPv6 puro, esses aplicativos simplesmente quebrariam. O CLAT dá a eles a ilusão de um ambiente IPv4 completo, permanecendo invisível.

Assim, a dupla funciona da seguinte forma: o CLAT resolve o problema de compatibilidade no dispositivo; o PLAT resolve o problema de compatibilidade na internet. Juntos, formam uma ponte perfeita.

NAT64 e DNS64: como um site sem registro AAAA ganha vida

Já entendemos a tradução de pacotes. Mas há ainda um problema fundamental – como o dispositivo descobre para onde enviar o pacote IPv6 se o site de destino existe apenas no mundo IPv4 e não tem nenhum registro IPv6?

Aqui entra em cena a dupla NAT64 e DNS64. Eles trabalham em estreita colaboração, e é impossível entender um sem o outro.

O problema da ausência do registro AAAA

No sistema de nomes de domínio, os endereços de diferentes protocolos são armazenados em diferentes tipos de registro. O endereço IPv4 fica no registro do tipo A. O endereço IPv6 fica no registro do tipo AAAA, que se pronuncia quad-A.

Quando um dispositivo puramente IPv6 quer abrir um site, ele consulta o DNS pelo registro AAAA. Mas, se o site não tem infraestrutura IPv6, também não tem registro AAAA. Existe apenas o registro A com o endereço IPv4. O dispositivo recebe uma resposta vazia e, em teoria, deveria dizer: site inacessível. Mas isso não acontece graças ao DNS64.

Como funciona o DNS64

DNS64 é um resolvedor DNS especial da operadora com um superpoder. Quando o dispositivo consulta um registro AAAA para um domínio e não existe um registro AAAA real, o DNS64 não desiste. Ele faz o seguinte:

1. Consulta o servidor autoritativo pelo registro A comum e obtém o endereço IPv4 do site
2. Pega esse endereço IPv4 e sintetiza um registro AAAA artificial
3. Para a síntese, ele insere os 32 bits do endereço IPv4 em um prefixo IPv6 especial
4. Retorna esse registro AAAA sintetizado para o dispositivo como se nada tivesse acontecido

O dispositivo recebe um endereço IPv6 válido e envia alegremente pacotes para ele. Ele não sabe e não precisa saber que esse endereço é artificial.

Prefixo sintetizado 64:ff9b::/96

Aqui chegamos a um dos artefatos mais reconhecíveis de todo o sistema. Para a síntese de endereços, é usado um prefixo especialmente reservado: 64:ff9b::/96. Ele é chamado de Well-Known Prefix, ou prefixo bem conhecido, e foi padronizado justamente para a tradução NAT64.

A mecânica é simples e elegante. O prefixo ocupa os primeiros 96 bits do endereço. Os 32 bits restantes são exatamente o tamanho de um endereço IPv4. O DNS64 simplesmente adiciona o endereço IPv4 do site ao final do prefixo.

Por exemplo, se o site tem um endereço IPv4 expresso em quatro números, o endereço IPv6 sintetizado será o prefixo 64:ff9b seguido, nos últimos 32 bits, da codificação desses quatro números. Quando esse pacote chega ao PLAT, o nó reconhece o prefixo familiar, entende que é uma tradução NAT64, extrai os últimos 32 bits e obtém o verdadeiro endereço IPv4 de destino. Em seguida, envia um pacote IPv4 normal.

Algumas operadoras, em vez do prefixo bem conhecido, usam um prefixo de rede próprio do seu espaço de endereçamento. A lógica é a mesma; muda apenas o valor específico dos primeiros bits.

Como a dupla funciona em conjunto

Vamos montar o quebra-cabeça. O DNS64 é responsável por fazer o dispositivo obter um endereço IPv6 para acessar a internet IPv4. O NAT64, na forma do PLAT, é responsável por fazer o pacote com esse endereço realmente chegar ao servidor IPv4. Um é inútil sem o outro: o DNS64 cria um endereço que só o NAT64 sabe processar, e o NAT64 só processa endereços que foram sintetizados pelo DNS64.

E o que acontece com sites que têm um registro AAAA real? Aqui é mais simples. O DNS64 vê um registro AAAA real e simplesmente o repassa, sem nenhuma síntese. O dispositivo se conecta ao site diretamente por IPv6, ignorando toda a maquinaria de tradução. Esse é o caminho direto ideal.

Percurso do pacote do aplicativo ao site com 464XLAT: esquema em palavras

Chegou a hora de reunir toda a mecânica em um esquema passo a passo. Vamos acompanhar um único pacote, desde o nascimento no aplicativo até a chegada ao servidor IPv4 de destino e de volta. Essa é a rota que o tráfego de um proxy móvel percorre.

Caminho direto: do telefone ao site

1. Passo 1. O aplicativo quer se conectar. O aplicativo no telefone decide abrir um site que só tem IPv4. Ele consulta o DNS pelo endereço.
2. Passo 2. O DNS64 sintetiza o endereço. O resolvedor da operadora não encontra um registro AAAA real, pega o registro A, insere o endereço IPv4 no prefixo 64:ff9b::/96 e retorna um registro AAAA sintetizado.
3. Passo 3. O aplicativo envia o pacote. Existem duas possibilidades. Se o aplicativo opera com IPv6, ele envia diretamente um pacote IPv6 para o endereço sintetizado. Se o aplicativo está rigidamente vinculado ao IPv4, ele envia um pacote IPv4 para a interface virtual do CLAT.
4. Passo 4. O CLAT traduz IPv4 para IPv6. No caso do aplicativo IPv4, o daemon CLAT intercepta o pacote e, conforme as regras de tradução stateless, o transforma em um pacote IPv6 usando o mesmo prefixo NAT64.
5. Passo 5. O pacote viaja pela rede rádio. Agora é um pacote IPv6 puro. Ele passa pela estação rádio base e pelo núcleo da rede móvel da operadora. Dentro de toda a parte de rádio, só existe IPv6.
6. Passo 6. O pacote atinge o PLAT. No núcleo da rede, há um nó PLAT com a função NAT64. Ele vê o pacote com destino começando pelo prefixo NAT64.
7. Passo 7. O PLAT traduz IPv6 para IPv4. O nó extrai os últimos 32 bits do endereço de destino – esse é o verdadeiro IPv4 do site. Em seguida, coloca como origem um IPv4 público do seu pool, registra a correspondência na tabela de estados.
8. Passo 8. O pacote vai para a internet. Agora é um pacote IPv4 comum. Ele viaja pela rede global até o servidor de destino.
9. Passo 9. O site vê IPv4. O servidor recebe a conexão do endereço IPv4 público da operadora. Nos logs, ele registra exatamente esse IPv4. Eis o momento da verdade: o site nunca saberá que o pacote nasceu originalmente em um ambiente IPv6.

Caminho de volta: do site ao telefone

1. Passo 10. O servidor responde. O site envia um pacote IPv4 de resposta para o endereço público que viu.
2. Passo 11. O PLAT encontra a correspondência. O nó NAT64 consulta sua tabela de estados, determina a qual dispositivo pertence a conexão e restaura o endereço IPv6.
3. Passo 12. Tradução reversa para IPv6. O PLAT transforma a resposta IPv4 em um pacote IPv6 e o envia pelo núcleo da rede de volta ao telefone.
4. Passo 13. O CLAT devolve IPv4 para o aplicativo. Se originalmente o aplicativo estava usando IPv4, o CLAT no dispositivo traduz a resposta IPv6 de volta para IPv4 e a entrega ao aplicativo pela interface virtual.
5. Passo 14. O aplicativo recebe a resposta. Para o aplicativo, tudo parece uma troca IPv4 normal. O ciclo se fecha.

Pare um segundo e aprecie a elegância dessa construção. O pacote mudou de identidade de protocolo quatro vezes, passou por dois tradutores, e os pontos finais – o aplicativo e o site – nem desconfiam disso. Cada um vê apenas seu mundo IPv4 familiar.

O que isso significa para proxies: onde nasce o endereço de saída

Agora vamos aplicar toda a teoria à prática dos proxies móveis. Esta é a seção mais importante para quem trabalha com tráfego.

Onde nasce o endereço de saída

Um proxy móvel é, basicamente, um ponto de entrada na rede por meio de um dispositivo móvel real ou modem conectado à operadora. Quando você direciona o tráfego por esse proxy, ele sai para a internet da mesma forma que o tráfego sairia do telefone.

E já sabemos o que acontece com esse tráfego. Ele passa pelo 464XLAT, atinge o PLAT, e lá recebe um endereço IPv4 público do pool da operadora. Exatamente esse endereço do PLAT se torna o endereço de saída do seu proxy. Ele não nasce no dispositivo, nem no modem, mas no nó NAT64 no núcleo da rede da operadora.

É por isso que a saída móvel geralmente é IPv4. O próprio dispositivo vive em IPv6, mas o ponto de onde o tráfego sai para a internet global em direção a sites IPv4 é o PLAT, que fornece IPv4.

O que o site de destino vê no final

O site de destino vê o endereço IPv4 público da operadora. É o endereço de um nó CGN ou NAT64, atrás do qual podem estar muitos assinantes. O site não vê nem o endereço IPv6 interno do dispositivo, nem o IPv4 virtual da interface CLAT. Apenas o IPv4 externo do PLAT.

Esse é um ponto fundamental. Os proxies móveis são valorizados porque seus endereços IPv4 parecem endereços de assinantes reais – porque tecnicamente são. Muitos usuários reais compartilham o mesmo IPv4 público por meio de um único PLAT. Do ponto de vista do site de destino, esse endereço é indistinguível de um cliente móvel comum.

Quando o site pode ver IPv6

Mas nem sempre o endereço de saída será IPv4. Se o site de destino tiver um registro AAAA real e infraestrutura IPv6 completa, o dispositivo se conectará diretamente a ele por IPv6, sem passar pelo PLAT. Nesse caso, o site verá um endereço IPv6 da sub-rede atribuída ao assinante pela operadora.

É por isso que um mesmo proxy móvel pode apresentar diferentes tipos de endereço para sites diferentes. Para um site sem IPv6 – IPv4 público via NAT64. Para um site com IPv6 – IPv6 real diretamente. Isso não é uma falha, mas o comportamento normal de um sistema de pilha dupla.

Checklist para entender o endereço de saída

• Dispositivo em rede IPv6 – sim, quase sempre nas grandes operadoras
• Endereço de saída para site IPv4 – IPv4 público do nó PLAT da operadora
• Endereço de saída para site IPv6 – IPv6 real da sub-rede do assinante
• Onde ocorre a tradução – no PLAT no núcleo da rede, não no dispositivo
• O que o site IPv4 vê – endereço IPv4 compartilhado da operadora, dividido entre assinantes

Pilha dupla e happy eyeballs: por que a verificação mostra às vezes IPv4, às vezes IPv6

Você certamente já passou por isso: um serviço de verificação de IP, em consultas repetidas, mostra endereços diferentes – ora IPv4, ora IPv6. Isso causa confusão. Vamos entender por que acontece.

O que é pilha dupla

Pilha dupla significa que o dispositivo possui simultaneamente um endereço IPv4 e um endereço IPv6 e pode usar ambos os protocolos. No ambiente móvel, isso geralmente é implementado via APN IPv4v6 ou pela combinação de IPv6 nativo mais o CLAT, que fornece um IPv4 local.

Quando o cliente tem a opção entre dois protocolos, surge a pergunta: qual usar para uma conexão específica? Antigamente, a decisão era tosca e causava atrasos. Se o caminho IPv6 estivesse quebrado, o navegador esperava muito tempo pelo timeout antes de cair para IPv4. Os usuários sofriam com carregamento lento.

O algoritmo happy eyeballs

Para resolver esse problema, foi criado o algoritmo happy eyeballs, que pode ser traduzido como olhos felizes. Sua essência é não adivinhar previamente qual protocolo é melhor, mas sim promover uma competição.

Veja como funciona em linhas gerais:

1. O cliente consulta o DNS pelo registro A e pelo registro AAAA do domínio simultaneamente
2. De posse dos endereços de ambos os protocolos, ele começa a estabelecer conexões quase em paralelo
3. A tentativa IPv6 geralmente começa primeiro com uma pequena vantagem de algumas dezenas ou centenas de milissegundos
4. Se a conexão IPv6 for estabelecida rapidamente, ela é usada
5. Se o IPv6 estiver lento ou não responder, o cliente muda quase instantaneamente para IPv4
6. O vencedor da corrida é usado para a transmissão de dados; a conexão perdedora é fechada

O algoritmo dá preferência ao IPv6 quando ele funciona bem, mas não permite que ele atrase o funcionamento se algo der errado. Daí o nome – os olhos permanecem felizes porque não há lentidão.

Por que a verificação mostra endereços diferentes

Agora fica claro de onde vem a inconstância. Quando você abre um serviço de verificação de IP, acontece o seguinte:

• Se o serviço tem registros A e AAAA, o happy eyeballs entra em ação
• Dependendo de qual conexão venceu a corrida naquele momento específico, você verá IPv4 ou IPv6
• O estado da rede, a carga, o cache de conexões – tudo influencia o resultado da corrida
• Na próxima consulta, a corrida pode terminar de forma diferente, e o endereço muda

Isso não é erro do proxy nem instabilidade de conexão. É o comportamento esperado de uma pilha dupla sob o comando do happy eyeballs. Se você precisa de um resultado previsível, deve forçar a versão do protocolo – falaremos disso na próxima seção.

Insight prático

Muitos erroneamente acham que o proxy móvel é instável ao ver endereços pulando no serviço de verificação. Na verdade, é um comportamento saudável de uma rede moderna. Se você quer ver apenas a saída IPv4, acesse serviços sem registro AAAA ou force IPv4 no nível do cliente. Assim o quadro se estabiliza.

Prática: como ver qual pilha de conexão está em uso

Teoria sem prática é morta. Vamos nos munir de comandos específicos para ver com os próprios olhos o que está acontecendo com sua conexão. Todas as ferramentas são padrão e disponíveis na maioria dos sistemas.

Verificando os endereços da interface

O primeiro passo é ver quais endereços estão atribuídos às interfaces de rede. Para IPv6, use o comando:

• ip -6 addr – mostra todos os endereços IPv6 em todas as interfaces
• ip -4 addr – análogo para IPv4
• ip addr – mostra tudo de uma vez

Preste atenção aos tipos de endereço. Endereços IPv6 globais geralmente começam com 2000::/3. Endereços locais de link começam com fe80 e não são roteados para fora. Se você vir um IPv6 global, o dispositivo tem conectividade IPv6 plena. Se também vir um IPv4 privado em uma interface separada, provavelmente é a interface do CLAT.

Testando acessibilidade com ping

Para verificar se um protocolo específico está funcionando, o ping ajuda:

• ping6 endereço ou ping -6 endereço – testa conectividade via IPv6
• ping -4 endereço – testa conectividade via IPv4

Se o ping via IPv6 para um nó global funcionar, você tem conectividade IPv6 operacional. Se funcionar apenas via IPv4, então o IPv6 não está configurado ou não está funcionando.

Forçando o protocolo no curl

A ferramenta mais poderosa para diagnosticar tráfego web é o curl com as opções de forçar o protocolo:

• curl -4 endereço – força uso apenas de IPv4
• curl -6 endereço – força uso apenas de IPv6
• curl -v endereço – modo detalhado, mostra a qual endereço realmente se conectou

Combinando as opções, você pode descobrir exatamente qual endereço o site remoto vê. Envie uma requisição com a opção -4 para um serviço que retorna seu IP, e você verá a saída IPv4 pura. Envie com -6 – verá IPv6, se disponível. Assim você separa a influência do happy eyeballs e enxerga o quadro real de cada protocolo.

Teste em um endpoint somente IPv6

Uma técnica especialmente valiosa é acessar um serviço que só existe em IPv6, sem nenhum registro A. Se essa conexão for estabelecida, você tem garantia de conectividade IPv6 nativa, e não apenas tradução. Se a conexão não funcionar mesmo forçando -6, então não há saída IPv6 real para fora; toda a atividade IPv6 gira em torno do prefixo NAT64.

Cenário prático de verificação:

1. Execute curl -6 em um endpoint somente IPv6 – testa conectividade IPv6 nativa
2. Execute curl -4 em um serviço de determinação de IP – vê a saída IPv4 via PLAT
3. Compare os endereços – se a saída IPv6 for da sub-rede do assinante e a IPv4 do pool da operadora, então está funcionando uma pilha dupla completa com 464XLAT

Como detectar a presença do prefixo NAT64

Para saber se sua rede usa NAT64, você pode observar os endereços sintetizados. Consulte um registro AAAA para um domínio que com certeza não tem IPv6 e veja a resposta. Se retornar um endereço começando com 64:ff9b, é um sinal claro de que DNS64 e NAT64 estão em operação. Alguns sistemas possuem mecanismos embutidos para detectar o prefixo NAT64, que funcionam exatamente assim: consultam um nome conhecido e analisam a estrutura da resposta.

Checklist de diagnóstico da pilha

• ip -6 addr – existe IPv6 global?
• ip -4 addr – existe IPv4 e ele não é um endereço privado do CLAT?
• ping -6 para um nó global – a conectividade IPv6 funciona?
• curl -4 em um serviço de IP – qual IPv4 o site vê?
• curl -6 em um endpoint somente IPv6 – existe IPv6 nativo?
• Consulta AAAA para um domínio somente IPv4 – o prefixo 64:ff9b é visível?

Compatibilidade: por que a sub-rede /64 é percebida como um único cliente

Agora vamos para uma questão de enorme importância prática para todos que trabalham com múltiplas contas. Trata-se de como as plataformas encaram as conexões IPv6.

Por que algumas plataformas tratam IPv6 pior

Historicamente, muitas grandes plataformas construíram seus sistemas de antifraude e reputação de endereços em torno do IPv4. Bancos de dados acumulados, pontuações de reputação, regras de limitação de frequência – tudo foi ajustado para endereços de 32 bits. O IPv6 veio depois, e nem todos os sistemas se adaptaram igualmente bem.

Há também uma razão estrutural. No IPv4, cada endereço é um recurso escasso, atrás do qual geralmente há um único nó ou um nó atrás de NAT. No IPv6, os endereços são tão abundantes que um único cliente pode mudar seu endereço mil vezes por hora dentro de sua sub-rede. Isso quebra a lógica habitual em que endereço = identificador do cliente.

Por isso, as plataformas desenvolveram uma abordagem especial para IPv6, e entendê-la é fundamental.

Como a sub-rede /64 é interpretada

Lembre-se do que dissemos na seção de fundamentos: a operadora atribui a cada assinante uma sub-rede inteira /64. Isso é uma quantidade gigantesca de endereços para um único dispositivo.

Sistemas inteligentes de reputação sabem disso. Em vez de avaliar cada endereço IPv6 individualmente, eles agregam toda a sub-rede /64 e a tratam como um único identificador. A lógica é simples: já que toda essa sub-rede pertence a um único assinante, deve ser tratada como um único cliente.

Isso significa que mudar o endereço IPv6 dentro de uma mesma /64 não cria um novo identificador para essas plataformas. Você pode embaralhar os últimos bits do endereço à vontade, mas, do ponto de vista da plataforma, ainda é o mesmo cliente, porque o prefixo /64 não muda.

O que isso significa para trabalhar com várias contas

Daí decorre uma conclusão prática importante. Se você tenta separar contas usando diferentes endereços IPv6 dentro de uma mesma sub-rede /64, para plataformas avançadas elas parecerão um único cliente. Endereços diferentes não proporcionam separação se o prefixo comum for o mesmo.

Compare isso com o comportamento do IPv4 via NAT64. O IPv4 público do nó PLAT é compartilhado por muitos assinantes diferentes da operadora. Do ponto de vista da plataforma, atrás de um único IPv4 estão dezenas de pessoas reais. Isso dá um quadro completamente diferente de mistura de tráfego.

Conclusões importantes para múltiplas contas:

• Mudar os últimos bits de um IPv6 dentro de uma mesma /64 não altera o identificador para plataformas inteligentes
• A unidade significativa para IPv6 é o prefixo /64, não o endereço individual
• A separação deve ocorrer no nível de diferentes sub-redes /64, não de endereços dentro de uma mesma
• O IPv4 via NAT64 mistura você com outros assinantes da operadora, proporcionando uma dinâmica de reputação diferente
• Entenda sempre qual protocolo está sendo realmente usado para a conexão com uma plataforma específica

Recomendação prática para controle do protocolo

Considerando tudo isso, é sensato controlar por qual protocolo sua conexão com a plataforma de destino está sendo feita. Se você sabe com certeza que precisa de saída IPv4 através da operadora móvel, force IPv4 no nível do cliente. Assim você garante obter o endereço público compartilhado do PLAT, e não a sub-rede IPv6 vinculada ao seu dispositivo.

Erros típicos ao trabalhar com IPv6 em redes móveis

Agora vamos reunir em um só lugar os equívocos e erros mais comuns. Estude-os com atenção – cada um pode estragar o trabalho ou levar a conclusões erradas.

Erro um: achar que o endereço IPv6 no telefone significa saída IPv6

Muitos veem um IPv6 global na interface e concluem que todo o tráfego é IPv6. Na verdade, o tráfego para sites IPv4 ainda se transforma em IPv4 no PLAT. O IPv6 no dispositivo é o transporte dentro da rede da operadora, não uma garantia de saída IPv6 para um site específico.

Erro dois: confundir endereço de saída com endereço da interface

O endereço na interface de rede do dispositivo e o endereço que o site vê são coisas diferentes. Entre eles estão o CLAT e o PLAT com tradução e NAT. Nunca julgue o endereço de saída pelo que o ip addr mostra. Sempre verifique em um serviço externo real.

Erro três: entrar em pânico com endereços pulando na verificação

Já explicamos que o happy eyeballs faz a pilha dupla mostrar ora IPv4, ora IPv6. Isso é normal. Não considere isso um sinal de proxy quebrado. Se precisar de estabilidade, force o protocolo.

Erro quatro: achar que mudar o IPv6 dentro de uma /64 gera um novo identificador

Esse é um dos erros mais caros em múltiplas contas. Plataformas inteligentes agregam toda a /64. Mudar os últimos bits do endereço é inútil para separar contas. A unidade significativa é o prefixo.

Erro cinco: ignorar o tipo de APN

O tipo de APN – IPv4, IPv6 ou IPv4v6 – determina diretamente o que acontece com o tráfego. Sem saber qual tipo está em uso, você trabalha no escuro. Sempre descubra a configuração da sessão.

Erro seis: testar a conectividade apenas por um protocolo

Testar só IPv4 ou só IPv6 dá uma imagem incompleta. O diagnóstico real exige testar ambos os protocolos separadamente com as opções -4 e -6, além de acessar um endpoint somente IPv6.

Erro sete: confundir prefixo NAT64 com um site IPv6 real

Um endereço sintetizado com prefixo 64:ff9b parece IPv6, mas por trás dele está um servidor IPv4. Se você se conectar por esse endereço, na verdade está passando pelo NAT64 para um servidor IPv4, e não se comunicando com um nó IPv6 real. Não tire conclusões sobre a presença de IPv6 nativo em um site baseado em um endereço sintetizado.

Erro oito: achar que CLAT e PLAT são a mesma coisa

CLAT vive no dispositivo e faz tradução stateless para aplicativos. PLAT vive na rede da operadora e faz tradução stateful com NAT. São componentes diferentes com tarefas diferentes. Confundi-los atrapalha o entendimento de onde realmente nasce o endereço de saída.

Ferramentas e recursos para trabalhar com a pilha de protocolos

Vamos montar um arsenal de ferramentas que ajudarão você a diagnosticar e entender a pilha de rede no ambiente móvel. Todas são padrão e não exigem nada exótico.

Linha de comando

• ip addr e suas variantes ip -4 addr, ip -6 addr – ferramenta básica para visualizar endereços de interfaces
• ping e ping6 – testam conectividade por um protocolo específico
• curl com opções -4 e -6 – principal ferramenta para diagnosticar conexões web e verificar o endereço de saída
• traceroute e traceroute6 – rastreiam a rota, ajudam a ver por quais nós o tráfego passa
• dig e nslookup – consultas DNS para verificar registros A e AAAA, detectar endereços sintetizados
• ip route – visualizar a tabela de roteamento para ambos os protocolos

Serviços online de verificação

• Serviços de determinação de IP externo – mostram o que o site remoto vê
• Endpoints de teste somente IPv6 – verificam a presença de conectividade IPv6 nativa
• Serviços que mostram separadamente IPv4 e IPv6 – ajudam a enxergar a pilha dupla
• Ferramentas para verificar suporte a IPv6 de um domínio – mostram se há registro AAAA

Diagnóstico de DNS

Consultas DNS ajudam a entender se o DNS64 está funcionando. Consulte um registro AAAA para um domínio que não tem IPv6 e observe a estrutura da resposta. A presença do prefixo 64:ff9b revela o trabalho de síntese. Essa é a forma mais direta de confirmar a presença do mecanismo NAT64 na rede.

Framework de diagnóstico sistêmico da pilha

Proponho um framework passo a passo que vale a pena executar ao conhecer qualquer rede móvel pela primeira vez:

1. Inventário de endereços. Execute ip addr, determine a presença de IPv6 global e a natureza do IPv4
2. Identificação do CLAT. Encontre a interface virtual com IPv4 privado – isso é sinal de 464XLAT
3. Verificação de NAT64. Consulte AAAA para um domínio somente IPv4, procure o prefixo 64:ff9b
4. Teste de IPv6 nativo. curl -6 em um endpoint somente IPv6
5. Determinação do IPv4 de saída. curl -4 em um serviço de determinação de IP
6. Determinação do IPv6 de saída. curl -6 em um serviço que suporte IPv6
7. Análise do comportamento da pilha dupla. Requisição normal sem forçar protocolo, observação do happy eyeballs

Seguindo todos os sete passos, você terá um quadro completo: qual tipo de conectividade a rede tem, se a tradução está funcionando, quais endereços diferentes tipos de site veem e como a pilha dupla se comporta. Esse é o seu auditor padrão.

Casos e resultados: análise de cenários reais

A mecânica abstrata é melhor compreendida com exemplos concretos. Vamos analisar alguns cenários típicos encontrados na prática.

Caso um: o site vê nos logs um único IPv4 para muitos clientes

Situação. Um analista examina os logs de um site e percebe que de um único endereço IPv4 vêm muitos usuários diferentes com comportamentos distintos. O primeiro pensamento é que é um proxy ou botnet.

Análise. Na verdade, é o clássico IPv4 público de um nó NAT64 ou CGN de uma grande operadora móvel. Atrás desse único endereço estão dezenas ou centenas de assinantes reais. O tráfego deles sai por um único PLAT. Isso não é uma anomalia, mas o funcionamento normal do 464XLAT em um cenário de escassez de IPv4.

Conclusão. Avaliar clientes móveis apenas pelo endereço IPv4 é ineficaz. Um endereço não equivale a um usuário no ambiente móvel. É exatamente essa característica que torna os endereços IPv4 móveis tão peculiares – alta densidade de usuários reais atrás de um mesmo endereço.

Caso dois: resposta inconsistente do serviço de verificação

Situação. Um operador de proxy móvel reclama que o serviço de verificação de IP mostra ora IPv4, ora IPv6, e conclui que o proxy é instável.

Análise. O serviço de verificação tem registros A e AAAA. O cliente opera em pilha dupla. Cada requisição dispara o happy eyeballs e, dependendo do resultado da corrida de conexões, um tipo diferente de endereço é retornado. O proxy está funcionando de forma absolutamente estável; apenas o protocolo escolhido pelo algoritmo muda.

Solução. Forçar o protocolo com curl -4 ou configurações correspondentes no cliente. Depois de fixar IPv4, o endereço se tornou previsível. O problema de instabilidade era ilusório.

Caso três: contas que se fundem apesar de IPv6 diferentes

Situação. Trabalho com várias contas via IPv6, cada conta recebe um endereço IPv6 separado. No entanto, a plataforma relaciona as contas entre si.

Análise. Todos os endereços atribuídos estavam dentro de uma mesma sub-rede /64, fornecida pela operadora ao dispositivo. Um sistema de reputação avançado agregou toda a /64 e a tratou como um único identificador. Endereços diferentes dentro de um mesmo prefixo não proporcionaram separação alguma.

Conclusão. Para IPv6, a unidade significativa é o prefixo /64, não o endereço individual. A separação exige prefixos diferentes. Nesse caso, o mais sensato teria sido trabalhar pela saída IPv4 do NAT64, onde o tráfego se mistura com outros assinantes da operadora.

Caso quatro: um aplicativo que não sabe lidar com IPv6

Situação. Um aplicativo antigo se conecta diretamente a um literal IPv4 e, teoricamente, deveria quebrar em uma rede puramente IPv6. Mas ele funciona.

Análise. No dispositivo, o CLAT está ativo. O aplicativo envia um pacote IPv4 para a interface virtual, o CLAT o traduz para IPv6, o pacote segue pelo PLAT até a internet IPv4. O aplicativo vive na ilusão de um IPv4 completo e não desconfia da tradução. Essa é exatamente a tarefa para a qual o CLAT existe.

Conclusão. O 464XLAT garante compatibilidade para aplicativos legados de forma transparente. É por isso que a migração das operadoras para IPv6 não quebrou o ecossistema de software IPv4.

Perguntas frequentes

Por que meu telefone mostra IPv6, mas o site registra IPv4 nos logs?

Porque a troca ocorre no nó PLAT no núcleo da rede da operadora. O dispositivo envia tráfego em IPv6, mas, ao sair para um site IPv4, o nó NAT64 traduz o pacote para IPv4 e coloca um endereço público da operadora. O site vê exatamente esse IPv4 de saída, e não o IPv6 interno do dispositivo.

O que é o prefixo 64:ff9b e de onde ele vem?

É um prefixo bem conhecido padronizado para tradução NAT64. O DNS64 o utiliza para sintetizar endereços IPv6 artificiais a partir de endereços IPv4 de sites sem registro AAAA. Os últimos 32 bits desse endereço contêm o IPv4 real, que o PLAT extrai durante a tradução.

Qual a diferença entre CLAT e PLAT?

CLAT opera no dispositivo e faz tradução stateless de IPv4 para IPv6 para aplicativos que precisam de IPv4. PLAT opera na rede da operadora e faz tradução stateful de IPv6 para IPv4 com NAT, colocando um endereço público. CLAT resolve a compatibilidade no dispositivo; PLAT resolve a compatibilidade com a internet IPv4.

Por que o serviço de verificação de IP mostra endereços diferentes ao atualizar?

Devido ao algoritmo happy eyeballs em um ambiente de pilha dupla. Se o serviço de verificação é acessível tanto por IPv4 quanto por IPv6, o cliente inicia uma corrida de conexões, e em momentos diferentes um protocolo diferente vence. Isso é normal, não é falha. Force o protocolo com uma opção para obter um resultado estável.

Como saber se tenho saída IPv6 real, e não apenas NAT64?

Acesse um endpoint disponível exclusivamente por IPv6 com o comando curl -6. Se a conexão for estabelecida, você tem conectividade IPv6 nativa. Se não funcionar mesmo forçando -6, então não há saída IPv6 real; toda a atividade IPv6 gira em torno do prefixo NAT64 sintetizado.

Por que mudar o endereço IPv6 não ajuda a separar contas?

Porque a operadora atribui ao dispositivo uma sub-rede inteira /64, e plataformas avançadas agregam toda essa sub-rede como um único identificador. Mudar os últimos bits do endereço não altera o prefixo, então para a plataforma continua sendo o mesmo cliente. A unidade significativa é a /64, não o endereço individual.

Por que um proxy móvel geralmente tem saída IPv4 e não IPv6?

Porque a maioria dos sites de destino não tem infraestrutura IPv6, e o tráfego para eles passa pelo NAT64. O nó PLAT traduz os pacotes para IPv4 e atribui um endereço público da operadora. Esse endereço se torna a saída. Para sites com registro AAAA real, o proxy pode sair diretamente por IPv6.

Como forçar o cliente a usar uma versão específica do protocolo?

No nível do curl, use as opções -4 para IPv4 e -6 para IPv6. Muitos aplicativos e bibliotecas têm configurações análogas de preferência de protocolo. Também é possível gerenciar pelas configurações de sistema de prioridade da política de endereços. Isso desliga a não determinismo do happy eyeballs e dá uma saída previsível.

O que o site de destino vê ao se conectar por uma rede móvel?

Se o site tem apenas IPv4, ele vê o endereço IPv4 público do nó NAT64 da operadora, compartilhado por muitos assinantes. Se o site tem IPv6 real, ele vê um endereço IPv6 da sub-rede atribuída ao assinante. Os endereços internos do dispositivo e o endereço virtual do CLAT o site nunca vê.

O tipo de APN influencia qual endereço o site verá?

Indiretamente, sim. O tipo de APN determina quais protocolos estão disponíveis para o dispositivo. Com IPv4v6 ou IPv6 puro com CLAT, toda a mecânica de tradução descrita funciona. Com APN IPv4 puro, a tradução não é necessária, mas essa opção é rara em grandes operadoras devido à escassez de endereços.

Conclusão: o essencial sobre a mecânica do IPv6 em redes móveis

Percorremos um longo caminho. Começamos com um enigma – telefone em IPv6, site vê IPv4 – e o desvendamos completamente. Vamos fixar as principais conclusões.

Primeiro e mais importante. A escassez de endereços IPv4 forçou as operadoras a migrar para IPv6. Os dispositivos vivem em ambiente IPv6, muitas vezes sem nenhum IPv4 público na interface de rádio. A compatibilidade com a antiga internet IPv4 é garantida pela tecnologia 464XLAT.

Segundo. O 464XLAT consiste em dois tradutores. O CLAT no dispositivo transforma o tráfego IPv4 dos aplicativos em IPv6. O PLAT na rede da operadora transforma o IPv6 de volta em IPv4 e atribui um endereço público. É no PLAT que nasce o endereço IPv4 de saída que o site vê.

Terceiro. NAT64 e DNS64 trabalham em par. O DNS64 sintetiza endereços IPv6 a partir de IPv4 para sites sem registro AAAA, usando o prefixo 64:ff9b. O NAT64, na forma do PLAT, entrega os pacotes para esses endereços até os servidores IPv4 reais. Juntos, eles tornam toda a internet IPv4 acessível para um dispositivo puramente IPv6.

Quarto. A pilha dupla e o happy eyeballs explicam por que a verificação mostra às vezes um protocolo, às vezes outro. O cliente promove uma corrida de conexões e escolhe o vencedor. Para estabilidade, force o protocolo com as opções -4 ou -6.

Quinto. Para múltiplas contas, é fundamental entender: a sub-rede /64 é percebida por plataformas inteligentes como um único cliente. Mudar o endereço dentro de uma mesma /64 é inútil para separação. O IPv4 via NAT64, por outro lado, mistura você com outros assinantes da operadora.

Quais os próximos passos? Adote como regra realizar o diagnóstico sistêmico da pilha em qualquer nova rede móvel, seguindo nosso framework de sete etapas. Domine o curl com as opções -4 e -6 como ferramenta principal. Sempre verifique o endereço de saída em um serviço externo real, não pela interface do dispositivo. E tenha em mente a diferença entre onde o dispositivo vive e de onde o tráfego realmente sai para a internet.

Entender essa mecânica transforma você de um usuário que se pergunta sobre endereços pulando em um engenheiro que sabe exatamente o que acontece com cada pacote. E saber, como se sabe, é controle. Que este artigo seja sua folha de consulta sobre o funcionamento do IPv6 em redes móveis. Volte a ele sempre que se deparar com mais um enigma de rede – e ele deixará de ser um enigma.