Découverte de la MTU de chemin

Statut du document

Le présent mémoire décrit un projet de norme pour la communauté de l'Internet. Il invite à des discussions et suggestions d'amélioration. La présente RFC spécifie un protocole en cours de normalisation par l'IAB pour la communauté de l'Internet. Prière de se référer à l'édition la plus récente des "Normes de protocole officielles de l'IAB" pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Table des Matières

1.   Introduction

2.   Généralités sur le protocole

3.   Spécification de l'hôte

3.1   Option MSS de TCP

4.   Spécification du routeur

5.   Traitement des messages d'ancien style par l'hôte

6.   Mise en œuvre d'hôte

6.1   Mise en couches

6.2   Mémorisation des informations de PMTU

6.3   Purge des informations de PMTU périmées

6.4   Actions de la couche TCP

6.5   Problèmes pour les autres protocoles de transport

6.6   Interface de gestion

7.   Valeurs vraisemblables des MTU de chemin

7.1   Un meilleur moyen pour détecter les accroissements de PMTU

8.   Considérations pour la sécurité

Résumé

Le présent mémoire décrit une technique pour découvrir de façon dynamique l'unité de transmission maximum (MTU, maximum transmission unit) d'un chemin internet arbitraire. Il spécifie un petit changement de la façon dont les routeurs génèrent un type de message ICMP. Pour un chemin qui passe à travers un routeur qui n'a pas subi la modification, cette technique pourrait ne pas découvrir la MTU de chemin correcte, mais elle va toujours choisi une MTU de chemin aussi précise, et dans de nombreux cas, plus précise, que la MTU de chemin qui aurait été choisie par les pratiques actuelles.

Remerciements

La présente proposition a été produite par le groupe de travail Découverte de MTU de l'IETF.

Le mécanisme proposé ici a été d'abord suggéré par Geof Cooper [2], qui en deux courts paragraphes a jeté les bases des idées qu'il aura fallu des mois au groupe de travail pour réinventer.

1.   Introduction

Lorsqu'un hôte IP a une grande quantité de données à envoyer à un autre hôte, les données sont transmises sous la forme d'une série de datagrammes IP. Il est généralement préférable que ces datagrammes soient de la plus grande taille qui n'exige pas de fragmentation à quelque endroit du chemin allant de la source à la destination. (Pour le procès de la fragmentation, voir [5].) Cette taille de datagramme est appelée la MTU de chemin (PMTU, Path MTU), et elle est égale au minimum des MTU de chacun des bonds du chemin. Une des insuffisances de la suite des protocoles actuels de l'Internet est l'absence d'un mécanisme standard pour qu'un hôte découvre la PMTU d'un chemin arbitraire.

Note : La MTU de chemin est ce qui dans [1] est appelé la "MTU efficace d'envoi " (EMTU_S). Une PMTU est associée à un chemin, qui est une combinaison particulière d'adresses IP de source et de destination et peut-être de Type de service (TOS).

La pratique actuelle de [1] est d'utiliser le plus petit de 576 et de la MTU du premier bond comme PMTU pour toute destination qui n'est pas connectée au même réseau ou sous-réseau que la source. Dans de nombreux cas, il en résulte une utilisation de datagrammes plus petits que nécessaire, parce que de nombreux chemins ont une PMTU supérieure à 576. Un hôte qui envoie des datagrammes beaucoup plus petits que la MTU de chemin ne le permet gaspille les ressources de l'Internet et obtient probablement un débit sous optimal. De plus, les pratiques actuelles n'empêchent pas la fragmentation dans tous les cas, car il y a certains chemins dont la PMTU est inférieure à 576.

On s'attend à ce que les futurs protocoles d'acheminement soient capables de fournir des informations de PMTU précises sur une zone d'acheminement, quoique peut-être pas à travers les hiérarchies d'acheminement multi niveaux. On ne sait pas clairement quand ceci sera partout disponible, aussi, pour les prochaines années, l'Internet a besoin d'un mécanisme simple qui découvre les PMTU sans gaspiller de ressources et qui fonctionne avant que tous les hôtes et routeurs ne soient modifiés.

2.   Généralités sur le protocole

Dans ce mémoire, on décrit une technique d'utilisation du bit Ne pas fragmenter (DF, Don't Fragment) dans l'en-tête IP pour découvrir de façon dynamique la PMTU d'un chemin. L'idée de base est qu'un hôte de source suppose initialement que la PMTU d'un chemin est la MTU (connue) de son premier bond, et qu'il envoie tous les datagrammes sur ce chemin avec le bit DF mis. Si un des datagrammes est trop grand pour être transmis sans fragmentation par un routeur le long du chemin, ce routeur va l'éliminer et retourner un message ICMP Destination injoignable avec un code signifiant "fragmentation nécessaire et DF mis" [7]. À réception d'un tel message (qu'on appellera désormais un message "Datagramme trop gros"), l'hôte de source réduit son hypothèse de PMTU pour le chemin.

Le processus de découverte de PMTU se termine lorsque l'estimation de PMTU de l'hôte est assez basse pour que ses datagrammes soient délivrés sans fragmentation. Ou bien, l'hôte peut choisir de mettre fin au processus de découverte en cessant d'établir le bit DF dans les en-têtes de datagramme ; il peut faire ainsi, par exemple, parce qu'il veut que dans certaines circonstances des datagrammes soient fragmentés. Normalement, l'hôte continue de mettre DF dans tous les datagrammes, de sorte que si le chemin change et que la nouvelle PMTU est inférieure, cela soit découvert.

Malheureusement, le message Datagramme trop gros, tel qu'il est spécifié actuellement, ne renseigne pas sur la MTU du bond pour lequel le datagramme rejeté est trop gros, de sorte que l'hôte de source ne peut pas dire exactement de combien il doit réduire son hypothèse de PMTU. Pour remédier à cela, on propose qu'un champ d'en-tête actuellement non utilisé dans le message Datagramme trop gros soit utilisé pour renseigner sur la MTU du bond qui bloque. C'est le seul changement spécifié pour les routeurs à l'appui de la découverte de la PMTU.

La PMTU d'un chemin peut changer avec le temps, du fait de changements dans la topologie d'acheminement. Les réductions de la PMTU sont détectés par les messages Datagramme trop gros, sauf sur les chemins pour lesquels l'hôte a arrêté d'établir le bit DF. Pour détecter les accroissements de la PMTU d'un chemin, un hôte augmente périodiquement son hypothèse de PMTU (et s'il l'avait arrêté, il reprend l'établissement du bit DF). Il en résultera presque toujours l'élimination de datagrammes et la génération de messages Datagramme trop gros, parce que dans la plupart des cas, la PMTU du chemin n'aura pas changé, aussi cela ne devrait pas être fait très fréquemment.

