RFC 7012

Information Model for IP Flow Information Export (IPFIX)

📅 published September 2013, from ietf

RFC 7012: Information Model for IP Flow Information Export (IPFIX) 💖

Okay bestie, this is the IETF's Standards Track doc from September 2013 (ISSN 2070-1721) that defines the IPFIX information model 🦋. The editors are B. Claise (Cisco Systems, Inc.) and B. Trammell (ETH Zurich), and it obsoletes RFC 5102 🎀. It's an official Internet standard, so it's giving serious authority ✨

Abstract

Okay so this doc defines the data types and management policy for the information model of the IP Flow Information Export (IPFIX) protocol 🌸. The model lives in the IANA "IPFIX Information Elements" registry, and its starting contents came from RFC 5102 💅. IPFIX uses this model to encode measured traffic info, plus info about the traffic Observation Point, the traffic Metering Process, and the Exporting Process 📊. It was built for IPFIX, but it's written in an open way so other protocols, interfaces, and apps can use it too, which is so iconic 👑. This document obsoletes RFC 5102 🫶

Status of This Memo

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community 🧚 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ For more on Internet Standards, check Section 2 of RFC 5741 💜

Info about the current status, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7012 🍓

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 🌈

This doc 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 read these carefully, bestie, because they explain your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💖

Table of Contents 🎀

1. Introduction ....................................................3
   1.1. Changes since RFC 5102 .....................................4
   1.2. IPFIX Documents Overview ...................................4
2. Properties of IPFIX Protocol Information Elements ...............5
   2.1. Information Element Specification Template .................5
   2.2. Scope of Information Elements ..............................7
   2.3. Naming Conventions for Information Elements ................8
3. Type Space ......................................................9
   3.1. Abstract Data Types ........................................9
        3.1.1. unsigned8 ...........................................9
        3.1.2. unsigned16 ..........................................9
        3.1.3. unsigned32 ..........................................9
        3.1.4. unsigned64 ..........................................9
        3.1.5. signed8 ............................................10
        3.1.6. signed16 ...........................................10
        3.1.7. signed32 ...........................................10
        3.1.8. signed64 ...........................................10
        3.1.9. float32 ............................................10
        3.1.10. float64 ...........................................10
        3.1.11. boolean ...........................................10
        3.1.12. macAddress ........................................10
        3.1.13. octetArray ........................................10
        3.1.14. string ............................................11
        3.1.15. dateTimeSeconds ...................................11
        3.1.16. dateTimeMilliseconds ..............................11
        3.1.17. dateTimeMicroseconds ..............................11
        3.1.18. dateTimeNanoseconds ...............................11
        3.1.19. ipv4Address .......................................11
        3.1.20. ipv6Address .......................................11
        3.1.21. basicList .........................................11
        3.1.22. subTemplateList ...................................11
        3.1.23. subTemplateMultiList ..............................12
   3.2. Data Type Semantics .......................................12
        3.2.1. quantity ...........................................12
        3.2.2. totalCounter .......................................12
        3.2.3. deltaCounter .......................................12
        3.2.4. identifier .........................................13
        3.2.5. flags ..............................................13
4. Information Element Identifiers ................................13
5. Information Elements ...........................................14
6. Extending the Information Model ................................15
7. IANA Considerations ............................................15
   7.1. IPFIX Information Elements ................................16
   7.2. MPLS Label Type Identifier ................................17
   7.3. XML Namespace and Schema ..................................17
   7.4. Addition, Revision, and Deprecation .......................18
8. Security Considerations ........................................19
9. Acknowledgments ................................................19
10. References ....................................................19
    10.1. Normative References .....................................19
    10.2. Informative References ...................................20
Contributors ......................................................23

1. Introduction ✨

Okay so IPFIX is the go-to protocol for sending network traffic measurement info around 🌸 RFC 7011 [RFC7011] covers how Information Elements get transmitted and also specifies the encoding for a set of basic data types 💅 But the list of Information Elements the protocol can carry is not in [RFC7011]. Think Flow attributes like source IP address and number of packets, or stuff about the Metering Process and Exporting Process like the packet Observation Point, sampling rate, and Flow timeout interval 📊

