Résumé

  • RFC 1191 a confié au routeur contraignant la production d’un message ICMP contenant le next-hop MTU. La source IPv4 plaçait Don't Fragment, puis réduisait son estimation ; le routeur observait, l’extrémité décidait.
  • RFC 2923 a documenté le trou noir créé lorsque l’ICMP disparaît : une connexion TCP peut s’ouvrir et transporter de petits paquets avant de se figer sur les segments plus grands. Le MSS ne révèle pas à lui seul le chemin.
  • Chez Cloudflare en 2015, l’ICMP n’était pas simplement bloqué. Le hachage ECMP des flux TCP et celui des messages ICMP différaient, si bien que l’avertissement pouvait atteindre le mauvais backend.
  • PLPMTUD et DPLPMTUD rendent l’extrémité moins dépendante du retour ICMP en lui faisant tester des tailles. Cette autonomie se paie en sondes, en état et en interprétation des pertes.

Le réseau avait parlé, mais pas à la bonne machine

Cloudflare venait d’étendre son usage interne de l’Equal-Cost Multi-Path routing. Pour un flux TCP, le routeur utilisait un hachage sur les adresses et ports source et destination. Les paquets d’une même connexion revenaient ainsi au même serveur.

Le message ICMP suivait une autre logique. Selon le compte rendu de l’opérateur, le routeur ne disposait pour ce trafic que des adresses source et destination dans son hachage. Il pouvait choisir un backend différent de celui qui conservait l’état TCP. Cloudflare écrivit que c’était précisément ce qui s’était produit.

Le billet ne parle que de quelques utilisateurs reliés par des tunnels IPv6. Il ne mesure donc ni un taux mondial de panne ni un préjudice général. Il prouve un mécanisme plus circonscrit : un message de contrôle peut parvenir à la bonne organisation sans atteindre l’instance qui peut l’utiliser.

L’opérateur choisit d’abord une solution prudente. Il limita à 1280 le MTU de ses chemins IPv6 et activa, pour IPv4, le sondage de RFC 4821. Puis il développa un démon chargé de capter les erreurs IPv4 fragmentation needed et IPv6 Packet Too Big, et de les diffuser à tous les serveurs.

Le dépôt public prévoyait une limite d’un paquet par seconde pour une source et de dix par seconde sur une interface. Ces valeurs ne certifient pas la sécurité du dispositif. Elles montrent que la redistribution de la preuve ouvrait elle-même une surface de capacité et d’abus à gouverner.

En 1990, la petite taille n’était pas une solution gratuite

RFC 1191 définit le Path MTU comme le plus petit MTU rencontré entre une source et une destination. Ce minimum appartient à un chemin, pas à une adresse. Un changement de route, un tunnel ou une nouvelle encapsulation peut donc le modifier sans que le préfixe ou les deux machines ne changent.

Avant ce mécanisme, une pratique prudente consistait à retenir la plus petite valeur entre 576 octets et le MTU du premier saut. Elle évitait de parier sur un chemin inconnu, mais sous-utilisait les liens capables de transporter davantage. Et si un saut ultérieur était plus étroit, la fragmentation restait nécessaire.

La fragmentation IPv4 transférait du travail au réseau. Un routeur divisait le datagramme ; la destination devait réunir les fragments ; la perte d’un seul pouvait rendre l’ensemble inutilisable. Les textes ultérieurs ont aussi recensé les interactions fragiles avec les pare-feu à état, les tunnels et les chemins asymétriques.

Les choix contemporains étaient donc tous coûteux : envoyer petit, permettre la fragmentation, demander une information explicite au chemin, ou combiner ces voies. RFC 1191 choisit le retour d’information pour approcher la capacité réelle sans faire de la fragmentation intermédiaire un comportement ordinaire.

Une observation locale devait traverser tout le chemin inverse

Dans le mécanisme IPv4 classique, la source active Don't Fragment. Le routeur incapable de transmettre le datagramme sur son prochain lien le rejette et renvoie ICMP Destination Unreachable avec le code fragmentation needed.