Comme ce mécanisme garantit essentiellement que l'hôte ne recevra aucun fragment d'un homologue qui pratique la découverte de PMTU, il peut aider à l'interfonctionnement avec certains hôtes qui (à tort) sont incapables de réassembler les datagrammes fragmentés.

3.   Spécification de l'hôte

Lorsque un hôte reçoit un message Datagramme trop gros, il DOIT réduire son estimation de la PMTU pour le chemin en question, sur la base de la valeur du champ MTU du prochain bond (Next-Hop MTU) dans le message (voir la section 4). On ne spécifie pas le comportement précis d'un hôte dans ces circonstance, car des applications différentes peuvent avoir des exigences différentes, et parce que des architectures de mise en œuvre différentes peuvent préférer des stratégies variées.

On exige effectivement qu'après avoir reçu un message Datagramme trop gros, un hôte DOIT essayer d'éviter de s'attirer d'autres messages comme celui là dans un avenir proche. L'hôte peut soit réduire la taille des datagrammes qu'il envoie sur ce chemin, soit cesser de mettre le bit Ne pas fragmenter dans les en-têtes de ces datagrammes. En clair, l'ancienne stratégie peut continuer de s'attirer des messages Datagramme trop gros pendant un petit moment, mais comme chacun de ces messages (et les datagrammes abandonnées auxquels ils répondent) consomme des ressources de l'Internet, l'hôte DOIT forcer la convergence du processus de découverte de PMTU.

