RFC 7013

Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements

📅 published September 2013, from ietf

RFC 7013: Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements 🎀

Part 1 of 7 🌸

Okay bestie, let's start with the basics. This is RFC 7013, filed under BCP 184, which means it's a Best Current Practice ✨. It was written by B. Trammell from ETH Zurich and B. Claise from Cisco Systems, Inc. It was published in September 2013, and its ISSN is 2070-1721. It's an IETF document, so it's a product of the Internet Engineering Task Force. It's basically the rulebook for how to write definitions for new IPFIX Information Elements 💅

Abstract

So the abstract says this doc gives guidelines for writing definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol 🦋. It shows you the right conventions for registering those Information Elements in the IANA IPFIX Information Element registry, and it gives expert reviewers a checklist for evaluating new registrations 💜.

Status of This Memo

This memo documents an Internet Best Current Practice 🌈.

It's a product of the 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) 👑. If you want more info on BCPs, check out Section 2 of RFC 5741 🧚.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7013 🍓.

Copyright (c) 2013 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, which you can find at http://trustee.ietf.org/license-info and which are in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🫶. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License 💀.

Table of Contents

   1. Introduction ....................................................3
      1.1. Intended Audience and Usage ................................3
      1.2. Overview of Relevant IPFIX Documents .......................4
   2. Terminology .....................................................4
   3. How to Apply IPFIX ..............................................5
   4. Defining New Information Elements ...............................6
      4.1. Information Element Naming .................................7
      4.2. Information Element Data Types .............................7
      4.3. Information Element Numbering ..............................8
      4.4. Ancillary Information Element Properties ...................9
      4.5. Internal Structure in Information Elements .................9
      4.6. Information Element Multiplicity ..........................10
      4.7. Enumerated Values and Subregistries .......................11
      4.8. Reversibility as per RFC 5103 .............................11
      4.9. Avoiding Bad Ideas in Information Element Design ..........11
   5. The Information Element Life Cycle .............................13
      5.1. The Process for Review by the IE-DOCTORS ..................13
      5.2. Revising Information Elements .............................14
      5.3. Deprecating Information Elements ..........................15
   6. When Not to Define New Information Elements ....................16
      6.1. Maximizing Reuse of Existing Information Elements .........16
      6.2. Applying Enterprise-Specific Information Elements .........18
   7. Information Element Definition Checklist .......................18
   8. Applying IPFIX to Non-Flow Applications ........................21
   9. Writing Internet-Drafts for IPFIX Applications .................21
      9.1. Example Information Element Definition ....................22
      9.2. Defining Recommended Templates ............................22
  10. A Textual Format for Specifying Information Elements
       and Templates .................................................23
      10.1. Information Element Specifiers ...........................24
      10.2. Specifying Templates .....................................26
      10.3. Specifying IPFIX Structured Data .........................27
  11. Security Considerations .......................................27
  12. Acknowledgments ...............................................28
  13. References ....................................................29
      13.1. Normative References .....................................29
      13.2. Informative References ...................................29
   Appendix A. Example Information Element Definitions ...............31
     A.1. sipResponseStatus ..........................................31
     A.2. duplicatePacketDeltaCount ..................................31
     A.3. ambientTemperature .........................................32

1. Introduction ✨

This doc gives you guidelines for defining new IPFIX Information Elements beyond the ones already in the IANA IPFIX Information Element Registry [IANA-IPFIX] 🦋. IPFIX export data is self-describing, so defining new Information Elements is often enough to apply IPFIX to brand new network measurement and management use cases. Iconic, honestly 💅.

The goal is to help experts apply IPFIX to new areas. That includes experts in an IETF Working Group or Area Directorate, people in the wider IETF community, and folks from organizations outside the IETF who care about the technical details of the protocol or application being measured or managed with IPFIX 🌈. This expansion happens in consultation with IPFIX experts informally called IE-DOCTORS 🩺. The doc gives guidance both to people defining new Information Elements and to the IE-DOCTORS reviewing them 🫶.

Basically, this doc boils down to two meta-guidelines: (1) "define new Information Elements that look like existing Information Elements" and (2) "don't define Information Elements unless you need to" 💖. Main character rules, no cap 👑.

1.1. Intended Audience and Usage

This doc is written for two different audiences 🎀. If you're defining new Information Elements, it gives you specifications and best practices for deciding which Information Elements an existing or new application needs. It also gives instructions for writing their definitions, and info on the supporting documentation the new application needs, which can go all the way up to publishing one or more RFCs describing it 📜. If you're an IPFIX expert appointed as an IE-DOCTOR, or IANA staff changing the IANA IPFIX Information Element Registry [IANA-IPFIX], the doc sets out acceptance criteria you should use to evaluate the proposed Information Elements 🔍.

This doc is not meant to guide changes to the IPFIX protocol itself, like new export mechanisms, data types, or anything similar. Those should go through Standards Track RFCs within the IPFIX Working Group 🚫.

This doc, together with [RFC7012], defines the procedures for managing the IANA IPFIX Information Element Registry [IANA-IPFIX] 📋. The practices here are meant to guide experts when they review additions or changes to Information Elements in the registry under Expert Review (as defined in [RFC5226]) 💅.

1.2. Overview of Relevant IPFIX Documents

[RFC7011] defines the IPFIX protocol, the IPFIX-specific terminology this doc uses, and the data type encodings for each data type IPFIX supports 🧚.

[RFC7012] defines the basis of the IPFIX Information Model and points to [IANA-IPFIX] for the specific Information Element definitions. It says new Information Elements may be added to the Information Model based on Expert Review. It also hands off the appointment of experts to an IESG Area Director, and sends you to this doc for the details of the extension process 👑. This doc is meant to further codify the best practices those experts should follow, so the process goes faster ⭐.

[RFC5103] defines a method for exporting bidirectional Flow information using IPFIX. You should follow this doc when extending IPFIX to represent information about bidirectional network interactions in general 🦋. New Information Elements should also be annotated for their reversibility, or lack of it, as described in this doc 🔁.

[RFC5610] defines a method for exporting information about Information Elements inline within IPFIX. In doing so, it clearly sets out a group of restrictions, which are implied in [RFC7011] and [RFC7012], on how data types and semantics can be used 🚨. These restrictions must be observed when defining new Information Elements, as in Section 4.4 💜.

2. Terminology 🌸

