Résumé

  • RFC 1504 séparait l’identité d’un réseau exporté — identifiant de domaine et plage d’origine — du numéro local que chaque routeur extérieur pouvait lui attribuer.
  • Si ce numéro local revenait par un chemin redondant, privé de son identifiant de tunnel, le routeur pouvait le prendre pour un réseau réel, le traduire encore et fabriquer un « réseau fantôme ».
  • La cohérence exigeait donc davantage qu’une route valide : époque du mappage, port d’entrée, état de l’échange initial, mises à jour reçues et résultat d’un paquet de contrôle devaient rester raccordables.

La somme de contrôle qui ne pouvait plus témoigner

RFC 1504 fut publié en août 1993 sous le nom d’Alan Oppenheimer, alors chez Apple Computer. Le document était informatif. Il voulait consigner avec beaucoup de précision un protocole Apple susceptible de traverser l’Internet, non transformer AURP en norme de l’Internet.

Cette précision rend sa mise en garde remarquable. Le routeur extérieur pouvait modifier le numéro de réseau dans l’en-tête DDP, dans une adresse d’entité NBP ou dans des données de routage AURP. Une somme de contrôle DDP correcte devait être vérifiée avant la réécriture, puis remplacée par zéro. Après l’opération, l’ancienne somme ne décrivait plus les octets transmis.

La validité avant traduction n’était donc pas la validité après traduction. Et la traduction elle-même ne disait pas si le nouveau numéro désignait une nouvelle chose ou une autre vue de la même chose.

Deux administrations, un même numéro

AURP visait les grands ensembles AppleTalk reliés par des réseaux étrangers, notamment IP, ou par des liaisons point à point. Deux organisations pouvaient avoir construit séparément leurs plans de numérotation. La même plage pouvait être légitime de part et d’autre du tunnel.

Le protocole ne demandait pas à l’une de renoncer immédiatement à son histoire locale. Il formait pour chaque réseau exporté un identifiant unique, le UI. Sur un tunnel, un routeur pratiquant le remappage combinait un identifiant de domaine, DI, avec le numéro ou la plage d’origine. À l’arrivée, un autre routeur associait ce UI à une plage libre réservée dans son réseau local.

Les machines locales continuaient à parler avec des numéros AppleTalk ordinaires. Le routeur gardait la table qui reliait la présentation locale à l’identité du tunnel. L’efficacité de la solution dépendait précisément de cette dissociation.

Mais le numéro local ne portait pas sa propre généalogie. Deux routeurs pouvaient montrer le même réseau distant sous deux nombres différents. Deux domaines distincts pouvaient, à des moments différents, recevoir le même nombre local. Lire seulement le champ visible ne suffisait ni pour conclure à l’identité, ni pour conclure à la différence.

Les adresses cachées dans les données échappaient au traducteur

Le remappage connaissait certains emplacements : en-tête DDP, adresse NBP, données de routage AURP. Il ne pouvait pas parcourir la grammaire de tout protocole tiers. Une application pouvait avoir enfoui un numéro de réseau ailleurs dans sa charge utile.

Dans ce cas, l’extérieur du paquet trouvait sa route tandis que la référence intérieure conservait l’ancien monde. Une session pouvait donc échouer après un tunnel ouvert, une mise à jour acquittée et une entrée de routage correcte. Ce n’était pas une contradiction : les preuves portaient sur des couches différentes.

La gestion de réseau rencontrait le même décalage. Les réponses SNMP ou d’autres protocoles pouvaient contenir des numéros non remappés. La station de gestion devait interroger séparément la base de remappage AURP pour retrouver le numéro présenté localement. Une console affichant l’original et une autre affichant l’alias ne décrivaient pas nécessairement deux réseaux.

RFC 1742 a ensuite normalisé des objets de gestion AppleTalk — ports, tables RTMP, compteurs de routage et observations par port. Ces objets amélioraient l’enquête, sans faire d’une valeur de MIB une preuve complète d’identité ou de service.

Le remappage dynamique créait des époques

Un mappage statique réservait un numéro précis à un UI. Il facilitait la corrélation et la supervision, mais consommait une plage finie. Le mappage dynamique affectait les numéros au fur et à mesure de la découverte ; il raccordait davantage de réseaux au prix d’une histoire plus fragile.

RFC 1504 conseillait de ne réutiliser un numéro qu’une fois les autres possibilités épuisées. Il déconseillait surtout d’associer aussitôt le UI d’un réseau disparu à un nouveau réseau qui venait d’apparaître. Une table courante peut avoir oublié l’ancien titulaire alors que des paquets retardés, des caches ou des instruments le nomment encore.

Le temps appartenait donc à l’identité. « 47 correspond à X » n’était pas une donnée complète. Il fallait écrire : « sur le routeur R, au port P et durant l’époque E, 47 présentait le UI composé de ce DI et de cette plage ; le retrait fut observé à T ». Sans cette phrase, la réutilisation transformait une économie de nombres en ambiguïté durable.

Le réseau fantôme arrivait par la redondance

Le scénario dangereux associait un tunnel et un second chemin entre les mêmes ensembles AppleTalk. Un numéro remappé à l’entrée pouvait circuler dans le réseau local, emprunter la voie redondante et revenir au routeur qui l’avait créé.

Au retour, la plage n’était plus accompagnée du DI et du UI permettant de reconnaître la traduction. Pour le routeur, elle ressemblait à une plage véritable de son réseau local. Il pouvait alors la remapper à nouveau et l’exporter dans le tunnel.

