Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types
Extracted elements (28)
Float writers MAY sacrifice precision to produce a more human-readable representation, at the expense of exact bit-pattern recovery at the reader; this tradeoff is intentional given the human-readability goal of the encoding.
In most cases where a textual representation is used, an explicit tradeoff is made for human readability or manipulability over compactness; this assumption drives all standard representations defined in this document.
Textual encodings for IPFIX abstract data types are defined to allow the IPFIX Information Elements registry to be used with JSON, XML, and other text-based protocols, enabling interoperability at the Information Element definition level without changing the IPFIX binary protocol itself.
The structured list ADTs (basicList, subTemplateList, subTemplateMultiList) are excluded from textual representation because they are structural mechanisms rather than true data types, and text-based protocols are expected to provide equivalent structural mechanisms natively.
In textual representations, Information Elements are identified by their human-readable names rather than by numeric Information Element identifiers, since numeric IDs are meaningful only in the context of the binary IPFIX protocol.
Mixed-direction Unicode strings should be avoided in this encoding because there is no accepted solution for their safe processing and display; direct byte-pattern comparison is insufficient for equivalence — see RFC 6885 and PRECIS for risks.
Unlike RFC 3339, timezone offsets are explicitly not permitted for IPFIX dateTime ADTs; all textual timestamps must be expressed in UTC only, reflecting the UTC-only nature of IPFIX binary timestamps.
Float values MUST be within range for single- or double-precision as defined in IEEE 754-2008; finite values outside range are clamped. Decoders MUST NOT assume represented float values are exactly comparable for equality, as writers MAY sacrifice precision for readability.
If the Enclosing Context defines a representation for binary objects, that representation SHOULD be used for octetArray values rather than the hex-pair default.
Information Elements of the basicList, subTemplateList, and subTemplateMultiList abstract data types MUST NOT be used in textual representations; protocols using textual IE representation are expected to provide their own structure.
Strings containing characters reserved in the Enclosing Context (control characters, markup, quotes) MUST be escaped or quoted per the Enclosing Context rules; nonrepresentable Unicode characters MUST also use the context's escaping facility.
The encoded value of a signed integer MUST be within range for the corresponding abstract data type or Information Element; out-of-range values are clipped to the implicit or explicit range.
The encoded value of an unsigned integer MUST be within range for the corresponding abstract data type or Information Element; out-of-range values are interpreted as clipped to the implicit or explicit range.
Boolean values are represented by the literal strings 'true' and 'false' unless the Enclosing Context provides its own boolean representation, which SHOULD be used instead.
float32 and float64 values are encoded as optionally signed, optionally base-10 exponent-suffixed decimal numbers per IEEE 754-2008; the special literals 'NaN', '+inf', and '-inf' represent not-a-number and infinities. Exponents are limited to at most three digits.
IPv4 addresses are encoded in dotted-quad format, most significant byte first, following the ABNF from RFC 3986; each octet is a decimal value 0–255 with no leading zeroes beyond the single-digit case.
IPv6 addresses are encoded per RFC 4291 Section 2.2 as updated by RFC 5952 (compressed '::' notation, lowercase hex, leading-zero suppression), using the ABNF from RFC 3986.
MAC addresses are encoded as IEEE 802 MAC-48 addresses: six colon-separated 2-digit hexadecimal octets with the most significant byte first. ABNF: macaddress = 2HEXDIG 5(':' 2HEXDIG).
Signed integer types (signed8/16/32/64) are represented as optionally sign-prefixed base-10 decimal strings; omitted sign implies positive, '-0' is valid and equals zero, and leading zeroes do not imply octal.
String Information Elements (already Unicode/UTF-8 in IPFIX binary) are represented directly using the Unicode encoding and the quoting/escaping rules of the Enclosing Context; if the context cannot represent a Unicode character natively, the context's escaping facility MUST be used.
The 'Enclosing Context' is the outer textual format (e.g., JSON, XML) within which IPFIX Information Element values are embedded; it defines the escaping and quoting rules that govern how represented values are handled.
The four dateTime ADTs are encoded as RFC 3339 UTC timestamps with precision-appropriate fractional seconds: dateTimeSeconds (no fraction), dateTimeMilliseconds ('.NNN'), dateTimeMicroseconds ('.NNNNNN'), dateTimeNanoseconds ('.NNNNNNNNN'). Time zone offsets are not supported; all timestamps are UTC.
The octetArray type is encoded as a string of pairs of hexadecimal digits, one pair per byte, in wire order; optional whitespace may appear between pairs for readability. ABNF: octetarray = 2HEXDIG *([WSP] 2HEXDIG).
Unsigned integer types (unsigned8/16/32/64) may be represented as unprefixed decimal, '0x'-prefixed hexadecimal, or '0b'-prefixed binary strings; leading zeroes are allowed and do not imply octal. For codepoint-semantic IEs, the codepoint name string MAY be used instead.
Because this encoding is not intended for storage but storage of exchanged data is common practice, the privacy considerations of RFC 7011 Section 11.8 are especially important; the ubiquity of text indexing tools increases the risk of privacy-sensitive network traffic data being accidentally indexed or searched.
Decoder implementations MUST correctly handle invalid input for all encoded ADT values; while the encodings are not special in this regard, robustness against malformed data is required.
The 'string' abstract data type may be vulnerable to ill-formed UTF-8 string attacks as discussed in RFC 7011 Section 6.1.6; all other ADT encodings are representable in US-ASCII and are not subject to this risk.
When transmitting or storing network traffic data in this textual encoding, privacy-sensitive columns or keys should be omitted using black-marker anonymization (RFC 6235 Section 4) or other anonymization techniques from RFC 6235.