Résumé

  • Dans l’IPv4 initial, une passerelle pouvait fragmenter un datagramme trop grand pour le réseau suivant, puis la destination reconstituait l’ensemble. L’hétérogénéité devenait invisible, mais la perte d’un seul fragment compromettait tout le datagramme.
  • Le PMTUD classique fit poser le bit DF par la source et demanda au routeur contraint de renvoyer un message ICMP. Quand ce retour disparaissait, une connexion pouvait accepter les petits paquets et engloutir les grands.
  • Le PLPMTUD ajouta une preuve de bout en bout : la couche qui forme les paquets sonde progressivement la route et confirme leur livraison. Le réseau témoigne d’une limite ; l’émetteur conserve une décision révisable.

Le prochain réseau est plus étroit

L’Internet relie des réseaux dont les tailles maximales ne coïncident pas. RFC 791, publié en septembre 1981, plaça donc l’adressage et la fragmentation parmi les deux fonctions fondamentales d’IP. Une passerelle confrontée à un réseau de plus petits paquets pouvait scinder un datagramme en plusieurs morceaux.

Les champs Identification, Fragment Offset et More Fragments permettaient à la destination de remettre ces morceaux en ordre. La source n’avait pas besoin de connaître chaque support traversé. Mais l’économie apparente se payait au goulet : davantage de paquets, du travail dans le routeur, un état de réassemblage au destinataire et l’échec de l’ensemble si une pièce manquait.

Le bit Don't Fragment offrait déjà un autre choix. Un datagramme DF trop grand devait être détruit, non découpé. Cette règle rendait possible une adaptation par la source, à condition qu’elle sache que la taille — et non une congestion quelconque — avait causé la perte.

Le MTU de chemin n’est pas le MTU d’« Internet ». C’est le minimum des MTU des liens empruntés maintenant. Un changement de route, un tunnel qui ajoute des en-têtes ou une autre branche de routage à coût égal peuvent changer la valeur sans modifier la destination.

Faire écrire chaque passerelle

RFC 1063, en juillet 1988, tenta d’obtenir la réponse dans le paquet lui-même. Une option Probe MTU partait avec le MTU du premier lien. Chaque passerelle comparait la valeur à ses interfaces d’entrée et de sortie et la diminuait si nécessaire. Une option Reply MTU la rapportait ensuite à l’émetteur.

La proposition décrivait correctement l’arbitrage. Une taille prudente gaspille le réseau en multipliant les en-têtes ; une grande taille aveugle provoque la fragmentation ; des sondes supplémentaires consomment des ressources et vieillissent dès que la route change. Elle distinguait aussi le MSS TCP — quantité de données TCP acceptable par le pair — du MTU du chemin IP.

Son coût institutionnel se trouvait dans chaque routeur. Une option utile seulement si les passerelles la comprennent impose une adoption coordonnée. Le texte reconnaissait que certains équipements ne connaissaient même pas encore les interfaces nécessaires au moment de traiter l’option et qu’une mise en œuvre pouvait exiger une modification majeure.

Le lien contraint ne parle qu’en cas d’échec

En novembre 1990, RFC 1191 réduisit ce qui était demandé au réseau. La source part du MTU de son premier saut et envoie avec DF. Le routeur incapable de transmettre le paquet intact le détruit et renvoie ICMP Destination Unreachable, code « fragmentation nécessaire et DF actif ». La source réduit alors son estimation.

Un champ ICMP auparavant inutilisé transporte le MTU du prochain saut qui a refusé le paquet. Au lieu de réécrire tous les paquets, le routeur ne fournit une preuve qu’au moment où la taille échoue. La source garde DF afin de détecter plus tard une route devenue plus étroite.

Les anciens routeurs renvoyaient zéro dans ce nouveau champ. RFC 1191 conserva donc une recherche parmi des « plateaux » correspondant à des MTU plausibles. Sous-estimer de quelques pour cent valait mieux que dépasser la limite d’un octet. La table restait une suggestion datée, non un registre éternel des technologies de liaison.

Une route peut aussi s’élargir. L’estimation doit vieillir, puis être testée avec parcimonie par un paquet plus grand. Un message d’erreur peut faire baisser la valeur, jamais la relever sur sa seule affirmation. Une hausse exige la preuve positive d’une livraison.

Le trou noir où seuls les gros paquets disparaissent

Le PMTUD classique avait une dépendance : le message ICMP devait revenir. RFC 2923, publié en 2000, décrivit le trou noir produit quand un routeur ne générait pas correctement le message ou qu’un pare-feu supprimait tout ICMP. L’émetteur répétait la même taille inutilisable sans apprendre à la réduire.

La panne ressemblait à une contradiction. Les petits paquets de la poignée de main TCP passaient. Un ping ou une session interactive pouvait fonctionner. Le premier transfert volumineux envoyait un grand segment DF, qui disparaissait puis revenait sous la même forme lors des retransmissions. La destination restait joignable, mais pas avec la taille choisie.

