Zusammenfassung

  • RFC 1191 ließ die IPv4-Quelle Don't Fragment setzen und den begrenzenden Router per ICMP den next-hop MTU melden. Der Pfad beobachtete; der Endpunkt hielt die Schätzung und entschied über kleinere Pakete.
  • RFC 2923 dokumentierte das PMTUD Black Hole: Fehlte ICMP, konnten TCP-Handshake und kleine Pakete funktionieren, während größere Segmente verschwanden. MSS war kein vollständiges Maß des Pfades.
  • Bei Cloudflare wurden TCP und ICMP 2015 unterschiedlich über ECMP gehasht. Die Kontrollmeldung erreichte das Netz, aber nicht das Backend mit dem Verbindungszustand.
  • PLPMTUD und DPLPMTUD gaben Endpunkten eine Alternative durch Probes und Zustellbestätigung. Weniger ICMP-Abhängigkeit bedeutete mehr Verkehr, Zustand und Verantwortung für die Deutung von Verlust.

Eine Meldung ohne zugehörige Verbindung

Cloudflare hatte den internen Einsatz von Equal-Cost Multi-Path routing ausgeweitet. Für TCP bildete der Router einen Hash aus Quell- und Zieladresse sowie beiden Ports. Die Pakete einer Verbindung gelangten damit verlässlich zum selben Server.

Für ICMP galt laut Betreiberbericht ein anderer Schlüssel: Quell- und Zieladresse. Packet Too Big konnte auf einem anderen Backend landen, obwohl der TCP-Fluss korrekt verteilt blieb. Cloudflare erklärte, genau dies sei im eigenen Fall geschehen.

Der Bericht nennt nur einige Nutzer von IPv6-Tunneln. Daraus folgt weder eine weltweite Häufigkeit noch ein bezifferbarer Schaden. Belegt ist eine präzisere Fehlersituation: Kontrollbeweise können die Organisation erreichen und trotzdem den Zustand verfehlen, der sie verwertbar macht.

Vorübergehend senkte Cloudflare den IPv6 MTU auf 1280 und aktivierte für IPv4 das Probing aus RFC 4821. Dauerhafter sollte ein Daemon IPv4 fragmentation-needed und IPv6 Packet Too Big erfassen und an alle Backends im Ethernet broadcasten.

Das Repository setzte als Default ein Paket pro Sekunde je Quelle und zehn pro Sekunde je Interface. Die Verteilung des Beweises löste das Zuständigkeitsproblem, schuf aber eine neue Oberfläche für Validierung, Kapazität und Missbrauch. Das war eine lokale Architekturlösung, keine allgemeine Vorgabe.

Kleine Pakete waren sicherer, aber nicht kostenlos

RFC 1191 definierte 1990 den Path MTU als kleinsten MTU aller Hops zwischen Quelle und Ziel. Dieser Wert gehört zu einem geschätzten Pfad. Eine Routingänderung oder ein Tunnel kann ihn ändern, obwohl Adressen und Präfixe gleich bleiben.

Zuvor konnte ein Host das Minimum aus 576 Oktetten und dem MTU des ersten Hops wählen. Die Quelle unterstellte dem unbekannten Weg damit keine große Kapazität. Auf breiten Pfaden verschwendete sie jedoch mögliche Nutzlast; war ein späterer Hop kleiner, blieb IPv4-Fragmentierung nötig.

Fragmentierung verlagerte Anpassung in das Netz. Ein Router zerlegte das Datagramm, das Ziel setzte es wieder zusammen; der Verlust eines Fragments gefährdete das Ganze. Spätere Erfahrungen in RFC 8900 ergänzten Stateful Middleboxes, Filter, Tunnel und ungleiche Pfade als Störquellen.

1990 standen also mehrere kostenträchtige Wege offen: immer klein senden, Router fragmentieren lassen, eine explizite Pfadmeldung einführen oder Mischformen nutzen. RFC 1191 entschied sich für Feedback, um die reale Kapazität besser zu nutzen, ohne routinemäßige Routerfragmentierung.

Der Router meldete, der Endpunkt entschied

Im klassischen IPv4-PMTUD setzt die Quelle Don't Fragment. Kann ein Router das Datagramm auf dem nächsten Link nicht ungeteilt weiterleiten, verwirft er es und sendet ICMP Destination Unreachable mit dem Code fragmentation needed.

