Résumé

  • ENCAPS proposait qu’un routeur d’entrée ajoute à chaque datagramme un en-tête IP désignant les domaines autonomes, puis qu’un routeur de sortie retire cette enveloppe ; le paquet d’origine et ses adresses demeuraient inchangés.
  • L’absence de modification des hôtes avait une contrepartie : nouvelle association dans le DNS, traitement spécialisé aux deux bordures, plan d’adressage des domaines, routage de cette seconde adresse et vingt octets supplémentaires par paquet en transit.
  • RFC 1955 est un mémo d’information. Il précise que sa publication ne valait pas acceptation par IPng, suppose encore l’unicité globale des adresses IPv4 internes et ne traite pas la sécurité.

Une enveloppe entre deux frontières

Le geste central tient en trois moments. À l’entrée d’un domaine de transit, un routeur reçoit un datagramme IPv4 ordinaire. Il consulte une association supplémentaire, construit un nouvel en-tête IP dont la destination est un domaine autonome, puis place le datagramme entier à l’intérieur. À la dernière frontière, un autre routeur enlève l’enveloppe et rend au paquet son rôle initial.

Entre les deux, les routeurs n’ont pas besoin de comprendre l’histoire complète. Ils voient une adresse IP extérieure et la font progresser. L’information détaillée reste aux bordures ; le milieu manipule une abstraction plus courte.

La proposition insistait sur ce qu’elle ne ferait pas : aucune traduction des adresses contenues dans le paquet. Ce refus distinguait ENCAPS d’un traducteur qui remplace une adresse et doit ensuite réparer sommes de contrôle, protocoles applicatifs et références inscrites dans la charge utile. Mais conserver l’intérieur ne supprimait ni l’état ni le pouvoir de décision. Cela les déplaçait vers le système de noms et les routeurs capables d’ajouter ou de retirer l’enveloppe.

Le texte publié en juin 1996 remonte lui-même à janvier 1992, lorsqu’il fut présenté au groupe ROAD, d’abord sous forme de courrier électronique. Il fut ensuite versé au dossier IPng en réponse à une sollicitation de livres blancs. Cette chronologie explique une étrangeté apparente : le RFC est postérieur à plusieurs décisions qui formaient déjà l’Internet suivant, mais il conserve une proposition conçue au moment où aucune issue de long terme n’était encore acquise.

Acheter du temps sans promettre l’éternité

Au début des années 1990, trois tensions se superposaient. Les numéros de réseaux de classe B étaient mal dimensionnés pour de nombreuses organisations. Les tables de routage et le travail humain nécessaire à leur contrôle croissaient vite. L’épuisement de l’espace IPv4 constituait un horizon plus lointain, mais plus fondamental.

Le débat ROAD refusa d’attendre qu’une seule architecture parfaite résolve tout. Les mesures immédiates, courtes, moyennes et longues devaient commencer en parallèle. Pour l’urgence la plus proche, changer tous les hôtes était exclu. ENCAPS adopta cette contrainte et se présenta franchement comme un pont : maintenir le réseau en fonctionnement assez longtemps pour concevoir et déployer autre chose.

La liste de ses avantages était volontairement séduisante : ne toucher ni aux hôtes ni à la plupart des routeurs, n’inventer ni protocole Internet ni protocole de routage, garder la structure d’adresse existante et diminuer la charge des tables. Pourtant, ce sont des propriétés annoncées, pas des mesures. La documentation retenue ne fournit ni trace de trafic, ni essai d’interopérabilité, ni inventaire de déploiements capable de transformer ces intentions en résultats.

Cette distinction change la lecture historique. Un projet abandonné n’est pas une architecture ratée dont il faudrait reconstruire le succès. C’est une expérience de pensée documentée : que doit-on concentrer aux frontières pour laisser le centre et les extrémités tranquilles ?

Le DNS donnait une seconde destination

Le routeur d’entrée devait examiner les adresses source et destination du paquet, puis demander au DNS les adresses des domaines autonomes correspondants. Ces valeurs alimentaient l’en-tête extérieur. Le routage inter-domaine portait alors sur les domaines plutôt que sur chaque réseau interne.

Le mémo proposait de réserver quelques numéros de réseaux de classes A et B à ces adresses de domaine. Une partie signalerait qu’il s’agit d’un identifiant de domaine ; l’autre sélectionnerait le domaine réel. Plusieurs ensembles permettraient d’organiser les domaines en « commonwealths ». Chacun conserverait le détail de ses propres membres, tandis que les autres seraient vus de manière plus agrégée.

Pour que les routeurs ordinaires du transit participent sans modification, les bordures injecteraient ces adresses dans le routage intérieur. BGP, IS-IS ou OSPF pouvaient, selon la proposition, servir à calculer les chemins. Ce n’était pas l’annonce d’un protocole magique : la nouveauté était façonnée de sorte que l’infrastructure intermédiaire la prenne pour une destination IP ordinaire.

Deux plans devaient toutefois coïncider. Le DNS devait donner le bon domaine de sortie, et le routage devait savoir joindre ce domaine. Une réponse de nom correcte sans chemin exécutable n’achemine rien. Un chemin extérieur valide vers une association périmée conduit au mauvais endroit. L’en-tête compactait le problème ; il ne fusionnait pas les preuves.

Préserver l’adresse ne rendait pas le système sans état

