Résumé

  • Une option REQ porte un jeton de quatre octets ; EOL rembourre la sonde à la taille choisie et une option RES renvoie le jeton reçu.
  • La correspondance confirme une sonde, un 5-tuple, un chemin et un moment. ECMP et le multihoming imposent un état distinct, puis une validation périodique.
  • Un silence peut venir du chemin aller, mais aussi de l’attente d’un paquet retour, d’une limitation de débit ou de la perte de la réponse. Il ne suffit pas à déclarer la taille impossible.

Une preuve positive, bornée par sa question

Le mécanisme de RFC 9869 applique DPLPMTUD à UDP Options. L’émetteur inscrit un jeton dans REQ, utilise EOL et le rembourrage pour construire le datagramme d’essai, puis associe une option RES au même jeton. La sonde peut dépasser l’estimation PLPMTU courante sans dépasser le MTU de l’interface ; elle ne doit pas être fragmentée par IP.

La réponse correspondante établit que le récepteur UDP Options a reçu cette sonde. Elle ne constitue pas un reçu de l’application. Elle ne prouve ni l’acceptation des données, ni la taille praticable sur le chemin retour, ni la stabilité de la route. Même taille et mêmes adresses ne garantissent pas que le paquet suivant prendra le même chemin.

Les sondes qui cherchent à augmenter la PLPMTU ne devraient donc pas transporter de données applicatives : leur perte fait partie de l’expérience. Une sonde sans charge utile n’est pas livrée à la couche supérieure. Des données applicatives peuvent participer à une confirmation ou à une validation, pas à la hausse initiale.

Le jeton délimite l’autorité de la réponse

Le jeton doit rester unique pour le 5-tuple pendant la durée MSL et ne doit pas être réutilisé dans cette fenêtre. Une valeur initiale aléatoire et une suite imprévisible réduisent la capacité d’un tiers hors chemin à fabriquer une réponse crédible. Elles ne remplacent pas le contexte : taille testée, horodatages, adresses et ports, chemin, tentative, état et version logicielle.

L’activation explicite fait également partie de la preuve. Les applications des deux extrémités doivent activer le service, et le récepteur ne doit pas répondre avant cette activation. Si la couche transport et un protocole supérieur exécutent tous deux une découverte, leurs jetons doivent être coordonnés ou séparés. Une réponse authentique mais attribuée au mauvais automate corrompt la mesure.

RFC 9869 vise surtout l’unicast et exclut le multicast. Il permet une réponse sans charge utile, soumise à une limitation de débit afin que la confirmation ne devienne pas une ressource illimitée.

La route mesurée ne représente pas ses voisines

Avec ECMP, plusieurs chemins ou plusieurs interfaces, le RFC exige un état DPLPMTUD par chemin. La contrainte est logique : la liaison limitante et ses politiques n’appartiennent pas au nom du serveur, mais au trajet effectivement emprunté. Recopier une PLPMTU sur un autre trajet supprime précisément la dimension que la mesure devait découvrir.

Le temps agit de la même manière. Une route peut changer et une limitation peut apparaître ou disparaître. La validation périodique n’est donc pas un simple entretien ; elle empêche une réussite historique d’autoriser indéfiniment de nouveaux envois. Les RFC 1191, 8085 et 8201 rappellent cette variabilité des chemins.

Le retour peut réduire la taille apparente

Un récepteur peut attendre un datagramme retour déjà prévu pour y joindre RES. Si plusieurs sondes arrivent entre-temps, seule la plus récente peut être accusée. Les précédentes semblent alors perdues, bien qu’elles aient franchi le chemin aller. Quand le trafic retour est rare, l’émetteur peut rester à une taille inférieure à la capacité réelle, voire à la PLPMTU minimale.

Une réponse dédiée accélère l’automate, mais elle est limitée en débit. Un délai d’attente agrège donc plusieurs causes : perte de la sonde, politique de retour, file d’attente, limitation ou perte sur le chemin inverse. Il indique une incertitude exploitable par l’automate, pas une explication unique.

Le traitement d’un message ICMP Packet Too Big reste facultatif. S’il est utilisé, le protocole cité doit être validé et le jeton REQ devrait l’être quand c’est possible. Un message invérifiable doit être ignoré. L’imprévisibilité protège surtout contre l’injection hors chemin ; un acteur situé sur le chemin conserve le pouvoir de bloquer ou modifier les paquets.

Sources