Découverte de la MTU de chemin pour IP version 6

Statut du présent mémoire

Le présent document spécifie un protocole en cours de normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé

Le présent document décrit la découverte de la MTU de chemin pour IP version 6. Il est largement dérivé de la RFC 1191, qui décrit la découverte de la MTU de chemin pour IP version 4.

Table des Matières

1.   Introduction

2.   Terminologie

3.   Vue d'ensemble du protocole

4.   Exigences du protocole

5.   Questions de mise en œuvre

5.1   Mise en couches

5.2   Mémorisation des informations de PMTU

5.3   Purge des informations de PMTU périmées

5.4   Actions de la couche TCP

5.5   Problèmes pour les autres protocoles de transport

5.6   Interface de gestion

6.   Considérations pour la sécurité

Remerciements

Appendice A - Comparaison avec la RFC 1191

Références

1.   Introduction

Lorsque un nœud IPv6 a une grande quantité de données à envoyer à un autre nœud, les données sont transmises dans une série de paquets IPv6. Il est normalement préférable que ces paquets soient de la plus grande taille qui peut réussir à traverser le chemin d'un tel nœud de source au nœud de destination. Cette taille de paquet est appelée la MTU de chemin (PMTU, Path MTU) et elle est égale à la MTU de liaison minimum de toutes les liaisons d'un chemin. IPv6 définit un mécanisme standard pour qu'un nœud découvre la PMTU d'un chemin arbitraire.

Les nœuds IPv6 DEVRAIENT mettre en œuvre la découverte de la MTU de chemin afin de découvrir et tirer parti des chemins qui ont une PMTU supérieure à la MTU de liaison IPv6 minimum [RFC1883]. Une mise en œuvre minimale d'IPv6 (par exemple, une mémoire d'amorçage en lecture seule) peut choisir d'omettre la mise en œuvre de la découverte de la MTU de chemin.

Les nœuds qui ne mettent pas en œuvre la découverte de la MTU de chemin peuvent utiliser la MTU minimum de liaison IPv6 définie dans la [RFC1883] comme taille maximum de paquet. Dans la plupart des cas, il en résultera l'utilisation de paquets plus petits que nécessaire, parce que la plupart des chemins ont une PMTU supérieure à la MTU minimum de liaison IPv6. Un nœud qui envoie des paquets beaucoup plus petits que ce que permet la MTU de chemin gaspille les ressources du réseau et obtient probablement un débit sous optimal.

2.   Terminologie

nœud   un appareil qui met en œuvre IPv6.

routeur   un nœud qui transmet des paquets IPv6 qui ne lui sont pas explicitement adressés.

hôte   tout nœud qui n'est pas un routeur.

couche supérieure   couche de protocole immédiatement au dessus de IPv6. Par exemple des protocoles de transport comme TCP et UDP, des protocoles de contrôle comme ICMP, des protocoles d'acheminement tels que OSPF, et des protocoles internet ou de couche inférieure qui sont "tunnelés" sur (c'est-à-dire, encapsulés dans) IPv6 comme IPX, AppleTalk, ou IPv6 lui-même.

liaison   facilité de communication ou support sur lequel des nœuds peuvent communiquer à la couche liaison, c'est à dire, à la couche immédiatement en dessous de IPv6. Par exemple des Ethernets (simples ou pontés) ; des liaisons point à point (PPP) ; des réseaux X.25, en relais de trame, ou ATM ; des "tunnels" de couche internet (ou supérieure) tels que des tunnels sur IPv4 ou IPv6 lui-même.

interface   c'est le rattachement d'un nœud à une liaison.

adresse   c'est un identifiant de couche IPv6 pour une interface ou ensemble d'interfaces.

paquet   c'est un en-tête IPv6 plus une charge utile.

MTU de liaison   c'est l'unité maximale de transmission, c'est à dire, la taille maximum de paquet en octets, qui peut être convoyée en un seul morceau sur une liaison.

chemin   c'est l'ensemble des liaisons traversées par un paquet entre un nœud de source et un nœud de destination.

MTU de chemin   c'est la MTU de liaison minimum de toutes les liaisons d'un chemin entre un nœud de source et un nœud de destination.

PMTU   MTU de chemin