Capitalized terms used in this doc that are defined in the Terminology section of [RFC7011] should be interpreted as defined there 🎀.

An "application", as this doc uses the word, means a candidate protocol, task, or domain that IPFIX export, collection, and/or storage gets applied to 🌈. By that definition, the IPFIX applicability statement [RFC5472] defined the first IPFIX applications. Packet Sampling (PSAMP) [RFC5476] was the first new IPFIX application published after the IPFIX protocol itself 🧚.

"IANA IE registry", as this doc uses it unless noted otherwise, refers to the IANA IPFIX Information Element Registry [IANA-IPFIX] 💖.

3. How to Apply IPFIX ✨

okay so, IPFIX was originally cooked up for exporting IP Flow information 🌊, but the message format, the template mechanism, and the data model turned out to be useful for a whole bunch of other network management situations 💅. Besides Flow information export (its main gig) and packet information export as specified by PSAMP [RFC5476], any application with the following characteristics is a good candidate for an IPFIX application 🦋:

  • The application's data Flow is fundamentally unidirectional. IPFIX is a "push" protocol, so it only supports exporting information from a sender (an Exporting Process) to a receiver (a Collecting Process). Request-response interactions are not supported by IPFIX 🙈.
  • The application handles discrete event information, or information to be periodically reported. IPFIX is particularly well suited to representing events, which can be scoped in time ⏰.
  • The application handles information about network entities. IPFIX's information model is network-oriented, so network management applications have lots of chances to reuse the information model 🫶.
  • The application requires a small number of arrangements of data structures relative to the number of records it handles. The template-driven self-description mechanism used by IPFIX is really good at handling large volumes of identically structured data, compared to representations that define structure inline with data (such as XML) 💜.

Most applications meeting these criteria can be supported over IPFIX 🎀. Once you've decided IPFIX is a good fit, the next step is figuring out which Information Elements you need to represent the information your application requires. Especially for network-centric applications, the IANA IE registry may already have all the Information Elements you need (see Section 6.1 for guidelines on maximizing Information Element reuse). If that's the case, no work within the IETF is necessary: just define Templates and start exporting 🚀.

It's expected, though, that most applications will be able to reuse some existing Information Elements but may need to define a few additional ones to cover all their requirements 🌸. In that case, see Section 4 for best practices to follow when defining Information Elements 📝.

Optionally, a Working Group or individual contributor may choose to write an Internet-Draft for publication as an RFC, detailing the new IPFIX application 🌈. Such an RFC should contain discussion of the new application, the Information Element definitions as in Section 4, as well as suggested Templates and examples of using those Templates within the new application as in Section 9.2. Section 10 defines a compact textual Information Element notation to be used in describing these suggested Templates and/or the use of IPFIX Structured Data [RFC6313] within the new application ✨.

4. Defining New Information Elements 👑

In many cases, a new application will require nothing more than a new Information Element (or a set of them) to be exportable using IPFIX 🧚. An Information Element meeting the following criteria, as evaluated by the IE-DOCTORS, is eligible for inclusion in the IANA IE registry 💖:

  • The Information Element must be unique within the registry, and its description must represent a substantially different meaning from that of any existing Information Element. An existing Information Element that can be reused for a given purpose should be reused 🔥.
  • The Information Element should contain as little internal structure as possible. Instead of representing complex information by overlaying internal structure on a simple data type such as octetArray, that information should be represented with multiple simple Information Elements to be exported in parallel or using IPFIX Structured Data [RFC6313], as in Section 4.5. The internal structure of a proposed IE may be evaluated by the IE-DOCTORS with an eye toward interoperability and/or backward compatibility with existing methods of exporting similar data, on a case-by-case basis 🍓.
  • Information Elements representing information about proprietary or nonstandard applications should not be registered in the IANA IE registry. Instead, these can be represented using enterprise-specific Information Elements as detailed in Section 3.2 of [RFC7011] 💅.

The definition of new Information Elements requires a descriptive name, a specification of the data type from the IPFIX Data Type subregistry in the IANA IE registry (defined in [RFC7012] as itself extensible via Standards Action as per [RFC5226]), and a human-readable description written in English 📖. This section gives guidelines on each of these components, referring to existing documentation such as [RFC7012] as appropriate 🫶.

4.1. Information Element Naming 🏷️

As the name of an Information Element is the first thing a potential implementor will use when deciding whether it's suitable for a given application, it's important to be as precise and descriptive as possible 💅. Names of Information Elements:

  • must be chosen carefully to describe the use of the Information Element within the context in which it will be used.
  • must be unique within the IANA IE registry.
  • start with lowercase letters.
  • use capital letters for the first letter of each component except for the first one (aka "camel case"). All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as IPv4 and IPv6. Examples are sourceMacAddress and destinationIPv4Address.

In addition, new Information Elements pertaining to a specific protocol should name the protocol in the first word, to make them easier to search for by name (e.g., sipMethod for a SIP method, as would be used in a logging format for SIP based on IPFIX) 🔍. Similarly, new Information Elements pertaining to a specific application should name the application in the first word 💜.

4.2. Information Element Data Types 🧁

IPFIX provides a set of data types covering most primitives used in network measurement and management applications 🌟. The most appropriate data type should be chosen for the Information Element type, from the IPFIX informationElementDataTypes subregistry at [IANA-IPFIX]. This subregistry may be extended from time to time by a Standards Action [RFC5226], as defined in [RFC5610] 🦄.

Information Elements representing an integral value with a natural width should be defined with the appropriate integral data type. This applies especially to values taken directly from fixed-width fields in a measured protocol. For example, tcpControlBits, the TCP flags byte, is an unsigned8, and tcpSequenceNumber is an unsigned32 🎀.

Information Elements representing counters or identifiers should be defined as signed64 or unsigned64, as appropriate, to maximize the range of values available. Applications can use reduced-size encoding as defined in Section 6.2 of [RFC7011] in cases where fewer than 2^64 values are necessary 🔢.

Information Elements representing time values must be defined with appropriate precision. For example, an Information Element for a time measured at second-level precision should be defined as having a dateTimeSeconds data type, instead of dateTimeMilliseconds ⏱️.

Information Elements of type string or octetArray that have length constraints (fixed length, minimum and/or maximum length) must note these constraints in their description 📏.

