Para que um dispositivo se comunique com outros dispositivos na internet usando o apropriadamente denominado protocolo de internet (IP), primeiro deve ser atribuído a ele um endereço numérico exclusivo. A aparência desse endereço depende da versão do IP usada: IPv4 ou IPv6.
O IPv4 foi implantado pela primeira vez em 1983. É a versão do IP que deu origem à internet moderna e ainda hoje permanece dominante. O IPv6 pode ser rastreado desde o início de 1998, mas somente na última década ele começou a ganhar aceitação significativa, passando de menos de 1% para algo entre 30 e 40%, dependendo de quem está relatando e de como estão medindo.
Com o crescimento dos dispositivos conectados excedendo em muito o número de endereços IPv4 disponíveis e os seus custos aumentando, o espaço de endereços muito maior fornecido pelo IPv6 deveria tê-lo tornado o protocolo dominante até agora. Contudo, como veremos, este não é o caso.
A Cloudflare tem sido uma forte defensora do IPv6 há muitos anos e, por meio do Cloudflare Radar, temos acompanhado de perto a adoção do IPv6 na internet. Aos três anos, o Radar ainda é uma plataforma relativamente recente. Para voltar no tempo, podemos recorrer brevemente aos nossos amigos do APNIC, um dos cinco Registros Regionais da Internet (RIRs). Através dos seus dados, que remontam a 2012, podemos ver que o IPv6 passou por um período de crescimento aparentemente exponencial até meados de 2017, após o qual entrou num período de crescimento linear que ainda continua:
A adoção do IPv6 é prejudicada pela falta de compatibilidade entre os dois protocolos, os dispositivos devem receber um endereço IPv4 e um endereço IPv6, juntamente com o fato de que praticamente todos os dispositivos na internet ainda são compatíveis com IPv4. No entanto, o IPv6 é fundamental para o futuro da internet e é necessário um esforço contínuo para aumentar a sua implantação.
O Cloudflare Radar, assim como o APNIC e a maioria das outras fontes hoje, publica números que refletem principalmente até que ponto os provedores de serviços de internet (ISPs) implantaram o IPv6: o lado do cliente. É um ângulo muito importante e que impacta diretamente os usuários finais, mas há também o outro extremo da equação: o lado do servidor.
Com isso em mente, convidamos você a nos acompanhar em um experimento rápido onde pretendemos ter uma ideia da adoção do IPv6 no lado do servidor e com que frequência os clientes são realmente (ou provavelmente) capazes de se comunicar com servidores através do IPv6. Contaremos com o DNS para esta exploração e, como dizem, os resultados podem surpreender você.
Adoção de IPv6 no lado do cliente (a partir de HTTP)
No final de outubro de 2023, da perspectiva da Cloudflare, a adoção do IPv6 na internet era de aproximadamente 36% de todo o tráfego, com pequenas variações dependendo da hora do dia e do dia da semana. Ao excluir os bots, a estimativa sobe para pouco mais de 46%, enquanto a exclusão dos humanos reduz a estimativa para perto de 24%. Esses números referem-se à parcela de solicitações HTTP atendidas por IPv6 em todo o conteúdo habilitado para IPv6 (a configuração padrão).
Para este exercício, o que mais importa é o número de humanos e de bots. Existem muitas razões para a diferença na adoção entre ambos os tipos de tráfego, desde os diferentes níveis de compatibilidade com IPv6 nos inúmeros softwares de cliente utilizados, até os diversos níveis de implementação do IPv6 nas diversas redes de onde o tráfego provém, até o tamanho variável dessas redes, etc, mas isso é uma questão para outro dia. Se você tiver curiosidade sobre os números de um país ou rede específicos, pode encontrá-los no Cloudflare Radar e no nosso relatório Análise do ano de 2023.
É preciso trabalhar em conjunto
Você, que está lendo, pode evidenciar que medir o lado do cliente da equação cliente-servidor conta apenas metade da história: para um cliente compatível com IPv6 estabelecer uma conexão com um servidor via IPv6, o servidor também deve ser compatível com IPv6.
Isso levanta duas questões:
Qual é a extensão da adoção do IPv6 no lado do servidor?
Até que ponto a adoção do IPv6 no lado do cliente se alinha com a adoção no lado do servidor?
Existem diversas respostas possíveis, dependendo se estamos falando de usuários, dispositivos, bytes transferidos e assim por diante. Vamos nos concentrar nas conexões (o porquê ficará claro em um momento), e a pergunta combinada que fazemos é:
Com que frequência um cliente compatível com IPv6 pode usar IPv6 ao se conectar a servidores na internet, sob padrões típicos de uso?
Os padrões típicos de uso incluem pessoas seguindo sua rotina diária, visitando alguns sites com mais frequência do que outros, ou clientes automatizados chamando APIs. Recorreremos ao DNS para obter essa perspectiva.
Inserir o DNS
Antes que um cliente possa tentar estabelecer uma conexão com um servidor por nome, usando o protocolo IPv4 clássico ou o IPv6 mais moderno, ele deve procurar o endereço de IP do servidor na lista telefônica da internet, o Sistema de Nomes de Domínio (DNS).
Procurar um hostname no DNS é um processo recursivo. Para encontrar o endereço de IP de um servidor, a hierarquia do domínio (os componentes separados por pontos do nome de um servidor) deve ser seguida por vários servidores DNS autoritativos até que um deles retorne a resposta desejada. A maioria dos clientes, entretanto, não faz isso diretamente e, em vez disso, pede a um servidor intermediário, chamado resolvedor recursivo, que faça isso por eles. A Cloudflare opera um resolvedor recursivo que qualquer pessoa pode usar: o 1.1.1.1.
Como um exemplo simplificado, quando um cliente pede ao 1.1.1.1 o endereço de IP onde reside “www.example.com”, o 1.1.1.1 pergunta aos servidores raiz de DNS sobre “.com”, depois pergunta aos servidores de DNS .com sobre “example.com” e, finalmente, pergunta aos servidores de DNS de example.com sobre “www.example.com”, que têm conhecimento direto dele e respondem com um endereço de IP. Para tornar as coisas mais rápidas para o próximo cliente que fizer uma pergunta semelhante, o 1.1.1.1 armazena em cache (lembra por um tempo) a resposta final e as etapas intermediárias.
Isso significa que o 1.1.1.1 está em uma posição muito boa para contar com que frequência os clientes tentam procurar endereços IPv4 (consultas do tipo A) comparado com a frequência que eles tentam procurar endereços IPv6 (consultas do tipo AAA), cobrindo a maior parte da internet observável.
Mas como um cliente sabe quando solicitar o endereço IPv4 ou IPv6 de um servidor?
A resposta curta é que os clientes com IPv6 disponível apenas solicitam ambos, fazendo pesquisas A e AAAA separadas para cada servidor ao qual desejam se conectar. Esses clientes compatíveis com IPv6 vão priorizar a conexão via IPv6 quando obtiverem uma resposta AAAA não vazia, independentemente de também obterem uma resposta A não vazia (o que quase sempre obtêm, como veremos). O algoritmo que impulsiona essa preferência pela modernidade é chamado Happy Eyeballs, se você tiver interesse nos detalhes.
Agora estamos prontos para começar a analisar alguns dados reais…
Adoção de IPv6 no lado do cliente (a partir do DNS)
A primeira etapa é estabelecer uma linha de base medindo a implantação do IPv6 pelos clientes a partir da perspectiva do 1.1.1.1 e compará-la com os números das solicitações HTTP com os quais começamos.
É tentador contar com que frequência os clientes se conectam ao 1.1.1.1 usando IPv6, mas os resultados são enganosos por alguns motivos, sendo o mais forte oculto à vista de todos: o 1.1.1.1 é o endereço mais memorável do conjunto de endereços IPv4 e IPv6 que os clientes podem usar para realizar pesquisas de DNS por meio do serviço 1.1.1.1. Idealmente, os clientes compatíveis com IPv6 que usam o 1.1.1.1 como seu resolvedor recursivo devem ter todos os quatro endereços de IP a seguir configurados, não apenas os dois primeiros:
1.1.1.1 (IPv4)
1.0.0.1 (IPv4)
2606:4700:4700::1111 (IPv6)
2606:4700:4700::1001 (IPv6)
Mas, quando a configuração manual está envolvida, os humanos consideram os endereços IPv6 menos memoráveis do que os endereços IPv4 e têm menos probabilidade de configurá-los, considerando suficientes apenas os endereços IPv4.
Um fator de confusão relacionado, mas menos óbvio, é que muitos clientes compatíveis com IPv6 ainda vão realizar pesquisas de DNS sobre IPv4 mesmo quando tiverem endereços IPv6 do 1.1.1.1 configurados, já que distribuir pesquisas pelos endereços disponíveis é uma opção padrão popular.
Uma abordagem mais sensata para avaliar a adoção do IPv6 a partir da atividade de DNS do cliente é calcular a porcentagem de consultas do tipo AAAA sobre a quantidade total de consultas do tipo A, assumindo que os clientes IPv6 sempre realizam ambas, conforme mencionado anteriormente.
Então, da perspectiva do 1.1.1.1, a adoção do IPv6 no lado do cliente é estimada em 30,5% por volume de consultas. Isso está um pouco abaixo do que observamos no tráfego HTTP no mesmo período (35,9%), mas essa diferença entre duas perspectivas diferentes não é inesperada.
Uma observação sobre TTLs
Não são apenas os resolvedores recursivos que armazenam em cache as respostas de DNS; a maioria dos clientes de DNS também tem seus próprios caches locais. Seu navegador da web, sistema operacional e até mesmo seu roteador doméstico mantêm as respostas na esperança de acelerar as consultas subsequentes.
O tempo que cada resposta permanece no cache depende do campo tempo de vida (TTL) enviado de volta com os registros de DNS. Se você conhece DNS, deve estar se perguntando se os registros A e AAAA têm TTLs semelhantes. Caso contrário, poderemos receber menos consultas para apenas um desses dois tipos (porque ele fica armazenado em cache por mais tempo no nível do cliente), distorcendo os números de adoção resultantes.
Os gráficos de pizza aqui detalham os TTLs mínimos enviados de volta pelo 1.1.1.1 em resposta às consultas A e AAAA. Existe alguma diferença entre os dois tipos, mas a diferença é muito pequena.
Adoção do IPv6 no lado do servidor
O gráfico a seguir mostra com que frequência as consultas do tipo A e AAAA obtêm respostas não vazias, esclarecendo a adoção do IPv6 no lado do servidor e nos aproximando da resposta que buscamos:
A adoção do IPv6 pelos servidores é estimada em 43,3% por volume de consultas, valor visivelmente superior ao observado para os clientes.
Com que frequência os dois lados combinam
Se 30,5% das pesquisas de endereços de IP tratadas pelo 1.1.1.1 pudessem fazer uso de um endereço IPv6 para se conectar aos destinos pretendidos, mas apenas 43,3% dessas pesquisas obtivessem uma resposta não vazia, isso poderia nos dar uma boa base de como muitas vezes, as conexões IPv6 são feitas entre cliente e servidor, aproximadamente 13,2% das vezes.
O possível impacto dos domínios populares
A adoção do IPv6 do lado do servidor medida pelo volume de consultas para os domínios na lista dos Top 100 do Radar é de 60,8%. Se excluirmos estes domínios dos nossos cálculos globais, o valor anterior de 13,2% cai para 8%. Esta é uma diferença significativa, mas não inesperada, já que os Top 100 domínios representam mais de 55% de todas as consultas A e AAAA para o 1.1.1.1.
Se apenas mais alguns desses domínios altamente populares implantassem o IPv6 hoje, a adoção observada aumentaria visivelmente e, com ela, a chance de clientes compatíveis com IPv6 estabelecerem conexões usando IPv6.
Considerações finais
Observar a extensão da adoção do IPv6 na internet pode significar coisas diferentes:
Contagem de usuários com acesso à internet compatíveis com IPv6.
Contagem de dispositivos ou software compatíveis com IPv6 nesses dispositivos (clientes e/ou servidores).
Cálculo da quantidade de tráfego que flui através de conexões IPv6, medido em bytes.
Contagem da fração de conexões (ou solicitações individuais) em IPv6.
Neste exercício optamos por analisar conexões e solicitações. Tendo em mente que a realidade subjacente só pode ser verdadeiramente compreendida considerando diversas perspectivas diferentes, vimos três números diferentes de adoção do IPv6:
35,9% (lado do cliente) ao contar as solicitações HTTP atendidas pela CDN da Cloudflare.
30,5% (lado do cliente) ao contar consultas de DNS do tipo A e AAAA tratadas pelo 1.1.1.1.
43,3% (lado do servidor) de respostas positivas a consultas de DNS do tipo AAAA, também a partir do 1.1.1.1.
Combinamos os números do lado do cliente e do servidor a partir do DNS para estimar a frequência com que as conexões a servidores de terceiros são provavelmente estabelecidas através de IPv6 em vez de IPv4: apenas 13,2% do tempo.
Para melhorar estes números, os provedores de internet, os fornecedores de nuvem e de hospedagem, bem como as empresas, devem aumentar a taxa de disponibilização do IPv6 para dispositivos nas suas redes. Mas grandes sites e fontes de conteúdo também têm um papel crítico a desempenhar para permitir que clientes compatíveis com IPv6 usem IPv6 com mais frequência, já que 39,2% das consultas para domínios nos Top 100 do Radar (representando mais da metade de todas as consultas A e AAAA para o 1.1.1.1) ainda estão limitados a respostas apenas IPv4.
A internet ainda tem um caminho a percorrer na adoção completa do IPv6. Mas o esforço contínuo de todos os envolvidos pode ajudar a impulsionar seu avanço, e talvez até acelerar o progresso.
No lado do servidor, a Cloudflare tem ajudado nesse esforço mundial há muitos anos, fornecendo compatibilidade com IPv6 gratuita para todos os domínios. No lado do cliente, o aplicativo 1.1.1.1 habilita automaticamente seu dispositivo para IPv6, mesmo que seu provedor de internet não seja compatível com IPv6. E, se acontecer de você gerenciar uma rede somente IPv6, o suporte DNS64 do 1.1.1.1 também vai ajudar.
***
1O resolvedor de DNS público da Cloudflare (1.1.1.1) é operado em parceria com a APNIC. Você pode ler mais sobre isso no post original do anúncio no blog e na política de privacidade do 1.1.1.1.
2Há mais informações sobre como o DNS funciona na seção “O que é DNS?” do nosso site. Se você é um aluno prático, sugerimos que dê uma olhada em “mess with dns” de Julia Evans.
3Qualquer resolvedor recursivo já conhece previamente os endereços de IP dos 13 servidores raiz. A Cloudflare também participa no nível mais alto do DNS, fornecendo serviço anycast para as instâncias E e F-Root, o que significa que o 1.1.1.1 não precisa ir muito longe para a primeira etapa de pesquisa.
4Ao usar o aplicativo 1.1.1.1, todos os quatro endereços de IP são configurados automaticamente.
5Para simplificar, deduzimos que a quantidade de clientes somente IPv6 ainda é insignificantemente pequena.É uma suposição razoável de forma geral, e outros conjuntos de dados disponíveis confirmam isso.
6O 1.1.1.1, como outros resolvedores recursivos, retorna TTLs ajustados: o TTL original do registro menos o número de segundos desde que o registro foi armazenado em cache pela última vez. As respostas vazias A e AAAA são armazenadas em cache pelo período de tempo definido no registro Start of Authority (SOA) do domínio, conforme especificado pela RFC 2308.