Résumé

  • RFC 2004 remplace le protocole et la destination de l’en-tête original, remplace parfois sa source, puis conserve les valeurs déplacées dans un Minimal Forwarding Header de huit ou douze octets.
  • Le bit S autorise l’absence de la source originale seulement lorsque l’entrée du tunnel est déjà l’émetteur initial. Cette condition réduit la taille ; elle n’authentifie personne.
  • La somme de contrôle du petit en-tête ne couvre ni l’en-tête IP modifié ni la charge. Une restitution réussie prouve une opération de format, pas l’autorisation du tunnel ni la livraison.

La facture de vingt octets n’a pas été seulement réduite

RFC 2004 part des champs dupliqués par l’encapsulation conventionnelle. Au lieu de placer le datagramme sous un deuxième en-tête IPv4 complet, l’entrée modifie celui qui existe déjà. Le champ Protocol devient 55, la destination devient la sortie du tunnel et, si l’entrée transfère le paquet d’un autre émetteur, la source devient une adresse de l’entrée. La longueur totale augmente de huit ou douze et la somme de contrôle IP est mise à jour.

La charge originale reste inchangée derrière le nouvel en-tête minimal. Le datagramme n’a donc plus, pendant la traversée, une copie complète et intacte de son ancien en-tête. C’est la frontière avec RFC 2003, qui ajoute une enveloppe IPv4 distincte. Ici, les douze octets économisés par la forme courte, ou les huit économisés par la forme longue, achètent moins de redondance documentaire.

La forme courte énonce une égalité

Le Minimal Forwarding Header contient toujours le protocole original et l’adresse de destination originale. Avec S=1, il contient aussi la source originale et mesure douze octets. Cette valeur est nécessaire lorsque l’entrée a remplacé la source par sa propre adresse.

Avec S=0, l’en-tête ne mesure que huit octets. L’entrée est alors censée être l’émetteur original : la source visible dans l’en-tête IP modifié est déjà celle qu’il faudra conserver après décapsulation. L’absence des quatre octets est donc porteuse de sens. Elle affirme que deux valeurs sont identiques selon la branche exécutée à l’entrée.

Cette affirmation n’est pas une preuve d’identité. Le bit S n’est pas signé. Il permet à la sortie de choisir une longueur et une règle de restauration, mais ne démontre ni le droit d’utiliser l’adresse, ni l’identité du logiciel, ni l’autorisation de la route. Sans capture avant l’entrée, la source omise n’a pas de seconde copie à comparer.

Deux sommes de contrôle, aucune signature

La somme de contrôle à seize bits du Minimal Forwarding Header porte exclusivement sur ses propres mots. Le champ checksum est traité comme nul pour le calcul ; l’en-tête IPv4 modifié et la charge qui suit sont exclus. Une valeur correcte soutient l’intégrité accidentelle de ce petit registre, pas celle de tout le datagramme.

L’en-tête IPv4 conserve sa somme de contrôle indépendante. Elle est recalculée à l’entrée, puis de nouveau à la sortie après restitution du protocole, de la destination et éventuellement de la source, retrait du petit en-tête et réduction de Total Length. Ces résultats décrivent deux domaines et deux moments. Ils ne sont ni une authentification, ni un reçu d’application.

Restituer n’efface pas les sauts

La sortie remet les champs conservés à leur place, mais elle ne recrée pas une photographie de tous les octets à l’entrée. L’ancienne somme IP n’a pas été gardée. Surtout, le TTL demeure dans l’unique en-tête pendant le tunnel et diminue lors du transfert IP ordinaire. Les sauts internes restent ainsi visibles, notamment à traceroute. La sortie ne rétablit pas un TTL antérieur.

La décapsulation valide signifie donc que la syntaxe a été comprise et qu’un en-tête IPv4 courant a été reconstruit. Elle ne dit pas que le chemin a été intact, que la source était authentique, que la politique autorisait cette entrée, que le prochain routeur a accepté le paquet ou que l’application l’a reçu.

La fragmentation révèle la limite du registre minimal

Le mécanisme ne doit pas être appliqué à un datagramme déjà fragmenté avant l’entrée : il n’existe aucun emplacement pour mémoriser ses informations de fragmentation. Cela n’interdit pas la fragmentation IPv4 après encapsulation lorsque DF est absent. RFC 1191 reste donc une borne utile, sans devenir le sujet principal.

Pour les boucles, ICMP et l’état souple du tunnel, RFC 2004 renvoie à RFC 2003. Il ne traite pas lui-même la sécurité. RFC 2002 explique l’usage possible avec Mobile IP, mais l’acceptation d’un binding et la restitution d’un paquet sont des faits séparés. Le RFC Editor et le Datatracker attestent un Proposed Standard, pas un déploiement.

La distinction rejoint Running-Code Primacy, Minimum Initial Specification et Reality Layers de Lu Heng : le format commun peut définir une opération locale déterministe sans produire, par déclaration, les preuves d’usage et de résultat qui se trouvent ailleurs.

Sources