The IANA "IPFIX Information Elements" registry [IANA-IPFIX] is the current complete reference for IPFIX Information Elements 💖 Its initial values were provided by [RFC5102] 🎀

This doc is the sidekick to the IPFIX Protocol Specification [RFC7011] 🫶 It gives an overview of the IPFIX information model and specifies data types for it. IPFIX-specific terms used here are defined in Section 2 of [RFC7011] 🧚 Just like in [RFC7011], these IPFIX terms get a capital first letter when used here ✨

Heads up, the term 'information model' isn't fully in line with how [RFC3444] defines it, because the IPFIX information model doesn't specify relationships between Information Elements, and it doesn't specify a concrete encoding either 🙈 For an encoding that works with the IPFIX protocol, see [RFC7011]. Besides that encoding, other encodings of IPFIX Information Elements can be used too, like XML-based ones 🌈

Here's the key bit 🔑 When this doc says "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", those words get interpreted as described in [RFC2119], periodt 💅

1.1. Changes since RFC 5102 🦋

Okay so this doc obsoletes the Proposed Standard revision of the IPFIX information model spec [RFC5102] 💜 Here's what changed from the previous doc:

  • At the time of this publication, technical and editorial errata reported for [RFC5102] have been reviewed and addressed as needed. 🫶
  • All references to [RFC5101] have been updated to [RFC7011], reflecting changes to [RFC5101]. 🌸
  • Information Element definitions have been removed, as the reference for these is now [IANA-IPFIX]; a historical note on categorizations of Information Elements as defined in [RFC5102] has been retained in Section 5. 🎀
  • The process for modifying [IANA-IPFIX] has been improved and is now described in [RFC7013]; Section 6 has been updated accordingly, and a new Section 7.3 provides IANA considerations for this process. 🧚
  • Definitions of timestamp data types have been clarified. ⭐
  • Appendices A and B have been removed. 💀

1.2. IPFIX Documents Overview 🌈

The IPFIX protocol gives network admins access to network flow info 👑 The architecture for exporting measured flow info from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], based on the requirements in [RFC3917] 🍓 The IPFIX Protocol Specification [RFC7011] defines how IPFIX Data Records and templates get carried over a bunch of transport protocols, from IPFIX Exporting Processes to IPFIX Collecting Processes 🫶

Four IPFIX optimizations and extensions are currently specified, and they're so good 🔥 There's a bandwidth-saving method for the IPFIX protocol [RFC5473], an efficient method for exporting bidirectional flows [RFC5103], a method for defining and exporting complex data structures [RFC6313], and the spec for the Protocol on IPFIX Mediators [IPFIX-MED-PROTO], which is built on the IPFIX Mediation Framework [RFC6183] 🦋

IPFIX has a formal description of IPFIX Information Elements, covering their names, data types, and extra semantic info, as specified in this doc 💖 The export of the Information Element types is specified in [RFC5610] ✨

[RFC6728] specifies a data model for configuring and monitoring devices that are IPFIX and Packet Sampling (PSAMP) compliant using the Network Configuration Protocol (NETCONF) 🧚 And [RFC6615] specifies MIB modules for monitoring 💜

For development, [RFC5153] provides guidelines for implementing and using the IPFIX protocol, and [RFC5471] provides guidelines for testing 🌸

Finally, [RFC5472] describes what kinds of applications can use the IPFIX protocol and how they can use the info it provides 💅 It also shows how the IPFIX framework relates to other architectures and frameworks 👑

2. Properties of IPFIX Protocol Information Elements 🎀

2.1. Information Element Specification Template ✨

Okay bestie, so IPFIX messages are modeled in terms of Information Elements from the IPFIX information model 🧚. The IPFIX Information Elements mentioned in Section 5 are specified in [IANA-IPFIX] 📚.

