4. Mécanismes DPLPMTUD

Cette section liste les mécanismes de protocole utilisés dans cette spécification.

4.1. Paquets de sondage PLPMTU

La méthode DPLPMTUD repose sur la capacité de l'émetteur PL à générer des paquets de sondage d'une taille spécifique. TCP est capable de générer ces paquets de sondage en choisissant un segment approprié de données envoyées [RFC4821]. En revanche, un PL de datagramme qui construit un paquet de sondage doit soit demander à l'application d'envoyer un bloc de données plus grand que celui généré par l'application, soit utiliser des fonctions de remplissage pour étendre un datagramme au-delà de la taille du bloc de données d'application. Les protocoles qui permettent l'échange de messages de contrôle (sans bloc de données d'application) peuvent générer un paquet de sondage en étendant un message de contrôle avec des données de remplissage. La taille totale d'un paquet de sondage inclut tous les en-têtes et le remplissage ajoutés aux données de charge utile envoyées (par exemple, y compris les champs d'option de protocole, les champs liés à la sécurité tels qu'une balise AEAD et le remplissage de la couche d'enregistrement TLS).

REQUIS: Le récepteur doit être capable de distinguer entre les blocs de données en bande et tout remplissage ajouté. Cela est nécessaire pour garantir que tout remplissage ajouté n'est pas transmis à l'application réceptrice.

Trois méthodes pour créer des paquets de sondage

1. Sondage utilisant des données de remplissage

Un paquet de sondage qui contient uniquement des informations de contrôle ainsi que tout remplissage nécessaire pour gonfler la longueur du datagramme à la taille du paquet de sondage. Étant donné que ces paquets de sondage ne transportent pas de bloc de données fourni par l'application, ils ne nécessitent généralement pas de retransmission, bien qu'ils consomment toujours de la capacité réseau et entraînent un traitement d'extrémité.

2. Sondage utilisant des données d'application et des données de remplissage

Un paquet de sondage qui contient un bloc de données fourni par une application qui est combiné avec du remplissage pour gonfler la longueur du datagramme à la taille du paquet de sondage.

3. Sondage utilisant des données d'application

Un paquet de sondage qui contient un bloc de données fourni par une application qui correspond à la taille d'un paquet de sondage. Cette méthode demande à l'application d'émettre un bloc de données de la taille de sondage souhaitée.

Protection des paquets de sondage

Les PL qui utilisent des paquets de sondage transportant des données d'application qui doivent être résilients à la perte de ce paquet de sondage peuvent effectuer une retransmission/réparation de la couche transport du bloc de données (par exemple, par retransmission après détection de la perte ou par duplication du bloc de données dans un datagramme sans les données de remplissage). Ce bloc de données retransmis peut devoir être envoyé en utilisant un PLPMTU plus petit, ce qui pourrait forcer le PL à utiliser une taille de paquet plus petite pour traverser le chemin de bout en bout (Cela pourrait utiliser la fragmentation de couche réseau d'extrémité ou pourrait segmenter le bloc de données en plusieurs datagrammes par un PL).

DPLPMTUD PEUT choisir d'utiliser une seule de ces méthodes pour simplifier l'implémentation.

Identification des paquets de sondage

Les messages de sondage envoyés par le PL DOIVENT contenir suffisamment d'informations pour identifier de manière unique le sondage dans la durée de vie maximale des segments (par exemple, y compris un identifiant unique du PL ou de l'implémentation DPLPMTUD) et être robustes au réordonnancement et à la relecture des réponses de sondage et des messages PTB.

4.2. Confirmation de la taille du paquet sondé

Le PL a besoin d'une méthode pour déterminer (confirmer) quand un paquet de sondage a été reçu avec succès de bout en bout sur un chemin réseau.

Les protocoles de transport peuvent inclure des méthodes de bout en bout qui détectent et signalent la réception de datagrammes spécifiques qu'ils envoient (par exemple, DCCP, SCTP et QUIC fournissent des fonctions de maintien en vie/battement de cœur). Lorsqu'il est pris en charge, ce mécanisme PEUT également être utilisé par DPLPMTUD pour accuser réception d'un paquet de sondage.

