Internet-Draft IPFIX IANA Fixes January 2024
Boucadair & Claise Expires 18 July 2024 [Page]
Workgroup:
OPSAWG
Internet-Draft:
draft-ietf-opsawg-ipfix-fixes-04
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Boucadair
Orange
B. Claise
Huawei

Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry

Abstract

This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphan section references, etc. The updates are also meant to bringing some consistency among the entries of the registry.

Discussion Venues

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.

Status of This Memo

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 18 July 2024.

▲

Table of Contents

1. Introduction

As the OPSAWG is currently considering [I-D.ietf-opsawg-rfc7125-update] which updates [RFC7125], the WG realized that some other parts of the IANA IP Flow Information Export (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 an 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].

Likewise, this document is not marked as formally updating [RFC5477], [RFC5610], [RFC5655], [RFC6235], [RFC6759], [RFC7014], [RFC7015], [RFC7133], [RFC7270], [RFC8038], and [RFC8158].

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This 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.

3. Why An RFC is Needed for These Updates?

Many of the edits in this document may be handled by the IPFIX Experts (informally called the IE-DOCTORS [RFC7013]). 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:

4. Update the Description

4.1. ipv6ExtensionHeaders Information Element

4.1.1. Issues

The current specification of the ipv6ExtensionHeaders Information Element should be updated to:

  1. Reflect missing IPv6 EHs, specifically 139, 140, 253, and 254.

  2. Specify how to automatically update the registry when a new value is assigned in [IANA-EH].

  3. Update the 108 entry given that 108 does not correspond to an extension header as per [IANA-Protocols].

  4. Specify the procedure to follow when all bits are exhausted.

Section 4.1.2 specifies fixes to the first three issues. Section 3 of [I-D.ietf-opsawg-ipfix-tcpo-v6eh] specifies a new Information Element to fix the last issue. Other Information Elements are defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh] to address some other limitations such as lack of reporting of extension header chains or aggregate extension headers length.

Note that some implementations may not be able to export all observed extension headers in a Flow because of a hardware or software limit (see, e.g., [I-D.ietf-6man-eh-limits]. The specification of the ipv6ExtensionHeaders Information Element does not discuss whether it covers all enclosed extension headers or only up to a limit. A solution to this shortcoming is also defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

4.1.2. Updates to the ipv6ExtensionHeaders Description 

 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 extension header associated with each bit is provided in [NEW_IPFIX_IPv6EH_SUBREGISTRY]. The following drawing indicates the position of each bit in the encoding of the Information Element.

This IE is used only when the observed extension headers are in the 0-31 range.

If the observed EHs exceeds that range, ipv6ExtensionHeadersFull Information Element MUST be used [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

             0     1     2     3     4     5     6     7
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |        IPv6 extension header bits             |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+

             8     9    10    11    12    13    14    15
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |         IPv6 extension header bits            |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+

            16    17    18    19    20    21    22    23
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |         IPv6 extension header bits            |  ...
         +-----+-----+-----+-----+-----+-----+-----+-----+

            24    25    26    27    28    29    30    31
         +-----+-----+-----+-----+-----+-----+-----+-----+
     ... |        IPv6 extension header bits             |
         +-----+-----+-----+-----+-----+-----+-----+-----+
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 [IANA-EH] for assigned extension headers.

4.2. tcpOptions

4.2.1. Issues

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].

The following section updates the description of the tcpOptions IE to explicitly indicate the applicable kind range and to point to the new IEs defined in [I-D.ietf-opsawg-ipfix-tcpo-v6eh].

4.2.2. Update the Description of the tcpOptions IE

This document requests IANA to update the description of the tcpOptions IE in [IANA-IPFIX] as follows:

  • OLD Description:

    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 |
        +-----+-----+-----+-----+-----+-----+-----+-----+
  • NEW Description:

    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 the drawing below. 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 [I-D.ietf-opsawg-ipfix-tcpo-v6eh] 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 |
        +-----+-----+-----+-----+-----+-----+-----+-----+

4.3. forwardingStatus

The current forwardingStatus entry in [IANA-IPFIX] deviates from what is provided in [RFC7270]. In particular, the registered Abstract Data Type is unsigned8, while it must be unsigned32. The following update fixes that issue. The description is also updated to clarify the use of the reduced-size encoding as per Section 6.2 of [RFC7011].

   - 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).

   - Abstract Data Type: unsigned8

   - 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 first
                   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 the Forwarding Status sub-registries
       at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status.

   - Abstract Data Type: unsigned32