All Information Elements specified for the IPFIX protocol MUST have the following properties defined 💅:

  • name - A unique and meaningful name for the Information Element. 🎀
  • elementId - A numeric identifier of the Information Element. If this identifier is used without an enterprise identifier (see [RFC7011] and the definition of enterpriseId listed below), then it is globally unique, and the list of allowed values is administered by IANA. It is used for compact identification of an Information Element when encoding Templates in the protocol. 🦋
  • description - The semantics of this Information Element. It describes how this Information Element is derived from the Flow or other information available to the observer. Information Elements of dataType string or octetArray that have length constraints (fixed length, minimum and/or maximum length) MUST note these constraints in their descriptions. 📝
  • dataType - One of the types listed in Section 3.1 of this document or registered in the IANA "IPFIX Information Element Data Types" subregistry. The type space for attributes is constrained to facilitate implementation. It's giving "most primitive types from modern programming languages" plus some derived types (such as ipv4Address) that are common to this domain. 🌸
  • status - The status of the specification of this Information Element. Allowed values are 'current' and 'deprecated'. All newly defined Information Elements have 'current' status. The process for moving Information Elements to the 'deprecated' status is defined in Section 5.3 of [RFC7013]. 🍓

Enterprise-specific Information Elements MUST have the following property defined 🏢:

  • enterpriseId - Enterprises may wish to define Information Elements without registering them with IANA, for example, for enterprise-internal purposes. For such Information Elements, the Information Element identifier described above is not sufficient when the Information Element is used outside the enterprise. If specifications of enterprise-specific Information Elements are made public and/or if enterprise-specific identifiers are used by the IPFIX protocol outside the enterprise, then the enterprise-specific identifier MUST be made globally unique by combining it with an enterprise identifier. Valid values for the enterpriseId are defined by IANA as Structure of Management Information (SMI) network management private enterprise numbers, defined at [IANA-PEN]. 💜

All Information Elements specified for the IPFIX protocol, either in this document or by any future extension, MAY have the following properties defined ✨:

  • dataTypeSemantics - The integral types are qualified by additional semantic details. Valid values for the data type semantics are either specified in Section 3.2 of this document or will be specified in a future extension of the information model. 🧠
  • units - If the Information Element is a measure of some kind, the units identify what the measure is. 📏
  • range - Some Information Elements may only be able to take on a restricted set of values that can be expressed as a range (e.g., 0 through 511, inclusive). If this is the case, the valid inclusive range SHOULD be specified. Values for this Information Element outside the range are invalid and MUST NOT be exported. 🚫
  • reference - Identifies additional specifications that more precisely define this item or provide additional context for its use. 🔗

The following two Information Element properties are defined to allow the management of an Information Elements registry, with Information Element definitions that may be updated over time, per the process defined in Section 5.2 of [RFC7013] 🗂️:

  • revision - The revision number of an Information Element, starting at 0 for Information Elements at time of definition and incremented by one for each revision. 🔢
  • date - The date of the entry of this revision of the Information Element into the registry. 📅

A template for specifying Information Elements is given in Section 9.1 of [RFC7013] 💖.

2.2. Scope of Information Elements

By default, most Information Elements have a scope specified in their definitions. Within Data Records defined by Options Templates, the IPFIX protocol allows further limiting of the Information Element scope 🎯. The new scope is specified by one or more scope fields and defined as the combination of all specified scope values. See Section 3.4.2.1 on IPFIX scopes in [RFC7011] 🔍.

2.3. Naming Conventions for Information Elements

Here's the naming tea ☕. The following naming conventions were used for naming Information Elements in this document. It is recommended that extensions of the model use the same conventions 💅.

  • Names of Information Elements SHOULD be descriptive. ✍️
  • Names of Information Elements MUST be unique within the "IPFIX Information Elements" registry [IANA-IPFIX]. Enterprise-specific Information Elements SHOULD be prefixed with a vendor name. 🏷️
  • Names of Information Elements MUST start with lowercase letters. 🔡
  • Composed names 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'. Examples are sourceMacAddress and destinationIPv4Address 🐪.
  • Middleboxes [RFC3234] may change Flow properties, such as the Differentiated Services Code Point (DSCP) value or the source IP address. If an IPFIX Observation Point is located in the path of a Flow before one or more middleboxes that potentially modify packets of the Flow, then it may be desirable to also report Flow properties after the modification performed by the middleboxes. 🔀