Les hôtes qui utilisent la découverte de PMTU DOIVENT détecter les diminutions de MTU de chemin aussi vite que possible. Les hôtes PEUVENT détecter les augmentations de MTU de chemin, comme pour ce faire, il faut envoyer des datagrammes plus grands que l'estimation actuelle de PMTU, et parce qu'il est vraisemblable que la PMTU ne va pas augmenter, cela DOIT n'être fait qu'à des intervalles peu fréquents. Une tentative de détecter une augmentation (par l'envoi d'un datagramme plus grand que l'estimation actuelle) NE DOIT PAS être faite moins de 5 minutes après la réception d'un message Datagramme trop gros pour la destination en cause, ou moins d'une minute après une tentative précédente réussie d'augmentation. On recommande de régler ces temporisations à deux fois leurs valeurs minimum (respectivement 10 minutes et 2 minutes).

Les hôtes DOIVENT être capables de traiter les messages Datagramme trop gros qui ne comportent pas la MTU du prochain bond, dans la mesure où il n'est pas possible de mettre à niveau dans un délai défini tous les routeurs de l'Internet. Un message Datagramme trop gros provenant d'un routeur non modifié peut se reconnaître par la présence d'un zéro dans le champ MTU du prochain bond (nouvellement défini). (Ceci est exigé par la spécification ICMP [7], qui dit que les champs "inutilisés" doivent être à zéro.) À la section 5, on expose les stratégies possibles que peut suivre un hôte en réponse à un message Datagramme trop gros du vieux style (envoyé par un routeur non modifié).

Un hôte NE DOIT PAS réduire son estimation de la MTU de chemin en dessous de 68 octets.

Un hôte NE DOIT PAS augmenter son estimation de la MTU de chemin en réponse au contenu d'un message Datagramme trop gros. Un message visant à annoncer une augmentation de la MTU de chemin pourrait être un datagramme périmé qui a circulé ça et là dans l'Internet, un paquet falsifié injecté au titre d'une attaque de déni de service, ou le résultat de l'existence de chemins multiples vers la destination.

3.1   Option MSS de TCP

Un hôte qui effectue la découverte de PMTU doit obéir à la règle qu'il n'envoie pas de datagrammes IP plus gros que 576 octets à moins qu'il n'ait la permission du receveur de le faire. Pour les connexions TCP, cela signifie qu'un hôte ne doit pas envoyer de datagrammes supérieurs à 40 octets plus la taille de segment maximum (MSS, Maximum Segment Size) envoyé par son homologue.

Note : La MSS de TCP est définie comme étant la taille pertinente du datagramme IP moins 40 [9]. La valeur par défaut de 576 octets comme taille maximum de datagramme IP donne une valeur par défaut de 536 octets pour la MSS de TCP.

Le paragraphe 4.2.2.6 des "Exigences pour les hôtes Internet – Couche de communication" [1] dit :

"Certaines mises en œuvre de TCP n'envoient une option MSS que si l'hôte de destination est sur un réseau non connecté. Cependant, en général la couche TCP peut n'avoir pas les informations appropriées pour prendre cette décision, de sorte qu'il est préférable de laisser à la couche IP la tâche de déterminer une MTU convenable pour le chemin Internet."

En fait, de nombreuses mises en œuvres TCP envoient toujours une option MSS, mais établissent la valeur 536 si la destination n'est pas locale. Ce comportement était correct lorsque l'Internet était plein d'hôtes qui ne suivaient pas la règle que les datagrammes supérieurs à 576 octets ne devraient pas être envoyés à des destinations non locales. Maintenant que la plupart des hôtes suivent bien cette règle, il n'est plus nécessaire de limiter la valeur dans l'option TCP MSS à 536 pour les homologues non locaux.

De plus, faire ainsi empêche la découverte de PMTU de découvrir des PMTU supérieures à 576, de sorte que les hôtes NE DEVRAIENT PLUS diminuer la valeur qu'ils envoient dans l'option MSS. L'option MSS devrait être de 40 octets inférieure à la taille du plus gros datagramme que l'hôte est capable de réassembler (MMS_R, comme défini dans [1]) ; dans de nombreux cas, ce sera la limite architecturale de 65 495 (65 535 - 40) octets. Un hôte PEUT envoyer une valeur de MSS déduite de la MTU de son réseau connecté (La MTU maximum sur ses réseaux connectés pour un hôte multi rattachement) ; cela ne devrait pas poser de problèmes pour la découverte de PMTU, et peut dissuader un homologue déficient d'envoyer d'énormes datagrammes.

Note : Pour le moment, on ne voit pas de raison d'envoyer un MSS supérieur à la MTU maximum des réseaux connectés, et on recommande que les hôtes n'utilisent pas 65 495. Il est fort possible que certaines mises en œuvre IP aient des fautes de bits de signe qui seraient réveillées par une utilisation inutile de MSS aussi grande.

4.   Spécification du routeur

Lorsqu'un routeur est incapable de transmettre un datagramme parce qu'il dépasse la MTU du réseau du prochain bond et que son bit Ne pas fragmenter est mis, le routeur est obligé de retourner un message ICMP Destination injoignable à la source du datagramme, avec le code indiquant "fragmentation nécessaire et DF mis". Pour prendre en charge la technique de découverte de MTU de chemin spécifiée dans le présent mémoire, le routeur DOIT inclure la MTU de ce réseau de prochain bond dans les 16 bits de moindre poids du champ d'en-tête ICMP qui est marqué "inutilisé" dans la spécification ICMP [7]. Les 16 bits de poids fort restent inutilisés, et DOIVENT être mis à zéro. Et donc, le message a le format suivant :

La valeur portée dans le champ MTU du prochain bond est la taille en octets du plus grand datagramme qui puisse être transmis, avec le chemin du datagramme original, sans fragmentation par ce routeur. La taille inclut l'en-tête IP et les données IP, et n'inclut aucun en-tête de niveau inférieur.

Ce champ ne contiendra jamais une valeur inférieure à 68, car chaque routeur "doit être capable de transmettre un datagramme de 68 octets sans fragmentation" [8].

5.   Traitement des messages d'ancien style par l'hôte

Dans cette section, on expose plusieurs stratégies possibles pour un hôte à réception d'un message Datagramme trop gros de la part d'un routeur non modifié (c'est-à-dire, celui dont le champ MTU du prochain bond est à zéro). Cette section ne fait pas partie de la spécification du protocole.

La chose la plus simple à faire pour un hôte en réponse à un tel message est de supposer que la PMTU est au minimum de son hypothèse de PMTU actuelle et de 576, et d'arrêter de mettre le bit DF dans les datagrammes qu'il envoie sur ce chemin. Et donc, l'hôte retombe à la même PMTU qu'il aurait choisie avec les pratiques actuelles (voir le paragraphe 3.3.3 de "Exigences pour les hôtes de l'Internet – Couches de communication" [1]). Cette stratégie a l'avantage qu'elle se termine rapidement, et ne fait pas pire que la pratique existante. Elle échoue cependant à éviter la fragmentation dans certains cas, et à faire l'utilisation la plus efficace de l'inter réseau dans d'autres cas.

Des stratégies plus sophistiquées impliquent une "recherche" d'une estimation précise de PMTU, en continuant à envoyer des datagrammes avec le bit DF, tout en variant leur taille. Une bonne stratégie de recherche est celle qui obtient une estimation précise de la MTU de chemin sans causer la perte de nombreux paquets dans le processus. Plusieurs stratégies possibles appliquent des fonctions algorithmiques à l'estimation de PMTU précédente pour générer une nouvelle estimation. Par exemple, on peut multiplier la vieille estimation par une constante (disons, 0,75). On ne RECOMMANDE PAS cela ; cela converge beaucoup trop lentement , ou cela sous-estime considérablement la vraie PMTU.

Une approche plus sophistiquée est de faire une recherche binaire sur la taille de paquet. Cela converge un peu plus vite, bien que cela mette 4 ou 5 étapes pour converger d'une MTU FDDI à une MTU Ethernet. Un sérieux inconvénient est que cela exige une mise en œuvre complexe afin de reconnaître quand un datagramme a fait le chemin jusqu'à l'autre extrémité (ce qui indique que l'estimation actuelle est trop basse). On ne recommande pas non plus cette stratégie.

Une stratégie qui paraît fonctionner assez bien commence à partir de l'observation qu'il y a, en pratique, assez peu de valeurs de MTU qui sont utilisées dans l'Internet. Et donc, plutôt que de chercher à l'aveugle à travers des valeurs choisies arbitrairement, on peut chercher seulement celles qui ont une probabilité d'apparaître. De plus, comme les concepteurs ont tendance à choisir les MTU de façon similaire, il est possible de collecter des groupes de valeurs de MTU similaires et d'utiliser la plus faible valeur du groupe comme "plateau" de la recherche. (Il est clair qu'il vaut mieux sous estimer une MTU de quelques pour cent que de la surestimer d'un octet.)

À la section 7, on décrit comment on est arrivé à un tableau des plateaux de MTU représentatives à utiliser dans une estimation de PMTU. Avec ce tableau, la convergence est aussi bonne qu'une recherche binaire dans le plus mauvais cas, et elle est bien meilleure dans les cas courants (par exemple, cela ne prend que le temps de deux allers-retours pour passer d'une MTU de FDDI à une MTU d'Ethernet). Comme les plateaux s'étalent sur une puissance de deux, si une MTU n'est pas représentée dans ce tableau, l'algorithme ne la sous estimera pas de plus qu'un facteur de 2.

Toute stratégie de recherche doit avoir une sorte de "mémoire" des estimations précédentes afin de choisir la prochaine. Une approche est d'utiliser les estimations de MTU de chemin actuellement en antémémoire, mais en fait, il y a de meilleures informations disponibles dans le message Datagramme trop gros lui-même. Tous les messages ICMP Destination injoignable, y compris celui-là, contiennent l'en-tête IP du datagramme original, qui contient la Longueur totale du datagramme qui était trop gros pour être transmis sans fragmentation. Comme cette Longueur totale peut être inférieure à l'estimation actuelle de PMTU, mais est néanmoins plus grande que la PMTU réelle, elle peut être une bonne entrée pour la méthode de choix de la prochaine estimation de PMTU.

Note : Les routeurs qui se fondent sur des mises en œuvre dérivées de l'Unix 4.2BSD envoient une valeur incorrecte pour la Longueur totale du datagramme IP original. La valeur envoyée par ces routeurs est la somme de la Longueur totale originale et de la Longueur d'en-tête original (exprimée en octets). Comme il est impossible à l'hôte qui reçoit un tel message Datagramme trop gros de savoir si il est envoyé par un de ces routeurs, l'hôte doit être prudent et supposer que c'est le cas. Si le champ Longueur totale retourné n'est pas inférieur à l'estimation de PMTU actuelle, elle doit être réduite de 4 fois la valeur du champ Longueur d'en-tête retourné.

La stratégie que nous recommandons alors est d'utiliser comme estimation de la prochaine PMTU la plus grande valeur de plateau qui est inférieure au champ Longueur totale retournée (corrigée, si nécessaire, selon la Note ci-dessus).

6.   Mise en œuvre d'hôte

Dans cette section, on expose comment est mise en œuvre la découverte de PMTU dans un logiciel d'hôte. Ce n'est pas une spécification, mais plutôt en ensemble de suggestions.

Les questions abordées sont :

-   Quelle couche ou couches mettent en œuvre la découverte de PMTU ?

-   Où sont mémorisées les informations de PMTU ?

-   Comment les informations de PMTU périmées sont-elles retirées ?

-   Que doivent faire les couches transport et au-dessus ?

6.1   Mise en couches

Dans l'architecture IP, le choix de la taille de datagramme à envoyer est fait par un protocole à une couche au dessus de IP. On appelle un tel protocole un "protocole de mise en paquet". Les protocoles de mise en paquet sont normalement des protocoles de transport (par exemple, TCP) mais ils peuvent aussi être des protocoles de couches supérieures (par exemple, des protocoles construits par dessus UDP).

La mise en œuvre de la découverte de PMTU dans les couches de mise en paquet simplifie certains des problèmes entre couches, mais a plusieurs inconvénients : la mise en œuvre peut devoir être refaite pour chaque protocole de mise en paquet, il devient difficile de partager les informations de PMTU entre les différentes couches de mise en paquet, et l'état orienté connexion entretenu par certaines couches de mise en paquet peut ne pas facilement s'étendre aux informations de PMTU sauvegardées pour de longues périodes.

Nous pensons donc que la couche IP devrait mémoriser les informations de PMTU et que la couche ICMP devrait traiter les messages Datagramme trop gros reçus. Les couches de mise en paquet doivent toujours être capables de répondre aux changement de MTU de chemin, en changeant la taille des datagrammes qu'elles envoient et doivent aussi être capables de spécifier que les datagrammes sont envoyés avec le bit DF mis. Nous ne voulons pas que la couche IP établisse simplement le bit DF dans chaque paquet, car il est possible qu'une couche de mise en paquet, peut-être une application UDP en dehors du noyau, soit incapable de changer sa taille de datagramme. Les protocoles qui impliquent une fragmentation intentionnelle, bien qu'inélégants, sont parfois efficaces (NFS en étant le principal exemple), et il n'est pas question de casser de tels protocoles.

Pour prendre en charge cette mise en couche, les couches de mise en paquet exigent une extension de l'interface de service IP définie dans [1] :

"Une façon d'apprendre les changements de la valeur de MMS_S, la "taille maximum de message de transport envoyé", qui est déduite de la MTU de chemin en soustrayant la taille minimum d'en-tête IP."

6.2   Mémorisation des informations de PMTU

En général, la couche IP devrait associer chaque valeur de PMTU qui est apprise à un chemin spécifique. Un chemin est identifié par une adresse de source, une adresse de destination et une type de service IP. (Certaines mises en œuvre n'enregistrent pas l'adresse de source des chemins ; ceci est acceptable pour les hôtes à rattachement unique, qui ont seulement une adresse de source possible.)

Note : Certains chemins peuvent être encore distingués par des classifications de sécurité différentes. Les détails d'une telle classification sortent du domaine d'application du présent mémoire.

L'endroit évident pour mémoriser cette association est un champ dans les entrées du tableau d'acheminement. Un hôte n'aura pas un chemin pour toutes les destinations possibles, mais il devrait être capable de mettre en antémémoire un chemin par hôte pour toutes les destinations actives. (Cette exigence s'impose déjà du fait du besoin de traiter les messages ICMP Redirect.)