5. Point to An Existing IANA Registry

This document requests IANA to update the following entries by adding the indicated "Additional Information" to the [IANA-IPFIX] registry:

Table 1: Cite an IANA Registry under Additional Information
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

6. Consistent Citation of IANA Registries

This document requests IANA to update [IANA-IPFIX] for each of the IE entries listed in the following subsections.

6.1. 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 [RFC3031] for the MPLS label structure.

      See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values].

  • 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 list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type].

      See [RFC3031] for the MPLS label structure.

6.2. 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.

    • Additional Information:

  • 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 https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.

6.3. 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.

    • Additional Information:

  • NEW:

    • Description:

      The reason for Flow termination. Values are listed in the flowEndReason registry.

    • Additional Information:

      See the Classification Engine IDs registry available at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason].

6.4. 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 [RFC3022] 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 assigned NAT originating address realm at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm]. See [RFC3022] for the definition of NAT.

6.5. 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 [RFC3022] for the definition of NAT.

      See [RFC3234] for the definition of middleboxes.

      See [RFC8158] 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 assigned NAT Event Types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type].

      See [RFC3022] for the definition of NAT.

      See [RFC3234] for the definition of middleboxes.

      See [RFC8158] for the definitions of values 4-16.

6.6. 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.

    • Additional Information:

  • NEW:

    • Description:

      Indicates a firewall event. Allowed values are listed in the firewallEvent registry.

    • Additional Information:

      See the assigned firewall events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event].

6.7. 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].

    • Additional Information:

  • 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 assigned biflow direction values at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].

6.8. 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.

    • Additional Information:

  • NEW:

    • Description:

      Type of observation point. Values are listed in the observationPointType registry.

    • Additional Information:

      See the assigned observation point type at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type].

6.9. 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.

    • Additional Information:

  • 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 assigned anonymization techniques at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique].

6.10. 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 [RFC3022] for the definition of NAT.

      See [RFC1631] for the definition of NAT44.

      See [RFC6144] for the definition of NAT64.

      See [RFC6146] for the definition of NAT46.

      See [RFC6296] for the definition of NAT66.

      See [RFC0791] for the definition of IPv4.

      See [RFC8200] for the definition of IPv6.

  • NEW:

    • Description:

      Values are listed in the natType registry.

    • Additional Information:

      See the assigned NAT types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type].

      See [RFC3022] for the definition of NAT.

      See [RFC1631] for the definition of NAT44.

      See [RFC6144] for the definition of NAT46.

      See [RFC6146] for the definition of NAT64.

      See [RFC6296] for the definition of NPTv6.

      See [RFC0791] for the definition of IPv4.

      See [RFC8200] for the definition of IPv6.

  • Note: This change also corrects errors in the pointers provided NAT46/NAT64.

6.11. 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 [RFC5475]. For their parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters.

      The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters.

      There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.

    • Additional Information:

  • 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 their parameters. For the methods 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. 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 assigned PSAMP parameters at [https://www.iana.org/assignments/psamp-parameters].

6.12. informationElementDataType

  • OLD:

    • Description:

      A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify.

    • Additional Information:

  • NEW:

    • Description:

      A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in Section 3.1 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry.

      The [informationElementDataType] subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify.

    • Additional Information:

      See the assigned emelement data types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types].

6.13. informationElementSemantics

  • OLD:

    • Description:

      A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model [RFC5102]; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify.

    • Additional Information:

  • NEW:

    • Description:

      A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in Section 3.2 of the IPFIX Information Model [RFC5102]; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the [IPFIX Information Element Semantics] subregistry; 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] subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action [RFC8126] to modify.

    • Additional Information:

      See the assigned semantics of an IPFIX Information Element at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-semantic].

