Résumé
- Tout fragment IPv4 pouvait faire allouer un contexte de réassemblage. L’absence du fragment zéro n’empêchait donc ni la conservation d’octets ultérieurs ni la consommation de mémoire.
- RFC 1122 imposa la destruction du datagramme incomplet à l’expiration, mais n’imposa l’envoi d’ICMP Time Exceeded Code 1 que si le fragment zéro avait été reçu et son en-tête conservé.
- La durée d’attente arbitre entre retard légitime, pression sur les tampons et durée de vie des identifiants. Le compteur ICMP, à lui seul, ne mesure aucun de ces trois phénomènes.
Le premier occupant n’était pas forcément le commencement
Le réassemblage ne pouvait pas attendre poliment le début avant de réserver une place. Un fragment portant un offset supérieur à zéro pouvait arriver le premier. Ses adresses source et destination, son protocole et son champ Identification suffisaient à choisir un contexte. Ses données avaient une position déterminée, même si la partie initiale manquait.
RFC 791 décrit cette mécanique sans supposer l’ordre. Le récepteur alloue des ressources lorsqu’aucun tampon ne correspond à la quadruple identité. Il copie les données à l’offset indiqué et marque les blocs reçus. Le fragment dont MF vaut zéro révèle la fin. Celui dont l’offset vaut zéro fournit le début et l’en-tête original. Le datagramme n’est livré que lorsque la longueur totale est connue et que tous les blocs depuis zéro sont présents.
Un dernier fragment peut donc être présent sans premier fragment. Le récepteur connaît alors la frontière droite de l’objet, garde plusieurs morceaux et peut mesurer les trous, mais il ne possède pas encore l’objet transmissible. Cette distinction transforme chaque contexte incomplet en location conditionnelle de mémoire.
Quinze secondes n’étaient qu’un premier loyer
Le modèle de RFC 791 associe au contexte un tampon de données, un tampon d’en-tête, une carte des blocs, une longueur totale et un timer. Il propose quinze secondes comme valeur initiale minimale. À chaque arrivée, le timer prend la plus grande valeur entre son état courant et le TTL restant du fragment.
La spécification relie elle-même le délai à la capacité : débit multiplié par durée donne le volume de tampon à prévoir. Plus le récepteur tolère l’arrivée tardive, plus un ensemble incomplet peut retenir de ressources. Réduire le délai libère plus vite, mais transforme certains retards en pertes définitives.
Le TTL constituait pourtant un mauvais bailleur. Les routeurs le traitaient déjà comme un compte de sauts minimalement décrémenté, non comme une mesure homogène des secondes écoulées. Le fragment ayant encore une grande valeur n’était pas nécessairement jeune ; celui ayant traversé de nombreux routeurs n’était pas nécessairement ancien. Une politique locale de mémoire ne pouvait durablement dépendre de cette ambiguïté.
Les trous étaient simples, l’en-tête ne l’était pas
RFC 815 proposa d’enregistrer les trous plutôt que tous les blocs reçus. Un nouveau fragment pouvait réduire un trou, le diviser ou le supprimer. Quand aucun trou ne subsistait, l’objet était complet. Cette représentation rendait le bookkeeping compact et supportait naturellement l’arrivée désordonnée.
L’en-tête original résistait à cette élégance. Certaines options IPv4 sont copiées dans chaque fragment ; d’autres restent exclusivement dans le premier. Avant le fragment zéro, le récepteur ne connaît donc pas nécessairement la taille finale de l’en-tête à reconstruire. Il peut réserver l’espace maximal ou déplacer ensuite les données, mais aucun choix de structure ne remplace l’information absente.
RFC 815 traitait surtout la réussite du réassemblage. RFC 1122 ajouta une exigence révélatrice : contrairement à la présentation de l’algorithme précédent, l’en-tête du premier fragment doit être sauvegardé pour un éventuel ICMP Time Exceeded. Le témoin devait survivre aussi longtemps que le contexte qu’il pouvait servir à expliquer.
Un message d’erreur est une citation
RFC 792 définit Time Exceeded Type 11. Code 1 signifie que le temps de réassemblage a expiré. Le message reprend l’en-tête IP original et les 64 premiers bits de données, censés aider l’hôte source à retrouver le processus concerné.
Il ne suffit donc pas de connaître l’adresse de retour. Chaque fragment possède un en-tête permettant de l’associer au contexte. Mais un fragment ultérieur ne contient pas les premiers bits promis par la citation ICMP. RFC 792 limite les erreurs ICMP aux erreurs concernant le fragment zéro et précise qu’en son absence aucun Time Exceeded n’a besoin d’être envoyé.
Le récepteur peut savoir qu’il a gaspillé du temps et de la mémoire. Il peut savoir quelle source figurait dans les fragments. Il peut néanmoins manquer du support que son message prétend reproduire. Le silence ne nie pas l’échec ; il évite de transformer un morceau ultérieur en faux commencement.
Le contrat de 1989 sépare expulsion et explication
RFC 1122 exige un timeout de réassemblage et recommande une valeur fixe comprise entre 60 et 120 secondes, plutôt qu’une valeur dérivée du TTL restant. Le texte expose les deux risques : trop court, le délai détruit inutilement des datagrammes légitimes ; trop long, il immobilise les tampons et agrandit la période pendant laquelle les identifiants doivent rester distinguables.
À l’échéance, le datagramme partiellement réassemblé doit être détruit. Un ICMP Time Exceeded doit être envoyé à la source si le fragment zéro a été reçu. La première obligation est absolue. La seconde possède une condition de preuve.
Cette asymétrie protège deux biens différents. L’expulsion rend la mémoire au récepteur. L’explication rend une information contestable à l’émetteur. Exiger la seconde sans le fragment zéro aurait élargi ce que le message pouvait prétendre citer ; suspendre la première jusqu’à l’arrivée du fragment zéro aurait permis à un début absent de garder la mémoire indéfiniment.
Les 60 à 120 secondes sont une recommandation normative de 1989, pas un relevé des réglages actuels. La source fermée ne mesure ni noyaux, ni équipements, ni réseaux contemporains.
Le routeur ne paie pas ce loyer pour tout transit
RFC 1812 précise la fonction. Un routeur qui réassemble un paquet destiné au routeur agit comme un hôte et suit les règles d’hôte. Le simple passage d’un fragment ne signifie pas que chaque routeur du trajet reconstruit le datagramme.
Le même document interdit l’émission d’une erreur ICMP en réponse à un fragment autre que le premier, et donne priorité à cette interdiction. Une enquête doit donc localiser le véritable propriétaire du contexte : le nœud destinataire qui a conservé les morceaux, et non tout équipement ayant observé un fragment.
Une durée de location est aussi une durée d’identité
Les morceaux sont regroupés par un champ Identification de seize bits ajouté aux adresses et au protocole. RFC 6864 rappelle le lien entre durée maximale du datagramme, timeout de réassemblage et période d’unicité nécessaire. Tant qu’un ancien morceau peut encore être admis, réutiliser la même combinaison peut confondre des générations.
Prolonger l’attente loue donc deux choses : de la mémoire et une signification dans un espace d’identifiants fini. Ce constat ne résume pas toute l’histoire du champ ID. Il montre seulement que le coût du timer dépasse les octets immédiatement visibles.
La facture ICMP ne révèle pas tous les locataires
Un Code 1 reçu établit une chaîne étroite : un réassembleur a conservé un datagramme incomplet jusqu’à l’échéance, possédait le fragment zéro et a produit un message qui a traversé le retour. Il ne localise pas le lieu de perte d’un autre fragment et n’attribue aucune faute institutionnelle.
L’absence de Code 1 est encore moins concluante. Le fragment zéro a pu manquer ; le message a pu être limité, filtré ou perdu ; l’implémentation ou le point d’observation a pu diverger. Compter uniquement les messages visibles revient à compter surtout les échecs dont le commencement a survécu. Les échecs qui perdent ce commencement sont précisément ceux qui peuvent disparaître du récit.
Le dernier fragment ne répare pas cette absence. Il peut établir la longueur attendue, donc borner les trous, sans fournir les premiers bits cités par ICMP. Un observateur doit garder séparément fin connue et début présent ; leur fusion en « presque complet » détruit l’information utile.
Code 1 n’annonce pas non plus un MTU ni l’équipement qui a perdu une pièce. RFC 1122 envisageait son utilité future dans une procédure de découverte, mais le message isolé ne contient ni largeur de lien ni verdict causal. Il décrit l’échéance d’un ensemble particulier.
Cette portée étroite est une qualité : elle laisse l’enquête ouverte sans transformer une notification de destination en jugement sur tout le trajet.
Elle oblige aussi à conserver l’incertitude comme un résultat valide, plutôt qu’à la masquer par une cause non démontrée.
Sources et limites
- RFC 791 — Internet Protocol
- RFC 792 — Internet Control Message Protocol
- RFC 815 — IP Datagram Reassembly Algorithms
- RFC 1122 — Requirements for Internet Hosts — Communication Layers
- RFC 1812 — Requirements for IP Version 4 Routers
- RFC 6864 — Updated Specification of the IPv4 ID Field
Ces textes établissent des règles, des algorithmes et des arbitrages déclarés. Ils ne mesurent pas les valeurs par défaut présentes, la fréquence de fragmentation, la livraison d’ICMP, le filtrage ou la conformité des fournisseurs.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
