Résumé

  • RFC 7872 rapporte des taux de perte pour trois constructions de sondes précises, vers des ensembles historiques de serveurs web, mail et DNS. Ces chiffres ne constituent pas un taux mondial valable en 2026.
  • La localisation reposait sur des traceroute appariés et produisait une fourchette d’attribution hors AS de destination. Elle ne permettait de conclure ni à l’intention d’un opérateur, ni à la conformité d’un fournisseur, ni à une cause unique.

La destination ne contrôle pas nécessairement son chemin

Le problème observé par RFC 7872 ne se limite pas à la compatibilité d’un serveur. Si un réseau de transit supprime un paquet porteur d’un en-tête d’extension, le destinataire ne peut pas choisir d’accepter ce paquet, même s’il maîtrise entièrement son propre réseau. La décision exécutable se situe alors en amont de la partie qui voulait employer la fonction.

Mais les chiffres doivent rester à leur date. Le RFC, publié en juin 2016 avec le statut Informational, décrit des mesures réalisées en août 2014 puis répétées en juin 2015 avec des résultats comparables. Une mise à jour ultérieure de la page du document n’est pas une nouvelle campagne de mesures.

Deux listes de domaines ont servi de point de départ : World IPv6 Launch et Alexa Top 1 Million. Les auteurs en ont extrait des adresses de serveurs web par AAAA, de serveurs mail par MX puis AAAA, et de serveurs de noms par NS puis AAAA. Ils ont éliminé les doublons, les adresses qui n’étaient pas global unicast et celles considérées comme injoignables.

Trois paquets expérimentaux furent utilisés. DO8 comportait huit octets de Destination Options, complétés par PadN. HBH8 faisait de même avec Hop-by-Hop Options. FH512 produisait environ deux fragments IPv6 de 512 octets. Le transport était toujours TCP et le port correspondait au service visé.

Cette définition interdit un raccourci fréquent : l’étude ne teste pas « tous les en-têtes d’extension ». Elle ne couvre ni toutes les options, ni tous les ordres d’en-têtes, transports, tailles, politiques, chemins ou régions. Elle mesure la réponse à trois formes de paquets dans un univers d’échantillonnage déterminé.

Le pourcentage entre parenthèses a un autre dénominateur

Chaque cellule donne d’abord le taux de perte observé. La fourchette entre parenthèses estime ensuite, parmi les seuls paquets perdus, la part abandonnée dans un AS différent de l’AS de destination. Confondre ces deux dénominateurs transforme l’expérience en une affirmation qu’elle n’a jamais faite.

Pour les serveurs web issus de World IPv6 Launch, DO8 affiche 11,88 % de perte ; la fourchette 17,60 % / 20,80 % concerne la part non attribuée à l’AS de destination parmi ces pertes. HBH8 atteint 40,70 %, avec 31,43 % / 40,00 % hors destination. FH512 atteint 30,51 %, avec 5,08 % / 6,78 %.

Sur les trois services de cette même source, DO8 varie de 11,88 % à 17,07 %, HBH8 de 40,70 % à 48,86 % et FH512 de 30,51 % à 39,17 %. Dans les ensembles issus d’Alexa, les plages sont respectivement 10,91–21,33 %, 39,03–54,12 % et 28,26–55,23 %.

L’attribution varie davantage encore. Parmi les pertes de l’ensemble web Alexa, la part estimée hors destination est de 46,52 % / 53,23 % pour DO8 et de 53,64 % / 61,43 % pour FH512. Pour HBH8 vers les serveurs de noms Alexa, elle atteint 50,64 % / 81,00 %. À l’inverse, FH512 vers les serveurs mail World IPv6 Launch donne seulement 2,91 % / 12,73 %.

Il n’existe donc pas un chiffre honnête qui résumerait à lui seul le comportement des en-têtes d’extension. La source de l’échantillon, le service, le paquet et la localisation présumée modifient le résultat.

Localiser un saut n’est pas identifier un décideur

La méthode compare un traceroute avec en-tête d’extension et un traceroute témoin. Le dernier nœud répondant dans le premier est nommé M; le nœud suivant est M+1. Si le filtrage précède la décision de transfert, le point de chute est supposé être M+1. S’il vient après, ce peut être M. L’analyse retient la première hypothèse.

Elle suppose aussi que les deux traceroute suivent le même chemin, ce que le RFC dit ne pas pouvoir garantir. Un changement de route ou de répartition de charge suffit à déplacer la frontière apparente.

Puis vient le passage de l’adresse à l’organisation. Sur un lien de peering, l’adresse peut provenir de l’un ou l’autre pair. À un IXP, elle peut appartenir à l’exchange. L’organisation qui exploite le nœud peut correspondre à l’AS de M+1 ou à celui qui suit. Enfin, une même organisation peut exploiter plusieurs ASN, alors que le modèle de l’étude les sépare.

La borne basse affecte les cas ambigus à la destination ; la borne haute les affecte à un autre AS. Cette fourchette documente une limite de connaissance. Elle ne donne pas le droit de nommer un responsable précis.

La politique, le défaut et le bogue restent confondus

RFC 7872 indique explicitement qu’une perte observée peut résulter d’une politique voulue, d’un mauvais réglage par défaut, d’un équipement défectueux ou d’une autre condition. L’expérience ne départage pas ces causes.

Des RFC plus récents éclairent les mécanismes. RFC 9098 décrit les difficultés de profondeur d’analyse, de chemin lent, de ressources et d’évasion. RFC 9288 formule des recommandations de filtrage en transit qui dépendent des capacités des équipements. RFC 9673 encadre plus tard le traitement de Hop-by-Hop Options. Ce sont des explications et des orientations, pas une autopsie des sondes de 2014.

De même, RFC 7045 expose des comportements de transfert recommandés et RFC 8200 définit IPv6. Aucun ne prouve ce qu’un appareil donné faisait sur un chemin mesuré. Il faut distinguer trois phrases : la sonde n’a pas obtenu la réponse témoin ; la perte semble commencer près d’une frontière sous certaines hypothèses ; tel opérateur filtre intentionnellement. Seules les deux premières peuvent découler, avec des degrés différents, de cette expérience.

Refaire la preuve pour le service réel

Une décision actuelle commence par la description exacte du paquet : chaîne et ordre des en-têtes, options, longueurs, transport, ports, taille et fragmentation. Elle associe à chaque sonde un témoin sans en-tête d’extension, vers les mêmes extrémités et dans la même fenêtre temporelle, depuis plusieurs points autorisés.

Il faut conserver les octets envoyés, les horodatages, les réponses, les observations de route et les états de routage. Quand les extrémités sont contrôlées, captures et compteurs renforcent le diagnostic. Les traceroute appariés restent utiles, à condition de publier les hypothèses sur le chemin et l’ordre filtrage/transfert.

Les résultats doivent être séparés par construction et, si possible, par client, pair, transit, exchange et destination. Un changement BGP, logiciel, matériel ou de politique déclenche une nouvelle mesure. Avant d’attribuer la responsabilité, on transmet les éléments de paquet à l’opérateur concerné pour reproduction.

La conclusion défendable sera locale : ce paquet, pour ce service, depuis ces sources, sur ces chemins et pendant cette période. C’est assez pour choisir un déploiement, une solution de repli ou une escalade ; ce n’est pas un verdict sur l’Internet entier.