An example is an Observation Point before a packet marker changing a packet's IPv4 Type of Service (TOS) field that is encoded in Information Element ipClassOfService. Then the value observed and reported by Information Element ipClassOfService is valid at the Observation Point but not after the packet passed the packet marker. For reporting the changed value of the TOS field, the IPFIX information model uses Information Elements that have a name prefix "post", for example, postIpClassOfService. Information Elements with prefix "post" report on Flow properties that are not necessarily observed at the Observation Point, but that are obtained within the Flow's Observation Domain by other means considered to be sufficiently reliable. For example, by analyzing the packet marker's marking tables. 🧩

3. Type Space ✨

This section describes the abstract data types that can be used for the specification of IPFIX Information Elements in Section 4. Section 3.1 describes the set of abstract data types 🌈.

Abstract data types unsigned8, unsigned16, unsigned32, unsigned64, signed8, signed16, signed32, and signed64 are integral data types. As described in Section 3.2, their data type semantics can be further specified, for example, by 'totalCounter', 'deltaCounter', 'identifier', or 'flags' 🔢.

3.1. Abstract Data Types

This section describes the set of valid abstract data types of the IPFIX information model, independent of encoding. Note that further abstract data types may be specified by future updates to this document. Changes to the associated IPFIX "Information Element Data Types" subregistry [IANA-IPFIX] specified in [RFC5610] require a Standards Action [RFC5226] 🔒.

The current encodings of these data types for use with the IPFIX protocol are defined in [RFC7011]. Encodings allowing the use of the IPFIX Information Elements [IANA-IPFIX] with other protocols may be defined in the future by referencing this document 🦋.

3.1.1. unsigned8

The type "unsigned8" is a non-negative integer, with a range of 0 to 255 💖.

3.1.2. unsigned16

The type "unsigned16" is a non-negative integer, with a range of 0 to 65535 🌸.

3.1.3. unsigned32

The type "unsigned32" is a non-negative integer, with a range of 0 to 4294967295 ✨.

3.1.4. unsigned64

The type "unsigned64" is a non-negative integer, with a range of 0 to 18446744073709551615 🚀.

3.1.5. signed8

The type "signed8" is an integer, with a range of -128 to 127 🧚.

3.1.6. signed16

The type "signed16" is an integer, with a range of -32768 to 32767 🎀.

3.1.7. signed32

The type "signed32" is an integer, with a range of -2147483648 to 2147483647 💜.

3.1.8. signed64

The type "signed64" is an integer, with a range of -9223372036854775808 to 9223372036854775807 🌌.

3.1.9. float32

The type "float32" corresponds to an IEEE single-precision 32-bit floating-point type, as defined in [IEEE.754.2008] 🦄.

3.1.10. float64

The type "float64" corresponds to an IEEE double-precision 64-bit floating-point type, as defined in [IEEE.754.2008] 🍭.

3.1.11. boolean

The type "boolean" is a binary value. The only allowed values are "true" and "false" ✅.

3.1.12. macAddress

The type "macAddress" represents a MAC-48 address, as defined in [IEEE.802-3.2012] 🖥️.

3.1.13. octetArray

The type "octetArray" is a finite-length string of octets 🧱.

3.1.14. string

The type "string" is a finite-length string of valid characters from the Unicode coded character set [ISO.10646]. Unicode incorporates ASCII [RFC20] and the characters of many other international character sets 🌍✨.

3.1.15. dateTimeSeconds

The type "dateTimeSeconds" represents a time value expressed with second-level precision ⏰.

3.1.16. dateTimeMilliseconds

The type "dateTimeMilliseconds" represents a time value expressed with millisecond-level precision ⏱️.

3.1.17. dateTimeMicroseconds

The type "dateTimeMicroseconds" represents a time value expressed with microsecond-level precision 🕐.

3.1.18. dateTimeNanoseconds

The type "dateTimeNanoseconds" represents a time value expressed with nanosecond-level precision 🌠.

3.1.19. ipv4Address

The type "ipv4Address" represents an IPv4 address 🌐.