Les PL qui n'accusent pas réception de données (par exemple, UDP et UDP-Lite) sont incapables par eux-mêmes de détecter quand un paquet qu'ils envoient a été supprimé parce que sa taille est supérieure au PMTU réel. Ces PL doivent s'appuyer sur un protocole d'application pour détecter cette perte.

Section 6 spécifie cette fonction pour un ensemble de protocoles spécifiés par l'IETF.

4.3. Détection de trou noir et réduction du PLPMTU

La description ci-dessous utilise l'ensemble des constantes définies dans Section 5.1.2 et les variables définies dans Section 5.1.3.

La détection de trou noir est déclenchée par une indication que le chemin réseau pourrait être incapable de prendre en charge la taille PLPMTU actuelle.

Trois indicateurs de détection de trou noir

1. Indication de message PTB

Un message PTB validé peut être reçu qui indique un PL_PTB_SIZE inférieur au PLPMTU actuel. La méthode DPLPMTUD NE DOIT PAS se fier uniquement à cette méthode.

2. Sondage périodique

Le PL peut utiliser le mécanisme de sondage DPLPMTUD pour générer périodiquement des paquets de sondage de la taille PLPMTU actuelle (par exemple, en utilisant le CONFIRMATION_TIMER, Section 5.1.1). Un minuteur suit si des accusés de réception sont reçus. La perte successive de sondes est une indication que le chemin actuel ne soutient plus le PLPMTU (par exemple, lorsque le nombre de paquets de sondage envoyés sans recevoir d'accusé de réception, PROBE_COUNT, devient supérieur à MAX_PROBES).

3. Indication d'événement PL

Le PL peut utiliser un événement qui indique que le chemin réseau ne soutient plus la taille PLPMTU de l'émetteur. Cela peut être détecté en utilisant des mécanismes implémentés dans le PL pour détecter une perte excessive de données envoyées avec une taille de paquet spécifique, puis déduire que cette perte excessive pourrait être le résultat d'un PLPMTU invalide (comme pour PLPMTUD pour TCP [RFC4821]).

Différences de modèle de sondage

Ces trois méthodes peuvent entraîner des modèles de transmission différents pour les paquets utilisés comme sondes et devraient entraîner une réactivité différente après un changement PMTU réel.

Suppression de sondage

PEUT: Le PL supprimer l'envoi de paquets de sondage lorsqu'une application n'a pas envoyé de données depuis le dernier paquet de sondage.

Un PL qui reprend l'envoi de données utilisateur PEUT continuer à utiliser la découverte PLPMTU pour chaque chemin. Cela lui permet d'utiliser le dernier PLPMTU. Cependant, cela pourrait entraîner l'envoi de paquets supplémentaires.

Réduction PLPMTU

Lorsque la méthode détecte que le PLPMTU actuel n'est pas pris en charge, DPLPMTUD définit un PLPMTU inférieur et un MPS inférieur. Le PL confirme ensuite que le nouveau PLPMTU peut être utilisé avec succès pour le chemin. Les paquets de sondage peuvent devoir être plus petits que la taille des blocs de données générés par l'application.

4.4. La taille maximale de paquet (MPS)

Le résultat du sondage détermine le PLPMTU disponible, qui est utilisé pour définir le MPS utilisé par l'application. Le MPS est plus petit que le PLPMTU car il est réduit par la taille des en-têtes PL (y compris la surcharge pour les champs liés à la sécurité tels que les balises AEAD et le remplissage de la couche d'enregistrement TLS).

Relation entre MPS et PLPMTU

|<----- PLPMTU ----->|
|<-- MPS -->|  En-têtes PL  |  En-têtes IP  |
| Données app | Transport | Sécurité | Réseau |

