RFC 7119
Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
RFC 7119: Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators 🎀
Okay bestie, here's the paperwork. RFC 7119 is by B. Claise (Cisco Systems, Inc.), A. Kobayashi (NTT), and B. Trammell (ETH Zurich). It's a Standards Track document, ISSN 2070-1721, dated February 2014. The title block doesn't list anything it obsoletes or updates. 🦋
Abstract 🦋
This doc spells out how IPFIX works when it's running on IPFIX Mediators 💖. It covers Template and Observation Point management, timing, and the other Mediator-specific stuff 🧚.
Status of This Memo 📜
This is an Internet Standards Track document 🌸.
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7119.
Copyright Notice ⚖️
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. IPFIX Documents Overview ...................................3
1.2. IPFIX Mediator Documents Overview ..........................4
1.3. Relationship with the IPFIX and PSAMP Protocols ............5
2. Terminology .....................................................5
3. Handling IPFIX Message Headers ..................................8
4. Template Management ............................................10
4.1. Passing Unmodified Templates through an IPFIX Mediator ....11
4.1.1. Template Mapping and Information Element Ordering ..15
4.2. Creating New Templates at an IPFIX Mediator ...............17
4.3. Handling Unknown Information Elements .....................17
5. Preserving Original Observation Point Information ..............17
5.1. originalExporterIPv4Address Information Element ...........20
5.2. originalExporterIPv6Address Information Element ...........20
6. Managing Observation Domain IDs ................................20
6.1. originalObservationDomainId Information Element ...........21
7. Timing Considerations ..........................................21
8. Transport Considerations .......................................23
9. Collecting Process Considerations ..............................23
10. Specific Reporting Requirements ...............................23
10.1. Intermediate Process Reliability Statistics
Options Template .........................................24
10.2. Flow Key Options Template ................................26
10.3. intermediateProcessId Information Element ................26
10.4. ignoredDataRecordTotalCount Information Element ..........27
11. Operations and Management Considerations ......................27
12. Security Considerations .......................................28
13. IANA Considerations ...........................................28
14. Acknowledgments ...............................................29
15. References ....................................................29
15.1. Normative References .....................................29
15.2. Informative References ...................................301. Introduction ✨
So the IPFIX architecture from [RFC5470] has two main players, IPFIX Devices and IPFIX Collectors, and they talk to each other using the IPFIX protocol [RFC7011] 💅. That protocol says how to export IP Flow info. It's built for IP traffic Flows and related measurement data, where a Flow is defined by a set of key attributes (like source and destination IP address, source and destination port, and so on) 🦋.
Here's the thing that makes it iconic 👑: thanks to its Template mechanism, IPFIX can export basically any kind of info, as long as the Information Element is specified in the IPFIX Information Model [RFC7012], registered with IANA, or specified as an enterprise-specific Information Element. But IPFIX wasn't originally written with IPFIX Mediators in mind 🙈. So the protocol has to be adapted for Intermediate Processes, the way they're laid out in the IPFIX Mediation Reference Model in Figure A of [RFC6183], which builds on the IPFIX Mediation Problem Statement [RFC5982].
This document is all about IPFIX in the context of actually building and deploying IPFIX Mediators 🧚. Using IPFIX inside a Mediator (a device that has both a Collecting Process and an Exporting Process) changes the technical details of how the protocol gets used 💖. Section 6 of [RFC5982] gives an overview of the problem. The issues it lists are: loss of original Exporter information, loss of base time information, transport sessions management, loss of Options Template Information, Template Id management, considerations for network topology, IPFIX mediation interpretation, and considerations for aggregation 😭.
The specs here are based on the IPFIX protocol specs in [RFC7011], but they've been adapted to fit the IPFIX Mediation Framework [RFC6183] 🌈.
1.1. IPFIX Documents Overview
The IPFIX protocol [RFC7011] gives network admins access to IP Flow information 🌸.
Exporting measured IP Flow info from an IPFIX Exporting Process to a Collecting Process is covered by the IPFIX Architecture [RFC5470], which follows the requirements in the IPFIX Requirements document, [RFC3917] 🫶.
The IPFIX Architecture [RFC5470] also explains how IPFIX Data Records and Templates get carried from IPFIX Exporting Processes to IPFIX Collecting Processes over a congestion-aware transport protocol 🔥.
IPFIX has a formal description of its Information Elements, covering their names, types, and extra semantic info, as laid out in the IPFIX Information Model [RFC7012]. IANA maintains the IPFIX Information Element registry [IANA-IPFIX]. New Information Element definitions can be added to that registry subject to an Expert Review [RFC5226], and [RFC7013] describes the extra process considerations and gives guidance to authors and reviewers of new Information Element definitions 💅. The inline export of Information Element type information is specified in [RFC5610] ✨.
Last one: the IPFIX Applicability Statement [RFC5472] describes which kinds of applications can use IPFIX and how they can use the info it provides. It also shows how the IPFIX framework fits with other architectures and frameworks 💜.
1.2. IPFIX Mediator Documents Overview
"IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982] gives an overview of where IPFIX Mediators make sense, and it lays out the general requirements for them 🍓. This doc is mostly useful for defining the problems that IPFIX Mediators are meant to solve, and for scoping the role they play in an IPFIX collection infrastructure 🦋.
"IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183] goes into the IPFIX Mediation reference model and the components of an IPFIX Mediator, with more architecture details on how Intermediate Processes are arranged inside an IPFIX Mediator 🧚.
Docs that specify how particular Intermediate Processes operate cover those Processes within the IPFIX Mediator framework, and they comply with the specs in this document. They can also specify how the process works on its own, outside an IPFIX Mediator, when that makes sense 🌷. When an Intermediate Process has extra export specs (for example, metadata about the intermediate processing sent through IPFIX Options Templates), each one is handled in its own document 📦. As of today, those documents are:
- "IP Flow Anonymization Support", [RFC6235], which describes anonymization techniques for IP flow data and how to export that anonymized data using the IPFIX protocol 🙈.
- "Flow Selection Techniques" [RFC7014], which describes picking a subset of Flows from all the Flows seen at an Observation Point, the reasons for flow selection, and some specific flow selection techniques 💖.
- "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol" [RFC7015], which describes Aggregated Flow export within the IPFIX Mediator framework and defines an interoperable, implementation-independent method for it 🔥.
This document specifies the IP Flow Information Export (IPFIX) protocol for Mediation, and all Intermediate Processes must comply with it 👑. Some extra specs might be required for each Intermediate Process type, and in that case, the document for that Intermediate Process would apply 🫶.
1.3. Relationship with the IPFIX and PSAMP Protocols
The spec in this document is based on the IPFIX protocol spec [RFC7011]. Everything in [RFC7011] applies unless this document says otherwise 💅.
The Packet Sampling (PSAMP) protocol specs [RFC5476] are based on the IPFIX protocol specs, so the specs here are also valid for PSAMP. That means the method in this document also applies to PSAMP 🌈✨.
2. Terminology ✨
okay so bestie, let's get into the vocab 📚🎀 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 💅 these are the official "how strict is this" words, so pay attention to them fr fr
the IPFIX-specific terms are defined in [RFC7011], like Observation Domain, Flow, Flow Key, Metering Process, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, Template, IPFIX Message, Message Header, Template Record, Data Record, Options Template Record, Set, Data Set, Information Element, Scope, and Transport Session 🦋 the PSAMP-specific terms, like Filtering and Sampling, live in [RFC5476] 🌸
IPFIX Mediation terms about aggregation, like Interval, Aggregated Flow, and Aggregated Function, are defined in [RFC7015] ✨
the IPFIX Mediation terms used here are defined in "IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982] and reused in "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183] 💜 but since both of those are Informational RFCs, the definitions got reproduced and elaborated on right here 🙈
same deal with [RFC6235] 🫶 it's Experimental, so the Anonymization Record, Anonymized Data Record, and Intermediate Anonymization Process terms are reproduced here too 💖
in this document, just like in [RFC7011], [RFC5476], [RFC7015], and [RFC6235], the first letter of each IPFIX-specific and PSAMP-specific term gets capitalized, along with the IPFIX Mediation-specific terms defined here 👑
we call a stream of records carrying flow- or packet-based information a "record stream" 🌈 the records may be encoded as IPFIX Data Records or any other format, no cap 🍓
Transport Session: the Transport Session is specified in [RFC7011] 🧚 in Stream Control Transmission Protocol (SCTP), the Transport Session info is the SCTP association 💅 in TCP and UDP, it corresponds to a 5-tuple:
{Exporter IP address, Collector IP address, Exporter transport port,
Collector transport port, transport protocol}Original Exporter: an Original Exporter is the source a Mediator receives its record stream from 🦋 for simple IPFIX mediation without protocol conversion, this is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed 💖
Original Observation Point: an Observation Point on a Metering Process associated with the Original Exporter ✨ for the Intermediate Aggregation Process on an IPFIX Mediator, the Original Observation Point can be composed of, but not limited to, a (set of) specific Exporter(s), a (set of) specific interface(s) on an Exporter, a (set of) line card(s) on an Exporter, or any combinations of these 🌸
IPFIX Mediation: IPFIX Mediation is the manipulation and conversion of a record stream for subsequent export using the IPFIX protocol 🎀
Template Mapping: a mapping from Template Records and/or Options Template Records received by an IPFIX Mediator to Template Records and/or Options Template Records sent by that IPFIX Mediator 🌈 each entry in a Template Mapping is scoped by incoming or outgoing Transport Session and Observation Domain, same as Templates and Options Templates in the IPFIX Protocol 💜
Anonymization Record: a record that defines the properties of the anonymization applied to a single Information Element within a single Template or Options Template, as in [RFC6235] 🫶
Anonymized Data Record: a Data Record within a Data Set containing at least one Information Element with anonymized values 😭 the Information Element(s) within the Template or Options Template describing this Data Record SHOULD have a corresponding Anonymization Record, as in [RFC6235] 🔥
the following terms describe the architectural entities used by IPFIX Mediation 👑
Intermediate Process: an Intermediate Process takes a record stream as its input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources 💅 it performs some transformations on this stream, based on the content of each record, states kept across multiple records, or other data sources, then passes the transformed record stream as its output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes, all to do IPFIX Mediation 🦋 typically, an Intermediate Process is hosted by an IPFIX Mediator 🌸 alternatively, it may be hosted by an Original Exporter ✨
IPFIX Mediator: an IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation by receiving a record stream from some data sources, hosting one or more Intermediate Processes to transform that stream, and exporting the transformed record stream into IPFIX Messages via an Exporting Process 🎀 in the common case, an IPFIX Mediator receives a record stream from a Collecting Process, but it could also receive one from data sources not encoded using IPFIX, e.g., when converting from the NetFlow V9 protocol [RFC3954] to IPFIX protocol 🌈
Specific Intermediate Processes are described below 💜
Intermediate Conversion Process (as in [RFC6183]): an Intermediate Conversion Process is an Intermediate Process that transforms non-IPFIX into IPFIX, or manages the relation among Templates and states of incoming/outgoing Transport Sessions in the case of transport protocol conversion (e.g., from UDP to SCTP) 🫶
Intermediate Aggregation Process (as in [RFC7015]): an Intermediate Process (IAP), as in [RFC6183], that aggregates records based upon a set of Flow Keys or functions applied to fields from the record 😭
Intermediate Correlation Process (as in [RFC6183]): an Intermediate Correlation Process is an Intermediate Process that adds information to records, noting correlations among them, or generates new records with correlated data from multiple records (e.g., producing bidirectional flow records from unidirectional flow records) 🔥
Intermediate Anonymization Process (as in [RFC6235]): an intermediate process that takes Data Records and transforms them into Anonymized Data Records 👑
Intermediate Selection Process (as in [RFC6183]): an Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria-evaluated record values and passes only those records that match the criteria (e.g., Filtering only records from a given network to a given Collector) 💅
Intermediate Flow Selection Process (as in [RFC7014]): an Intermediate Flow Selection Process is an Intermediate Process, as in [RFC6183], that takes Flow Records as its input and selects a subset of that set as its output 🦋 the Intermediate Flow Selection Process is a more general concept than the Intermediate Selection Process as defined in [RFC6183] 🌸 while an Intermediate Selection Process selects Flow Records from a sequence based upon criteria-evaluated Flow record values and only passes on those Flow Records that match the criteria, an Intermediate Flow Selection Process selects Flow Records using selection criteria applicable to a larger set of Flow characteristics and information ✨
Note: for more info on the difference between the Intermediate Flow Selection Process and the Intermediate Selection Process, see Section 4 in [RFC7014] 🧚
3. Handling IPFIX Message Headers ✨
okay so the IPFIX Message Header that an IPFIX Mediator exports looks exactly like the one IPFIX defines in [RFC7011] 🎀 the only difference is that Export Time and Observation Domain ID can get handled differently at certain Mediators, which I'll flag as we go 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPFIX Message Header formatHere's the rundown on every header field as an IPFIX Mediator exports it 🦋
Version:
Version of IPFIX this Message conforms to 🌸 The value for the current version is 0x000a, which is one more than the version used in the NetFlow services export version 9 [RFC3954]. Iconic glow-up behavior 👑
Length:
Total length of the IPFIX Message, measured in octets, counting both the Message Header and the Set(s) 🧚
Export Time:
The time at which the IPFIX Message Header leaves the IPFIX Mediator, written as seconds since the UNIX epoch of 1 January 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer ⏰
Now the plot twist 🙈 in the specific case of an IPFIX Mediator containing an Intermediate Conversion Process, the IPFIX Mediator MAY use the export time received from the incoming Transport Session. So it's not always locked to its own clock, which is lowkey so cool 💜
Sequence Number:
An incremental sequence counter, modulo 2^32, of all IPFIX Data Records sent in the current stream from the current Observation Domain by the Exporting Process 📈 Each SCTP Stream counts sequence numbers separately, but all messages in a TCP connection or UDP Transport Session are treated as part of the same stream. The Collecting Process can use this value to figure out whether any IPFIX Data Records went missing 👀 And note that Template and Options Template Records do not increase the Sequence Number, so they don't count toward it 🫶
Observation Domain ID:
A 32-bit identifier of the Observation Domain, locally unique to the Exporting Process 🔥 The Exporting Process uses it to tell the Collecting Process which Observation Domain metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device, which is giving organized energy ✨ Collecting Processes can combine the Transport Session with the Observation Domain ID field to separate different export streams coming from the same Exporter 🌈 The Observation Domain ID is set to 0 when no specific Observation Domain ID is relevant to the entire IPFIX Message. Examples are exporting the Exporting Process Statistics, or a hierarchy of Collectors exporting aggregated Data Records 🍓
For the special considerations around Observation Domain management when you pass unmodified templates through an IPFIX Mediator, check out Section 4.1. And if you want guidelines for keeping the original Observation Domain information intact at an IPFIX Mediator, that's Section 5 💖
Okay, now the bits copied over from [RFC7011] that matter here 💅
Template Withdrawals MAY appear interleaved with Template Sets, Options Template Sets, and Data Sets within an IPFIX Message. In this case, the Templates and Template Withdrawals shall be interpreted as taking effect in the order in which they appear in the IPFIX Message.
So the order is the whole vibe 🎀 If an IPFIX Mediator receives an IPFIX Message made of Template Withdrawals and Template Sets, and it forwards that IPFIX Message, it MUST NOT modify the Set order 🙅♀️ And if it receives several IPFIX Messages made of Template Withdrawals and Template Sets and forwards those, it MUST NOT modify the IPFIX Message order either 😭 Keep in mind that the Template Mapping (see Section 4.1) is the authoritative source on whether the Mediator can forward the entire IPFIX Messages as-is, so go check it 🧚♀️
4. Template Management 🌸
How an IPFIX Mediator handles the Templates it gets from the Original Exporter depends entirely on what the Intermediate Process running on that IPFIX Mediator is doing 💅 There are two cases here:
- IPFIX Mediators that pass substantially the same Data Records from the Original Exporter downstream (for example, an Intermediate Selection Process) pass unmodified Templates as described in Section 4.1 ✨ That section covers a Template Mapping needed to make this work in the general case, plus how the received and generated IPFIX Message Withdrawals get correlated 🔗
- IPFIX Mediators that export Data Records substantially changed from the Data Records received from the Original Exporter follow the guidelines in Section 4.2 instead 🦋 In this case the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process, and no Template Mapping is required 🌈
The subsequent subsections deal with specific Template management issues that may come up at IPFIX Mediators, so keep reading bestie 🫶
4.1. Passing Unmodified Templates through an IPFIX Mediator ✨
okay so sometimes an Intermediate Process doesn't touch the (Options) Template Record(s) content at all 💅 A super typical example is an Intermediate Flow Selection Process acting as a distributor. It collects Flow Records from one or more Exporters and, based on the Information Elements, sends each Flow Record to the right Collector 🦋 Picture one single network operation center managing a bunch of universities: a unique IPFIX Collector grabs all the Flow Records for the common infrastructure, but it might be re-exporting specific university Flow Records to the responsible system administrator 🎀
Now the tea 🫖 per [RFC7011], Template IDs are unique per Exporter, per Transport Session, and per Observation Domain. ngl there's no guarantee that for similar Template Records, the Template IDs you get on the incoming Transport Session are the same ones you export on the outgoing Transport Session 😭 so the IPFIX Mediator MUST maintain a Template Mapping made up of related received and exported (Options) Template Records:
- for each received (Options) Template Record: Template Record Information Elements, Template ID, Observation Domain ID, and Transport Session information, metadata scoped to the Template (*)
- for each exported (Options) Template Record: Template Record Information Elements, Template ID, Collector, Observation Domain ID, and Transport Session information metadata scoped to the Template (*)
(*) The "metadata scoped to the Template" encompasses the metadata, that are scoped to the Template, and that help to determine the semantics of the Template Record. Note that these metadata are typically sent in Data Records described by an Options Template. An example is the flowKeyIndicator. An IPFIX Mediator could potentially receive two different Template IDs, from the same Exporter, with the same Information Elements, but with a different set of Flow Keys (indicated by the flowKeyIndicator in an Options Template Record). Another example is the combination of anonymizationFlags and anonymizationTechnique [RFC6235]). This metadata information must be present in the Template Mapping, to stress that the two Template Record semantics are different.
This part is giving main character energy 👑 If an IPFIX Mediator receives an IPFIX Withdrawal Message for a (Options) Template Record that is not used anymore in any other Template Mappings, the IPFIX Mediator SHOULD export the appropriate IPFIX Withdrawal Message(s) on the outgoing Transport Session and remove the corresponding entry in the Template Mapping.
And if a (Options) Template Record is not used anymore in an outgoing Transport Session, it MUST be withdrawn with an IPFIX Template Withdrawal Message on that specific outgoing Transport Session, and its entry, MUST be removed from the Template Mapping. 🧹
Also, if an incoming or outgoing Transport Session is gracefully shut down or reset, the (Options) Template Records corresponding to that Transport Session MUST be removed from the Template Mapping. bestie, that's a whole cleanup crew 🧚
Okay, the example time 🌸 Figure 2 shows an Intermediate Flow Selection Process redistributing Data Records to Collectors based on customer networks, i.e., the Route Distinguisher (RD). Here the Template Record received from Exporter #1 is reused towards Collector #1, Collector #2, and Collector #3, for customer #1, customer #2, and customer #3, respectively. In this example, the outgoing Template Records exported to the different Collectors are identical. As a reminder that Template ID uniqueness is local to the Transport Session and Observation Domain that generated the Template ID, a mix of Template ID 256 and 257 has been used 🍓
.---------.
Tmpl. | |
ID .---->|Collector|<==>Customer 1
256 | | #1 |
| | |
RD=100:1 '---------'
.--------. .--------. |
| | Tmpl. | |----'
| | Id | | .---------.
| | 258 | | RD=100:2 | |
| IPFIX |------->| IPFIX |--------->|Collector|<==>Customer 2
|Exporter| |Mediator| Tmpl. | #2 |
| #1 | | | ID 257 | |
| | | | '---------'
| | | |----.
'--------' '--------' |
RD=100:3
| .---------.
Tmpl. | | |
ID '---->|Collector|<==>Customer 3
257 | #3 |
| |
'---------'Figure 2: Intermediate Flow Selection Process Example
Figure 3 shows the Template Mapping for the system from Figure 2 🦋
+-----------------------------------------------------------------+
| Template Entry A: |
| Incoming Transport Session information (from Exporter#1): |
| Source IP: <Exporter#1 export IP address> |
| Destination IP: <IPFIX Mediator IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 258 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry B: |
| Outgoing Transport Session information (to Collector#1): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#1 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 256 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry C: |
| Outgoing Transport Session information (to Collector#2): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#2 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
| |
| Template Entry D: |
| Outgoing Transport Session information (to Collector#3): |
| Source IP: <IPFIX Mediator IP address> |
| Destination IP: <IPFIX Collector#3 IP address> |
| Protocol: SCTP |
| Source Port: <source port> |
| Destination Port: 4739 (IPFIX) |
| Observation Domain ID: <Observation Domain ID> |
| Template ID: 257 |
| Metadata scoped to the Template : <not applicable in this case> |
+-----------------------------------------------------------------+Figure 3: Template Mapping Example: Templates
The Template Mapping for Figure 3 is shown in Figure 4 🌈
Template Entry A <----> Template Entry B
Template Entry A <----> Template Entry C
Template Entry A <----> Template Entry DFigure 4: Template Mapping Example: Mappings
Or, if you want it leaner, the Template Mapping may be optimized as in Figure 5 ✨
+--> Template Entry B
|
Template Entry A <--+--> Template Entry C
|
+--> Template Entry DFigure 5: Template Mapping Example 2: Mappings
Quick note 💜 all of these examples use Transport Sessions based on SCTP, just as simplified use cases. The transport protocol would be important though, in situations like an Intermediate Conversion Process doing transport protocol conversion 🔥
4.1.1. Template Mapping and Information Element Ordering 🧩
okay so picture this: multiple Original Exporters each send an (Options) Template Record to one IPFIX Mediator, and the records have the same Information Elements, just in a different order 👀. Should the Mediator keep one Export Template Record (Figure 6) or keep multiple independent Template Records (Figure 7) before re-exporting to the Collector? bestie, this is a whole decision 💅
Template Entry A <--+
|
Template Entry B <--+--> Template Entry D
|
Template Entry C <--+
Figure 6: Template Mapping and Ordering:
A single Export Template Record
Template Entry A <--+--> Template Entry D
Template Entry B <--+--> Template Entry E
Template Entry C <--+--> Template Entry F
Figure 7: Template Mapping and Ordering:
Multiple Export Template Recordsso the answer depends on whether the order of the Information Elements implies some specific semantic 🤔. One of the guiding principles in IPFIX protocol specs is that the meaning of one Information Element doesn't depend on the value of any other Information Element. BUT there's one noticeable exception, and [RFC7011] spills the tea on it:
Multiple Scope Fields MAY be present in the Options Template Record, in which case the composite scope is the combination of the scopes. For example, if the two scopes are meteringProcessId and templateId, the combined scope is this Template for this Metering Process. If a different order of Scope Fields would result in a Record having a different semantic meaning, then the order of Scope Fields MUST be preserved by the Exporting Process. For example, in the context of PSAMP [RFC5476], if the first scope defines the filtering function, while the second scope defines the sampling function, the order of the scope is important. Applying the sampling function first, followed by the filtering function, would lead to potentially different Data Records than applying the filtering function first, followed by the sampling function.
so scope field order can totally change what a record means 😭. That's the whole vibe.
if an IPFIX Mediator gets Template Records from multiple Exporters with identical Information Elements that are just ordered differently, it SHOULD consider those Template Records as identical, subject to metadata information in the associated Options Template (for example, the Flow Key Options Template, see Section 10.2) ✨.
if an IPFIX Mediator gets Options Template Records from multiple Exporters with identical and ordered Information Elements in the Scope fields, and with identical Information Elements that are ordered differently in the non-Scope fields, it SHOULD consider those Template Records as identical 🫶.
but if an IPFIX Mediator gets Options Template Records from multiple Exporters with identical Information Elements in the Scope field that are ordered differently, it MUST consider those Template Records as semantically different. no shade, just facts 💀.
4.2. Creating New Templates at an IPFIX Mediator 🛠️
for other Intermediate Processes, the IPFIX Mediator generates new (Options) Template Records as a result of the Intermediate Process. slay, it's making its own templates now.
in these cases the IPFIX Mediator doesn't need to maintain a Template Mapping, because it generates its own series of (Options) Template Records. BUT some special cases still might need a Template Mapping 👀. Picture this: the IPFIX Mediator generates new (Options) Template Records based on what it receives from the Exporter(s), depending on the Intermediate Process function. For example, an Intermediate Anonymization process that performs black-marker anonymization [RFC6235] on certain Information Elements. In that case, it's important to keep the correlation between the received (Options) Template Records and the derived ones in the Template Mapping. These Template Mappings would be kept as in Section 4.1, except that the exported Template would not be identical to the received Template 🎀.
similar to Exporting Processes in any Exporter, an IPFIX Mediator MAY use the technique for reducing redundancy in IPFIX described in [RFC5473]. (sorry, I know the caps are a lot, but that's the one word that's giving real permission here 🙈)
4.3. Handling Unknown Information Elements 🫥
depending on application requirements, Mediators that do not generate new Records SHOULD re-export values for unknown Information Elements, meaning ones the Mediator doesn't have information about in terms of Information Element data type and semantics. HOWEVER, there may be presence or ordering dependencies among those unknown Information Elements, so the Mediator MUST NOT omit fields from such re-exported Records or reorder any fields within the Records 😤.
Mediators that generate new Records, as in Section 4.2, MUST ignore values of Information Elements they do not understand. And if a Mediator passes values of Information Elements it does not understand (for example, when re-exporting Flow Records), it MUST pass them in the order in which they were originally received 🧚.
in any case, Mediators handling unknown Information Elements SHOULD log this fact, because mediating records with unknown values is likely to have unintended consequences 💀📝.
5. Preserving Original Observation Point Information 🔭
depending on the use case, the Collector in an Exporter/IPFIX Mediator/Collector structure (for example, tiered Mediators) may need to receive information about the Original Observation Point(s). Otherwise, it may wrongly conclude that the IPFIX Device exporting the Flow Records (aka the IPFIX Mediator) directly observed the packets that generated the Flow Records 🙃. Two new Information Elements handle this: originalExporterIPv4Address and originalExporterIPv6Address. Practically speaking, the Original Exporters will not be exporting these Information Elements, so the Intermediate Process will report the Original Observation Point(s) to the best of its knowledge. Also, the Configuration Data Model for IPFIX and PSAMP [RFC6728] may report the Original Exporter information out of band 🫶.
in the IPFIX Mediator, the Observation Point(s) may be represented by:
- A single Original Exporter (represented by the
originalExporterIPv4AddressororiginalExporterIPv6AddressInformation Elements). - A list of Original Exporters (represented by a list of
originalExporterIPv4AddressororiginalExporterIPv6AddressInformation Elements). - Any combination or list of Information Elements representing Observation Points. For example:
- A list of Original Exporter interfaces (represented by the
originalExporterIPv4AddressororiginalExporterIPv6Address, theingressInterface, and/oregressInterfaceInformation Elements, respectively). - A list of Original Exporter line cards (represented by the
originalExporterIPv4Address,originalExporterIPv6Address, orlineCardIdInformation Elements, respectively).
- A list of Original Exporter interfaces (represented by the
some Information Elements characterizing the Observation Point may be added too. For example, the flowDirection Information Element specifies the direction of the observation, so it characterizes the Observation Point 🧭. Any combination of the above is possible. Here's an example of an Original Observation Point for an Intermediate Aggregation Process in Figure 8 🍓:
exporterIPv4Address 192.0.2.1
exporterIPv4Address 192.0.2.2,
interface ethernet 0, direction ingress
interface ethernet 1, direction ingress
interface serial 1, direction egress
interface serial 2, direction egress
exporterIPv4Address 192.0.2.3,
lineCardId 1, direction ingress
Figure 8: Complex Observation Point Definition Examplea Mediator MAY export such complex Original Observation Point information, depending on application requirements. If it does, the Mediator MUST use [RFC6313] to do so, as described below 📦.
the most generic way to export the Original Observation Point is to use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking the previous example, the encoding in Figure 9 can be used 🌈.
Template Record 257: exporterIPv4Address
Template Record 258: exporterIPv4Address,
basicList of ingressInterface, flowDirection
Template Record 259: exporterIPv4Address, lineCardId, flowDirection
Figure 9: Complex Observation Point Definition Example: Templatesthe Original Observation Point is modeled with the Data Records corresponding to either Template Record 1, Template Record 2, or Template Record 3, but not more than one of these ("exactlyOneOf" semantic). This implies that the Flow was observed at exactly one of the Observation Points reported 🎯.
when an IPFIX Mediator receives Flow Records containing the Original Observation Point Information Element (originalExporterIPv4Address or originalExporterIPv6Address), the IPFIX Mediator SHOULD NOT modify its value(s) when composing new Flow Records in the general case. The known exceptions are anonymization per Section 7.2.4 of [RFC6235] and an Intermediate Correlation Process rewriting addresses across NAT. In other words, the Original Observation Point should not be replaced with the IPFIX Mediator Observation Point. The daisy chain of (Exporter, Observation Point) pairs, representing the path the Flow Records took from the Exporter to the top Collector in the Exporter/IPFIX Mediator(s)/Collector structure model, is out of scope for this specification 🔗.
the following subsections describe Information Elements for reporting Original Exporter addresses as seen by the Collecting Process. Note they may be subject to network address translation upstream, so see [NAT-LOGGING] for more on logging in this situation 🙈.
5.1. originalExporterIPv4Address Information Element 🌸
Name: originalExporterIPv4Address
Description: This is the IPv4 address used by the Exporting Process on an Original Exporter, as seen by the Collecting Process on an IPFIX Mediator. It's used to give a downstream Collector info about the Original Observation Points 💖.
Data Type: ipv4Address
ElementId: 403
5.2. originalExporterIPv6Address Information Element 🦋
Name: originalExporterIPv6Address
Description: This is the IPv6 address used by the Exporting Process on an Original Exporter, as seen by the Collecting Process on an IPFIX Mediator. It's used to give a downstream Collector info about the Original Observation Points 💜.
Data Type: ipv6Address
ElementId: 404
6. Managing Observation Domain IDs 🎀
Okay bestie, so the Observation Domain ID of any IPFIX Message with Flow Records that are relevant to no particular Observation Domain, or to multiple Observation Domains, MUST have an Observation Domain ID of 0 🌸
IPFIX Mediators that don't change (Options) Template Records MUST maintain a Template Mapping (see Section 4.1) so the combo of Observation Domain IDs and Template IDs doesn't collide on export. Main character energy, no notes 💅
For IPFIX Mediators that export New (Options) Template Records (see Section 4.2), there are two options for managing Observation Domain IDs 🦋
Option one is the simplest: you fully decouple the exported Observation Domain IDs from the received ones. The IPFIX Mediator gets its own set of Observation Domain(s), totally independent of the Original Exporters' Observation Domain(s) 🧚
Option two is to provide or maintain a Template Mapping for received (Options) Template Records and exported inferred (Options) Template Records, along with the right Observation Domain IDs per Transport Session. That keeps the combo of Observation Domain IDs and Template IDs from colliding on export 💜
Sometimes the IPFIX Message Header can't hold one consistent Observation Domain for the whole IPFIX Message, but the Flow Records leaving the IPFIX Mediator should still carry the Original Exporter's Observation Domain anyway. In that case the (Options) Template Record must contain the originalObservationDomainId Information Element, which is specified in Section 6.1. When an IPFIX Mediator receives Flow Records containing the originalObservationDomainId Information Element, it MUST NOT modify its value(s) when composing new Flow Records with that element. Do not touch it, bestie 🙈
6.1. originalObservationDomainId Information Element ✨
Name: originalObservationDomainId
Description: The Observation Domain ID reported by the Exporting
Process on an Original Exporter, as seen by the Collecting Process
on an IPFIX Mediator. Used to provide information about the
Original Observation Domain to a downstream Collector. When
cascading through multiple Mediators, this identifies the initial
Observation Domain in the cascade.
Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 4057. Timing Considerations 🕰️
Okay so the IPFIX Message Header Export Time field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message leaves the IPFIX Mediator. BUT, if the IPFIX Mediator has an Intermediate Conversion Process, it MAY use the export time it received from the incoming Transport Session. Plot twist 🌈
It is RECOMMENDED that IPFIX Mediators handle time with absolute timestamps wherever possible (e.g., flowStartSeconds, flowStartMilliseconds, or flowStartNanoseconds). These are specified relative to the UNIX epoch (00:00 UTC 1 Jan 1970) [POSIX.1]. Try to avoid relative timestamps (e.g., flowStartSysUpTime or flowStartDeltaMicroseconds), which are specified relative to protocol structures like system initialization or message export time 🙅♀️
Relative timestamps are a mess, and here's why. First, they need constant translation, because the system initialization time of an intermediate system and the export time of an intermediate message keep changing across mediation operations. Second, they bring range problems. For example, when using the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [IANA-IPFIX], the Data Record must be exported within a maximum of 71 minutes after it's created. Otherwise the 32-bit counter can't hold the flow start time offset. Those time constraints might clash with what some Intermediate Processes need for their applications 😭
Intermediate Processes MUST NOT assume that received records appear in flowStartTime, flowEndTime, or observationTime order. An Intermediate Process that handles timing information (e.g., an Intermediate Aggregation Process) MAY ignore records that are significantly out of order, so it can meet application-specific state and latency requirements, but it SHOULD report that records were dropped 💀
When an Intermediate Process aggregates information from different Flow Records, the timestamps on exported records SHOULD be the minimum of the start times and the maximum of the end times in the general case. However, if the Flow Records don't overlap (i.e., there's a time gap between them), the report may be inaccurate. The IPFIX Mediator is only reporting what it knows, based on the info it has, and there may not have been any data to observe during the gap. Then again, if the timestamps overlap, there's a risk of double-accounting: different Observation Points may have observed the same traffic at the same time. Figuring out the precise rules for applying Flow Record timestamps at IPFIX Mediators in every situation is out of scope for this document 🫶
Note that [RFC7015] has more specs for handling timestamps at an Intermediate Aggregation Process 📚
8. Transport Considerations 🚚
SCTP [RFC4960] using the Partially Reliable SCTP (PR-SCTP) extension specified in [RFC3758] MUST be implemented by all compliant IPFIX Mediator implementations. TCP [RFC0793] MAY also be implemented by compliant IPFIX Mediator implementations. UDP [RFC0768] MAY also be implemented by compliant IPFIX Mediator implementations. The transport-specific considerations for IPFIX Exporters in Sections 8.3, 8.4, 9.1, 9.2, and 10 of [RFC7011] apply to IPFIX Mediators as well 🦋
SCTP SHOULD be used in deployments where IPFIX Mediators and Collectors talk over links that are prone to congestion. SCTP can provide any degree of reliability you need 👑 TCP MAY be used in those deployments too, but SCTP is preferred because it can limit back pressure on Exporters and has a message-oriented, stream-oriented design 💖 UDP MAY be used, though it's not congestion-aware. In that case, though, the IPFIX traffic between the IPFIX Mediator and Collector MUST run in an environment where IPFIX traffic has been provisioned for and/or separated from non-IPFIX traffic, whether physically or virtually. No skipping this one, bestie 🚨
9. Collecting Process Considerations 📥
Any Collecting Process compliant with [RFC7011] can receive IPFIX Messages from an IPFIX Mediator. If the IPFIX Mediator uses IPFIX Structured Data [RFC6313] to export Original Exporter Information (as in Section 5), the Collecting Process MUST support [RFC6313] 🧠
10. Specific Reporting Requirements 📊
IPFIX provides Options Templates for reporting the reliability of processes within the IPFIX Architecture. Since each Mediator includes at least one IPFIX Exporting Process, they MAY use the Exporting Process Reliability Statistics Options Template, as specified in [RFC7011] ✨
Analogous to the Metering Process Reliability Statistics Options Template (also specified in [RFC7011]), Mediators MAY implement the Intermediate Process Reliability Statistics Options Template, specified in Sections 10.1, 10.3, and 10.4 define Information Elements used by this Options Template. 🌷
The Flow Keys Options Template, as specified in [RFC7011], may require special handling at an IPFIX Mediator, as described in Section 10.2 🔑
Plus, each Intermediate Process may have its own reporting requirements (e.g., Anonymization Records as in [RFC6235], or the Aggregation Counter Distribution Options Template as in [RFC7015]). These SHOULD be implemented as necessary, as described in the specification for each Intermediate Process. Each process has its own rules, so check them out 🍓
10.1. Intermediate Process Reliability Statistics Options Template 📊
okay so the Intermediate Process Statistics Options Template is the blueprint for a Data Record that reports Intermediate Process statistics ✨ It SHOULD contain the following Information Elements. intermediateProcessId lives in Section 10.3 and ignoredDataRecordTotalCount lives in Section 10.4 💖
+-----------------------------+-------------------------------------+
| IE | Description |
+-----------------------------+-------------------------------------+
| observationDomainId [scope] | An identifier of the Observation |
| | Domain (of messages exported by |
| | this Mediator), locally unique to |
| | the Intermediate Process, to which |
| | this statistics record applies. |
| | ---------------------------------- |
| intermediateProcessId | An identifier for the Intermediate |
| [scope] | Process to which this statistics |
| | record applies. |
| | ---------------------------------- |
| ignoredDataRecordTotalCount | The total number of Data Records |
| | received but not processed by the |
| | Intermediate Process. |
| | ---------------------------------- |
| time first record ignored | The timestamp of the first record |
| | that was ignored by the |
| | Intermediate Process. For Data |
| | Records containing timestamp |
| | ranges, this SHOULD be taken from |
| | the start timestamp of the range; |
| | for data records containing no |
| | timing information, this SHOULD be |
| | taken from the Export Time in the |
| | message header of the IPFIX Message |
| | that contains it. For this |
| | timestamp, any of the following |
| | timestamp can be used: |
| | observationTimeSeconds, |
| | observationTimeMilliseconds, |
| | observationTimeMicroseconds, or |
| | observationTimeNanoseconds. |
+-----------------------------+-------------------------------------+
+-----------------------------+-------------------------------------+
| IE | Description |
+-----------------------------+-------------------------------------+
| time last record ignored | The timestamp of the last record |
| | that was ignored by the |
| | Intermediate Process. For Data |
| | Records containing timestamp |
| | ranges, this SHOULD be taken from |
| | the end timestamp of the range; for |
| | data records containing no timing |
| | information, this SHOULD be taken |
| | from the Export Time in the message |
| | header of the containing IPFIX |
| | Message. For this timestamp, any |
| | of the following timestamp can be |
| | used: observationTimeSeconds, |
| | observationTimeMilliseconds, |
| | observationTimeMicroseconds, or |
| | observationTimeNanoseconds. |
+-----------------------------+-------------------------------------+10.2. Flow Key Options Template 🔑
okay the Flow Keys Options Template is the one that describes a Data Record for reporting the Flow Keys of reported Flows 🌸 A Flow Keys Data Record extends a particular Template Record, the one referenced by its templateId identifier. You extend that Template Record by saying which of the Information Elements in the matching Data Records describe the Flow properties that act as Flow Keys for the reported Flow 💅 This Options Template is defined in Section 4.4 of [RFC7011] and SHOULD be used by Mediators for export as defined there ✨
When an Intermediate Process exports Data Records with different Flow Keys from the ones it received from the Original Exporter, and the Original Exporter had sent a Flow Keys Options record to the IPFIX Mediator, the IPFIX Mediator MUST export a Flow Keys Options record defining the new set of Flow Keys 🫶
10.3. intermediateProcessId Information Element 🧚
Name: intermediateProcessId
Data Type: unsigned32
Data Type Semantics: identifier
ElementId: 406so this one is an identifier for an Intermediate Process that's unique per IPFIX Device 🦋 Typically it's used for limiting the scope of other Information Elements. Process identifiers can be assigned dynamically, which means an Intermediate Process might get restarted with a different ID 💜
10.4. ignoredDataRecordTotalCount Information Element 📉
Name: ignoredDataRecordTotalCount
Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 407this is the total number of received Data Records that the Intermediate Process didn't process since it was (re-)initialized 🌈 It only counts the Data Records that weren't examined or otherwise handled because of resource constraints. It does NOT count Data Records that were examined or handled but just didn't end up contributing to any exported Data Record because of the operations the Intermediate Process performed 🙈
11. Operations and Management Considerations 🛠️
ngl this section is the "be careful, bestie" part ⭐ Using IPFIX Mediators to combine information from multiple Original Exporters requires a consistent configuration of the Metering Processes behind those Original Exporters. The exact details of that consistency depend on each Intermediate Process 💅 Configuration consistency should be verified out of band, using the MIB modules ([RFC6615] and [RFC6727]) or the Configuration Data Model for IPFIX and PSAMP [RFC6728] 🎀
From an operational point of view, this specification gives you all the info you need to set up IPFIX Mediators and the Collectors that sit behind them ✨ When you're configuring the IPFIX Mediators, you have to include all the relevant information so the Collectors can work out the precise semantics of the Data Records. That's what the Template Mapping specifications in Section 4.1 are for 🧠 Also, if something isn't configured carefully somewhere in the processing chain, the collected IPFIX data can get interpreted wrongly, and the applications using it can produce results that aren't operationally meaningful 💀
12. Security Considerations 🔐
this one is serious, bestie, so listen up 😭 Because IPFIX Mediators act as both IPFIX Collecting Processes and Exporting Processes, the Security Considerations for the IPFIX Protocol [RFC7011] also apply to them 💖 The Security Considerations for IPFIX Files [RFC5655] apply to any IPFIX Mediator that writes IPFIX Files or uses them for internal storage. There are also a few specific considerations that IPFIX Mediator implementations must take into account 👑
By design, IPFIX Mediators are "men in the middle" 🕵️♀️ They step in between an Original Exporter (or another upstream IPFIX Mediator) and a downstream Collecting Process. That has two big implications: it affects how much confidentiality you get across an IPFIX Mediator, and it affects your ability to protect data integrity and Original Exporter authenticity across one too. These are covered in more detail in the Security Considerations for IPFIX Mediators in [RFC6183] 🫣
Note that IPFIX Mediators can use the exporterCertificate and collectorCertificate Information Elements defined in [RFC5655] to export information about X.509 identities in upstream TLS-protected Transport Sessions, as described in Section 9.3 of [RFC6183]. BUT this mechanism can't give you true end-to-end assertions about a chain of IPFIX Mediators, because any IPFIX Mediator in the chain can just falsify the information about the upstream Transport Sessions 🚨 If it matters to know about the chain of mediation, you have to figure that out out of band. Also, an Exporting Process has no in-band way to tell whether a given Collecting Process will act as a Mediator 😬 Trust placed in Collecting Processes is absolute, so be careful when exporting IPFIX Messages between Exporting Processes and Collecting Processes controlled by different entities 🥹
13. IANA Considerations 📚
this document specifies new IPFIX Information Elements. They are originalExporterIPv4Address in Section 5.1, originalExporterIPv6Address in Section 5.2, originalObservationDomainId in Section 6.1, intermediateProcessId in Section 10.3, and ignoredDataRecordTotalCount in Section 10.4 🎀 All of them have been added to the IPFIX Information Element registry [IANA-IPFIX] 🌸
14. Acknowledgments 🫶
the authors want to thank the IPFIX contributors, especially Paul Aitken (THE ultimate IPFIX document reviewer) and Andrew Feren for their thorough reviews 👑 Thank you to Nevil Brownlee and Juergen Quittek for shepherding this document and chairing the IPFIX Working Group. And thanks to Rahul Patel, Meral Shirazipour, and Juergen Schoenwaelder for their feedback and comments 💜 This work is materially supported by the European Union Seventh Framework Programme under grant agreements 257315 (DEMONS) and 318627 (mPlane) 🌈
15. References ✨
15.1. Normative References
okay bestie, these are the docs the spec leans on so hard it literally can't stand without them 💅 every one of these is required reading to really get IPFIX, so no skipping 🫶
- [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. 🦋
- [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🌸
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
- [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. ✨
- [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 💜
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🎀
- [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009. 🍓
- [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011. 🧚
- [RFC6615] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 2012. ⭐
- [RFC6727] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", RFC 6727, October 2012. 🌈
- [RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols", RFC 6728, October 2012. 🔥
- [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013. 💖
- [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013. 🙈
- [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, September 2013. 🫶
- [RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, September 2013. 😭
- [RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, September 2013. 💅
15.2. Informative References
these ones are the background reading 🧠 super useful for context, but the spec doesn't need them to function, so they're the "ooh tell me more" section of the reading list 🌸
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. ✨
- [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. 🦋
- [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. 🎀
- [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. 💜
- [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 🍓
- [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. 🧚
- [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009. ⭐
- [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010. 🌈
- [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011. 🔥
- [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011. 💖
- [NAT-LOGGING] Sivakumar, S. and R. Penno, "IPFIX Information Elements for logging NAT Events", Work in Progress, November 2013. 🙈
- [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
<http://www.iana.org/assignments/ipfix>. 🫶 - [POSIX.1] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface", IEEE 1003.1-2008, 2008. 😭
the [NAT-LOGGING] one is still a Work in Progress, so it's not a finished RFC yet, bestie 👀
Authors' Addresses
these are the three legends who wrote it, and yes, you can slide into their emails 💌 🦋
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.comAtsushi Kobayashi
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3978
EMail: akoba@nttv6.netBrian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.chthat's the whole spec, babe! 🌈👑 thank you for reading all of it with me 🫶💖
📦 where this page comes from
- ietf: rfc7119 2014-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms