4. DPLPMTUD-Mechanismen

Dieser Abschnitt listet die in dieser Spezifikation verwendeten Protokollmechanismen auf.

4.1. PLPMTU-Sondierungspakete

Die DPLPMTUD-Methode beruht darauf, dass der PL-Sender in der Lage ist, Sondierungspakete mit einer bestimmten Größe zu erzeugen. TCP ist in der Lage, diese Sondierungspakete zu erzeugen, indem es ein geeignetes Segment der zu sendenden Daten auswählt [RFC4821]. Im Gegensatz dazu muss ein Datagramm-PL, der ein Sondierungspaket konstruiert, entweder die Anwendung auffordern, einen Datenblock zu senden, der größer ist als der von der Anwendung erzeugte, oder Padding-Funktionen nutzen, um ein Datagramm über die Größe des Anwendungsdatenblocks hinaus zu erweitern. Protokolle, die den Austausch von Kontrollnachrichten (ohne Anwendungsdatenblock) erlauben, können ein Sondierungspaket erzeugen, indem sie eine Kontrollnachricht mit Padding-Daten erweitern. Die Gesamtgröße eines Sondierungspakets umfasst alle Header und Padding, die den zu sendenden Payload-Daten hinzugefügt werden (z.B. einschließlich Protokolloptionsfelder, sicherheitsbezogene Felder wie ein AEAD-Tag und TLS-Record-Layer-Padding).

ERFORDERLICH: Der Empfänger muss in der Lage sein, zwischen Inband-Datenblöcken und hinzugefügtem Padding zu unterscheiden. Dies ist erforderlich, um sicherzustellen, dass hinzugefügtes Padding nicht an die empfangende Anwendung weitergegeben wird.

Drei Methoden zur Erstellung von Sondierungspaketen

1. Sondierung mit Padding-Daten

Ein Sondierungspaket, das nur Kontrollinformationen zusammen mit dem zum Aufblähen der Länge des Datagramms auf die Größe des Sondierungspakets erforderlichen Padding enthält. Da diese Sondierungspakete keinen von der Anwendung bereitgestellten Datenblock transportieren, erfordern sie normalerweise keine Neuübertragung, obwohl sie immer noch Netzwerkkapazität verbrauchen und Endpunkt-Verarbeitung verursachen.

2. Sondierung mit Anwendungsdaten und Padding-Daten

Ein Sondierungspaket, das einen von einer Anwendung bereitgestellten Datenblock enthält, der mit Padding kombiniert wird, um die Länge des Datagramms auf die Größe des Sondierungspakets aufzublähen.

3. Sondierung mit Anwendungsdaten

Ein Sondierungspaket, das einen von einer Anwendung bereitgestellten Datenblock enthält, der der Größe eines Sondierungspakets entspricht. Diese Methode fordert die Anwendung auf, einen Datenblock der gewünschten Sondierungsgröße auszugeben.

Schutz von Sondierungspaketen

PLs, die Sondierungspakete verwenden, die Anwendungsdaten transportieren und gegen den Verlust dieses Sondierungspakets resilient sein müssen, können eine Neuübertragung/Reparatur des Datenblocks auf der Transportschicht durchführen (z.B. durch Neuübertragung nach Erkennung des Verlusts oder durch Duplizierung des Datenblocks in einem Datagramm ohne die Padding-Daten). Dieser neu übertragene Datenblock muss möglicherweise unter Verwendung einer kleineren PLPMTU gesendet werden, was den PL zwingen könnte, eine kleinere Paketgröße zu verwenden, um den Ende-zu-Ende-Pfad zu durchqueren (Dies könnte Endpunkt-Netzwerkschicht-Fragmentierung nutzen oder den Datenblock durch einen PL in mehrere Datagramme segmentieren).

DPLPMTUD KANN wählen, nur eine dieser Methoden zu verwenden, um die Implementierung zu vereinfachen.

Identifikation von Sondierungspaketen

