Résumé

  • Le RFC 5180 ne délivre pas une propriété universelle appelée « performance IPv6 ». Il organise une expérience reproductible dont les tailles de trame, les destinations, les préfixes, les voisins, la direction, les filtres et la version du matériel bornent la conclusion.
  • L’essai Hop-by-Hop rend cette limite visible : charges de 1 %, 10 % et 50 %, télémétrie des ressources et objectif d’impact de traitement. Depuis le RFC 8200, la configuration explicite du nœud doit aussi figurer dans la preuve.

Deux laboratoires annoncent le même débit. Le premier envoie de grandes trames vers une seule destination, sur un port, sans filtre. Le second mélange les tailles, distribue les destinations, active plusieurs ports et force l’inspection au-delà d’une chaîne d’en-têtes. L’égalité des nombres ne signifie pas l’égalité des machines exécutées.

Cette différence relève de la métrologie, pas du goût rédactionnel. Une mesure est un triplet : grandeur observée, instrument configuré et incertitude maîtrisée. En 2008, le RFC 5180 a appliqué cette discipline aux équipements IPv6. Ce document informatif complète le RFC 2544 et reprend le vocabulaire du RFC 1242. Il demande répétabilité, examen de la variance et prudence statistique lorsque le nombre d’essais est faible.

Le titre du rapport n’est donc jamais la preuve complète. « Conforme au RFC 5180 » indique au mieux une famille de procédures. Il reste à montrer lesquelles ont été exécutées, sur quelle version, avec quelles entrées et quels résultats bruts.

La série de trames est une courbe, pas une case à cocher

Pour Ethernet, le RFC propose 64, 128, 256, 512, 1024, 1280 et 1518 octets. À débit binaire égal, une petite trame multiplie les décisions par seconde. Une grande trame peut afficher un débit flatteur tout en évitant la limite de traitement par paquet. Inversement, la plus petite trame ne représente pas nécessairement le trafic utile d’un opérateur.

La donnée responsable est donc une série accompagnée du profil de trafic visé. Le support physique compte aussi. Les maxima Ethernet sont théoriques et la méthode rappelle une tolérance d’horloge de plus ou moins 100 parties par million. Sur Packet over SONET, le bourrage de bits peut modifier le débit de trames. Ajouter deux décimales au graphique ne supprime pas ces hypothèses.

La distribution des adresses constitue un autre réglage de l’instrument. Un couple source-destination unique peut stabiliser les caches et les recherches. Des destinations aléatoires déplacent la charge. Le RFC demande de commencer par le couple unique, puis de répéter avec une distribution aléatoire. Il retient /48, /64, /126 et /128 comme frontières utiles de préfixe. Les retirer du compte rendu revient à retirer le phénomène mesuré.

Le voisin fait partie de l’expérience

Un banc peut installer des voisins statiques ou utiliser Neighbor Discovery. Le RFC préfère le mode dynamique lorsque l’outil maintient les caches actifs. Il place les terminaux simulés un saut derrière l’équipement afin d’éviter des tempêtes de sollicitations et d’annonces dues à Neighbor Unreachability Detection.

Ces choix ne sont pas équivalents. Une entrée statique, un cache continuellement rafraîchi et une expiration en cours de charge déclenchent des travaux différents. Si la production souffre lors d’un renouvellement de voisin, un essai au cache figé ne l’a pas réfuté. Il a étudié un autre état.

La même règle vaut pour l’échelle. Un essai à un port décrit l’interface. Un essai multiport examine la plateforme. Des cartes distinctes peuvent partager une fabrique, une mémoire de recherche ou un chemin logiciel. L’extrapolation de l’un vers l’autre est une décision, non une conséquence automatique du nombre.

L’asymétrie disparaît dans la moyenne

Le RFC 5180 recommande le trafic bidirectionnel, puis autorise des essais unidirectionnels pour caractériser une situation asymétrique. Le résultat bidirectionnel ne révèle que la direction la moins performante. Il ne dit pas où se trouve la limite.

Or les politiques, les tailles de paquet et les flux applicatifs sont rarement symétriques. Une direction peut exécuter un filtre ou une classification supplémentaire. Le plan de capacité doit donc garder deux observations avant de les agréger. Sinon, la valeur prudente n’est prudente qu’en apparence : elle cache le mécanisme à corriger.