The type of an Information Element must match the type of the data it represents. More specifically, information that could be represented as a string but that better matches one of the other data types (e.g., an integral type for a number or enumerated type, an address type for an address) must be represented by the best-matching type, even if the data was represented using a different type in the source. For example, an IPFIX application that exports Options Template Records mapping IP addresses to additional information about each host from an external database must use Information Elements of an address type to represent the addresses, even if the source database represented these as strings 🌈.

Strings and octetArrays must not be used to encode data that would be more properly represented using multiple Information Elements and/or IPFIX Structured Data [RFC6313]; see Section 4.5 for more 🙅.

This document does not cover adding new Data Types or Data Type Semantics to the IPFIX protocol. Because such changes have important interoperability considerations and require implementation on both Collecting and Exporting Processes, they require a Standards Action as per [RFC5610]. However, note that the set of primitive types provided by IPFIX applies to almost any appropriate application, so extending the type system is generally not necessary 💖.

4.3. Information Element Numbering 🔢

Each Information Element has a unique identifier in the IANA registry 🪪.

When adding newly registered Information Elements to the IANA IE registry, IANA should assign the lowest available Information Element identifier (the value column in [IANA-IPFIX]) in the range 128-32767 ✨.

Information Elements with identifiers in the range 1-127 are reserved for compatibility with corresponding fields in NetFlow version 9, as described in [RFC3954] 🦋.

4.4. Ancillary Information Element Properties 🍭

Information Elements to which special semantics apply should refer to one of the values in the Information Element Semantics subregistry of the IANA IE registry, as described in Section 3.2 of [RFC7012], subject to the restrictions given in Section 3.10 of [RFC5610]. In other words, the semantics and the type must be consistent 🫧.

When defining Information Elements representing a dimensioned quantity or entity count, the units of that quantity should be defined in the units field. This field takes its values from the IANA Information Element Units subregistry of the IANA IE registry. If an Information Element expresses a quantity in units not yet in this subregistry, then the unit must be added to the Units subregistry at the same time the Information Element is added to the IANA IE registry. Note that the Units subregistry as defined in [RFC5610] is maintained on an Expert Review basis 🌸.

Additionally, when the range of values an Information Element can take is smaller than the range implied by its data type, the range should be defined within the Information Element's entry in the IANA IE registry 💜.

4.5. Internal Structure in Information Elements 🎀

okay so the rule here is that defining an Information Element whose internal structure is spelled out in its Description field is not recommended 🙅‍♀️, except in these four cases:

  1. The Information Element is a direct copy of a structured entity in a measured protocol (e.g., the tcpControlBits Information Element for the flags byte from the TCP header). 💖
  2. The Information Element represents a section of a packet of protocol entity, in raw form as captured from the wire (e.g., the mplsLabelStackSection Information Element for the MPLS label stack). 🦋
  3. The Information Element represents a set of flags that are tightly semantically related, where representing the flags as separate one-byte booleans would be inefficient, and that should always appear together in a data record (e.g., the anonymizationFlags Information Element for specifying optional features of anonymization techniques). 🍓
  4. The Information Element contains internal structure by reference to an external data type or specification containing internal structure (e.g., a MIME type or URL), for interoperability and backward-compatibility purposes. 🫶

Additional exceptions to the above list should be made through publication of an RFC. 📜

In other cases, candidate Information Elements with internal structure should be decomposed into multiple primitive Information Elements to be used in parallel. ✨ For more complicated semantics, where the structure is not identical from Data Record to Data Record, or where there is semantic dependency between multiple decomposed primitive Information Elements, use the IPFIX Structured Data [RFC6313] extension instead. 💅

As an example of Information Element decomposition, consider an application-level identifier called an "endpoint", which represents a {host, port, protocol} tuple. 🧚 Instead of allocating an opaque, structured "source endpoint" Information Element, the source endpoint should be represented by three separate Information Elements: "source address", "source port", "transport protocol". The required Information Elements already exist in the IANA IE registry: sourceIPv4Address or sourceIPv6Address, sourceTransportPort, protocolIdentifier. Indeed, as well as being good practice, this normalization down to non-structured Information Elements also increases opportunities for reuse as in Section 6.1. 👑

The decomposition of data with internal structure should avoid the definition of Information Elements that have a meaning too specific to be generally useful or that would result in a multitude of templates to handle different multiplicities. 🙈 More information on multiplicities is given in the following section.

4.6. Information Element Multiplicity 🌈

Some Information Elements may represent information with a multiplicity other than one, i.e., items that may occur multiple times within the data to be represented in a single IPFIX record. 🍓 In this case, there are several options, depending on the circumstances:

  1. As specified in Section 8 of [RFC7011]: "if an Information Element is required more than once in a Template, the different occurrences of this Information Element should follow the logical order of their treatments by the Metering Process." In other words, in cases where the items have a natural order (e.g., the order in which they occur in the packet), and the multiplicity is the same for each record, the information can be modeled by containing multiple instances of the Information Element representing a single item within the Template Record describing the Data Records. 🦋
  2. In cases where the items have a variable multiplicity, a basicList of the Information Element representing a single item can be used as in the IPFIX Structured Data [RFC6313] extension. 🧚
  3. If the multiple-item structure is taken directly from bytes observed on the wire by the Metering Process or otherwise taken from the application being measured (e.g., a TCP options stack), the multiple-item structure can be exported as a variable-length octetArray Information Element holding the raw content. 💖

Specifically, a new Information Element should not encode any multiplicity or ordinality information into the definition of the Information Element itself. 🛑

4.7. Enumerated Values and Subregistries 📚

When defining an Information Element that takes an enumerated value from a set of values that may change in the future, this enumeration must be defined by an IANA IE registry or subregistry. ✨ For situations where an existing registry defines the enumeration (e.g., the IANA Protocol Numbers registry for the protocolIdentifier Information Element), that registry must be used. Otherwise, a new subregistry of the IANA IPFIX registry must be defined for the enumerated value, to be modified subject to Expert Review [RFC5226]. 🫶

4.8. Reversibility as per RFC 5103 🔁

[RFC5103] defines a method for exporting bidirectional Flows using a special Private Enterprise Number to define reverse-direction variants of IANA Information Elements, and a set of criteria for determining whether an Information Element may be reversed using this method. 💅 Since almost all Information Elements are reversible, [RFC5103] enumerates those Information Elements that were defined at the time of its publication that are NOT reversible. 🙌

New non-reversible Information Elements must contain a note in the description stating that they are not reversible. 📝