3.1.20. ipv6Address

The type "ipv6Address" represents an IPv6 address 🌏.

3.1.21. basicList

The type "basicList" supports structured data export as described in [RFC6313]. See Section 4.5.1 of that document for encoding details 📦.

3.1.22. subTemplateList

The type "subTemplateList" supports structured data export as described in [RFC6313]. See Section 4.5.2 of that document for encoding details 🗃️.

3.1.23. subTemplateMultiList

The type "subTemplateMultiList" supports structured data export as described in [RFC6313]. See Section 4.5.3 of that document for encoding details 🫶.

3.2. Data Type Semantics ✨

okay so this section is all about the valid data type semantics of the IPFIX information model 💅 there's a subregistry of them over in [RFC5610] (the rules are compatible with its Section 3.10, so we're good), and these semantics only apply to numeric types. each one says so in its own description 🔢

Future updates to this document can add more semantics, bestie 🦋 and changing the "IPFIX Information Element Semantics" subregistry [IANA-IPFIX] needs a Standards Action [RFC5226]. big commitment energy 💀

3.2.1. quantity

"quantity" is a numeric value (integral or floating point) that represents a measured value for the record 📏 it's different from counters, which track an ongoing measurement whose "odometer" reading gets captured as part of a record. quantity is also the default semantic for every numeric data type, so if you don't say otherwise, that's what you've got 💖

3.2.2. totalCounter

"totalCounter" is an integral value that reports the value of a counter 🧮 counters are unsigned and wrap back to zero once they hit the limit of their type. like, an unsigned64 with counter semantics keeps incrementing until it reaches 2**64 - 1. then the next increment wraps it to zero and it starts counting from zero again 🌀

totalCounter is basically the same vibe as the counters in the Simple Network Management Protocol (SNMP), like Counter32 from [RFC2578] 🤝 the only difference is that total counters start at an initial value of 0. and a total counter counts on its own, regardless of when its value gets exported 🎀

3.2.3. deltaCounter

"deltaCounter" is also an integral value reporting the value of a counter 🌸 same wrap-around rules: unsigned, back to zero at the limit of the type, so an unsigned64 with counter semantics goes up to 2**64 - 1 and then wraps to zero and keeps counting 🔁

deltaCounter is similar to the SNMP counters too, like Counter32 in [RFC2578]. the only difference from those is that delta counters have an initial value of 0 🧚 the big thing with a delta counter is that it gets reset to 0 each time it's exported and/or when it expires without being exported ⏰

3.2.4. identifier

"identifier" is an integral value that works as an identifier 🪪 the key thing is that doing math on two identifiers (except for equality checks) is meaningless. like, Autonomous System ID 1 * Autonomous System ID 2 is just nonsense, Autonomous System ID 1 * Autonomous System ID 2 🙈 identifiers MUST be one of the signed or unsigned data types, no exceptions 🔒

3.2.5. flags

"flags" is an integral value that represents a set of bit fields 🚩 logical operations make sense on flags, but other math operations don't. flags MUST always be of an unsigned data type 💜

4. Information Element Identifiers 🆔

all the Information Elements in the IANA "IPFIX Information Elements" registry [IANA-IPFIX] get their identifiers assigned by IANA 👑

the identifier values are in the range of 1-32767 🔢 and inside that range, the sub-range of 1-127 is compatible with field types used by NetFlow version 9 [RFC3954], for historical reasons 🕰️

generally, when IANA adds newly registered Information Elements to the registry, it gives them the lowest available identifier in the range of 128-32767 🎯

enterprise-specific Information Element identifiers also live in the range of 1-32767, but they're paired with an extra enterprise identifier 🏢 for enterprise-specific Information Elements, identifier 0 is reserved too. an enterprise can pick its identifiers arbitrarily within 1-32767 🎨 another enterprise might use the same identifier for something totally different, and that's fine because the identifier is coupled with the enterprise identifier, so they stay distinct 🧩

enterprise identifiers are supposed to be registered as SMI network management private enterprise code numbers with IANA 📒 you can find that registry at [IANA-PEN] 🔗

5. Information Elements 🧠