Lorsque le premier paquet est envoyé à un hôte pour lequel n'existe pas encore de chemin, une route est choisie soit dans l'ensemble des chemins par hôte, soit dans l'ensemble des routes par défaut. Les champs PMTU de ces entrées de route devraient être initialisés avec la MTU de la liaison de données du premier bond qui y est associé, et ne doivent jamais être changés par le processus de découverte de PMTU. (La découverte de PMTU crée ou change les entrées seulement pour les chemins par hôte). Jusqu'à ce qu'un message Datagramme trop gros soit reçu, la PMTU associée à la route initialement choisie est supposée être adéquate.

Lorsque un message Datagramme trop gros est reçu, la couche ICMP détermine une nouvelle estimation pour la MTU de chemin (soit à partir d'une valeur de MTU de prochain bond différente de zéro dans le paquet, soit en utilisant la méthode décrite à la section 5). S'il n'existe pas de chemin par hôte, il en est créé un (presque comme si on traitait un Redirect ICMP par hôte ; le nouveau chemin utilise le même routeur de premier bond comme route actuelle). Si l'estimation de PMTU associée au chemin par hôte est plus élevée que la nouvelle estimation, la valeur de l'entrée d'acheminement est alors changée.

Les couches de mise en paquet doivent être notifiées des diminutions de la PMTU. Toute instance de couche de mise en paquet (par exemple, une connexion TCP) qui utilise activement le chemin doit être notifiée de la diminution de l'estimation de PMTU.

Note : Même si le message Datagramme trop gros contient un en-tête Datagramme d'origine qui se réfère à un paquet UDP, la couche TCP doit être notifiée de toute utilisation du chemin en question par une de ses connexions.

De plus, l'instance qui a envoyé le datagramme qui s'est attiré le message Datagramme trop gros devrait être avisée de l'abandon de son datagramme, même si l'estimation de la PMTU n'a pas changé, de sorte 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 Extinction de source. Dans certaines mises en œuvre (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, aussi un mécanisme supplémentaire est-il nécessaire.

Autrement, une mise en œuvre peut éviter d'utiliser un mécanisme de notification asynchrone pour les diminutions de PMTU en retardant la notification jusqu'à la prochaine tentative d'envoi d'un datagramme plus gros que l'estimation de PMTU. Dans cette approche, lorsque est faite une tentative d'ENVOI d'un datagramme avec le bit DF mis, et que le datagramme est plus gros que l'estimation de la PMTU, la fonction ENVOI (SEND) devrait échouer et retourner une indication d'erreur convenable. Cette approche peut mieux convenir à une couche de mise en paquet sans connexion (telle que celles qui utilisent UDP), qui (dans certaines mises en œuvre) peuvent être difficiles à "notifier" à partir de la couche ICMP. Dans ce cas, les mécanismes normaux de retransmission fondés sur l'existence d'une temporisation seraient utilisés pour récupérer de l'abandon des datagrammes.

Il est important de comprendre que la notification du changement de la PMTU aux instances de couche de mise en paquet en utilisant le chemin est distincte de la notification à une instance spécifique de l'abandon d'un paquet. Cette dernière devrait être faite aussitôt que possible en pratique (c'est-à-dire, en asynchrone du point de vue de l'instance), alors que la première peut être retardée jusqu'à ce qu'une instance de couche de mise en paquet veuille créer un paquet. La retransmission ne devrait être faite que pour les paquets dont on sait qu'ils sont abandonnés, comme indiqué par un message Datagramme trop gros.

6.3   Purge des informations de PMTU périmées

La topologie de l'Internet est dynamique ; les routes changent au fil du temps. La PMTU découverte pour une destination donnée peut devenir fausse si une nouvelle route vient à être utilisée. Et donc, les informations de PMTU mises en antémémoire par un hôte peuvent se périmer.

Comme un hôte qui utilise la découverte de PMTU établit toujours le bit DF, si la valeur de PMTU périmée est trop grande, cela sera découvert presque immédiatement lors de l'envoi d'un datagramme sur la destination en question. Il n'existe pas un tel mécanisme pour réaliser qu'une valeur de PMTU périmée est trop petite, de sorte qu'une mise en œuvre devrait "faire vieillir" ses valeurs en antémémoire. Lorsqu'une valeur de PMTU n'a pas été diminuée pendant un moment (de l'ordre de 10 minutes), l'estimation de PMTU devrait être réglée à la MTU de liaison de données de premier bond, et les couches de mise en paquet devrait être avisées du changement. Cela va causer un nouveau cycle complet du processus de découverte de PMTU.

