Test NTP IPv6
Validateur Dual-Stack & Audit AAAA
Vérifier la joignabilité NTP en IPv6 — avec preuves NIS 2 et ISO 27001
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)) 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-pool.rdem-systems.com +short
2a02:2178:3:24::3
$ dig AAAA time.cloudflare.com +short
2606:4700:f1::1
2606:4700:f1::123
$ dig AAAA time.nist.gov +short
2610:20:6f15:15::27Une 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-pool.rdem-systems.com iburst nts4. Comment tester NTP IPv6 (CLI et navigateur)
Depuis le navigateur
Pour un serveur public, le validateur teste directement IPv4 et IPv6, par le nom. Pour un serveur interne, utilisez le mode Bridge avec une cible IPv6 ([2a02:2178:3:24::3] 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-pool.rdem-systems.com
server 2a02:2178:3:24::3, stratum 2, offset +0.000412, delay 0.01912
$ sntp -6 ntp-pool.rdem-systems.com
+0.000412 +/- 0.001243 ntp-pool.rdem-systems.com 2a02:2178:3:24::3 s2 no-leapConfiguration chrony explicite par famille
# /etc/chrony/chrony.conf
# Forcer l'interrogation IPv6 uniquement
server ntp-pool.rdem-systems.com iburst family ipv6
# Dual-stack avec préférence
pool 2.pool.ntp.org iburstWindows — w32tm
> w32tm /monitor /computers:ntp-pool.rdem-systems.com
ntp-pool.rdem-systems.com[2a02:2178:3:24::3:123]:
ICMP: 12ms delay
NTP: -0.0002341s offset from local clock
RefID: 'GNSS' [0x53534E47]
Stratum: 15. 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-pool.rdem-systems.com
+0.000398 +/- 0.001200 ntp-pool.rdem-systems.com 45.13.156.18 s2 no-leap
$ sntp -6 ntp-pool.rdem-systems.com
+0.000412 +/- 0.001243 ntp-pool.rdem-systems.com 2a02:2178:3:24::3 s2 no-leap
# Écart d'offset : 0.014 ms — dans le bruit de mesure, sain
# Écart de RTD : 0.043 ms — sain6. Sources NTP dual-stack fiables (avril 2026)
| Source | IPv4 | IPv6 | NTS | Strate |
|---|---|---|---|---|
ntp-pool.rdem-systems.com | ✓ | ✓ | ✓ | 2 |
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-pool.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 :
- Log de résolution AAAA — sortie de
dig AAAAsur chaque source configurée, datée, archivée. - Log d'interrogation par famille — sortie de chrony sources montrant A et AAAA pour au moins une source commune.
- 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.
- 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