Découverte de la MTU de chemin   processus par lequel un nœud apprend la PMTU d'un chemin.

flux   séquence de paquets envoyée d'une source particulière à une destination particulière (en envoi individuel ou en diffusion groupée) pour laquelle la source désire un traitement particulier de la part des routeurs qui interviennent.

id de flux   c'est la combinaison d'une adresse de source et d'une étiquette de flux différente de zéro.

3.   Vue d'ensemble du protocole

Le présent mémoire décrit une technique pour découvrir de façon dynamique la MTU d'un chemin. L'idée de base est qu'un nœud source suppose au départ que la MTU d'un chemin (PMTU) est la MTU (connue) du premier bond de ce chemin. Si un des paquets envoyés sur ce chemin est trop grand pour être transmis par un des nœuds le long du chemin, ce nœud va l'éliminer et retourner un message ICMPv6 Paquet trop gros [RFC1885]. À réception d'un tel message, le nœud de source va réduire sa PMTU supposée pour le chemin sur la base de la MTU du bond restricteur de la façon rapportée dans le message Paquet trop gros.

Le processus de découverte de la MTU de chemin se termine lorsque l'estimation de la PMTU par le nœud est inférieure ou égale à la PMTU réelle. Noter que plusieurs itérations du cycle envoi du paquet/message Paquet trop gros peuvent survenir avant que se termine le processus de découverte de la MTU de chemin, car il peut y avoir des liaisons avec des MTU plus petites plus loin le long du chemin.

Autrement, le nœud peut choisir de terminer le processus de découverte en cessant d'envoyer des paquets plus grands que la MTU de liaison IPv6 minimum.

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ées par les messages Paquet trop gros. Pour détecter les augmentations de la PMTU d'un chemin, un nœud augmente périodiquement sa PMTU supposée. Cela va presque toujours résulter en l'élimination de paquets et à générer des messages Paquet trop gros, parce que dans la plupart des cas, la PMTU du chemin n'aura pas changé. Donc, les tentatives de détection des augmentations de la PMTU d'un chemin ne devraient être faites que rarement.

La découverte de la MTU de chemin accepte les destinations de diffusion groupée aussi bien que d'envoi individuel. Dans le cas d'une destination de diffusion groupée, des copies d'un paquet peuvent traverser de nombreux chemins différents vers de nombreux nœuds différents. Chaque chemin peut avoir une PMTU différente, et un seul paquet de diffusion groupé peut résulter en plusieurs messages Paquet trop gros, chacun rapportant une MTU de prochain bond différente. La valeur de PMTU minimum à travers l'ensemble des chemins utilisés détermine la taille des paquets envoyés ultérieurement à la destination de diffusion groupée

Noter que la découverte de la MTU de chemin doit être effectuée même dans les cas où un nœud "pense" qu'une destination est rattachée à la même liaison que lui. Dans une situation comme celle où un routeur voisin agit comme mandataire [RFC1970] pour une certaine destination, la destination peut apparaître comme directement connectée mais être en fait à plus d'un bond.

4.   Exigences du protocole

Comme exposé à la section 1, les nœuds IPv6 ne sont pas obligés de mettre en œuvre la découverte de la MTU de chemin. Les exigences de la présente section ne s'appliquent qu'aux mises en œuvre qui comportent la découverte de la MTU de chemin.

Lorsque un nœud reçoit un message Paquet trop gros, il DOIT réduire son estimation de PMTU pour le chemin pertinent, sur la base de la valeur du champ MTU du message. Le comportement précis d'un nœud dans ces circonstances n'est pas spécifié, car des applications différentes peuvent avoir des exigences différentes, et donc des architectures de mise en œuvre différentes peuvent choisir des stratégies différentes.

Après avoir reçu un message Paquet trop gros, un nœud DOIT essayer d'éviter de provoquer d'autres messages de cette sorte dans un futur proche. Le nœud DOIT réduire la taille des paquets qu'il envoie le long du chemin. Utiliser une estimation de PMTU plus grande que la MTU de liaison IPv6 minimum peut continuer de provoquer des messages Paquet trop gros. Comme chacun de ces messages (et les abandons de paquets qu'ils provoquent) consomme des ressources du réseau, le nœud DOIT forcer le processus de découverte de la MTU de chemin à se terminer.