RFC 1191 lui impose d’inscrire le next-hop MTU dans le message. La source doit alors réduire son estimation. Elle peut diminuer ses paquets ou cesser de mettre DF ; le routeur n’acquiert pas le droit de choisir la politique du transport.

Cette répartition est techniquement sobre et institutionnellement fragile. Le routeur possède la mesure directe d’une interface. L’extrémité possède l’algorithme de packetisation. Aucun ne peut réparer seul. Le message ICMP est le canal qui relie leur autorité respective.

Une augmentation exige davantage de prudence. L’extrémité ne doit jamais relever son estimation parce qu’un ICMP annonce une valeur supérieure. Elle doit sonder à nouveau, après un délai. RFC 1191 recommandait d’attendre au moins cinq minutes après une baisse, de préférence dix.

Ce sont des recommandations historiques, non un relevé des piles actuelles. Elles révèlent cependant le statut de la donnée : une estimation peut vieillir avec la route, et un message faux ou obsolète ne doit pas imposer une taille supérieure.

IPv6 a supprimé la fragmentation par les routeurs, pas l’incertitude

Le socle IPv6 exige que chaque lien puisse transporter 1280 octets ou fournisse en dessous d’IP son propre dispositif de fragmentation et de réassemblage. Un routeur IPv6 ne fragmente pas un paquet en transit. Seule la source peut ajouter un Fragment header.

RFC 8200 recommande fortement PMTUD afin d’exploiter des tailles supérieures à 1280. Une implémentation minimale peut aussi rester à 1280 ou moins. Cette option réduit la dépendance à la découverte, tout en renonçant aux gains possibles sur les chemins plus larges.

Avec RFC 8201, le routeur contraignant produit ICMPv6 Packet Too Big. Le destinataire du message doit vérifier que le paquet cité correspond bien à un trafic qu’il a envoyé. Il peut réduire son estimation, mais jamais sous le minimum IPv6 de 1280.

Le message ne peut pas servir à relever l’estimation. Après une baisse, la source pourra essayer plus grand, au plus une fois toutes les cinq minutes et de préférence toutes les dix. Le chemin rapporte une limite ; l’extrémité valide le contexte et garde la décision.

RFC 4890 classe Packet Too Big parmi les messages ICMPv6 qu’un pare-feu ne doit pas supprimer, car leur absence peut empêcher ou détériorer gravement les communications. Cette recommandation ne prouve pas qu’elle est appliquée partout et ne signifie pas que tout message ICMP doit être accepté sans contrôle.

Le trou noir est né de l’absence de preuve, non de l’absence de limite

RFC 2923 décrit en 2000 le PMTUD black hole déjà connu depuis longtemps. Un routeur, un défaut du noyau, une configuration ou un pare-feu empêche le retour de l’erreur ICMP. La source continue alors d’émettre une taille que le chemin rejette.

Le résultat est trompeur. Le handshake TCP, constitué de petits paquets, peut réussir. Les premiers échanges passent. Lorsqu’un segment plus grand apparaît, il disparaît et les retransmissions répètent le même choix. L’exemple FTP du document oppose un canal de commande fonctionnel à un transfert de masse bloqué.

Ce symptôme ne suffit pas à conclure. La congestion, une politique asymétrique ou une autre forme de perte peuvent imiter le même gel. Il faut enregistrer les tailles, la famille d’adresses, DF ou Fragment, les retransmissions et le contenu de tout message ICMP reçu.

Le Maximum Segment Size TCP ne donne pas la réponse complète. Il annonce ce que le récepteur accepte comme payload TCP. Il ne mesure pas chaque tunnel du trajet aller et le trajet retour peut être différent.

RFC 2923 préfère que l’on répare le passage de l’ICMP. La détection de trou noir à l’extrémité peut aussi réduire la taille après plusieurs timeouts. Elle rend parfois la session utilisable, mais ajoute des secondes et masque un défaut qui demeure pour les autres flux.

