Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry
Extracted elements (27)
An RFC rather than an IE-DOCTORS expert action is required for these updates because many of the impacted IEs were created via the IETF stream. Per RFC 7013 Section 5.1, Information Elements added with IETF consensus require IETF consensus for revision or deprecation.
Registry links in 'Additional Information' facilitate automatic extraction of IPFIX IE values by Collectors (e.g., via cron jobs), which is required for Collectors to support new IPFIX IEs and adequately interpret new registry values without manual updates.
The 'Additional Information' entry in the IPFIX registry should contain a link to an existing IANA sub-registry rather than embedding registry values inline in 'Description'. Inline values require updating the description each time the referenced registry changes, causing maintenance burden and staleness.
The 'forwardingStatus' IE was registered with Abstract Data Type unsigned8, which deviates from RFC 7270. This document corrects it to unsigned32. Implementations using RFC 7270 should use unsigned32 with reduced-size encoding to export as unsigned8.
This document's updates to the IANA IPFIX Entities registry do not formally update RFC 7011 or any of the following: RFC 5477, RFC 5610, RFC 5655, RFC 6235, RFC 6759, RFC 7014, RFC 7015, RFC 7133, RFC 7270, RFC 8038, and RFC 8158. The IANA registry is the normative reference per RFC 7012 Section 5.
For the 'biflowDirection' IE, when using IPFIX Options to apply it 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 IE SHOULD appear in each Flow Record.
The 'anonymizationFlags' PmA bit (bit 2) MUST NOT be set when the flag is associated with a non-endpoint (i.e., source or destination) Information Element. The PmA bit SHOULD be consistent within a record.
The 'flowSelectorAlgorithm' IE requires that its configuration parameters MUST be clearly specified. Additional IEs are needed to fully specify packet selection methods and all their parameters.
The 'forwardingStatus' IE SHOULD currently be exported as unsigned8 via IPFIX reduced-size encoding, even though its Abstract Data Type is unsigned32, to allow future extension of the remaining bits.
The 'informationElementDataType' and 'informationElementSemantics' registries are intended to assign numbers for type/semantics names only, not to provide a mechanism for adding data types or semantics to the IPFIX Protocol; modifications require Standards Action per RFC 8126.
The 'mibCaptureTimeSemantics' IE SHOULD be used when exporting a mibObjectValue that specifies counters or statistics, to indicate whether the MIB value was collected closer to Flow creation or Flow export time.
The 'anonymizationFlags' IE bit-field description is updated to add proper RFC section references: Stability Class (bits 0-1) references Section 5.1 of RFC 6235, and the PmA bit (bit 2) references Section 7.2.2 of RFC 6235.
The 'collectorTransportPort' IE description is corrected: the Additional Information now properly references the UDP destination port field (not source port) and the SCTP destination port number field (not generic SCTP reference).
The 'exporterTransportPort' IE description is corrected: the Additional Information now properly references the SCTP source port number field specifically, replacing a generic SCTP reference.
The 'externalAddressRealm' IE description is updated to explicitly cross-reference the 'internalAddressRealm' IE for the detailed definition, replacing the self-referential 'as specified above' text that became an orphaned reference.
The 'forwardingStatus' IE Abstract Data Type is corrected from unsigned8 to unsigned32. The current version is structured around the least-significant byte using IPFIX reduced-size encoding; future versions may assign meaning to remaining bits.
The 'informationElementDataType' registry has been renamed to 'IPFIX Information Element Data Types' and the 'informationElementsUnits' registry has been renamed to 'IPFIX Information Element Units'; descriptions are updated to use the new names consistently.
The 'informationElementDescription' IE description is updated to replace the orphaned 'See the Security Considerations section' with a specific pointer to Section 4 of RFC 5610 for notes on string handling for Information Element type records.
The 'messageMD5Checksum' IE description is clarified: the orphaned 'as defined below' reference is removed since messageScope is defined elsewhere. The IE has a fixed length of 16 octets and is intended as a simple checksum only, not requiring collision resistance.
The 'natType' IE description is updated to clarify that RFC 3022 defines NAT (commonly named NAT44), RFC 6144 defines NAT46 (not NAT64 as previously implied by ordering), RFC 6146 defines NAT64, and RFC 6296 defines NPTv6 (not NAT66, correcting the prior label).
The 'sourceTransportPort' and 'destinationTransportPort' IEs are updated to include DCCP (RFC 4340) alongside UDP, TCP, and SCTP as transport protocols with 16-bit port identifiers. The Additional Information now references the DCCP port field definition.
IANA updated 24 IPFIX IE entries (mplsTopLabelType, classificationEngineId, flowEndReason, natOriginatingAddressRealm, natEvent, firewallEvent, biflowDirection, observationPointType, anonymizationTechnique, natType, selectorAlgorithm, informationElementDataType, informationElementSemantics, informationElementUnits, portRangeStart, portRangeEnd, ingressInterfaceType, egressInterfaceType, valueDistributionMethod, flowSelectorAlgorithm, dataLinkFrameType, mibCaptureTimeSemantics, natQuotaExceededEvent, natThresholdEvent) to move registry references from inline Description text to the 'Additional Information' field.
IANA updated eight IPFIX IE entries (icmpTypeCodeIPv4, igmpType, icmpTypeCodeIPv6, icmpTypeIPv4, icmpCodeIPv4, icmpTypeIPv6, icmpCodeIPv6, privateEnterpriseNumber) to add 'Additional Information' pointers to their respective IANA registries (ICMP parameters, ICMPv6 parameters, PEN registry).
IANA updated references to the 'Service Name and Transport Protocol Port Number' registry consistently throughout the IPFIX Entities registry, replacing the old URL format (http://www.iana.org/assignments/port-numbers) with the current canonical URL and adding SCTP and DCCP to the cited protocols.
IANA updated the note in the 'IPFIX Information Elements' registry under the 'IP Flow Information Export (IPFIX) Entities' registry group to clarify that RFC 5102 provided initial values, RFC 7012 obsoleted RFC 5102, and the current registry is the normative reference for these IEs.
RFC 9710 introduces no new security considerations. Security considerations for IPFIX remain as discussed in Section 8 of RFC 7012.
The 'forwardingStatus' IE encodes a 1-byte layout in the least-significant byte: bits 7-6 carry the Status (Forward, Drop, etc.) and bits 5-0 carry the Reason code or flags. Example: 0x40 (01000000) = Forward with no further information; 0x89 (10001001) = Drop with Bad TTL.