Résumé

  • Une adresse IPv6, une route BGP et un ping réussi ne prouvent pas qu’un paquet muni d’un en-tête Fragment, Destination Options, Hop-by-Hop ou Routing empruntera le même chemin. La capacité se mesure pour une direction, une chaîne, une taille et un instant donnés.
  • RFC 7872 et les travaux APNIC/RIPE ont observé des pertes importantes mais dépendantes de la méthode, du type, de la longueur, du serveur et de la population testée. Ces chiffres historiques justifient un protocole de mesure ; ils ne constituent pas le taux mondial de 2026.
  • L’opérateur du réseau, du pare-feu ou du service DDoS, et le constructeur du parseur, disposent du pouvoir pratique. La thèse est réfutable par une matrice multi-chemins ; le contrefactuel crédible est un profil borné, mesuré et périssable, non une obligation illimitée de traitement.

La ligne manquante du cahier des charges

L’en-tête de base IPv6 mesure 40 octets. Les informations optionnelles suivent dans une chaîne d’en-têtes, chaque champ Next Header désignant le suivant jusqu’au protocole de transport. Pour appliquer une ACL sur un port, un équipement doit trouver TCP ou UDP derrière cette chaîne.

Cette opération apparemment banale rencontre le matériel. Un ASIC possède un nombre fini d’étages et une fenêtre d’analyse fixe ; la voie logicielle et le processeur de contrôle ont également une capacité finie. Un paquet IPv6 simple peut rester à débit filaire tandis que le même flux, avec le transport placé 64 ou 128 octets plus loin, est ralenti, limité ou éliminé.

RFC 7045 demande aux nœuds de transfert de ne pas jeter un paquet pour la seule présence d’un en-tête standard et exige qu’un pare-feu qui les inspecte sache les traiter correctement. Il conserve la possibilité d’une politique volontaire. C’est une distinction honnête : une norme définit l’interopérabilité ; elle ne remplace pas le silicium d’une carte ancienne et n’administre pas le service anti-DDoS d’un tiers.

RFC 7112 impose que le premier fragment contienne toute la chaîne jusqu’à la couche supérieure. Le contrôle devient possible, pas nécessairement bon marché. RFC 9098 rappelle qu’en dehors de la MTU du chemin, il n’existe pas de profondeur universelle : qui veut voir la couche 4 doit parcourir la chaîne dans l’ordre. « Connectivité IPv6 » ne décrit donc pas toute la prestation.

Trois mesures, trois périmètres à ne pas mélanger

RFC 7872, publié en 2016, a testé des serveurs web, mail et DNS issus de World IPv6 Launch et d’Alexa Top 1M. Pour les serveurs web World IPv6 Launch, les pertes étaient de 11,88 % avec huit octets de Destination Options, 40,70 % avec huit octets Hop-by-Hop et 30,51 % dans la condition Fragment. Pour les serveurs web Alexa : 10,91 %, 39,03 % et 28,26 %. La condition Fragment des serveurs DNS Alexa atteignait 55,23 %.

La leçon solide est la variation. Le rôle de la destination et le type d’en-tête expliquaient une partie du résultat que la simple joignabilité IPv6 n’expliquait pas. Les valeurs ne sont ni contemporaines ni universelles ; listes, paquets, routes et période font partie de l’observation.

APNIC a ensuite mesuré depuis quelques serveurs vers des clients recrutés par publicité. Son rapport de 2022 décrit environ quatre millions d’essais quotidiens. En 2023, l’expérience variait Destination Options et Hop-by-Hop PadN sur 8, 16, 32, 64 et 128 octets, et la condition Fragment de 1 200 à 1 416 octets.

L’article APNIC de 2023 publiait environ 30 % de pertes Destination Options jusqu’à 64 octets et environ 55 % à 128 octets, après une variation inexpliquée d’environ 90 % à 55 % en avril 2023. Le même article APNIC indiquait que, du 27 avril au 15 mai, un serveur de l’Université d’Aberdeen avait produit 370 742 essais Hop-by-Hop pour un échantillon publicitaire britannique : 99,04 % de pertes au total, 98,25 % à 8 octets et 99,99 % à 128.

Un pourcentage proche de 100 ne localise pas automatiquement la panne. Les ASN d’accès différaient et les auteurs ne concluaient pas quel composant — hébergement, réseau virtuel, transit ou extrémité — avait rejeté. Le résultat confirme précisément qu’un seul taux ne suffit pas.

L’étude RIPE Atlas sur la taille des paquets fournit un contrôle voisin : environ 10 % des sondes IPv6 participantes présentaient un problème de fragmentation, mais près de 11 % perdaient déjà tous les essais à 100 octets. Selon la taille, environ 1 284 à 1 292 sondes participaient. RIPE indiquait que l’extrapolation au reste d’Internet restait inconnue. Tout test EH doit donc filtrer d’abord sur la réussite du paquet IPv6 témoin.

