Résumé

  • RFC 1241 plaçait un « Clear Datagram » inchangé derrière un en-tête IP externe et un en-tête d’encapsulation de huit octets, puis le faisait circuler dans un Encapsulation Space distinct.
  • Le Flow ID de 32 bits n’était unique qu’au niveau d’un encapsulateur ou d’un décapsulateur ; un mécanisme supérieur, non défini, devait entretenir les tables et les traductions de retour.
  • Un ICMP émis dans le tunnel citait l’en-tête externe et les huit octets d’encapsulation, mais aucune partie du datagramme clair. L’erreur revenait sans son contexte causal.

Le chemin virtuel déplaçait le savoir au lieu de le supprimer

Le RFC 1241, publié en juillet 1991 par Robert Woodburn et David L. Mills, définissait un protocole expérimental. Son vocabulaire rendait visible une frontière souvent masquée. Le paquet IP initial était le Clear Datagram, dans le User Space. L’encapsulateur le projetait dans un Encapsulation Space, doté de ses propres adresses et de son propre routage. Le décapsulateur retirait ensuite l’enveloppe et réinjectait le paquet initial dans IP.

Une telle voie pouvait contourner une panne de routage, une passerelle défectueuse ou un domaine que l’on ne souhaitait pas traverser. Elle permettait aussi d’expérimenter sans apprendre à chaque source la topologie intermédiaire. Contrairement au source routing, la source ne nommait pas le trajet. Contrairement à un nouvel IP, le mécanisme utilisait le réseau installé.

Cette ignorance était une propriété pour la source, mais une obligation pour l’infrastructure. Il fallait décider quel en-tête clair correspondait à quel chemin, où se trouvait le prochain décapsulateur et comment revenir en arrière en cas d’erreur. RFC 1241 appelait ce chemin un Flow, ou tunnel.

Son identifiant tenait sur 32 bits sans être mondial. Un Flow ID n’avait de sens que pour l’entité qui l’avait attribué. Le même Flow pouvait changer de numéro à chaque couple encapsulateur-décapsulateur. Pour renvoyer une erreur, une table devait donc conserver l’adresse de l’encapsulateur précédent et le numéro que celui-ci utilisait. Le retour était une suite de traductions locales, non la lecture d’un identifiant universel.

Le protocole ne définissait ni construction ni entretien de ces tables. Une entité de couche supérieure en avait la charge ; des fichiers ASCII pouvaient suffire pour une expérience. La présence d’une entrée locale ne prouvait donc ni sa fraîcheur, ni l’accord du prochain nœud, ni l’existence du chemin inverse de diagnostic.

Les octets intérieurs restaient intacts, pas leurs conditions de transport

L’enveloppe ajoutait un nouvel en-tête IP et huit octets indiquant version, type de message, motif, somme de contrôle et Flow ID. Le Clear Datagram suivait sans modification. Pourtant, le paquet vu par le réseau avait changé de taille, d’adresses et de contexte.

Les adresses externes désignaient l’encapsulateur et le décapsulateur. La priorité et la qualité de service pouvaient être copiées ; les options de timestamp, record route ou source route ne l’étaient pas. Le TTL intérieur ne devenait pas le TTL extérieur, mais devait être décrémenté avant l’encapsulation. Lorsqu’un décapsulateur utilisait directement le Flow ID au lieu du transfert IP ordinaire, il héritait lui-même de cette responsabilité avant le prochain encapsulage.

L’ajout des en-têtes rendait surtout un paquet plus grand. Un datagramme adapté au MTU de l’interface de départ pouvait dépasser celui du tunnel. RFC 1241 autorisait la fragmentation externe, tout en rappelant son inefficacité. Si l’encapsulateur la refusait, le MTU effectif de l’espace d’encapsulation devenait inférieur au MTU physique et il fallait prévenir utilement la source intérieure.

