Internet-Draft | IPFIX IANA Fixes | February 2023 |
Boucadair & Claise | Expires 11 August 2023 | [Page] |
This document describes simple fixes to the IANA IP Flow Information Export (IPFIX) registry. These fixes are mainly updates to point to newer IANA registries and also updates to the description of some Information Elements (IEs).¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/.¶
Source for this draft and an issue tracker can be found at https://github.com/boucadair/simple-ipfix-fixes.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 August 2023.¶
Copyright (c) 2023 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.¶
As the OPSAWG is currently considering [I-D.boucadair-opsawg-rfc7125-update] that updates [RFC7125], the WG realized that some other parts of the IANA IPFIX registry [IANA-IPFIX] were not up-to-date. Indeed, since its initial creation in 2007, some IPFIX Information Elements (IEs) are not adequately specified any longer (while they were at some point in time in the past). This document intends to update the IANA registry and bringing some consistency among the entries of the registry.¶
As discussed with IANA, the "Additional Information" entry in [IANA-IPFIX] should contain a link to the existing registry, when applicable, as opposed to having:¶
Therefore, this document lists a set of simple fixes to the IPFIX IANA registry [IANA-IPFIX]. These fixes are classified as follows:¶
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 [RFC7012], [IANA-IPFIX] is the normative reference for the IPFIX IEs that were defined in [RFC5102]. Therefore, the updates in this document do not update any part of [RFC7011].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the IPFIX-specific terminology (Information Element, Template, Collector, Data Record, Flow Record, Exporting Process, Collecting Process, etc.) defined in Section 2 of [RFC7011]. As in [RFC7011], these IPFIX-specific terms have the first letter of a word capitalized.¶
Many of the edits in this document may be handled by the IPFIX Design Experts. However, and given that many of the impacted IEs were created via the IETF stream, the following from Section 5.1 of [RFC7013] should be 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.¶
The IEs listed in the following subsections cannot echo some values that can be seen in a packet.¶
The current specification of ipv6ExtensionHeaders Information Element should be updated to:¶
The following section proposes a fix for the first two issues. A companion document [I-D.boucadair-opsawg-ipfix-tcpo-v6eh] specifies a new option to fix the last issue.¶
Description: IPv6 extension headers observed in packets of this Flow. The information is encoded in a set of bit fields. For each IPv6 option header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contained the respective IPv6 extension header, the value of the corresponding bit is 0. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DST | HOP | Res | UNK |FRA0 | RH |FRA1 | Res | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | MOB | ESP | AH | PAY | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 24 25 26 27 28 29 30 31 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Bit IPv6 Option Description 0, DST 60 Destination option header 1, HOP 0 Hop-by-hop option header 2, Res Reserved 3, UNK Unknown Layer 4 header (compressed, encrypted, not supported) 4, FRA0 44 Fragment header - first fragment 5, RH 43 Routing header 6, FRA1 44 Fragmentation header - not first fragment 7, Res Reserved 8 to 11 Reserved 12, MOB 135 IPv6 mobility [RFC3775] 13, ESP 50 Encrypted security payload 14, AH 51 Authentication Header 15, PAY 108 Payload compression header 16 to 31 Reserved Abstract Data Type: unsigned32 Data Type Semantics: flags ElementId: 64 Status: current Reference: [RFC5102] Additional Information: See [RFC8200] for the general definition of IPv6 extension headers and for the specification of the hop-by-hop options header, the routing header, the fragment header, and the destination options header. See [RFC4302] for the specification of the authentication header. See [RFC4303] for the specification of the encapsulating security payload. The diagram provided in [RFC5102] is incorrect. The diagram in this registry is taken from Errata 1738. See [RFC Errata 1738].¶
Description: IPv6 extension headers observed in packets of this Flow. The information is encoded in a set of bit fields. For each IPv6 option header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contained the respective IPv6 extension header, the value of the corresponding bit is 0. The IPv6 EH associated with each bit is provided in [NEW_IPFIX_IPv6EH_SUBREGISTRY]. This IE is used only when when the observed extension headers are in the 0-31 range. If the observed EHs exceeds that range, ipv6ExtensionHeadersFull Information Element MUST be used. Abstract Data Type: unsigned32 Data Type Semantics: flags ElementId: 64 Status: current Reference: [RFC5102][This-Document] Additional Information: See the assigned bits to each IPv6 extension header in [NEW_IPFIX_IPv6EH_SUBREGISTRY]. See [RFC8200] for the general definition of IPv6 extension headers and [IPv6-EH] for assigned extension headers.¶
Only options having a kind =< 63 can be included in a tcpOptions IE. An update is thus required to specify how any observed TCP option in a packet can be exported using IPFIX. Also, there is no way to report the observed Experimental Identifiers (ExIDs) that are carried in shared TCP options (kind=253 or 254) [RFC6994].¶
This document requests IANA to update the description of the tcpOptions IE in the IANA IPFIX registry [IANA-IPFIX] as follows.¶
TCP options in packets of this Flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding TCP option. Otherwise, if no observed packet of this Flow contained the respective TCP option, the value of the corresponding bit is 0. Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. TCP option numbers are maintained by IANA.¶
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | +-----+-----+-----+-----+-----+-----+-----+-----+¶
TCP options in packets of this Flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding TCP option. Otherwise, if no observed packet of this Flow contained the respective TCP option, the value of the corresponding bit is 0. Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. TCP option numbers are maintained by IANA. This information element is used only when the observed kinds are within the 0-63 range. If not, the tcpOptionsFull IE MUST be used.¶
0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ... +-----+-----+-----+-----+-----+-----+-----+-----+ 8 9 10 11 12 13 14 15 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 |... +-----+-----+-----+-----+-----+-----+-----+-----+ 16 17 18 19 20 21 22 23 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 |... +-----+-----+-----+-----+-----+-----+-----+-----+ . . . 56 57 58 59 60 61 62 63 +-----+-----+-----+-----+-----+-----+-----+-----+ ... | 63 | 62 | 61 | 60 | 59 | 58 | 57 | 56 | +-----+-----+-----+-----+-----+-----+-----+-----+¶
This document requests IANA to update the following entries by adding the indicated "Additional Information" to the [IANA-IPFIX] registry:¶
IE | Additional Information |
---|---|
icmpTypeCodeIPv4 | https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml |
igmpType | https://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numbers-1 |
icmpTypeCodeIPv6 | https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml |
icmpTypeIPv4 | https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types |
icmpCodeIPv4 | https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes |
icmpTypeIPv6 | https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2 |
icmpCodeIPv6 | https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-3 |
privateEnterpriseNumber | https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers |
This document requests IANA to update [IANA-IPFIX] for each of the IE entries listed in the following subsections.¶
OLD:¶
NEW:¶
- 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 https://www.iana.org/assignments/ipfix/ipfix.xhtml#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].¶
- 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 | +---+---+---+---+---+---+---+---+ 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 the Forwarding Status sub-registries at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status.¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
This document requests IANA to update the description of the following entries in [IANA-IPFIX].¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
+--------+----------+-----------------------------------------------+ | 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.) | | 3 | LOR | Low-Order Unchanged: when set (1), the | | | | low-order bits of the anonymized Information | | | | Element contain real data. This modification | | | | is intended for the anonymization of | | | | network-level addresses while leaving | | | | host-level addresses intact in order to | | | | preserve host level-structure, which could | | | | otherwise be used to reverse anonymization. | | | | MUST NOT be set when associated with a | | | | truncation-based anonymizationTechnique. | | 4-15 | Reserved | Reserved for future use: SHOULD be cleared | | | | (0) by the Exporting Process and MUST be | | | | ignored by the Collecting Process. | +--------+----------+-----------------------------------------------+¶
+--------+----------+-----------------------------------------------+ | 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.) | | 3 | LOR | Low-Order Unchanged: when set (1), the | | | | low-order bits of the anonymized Information | | | | Element contain real data. This modification | | | | is intended for the anonymization of | | | | network-level addresses while leaving | | | | host-level addresses intact in order to | | | | preserve host level-structure, which could | | | | otherwise be used to reverse anonymization. | | | | MUST NOT be set when associated with a | | | | truncation-based anonymizationTechnique. | | 4-15 | Reserved | Reserved for future use: SHOULD be cleared | | | | (0) by the Exporting Process and MUST be | | | | ignored by the Collecting Process. | +--------+----------+-----------------------------------------------+¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
OLD:¶
NEW:¶
IPFIX security considerations are discussed in Section 8 of [RFC7012].¶
A set of requested IANA actions are described in the main document. These actions are not repeated here.¶
This document also requests IANA to update the reference clause of the "IPFIX Information Elements" subregistry with the reference to this document.¶
This document requests IANA to create a new subregistry entitled "ipv6ExtensionHeaders Bits" under the IANA IPFIX registry [IANA-IPFIX].¶
The initial values of this subregistry are as follows:¶
Bit IPv6 Option Description 0, DST 60 Destination option header 1, HOP 0 Hop-by-hop option header 2, U Unassigned 3, UNK Unknown Layer 4 header (compressed, encrypted, not supported) 4, FRA0 44 Fragment header - first fragment 5, RH 43 Routing header 6, FRA1 44 Fragmentation header - not first fragment 7 to 11 Unassigned 12, MOB 135 IPv6 mobility [RFC3775] 13, ESP 50 Encrypted security payload 14, AH 51 Authentication Header 15, PAY 108 Payload compression header 16, HIP 139 Host Identity Protocol 17, SHIM6 140 Shim6 Protocol 18 253 Use for experimentation and testing 19 254 Use for experimentation and testing 20 to 255 Unassigned¶
Values are not added directly into this subregistry. When a new code is assigned to an IPv6 EH in [IPv6-EH], a free bit is selected by IANA for this EH from "ipv6ExtensionHeaders Bits" subregistry and the subregistry is udpated with the details that mirror the assigned EH.¶
IANA is requested to add this note to [IPv6-EH]:¶
When a new code is assigned to an IPv6 Extension Header, a free bit in [NEW_IPFIX_IPv6EH_SUBREGISTRY] is selected for this new Extension Header [NEW_IPFIX_IPv6EH_SUBREGISTRY] is updated accordingly.¶
Thanks to Paul Aitken for the review.¶