Information Model for IP Flow Information Export (IPFIX)
obsoletes
- rfc-5102 — Information Model for IP Flow Information Export
Extracted elements (25)
IE identifiers 1–127 are kept compatible with NetFlow version 9 field types for historical reasons. IANA marks reserved IEs in this range as 'Assigned for NetFlow v9 compatibility' with a reference to RFC 3954.
Information Elements with the 'post' prefix (e.g., postIpClassOfService) report Flow properties obtained after middlebox modification within the Observation Domain rather than directly observed at the Observation Point. This design allows reporting of both pre- and post-modification values.
The use of the term 'information model' for IPFIX is not fully aligned with RFC 3444's definition, because the IPFIX information model specifies neither relationships between Information Elements nor a concrete wire encoding. The IPFIX encoding is defined separately in RFC 7011; other encodings (e.g., XML) are also possible.
IE identifiers in the range 1–127 are backward-compatible with NetFlow version 9 field types (RFC 3954). New assignments in this range are restricted to IEs that are compatible with the NetFlow v9 protocol, ensuring tools supporting both protocols can share the same identifier space.
All Information Elements specified for the IPFIX protocol MUST have name, elementId, description, dataType, and status defined. String or octetArray IEs with length constraints MUST note those constraints in their descriptions.
Enterprise-specific Information Elements MUST have an enterpriseId defined. If such IEs are used outside the enterprise, the identifier MUST be made globally unique by combining it with an enterprise identifier from the IANA SMI private enterprise numbers registry.
For Information Elements with packet-derived values that may change per packet within a single Flow, the exported value is by default determined by the first packet observed for the corresponding Flow, unless the IE description explicitly specifies different semantics.
Future IE registry assignments requiring subregistries for enumerated values must have those subregistries added simultaneously with the new assignment; additions to these subregistries must be subject to Expert Review.
If a valid inclusive range is specified for an Information Element, values outside that range are invalid and MUST NOT be exported.
Information Element identifiers in range 1–127 must not be assigned to new IEs unless the IE is compatible with the NetFlow version 9 protocol, as determined by a NetFlow v9 expert among the IE-DOCTORS.
Information Element names MUST be unique within the IANA 'IPFIX Information Elements' registry. Names MUST start with lowercase letters, and composed names MUST use camelCase (first letter of each component capitalized except the first).
IPFIX Collectors MAY use the machine-readable IANA registry to automatically adapt to information model extensions, but SHOULD NOT poll the IANA registry directly at runtime to avoid unnecessary load on IANA infrastructure.
New abstract data types and new data type semantics added to the IPFIX subregistries require a Standards Action and MUST be defined in IETF Standards Track documents updating RFC 7012.
The 'identifier' semantic MUST be applied only to signed or unsigned integral data types. The 'flags' semantic MUST always use an unsigned data type.
Enterprise-specific Information Elements use identifiers in range 1–32767 combined with an enterprise identifier (SMI PEN). Enterprise IE identifier 0 is reserved; enterprises may freely assign 1–32767 within their enterprise scope, and the same numeric ID used by different enterprises identifies distinct IEs.
IANA-assigned Information Element identifiers occupy the range 1–32767. Identifiers 1–127 are reserved for NetFlow version 9 compatibility. IANA assigns newly registered IEs the lowest available identifier in the range 128–32767.
IPFIX defines 23 abstract data types: unsigned8/16/32/64, signed8/16/32/64, float32, float64, boolean, macAddress, octetArray, string, dateTimeSeconds/Milliseconds/Microseconds/Nanoseconds, ipv4Address, ipv6Address, basicList, subTemplateList, and subTemplateMultiList.
IPFIX defines five data type semantics: 'quantity' (default for all numerics), 'totalCounter' (wrapping counter that counts independently of export), 'deltaCounter' (wrapping counter reset to 0 on each export), 'identifier' (only equality operations are meaningful), and 'flags' (bit fields; logical operations only).
The IPFIX Information Element Specification Template requires every IE to have a name, elementId, description, dataType, and status. Optional properties include dataTypeSemantics, units, range, reference, revision, and date.
IANA created an 'IPFIX MPLS label type' subregistry for IE #46 (mplsTopLabelType), initially populated from the description of that IE in RFC 5102. New MPLS label type assignments require Expert Review; specifications must be published in a well-established, persistent publication medium.
The IANA 'IPFIX Information Elements' registry (IP Flow Information Export Entities) is the normative reference for IPFIX IEs. It uses Expert Review (by IE-DOCTORS appointed by IESG) for additions, revisions, and deprecations. The registry stores at minimum the fields defined in the IE Specification Template (Section 2.1).
The 'IPFIX Information Element Data Types' and 'IPFIX Information Element Semantics' subregistries are governed by Standards Action. IANA added Revision and Date columns to the IE registry when obsoleting RFC 5102 with this document.
The IPFIX information model does not directly introduce security issues, but Information Elements (e.g., header field values) may constitute sensitive information for privacy or business reasons. Exporting header field values may enable attacks by the receiver that would otherwise require direct observation of traffic along the data path.
The underlying protocol used to exchange IPFIX information MUST apply appropriate procedures to guarantee integrity and confidentiality of exported information; these procedures are defined in the IPFIX Protocol Specification (RFC 7011).
The 'basicList' type supports structured data export per RFC 6313 Section 4.5.1. 'subTemplateList' and 'subTemplateMultiList' types are encoded per RFC 6313 Sections 4.5.2 and 4.5.3 respectively.