Lista de verificación para habilitar IPv6 en un sitio web

Objetivo

Servir el sitio por IPv6 con la misma fiabilidad que por IPv4, de modo que ningún cliente sufra una conexión más lenta o fallida por haber publicado un registro AAAA antes de que la ruta que hay detrás funcionara.

Requisitos previos

Una dirección IPv6 enrutada hacia el host o el balanceador de carga, control de la zona DNS y acceso a la shell para ejecutar pruebas desde una red con IPv6.

Pasos

1. Configura la dirección en el host y abre el firewall para ella por separado; con iptables, ip6tables es un conjunto de reglas distinto, y es habitual encontrar un host que responde solo por v4 porque nunca se escribieron las reglas de v6.
2. Haz que el servidor web escuche. La documentación de nginx explica que ipv6only, activado por defecto, determina si un socket IPv6 en la dirección comodín [::] acepta solo conexiones IPv6 o ambas; con el valor por defecto, listen [::]:443 ssl; debe ir acompañado de listen 443 ssl; para IPv4. Reinicia y comprueba con ss -ltn que existen ambos sockets.
3. Prueba por dirección antes de publicar el DNS: curl -6 --resolve example.com:443:[2001:db8::1] https://example.com/ y haz lo mismo con las redirecciones de HTTP a HTTPS y con cada nombre de host; comprueba el certificado por v6 como en el artículo sobre la cadena TLS.
4. Revisa todo lo que hay detrás del front: proxies inversos que transmiten la dirección del cliente, limitación de tasa y reglas antiabuso basadas en la dirección (un abonado suele disponer de un prefijo completo, por lo que los límites por dirección se comportan de otra manera), geolocalización, análisis de logs y cualquier lista de permitidos que contenga solo direcciones IPv4.
5. Publica el registro AAAA con un TTL corto. El RFC 3596 define AAAA como el tipo de registro que almacena una única dirección IPv6; el RFC 8305 establece que los clientes de doble pila consultan AAAA y A una justo después de la otra.
6. Vigila los logs en busca de tráfico y errores de v6. El RFC 8305 describe cómo los clientes con Happy Eyeballs resuelven ambas familias, prefieren IPv6 y recurren a IPv4 tras un breve retraso si el primer intento no conecta; por tanto, un cliente con este comportamiento disimula una ruta v6 rota como un pequeño retraso, mientras que uno que no lo tiene espera a que venza su timeout o falla. Prueba con curl -6, que fuerza la familia, y también con un navegador.
7. Añade sondas de monitorización que se conecten solo por IPv4 y solo por IPv6, para que el fallo de una familia sea visible en lugar de diluirse en un promedio. Sube el TTL cuando todo esté estable.

Resultado esperado

Ambas familias de direcciones sirven el mismo contenido y los mismos certificados, la monitorización las muestra por separado y ninguna regla detrás del front end trata a los clientes v6 de forma distinta por accidente.

Límites y base de verificación

El correo, SSH y otros servicios con el mismo nombre de host también obtienen un registro AAAA y requieren la misma comprobación. El orden de los pasos y el comportamiento de los clientes se basan en los RFC y la documentación citados; no se afirman cuotas de tráfico ni latencias.