Une réduction défensive peut rétablir le service et cacher durablement une politique fautive. Le filtrage ICMP n’est d’ailleurs pas l’unique cause : encapsulation, chemin asymétrique, limitation du débit ICMP ou incohérence au niveau liaison peuvent tous priver la source d’un retour exploitable.

La spécification IPv6 actuelle, RFC 8201, décrit elle aussi la poignée de main réussie suivie d’un transfert bloqué si Packet Too Big n’arrive pas. En IPv6, les routeurs ne fragmentent pas les paquets en transit. La source doit choisir la taille et, si nécessaire, produire elle-même les fragments.

Démontrer le passage plutôt qu’attendre l’explication

RFC 4821, en 2007, inversa la question. Le PLPMTUD ne dépend pas uniquement de l’explication d’un échec : la couche de mise en paquets part d’une taille fonctionnelle et envoie des sondes progressivement plus grandes. Une livraison confirmée relève la borne basse ; l’échec isolé et concluant d’une sonde abaisse la borne haute.

Cette couche — TCP dans le cas familier — sait quel paquet a été reconnu. Elle peut maintenir les données ordinaires à une taille sûre et traiter une sonde comme une expérience. Mais la dérogation est étroite : un délai expiré ou d’autres pertes rendent le résultat ambigu, et le contrôle de congestion normal doit s’appliquer. Toute perte n’est pas une preuve de MTU.

Une réussite est elle aussi bornée. Elle établit qu’un paquet de cette taille a franchi la route observée à cet instant. Elle ne promet ni le prochain itinéraire ni toutes les branches d’un chemin multiple. La méthode associe donc bornes, répétitions, temporisations et cache de chemin.

Le PLPMTUD peut exploiter ICMP ou continuer sans lui. Il ne nie pas la connaissance locale du routeur ; il retire à un canal de retour absent ou non vérifié le pouvoir de bloquer indéfiniment la connexion. L’extrémité paie cette robustesse par davantage de logique de sonde et de validation.

Les datagrammes exigent leur propre accusé

Le passage à IPv6 n’a pas supprimé la recherche. RFC 8201 permet de rester au MTU minimal IPv6, au prix de paquets inutilement petits sur les chemins plus larges, ou de découvrir une meilleure taille avec une stratégie qui doit survivre aux trous noirs.

RFC 8899, en 2020, précisa le DPLPMTUD pour les transports et applications à datagrammes, notamment les protocoles sur UDP, SCTP et QUIC. Là où TCP possède des accusés, UDP nu exige que l’application fournisse un moyen de confirmer la réception d’une sonde.

Les données ordinaires restent sous la taille effective ; une sonde identifiée peut la dépasser. La détection d’un trou noir réduit la valeur, les confirmations permettent de l’augmenter. Les messages PTB peuvent accélérer la recherche, mais ne sont qu’une entrée facultative et doivent être rattachés à un paquet réellement émis.

Cette histoire n’est donc pas une disparition soudaine du réseau. La fragmentation cachait la diversité mais amplifiait le coût des pertes. L’option de 1988 recueillait un excellent savoir local mais exigeait chaque passerelle. ICMP ne sollicitait que le lien qui échouait, mais supposait un retour fiable. Le sondage de bout en bout limita ce dernier présupposé sans rendre les liens ni les routeurs inutiles.

Une décision mesurée, pas un nombre sacré

Réduire le MTU à 1500 ou 1280 masque le véritable héritage. Un opérateur fixe une limite locale. Un routeur l’applique et peut la signaler. Une politique de sécurité peut supprimer le signal. L’hôte conserve l’état du chemin. Le transport ou l’application choisit les frontières du prochain paquet. Aucun acteur ne maîtrise toute la route.

La règle commune demeure volontairement limitée : exposer la contrainte lorsqu’on le peut, laisser l’émetteur confronter ce témoignage à la livraison et à la congestion, puis rendre l’estimation périssable. Ce n’est pas le paquet qui devint intelligent ; l’architecture plaça la décision là où ses conséquences pouvaient être observées.

Sources et limites de la preuve

RFC 791 documente le modèle IPv4 et DF ; RFC 1063, les options modifiées par les passerelles ; RFC 1191, le PMTUD classique, le MTU du prochain saut, les plateaux et le vieillissement. RFC 2923 décrit les trous noirs TCP. RFC 4821 fixe les sondes de la couche de mise en paquets, RFC 8201 le modèle IPv6 et RFC 8899 l’extension aux datagrammes.

Ces textes établissent des spécifications et des modes d’échec reconnus. Ils ne constituent ni un recensement mondial des déploiements, ni la preuve d’une date d’adoption universelle, ni une mesure actuelle de la fréquence des pannes.