IPv6 fonctionne rarement à moitié : soit on ne le remarque pas, soit il génère des symptômes déroutants. Un service qui répond en IPv4 mais pas en IPv6, une adresse notée qui ne fonctionne plus la semaine suivante, un pare-feu qui semble ne pas s'appliquer.
Le réflexe est de tout désactiver. C'est un report de problème — et souvent une source de comportements incohérents supplémentaires.
La différence de fond : plus de traduction d'adresses
En IPv4 domestique, toutes vos machines partagent une adresse publique via la traduction d'adresses. Cette traduction n'a jamais été un dispositif de sécurité, mais elle en avait l'effet : sans redirection explicite, rien de l'extérieur ne peut initier une connexion vers vos machines.
En IPv6, ce mécanisme disparaît. Chaque machine reçoit une adresse publique directement routable. C'est un retour au modèle d'origine de l'internet, plus propre techniquement — mais la barrière implicite dont vous bénéficiiez sans le savoir n'existe plus.
La protection repose désormais entièrement sur le pare-feu. Et c'est là que le premier problème se pose.
Le pare-feu qui ne protège que la moitié
Les règles IPv4 et IPv6 sont distinctes. Beaucoup d'outils de configuration ne les appliquent pas automatiquement aux deux protocoles.
Le scénario typique : vous écrivez des règles, vous vérifiez qu'un port est bien fermé depuis l'extérieur, tout semble correct. Mais votre test est parti en IPv4, tandis que le service écoute et reste joignable en IPv6.
Une machine peut ainsi être directement accessible depuis l'internet alors que son équivalent IPv4 est parfaitement protégé.
Les adresses qui changent seules
Deuxième source de confusion : une machine possède normalement plusieurs adresses IPv6 simultanément.
Une adresse de lien local, utilisable uniquement sur le segment. Une ou plusieurs adresses globales construites à partir du préfixe annoncé. Et des adresses temporaires, renouvelées régulièrement pour les connexions sortantes, destinées à limiter le pistage.
Ce dernier mécanisme est voulu et souhaitable pour un poste client. Il est problématique pour un serveur : l'adresse que vous aviez relevée n'est plus valide quelques jours plus tard, et le service devient injoignable sans que rien n'ait changé en apparence.
Pour tout ce qui doit être joint, il faut une adresse stable — configurée explicitement, ou dérivée d'un identifiant qui ne varie pas — et c'est celle-là, et elle seule, qui doit figurer dans votre DNS.
Le préfixe qui bouge
Le problème est parfois plus haut. Certains fournisseurs d'accès ne délèguent pas de préfixe stable : à chaque renégociation, vous recevez un nouveau bloc d'adresses.
Tout le réseau est alors renuméroté. Les adresses changent, les règles de pare-feu écrites en dur ne correspondent plus, les entrées DNS pointent dans le vide.
Deux réponses possibles. Demander un préfixe fixe, quand l'offre le permet. Ou utiliser en interne des adresses locales uniques : un espace privé, stable, non routable sur l'internet, pour tout ce qui doit conserver une adresse constante. Vos services internes s'appuient dessus, la connectivité externe utilise le préfixe public — variable, mais sans conséquence puisque plus rien de critique n'en dépend.
La lenteur au démarrage des connexions
Symptôme fréquent et mal identifié : les connexions mettent quelques secondes à s'établir, puis fonctionnent normalement.
C'est la signature d'une IPv6 annoncée mais non fonctionnelle. Le client voit une adresse IPv6 disponible, la privilégie, tente la connexion, attend l'expiration du délai, puis bascule en IPv4.
Le mécanisme de bascule rapide des systèmes modernes réduit ce délai mais ne l'élimine pas. Et la cause est presque toujours une configuration incomplète : un préfixe annoncé sans route fonctionnelle, ou un pare-feu qui bloque les messages de contrôle nécessaires au protocole.
Le piège des messages de contrôle
Dernier point, et il mérite d'être souligné : en IPv6, les messages de contrôle ne sont pas optionnels.
La découverte des voisins, l'annonce des routeurs, la découverte de la taille maximale des paquets en dépendent entièrement. En IPv4, bloquer l'ICMP dégradait le fonctionnement ; en IPv6, cela casse le protocole.
Une règle de pare-feu qui rejette l'ICMPv6 en bloc produit des symptômes spectaculaires et difficiles à relier à leur cause : machines qui ne trouvent plus leur passerelle, connexions qui se figent sur les gros transferts, adresses qui ne se configurent plus.
La méthode de diagnostic
Dans l'ordre, en s'arrêtant au premier problème trouvé :
- La machine a-t-elle une adresse globale stable, ou seulement des adresses temporaires ?
- La passerelle répond-elle en IPv6 depuis cette machine ?
- Le pare-feu a-t-il des règles IPv6, et laisse-t-il passer les messages de contrôle ?
- Le service écoute-t-il réellement en IPv6, ou seulement sur l'adresse IPv4 ?
- Le DNS renvoie-t-il une adresse encore valide ?
Quatre fois sur cinq, la réponse se trouve aux points 1 ou 3. Et dans tous les cas, tester explicitement en IPv6 plutôt que de laisser le système choisir le protocole évite de conclure trop vite.
Commentaires