Deux plages, puis trois, désignaient le même réseau physique. RFC 1504 appelait ces apparitions des réseaux fantômes. Le cycle pouvait continuer jusqu’à ce que la distance apparente dépasse la limite de sauts. La limite finissait par empêcher la circulation, mais elle ne réparait pas le registre des identités déjà multipliées.

Ce n’était pas la redondance en elle-même qui créait le fantôme. C’était une redondance traversant la frontière de traduction sans conserver l’origine. Le chemin de secours révélait que la portée réelle du mappage était plus vaste que la portée supposée.

Un tunnel multipoint n’était pas toujours le lien qu’il prétendait être

AURP présentait le tunnel multipoint comme une liaison virtuelle unique. Les routeurs extérieurs appliquaient le split horizon : ils envoyaient les routes de leur réseau local, mais ne réexportaient pas sur le même tunnel les routes apprises d’un autre routeur extérieur.

Cette règle supposait que tous les pairs se joignaient directement. Or un tunnel pouvait être partiellement connecté, par choix ou par erreur. Un routeur ne pouvait généralement pas distinguer ces deux intentions. Une topologie faite de deux liaisons virtuelles aurait parfois exprimé honnêtement ce que le seul tunnel multipoint masquait.

Le remappage étant activé routeur par routeur, un déploiement mixte produisait une propriété de sécurité asymétrique. Les routeurs remappant les numéros effectuaient une détection de boucle ; les autres ne la faisaient pas. Une boucle entre ces derniers pouvait renvoyer des copies au premier, qui les inscrivait sous des alias supplémentaires.

La redondance de deux routeurs remappeurs demandait en outre le même DI pour le réseau local et exactement les mêmes correspondances UI-numéro local. Le texte envisageait une configuration commune ou un futur partage, tout en précisant qu’AURP ne fournissait pas encore cette fonction. Le second chemin existait ; le second exemplaire cohérent de l’état d’identité, non.

Une ressemblance déclenchait une enquête, pas un verdict

RFC 1504 décrivait une information « indicative de boucle » : taille de plage et liste de zones pouvaient correspondre à un réseau local déjà connu. Cette ressemblance ne suffisait pas. Le routeur devait envoyer un paquet par le tunnel et observer s’il revenait par un port du réseau local.

Le test sépare correctement hypothèse et observation. Le retour du paquet prouve le chemin vu pendant l’expérience. Il ne prouve ni l’intention administrative, ni la durée future de la topologie, ni l’effet sur chaque service. Il autorise une décision locale limitée.

La section de sécurité impose la même modestie. Elle qualifie le masquage de réseaux et d’équipements de sécurité faible, et laisse les préoccupations générales hors du document. Faire disparaître une zone du Chooser n’authentifie personne. Une absence dans l’interface n’établit pas une absence dans le réseau.

Un accusé de réception ne synchronisait pas le monde

AURP remplaçait une partie du trafic périodique par un échange initial puis des événements. Les connexions unidirectionnelles possédaient un identifiant ; chaque paquet portait une séquence ; l’émetteur attendait RI-Ack avant d’avancer.

Une nouvelle connexion pouvait toutefois commencer pendant que des événements attendaient l’envoi. Le récepteur recevait alors une photographie et, ensuite, un événement qui semblait incompatible avec elle. Le protocole prescrivait des conversions pragmatiques : une variation de distance pour un réseau inconnu devenait une addition ; une addition pour un réseau connu devenait une variation ; certains retraits inconnus étaient ignorés.

Cette tolérance permettait de reconstruire un état utilisable. Elle ne créait pas un instant atomique commun à tous les pairs. RI-Ack attestait un paquet et une séquence, non la propagation RTMP locale, l’alignement des tables de remappage ou l’arrivée de la charge utile.

Si la table du récepteur débordait, les données perdues ne seraient pas forcément rejouées. Le conseil était de demander à nouveau la table complète avec RI-Req. Après une lacune, la dernière mise à jour ne pouvait pas guérir l’histoire manquante ; il fallait rouvrir une frontière de photographie.

Les six pièces d’une identité exploitable

Une enquête sérieuse devait conserver au moins : le UI original <DI, plage> ; l’alias local avec routeur, port et époque ; la connexion et la séquence du message ; le type photographie ou événement ; le chemin d’entrée ; la décision de transfert et son résultat observé.

Deux nombres différents pouvaient se réduire au même UI. Un nombre identique pouvait avoir changé de UI après réutilisation. Une route valide pouvait conduire à une application cassée par une adresse intérieure non traduite. Le rapprochement de ces pièces, et non l’apparence d’un numéro, permettait de choisir entre collision, fantôme, ancien état et véritable nouveau réseau.

Ce que les sources ne démontrent pas

RFC 1504 décrit le mécanisme, pas sa diffusion. Les sources ne donnent ni nombre de déploiements, ni incident nommé, ni taux de conformité, ni comportement d’un produit actuel. Le statut RFC ne certifie aucun routeur.

RFC 1378 définit comment PPP pouvait négocier AppleTalk et transporter des informations AURP sur une liaison point à point. Il ne prouve pas qu’une session AURP ait convergé. RFC 1742 définit des objets de gestion ; il ne garantit pas une base de remappage complète. Les textes de Lu Heng fournissent ici une règle de lecture : spécification, présentation locale, autorité administrative et effet constaté doivent rester des reçus distincts.

Le réseau fantôme n’était pas une illusion sans effet. Il pouvait remplir des tables et modifier le transfert. Mais son origine était bien une erreur de catégorie : prendre une présentation revenue pour une identité nouvelle.

Sources