RFC 9710
Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry
RFC 9710: Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry 🎀
okay bestie, RFC 9710 is a Standards Track doc (so it's real, official IETF stuff 💅) published in February 2025, ISSN 2070-1721. It was written by M. Boucadair of Orange and B. Claise of Huawei. The title block doesn't list anything it obsoletes or updates, but Section 1 explains what it does and doesn't touch 👀
Abstract 💖
This doc gives simple fixes to the IANA "IP Flow Information Export (IPFIX) Entities" registry. It fixes shortcomings in the descriptions of some Information Elements (IEs), makes sure the entries cite an existing IANA registry in a consistent way, and repairs broken pointers and orphaned section references, etc. It also brings some consistency across the registry entries ✨
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Info about the current status of this document, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc9710 🔗
Copyright Notice ©️
Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🧚
1. Introduction
2. Conventions and Definitions
3. Why an RFC Is Needed for These Updates
4. Update the Descriptions in the IANA Registry
4.1. sourceTransportPort
4.2. destinationTransportPort
4.3. forwardingStatus
4.4. collectorTransportPort
4.5. exporterTransportPort
5. Point to an Existing IANA Registry
6. Consistent Citation of IANA Registries
6.1. mplsTopLabelType
6.2. classificationEngineId
6.3. flowEndReason
6.4. natOriginatingAddressRealm
6.5. natEvent
6.6. firewallEvent
6.7. biflowDirection
6.8. observationPointType
6.9. anonymizationTechnique
6.10. natType
6.11. selectorAlgorithm
6.12. informationElementDataType
6.13. informationElementSemantics
6.14. informationElementUnits
6.15. portRangeStart
6.16. portRangeEnd
6.17. ingressInterfaceType
6.18. egressInterfaceType
6.19. valueDistributionMethod
6.20. flowSelectorAlgorithm
6.21. dataLinkFrameType
6.22. mibCaptureTimeSemantics
6.23. natQuotaExceededEvent
6.24. natThresholdEvent
7. Miscellaneous Updates
7.1. collectionTimeMilliseconds
7.2. messageMD5Checksum
7.3. anonymizationFlags
7.4. informationElementDescription
7.5. distinctCountOfDestinationIPAddress
7.6. externalAddressRealm
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
So when the Operations and Management Area Working Group (OPSAWG) was looking at [RFC9565], which obsoletes [RFC7125], the WG noticed that some parts of the IANA "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX] weren't up to date 😭 This doc updates the registry and makes the entries more consistent with each other.
As discussed with IANA while working on [RFC9487], the "Additional Information" entry in [IANA-IPFIX] should contain a link to an existing registry when that applies, instead of doing either of these:
- A link to an existing registry in the "Description" entry.
- The registry's detailed values repeated in the "Description" entry. This is messy because the description has to be updated every time the registry changes.
So this doc lists a bunch of simple fixes to the IPFIX registry [IANA-IPFIX]. They're sorted like this:
- Updates that fix a shortcoming in the description of an IE (Section 4).
- Updates that add a pointer to an existing IANA registry (Section 5).
- Updates that make the structure consistent when calling an existing IANA registry (Section 6).
- Miscellaneous updates that fix broken pointers, orphaned section references, etc. (Section 7).
These updates also make it easier to automatically pull the values out of IANA registries (e.g., with a cron job). Collectors need that so they can support new IPFIX IEs and, more importantly, correctly interpret new values in the registries those IEs point to 🧠
Quick note: as per Section 5 of [RFC7012], [IANA-IPFIX] is the normative reference for the IPFIX IEs that were defined in [RFC5102]. So the updates in this document don't update any part of [RFC7011] 🙅♀️
Likewise, this document is not marked as formally updating [RFC5477], [RFC5610], [RFC5655], [RFC6235], [RFC6759], [RFC7014], [RFC7015], [RFC7133], [RFC7270], [RFC8038], and [RFC8158].
2. Conventions and Definitions 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This doc uses the IPFIX-specific terminology (Information Element, Template, Collector, Data Record, Flow Record, Exporting Process, Collecting Process, etc.) defined in Section 2 of [RFC7011]. Just like in [RFC7011], these IPFIX-specific terms have the first letter of each word capitalized 🌸
3. Why an RFC Is Needed for These Updates 🤔
A lot of the edits in this doc could be handled by the IPFIX Experts (informally called the IE-DOCTORS [RFC7013]). But a lot of the affected IEs were created through the IETF stream, so the following from Section 5.1 of [RFC7013] applies:
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.
4. Update the Descriptions in the IANA Registry 🛠️
Here's the part where we actually fix the descriptions, one IE at a time 💅
4.1. sourceTransportPort 🔌
4.1.1. OLD
This is the current sourceTransportPort entry, copied exactly:
Description: The source port identifier in the transport header.
For the transport protocols UDP, TCP, and SCTP, this is the source
port number given in the respective header. This field MAY also
be used for future transport protocols that have 16-bit source
port identifiers.
Additional Information: See [RFC768] for the definition of the UDP
source port field.
See [RFC9293] for the definition of the TCP source port field.
See [RFC9260] for the definition of SCTP.
Additional information on defined UDP and TCP port numbers can be
found at [https://www.iana.org/assignments/service-names-port-
numbers].4.1.2. NEW
And here's the glow-up 🦋 with the new text:
Description: The source port identifier in the transport protocol
header. For transport protocols such as UDP, TCP, SCTP, and DCCP,
this is the source port number given in the respective header.
This field MAY also be used for future transport protocols that
have 16-bit source port identifiers.
Additional Information: See [RFC768] for the definition of the UDP
source port field.
See [RFC9293] for the definition of the TCP source port field.
See [RFC9260] for the definition of the SCTP source port number
field.
See [RFC4340] for the definition of the DCCP source port field.
See the assigned transport protocol (e.g., UDP, TCP, SCTP, and
DCCP) port numbers [https://www.iana.org/assignments/service-
names-port-numbers].4.2. destinationTransportPort 🎯
4.2.1. OLD
Here's the current destinationTransportPort entry, exactly as it is:
Description: The destination port identifier in the transport
header. For the transport protocols UDP, TCP, and SCTP, this is
the destination port number given in the respective header. This
field MAY also be used for future transport protocols that have
16-bit destination port identifiers.
Additional Information: See [RFC768] for the definition of the UDP
source port field.
See [RFC9293] for the definition of the TCP source port field.
See [RFC9260] for the definition of SCTP.
Additional information on defined UDP and TCP port numbers can be
found at https://www.iana.org/assignments/service-names-port-
numbers.4.2.2. NEW
And the fixed version 🌈
Description: The destination port identifier in the transport
protocol header. For transport protocols such as UDP, TCP, SCTP,
and DCCP, this is the destination port number given in the
respective header. This field MAY also be used for future
transport protocols that have 16-bit destination port identifiers.
Additional Information: See [RFC768] for the definition of the UDP
destination port field.
See [RFC9293] for the definition of the TCP destination port
field.
See [RFC9260] for the definition of the SCTP destination port
number field.
See [RFC4340] for the definition of the DCCP destination port
field.
See the assigned transport protocol (e.g., UDP, TCP, SCTP, and
DCCP) port numbers [https://www.iana.org/assignments/service-
names-port-numbers].4.3. forwardingStatus 🚦
The current forwardingStatus entry in [IANA-IPFIX] doesn't match what [RFC7270] provides, and that's a whole mood 😤 The registered Abstract Data Type is unsigned8, but it must be unsigned32. The update below fixes that. The description is also updated to make the use of the reduced-size encoding clear, as per Section 6.2 of [RFC7011] ✨
4.3.1. OLD
This is the forwardingStatus entry, copied exactly with its diagram and examples:
Description: This Information Element describes the forwarding
status of the flow and any attached reasons.
The layout of the encoding is as follows:
MSB - 0 1 2 3 4 5 6 7 - LSB
+---+---+---+---+---+---+---+---+
| Status| Reason code or flags |
+---+---+---+---+---+---+---+---+
See the Forwarding Status sub-registries at
[Forwarding-Status].
Examples:
value : 0x40 = 64
binary: 01000000
decode: 01 -> Forward
000000 -> No further information
value : 0x89 = 137
binary: 10001001
decode: 10 -> Drop
001001 -> Bad TTL
Additional Information: See "NetFlow Version 9 Flow-Record Format"
[CCO-NF9FMT].
Abstract Data Type: unsigned8🦋 to be continued in part 2 🦋
4.3.2. NEW ✨
Description: okay bestie, this Information Element tells you the forwarding status of the flow and any reasons attached to it 💅 IPFIX reduced-size encoding is used as required 🎀
ngl there's a structure tied to the least-significant byte 🦋 future versions may be defined to give meaning to the remaining bits, so keep an eye out 👀 the current version of the Information Element should be exported as unsigned8 💖
the layout of the encoding goes like this 🧚
MSB - 0 1 2 3 4 5 6 7 - LSB
+---+---+---+---+---+---+---+---+
| Status| Reason code or flags |
+---+---+---+---+---+---+---+---+Examples:
value : 0x40 = 64
binary: 01000000
decode: 01 -> Forward
000000 -> No further information
value : 0x89 = 137
binary: 10001001
decode: 10 -> Drop
001001 -> Bad TTLAdditional Information: see "NetFlow Version 9 Flow-Record Format" [CCO-NF9FMT] 📚 and also the "Forwarding Status (Value 89)" registry [https://www.iana.org/assignments/ipfix] 🌸
Abstract Data Type: unsigned32 🍓
4.4. collectorTransportPort 🦋
4.4.1. OLD
Description: this is the destination port identifier that the Exporting Process sends Flow information to 🎀 for the transport protocols UDP, TCP, and SCTP, it's the destination port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers 💜
Additional Information: see [RFC768] for the definition of the UDP source port field 🌈
see [RFC9293] for the definition of the TCP source port field 🫶
see [RFC9260] for the definition of SCTP 🧚
more info on defined UDP and TCP port numbers is at https://www.iana.org/assignments/service-names-port-numbers ✨
4.4.2. NEW
Description: same energy, just cleaner 💅 this is the destination port identifier that the Exporting Process sends Flow information to. For transport protocols such as UDP, TCP, and SCTP, it's the destination port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers 🎀
Additional Information: see [RFC768] for the definition of the UDP destination port field 🦋
see [RFC9293] for the definition of the TCP destination port field 💖
see [RFC9260] for the definition of the SCTP destination port number field 🧚
see the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers at https://www.iana.org/assignments/service-names-port-numbers 🌸
4.5. exporterTransportPort 🌈
4.5.1. OLD
Description: this is the source port identifier that the Exporting Process sends Flow information from 💜 for the transport protocols UDP, TCP, and SCTP, it's the source port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers. This field may be useful for distinguishing multiple Exporting Processes that use the same IP address 👀
Additional Information: see [RFC768] for the definition of the UDP source port field ✨
see [RFC9293] for the definition of the TCP source port field 🫶
see [RFC9260] for the definition of SCTP 🍓
more info on defined UDP and TCP port numbers is at https://www.iana.org/assignments/service-names-port-numbers 💅
4.5.2. NEW
Description: this is the source port identifier that the Exporting Process sends Flow information from. For transport protocols such as UDP, TCP, and SCTP, it's the source port number. This field MAY also be used for future transport protocols that have 16-bit source port identifiers 🎀
Additional Information: see [RFC768] for the definition of the UDP source port field 🦋
see [RFC9293] for the definition of the TCP source port field 💖
see [RFC9260] for the definition of the SCTP source port number field 🧚
see the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers at https://www.iana.org/assignments/service-names-port-numbers 🌸
5. Point to an Existing IANA Registry 👑
IANA has updated the following entries by adding the indicated "Additional Information" to the [IANA-IPFIX] registry 💅 (In Table 1, "ID" refers to "ElementID".)
+===+=========================+=====================================+
|ID | Name | Additional Information |
+===+=========================+=====================================+
|32 | icmpTypeCodeIPv4 | See the "ICMP Type Numbers" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | icmp-parameters] |
+---+-------------------------+-------------------------------------+
|33 | igmpType | See the "IGMP Type Numbers" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | igmp-type-numbers] |
+---+-------------------------+-------------------------------------+
|139| icmpTypeCodeIPv6 | See the "ICMPv6 'type' Numbers" |
| | | and "ICMPv6 'Code' Fields" |
| | | registries |
| | | [https://www.iana.org/assignments/ |
| | | icmpv6-parameters] |
+---+-------------------------+-------------------------------------+
|176| icmpTypeIPv4 | See the "ICMP Type Numbers" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | icmp-parameters] |
+---+-------------------------+-------------------------------------+
|177| icmpCodeIPv4 | See the "ICMP Type Numbers" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | icmp-parameters] |
+---+-------------------------+-------------------------------------+
|178| icmpTypeIPv6 | See the "ICMPv6 'type' Numbers" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | icmpv6-parameters] |
+---+-------------------------+-------------------------------------+
|179| icmpCodeIPv6 | See the "ICMPv6 'Code' Fields" |
| | | registry |
| | | [https://www.iana.org/assignments/ |
| | | icmpv6-parameters] |
+---+-------------------------+-------------------------------------+
|346| privateEnterpriseNumber | See the "Private Enterprise |
| | | Numbers (PENs)" registry |
| | | [https://www.iana.org/assignments/ |
| | | enterprise-numbers] |
+---+-------------------------+-------------------------------------+Table 1: Cite an IANA Registry Under Additional Information
6. Consistent Citation of IANA Registries 🧁
IANA has updated the "IP Flow Information Export (IPFIX) Entities" registry [IANA-IPFIX] for each of the IE entries listed in the following subsections 💖
6.1. mplsTopLabelType 🦋
6.1.1. OLD
Description: this field identifies the control protocol that allocated the top-of-stack label 🎀 values for this field are listed in the MPLS label type registry 🌈
see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type 👀
Additional Information: see [RFC3031] for the MPLS label structure ✨
see the list of MPLS label types assigned by IANA at https://www.iana.org/assignments/mpls-label-values 🧚
6.1.2. NEW
Description: this field identifies the control protocol that allocated the top-of-stack label 💅 values for this field are listed in the MPLS label type registry 🌸
Additional Information: see the IPFIX MPLS label type (Value 46) [https://www.iana.org/assignments/ipfix] 🍓
see [RFC3031] for the MPLS label structure 💜
6.2. classificationEngineId 🌈
6.2.1. OLD
Description: a unique identifier for the engine that determined the Selector ID 🫶 thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments 👑
values for this field are listed in the Classification Engine IDs registry 💅 see https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids ✨
6.2.2. NEW
Description: a unique identifier for the engine that determined the Selector ID 💖 thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments 🦋
values for this field are listed in the Classification Engine IDs registry 🎀
Additional Information: see the "Classification Engine IDs (Value 101)" registry [https://www.iana.org/assignments/ipfix] 🧚
6.3. flowEndReason 🌸
6.3.1. OLD
Description: this is the reason for Flow termination 🍓 values are listed in the flowEndReason registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason 💜
6.3.2. NEW
Description: this is the reason for Flow termination ✨ values are listed in the flowEndReason registry 🌈
Additional Information: see the "flowEndReason (Value 136)" registry [https://www.iana.org/assignments/ipfix] 👀
6.4. natOriginatingAddressRealm 🫶
6.4.1. OLD
Description: indicates whether the session was created because traffic originated in the private or public address realm 💅 postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective 🎀
values are listed in the natOriginatingAddressRealm registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm 🦋
Additional Information: see [RFC3022] for the definition of NAT 🧚
6.4.2. NEW
Description: indicates whether the session was created because traffic originated in the private or public address realm 💖 postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective 🌸
values are listed in the natOriginatingAddressRealm registry 🍓
Additional Information: see the "natOriginatingAddressRealm (Value 229)" registry [https://www.iana.org/assignments/ipfix] 💜
see [RFC3022] for the definition of NAT 🌈
6.5. natEvent 👑
6.5.1. OLD
Description: ✨ okay so this IE tells you what kind of NAT event happened 🦋 Think NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. (those are examples, not a full list, bestie 💅). The values live in the "NAT Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type.
Additional Information: Go check [RFC3022] for what NAT is 🌸
Then peep [RFC3234] for middleboxes 🧚
And [RFC8158] has the deets for values 4-16 💜
6.5.2. NEW
Description: Still the same vibe 🎀 This IE identifies a NAT event and tells you the type. Examples include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry.
Additional Information: See the "NAT Event Type (Value 230)" registry [https://www.iana.org/assignments/ipfix] 🦋
Also [RFC3022] for the definition of NAT 🌸
And [RFC8158] for the definitions of values 4-16 💜
6.6. firewallEvent
6.6.1. OLD
Description: Indicates a firewall event 🔥 Allowed values are listed in the firewallEvent registry.
See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event 🫶
6.6.2. NEW
Description: Indicates a firewall event 🔥 Allowed values are listed in the firewallEvent registry.
Additional Information: See the "firewallEvent (Value 233)" registry [https://www.iana.org/assignments/ipfix] ✨
6.7. biflowDirection
6.7.1. OLD
Description: Okay this one is lowkey a lot 👑 It's a description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element MAY be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. 🙈
Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element SHOULD appear in each Flow Record. 💀
Values are listed in the biflowDirection registry. See [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction] 🦋
6.7.2. NEW
Description: Same energy, just tidier 🎀 A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element MAY be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band.
Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element SHOULD appear in each Flow Record.
Values are listed in the biflowDirection registry.
Additional Information: See the "biflowDirection (Value 239)" registry [https://www.iana.org/assignments/ipfix] 💖
6.8. observationPointType
6.8.1. OLD
Description: Type of observation point 👀 Values are listed in the observationPointType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type 🌈
6.8.2. NEW
Description: Type of observation point 👀 Values are listed in the observationPointType registry.
Additional Information: See the "observationPointType (Value 277)" registry [https://www.iana.org/assignments/ipfix] 🧚
6.9. anonymizationTechnique
6.9.1. OLD
Description: So this is the anonymization technique applied to a referenced Information Element within a referenced Template 🫣 Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique 🔐
6.9.2. NEW
Description: Same as before, bestie 💅 A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry.
Additional Information: See the "anonymizationTechnique (Value 286)" registry [https://www.iana.org/assignments/ipfix/] 🔐
6.10. natType
6.10.1. OLD
Description: Values are listed in the natType registry 🦋
See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type ✨
Additional Information: Okay the NAT lineup is giving 👑 [RFC3022] for NAT 🌸 [RFC1631] for NAT44 💖 [RFC6144] for NAT64 🌈 [RFC6146] for NAT46 🦋 [RFC6296] for NAT66 🧚 [RFC791] for IPv4 ⭐ and [RFC8200] for IPv6 💜
6.10.2. NEW
Description: This Information Element identifies the NAT type applied to packets of the Flow 🎀
Values are listed in the natType registry.
Additional Information: See the "natType (Value 297)" registry [https://www.iana.org/assignments/ipfix] ✨
See [RFC3022] for the definition of NAT (commonly named NAT44) 🌸
See [RFC6144] for the definition of NAT46 🦋
See [RFC6146] for the definition of NAT64 🧚
See [RFC6296] for the definition of NPTv6 💜
See [RFC791] for the definition of IPv4 ⭐
See [RFC8200] for the definition of IPv6 👑
6.11. selectorAlgorithm
6.11.1. OLD
Description: This one is about the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process 🍓 Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. The methods listed below are defined in [RFC5475]. For their parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters. 🧠
The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters.
There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified. 🙃
6.11.2. NEW
Description: Same packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process 🍓 Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all of their parameters. For the methods parameters, Information Elements are defined in the IPFIX registry [IANA-IPFIX]. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list. It might be necessary to define new Information Elements to specify their parameters.
There is a broad variety of possible parameters that could be used for Property Match Filtering (5) but currently there are no agreed parameters specified. 🙃
Additional Information: See the "Packet Sampling (PSAMP) Parameters" registry [https://www.iana.org/assignments/psamp-parameters] 🦋
6.12. informationElementDataType
Note that the "informationElementDataType" registry has been renamed as the "IPFIX Information Element Data Types" registry. 📣
6.12.1. OLD
Description: A description of the abstract data type of an IPFIX information element 🧁 These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify. 🔒
6.12.2. NEW
Description: A description of the abstract data type of an IPFIX information element 🧁 These are taken from the abstract data types defined in Section 3.1 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the "IPFIX Information Element Data Types" registry. These types are registered in the "IPFIX Information Element Data Types" registry.
The "IPFIX Information Element Data Types" registry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol; as such, modifications require Standards Action [RFC8126]. 🔒
Additional Information: See the "IPFIX Information Element Data Types" registry [https://www.iana.org/assignments/ipfix] 💖
6.13. informationElementSemantics
6.13.1. OLD
Description: A description of the semantics of an IPFIX Information Element 🌟 These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model [RFC5102]; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify. 🫶
6.13.2. NEW ✨
Description: okay so this one is about the semantics of an IPFIX Information Element 💅 These are borrowed from the data type semantics in Section 3.2 of the IPFIX Information Model [RFC5102], so check that section if you want the deets on the types in the "IPFIX Information Element Semantics" registry 📖 This field can take the values from that registry. The special value 0x00 (default) means no semantics apply to the field, and a Collecting Process or File Reader that doesn't understand it a priori can't manipulate it 🙈
The "IPFIX Information Element Semantics" registry is only there to hand out numbers for semantics names. It's NOT a way to bolt new semantics onto the IPFIX Protocol, so changing it needs a Standards Action [RFC8126] 🔒
Additional Information: see the "IPFIX Information Element Semantics" registry [https://www.iana.org/assignments/ipfix] 🧚
6.14. informationElementUnits 🌸
Heads up, the "informationElementsUnits" registry got a glow-up and is now called the "IPFIX Information Element Units" registry 💖
6.14.1. OLD
Description: this is the units bit for an IPFIX Information Element 📏 These match the units that are implicitly defined in the Information Element definitions in section 5 of the IPFIX Information Model [RFC5102], so peek at that section for more on the types in the informationElementsUnits subregistry. The field can take the values in Table 3 below, and the special value 0x00 (none) means the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.
6.14.2. NEW ✨
Description: same energy, just cleaner 🧼 This is the units description for an IPFIX Information Element. These match the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model [RFC5102]. Look there for more on the types in the "IPFIX Information Element Units" registry. These types can take the values in that registry, and the special value 0x00 (none) means the field is unitless.
Additional Information: see the "IPFIX Information Element Units" registry [https://www.iana.org/assignments/ipfix] 🎀
6.15. portRangeStart 🦋
6.15.1. OLD
Description: this is the port number where a range of ports starts 🚪 A value of zero means the range start isn't specified, ie the range is defined some other way. More info on defined TCP port numbers lives at https://www.iana.org/assignments/service-names-port-numbers 🔎
6.15.2. NEW ✨
Description: the port number where a range of port numbers starts 🚪 A value of zero means the range start isn't specified, i.e., the range is defined some other way.
Additional Information: see the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers [https://www.iana.org/assignments/service-names-port-numbers] 🧚
6.16. portRangeEnd 🌈
6.16.1. OLD
Description: this is the port number where a range of ports ends 🏁 A value of zero means the range end isn't specified, ie the range is defined some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers 🫶
6.16.2. NEW ✨
Description: the port number where a range of port numbers ends 🏁 A value of zero means the range end isn't specified, i.e., the range is defined some other way.
Additional Information: see the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers [https://www.iana.org/assignments/service-names-port-numbers] 💜
6.17. ingressInterfaceType 🚀
6.17.1. OLD
Description: this is the type of interface where packets of this Flow are being received 📥 The value matches the value of managed object ifType as defined in https://www.iana.org/assignments/ianaiftype-mib.
Additional Information: https://www.iana.org/assignments/ianaiftype-mib
6.17.2. NEW ✨
Description: the type of interface where packets of this Flow are being received 📥 The value matches the value of managed object ifType.
Additional Information: see the "IANAifType-MIB" registry [https://www.iana.org/assignments/ianaiftype-mib] 🧁
6.18. egressInterfaceType 🍓
6.18.1. OLD
Description: this is the type of interface where packets of this Flow are being sent 📤 The value matches the value of managed object ifType as defined in https://www.iana.org/assignments/ianaiftype-mib.
Additional Information: https://www.iana.org/assignments/ianaiftype-mib
6.18.2. NEW ✨
Description: the type of interface where packets of this Flow are being sent 📤 The value matches the value of managed object ifType.
Additional Information: see the "IANAifType-MIB" registry [https://www.iana.org/assignments/ianaiftype-mib] 🧁
6.19. valueDistributionMethod 🌷
6.19.1. OLD
Description: this describes how counters from Contributing Flows get spread out into the Aggregated Flow records in an associated scope (usually a Template) 🧩 The method applies to all the non-key Information Elements in the referenced scope where value distribution is a valid operation. If originalFlowsInitiated and/or originalFlowsCompleted show up in the Template, they're exempt, because each one infers its own distribution method 🙅♀️ The valueDistributionMethod registry is meant to list a complete set of possible value distribution methods.
See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method 🔗
6.19.2. NEW ✨
Description: this describes how counters from Contributing Flows get distributed into the Aggregated Flow records in an associated scope, usually a Template 🧩 The method applies to all the non-key Information Elements in the referenced scope where value distribution is a valid operation. If originalFlowsInitiated and/or originalFlowsCompleted appear in the Template, they're not subject to this method, since each one infers its own distribution method 🙅♀️ The "valueDistributionMethod (Value 384)" registry is meant to list a complete set of possible value distribution methods.
Additional Information: see the "valueDistributionMethod (Value 384)" registry [https://www.iana.org/assignments/ipfix] 🌸
6.20. flowSelectorAlgorithm 🎯
6.20.1. OLD
Description: this Information Element names the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that the Intermediate Flow Selection Process applies 🎛️ Most of these techniques have parameters, and their configuration parameter(s) MUST be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. More method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters.
Please note that the purpose of the flow selection techniques described in this document is to improve the measurement functions defined in the Scope (Section 1) 📏
The Intermediate Flow Selection Process Techniques identifiers are defined at https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm 🗂️
6.20.2. NEW ✨
Description: this Information Element names the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that the Intermediate Flow Selection Process applies 🎛️ Most of these techniques have parameters, and their configuration parameter(s) MUST be clearly specified. Additional Information Elements are needed to fully specify packet selection with these methods and all of their parameters. Additional method identifiers may be added to the "flowSelectorAlgorithm (Value 390)" registry. It might be necessary to define new Information Elements to specify their parameters.
Additional Information: see the "flowSelectorAlgorithm (Value 390)" registry [https://www.iana.org/assignments/ipfix] 💅
6.21. dataLinkFrameType 🪞
6.21.1. OLD
Description: this Information Element says what type of data link frame was selected 🖼️ Data link types are defined in the dataLinkFrameType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type.
Further values may be assigned by IANA. Note that the assigned values are bits, so multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].
Additional Information: (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994)
6.21.2. NEW ✨
Description: this Information Element says what type of data link frame was selected 🖼️ Data link types are defined in the "dataLinkFrameType (Value 408)" registry.
Additional values may be assigned by IANA. Note that the assigned values are bits, so multiple observations can be OR'd together.
Additional Information: see the "dataLinkFrameType (Value 408)" registry [https://www.iana.org/assignments/ipfix] 🧚
More information about the data link layer can be found in (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994) 🌐
6.22. mibCaptureTimeSemantics ⏰
6.22.1. OLD
Description: this says when in the lifetime of the Flow the MIB value was pulled from the MIB for a mibObjectIdentifier ⏳ It tells you whether the exported value was collected closer to Flow creation or to Flow export time, and it refers to the Timestamp fields in the same Data Record.
This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP before the IPFIX Metering Process or Exporting Process retrieved it (so the data is already stale) and it matters exactly when it was sampled, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data [RFC6313]. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data 🧠
Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics 📋
6.22.2. NEW ✨
Description: okay so this one tells you when in the Flow's life the MIB value got pulled from the MIB for a mibObjectIdentifier 🕰️ It's how you figure out if the value you're exporting was collected closer to Flow creation or closer to Flow export time 👀 and it points back to the Timestamp fields in the same Data Record 💅
This field SHOULD be used when exporting a mibObjectValue that specifies counters or statistics 📊 If the MIB value was sampled by SNMP before the IPFIX Metering Process or Exporting Process goes and retrieves it (aka the data is already stale 🫠) and it matters to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data [RFC6313] ✨ Similarly, if different MIB capture times apply to different mibObjectValue elements in the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data 🎀
Values are listed in the "mibCaptureTimeSemantics (Value 448)" registry 🦋
Additional Information: See the "mibCaptureTimeSemantics (Value 448)" registry [https://www.iana.org/assignments/ipfix].
6.23. natQuotaExceededEvent 🚫
6.23.1. OLD 📜
Description: This Information Element identifies the type of a NAT Quota Exceeded event 🙅 Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event.
Additional Information: See [RFC791] for the definition of the IPv4 source address field.
See [RFC3022] for the definition of NAT.
See [RFC3234] for the definition of middleboxes.
6.23.2. NEW ✨
Description: This Information Element identifies the type of a NAT Quota Exceeded event 🙅 Values for this Information Element are listed in the "NAT Quota Exceeded Event Type (Value 466)" registry.
Additional Information: See the "NAT Quota Exceeded Event Type (Value 466)" registry [https://www.iana.org/assignments/ipfix].
See [RFC3022] for the definition of NAT.
6.24. natThresholdEvent 📈
6.24.1. OLD 📜
Description: This Information Element identifies a type of a NAT Threshold event 🚦 Values for this Information Element are listed in the "NAT Threshold Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event.
Additional Information: See [RFC791] for the definition of the IPv4 source address field.
See [RFC3022] for the definition of NAT.
See [RFC3234] for the definition of middleboxes.
6.24.2. NEW ✨
Description: This Information Element identifies a type of a NAT Threshold event 🚦 Values for this Information Element are listed in the "NAT Threshold Event Type (Value 467)" registry.
Additional Information: See the "NAT Threshold Event Type (Value 467)" registry [https://www.iana.org/assignments/ipfix]).
See [RFC3022] for the definition of NAT.
7. Miscellaneous Updates 🧁
IANA has updated the descriptions of the following entries in [IANA-IPFIX] 💖
7.1. collectionTimeMilliseconds ⏰
7.1.1. OLD 📜
Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element SHOULD be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below.
7.1.2. NEW ✨
Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element SHOULD be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element.
7.2. messageMD5Checksum 🔐
7.2.1. OLD 📜
Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message.
This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.
7.2.2. NEW ✨
Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message.
This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.
7.3. anonymizationFlags 🎭
7.3.1. OLD 📜
+--------+----------+-----------------------------------------------+
| bit(s) | name | description |
| (LSB = | | |
| 0) | | |
+--------+----------+-----------------------------------------------+
| 0-1 | SC | Stability Class: see the Stability Class |
| | | table below, and section Section 5.1. |
| 2 | PmA | Perimeter Anonymization: when set (1), |
| | | source- Information Elements as described in |
| | | [RFC5103] are interpreted as external |
| | | addresses, and destination- Information |
| | | Elements as described in [RFC5103] are |
| | | interpreted as internal addresses, for the |
| | | purposes of associating |
| | | anonymizationTechnique to Information |
| | | Elements only; see Section 7.2.2 for details. |
| | | This bit MUST NOT be set when associated with |
| | | a non-endpoint (i.e., source- or |
| | | destination-) Information Element. SHOULD be |
| | | consistent within a record (i.e., if a |
| | | source- Information Element has this flag |
| | | set, the corresponding destination- element |
| | | SHOULD have this flag set, and vice-versa.) |
+--------+----------+-----------------------------------------------+7.3.2. NEW ✨
+--------+----------+-----------------------------------------------+
| bit(s) | name | description |
| (LSB = | | |
| 0) | | |
+--------+----------+-----------------------------------------------+
| 0-1 | SC | Stability Class: see the Stability Class |
| | | table below, and Section 5.1 of [RFC6235]. |
| 2 | PmA | Perimeter Anonymization: when set (1), |
| | | source Information Elements as described in |
| | | [RFC5103] are interpreted as external |
| | | addresses, and destination Information |
| | | Elements as described in [RFC5103] are |
| | | interpreted as internal addresses, for the |
| | | purposes of associating |
| | | anonymizationTechnique to Information |
| | | Elements only; see Section 7.2.2 of [RFC6235] |
| | | for details. |
| | | This bit MUST NOT be set when associated with |
| | | a non-endpoint (i.e., source or |
| | | destination) Information Element. SHOULD be |
| | | consistent within a record (i.e., if a |
| | | source Information Element has this flag |
| | | set, the corresponding destination element |
| | | SHOULD have this flag set, and vice versa.) |
+--------+----------+-----------------------------------------------+7.4. informationElementDescription 🌸
7.4.1. OLD 📜
Description: A UTF-8 [RFC3629] encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription MAY be annotated with one or more language tags [RFC4646], encoded in-line [RFC2482] within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages MAY tag each section with its own language tag; in this case, the description information in each language SHOULD have equivalent meaning. In the absence of any language tag, the "i-default" [RFC2277] language SHOULD be assumed.
See the Security Considerations section for notes on string handling for Information Element type records.
7.4.2. NEW ✨
Description: A UTF-8 [RFC3629] encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription MAY be annotated with one or more language tags [RFC4646], encoded in-line [RFC2482] within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages MAY tag each section with its own language tag; in this case, the description information in each language SHOULD have equivalent meaning. In the absence of any language tag, the "i-default" [RFC2277] language SHOULD be assumed.
See Section 4 (Security Considerations) of [RFC5610] for notes on string handling for Information Element type records.
7.5. distinctCountOfDestinationIPAddress 🔢
7.5.1. OLD 📜
Description: The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters below, unless it is important to separate the counts by version.
7.5.2. NEW ✨
Description: The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters, unless it is important to separate the counts by version.
7.6. externalAddressRealm 🌈
7.6.1. OLD 🎀
Okay so this is the old version of the definition, and it's giving "look at the other spot for the real details" 💅 Description: This Information Element represents the external address realm where the packet is originated from or destined to. The detailed definition is in the internal address realm as specified above.
7.6.2. NEW ✨
The new version is way cuter and more streamlined 🦋 Description: This Information Element represents the external address realm where the packet is originated from or destined to.
See the internalAddressRealm IE for the detailed definition. 🧚
8. Security Considerations 🔐
Okay bestie, this one is short and sweet 🫶 This document does not add new security considerations to those already discussed for IPFIX in Section 8 of [RFC7012]. So if you want the full security tea, go check that section 👀
9. IANA Considerations 🌈
Sections 4 to 7 include actions for IANA. These actions are not repeated here. IANA has added a reference to this document for each of the entries updated per this document. 💜
IANA has updated the note in the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX] as follows:
OLD: The columns previously titled "References" and "Requester" have been renamed "Additional Information" and "Reference", respectively.
NEW: The columns previously titled "References" and "Requester" have been renamed "Additional Information" and "Reference", respectively.
The initial values for this registry were provided in [RFC5102]. [RFC7012] has obsoleted [RFC5102] and specifies that the current registry is the normative reference for these Information Elements. 🍓
IANA has added this document as a reference for the "IPFIX Information Elements" registry within the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX]. ⭐
IANA has also updated references to the "Service Name and Transport Protocol Port Number" consistently throughout the registry as follows:
OLD: Additional information on defined UDP and TCP port numbers can be found at http://www.iana.org/assignments/port-numbers.
NEW: See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers [https://www.iana.org/assignments/service-names-port-numbers]. 🦋
10. References 📚
10.1. Normative References 💖
- [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
https://www.iana.org/assignments/ipfix. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [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, DOI 10.17487/RFC7011, September 2013,
https://www.rfc-editor.org/info/rfc7011. - [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013,
https://www.rfc-editor.org/info/rfc7012. - [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, September 2013,
https://www.rfc-editor.org/info/rfc7013. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. 🌸
10.2. Informative References 📚
Okay bestie, these are the informative references, the extra reading that backs up the spec 💅 Every single one is listed below exactly as written, so nothing gets lost 🫶
[CCO-NF9FMT] Cisco, "NetFlow Version 9 Flow-Record Format", May 2011, https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, https://www.rfc-editor.org/info/rfc768.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, https://www.rfc-editor.org/info/rfc791.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, https://www.rfc-editor.org/info/rfc1321.
[RFC1631] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, May 1994, https://www.rfc-editor.org/info/rfc1631.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, January 1998, https://www.rfc-editor.org/info/rfc2277.
[RFC2482] Whistler, K. and G. Adams, "Language Tagging in Unicode Plain Text", RFC 2482, DOI 10.17487/RFC2482, January 1999, https://www.rfc-editor.org/info/rfc2482.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, https://www.rfc-editor.org/info/rfc3022.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, https://www.rfc-editor.org/info/rfc3031.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, https://www.rfc-editor.org/info/rfc3234.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, https://www.rfc-editor.org/info/rfc3629.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, https://www.rfc-editor.org/info/rfc4340.
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", RFC 4646, DOI 10.17487/RFC4646, September 2006, https://www.rfc-editor.org/info/rfc4646.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, January 2008, https://www.rfc-editor.org/info/rfc5102.
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, DOI 10.17487/RFC5103, January 2008, https://www.rfc-editor.org/info/rfc5103.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, https://www.rfc-editor.org/info/rfc5475.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, https://www.rfc-editor.org/info/rfc5477.
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, DOI 10.17487/RFC5610, July 2009, https://www.rfc-editor.org/info/rfc5610.
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, October 2009, https://www.rfc-editor.org/info/rfc5655.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, https://www.rfc-editor.org/info/rfc6144.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, https://www.rfc-editor.org/info/rfc6146.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, https://www.rfc-editor.org/info/rfc6235.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, https://www.rfc-editor.org/info/rfc6296.
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, https://www.rfc-editor.org/info/rfc6313.
[RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", RFC 6759, DOI 10.17487/RFC6759, November 2012, https://www.rfc-editor.org/info/rfc6759.
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, https://www.rfc-editor.org/info/rfc7014.
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, September 2013, https://www.rfc-editor.org/info/rfc7015.
[RFC7125] Trammell, B. and P. Aitken, "Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element", RFC 7125, DOI 10.17487/RFC7125, February 2014, https://www.rfc-editor.org/info/rfc7125.
[RFC7133] Kashima, S., Kobayashi, A., Ed., and P. Aitken, "Information Elements for Data Link Layer Traffic Measurement", RFC 7133, DOI 10.17487/RFC7133, May 2014, https://www.rfc-editor.org/info/rfc7133.
[RFC7270] Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10.17487/RFC7270, June 2014, https://www.rfc-editor.org/info/rfc7270.
[RFC8038] Aitken, P., Ed., Claise, B., S, S. B., McDowall, C., and J. Schoenwaelder, "Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol", RFC 8038, DOI 10.17487/RFC8038, May 2017, https://www.rfc-editor.org/info/rfc8038.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.
[RFC8158] Sivakumar, S. and R. Penno, "IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events", RFC 8158, DOI 10.17487/RFC8158, December 2017, https://www.rfc-editor.org/info/rfc8158.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022, https://www.rfc-editor.org/info/rfc9260.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, https://www.rfc-editor.org/info/rfc9293.
[RFC9487] Graf, T., Claise, B., and P. Francois, "Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)", RFC 9487, DOI 10.17487/RFC9487, November 2023, https://www.rfc-editor.org/info/rfc9487.
[RFC9565] Boucadair, M., "An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element", RFC 9565, DOI 10.17487/RFC9565, March 2024, https://www.rfc-editor.org/info/rfc9565.
Acknowledgments 💖
Huge thanks to Paul Aitken ✨ for the review and so many suggestions that made this spec way better 🙌 Special shoutout to Andrew Feren 🦋 for sharing data about scans of IPFIX data he collected, literal main character energy 👑
Thomas Graf 🔥 tagged an issue with the forwardingStatus Information Element and did the Shepherd review, iconic behaviour ngl 💅
Thanks to Éric Vyncke 🫶 for the review and comments!
Thanks to Qin Wu 🌸 for the opsdir review, Behcet Sarikaya 🧚 for the genart review, Martin Duke 🌈 for the tsvart review, Donald Eastlake 🍓 for the intdir review, and Hilarie Orman 💜 for the secdir review. The whole squad showed up 😭
Thanks to Mahesh Jethanandani ⭐ for the AD review.
Thanks to Éric Vyncke 💖 again for the IESG review, he really did not miss a thing 🙈
Authors' Addresses 🦋
Mohamed Boucadair Orange Email: mohamed.boucadair@orange.com
Benoit Claise Huawei Email: benoit.claise@huawei.com
📦 where this page comes from
- ietf: rfc9710 2025-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms