Test NTP IPv6
Validateur Dual-Stack & Audit AAAA

Publié le 20 avril 2026 · Mis à jour le 12 mai 2026 · Par Richard DEMONGEOT, RDEM Systems · Audience : DevOps, architectes réseau, RSSI validant le déploiement IPv6 contre les exigences de synchronisation temporelle.

1. Pourquoi NTP sur IPv6 compte en 2026

Le déploiement IPv6 a franchi le seuil majoritaire chez les principaux FAI européens (Orange, Proximus, Deutsche Telekom tous au-dessus de 60 %). Les réseaux internes qui portent IPv6 en production mais retombent en IPv4 pour NTP créent deux problèmes simultanément :

• Opérationnel : une règle firewall ou un changement de routage IPv6-seul peut couper silencieusement la synchronisation temporelle d'un sous-réseau — souvent détecté seulement lorsque Kerberos échoue.
• Audit : un auditeur NIS 2 lisant le contrôle supply-chain TIC (art. 21(2)(d)(e)) attend que la couche temporelle suive les mêmes garanties de disponibilité et d'authentification que le reste de la stack. « Nous avons IPv6 mais notre NTP est IPv4-seul » est un écart documenté.

2. Résolution AAAA : ce que retourne le DNS

Avant que NTP ne parle IPv6, le résolveur doit retourner un enregistrement AAAA. Vérifiez avec dig :

$ dig AAAA ntp.rdem-systems.com +short
2a01:e0a:4bc:5110::1

$ dig AAAA time.cloudflare.com +short
2606:4700:f1::1
2606:4700:f1::123

$ dig AAAA time.nist.gov +short
2610:20:6f15:15::27

Une réponse vide signifie que l'opérateur n'a pas publié d'AAAA — vous devez choisir une autre source pour le dual-stack. time.ntsc.ac.cn, par exemple, est IPv4-seul en avril 2026.

3. pool.ntp.org et IPv6 — l'astuce des sous-zones

La zone globale pool.ntp.org retourne des A et AAAA mélangés, pondérés par le pourcentage de serveurs volontaires dans chaque famille. Comme les serveurs IPv4 dépassent IPv6 d'environ 3 pour 1, un client interrogeant pool.ntp.org reçoit souvent quatre A et aucun AAAA — comportement effectivement IPv4-seul.

Le contournement est la structure statistique des sous-zones :

Zone	Probabilité AAAA	Recommandé pour
0.pool.ntp.org	Très faible (~5 %)	Clients IPv4 legacy
1.pool.ntp.org	Faible (~10 %)	Majoritairement IPv4
2.pool.ntp.org	Élevée (~70 %)	Clients IPv6-preferred
3.pool.ntp.org	Élevée (~70 %)	Clients IPv6-preferred

Bonne pratique de configuration chrony/ntpd dual-stack :

# Privilégier IPv6 quand disponible
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# Ancres dual-stack explicites (AAAA garanti)
server time.cloudflare.com iburst nts
server ntp.rdem-systems.com iburst nts

4. Comment tester NTP IPv6 (CLI et navigateur)

Depuis le navigateur

Utilisez le Validateur de Conformité en mode Bridge avec une cible IPv6 ([2a01:e0a:4bc:5110::1] ou le hostname sur un réseau IPv6-seul en sortie). Le bridge relaie le paquet NTPv4 via votre processus Node.js local : la résolution DNS et le routage reflètent la stack réseau réelle de votre poste.

Linux — sonde forcée v6

$ ntpdate -q -6 ntp.rdem-systems.com
server 2a01:e0a:4bc:5110::1, stratum 1, offset +0.000412, delay 0.01912

$ sntp -6 ntp.rdem-systems.com
+0.000412 +/- 0.001243 ntp.rdem-systems.com 2a01:e0a:4bc:5110::1 s1 no-leap

Configuration chrony explicite par famille

# /etc/chrony/chrony.conf
# Forcer l'interrogation IPv6 uniquement
server ntp.rdem-systems.com iburst family ipv6
# Dual-stack avec préférence
pool 2.pool.ntp.org iburst

Windows — w32tm

> w32tm /monitor /computers:ntp.rdem-systems.com
ntp.rdem-systems.com[2a01:e0a:4bc:5110::1:123]:
    ICMP: 12ms delay
    NTP: -0.0002341s offset from local clock
    RefID: 'GNSS' [0x53534E47]
    Stratum: 1

5. Comparatif offset v4 vs v6

Sondez le même nom d'hôte sur les deux familles et comparez. Une source dual-stack bien opérée affiche un offset quasi-identique et une variance de RTD sous 5 ms :

$ sntp -4 ntp.rdem-systems.com
+0.000398 +/- 0.001200 ntp.rdem-systems.com 51.159.173.61 s1 no-leap

$ sntp -6 ntp.rdem-systems.com
+0.000412 +/- 0.001243 ntp.rdem-systems.com 2a01:e0a:4bc:5110::1 s1 no-leap

# Écart d'offset : 0.014 ms  — dans le bruit de mesure, sain
# Écart de RTD : 0.043 ms    — sain

6. Sources NTP dual-stack fiables (avril 2026)

Source	IPv4	IPv6	NTS	Strate
ntp.rdem-systems.com	✓	✓	✓	1
time.cloudflare.com	✓	✓	✓	3 (anycast)
time.google.com	✓	✓	—	1 (leap-smeared)
time.nist.gov	✓	✓	—	1
ntp1.ptb.de	✓	✓	—	1
nts.netnod.se	✓	✓	✓	1
2.pool.ntp.org	✓	✓ (70 %)	—	Variable

Pour des configurations de qualité audit, préférez trois sources full dual-stack + NTS : par exemple ntp.rdem-systems.com, time.cloudflare.com, nts.netnod.se.

7. Preuves dual-stack pour NIS 2 / ISO 27001

Les auditeurs demanderont : la synchronisation temporelle de l'entité essentielle/importante peut-elle continuer si le chemin v4 ou v6 est dégradé ? Le dossier de preuves :

1. Log de résolution AAAA — sortie de dig AAAA sur chaque source configurée, datée, archivée.
2. Log d'interrogation par famille — sortie de chrony sources montrant A et AAAA pour au moins une source commune.
3. Test de bascule mono-famille — procédure documentée coupant v4 (ou v6) au firewall et confirmant que l'horloge reste synchronisée via l'autre famille sous 2 minutes.
4. Enregistrement de change-management — toute modification NTP ticketée en parallèle du changement de routage ou firewall correspondant.

Références croisées : notre page exigences NIS 2 NTP liste ce point dans la checklist des 10 contrôles, et la checklist d'audit complète développe l'argument de diversification supply-chain. Pour l'alignement contrôle par contrôle, voir ISO 27001 Annexe A.8.17, PCI-DSS Exigence 10.6 et le référentiel ANSSI / OIV.

Votre besoin n'est pas l'audit ? Utilisez l'outil adapté :

• Mesurer jitter, offset, latence → ntp-tester.eu
• Diagnostiquer firewall / port 123 / démon → check-ntp.net
• Architecture de référence entreprise → ntp.rdem-systems.com