Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry Orange
mohamed.boucadair@orange.com
Huawei
benoit.claise@huawei.com
OPS opsawg IPFIX Operations Network Providers Network Managment Anomaly detection Telemetry 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 .
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 () 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
  • .  Introduction
  • .  Conventions and Definitions
  • .  Why an RFC Is Needed for These Updates
  • .  Update the Descriptions in the IANA Registry
    • .  sourceTransportPort
    • .  destinationTransportPort
    • .  forwardingStatus
    • .  collectorTransportPort
    • .  exporterTransportPort
  • .  Point to an Existing IANA Registry
  • .  Consistent Citation of IANA Registries
    • .  mplsTopLabelType
    • .  classificationEngineId
    • .  flowEndReason
    • .  natOriginatingAddressRealm
    • .  natEvent
    • .  firewallEvent
    • .  biflowDirection
    • .  observationPointType
    • .  anonymizationTechnique
    • . natType
    • . selectorAlgorithm
    • . informationElementDataType
    • . informationElementSemantics
    • . informationElementUnits
    • . portRangeStart
    • . portRangeEnd
    • . ingressInterfaceType
    • . egressInterfaceType
    • . valueDistributionMethod
    • . flowSelectorAlgorithm
    • . dataLinkFrameType
    • . mibCaptureTimeSemantics
    • . natQuotaExceededEvent
    • . natThresholdEvent
  • .  Miscellaneous Updates
    • .  collectionTimeMilliseconds
    • .  messageMD5Checksum
    • .  anonymizationFlags
    • .  informationElementDescription
    • .  distinctCountOfDestinationIPAddress
    • .  externalAddressRealm
  • .  Security Considerations
  • .  IANA Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgments
  • Authors' Addresses