La coexistence IPv4-IPv6 demande la même transparence. La matrice contient IPv4 seul, IPv6 seul, puis des mélanges 90/10, 50/50 et 10/90. Un résultat IPv6 pur ne représente pas un équipement dont les ressources sont partagées entre deux familles de trafic. Le ratio est une entrée exécutable.

Hop-by-Hop mesure un coût de chemin

Le passage le plus instructif du RFC sépare débit et impact. Les en-têtes d’extension doivent être testés individuellement, puis sous forme de chaîne. Pour comparer de petites trames avec et sans ces en-têtes, une même taille minimale doit être utilisée. Sans cette précaution, la comparaison attribue au protocole un écart créé par le banc.

Pour Hop-by-Hop, l’objectif change. Le trafic est injecté à 1 %, 10 % et 50 % de la bande passante, pendant que les ressources sont observées. Le test ne recherche pas le débit maximal ordinaire ; il cherche l’effet du traitement. CPU, mémoire et chemin de commutation doivent être relevés hors bande, indépendamment des interfaces qui portent le trafic de test. Cette séparation aide à voir un traitement matériel, une recirculation ou un basculement logiciel.

Il faut néanmoins dater l’hypothèse. Le RFC 5180 s’appuyait sur le modèle du RFC 2460. Le RFC 8200 indique ensuite que les nœuds intermédiaires n’examinent et ne traitent Hop-by-Hop que s’ils sont explicitement configurés. Le RFC 7045 avait déjà constaté que des routeurs rapides pouvaient ignorer cet en-tête ou l’envoyer vers un chemin lent. Le RFC 9098 décrit des limites de profondeur d’inspection, la recirculation, les chemins logiciels et les abandons.

Un rapport actuel doit donc donner la configuration, pas répéter mécaniquement la phrase de 2008. Deux paquets identiques peuvent rencontrer des décisions différentes. Le débit seul ne peut identifier laquelle a eu lieu.

L’isolement protège la mesure et limite sa portée

Le réseau d’essai doit être indépendant. Il ne doit pas pouvoir injecter son trafic dans la production ni dans le réseau de gestion. L’observation est de type boîte noire, externe au système testé, et aucune fonction spéciale réservée au benchmark ne devrait exister.

Ces exigences rendent l’expérience plus propre. Elles établissent aussi que la production n’a pas été mesurée. La topologie réelle ajoute les variations de routage, les files, les pannes, les politiques, les versions hétérogènes et les utilisateurs. Le laboratoire retire volontairement ces variables pour isoler un mécanisme.

Même l’espace d’adresses conserve cette frontière. Le texte initial comportait une erreur technique vérifiée. Le registre IANA actuel donne 2001:2::/48 pour les benchmarks et le marque non joignable globalement. Une adresse de laboratoire correctement attribuée ne devient pas une annonce de production.

Le périmètre fonctionnel a aussi ses limites. Le RFC 8219 traite séparément les technologies de traduction et d’encapsulation, dont certaines ajoutent des tables d’état et des comportements en surcharge. La méthode RFC 5180 convient au double empilement avec le RFC 2544 ; elle n’absorbe pas, par son seul nom, la complexité d’une passerelle de transition.

Le reçu qu’un comité doit exiger

Chaque valeur devrait porter un identifiant de profil immuable : modèle, version logicielle, fonctions activées, ports, support, topologie, outil, hypothèses d’horloge, tailles, préfixes, distribution des destinations, mode voisin, chaîne d’en-têtes, filtres, routes, trafic de contrôle, direction, mélange IP, durée, nombre d’essais, perte, latence, distribution statistique et télémétrie hors bande.

Le rétablissement après surcharge et le redémarrage sont deux essais différents. Le RFC refuse par ailleurs de recommander le test de trames dos à dos pour IPv6, à cause d’une variance importante. Une organisation mature accepte qu’un indicateur instable ne mérite pas une case verte.

La décision exécutive consiste à attribuer les responsabilités : méthode, configuration du banc, statistiques, équivalence de version, puis observation prudente de la production. Le chiffre garde toute sa valeur, mais aucune couche ne parle au nom de la suivante.

Sources

  1. RFC 5180 — HTML
  2. RFC 5180 — texte
  3. Notice RFC Editor
  4. Document IETF Datatracker
  5. Historique Datatracker
  6. Références Datatracker
  7. Errata du RFC 5180
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. Registre IANA des adresses IPv6 à usage spécial
  17. RFC 8219
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification initiale minimale et adoption volontaire
  20. Heng Lu — primauté du code en fonctionnement