6.14. informationElementUnits

  • OLD:

    • Description:

      A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in section 5 of the IPFIX Information Model [RFC5102]; 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.

    • Additional Information:

  • NEW:

    • Description:

      A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model [RFC5102]; see that section for more information on the types described in the informationElementsUnits subregistry. These types can take the values in the [IANA IPFIX Information Element Units] subregistry. The special value 0x00 (none) is used to note that the field is unitless.

    • Additional Information: See the assigned units of an IPFIX Information Element at [IANA IPFIX Information Element Units].

6.15. 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.

    • Additional Information:

  • NEW:

    • Description:

      The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, i.e., the range is defined in some other way.

    • Additional Information:

      Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.

6.16. 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.

    • Additional Information:

  • NEW:

    • Description:

      The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, i.e., the range is defined in some other way.

    • Additional Information:

      Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.

6.17. 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 assigned ingress interface types at [https://www.iana.org/assignments/ianaiftype-mib].

6.18. 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 assigned egress interface types at [https://www.iana.org/assignments/ianaiftype-mib].

6.19. 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.

    • Additional Information:

  • 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 registry is intended to list a complete set of possible value distribution methods.

    • Additional Information:

      See the assigned distributed methods at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method].

6.20. 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.

    • Additional Information:

  • 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. 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.

    • Additional Information:

      See the assigned flow selector algorithms at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm].

6.21. 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 registry.

      Further 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 assigned data link frame types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type].

      More information about the data link layer can be found in (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994).

6.22. 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 [RFC6313]. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data.

      Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics.

    • Additional Information:

  • 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 [RFC6313]. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data.

      Values are listed in the mibCaptureTimeSemantics registry.

    • Additional Information:

      See the assigned values for the MIB capture time semantics at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics].

6.23. 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 [RFC0791] for the definition of the IPv4 source address field.

      See [RFC3022] for the definition of NAT.

      See [RFC3234] 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" registry.

    • Additional Information:

      See the assigned events for exceeded NAT quota at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event].

      See [RFC0791] for the definition of the IPv4 source address field.

      See [RFC3022] for the definition of NAT.

      See [RFC3234] for the definition of middleboxes.

6.24. 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 [RFC0791] for the definition of the IPv4 source address field.

      See [RFC3022] for the definition of NAT.

      See [RFC3234] 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" registry.

    • Additional Information:

      See the assigned values for the NAT Threshold events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event].

      See [RFC0791] for the definition of the IPv4 source address field.

      See [RFC3022] for the definition of NAT.

      See [RFC3234] for the definition of middleboxes.

7. Misc

This document requests IANA to update the description of the following entries in [IANA-IPFIX].

7.1. 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.

7.2. 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 [RFC1321], place the resulting value in this Information Element, and export the buffered message.

      This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.

  • NEW:

    • Description:

      The MD5 checksum of the IPFIX Message containing this record. This Information Element SHOULD be bound to its containing IPFIX Message via an options record and the messageScope Information Element, and SHOULD appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in [RFC1321], place the resulting value in this Information Element, and export the buffered message.

      This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.

7.3. anonymizationFlags 

+--------+----------+-----------------------------------------------+
| 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.)   |
+--------+----------+-----------------------------------------------+

+--------+----------+-----------------------------------------------+
| bit(s) | name     | description                                   |
| (LSB = |          |                                               |
| 0)     |          |                                               |
+--------+----------+-----------------------------------------------+
| 0-1    | SC       | Stability Class: see the Stability Class      |
|        |          | table below, and Section 5.1 of [RFC6235].    |
| 2      | PmA      | Perimeter Anonymization: when set (1),        |
|        |          | source- Information Elements as described in  |
|        |          | [RFC5103] are interpreted as external         |
|        |          | addresses, and destination- Information       |
|        |          | Elements as described in [RFC5103] are        |
|        |          | interpreted as internal addresses, for the    |
|        |          | purposes of associating                       |
|        |          | anonymizationTechnique to Information         |
|        |          | Elements only; see Section 7.2.2 of [RFC6235] |
|        |          | for details.                                  |
|        |          | This bit MUST NOT be set when associated with |
|        |          | a non-endpoint (i.e., source- or              |
|        |          | destination-) Information Element.  SHOULD be |
|        |          | consistent within a record (i.e., if a        |
|        |          | source- Information Element has this flag     |
|        |          | set, the corresponding destination- element   |
|        |          | SHOULD have this flag set, and vice-versa.)   |
+--------+----------+-----------------------------------------------+