La fragmentation pouvait aussi briser la classification. La table de correspondance avait le droit d’examiner les ports TCP, voire une connexion. Mais après fragmentation IP dans le User Space, seul le premier fragment contenait l’en-tête TCP. Une règle par ports pouvait sélectionner le premier fragment et ne plus reconnaître les suivants. Le document ne rapportait pas un incident ; il montrait qu’une règle précise sur un paquet complet ne restait pas nécessairement précise sur ses morceaux.

Le RFC 1191 avait déjà formalisé Path MTU Discovery : poser le bit DF, recevoir un ICMP signalant la fragmentation nécessaire, réduire le MTU supposé. Dans le tunnel, l’adresse source externe était celle de l’encapsulateur. L’ICMP revenait donc correctement à lui, pas à la source du datagramme clair.

L’ICMP rapportait l’enveloppe, pas le message

Selon le RFC 792, une erreur ICMP devait citer l’en-tête IP fautif et au moins 64 bits de données. Dans le format de RFC 1241, ces 64 bits couvraient exactement l’en-tête d’encapsulation de huit octets. La citation s’arrêtait avant le premier octet du Clear Datagram.

L’encapsulateur retrouvait le Flow et la destination externe, mais pas l’adresse source intérieure ni l’éventuel en-tête TCP. Plusieurs Clear Headers pouvaient mener au même Flow ; aucune inversion exacte du Flow ID n’était donc possible. Ce n’était pas une perte accidentelle d’un journal : c’était une limite du format de retour.

RFC 1241 distinguait l’inconnu « Flow ID » des ICMP ordinaires. Le premier était signalé au précédent encapsulateur et au gestionnaire de table. Les seconds pouvaient remonter le Flow, chaque nœud traduisant l’identifiant pour son prédécesseur. Mais transporter l’objet ICMP ne recréait pas les octets intérieurs absents. Et une erreur rencontrée pendant l’envoi d’une erreur n’engendrait plus d’autre erreur.

Le compromis proposé était révélateur. Un ICMP pouvait marquer un Flow ; le prochain paquet clair correspondant déclencherait alors un nouvel ICMP vers sa source. Le paquet suivant devenait le support d’un état appris à propos du précédent. Ce mécanisme ne constituait pas une attribution paquet par paquet, et le texte ne le jugeait probablement sûr que pour certaines catégories.

Les RFC ultérieurs conservèrent le problème, sans prouver un déploiement

Il serait abusif de transformer ces textes en filiation universelle ou en preuve d’adoption de RFC 1241. Le RFC 1853 offre une relation plus précise : il distingue IP-in-IP, sans en-tête intermédiaire spécial, du protocole 98 de RFC 1241 et reconnaît avoir repris une partie de son organisation et de son texte.

Le RFC 2003, sur la voie des standards, répéta que huit octets cités ne suffisaient pas à inclure l’en-tête IP intérieur. Il demanda de conserver un état souple du MTU, du TTL et de l’accessibilité du tunnel. Cet état aidait à produire des erreurs exactes dans de nombreux cas, mais ne faisait pas d’un ICMP externe la preuve individuelle d’un datagramme intérieur.

Le RFC 4459 qualifia ensuite les problèmes de taille dans les tunnels de courants et non triviaux. Fragmenter l’extérieur, signaler un MTU inférieur, réserver de la marge ou fragmenter l’intérieur : chaque stratégie attribue les coûts et les preuves à des acteurs différents.

La portée historique de RFC 1241 tient à cette séparation. Il prouve le format proposé, la portée locale des identifiants et la disparition du Clear Datagram dans la citation ICMP. Il ne prouve ni implémentation nommée, ni trafic réel, ni livraison intérieure. Pour soutenir cette dernière, il faut relier une capture d’entrée, la version de table, l’en-tête externe, le Flow ID, une observation de décapsulation et les octets exacts de l’erreur. La transparence n’autorise pas à inventer les maillons absents.

Sources