4.9. Avoiding Bad Ideas in Information Element Design 🙅‍♀️

In general, the existence of a similarly defined Information Element in the IANA IE registry sets a precedent that may be followed to determine whether a given proposed Information Element "fits" within the registry. Indeed, the rules specified by this document could be interpreted to mean "make new Information Elements that look like existing Information Elements". 🤔 However, for reasons of history, there are several Information Elements within the IANA IE registry that do not follow best practices in Information Element design. 💀

These Information Elements are not necessarily so flawed so as to require deprecation, but they should be explicitly ignored when looking for guidance as to whether a new Information Element should be added. 🧹 Here we provide a set of representative examples taken from the IANA IE registry; in general, entries in the IANA IE registry that do not follow the guidelines in this document should not be used as examples for new Information Element definitions. 🚫

Before registering a new Information Element, it must be determined that it would be sufficiently unique within the IANA IE registry. 🔍 This evaluation has not always been done in the past, and the existence of the Information Elements defined without this evaluation should not be taken as an example that such Information Element definition practices should be followed in the future. Specific examples of such Information Elements include initiatorOctets and responderOctets (which duplicate octetDeltaCount and its reverse per [RFC5103]) and initiatorPackets and responderPackets (the same, for packetDeltaCount). 😭

As mentioned in Section 4.2, the type of an Information Element should match the type of data the Information Element represents. 🎯 An example of how not to do this is presented by the p2pTechnology, tunnelTechnology, and encryptedTechnology Information Elements: these represent a three-state enumeration using a String. 🙈 The example set by these Information Elements should not be followed in the definition of new Information Elements. 🛑

As mentioned in Section 4.6, an Information Element definition should not include any ordinality or multiplicity information. 🌸 The only example of this within the IANA IE registry is the following list of assigned IPFIX Information Elements: mplsTopLabelStackSection, mplsLabelStackSection2, mplsLabelStackSection3, mplsLabelStackSection4, mplsLabelStackSection5, mplsLabelStackSection6, mplsLabelStackSection7, mplsLabelStackSection8, mplsLabelStackSection9, and mplsLabelStackSection10. 🧐 The only distinction between those almost-identical Information Elements is the position within the MPLS stack. 💜 This Information Element design pattern met an early requirement of the definition of IPFIX that was not carried forward into the final specification -- namely, that no semantic dependency was allowed between Information Elements in the same Record -- and as such should not be followed in the definition of new Information Elements. 🙃 In this case, since the size of the MPLS stack will vary from Flow to Flow, it should be exported using IPFIX Structured Data [RFC6313] where supported, as a basicList of MPLS label entries, or as a raw MPLS label stack using the variable-length mplsLabelStackSection Information Element. 🧠

5. The Information Element Life Cycle 🔄

Once an Information Element or set of Information Elements has been identified for a given application, Information Element specifications in accordance with Section 4 are submitted to IANA to follow the process for review by the IE-DOCTORS, as defined below. 📬 This process is also used for other changes to the IANA IE registry, such as deprecation or revision, as described later in this section. 🌷

5.1. The Process for Review by the IE-DOCTORS 🩺

Requests to change the IANA IE registry or a linked subregistry are submitted to IANA, which forwards the request to a designated group of experts (IE-DOCTORS) appointed by the IESG; these are the reviewers called for by the Expert Review [RFC5226] policy defined for the IANA IE registry by [RFC7012]. 👩‍🔬 The IE-DOCTORS review the request for such things as compliance with this document, compliance with other applicable IPFIX-related RFCs, and consistency with the currently defined set of Information Elements. 🔎

Authors are expected to review compliance with the specifications in this document to check their submissions before sending them to IANA. ✅

The IE-DOCTORS should endeavor to complete referred reviews in a timely manner. ⏰ If the request is acceptable, the IE-DOCTORS signify their approval to IANA, which changes the IANA IE registry. 🎉 If the request is not acceptable, the IE-DOCTORS can coordinate with the requestor to change the request to be compliant. 🤝 The IE-DOCTORS may also choose in exceptional circumstances to reject clearly frivolous or inappropriate change requests outright. 🚫

This process should not in any way be construed as allowing the IE-DOCTORS to overrule IETF consensus. 🗳️ Specifically, Information Elements in the IANA IE registry that were added with IETF consensus require IETF consensus for revision or deprecation. 🫡

Decisions by the IE-DOCTORS may be appealed as in Section 7 of [RFC5226]. ⚖️

5.2. Revising Information Elements 🔄

okay so the Information Element status field in the IANA IE registry is defined in [RFC7012] and lets an Information Element be either 'current' or 'deprecated' 💅. As of this writing, none of them are deprecated, so the list is literally clean ✨. [RFC5102] also had an 'obsolete' status, but it got removed on revision because it did nothing useful operationally 💀.

No policy is defined for revising IANA IE registry entries or fixing mistakes in them 🙈. To be clear, changes and deprecations in the registry are not encouraged and should be avoided as much as possible 🫶. BUT change is inevitable, so this section exists to fill that gap 🦋.

Changes start by sending a new Information Element definition to IANA, same as Section 5.1, for an Information Element that already exists 📨.

The big priority here is avoiding interoperability problems. IE-DOCTORS must work to maintain interoperability above all else 👑. Changes to Information Elements that are already in use may only be done in an interoperable way. If a necessary change can't be done in a way that still works with unchanged implementations, it must result in deprecation 😭.

A change is held to be interoperable only when:

  1. it involves the correction of an error that is obviously only editorial; or
  2. it corrects an ambiguity in the Information Element's definition, which itself leads to non-interoperability severe enough to prevent the Information Element's usage as originally defined (e.g., a prior change to ipv6ExtensionHeaders); or
  3. it expands the Information Element's data type without changing how it is represented (e.g., changing unsigned32 to unsigned64, as with a prior change to selectorId); or
  4. it corrects missing information in the Information Element's definition without changing its meaning (e.g., the explicit definition of 'quantity' semantics for numeric Information Elements without a Data Type Semantics value); or
  5. it defines a previously undefined or reserved enumerated value, or one or more previously reserved bits in an Information Element with flag semantics; or
  6. it expands the set of permissible values in the Information Element's range; or
  7. it harmonizes with an external reference that was itself corrected.

If IE-DOCTORS says a change is permissible, IANA makes it in the IANA IE registry 🎉. The requestor of the change gets appended to the requestor in the registry.

