Résumé

  • La RFC 1475 proposait un identifiant de route avant de 64 bits, interprété par le prochain routeur et opaque en dehors de la machine qui l’avait émis.
  • La valeur pouvait être nulle, invalide, remplacée à chaque saut, affinée lors d’une agrégation ou abandonnée au profit d’une recherche ordinaire.
  • Le statut expérimental de 1993, l’évolution vers CATNIP puis le classement Historic décrivent la trajectoire documentaire, pas un déploiement ni le parcours d’un paquet réel.

Un journal sans dictionnaire

La RFC 1475, publiée en juin 1993, décrivait TP/IX, une proposition appelée aussi Internet Protocol version 7. Elle voulait agrandir l’adressage, étendre TCP et UDP et accélérer le transfert. Son identifiant de route avant paraît offrir à l’historien un objet idéal : un nombre de 64 bits inscrit dans chaque datagramme.

Mais un nombre n’est une preuve que si son dictionnaire subsiste. TP/IX autorisait un routeur à fabriquer un identifiant interne — indice de table, voire adresse mémoire — puis à l’annoncer au voisin qui lui enverrait les paquets. Pour le voisin, cette valeur restait opaque. Elle n’expliquait ni la route, ni l’interface, ni le prochain identifiant. Elle devenait exploitable seulement à l’intérieur de la machine qui l’avait créée.

Ainsi, extraire la valeur d’une capture et la conserver sans l’identité de l’émetteur revient à archiver une clé en jetant la serrure. La largeur du champ ne lui donne aucune universalité.

Le trajet X–A–B–C–Y

L’exemple de la RFC met trois routeurs entre deux hôtes. C annonce à B une route vers Y et lui remet un identifiant propre à C. B enregistre ce jeton, construit sa route via C, puis remet à A un autre identifiant, propre à B. A ne connaît pas la structure interne de B. Il sait seulement quelle valeur lui retourner dans le prochain datagramme.

X émet d’abord le paquet avec zéro. A ne dispose donc d’aucun raccourci et consulte la destination dans sa table. Il choisit B, inscrit l’identifiant de B et transmet. B interprète cette valeur dans son propre espace, trouve la route via C, efface le champ et y place l’identifiant de C. C répète l’opération, puis remet zéro avant d’atteindre Y. Le destinataire reconnaît son adresse et ignore le champ.

Le même emplacement binaire a donc porté trois affirmations de portée différente. Chez A, il représentait la connaissance prêtée par B. Chez B, il était une clé locale. Après B, il ne parlait plus de B du tout. À Y, il n’était pas nécessaire à la remise.

Un outil qui dessinerait une ligne continue à partir de ces valeurs inventerait un lien absent du protocole. TP/IX transmet une succession de capacités locales de recherche, non la description compacte d’un chemin.

La validation précédait l’accélération

La RFC ne demandait pas d’obéir aveuglément au jeton. Le routeur devait vérifier qu’il appartenait à un domaine admissible, notamment s’il ressemblait à une adresse mémoire. Il devait vraisemblablement contrôler que la route ainsi trouvée correspondait à la destination du datagramme.

En cas d’échec, aucune conclusion générale ne suivait. La machine ignorait silencieusement l’identifiant et revenait à la recherche ordinaire utilisée pour une valeur nulle. Un jeton invalide ne signifiait donc ni destination absente, ni panne, ni attaque, ni paquet perdu. Il établissait seulement que ce raccourci n’était pas utilisable à cet instant dans ce routeur.

Cette hiérarchie est essentielle. L’adresse de destination restait l’ancre de correction. L’identifiant promettait de préserver une connaissance entre deux voisins et d’éviter une consultation. La table locale, sa génération et ses règles de validation décidaient si la promesse pouvait encore être honorée.

L’agrégation obligeait à rouvrir la décision

Une route agrégée ne révélait pas forcément la branche précise à emprunter. Lorsqu’un identifiant entrant ne désignait que l’agrégat, le routeur situé avant la divergence devait choisir une route plus spécifique. Il écrivait ensuite l’identifiant que le prochain routeur saurait lire.

Le gain de vitesse avait donc une frontière géographique et sémantique. Tant que la connaissance prêtée restait assez précise, elle avançait. Dès qu’elle ne l’était plus, une décision locale redevenait nécessaire.

