Zusammenfassung

  • Im frühen IPv4 durfte ein Gateway ein zu großes Datagramm für den nächsten Link zerlegen; das Ziel setzte die Teile zusammen. Damit verschwand Heterogenität aus der Sicht des Senders, doch ein verlorenes Fragment gefährdete das Ganze.
  • Klassisches PMTUD setzte DF und ließ den beschränkenden Router per ICMP antworten. Verschwand diese Rückmeldung, konnten kleine Pakete passieren, während große Pakete in einem Black Hole endeten.
  • PLPMTUD lässt die paketbildende Schicht mit bestätigbaren Größen experimentieren. Der Pfad liefert begrenzte Evidenz; der Sender behält Zustand, Prüfung und eine revidierbare Entscheidung.

Zu groß für das nächste Netz

Das Internet verband Netze mit unterschiedlichen maximalen Paketgrößen. RFC 791 vom September 1981 nannte Adressierung und Fragmentierung die zwei Grundfunktionen von IP. Traf ein Datagramm später auf ein Netz mit kleinerer Grenze, konnte ein Gateway es teilen.

Identification, Fragment Offset und More Fragments ermöglichten dem Ziel die Rekonstruktion. Die oberen Schichten mussten den Unterschied nicht kennen. Der Preis blieb dennoch real: mehr Pakete am Engpass, Arbeit im Router, Reassembly-Zustand am Ziel und ein unvollständiges Datagramm, wenn nur ein Teil fehlte.

Mit Don't Fragment besaß IPv4 bereits eine Alternative. Ein zu großes DF-Paket musste verworfen werden. Damit konnte der Sender die Zwischenfragmentierung vermeiden, aber nur eine brauchbare Rückmeldung verwandelte den Verlust in eine Größenanpassung.

Die Path MTU ist das Minimum der Link-MTUs auf dem aktuellen Weg. Sie ist keine dauerhafte Eigenschaft des Ziels. Routingwechsel, Tunnel-Header und andere ECMP-Zweige können den verfügbaren Raum verändern.

Die Option, die jedes Gateway ändern sollte

RFC 1063 schlug im Juli 1988 vor, den Pfad sein Minimum eintragen zu lassen. Probe MTU startete mit dem Wert des ersten Links. Jedes Gateway verglich Ein- und Ausgang und verringerte den Wert. Reply MTU brachte ihn zurück.

Der Entwurf erfasste den Zielkonflikt: kleine Pakete verschwenden Kapazität und Header, große Annahmen erzeugen Fragmentierung, zusätzliche Probes belasten das Netz und veralten mit der Route. Auch TCP MSS und PMTU wurden getrennt. MSS beschreibt die vom Peer akzeptierte TCP-Nutzlast; PMTU die vom IP-Pfad tragbare Paketgröße.

Die Genauigkeit verlangte jedoch Kooperation auf dem gesamten Weg. RFC 1063 räumte ein, dass manche Gateways beim Verarbeiten der Option die nötigen Interfaces noch nicht kannten und erhebliche Softwareänderungen brauchen könnten.

Nur der ablehnende Link antwortet

RFC 1191 vom November 1990 reduzierte die Mitwirkung. Die Quelle beginnt mit der MTU des ersten Hops und setzt DF. Kann ein Router das Paket nicht intakt weiterleiten, verwirft er es und sendet ICMP Destination Unreachable mit „Fragmentation Needed and DF Set“. Die Quelle senkt ihre Schätzung.

Ein zuvor ungenutztes ICMP-Feld meldete nun die MTU des nächsten Hops, der den Fehler verursachte. Router änderten nicht mehr jedes Paket, sondern sprachen nur beim Scheitern. Weiter gesetztes DF entdeckte einen später enger gewordenen Pfad.

Alte Router lieferten in dem Feld null. Dann suchte der Host abwärts über plausible MTU-„Plateaus“. Wenige Prozent zu niedrig waren besser als ein Byte zu hoch. Die Tabelle blieb Implementierungshinweis ihrer Zeit, kein ewiges Register.

Auch breitere Wege müssen wiederentdeckt werden. Der Cache altert, und größere Pakete werden in begrenzten Abständen erprobt. Eine Fehlermeldung darf die Schätzung senken, aber nicht allein erhöhen. Für den Anstieg braucht es beobachtete Zustellung.

Erreichbar für den Handshake, unbrauchbar für Daten

Klassisches PMTUD setzt voraus, dass ICMP zurückkehrt. RFC 2923 katalogisierte 2000 das Black Hole, das entsteht, wenn Router die Nachricht nicht erzeugen oder Firewalls ICMP pauschal blockieren. Der Sender wiederholt ein zu großes DF-Paket, ohne kleiner zu werden.

