Résumé

  • RFC 9510 loge un exposant de cinq bits et une mantisse de trois bits dans un octet, au prix d’un arrondi vers la valeur inférieure.
  • Le même format d’un octet reste attaché aux TLV existants : ancien et nouveau routeur peuvent donc tirer des durées incompatibles d’une séquence binaire identique.
  • La preuve exploitable relie le TLV brut à la version logicielle, au calcul réalisé à chaque saut, à l’effet PIT ou cache, puis à l’observation du trafic.

La scène tient dans une capture de paquet. Un Interest CCNx porte un champ Interest Lifetime long d’un octet. Rien d’anormal dans la syntaxe. Pourtant, un ancien routeur le lit comme un entier de 0 à 255 millisecondes, tandis qu’un routeur conforme à la RFC 9510 y voit un nombre compact à exposant et mantisse. L’un libère rapidement son entrée en attente ; l’autre peut conserver un état pendant des années.

Ce n’est ni une dérive d’horloge ni un bit corrompu. C’est un changement de grammaire au milieu du réseau.

Le besoin auquel répond le texte est sérieux. La sémantique CCNx et son encodage TLV doivent fonctionner dans des environnements où huit octets ne sont pas gratuits. L’adaptation ICN aux réseaux personnels sans fil de faible puissance a déjà établi l’intérêt d’un temps compact, et la cartographie des défis ICN replace cette contrainte dans un programme de recherche plus vaste.

Inspiré de la RFC 5497, le code de RFC 9510 réserve cinq bits à l’exposant et trois à la mantisse. Il est précis près de zéro et gagne de l’étendue à mesure qu’il perd en finesse. La valeur maximale des vecteurs d’essai atteint 125 829 120 secondes, soit près de quatre ans. Une durée non représentable est ramenée à la valeur disponible immédiatement inférieure. L’algorithme compresse donc aussi une décision de prudence : il ne promet pas plus longtemps que l’entrée demandée.

Réutiliser le type, déplacer le risque

Le document n’attribue aucun nouveau code. La longueur d’un octet devient le discriminant de la nouvelle représentation, dans les TLV Interest Lifetime et Recommended Cache Time déjà inscrits au registre CCNx de l’IANA.

Les auteurs reconnaissent le problème de compatibilité. Ils l’acceptent parce que les RFC 8569 et 8609 sont expérimentales, que les domaines visés sont souvent de petits réseaux de capteurs capables de se mettre à niveau de façon coordonnée, et que ces champs saut par saut ne sont pas protégés par le hachage signé du contenu. Un routeur qui connaît les deux formats peut les réencoder. Cette justification limite le compromis ; elle n’autorise pas à ignorer un parc hétérogène.

Pour Interest Lifetime, un ancien équipement réduit le code compact à 255 millisecondes au maximum et peut faire expirer l’état PIT trop tôt. Dans l’autre sens, l’équipement mis à jour peut lire une courte durée de l’ancien format comme un code logarithmique et immobiliser de l’état jusqu’à environ quatre ans. L’échec peut donc être une réponse perdue ou une table occupée, selon l’ordre des versions.

Recommended Cache Time produit une rupture différente. Le nouveau format est un décalage relatif : le routeur le combine à l’heure de réception, puis recalcule le temps restant avant le saut suivant. L’ancien format exigeait huit octets d’heure absolue. Une longueur de un est alors une erreur structurelle ou syntaxique qui devrait entraîner le rejet ; sinon, elle ressemble à une date absolue très ancienne. Le même octet joue sur la durée du cache, mais aussi sur l’acceptation du paquet.

Les temps signés restent ailleurs

Signature Time et Expiry Time ne sont pas concernés. Ils restent des dates absolues dans l’enveloppe de sécurité du Content Object. RFC 9510 écarte leur compression parce qu’elle ne préserverait ni leur sens ni leurs propriétés de sécurité. Une recommandation de cache modifiable à chaque saut ne prouve donc pas la fraîcheur du contenu ; une date d’expiration signée ne prouve pas la durée réelle de séjour dans un cache.

Le dossier opératoire doit commencer par le type, la longueur et l’octet brut, puis conserver le build et l’option d’encodage de l’émetteur, le build et la règle du récepteur. Viennent ensuite l’heure d’arrivée, la durée décodée, l’échéance calculée et le réencodage éventuel. La création ou la libération d’une entrée PIT, l’admission ou l’éviction d’un objet en cache, puis la trace du paquet sont des reçus distincts.

Les sources officielles fixent la norme, pas son exécution. Le RFC Editor publie la notice, le texte brut, la source XML et la recherche d’errata. Le Datatracker conserve l’historique, le dernier Internet-Draft et les références. Aucun de ces documents ne démontre qu’un déploiement donné a appliqué le bon dictionnaire.

RFC 9510 est une publication expérimentale de l’IRTF issue du consensus de l’ICNRG, et non une norme IETF. La RFC 7841 rappelle qu’un résultat IRTF peut être publié pour l’étude tout en restant inadapté à un déploiement. Ce statut rend la décision locale plus importante, pas moins.

Trois textes de Heng Lu constituent ici une grille éditoriale déclarée : la primauté du code exécuté, la spécification initiale minimale et l’adoption volontaire, et les couches de réalité. Ils ne font pas autorité sur le protocole. Ils imposent seulement une bonne question : quel logiciel a transformé cet octet en quel état observable ?