|
|
|
|
|
|
IETF RFC 9710
Last modified on Wednesday, February 26th, 2025
 Permanent link to RFC 9710
 Search GitHub Wiki for RFC 9710
 Show other RFCs mentioning RFC 9710
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9710 Orange
Category: Standards Track B. Claise
ISSN: 2070-1721 Huawei
February 2025
Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA
Registry
 Abstract
This document provides simple fixes to the IANA "IP Flow Information
Export (IPFIX) Entities" registry. Specifically, this document
provides updates to fix shortcomings in the description of some
Information Elements (IEs), to ensure a consistent structure when
citing an existing IANA registry, and to fix broken pointers,
orphaned section references, etc. The updates are also meant to
bring some consistency among the entries of the registry.
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.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/RFC 9710.
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' Addresses
1. Introduction
When the Operations and Management Area Working Group (OPSAWG) was
considering [RFC 9565], which obsoletes [RFC 7125], the WG realized
that some parts of the IANA "IP Flow Information Export (IPFIX)
Entities" registry [IANA-IPFIX] were not up to date. This document
updates the IANA registry and brings some consistency among the
entries of the registry.
As discussed with IANA during the development of [RFC 9487], the
"Additional Information" entry in [IANA-IPFIX] should contain a link
to an existing registry, when applicable, as opposed to having:
* A link to an existing registry in the "Description" entry.
* The registry detailed values repeated in the "Description" entry.
This practice has the drawback that the description must be
updated each time the registry is updated.
Therefore, this document lists a set of simple fixes to the IPFIX
registry [IANA-IPFIX]. These fixes are classified as follows:
* Updates to fix a shortcoming in the description of an IE
(Section 4).
* Updates to include a pointer to an existing IANA registry
(Section 5).
* Updates to ensure a consistent structure when calling an existing
IANA registry (Section 6).
* Miscellaneous updates to fix broken pointers, orphaned section
references, etc. (Section 7).
These updates are also meant to facilitate the automatic extraction
of the values maintained in IANA registries (e.g., with a cron job),
required by Collectors to be able to support new IPFIX IEs and, more
importantly, adequately interpret new values in registries specified
by those IPFIX IEs.
Note that, as per Section 5 of [RFC 7012], [IANA-IPFIX] is the
normative reference for the IPFIX IEs that were defined in [RFC 5102].
Therefore, the updates in this document do not update any part of
[RFC 7011].
Likewise, this document is not marked as formally updating [RFC 5477],
[RFC 5610], [RFC 5655], [RFC 6235], [RFC 6759], [RFC 7014], [RFC 7015],
[RFC 7133], [RFC 7270], [RFC 8038], and [RFC 8158].
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 [RFC 2119] [RFC 8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the IPFIX-specific terminology (Information
Element, Template, Collector, Data Record, Flow Record, Exporting
Process, Collecting Process, etc.) defined in Section 2 of [RFC 7011].
As in [RFC 7011], these IPFIX-specific terms have the first letter of
a word capitalized.
3. Why an RFC Is Needed for These Updates
Many of the edits in this document may be handled by the IPFIX
Experts (informally called the IE-DOCTORS [RFC 7013]). However, and
given that many of the impacted IEs were created via the IETF stream,
the following from Section 5.1 of [RFC 7013] is followed:
| 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
4.1. sourceTransportPort
4.1.1. OLD
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 [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] 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
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 [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] for the definition of the SCTP source port number
field.
See [RFC 4340] 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
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 [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] 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
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 [RFC 768] for the definition of the UDP
destination port field.
See [RFC 9293] for the definition of the TCP destination port
field.
See [RFC 9260] for the definition of the SCTP destination port
number field.
See [RFC 4340] 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] deviates from what
is provided in [RFC 7270]. In particular, the registered Abstract
Data Type is unsigned8, while it must be unsigned32. The following
update fixes that issue. The description is also updated to clarify
the use of the reduced-size encoding as per Section 6.2 of [RFC 7011].
4.3.1. OLD
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
4.3.2. NEW
Description: This Information Element describes the forwarding
status of the flow and any attached reasons. IPFIX reduced-size
encoding is used as required.
A structure is currently associated with the least-significant
byte. Future versions may be defined to associate meanings with
the remaining bits.
The current version of the Information Element should be exported
as unsigned8.
The layout of the encoding is as follows:
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 TTL
Additional Information: See "NetFlow Version 9 Flow-Record Format"
[CCO-NF9FMT]. See the "Forwarding Status (Value 89)" registry
[https://www.iana.org/assignments/ipfix].
Abstract Data Type: unsigned32
4.4. collectorTransportPort
4.4.1. OLD
Description: The destination port identifier to which the Exporting
Process sends Flow information. For the transport protocols UDP,
TCP, and SCTP, this is the destination port number. This field
MAY also be used for future transport protocols that have 16-bit
source port identifiers.
Additional Information: See [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] 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.4.2. NEW
Description: The destination port identifier to which the Exporting
Process sends Flow information. For transport protocols such as
UDP, TCP, and SCTP, this is the destination port number. This
field MAY also be used for future transport protocols that have
16-bit source port identifiers.
Additional Information: See [RFC 768] for the definition of the UDP
destination port field.
See [RFC 9293] for the definition of the TCP destination port
field.
See [RFC 9260] for the definition of the SCTP destination port
number field.
See the assigned transport protocol (e.g., UDP, TCP, and SCTP)
port numbers [https://www.iana.org/assignments/service-names-port-
numbers].
4.5. exporterTransportPort
4.5.1. OLD
Description: The source port identifier from which the Exporting
Process sends Flow information. For the transport protocols UDP,
TCP, and SCTP, this is 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 [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] 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.5.2. NEW
Description: The source port identifier from which the Exporting
Process sends Flow information. For transport protocols such as
UDP, TCP, and SCTP, this is the source port number. This field
MAY also be used for future transport protocols that have 16-bit
source port identifiers.
Additional Information: See [RFC 768] for the definition of the UDP
source port field.
See [RFC 9293] for the definition of the TCP source port field.
See [RFC 9260] for the definition of the SCTP source port number
field.
See the assigned transport protocol (e.g., UDP, TCP, and SCTP)
port numbers [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 [RFC 3031] 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 [RFC 3031] 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: 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: 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 [RFC 3022] 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 [RFC 3022] for the definition of NAT.
6.5. natEvent
6.5.1. OLD
Description: This Information Element identifies a NAT event. This
IE identifies the type of a NAT event. Examples of NAT events
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, see https://www.iana.org/assignments/ipfix/
ipfix.xhtml#ipfix-nat-event-type.
Additional Information: See [RFC 3022] for the definition of NAT.
See [RFC 3234] for the definition of middleboxes.
See [RFC 8158] for the definitions of values 4-16.
6.5.2. NEW
Description: This Information Element identifies a NAT event. This
IE identifies the type of a NAT event. Examples of NAT events
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].
See [RFC 3022] for the definition of NAT.
See [RFC 8158] 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: 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: 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: 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. See
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-
anonymization-technique.
6.9.2. NEW
Description: 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: See [RFC 3022] for the definition of NAT.
See [RFC 1631] for the definition of NAT44.
See [RFC 6144] for the definition of NAT64.
See [RFC 6146] for the definition of NAT46.
See [RFC 6296] for the definition of NAT66.
See [RFC 791] for the definition of IPv4.
See [RFC 8200] for the definition of 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 [RFC 3022] for the definition of NAT (commonly named NAT44).
See [RFC 6144] for the definition of NAT46.
See [RFC 6146] for the definition of NAT64.
See [RFC 6296] for the definition of NPTv6.
See [RFC 791] for the definition of IPv4.
See [RFC 8200] for the definition of IPv6.
6.11. selectorAlgorithm
6.11.1. OLD
Description: This Information Element identifies 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 [RFC 5475]. 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: This Information Element identifies 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 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 [RFC 5102];
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
[RFC 8126] 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 [RFC 5102];
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 [RFC 8126].
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 [RFC 5102]; 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 [RFC 8126] to modify.
6.13.2. NEW
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 [RFC 5102]; see that
section for more information on the types defined in the "IPFIX
Information Element Semantics" registry. This field may take the
values in the "IPFIX Information Element 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.
The "IPFIX Information Element Semantics" registry is intended to
assign numbers for semantics names, not to provide a mechanism for
adding semantics to the IPFIX Protocol; as such, modifications
require Standards Action [RFC 8126].
Additional Information: See the "IPFIX Information Element
Semantics" registry [https://www.iana.org/assignments/ipfix].
6.14. informationElementUnits
Note that the "informationElementsUnits" registry has been renamed as
the "IPFIX Information Element Units" registry.
6.14.1. OLD
Description: A description of the units of an IPFIX Information
Element. These correspond to the units implicitly defined in the
Information Element definitions in section 5 of the IPFIX
Information Model [RFC 5102]; see that section for more information
on the types described in the informationElementsUnits
subregistry. This field may take the values in Table 3 below; the
special value 0x00 (none) is used to note that the field is
unitless. These types are registered in the [IANA IPFIX
Information Element Units] subregistry.
6.14.2. NEW
Description: A description of the units of an IPFIX Information
Element. These correspond to the units implicitly defined in the
Information Element definitions in Section 5 of the IPFIX
Information Model [RFC 5102]; see that section for more information
on the types described in the "IPFIX Information Element Units"
registry. These types can take the values in the "IPFIX
Information Element Units" registry. The special value 0x00
(none) is used to note that 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: The port number identifying the start of a range of
ports. A value of zero indicates that the range start is not
specified, ie the range is defined in some other way.
Additional information on defined TCP port numbers can be found at
https://www.iana.org/assignments/service-names-port-numbers.
6.15.2. NEW
Description: The port number identifying the start of a range of
port numbers. A value of zero indicates that the range start is
not specified, i.e., the range is defined in 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: The port number identifying the end of a range of
ports. A value of zero indicates that the range end is not
specified, ie the range is defined in 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 identifying the end of a range of port
numbers. A value of zero indicates that the range end is not
specified, i.e., the range is defined in 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: 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: 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: A description of the method used to distribute the
counters from Contributing Flows into the Aggregated Flow records
described by an associated scope, generally a Template. The
method is deemed to apply to all the non-key Information Elements
in the referenced scope for which value distribution is a valid
operation; if the originalFlowsInitiated and/or
originalFlowsCompleted Information Elements appear in the
Template, they are not subject to this distribution method, as
they each infer their own distribution method. The
valueDistributionMethod registry is intended 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: A description of the method used to distribute the
counters from Contributing Flows into the Aggregated Flow records
described by an associated scope, generally a Template. The
method is deemed to apply to all the non-key Information Elements
in the referenced scope for which value distribution is a valid
operation; if the originalFlowsInitiated and/or
originalFlowsCompleted Information Elements appear in the
Template, they are not subject to this distribution method, as
they each infer their own distribution method. The
"valueDistributionMethod (Value 384)" registry is intended 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 identifies the Intermediate
Flow Selection Process technique (e.g., Filtering, Sampling) that
is applied by the Intermediate Flow Selection Process. Most of
these techniques have parameters. Its configuration parameter(s)
MUST be clearly specified. Further Information Elements are
needed to fully specify packet selection with these methods and
all their parameters. Further 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 the improvement of measurement
functions as 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 identifies the Intermediate
Flow Selection Process technique (e.g., Filtering, Sampling) that
is applied by the Intermediate Flow Selection Process. Most of
these techniques have parameters. Its 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 specifies the type of the
selected data link frame. 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 that 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 specifies the type of the
selected data link frame. 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 that 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: Indicates when in the lifetime of the Flow the MIB
value was retrieved from the MIB for a mibObjectIdentifier. This
is used to indicate if the value exported was collected from the
MIB closer to Flow creation or Flow export time and refers to the
Timestamp fields included 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 prior to the IPFIX Metering Process or Exporting Process
retrieving the value (i.e., the data is already stale) and it is
important to know the exact sampling time, then an additional
observationTime* element should be paired with the OID using IPFIX
Structured Data [RFC 6313]. 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: Indicates when in the lifetime of the Flow the MIB
value was retrieved from the MIB for a mibObjectIdentifier. This
is used to indicate if the value exported was collected from the
MIB closer to Flow creation or Flow export time and refers to the
Timestamp fields included 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 prior to the IPFIX Metering Process or Exporting Process
retrieving the value (i.e., the data is already stale) and it is
important to know the exact sampling time, then an additional
observationTime* element should be paired with the OID using IPFIX
Structured Data [RFC 6313]. 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 (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 [RFC 791] for the definition of the IPv4
source address field.
See [RFC 3022] for the definition of NAT.
See [RFC 3234] 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 [RFC 3022] 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 [RFC 791] for the definition of the IPv4
source address field.
See [RFC 3022] for the definition of NAT.
See [RFC 3234] 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 [RFC 3022] 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 [RFC 1321], 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 [RFC 1321],
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 |
| | | [RFC 5103] are interpreted as external |
| | | addresses, and destination- Information |
| | | Elements as described in [RFC 5103] 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 [RFC 6235]. |
| 2 | PmA | Perimeter Anonymization: when set (1), |
| | | source Information Elements as described in |
| | | [RFC 5103] are interpreted as external |
| | | addresses, and destination Information |
| | | Elements as described in [RFC 5103] are |
| | | interpreted as internal addresses, for the |
| | | purposes of associating |
| | | anonymizationTechnique to Information |
| | | Elements only; see Section 7.2.2 of [RFC 6235] |
| | | 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 [RFC 3629] 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 [RFC 4646], encoded in-line [RFC 2482] 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"
[RFC 2277] 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 [RFC 3629] 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 [RFC 4646], encoded in-line [RFC 2482] 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"
[RFC 2277] language SHOULD be assumed.
See Section 4 (Security Considerations) of [RFC 5610] 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
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
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
This document does not add new security considerations to those
already discussed for IPFIX in Section 8 of [RFC 7012].
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 [RFC 5102].
[RFC 7012] has obsoleted [RFC 5102] 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>.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC 2119, March 1997,
<https://www.rfc-editor.org/info/RFC 2119>.
[RFC 7011] 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/RFC 7011, September 2013,
<https://www.rfc-editor.org/info/RFC 7011>.
[RFC 7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC 7012, September 2013,
<https://www.rfc-editor.org/info/RFC 7012>.
[RFC 7013] 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/RFC 7013, September 2013,
<https://www.rfc-editor.org/info/RFC 7013>.
[RFC 8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC 8174,
May 2017, <https://www.rfc-editor.org/info/RFC 8174>.
10.2. Informative References
[CCO-NF9FMT]
Cisco, "NetFlow Version 9 Flow-Record Format", May 2011,
<https://www.cisco.com/en/US/technologies/tk648/tk362/
technologies_white_paper09186a00800a3db9.html>.
[RFC 768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC 768, August 1980,
<https://www.rfc-editor.org/info/RFC 768>.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC 791, September 1981,
<https://www.rfc-editor.org/info/RFC 791>.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC 1321, April 1992,
<https://www.rfc-editor.org/info/RFC 1321>.
[RFC 1631] Egevang, K. and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, DOI 10.17487/RFC 1631, May
1994, <https://www.rfc-editor.org/info/RFC 1631>.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, DOI 10.17487/RFC 2277,
January 1998, <https://www.rfc-editor.org/info/RFC 2277>.
[RFC 2482] Whistler, K. and G. Adams, "Language Tagging in Unicode
Plain Text", RFC 2482, DOI 10.17487/RFC 2482, January 1999,
<https://www.rfc-editor.org/info/RFC 2482>.
[RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC 3022, January 2001,
<https://www.rfc-editor.org/info/RFC 3022>.
[RFC 3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC 3031, January 2001,
<https://www.rfc-editor.org/info/RFC 3031>.
[RFC 3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC 3234, February 2002,
<https://www.rfc-editor.org/info/RFC 3234>.
[RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC 3629, November
2003, <https://www.rfc-editor.org/info/RFC 3629>.
[RFC 4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC 4340, March 2006,
<https://www.rfc-editor.org/info/RFC 4340>.
[RFC 4646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, DOI 10.17487/RFC 4646, September
2006, <https://www.rfc-editor.org/info/RFC 4646>.
[RFC 5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, DOI 10.17487/RFC 5102, January 2008,
<https://www.rfc-editor.org/info/RFC 5102>.
[RFC 5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export
Using IP Flow Information Export (IPFIX)", RFC 5103,
DOI 10.17487/RFC 5103, January 2008,
<https://www.rfc-editor.org/info/RFC 5103>.
[RFC 5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", RFC 5475, DOI 10.17487/RFC 5475, March 2009,
<https://www.rfc-editor.org/info/RFC 5475>.
[RFC 5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports",
RFC 5477, DOI 10.17487/RFC 5477, March 2009,
<https://www.rfc-editor.org/info/RFC 5477>.
[RFC 5610] 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/RFC 5610, July 2009,
<https://www.rfc-editor.org/info/RFC 5610>.
[RFC 5655] 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/RFC 5655,
October 2009, <https://www.rfc-editor.org/info/RFC 5655>.
[RFC 6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC 6144,
April 2011, <https://www.rfc-editor.org/info/RFC 6144>.
[RFC 6146] 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/RFC 6146,
April 2011, <https://www.rfc-editor.org/info/RFC 6146>.
[RFC 6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC 6235, May 2011,
<https://www.rfc-editor.org/info/RFC 6235>.
[RFC 6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC 6296, June 2011,
<https://www.rfc-editor.org/info/RFC 6296>.
[RFC 6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information Export
(IPFIX)", RFC 6313, DOI 10.17487/RFC 6313, July 2011,
<https://www.rfc-editor.org/info/RFC 6313>.
[RFC 6759] 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/RFC 6759, November
2012, <https://www.rfc-editor.org/info/RFC 6759>.
[RFC 7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
Selection Techniques", RFC 7014, DOI 10.17487/RFC 7014,
September 2013, <https://www.rfc-editor.org/info/RFC 7014>.
[RFC 7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, DOI 10.17487/RFC 7015, September 2013,
<https://www.rfc-editor.org/info/RFC 7015>.
[RFC 7125] Trammell, B. and P. Aitken, "Revision of the
tcpControlBits IP Flow Information Export (IPFIX)
Information Element", RFC 7125, DOI 10.17487/RFC 7125,
February 2014, <https://www.rfc-editor.org/info/RFC 7125>.
[RFC 7133] Kashima, S., Kobayashi, A., Ed., and P. Aitken,
"Information Elements for Data Link Layer Traffic
Measurement", RFC 7133, DOI 10.17487/RFC 7133, May 2014,
<https://www.rfc-editor.org/info/RFC 7133>.
[RFC 7270] Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-
Specific Information Elements Reused in IP Flow
Information Export (IPFIX)", RFC 7270,
DOI 10.17487/RFC 7270, June 2014,
<https://www.rfc-editor.org/info/RFC 7270>.
[RFC 8038] 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/RFC 8038, May 2017,
<https://www.rfc-editor.org/info/RFC 8038>.
[RFC 8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC 8126, June 2017,
<https://www.rfc-editor.org/info/RFC 8126>.
[RFC 8158] Sivakumar, S. and R. Penno, "IP Flow Information Export
(IPFIX) Information Elements for Logging NAT Events",
RFC 8158, DOI 10.17487/RFC 8158, December 2017,
<https://www.rfc-editor.org/info/RFC 8158>.
[RFC 8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC 8200, July 2017,
<https://www.rfc-editor.org/info/RFC 8200>.
[RFC 9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC 9260,
June 2022, <https://www.rfc-editor.org/info/RFC 9260>.
[RFC 9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC 9293, August 2022,
<https://www.rfc-editor.org/info/RFC 9293>.
[RFC 9487] 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/RFC 9487, November
2023, <https://www.rfc-editor.org/info/RFC 9487>.
[RFC 9565] Boucadair, M., "An Update to the tcpControlBits IP Flow
Information Export (IPFIX) Information Element", RFC 9565,
DOI 10.17487/RFC 9565, March 2024,
<https://www.rfc-editor.org/info/RFC 9565>.
Acknowledgments
Many thanks to Paul Aitken for the review and many suggestions that
enhanced this specification. Special thanks to Andrew Feren for
sharing data about scans of IPFIX data he collected.
Thomas Graf tagged an issue with the forwardingStatus Information
Element and for the Shepherd review.
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.
Thanks to Mahesh Jethanandani for the AD review.
Thanks to Éric Vyncke for the IESG review.
Authors' Addresses
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Benoit Claise
Huawei
Email: benoit.claise@huawei.com
RFC TOTAL SIZE: 71593 bytes
PUBLICATION DATE: Wednesday, February 26th, 2025
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