Every Information Element in the IANA IE registry has a revision number, starting at zero 🔢. Each change that goes through this process bumps the revision number up by one. Since any revision must be interoperable under the criteria above, the IANA IE registry doesn't need to store info about old revisions 🗑️.

When a revised Information Element gets accepted into the registry, the date of acceptance of the most recent revision goes into the revision Date column for that Information Element 📅.

5.3. Deprecating Information Elements 🪦

Changes that don't pass these criteria may only be handled by deprecation. An Information Element MAY be deprecated and replaced when:

  1. the Information Element definition has an error or shortcoming that cannot be permissibly changed as in Section 5.2; or
  2. the deprecation harmonizes with an external reference that was itself deprecated through that reference's accepted deprecation method; or
  3. changes in the IPFIX protocol or its extensions, or in community understanding thereof, allow the information represented by the Information Element to be represented in a more efficient or convenient way. Deprecation in this circumstance requires a Standards Action.

A request for deprecation gets sent to IANA, which passes it to IE-DOCTORS for review, same as Section 5.1 🔍. When deprecating an Information Element, its description in the IANA IE registry must be updated to explain the deprecation, and to point to any new Information Elements created to replace it 📝.

The revision number of an Information Element goes up upon deprecation, and the revision Date gets updated, just like with any revision 🔁.

Deprecated Information Elements should continue to be supported by Collecting Processes, but should not be exported by Exporting Processes 🫠. Using deprecated Information Elements should result in a log entry or human-readable warning at the Exporting and Collecting Processes 🚨.

Names and elementIDs of deprecated Information Elements must not be reused 🙅‍♀️.

6. When Not to Define New Information Elements 🚫

Okay, this part is super important. The IANA IE registry has a relatively limited number space for Information Elements, and the registry gets harder to manage and understand the bigger it grows 📚. So avoiding redundancy and clutter matters a lot when you're defining new applications 🧹. New Information Elements should not be added to the IANA IE registry unless there's an intent to implement and deploy applications using them. Research or experimental applications should use enterprise-specific Information Elements instead, as in Section 6.2 🧪.

The subsections below give guidelines for reusing existing Information Elements, plus guidelines for using enterprise-specific Information Elements instead of adding new ones to the IANA IE registry 🌸.

6.1. Maximizing Reuse of Existing Information Elements ♻️

Whenever possible, new applications should prefer existing IPFIX Information Elements over creating new ones 💖. IPFIX already has Information Elements for every common Layer 4 and Layer 3 packet header field in the IETF protocol suite, basic Layer 2 info, basic counters, timestamps and time ranges, and more 🤩. When defining a new Information Element that's similar to an existing one, reviewers should make sure the existing one doesn't already work 🔎.

Maximizing reuse does NOT mean an Information Element that represents the same packet info as an existing one shouldn't be added to the IANA IE registry, though 👀. Take ipClassOfService (Element ID 5), ipDiffServCodePoint (Element ID 98), and ipPrecedence (Element ID 196). These all represent subsets of the same field in an IP version 4 packet header, but they're different uses of those bits 🧩. Which one you pick tells you how the Metering Process interpreted the bits, so the choice carries info all by itself ✨.

Now, just changing the context an Information Element gets used in is NOT a good enough reason to define a new one 🙅‍♀️. For example, an extension of IPFIX that logs detailed info about HTTP transactions alongside network-level info should not define httpClientAddress and httpServerAddress Information Elements. It should prefer sourceIPv[46]Address and destinationIPv[46]Address instead 💅.

Applications dealing with bidirectional interactions should use Bidirectional Flow Support for IPFIX [RFC5103] to represent those interactions 🔁.

Existing timestamp and time range Information Elements should be reused for any situation that needs simple time stamping of an event 🕰️. For single observations, the observationTime* Information Elements from PSAMP are provided. For events with a duration, the flowStart* and flowEnd* Information Elements do the job. This setup lets existing Collecting Processes and analysis workflows handle time with minimal generic work 🫶. New timestamp Information Elements should ONLY be defined for semantically distinct timing info (e.g., an IPFIX-exported record containing info about an event to be scheduled in the future) 📆.

In all cases, using absolute timestamp Information Elements (e.g., flowStartMilliseconds) is recommended, since they give maximum flexibility in processing with minimal overhead ⭐. Timestamps based on the Export Time header in the enclosing IPFIX Message (e.g., flowStartTimeDeltaMicroseconds) MAY be used if high-precision timing is important, export bandwidth or storage space is limited, timestamps make up a relatively large fraction of the record size, and the application naturally groups records into IPFIX Messages 🧃. Timestamps based on info that has to be exported in a separate Data Record defined by an Options Template (e.g., flowStartSysUpTime) MAY be used only in the context of an existing practice of using runtime-defined epochs for the given application 🕹️. New applications should avoid these structures when possible 🙈.

6.2. Applying Enterprise-Specific Information Elements 🏢

IPFIX has a mechanism for defining enterprise-specific Information Elements, as in Section 3.2 of [RFC7011] 🛠️. These are scoped to a vendor's or organization's Structure of Management Information (SMI) Private Enterprise Number, and they're under complete control of the organization that assigns them 👑.

When interoperability doesn't matter, new information should be exported using enterprise-specific Information Elements instead of adding new ones to the IANA IE registry 🔐. These situations include:

  • export of implementation-specific information, or
  • export of information supporting research or experiments within a single organization or closed community, or
  • export of information derived in a commercially sensitive or proprietary method, or
  • export of information or meta-information specific to a commercially sensitive or proprietary application.

Work within the IETF generally doesn't fall into these categories, but enterprise-specific Information Elements are still useful for pre-standardization testing of a new IPFIX application 🧪. While doing initial development and interoperability testing of a new application, the Information Elements the application uses should not be submitted to IANA for inclusion in the IANA IE registry. Instead, those experimental Information Elements should be represented as enterprise-specific until their definitions are finalized 🌈.

And since this document has best practices for defining new Information Elements, organizations using enterprise-specific Information Elements are advised to follow the guidelines here even if they aren't submitting anything to the IANA IE registry 🫶💜

7. Information Element Definition Checklist ✨

Okay so these three checklists are the cheat sheet 📝 condensed from the rest of this doc, bestie. Use them when you're defining and reviewing Information Elements, and each item points back to the section it came from 🦋. They're meant for defining brand new Information Elements. Revisions follow the process in Section 5.2, and deprecations follow Section 5.3.