Les nœuds qui utilisent la découverte de MTU de chemin DOIVENT détecter aussi vite que possible les diminutions de PMTU. Les nœud PEUVENT détecter les augmentations de PMTU, mais comme le faire exige d'envoyer des paquets plus grands que l'estimation actuelle de PMTU, et parce qu'il est vraisemblable que la PMTU n'aura pas augmenté, cela DOIT être à des intervalles peu fréquents. Un tentative de détection d'augmentation (par l'envoi d'un paquet plus grand que l'estimation en cours) NE DOIT PAS être faite moins de 5 minutes après la réception d'un message Paquet trop gros pour le chemin en question. Le réglage recommandé pour ce temporisateur est de deux fois la valeur minimum (10 minutes).

Un nœud NE DOIT PAS réduire son estimation de la MTU de chemin en dessous de la MTU de liaison IPv6 minimum.

Note : Un nœud peut recevoir un message Paquet trop gros rapportant une MTU de prochain bond inférieure à la MTI de liaison IPv6 minimum. Dans ce cas, le nœud n'est pas obligé de réduire la taille des paquets suivants envoyés sur le chemin à moins que la MTU de liaison IPv6 minimum, mais doit plutôt inclure un en-tête Fragment dans ces paquets [RFC1883].

Un nœud NE DOIT PAS augmenter son estimation de la MTU de chemin en réponse au contenu d'un message Paquet trop gros. Un message se proposant d'annoncer une augmentation de la MTU de chemin peut être un paquet périmé qui a erré dans le réseau, un paquet falsifié injecté au titre d'une attaque de déni de service, ou le résultat de l'existence de plusieurs chemins vers la destination, ayant chacun une MTU différente.

5.   Questions de mise en œuvre

Cette section expose un certain nombre de questions relatives à la mise en œuvre de la découverte de la MTU de chemin. Ce n'est pas une spécification, mais plutôt un ensemble de notes destinées à aider à la mise en œuvre.

Les questions étudiées sont

-   quelles sont les couches qui mettent en œuvre la découverte de la MTU de chemin ?

-   comment sont mises en antémémoire les informations de PMTU ?

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

-   que doivent faire la couche de transport et les couches supérieures ?

5.1   Mise en couches

Dans l'architecture IP, le choix de la taille du paquet à envoyer est fait par un protocole à la couche au dessus de IP. Le présent mémoire se réfère à un tel protocole comme à un "protocole de mise en paquets". Les protocoles de mise en paquet sont normalement des protocoles de transport (par exemple, TCP) mais peuvent aussi être des protocoles de couche supérieure (par exemple, des protocoles construits par dessus UDP).

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

Il est donc suggéré que la couche IP mémorise les informations de PMTU et que la couche ICMP traite les messages Paquet trop gros reçus. La couche de mise en paquet peut répondre aux changements de la PMTU en changeant la taille des messages qu'elle envoie. Pour prendre en charge cette mise en couches, les couches de mise en paquet ont besoin d'un moyen pour apprendre les changements de valeur de MMS_S, la "taille maximum de message de transport envoyé". La MMS_S est déduite de la MTU de chemin en soustrayant la taille de l'en-tête IPv6 plus l'espace réservé par la couche IP pour d'éventuels en-têtes supplémentaires.

Il est possible qu'une couche de mise en paquets, peut-être une application UDP en dehors du noyau, soit incapable de changer la taille des messages qu'elle envoie. Il peut en résulter une taille de paquet qui excède la MTU de chemin. Pour s'accommoder de telles situations, IPv6 définit un mécanisme qui permet que de grosses charges utiles soient divisées en fragments, chaque fragment étant envoyé dans un paquet distinct (voir la section "En-tête de fragment" de la [RFC1883]). Cependant, il est conseillé aux couches de mise en paquet d'éviter d'envoyer des messages qui vont exiger la fragmentation (pour les arguments contre la fragmentation, voir [FRAG]).

5.2   Mémorisation des informations de PMTU