[IANA-IPFIX] is now the normative reference for IPFIX Information Elements 💅 when [RFC5102] was published, its Section 5 defined the initial contents of that registry 🗂️

as a little historical tea ☕ Information Elements (IEs) used to be sorted into categories in [RFC5102] based on their semantics and applicability. those categories didn't carry over into [IANA-IPFIX] as an organizing principle 🙃 the original categories, with example IEs, were:

  1. Identifiers (e.g., ingressInterface)
  2. Metering and Exporting Process Configuration (e.g., exporterIPv4Address)
  3. Metering and Exporting Process Statistics (e.g., exportedOctetTotalCount)
  4. IP Header Fields (e.g., sourceIPv4Address)
  5. Transport Header Fields (e.g., sourceTransportPort)
  6. Sub-IP Header Fields (e.g., sourceMacAddress)
  7. Derived Packet Properties (e.g., bgpSourceAsNumber)
  8. Min/Max Flow Properties (e.g., minimumIpTotalLength)
  9. Flow Timestamps (e.g., flowStartTimeMilliseconds)
  10. Per-Flow Counters (e.g., octetDeltaCount)
  11. Miscellaneous Flow Properties (e.g., flowEndReason)
  12. Padding (paddingOctets)

Information Elements that come from packet fields or from Packet Treatment can usually act as Flow Keys, which is how packets get mapped to Flows 🗺️ those were placed in categories 4-7 in the original categorization 🎀

Information Elements that aren't Flow Keys can have different values for each packet in a Flow 🌊 for the ones whose values come from packet fields or Packet Treatment, and whose value might change from packet to packet inside a single Flow, the exported value is by default determined by the first packet observed for that Flow ✨ the description can explicitly say something different, though 🙌 this simple rule means all the header-field Information Elements only need to be written once, when the first packet of the Flow shows up 📝 for further packets of the same Flow, only Flow properties that depend on more than one packet need updating. those were placed in categories 8-11 in the original categorization 🔄

Information Elements with a name using the "post" prefix (e.g., postIpClassOfService) don't necessarily report properties that were actually observed at the Observation Point 👀 they might be retrieved by other means within the Observation Domain instead 🕵️‍♀️ these can be used when there are middlebox functions in the Observation Domain changing Flow properties after packets have passed the Observation Point 🔀 they can also be reported directly by the Observation Point if it's placed where it can see packets on both sides of the middlebox 🪞

6. Extending the Information Model 🌱

a key requirement for IPFIX is being able to extend the Information Model through the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX] 🙌 new Information Element definitions can be added to this registry subject to Expert Review [RFC5226], with extra process considerations described in [RFC7013] 📚 that document also has guidelines for authors and reviewers of new Information Element definitions, so go read it, bestie 🤓

for new Information Elements, you can use the type space defined in Section 3 🧸 if you need it, new abstract data types can be added to the "IPFIX Information Element Data Types" subregistry [IANA-IPFIX] as defined in [RFC5610] 🧩 new abstract data types and semantics are subject to Standards Action [RFC5226], and they MUST be defined in IETF Standards Track documents updating this document 🏛️

enterprises can define Information Elements without registering them with IANA 🏢 IPFIX explicitly supports enterprise-specific Information Elements 💜 those are described in Sections 2.1 and 4, and guidelines for using them are in [RFC7013] 🫶

7. IANA Considerations 🧾

okay so because this document obsoletes [RFC5102], IANA updated the references in a bunch of places 💌 that includes the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX], the "IPFIX MPLS label type" subregistry of that registry, the urn:ietf:params:xml:ns:ipfix-info XML namespace, and the urn:ietf:params:xml:schema:ipfix-info XML schema. now they all point to this document 🎉

[RFC5102] still gives historical context for the initial entries in the "IPFIX Information Elements" registry 🕰️ so IANA kept [RFC5102] as the requestor for the Information Elements that list it as their requestor, and added this explanatory note to the registry:

"RFC 7012 has obsoleted RFC 5102; references to RFC 5102 in this
registry remain as part of the historical record".