7.4. informationElementDescription

  • OLD:

    • Description:

      A UTF-8 [RFC3629] encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription MAY be annotated with one or more language tags [RFC4646], encoded in-line [RFC2482] within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages MAY tag each section with its own language tag; in this case, the description information in each language SHOULD have equivalent meaning. In the absence of any language tag, the "i-default" [RFC2277] language SHOULD be assumed.

      See the Security Considerations section for notes on string handling for Information Element type records.

  • NEW:

    • Description:

      A UTF-8 [RFC3629] encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription MAY be annotated with one or more language tags [RFC4646], encoded in-line [RFC2482] within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages MAY tag each section with its own language tag; in this case, the description information in each language SHOULD have equivalent meaning. In the absence of any language tag, the "i-default" [RFC2277] language SHOULD be assumed.

      See the Security Considerations Section of [RFC5610] for notes on string handling for Information Element type records.

7.5. 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.

7.6. 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.

8. Security Considerations

IPFIX security considerations are discussed in Section 8 of [RFC7012].

9. IANA Considerations

Sections 4 to 7 include actions for IANA. These actions are not repeated here.

This document also requests IANA to update the reference clause of the "IPFIX Information Elements" registry [IANA-IPFIX] with the reference to this document.

9.1. IPFIX Subregistry for IPv6 Extension Headers

This document requests IANA to create a new registry entitled "ipv6ExtensionHeaders Bits" under the IANA IPFIX registry group [IANA-IPFIX].

When a new code is assigned to an IPv6 EH in [IANA-EH], a free bit is selected by IANA for this EH from "ipv6ExtensionHeaders Bits" registry and the registry is updated with the details that mirror the assigned EH. The "Label" mirrors the "keyword" of an EH as indicated in [IANA-Protocols], while the "Protocol Number" mirrors the "Protocol Number" in [IANA-EH]. IANA is requested to add the following note to [IANA-EH]:

  • Note:

    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. Modifications to existing registrations must be mirrored in [NEW_IPFIX_IPv6EH_SUBREGISTRY].

  • Note to the RFC Editor: Please replace [NEW_IPFIX_IPv6EH_SUBREGISTRY] with the link used by IANA for this new registry.

Otherwise, the registration policy for the registry is Expert Review (Section 4.5 of [RFC8126]). See more details in Section 9.2.

The initial values of this registry are as follows:

   Bit Label   Protocol Description
               Number
    0  DST      60      Destination Options for IPv6
    1  HOP       0      IPv6 Hop-by-Hop Options
    2  NoNxt     59     No Next Header for IPv6
    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      Mobility Header
    13 ESP      50      Encapsulating Security Payload
    14 AH       51      Authentication Header
    15                  Unassigned
    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

9.2. Guidelines for the Designated Experts

It is suggested that multiple designated experts be appointed for registry change requests.

Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is clear and fits the purpose of this registry.

Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

10. References

10.1. Normative References

