Checklist de ativação de IPv6 para um site

Objetivo

Servir o site por IPv6 com a mesma confiabilidade que por IPv4, sem que nenhum cliente tenha uma conexão mais lenta ou com falha porque um registro AAAA foi publicado antes de o caminho por trás dele funcionar.

Pré-requisitos

Um endereço IPv6 roteado para o host ou para o balanceador de carga, controle da zona DNS e acesso ao shell para executar testes a partir de uma rede que tenha IPv6.

Passos

1. Configure o endereço no host e abra o firewall para ele separadamente; com iptables, ip6tables é um conjunto de regras à parte, e é comum um host responder apenas em v4 porque as regras de v6 nunca foram escritas.
2. Faça o servidor web escutar. A documentação do nginx explica que ipv6only, ativado por padrão, determina se um socket IPv6 no endereço curinga [::] aceita apenas conexões IPv6 ou ambas; com o padrão, listen [::]:443 ssl; deve vir acompanhado de listen 443 ssl; para IPv4. Reinicie e confirme com ss -ltn que os dois sockets existem.
3. Teste por endereço antes de publicar o DNS: curl -6 --resolve example.com:443:[2001:db8::1] https://example.com/ e o mesmo para os redirecionamentos de HTTP para HTTPS e para cada hostname; verifique o certificado via v6, como no artigo sobre a cadeia TLS.
4. Verifique tudo o que fica atrás do front: proxies reversos que repassam o endereço do cliente, limitação de taxa e regras antiabuso baseadas em endereço (um assinante normalmente recebe um prefixo inteiro, então limites por endereço se comportam de outra forma), geolocalização, análise de logs e qualquer lista de permissão que contenha apenas endereços IPv4.
5. Publique o registro AAAA com um TTL curto. A RFC 3596 define AAAA como o tipo de registro que armazena um único endereço IPv6; a RFC 8305 faz com que clientes dual-stack consultem AAAA e A em sequência imediata.
6. Acompanhe nos logs o tráfego e os erros em v6. A RFC 8305 descreve como clientes Happy Eyeballs resolvem as duas famílias, preferem IPv6 e recorrem ao IPv4 após um breve atraso se a primeira tentativa não conectar; um cliente com esse comportamento, portanto, mascara um caminho v6 quebrado como um pequeno atraso, enquanto um cliente sem ele espera o timeout ou falha. Teste com curl -6, que força a família, e também com um navegador.
7. Adicione sondas de monitoramento que conectem somente por IPv4 e somente por IPv6, para que a falha de uma família fique visível em vez de diluída na média. Aumente o TTL quando estiver estável.

Resultado esperado

As duas famílias de endereços servem conteúdo e certificados idênticos, o monitoramento as mostra separadamente e nenhuma regra por trás do front end trata clientes v6 de forma diferente por acidente.

Limites e base de verificação

E-mail, SSH e outros serviços no mesmo hostname também passam a ter um registro AAAA e precisam da mesma verificação. A ordem dos passos e o comportamento dos clientes seguem as RFCs e a documentação citadas; não se afirmam percentuais de tráfego nem latências.