1. Einführung

Die IETF hat Datagram-Transport unter Verwendung von UDP, Stream Control Transmission Protocol (SCTP) und Datagram Congestion Control Protocol (DCCP) spezifiziert, sowie Protokolle, die über diesen Transporten geschichtet sind (z.B. SCTP/UDP, DCCP/UDP, QUIC/UDP) und direkten Datagram-Transport über die IP-Netzwerkschicht. Dieses Dokument beschreibt eine robuste Methode zur Pfad-MTU-Erkennung (Path MTU Discovery, PMTUD), die mit diesen Transportprotokollen (oder den Anwendungen, die ihren Transportdienst nutzen) verwendet werden kann, um eine geeignete Paketgröße für die Verwendung über einen Internetpfad zu ermitteln.

1.1. Klassische Pfad-MTU-Erkennung (Classical Path MTU Discovery)

Die klassische Pfad-Maximum-Transmission-Unit-Erkennung (Classical Path Maximum Transmission Unit Discovery, PMTUD) kann mit jedem Transport verwendet werden, der ICMP Packet Too Big (PTB)-Nachrichten verarbeiten kann (z.B. [RFC1191] und [RFC8201]). In diesem Dokument wird der Begriff PTB-Nachricht sowohl auf IPv4-ICMP-Unreachable-Nachrichten (Typ 3) angewendet, die den Fehler Fragmentation Needed (Typ 3, Code 4) [RFC0792] übertragen, als auch auf ICMPv6-Packet-Too-Big-Nachrichten (Typ 2) [RFC4443]. Wenn ein Sender eine PTB-Nachricht empfängt, reduziert er die effektive MTU auf den Wert, der als Link-MTU in der PTB-Nachricht gemeldet wird. Klassisches PMTUD spezifiziert eine Methode zur periodischen Erhöhung der Paketgröße, um zu versuchen, eine Erhöhung der unterstützten PMTU zu ermitteln. Die mit einer Größe, die größer als die aktuelle effektive PMTU ist, gesendeten Pakete werden als Sondierungspakete bezeichnet.

Pakete, die nicht als Sondierungspakete gedacht sind, werden entweder auf die aktuelle effektive PMTU fragmentiert, oder der Sendeversuch schlägt mit einem Fehlercode fehl. Anwendungen kann ein Primitiv bereitgestellt werden, mit dem sie die maximale Paketgröße (Maximum Packet Size, MPS) lesen können, die von der aktuellen effektiven PMTU abgeleitet wird.

Klassisches PMTUD unterliegt Protokollfehlern. Ein Fehler tritt auf, wenn Verkehr mit einer Paketgröße, die größer als die tatsächliche PMTU ist, in ein schwarzes Loch fällt (alle Datagramme, die größer als die tatsächliche PMTU sind, werden verworfen). Dies kann auftreten, wenn die PTB-Nachrichten aus irgendeinem Grund nicht an den Sender zurückgesendet werden (siehe z.B. [RFC2923]).

Beispiele, bei denen PTB-Nachrichten nicht zugestellt werden, umfassen Folgendes:

• Die Generierung von ICMP-Nachrichten ist normalerweise ratenbegrenzt. Dies könnte dazu führen, dass keine PTB-Nachrichten an den Sender generiert werden (siehe [RFC4443] Abschnitt 2.4).

• ICMP-Nachrichten können von Middleboxes, einschließlich Firewalls [RFC4890], gefiltert werden. Eine Firewall könnte mit einer Richtlinie konfiguriert sein, die eingehende ICMP-Nachrichten blockiert, was den Empfang von PTB-Nachrichten durch einen sendenden Endpunkt hinter dieser Firewall verhindern würde.

• Wenn der Router, der die ICMP-Nachricht ausgibt, ein getunneltes Paket verwirft, wird die resultierende ICMP-Nachricht an den Tunneleingang geleitet. Dieser Tunnelendpunkt ist dafür verantwortlich, die ICMP-Nachricht weiterzuleiten, das zitierte Paket im Nutzlastfeld zu verarbeiten, um die Wirkung des Tunnels zu beseitigen, und eine korrekt formatierte ICMP-Nachricht an den Sender zurückzugeben [TUNNELS]. Das Unterlassen dessen verhindert, dass die PTB-Nachricht den ursprünglichen Sender erreicht.

