Einschließlich Fragmentierungsbezeichner und IPv6 Extension Header-Elemente in IPFIX-Vorlagen auf Routern der MX-Serie

Ein Datenstrom kann viele Fragmente in einem bestimmten Intervall empfangen. Für eine bestimmte Gruppe von Fragmenten eines Pakets gibt es eine eindeutige Fragment-Identifizierung. Daher können mehrere solche Werte in einem bestimmten Intervall empfangen werden. RFC 5102 für FragmentIdentifizierung 54 gibt nicht eindeutig an, welche Fragmentidentifizierung in den Datenflussdatensatz gesendet werden muss (erstes Fragment beobachtet nach dem Senden der Datenstromdatensatzinformationen oder das zuletzt beobachtete vor dem Versand der Datenstromdatensatzinformationen). Das zuletzt beobachtete Fragment Identifizierung für einen bestimmten Fluss wird jedoch auch an den Datenstromsammler übermittelt.

Im Gegensatz zu IPv4 fragmentiert IPv6-Router niemals IPv6-Pakete. Pakete, die die Größe der maximalen Übertragungseinheit der Zielverbindung überschreiten, werden gelöscht, und diese Bedingung wird durch eine Packet Too Big ICMPv6-Nachricht des Typs 2 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-Flussvorlagen unterstützt. Das fragmentIdentification-Element wird der Datensatzvorlage hinzugefügt. Das FragmentIdentification-Attribut hat eine Größe von 32 Bits sowohl für IPv4 als auch für IPv6. Für IPv6 ist dieses Feld im Fragment Extension Header vorhanden, und Fragment Identifier wird als 0 aktualisiert, wenn kein Fragmenterweiterungs-Header vorhanden ist.

Ports sind Teil des Schlüssels, der zur Identifizierung eines Datenstroms und der nachfolgenden Pakete verwendet wird, nachdem das erste fragmentierte Paket keine Portinformationen hat. Für ein fragmentiertes Paket, das für den Router bestimmt ist, gehen die geteilten Pakete von unterschiedlichen Datenströmen aus (das erste und die nachfolgenden Pakete). Da der Port auch als Nullen für fragmentierte Pakete angegeben wird, kann der gesamte Datenverkehr, der von einer bestimmten Quelle an ein bestimmtes Ziel bestimmt ist, als derselbe Datenfluss gemeldet werden, obwohl keine Zuordnung zwischen ihnen in Bezug auf Zielports besteht. Fragment-ID ist nicht Teil des Schlüssels. Obwohl das Fragment-ID-Attribut zwischen jeder Quelle und dem Ziel eindeutig ist, können sie als dieselben Datenströme im Zwischenrouter enden.

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

Es wird erwartet, dass Zielknoten oder Endpunkte in IPv6 eine Pfad-MTU-Erkennung durchführen, um die maximale Größe der zu sendenden Pakete zu bestimmen, und das Protokoll der oberen Ebene wird erwartet, dass die Nutzlastgröße begrenzt wird. Wenn das Protokoll der oberen Schicht jedoch nicht in der Lage ist, kann der sendende Host den Fragment-Erweiterungs-Header verwenden, um eine end-to-End-Fragmentierung von IPv6-Paketen durchzuführen. Jede Datenverbindungsschicht, die IPv6-Daten transportiert, muss in der Lage sein, ein IP-Paket mit 1280 Bytes zu liefern, ohne dass auf der IP-Ebene eine End-to-End-Fragmentierung aufgerufen werden muss.

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

Um die Integration von Element-ID, 54, fragmentIdentification und Element-ID, 64, ipv6ExtensionHeaders in IPFIX-Flussvorlagen, die in den Datenstromsammler exportiert werden, zu ermöglichen, fügen Sie die ipv6-extended-attrib Anweisung auf Hierarchieebene ein [edit chassis fpc slot-number inline- services flow-table-size] . 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 deren 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 deren Funktionen, die in IPv6-Paketen enthalten sind, in Tabelle 2 beschrieben.