Idéalement, une valeur de PMTU devrait être associée à un chemin spécifique traversé par les paquets échangés entre les nœud de source et de destination. Cependant, dans la plupart des cas, un nœud n'aura pas assez d'informations pour identifier de façon complète et précise un tel chemin. Un nœud doit plutôt associer une valeur de PMTU à une représentation locale d'un chemin. Il appartient aux mises en œuvre de choisir la représentation locale d'un chemin.

Dans le cas d'une adresse de destination en diffusion groupée, 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" pour une destination de diffusion groupée peut en fait représenter un ensemble de chemins potentiellement grand.

Au minimum, une mise en œuvre pourrait conserver une seule valeur de PMTU à utiliser pour tous les paquets générés à partir de ce nœud. Cette valeur de PMTU serait la PMTU minimum apprise à travers l'ensemble de tous les chemins utilisés par le nœud. Cette approche aura vraisemblablement pour résultat l'utilisation de paquets plus petits que ce qui est nécessaire pour de nombreux chemins.

Une mise en œuvre pourrait utiliser l'adresse de destination comme représentation locale d'un chemin. La valeur de PMTU associée à une destination serait la PMTU minimum apprise à travers l'ensemble de tous les chemins qui utilisent cette destination. L'ensemble des chemins utilisés vers une destination particulière est supposé être petit, consistant dans de nombreux cas en un seul chemin. Cette approche résultera en l'utilisation de paquets de taille optimale destination par destination. Cette approche s'intègre harmonieusement dans le modèle conceptuel d'un hôte tel que décrit dans la [RFC1970] : une valeur de PMTU pourrait être mémorisée avec l'entrée correspondante dans l'antémémoire de destination.

Si les flux de la [RFC1883] sont utilisés, une mise en œuvre pourrait utiliser l'identifiant de flux comme représentation locale d'un chemin. Les paquets envoyés à une destination particulière mais appartenant à des flux différents peuvent utiliser des chemins différents, le choix du chemin dépendant de l'identifiant de flux. Cette approche résultera en l'utilisation de paquets de taille optimale flux par flux, donnant une granularité plus fine que les valeurs de PMTU conservées sur la base de la destination.

Pour les paquets acheminés par la source (c'est à dire, les paquets qui contiennent un en-tête IPv6 Acheminement [RFC1883]) l'acheminement de source peut qualifier plus précisément la représentation locale d'un chemin. En particulier, un paquet qui contient un en-tête Acheminement de type 0 dans lequel tous les bits dans la représentation binaire Stricte/Lâche sont égaux à 1 contiennent une spécification de chemin complète. Une mise en œuvre pourrait utiliser les informations d'acheminement de source dans la représentation locale d'un chemin.

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

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

Lorsque un message Paquet trop gros est reçu, le nœud détermine à quels chemins le message s'applique sur la base du contenu du message Paquet trop gros. Par exemple, si l'adresse de destination est utilisée comme représentation locale d'un chemin, l'adresse de destination provenant du paquet original sera utilisée pour déterminer à quel chemin le message s'applique.

Note : Si le paquet original contenait un en-tête Acheminement, celui-ci devrait être utilisé pour déterminer la localisation de l'adresse de destination au sein du paquet original. Si le champ Segments restants est égal à zéro, l'adresse de destination est dans le champ Adresse de destination de l'en-tête IPv6. Si Segments restants est supérieur à zéro, l'adresse de destination est la dernière adresse (Adresse[n]) dans l'en-tête Acheminement.

Le nœud utilise alors la valeur du champ MTU du message Paquet trop gros comme valeur de PMTU d'essai, et la compare à la PMTU existante. Si la PMTU d'essai est inférieure à l'estimation existante de PMTU, la PMTU d'essai remplace la PMTU existante comme valeur de PMTU pour le chemin.

Les couches de mise en paquet doivent recevoir notification 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 d'une diminution de l'estimation de PMTU.

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

Aussi, l'instance qui envoie le paquet qui a provoqué le message Paquet trop gros devrait être notifiée de l'abandon du paquet, même si l'estimation de PMTU n'a pas changé, de sorte qu'elle puisse retransmettre les données éliminées.

Note : 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 paquet plus grand que l'estimation de PMTU. Dans cette approche, lorsque est faite une tentative d'ENVOI d'un paquet plus grand que l'estimation de PMTU, la fonction ENVOI devrait échouer et retourner une indication d'erreur convenable. Cette approche peut être plus convenable pour une couche de mise en paquet sans connexion (comme 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 la temporisation devraient être utilisés pour récupérer de l'abandon de paquets.

Il est important de comprendre que la notification des instances de couche de mise en paquet qui utilisent le chemin au sujet du changement de la PMTU est distincte de la notification d'une instance spécifique de l'abandon d'un paquet. Cette dernière devrait être effectuée aussitôt que possible en pratique (c'est-à-dire, en asynchrone du point de vue de l'instance de couche de mise en paquet) 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 effectuée que pour les paquets dont il est connu qu'ils ont été abandonnés, comme c'est indiqué par un message Paquet trop gros.

5.3   Purge des informations de PMTU périmées

La topologie de l'Internet est dynamique ; les chemins changent avec le temps. Bien que la représentation locale d'un chemin puisse rester constante, le ou les chemins réels utilisés peuvent changer. Et donc, les informations de PMTU mises en antémémoire par un nœud peuvent se périmer.

Si la valeur de PMTU périmée est trop grande, cela sera découvert presque immédiatement une fois qu'un paquet assez grand sera envoyé sur le chemin. Il n'existe pas de mécanisme de ce genre pour voir qu'une valeur périmée de PMTU est trop petite, de sorte qu'une mise en œuvre devrait "vieillir" les valeurs en antémémoire. Lorsque une valeur de PMTU n'a pas été diminuée pendant un certain temps (de l'ordre de 10 minutes) l'estimation de la PMTU devrait être réglée à la MTU de la liaison du premier bond, et les couches de mise en paquet devraient être informées du changement. Cela va causer à nouveau le déroulement du processus complet de découverte de la MTU du chemin.