RFC 1191 verlangt den next-hop MTU in der Meldung. Der Host senkt seine Schätzung. Er kann kleinere Pakete senden oder DF abschalten; der Router gewinnt keine Befugnis über die Transportstrategie.

Diese Aufgabenteilung ist zugleich die Abhängigkeit. Der Router besitzt unmittelbares Wissen über ein Interface. Der Endpunkt besitzt Packetization und Korrekturalgorithmus. Die ICMP-Meldung verbindet zwei getrennte Kontrollflächen.

Ein größerer Wert durfte nie allein aus einer ICMP-Meldung folgen. Der Host musste später selbst testen. RFC 1191 empfahl nach einer Senkung mindestens fünf Minuten, vorzugsweise zehn, bis zum nächsten Aufwärtstest.

Diese Intervalle sind historische Empfehlungen, keine Messung heutiger Stacks. Sie markieren aber die Beweisgrenze: Routen wechseln, Meldungen können veraltet oder falsch sein, und eine lokale Beobachtung ist keine dauerhafte Erlaubnis.

IPv6 nahm Routern die Fragmentierung, nicht den Lernbedarf

Die heutige IPv6-Basis verlangt, dass jeder Link 1280 Oktette trägt oder unterhalb von IP selbst fragmentiert und wieder zusammensetzt. IPv6-Router fragmentieren weitergeleitete Pakete nicht. Nur die Quelle kann einen Fragment header hinzufügen.

RFC 8200 empfiehlt PMTUD nachdrücklich, um Größen über 1280 zu nutzen. Eine minimale Implementierung darf bei höchstens 1280 bleiben. Das ist ein legitimer Verzicht auf volle Entdeckung und zugleich ein Effizienzverlust auf größeren Pfaden.

Nach RFC 8201 sendet der begrenzende Router ICMPv6 Packet Too Big. Der Endpunkt muss prüfen, ob das zitierte Paket wirklich aus seinem Verkehr stammt. Eine gültige Meldung kann die Schätzung senken, jedoch nie unter das IPv6-Minimum 1280.

Zum Erhöhen darf PTB nicht verwendet werden. Nach einer Senkung kann die Quelle in Abständen von mindestens fünf, besser zehn Minuten aufwärts testen. Der Router berichtet den lokalen Fakt; der Endpunkt validiert Kontext und Dauer.

RFC 4890 zählt Packet Too Big zu den ICMPv6-Meldungen, die Firewalls nicht verwerfen dürfen, weil Kommunikation sonst verhindert oder schwer beeinträchtigt wird. Das ist klare Betriebsanleitung, aber kein Beleg universeller Umsetzung und keine pauschale Freigabe aller ICMP-Typen.

Das Black Hole beseitigte die Erklärung, nicht die Grenze

RFC 2923 beschrieb 2000 ein seit Langem bekanntes Problem. Router, Kerneldefekt, Konfiguration oder Firewall verhinderten den ICMP-Rückweg. Die Quelle sendete weiter Pakete, die der Pfad nicht tragen konnte.

TCP machte den Fehler teilweise sichtbar. Ein kleiner Handshake konnte gelingen, ebenso erste Daten. Kam ein größeres Segment, verschwand es; Retransmissions wiederholten dieselbe Größe. Im FTP-Beispiel funktionierte der kleine Steuerkanal, während der Massentransfer hängen blieb.

Dieses Muster ist ein Untersuchungsauslöser, kein Beweis. Congestion, Beschädigung oder asymmetrische Policies können ähnliche Verluste erzeugen. Erforderlich sind Paketgrößen, Adressfamilie, DF oder Fragment, Retransmissions und der Inhalt einer empfangenen ICMP-Zitation.

Auch TCP MSS ersetzt den Pfadwert nicht. Es beschreibt die größte TCP-Nutzlast, die der Empfänger annimmt. Es sieht nicht jeden Tunnel des Hinwegs und sagt nichts über die Gleichheit des Rückwegs.

RFC 2923 bevorzugte die Reparatur des ICMP Black Hole. Lokale Erkennung konnte nach Timeouts kleiner senden. Sie stellte einzelne Sessions wieder her, fügte aber Sekunden hinzu und verdeckte einen Pfaddefekt, der für andere Flows bestehen blieb.

