Einbinden von Fragmentierungs-ID- und IPv6-Erweiterungs-Header-Elementen in IPFIX-Vorlagen auf Routern der MX-Serie

Ein Flow kann viele Fragmente in einem bestimmten Intervall empfangen. Für einen bestimmten Satz von Fragmenten eines Pakets gibt es eine eindeutige Fragment-Identifikation. Daher können mehrere solcher Werte in einem bestimmten Intervall empfangen werden. RFC 5102 für fragmentIdentification 54 gibt nicht eindeutig an, welche Fragmentidentifizierung in den Datenflussdatensatzinformationen versendet werden muss (erstes Fragment, das nach dem Senden der Datenstromdatensatzinformationen beobachtet wird, oder das letzte, das vor dem Versand der Datenstromdatensatzinformationen beobachtet wird). Die zuletzt beobachtete Fragmentidentifikation für eine bestimmte Strömung wird jedoch auch an den Strömungssammler übertragen.

Anders als bei IPv4 fragmentieren IPv6-Router niemals IPv6-Pakete. Pakete, die die Größe der maximalen Übertragungseinheit der Zielverbindung überschreiten, werden verworfen, und dieser Zustand wird durch eine ICMPv6-Typ-2-Nachricht vom Typ "Paket zu groß" an den Ursprungsknoten signalisiert, ähnlich wie bei der IPv4-Methode, wenn das DF-Bit (Don't Fragment) festgelegt ist.

Das fragmentIdentification-Element wird sowohl für IPv4- als auch für IPv6-Datenflussvorlagen unterstützt. Das fragmentIdentification-Element wird der Datensatzvorlage hinzugefügt. Das fragmentIdentification-Attribut ist sowohl für IPv4 als auch für IPv6 32 Bit groß. Bei IPv6 ist dieses Feld im Fragment-Extension-Header vorhanden, und der Fragment-Identifier wird als 0 aktualisiert, wenn kein Fragment-Extension-Header vorhanden ist.

Ports sind ein Teil des Schlüssels, der zur Identifizierung eines Flows und der nachfolgenden Pakete verwendet wird, nachdem das erste fragmentierte Paket keine Portinformationen enthält. Bei einem fragmentierten Paket, das für den Router bestimmt ist, gehen die geteilten Pakete von unterschiedlichen Strömen aus (das erste und das nachfolgende Paket). Da der Port bei fragmentierten Paketen als Nullen angegeben wird, kann der gesamte Datenverkehr, der von einer bestimmten Quelle zu einem bestimmten Ziel bestimmt ist, als derselbe Datenstrom gemeldet werden, obwohl keine Zuordnung zwischen ihnen in Bezug auf Zielports besteht. Die Fragment-ID ist nicht Teil des Schlüssels. Obwohl das Fragment-ID-Attribut zwischen Quelle und Ziel eindeutig ist, können sie im zwischengeschalteten Router als dieselben Datenströme enden.

Da Ports im Schlüssel für die Datenstromsuche verwendet werden, werden die fragmentierten Pakete eines Datenstroms in zwei verschiedenen Datenströmen erfasst. Das erste fragmentierte Paket, das die Portinformationen in seinem Paket enthält, ist Teil eines Datenstroms. Nachfolgende Pakete nach den ersten Fragmenten, die die Portinformationen nicht enthalten, werden in einem anderen Fluss abgerechnet. Da der zweite Datenstrom keine Portinformationen enthält, um sich selbst zu identifizieren, konsolidiert er alle anderen Datenströme mit denselben Quell-IP- und Ziel-IP-Adresspräfixen (schließt auch die nicht ersten fragmentierten Pakete ein, die an verschiedenen Ports gesendet werden).

Von Zielknoten oder Endpunkten in IPv6 wird erwartet, dass sie eine MTU-Pfaderkennung durchführen, um die maximale Größe der zu sendenden Pakete zu bestimmen, und es wird erwartet, dass das Protokoll der oberen Ebene die Nutzlastgröße begrenzt. Wenn das Protokoll der oberen Schicht jedoch nicht dazu in der Lage ist, kann der sendende Host den Fragment-Erweiterungsheader verwenden, um eine End-to-End-Fragmentierung von IPv6-Paketen durchzuführen. Jede Datenverbindungsschicht, die IPv6-Daten überträgt, muss in der Lage sein, ein IP-Paket mit 1280 Byte zuzustellen, ohne dass eine End-to-End-Fragmentierung auf der IP-Ebene aufgerufen werden muss.

Das Informationselement ipv6ExtensionHeaders ist ein Satz für 32-Bit-Felder. Jedes Bit in diesem Satz stellt einen IPv6-Erweiterungsheader dar. Ein Erweiterungsheaderbit wird festgelegt, wenn dieser bestimmte Erweiterungsheader für den Fluss beachtet wird. Das Bit wird auf 1 gesetzt, wenn ein beobachtetes Paket dieses Flows den entsprechenden IPv6-Erweiterungsheader enthält. Andernfalls, wenn kein beobachtetes Paket dieses Flows den entsprechenden IPv6-Erweiterungsheader enthielt, ist der Wert des entsprechenden Bits 0. Das ipv6ExtensionHeaders-Element wird in der Datensatzvorlage hinzugefügt. Die Anzahl der erstellten Datenströme hängt von der Anzahl der IPv6-Pakete ab, die das Attribut IPv6 extender header enthalten.

Um die Aufnahme von Element ID, 54, fragmentIdentification und Element ID, 64, ipv6ExtensionHeaders in IPFIX-Flussvorlagen zu ermöglichen, die in den Flow-Kollektor exportiert werden, schließen Sie die ipv6-extended-attrib Anweisung auf der [edit chassis fpc slot-number inline- services flow-table-size] Hierarchieebene ein. Die Erfassung von IP4-Fragmentierungs-IDs erfolgt automatisch, ohne dass diese Einstellung explizit konfiguriert werden muss.

Ab den Junos OS-Versionen 17.3R4, 17.4R3, 18.1R4, 18.2R2, 18.3R2 und 18.4R1 werden die Werte der IPv6-Optionen und ihre Funktionen, die in IPv6-Paketen enthalten sind, in Tabelle 1 beschrieben.

Für Junos OS-Versionen vor 17.3R4, 17.4R3, 18.1R4, 18.2R2 und 18.3R2 werden die Werte der IPv6-Optionen und ihre Funktionen, die in IPv6-Paketen enthalten sind, in Tabelle 2 beschrieben.