La plupart des sites fonctionnent désormais en dual-stack. Le même serveur, API ou page de paiement répond simultanément en IPv4 et en IPv6. Cette configuration vous rend accessible alors que les adresses IPv4 se font rares, mais elle répartit également votre trafic sur deux réseaux qui peuvent tomber en panne indépendamment.
Voici le problème que cela crée. Si votre surveillance ne teste que via IPv4, elle affiche du vert alors que les utilisateurs natifs IPv6 rencontrent une passerelle morte, un enregistrement DNS manquant ou une règle de pare-feu jamais mise à jour. Le tableau de bord indique 100 % de disponibilité. Une part croissante de votre audience affirme que le site est en panne.
Cet article explique comment Dotcom-Monitor teste le chemin IPv6 selon ses propres termes : des nœuds natifs IPv6-only sans tunnel, des scripts de navigateur qui chargent chaque ressource tierce via IPv6, et des contrôles de protocole qui isolent une défaillance IPv6 tandis que le chemin IPv4 reste sain.
Qu’est-ce que la surveillance IPv6 ?
La surveillance IPv6 consiste à tester si votre site web, API et services répondent correctement en IPv6, du point de vue d’un véritable utilisateur IPv6 natif. Elle effectue les mêmes vérifications de disponibilité et de performance que vous utilisez déjà en IPv4 — résolution DNS, chargement de pages, transactions et réponses de protocole — mais sur le chemin IPv6, qui dispose de ses propres enregistrements DNS, routes et règles de pare-feu.
Sur un site dual-stack qui sert les deux protocoles, la surveillance IPv6 est la seule façon de confirmer que la partie IPv6 fonctionne. Un test IPv4 réussit que l’IPv6 soit sain ou non, donc sans test dédié de surveillance réseau IPv6, une panne touchant uniquement les utilisateurs IPv6 reste invisible. Les sections ci-dessous montrent comment Dotcom-Monitor effectue ce test depuis des nœuds natifs IPv6-only, couvrant la disponibilité, les transactions, DNS et contrôles de protocole sur les deux plans.
Pourquoi les réseaux dual-stack créent un angle mort dans la surveillance
Un service dual-stack répond sur deux protocoles, mais IPv4 et IPv6 ne partagent pas un même chemin. Ce sont deux plans de routage. Le trafic se résout via différents enregistrements DNS, traverse différentes règles de pare-feu et transite par différents fournisseurs avant d’atteindre la même origine.
Ainsi, une requête peut réussir sur un plan et échouer sur l’autre. Le client IPv4 résout votre enregistrement A, franchit un pare-feu IPv4 configuré depuis des années par votre équipe, et charge la page. Le client IPv6 résout votre enregistrement AAAA, tombe sur une passerelle jamais complètement configurée, et expire. Les deux utilisateurs ont tapé la même URL. L’un pense que votre site est en panne.
Les deux plans diffèrent aussi en technologie. IPv6 utilise un en-tête de base fixe de 40 octets, un champ Traffic Class de 8 bits et un Flow Label de 20 bits, donc les routeurs transit traitent les paquets IPv6 différemment du modèle IPv4 best-effort qu’ils ont supporté pendant des décennies. Et un seul sous-réseau IPv6 contient bien plus d’adresses que tout l’internet IPv4 legacy, ce qui modifie la propagation des routes et l’application des filtres. L’essentiel pour la surveillance est simple : un résultat IPv4 ne vous renseigne pas de façon fiable sur le chemin IPv6. Vous devez tester chacun sur son propre terrain.
Comment Dotcom-Monitor réalise une surveillance native IPv6-only
Dotcom-Monitor exécute ses contrôles depuis un réseau mondial de surveillance constitué de nœuds sur de véritables backbones IPv4 et IPv6. Certains de ces nœuds sont dual-stack et peuvent atteindre une cible via l’un ou l’autre protocole. D’autres sont uniquement IPv6.
Les localisations IPv6-only sont la partie importante ici, à cause de ce qu’elles refusent de faire. Une grande partie des équipements réseau qui supportent IPv6 peuvent aussi retranscrire le trafic en IPv4 via des mécanismes de transition comme le tunneling 6to4 ou NAT64. Cette traduction est pratique en production mais trompeuse en test. Un agent dual-stack peut rapporter un résultat propre tout en retombant silencieusement sur IPv4, ce qui masque la défaillance exacte que vous cherchez à détecter.
Un nœud IPv6-only n’utilise aucune traduction. Il n’envoie et ne reçoit que du IPv6. Lorsqu’un contrôle réussit depuis ce nœud, la cible a réellement répondu en IPv6 natif. Lorsqu’il échoue, vous avez détecté une vraie panne IPv6 au lieu d’un report de secours.
Exécuter le même contrôle depuis un nœud natif IPv4 et un nœud natif IPv6-only vous donne un préalable et un postérieur clairs pour chaque plan. Tout écart entre les deux résultats est un problème spécifique à IPv6, et non un bruit de mesure.
Cette base de référence fractionnée fonctionne sur tous les types d’appareils de la plateforme. La surveillance Web Applications pilote un véritable navigateur via une transaction scriptée. La surveillance Web Pages charge une page unique de la même manière. La surveillance Internet Infrastructure exécute des vérifications de protocole contre vos serveurs. Et la surveillance Web Services valide vos API. Chacun peut être assigné à des localisations IPv6-only, et les deux appareils navigateur enregistrent avec l’outil de script EveryStep, afin que vous capturiez un chemin une fois et le rejouiez depuis n’importe quel nœud.
Détecter les fantômes AAAA tiers avec une surveillance en vrai navigateur
Votre origine peut supporter parfaitement IPv6 et vos pages peuvent quand même se casser pour les utilisateurs IPv6. La raison est tout ce que vous n’hébergez pas. Une page moderne fait appel à un CDN, des polices web, une balise d’analyse, un widget de chat et un processeur de paiement. Lorsqu’un utilisateur IPv6-only charge cette page, le navigateur tente de récupérer chacun de ces éléments aussi via IPv6.
Si un tiers n’a jamais publié d’enregistrement AAAA ou laisse tomber les paquets IPv6, le navigateur reste bloqué sur cet élément. Il attend que la connexion expire et peut retenir le reste du rendu en attendant. Le résultat visible est une page à moitié chargée : navigation manquante, cadres d’éléments vides, bouton de paiement inopérant. Votre tableau de bord interne de santé reste vert tout le temps, car votre origine est correcte. La panne est dans le réseau de quelqu’un d’autre.
La surveillance Web Applications capture ce phénomène en chargeant la page complète dans un véritable navigateur depuis un nœud IPv6-only et en enregistrant chaque requête dans la cascade. Pour une page unique plutôt qu’une transaction complète, la surveillance Web Pages fonctionne pareillement. Au lieu d’un simple succès/échec, vous voyez quel élément a résolu, lequel a expiré, et où le rendu s’est bloqué. Le tableau ci-dessous montre le modèle qu’elle révèle.
| Profil de test | HTML principal | CDN et ressources médias | Scripts tiers | Ce que voit l’utilisateur |
|---|---|---|---|---|
| Surveillance IPv4 | Résout (enregistrement A) | Résout | Résout | La page complète se charge normalement. |
| Surveillance IPv6-only | Résout (enregistrement AAAA) | Échec de résolution | Expiration | Chargement partiel : mise en page cassée, cadres vides, paiement bloqué. |
Prenons un flux de paiement en exemple. Un script Web Applications se connecte, ajoute un article, et arrive à l’étape du paiement. En IPv4, toute la séquence réussit. Depuis le nœud IPv6-only, le script du processeur de paiement n’a pas d’enregistrement AAAA, donc le navigateur se bloque avant que le formulaire soit utilisable. Le script échoue à cette étape et vous indique quel élément en est la cause. Un ping de disponibilité sur votre propre domaine n’aurait jamais détecté ce problème de paiement. Script la transaction avec la surveillance synthétique transforme un « site en ligne » en « clients pouvant réellement payer ».
Comment la surveillance Internet Infrastructure isole les échecs de protocole IPv6
Les contrôles navigateur capturent ce que voient les utilisateurs. Vous avez aussi besoin de la couche en dessous. La surveillance Internet Infrastructure exécute des vérifications au niveau protocole contre vos serveurs, aussi souvent qu’une fois par minute, et depuis des localisations IPv6-only de la même façon que les appareils navigateur.
Cette fréquence et cette isolation sont la partie utile. Si votre point de terminaison HTTP/S ou DNS répond en IPv4 mais échoue en IPv6, la surveillance Internet Infrastructure rapporte l’erreur protocole IPv6 isolément au lieu de l’effacer dans la moyenne avec le résultat IPv4 sain. La surveillance Web Services fait de même pour vos points d’API. Vous recevez une alerte qui nomme le protocole et le chemin, pas un vague « temps de réponse en hausse ».
Le DNS mérite une vérification dédiée. Un site dual-stack nécessite un enregistrement A et un enregistrement AAAA résolus globalement à la même vitesse, et un enregistrement AAAA périmé ou manquant est l’une des pannes IPv6 les plus courantes. La surveillance DNS confirme que les deux enregistrements répondent partout et surveille les valeurs TTL pour qu’un changement de routage lors d’une migration ne bloque pas les utilisateurs IPv6 sur une entrée morte. Lorsqu’une alerte se déclenche, un traceroute IPv6 automatique indique si la panne se situe sur votre origine ou dans une table de routage d’un fournisseur transit en amont.
Comment Dotcom-Monitor révèle la latence Happy Eyeballs
Certains problèmes IPv6 ne se manifestent jamais par une panne. Ils se manifestent par un site lent sans cause identifiable. La cause est souvent Happy Eyeballs.
Happy Eyeballs (RFC 8305) est un secours du navigateur. Le navigateur commence d’abord la connexion IPv6, puis attend un court intervalle (le délai de tentative de connexion, environ 250 millisecondes par défaut) avant de lancer aussi une course IPv4. Si le chemin IPv6 est cassé ou lent, la tentative IPv4 gagne et porte la requête. La connexion réussit toujours, donc l’utilisateur voit rarement une erreur.
C’est bon pour l’utilisateur et mauvais pour votre visibilité. L’attente avant que le navigateur abandonne IPv6 et bascule sur IPv4 s’ajoute au vrai Temps jusqu’au Premier Octet et au Largest Contentful Paint. Chaque utilisateur IPv6 paie une taxe de latence sur une connexion qui finit par marcher en IPv4. Les outils passifs et l’analytique utilisateurs réels enregistrent un chargement réussi et poursuivent, donc la faute structurelle reste invisible tandis que l’expérience se dégrade silencieusement.
La surveillance native IPv6-only mesure directement cette taxe, car il n’y a pas de secours disponible pour s’en cacher. Le chemin IPv6 fonctionne ou pas, et le chiffre apparaît dans le rapport. Les rapports en cascade côte à côte affichent les temps IPv4 et IPv6 côte à côte, donc un écart de 250 millisecondes que les utilisateurs perçoivent mais ne peuvent décrire devient une ligne pointable. Si vous souhaitez un rappel sur la lecture de ces graphiques, consultez notre guide sur les graphiques en cascade.
Comment configurer la surveillance dual-stack dans Dotcom-Monitor
Voici la configuration qui vous donne les deux plans sans doubler la charge de maintenance.
- Étape 1 : Construisez le contrôle une seule fois dans EveryStep. Enregistrez votre chemin critique ou contrôle de protocole une seule fois. Le même script EveryStep s’exécute sur tous les sites, donc vous ne maintenez pas de versions IPv4 et IPv6 séparées.
- Étape 2 : Assignez des localisations natives IPv4 et IPv6-only. Ajoutez le contrôle à la fois sur un nœud natif IPv4 et un nœud IPv6-only. Évitez les localisations 6to4 et NAT64 pour la base IPv6 afin qu’aucune traduction ne se situe entre le nœud et votre cible.
- Étape 3 : Réglez la fréquence des contrôles. Exécutez les contrôles de protocole Internet Infrastructure jusqu’à une fois par minute. Planifiez les contrôles navigateur Web Applications selon l’intervalle défini par votre SLA.
- Étape 4 : Ajoutez des contrôles DNS pour les enregistrements A et AAAA. Confirmez que les deux enregistrements se résolvent globalement à la même vitesse, et surveillez les valeurs TTL afin qu’une migration ne bloque pas les utilisateurs IPv6 sur une route périmée.
- Étape 5 : Déclenchez un traceroute IPv6 en cas de déviation. Programmez des alertes qui lancent un traceroute dès que la disponibilité ou le temps de réponse baisse, pour que vous puissiez immédiatement différencier une panne d’origine d’une panne chez un transit en amont.
- Étape 6 : Comparez les deux cascades. Examinez les rapports IPv4 et IPv6 côte à côte. Tout élément, saut ou protocole différent entre eux est votre problème spécifique à IPv6.
Le résumé
Dual-stack signifie que chaque requête a deux voies pour vous joindre et deux façons de tomber en panne. La surveillance uniquement IPv4 en surveille une seule et rapporte sur les deux, ce qui explique comment un site peut avoir un taux de disponibilité parfait alors que les utilisateurs IPv6 obtiennent des expirations, des pages à moitié chargées et une pénalité de latence que personne ne peut tracer.
Dotcom-Monitor comble ce fossé en testant le chemin IPv6 selon ses propres termes. Des nœuds natifs IPv6-only sans tunnel, des scripts navigateur Web Applications qui chargent chaque ressource tierce en IPv6, des contrôles de protocole Internet Infrastructure jusqu’à une fois par minute, et des cascades côte à côte qui distinguent une panne d’origine d’une panne en amont. Vous arrêtez de deviner pour la moitié de votre trafic qui n’a jamais été touchée par les contrôles IPv4.
Testez votre chemin IPv6 avant vos utilisateurs
Déployez des nœuds de surveillance natifs IPv6-only et voyez exactement ce que vivent vos utilisateurs dual-stack, jusqu’à la ressource tierce. Commencez un essai gratuit de 30 jours avec Dotcom-Monitor.
