Aller au contenu principal

1. Introduction

L'IETF a spécifié le transport par datagramme utilisant UDP, le protocole de contrôle de transmission en flux (Stream Control Transmission Protocol, SCTP) et le protocole de contrôle de congestion de datagramme (Datagram Congestion Control Protocol, DCCP), ainsi que les protocoles superposés sur ces transports (par exemple, SCTP/UDP, DCCP/UDP, QUIC/UDP) et le transport de datagramme direct sur la couche réseau IP. Ce document décrit une méthode robuste de découverte du MTU de chemin (Path MTU Discovery, PMTUD) qui peut être utilisée avec ces protocoles de transport (ou les applications qui utilisent leur service de transport) pour découvrir une taille de paquet appropriée à utiliser sur un chemin Internet.

1.1. Découverte classique du MTU de chemin (Classical Path MTU Discovery)​

La découverte classique de l'unité de transmission maximale de chemin (Classical Path Maximum Transmission Unit Discovery, PMTUD) peut être utilisée avec tout transport capable de traiter les messages ICMP Packet Too Big (PTB) (par exemple, [RFC1191] et [RFC8201]). Dans ce document, le terme message PTB s'applique à la fois aux messages ICMP Unreachable IPv4 (Type 3) qui transportent l'erreur Fragmentation Needed (Type 3, Code 4) [RFC0792] et aux messages ICMPv6 Packet Too Big (Type 2) [RFC4443]. Lorsqu'un émetteur reçoit un message PTB, il réduit le MTU effectif à la valeur signalée comme MTU de liaison dans le message PTB. Le PMTUD classique spécifie une méthode d'augmentation périodique de la taille du paquet dans une tentative de découvrir une augmentation du PMTU pris en charge. Les paquets envoyés avec une taille supérieure au PMTU effectif actuel sont appelés paquets de sondage.

Les paquets non destinés à être des paquets de sondage sont soit fragmentés au PMTU effectif actuel, soit la tentative d'envoi échoue avec un code d'erreur. Les applications peuvent se voir fournir une primitive leur permettant de lire la taille maximale de paquet (Maximum Packet Size, MPS), qui est dérivée du PMTU effectif actuel.

Le PMTUD classique est sujet à des défaillances de protocole. Une défaillance survient lorsque le trafic utilisant une taille de paquet supérieure au PMTU réel est mis en trou noir (tous les datagrammes plus grands que le PMTU réel sont supprimés). Cela peut survenir lorsque les messages PTB ne sont pas renvoyés à l'émetteur pour une raison quelconque (par exemple, voir [RFC2923]).

Les exemples de cas où les messages PTB ne sont pas livrés incluent les suivants:

  • La génération de messages ICMP est généralement limitée en débit. Cela pourrait entraîner l'absence de génération de messages PTB vers l'émetteur (voir [RFC4443] Section 2.4).

  • Les messages ICMP peuvent être filtrés par des middleboxes, y compris les pare-feu [RFC4890]. Un pare-feu pourrait être configuré avec une politique bloquant les messages ICMP entrants, ce qui empêcherait la réception de messages PTB par un point de terminaison émetteur derrière ce pare-feu.

  • Lorsque le routeur émettant le message ICMP supprime un paquet tunnelisé, le message ICMP résultant est dirigé vers l'entrée du tunnel. Ce point de terminaison de tunnel est responsable du transfert du message ICMP, du traitement du paquet cité dans le champ de charge utile pour supprimer l'effet du tunnel et du renvoi d'un message ICMP correctement formaté à l'émetteur [TUNNELS]. Le fait de ne pas le faire empêche le message PTB d'atteindre l'émetteur d'origine.

  • L'asymétrie dans le transfert peut entraîner l'absence de route de retour vers l'émetteur d'origine, ce qui empêcherait la livraison d'un message ICMP à l'émetteur. Ce problème peut également survenir lorsque soit le routage basé sur des politiques, soit le routage multi-chemin à coût égal (Equal-Cost Multipath, ECMP) est utilisé, ou lorsqu'une middlebox agit comme équilibreur de charge d'application. Un exemple est un routeur ECMP choisissant un chemin vers le serveur en fonction des octets dans la charge utile IP. Dans ce cas, si un paquet envoyé par le serveur rencontre un problème après le routeur ECMP, alors le routeur ECMP doit diriger tout message ICMP résultant vers l'émetteur d'origine.

  • Il existe des cas supplémentaires où la destination du prochain saut ne reçoit pas un paquet en raison de sa taille. Cela pourrait être dû à une mauvaise configuration du chemin de couche 2 entre les nœuds, par exemple le MTU configuré dans un commutateur de couche 2, ou une mauvaise configuration de l'unité de réception maximale (Maximum Receive Unit, MRU). Si un paquet est supprimé par la liaison, cela n'entraînera pas l'envoi d'un message PTB à l'émetteur d'origine.