Note : Une mise en œuvre devrait fournir un moyen pour changer la durée de la temporisation, y compris son réglage à "l'infini". Par exemple, les nœuds rattachés à une liaison FDDI qui est elle-même rattachée au reste de l'Internet via une ligne de série de petite MTU ne vont jamais découvrir une nouvelle PMTU non locale, de sorte qu'ils ne devraient pas avoir à s'occuper des paquets éliminés toutes les 10 minutes.

Une couche supérieure ne doit pas retransmettre les données en réponse à une augmentation d'estimation de PMTU, car cette augmentation ne vient jamais en réponse à une indication d'un abandon de paquet.

Une approche de la mise en œuvre du vieillissement de la PMTU est d'associer un champ d'horodatage à une valeur de PMTU. Ce champ est initialisé à une valeur "réservée", qui indique que la PMTU est égale à la MTU de la liaison du premier bond. Chaque fois que la PMTU est diminuée en réponse à un message Paquet trop gros, l'horodatage est mis à l'heure actuelle.

Une fois par minute, une procédure pilotée par un temporisateur passe en revue toutes les valeurs de PMTU en antémémoire, et pour chaque PMTU dont l'horodatage n'est pas "réservé" et qui est plus ancienne que l'intervalle du temporisateur :

-   L'estimation de PMTU est réglée à la MTU de la liaison de premier bond.

-   L'horodatage est réglé à la valeur "réservé".

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

5.4   Actions de la couche TCP

La couche TCP doit garder trace de la PMTU pour le ou les chemins utilisés par une connexion ; elle ne devrait pas envoyer de segments qui résulteraient en paquets plus grands que la PMTU. Une mise en œuvre simple pourrait demander ces valeurs à la couche IP chaque fois qu'elle crée un nouveau segment, mais cela pourrait être inefficace. De plus, les mises en œuvre de TCP qui suivent l'algorithme d'évitement d'encombrement "démarrage lent" de [CONG] 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 la PMTU change, de sorte que toutes ces variables puissent être mises à jour.

Une mise en œuvre de TCP doit aussi mémoriser la valeur de MSS (Maximum Segment Size)reçue de son homologue, et ne doit pas envoyer de segment plus grand que cette MSS, sans considération de la PMTU. Dans les mises en œuvre dérivées de 4.xBSD, cela peut exiger d'ajouter un champ supplémentaire à l'enregistrement d'état de TCP.