[I-D.ietf-opsawg-ipfix-tcpo-v6eh]
Boucadair, M. and B. Claise, "Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements", Work in Progress, Internet-Draft, draft-ietf-opsawg-ipfix-tcpo-v6eh-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-tcpo-v6eh-06>.
[IANA-EH]
"Internet Protocol Version 6 (IPv6) Parameters, IPv6 Extension Header Types", n.d., <https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-1>.
[IANA-IPFIX]
"IP Flow Information Export (IPFIX) Entities", n.d., <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[IANA-Protocols]
"Protocol Numbers", n.d., <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6994]
Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, , <https://www.rfc-editor.org/rfc/rfc6994>.
[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/rfc/rfc7011>.
[RFC7012]
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, , <https://www.rfc-editor.org/rfc/rfc7012>.
[RFC7013]
Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, , <https://www.rfc-editor.org/rfc/rfc7013>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

10.2. Informative References

[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-limits-12>.
[I-D.ietf-opsawg-rfc7125-update]
Boucadair, M., "An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element", Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc7125-update-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc7125-update-07>.
[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/rfc/rfc791>.
[RFC1321]
Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, , <https://www.rfc-editor.org/rfc/rfc1321>.
[RFC1631]
Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, DOI 10.17487/RFC1631, , <https://www.rfc-editor.org/rfc/rfc1631>.
[RFC2277]
Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, , <https://www.rfc-editor.org/rfc/rfc2277>.
[RFC2482]
Whistler, K. and G. Adams, "Language Tagging in Unicode Plain Text", RFC 2482, DOI 10.17487/RFC2482, , <https://www.rfc-editor.org/rfc/rfc2482>.
[RFC3022]
Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, , <https://www.rfc-editor.org/rfc/rfc3022>.
[RFC3031]
Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, , <https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3234]
Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, , <https://www.rfc-editor.org/rfc/rfc3234>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, , <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC3775]
Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, DOI 10.17487/RFC3775, , <https://www.rfc-editor.org/rfc/rfc3775>.
[RFC4302]
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/rfc/rfc4303>.
[RFC4646]
Phillips, A. and M. Davis, "Tags for Identifying Languages", RFC 4646, DOI 10.17487/RFC4646, , <https://www.rfc-editor.org/rfc/rfc4646>.
[RFC5102]
Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, , <https://www.rfc-editor.org/rfc/rfc5102>.
[RFC5103]
Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, DOI 10.17487/RFC5103, , <https://www.rfc-editor.org/rfc/rfc5103>.
[RFC5475]
Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, , <https://www.rfc-editor.org/rfc/rfc5475>.
[RFC5477]
Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, , <https://www.rfc-editor.org/rfc/rfc5477>.
[RFC5610]
Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, DOI 10.17487/RFC5610, , <https://www.rfc-editor.org/rfc/rfc5610>.
[RFC5655]
Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, , <https://www.rfc-editor.org/rfc/rfc5655>.
[RFC6144]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, , <https://www.rfc-editor.org/rfc/rfc6144>.
[RFC6146]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, , <https://www.rfc-editor.org/rfc/rfc6146>.
[RFC6235]
Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, , <https://www.rfc-editor.org/rfc/rfc6235>.
[RFC6296]
Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, , <https://www.rfc-editor.org/rfc/rfc6296>.
[RFC6313]
Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, , <https://www.rfc-editor.org/rfc/rfc6313>.
[RFC6759]
Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)", RFC 6759, DOI 10.17487/RFC6759, , <https://www.rfc-editor.org/rfc/rfc6759>.
[RFC7014]
D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, , <https://www.rfc-editor.org/rfc/rfc7014>.
[RFC7015]
Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", RFC 7015, DOI 10.17487/RFC7015, , <https://www.rfc-editor.org/rfc/rfc7015>.
[RFC7125]
Trammell, B. and P. Aitken, "Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element", RFC 7125, DOI 10.17487/RFC7125, , <https://www.rfc-editor.org/rfc/rfc7125>.
[RFC7133]
Kashima, S., Kobayashi, A., Ed., and P. Aitken, "Information Elements for Data Link Layer Traffic Measurement", RFC 7133, DOI 10.17487/RFC7133, , <https://www.rfc-editor.org/rfc/rfc7133>.
[RFC7270]
Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10.17487/RFC7270, , <https://www.rfc-editor.org/rfc/rfc7270>.
[RFC8038]
Aitken, P., Ed., Claise, B., S, S. B., McDowall, C., and J. Schoenwaelder, "Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol", RFC 8038, DOI 10.17487/RFC8038, , <https://www.rfc-editor.org/rfc/rfc8038>.
[RFC8158]
Sivakumar, S. and R. Penno, "IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events", RFC 8158, DOI 10.17487/RFC8158, , <https://www.rfc-editor.org/rfc/rfc8158>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/rfc/rfc8200>.

Acknowledgments

Thanks to Paul Aitken for the review. Special thanks to Andrew Feren for sharing data about scans of IPFIX data he collected.

Thomas Graf tagged an issue with the forwardingStatus Information Element.

Thanks to Eric Vyncke for the review and comments.

Thanks to Qin Wu for the opsdir review and Behcet Sarikay for the genart review.

Authors' Addresses

Mohamed Boucadair
Orange
Benoit Claise
Huawei