5.2. Storing PMTU Information (Speichern von PMTU-Informationen)
Idealerweise sollte ein PMTU-Wert mit einem spezifischen Pfad assoziiert werden, der von Paketen durchlaufen wird, die zwischen Quell- und Zielknoten ausgetauscht werden. In den meisten Fällen hat ein Knoten jedoch nicht genügend Informationen, um einen solchen Pfad vollständig und genau zu identifizieren. Vielmehr muss ein Knoten einen PMTU-Wert mit einer lokalen Darstellung eines Pfades assoziieren. Es liegt an der Implementierung, die lokale Darstellung eines Pfades auszuwählen. Für Knoten mit mehreren Schnittstellen sollten Path MTU-Informationen für jeden IPv6-Link gepflegt werden.
Im Fall einer Multicast-Zieladresse können Kopien eines Pakets viele verschiedene Pfade durchlaufen, um viele verschiedene Knoten zu erreichen. Die lokale Darstellung des "Pfades" zu einem Multicast-Ziel muss eine potenziell große Menge von Pfaden darstellen.
Minimal könnte eine Implementierung einen einzelnen PMTU-Wert pflegen, der für alle vom Knoten ausgehenden Pakete verwendet wird. Dieser PMTU-Wert wäre die minimale PMTU, die über die Menge aller vom Knoten verwendeten Pfade gelernt wurde. Dieser Ansatz führt wahrscheinlich zur Verwendung kleinerer Pakete als für viele Pfade notwendig. Im Fall von Multipath-Routing (z.B. Equal-Cost Multipath Routing, ECMP) kann eine Menge von Pfaden selbst für ein einzelnes Quell- und Zielpaar existieren.
Eine Implementierung könnte die Zieladresse als lokale Darstellung eines Pfades verwenden. Der PMTU-Wert, der mit einem Ziel assoziiert ist, wäre die minimale PMTU, die über die Menge aller zu diesem Ziel verwendeten Pfade gelernt wurde. Dieser Ansatz führt zur Verwendung optimal dimensionierter Pakete auf Basis einzelner Ziele. Dieser Ansatz integriert sich gut mit dem konzeptionellen Modell eines Hosts, wie in [ND] beschrieben: Ein PMTU-Wert könnte mit dem entsprechenden Eintrag im Destination-Cache gespeichert werden.
Wenn Flows [RFC8200] verwendet werden, könnte eine Implementierung die Flow-ID als lokale Darstellung eines Pfades verwenden. Pakete, die an ein bestimmtes Ziel gesendet werden, aber zu verschiedenen Flows gehören, können verschiedene Pfade verwenden, wie bei ECMP, bei dem die Wahl des Pfades von der Flow-ID abhängen kann. Dieser Ansatz könnte zur Verwendung optimal dimensionierter Pakete auf Flow-Basis führen und eine feinere Granularität bieten als PMTU-Werte, die auf Basis einzelner Ziele gepflegt werden.
Für Quell-geroutete Pakete (d.h. Pakete, die einen IPv6-Routing-Header enthalten [RFC8200]) kann die Quell-Route die lokale Darstellung eines Pfades weiter qualifizieren.
Zunächst wird angenommen, dass der PMTU-Wert für einen Pfad die (bekannte) MTU des ersten Hop-Links ist.
Wenn eine Packet Too Big-Nachricht empfangen wird, bestimmt der Knoten, auf welchen Pfad die Nachricht zutrifft, basierend auf dem Inhalt der Packet Too Big-Nachricht. Wenn beispielsweise die Zieladresse als lokale Darstellung eines Pfades verwendet wird, würde die Zieladresse aus dem ursprünglichen Paket verwendet, um zu bestimmen, auf welchen Pfad die Nachricht zutrifft.
Hinweis: Wenn das ursprüngliche Paket einen Routing-Header enthielt, sollte der Routing-Header verwendet werden, um die Position der Zieladresse innerhalb des ursprünglichen Pakets zu bestimmen. Wenn Segments Left gleich Null ist, befindet sich die Zieladresse im Destination Address-Feld im IPv6-Header. Wenn Segments Left größer als Null ist, ist die Zieladresse die letzte Adresse (Address[n]) im Routing-Header.
Der Knoten verwendet dann den Wert im MTU-Feld in der Packet Too Big-Nachricht als tentative PMTU oder die IPv6-Mindest-Link-MTU, wenn diese größer ist, und vergleicht die tentative PMTU mit der bestehenden PMTU. Wenn die tentative PMTU kleiner ist als die bestehende PMTU-Schätzung, ersetzt die tentative PMTU die bestehende PMTU als PMTU-Wert für den Pfad.
Die Paketisierungsschichten müssen über Verringerungen der PMTU benachrichtigt werden. Jede Paketisierungsschicht-Instanz (z.B. eine TCP-Verbindung), die den Pfad aktiv nutzt, muss benachrichtigt werden, wenn die PMTU-Schätzung verringert wird.
Hinweis: Selbst wenn die Packet Too Big-Nachricht einen Original Packet Header enthält, der sich auf ein UDP-Paket bezieht, muss die TCP-Schicht benachrichtigt werden, wenn eine ihrer Verbindungen den gegebenen Pfad verwendet.
Außerdem sollte die Instanz, die das Paket gesendet hat, das die Packet Too Big-Nachricht hervorgerufen hat, benachrichtigt werden, dass ihr Paket verworfen wurde, selbst wenn die PMTU-Schätzung sich nicht geändert hat, damit sie die verworfenen Daten erneut übertragen kann.
Hinweis: Eine Implementierung kann die Verwendung eines asynchronen Benachrichtigungsmechanismus für PMTU-Verringerungen vermeiden, indem die Benachrichtigung bis zum nächsten Versuch verschoben wird, ein Paket zu senden, das größer ist als die PMTU-Schätzung. Bei diesem Ansatz sollte die SEND-Funktion fehlschlagen und eine geeignete Fehleranzeige zurückgeben, wenn versucht wird, ein Paket zu SEND, das größer ist als die PMTU-Schätzung. Dieser Ansatz kann für eine verbindungslose Paketisierungsschicht (wie eine, die UDP verwendet) besser geeignet sein, die (in einigen Implementierungen) schwer von der ICMPv6-Schicht zu "benachrichtigen" sein kann. In diesem Fall würden die normalen Timeout-basierten Retransmissions-Mechanismen verwendet, um sich von den verworfenen Paketen zu erholen.
Es ist wichtig zu verstehen, dass die Benachrichtigung der Paketisierungsschicht-Instanzen, die den Pfad verwenden, über die Änderung der PMTU von der Benachrichtigung einer bestimmten Instanz unterschieden werden muss, dass ein Paket verworfen wurde. Letzteres sollte so schnell wie praktisch möglich erfolgen (d.h. asynchron aus der Sicht der Paketisierungsschicht-Instanz), während Ersteres verzögert werden kann, bis eine Paketisierungsschicht-Instanz ein Paket erstellen möchte.