Zusammenfassung

  • Eine positive Bestätigung belegt, dass die identifizierte Sonde in dieser Größe über den beobachteten Pfad die entfernte Paketisierungsschicht erreichte.
  • RFC 8201 behandelt die Pfad-MTU als veränderlichen Zustand; RFC 8899 verlangt erneute Bestätigung und bei Multipath oder Multihoming einen Zustand je Pfad.
  • Ein belastbarer Beleg verbindet Endpunkte, Flow- oder Pfadidentität, Kapselungsaufwand, Sonde, Rückmeldung, Zeit und repräsentative Nutzdatenzustellung.

Eine richtige Messung mit zu großer Reichweite

Ein Datagrammdienst sendet eine auf 1.450 Byte aufgefüllte Sonde. Der Empfänger bestätigt genau diese Sonde, und der Sender erhöht seine PLPMTU. Kurz darauf wird ein Anwendungsdatagramm gleicher Größe einem anderen ECMP-Mitglied zugeordnet. Dort verbraucht ein Tunnel mehr Headerraum oder ein Link hat eine kleinere wirksame MTU; das Paket kommt nicht an.

Die erste Beobachtung bleibt wahr. Sie beschreibt ein bestimmtes Paket auf dem damals genommenen Pfad. Sie vermisst weder alle parallelen Mitglieder noch eine spätere Route. Ein einzelnes „MTU OK“ verwirft Sonden-ID, Flow-Schlüssel, Routengeneration, Overhead und Alter der Bestätigung.

IPv6-PMTUD verwaltet eine Schätzung

RFC 8201 definiert die Pfad-MTU als kleinste Link-MTU auf dem Pfad zwischen Quelle und Ziel. Die Quelle kann mit der MTU des ersten Hops beginnen und ihre Schätzung nach einer validierten ICMPv6-Packet-Too-Big-Nachricht senken. Mehrere Runden können nötig sein, wenn weiter hinten ein noch kleinerer Link liegt.

Topologieänderungen können die PMTU verändern. Verringerungen werden über PTB erkannt; Vergrößerungen erfordern regelmäßige Versuche mit größeren Paketen. Nach einer Verringerung empfiehlt RFC 8201, einen Erhöhungsversuch höchstens einmal in fünf Minuten zu unternehmen. Der Cachewert besitzt damit Alterung und Erneuerungsregeln und ist keine ewige Zieleigenschaft.

Auch eine validierte PTB-Nachricht belegt nur eine Einschränkung für den zugeordneten Versand. Sie erklärt nicht allein, welche Route wechselte, welcher Tunnel Bytes hinzufügte oder ob alle parallelen Pfade dieselbe Obergrenze besitzen.

Was DPLPMTUD wirklich bestätigt

RFC 8899 verlagert die Ermittlung in die Paketisierungsschicht. Der Sender wählt eine Sondengröße und benötigt eine Rückmeldung, dass genau diese Sonde am entfernten Endpunkt einging. Nach der Bestätigung kann die getestete Größe zur aktuellen PLPMTU werden.

Das ist stärker als Erfolg aus Schweigen abzuleiten, bleibt aber eng begrenzt. Ein einzelner Verlust beweist kein MTU-Problem; Stau, Fehler und Umordnung sind ebenfalls möglich. Eine Bestätigung macht Search Complete nicht zur Dauergarantie. Fehlen andere Zustellungsbelege, prüft ein Bestätigungstimer die aktuelle Größe erneut.

Das Verfahren muss Pfadwechsel, widersprüchliche Informationen, Verzögerung, Duplikate, Umordnung und Verkehr über mehrere Pfade verkraften. Bei Multipath oder Multihoming verlangt RFC 8899 eine Zustandsmaschine je Pfad. Ein grünes Zielkennzeichen reicht deshalb nicht.

Header gehören zum Größenbudget

PLPMTU und Anwendungsnutzlast sind verschiedene Größen. IP-, Erweiterungs-, Transport-, Sicherheits- und Tunnelheader verbrauchen Raum. Neue Kapselung kann die sichere Nachrichtengröße senken, obwohl die physische Link-MTU unverändert bleibt.

Der Datensatz muss also Messschicht und Headerbudget nennen. Wiederholter größenabhängiger Verlust rechtfertigt eine vorsichtige Absenkung, aber keine alleinige Ursachenzuweisung. Filter, Stau, Empfängerzustand und gewöhnlicher Verlust bleiben zu prüfen.

Quellen