Liste de contrôle pour l'activation d'IPv6 sur un site web

Objectif

Servir le site en IPv6 avec la même fiabilité qu'en IPv4, sans qu'aucun client ne subisse une connexion plus lente ou en échec parce qu'un enregistrement AAAA a été publié avant que le chemin situé derrière ne fonctionne.

Prérequis

Une adresse IPv6 routée vers l'hôte ou l'équilibreur de charge, le contrôle de la zone, et un accès shell permettant d'exécuter des tests depuis un réseau disposant d'IPv6.

Étapes

1. Configurer l'adresse sur l'hôte et ouvrir le pare-feu séparément pour elle ; avec iptables, ip6tables constitue un jeu de règles distinct, et un hôte qui ne répond qu'en v4 parce que les règles v6 n'ont jamais été écrites est un état fréquent.
2. Mettre le serveur web à l'écoute. La documentation de nginx explique que ipv6only, activé par défaut, détermine si un socket IPv6 sur l'adresse générique [::] accepte uniquement les connexions IPv6 ou les deux ; avec ce réglage par défaut, listen [::]:443 ssl; doit être accompagné de listen 443 ssl; pour l'IPv4. Redémarrer et vérifier avec ss -ltn que les deux sockets existent.
3. Tester par adresse avant de publier le DNS : curl -6 --resolve example.com:443:[2001:db8::1] https://example.com/ et de même pour les redirections HTTP vers HTTPS et pour chaque nom d'hôte ; vérifier le certificat en v6 comme indiqué dans l'article sur la chaîne TLS.
4. Vérifier tout ce qui se trouve derrière la façade : les proxys inverses transmettant l'adresse du client, la limitation de débit et les règles anti-abus indexées par adresse (un abonné détient généralement un préfixe entier, si bien que des limites par adresse se comportent différemment), la géolocalisation, l'analyse des journaux, et toute liste d'autorisation ne contenant que des adresses IPv4.
5. Publier l'enregistrement AAAA avec un TTL court. La RFC 3596 définit AAAA comme le type d'enregistrement stockant une seule adresse IPv6 ; la RFC 8305 fait interroger AAAA puis A l'un après l'autre par les clients à double pile.
6. Surveiller les journaux pour le trafic v6 et les erreurs. La RFC 8305 décrit comment les clients Happy Eyeballs résolvent les deux familles, préfèrent IPv6 et se replient sur IPv4 après un court délai si la première tentative ne se connecte pas ; un client doté de ce comportement masque donc un chemin v6 défaillant sous la forme d'un petit délai, tandis qu'un client qui en est dépourvu attend son délai d'expiration ou échoue. Tester avec curl -6, qui force la famille, ainsi qu'avec un navigateur.
7. Ajouter des sondes de surveillance qui se connectent exclusivement en IPv4 et exclusivement en IPv6, afin qu'une défaillance d'une famille soit visible au lieu d'être noyée dans la moyenne. Augmenter le TTL une fois la situation stable.

Résultat attendu

Les deux familles d'adresses servent un contenu et des certificats identiques, la surveillance les affiche séparément, et aucune règle derrière la façade ne traite accidentellement les clients v6 différemment.

Limites et base de vérification

Le courrier électronique, SSH et d'autres services sur le même nom d'hôte reçoivent eux aussi un enregistrement AAAA et nécessitent la même vérification. L'ordre des étapes et le comportement des clients suivent les RFC et la documentation citées ; aucune part de trafic ni aucune latence n'est affirmée.