Information Model for IP Flow Information Export

For Information Elements derived from packet header fields where values may change packet-to-packet within a Flow, the model defines that their value is determined by the first packet observed for the Flow unless the IE description specifies otherwise. This allows header-derived IEs to be written once at flow start rather than updated per packet.

Information Elements with the 'post' prefix (e.g., postIpClassOfService IE 55) report Flow properties after modification by downstream middlebox functions, obtained within the Observation Domain by other means (e.g., analyzing a packet marker's tables) rather than direct observation at the Observation Point.

The information model was intentionally defined in an open way to allow use in protocols, interfaces, and applications beyond IPFIX. The XML-based specification in the appendices (informational) enables automated syntactical checking and code generation, while the main body remains normative.

totalCounter and deltaCounter semantics are distinguished because totalCounter counts independently of export (analogous to SNMP Counter32), while deltaCounter resets to 0 on each export. This prevents double-counting during aggregation across multiple export intervals at the Collector.

snmp

exportProtocolVersion (IE 214, unsigned8) identifies the export protocol in use: value 10 for IPFIX, value 9 for NetFlow version 9, and value 0 when no export protocol is in use.

Information Element identifier values 1–127 are backward-compatible with field types used by NetFlow version 9 [RFC3954], easing migration from NetFlow v9 deployments to IPFIX.

The ingressInterface (IE 10) and egressInterface (IE 14) IEs match ifIndex as defined in RFC 2863, but ifIndex values are not statically assigned and may be renumbered each time the device's management system is re-initialized.

snmp

All IPFIX Information Elements (defined in this document or any future extension) MUST have the following properties defined: name, elementId, description, dataType, and status.

registry

Enterprise identifiers used for enterprise-specific Information Element identifiers MUST be registered as SMI network management private enterprise code numbers with IANA.

registry

Enterprise-specific Information Elements MUST have an enterpriseId defined. If used outside the enterprise, the enterprise-specific identifier MUST be made globally unique by combining it with an SMI network management private enterprise code registered with IANA.

registry

For flowKeyIndicator, bits corresponding to Information Elements beyond those present in the Data Record MUST have the value 0. If a record has more than 64 IEs, the Template SHOULD be designed so all Flow Keys fall within the first 64 IEs, since flowKeyIndicator only holds 64 bits.

It is RECOMMENDED that observationDomainId (IE 149) is also unique per IPFIX Device, not just locally unique to an Exporting Process. A value of 0 indicates no specific Observation Domain.

Names of non-enterprise-specific Information Elements MUST be unique within the IPFIX information model. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name.

The reserved bit (Bit 0, RS) in the fragmentFlags Information Element MUST be 0 until specified otherwise.

ip

commonPropertiesId (IE 137, unsigned64, identifier) identifies a set of common properties unique per Observation Domain and Transport Session, used to link Data Records sharing common properties stored separately.

Data type semantics qualify integral Information Elements: 'quantity' (discrete measured value), 'totalCounter' (cumulative, counts independently of export and wraps at type limit), 'deltaCounter' (reset to 0 on each export), 'identifier' (equality comparisons only; arithmetic is meaningless), and 'flags' (bitfield; logical operations appropriate).

flowKeyIndicator (IE 173, unsigned64, flags) uses a 64-bit field where the n-th bit, when set to 1, marks the n-th Information Element in a Data Record as a Flow Key of the reported Flow.

Metering and Exporting Process statistics group (Section 5.3) defines nine unsigned64 totalCounter IEs: exportedMessageTotalCount (41), exportedOctetTotalCount (40), exportedFlowRecordTotalCount (42), observedFlowTotalCount (163), ignoredPacketTotalCount (164), ignoredOctetTotalCount (165), notSentFlowTotalCount (166), notSentPacketTotalCount (167), and notSentOctetTotalCount (168).

observationDomainId (IE 149, unsigned32, identifier) uniquely identifies the Observation Domain to a Collecting Process within an Exporting Process. Typically used to limit scope of other Information Elements.

protocolIdentifier (IE 4, unsigned8, identifier) carries the IANA-assigned IP protocol number from the IPv4 Protocol field or the final IPv6 Next Header field, identifying the packet payload type.

ip

The IPFIX abstract data type system defines unsigned integers (unsigned8/16/32/64), signed integers (signed8/16/32/64), IEEE 754 floating point (float32/float64), boolean, macAddress (6 octets), octetArray, Unicode string, four datetime resolutions (dateTimeSeconds/Milliseconds/Microseconds/Nanoseconds), ipv4Address, and ipv6Address. All datetime types are UTC-based with leap seconds excluded.

IANA administers the IPFIX Information Elements registry. IANA-assigned IE identifiers are in the range 1–32767; identifier 0 is reserved. Identifiers 1–127 are compatible with NetFlow version 9 field types; 128–32767 are further IPFIX-specific identifiers.

registry

IANA administers the MPLS Label Type Identifier registry, which is referenced by the mplsTopLabelType Information Element (IE 46).

registry, mpls

IANA registers the XML namespace and schema for the IPFIX information model as defined in this document and its appendices.

registry

Section 8 addresses security considerations for the IPFIX information model. The model defines Information Elements (IP addresses, port numbers, packet and byte counts, flow keys) that constitute sensitive traffic metadata capable of revealing communication patterns; implementations must apply appropriate access controls to IPFIX collection infrastructure and consider using secure transport for IPFIX messages.

security, privacy

fragmentFlags (IE 197, unsigned8, flags) encodes fragmentation properties: Bit 0 = RS (reserved, must be 0), Bit 1 = DF (Don't Fragment, from IPv4 or future IPv6), Bit 2 = MF (More Fragments, from IPv4 or IPv6 Fragment header M flag), Bits 3–7 = don't care.

ip

isMulticast (IE 206, unsigned8, flags) encodes: Bit 0 = IPv4 multicast (destination in 224.0.0.0–239.255.255.255), Bits 1–2 reserved, Bit 3 = IPv6 T flag, Bits 4–7 = IPv6 multicast scope; all bits zero for unicast destinations.

ip, multicast