Zusammenfassung

  • REQ trägt ein vier Oktett langes Token, EOL füllt bis zur Prüfgröße auf, und ein passendes RES bestätigt den Empfang genau dieser Sonde beim UDP-Options-Empfänger.
  • Das Ergebnis gehört zu 5-Tupel, Pfad und Zeitpunkt. ECMP und Multihoming verlangen getrennten Zustand; periodische Validierung begrenzt das Alter der PLPMTU.
  • Eine verspätete Antwort kann durch Bündelung mit Rückverkehr, Ratenbegrenzung oder Verlust auf dem Rückweg entstehen. Schweigen beweist nicht allein eine zu kleine Vorwärtskapazität.

Eine Quittung für einen einzelnen Versuch

RFC 9869 überträgt DPLPMTUD auf UDP Options. Der Sender schreibt ein Token in REQ und baut mit EOL und Padding ein Datagramm der gewählten Prüfgröße. Die Sonde darf über der aktuellen PLPMTU-Schätzung, aber nicht über der Interface-MTU liegen; IP-Fragmentierung bleibt ausgeschlossen. Der Empfänger gibt das zuletzt empfangene Token in RES zurück.

Bei Übereinstimmung steht fest, dass diese Sonde die entfernte UDP-Options-Verarbeitung erreicht hat. Nicht belegt sind Zustellung oder Annahme durch die Anwendung, die maximale Größe des Rückwegs oder die Route des nächsten Pakets. Gleichbleibende Adressen und Ports erzwingen keinen gleichbleibenden Pfad.

Sonden zur Erhöhung der PLPMTU sollten deshalb keine Anwendungsdaten tragen. Der Verlust zu großer Kandidaten ist Teil der Suche. Eine Sonde ohne Nutzlast wird nicht an die obere Schicht geliefert. Datenpakete können eine genutzte Größe bestätigen oder validieren, sollen sie aber nicht explorativ erhöhen.

Token-Lebensdauer erhält die Zuordnung

Innerhalb eines 5-Tupels muss das Token während der Maximum Segment Lifetime eindeutig bleiben und darf in diesem Fenster nicht wiederverwendet werden. Ein zufälliger Start und unvorhersehbare Werte erschweren gefälschte Antworten abseits des Pfads. Gespeichert werden müssen dennoch Größe, Endpunkte, Pfad, Sende- und Antwortzeit, Versuch, Zustand und Softwareversion.

Beide Anwendungen müssen den Dienst ausdrücklich aktivieren; vorher darf der Empfänger kein RES senden. Wenn Transportdienst und höheres Protokoll gleichzeitig DPLPMTUD betreiben, müssen sie Tokens koordinieren oder trennen. Eine echte Antwort am falschen Zustandsautomaten ist falsch zugeordnete Evidenz.

Das Verfahren ist primär für Unicast ausgelegt und unterstützt kein Multicast. Eine leere Antwort kann den Ablauf beschleunigen, muss als reiner Antwortverkehr jedoch ratenbegrenzt werden.

Ein gemessener Pfad vertritt keinen anderen

Bei Multipath, ECMP oder Multihoming fordert RFC 9869 unabhängigen Zustand pro Pfad. Der begrenzende Link gehört zur tatsächlich durchlaufenen Route, nicht zum entfernten Namen. Wer den erfolgreichen Wert auf Alternativen kopiert, ersetzt Messung durch Annahme.

Auch Zeit entwertet den Zustand. Routing, Tunnel und Richtlinien können sich ändern, vorübergehende Beschränkungen verschwinden. Periodische Validierung verhindert, dass ein historischer Erfolg unbegrenzt neue Sendungen autorisiert oder ein vorübergehend kleiner Wert zur ewigen Obergrenze wird.

Schweigen kann auf dem Rückweg entstehen

Der Empfänger darf RES an ein ohnehin anstehendes Rückdatagramm anhängen. Treffen vorher mehrere Sonden ein, kann nur das neueste Token bestätigt werden; frühere, tatsächlich eingetroffene Sonden wirken dann verloren. Bei wenig Rückverkehr bleibt der Sender womöglich unter der realen Kapazität oder sogar bei der Mindest-PLPMTU.

Eine eigens erzeugte leere Antwort verkürzt die Wartezeit, unterliegt aber der Ratenbegrenzung. Ein Timeout kann daher Vorwärtsverlust, Antwortpolitik, Warteschlange, Begrenzung oder Rückwärtsverlust bedeuten. Die konservative Reaktion des Zustandsautomaten ist keine eindeutige Ursachenanalyse.

ICMP Packet Too Big darf optional genutzt werden. Dann ist der zitierte Protokollkontext zu prüfen; wenn möglich, sollte auch das zitierte REQ-Token übereinstimmen. Nicht prüfbare Nachrichten sind zu ignorieren. Unvorhersehbare Tokens erschweren Off-Path-Fälschung, verhindern aber keine Eingriffe auf dem Pfad.

Quellen