6. Spezifikation protokollspezifischer Methoden
DPLPMTUD erfordert, dass für jeden PL, der es verwendet, protokollspezifische Details angegeben werden.
Der erste Unterabschnitt bietet Anleitung zur Implementierung der DPLPMTUD-Methode als Teil einer Anwendung, die UDP oder UDP-Lite verwendet. Diese Anleitung gilt auch für andere Datagrammdienste, die kein spezifisches Transportprotokoll enthalten (wie Tunnelkapselung). Die folgenden Unterabschnitte beschreiben, wie DPLPMTUD als Teil eines Transportdienstes implementiert wird, sodass Anwendungen, die diesen Dienst nutzen, von der Erkennung der PLPMTU profitieren können, ohne diese Methode selbst implementieren zu müssen, wenn sie SCTP und QUIC verwenden.
6.1. Anwendungsunterstützung für DPLPMTUD mit UDP oder UDP-Lite
Die aktuellen Spezifikationen von UDP [RFC0768] und UDP-Lite [RFC3828] definieren keine Methode in der RFC-Serie, die PLPMTUD unterstützt. Insbesondere bietet der UDP-Transport nicht die erforderlichen Transportfunktionen zur Implementierung von Datagramm-PLPMTUD.
Die DPLPMTUD-Methode kann als Teil einer Anwendung implementiert werden, die direkt oder indirekt auf UDP oder UDP-Lite aufbaut, stützt sich jedoch auf Protokollfunktionen höherer Schichten zur Implementierung der Methode [BCP145].
Einige von DPLPMTUD verwendete Primitive sind möglicherweise nicht über die Datagramm-API verfügbar (z.B. die Fähigkeit, auf die PLPMTU aus dem IP-Schicht-Cache zuzugreifen oder die Fähigkeit, empfangene PTB-Nachrichten zu interpretieren).
Darüber hinaus wird EMPFOHLEN, dass die PMTU-Erkennung nicht von mehreren Protokollschichten durchgeführt wird. Wenn das zugrunde liegende Transportsystem diese Funktion bereitstellt, SOLLTE eine Anwendung DPLPMTUD vermeiden. Es gibt Vorteile einer generischen Methode zur Verwaltung der PLPMTU, sowohl beim Teilen des Zustands zwischen Prozessen als auch bei der Koordinierung des Sondierens für verschiedene PL-Instanzen.
6.1.1. Anwendungsanforderung
Eine Anwendung benötigt einen Anwendungsschicht-Protokollmechanismus (wie eine Nachrichtenbestätigungsmethode), um eine Antwort vom Ziel-Endpunkt anzufordern. Die Methode SOLLTE dem Sender ermöglichen, in der Antwort zurückgegebene Werte zu überprüfen, um zusätzlichen Schutz gegen die Injektion von Daten von außerhalb des Pfades zu bieten [BCP145]. Geeignete Methoden umfassen Parameter, die nur den beiden Endpunkten bekannt sind, wie eine Sitzungs-ID oder eine initialisierte Sequenznummer.
6.1.2. Anwendungsantwort
Eine Anwendung benötigt einen Anwendungsschicht-Protokollmechanismus, um eine Antwort vom Ziel-Endpunkt zu kommunizieren. Diese Antwort kann anzeigen, dass eine Sondierung den Pfad erfolgreich durchquert hat, kann aber auch anzeigen, dass einige (oder alle) Pakete das Ziel nicht erreicht haben.
6.1.3. Senden von Anwendungssondierungspaketen
Sondierungspakete können einen Anwendungsdatenblock tragen, aber es besteht das Risiko, dass die erfolgreiche Übertragung dieser Daten gefährdet ist, wenn sie zum Sondieren verwendet wird. Einige Anwendungen bevorzugen möglicherweise Sondierungspakete, die keinen Anwendungsdatenblock tragen, um Störungen der Datenübertragung zu vermeiden.
6.1.4. Anfängliche Konnektivität
Eine Anwendung, die keine anderen höherschichtigen Informationen hat, die die Konnektivität mit dem entfernten Peer bestätigen, SOLLTE einen Mechanismus für die Verbindung unter Verwendung bestätigter Sondierungspakete implementieren, bevor sie in den BASE-Zustand eintritt.
6.1.5. Validierung des Pfades
Eine Anwendung, die keine anderen höherschichtigen Informationen hat, die bestätigen, dass Datagramme korrekt zugestellt werden, SOLLTE den CONFIRMATION_TIMER implementieren, um periodisch Sondierungspakete zu senden, wenn sie sich im SEARCH_COMPLETE-Zustand befindet.
6.1.6. Behandlung von PTB-Nachrichten
Anwendungen, die in der Lage sind und PTB-Nachrichten empfangen möchten, MÜSSEN die in Abschnitt 5.2 von [BCP145] spezifizierte ICMP-Validierung durchführen. Dies erfordert, dass die Anwendung jede empfangene PTB-Nachricht überprüft, um zu validieren, dass sie als Antwort auf übertragenen Verkehr empfangen wurde und dass die gemeldete PL_PTB_SIZE kleiner ist als die aktuell sondierte Größe (siehe Abschnitt 4.6.2). Eine validierte PTB-Nachricht KANN als Eingabe für den DPLPMTUD-Algorithmus verwendet werden, DARF jedoch NICHT direkt verwendet werden, um die PLPMTU festzulegen.
6.2. DPLPMTUD für SCTP
Abschnitt 10.2 von [RFC4821] spezifiziert eine empfohlene PLPMTUD-Sondierungsmethode für SCTP, und Abschnitt 7.3 von [RFC4960] empfiehlt, dass ein Endpunkt die Techniken in RFC 4821 auf Basis der Zieladresse anwendet. Die DPLPMTUD-Spezifikation setzt die Praxis fort, dass der PL die PMTU ermittelt, aktualisiert jedoch RFC4960, um die Verwendung der in diesem Dokument spezifizierten Methode zu EMPFEHLEN: Die EMPFOHLENE Methode zur Erzeugung von Sondierungen besteht darin, einen Chunk hinzuzufügen, der nur aus Padding besteht, zu einer SCTP-Nachricht. Der in [RFC4820] definierte PAD-Chunk SOLLTE an einen minimalen HEARTBEAT (HB)-Chunk angehängt werden, um ein Sondierungspaket zu erstellen. Dies macht das Sondieren unabhängig von der Übertragung von Benutzernachrichten und unabhängig von Stauungs- oder Flusssteuerung. Dies wird bevorzugt gegenüber der Verwendung von DATA-Chunks (bei Bedarf gebündelt mit anderen Kontroll-Chunks) als Pfadsondierungen.
Abschnitt 6.9 von [RFC4960] beschreibt den PL-Sender, der Benutzernachrichten in DATA-Chunks segmentiert, wenn SCTP verwendet wird. Dies bemerkt, dass eine SCTP-Nachricht, sobald sie gesendet wurde, nicht neu segmentiert werden kann. [RFC4960] beschreibt eine Methode zur Neuübertragung von DATA-Chunks, wenn die MPS reduziert wird, und Abschnitt 6.9 von [RFC4960] beschreibt die Verwendung von IP-Fragmentierung in diesem Fall. Dieses Dokument nimmt keine Änderungen daran vor.
6.2.1. SCTP/IPv4 und SCTP/IPv6
6.2.1.1. Anfängliche Konnektivität
Das Basisprotokoll ist in [RFC4960] spezifiziert. Dies bietet einen bestätigten PL. Daher kann ein Sender in den BASE-Zustand eintreten, sobald die Assoziation bestätigt wurde.
6.2.1.2. Senden von SCTP-Sondierungspaketen
Das Sondierungspaket besteht aus einem SCTP-Gemeinsamen-Header, einem HEARTBEAT-Chunk und einem PAD-Chunk. Der PAD-Chunk wird verwendet, um die Länge des Sondierungspakets zu steuern. Der HEARTBEAT-Chunk wird verwendet, um das Senden eines HEARTBEAT ACK-Chunks auszulösen. Der Empfang eines HEARTBEAT ACK-Chunks bestätigt den Empfang einer erfolgreichen Sondierung. Erfolgreiche Sondierungen aktualisieren die Assoziations- und Pfadzähler, aber erfolglose Sondierungen werden ignoriert (angenommen, sie sind das Ergebnis der Wahl einer zu großen PLPMTU).
Der SCTP-Sender muss in der Lage sein, die Gesamtgröße eines Sondierungspakets zu bestimmen. Der HEARTBEAT-Chunk kann einen Heartbeat-Informationsparameter tragen, der zusätzlich zu den in [RFC4960] vorgeschlagenen Informationen auch die Größe der Sondierung enthält, um Implementierungen zu helfen, einen HEARTBEAT ACK mit der Größe der gesendeten Sondierung zu verknüpfen. Andere Methoden sind möglich, wie das Senden einer Zufallszahl und das Überprüfen, dass die zurückgegebenen Informationen auch die entsprechende Zufallszahl enthalten.
Die Länge des PAD-Chunks wird berechnet, indem die Größe des SCTP-Gemeinsamen-Headers und des HEARTBEAT-Chunks reduziert wird. Die Nutzlast des PAD-Chunks enthält willkürliche Daten. Bei Übertragung über IP umfasst die PMTU-Größe auch den IPv4- oder IPv6-Header.
Das Sondieren kann direkt nach dem PL-Handshake beginnen; dies kann erfolgen, bevor Daten gesendet werden. Unter Annahme dieses Verhaltens (d.h. PMTU ist kleiner oder gleich der Schnittstellen-MTU) erfordert dieser Prozess mehrere Round-Trip-Zeitperioden, abhängig von der Anzahl der gesendeten DPLPMTUD-Sondierungen. Der Heartbeat-Timer kann verwendet werden, um den PROBE_TIMER zu implementieren.
6.2.1.3. Validierung des Pfades mit SCTP
Da SCTP einen bestätigten PL bereitstellt, DARF ein Sender den CONFIRMATION_TIMER NICHT implementieren, wenn er sich im SEARCH_COMPLETE-Zustand befindet.
6.2.1.4. PTB-Nachrichten-Behandlung durch SCTP
Normale ICMP-Validierung MUSS wie in Anhang C von [RFC4960] spezifiziert durchgeführt werden. Dies erfordert, dass die ersten 8 Bytes des SCTP-Gemeinsamen-Headers in der Nutzlast der PTB-Nachricht zitiert werden, was für ICMPv4 der Fall sein kann und normalerweise für ICMPv6 der Fall ist.
Wenn eine PTB-Nachricht validiert wurde, SOLLTE die aus dem in der PTB-Nachricht gemeldeten PTB_SIZE berechnete PL_PTB_SIZE mit dem DPLPMTUD-Algorithmus verwendet werden, vorausgesetzt, die gemeldete PL_PTB_SIZE ist kleiner als die aktuelle Sondierungsgröße (siehe Abschnitt 4.6).
6.2.2. DPLPMTUD für SCTP/UDP
Die UDP-Kapselung von SCTP ist in [RFC6951] spezifiziert.
Diese Spezifikation aktualisiert die Referenz auf RFC 4821 in Abschnitt 5.6 von RFC 6951, um auf dieses Dokument (RFC 8899) zu verweisen. RFC 6951 wird aktualisiert, indem am Ende von Abschnitt 5.6 von RFC 6951 der folgende Satz hinzugefügt wird:
Die EMPFOHLENE Methode zur Bestimmung der Pfad-MTU ist in RFC 8899 spezifiziert.
6.2.2.1. Anfängliche Konnektivität
Ein Sender kann in den BASE-Zustand eintreten, sobald die SCTP-Assoziation bestätigt wurde.
6.2.2.2. Senden von SCTP/UDP-Sondierungspaketen
Datagramm-Sondierung kann wie in Abschnitt 6.2.1.2 spezifiziert durchgeführt werden. Die Größe der Sondierungspakete umfasst den 8-Byte-UDP-Header. Dies muss berücksichtigt werden, wenn ein Sondierungspaket mit einem PAD-Chunk aufgefüllt wird.
6.2.2.3. Validierung des Pfades mit SCTP/UDP
SCTP bietet einen bestätigten PL; daher implementiert ein Sender den CONFIRMATION_TIMER nicht, wenn er sich im SEARCH_COMPLETE-Zustand befindet.
6.2.2.4. Behandlung von PTB-Nachrichten durch SCTP/UDP
Die ICMP-Validierung von PTB-Nachrichten MUSS wie in Anhang C von [RFC4960] spezifiziert durchgeführt werden. Dies erfordert, dass die ersten 8 Bytes des SCTP-Gemeinsamen-Headers in der PTB-Nachricht vorhanden sind, was für ICMPv4 der Fall sein könnte (beachten Sie jedoch, dass der UDP-Header einen Teil des zitierten Paket-Headers verbraucht) und normalerweise für ICMPv6 der Fall ist. Wenn die Validierung abgeschlossen ist, SOLLTE die aus dem PTB_SIZE in der PTB-Nachricht berechnete PL_PTB_SIZE mit DPLPMTUD verwendet werden, vorausgesetzt, die gemeldete PL_PTB_SIZE ist kleiner als die aktuelle Sondierungsgröße.
6.2.3. DPLPMTUD für SCTP/DTLS
Die Datagram Transport Layer Security (DTLS)-Kapselung von SCTP ist in [RFC8261] spezifiziert. Dies wird in Datenkanälen für WebRTC-Implementierungen verwendet. Diese Spezifikation aktualisiert die Referenz auf RFC 4821 in Abschnitt 5 von RFC 8261, um auf dieses Dokument (RFC 8899) zu verweisen.
6.2.3.1. Anfängliche Konnektivität
Ein Sender kann in den BASE-Zustand eintreten, sobald die SCTP-Assoziation bestätigt wurde.
6.2.3.2. Senden von SCTP/DTLS-Sondierungspaketen
Datagramm-Sondierung kann wie in Abschnitt 6.2.1.2 spezifiziert durchgeführt werden. Die maximale Nutzlast wird durch die Größe der DTLS-Header reduziert, was beim Auffüllen mit einem PAD-Chunk berücksichtigt werden muss. Die Größe der Sondierungspakete umfasst den DTLS-PL-Header. Dies muss berücksichtigt werden, wenn ein Sondierungspaket mit einem PAD-Chunk aufgefüllt wird.
6.2.3.3. Validierung des Pfades mit SCTP/DTLS
Da SCTP einen bestätigten PL bereitstellt, DARF ein Sender den CONFIRMATION_TIMER NICHT implementieren, wenn er sich im SEARCH_COMPLETE-Zustand befindet.
6.2.3.4. Behandlung von PTB-Nachrichten durch SCTP/DTLS
[RFC4960] spezifiziert keine Methode zur Validierung von SCTP/DTLS-ICMP-Nachrichten-Nutzlasten, und dieses Dokument auch nicht. Dies verhindert die Verarbeitung von PTB-Nachrichten auf der PL.
6.3. DPLPMTUD für QUIC
QUIC [QUIC] ist ein UDP-basierter PL, der Empfangsrückmeldung bietet. Die UDP-Nutzlast umfasst einen QUIC-Paket-Header, eine geschützte Nutzlast und alle Authentifizierungsfelder. Es unterstützt Padding und Paketkoaleszenz, die zum Konstruieren von Sondierungspaketen verwendet werden können. Aus der Perspektive von DPLPMTUD kann QUIC als bestätigter PL funktionieren. [QUIC] beschreibt eine Methode zur Verwendung von DPLPMTUD mit QUIC-Paketen.
Implementierungsüberlegungen
Bei der Implementierung von DPLPMTUD für ein spezifisches Protokoll:
- Wählen Sie die geeignete Sondierungsmethode - Wählen Sie den effizientesten Sondierungspakettyp basierend auf Protokollcharakteristiken
- Nutzen Sie vorhandene Mechanismen - Verwenden Sie nach Möglichkeit eingebaute Bestätigungs- und Heartbeat-Mechanismen
- Berücksichtigen Sie den Kapselungsaufwand - Berechnen Sie die Größe der Header auf jeder Schicht korrekt
- Koordinieren Sie die Zustandsverwaltung - Stellen Sie sicher, dass der PLPMTU-Zustand mit dem Protokollverbindungszustand synchronisiert wird
- Behandeln Sie protokollspezifische Einschränkungen - Berücksichtigen Sie die einzigartigen Beschränkungen und Anforderungen jedes Protokolls
Diese protokollspezifischen Implementierungsrichtlinien stellen sicher, dass DPLPMTUD sich effektiv mit verschiedenen Transportprotokollen integrieren kann.