The Information Element Specification Template (Section 2.1) needs two new columns that weren't in [RFC5102] 📊 IANA made a new Revision column in the "IPFIX Information Elements" registry and set the Revision of existing Information Elements to 0 🔢 it also made a new Date column and set the Date of all existing Information Elements to the publication date of this document 📅

to mark Information Elements with identifiers 127 or below as NetFlow version 9 [RFC3954] compatible, IANA set the Name of all existing Reserved Information Elements with identifier 127 or less to "Assigned for NetFlow v9 compatibility" 🏷️ and set the Reference of those Information Elements to [RFC3954] 🔗

since IANA now has change control of the schema for the IANA "IPFIX Information Elements" registry [IANA-IPFIX], it deprecated the old XML schema for describing Information Elements, urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] 🗑️

to support the process in Section 7.4, IANA set up a mailing list for talking with the IE-DOCTORS, called ie-doctors@ietf.org 📬

the rest of the subsections in this section have no actions for IANA 🌈

7.1. IPFIX Information Elements

this document refers to Information Elements, for which the Internet Assigned Numbers Authority (IANA) created the IPFIX "Information Elements" registry [IANA-IPFIX] 🗃️ the columns of this registry must, at minimum, be able to store the information defined in the template in Section 2.1 🧾 it can hold other info too if the registry needs it for management 💅

the process for making additions or other changes to the "IPFIX Information Elements" registry is in Section 7.4 🔍

7.2. MPLS Label Type Identifier

okay bestie, Information Element #46, named mplsTopLabelType, is the one that carries MPLS label types 🏷️✨. Right now there are 5 different types defined. To keep this extensible (very future-proof, very iconic 💅), IANA made a brand new subregistry just for MPLS label types and filled it with the starter list from the description of Information Element #46, mplsTopLabelType.

New MPLS label types get handed out by IANA through Expert Review [RFC5226], which means a group of experts picked by an IETF Area Director reviews them 🧐. Those experts have to double-check each new label type against the ones already defined for completeness, accuracy, and redundancy, so no duplicate drama allowed 🙅‍♀️. And the specification of any new MPLS label type MUST be published using a well-established and persistent publication medium 📚🔒.

7.3. XML Namespace and Schema

this one's a little throwback 🕰️. The older version of this doc [RFC5102] specified an XML schema for IPFIX Information Element definitions [IPFIX-XML-SCHEMA], and that schema was used to generate the document text itself. When the IANA "IPFIX Information Elements" registry [IANA-IPFIX] was created, change control on the registry and on the schema used to validate it passed over to IANA 🤝.

A machine-readable registry is what lets IPFIX tools automatically adapt to extensions to the information model 🤖. But XML is not mandatory for deploying IPFIX, ngl. Exporting Processes don't produce or consume XML as part of their operation at all 🙌. IPFIX Collectors MAY take advantage of the machine-readability of the information model, instead of hard-coding their behavior or inventing proprietary means for handling extensions. BUT, to avoid piling unnecessary load onto the IANA infrastructure serving the registry, Collectors SHOULD NOT poll the IANA registry [IANA-IPFIX] directly at runtime 🙏💀.

The reference to the current schema is embedded in the registry [IANA-IPFIX], and this schema may change from time to time as necessary to support the maintenance of the registry 🔄. So the schema urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in [RFC5102] has been deprecated 🪦.

7.4. Addition, Revision, and Deprecation

Let's talk about how entries get added, changed, and retired in the "IPFIX Information Elements" registry 📋✨. New assignments are administered by IANA through Expert Review [RFC5226]. These experts are called IE-DOCTORS 🩺, they're appointed by the IESG, and the process they follow is defined in [RFC7013].

Information Element identifiers in the range of 1-127 are compatible with field types used by NetFlow version 9 [RFC3954] for historical reasons 🕰️. They must not be assigned unless the Information Element is compatible with the NetFlow version 9 protocol, as determined by one of the IE-DOCTORS designated by the IESG as a NetFlow version 9 expert. very strict, very iconic 👑.