Le changement de routage créait la même rupture. La RFC admettait qu’un routeur devrait remettre les datagrammes en circulation sur un nouveau rail pendant qu’ils étaient en vol. Le champ ne verrouillait pas l’itinéraire choisi auparavant. Il rencontrait des tables qui pouvaient changer plus vite que le paquet.

Il faut alors distinguer cinq faits : la route annoncée, l’identifiant émis, sa validation ultérieure, la décision de réacheminement et la sortie effectivement utilisée. Aucun ne remplace les quatre autres.

Le flux restait une affaire privée

TP/IX envisageait également de placer dans le même champ un identifiant de flux. L’objet interne du routeur pointerait vers une route construite pour ce flux. Un datagramme pouvait entrer dans le flux ou le quitter, à l’initiative de l’hôte ou d’un routeur proche.

Le protocole ne publiait pas un type universel capable de dire à tout observateur : ceci est une route, ceci est un flux. Le routeur pouvait distinguer ses deux familles d’identifiants par une méthode privée. Le voisin devait seulement lui rendre la valeur opaque.

Une capture ne prouve donc pas qu’un flux réservé existait, encore moins qu’il disposait de capacité ou qu’un service fut rendu. Il faudrait conserver le type local, l’objet de flux, la route associée, l’époque de validité et la décision de sortie. La qualité de service et le résultat applicatif restent des preuves supplémentaires.

RAP limitait la promesse à un instant

La proposition voisine, RFC 1476, décrivait RAP. Lorsqu’un pair envoyait Add Route, la route offerte devait être réellement chargée dans sa base de transfert à ce moment-là. Le destinataire recevait aussi l’identifiant à replacer dans les datagrammes envoyés vers ce pair.

Cette obligation empêchait d’annoncer volontairement une pure fiction, mais elle n’immobilisait pas l’avenir. Une route pouvait être retirée. Purge Route demandait alors au pair de la supprimer et de révoquer les annonces propagées. La RFC préférait que la purge parte avant la suppression locale, tout en reconnaissant que cet ordre ne pouvait être imposé.

Entre le retrait local, l’envoi de la purge, sa réception et le prochain paquet, un décalage demeurait. Un identifiant peut avoir été correctement annoncé et être déjà périmé. Le registre RFC de RAP fixe le statut du document, pas la synchronisation d’un réseau hypothétique.

La conversion ne conservait pas une vérité imaginaire

TP/IX voulait permettre la coexistence avec IPv4. Son option « Don't Convert » pouvait interdire à un routeur de convertir le datagramme vers IPv4, mais le texte rappelait que la norme ne spécifie que les bits sur le fil : un hôte destinataire pouvait encore effectuer un traitement interne.

Le mécanisme reconnaissait d’autres limites. Des fragments empruntant des chemins différents pouvaient atteindre des convertisseurs distincts et devenir impossibles à rassembler. La version du voisin pouvait être déduite d’un datagramme reçu, d’un échange d’écho ou d’une configuration explicite. Une adresse au format IPv7 ne prouvait pas une mise en œuvre native, car un système hybride pouvait l’utiliser.

Surtout, la conversion d’IPv4 vers IPv7 mettait l’identifiant de route à zéro. Elle n’essayait pas de transporter à travers la frontière une poignée dont le prochain domaine ne possédait pas le dictionnaire. La route devait être décidée de nouveau.

Le statut historique ne juge pas chaque idée

La fiche RFC 1475 la classe aujourd’hui Historic. La RFC 1752 explique que TP/IX devint CATNIP, que cette proposition fut jugée trop incomplète et que SIPP à 128 bits fut recommandé comme base d’IPng. La RFC 6814 a ensuite formellement rendu RFC 1475 obsolète. RFC 791 reste le repère IPv4 auquel la proposition se comparait.

Ces documents prouvent des décisions éditoriales et institutionnelles. Ils ne comptent pas les implémentations et n’effacent pas la précision conceptuelle du jeton local. Inversement, le titre ambitieux The Next Internet ne prouvait ni adoption ni trafic réel. La RFC 1475 ne discutait pas non plus la sécurité : valider un indice local n’en faisait pas un justificatif authentifié.

Sources