Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Including Fragmentation Identifier and IPv6 Extension Header Elements in IPFIX Templates on MX Series Routers

Starting with Junos OS Release 14.2, the following attributes can be contained in IPFIX flow templates that are sent to the flow collector:

  • fragmentIdentification (element ID 54)

  • ipv6ExtensionHeaders (element ID 64)

A flow can receive many fragments in a given interval. For a given set of fragments of a packet, there is a unique fragment Identification. Hence, multiple such values can be received in a given interval. RFC 5102 for fragmentIdentification 54 does not clearly indicate which fragment identification needs to be shipped in the flow record information (first fragment observed after sending the flow record information or the last observed before shipping the flow record information). However, the last observed fragment Identification for a given flow is also transmitted to the flow collector.

Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets exceeding the size of the maximum transmission unit of the destination link are dropped and this condition is signaled by a Packet Too Big ICMPv6 type 2 message to the originating node, similarly to the IPv4 method when the Don't Fragment (DF) bit is set.

The fragmentIdentification element is supported for both IPv4 and IPv6 flow templates. The fragmentIdentification element is added in the record template. The fragmentIdentification attribute is 32 bits in size for both IPv4 and IPv6. For IPv6, this field is present in fragment Extension header and Fragment Identifier is updated as 0 if there is no Fragment extension header.

Ports are a part of the key used to identify a Flow and the subsequent packets after the first fragmented packet does not have the port information. For a fragmented packet that is destined to the router, the packets that are split assume different flows (the first and the subsequent packets). Also, because the port is denoted as zeroes for fragmented packets, all the traffic destined to a particular destination from a particular source might be reported as the same flow, although no association exists between them in terms of destination ports. Fragment ID is not part of the key. Although the fragment ID attribute is unique between each source and destination, they might end up as same flows in the intermediate router.

With ports being used in the key for the flow lookup, the fragmented packets of a stream are accounted in two different flows. The first fragmented packet, which contains the port information in its packet, is part of one flow. Subsequent packets after the first fragments, which do not contain the port information, are accounted under a different flow. Because the second flow does not contain the port information to identify itself, it consolidates all the other traffic streams with same source IP and destination IP address prefixes (also includes the non-first fragmented packets sent on different ports).

Destination nodes or endpoints in IPv6 are expected to perform path MTU discovery to determine the maximum size of packets to send, and the upper-layer protocol is expected to limit the payload size. However, if the upper-layer protocol is unable to do so, the sending host can use the Fragment extension header in order to perform end-to-end fragmentation of IPv6 packets. Any data link layer conveying IPv6 data must be capable of delivering an IP packet containing 1280 bytes without the need to invoke end-to-end fragmentation at the IP layer.

The ipv6ExtensionHeaders information element is a set for 32 bit fields. Each bit in this set represents one IPv6 Extension header. An extension header bit is set if that particular extension header is observed for the flow. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contained the respective IPv6 extension header, the value of the corresponding bit is 0. The ipv6ExtensionHeaders element is added in the record template. The number of flows that are created depends on the number of IPv6 packets that include the IPv6 extender header attribute.

To enable the inclusion of element ID, 54, fragmentIdentification and element ID, 64, ipv6ExtensionHeaders in IPFIX flow templates that are exported to the flow collector, include the ipv6-extended-attrib statement at the [edit chassis fpc slot-number inline- services flow-table-size] hierarchy level. Collection of IP4 fragmentation IDs occurs automatically without having to configure this setting explicitly.

Starting in Junos OS Releases 17.3R4, 17.4R3, 18.1R4, 18.2R2, 18.3R2, and 18.4R1, the values of the IPv6 options and their functions that are contained in IPv6 packets are described in Table 1.

Table 1: Values of IPv6 Options and Extension Headers in Packets

Bit Value

IPv6 Option

Next Header Code

Description

0

DST

60

Destination option header

1

HOP

0

Hop-by-hop option header

2

Res

Not applicable

Reserved

3

UNK

Not applicable

Unknown layer 4 header (compressed, encrypted, not supported)

4

FRA0

44

Fragment header – first fragment

5

RH

43

Routing header

6

FRA1

44

Fragmentation header – not first fragment

7

Res

Not applicable

Reserved

8 through 11

Res

Not applicable

Reserved

12

MOB

135

IPv6 mobility (RFC3775)

13

ESP

50

Encrypted security payload

14

AH

51

Authentication header

15

PAY

108

Payload compression header

16 through 31

Res

Not applicable

Reserved

For Junos OS Releases prior to 17.3R4, 17.4R3, 18.1R4, 18.2R2, and 18.3R2, the values of the IPv6 options and their functions that are contained in IPv6 packets are described in Table 2.

Table 2: Values of IPv6 Options and Extension Headers in Packets

Bit Value

IPv6 Option

Next Header Code

Description

0

Res

Not applicable

Reserved

1

FRA1

44

Fragmentation Header

2

RH

43

Routing Header

3

FRA0

44

Fragment Header – First Fragment

4

UNK

Not applicable

Unknown Layer 4 header (compressed, encrypted, not supported)

5

Res

Not applicable

Reserved

6

HOP

0

Hop-by-hop option header

7

DST

60

Destination option header

8

PAY

108

Payload compression header

9

AH

51

Authentication header

10

ESP

50

Encrypted security payload

11 through 31

Res

Not applicable

Reserved

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.3R4
Starting in Junos OS Releases 17.3R4, 17.4R3, 18.1R4, 18.2R2, 18.3R2, and 18.4R1, the values of the IPv6 options and their functions that are contained in IPv6 packets are described in Table 1.