Lokale Filterhoheit ist keine End-to-End-Zertifizierung

Ein Betreiber kann legitime Befugnis über die Firewall des eigenen Netzes haben. Die Quellen tragen keine Behauptung von Rechtswidrigkeit, Bosheit oder privater Motivation eines konkreten Akteurs.

Die überprüfbare Grenze liegt woanders. Das Verwerfen von Packet Too Big macht das ursprüngliche Paket nicht weiterleitbar. Es entfernt den Beweis, während die Einschränkung bleibt. Der Filter kann Anpassung faktisch verhindern, ohne das Wissen des Routers oder die Verantwortung des Endpunkts zu übernehmen.

Tunnel fügen Header hinzu, nachdem der Endpunkt seine Größe gewählt hat. ECMP und Anycast können Daten und Fehler verschiedenen Instanzen zuordnen. Ein MTU-Wert ohne Zeit, Richtung, Flow und Encapsulation ist keine dauerhafte Eigenschaft eines Adressblocks.

Für Nummernressourcenhalter ist das entscheidend. Ein RIR weist Adressen zu, zertifiziert jedoch nicht den End-to-End-MTU jeder Route. ASN, Präfix und Serviceadresse können unverändert bleiben, während eine Betriebsänderung nur große Pakete unzustellbar macht.

PLPMTUD machte aus Schweigen ein Experiment

RFC 4821 definierte 2007 Packetization Layer PMTUD. Die packetbildende Schicht sendet zunehmend größere Probes und lernt aus Lieferung oder Verlust. Sie kann fortfahren, wenn ICMP nicht ankommt.

Die neue Autonomie schafft keine Gewissheit. Verliert sich nur eine große Probe, kann das auf die Grenze deuten. Gehen gleichzeitig andere Pakete verloren, bleiben Congestion und weitere Ursachen möglich. Suchzustand, Timer und vorsichtiges Retesting sind nötig.

Die Charter der IETF PMTUD Working Group bezeichnete Schwächen des alten Mechanismus als chronisches Hindernis für neue Links und Tunnel. Der Ansatz sollte klein beginnen und ohne ICMP-Abhängigkeit nach oben sondieren. Die Charter belegt einen Arbeitsauftrag, keinen weltweiten Konsens oder Einsatz.

RFC 8899 übertrug das Prinzip auf Datagram Packetization Layers. DPLPMTUD testet Größen, erhöht den bestätigten Wert nach Zustellnachweis und senkt ihn bei Black-Hole-Erkennung. Ein validiertes PTB kann helfen, darf aber weder einzige Quelle noch Grundlage einer Erhöhung sein.

UDP liefert selbst kein Acknowledgement. Anwendung oder Packetization Layer müssen die Probe bestätigen. Mit der Entscheidungsmacht wandern Probeverkehr, Zustand und Verlustdeutung zum Endpunkt.

Die moderne Lösung ist Koexistenz

Die heutige TCP-Spezifikation empfiehlt PMTUD nachdrücklich und PLPMTUD ebenfalls. Kleine Fallback-Größen bleiben, während RFC 9293 vor Performancekosten warnt. Endpoint-Probing hat die Routersignale nicht ersetzt, sondern einen Ausgang aus deren Schweigen geschaffen.

Die aktuelle Linux-Dokumentation zeigt Wahlmöglichkeiten. tcp_mtu_probing=0 deaktiviert Probing; Modus 1 schaltet es nach Erkennung eines ICMP Black Hole ein; Modus 2 hält es ab einem base MSS aktiv. Das dokumentierte Intervall hat einen Default von zehn Minuten.

Das beweist eine Produktoberfläche, keine weltweite Konfiguration. Firewalls, Tunnel, Kernel, Transports und Anwendungen verschiedener Generationen bilden die installierte Lock-in-Basis.

RFC 8900 erklärte Fragmentierung deshalb nicht für abgeschafft. Es katalogisierte Fragilität und verlangte weniger Abhängigkeit in oberen Schichten. Übrig blieb eine Kombination aus explizitem Signal, Validierung, Probing und konservativem Fallback.