La valeur envoyée dans l'option TCP MSS est indépendante de la PMTU. Cette valeur d'option MSS est utilisée par l'autre extrémité de la connexion, qui peut se servir d'une valeur de PMTU sans relation avec celle-ci. Voir dans la [RFC1883] les sections intitulées "Questions de taille de paquet" et "Taille maximum de charge utile de couche supérieure" pour des informations sur le choix d'une valeur pour l'option TCP MSS.

Lorsque un message Paquet trop gros est reçu, il implique qu'un paquet a été abandonné par le nœud qui a envoyé le message ICMP. Cela est suffisant pour le traiter comme n'importe quel autre segment abandonné, et attendre jusqu'à la fin du temporisateur de retransmission pour causer la retransmission du segment. Si le processus de découverte de la MTU de chemin exige plusieurs étapes pour trouver la PMTU du chemin complet, 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 de changement de la PMTU, mais seulement pour la connexion spécifiée par le message Paquet trop gros. La taille de paquet utilisée dans la retransmission ne devrait pas être supérieure à la nouvelle PMTU.

Note : Une couche de mise en paquet ne doit pas retransmettre en réponse à chaque message Paquet trop gros, car une salve de plusieurs segments surdimensionnés donnerait lieu à plusieurs de ces messages et donc à plusieurs retransmissions des mêmes données. Si la nouvelle estimation de PMTU est toujours erronée, 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 paquet trop gros diminue réellement la PMTU qui est déjà utilisée pour envoyer un paquet sur une connexion donnée, et devrait ignorer toutes les autres notifications.

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

Les performances de TCP peuvent être réduites si la taille de fenêtre maximum 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 de fenêtre maximum (l'espace d'envoi) est normalement un multiple de 1024 octets, de sorte que les relations appropriées tiennent par défaut. Cependant, si la découverte de la MTU de chemin 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 la MTU de chemin change la valeur de la PMTU. La taille de fenêtre maximum devrait être réglée au plus grand multiple de la taille de segment qui est inférieure ou égale à la taille de l'espace de mémoire tampon de l'envoyeur.

5.5   Problèmes pour les autres protocoles de transport

Certains protocoles de transport (comme ISO TP4 [RFC0905]) ne sont pas autorisés à refaire la mise en paquet lors d'une retransmission. C'est à dire que une fois qu'il tente de transmettre un segment d'une certaine taille, le transport ne peut pas partager le contenu du segment en segments plus petits pour la retransmission. Dans un tel cas, le segment original peut être fragmenté par la couche IP durant la retransmission. Les segments suivants, lorsque ils sont transmis pour la première fois, ne devraient pas être plus grands que ce qui est permis par la MTU de chemin.

Le système de fichiers réseau Sun (NFS, Network File System) utilise un protocole d'appel de procédure distante (RPC, Remote Procedure Call) [RFC1057] qui, lorsque utilisé sur UDP, va dans de nombreux cas générer des charges utiles qui doivent être fragmentées même pour la liaison du premier bond. Cela peut améliorer les performances dans certains cas, mais 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.

Il est recommandé que les mises en œuvre de NFS utilisent la découverte de la MTU de chemin chaque fois que des routeurs sont impliqués La plupart des mises en œuvre de NFS admettent que la taille du datagramme RPC soit changée au moment du montage (indirectement, en changeant la taille effective du bloc de système de fichiers) mais pourraient exiger des modification pour prendre ultérieurement en charge les changements.

Aussi, comme une seule opération NFS ne peut pas être partagée entre plusieurs datagrammes UDP, certaines opérations (principalement, celles opérant sur les noms et répertoires de fichiers) exigent une taille de charge utile minimum qui si elle était envoyée dans un seul paquet excéderait la PMTU. Les mises en œuvre de NFS ne devraient pas réduire la taille de la charge utile en dessous de ce seuil même si la découverte de la MTU de chemin suggère une valeur inférieure. Dans ce cas, la charge utile sera fragmentée par la couche IP.

5.6   Interface de gestion

Il est suggéré qu'une mise en œuvre fournisse un moyen pour qu'un programme utilitaire de ssytème :

-   spécifie que la découverte de la MTU de chemin ne soit pas faite sur un chemin donné,