Introduction When the Operations and Management Area Working Group (OPSAWG) was considering , which obsoletes , the WG realized that some parts of the IANA "IP Flow Information Export (IPFIX) Entities" registry 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 , the "Additional Information" entry in 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 . These fixes are classified as follows:
  • Updates to fix a shortcoming in the description of an IE ().
  • Updates to include a pointer to an existing IANA registry ().
  • Updates to ensure a consistent structure when calling an existing IANA registry ().
  • Miscellaneous updates to fix broken pointers, orphaned section references, etc. ().
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 , is the normative reference for the IPFIX IEs that were defined in . Therefore, the updates in this document do not update any part of . Likewise, this document is not marked as formally updating , , , , , , , , , , and .
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 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 . As in , these IPFIX-specific terms have the first letter of a word capitalized.
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 ). However, and given that many of the impacted IEs were created via the IETF stream, the following from 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.
Update the Descriptions in the IANA Registry
sourceTransportPort
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See for the definition of SCTP. Additional information on defined UDP and TCP port numbers can be found at [].
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See for the definition of the SCTP source port number field. See for the definition of the DCCP source port field. See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers [].
destinationTransportPort
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See 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.
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 for the definition of the UDP destination port field. See for the definition of the TCP destination port field. See for the definition of the SCTP destination port number field. See for the definition of the DCCP destination port field. See the assigned transport protocol (e.g., UDP, TCP, SCTP, and DCCP) port numbers [].
forwardingStatus The current forwardingStatus entry in deviates from what is provided in . 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 .
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" .
Abstract Data Type:
unsigned8
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" . See the "Forwarding Status (Value 89)" registry [].
Abstract Data Type:
unsigned32
collectorTransportPort
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See 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].
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 for the definition of the UDP destination port field. See for the definition of the TCP destination port field. See for the definition of the SCTP destination port number field. See the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers [].
exporterTransportPort
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See 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].
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 for the definition of the UDP source port field. See for the definition of the TCP source port field. See for the definition of the SCTP source port number field. See the assigned transport protocol (e.g., UDP, TCP, and SCTP) port numbers [].
Point to an Existing IANA Registry IANA has updated the following entries by adding the indicated "Additional Information" to the registry. (In , "ID" refers to "ElementID".) Cite an IANA Registry Under Additional Information
ID Name Additional Information
32 icmpTypeCodeIPv4 See the "ICMP Type Numbers" registry []
33 igmpType See the "IGMP Type Numbers" registry []
139 icmpTypeCodeIPv6 See the "ICMPv6 'type' Numbers" and "ICMPv6 'Code' Fields" registries []
176 icmpTypeIPv4 See the "ICMP Type Numbers" registry []
177 icmpCodeIPv4 See the "ICMP Type Numbers" registry []
178 icmpTypeIPv6 See the "ICMPv6 'type' Numbers" registry []
179 icmpCodeIPv6 See the "ICMPv6 'Code' Fields" registry []
346 privateEnterpriseNumber See the "Private Enterprise Numbers (PENs)" registry []
Consistent Citation of IANA Registries IANA has updated the "IP Flow Information Export (IPFIX) Entities" registry for each of the IE entries listed in the following subsections.
mplsTopLabelType
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 for the MPLS label structure. See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values].
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) []. See for the MPLS label structure.
classificationEngineId
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.
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 [].
flowEndReason
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.
NEW
Description:
The reason for Flow termination. Values are listed in the flowEndReason registry.
Additional Information:
See the "flowEndReason (Value 136)" registry [].
natOriginatingAddressRealm
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 for the definition of NAT.
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 []. See for the definition of NAT.
natEvent
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 for the definition of NAT. See for the definition of middleboxes. See for the definitions of values 4-16.
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 []. See for the definition of NAT. See for the definitions of values 4-16.
firewallEvent
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.
NEW
Description:
Indicates a firewall event. Allowed values are listed in the firewallEvent registry.
Additional Information:
See the "firewallEvent (Value 233)" registry [].
biflowDirection
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].
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 [].
observationPointType
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.
NEW
Description:
Type of observation point. Values are listed in the observationPointType registry.
Additional Information:
See the "observationPointType (Value 277)" registry [].
anonymizationTechnique
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.
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 [].
natType
OLD
Description:
Values are listed in the natType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type.
Additional Information:
See for the definition of NAT. See for the definition of NAT44. See for the definition of NAT64. See for the definition of NAT46. See for the definition of NAT66. See for the definition of IPv4. See for the definition of IPv6.
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 []. See for the definition of NAT (commonly named NAT44). See for the definition of NAT46. See for the definition of NAT64. See for the definition of NPTv6. See for the definition of IPv4. See for the definition of IPv6.
selectorAlgorithm
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 . 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.
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 . 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 [].
informationElementDataType Note that the "informationElementDataType" registry has been renamed as the "IPFIX Information Element Data Types" registry.
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 of the IPFIX Information Model ; 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 to modify.
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 of the IPFIX Information Model ; 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 .
Additional Information:
See the "IPFIX Information Element Data Types" registry [].
informationElementSemantics
OLD
Description:
A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section of the IPFIX Information Model ; 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 to modify.
NEW
Description:
A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in Section of the IPFIX Information Model ; 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 .
Additional Information:
See the "IPFIX Information Element Semantics" registry [].
informationElementUnits Note that the "informationElementsUnits" registry has been renamed as the "IPFIX Information Element Units" registry.
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 of the IPFIX Information Model ; 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.
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 of the IPFIX Information Model ; 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 [].
portRangeStart
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.
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 [].
portRangeEnd
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.
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 [].
ingressInterfaceType
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
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 [].
egressInterfaceType
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
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 [].
valueDistributionMethod
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.
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 [].
flowSelectorAlgorithm
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.
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 [].
dataLinkFrameType
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)
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 []. More information about the data link layer can be found in (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994).
mibCaptureTimeSemantics
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 . 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.
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 . 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 [].
natQuotaExceededEvent
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 for the definition of the IPv4 source address field. See for the definition of NAT. See for the definition of middleboxes.
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 []. See for the definition of NAT.
natThresholdEvent
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 for the definition of the IPv4 source address field. See for the definition of NAT. See for the definition of middleboxes.
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 []). See for the definition of NAT.
Miscellaneous Updates IANA has updated the descriptions of the following entries in .
collectionTimeMilliseconds
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.
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.
messageMD5Checksum
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 , 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.
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 , 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.
anonymizationFlags
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.) | +--------+----------+-----------------------------------------------+
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.) | +--------+----------+-----------------------------------------------+
informationElementDescription
OLD
Description:
A UTF-8 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 , encoded in-line 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" language SHOULD be assumed. See the Security Considerations section for notes on string handling for Information Element type records.
NEW
Description:
A UTF-8 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 , encoded in-line 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" language SHOULD be assumed. See Section Security Considerations of for notes on string handling for Information Element type records.
distinctCountOfDestinationIPAddress
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.
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.
externalAddressRealm
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.
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.
Security Considerations This document does not add new security considerations to those already discussed for IPFIX in .
IANA Considerations Sections to 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 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 . has obsoleted 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 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 [].
References Normative References IP Flow Information Export (IPFIX) Entities IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. Information Model for IP Flow Information Export (IPFIX) This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References NetFlow Version 9 Flow-Record Format Cisco User Datagram Protocol Internet Protocol The MD5 Message-Digest Algorithm This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. The IP Network Address Translator (NAT) This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. IETF Policy on Character Sets and Languages This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Language Tagging in Unicode Plain Text This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community. Traditional IP Network Address Translator (Traditional NAT) The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation. In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail. This memo provides information for the Internet community. Multiprotocol Label Switching Architecture This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] Middleboxes: Taxonomy and Issues This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community. UTF-8, a transformation format of ISO 10646 ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. Datagram Congestion Control Protocol (DCCP) The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK] Tags for Identifying Languages This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Information Model for IP Flow Information Export This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK] Bidirectional Flow Export Using IP Flow Information Export (IPFIX) This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK] Sampling and Filtering Techniques for IP Packet Selection This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK] Information Model for Packet Sampling Exports This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK] Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. [STANDARDS-TRACK] Specification of the IP Flow Information Export (IPFIX) File Format This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK] Framework for IPv4/IPv6 Translation This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. This document is not an Internet Standards Track specification; it is published for informational purposes. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. IP Flow Anonymization Support This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community. IPv6-to-IPv6 Network Prefix Translation This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. This document defines an Experimental Protocol for the Internet community. Export of Structured Data in IP Flow Information Export (IPFIX) This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK] Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes. Flow Selection Techniques The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. Information Elements for Data Link Layer Traffic Measurement This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012. Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified. Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Stream Control Transmission Protocol This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with. An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated. This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry. This document obsoletes RFC 7125.
Acknowledgments Many thanks to for the review and many suggestions that enhanced this specification. Special thanks to for sharing data about scans of IPFIX data he collected. tagged an issue with the forwardingStatus Information Element and for the Shepherd review. Thanks to for the review and comments. Thanks to for the opsdir review, for the genart review, for the tsvart review, for the intdir review, and for the secdir review. Thanks to for the AD review. Thanks to for the IESG review.
Authors' Addresses Orange
mohamed.boucadair@orange.com
Huawei
benoit.claise@huawei.com