Une autre défaillance pourrait résulter si un nœud qui n'est pas sur le chemin réseau envoie un message PTB qui tente de forcer un émetteur à changer le PMTU effectif [RFC8201]. Un émetteur peut se protéger contre la réaction à de tels messages en utilisant le paquet cité dans une charge utile de message PTB pour valider que le message PTB reçu a été généré en réponse à un paquet qui avait effectivement été émis par l'émetteur. Cependant, il existe des situations où un émetteur serait incapable de fournir cette validation.

Les exemples où la validation du message PTB n'est pas possible incluent les suivants:

  • Lorsqu'un routeur émettant le message ICMP implémente RFC 792 [RFC0792], il n'est tenu d'inclure que les 64 premiers bits de la charge utile IP du paquet dans la charge utile citée. Il pourrait ne pas rester suffisamment d'octets pour que l'émetteur interprète les informations de transport citées.

    Remarque: La recommandation dans RFC 1812 [RFC1812] est que les routeurs IPv4 renvoient un paquet cité avec autant du datagramme d'origine que possible sans que la longueur du datagramme ICMP ne dépasse 576 octets. Les routeurs IPv6 incluent autant du paquet invoquant que possible sans que le paquet ICMPv6 ne dépasse 1280 octets [RFC4443].

  • L'utilisation de tunnels et/ou de chiffrement peut réduire la taille du paquet cité renvoyé à l'adresse source d'origine, augmentant le risque qu'il ne reste pas suffisamment d'octets pour que l'émetteur interprète les informations de transport citées.

  • Même lorsque le message PTB inclut suffisamment d'octets du paquet cité, la couche réseau pourrait manquer de contexte suffisant pour valider le message car la validation dépend des informations sur les flux de transport actifs à un nœud de point de terminaison (par exemple, les paires socket/adresse utilisées et d'autres informations d'en-tête de protocole).

  • Lorsqu'un paquet est encapsulé/tunnelisé sur un transport chiffré, l'entrée du tunnel/encapsulation peut ne pas avoir suffisamment de contexte ou de puissance de calcul pour reconstruire l'en-tête de transport qui serait nécessaire pour effectuer la validation.

  • Lorsqu'un message ICMP est généré par un routeur dans un segment de réseau qui a inséré un en-tête dans un paquet, le paquet cité pourrait contenir des informations d'en-tête de protocole supplémentaires qui n'étaient pas incluses dans le paquet envoyé d'origine et que l'émetteur PL ne traite pas ou peut ne pas savoir comment traiter. Cela pourrait perturber la capacité de l'émetteur à valider ce message PTB.

  • Un dispositif de traduction d'adresses réseau (Network Address Translation, NAT) qui traduit un en-tête de paquet devrait également traduire les messages ICMP et mettre à jour le paquet cité ICMP [RFC5508] dans ce message. Si cela n'est pas correctement traduit, alors l'émetteur ne serait pas capable d'associer le message avec le PL qui a émis le paquet, et donc ce message ICMP ne peut pas être validé.

1.2. Découverte du MTU de chemin de la couche de paquetisation (Packetization Layer Path MTU Discovery)​

Le terme couche de paquetisation (Packetization Layer, PL) a été introduit pour décrire la couche responsable du placement de blocs de données dans la charge utile de paquets IP et de la sélection d'un MPS approprié. Cette fonction est souvent effectuée par un protocole de transport (par exemple, DCCP, RTP, SCTP, QUIC) mais peut également être effectuée par d'autres méthodes d'encapsulation fonctionnant au-dessus de la couche de transport.

Contrairement au PMTUD, la découverte du MTU de chemin de la couche de paquetisation (Packetization Layer Path MTU Discovery, PLPMTUD) [RFC4821] introduit une méthode qui ne repose pas sur la réception et la validation des messages PTB. Elle est donc plus robuste que le PMTUD classique. C'est devenu l'approche recommandée pour mettre en œuvre la découverte du PMTU [BCP145].

Ce document met à jour [RFC4821] pour spécifier la méthode PLPMTUD pour les PL de datagramme et met également à jour [BCP145] pour référer à la méthode spécifiée dans ce document pour une utilisation avec les datagrammes UDP au lieu de la méthode dans [RFC4821].