-   change la valeur de PMTU associée à un chemin donné.

Le premier peut être accompli en associant un fanion au chemin ; lorsque un paquet est envoyé sur un chemin avec le fanion établi, la couche IP n'envoie pas de paquets supérieurs à la MTU de liaison IPv6 minimum.

Ces dispositifs peuvent être utilisés pour fonctionner dans une situation aberrante, ou par une mise en œuvre de protocole d'acheminement qui est capable d'obtenir les valeurs de MTU de chemin.

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

6.   Considérations pour la sécurité

Ce mécanisme de découverte de la MTU de chemin rend possible deux attaques de déni de service, toutes deux fondées sur un malveillant qui envoie de faux messages Paquet trop gros à un nœud.

Dans la première attaque, le faux message indique une PMTU beaucoup plus petite que la réalité. Cela devrait ne pas arrêter entièrement le flux de données, car le nœud victime ne devrait jamais établir son estimation de PMTU en dessous de la MTU de liaison IPv6 minimum. Il en résultera cependant des performances sous optimales.

Dans la seconde attaque, le faux message indique une PMTU supérieure à la réalité. Si il est cru, cela peut causer un blocage temporaire lorsque la victime envoie des paquets qui vont être éliminés par un des routeurs. En l'espace d'un aller retour, le nœud va découvrir son erreur (en recevant des messages Paquet trop gros de la part de ce routeur) mais la répétition fréquente de cette attaque pourrait causer l'élimination de beaucoup de paquets. Un nœud ne devrait cependant jamais augmenter son estimation de la PMTU sur la base d'un message Paquet trop gros, et ne devrait donc pas être vulnérable à cette attaque.

Un malveillant pourrait aussi causer des problèmes si il pouvait empêcher sa victime de recevoir les messages Paquet trop gros légitimes, mais dans ce cas, des attaques de déni de service plus simples sont disponibles.

Remerciements

Nous tenons à remercier les auteurs et les contributeurs à la [RFC1191], d'où la majorité du présent document est tirée. Nous tenons aussi à remercier les membres du groupe de travail IPng pour leur révision attentive et leurs critiques constructives.

Appendice A - Comparaison avec la RFC 1191

Le présent document se fonde en grande partie sur la RFC 1191, qui décrit la découverte de la MTU de chemin pour IPv4. Certaines portions de la RFC 1191 n'étaient pas nécessaires dans le présent document :

spécification de routeur    – les messages Paquet trop gros et le comportement correspondant de routeur sont définis dans la [RFC1885]

bit Ne pas fragmenter    – il n'y a pas de bit DF dans les paquets IPv6

discussion sur TCP MSS    – le choix d'une valeur à envoyer dans l'option TCP MSS est exposé dans la [RFC1883]

messages de style ancien    – tous les messages Paquet trop gros rapportent la MTU de la liaison la plus restrictive

tableaux de MTU plateau    – ne sont pas nécessaires parce qu'il n'y a pas de message de style ancien.

Références

[CONG]   Van Jacobson, "Congestion Avoidance and Control", Conclusions du SIGCOMM '88 Symposium on Communications Architectures and Protocols, pages 314-329. Stanford, CA, août 1988.

[FRAG]   C. Kent and J. Mogul, "Fragmentation Considered Harmful", Dans les conclusion de l'atelier SIGCOMM '87 sur Frontiers in Computer Communications Technology, août 1987.

[RFC1885]   A. Conta, S. Deering, "Protocole de contrôle de message Internet (ICMPv6) pour le protocole Internet version 6 (IPv6)", décembre 1995. (Obsolète, voirRFC2463) (P.S.)

[RFC1883]   S. Deering, R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1995. (Obsolète, voirRFC2460) (P.S.)

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

[RFC1970]   T. Narten, E. Nordmark, W. Simpson, "Découverte du voisinage pour IP version 6 (IPv6)", août 1996. (Obsolète, voirRFC2461) (P.S.)

[RFC1191]   J. Mogul et S. Deering, "Découverte de la MTU de chemin", novembre 1990.

[RFC1057]   Sun Microsystems, Inc. "RPC : Protocole de procédure d'appel à distance", juin 1988.

Adresse des auteurs