Résumé

  • La RFC 875 distinguait la passerelle Internet, qui préservait un datagramme IP commun, de la passerelle de traduction qui devait rapprocher des sémantiques d’adressage, d’acquittement, de flux et d’application différentes.
  • En terminant les deux mondes protocolaires, l’intermédiaire devenait un point singulier d’état : la redondance, la reprise et chaque évolution des extrémités exigeaient une conception supplémentaire.

Le premier indice n’était pas un paquet perdu. C’était un acquittement reçu trop tôt. Le réseau proche de l’intermédiaire pouvait confirmer son propre transfert tandis que l’hôte situé de l’autre côté n’avait encore rien garanti. Les octets avançaient ; la preuve, elle, s’arrêtait à une autre frontière.

C’est ce décalage que M. A. Padlipsky a placé au centre de la RFC 875, Gateways, Architectures, and Heffalumps. Publié en septembre 1982, le document n’était ni une norme de traduction ni un inventaire de systèmes en exploitation. C’était une critique d’architecture : une passerelle reliant deux suites incompatibles ne pouvait pas être décrite comme une version plus savante d’un routeur Internet.

Le titre empruntait une métaphore à un animal imaginaire. La démonstration, elle, était concrète. Une boîte baptisée « gateway » pouvait cacher une adresse sans équivalent, un accusé venant du mauvais acteur, un contrôle de flux dont les limites ne coïncidaient pas et deux commandes d’urgence qui ne demandaient pas la même action.

Une passerelle IP avait déjà choisi ce qu’elle ne ferait pas

La RFC 791 définissait IP pour relier des réseaux à commutation de paquets. Le datagramme recevait une adresse Internet et pouvait être fragmenté pour franchir des réseaux de tailles de paquet différentes. IP n’offrait cependant ni livraison fiable de bout en bout, ni séquencement, ni contrôle de flux.

Cette absence n’était pas un oubli à combler dans chaque routeur. Elle délimitait la couche commune. Une passerelle retirait l’enveloppe locale, choisissait la prochaine étape et remettait le même datagramme dans une nouvelle enveloppe. La RFC 791 précisait même que les protocoles de niveau supérieur n’avaient pas à être implantés dans la passerelle.

La RFC 793 confiait à TCP, dans les hôtes, l’état de connexion, les numéros de séquence, les fenêtres, la livraison fiable et l’indication urgente. La passerelle IP pouvait donc rester étroite non parce que son travail était insignifiant, mais parce que les participants partageaient l’objet à préserver et savaient quelle couche portait chaque promesse.

La thèse de la RFC 875 ne condamnait pas l’hétérogénéité. L’Internet avait précisément été conçu pour traverser des réseaux locaux différents. Elle séparait deux situations : adapter l’exécution locale sous un protocole commun, ou inventer une correspondance lorsque les sémantiques supérieures ne coïncident pas.

Le champ absent d’une adresse n’était pas un problème de format

NCP identifiait un hôte dans l’espace ARPANET. Une adresse IP comprenait une partie réseau et une partie hôte. Du côté NCP, le dialogue ordinaire ne possédait donc pas la dimension permettant de désigner « cet hôte sur cet autre réseau ».

On pouvait chercher des bits libres, modifier le protocole d’ouverture ou glisser une adresse Internet dans les données d’application. Mais chacune de ces solutions changeait l’environnement NCP que la traduction était censée conserver. Reformater un nombre ne crée pas la portée que le contrat initial n’exprimait pas.

Padlipsky proposait alors une limite plus visible : l’intermédiaire devenait lui-même un hôte, terminait la première connexion, demandait à l’utilisateur la destination étrangère, puis ouvrait une seconde connexion. Il appelait ce relais un « Janus Host ». Pour Telnet, cette démarche pouvait rendre un service réel ; elle ne produisait pas une connexion transparente.

La RFC 801, consacrée à la transition NCP/TCP, rend cette séparation très tangible. Un utilisateur Telnet se connectait à une machine relais, utilisait un compte spécial, puis lançait une nouvelle session de l’autre côté. Avec FTP, le fichier effectuait deux transferts. Le courrier possédait encore son propre relais. L’application disait explicitement où la première relation finissait et où la seconde commençait.

Le signal de reprise ne venait pas nécessairement du destinataire final

Dans NCP, le Ready for Next Message provenait de l’IMP de destination. Avec un traducteur, il pouvait donc venir de l’IMP voisin du traducteur, non de l’hôte étranger finalement visé. Le mot « prêt » ne décrivait pas le même périmètre.

La passerelle pouvait retarder ce signal et accumuler les données. Il lui fallait alors décider quel événement du protocole opposé autorisait la reprise. Une transmission acceptée par un réseau local ? Un octet placé dans une file ? Une réception de transport ? Une consommation par l’application ? Si l’autre suite n’exposait pas le fait recherché, aucun tampon ne pouvait le fabriquer.

Le contrôle de flux indiquait ainsi plus qu’une vitesse. Il nommait l’acteur qui devait ralentir, la ressource protégée et la preuve autorisant le redémarrage. Lorsque les deux protocoles plaçaient ces frontières à des endroits différents, l’intermédiaire héritait du différend et devenait le principal détenteur d’état.

Deux urgences pouvaient commander deux autorités