Lots of this still needs subjective judgement from authors, reviewers, and IANA 🧠, but some parts can be made way easier with tool support 🤖. Items marked "(tool support)" are the ones tools can handle. The rest need a human brain. Checks for semantic uniqueness might get some help from textual analysis of descriptions later on 🔮.

Checklist 1 contains conditions that must be met by all proposed Information Elements:

  1. The name must be unique within the IANA IE registry, and the name of any current or deprecated Information Element must not be reused. (Section 4.1) (tool support)
  2. The description must be sufficiently semantically unique within the IANA IE registry, representing a substantially different meaning from any current or deprecated Information Element. (Section 4)
  3. The name must start with a lowercase letter. (Section 4.1) (tool support)
  4. Names composed of more than one word must use capital letters for the first letter of each component except for the first one; all other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as IPv4 and IPv6. (Section 4.1) (tool support)
  5. The data type must match the type of the data being represented. (Section 4.2)
  6. Data type semantics must be appropriate for the data type. (Section 4.4) (tool support)
  7. The Information Element identifier assigned by IANA must be unique. (Section 4.3) (tool support)
  8. The Information Element must be reviewed for the potential of information leakage or other misuse that could reduce the security of the measured system; security considerations specific to the Information Element must be discussed in the description or in a supporting RFC. (Section 11)

Checklist 2 contains conditions that must be met by proposed Information Elements with certain properties, as noted:

  1. Time values must be defined with appropriate precision. (Section 4.2)
  2. Strings and octet arrays with length restrictions must note those length restrictions in their descriptions. (Section 4.2)
  3. Enumerations must refer to an IANA IE registry or subregistry, or a registry maintained by an external standards organization. If no suitable registry or subregistry exists, a new subregistry of the IPFIX Information Element registry must be created for the enumeration, to be modified subject to Expert Review [RFC5226]. (Section 4.7)

Checklist 3 contains conditions that should be met by proposed Information Elements:

  1. The name of an Information Element pertaining to a specific protocol or application should contain the name of the protocol or application as the first word. (Section 4.1)
  2. Information Elements representing integral values should use a data type for the appropriate width for the value. (Section 4.2)
  3. Information Elements representing counters or identifiers should be represented as signed64 or unsigned64, unless they are naturally represented with narrower integral types, as appropriate. (Section 4.2)
  4. An Information Element should not contain internal structure, subject to the exceptions in Section 4.5; candidate Information Elements with internal structure should be decomposed into multiple Information Elements. (Section 4.5)
  5. An Information Element should not contain multiplicity or ordinality information within the definition of the Information Element itself. (Section 4.6)
  6. Data type semantics should be defined, if appropriate. (Section 4.4) (tool support)
  7. Units should be defined, if appropriate, with new units added to the Information Element Units subregistry if necessary. (Section 4.4) (tool support)
  8. Ranges should be defined, if appropriate. (Section 4.4) (tool support)
  9. Non-reversible Information Elements (see [RFC5103]) should note non-reversibility in the description. (Section 4.8)
  10. Information Elements to be registered with IANA should be intended for implementation and deployment on production networks.

8. Applying IPFIX to Non-Flow Applications 🌸

Okay, so the whole core of IPFIX is its definition of a Flow 🌊: a set of packets sharing some common properties that cross an Observation Point within a certain time window. BUT not relying on that definition doesn't mean IPFIX can't be used for stuff that isn't obviously Flow data 🙈. Most network management data collection tasks (the ones IPFIX is best at) are basically about moving packets from one place to another. So if you interpret those common properties liberally, almost any event handled by these tasks can be treated as data records that fit the IPFIX definition of a Flow ✨.

Non-Flow information that defines associations or key-value pairs is a whole different vibe 💜. That gets defined by IPFIX Options Templates. In an Options Template Record, the Information Elements are split into Scope Information Elements, which define the key, and non-scope Information Elements, which define the values tied to that key. Unlike Flows, Data Records defined by Options Templates aren't necessarily scoped in time. They're generally considered in effect until a new set of values for a specific set of keys gets exported 🧚. IPFIX often uses this mechanism to export metadata about the collection infrastructure, but it works for any association information too 💅.

An IPFIX application can mix Data Records described by either type of template in an IPFIX Message or Message stream 🎀. It can also exploit relationships among the Flow Keys, values, and Scopes to build interrelated data structures. See [RFC5473] for an example application of this 🦋.

9. Writing Internet-Drafts for IPFIX Applications 📝

When a new application is complex enough to need extra clarification or specification about how to use the defined Information Elements, that can be written up in an Internet-Draft 💖.

Internet-Drafts for new IPFIX applications are best submitted to a Working Group with expertise in the area of the new application, or to the Independent Submission stream 🌈.

When you're defining new Information Elements in an Internet-Draft, the draft should have a section (or subsection) for each Information Element, containing the attributes from Section 4 in human-readable form ✨. An example subsection is shown below. These Information Element descriptions should not assign Information Element numbers. Instead, use placeholder identifiers like TBD1, TBD2, and TBD3, plus a note to IANA in the IANA Considerations section asking them to swap those placeholders for real numbers once they're assigned 🔢. Placeholders let you reference the numbers in things like box-and-line diagrams or template definitions, as shown in Section 10 🦋.

9.1. Example Information Element Definition

This is an example of an Information Element definition that would appear in an Internet-Draft 💅. The name appears in the section title.

Description:   Description goes here.; obligatory

Data Type:   Data type goes here; obligatory

Data Type Semantics:   Data type semantics, if any, go here; optional

Units:   Units, if any, go here; optional

Range:   Range, if not implied by the data type, goes here; optional

References:   References to other RFCs or documents outside the IETF,
   in which additional information is given, or which are referenced
   by the description, go here; optional

ElementId:   ElementId, if known, or "TBD" if it will be assigned by
   IANA and filled in at publication time.

Okay, so new IPFIX applications generally should NOT define fixed templates for export 🙅, because that throws away a lot of the flexibility IPFIX gives you. The exception is when the export implementation has to run in a resource-constrained environment, and/or when the application is replacing an existing fixed-format binary export format in a maximally compatible way 💜. Either way, Collecting Processes for these applications should support collection Templates with Information Elements in any order, or Templates with additional Information Elements ✨.