Il utilise une stratégie générale dans laquelle le PL envoie des paquets de sondage pour rechercher la plus grande taille de datagramme non fragmenté pouvant être envoyé sur un chemin réseau. Des paquets de sondage sont envoyés pour explorer en utilisant une taille de paquet plus grande. Si un paquet de sondage est livré avec succès (tel que déterminé par le PL), alors le PLPMTU est augmenté à la taille du sondage réussi. Si un trou noir est détecté (par exemple, où des paquets de taille PLPMTU ne sont pas reçus de manière cohérente), la méthode réduit le PLPMTU.

Le PLPMTUD de datagramme introduit de la flexibilité dans l'implémentation. À un extrême, il peut être configuré pour effectuer uniquement la détection et la récupération de trou noir avec une robustesse accrue par rapport au PMTUD classique. À l'autre extrême, tout le traitement PTB peut être désactivé, et PLPMTUD remplace le PMTUD classique.

PLPMTUD peut également inclure des vérifications de cohérence supplémentaires sans augmenter le risque que des données soient perdues lors du sondage pour découvrir le MTU de chemin. Par exemple, les informations disponibles au PL, ou aux couches supérieures, permettent de valider les messages PTB reçus avant d'être utilisés.

1.3. Découverte du MTU de chemin pour les services de datagramme (Path MTU Discovery for Datagram Services)​

La Section 5 de ce document présente un ensemble d'algorithmes permettant aux protocoles de datagramme de découvrir la plus grande taille de datagramme non fragmenté pouvant être envoyé sur un chemin réseau. La méthode repose sur les fonctionnalités du PL décrites dans la Section 3 et s'applique aux protocoles de transport fonctionnant sur IPv4 et IPv6. Elle ne nécessite pas de coopération des couches inférieures, bien qu'elle puisse utiliser les messages PTB lorsque ces messages reçus sont mis à disposition du PL.

Les directives de taille de message dans la Section 3.2 des directives d'utilisation UDP [BCP145] stipulent qu'«une application DEVRAIT soit utiliser les informations de MTU de chemin fournies par la couche IP, soit implémenter la découverte du MTU de chemin (PMTUD)» mais ne fournissent pas de mécanisme pour découvrir la plus grande taille de datagramme non fragmenté pouvant être utilisé sur un chemin réseau. Le présent document met à jour RFC 8085 pour spécifier cette méthode à la place de PLPMTUD [RFC4821] et fournit un mécanisme pour partager la plus grande taille découverte en tant que MPS (voir Section 4.4).

La Section 10.2 de [RFC4821] recommandait une méthode de sondage PLPMTUD pour le protocole de contrôle de transmission en flux (Stream Control Transport Protocol, SCTP). SCTP utilise des paquets de sondage composés d'un chunk HEARTBEAT de taille minimale regroupé avec un chunk PAD tel que défini dans [RFC4820]. Cependant, RFC 4821 ne fournissait pas de spécification complète. Le présent document remplace cette description en fournissant une spécification complète.

Le protocole de contrôle de congestion de datagramme (Datagram Congestion Control Protocol, DCCP) [RFC4340] exige que les implémentations prennent en charge le PMTUD classique et stipule qu'un émetteur DCCP «DOIT maintenir le MPS autorisé pour chaque session DCCP active». Il définit également le MPS de contrôle de congestion actuel (Current Congestion Control MPS, CCMPS) pris en charge par un chemin réseau. Cela recommande l'utilisation de PMTUD et suggère l'utilisation de paquets de contrôle (DCCP-Sync) comme paquets de sondage de chemin car ils ne risquent pas la perte de données d'application. La méthode définie dans cette spécification peut être utilisée avec DCCP.

La Section 4 et la Section 5 définissent les mécanismes de protocole et la spécification pour la découverte du MTU de chemin de la couche de paquetisation de datagramme (Datagram Packetization Layer Path MTU Discovery, DPLPMTUD).

La Section 6 spécifie la méthode pour les transports de datagramme et fournit des informations pour permettre l'implémentation de PLPMTUD avec d'autres transports de datagramme et applications qui utilisent des transports de datagramme.

La Section 6 fournit également des recommandations pour les points de terminaison SCTP, mettant à jour [RFC4960], [RFC6951] et [RFC8261] pour utiliser la méthode spécifiée dans ce document au lieu de la méthode dans [RFC4821].

Dernière mise à jour le