• Asymmetrie bei der Weiterleitung kann dazu führen, dass keine Rückroute zum ursprünglichen Sender vorhanden ist, was verhindern würde, dass eine ICMP-Nachricht an den Sender zugestellt wird. Dieses Problem kann auch auftreten, wenn entweder richtlinienbasiertes oder gleichwertiges Multipath-Routing (Equal-Cost Multipath, ECMP) verwendet wird oder wenn eine Middlebox als Anwendungslastausgleich fungiert. Ein Beispiel dafür ist ein ECMP-Router, der einen Pfad zum Server basierend auf den Bytes in der IP-Nutzlast auswählt. In diesem Fall muss der ECMP-Router, wenn ein vom Server gesendetes Paket nach dem ECMP-Router auf ein Problem stößt, jede resultierende ICMP-Nachricht zum ursprünglichen Sender leiten.

• Es gibt zusätzliche Fälle, in denen das Ziel des nächsten Hops ein Paket aufgrund seiner Größe nicht empfangen kann. Dies könnte auf eine Fehlkonfiguration des Layer-2-Pfads zwischen Knoten zurückzuführen sein, beispielsweise die in einem Layer-2-Switch konfigurierte MTU oder eine Fehlkonfiguration der maximalen Empfangseinheit (Maximum Receive Unit, MRU). Wenn ein Paket durch den Link verworfen wird, führt dies nicht dazu, dass eine PTB-Nachricht an den ursprünglichen Sender gesendet wird.

Ein anderer Fehler könnte auftreten, wenn ein Knoten, der sich nicht auf dem Netzwerkpfad befindet, eine PTB-Nachricht sendet, die versucht, einen Sender zu zwingen, die effektive PMTU zu ändern [RFC8201]. Ein Sender kann sich vor der Reaktion auf solche Nachrichten schützen, indem er das zitierte Paket innerhalb einer PTB-Nachrichtennutzlast verwendet, um zu validieren, dass die empfangene PTB-Nachricht als Antwort auf ein Paket generiert wurde, das tatsächlich vom Sender stammte. Es gibt jedoch Situationen, in denen ein Sender diese Validierung nicht bereitstellen könnte.

Beispiele, bei denen die Validierung der PTB-Nachricht nicht möglich ist, umfassen Folgendes:

• Wenn ein Router, der die ICMP-Nachricht ausgibt, RFC 792 [RFC0792] implementiert, ist es nur erforderlich, die ersten 64 Bits der IP-Nutzlast des Pakets in der zitierten Nutzlast einzuschließen. Es könnten unzureichende Bytes verbleiben, damit der Sender die zitierten Transportinformationen interpretieren kann.

  Hinweis: Die Empfehlung in RFC 1812 [RFC1812] ist, dass IPv4-Router ein zitiertes Paket mit so viel vom ursprünglichen Datagramm wie möglich zurückgeben, ohne dass die Länge des ICMP-Datagramms 576 Bytes überschreitet. IPv6-Router schließen so viel vom aufrufenden Paket wie möglich ein, ohne dass das ICMPv6-Paket 1280 Bytes überschreitet [RFC4443].

• Die Verwendung von Tunneln und/oder Verschlüsselung kann die Größe des zitierten Pakets, das an die ursprüngliche Quelladresse zurückgegeben wird, verringern und das Risiko erhöhen, dass unzureichende Bytes verbleiben, damit der Sender die zitierten Transportinformationen interpretieren kann.

• Selbst wenn die PTB-Nachricht ausreichend Bytes des zitierten Pakets enthält, könnte der Netzwerkschicht ausreichender Kontext fehlen, um die Nachricht zu validieren, da die Validierung von Informationen über die aktiven Transportflüsse an einem Endpunktknoten abhängt (z.B. die verwendeten Socket-/Adresspaare und andere Protokoll-Header-Informationen).