Le pouvoir de filtrer n’est pas le pouvoir de certifier le chemin

Un opérateur peut légitimement filtrer le trafic de son propre réseau. Les sources retenues ne permettent d’accuser aucun pare-feu, fournisseur ou participant de malveillance, d’illégalité ou de négligence volontaire.

La limite de ce pouvoir est plus simple. Supprimer Packet Too Big ne rend pas le paquet initial transmissible. Le filtre enlève une preuve tout en maintenant la contrainte. Il obtient donc un veto pratique sur l’adaptation sans posséder l’observation du routeur ni la responsabilité du transport.

Les tunnels ajoutent des en-têtes après le choix de taille. L’ECMP ou l’anycast peuvent dissocier l’identité de l’instance qui voit les données de celle qui reçoit l’erreur. Une valeur de MTU n’a de portée probante qu’avec une date, une direction, un flux, une route et une encapsulation.

Pour un titulaire de ressources de numérotation, cette distinction est déterminante. Un RIR alloue des adresses ; il ne garantit pas un MTU de bout en bout pour chaque route vers le titulaire. Le préfixe peut rester stable pendant qu’une modification de tunnel ou de répartition rend le service partiellement inaccessible.

Le sondage a redonné une porte de sortie à l’extrémité

RFC 4821 déplace en 2007 la production de preuve. PLPMTUD envoie des sondes de taille croissante et observe la confirmation ou la perte au niveau qui fabrique les paquets. Il peut progresser même lorsque l’ICMP ne revient jamais.

Le silence reste ambigu. La perte isolée d’une grande sonde peut signaler une limite. Si des paquets voisins sont également perdus, la congestion ou une autre cause empêche de conclure. L’algorithme a besoin d’un état de recherche, de délais et d’une manière prudente de retester.

La charte du groupe PMTUD de l’IETF présentait les faiblesses de l’ancien mécanisme comme un obstacle chronique aux nouveaux liens et tunnels. Elle proposait de commencer petit et de sonder vers le haut sans dépendre de l’ICMP. Elle atteste un mandat de travail, non un consensus mondial ni un déploiement achevé.

RFC 8899 adapte ensuite le principe aux couches de packetisation des datagrammes. DPLPMTUD teste une taille, la confirme grâce à une preuve de livraison et la réduit lorsqu’un trou noir est détecté. Un Packet Too Big validé peut aider, mais ne doit être ni l’unique source ni un moyen d’augmenter la taille.

UDP n’apporte pas lui-même d’accusé de réception. Le transport ou l’application doit donc produire la confirmation. L’autonomie de l’extrémité reporte sur le logiciel une partie du coût : sondes supplémentaires, mémoire d’état et interprétation de la perte.

Le résultat historique est une coexistence de mécanismes

La spécification TCP actuelle recommande fortement PMTUD et recommande PLPMTUD. Les petites tailles de repli subsistent, tandis que RFC 9293 rappelle leur coût possible en performance. Le nouveau procédé n’a pas rendu le retour ICMP inutile ; il lui a ajouté une voie de secours.

La documentation Linux actuelle expose ce choix. tcp_mtu_probing=0 désactive le sondage ; le mode 1 l’active après détection d’un trou noir ICMP ; le mode 2 le maintient actif à partir d’un base MSS configuré. L’intervalle documenté vaut dix minutes par défaut.

Ces paramètres ne mesurent pas les hôtes du monde. Ils prouvent que la traduction d’une norme en comportement reste une décision de produit et d’opérateur. Le verrouillage vient précisément de la coexistence de pare-feu, tunnels, noyaux et applications conçus à des moments différents.

RFC 8900 ne déclare donc pas la fragmentation abolie. Il en dresse les fragilités et demande aux couches supérieures d’en réduire la dépendance. La solution durable est composite : conserver le signal explicite, le valider, sonder en cas de silence et garder une taille prudente lorsque les deux échouent.