Sondierungsnachrichten, die vom PL gesendet werden, MÜSSEN genügend Informationen enthalten, um die Sondierung innerhalb der maximalen Segment-Lebensdauer eindeutig zu identifizieren (z.B. einschließlich einer eindeutigen Kennung vom PL oder von der DPLPMTUD-Implementierung) und robust gegen Neuordnung und Wiederholung von Sondierungsantworten und PTB-Nachrichten sein.

4.2. Bestätigung der sondier­ten Paketgröße

Der PL benötigt eine Methode, um zu bestimmen (bestätigen), wann ein Sondierungspaket erfolgreich Ende-zu-Ende über einen Netzwerkpfad empfangen wurde.

Transportprotokolle können Ende-zu-Ende-Methoden enthalten, die den Empfang bestimmter Datagramme erkennen und melden, die sie senden (z.B. bieten DCCP, SCTP und QUIC Keep-Alive-/Heartbeat-Funktionen). Wenn unterstützt, KANN dieser Mechanismus auch von DPLPMTUD verwendet werden, um den Empfang eines Sondierungspakets zu bestätigen.

PLs, die den Datenempfang nicht bestätigen (z.B. UDP und UDP-Lite), sind selbst nicht in der Lage zu erkennen, wann ein von ihnen gesendetes Paket verworfen wurde, weil seine Größe größer als die tatsächliche PMTU ist. Diese PLs müssen sich auf ein Anwendungsprotokoll verlassen, um diesen Verlust zu erkennen.

Abschnitt 6 spezifiziert diese Funktion für eine Reihe von IETF-spezifizierten Protokollen.

4.3. Black-Hole-Erkennung und Reduzierung der PLPMTU

Die folgende Beschreibung verwendet die in Abschnitt 5.1.2 definierten Konstanten und die in Abschnitt 5.1.3 definierten Variablen.

Die Black-Hole-Erkennung wird durch eine Anzeige ausgelöst, dass der Netzwerkpfad möglicherweise nicht in der Lage ist, die aktuelle PLPMTU-Größe zu unterstützen.

Drei Black-Hole-Erkennungsindikatoren

1. PTB-Nachrichten-Indikator

Eine validierte PTB-Nachricht kann empfangen werden, die eine PL_PTB_SIZE anzeigt, die kleiner als die aktuelle PLPMTU ist. Die DPLPMTUD-Methode DARF SICH NICHT ausschließlich auf diese Methode verlassen.

2. Periodische Sondierung

Der PL kann den DPLPMTUD-Sondierungsmechanismus verwenden, um periodisch Sondierungspakete der aktuellen PLPMTU-Größe zu erzeugen (z.B. unter Verwendung des CONFIRMATION_TIMER, Abschnitt 5.1.1). Ein Timer verfolgt, ob Bestätigungen empfangen werden. Aufeinanderfolgender Verlust von Sondierungen ist eine Anzeige dafür, dass der aktuelle Pfad die PLPMTU nicht mehr unterstützt (z.B. wenn die Anzahl der ohne Empfang einer Bestätigung gesendeten Sondierungspakete, PROBE_COUNT, größer als MAX_PROBES wird).

3. PL-Ereignis-Indikator

Der PL kann ein Ereignis nutzen, das anzeigt, dass der Netzwerkpfad die PLPMTU-Größe des Senders nicht mehr unterstützt. Dies kann unter Verwendung von im PL implementierten Mechanismen erkannt werden, um übermäßigen Verlust von Daten zu erkennen, die mit einer bestimmten Paketgröße gesendet wurden, und dann zu folgern, dass dieser übermäßige Verlust das Ergebnis einer ungültigen PLPMTU sein könnte (wie bei PLPMTUD für TCP [RFC4821]).

Unterschiede im Sondierungsmuster

Diese drei Methoden können zu unterschiedlichen Übertragungsmustern für als Sondierungen verwendete Pakete führen und werden voraussichtlich zu unterschiedlicher Reaktionsfähigkeit nach einer tatsächlichen PMTU-Änderung führen.

Sondierungs-Unterdrückung

