IPv6 no Brasil: quando ele deixa de ser opcional

O endereçamento IPv4 acabou. Não é previsão — os registros regionais distribuíram os últimos blocos há anos, e o que circula desde então é mercado secundário, com endereço sendo comprado e alugado como ativo escasso.

Para quem opera servidor, isso deixou de ser curiosidade técnica e virou linha de custo. Endereço IPv4 público é cobrado porque é finito, e o preço acompanha a escassez. Ao mesmo tempo, o IPv6 já responde por uma fatia expressiva do tráfego brasileiro — o Brasil está entre os países com maior adoção do mundo, empurrado pelas operadoras móveis.

O resultado é uma assimetria estranha: boa parte dos seus usuários já tem IPv6, e boa parte dos servidores ainda não.

O que o CGNAT fez com a internet brasileira

Sem IPv4 para distribuir, as operadoras passaram a compartilhar um endereço público entre muitos assinantes. É o CGNAT, e ele funciona bem o suficiente para navegar — mas produz efeitos colaterais que aparecem no seu servidor.

O primeiro é que o IP de origem deixou de identificar um cliente. Centenas de pessoas diferentes chegam com o mesmo endereço. Isso quebra três coisas que muita aplicação faz:

• Limite por IP. Bloquear um IP abusivo pode derrubar um bairro inteiro junto.
• Bloqueio geográfico e listas de reputação. Um assinante mal-intencionado contamina a reputação do endereço compartilhado.
• Log de auditoria. "De qual IP veio essa ação" perde precisão como evidência.

O segundo efeito é a conexão de entrada. Quem está atrás de CGNAT não recebe conexão iniciada de fora, o que complica acesso remoto, VPN e qualquer coisa que dependa de alcançar a ponta.

Para o usuário com IPv6, nada disso acontece: ele tem endereço próprio, roteável, e a conexão é fim a fim. É uma internet melhor, e é a razão técnica de fundo para a transição.

O que acontece se você ignorar

Nada de dramático, e é justamente por isso que a decisão fica adiada. Um servidor só com IPv4 continua acessível para todo mundo, porque as operadoras mantêm tradução para os clientes IPv6-only.

Os custos aparecem de forma indireta:

• Latência extra. Cada tradução adiciona um salto e um ponto de congestionamento. Em rede móvel, isso é perceptível.
• Preço do endereço. IPv4 tende a ficar mais caro, e a conta cresce junto com o número de máquinas.
• Exigência contratual. Editais públicos e questionários de fornecedor cada vez mais pedem suporte a IPv6.
• Entregabilidade de e-mail. Alguns provedores tratam origem IPv6 corretamente configurada melhor que IPv4 compartilhado.

Nenhum desses é urgente sozinho. Somados, eles explicam por que a resposta certa costuma ser habilitar agora, com calma, em vez de habilitar depois, com pressa.

Dual stack é a resposta, e ele é chato num ponto

Ninguém desliga IPv4. A transição real é *dual stack*: o servidor responde nos dois protocolos, e cada cliente usa o que tiver.

Começa pelo DNS. O registro A aponta para IPv4 e o AAAA para IPv6:

dig meusite.com.br A +short
dig meusite.com.br AAAA +short

E aqui está a parte chata, que causa o incidente mais comum desta transição: os navegadores usam *Happy Eyeballs*, tentando IPv6 primeiro e caindo para IPv4 se houver falha rápida. Se o AAAA existe mas o servidor não responde bem naquele endereço, o usuário não recebe erro — recebe lentidão intermitente, difícil de reproduzir e de diagnosticar.

A regra prática: publique o `AAAA` por último, só depois que o serviço estiver comprovadamente respondendo em IPv6. Registro publicado antes da hora é a receita do problema.

Habilitar de fato

O nginx precisa escutar explicitamente nos dois. Só listen 443 ssl não cobre IPv6:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name meusite.com.br;
}

Os colchetes são a notação de endereço IPv6 e aparecem em toda configuração — vale se acostumar, porque errar isso é a causa de metade dos erros de sintaxe nessa etapa.

Confirme que o socket está aberto nos dois:

sudo ss -tulpn | grep ':443'

Você deve ver uma linha 0.0.0.0:443 e outra [::]:443. Em muitos sistemas, o socket IPv6 aceita IPv4 também, e aí aparece só a segunda — o que é normal.

Teste de fora, forçando cada protocolo:

curl -4 -I https://meusite.com.br/
curl -6 -I https://meusite.com.br/

Se o segundo falhar, não publique o AAAA ainda.

O firewall é o erro número um

