Résumé

  • RFC 2003 conserve le datagramme IPv4 d’origine sous un nouvel en-tête : les adresses externes nomment les extrémités du tunnel, les adresses internes restent celles de la communication.
  • L’entrée qui transfère le paquet décrémente le TTL interne, puis choisit séparément un TTL externe pour joindre la sortie.
  • DF, MTU, fragmentation, réassemblage et traduction ICMP répartissent des obligations entre l’émetteur d’origine, l’entrée, le réseau intermédiaire et la sortie.

L’enveloppe crée un second itinéraire

RFC 2003 décrit une opération sobre : placer un en-tête IPv4 devant un datagramme IPv4 complet. La source externe est une adresse de l’encapsulateur et la destination externe celle du décapsulateur. Les adresses internes ne sont pas réécrites ; elles continuent de désigner l’émetteur et le destinataire originels.

Le routage jusqu’à la sortie consulte la destination externe. Après retrait de l’enveloppe, le routage consulte de nouveau la destination interne. La valeur 4 du champ Protocol annonce seulement qu’un autre en-tête IPv4 suit. RFC 1853 souligne cette simplicité : aucun en-tête de raccord particulier n’est nécessaire. Mais simplicité de syntaxe ne signifie ni authentification de la source interne, ni autorisation, ni arrivée au destinataire final.

Deux horloges ne mesurent pas le même trajet

Quand l’encapsulateur agit comme routeur, il décrémente le TTL interne avant l’encapsulation. Une valeur devenue nulle entraîne l’abandon et, normalement, un message Time Exceeded. Un paquet dont le TTL est déjà nul ne doit jamais être encapsulé. Si l’encapsulateur est lui-même l’émetteur du datagramme, la seule opération d’encapsulation ne consomme pas ce saut.

Le TTL externe est choisi indépendamment pour le chemin vers la sortie. La décapsulation ne décrémente pas le TTL interne ; un transfert ultérieur le fera selon les règles ordinaires. Une capture externe avec un TTL confortable ne révèle donc pas le budget restant à l’intérieur. Il faut enregistrer les deux horloges et les événements qui les modifient, non déduire l’une de l’autre.

Le bit DF déplace la charge

Si DF est positionné dans le paquet interne, il doit l’être dans l’enveloppe. S’il ne l’est pas à l’intérieur, l’entrée peut néanmoins le positionner à l’extérieur afin de découvrir le MTU du tunnel. Cette asymétrie protège l’intention de l’émetteur tout en laissant à l’opérateur une décision sur son propre trajet.

Si l’enveloppe est fragmentée, la sortie doit réunir tous ses fragments avant la décapsulation. Les tampons, identifiants et délais de réassemblage appartiennent alors à cette sortie. Un paquet interne fragmentable peut, lui, être fragmenté avant encapsulation ; chaque fragment voyage dans sa propre enveloppe, et le destinataire final demeure responsable du réassemblage interne.

RFC 1191 prévoit qu’un routeur incapable de transférer un paquet DF renvoie l’erreur code 4 avec le MTU du prochain saut. Dans un tunnel, ce message vise la source externe, donc l’entrée. RFC 2003 exige un état souple au moins pour le MTU, la longueur du chemin ou TTL, et l’accessibilité de la sortie. L’entrée peut annoncer à l’émetteur interne un MTU utile diminué de la taille de l’en-tête ajouté.

Lorsque l’émetteur avait laissé DF à zéro mais que l’entrée l’a imposé, le texte reconnaît qu’il peut ne rien exister de raisonnable à lui signaler. L’entrée peut conserver une copie pendant une sonde, fragmenter puis renvoyer après l’erreur, ou éviter cette politique pour certains trafics. Le choix transforme un détail d’en-tête en responsabilité d’exploitation.

Une erreur ICMP change de sens à la frontière

Les messages ne se relaient pas mécaniquement. Protocol Unreachable devient une indisponibilité réseau ou hôte, car l’émetteur originel n’a jamais choisi le protocole 4. Port Unreachable ne doit pas être relayé : l’enveloppe ne contient aucun port. Datagram Too Big doit l’être. Un Time Exceeded du tunnel est présenté comme Host Unreachable. Un Parameter Problem ne franchit la frontière que s’il désigne un champ copié de l’intérieur.

La citation minimale historique de RFC 792 ne renvoyait que l’en-tête fautif et huit octets suivants. Pour une enveloppe IP-dans-IP, cela peut ne pas atteindre l’en-tête interne. L’entrée met alors à jour son modèle du tunnel sans pouvoir rattacher l’erreur à un paquet interne unique. Une erreur générée ensuite n’est pas nécessairement le reçu exact d’un incident antérieur.

Les mises à jour empêchent une lecture figée

Le TOS externe était initialement copié. RFC 3168 a précisé la transmission d’ECN : un tunnel complet doit préserver le signal de congestion, tandis qu’un tunnel à fonction limitée neutralise ECN à l’extérieur. RFC 6864 a révisé la portée de l’identifiant IPv4 ; sa contrainte d’unicité dépend désormais de la possibilité ou de la présence de fragmentation. Cet identifiant n’est pas un numéro de série universel.

Le Datatracker de l’IETF classe RFC 2003 comme Proposed Standard et répertorie ces mises à jour. Il établit l’histoire normative, pas la conformité d’un équipement observé.

Ce qu’une observation peut réellement prouver

RFC 2003 avertit que l’enveloppe masque aux filtres ordinaires les adresses, le protocole et les ports originels. Une règle de sécurité peut devoir examiner les deux couches. Faire confiance à la source externe ne revient pas à authentifier l’émetteur interne.

La chaîne de preuve doit rester graduée : le texte établit une règle ; la configuration exprime l’intention ; une capture d’entrée relie une empreinte interne à un couple externe ; le réassemblage prouve que l’enveloppe a été reconstituée ; la décapsulation prouve une analyse locale ; une capture après sortie prouve un transfert supplémentaire ; seul un accusé applicatif dit quelque chose d’ultérieur.

Le principe de primauté du code en fonctionnement empêche de prendre la publication pour l’exécution. La spécification initiale minimale explique pourquoi un format commun n’épuise pas les décisions locales. Les couches de réalité séparent enfin règle, configuration, observation et résultat.

RFC 791 fournit les champs IPv4 sous-jacents, et RFC 4459 montre que taille et fragmentation des tunnels sont restées des difficultés concrètes. La conclusion est volontairement étroite : le protocole 4 indique quelle enveloppe ouvrir, non ce qui est arrivé à la lettre.

Sources