Le PL ne peut pas envoyer un paquet (autre qu'un paquet de sondage) avec une taille au niveau de la couche réseau supérieure au PLPMTU actuel. Pour éviter cela, un PL PEUT être conçu pour segmenter des blocs de données plus grands que le MPS en plusieurs datagrammes.

DPLPMTUD cherche à éviter la fragmentation IP. Si le PL est incapable de segmenter les données, une tentative d'envoi d'un bloc de données plus grand que le MPS échouera. Pour déterminer le plus grand bloc de données pouvant être envoyé, un PL DEVRAIT fournir une primitive à l'application qui renvoie le MPS dérivé du PLPMTU actuel.

Gestion du changement MPS

Si DPLPMTUD entraîne un changement du MPS, les applications doivent s'adapter au nouveau MPS. Un cas particulier peut survenir lorsque des paquets sont envoyés avec une taille inférieure au MPS et que le PLPMTU est ensuite réduit. Si ces paquets sont perdus, le PL PEUT segmenter les données en utilisant le nouveau MPS.

Si le PL est incapable de resegmenter un datagramme précédemment envoyé (par exemple, [RFC4960]), l'émetteur supprime soit le datagramme, soit peut effectuer une retransmission en utilisant la fragmentation de couche réseau pour former plusieurs paquets IP ne dépassant pas le PLPMTU. Pour IPv4, l'émetteur utilise la fragmentation d'extrémité de préférence à l'effacement du bit DF dans l'en-tête IPv4. L'expérience opérationnelle montre que la fragmentation IP peut réduire la fiabilité de la communication Internet [RFC8900], ce qui pourrait réduire la probabilité de retransmission réussie.

4.5. Désactivation de l'effet du PMTUD

Un PL implémentant cette spécification DOIT suspendre l'application du PMTU [RFC1191] [RFC8201] pour le traitement de couche réseau des paquets sortants pour chaque flux qui utilise DPLPMTUD et utiliser à la place DPLPMTUD pour contrôler la taille des paquets que le flux envoie. Cela élimine le besoin pour la couche réseau de supprimer ou de fragmenter les paquets envoyés avec une taille supérieure au PMTU.

4.6. Réponse aux messages PTB

Cette méthode exige que l'émetteur DPLPMTUD valide tout message PTB reçu avant d'utiliser les informations PTB. La réponse à un message PTB dépend du PL_PTB_SIZE calculé à partir du PTB_SIZE dans le message PTB, de l'état de la machine à états PLPMTUD et du protocole IP en cours d'utilisation.

Section 4.6.1 décrit la validation des messages ICMP Unreachable IPv4 (Type 3) et des messages ICMPv6 Packet Too Big, tous deux appelés messages PTB dans ce document.

4.6.1. Validation des messages PTB

Cette section spécifie l'utilisation et la validation des messages PTB.

Options d'implémentation

• Implémentation simple: PEUT ignorer les messages PTB reçus, auquel cas le PLPMTU n'est pas mis à jour lorsqu'un message PTB est reçu.

• PL prenant en charge PTB: DOIT valider ces messages avant un traitement ultérieur.

Processus de validation

Un PL qui reçoit un message PTB d'un routeur ou d'une middlebox effectue une validation ICMP (voir Section 4 de [RFC8201] et Section 5.2 de [BCP145]). Étant donné que DPLPMTUD fonctionne au niveau PL, le PL doit vérifier chaque message PTB reçu pour déterminer s'il a été reçu en réponse à un paquet provenant de l'extrémité PL effectuant DPLPMTUD.

Le PL DOIT vérifier les informations de protocole dans le paquet cité transporté dans une charge utile de message ICMP PTB pour valider que le message provient du nœud émetteur. Cette validation inclut la détermination que la combinaison d'adresses IP, de protocole, de port source et de port de destination correspond à la combinaison renvoyée dans le paquet cité -- cela est également nécessaire pour que le message PTB soit transmis au PL correspondant.

La validation DEVRAIT utiliser des informations qui ne sont pas facilement disponibles pour un attaquant hors chemin [BCP145]. Par exemple, elle peut vérifier la valeur des champs d'en-tête de protocole connus uniquement des deux extrémités PL. Les applications de datagramme utilisant des ports source et de destination bien connus devraient également s'appuyer sur d'autres informations pour compléter cette validation.

Ces vérifications visent à fournir une protection contre les paquets provenant d'un nœud qui n'est pas sur le chemin réseau. Les messages PTB qui n'ont pas terminé la validation NE DOIVENT PAS être utilisés davantage par la méthode DPLPMTUD, comme discuté dans la section Considérations de sécurité (Section 8).

Section 4.6.2 décrit le traitement des messages PTB.

4.6.2. Utilisation des messages PTB

Un message PTB validé PEUT être utilisé par l'algorithme DPLPMTUD mais NE DOIT PAS être utilisé directement pour définir le PLPMTU.

Avant d'utiliser la taille signalée dans le message PTB, elle doit d'abord être convertie en PL_PTB_SIZE. Le PL_PTB_SIZE est plus petit que le PTB_SIZE car il est réduit par les en-têtes en dessous du PL, y compris toutes les options ou extensions IP ajoutées au paquet PL.

Les méthodes qui utilisent ces messages PTB peuvent améliorer la vitesse à laquelle l'algorithme détecte un PLPMTU approprié en déclenchant un sondage immédiat pour un PL_PTB_SIZE (résultant en une taille de paquet de couche réseau de PTB_SIZE), par rapport aux méthodes qui reposent uniquement sur un algorithme de recherche basé sur un minuteur.

Un ensemble de vérifications vise à fournir une protection contre un routeur signalant un PTB_SIZE inattendu. Le PL doit également vérifier que le PL_PTB_SIZE indiqué est inférieur à la taille utilisée par un paquet de sondage et au moins la taille minimale acceptée.

Résumé du traitement des messages PTB

Cette section fournit un résumé de la façon dont les messages PTB sont utilisés, en utilisant l'ensemble des constantes définies dans Section 5.1.2. Ce traitement dépend du PL_PTB_SIZE et des valeurs actuelles d'un ensemble de variables:

PL_PTB_SIZE < MIN_PLPMTU

• PL_PTB_SIZE invalide, voir Section 4.6.1
• Le message PTB devrait être supprimé sans traitement ultérieur (c'est-à-dire que le PLPMTU n'est pas modifié)
• Ces informations pourraient être utilisées comme entrée pour déclencher l'activation d'un mode de résilience (voir Section 5.3.3)

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU

• Un PL robuste PEUT entrer dans l'état d'erreur (voir Section 5.2) pour un chemin IPv4 lorsque le PL_PTB_SIZE signalé dans le message PTB est supérieur ou égal à 68 octets [RFC0791] et inférieur à BASE_PLPMTU
• Un PL robuste PEUT entrer dans l'état d'erreur (voir Section 5.2) pour un chemin IPv6 lorsque le PL_PTB_SIZE signalé dans le message PTB est supérieur ou égal à 1280 octets [RFC8200] et inférieur à BASE_PLPMTU

BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU

• Cela pourrait être une indication d'un trou noir. Le PLPMTU DEVRAIT être défini sur BASE_PLPMTU (le PLPMTU est réduit à BASE_PLPMTU pour éviter une perte de paquets inutile lors de la rencontre d'un trou noir)
• Le PL devrait commencer une recherche pour découvrir rapidement le nouveau PLPMTU. Le PL_PTB_SIZE signalé dans le message PTB peut être utilisé pour initialiser l'algorithme de recherche

PLPMTU < PL_PTB_SIZE < PROBED_SIZE

• Le PLPMTU continue d'être valide, mais la taille utilisée pour une recherche (PROBED_SIZE) est supérieure au PMTU réel
• Le PLPMTU n'est pas mis à jour
• Lorsqu'il reprend l'algorithme de recherche, le PL peut utiliser le PL_PTB_SIZE signalé dans le message PTB comme prochain point de recherche

PL_PTB_SIZE >= PROBED_SIZE

• Signal réseau incohérent
• Le message PTB devrait être supprimé sans traitement ultérieur (c'est-à-dire que le PLPMTU n'est pas modifié)
• Ces informations pourraient être utilisées comme entrée déclenchant l'activation d'un mode de résilience

Ces mécanismes garantissent ensemble que DPLPMTUD peut découvrir et maintenir de manière fiable un MTU de chemin approprié.