• Wenn ein Paket über einen verschlüsselten Transport gekapselt/getunnelt wird, könnte der Tunnel-/Kapselungseingang unzureichenden Kontext oder Rechenleistung haben, um den Transport-Header zu rekonstruieren, der für die Durchführung der Validierung erforderlich wäre.

• Wenn eine ICMP-Nachricht von einem Router in einem Netzwerksegment generiert wird, das einen Header in ein Paket eingefügt hat, könnte das zitierte Paket zusätzliche Protokoll-Header-Informationen enthalten, die nicht im ursprünglich gesendeten Paket enthalten waren und die der PL-Sender nicht verarbeitet oder möglicherweise nicht weiß, wie man verarbeitet. Dies könnte die Fähigkeit des Senders beeinträchtigen, diese PTB-Nachricht zu validieren.

• Ein Netzwerkadressenübersetzungsgerät (Network Address Translation, NAT), das einen Paket-Header übersetzt, sollte auch ICMP-Nachrichten übersetzen und das ICMP-zitierte Paket [RFC5508] in dieser Nachricht aktualisieren. Wenn dies nicht korrekt übersetzt wird, wäre der Sender nicht in der Lage, die Nachricht mit dem PL zu verknüpfen, der das Paket ausgelöst hat, und daher kann diese ICMP-Nachricht nicht validiert werden.

1.2. Paketisierungsschicht-Pfad-MTU-Erkennung (Packetization Layer Path MTU Discovery)

Der Begriff Paketisierungsschicht (Packetization Layer, PL) wurde eingeführt, um die Schicht zu beschreiben, die dafür verantwortlich ist, Datenblöcke in die Nutzlast von IP-Paketen zu platzieren und eine geeignete MPS auszuwählen. Diese Funktion wird häufig von einem Transportprotokoll (z.B. DCCP, RTP, SCTP, QUIC) durchgeführt, kann aber auch von anderen Kapselungsmethoden durchgeführt werden, die über der Transportschicht arbeiten.

Im Gegensatz zu PMTUD führt die Paketisierungsschicht-Pfad-MTU-Erkennung (Packetization Layer Path MTU Discovery, PLPMTUD) [RFC4821] eine Methode ein, die nicht auf dem Empfang und der Validierung von PTB-Nachrichten beruht. Sie ist daher robuster als klassisches PMTUD. Dies ist zum empfohlenen Ansatz für die Implementierung der Erkennung der PMTU geworden [BCP145].

Dieses Dokument aktualisiert [RFC4821], um die PLPMTUD-Methode für Datagram-PLs zu spezifizieren, und aktualisiert auch [BCP145], um auf die in diesem Dokument spezifizierte Methode für die Verwendung mit UDP-Datagrammen anstelle der Methode in [RFC4821] zu verweisen.

Es verwendet eine allgemeine Strategie, bei der die PL Sondierungspakete sendet, um nach der größten Größe eines unfragmentierten Datagramms zu suchen, das über einen Netzwerkpfad gesendet werden kann. Sondierungspakete werden gesendet, um mit einer größeren Paketgröße zu erforschen. Wenn ein Sondierungspaket erfolgreich zugestellt wird (wie vom PL bestimmt), wird die PLPMTU auf die Größe der erfolgreichen Sondierung erhöht. Wenn ein schwarzes Loch erkannt wird (z.B. wo Pakete der Größe PLPMTU konsistent nicht empfangen werden), reduziert die Methode die PLPMTU.

Datagram-PLPMTUD führt Flexibilität in der Implementierung ein. An einem Extrem kann es konfiguriert werden, um nur die Erkennung und Wiederherstellung schwarzer Löcher mit erhöhter Robustheit im Vergleich zu klassischem PMTUD durchzuführen. Am anderen Extrem kann die gesamte PTB-Verarbeitung deaktiviert werden, und PLPMTUD ersetzt klassisches PMTUD.

