Résumé

  • La révision 01 de TREB permet à chaque nœud BPv7 participant d’inscrire le prochain nœud choisi, ses temps locaux et des caractéristiques de liaison, puis de renvoyer ces données dans des rapports d’état.
  • L’inscription intervient lors de la mise en file, avant toute preuve d’émission ou de réception; un nœud peut refuser, masquer des champs, remplacer son inscription ou ne pas produire de rapport.
  • Les blocs modifiés en chemin ne peuvent être protégés que saut par saut; le projet interdit donc d’utiliser ces données diagnostiques pour décider du routage ou du contrôle d’accès.

Le trajet comme dossier de déclarations

Le traceroute de l’Internet ordinaire provoque des expirations successives et observe les réponses. TREB adopte une logique différente, adaptée aux bundles qui patientent avant une fenêtre radio, optique ou intersatellite. Le bloc accompagne le bundle et s’enrichit au fil du transfert différé.

Le nœud de départ crée un identifiant. Chaque participant consigne son propre identifiant, le prochain nœud qu’il a choisi, l’instant où il place le bundle en file, le début prévu du contact ainsi que le type, le débit nominal, la distance estimée, la couche de convergence et une estimation de congestion. À la livraison ou à la suppression, un événement de demi-tour sépare le trajet aller de celui du rapport qui revient.

Ce mécanisme comble une vraie lacune. Les rapports d’état ordinaires n’offrent ni tous les détails de liaison ni, sans une série complète de rapports intermédiaires, une vue assemblée du parcours. Une seule copie de rapport de livraison pourrait rapporter la chaîne accumulée et enregistrer son propre retour.

Mais il s’agit de la révision 01 d’un Internet-Draft individuel, daté du 28 septembre 2026 et valable jusqu’au 1er avril 2027. Le statut visé est expérimental. Le type de bloc demandé n’est pas encore une attribution IANA, et aucune implémentation n’est recensée. Un dessin de protocole n’est pas encore une pratique opérationnelle.

Une intention de transmettre, pas une remise prouvée

Le moment décisif est souvent mal lu. Pour un événement de départ ou de transit, le nœud écrit après avoir choisi un prochain saut et placé le bundle dans une file. Rien ne prouve encore que le contact s’est ouvert, que les octets ont quitté l’équipement ou que le voisin les a reçus.

Si une tentative échoue ou si le prochain saut change, l’ancienne inscription est remplacée. La copie finalement transmise ne conserve donc pas toute l’histoire des essais. Elle présente la décision locale la plus récente. Le temps de rayonnement est lui aussi un horaire prévu, jamais corrigé avec l’heure d’émission réelle.

Comparer deux temps issus de nœuds distincts suppose des horloges synchronisées, ce que BPv7 n’exige pas. L’écart entre le départ prévu d’un nœud et l’inscription suivante mélange transmission et propagation. Le projet refuse justement d’y lire automatiquement un délai causal précis.

La valeur zéro n’est pas davantage un zéro physique. Elle peut signifier inconnu, sans objet ou volontairement retenu. Cela vaut pour les temps, la vitesse, la distance, le code de convergence et la congestion. Les politiques locales restent visibles dans la forme même de la preuve.

L’absence n’a pas une cause unique

Un nœud peut ne pas traiter TREB parce qu’il ne fait pas confiance à la source, protège sa topologie ou manque de ressources. Il transmet alors le bloc sans le modifier. Une rupture entre next-node-id et le self-node-id suivant révèle au moins un nœud transparent, sans dire combien ni qui a pris chaque décision.

Le Hop Count Block peut aider: si tous les nœuds le mettent correctement à jour, l’écart entre le nombre de sauts et les inscriptions visibles donne un nombre de sauts transparents. En revanche, record-limit n’est qu’une limite de taille. Une fois atteinte, le bundle continue. Les inscriptions ultérieures deviennent des éléments de débordement susceptibles de revenir séparément.

Les rapports eux-mêmes sont discrétionnaires. Dans BPv7, demander un rapport n’oblige pas l’agent à le produire. Le silence peut résulter d’un refus, d’une perte du rapport ou d’une politique désactivée. À l’expiration de son délai local, la source clôt la reconstitution et ignore les arrivées tardives, même si le réseau continue de transporter les bundles.

Le constat exact est donc temporel: aucun autre rapport n’a été reçu avant le délai local. Attribuer la perte au dernier nœud visible dépasse les faits.

Deux directions, deux expériences

Une copie de rapport de livraison ou de suppression est modifiée pendant son retour. Les inscriptions placées avant l’événement de demi-tour décrivent le trajet aller du bundle initial; celles qui suivent décrivent le trajet propre du rapport. L’asymétrie est normale. Des refus ou une limite pleine peuvent tronquer l’une des deux directions.

Les rapports de transfert ne suivent pas ce modèle: chacun ne transporte que l’inscription du nœud qui l’a émis et une position, puis demeure inchangé. La source rassemble les pièces grâce à l’identifiant, à l’identité du bundle, à la position et au chaînage. Si le bundle a été répliqué, plusieurs branches peuvent occuper la même position.

Une présentation ordonnée donne une impression de certitude. Pourtant, chaque ligne a été rédigée par le nœud qu’elle décrit, selon sa propre politique, et la source a assemblé le résultat. La cohérence d’un récit ne crée pas un tiers de confiance.

La protection s’arrête là où le bloc change

Le bloc révèle identités, topologie, horaires, capacité et congestion. Or il est modifié à chaque nœud participant, tant à l’aller que lors du retour d’un rapport de livraison ou de suppression. Une intégrité de bout en bout sur ces octets mouvants n’est pas possible. BIB ou BCB ne peuvent les protéger que saut par saut, entre une source de sécurité locale et son voisin.

Un rapport de transfert, immuable après sa création, peut recevoir une protection provenant de son auteur. Cela authentifie mieux une déclaration isolée, non l’ensemble du trajet. Le projet le dit sans détour: les hop-records ne sont pas authentifiés de bout en bout, ne sont que diagnostiques et ne doivent jamais alimenter une décision de routage ou d’accès.

Enfin, l’adresse de retour d’un rapport n’est pas une identité de source suffisamment authentifiée. Un probe usurpé pourrait faire envoyer des rapports plus volumineux à un tiers. Les limites de taille, le filtrage, la limitation de débit et la faculté d’omettre la copie réduisent cette amplification sans abolir le problème.