An Internet-Draft clarifying the use of new Information Elements should include any recommended Template or Options Template Records needed to support the application, along with examples of records exported using those Template Records 🌸. When defining these Template Records, these drafts should mention (with rare exceptions) the following:

  1. that the order of different Information Elements within a Template is not significant;
  2. that Templates on the wire for the application may also contain additional Information Elements beyond those specified in the recommended Template;
  3. that a stream of IPFIX Messages supporting the application may also contain Data Records not described by the recommended Templates; and
  4. that any reader of IPFIX Messages supporting the application must accept these conditions.

Definitions of recommended Template Records for Flow-like information, where the Flow Key is well-defined, should indicate which of the Information Elements in the recommended Template are Flow Keys 🔑.

Recommended Templates are defined, for example, in [RFC5476] for PSAMP packet reports (Section 6.4.1) and extended packet reports (Section 6.4.2) 🎀. Recommended Options Templates are defined extensively throughout the IPFIX documents. That includes the protocol document itself [RFC7011] for exporting export statistics, the file format [RFC5655] for exporting file metadata, and intermediate process definitions such as [RFC6235] for intermediate process metadata 🧚. The discussion in these examples is a really good model for writing recommended template definitions 🫶.

10. A Textual Format for Specifying Information Elements and Templates ✨

okay so bestie, the example Templates in existing IPFIX documents are usually drawn as bitmap diagrams 🦋 and honestly? they're a vibe for showing what a simple Template looks like on the wire, but they get messy fast once the Template gets complicated 💀. They also don't help anyone whip up a brand-new Template quickly, and they don't clearly show that ordering and extra Information Elements can be optional 🙈. So this section defines a recommended textual format for writing down Information Elements and Templates in Internet-Drafts 💅.

the goals here are giving it a total main character glow-up: human readable, human writable, compact, and easy for a parser or generator to implement WITHOUT needing any external XML support 🌸. it's meant for people (like new Internet-Drafts with higher-level descriptions of Templates, or new Information Elements for shiny new applications 🧚) AND for IPFIX implementations to use at runtime 🔥.

10.1. Information Element Specifiers

the core of this format is the textual Information Element Specifier, aka the IESpec 💖. an IESpec packs in all four key facts about an Information Element: its name, its number, its type, and its size, and uses brackets to separate them 🎀. fully qualified IESpecs can define existing or new Information Elements in an Information Model, while either fully qualified or partial IESpecs can define the fields in a Template ✨.

names are bare words, and each kind of info gets its own bracket type 💜:

  • () parentheses for Information Element numbers,
  • <> angle brackets for Information Element data types, and
  • [] square brackets for Information Element sizes.
  • {} curly braces hold an optional space-separated list of context identifiers for an Information Element, more on that in Section 10.2 🦋

the symbol + is reserved for Information Elements nested inside structured data elements, which we cover in Section 10.3 🌈

whitespace in IESpecs doesn't matter at all, so you can add spaces after each element to line stuff up and make it easier to read 🍓

the basic form of a fully qualified IESpec for an IANA-registered Information Element looks like this:

name(number)<type>[size]

where name is the Information Element's name in UTF-8, number is the Information Element as a decimal integer, type is the name of the data type from the IANA informationElementDataTypes registry, and size is the length of the Information Element in octets as a decimal integer. the value 65535 or the string v means a variable-length Information Element 🫶. [size] can be left out, and then the data type's native or default size gets assumed 💅.

the basic form of a fully qualified IESpec for an enterprise-specific Information Element is:

name(pen/number)<type>[size]

where pen is the Private Enterprise Number as a decimal integer 👑.

a fully qualified IESpec is meant to carry enough info to decode and display Data Records defined by Templates that contain that Information Element ✨. range, unit, semantic, and description info (like in [RFC5610]) is NOT supported by this syntax 💀.

here are some example fully qualified IESpecs:

octetDeltaCount(1)<unsigned64>[8]

octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets
long)

sourceIPv4Address(8)<ipv4Address>

wlanSSID(146)<string>[v]

sipRequestURI(35566/403)<string>[65535]

a partial IESpec is any IESpec that isn't fully qualified, and these are super useful when defining Templates 🧚. a partial IESpec takes any missing values from its canonical definition in the IANA IE registry 🌸. at minimum, a partial IESpec has to contain a name or a number 🔥. any name, number, or type info given in a partial IESpec must match what the Information Model says, BUT size info in a partial IESpec overrides the size in the Information Model 🦋. that's how IESpecs can express reduced-size encoding for Information Elements, which is so clever 😭.

example partial IESpecs:

  • octetDeltaCount
  • octetDeltaCount[4] (reduced-size encoding)
  • (1)
  • (1)[4] (reduced-size encoding; note that this is exactly equivalent to an Information Element specifier in a Template)

10.2. Specifying Templates

a Template is just an ordered sequence of IESpecs, separated by newlines 🎀. IESpecs in example Templates that illustrate a new application of IPFIX should be fully qualified 💖. Flow Keys can optionally be annotated by adding the {key} context to the end of each Flow Key specifier 🫶. here's a Template that counts packets and octets per 5-tuple with millisecond precision, written in IESpec syntax, in Figure 1 ✨:

flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
octetDeltaCount(1)<unsigned64>[8]
packetDeltaCount(2)<unsigned64>[8]
sourceIPv4Address(8)<ipv4Address>[4]{key}
destinationIPv4Address(12)<ipv4Address>[4]{key}
sourceTransportPort(7)<unsigned16>[2]{key}
destinationTransportPort(11)<unsigned16>[2]{key}
protocolIdentifier(4)<unsigned8>[1]{key}

Figure 1: Sample Flow Template in IESpec Syntax

Options Templates are specified in a similar way 🌈. Scope is specified by appending the {scope} context to the end of each IESpec for a Scope IE 🦋. because of how Information Elements are represented in Options Templates, all {scope} IESpecs MUST appear before any non-scope IESpec 👑. the Flow Key Options Template from Section 4.4 of [RFC7011], written in IESpec syntax, is in Figure 2 💅:

templateId(145)<unsigned16>[2]{scope}
flowKeyIndicator(173)<unsigned64>[8]

Figure 2: Flow Key Options Template in IESpec Syntax

10.3. Specifying IPFIX Structured Data