Este é o ponto onde quase todo mundo tropeça: regras IPv4 e IPv6 são listas separadas. Fechar a porta no iptables não fecha no ip6tables.

O resultado é um servidor cuidadosamente protegido em IPv4 e completamente aberto em IPv6 — com a agravante de que ninguém percebe, porque as ferramentas de teste usam IPv4 por padrão.

O ufw cuida dos dois automaticamente, desde que esteja habilitado:

grep IPV6 /etc/default/ufw     # precisa ser IPV6=yes
sudo ufw status verbose

Com nftables ou iptables na mão, a conferência é explícita:

sudo nft list ruleset | grep -A5 'family ip6'
sudo ip6tables -L -n -v

Vale repetir o teste de fora, agora pelo protocolo novo:

nmap -6 -Pn -p 22,80,443,3306,5432,6379 meusite.com.br

Se aparecer porta de banco aberta aqui e fechada no teste IPv4, você acabou de encontrar o problema antes que ele encontrasse você. A mesma lógica vale na camada de perímetro: confira que as regras de firewall cobrem as duas famílias de endereço.

O que mais costuma quebrar

Depois do firewall, os tropeços seguintes são previsíveis:

• Aplicação escutando só em `0.0.0.0`. Isso é apenas IPv4. Para os dois, use :: ou configure explicitamente o duplo bind.
• Campo de IP curto no banco. Um VARCHAR(15) guarda 192.168.0.1 e trunca um endereço IPv6, que chega a 45 caracteres. Trunca em silêncio, corrompendo o log.
• Validação de IP na aplicação. Expressão regular escrita para IPv4 rejeita usuário legítimo.
• Lista de permissão por IP. Se um serviço interno libera por endereço, o cliente que passou a chegar por IPv6 é barrado sem explicação.
• `X-Forwarded-For` com colchetes. O formato muda, e código que separa por dois-pontos para tirar a porta quebra feio.
• Geolocalização desatualizada. Base de dados que só mapeia IPv4 devolve resultado vazio.

O padrão comum a todos: são falhas de código que só aparecem quando o primeiro usuário real chega pelo protocolo novo. Vale procurá-las antes.

Endereço fixo, não temporário

Um detalhe que morde depois e é difícil de associar à causa. Sistemas Linux costumam habilitar extensões de privacidade no IPv6: além do endereço estável, a máquina gera endereços temporários que mudam periodicamente e são usados para conexões de saída.

Em desktop isso é ótimo — dificulta rastreamento. Em servidor é um problema, porque a origem das suas conexões muda sozinha. O sintoma aparece longe: a API do parceiro, que autoriza por lista de origem, passa a recusar de forma intermitente. O e-mail enviado começa a cair em spam porque o reverso não bate com o endereço de saída.

sysctl net.ipv6.conf.all.use_tempaddr

Em servidor, o valor deve ser 0:

# /etc/sysctl.d/99-ipv6.conf
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0

sudo sysctl --system
ip -6 addr show scope global

Você deve ver um único endereço global, sem nenhum marcado como temporary.

Pelo mesmo motivo, prefira endereço configurado explicitamente a endereço obtido por autoconfiguração. Servidor com endereço que pode mudar é servidor cujo registro AAAA pode apontar para o lugar errado — e a autoconfiguração existe justamente para máquinas que não precisam de endereço previsível.

Se o servidor envia e-mail, configure também o reverso do endereço IPv6. Vários provedores de e-mail são mais rigorosos com IPv6 do que com IPv4, e mensagem enviada de endereço sem reverso adequado tem chance alta de ser recusada.

Um roteiro sem susto

A sequência que evita incidente é sempre a mesma, e a ordem é o que importa:

• Peça o endereço IPv6 e confirme que a interface subiu com ele.
• Ajuste o firewall para IPv6 antes de qualquer outra coisa. Padrão negar, mesmas exceções do IPv4.
• Faça a aplicação escutar nos dois protocolos e teste localmente.
• Teste de fora com `curl -6`, usando o endereço direto, sem DNS.
• Só então publique o `AAAA`, começando por um subdomínio de teste.
• Acompanhe por alguns dias antes de estender ao domínio principal.

Um bom momento para fazer isso é ao subir uma máquina nova, onde não há tráfego em risco — a criação de VPS já entrega IPv4 e IPv6, e serve de laboratório para o roteiro inteiro antes de aplicá-lo em produção.

E se o motivo por trás do interesse for reduzir custo de endereço, vale considerar a arquitetura: nem toda máquina precisa de IPv4 público. Aplicação atrás de proxy ou de balanceador pode viver só com endereço interno e IPv6, deixando o endereço escasso apenas onde ele é indispensável.