Résumé

  • L’acquittement d’une sonde confirme que ce paquet identifié, à cette taille, a atteint la couche de mise en paquets distante sur le chemin observé.
  • La RFC 8201 traite la MTU de chemin comme une donnée variable ; la RFC 8899 prévoit une nouvelle confirmation et un état par chemin en cas de multipath ou de multihoming.
  • Une attestation exploitable doit relier résultat, extrémités, identité de flux ou de chemin, surcharge d’encapsulation, retour de sonde, heure et livraison réelle.

Une réussite ponctuelle sur un chemin mouvant

Un service envoie une sonde rembourrée à 1 450 octets. Le destinataire acquitte précisément cette sonde et l’émetteur augmente sa PLPMTU. Peu après, un datagramme applicatif de même taille est affecté à un autre membre ECMP. Ce membre ajoute davantage d’encapsulation ou traverse un lien plus contraint ; le paquet ne passe plus.

La première mesure reste vraie. Elle décrit la livraison d’un paquet identifié sur le chemin emprunté à cet instant. Elle ne certifie ni les membres parallèles, ni une route future, ni une nouvelle pile d’en-têtes. Résumer cette observation par un voyant « MTU OK » efface exactement les conditions qui lui donnent son sens.

Ce que maintient réellement la PMTUD IPv6

La RFC 8201 définit la PMTU comme la plus petite MTU de lien sur le chemin entre une source et une destination. La source peut partir de la MTU du premier saut, puis réduire son estimation après validation d’un message ICMPv6 Packet Too Big. Plusieurs cycles peuvent être nécessaires si une contrainte plus faible se trouve plus loin.

Cette valeur est temporelle. Une modification de topologie peut changer la PMTU ; les baisses sont signalées par des PTB et les hausses doivent être recherchées périodiquement. Après une réduction, la RFC 8201 recommande de ne pas tenter une hausse plus d’une fois toutes les cinq minutes. Une valeur en cache est donc une estimation assortie d’un vieillissement, non une propriété permanente du destinataire.

Même validé, un PTB indique une contrainte rencontrée par l’échange auquel il correspond. Il n’identifie pas à lui seul le changement de route, le tunnel responsable de la surcharge ou l’homogénéité des chemins parallèles.

La portée de l’acquittement positif

La RFC 8899 place la découverte au niveau de la couche de mise en paquets pour les transports par datagrammes. La réponse doit montrer que la sonde précise a atteint l’extrémité distante. Après acquittement, la taille testée peut devenir la PLPMTU courante.

Cette preuve est meilleure qu’une réussite déduite du silence, mais elle reste circonscrite. La perte d’une seule sonde ne suffit pas : congestion, erreur ou réordonnancement sont possibles. Inversement, une sonde reçue ne transforme pas l’état Search Complete en garantie perpétuelle. Quand la couche ne fournit pas d’autre preuve de livraison, un temporisateur de confirmation sert à vérifier que la taille reste utilisable.

Le texte exige aussi une robustesse face aux changements de chemin, aux informations incohérentes, au retard, à la duplication et au partage du trafic entre plusieurs chemins. En présence de multipath ou de multihoming, un automate par chemin est nécessaire. Il ne s’agit donc jamais d’un simple feu vert attaché au nom de destination.

Taille de paquet et budget d’en-têtes

La PLPMTU n’est pas le volume utile de l’application. Les en-têtes IP, transport, sécurité et tunnel consomment une partie du budget. Une nouvelle encapsulation peut réduire la taille maximale du message sans modifier la MTU physique du lien.

La taille maximale exposée à l’application peut changer après une modification de chemin ou des pertes de sonde. Il faut donc noter le niveau auquel la taille a été mesurée et les en-têtes présents. De même, des pertes corrélées à une taille justifient une réaction prudente, mais ne prouvent pas à elles seules que la MTU est la cause de l’incident.

Sources