Note : Une mise en œuvre devrait fournir le moyen de changer la durée de la temporisation, y compris la possibilité de la régler à "infini". Par exemple, les hôtes rattachés à un réseau FDDI qui se trouve rattaché au reste de l'Internet via une ligne série lente ne vont jamais découvrir une nouvelle PMTU non locale, de sorte qu'ils ne devraient pas avoir à faire avec un datagramme toutes les 10 minutes.

Une couche supérieure NE DOIT PAS retransmettre de datagrammes en réponse à un accroissement de l'estimation de la PMTU, car cette augmentation ne vient jamais en réponse à une indication d'abandon de datagramme.

Une approche de la mise en œuvre du vieillissement de PMTU est d'ajouter un champ d'horodatage à l'entrée de tableau d'acheminement. Ce champ est initialisé par une valeur "réservée", indiquant que la PMTU n'a jamais été changée. Chaque fois que la PMTU est diminuée en réponse à un message Datagramme trop gros, l'horodatage est réglé à l'heure en cours.

Une fois par minute, une procédure pilotée par un temporisateur traverse le tableau d'acheminement, et pour chaque entrée dont l'horodatage n'est pas "réservé" et est plus vieux que l'intervalle de temporisation :

-   l'estimation de la PMTU est réglée à la MTU du premier bond associé,

