9. Application Probing (Anwendungssondierung)

Alle Implementierungen MÜSSEN einen Mechanismus enthalten, bei dem Anwendungen, die verbindungslose Protokolle verwenden, ihre eigenen Sondierungen senden können. Dies ist notwendig, um PLPMTUD in einem Anwendungsprotokoll zu implementieren, wie in Abschnitt 10.4 beschrieben, oder um Diagnosetools zur Fehlerbehebung bei Problemen mit PMTUD zu implementieren. Es MUSS einen Mechanismus geben, der es einer Anwendung ermöglicht, Datagramme zu senden, die größer als eff_pmtu sind, die Schätzung des Path MTU durch das Betriebssystem, ohne fragmentiert zu werden. Wenn dies IPv4-Pakete sind, MÜSSEN sie das DF-Bit gesetzt haben.

Zu diesem Zeitpunkt unterstützen die meisten Betriebssysteme zwei Modi zum Senden von Datagrammen: einen, der Pakete, die zu groß sind, stillschweigend fragmentiert, und einen anderen, der Pakete, die zu groß sind, ablehnt. Keiner dieser Modi ist geeignet, um PLPMTUD in einer Anwendung zu implementieren oder Probleme mit Path MTU Discovery zu diagnostizieren. Ein dritter Modus ist ERFORDERLICH, bei dem das Datagramm gesendet wird, auch wenn es größer als die aktuelle Schätzung des Path MTU ist.

Die Implementierung von PLPMTUD in einer Anwendung erfordert auch einen Mechanismus, bei dem die Anwendung das Betriebssystem über das Ergebnis der Sondierung informieren kann, wie in Abschnitt 7.6 beschrieben, oder direkt search_low, search_high und eff_pmtu aktualisieren kann, wie in Abschnitt 7.1 beschrieben.

Diagnoseanwendungen sind nützlich, um PMTUD-Probleme zu finden, wie solche, die möglicherweise durch einen defekten Router verursacht werden, der ICMP PTB-Nachrichten mit falschen Größeninformationen zurückgibt. Solche Probleme können am schnellsten mit einem Tool lokalisiert werden, das Sondierungen jeder angegebenen Größe senden und alle zurückgegebenen ICMP PTB-Nachrichten sammeln und anzeigen kann.