KANN: Der PL das Senden von Sondierungspaketen unterdrücken, wenn eine Anwendung seit dem letzten Sondierungspaket keine Daten gesendet hat.

Ein PL, der das Senden von Benutzerdaten wieder aufnimmt, KANN die PLPMTU-Erkennung für jeden Pfad weiter verwenden. Dies ermöglicht die Verwendung der neuesten PLPMTU. Dies könnte jedoch dazu führen, dass zusätzliche Pakete gesendet werden.

PLPMTU-Reduzierung

Wenn die Methode erkennt, dass die aktuelle PLPMTU nicht unterstützt wird, setzt DPLPMTUD eine niedrigere PLPMTU und eine niedrigere MPS. Der PL bestätigt dann, dass die neue PLPMTU erfolgreich für den Pfad verwendet werden kann. Sondierungspakete müssen möglicherweise kleiner sein als die Größe der von der Anwendung erzeugten Datenblöcke.

4.4. Die maximale Paketgröße (MPS)

Das Ergebnis der Sondierung bestimmt die verfügbare PLPMTU, die verwendet wird, um die von der Anwendung verwendete MPS festzulegen. Die MPS ist kleiner als die PLPMTU, weil sie durch die Größe der PL-Header reduziert wird (einschließlich des Overheads für sicherheitsbezogene Felder wie AEAD-Tags und TLS-Record-Layer-Padding).

Beziehung zwischen MPS und PLPMTU

|<----- PLPMTU ----->|
|<-- MPS -->|  PL-Header  |  IP-Header  |
| App-Daten | Transport | Sicherheit | Netzwerk |

Der PL kann kein Paket (außer einem Sondierungspaket) mit einer Größe auf der Netzwerkschicht senden, die größer als die aktuelle PLPMTU ist. Um dies zu vermeiden, KANN ein PL so gestaltet sein, dass er Datenblöcke, die größer als die MPS sind, in mehrere Datagramme segmentiert.

DPLPMTUD versucht, IP-Fragmentierung zu vermeiden. Wenn der PL Daten nicht segmentieren kann, schlägt ein Versuch, einen Datenblock zu senden, der größer als die MPS ist, fehl. Um den größten Datenblock zu bestimmen, der gesendet werden kann, SOLLTE ein PL der Anwendung ein Primitiv bereitstellen, das die von der aktuellen PLPMTU abgeleitete MPS zurückgibt.

MPS-Änderungshandhabung

Wenn DPLPMTUD zu einer Änderung der MPS führt, müssen sich Anwendungen an die neue MPS anpassen. Ein besonderer Fall kann auftreten, wenn Pakete mit einer Größe kleiner als die MPS gesendet werden und die PLPMTU anschließend reduziert wird. Wenn diese Pakete verloren gehen, KANN der PL die Daten unter Verwendung der neuen MPS segmentieren.

Wenn der PL ein zuvor gesendetes Datagramm nicht neu segmentieren kann (z.B. [RFC4960]), verwirft der Sender entweder das Datagramm oder kann eine Neuübertragung unter Verwendung von Netzwerkschicht-Fragmentierung durchführen, um mehrere IP-Pakete zu bilden, die nicht größer als die PLPMTU sind. Für IPv4 verwendet der Sender Endpunkt-Fragmentierung anstelle des Löschens des DF-Bits im IPv4-Header. Betriebserfahrung zeigt, dass IP-Fragmentierung die Zuverlässigkeit der Internet-Kommunikation verringern kann [RFC8900], was die Wahrscheinlichkeit einer erfolgreichen Neuübertragung verringern könnte.

4.5. Deaktivierung der Wirkung von PMTUD

Ein PL, der diese Spezifikation implementiert, MUSS die Durchsetzung der PMTU [RFC1191] [RFC8201] für die Netzwerkschichtverarbeitung ausgehender Pakete für jeden Fluss aussetzen, der DPLPMTUD verwendet, und stattdessen DPLPMTUD verwenden, um die Größe der Pakete zu steuern, die der Fluss sendet. Dies eliminiert die Notwendigkeit für die Netzwerkschicht, gesendete Pakete mit einer Größe größer als die PMTU zu verwerfen oder zu fragmentieren.