-   les couches de mise en paquet qui utilisent ce chemin sont avisées de l'augmentation.

Les estimations de PMTU peuvent disparaître du tableau d'acheminement si les chemins par hôte sont retirés ; cela peut arriver en réponse à un message ICMP Redirect, ou parce que certains démons de tableau d'acheminement suppriment les vieilles routes après plusieurs minutes. Et aussi, sur un hôte à rattachements multiples, un changement de topologie peut résulter en l'utilisation d'une interface de source différente. Lorsque cela arrive, si la couche de mise en paquet n'en a pas eu notification, elle peut continuer d'utiliser une valeur de PMTU maintenant trop petite qui figurait dans l'antémémoire. Une solution est de notifier à la couche de mise en paquet un changement possible de PMTU chaque fois qu'un message Redirect cause un changement de chemin, et chaque fois qu'une route est simplement supprimée du tableau d'acheminement.

Note : Une méthode plus sophistiquée pour détecter les augmentations de PMTU est décrite au paragraphe 7.1.

6.4   Actions de la couche TCP

La couche TCP doit garder trace de la PMTU pour la destination d'une connexion ; elle ne devrait pas envoyer de datagrammes qui soient plus grands qu'elle. Une mise en œuvre simple pourrait demander cette valeur à la couche IP (en utilisant l'interface GET_MAXSIZES décrite en [1]) chaque fois qu'elle crée un nouveau segment, mais cela pourrait être inefficace. De plus, les mises en œuvre TCP qui suivent l'algorithme d'évitement d'encombrement "démarrage lent" [4] calculent et mettent normalement en antémémoire plusieurs autres valeurs dérivées de la PMTU. Il peut être plus simple de recevoir une notification asynchrone lorsque change la PMTU, de sorte que ces variables puissent être mises à jour.

Une mise en œuvre de TCP doit aussi mémoriser les valeurs de MSS reçues de son homologue (qui reviennent pas défaut à 536), et n'envoyer aucun segment plus gros que cette MSS, sans considération de la PMTU. Dans les mises en œuvre dérivées de 4.xBSD, cela exige d'ajouter un champ supplémentaire à l'enregistrement d'état TCP.

Finalement, lorsque un message Datagramme trop gros est reçu, cela implique qu'un datagramme a été abandonné par le routeur qui a envoyé le message ICMP. Ceci est suffisant pour le traiter comme tout autre segment abandonné et attendre l'arrivée à expiration du temporisateur de retransmission pour causer la retransmission du segment. Si le processus de découverte de PMTU exige plusieurs étapes pour estimer la bonne PMTU, cela pourrait retarder la connexion de nombreux délais d'aller-retour.

Autrement, la retransmission pourrait être faite en réponse immédiate à une notification que la MTU de chemin a changé, mais seulement pour la connexion spécifique mentionnée par le message Datagramme trop gros. La taille de datagramme utilisée dans la retransmission devrait, bien sûr, n'être pas plus grande que la nouvelle PMTU.

Note : On NE DOIT PAS retransmettre en réponse à chaque message Datagramme trop gros, car une salve de plusieurs segments surdimensionnés donnerait naissance à plusieurs de ces messages et donc plusieurs retransmissions des mêmes données. Si la nouvelle estimation de PMTU est toujours fausse, le processus se répète, et il y a une croissance exponentielle du nombre de segments superflus envoyés !

Cela signifie que la couche TCP doit être capable de reconnaître quand une notification de Datagramme trop gros diminue réellement la PMTU qu'elle a déjà utilisée pour envoyer un datagramme sur une connexion donnée, et devrait ignorer toute autre notification.

Les mises en œuvre modernes de TCP incorporent des algorithmes"d'évitement d'encombrement" et de "démarrage lent" pour améliorer les performances [4]. À la différence d'une retransmission causée par la fin d'une temporisation de retransmission TCP, une retransmission causée par un message Datagramme trop gros ne devrait pas changer la fenêtre d'encombrement. Elle devrait cependant déclancher le mécanisme de démarrage lent (c'est-à-dire que seulement un segment devrait être retransmis jusqu'à ce que les accusés de réception commencent à arriver à nouveau).

Les performances de TCP peuvent être réduites si la taille maximum de fenêtre de l'envoyeur n'est pas un multiple exact de la taille de segment utilisée (ce n'est pas la taille de la fenêtre d'encombrement, qui est toujours un multiple de la taille de segment). Dans de nombreux systèmes (comme ceux dérivés de 4.2BSD), la taille de segment est souvent réglée à 1024 octets, et la taille maximum de fenêtre ("l'espace d'envoi") est généralement un multiple de 1024 octets, de sorte que la relation appropriée tient par défaut. Cependant si la découverte de PMTU est utilisée, la taille de segment peut n'être pas un sous-multiple de l'espace d'envoi, et elle peut changer durant une connexion ; cela signifie que la couche TCP peut avoir besoin de changer la taille de fenêtre de transmission lorsque la découverte de PMTU change la valeur de la PMTU. La taille maximum de fenêtre devrait être réglée au plus grand multiple de la taille de segment (PMTU - 40) qui est inférieure ou égale à la taille d'espace de mémoire tampon de l'envoyeur.

La découverte de PMTU n'affecte pas la valeur envoyée dans l'option MSS de TCP, parce que cette valeur est utilisée par l'autre extrémité de la connexion, qui peut utiliser une valeur de PMTU sans rapport avec celle là.

6.5   Problèmes pour les autres protocoles de transport

Certains protocoles de transport (tels que ISO TP4 [3]) ne sont pas autorisés à remettre en paquet lorsqu'ils font une retransmission. C'est-à-dire que, une fois qu'une tentative est faite pour transmettre un datagramme d'une certaine taille, son contenu ne peut plus être partagé en plus petits datagrammes pour la retransmission. Dans un tel cas, le datagramme original devrait être retransmis sans que soit établi le bit DF, lui permettant d'être fragmenté en tant que de besoin pour atteindre sa destination. Les datagrammes ultérieurs, lorsqu'ils sont transmis pour la première fois, ne devraient pas être plus grands que ce qui est permis par la MTU de chemin, et devraient avoir le bit DF mis.

Le système de fichier réseau (NFS, Network File System) de SUN utilise un protocole d'appel de procédure distante (RPC, Remote Procedure Call) [11] qui, dans de nombreux cas, envoie des datagrammes qui doivent être fragmentés même pour la liaison de premier bond. Cela peut améliorer les performances dans certains cas, mais c'est connu pour causer des problèmes de fiabilité et de performances, en particulier lorsque client et serveur sont séparés par des routeurs.

On recommande que les mises en œuvre de NFS utilisent la découverte de PMTU chaque fois que des routeurs sont impliqués. La plupart des mises en œuvre NFS permettent de changer la taille du datagramme de RPC au moment du montage (indirectement, en changeant la taille effective de bloc système de fichier), mais cela peut exiger certaines modification pour prendre en charge des changements ultérieurs.

Aussi, comme une seule opération NFS ne peut être partagée entre plusieurs datagrammes UDP, certaines opérations (principalement, celles qui fonctionnent sur les noms de fichier et les répertoires) requièrent une taille de datagramme minimale qui peut être supérieure à la PMTU. Les mises en œuvre de NFS ne devraient pas réduire la taille de datagramme en dessous de ce seuil, même si la découverte de PMTU suggère une valeur inférieure. (Bien sûr, dans ce cas les datagrammes ne devraient pas être envoyés avec le bit DF mis.)

6.6   Interface de gestion

On suggère qu'une mise en œuvre fournisse un moyen pour qu'un programme utilitaire de système :

-   spécifie que la découverte de PMTU n'est pas faite sur une route donnée ;

-   change la valeur de PMTU associée à une route donnée.

La première peut être réalisée en associant un fanion à l'entrée d'acheminement ; lorsque un paquet est envoyé via une route avec ce fanion mis, la couche IP laisse le bit DF non mis quoi que demande la couche supérieure.

Ces dispositifs peuvent être utilisés pour réparer une situation anormale, ou par une mise en œuvre de protocole d'acheminement qui soit capable d'obtenir les valeurs de MTU de chemin.

La mise en œuvre devrait aussi fournir le moyen de changer la période de temporisation pour le vieillissement des informations de PMTU.

7.   Valeurs vraisemblables des MTU de chemin

L'algorithme recommandé à la section 5 pour "rechercher" l'espace des MTU de chemin se fonde sur un tableau des valeurs qui restreint considérablement l'espace de recherche. On décrit ici un tableau des valeurs de MTU qui, pour l'instant, représente toutes les technologies majeures de liaisons de données utilisées dans l'Internet.

Au tableau 7-1, la liste des liaisons de données figure dans l'ordre décroissant des MTU, groupées de telle sorte que chaque ensemble de MTU similaires soit associé à un "plateau" égal à la plus faible MTU du groupe. (Le tableau comporte aussi des entrées qui ne sont pas actuellement associées à une liaison de données, et donne des références lorsqu'il en est de disponibles). Lorsque un plateau représente plus d'une MTU, le tableau montre l'imprécision maximum associée au plateau, en pourcentage.

