IPv6 é a sexta versão do protocolo de internet, com endereços de 128 bits, criada para substituir o IPv4 e seu teto de aproximadamente 4,3 bilhões de endereços. São cerca de 340 undecilhões de combinações únicas, espaço de sobra para as próximas décadas de dispositivos conectados.
Feita a definição, vamos ao que interessa para quem opera infraestrutura.
O IPv6 deixou de ser assunto de roadmap. O IPv4 acabou na prática, endereços públicos viraram item caro de orçamento e uma fatia real da sua audiência já chega pela rede IPv6 sem que ninguém tenha avisado o time.
Ou seja, a pergunta mudou. Não é mais “o que é IPv6”. É: o meu domínio já responde por IPv6?
Neste artigo a gente traduz o protocolo em impacto operacional: o que muda em relação ao IPv4, como ler um endereço, o que acontece com o firewall quando o NAT some e como verificar em dois minutos se o seu WordPress já está sendo servido por IPv6.
O esgotamento do IPv4 não é previsão, é registro contábil. Os registros regionais de endereçamento, incluindo APNIC e NIC.br, já liberaram seus últimos blocos. Endereço IPv4 público virou commodity escassa, e todo custo escasso reaparece na fatura de hospedagem.
Do outro lado, a adoção cresce de forma consistente. As estatísticas públicas de adoção de IPv6 medidas pelo Google mostram uma parcela relevante dos acessos aos serviços da empresa chegando por IPv6. No recorte por país, as medições de capacidade IPv6 do APNIC Labs colocam o Brasil entre os mais avançados da América Latina, acima da marca de 45% de capacidade medida, número também acompanhado pelo programa IPv6.br do NIC.br.
Traduzindo esse percentual para a sua realidade: em um site com 100 mil sessões mensais vindas do Brasil, dezenas de milhares de visitantes têm capacidade de chegar por IPv6. Se o seu domínio não publica IPv6, todos eles são empurrados de volta para a fila do IPv4.
E aí entra o efeito de rede. Em conexões IPv6 nativas, o tráfego dispensa o CGNAT que caracteriza boa parte da última milha IPv4. Menos tradução de endereço e, em muitos casos, menos hops até a origem. Isso tende a favorecer a latência de conexão e, por consequência, o TTFB percebido por essa fatia da audiência.
Não é bala de prata e não substitui cache em camadas. Mas em site de alto tráfego, milissegundo de roteamento é dinheiro.
A comparação abaixo foca no que realmente altera decisão técnica no dia a dia.
Característica | IPv4 | IPv6 |
|---|---|---|
Tamanho do endereço | 32 bits | 128 bits |
Endereços únicos | ~4,3 bilhões | ~3,4 x 10³⁸ |
Notação | Decimal (192.168.0.1) | Hexadecimal (2001:db8::1) |
Configuração de host | Manual ou DHCP | SLAAC ou DHCPv6 |
NAT | Padrão da indústria | Dispensável (endereço público por host) |
MTU mínima | 576 bytes | 1.280 bytes |
Fragmentação | Roteadores e host | Apenas o host emissor |
Registro DNS | A | AAAA |
Três linhas dessa tabela merecem tradução operacional.
A primeira é o registro AAAA. Ele é o equivalente IPv6 do registro A e é o que define se o seu domínio é alcançável por IPv6. Sem AAAA publicado, não existe serviço IPv6, por mais que o servidor tenha endereço configurado na interface.
A segunda é o SLAAC, a autoconfiguração de endereço via anúncio do roteador. Ela reduz a dependência de DHCP em vários cenários e simplifica provisionamento de hosts em escala.
A terceira é a fragmentação restrita ao host emissor. Na prática, isso significa que Path MTU Discovery precisa funcionar. Bloquear ICMPv6 no firewall por reflexo de segurança quebra descoberta de MTU e gera aquele sintoma clássico: conexão abre, TLS negocia, e a resposta trava no meio. Já vimos esse diagnóstico consumir dias de time de infra.
São 128 bits escritos em oito blocos de quatro dígitos hexadecimais, separados por dois pontos. Um endereço completo fica assim:
2001:0db8:0000:25e2:0000:0000:f0ca:84c1Como o formato é longo, existem duas regras de compressão. Zeros à esquerda de cada bloco podem ser omitidos. E uma sequência contínua de blocos zerados pode ser substituída por dois pontos duplos, uma única vez no endereço.
Aplicando as duas, o mesmo endereço vira:
2001:db8:0:25e2::f0ca:84c1Compare com um IPv4 como 189.26.216.84 e a diferença de escala fica evidente: quatro vezes mais bits, em hexadecimal, com notação variável.
Para quem desenvolve, isso tem consequência direta. Validação de entrada, colunas de banco e parsers de log precisam acomodar 45 caracteres e as formas comprimidas do mesmo endereço. Regex de IPv4 copiada do Stack Overflow não cobre IPv6, e log truncado é log inútil em auditoria de segurança.
O IPv6 trabalha com três tipos principais, e o terceiro é o que sustenta a internet moderna.
Unicast: identifica uma única interface de rede. Pacotes enviados a um endereço unicast chegam apenas àquele destino, no modelo ponto a ponto tradicional.
Multicast: identifica um grupo de interfaces e entrega o pacote a todos os membros do grupo. Ele substitui o broadcast do IPv4, que simplesmente deixou de existir no protocolo.
Anycast: o mesmo endereço é anunciado por vários nós, e o pacote vai para o mais próximo em termos de roteamento. É o mecanismo por trás de CDNs e servidores DNS autoritativos distribuídos.
Anycast em IPv6 é o motivo de o seu visitante em Recife ser atendido por um nó em Recife e não por um datacenter na Virgínia. Não é estética de arquitetura. É redução de RTT.
Existe um mito confortável de que o IPv6 é mais seguro por natureza. Nossa posição é outra.
A especificação do IPv6 na RFC 8200 nasceu com IPSec previsto no desenho do protocolo, oferecendo autenticidade e integridade em nível de rede. Só que, na operação real, o uso de IPSec segue opcional na maioria absoluta das redes. Recurso disponível não é recurso ativado.
O que muda de verdade é o fim do NAT.
Pense no NAT do IPv4 como o porteiro do prédio: ele não foi contratado para ser segurança, mas como todo mundo precisa passar por ele, acabou virando uma barreira acidental. No IPv6, cada host pode ter endereço público próprio. O porteiro sai, e o que estava escondido por acidente passa a estar exposto por padrão.
Ou seja, ativar IPv6 sem revisar borda é trocar obscuridade por superfície. A regra aqui é simples: firewall stateful explícito para IPv6, com política de negação por padrão, permitindo ICMPv6 no que é necessário para o protocolo funcionar. Vale a mesma lógica que defendemos em segurança no WordPress: a plataforma não é o problema, a configuração é.
A checagem é rápida e não exige acesso ao servidor. O sinal definitivo é a presença do registro AAAA.
Rode dig AAAA seudominio.com.br no terminal. Se a seção de resposta trouxer um endereço hexadecimal, o seu domínio publica IPv6.
Rode curl -6 -I https://seudominio.com.br para confirmar que o servidor realmente responde por IPv6, e não apenas que o registro existe no DNS.
Acesse o test-ipv6.com para avaliar a capacidade IPv6 da conexão que você está usando e identificar problemas de MTU na sua própria rede.
Confira no painel de DNS se o AAAA convive com o registro A e se ambos apontam para a mesma origem, evitando divergência de conteúdo entre os dois protocolos.
Em hospedagem WordPress gerenciada bem operada, o IPv6 vem em modo dual stack por padrão. O servidor atende por IPv4 e por IPv6 ao mesmo tempo, e o cliente escolhe o caminho.
O WordPress em si não pede nada. O protocolo opera nas camadas de rede e de hospedagem, não na aplicação. O que muda dentro do site são detalhes de código que tratam endereço de visitante: plugins de log, listas de bloqueio, geolocalização e limitadores de tentativa de login precisam saber lidar com o formato. Aliás, IPv6 e HTTP/2 andam juntos nessa conversa, como já detalhamos em sites mobile em WordPress com HTTP/2 e IPv6.
Considere ativar assim que o seu provedor suportar dual stack e a sua borda estiver auditada. Não antes.
A ordem que recomendamos é esta: revisar regras de firewall para IPv6, validar que WAF e CDN aplicam as mesmas políticas nos dois protocolos, ajustar o tratamento de endereço nos logs e só então publicar o registro AAAA. Publicar AAAA é o último passo, porque é ele que liga o tráfego real.
Ativar primeiro e auditar depois é o roteiro clássico de um incidente evitável.
Sim, e é o que a maioria dos ambientes faz. A configuração chama-se dual stack: o servidor responde por IPv4 para quem chega por IPv4 e por IPv6 para quem chega por IPv6, sem perda de compatibilidade e sem exigir escolha entre os dois protocolos.
Pode melhorar para a parte da audiência que tem conectividade IPv6 nativa, porque o caminho dispensa camadas de CGNAT e costuma ter menos hops até a origem. O ganho aparece na latência de conexão e no TTFB dessa fatia, mas não substitui cache em camadas, CDN e otimização de código.
Não no curto prazo. O IPv4 seguirá operando por muitos anos em paralelo ao IPv6, sustentado por configurações dual stack e por mecanismos de tradução. O que mudou foi a economia: novos endereços IPv4 ficaram escassos e caros, o que empurra a internet para o IPv6.
No core, não. O suporte depende do servidor, do DNS e da rede do provedor de hospedagem WordPress gerenciada. A atenção fica em plugins que registram, comparam ou bloqueiam endereços de visitantes, porque muitos ainda assumem o formato IPv4 de 32 bits e falham silenciosamente com endereços IPv6.
Não existe fator de ranqueamento específico para IPv6. O impacto é indireto: disponibilidade e latência para usuários em redes IPv6 nativas, o que se reflete em métricas de experiência. Rastreadores continuam alcançando o site normalmente em dual stack.
IPv6 não é modernização estética de rede. É endereçamento, alcance e caminho até a sua origem.
O protocolo já está na casa da sua audiência. A pergunta é se a sua infraestrutura publica AAAA, aplica firewall stateful nos dois protocolos e trata endereços de 128 bits nos logs sem quebrar. Verificamos, ajustamos a borda, publicamos e monitoramos: nessa ordem.
Se você quer saber como o seu ambiente responde hoje por IPv4 e por IPv6, nossa equipe faz essa avaliação de infraestrutura junto com o seu time de TI.
E aí, me conta: você já rodou o dig AAAA no seu domínio principal antes de terminar esta leitura?
josuesantos93 
Thiago Lima 
Leandro Vieira 