4.6. Antwort auf PTB-Nachrichten

Diese Methode erfordert, dass der DPLPMTUD-Sender jede empfangene PTB-Nachricht validiert, bevor er die PTB-Informationen verwendet. Die Antwort auf eine PTB-Nachricht hängt von der aus dem PTB_SIZE in der PTB-Nachricht berechneten PL_PTB_SIZE, dem Zustand der PLPMTUD-Zustandsmaschine und dem verwendeten IP-Protokoll ab.

Abschnitt 4.6.1 beschreibt die Validierung sowohl von IPv4 ICMP Unreachable-Nachrichten (Typ 3) als auch von ICMPv6 Packet Too Big-Nachrichten, die beide in diesem Dokument als PTB-Nachrichten bezeichnet werden.

4.6.1. Validierung von PTB-Nachrichten

Dieser Abschnitt spezifiziert die Nutzung und Validierung von PTB-Nachrichten.

Implementierungsoptionen

• Einfache Implementierung: KANN empfangene PTB-Nachrichten ignorieren, in diesem Fall wird die PLPMTU nicht aktualisiert, wenn eine PTB-Nachricht empfangen wird.

• PL mit PTB-Unterstützung: MUSS diese Nachrichten vor der weiteren Verarbeitung validieren.

Validierungsprozess

Ein PL, der eine PTB-Nachricht von einem Router oder einer Middlebox empfängt, führt eine ICMP-Validierung durch (siehe Abschnitt 4 von [RFC8201] und Abschnitt 5.2 von [BCP145]). Da DPLPMTUD auf der PL arbeitet, muss der PL jede empfangene PTB-Nachricht überprüfen, um festzustellen, ob sie als Antwort auf ein Paket empfangen wurde, das vom Endpunkt-PL stammt, der DPLPMTUD durchführt.

Der PL MUSS die Protokollinformationen im zitierten Paket überprüfen, das in einer ICMP PTB-Nachrichtnutzlast transportiert wird, um zu validieren, dass die Nachricht vom sendenden Knoten stammt. Diese Validierung umfasst die Feststellung, dass die Kombination von IP-Adressen, Protokoll, Quellport und Zielport mit der im zitierten Paket zurückgegebenen Kombination übereinstimmt -- dies ist auch erforderlich, damit die PTB-Nachricht an den entsprechenden PL weitergeleitet wird.

Die Validierung SOLLTE Informationen nutzen, die einem Off-Path-Angreifer nicht ohne weiteres zur Verfügung stehen [BCP145]. Sie kann beispielsweise den Wert von Protokoll-Header-Feldern überprüfen, die nur den beiden PL-Endpunkten bekannt sind. Datagrammanwendungen, die bekannte Quell- und Zielports verwenden, sollten sich auch auf andere Informationen verlassen, um diese Validierung abzuschließen.

Diese Überprüfungen sollen Schutz vor Paketen bieten, die von einem Knoten stammen, der sich nicht auf dem Netzwerkpfad befindet. PTB-Nachrichten, die die Validierung nicht abgeschlossen haben, DÜRFEN NICHT weiter von der DPLPMTUD-Methode genutzt werden, wie im Abschnitt Sicherheitsüberlegungen (Abschnitt 8) diskutiert.

Abschnitt 4.6.2 beschreibt die Verarbeitung von PTB-Nachrichten.

4.6.2. Verwendung von PTB-Nachrichten

Eine validierte PTB-Nachricht KANN vom DPLPMTUD-Algorithmus genutzt werden, aber DARF NICHT direkt verwendet werden, um die PLPMTU festzulegen.

Bevor die in der PTB-Nachricht gemeldete Größe verwendet wird, muss sie zuerst in eine PL_PTB_SIZE umgewandelt werden. Die PL_PTB_SIZE ist kleiner als die PTB_SIZE, weil sie durch Header unterhalb des PL reduziert wird, einschließlich aller IP-Optionen oder -Erweiterungen, die dem PL-Paket hinzugefügt wurden.