On ne s'attend pas à ce que les valeurs du tableau, en particulier pour les plus forts niveaux de MTU, restent valides pour toujours. Les valeurs données ici sont une suggestion de mise en œuvre, et NON une spécification ou une exigence. Les développeurs devraient utiliser des références à jour pour monter un ensemble de plateaux ; il est important que le tableau ne contienne pas trop d'entrées sinon le processus de recherche de la PMTU peut consommer les ressources de l'Internet. Les développeurs devraient aussi faciliter la mise à jour des valeurs du tableau pour les utilisateurs sans code source dans leur système (par exemple, le tableau dans un noyau Unix dérivé de BSD pourrait être changé en utilisant une nouvelle commande "ioctl").

Note : Il peut être une bonne idée d'ajouter quelques entrées au tableau pour des valeurs égales aux petites puissances de 2 plus 40 (pour les en-têtes IP et TCP), lorsque il n'existe pas de valeurs similaires, car cela semble être une façon non arbitraire raisonnable de choisir des valeurs arbitraires.

Le tableau pourrait aussi contenir des entrées pour des valeurs légèrement inférieures aux grandes puissances de 2, au cas où des MTU seraient définies proches de ces valeurs (dans ce cas, il est préférable que les entrées du tableau soient plus faibles que plus fortes, ou alors que le prochain plateau inférieur soit choisi plutôt).

