6.2 Storing PMTU Information (Stockage des informations PMTU)
6.2 Storing PMTU Information (Stockage des informations PMTU)
En général, la couche IP devrait associer chaque valeur PMTU qu'elle a apprise avec un chemin spécifique. Un chemin est identifié par une adresse source, une adresse de destination et un IP type-of-service (type de service). (Certaines implémentations n'enregistrent pas l'adresse source des chemins; ceci est acceptable pour les hôtes mono-hébergés, qui n'ont qu'une seule adresse source possible.)
Note: Certains chemins peuvent être davantage distingués par différentes classifications de sécurité. Les détails de telles classifications dépassent le cadre de ce mémorandum.
L'endroit évident pour stocker cette association est comme un champ dans les entrées de table de routage. Un hôte n'aura pas de route pour chaque destination possible, mais il devrait être capable de mettre en cache une route par hôte pour chaque destination active. (Cette exigence est déjà imposée par la nécessité de traiter les messages ICMP Redirect (redirection).)
Lorsque le premier paquet est envoyé à un hôte pour lequel aucune route par hôte n'existe, une route est choisie soit dans l'ensemble des routes par réseau, soit dans l'ensemble des routes par défaut. Les champs PMTU dans ces entrées de route devraient être initialisés au MTU de la liaison de données du premier saut associée, et ne doivent jamais être changés par le processus de PMTU Discovery. (PMTU Discovery crée ou change uniquement les entrées pour les routes par hôte). Jusqu'à ce qu'un message Datagram Too Big soit reçu, le PMTU associé à la route initialement choisie est présumé être précis.
Lorsqu'un message Datagram Too Big est reçu, la couche ICMP détermine une nouvelle estimation pour le Path MTU (soit à partir d'une valeur Next-Hop MTU non nulle dans le paquet, soit en utilisant la méthode décrite dans la section 5). Si une route par hôte pour ce chemin n'existe pas, alors une est créée (presque comme si une redirection ICMP par hôte était en cours de traitement; la nouvelle route utilise le même routeur de premier saut que la route actuelle). Si l'estimation PMTU associée à la route par hôte est supérieure à la nouvelle estimation, alors la valeur dans l'entrée de routage est changée.
Les couches de paquétisation doivent être notifiées des diminutions du PMTU. Toute instance de couche de paquétisation (par exemple, une connexion TCP) qui utilise activement le chemin doit être notifiée si l'estimation PMTU diminue.
Note: même si le message Datagram Too Big contient un Original Datagram Header (en-tête de datagramme original) qui fait référence à un paquet UDP, la couche TCP doit être notifiée si l'une de ses connexions utilise le chemin donné.
De plus, l'instance qui a envoyé le datagramme qui a suscité le message Datagram Too Big devrait être notifiée que son datagramme a été abandonné, même si l'estimation PMTU n'a pas changé, afin qu'elle puisse retransmettre le datagramme abandonné.
Note: Le mécanisme de notification peut être analogue au mécanisme utilisé pour fournir la notification d'un message ICMP Source Quench (limitation de source). Dans certaines implémentations (telles que les systèmes dérivés de 4.2BSD), le mécanisme de notification existant n'est pas capable d'identifier la connexion spécifique impliquée, et donc un mécanisme supplémentaire est nécessaire.
Alternativement, une implémentation peut éviter l'utilisation d'un mécanisme de notification asynchrone pour les diminutions PMTU en reportant la notification jusqu'à la prochaine tentative d'envoi d'un datagramme plus grand que l'estimation PMTU. Dans cette approche, lorsqu'une tentative est faite d'ENVOYER un datagramme avec le bit DF défini, et que le datagramme est plus grand que l'estimation PMTU, la fonction SEND devrait échouer et retourner une indication d'erreur appropriée. Cette approche peut être plus appropriée pour une couche de paquétisation sans connexion (comme une utilisant UDP), qui (dans certaines implémentations) peut être difficile à "notifier" depuis la couche ICMP. Dans ce cas, les mécanismes de retransmission normaux basés sur le délai d'attente seraient utilisés pour récupérer des datagrammes abandonnés.
Il est important de comprendre que la notification des instances de couche de paquétisation utilisant le chemin du changement dans le PMTU est distincte de la notification d'une instance spécifique qu'un paquet a été abandonné. Cette dernière devrait être faite dès que possible (c'est-à-dire, de manière asynchrone du point de vue de l'instance de couche de paquétisation), tandis que la première peut être retardée jusqu'à ce qu'une instance de couche de paquétisation veuille créer un paquet. La retransmission ne devrait être effectuée que pour les paquets qui sont connus pour avoir été abandonnés, comme indiqué par un message Datagram Too Big.