Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information
obsoletes
- rfc-5101 — Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
also
- std-77
Extracted elements (29)
Template IDs are reused across Transport Sessions deliberately so that Exporting Processes have freedom to allocate IDs without coordination across sessions. Collecting Processes are explicitly prohibited from assuming Template ID stability across sessions precisely because the protocol does not guarantee it, avoiding a class of incorrect-interpretation bugs.
The Enterprise bit in the Field Specifier allows vendors to define proprietary Information Elements without IANA registration, enabling pre-standards products and commercially sensitive IEs. The 15-bit IE identifier space is doubled for enterprise use by the presence of a 32-bit IANA Private Enterprise Number, keeping the standard and enterprise namespaces cleanly separated.
RFC 7011 obsoletes RFC 5101 and is interoperable with it. All outstanding errata on RFC 5101 have been resolved, template management language has been relaxed compared to RFC 5101 (especially around Template ID reuse failure cases), and the new specification is interoperable to the extent that behavior was defined in the prior specification.
All IPFIX values, including Message Header and Set Header fields and all Information Elements (except string and octetArray), MUST be encoded in network byte order (big-endian). Signed integral types use two's complement. Float types use IEEE 754 binary32/binary64 in network byte order.
Collecting Processes MUST properly handle Templates with multiple identical Information Elements, and MUST properly handle the case where different Observation Domains within a Transport Session use the same Template ID to refer to different Templates.
Exporting Processes SHOULD export dateTimeSeconds and the Export Time Message Header field as seconds since the UNIX epoch modulo 2^32 to support timestamp wraparound (expected 7 February 2106). Collecting Processes SHOULD use current date or contextual information to interpret such values correctly.
IPFIX Exporting Processes MUST NOT send IPFIX Messages containing ill-formed UTF-8 string values for Information Elements of the string data type; Collecting Processes SHOULD detect and ignore such values. The string data type MUST be encoded in UTF-8 format.
IPFIX implementations MUST support SCTP as the transport protocol. TCP and UDP MAY additionally be supported. When SCTP is used, the Exporting Process MUST use a single SCTP association per Collecting Process and SHOULD use multiple SCTP streams to avoid head-of-line blocking.
Padding octets inserted by the Exporting Process to align Set boundaries MUST be composed of zero-value octets, and the padding length MUST be shorter than any allowable record in the Set. Record types MUST NOT be mixed within a Set.
Reduced-size encoding MAY be applied to signed, unsigned, and float integer types, allowing export with fewer octets than the information model maximum. The signed/unsigned property MUST be preserved, and only leading zeroes may be dropped. Reduced-size encoding MUST NOT be applied to types with internal structure or restricted ranges (e.g., ipv4Address, dateTimeMicroseconds, dateTimeMilliseconds).
The Collecting Process MUST store all received Template Record information for the duration of each Transport Session and MUST NOT use Templates from one Transport Session to decode Data Sets in a subsequent Transport Session. Template IDs from a given Exporting Process MUST NOT be assumed to refer to the same Templates across sessions.
The Scope Field Count in an Options Template Record MUST NOT be zero; at least one Scope Field is required. If a different order of Scope Fields would result in a different semantic meaning, the order MUST be preserved by the Exporting Process.
When UDP is used, the Exporting Process MUST periodically retransmit all Template Records so that a Collecting Process that starts or restarts can receive them. The retransmission period SHOULD be configurable, and Template Records MUST be retransmitted within the configured period.
Flow data collected by IPFIX may include sensitive information such as IP addresses, port numbers, and communication patterns that can reveal details about users' activities. Operators MUST consider access control, data minimization, and retention policies to protect end-user privacy when deploying IPFIX collectors.
Template Withdrawal allows an Exporting Process to signal that a Template ID is no longer in use by sending a Template Record with Field Count = 0 for that Template ID. After receiving a withdrawal, a Collecting Process MUST stop using the Template to interpret subsequently exported Data Sets. Template Withdrawal does not apply to UDP transport.
The IPFIX Template Record defines the structure of Data Records via an ordered sequence of Field Specifiers, each identifying an Information Element by ID and length. Templates enable the Collecting Process to interpret Data Records without prior knowledge of all IE types. Template IDs (256–65535) are allocated per Transport Session and Observation Domain, and Templates and Options Templates cannot share IDs within a session.
The Metering Process Statistics Options Template, Metering Process Reliability Statistics Options Template, Exporting Process Reliability Statistics Options Template, and Flow Keys Options Template are defined as standard Options Templates for exporting operational metadata about the Metering and Exporting Processes.
The Options Template Record extends the Template concept with Scope Fields that provide context for the reported Data Records. The Scope Field Count specifies that the first N Field Specifiers are scope fields. At a minimum, Collecting Processes SHOULD support observationDomainId, exportingProcessId, meteringProcessId, templateId, lineCardId, exporterIPv4Address, exporterIPv6Address, and ingressInterface as scope.
The Sequence Number in the IPFIX Message Header is an incremental counter modulo 2^32 of all IPFIX Data Records sent in the current stream from the current Observation Domain. Each SCTP stream counts separately; TCP and UDP sessions are treated as a single stream. Template and Options Template Records do not increment the Sequence Number.
RFC 7011 relies on and updates the IANA 'IPFIX Information Elements' registry (formerly at IANA-IPFIX), which is now the normative reference for all Information Element definitions as specified in RFC 7012. The document also references the IANA Private Enterprise Numbers (PEN) registry for enterprise-specific Information Elements.
IPFIX Collecting Processes are susceptible to denial-of-service attacks via high-rate IPFIX message floods or via malformed IPFIX Messages. Implementations SHOULD implement rate limiting and MUST handle malformed messages gracefully without crashing or excessive resource consumption.
IPFIX deployments SHOULD use TLS for TCP transport and DTLS for UDP and SCTP transport to protect the confidentiality and integrity of exported flow data. Without such protection, IPFIX traffic is susceptible to eavesdropping, modification, and injection of false flow data.
Mutual authentication between Exporting and Collecting Processes MUST be performed using TLS or DTLS with certificate-based authentication. The Collecting Process MUST authenticate the Exporting Process and vice versa to prevent unauthorized data export or collection.
The boolean data type is encoded as a single-octet integer with value 1 for true and value 2 for false; all other values are undefined. The dateTimeMicroseconds and dateTimeNanoseconds types share an identical 64-bit NTP Timestamp encoding (two 32-bit fields: Seconds and Fraction), but for dateTimeMicroseconds the bottom 11 bits of the Fraction field SHOULD be zero and MUST be ignored.
The Field Specifier consists of an Enterprise bit (E, 1 bit), Information Element identifier (15 bits), Field Length (16 bits), and an optional 32-bit Enterprise Number present only when E=1. When E=0, the Enterprise Number MUST NOT be present; when E=1, the Enterprise Number MUST be present.
The IPFIX Message Header is a fixed 16-octet structure containing: Version Number (16-bit, value 0x000a), Length (16-bit, total message length in octets), Export Time (32-bit unsigned, seconds since UNIX epoch), Sequence Number (32-bit, incremental counter of Data Records modulo 2^32), and Observation Domain ID (32-bit). All fields are exported in network byte order.
The Set Header is a fixed 4-octet structure with Set ID (16-bit) and Length (16-bit, total Set length including header, records, and padding). Set ID 2 is reserved for Template Sets, 3 for Options Template Sets, 4–255 reserved for future use, and values 256 and above identify Data Sets.
The Template Record Header contains Template ID (16-bit, range 256–65535) and Field Count (16-bit). Template IDs are unique per Transport Session and Observation Domain. The Options Template Record Header additionally includes a Scope Field Count (16-bit), which MUST NOT be zero.
Variable-length Information Elements use a 1-octet length prefix for values less than 255 octets. For values of 255 octets or more, the first octet MUST be 255 and the actual length is carried in the following 2 octets (supporting lengths 0–65535). The length octets are not included in the reported length of the Information Element. In Templates, variable-length IEs use the reserved Field Length value 65535.