5.2 Storing PMTU Information (Stockage des informations PMTU)

5.2 Stockage des informations PMTU

Idéalement, une valeur PMTU devrait être associée à un chemin spécifique emprunté par les paquets échangés entre les nœuds source et destination. Cependant, dans la plupart des cas, un nœud n'aura pas suffisamment d'informations pour identifier complètement et avec précision un tel chemin. Au lieu de cela, un nœud doit associer une valeur PMTU à une représentation locale d'un chemin. Il appartient à l'implémentation de sélectionner la représentation locale d'un chemin. Pour les nœuds avec plusieurs interfaces, les informations de MTU de chemin devraient être maintenues pour chaque liaison IPv6.

Dans le cas d'une adresse de destination multicast, des copies d'un paquet peuvent traverser de nombreux chemins différents pour atteindre de nombreux nœuds différents. La représentation locale du "chemin" vers une destination multicast doit représenter un ensemble potentiellement large de chemins.

Au minimum, une implémentation pourrait maintenir une seule valeur PMTU à utiliser pour tous les paquets provenant du nœud. Cette valeur PMTU serait le PMTU minimum appris dans l'ensemble de tous les chemins utilisés par le nœud. Cette approche est susceptible d'entraîner l'utilisation de paquets plus petits que nécessaire pour de nombreux chemins. Dans le cas du routage multi-chemin (par exemple, Equal-Cost Multipath Routing, ECMP), un ensemble de chemins peut exister même pour une seule paire source-destination.

Une implémentation pourrait utiliser l'adresse de destination comme représentation locale d'un chemin. La valeur PMTU associée à une destination serait le PMTU minimum appris dans l'ensemble de tous les chemins utilisés vers cette destination. Cette approche entraînera l'utilisation de paquets de taille optimale sur une base par destination. Cette approche s'intègre bien avec le modèle conceptuel d'un hôte tel que décrit dans [ND] : une valeur PMTU pourrait être stockée avec l'entrée correspondante dans le cache de destination.

Si des flux [RFC8200] sont utilisés, une implémentation pourrait utiliser l'identifiant de flux comme représentation locale d'un chemin. Les paquets envoyés vers une destination particulière mais appartenant à différents flux peuvent utiliser différents chemins, comme avec ECMP, où le choix du chemin peut dépendre de l'identifiant de flux. Cette approche pourrait entraîner l'utilisation de paquets de taille optimale sur une base par flux, fournissant une granularité plus fine que les valeurs PMTU maintenues sur une base par destination.

Pour les paquets routés à la source (c'est-à-dire les paquets contenant un en-tête de routage IPv6 [RFC8200]), la route source peut qualifier davantage la représentation locale d'un chemin.

Initialement, la valeur PMTU pour un chemin est supposée être le MTU (connu) de la liaison du premier saut.

Lorsqu'un message Packet Too Big est reçu, le nœud détermine à quel chemin le message s'applique en fonction du contenu du message Packet Too Big. Par exemple, si l'adresse de destination est utilisée comme représentation locale d'un chemin, l'adresse de destination du paquet d'origine serait utilisée pour déterminer à quel chemin le message s'applique.

Note : si le paquet d'origine contenait un en-tête de routage, l'en-tête de routage devrait être utilisé pour déterminer l'emplacement de l'adresse de destination dans le paquet d'origine. Si Segments Left est égal à zéro, l'adresse de destination est dans le champ Destination Address de l'en-tête IPv6. Si Segments Left est supérieur à zéro, l'adresse de destination est la dernière adresse (Address[n]) dans l'en-tête de routage.

Le nœud utilise ensuite la valeur dans le champ MTU du message Packet Too Big comme valeur PMTU provisoire ou le MTU de liaison minimum IPv6 si celui-ci est plus grand, et compare le PMTU provisoire au PMTU existant. Si le PMTU provisoire est inférieur à l'estimation PMTU existante, le PMTU provisoire remplace le PMTU existant comme valeur PMTU pour le chemin.

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 du PMTU est diminuée.

Note : même si le message Packet Too Big contient un en-tête de paquet d'origine 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 paquet qui a suscité le message Packet Too Big devrait être notifiée que son paquet a été rejeté, même si l'estimation du PMTU n'a pas changé, afin qu'elle puisse retransmettre les données rejetées.

Note : Une implémentation peut éviter l'utilisation d'un mécanisme de notification asynchrone pour les diminutions de PMTU en reportant la notification jusqu'à la prochaine tentative d'envoi d'un paquet plus grand que l'estimation du PMTU. Dans cette approche, lorsqu'une tentative est faite pour ENVOYER un paquet plus grand que l'estimation du 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 (telle qu'une utilisant UDP), qui (dans certaines implémentations) peut être difficile à "notifier" depuis la couche ICMPv6. 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 paquets rejetés.

Il est important de comprendre que la notification des instances de couche de paquétisation utilisant le chemin concernant le changement du PMTU est distincte de la notification d'une instance spécifique qu'un paquet a été rejeté. Cette dernière devrait être effectuée 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 souhaite créer un paquet.