La difficulté réapparaissait avec les signaux exceptionnels. NCP disposait d’une commande d’interruption sur un lien de contrôle. TCP proposait un mécanisme Urgent dans la connexion ; Telnet ajoutait une commande Interrupt Process ; d’autres familles parlaient de données accélérées. Les étiquettes suggéraient une proximité qui n’établissait pas une équivalence.

La RFC 793 permet de localiser la promesse TCP : l’indication urgente devait pousser l’utilisateur récepteur à traiter les informations urgentes et suivre les transitions du mode correspondant. Accorder une priorité à un interpréteur de protocole n’est pas nécessairement interrompre le processus de destination. Les deux mécanismes peuvent viser des acteurs différents.

Le traducteur devait donc choisir. Supprimer le signal perdait une fonction. Transformer une livraison accélérée en interruption de processus lui attribuait une autorité nouvelle. Terminer l’application et appliquer une politique locale reconnaissait au moins que la décision venait du relais.

La RFC 875 mentionnait une passerelle de terminal de l’University College London entre Telnet ARPANET et la famille X.25/X.28/X.29. Selon le compte rendu du document, les données passaient, mais seule l’option d’écho franchissait la frontière. Ce témoignage ne doit pas devenir un audit général du dispositif. Il montre plus modestement que le passage des caractères ne prouvait pas celui du vocabulaire d’options qui leur donnait un comportement.

Une deuxième boîte ne possédait pas la conversation de la première

Imaginons toutes les correspondances résolues. La passerelle détenait désormais deux identifiants de connexion, deux espaces de séquence, les deux états de flux, les associations d’adresses, les options et les hypothèses d’application. Installer une machine identique à côté ne copiait aucune de ces connaissances vivantes.

La RFC 875 appelait l’intermédiaire un point de singularité. Une connexion née dans une passerelle restait liée à elle. Le routage pouvait éviter une liaison défaillante au niveau des paquets ; il ne reconstituait pas l’histoire privée du traducteur. Une véritable reprise imposait un protocole de réplication, de résolution des conflits et de prise de contrôle. Le rectangle était devenu un système distribué.

Le temps produisait la même dépendance. Un traducteur liait A à B. Ajouter C multipliait les couples. Modifier une option, une adresse ou une application d’un seul côté obligeait à réexaminer chaque boîte concernée. La commodité initiale concentrait les calendriers de publication et les ambiguïtés des deux suites.

Le routeur ultérieur gardait un objet commun

La RFC 1009 a plus tard défini la passerelle Internet comme un routeur au niveau IP. Son rôle n’avait rien de trivial : adaptation des trames, MTU, correspondance avec les adresses locales, indications locales de flux ou d’erreur, mémoire tampon et sélection du prochain saut.

Malgré cette complexité, le datagramme IP restait l’objet traversant ces adaptations. Le routeur ne promettait pas de reconstruire l’accusé d’une extrémité étrangère ni de rendre équivalentes toutes les options d’application. Une couche mince est une frontière précise, pas une petite quantité de code.

Les intermédiaires ultérieurs ont reformulé la question

La RFC 2775 constatait bien plus tard que la traduction d’adresses brisait la transparence des adresses de bout en bout. Les applications transportant des adresses dans leurs données exigeaient alors des passerelles ou des mandataires qui les comprennent. Chaque nouvelle application dépendante de l’adresse pouvait demander une nouvelle connaissance dans le réseau.

La RFC 3234 a dressé une taxonomie des middleboxes sans nier leurs usages. Elle recensait aussi leurs frontières de panne : un nouvel itinéraire peut rencontrer une boîte dépourvue de l’ancien état, un redémarrage peut détruire des sessions et le diagnostic traverse plusieurs couches. Une passerelle d’application conserve de l’état parce qu’elle participe à la sémantique de l’application.

La RFC 4966 a placé NAT-PT dans la catégorie Historic pour des raisons précises : adresses incorporées, divergences IPv4/IPv6, fragments, durée des associations, charge des ALG DNS et concentration des pannes ou attaques. Ces documents ne forment pas une preuve que Padlipsky aurait prévu chaque technologie, ni un verdict contre toute traduction. Ils confirment seulement qu’« adapter le paquet » ne décrit jamais toute l’obligation.

Une correspondance de sens est une décision visible

La RFC 875 laisse un test simple pour chaque flèche d’un schéma. Quelle affirmation entre dans la boîte ? Quelle affirmation en sort ? Qui décide qu’elles sont équivalentes ? Quelle preuve subsiste après un échec ?

Lorsqu’un protocole minimal est commun, la passerelle peut adapter les réseaux locaux tout en préservant un objet déterminé. Sinon, le choix doit être explicite : réduire le service à l’intersection, terminer puis recréer la relation, enrichir une extrémité, ou admettre qu’une fonction ne traverse pas.

Les octets livrés et l’adresse réécrite sont des résultats observables. Ils ne démontrent ni la continuité de l’acquittement, ni l’identité de l’urgence, ni la conservation des options, ni la reprise de l’état. Une passerelle transporte ce que les deux côtés ont défini. La garantie absente doit être perdue, ajoutée ou décidée par quelqu’un — jamais découverte dans la boîte comme si elle avait toujours existé.

Sources