IESpecs can also show the structure of information exported using the IPFIX Structured Data extension in [RFC6313] 🧚. here, the semantics of structured data elements are specified with contexts, and the Information Elements inside each structured data element come right after it, prefixed with + to show they're contained in it 🌸. you can nest structured data elements as deep as you want by using multiple + signs in the prefix 🔥. for example, a basic list of IP addresses with "one or more" semantics is written with partially qualified IESpecs, as shown in Figure 3 🦋:

basicList{oneOrMoreOf}
+sourceIPv4Address(8)[4]

Figure 3: Sample basicList in IESpec Syntax

and here's an example subTemplateList that itself contains a basicList, in Figure 4 😭:

subTemplateList{allOf}
+basicList{oneOrMoreOf}
++sourceIPv4Address(8)[4]
+destinationIPv4Address(12)[4]

Figure 4: Sample subTemplateList in IESpec Syntax

this describes a subTemplateMultilist containing all of the expressed set of source-destination pairs, where the source address could be any number of addresses in a basicList (for example, with SCTP multihoming) 💜.

the contexts you can associate with structured data Information Elements are the semantics defined in Section 4.4 of [RFC6313] 🎀. a structured data Information Element without any context is taken to have undefined semantics 💀. more info on structured data is in [RFC6313] 📚✨.

11. Security Considerations 🔐

⚠️ bestie, this one is SERIOUS. Don't skip it 💀

the IE-DOCTORS MUST evaluate the security aspects of new Information Elements, considering what info they could give to attackers targeting the measured network or the entities the info is exported about 🙈. specific aspects to check include whether the exported info contains personally identifiable information, or info that should stay confidential about the described entities (for example, partial payload, or configuration info that could be exploited) 😭. this doesn't mean such Information Elements can't be defined, BUT there MUST be an evaluation of the security risk versus the utility of the exported info for the intended application 💅. for example, "A Framework for Packet Selection and Reporting" [RFC5474] concluded in Section 12.3.2 that the hash function's private parameters should not be exported within IPFIX 🔥.

security considerations specific to an Information Element MUST be addressed in the Security Considerations section of the Internet-Draft that describes the Information Element, or in the Information Element description itself if it isn't defined in an Internet-Draft 🦋. Information Elements with specific security considerations SHOULD be described in an Internet-Draft 🫶.

for example, the ipHeaderPacketSection entry in the IPFIX IE registry says: "This Information Element, which may have a variable length, carries a series of octets from the start of the IP header of a sampled packet. With sufficient length, this element also reports octets from the IP payload, subject to [RFC2804]. See the Security Considerations section". another example is from the "Packet Sampling (PSAMP) Protocols Specification" [RFC5476]: "In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer, and other encapsulation headers) and some subsequent bytes of the packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC2804]. The PSAMP Device MUST respect local privacy laws." 👑

12. Acknowledgments 🌸

thanks to Paul Aitken, Andrew Feren, Dan Romascanu, and David Harrington for their reviews and feedback 🫶. thanks also to Roni Even and Yoav Nir for their area reviews, and to Pete Resnick, Adrian Farrel, Stephen Farrell, Stewart Bryant, and Barry Leiba for their contributions during IESG discussions 💖. this work is materially supported by the European Union Seventh Framework Programme under grant agreement 257315 (DEMONS) ✨.

13. References 📚

13.1. Normative References

[RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
           Using IP Flow Information Export (IPFIX)", RFC 5103,
           January 2008.

[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.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

[RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
           "Export of Structured Data in IP Flow Information Export
           (IPFIX)", RFC 6313, July 2011.

[RFC7011]  Claise, B., Ed., Trammell, B., Ed., 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., Ed. and B. Trammell, Ed., "Information Model
           for IP Flow Information Export (IPFIX)", RFC 7012,
           September 2013.

13.2. Informative References 📚

okay so these are the "good to know" references, the ones that give extra context without you strictly needing them to implement the spec 🤓✨

  • [RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 🕵️
  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞
  • [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004. 🌊
  • [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. 🧠
  • [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. ✂️
  • [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009. 🎯
  • [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. 🍰
  • [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009. 👯
  • [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. 🗂️
  • [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011. 🫥
  • [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", http://www.iana.org/assignments/ipfix. 👑

Appendix A. Example Information Element Definitions ✨

okay this part is the fun one, bestie 💖 these are a few example Information Element definitions, written the way they'd look inside an Internet-Draft. Be sure to check how well they follow the guidelines in Section 4, because they're meant to be the good examples 🫶

The sipResponseStatus Information Element (Appendix A.1) shows how to add an Information Element for Layer 7 application info, and it points to the registry that holds the allowed values 📞. The duplicatePacketDeltaCount Information Element (Appendix A.2) shows how to add a brand new metric, with a reference to the RFC that defines it 📈. And the ambientTemperature Information Element (Appendix A.3) shows how to add a new measured value that lives way outside traditional networking 🌡️🧚

A.1. sipResponseStatus 📞

   Description:   The SIP Response code as an integer, as in the
      Response Codes registry at http://www.iana.org/assignments/sip-
      parameters defined in [RFC3261] and amended in subsequent RFCs.
      The presence of this Information Element in a SIP Message record
      marks it as describing a SIP response; if absent, the record
      describes a SIP request.

   Data Type:   unsigned16

   Data Type Semantics:   identifier

   References:   [RFC3261]

   ElementId:   TBD1

   Replaces Enterprise-Specific Element:  35566 / 412

A.2. duplicatePacketDeltaCount 👯

   Description:   The number of uncorrupted and identical additional
      copies of each individual packet in the Flow arriving at the
      destination since the previous Data Record for this Flow (if any),
      as measured at the Observation Point.  This is measured as the
      Type-P-one-way-packet-duplication metric defined in Section 3 of
      [RFC5560].

   Data Type:   unsigned64

   Data Type Semantics:   deltaCounter
   Units:   packets

   References:   [RFC5560]

   ElementId:   TBD2

A.3. ambientTemperature 🌡️

   Description:   An ambient temperature observed by measurement
      equipment at an Observation Point, positioned such that it
      measures the temperature of the surroundings (i.e., not including
      any heat generated by the measuring or measured equipment),
      expressed in degrees Celsius.

   Data Type:   float

   Units:   degrees Celsius

   Range:   -273.15 - +inf

   ElementId:   TBD3

Authors' Addresses 💌

these are the two authors, and you can reach them at the details below 🎀

   Brian Trammell
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   EMail: trammell@tik.ee.ethz.ch
   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com
📦 where this page comes from