ENCAPS gardait la source et la destination internes. Cette propriété évitait certaines fragilités contemporaines de la traduction : modification des sommes, traitement spécial des adresses incluses dans les applications, synchronisation entre sorties, impossibilité de réécrire des données chiffrées.

Mais un paquet intact peut encore être mal enveloppé. Le DNS peut être périmé, le routeur d’entrée mal configuré, le chemin externe rompu ou la sortie incapable de décapsuler. Chaque étape exige sa propre observation. L’adresse interne prouve ce qui a été conservé ; elle ne prouve ni le domaine choisi, ni la livraison.

Le projet reposait en outre sur la continuation de l’unicité globale d’IPv4. Il imaginait qu’un couple formé par l’adresse de domaine et l’adresse IP puisse un jour devenir l’adresse globalement unique. Le prix réapparaissait aussitôt : si les hôtes ne changeaient toujours pas, la bordure devrait employer la traduction ; si l’on voulait éviter cette traduction, les hôtes devraient connaître l’association et ajouter eux-mêmes l’en-tête.

Autrement dit, trois frontières ne pouvaient être abolies ensemble. Il fallait conserver l’unicité, modifier la bordure ou modifier l’hôte. ENCAPS choisissait un ordre et un délai, pas une exemption définitive.

Le prix visible et le prix déplacé

Le texte chiffre le coût le plus simple : vingt octets de nouvel en-tête IP pour chaque datagramme concerné. Il reconnaît aussi un traitement supplémentaire aux routeurs d’entrée et de sortie. Ce sont les coûts visibles dans les paquets et sur les machines.

Le prix moins visible se trouve dans le contrôle. Chaque nom devait obtenir une nouvelle entrée de domaine. Les identifiants de domaine et leur regroupement demandaient une coordination. Les bordures devaient chercher, encapsuler, router et décapsuler. Les opérateurs devaient diagnostiquer séparément la route extérieure et la destination intérieure.

Le mémo ne donne pas de politique détaillée de cache, d’authentification de l’association, de déploiement asymétrique, de découverte MTU, de fragmentation, d’attribution ICMP ou de sortie du dispositif. Sa section de sécurité dit seulement que le sujet n’est pas traité. Ce silence interdit de convertir l’élégance du schéma en sûreté opérationnelle.

Des RFC ultérieurs ont spécifié plus précisément l’encapsulation IP dans IP. IPv6 a constitué le résultat officiel du processus IPng. La comparaison reste légitime si elle porte sur les questions ; elle devient trompeuse si elle invente une filiation directe. Des mécanismes différents peuvent ajouter une enveloppe sans hériter les uns des autres.

CIDR plaçait l’agrégation ailleurs

CIDR traitait la croissance des routes par une allocation topologique et des préfixes accompagnés de masques. Son coût portait sur la politique d’attribution, les capacités de routage, l’attachement au fournisseur et parfois le renumérotage. Le paquet ne recevait pas, pour cette raison, une adresse de domaine extérieure.

ENCAPS créait au contraire une seconde hiérarchie de destination pour transporter l’ancienne. Les deux projets voulaient gagner du temps, mais ne facturaient pas la transition aux mêmes acteurs. CIDR inscrivait davantage la topologie dans l’adresse annoncée. ENCAPS demandait au DNS et aux frontières de relier l’adresse existante à un autre espace de routage.

Dire simplement « agrégation » masque cette économie. Il faut demander qui tient la table, qui modifie le paquet, qui renumérote, qui supporte les exceptions et qui peut revenir en arrière.

Ce qu’un RFC sans adoption peut encore prouver

Le principe de primauté du code en fonctionnement interdit de faire du texte une exécution. RFC 1955 prouve qu’une proposition a été formulée. Une entrée DNS aurait prouvé une association configurée. Une configuration de bordure aurait prouvé une préparation locale. Un en-tête observé aurait prouvé une encapsulation en un point. Aucun de ces objets ne suffit à prouver le retrait correct de l’en-tête ou la réception par l’application.

La spécification initiale minimale éclaire l’intention : réduire le nombre de participants obligés de changer et laisser la décision future aux bordures qui expérimentent. Cette localisation ne reste pourtant réelle que si le chemin ordinaire, le refus et le retrait demeurent possibles. Si l’association commune devient obligatoire pour être reconnu, la bordure provisoire s’est changée en autorité.

Les couches de réalité fournissent enfin le registre de preuve. Identifiant écrit, association publiée, état chargé, paquet enveloppé, route exécutée et service rendu sont liés, mais non équivalents. Le meilleur legs d’ENCAPS est peut-être de rendre visible l’endroit où l’on serait tenté de les confondre.

Sources et limites

L’identité et le statut figurent dans la notice RFC Editor de RFC 1955, et le mécanisme dans RFC 1955. Le contexte ROAD vient de RFC 1380, la procédure IPng de RFC 1550, et la stratégie distincte de CIDR de RFC 1519. La comparaison avec la traduction est bornée par RFC 1631. Sans prétendre à une filiation, les résultats ultérieurs sont représentés par la première spécification IPv6 et IP dans IP. Le cadre analytique suit Running-Code Primacy, Minimum Initial Specification et Reality Layers.

Ces sources établissent une proposition écrite et des comparaisons bornées. Elles n’établissent ni acceptation par IPng, ni normalisation, mise en œuvre, déploiement, adoption, performance, interopérabilité, sécurité, opérateur nommé, trace de paquets, produit actuel ou lignée causale.