7.1   Un meilleur moyen pour détecter les accroissements de PMTU

Le paragraphe 6.3 suggère de détecter les augmentations de valeur de PMTU en augmentant périodiquement l'estimation de la PTMU à la MTU du premier bond. Comme il est vraisemblable que ce processus va simplement "redécouvrir" l'estimation de PTMU actuelle, au prix de plusieurs datagrammes abandonnés, il ne devrait pas être effectué souvent.

Une meilleure approche est d'augmenter périodiquement l'estimation de PMTU à la prochaine plus forte valeur du plateau du tableau (ou à la MTU du prochain bond, si elle est plus petite). Si l'estimation augmentée est fausse, on perd au plus un temps d'aller-retour avant que la valeur correcte soit redécouverte. Si l'estimation augmentée est encore trop faible, une estimation plus forte sera tentée un peu plus tard.

Comme il prend plusieurs périodes pour découvrir une augmentation significative de la PMTU, on recommande qu'une courte période de temporisation soit utilisée après l'augmentation de l'estimation, et on peut utiliser une temporisation plus longue après une diminution de l'estimation de la PTMU à cause d'un message Datagramme trop gros. Par exemple, après la diminution de l'estimation de la PTMU, la temporisation devrait être réglée à 10 minutes ; une fois l'arrivée à expiration de la temporisation, une MTU plus forte est tentée, la temporisation peut être réglée à une valeur bien plus faible (disons, 2 minutes). En aucun cas la temporisation ne devrait être plus courte que la durée estimée de l'aller-retour, si elle est connue.

Tableau 7-1 : MTU courantes dans l'Internet

8.   Considérations pour la sécurité

Ce mécanisme de découverte de la MTU de chemin rend possibles deux attaques de déni de service, toutes deux fondées sur l'envoi d'un faux message Datagramme trop gros par un agresseur malveillant à un hôte Internet.

Dans la première attaque, le faux message indique une PMTU beaucoup plus faible que la réalité. Cela ne devrait pas arrêter entièrement les flux des données, car l'hôte victime ne pourrait jamais régler son estimation de PMTU en dessous du minimum absolu, mais à 8 octets de données IP par datagramme, la progression pourrait être lente.

Dans l'autre attaque, le faux message indique une PMTU plus grande que la réalité. Si il est cru, cela peut causer un blocage temporaire car la victime envoie des datagrammes qui seront éliminés par un routeur ou l'autre. En un aller-retour, l'hôte va découvrir son erreur (en recevant un message Datagramme trop gros de ce routeur), mais la répétition fréquente de cette attaque peut causer l'abandon de pas mal de datagrammes. Cependant, un hôte ne devrait jamais augmenter son estimation de la PMTU sur la base d'un message Datagramme trop gros, et donc ne devrait pas être vulnérable à cette attaque.

Une partie malveillante pourrait causer des problèmes si elle peut empêcher une victime de recevoir des messages Datagramme trop gros légitimes, mais dans ce cas, il y a des attaques de déni de service plus simples qui sont disponibles.

Références

[1]   R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, RFC 1122, octobre 1989.

[2]   Geof Cooper. "IP Datagram Sizes". Diffusion électronique du groupe de discussion TCP-IP, Message-ID <8705240517.AA01407@apolling.imagen.uucp>.

[3]   Organisation internationale de normalisation, "Spécification du protocole de transport ISO - ISO DP 8073", RFC 905, avril 1984.

[4]   Van Jacobson. Congestion Avoidance and Control. In Proc. SIGCOMM '88 Symposium on Communications Architectures and Protocols, pages 314-329. Stanford, CA, August, 1988.

[5]   C. Kent and J. Mogul. Fragmentation Considered Harmful. In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August, 1987.

[6]   Drew Daniel Perkins. Communication privée.

[7]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, RFC 792, USC/Information Sciences Institute, septembre 1981.

[8]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", STD 5, RFC 791, USC/Information Sciences Institute, septembre 1981.

[9]   J. Postel. "Taille maximum de segment TCP et questions qui s'y rapportent". RFC 879, SRI Network Information Center, novembre 1983.

[10]   Michael Reilly. Communication privée.

[11]   Sun Microsystems, Inc. "RPC : Protocole de procédure d'appel à distance", RFC 1057, SRI Network Information Center, juin 1988.

Adresse des auteurs