Future assignments that need subregistries for enumerated values (e.g., Section 7.2) must have those subregistries added at the same time as the new assignment 🧩. Additions to these subregistries must be subject to Expert Review [RFC5226]. Unless it's specified at assignment time, the experts for the subregistry will be the same as for the "IPFIX Information Elements" registry as a whole 🫶.

When IANA gets a request to add, revise, or deprecate an Information Element in the "IPFIX Information Elements" registry, it forwards the request to the IE-DOCTORS for review 📨.

When IANA gets an approval from the IE-DOCTORS for a request to add an Information Element definition, it adds that Information Element to the registry 🎉. The approved request may include changes made by the requestor and/or reviewers compared to the original request.

When IANA gets an approval for a request to revise an Information Element definition, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate ✏️. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the revision will require IETF consensus as well.

When IANA gets an approval for a request to deprecate an Information Element definition, it changes that Information Element's definition in the registry and updates the Revision and Date columns as appropriate 🪦. The approved request may include changes from the original request. If the original Information Element was added to the registry with IETF consensus (i.e., was defined by an RFC), the deprecation will require IETF consensus as well.

8. Security Considerations 🔐

this section is serious business, bestie 😭. The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may, for privacy or business issues, be considered sensitive information 🕵️‍♀️.

For example, exporting values of header fields may make attacks possible for the receiver of this information. This would otherwise only be possible for direct observers of the reported Flows along the data path 👀.

The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information 🛡️. These protocols are defined in separate documents, specifically the IPFIX protocol document [RFC7011] 📄.

9. Acknowledgments 🫶

This document is substantially based on [RFC5102], and the editors thank the authors of that document 💖. Those authors are listed below as contributors. Special thanks go to Paul Aitken for the detailed review 🌟. Finally, the authors thank the IPFIX WG chairs: Nevil Brownlee and Juergen Quittek 🙏.

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [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.

10.2. Informative References

  • [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix/>.
  • [IEEE.754.2008] Institute of Electrical and Electronics Engineers, "IEEE Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008.
  • [IEEE.802-3.2012] Institute of Electrical and Electronics Engineers, "IEEE Standard for Ethernet", IEEE Standard 802.3, 2012.
  • [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell, "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Work in Progress, July 2013.
  • [IPFIX-XML-SCHEMA] IANA, "IETF XML Registry", <http://www.iana.org/assignments/xml-registry/>.
  • [ISO.10646] International Organization for Standardization, "Information technology - Universal Coded Character Set (UCS)", ISO/IEC 10646:2012, November 2012.
  • [IANA-PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
  • [RFC20] Cerf, V., "ASCII format for Network Interchange", RFC 20, October 1969.
  • [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
  • [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
  • [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
  • [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
  • [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
  • [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
  • [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
  • [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
  • [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
  • [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, 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.
  • [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.
  • [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
  • [RFC6615] Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 6615, June 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.

Contributors 🌸

Juergen Quittek 💜

Juergen Quittek
NEC
Kurfuersten-Anlage 36
Heidelberg 69115
Germany

Phone: +49 6221 90511-15
EMail: quittek@nw.neclab.eu
URI:   http://www.neclab.eu/

Stewart Bryant 🦋

Stewart Bryant
Cisco Systems, Inc.
10 New Square, Bedfont Lakes
Feltham, Middlesex  TW18 8HA
United Kingdom

EMail: stbryant@cisco.com

Paul Aitken 🍓

Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Edinburgh EH6 6LX
Scotland

Phone: +44 131 561 3616
EMail: paitken@cisco.com

Jeff Meyer 🧚

Jeff Meyer
PayPal
2211 N. First St.
San Jose, CA  95131-2021
US

Phone: +1 408 976-9149
EMail: jemeyer@paypal.com
URI:   http://www.paypal.com

Authors' Addresses 💌

okay so this is the very last bit, and it's where you find the two editors, bestie 🦋 Benoit Claise and Brian Trammell, both legends in the protocol world. Here's how to reach them:

Benoit Claise (editor) 🌸

Benoit Claise (editor)
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium

Phone: +32 2 704 5622
EMail: bclaise@cisco.com

Brian Trammell (editor) 💜

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

Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch

the end 🌈✨

📦 where this page comes from