PLPMTUD kann auch zusätzliche Konsistenzprüfungen einschließen, ohne das Risiko zu erhöhen, dass Daten verloren gehen, wenn zum Ermitteln des Pfad-MTU sondiert wird. Beispielsweise ermöglichen Informationen, die auf der PL oder höheren Schichten verfügbar sind, die Validierung empfangener PTB-Nachrichten, bevor sie verwendet werden.

1.3. Pfad-MTU-Erkennung für Datagram-Dienste (Path MTU Discovery for Datagram Services)

Abschnitt 5 dieses Dokuments präsentiert eine Reihe von Algorithmen für Datagram-Protokolle, um die größte Größe eines unfragmentierten Datagramms zu ermitteln, das über einen Netzwerkpfad gesendet werden kann. Die Methode beruht auf den in Abschnitt 3 beschriebenen Funktionen des PL und gilt für Transportprotokolle, die über IPv4 und IPv6 arbeiten. Sie erfordert keine Zusammenarbeit von den unteren Schichten, obwohl sie PTB-Nachrichten verwenden kann, wenn diese empfangenen Nachrichten dem PL zur Verfügung gestellt werden.

Die Richtlinien zur Nachrichtengröße in Abschnitt 3.2 der UDP-Nutzungsrichtlinien [BCP145] besagen, dass «eine Anwendung entweder die vom der IP-Schicht bereitgestellten Pfad-MTU-Informationen verwenden oder Pfad-MTU-Erkennung (PMTUD) implementieren SOLLTE», bieten jedoch keinen Mechanismus zur Ermittlung der größten Größe eines unfragmentierten Datagramms, das auf einem Netzwerkpfad verwendet werden kann. Das vorliegende Dokument aktualisiert RFC 8085, um diese Methode anstelle von PLPMTUD [RFC4821] zu spezifizieren, und bietet einen Mechanismus zum Teilen der ermittelten größten Größe als MPS (siehe Abschnitt 4.4).

[RFC4821] Abschnitt 10.2 empfahl eine PLPMTUD-Sondierungsmethode für das Stream Control Transport Protocol (SCTP). SCTP verwendet Sondierungspakete, die aus einem minimal großen HEARTBEAT-Chunk bestehen, der mit einem PAD-Chunk gebündelt ist, wie in [RFC4820] definiert. RFC 4821 lieferte jedoch keine vollständige Spezifikation. Das vorliegende Dokument ersetzt diese Beschreibung durch Bereitstellung einer vollständigen Spezifikation.

Das Datagram Congestion Control Protocol (DCCP) [RFC4340] verlangt von Implementierungen, klassisches PMTUD zu unterstützen, und besagt, dass ein DCCP-Sender «die für jede aktive DCCP-Sitzung erlaubte MPS aufrechterhalten MUSS». Es definiert auch die aktuelle Staukontroll-MPS (Current Congestion Control MPS, CCMPS), die von einem Netzwerkpfad unterstützt wird. Dies empfiehlt die Verwendung von PMTUD und schlägt die Verwendung von Steuerpaketen (DCCP-Sync) als Pfad-Sondierungspakete vor, da sie keinen Verlust von Anwendungsdaten riskieren. Die in dieser Spezifikation definierte Methode kann mit DCCP verwendet werden.

Abschnitt 4 und Abschnitt 5 definieren die Protokollmechanismen und Spezifikation für die Datagram-Paketisierungsschicht-Pfad-MTU-Erkennung (Datagram Packetization Layer Path MTU Discovery, DPLPMTUD).

Abschnitt 6 spezifiziert die Methode für Datagram-Transporte und stellt Informationen bereit, um die Implementierung von PLPMTUD mit anderen Datagram-Transporten und Anwendungen zu ermöglichen, die Datagram-Transporte verwenden.

Abschnitt 6 bietet auch Empfehlungen für SCTP-Endpunkte und aktualisiert [RFC4960], [RFC6951] und [RFC8261], um die in diesem Dokument spezifizierte Methode anstelle der Methode in [RFC4821] zu verwenden.