Die Störung tarnt sich. Der TCP-Handshake besteht aus kleinen Paketen und gelingt. Ping oder interaktive Befehle funktionieren. Erst das große Segment der Datenübertragung verschwindet und wird in gleicher Größe erneut gesendet, bis die Verbindung ausläuft. Erreichbarkeit und Nutzbarkeit fallen nach Paketgröße auseinander.

Ein kleiner Fallback stellt Dienst her, kann aber die defekte Rückmeldung verbergen und Effizienz dauerhaft kosten. Nicht nur Firewalls sind verantwortlich: Tunnel, asymmetrische Wege, ICMP-Ratenbegrenzung und Layer-2-Fehlkonfiguration können ebenfalls den Beweiskanal brechen.

RFC 8201, die aktuelle IPv6-PMTUD-Spezifikation, beschreibt denselben erfolgreichen Handshake mit anschließendem Stillstand, wenn Packet Too Big fehlt. IPv6-Router fragmentieren Transitpakete nicht; die Quelle wählt die Größe und erzeugt nötigenfalls Fragmente.

Zustellung als Experiment

RFC 4821 verlagerte 2007 die Beweisführung. Packetization Layer PMTUD beginnt bei einer funktionierenden Größe und sendet zunehmend größere Probes. Bestätigte Zustellung hebt die Untergrenze; der schlüssige Verlust einer isolierten Probe senkt die Obergrenze.

Die paketbildende Schicht — typischerweise TCP — kennt die Bestätigung einer bestimmten Probe. Normale Daten können auf sicherer Größe bleiben. Doch ein Timeout oder zusätzliche Verluste machen das Ergebnis mehrdeutig; normale Staukontrolle gilt weiter. Ein verlorenes Paket beweist keine MTU-Grenze.

Auch Erfolg ist begrenzt. Eine Probe zeigt die Passage dieses Pakets zu diesem Zeitpunkt, nicht alle künftigen Routen oder jeden Multipath-Zweig. Deshalb benötigt die Suche Intervalle, Wiederholung, Timer und alternden Pfadzustand.

PLPMTUD kann ICMP nutzen, muss aber nicht darauf warten. Routerwissen bleibt wertvoll; ein fehlender Rückkanal verliert nur sein absolutes Vetorecht. Dafür übernimmt der Endpunkt Bestätigung, Suche, Header-Berechnung und Abstimmung mit der Staukontrolle.

Datagramme brauchen eigene Rückmeldung

IPv6 beseitigt die Entdeckung nicht. Wer beim IPv6-Minimum bleibt, verschenkt breitere Pfade. Wer größer sendet, braucht Robustheit gegen fehlendes PTB.

RFC 8899 definierte 2020 DPLPMTUD für Datagrammtransporte und Anwendungen, darunter UDP-basierte Protokolle, SCTP und QUIC. Fehlt dem Transport eine Bestätigung, muss die Anwendung die Ankunft einer Probe erkennbar machen.

Normale Daten bleiben unter der wirksamen Größe; eine gekennzeichnete Probe darf größer sein. Erkanntes Black Hole senkt den Wert, bestätigte Probes erlauben die Suche nach oben. Validiertes PTB kann beschleunigen, ist aber optional und muss zu tatsächlich gesendetem Verkehr gehören.

Die Geschichte war keine einmalige Vertreibung des Netzkerns. Fragmentierung versteckte Vielfalt und verstärkte Verlustkosten. Die 1988er Option sammelte präzises lokales Wissen und verlangte alle Geräte. ICMP meldete nur Fehler, hing aber am Rückweg. Endpunkt-Probes ergänzten reale Zustellung und begrenzten diese Abhängigkeit.

Größe als verfallende Entscheidung

MTU wird oft als 1500 oder 1280 erinnert. Wichtiger ist die Kontrollfläche: Betreiber setzen lokale Grenzen, Router erzwingen und melden sie, Firewalls können Meldungen löschen, Hosts speichern Pfadzustand, Transporte formen Pakete. Niemand besitzt den gesamten Weg.

Die gemeinsame Regel bleibt schmal: Einschränkungen möglichst offenlegen, den Sender Nachricht, Zustellung und Stau zusammenführen lassen und das Ergebnis verfallen lassen. Nicht das Paket wurde klug; die Architektur legte die Entscheidung dorthin, wo Beleg und Folge zusammen sichtbar sind.

Quellen und Evidenzgrenzen

RFC 791 dokumentiert IPv4-Fragmentierung und DF; RFC 1063 die Gateway-Optionen; RFC 1191 klassisches PMTUD, Next-Hop-MTU, Plateaus und Alterung. RFC 2923 beschreibt TCP-Black-Holes. RFC 4821 liefert Packetization-Layer-Probes, RFC 8201 IPv6 und RFC 8899 Datagramme.

Die Dokumente belegen Spezifikationen und bekannte Fehlerbilder, aber keine weltweite Einführung zu einem Datum, keine aktuelle Häufigkeit und keine Konfiguration jedes Netzes.