Le pouvoir tient dans le parseur

La documentation Cisco décrit, pour des plates-formes nommées, des ressources matérielles fixes, un exemple de chaîne de 64 octets traitée en matériel et un basculement logiciel au-delà lorsque des filtres de couche supérieure s’appliquent. Le guide Cisco IOS XR 7.1.1 pour NCS 5500 distingue les cartes : certaines gèrent des EH précisés en matériel ; d’autres conditions ne permettent pas le filtrage couche 4 d’un trafic avec EH.

Juniper expose des critères extension-headers et des limites de plate-forme. Sur une surface IDS, l’absence de règle allow-ipv6-extension-header bloque par défaut tout paquet contenant un EH. Nokia expose ipv6-eh max et limited ; la version citée examine jusqu’à six en-têtes pour certains critères.

Ce ne sont pas des parts de marché ni un classement. Ce sont des preuves que profondeur, types reconnus, défauts, compteurs et voie rapide sont des attributs de produit. Le client d’un cloud achète parfois cette politique sans même connaître le châssis.

La sécurité impose une vraie limite. RFC 8504 autorise des plafonds de longueur, nombre d’en-têtes, nombre d’options et chaîne agrégée. RFC 8883 définit des erreurs ICMPv6 pour en-tête trop grand, chaîne trop longue ou trop d’éléments. RFC 9288 précise le filtrage en transit. RFC 9673 a actualisé en 2024 le traitement Hop-by-Hop pour permettre un traitement sélectif. RFC 9740 ajoute en 2025 des champs IPFIX pour le type, le nombre, la longueur de chaîne et l’exhaustivité de l’export. RFC 9805 déprécie Router Alert pour les nouveaux protocoles.

Définir une erreur ne prouve pas son déploiement ni son retour jusqu’à la source. L’alternative réaliste à la perte silencieuse est une limite déclarée et observable, pas un droit à un processeur infini.

Le test qui peut invalider la tendance

Pendant 90 jours, tester au moins trois familles d’accès, trois de transit, trois de cloud/DDoS ; trois familles de silicium routeur, trois pare-feu et trois piles hôtes ; 100 couples de chemins indépendants par famille de service. Comparer témoin IPv6, Fragment, Destination Options, Hop-by-Hop et Routing/SRH.

Varier 8, 16, 32, 64 et 128 octets EH agrégés, ordre recommandé et autre ordre valide, TCP, UDP et UDP de type QUIC, paquets de 256, 1 200 et 1 400 octets, 100 essais par cellule. Mesurer livraison, perte silencieuse, latence p95, débit, ICMP, voie lente et CPU contrôlé.

Rejeter la thèse seulement si toutes les cellules valides restent à 0,1 point de livraison du témoin ; au plus une perte silencieuse EH sur 100 000 ; latence et débit à 2 % ; CPU à moins de cinq points ; aucune rupture de voie jusqu’à 128 octets ; et 99,9 % des dépassements intentionnels reçoivent l’erreur RFC 8883 attendue. Type, octets, ordre, équipement et politique ne doivent rien expliquer au-delà de la joignabilité ordinaire, tandis que de nouveaux usages progressent sans tunnel, liste blanche, sonde ou remplacement.

La tendance se renforce si un EH valide de 8 octets crée plus de cinq points d’écart sur 10 % des chemins, si 64 à 128 octets produit une rupture reproductible, si p95 augmente de 25 %, le débit baisse de 20 %, le CPU monte de 15 points, plus de la moitié des rejets n’émettent aucun ICMP utile, ou si seul le changement d’équipement, firmware, DDoS ou chemin change l’issue. Ces seuils sont prospectifs.

L’allocation n’est pas une garantie de traitement

Une allocation IPv6 prouve unicité et inscription. Une route BGP prouve une visibilité de contrôle. Ni l’une ni l’autre n’achète la compatibilité optionnelle de toute la chaîne de fournisseurs. Le détenteur doit séparer quantité d’adresses, visibilité de route, joignabilité simple et capacité EH.

Il faut demander les types et limites, la voie rapide/lente, le défaut du pare-feu, les compteurs RFC 8883 et la date d’expiration après changement de firmware, châssis, cloud ou politique. Tester dans les deux sens. Un SLA « IPv6 » peut être exact tout en restant muet sur l’usage réel.

IANA attribue des identifiants, l’IETF formalise syntaxe et comportement, les RIR enregistrent les ressources. Aucun n’exploite le parseur du transit. À l’inverse, le boîtier intermédiaire détient un pouvoir pratique, pas un mandat mondial. La légitimité opérationnelle exige une mesure proportionnée, explicite, diagnostiquable et remplaçable.

Le verrouillage est circulaire : les applications évitent les EH incertains ; le faible trafic décourage le silicium ; le silicium maintient l’incertitude. Un tunnel ou un domaine SRv6 fermé résout parfois le transport, mais remplace le verrou par un contrôleur et un fournisseur.