6. Spécification des méthodes spécifiques aux protocoles
DPLPMTUD nécessite que des détails spécifiques au protocole soient spécifiés pour chaque PL qui l'utilise.
La première sous-section fournit des conseils sur la façon d'implémenter la méthode DPLPMTUD dans le cadre d'une application utilisant UDP ou UDP-Lite. Ces conseils sont également applicables à d'autres services de datagramme qui n'incluent pas de protocole de transport spécifique (comme l'encapsulation de tunnel). Les sous-sections suivantes décrivent comment implémenter DPLPMTUD dans le cadre d'un service de transport, permettant aux applications qui utilisent ce service de bénéficier de la découverte du PLPMTU sans avoir besoin d'implémenter elles-mêmes cette méthode lors de l'utilisation de SCTP et QUIC.
6.1. Support applicatif pour DPLPMTUD avec UDP ou UDP-Lite
Les spécifications actuelles d'UDP [RFC0768] et UDP-Lite [RFC3828] ne définissent pas de méthode dans la série RFC qui prend en charge PLPMTUD. En particulier, le transport UDP ne fournit pas les fonctionnalités de transport requises pour implémenter le datagramme PLPMTUD.
La méthode DPLPMTUD peut être implémentée dans le cadre d'une application construite directement ou indirectement sur UDP ou UDP-Lite, mais s'appuie sur les fonctionnalités de protocole de couche supérieure pour implémenter la méthode [BCP145].
Certaines primitives utilisées par DPLPMTUD peuvent ne pas être disponibles via l'API de datagramme (par exemple, la capacité d'accéder au PLPMTU à partir du cache de couche IP ou la capacité d'interpréter les messages PTB reçus).
De plus, il est RECOMMANDÉ que la découverte PMTU ne soit pas effectuée par plusieurs couches de protocole. Lorsque le système de transport sous-jacent fournit cette fonction, une application DEVRAIT éviter d'utiliser DPLPMTUD. Il y a des avantages à une méthode générique pour gérer le PLPMTU, à la fois pour partager l'état entre les processus et pour coordonner la sonde pour différentes instances PL.
6.1.1. Requête d'application
Une application a besoin d'un mécanisme de protocole de couche application (tel qu'une méthode d'accusé de réception de message) pour demander une réponse de l'extrémité de destination. La méthode DEVRAIT permettre à l'émetteur de vérifier les valeurs renvoyées dans la réponse pour fournir une protection supplémentaire contre l'injection de données hors du chemin [BCP145]. Les méthodes appropriées incluent des paramètres connus uniquement des deux extrémités, tels qu'un ID de session ou un numéro de séquence initialisé.
6.1.2. Réponse d'application
Une application a besoin d'un mécanisme de protocole de couche application pour communiquer une réponse de l'extrémité de destination. Cette réponse peut indiquer qu'une sonde a traversé avec succès le chemin, mais peut également indiquer que certains (ou tous) paquets n'ont pas atteint la destination.
6.1.3. Envoi de paquets de sonde d'application
Les paquets de sonde peuvent transporter un bloc de données d'application, mais il existe un risque que la transmission réussie de ces données soit menacée lorsqu'elle est utilisée pour la sonde. Certaines applications peuvent préférer utiliser des paquets de sonde qui ne transportent pas de bloc de données d'application pour éviter toute perturbation de la transmission de données.
6.1.4. Connectivité initiale
Une application qui n'a pas d'autres informations de couche supérieure confirmant la connectivité avec le pair distant DEVRAIT implémenter un mécanisme de connexion utilisant des paquets de sonde acquittés avant d'entrer dans l'état BASE.
6.1.5. Validation du chemin
Une application qui n'a pas d'autres informations de couche supérieure confirmant que les datagrammes sont correctement livrés DEVRAIT implémenter le CONFIRMATION_TIMER pour envoyer périodiquement des paquets de sonde lorsqu'elle est dans l'état SEARCH_COMPLETE.
6.1.6. Traitement des messages PTB
Les applications qui sont capables et souhaitent recevoir des messages PTB DOIVENT effectuer la validation ICMP spécifiée dans la section 5.2 de [BCP145]. Cela nécessite que l'application vérifie chaque message PTB reçu pour valider qu'il a été reçu en réponse au trafic transmis et que le PL_PTB_SIZE signalé est inférieur à la taille actuellement sondée (voir Section 4.6.2). Un message PTB validé PEUT être utilisé comme entrée de l'algorithme DPLPMTUD mais NE DOIT PAS être utilisé directement pour définir le PLPMTU.
6.2. DPLPMTUD pour SCTP
La section 10.2 de [RFC4821] spécifie une méthode de sondage PLPMTUD recommandée pour SCTP, et la section 7.3 de [RFC4960] recommande qu'un point terminal applique les techniques de RFC 4821 sur une base par adresse de destination. La spécification DPLPMTUD poursuit la pratique du PL découvrant le PMTU mais met à jour RFC4960 pour RECOMMANDER l'utilisation de la méthode spécifiée dans ce document: La méthode RECOMMANDÉE pour générer des sondes consiste à ajouter un morceau ne contenant que du remplissage à un message SCTP. Le morceau PAD défini dans [RFC4820] DEVRAIT être attaché à un morceau HEARTBEAT (HB) de longueur minimale pour construire un paquet de sonde. Cela rend le sondage indépendant du transfert de messages utilisateur et indépendant du contrôle de congestion ou du contrôle de flux. Ceci est préférable à l'utilisation de morceaux DATA (regroupés, si nécessaire, avec d'autres morceaux de contrôle) comme sondes de chemin.
La section 6.9 de [RFC4960] décrit l'émetteur PL segmentant les messages utilisateur en morceaux DATA lors de l'utilisation de SCTP. Cela note qu'une fois qu'un message SCTP est envoyé, il ne peut pas être re-segmenté. [RFC4960] décrit une méthode de retransmission des morceaux DATA lorsque le MPS est réduit, et la section 6.9 de [RFC4960] décrit l'utilisation de la fragmentation IP dans ce cas. Ce document n'apporte pas de modifications à cela.
6.2.1. SCTP/IPv4 et SCTP/IPv6
6.2.1.1. Connectivité initiale
Le protocole de base est spécifié dans [RFC4960]. Cela fournit un PL acquitté. Par conséquent, un émetteur peut entrer dans l'état BASE une fois que l'association a été confirmée.
6.2.1.2. Envoi de paquets de sonde SCTP
Le paquet de sonde se compose d'un en-tête commun SCTP, d'un morceau HEARTBEAT et d'un morceau PAD. Le morceau PAD est utilisé pour contrôler la longueur du paquet de sonde. Le morceau HEARTBEAT est utilisé pour déclencher l'envoi d'un morceau HEARTBEAT ACK. La réception d'un morceau HEARTBEAT ACK reconnaît la réception d'une sonde réussie. Les sondes réussies mettent à jour les compteurs d'association et de chemin, mais les sondes infructueuses sont ignorées (supposées être le résultat du choix d'un PLPMTU trop grand).
L'émetteur SCTP doit être capable de déterminer la taille totale d'un paquet de sonde. Le morceau HEARTBEAT peut transporter un paramètre d'information de battement de cœur qui, en plus des informations suggérées dans [RFC4960], inclut également la taille de la sonde pour aider les implémentations à associer un HEARTBEAT ACK à la taille de la sonde envoyée. D'autres méthodes sont possibles, comme l'envoi d'un nombre aléatoire et la vérification que les informations renvoyées contiennent également le nombre aléatoire correspondant.
La longueur du morceau PAD est calculée en réduisant la taille de l'en-tête commun SCTP et du morceau HEARTBEAT. La charge utile du morceau PAD contient des données arbitraires. Lors de la transmission sur IP, la taille PMTU inclut également l'en-tête IPv4 ou IPv6.
Le sondage peut commencer directement après la poignée de main PL; cela peut être fait avant l'envoi de données. En supposant ce comportement (c'est-à-dire que PMTU est inférieur ou égal à l'interface MTU), ce processus nécessitera plusieurs périodes de temps aller-retour, en fonction du nombre de sondes DPLPMTUD envoyées. Le temporisateur de battement de cœur peut être utilisé pour implémenter le PROBE_TIMER.
6.2.1.3. Validation du chemin avec SCTP
Étant donné que SCTP fournit un PL acquitté, un émetteur NE DOIT PAS implémenter le CONFIRMATION_TIMER lorsqu'il est dans l'état SEARCH_COMPLETE.
6.2.1.4. Traitement des messages PTB par SCTP
La validation ICMP normale DOIT être effectuée comme spécifié dans l'annexe C de [RFC4960]. Cela nécessite que les 8 premiers octets de l'en-tête commun SCTP soient cités dans la charge utile du message PTB, ce qui peut être le cas pour ICMPv4 et est généralement le cas pour ICMPv6.
Lorsqu'un message PTB a été validé, le PL_PTB_SIZE calculé à partir du PTB_SIZE signalé dans le message PTB DEVRAIT être utilisé avec l'algorithme DPLPMTUD, à condition que le PL_PTB_SIZE signalé soit inférieur à la taille de sonde actuelle (voir Section 4.6).
6.2.2. DPLPMTUD pour SCTP/UDP
L'encapsulation UDP de SCTP est spécifiée dans [RFC6951].
Cette spécification met à jour la référence à RFC 4821 dans la section 5.6 de RFC 6951 pour faire référence à ce document (RFC 8899). RFC 6951 est mis à jour en ajoutant la phrase suivante à la fin de la section 5.6 de RFC 6951:
La méthode RECOMMANDÉE pour déterminer le MTU de chemin est spécifiée dans RFC 8899.
6.2.2.1. Connectivité initiale
Un émetteur peut entrer dans l'état BASE une fois que l'association SCTP a été confirmée.
6.2.2.2. Envoi de paquets de sonde SCTP/UDP
Le sondage de datagramme peut être effectué comme spécifié dans Section 6.2.1.2. La taille des paquets de sonde inclut l'en-tête UDP de 8 octets. Cela doit être pris en compte lors du remplissage d'un paquet de sonde à l'aide d'un morceau PAD.
6.2.2.3. Validation du chemin avec SCTP/UDP
SCTP fournit un PL acquitté; par conséquent, un émetteur n'implémente pas le CONFIRMATION_TIMER lorsqu'il est dans l'état SEARCH_COMPLETE.
6.2.2.4. Traitement des messages PTB par SCTP/UDP
La validation ICMP des messages PTB DOIT être effectuée comme spécifié dans l'annexe C de [RFC4960]. Cela nécessite que les 8 premiers octets de l'en-tête commun SCTP soient présents dans le message PTB, ce qui pourrait être le cas pour ICMPv4 (mais notez que l'en-tête UDP consomme une partie de l'en-tête de paquet cité) et est généralement le cas pour ICMPv6. Lorsque la validation est terminée, le PL_PTB_SIZE calculé à partir du PTB_SIZE dans le message PTB DEVRAIT être utilisé avec DPLPMTUD, à condition que le PL_PTB_SIZE signalé soit inférieur à la taille de sonde actuelle.
6.2.3. DPLPMTUD pour SCTP/DTLS
L'encapsulation Datagram Transport Layer Security (DTLS) de SCTP est spécifiée dans [RFC8261]. Ceci est utilisé dans les canaux de données pour les implémentations WebRTC. Cette spécification met à jour la référence à RFC 4821 dans la section 5 de RFC 8261 pour faire référence à ce document (RFC 8899).
6.2.3.1. Connectivité initiale
Un émetteur peut entrer dans l'état BASE une fois que l'association SCTP a été confirmée.
6.2.3.2. Envoi de paquets de sonde SCTP/DTLS
Le sondage de datagramme peut être effectué comme spécifié dans Section 6.2.1.2. La charge utile maximale est réduite par la taille des en-têtes DTLS, ce qui doit être pris en compte lors du remplissage à l'aide d'un morceau PAD. La taille des paquets de sonde inclut l'en-tête PL DTLS. Cela doit être pris en compte lors du remplissage d'un paquet de sonde à l'aide d'un morceau PAD.
6.2.3.3. Validation du chemin avec SCTP/DTLS
Étant donné que SCTP fournit un PL acquitté, un émetteur NE DOIT PAS implémenter le CONFIRMATION_TIMER lorsqu'il est dans l'état SEARCH_COMPLETE.
6.2.3.4. Traitement des messages PTB par SCTP/DTLS
[RFC4960] ne spécifie pas de méthode pour la validation des charges utiles de message ICMP SCTP/DTLS, et ce document non plus. Cela empêche le traitement des messages PTB au niveau PL.
6.3. DPLPMTUD pour QUIC
QUIC [QUIC] est un PL basé sur UDP qui fournit une rétroaction de réception. La charge utile UDP comprend un en-tête de paquet QUIC, une charge utile protégée et tous les champs d'authentification. Il prend en charge le remplissage et la coalescence de paquets qui peuvent être utilisés pour construire des paquets de sonde. Du point de vue de DPLPMTUD, QUIC peut fonctionner comme un PL acquitté. [QUIC] décrit une méthode d'utilisation de DPLPMTUD avec des paquets QUIC.
Considérations d'implémentation
Lors de l'implémentation de DPLPMTUD pour un protocole spécifique:
- Choisir la méthode de sonde appropriée - Sélectionner le type de paquet de sonde le plus efficace en fonction des caractéristiques du protocole
- Utiliser les mécanismes existants - Utiliser les mécanismes d'acquittement et de battement de cœur intégrés dans la mesure du possible
- Considérer le surcoût d'encapsulation - Calculer correctement la taille des en-têtes à chaque couche
- Coordonner la gestion de l'état - Assurer que l'état PLPMTU se synchronise avec l'état de connexion du protocole
- Gérer les limitations spécifiques au protocole - Considérer les contraintes et exigences uniques de chaque protocole
Ces directives d'implémentation spécifiques au protocole garantissent que DPLPMTUD peut s'intégrer efficacement avec divers protocoles de transport.