Methoden, die diese PTB-Nachrichten nutzen, können die Geschwindigkeit verbessern, mit der der Algorithmus eine geeignete PLPMTU erkennt, indem sie eine sofortige Sondierung für eine PL_PTB_SIZE auslösen (was zu einer Netzwerkschicht-Paketgröße von PTB_SIZE führt), verglichen mit Methoden, die sich ausschließlich auf einen timerbasierten Suchalgorithmus verlassen.

Eine Reihe von Überprüfungen soll Schutz vor einem Router bieten, der eine unerwartete PTB_SIZE meldet. Der PL muss auch überprüfen, dass die angegebene PL_PTB_SIZE kleiner als die von einem Sondierungspaket verwendete Größe und mindestens die minimal akzeptierte Größe ist.

Zusammenfassung der PTB-Nachrichten-Verarbeitung

Dieser Abschnitt bietet eine Zusammenfassung, wie PTB-Nachrichten genutzt werden, unter Verwendung der in Abschnitt 5.1.2 definierten Konstantenmenge. Diese Verarbeitung hängt von der PL_PTB_SIZE und den aktuellen Werten einer Variablenmenge ab:

PL_PTB_SIZE < MIN_PLPMTU

• Ungültige PL_PTB_SIZE, siehe Abschnitt 4.6.1
• Die PTB-Nachricht sollte ohne weitere Verarbeitung verworfen werden (d.h. PLPMTU wird nicht geändert)
• Diese Informationen könnten als Eingabe genutzt werden, um die Aktivierung eines Resilienzmodus auszulösen (siehe Abschnitt 5.3.3)

MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU

• Ein robuster PL KANN in den Fehlerzustand eintreten (siehe Abschnitt 5.2) für einen IPv4-Pfad, wenn die in der PTB-Nachricht gemeldete PL_PTB_SIZE größer oder gleich 68 Bytes [RFC0791] und kleiner als BASE_PLPMTU ist
• Ein robuster PL KANN in den Fehlerzustand eintreten (siehe Abschnitt 5.2) für einen IPv6-Pfad, wenn die in der PTB-Nachricht gemeldete PL_PTB_SIZE größer oder gleich 1280 Bytes [RFC8200] und kleiner als BASE_PLPMTU ist

BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU

• Dies könnte eine Anzeige für ein schwarzes Loch sein. Die PLPMTU SOLLTE auf BASE_PLPMTU gesetzt werden (PLPMTU wird auf BASE_PLPMTU reduziert, um unnötigen Paketverlust bei Auftreten eines schwarzen Lochs zu vermeiden)
• Der PL sollte eine Suche starten, um schnell die neue PLPMTU zu entdecken. Die in der PTB-Nachricht gemeldete PL_PTB_SIZE kann verwendet werden, um den Suchalgorithmus zu initialisieren

PLPMTU < PL_PTB_SIZE < PROBED_SIZE

• Die PLPMTU bleibt gültig, aber die für eine Suche verwendete Größe (PROBED_SIZE) ist größer als die tatsächliche PMTU
• Die PLPMTU wird nicht aktualisiert
• Wenn der Suchalgorithmus fortgesetzt wird, kann der PL die in der PTB-Nachricht gemeldete PL_PTB_SIZE als nächsten Suchpunkt verwenden

PL_PTB_SIZE >= PROBED_SIZE

• Inkonsistentes Netzwerksignal
• Die PTB-Nachricht sollte ohne weitere Verarbeitung verworfen werden (d.h. PLPMTU wird nicht geändert)
• Diese Informationen könnten als Eingabe genutzt werden, die die Aktivierung eines Resilienzmodus auslöst

Diese Mechanismen stellen zusammen sicher, dass DPLPMTUD zuverlässig eine geeignete Pfad-MTU ermitteln und aufrechterhalten kann.