<pre>Internet Engineering Task Force (IETF)                    B. Claise, Ed.
Request for Comments: 7012                           Cisco Systems, Inc.
Obsoletes: <a href="./rfc5102">5102</a>                                         B. Trammell, Ed.
Category: Standards Track                                     ETH Zurich
ISSN: 2070-1721                                           September 2013


        <span class="h1">Information Model for IP Flow Information Export (IPFIX)</span>

Abstract

   This document defines the data types and management policy for the
   information model for the IP Flow Information Export (IPFIX)
   protocol.  This information model is maintained as the IANA "IPFIX
   Information Elements" registry, the initial contents of which were
   defined by <a href="./rfc5102">RFC 5102</a>.  This information model is used by the IPFIX
   protocol for encoding measured traffic information and information
   related to the traffic Observation Point, the traffic Metering
   Process, and the Exporting Process.  Although this model was
   developed for the IPFIX protocol, it is defined in an open way that
   allows it to be easily used in other protocols, interfaces, and
   applications.  This document obsoletes <a href="./rfc5102">RFC 5102</a>.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7012">http://www.rfc-editor.org/info/rfc7012</a>.















<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. Changes since <a href="./rfc5102">RFC 5102</a> .....................................<a href="#page-4">4</a>
      <a href="#section-1.2">1.2</a>. IPFIX Documents Overview ...................................<a href="#page-4">4</a>
   <a href="#section-2">2</a>. Properties of IPFIX Protocol Information Elements ...............<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Information Element Specification Template .................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Scope of Information Elements ..............................<a href="#page-7">7</a>
      <a href="#section-2.3">2.3</a>. Naming Conventions for Information Elements ................<a href="#page-8">8</a>
   <a href="#section-3">3</a>. Type Space ......................................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Abstract Data Types ........................................<a href="#page-9">9</a>
           <a href="#section-3.1.1">3.1.1</a>. unsigned8 ...........................................<a href="#page-9">9</a>
           <a href="#section-3.1.2">3.1.2</a>. unsigned16 ..........................................<a href="#page-9">9</a>
           <a href="#section-3.1.3">3.1.3</a>. unsigned32 ..........................................<a href="#page-9">9</a>
           <a href="#section-3.1.4">3.1.4</a>. unsigned64 ..........................................<a href="#page-9">9</a>
           <a href="#section-3.1.5">3.1.5</a>. signed8 ............................................<a href="#page-10">10</a>
           <a href="#section-3.1.6">3.1.6</a>. signed16 ...........................................<a href="#page-10">10</a>
           <a href="#section-3.1.7">3.1.7</a>. signed32 ...........................................<a href="#page-10">10</a>
           <a href="#section-3.1.8">3.1.8</a>. signed64 ...........................................<a href="#page-10">10</a>
           <a href="#section-3.1.9">3.1.9</a>. float32 ............................................<a href="#page-10">10</a>
           <a href="#section-3.1.10">3.1.10</a>. float64 ...........................................<a href="#page-10">10</a>
           <a href="#section-3.1.11">3.1.11</a>. boolean ...........................................<a href="#page-10">10</a>
           <a href="#section-3.1.12">3.1.12</a>. macAddress ........................................<a href="#page-10">10</a>
           <a href="#section-3.1.13">3.1.13</a>. octetArray ........................................<a href="#page-10">10</a>
           <a href="#section-3.1.14">3.1.14</a>. string ............................................<a href="#page-11">11</a>
           <a href="#section-3.1.15">3.1.15</a>. dateTimeSeconds ...................................<a href="#page-11">11</a>
           <a href="#section-3.1.16">3.1.16</a>. dateTimeMilliseconds ..............................<a href="#page-11">11</a>
           <a href="#section-3.1.17">3.1.17</a>. dateTimeMicroseconds ..............................<a href="#page-11">11</a>
           <a href="#section-3.1.18">3.1.18</a>. dateTimeNanoseconds ...............................<a href="#page-11">11</a>
           <a href="#section-3.1.19">3.1.19</a>. ipv4Address .......................................<a href="#page-11">11</a>
           <a href="#section-3.1.20">3.1.20</a>. ipv6Address .......................................<a href="#page-11">11</a>





<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


           <a href="#section-3.1.21">3.1.21</a>. basicList .........................................<a href="#page-11">11</a>
           <a href="#section-3.1.22">3.1.22</a>. subTemplateList ...................................<a href="#page-11">11</a>
           <a href="#section-3.1.23">3.1.23</a>. subTemplateMultiList ..............................<a href="#page-12">12</a>
      <a href="#section-3.2">3.2</a>. Data Type Semantics .......................................<a href="#page-12">12</a>
           <a href="#section-3.2.1">3.2.1</a>. quantity ...........................................<a href="#page-12">12</a>
           <a href="#section-3.2.2">3.2.2</a>. totalCounter .......................................<a href="#page-12">12</a>
           <a href="#section-3.2.3">3.2.3</a>. deltaCounter .......................................<a href="#page-12">12</a>
           <a href="#section-3.2.4">3.2.4</a>. identifier .........................................<a href="#page-13">13</a>
           <a href="#section-3.2.5">3.2.5</a>. flags ..............................................<a href="#page-13">13</a>
   <a href="#section-4">4</a>. Information Element Identifiers ................................<a href="#page-13">13</a>
   <a href="#section-5">5</a>. Information Elements ...........................................<a href="#page-14">14</a>
   <a href="#section-6">6</a>. Extending the Information Model ................................<a href="#page-15">15</a>
   <a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-15">15</a>
      <a href="#section-7.1">7.1</a>. IPFIX Information Elements ................................<a href="#page-16">16</a>
      <a href="#section-7.2">7.2</a>. MPLS Label Type Identifier ................................<a href="#page-17">17</a>
      <a href="#section-7.3">7.3</a>. XML Namespace and Schema ..................................<a href="#page-17">17</a>
      <a href="#section-7.4">7.4</a>. Addition, Revision, and Deprecation .......................<a href="#page-18">18</a>
   <a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-19">19</a>
   <a href="#section-9">9</a>. Acknowledgments ................................................<a href="#page-19">19</a>
   <a href="#section-10">10</a>. References ....................................................<a href="#page-19">19</a>
      <a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-19">19</a>
      <a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-20">20</a>
   Contributors ......................................................<a href="#page-23">23</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The IP Flow Information Export (IPFIX) protocol serves as a means for
   transmitting information related to network traffic measurement.  The
   IPFIX Protocol Specification [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>] defines how Information
   Elements are transmitted and also specifies the encoding of a set of
   basic data types for these Information Elements.  However, the list
   of Information Elements that can be transmitted by the protocol, such
   as Flow attributes (source IP address, number of packets, etc.) and
   information about the Metering Process and Exporting Process (packet
   Observation Point, sampling rate, Flow timeout interval, etc.), is
   not specified in [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>].

   The IANA "IPFIX Information Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] is the
   current complete reference for IPFIX Information Elements.  The
   initial values for this registry were provided by [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>].

   This document complements the IPFIX Protocol Specification [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>]
   by providing an overview of the IPFIX information model and
   specifying data types for it.  IPFIX-specific terminology used in
   this document is defined in <a href="./rfc7011#section-2">Section&nbsp;2 of [RFC7011]</a>.  As in [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>],
   these IPFIX-specific terms have the first letter of a word
   capitalized when used in this document.




<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   The use of the term 'information model' is not fully in line with the
   definition of this term in [<a href="./rfc3444" title="&quot;On the Difference between Information Models and Data Models&quot;">RFC3444</a>], as the IPFIX information model
   does not specify relationships between Information Elements, nor does
   it specify a concrete encoding of Information Elements.  For an
   encoding suitable for use with the IPFIX protocol, see [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>].
   Besides the encoding used by the IPFIX protocol, other encodings of
   IPFIX Information Elements can be applied, for example, XML-based
   encodings.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Changes since <a href="./rfc5102">RFC 5102</a></span>

   This document obsoletes the Proposed Standard revision of the IPFIX
   information model specification [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>].  The following changes
   have been made to this document with respect to the previous
   document:

   - At the time of this publication, technical and editorial errata
     reported for [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] have been reviewed and addressed as needed.

   - All references to [<a href="./rfc5101" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information&quot;">RFC5101</a>] have been updated to [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>],
     reflecting changes to [<a href="./rfc5101" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information&quot;">RFC5101</a>].

   - Information Element definitions have been removed, as the reference
     for these is now [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>]; a historical note on categorizations
     of Information Elements as defined in [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] has been retained
     in <a href="#section-5">Section 5</a>.

   - The process for modifying [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] has been improved and is now
     described in [<a href="./rfc7013" title="&quot;Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements&quot;">RFC7013</a>]; <a href="#section-6">Section 6</a> has been updated accordingly, and
     a new <a href="#section-7.3">Section 7.3</a> provides IANA considerations for this process.

   - Definitions of timestamp data types have been clarified.

   - Appendices A and B have been removed.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  IPFIX Documents Overview</span>

   The IPFIX protocol provides network administrators with access to
   network flow information.  The architecture for the export of
   measured flow information out of an IPFIX Exporting Process to a
   Collecting Process is defined in [<a href="./rfc5470" title="&quot;Architecture for IP Flow Information Export&quot;">RFC5470</a>], per the requirements
   defined in [<a href="./rfc3917" title="&quot;Requirements for IP Flow Information Export (IPFIX)&quot;">RFC3917</a>].  The IPFIX Protocol Specification [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>]





<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   defines how IPFIX Data Records and templates are carried via a number
   of transport protocols from IPFIX Exporting Processes to IPFIX
   Collecting Processes.

   Four IPFIX optimizations/extensions are currently specified: a
   bandwidth-saving method for the IPFIX protocol [<a href="./rfc5473" title="&quot;Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports&quot;">RFC5473</a>], an
   efficient method for exporting bidirectional flows [<a href="./rfc5103" title="&quot;Bidirectional Flow Export Using IP Flow Information Export (IPFIX)&quot;">RFC5103</a>], a
   method for the definition and export of complex data structures
   [<a href="./rfc6313" title="&quot;Export of Structured Data in IP Flow Information Export (IPFIX)&quot;">RFC6313</a>], and the specification of the Protocol on IPFIX Mediators
   [<a href="#ref-IPFIX-MED-PROTO">IPFIX-MED-PROTO</a>] based on the IPFIX Mediation Framework [<a href="./rfc6183" title="&quot;IP Flow Information Export (IPFIX) Mediation: Framework&quot;">RFC6183</a>].

   IPFIX has a formal description of IPFIX Information Elements -- their
   names, data types, and additional semantic information -- as
   specified in this document.  The export of the Information Element
   types is specified in [<a href="./rfc5610" title="&quot;Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements&quot;">RFC5610</a>].

   [<a id="ref-RFC6728">RFC6728</a>] specifies a data model for configuring and monitoring
   devices that are IPFIX and Packet Sampling (PSAMP) compliant using
   the Network Configuration Protocol (NETCONF), while [<a href="./rfc6615" title="&quot;Definitions of Managed Objects for IP Flow Information Export&quot;">RFC6615</a>]
   specifies MIB modules for monitoring.

   In terms of development, [<a href="./rfc5153" title="&quot;IP Flow Information Export (IPFIX) Implementation Guidelines&quot;">RFC5153</a>] provides guidelines for the
   implementation and use of the IPFIX protocol, while [<a href="./rfc5471" title="&quot;Guidelines for IP Flow Information Export (IPFIX) Testing&quot;">RFC5471</a>]
   provides guidelines for testing.

   Finally, [<a href="./rfc5472" title="&quot;IP Flow Information Export (IPFIX) Applicability&quot;">RFC5472</a>] describes what types of applications can use the
   IPFIX protocol and how they can use the information provided.  It
   furthermore shows how the IPFIX framework relates to other
   architectures and frameworks.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Properties of IPFIX Protocol Information Elements</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Information Element Specification Template</span>

   Information in messages of the IPFIX protocol is modeled in terms of
   Information Elements of the IPFIX information model.  The IPFIX
   Information Elements mentioned in <a href="#section-5">Section 5</a> are specified in
   [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>].

   All Information Elements specified for the IPFIX protocol MUST have
   the following properties defined:

   name - A unique and meaningful name for the Information Element.








<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   elementId - A numeric identifier of the Information Element.  If this
      identifier is used without an enterprise identifier (see [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>]
      and the definition of enterpriseId listed below), then it is
      globally unique, and the list of allowed values is administered by
      IANA.  It is used for compact identification of an Information
      Element when encoding Templates in the protocol.

   description - The semantics of this Information Element.  Describes
      how this Information Element is derived from the Flow or other
      information available to the observer.  Information Elements of
      dataType string or octetArray that have length constraints (fixed
      length, minimum and/or maximum length) MUST note these constraints
      in their descriptions.

   dataType - One of the types listed in <a href="#section-3.1">Section 3.1</a> of this document or
      registered in the IANA "IPFIX Information Element Data Types"
      subregistry.  The type space for attributes is constrained to
      facilitate implementation.  The existing type space encompasses
      most primitive types used in modern programming languages, as well
      as some derived types (such as ipv4Address) that are common to
      this domain.

   status - The status of the specification of this Information Element.
      Allowed values are 'current' and 'deprecated'.  All newly defined
      Information Elements have 'current' status.  The process for
      moving Information Elements to the 'deprecated' status is defined
      in <a href="./rfc7013#section-5.3">Section&nbsp;5.3 of [RFC7013]</a>.

   Enterprise-specific Information Elements MUST have the following
   property defined:

   enterpriseId - Enterprises may wish to define Information Elements
      without registering them with IANA, for example, for enterprise-
      internal purposes.  For such Information Elements, the Information
      Element identifier described above is not sufficient when the
      Information Element is used outside the enterprise.  If
      specifications of enterprise-specific Information Elements are
      made public and/or if enterprise-specific identifiers are used by
      the IPFIX protocol outside the enterprise, then the enterprise-
      specific identifier MUST be made globally unique by combining it
      with an enterprise identifier.  Valid values for the enterpriseId
      are defined by IANA as Structure of Management Information (SMI)
      network management private enterprise numbers, defined at
      [<a href="#ref-IANA-PEN" title="&quot;Private Enterprise Numbers&quot;">IANA-PEN</a>].







<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   All Information Elements specified for the IPFIX protocol either in
   this document or by any future extension MAY have the following
   properties defined:

   dataTypeSemantics - The integral types are qualified by additional
      semantic details.  Valid values for the data type semantics are
      either specified in <a href="#section-3.2">Section 3.2</a> of this document or will be
      specified in a future extension of the information model.

   units - If the Information Element is a measure of some kind, the
      units identify what the measure is.

   range - Some Information Elements may only be able to take on a
      restricted set of values that can be expressed as a range (e.g., 0
      through 511, inclusive).  If this is the case, the valid inclusive
      range SHOULD be specified; values for this Information Element
      outside the range are invalid and MUST NOT be exported.

   reference - Identifies additional specifications that more precisely
      define this item or provide additional context for its use.

   The following two Information Element properties are defined to allow
   the management of an Information Elements registry with Information
   Element definitions that may be updated over time, per the process
   defined in <a href="./rfc7013#section-5.2">Section&nbsp;5.2 of [RFC7013]</a>:

   revision - The revision number of an Information Element, starting at
      0 for Information Elements at time of definition and incremented
      by one for each revision.

   date - The date of the entry of this revision of the Information
      Element into the registry.

   A template for specifying Information Elements is given in
   <a href="./rfc7013#section-9.1">Section&nbsp;9.1 of [RFC7013]</a>.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Scope of Information Elements</span>

   By default, most Information Elements have a scope specified in their
   definitions.  Within Data Records defined by Options Templates, the
   IPFIX protocol allows further limiting of the Information Element
   scope.  The new scope is specified by one or more scope fields and
   defined as the combination of all specified scope values; see
   <a href="#section-3.4.2.1">Section 3.4.2.1</a> on IPFIX scopes in [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>].







<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Naming Conventions for Information Elements</span>

   The following naming conventions were used for naming Information
   Elements in this document.  It is recommended that extensions of the
   model use the same conventions.

   o  Names of Information Elements SHOULD be descriptive.

   o  Names of Information Elements MUST be unique within the "IPFIX
      Information Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>].  Enterprise-specific
      Information Elements SHOULD be prefixed with a vendor name.

   o  Names of Information Elements MUST start with lowercase letters.

   o  Composed names MUST use capital letters for the first letter of
      each component (except for the first one).  All other letters are
      lowercase, even for acronyms.  Exceptions are made for acronyms
      containing a mixture of lowercase and capital letters, such as
      'IPv4' and 'IPv6'.  Examples are "sourceMacAddress" and
      "destinationIPv4Address".

   o  Middleboxes [<a href="./rfc3234" title="&quot;Middleboxes: Taxonomy and Issues&quot;">RFC3234</a>] may change Flow properties, such as the
      Differentiated Services Code Point (DSCP) value or the source IP
      address.  If an IPFIX Observation Point is located in the path of
      a Flow before one or more middleboxes that potentially modify
      packets of the Flow, then it may be desirable to also report Flow
      properties after the modification performed by the middleboxes.
      An example is an Observation Point before a packet marker changing
      a packet's IPv4 Type of Service (TOS) field that is encoded in
      Information Element ipClassOfService.  Then the value observed and
      reported by Information Element ipClassOfService is valid at the
      Observation Point but not after the packet passed the packet
      marker.  For reporting the change value of the TOS field, the
      IPFIX information model uses Information Elements that have a name
      prefix "post", for example, "postIpClassOfService".  Information
      Elements with prefix "post" report on Flow properties that are not
      necessarily observed at the Observation Point but that are
      obtained within the Flow's Observation Domain by other means
      considered to be sufficiently reliable, for example, by analyzing
      the packet marker's marking tables.











<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Type Space</span>

   This section describes the abstract data types that can be used for
   the specification of IPFIX Information Elements in <a href="#section-4">Section 4</a>.
   <a href="#section-3.1">Section 3.1</a> describes the set of abstract data types.

   Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
   signed8, signed16, signed32, and signed64 are integral data types.
   As described in <a href="#section-3.2">Section 3.2</a>, their data type semantics can be further
   specified, for example, by 'totalCounter', 'deltaCounter',
   'identifier', or 'flags'.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Abstract Data Types</span>

   This section describes the set of valid abstract data types of the
   IPFIX information model, independent of encoding.  Note that further
   abstract data types may be specified by future updates to this
   document.  Changes to the associated IPFIX "Information Element Data
   Types" subregistry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] specified in [<a href="./rfc5610" title="&quot;Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements&quot;">RFC5610</a>] require a
   Standards Action [<a href="./rfc5226" title="">RFC5226</a>].

   The current encodings of these data types for use with the IPFIX
   protocol are defined in [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>]; encodings allowing the use of the
   IPFIX Information Elements [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] with other protocols may be
   defined in the future by referencing this document.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  unsigned8</span>

   The type "unsigned8" represents a non-negative integer value in the
   range of 0 to 255.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  unsigned16</span>

   The type "unsigned16" represents a non-negative integer value in the
   range of 0 to 65535.

<span class="h4"><a class="selflink" id="section-3.1.3" href="#section-3.1.3">3.1.3</a>.  unsigned32</span>

   The type "unsigned32" represents a non-negative integer value in the
   range of 0 to 4294967295.

<span class="h4"><a class="selflink" id="section-3.1.4" href="#section-3.1.4">3.1.4</a>.  unsigned64</span>

   The type "unsigned64" represents a non-negative integer value in the
   range of 0 to 18446744073709551615.






<span class="grey">Claise &amp; Trammell            Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h4"><a class="selflink" id="section-3.1.5" href="#section-3.1.5">3.1.5</a>.  signed8</span>

   The type "signed8" represents an integer value in the range of -128
   to 127.

<span class="h4"><a class="selflink" id="section-3.1.6" href="#section-3.1.6">3.1.6</a>.  signed16</span>

   The type "signed16" represents an integer value in the range of
   -32768 to 32767.

<span class="h4"><a class="selflink" id="section-3.1.7" href="#section-3.1.7">3.1.7</a>.  signed32</span>

   The type "signed32" represents an integer value in the range of
   -2147483648 to 2147483647.

<span class="h4"><a class="selflink" id="section-3.1.8" href="#section-3.1.8">3.1.8</a>.  signed64</span>

   The type "signed64" represents an integer value in the range of
   -9223372036854775808 to 9223372036854775807.

<span class="h4"><a class="selflink" id="section-3.1.9" href="#section-3.1.9">3.1.9</a>.  float32</span>

   The type "float32" corresponds to an IEEE single-precision 32-bit
   floating-point type as defined in [<a href="#ref-IEEE.754.2008">IEEE.754.2008</a>].

<span class="h4"><a class="selflink" id="section-3.1.10" href="#section-3.1.10">3.1.10</a>.  float64</span>

   The type "float64" corresponds to an IEEE double-precision 64-bit
   floating-point type as defined in [<a href="#ref-IEEE.754.2008">IEEE.754.2008</a>].

<span class="h4"><a class="selflink" id="section-3.1.11" href="#section-3.1.11">3.1.11</a>.  boolean</span>

   The type "boolean" represents a binary value.  The only allowed
   values are "true" and "false".

<span class="h4"><a class="selflink" id="section-3.1.12" href="#section-3.1.12">3.1.12</a>.  macAddress</span>

   The type "macAddress" represents a MAC-48 address as defined in
   [<a href="#ref-IEEE.802-3.2012">IEEE.802-3.2012</a>].

<span class="h4"><a class="selflink" id="section-3.1.13" href="#section-3.1.13">3.1.13</a>.  octetArray</span>

   The type "octetArray" represents a finite-length string of octets.








<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h4"><a class="selflink" id="section-3.1.14" href="#section-3.1.14">3.1.14</a>.  string</span>

   The type "string" represents a finite-length string of valid
   characters from the Unicode coded character set [<a href="#ref-ISO.10646">ISO.10646</a>].  Unicode
   incorporates ASCII [<a href="./rfc20" title="&quot;ASCII format for Network Interchange&quot;">RFC20</a>] and the characters of many other
   international character sets.

<span class="h4"><a class="selflink" id="section-3.1.15" href="#section-3.1.15">3.1.15</a>.  dateTimeSeconds</span>

   The type "dateTimeSeconds" represents a time value expressed with
   second-level precision.

<span class="h4"><a class="selflink" id="section-3.1.16" href="#section-3.1.16">3.1.16</a>.  dateTimeMilliseconds</span>

   The type "dateTimeMilliseconds" represents a time value expressed
   with millisecond-level precision.

<span class="h4"><a class="selflink" id="section-3.1.17" href="#section-3.1.17">3.1.17</a>.  dateTimeMicroseconds</span>

   The type "dateTimeMicroseconds" represents a time value expressed
   with microsecond-level precision.

<span class="h4"><a class="selflink" id="section-3.1.18" href="#section-3.1.18">3.1.18</a>.  dateTimeNanoseconds</span>

   The type "dateTimeNanoseconds" represents a time value expressed with
   nanosecond-level precision.

<span class="h4"><a class="selflink" id="section-3.1.19" href="#section-3.1.19">3.1.19</a>.  ipv4Address</span>

   The type "ipv4Address" represents an IPv4 address.

<span class="h4"><a class="selflink" id="section-3.1.20" href="#section-3.1.20">3.1.20</a>.  ipv6Address</span>

   The type "ipv6Address" represents an IPv6 address.

<span class="h4"><a class="selflink" id="section-3.1.21" href="#section-3.1.21">3.1.21</a>.  basicList</span>

   The type "basicList" supports structured data export as described in
   [<a href="./rfc6313" title="&quot;Export of Structured Data in IP Flow Information Export (IPFIX)&quot;">RFC6313</a>]; see <a href="#section-4.5.1">Section 4.5.1</a> of that document for encoding details.

<span class="h4"><a class="selflink" id="section-3.1.22" href="#section-3.1.22">3.1.22</a>.  subTemplateList</span>

   The type "subTemplateList" supports structured data export as
   described in [<a href="./rfc6313" title="&quot;Export of Structured Data in IP Flow Information Export (IPFIX)&quot;">RFC6313</a>]; see <a href="#section-4.5.2">Section 4.5.2</a> of that document for
   encoding details.






<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h4"><a class="selflink" id="section-3.1.23" href="#section-3.1.23">3.1.23</a>.  subTemplateMultiList</span>

   The type "subTemplateMultiList" supports structured data export as
   described in [<a href="./rfc6313" title="&quot;Export of Structured Data in IP Flow Information Export (IPFIX)&quot;">RFC6313</a>]; see <a href="#section-4.5.3">Section 4.5.3</a> of that document for
   encoding details.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Data Type Semantics</span>

   This section describes the set of valid data type semantics of the
   IPFIX information model.  A subregistry of data type semantics
   [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] is established in [<a href="./rfc5610" title="&quot;Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements&quot;">RFC5610</a>]; the restrictions on the use
   of semantics below are compatible with those specified in
   <a href="#section-3.10">Section 3.10</a> of that document.  These semantics apply only to numeric
   types, as noted in the description of each semantic below.

   Further data type semantics may be specified by future updates to
   this document.  Changes to the associated "IPFIX Information Element
   Semantics" subregistry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] require a Standards Action
   [<a href="./rfc5226" title="">RFC5226</a>].

<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>.  quantity</span>

   "quantity" is a numeric (integral or floating point) value
   representing a measured value pertaining to the record.  This is
   distinguished from counters that represent an ongoing measured value
   whose "odometer" reading is captured as part of a given record.  This
   is the default semantic type of all numeric data types.

<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>.  totalCounter</span>

   "totalCounter" is an integral value reporting the value of a counter.
   Counters are unsigned and wrap back to zero after reaching the limit
   of the type.  For example, an unsigned64 with counter semantics will
   continue to increment until reaching the value of 2**64 - 1.  At this
   point, the next increment will wrap its value to zero and continue
   counting from zero.  The semantics of a total counter is similar to
   the semantics of counters used in the Simple Network Management
   Protocol (SNMP), such as Counter32 as defined in [<a href="./rfc2578" title="&quot;Structure of Management Information Version 2 (SMIv2)&quot;">RFC2578</a>].  The only
   difference between total counters and counters used in SNMP is that
   the total counters have an initial value of 0.  A total counter
   counts independently of the export of its value.

<span class="h4"><a class="selflink" id="section-3.2.3" href="#section-3.2.3">3.2.3</a>.  deltaCounter</span>

   "deltaCounter" is an integral value reporting the value of a counter.
   Counters are unsigned and wrap back to zero after reaching the limit
   of the type.  For example, an unsigned64 with counter semantics will
   continue to increment until reaching the value of 2**64 - 1.  At this



<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   point, the next increment will wrap its value to zero and continue
   counting from zero.  The semantics of a delta counter is similar to
   the semantics of counters used in SNMP, such as Counter32 as defined
   in [<a href="./rfc2578" title="&quot;Structure of Management Information Version 2 (SMIv2)&quot;">RFC2578</a>].  The only difference between delta counters and
   counters used in SNMP is that the delta counters have an initial
   value of 0.  A delta counter is reset to 0 each time it is exported
   and/or expires without export.

<span class="h4"><a class="selflink" id="section-3.2.4" href="#section-3.2.4">3.2.4</a>.  identifier</span>

   "identifier" is an integral value that serves as an identifier.
   Specifically, mathematical operations on two identifiers (aside from
   the equality operation) are meaningless.  For example, Autonomous
   System ID 1 * Autonomous System ID 2 is meaningless.  Identifiers
   MUST be one of the signed or unsigned data types.

<span class="h4"><a class="selflink" id="section-3.2.5" href="#section-3.2.5">3.2.5</a>.  flags</span>

   "flags" is an integral value that represents a set of bit fields.
   Logical operations are appropriate on such values, but other
   mathematical operations are not.  Flags MUST always be of an unsigned
   data type.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Information Element Identifiers</span>

   All Information Elements defined in the IANA "IPFIX Information
   Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] have their identifiers assigned
   by IANA.

   The values of these identifiers are in the range of 1-32767.  Within
   this range, Information Element identifier values in the sub-range of
   1-127 are compatible with field types used by NetFlow version 9
   [<a href="./rfc3954" title="&quot;Cisco Systems NetFlow Services Export Version 9&quot;">RFC3954</a>] for historical reasons.

   In general, IANA will add newly registered Information Elements to
   the registry, assigning the lowest available Information Element
   identifier in the range of 128-32767.

   Enterprise-specific Information Element identifiers have the same
   range of 1-32767, but they are coupled with an additional enterprise
   identifier.  For enterprise-specific Information Elements,
   Information Element identifier 0 is also reserved.  Enterprise-
   specific Information Element identifiers can be chosen by an
   enterprise arbitrarily within the range of 1-32767.  The same
   identifier may be assigned by other enterprises for different
   purposes; these Information Elements are distinct because the
   Information Element identifier is coupled with an enterprise
   identifier.



<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   Enterprise identifiers are to be registered as SMI network management
   private enterprise code numbers with IANA.  The registry can be found
   at [<a href="#ref-IANA-PEN" title="&quot;Private Enterprise Numbers&quot;">IANA-PEN</a>].

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Information Elements</span>

   [<a id="ref-IANA-IPFIX">IANA-IPFIX</a>] is now the normative reference for IPFIX Information
   Elements.  When [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] was published, it defined, in its
   <a href="#section-5">Section 5</a>, the initial contents of that registry.

   As a historical note, Information Elements (IEs) were organized into
   categories in [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] according to their semantics and their
   applicability; these categories were not carried forward into
   [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] as an organizing principle.  The categories (with
   example IEs) were:

      1.  Identifiers (e.g., ingressInterface)
      2.  Metering and Exporting Process Configuration
          (e.g., exporterIPv4Address)
      3.  Metering and Exporting Process Statistics
          (e.g., exportedOctetTotalCount)
      4.  IP Header Fields (e.g., sourceIPv4Address)
      5.  Transport Header Fields (e.g., sourceTransportPort)
      6.  Sub-IP Header Fields (e.g., sourceMacAddress)
      7.  Derived Packet Properties (e.g., bgpSourceAsNumber)
      8.  Min/Max Flow Properties (e.g., minimumIpTotalLength)
      9.  Flow Timestamps (e.g., flowStartTimeMilliseconds)
      10. Per-Flow Counters (e.g., octetDeltaCount)
      11. Miscellaneous Flow Properties (e.g., flowEndReason)
      12. Padding (paddingOctets)

   Information Elements derived from fields of packets or from Packet
   Treatment can typically serve as Flow Keys used for mapping packets
   to Flows.  These Information Elements were placed in categories 4-7
   in the original categorization.

   Information Elements not serving as Flow Keys may have different
   values for each packet in a Flow.  For Information Elements with
   values derived from fields of packets or from Packet Treatment, and
   for which the value may change from packet to packet within a single
   Flow, the exported value of an Information Element is by default
   determined by the first packet observed for the corresponding Flow;
   the description of the Information Element may, however, explicitly
   specify different semantics.  This simple rule allows the writing of
   all Information Elements related to header fields once, when the
   first packet of the Flow is observed.  For further observed packets





<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   of the same Flow, only Flow properties that depend on more than one
   packet need to be updated; these Information Elements were placed in
   categories 8-11 in the original categorization.

   Information Elements with a name having the "post" prefix (e.g.,
   postIpClassOfService) do not necessarily report properties that were
   actually observed at the Observation Point but may be retrieved by
   other means within the Observation Domain.  These Information
   Elements can be used if there are middlebox functions within the
   Observation Domain changing Flow properties after packets passed the
   Observation Point; they may also be reported directly by the
   Observation Point if the Observation Point is situated where it can
   observe packets on both sides of the middlebox.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Extending the Information Model</span>

   A key requirement for IPFIX is to allow for extension of the
   Information Model via the "IP Flow Information Export (IPFIX)
   Entities" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>].  New Information Element definitions
   can be added to this registry subject to Expert Review [<a href="./rfc5226" title="">RFC5226</a>],
   with additional process considerations as described in [<a href="./rfc7013" title="&quot;Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements&quot;">RFC7013</a>];
   that document also provides guidelines for authors and reviewers of
   new Information Element definitions.

   For new Information Elements, the type space defined in <a href="#section-3">Section 3</a> can
   be used.  If required, new abstract data types can be added to the
   "IPFIX Information Element Data Types" subregistry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] as
   defined in [<a href="./rfc5610" title="&quot;Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements&quot;">RFC5610</a>].  New abstract data types and semantics are
   subject to Standards Action [<a href="./rfc5226" title="">RFC5226</a>] and MUST be defined in IETF
   Standards Track documents updating this document.

   Enterprises may wish to define Information Elements without
   registering them with IANA.  IPFIX explicitly supports enterprise-
   specific Information Elements.  Enterprise-specific Information
   Elements are described in Sections <a href="#section-2.1">2.1</a> and <a href="#section-4">4</a>; guidelines for using
   them appear in [<a href="./rfc7013" title="&quot;Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements&quot;">RFC7013</a>].

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IANA Considerations</span>

   As this document obsoletes [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>], IANA has updated the references
   in the "IP Flow Information Export (IPFIX) Entities" registry
   [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>], the "IPFIX MPLS label type" subregistry of that
   registry, the urn:ietf:params:xml:ns:ipfix-info XML namespace, and
   the urn:ietf:params:xml:schema:ipfix-info XML schema to refer to this
   document.






<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   However, [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] still provides a historical reference for the
   initial entries in the "IPFIX Information Elements" registry.
   Therefore, IANA has kept [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] as the requestor of those
   Information Elements in the "IPFIX Information Elements" registry
   that list [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] as their requestor and added the following
   explanatory note to the "IPFIX Information Elements" registry:

      "<a href="./rfc7012">RFC 7012</a> has obsoleted <a href="./rfc5102">RFC 5102</a>; references to <a href="./rfc5102">RFC 5102</a> in this
      registry remain as part of the historical record".

   The Information Element Specification Template (<a href="#section-2.1">Section 2.1</a>) requires
   two new columns not present in [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>].  IANA has created a new
   Revision column in the "IPFIX Information Elements" registry and set
   the Revision of existing Information Elements to 0.  IANA has also
   created a new Date column in that registry and set the Date of all
   existing Information Elements to the publication date of this
   document.

   To identify Information Elements with identifiers 127 or below as
   NetFlow version 9 [<a href="./rfc3954" title="&quot;Cisco Systems NetFlow Services Export Version 9&quot;">RFC3954</a>] compatible, IANA has set the Name of all
   existing Reserved Information Elements with identifier 127 or less to
   "Assigned for NetFlow v9 compatibility" and the Reference of those
   Information Elements to [<a href="./rfc3954" title="&quot;Cisco Systems NetFlow Services Export Version 9&quot;">RFC3954</a>].

   As IANA now has change control of the schema used for the IANA "IPFIX
   Information Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>], IANA has deprecated the
   previous XML schema for the description of Information Elements
   urn:ietf:params:xml:schema:ipfix-info [<a href="#ref-IPFIX-XML-SCHEMA">IPFIX-XML-SCHEMA</a>].

   To support the process described in <a href="#section-7.4">Section 7.4</a>, IANA has established
   a mailing list for communicating with the IE-DOCTORS, named
   ie-doctors@ietf.org.

   The remaining subsections of this section contain no actions
   for IANA.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  IPFIX Information Elements</span>

   This document refers to Information Elements, for which the Internet
   Assigned Numbers Authority (IANA) has created the IPFIX "Information
   Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>].  The columns of this registry must,
   at minimum, be able to store the information defined in the template
   detailed in <a href="#section-2.1">Section 2.1</a>; it may contain other information as
   necessary for the management of the registry.

   The process for making additions or other changes to the "IPFIX
   Information Elements" registry is given in <a href="#section-7.4">Section 7.4</a>.




<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  MPLS Label Type Identifier</span>

   Information Element #46, named mplsTopLabelType, carries MPLS label
   types.  Values for 5 different types have initially been defined.
   For ensuring the extensibility of this information, IANA has created
   a new subregistry for MPLS label types and filled it with the initial
   list from the description Information Element #46, mplsTopLabelType.

   New assignments for MPLS label types are administered by IANA through
   Expert Review [<a href="./rfc5226" title="">RFC5226</a>], i.e., review by one of a group of experts
   designated by an IETF Area Director.  The group of experts must
   double-check the label type definitions with already-defined label
   types for completeness, accuracy, and redundancy.  The specification
   of new MPLS label types MUST be published using a well-established
   and persistent publication medium.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  XML Namespace and Schema</span>

   The prior version of this document [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] specified an XML schema
   for IPFIX Information Element definitions [<a href="#ref-IPFIX-XML-SCHEMA">IPFIX-XML-SCHEMA</a>] that was
   used in the generation of the document text itself.  When the IANA
   "IPFIX Information Elements" registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] was created,
   change control on the registry and the schema used to validate it
   passed to IANA.

   The use of a machine-readable syntax for the registry enables the
   creation of IPFIX tools that can automatically adapt to extensions to
   the information model.  It should be noted that the use of XML in
   Exporters, Collectors, or other tools is not mandatory for the
   deployment of IPFIX.  In particular, Exporting Processes do not
   produce or consume XML as part of their operation.  IPFIX Collectors
   MAY take advantage of the machine-readability of the information
   model versus hard-coding their behavior or inventing proprietary
   means for accommodating extensions.  However, in order to avoid
   unnecessary load on the IANA infrastructure serving the registry,
   Collectors SHOULD NOT poll the IANA registry [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>] directly at
   runtime.

   The reference to the current schema is embedded in the registry
   [<a href="#ref-IANA-IPFIX">IANA-IPFIX</a>]; this schema may change from time to time as necessary
   to support the maintenance of the registry.  As such, the schema
   urn:ietf:params:xml:schema:ipfix-info [<a href="#ref-IPFIX-XML-SCHEMA">IPFIX-XML-SCHEMA</a>] specified in
   [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>] has been deprecated.








<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Addition, Revision, and Deprecation</span>

   New assignments for the "IPFIX Information Elements" registry are
   administered by IANA through Expert Review [<a href="./rfc5226" title="">RFC5226</a>].  These experts
   are referred to as IE-DOCTORS and are appointed by the IESG.  The
   process they follow is defined in [<a href="./rfc7013" title="&quot;Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements&quot;">RFC7013</a>].

   Information Element identifiers in the range of 1-127 are compatible
   with field types used by NetFlow version 9 [<a href="./rfc3954" title="&quot;Cisco Systems NetFlow Services Export Version 9&quot;">RFC3954</a>] for historical
   reasons and must not be assigned unless the Information Element is
   compatible with the NetFlow version 9 protocol, as determined by one
   of the IE-DOCTORS designated by the IESG as a NetFlow version 9
   expert.

   Future assignments added to the "IPFIX Information Elements" registry
   that require subregistries for enumerated values (e.g., <a href="#section-7.2">Section 7.2</a>)
   must have those subregistries added simultaneously with the new
   assignment; additions to these subregistries must be subject to
   Expert Review [<a href="./rfc5226" title="">RFC5226</a>].  Unless specified at assignment time, the
   experts for the subregistry will be the same as for the "IPFIX
   Information Elements" registry as a whole.

   When IANA receives a request to add, revise, or deprecate an
   Information Element in the "IPFIX Information Elements" registry, it
   forwards the request to the IE-DOCTORS for review.

   When IANA receives an approval for a request to add an Information
   Element definition from the IE-DOCTORS, it adds that Information
   Element to the registry.  The approved request may include changes
   made by the requestor and/or reviewers as compared to the original
   request.

   When IANA receives an approval for a request to revise an Information
   Element definition from the IE-DOCTORS, it changes that Information
   Element's definition in the registry and updates the Revision and
   Date columns as appropriate.  The approved request may include
   changes from the original request.  If the original Information
   Element was added to the registry with IETF consensus (i.e., was
   defined by an RFC), the revision will require IETF consensus as well.

   When IANA receives an approval for a request to deprecate an
   Information Element definition from the IE-DOCTORS, it changes that
   Information Element's definition in the registry and updates the
   Revision and Date columns as appropriate.  The approved request may
   include changes from the original request.  If the original
   Information Element was added to the registry with IETF consensus
   (i.e., was defined by an RFC), the deprecation will require IETF
   consensus as well.



<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Security Considerations</span>

   The IPFIX information model itself does not directly introduce
   security issues.  Rather, it defines a set of attributes that may,
   for privacy or business issues, be considered sensitive information.

   For example, exporting values of header fields may make attacks
   possible for the receiver of this information; this would otherwise
   only be possible for direct observers of the reported Flows along the
   data path.

   The underlying protocol used to exchange the information described
   here must therefore apply appropriate procedures to guarantee the
   integrity and confidentiality of the exported information.  These
   protocols are defined in separate documents, specifically the IPFIX
   protocol document [<a href="./rfc7011" title="&quot;Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information&quot;">RFC7011</a>].

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Acknowledgments</span>

   This document is substantially based on [<a href="./rfc5102" title="&quot;Information Model for IP Flow Information Export&quot;">RFC5102</a>].  The editors thank
   the authors of that document; those authors are listed below as
   contributors.  Special thanks go to Paul Aitken for the detailed
   review.  Finally, the authors thank the IPFIX WG chairs: Nevil
   Brownlee and Juergen Quittek.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC6313">RFC6313</a>]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
              "Export of Structured Data in IP Flow Information Export
              (IPFIX)", <a href="./rfc6313">RFC 6313</a>, July 2011.

   [<a id="ref-RFC7011">RFC7011</a>]  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,
              <a href="./rfc7011">RFC 7011</a>, September 2013.

   [<a id="ref-RFC7013">RFC7013</a>]  Trammell, B., and B. Claise, "Guidelines for Authors and
              Reviewers of IP Flow Information Export (IPFIX)
              Information Elements", <a href="https://www.rfc-editor.org/bcp/bcp184">BCP 184</a>, <a href="./rfc7013">RFC 7013</a>, September 2013.







<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-IANA-IPFIX">IANA-IPFIX</a>]
              IANA, "IP Flow Information Export (IPFIX) Entities",
              &lt;<a href="http://www.iana.org/assignments/ipfix/">http://www.iana.org/assignments/ipfix/</a>&gt;.

   [<a id="ref-IEEE.754.2008">IEEE.754.2008</a>]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Floating-Point Arithmetic", IEEE
              Standard 754, August 2008.

   [<a id="ref-IEEE.802-3.2012">IEEE.802-3.2012</a>]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Ethernet", IEEE Standard 802.3, 2012.

   [<a id="ref-IPFIX-MED-PROTO">IPFIX-MED-PROTO</a>]
              Claise, B., Kobayashi, A., and B. Trammell, "Operation of
              the IP Flow Information Export (IPFIX) Protocol on IPFIX
              Mediators", Work in Progress, July 2013.

   [<a id="ref-IPFIX-XML-SCHEMA">IPFIX-XML-SCHEMA</a>]
              IANA, "IETF XML Registry",
              &lt;<a href="http://www.iana.org/assignments/xml-registry/">http://www.iana.org/assignments/xml-registry/</a>&gt;.

   [<a id="ref-ISO.10646">ISO.10646</a>]
              International Organization for Standardization,
              "Information technology - Universal Coded Character Set
              (UCS)", ISO/IEC 10646:2012, November 2012.

   [<a id="ref-IANA-PEN">IANA-PEN</a>] IANA, "Private Enterprise Numbers",
              &lt;<a href="http://www.iana.org/assignments/enterprise-numbers">http://www.iana.org/assignments/enterprise-numbers</a>&gt;.

   [<a id="ref-RFC20">RFC20</a>]    Cerf, V., "ASCII format for Network Interchange", <a href="./rfc20">RFC 20</a>,
              October 1969.

   [<a id="ref-RFC2578">RFC2578</a>]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, <a href="./rfc2578">RFC 2578</a>, April 1999.

   [<a id="ref-RFC3234">RFC3234</a>]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", <a href="./rfc3234">RFC 3234</a>, February 2002.

   [<a id="ref-RFC3444">RFC3444</a>]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", <a href="./rfc3444">RFC 3444</a>,
              January 2003.






<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   [<a id="ref-RFC3917">RFC3917</a>]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              <a href="./rfc3917">RFC 3917</a>, October 2004.

   [<a id="ref-RFC3954">RFC3954</a>]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
              Version 9", <a href="./rfc3954">RFC 3954</a>, October 2004.

   [<a id="ref-RFC5101">RFC5101</a>]  Claise, B., Ed., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", <a href="./rfc5101">RFC 5101</a>, January 2008.

   [<a id="ref-RFC5102">RFC5102</a>]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              <a href="./rfc5102">RFC 5102</a>, January 2008.

   [<a id="ref-RFC5103">RFC5103</a>]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
              Using IP Flow Information Export (IPFIX)", <a href="./rfc5103">RFC 5103</a>,
              January 2008.

   [<a id="ref-RFC5153">RFC5153</a>]  Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P.
              Aitken, "IP Flow Information Export (IPFIX) Implementation
              Guidelines", <a href="./rfc5153">RFC 5153</a>, April 2008.

   [<a id="ref-RFC5226">RFC5226</a>]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
              May 2008.

   [<a id="ref-RFC5470">RFC5470</a>]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
              "Architecture for IP Flow Information Export", <a href="./rfc5470">RFC 5470</a>,
              March 2009.

   [<a id="ref-RFC5471">RFC5471</a>]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
              Flow Information Export (IPFIX) Testing", <a href="./rfc5471">RFC 5471</a>,
              March 2009.

   [<a id="ref-RFC5472">RFC5472</a>]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
              Flow Information Export (IPFIX) Applicability", <a href="./rfc5472">RFC 5472</a>,
              March 2009.

   [<a id="ref-RFC5473">RFC5473</a>]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
              in IP Flow Information Export (IPFIX) and Packet Sampling
              (PSAMP) Reports", <a href="./rfc5473">RFC 5473</a>, March 2009.

   [<a id="ref-RFC5610">RFC5610</a>]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", <a href="./rfc5610">RFC 5610</a>, July 2009.





<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


   [<a id="ref-RFC6183">RFC6183</a>]  Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
              "IP Flow Information Export (IPFIX) Mediation: Framework",
              <a href="./rfc6183">RFC 6183</a>, April 2011.

   [<a id="ref-RFC6615">RFC6615</a>]  Dietz, T., Ed., Kobayashi, A., Claise, B., and G. Muenz,
              "Definitions of Managed Objects for IP Flow Information
              Export", <a href="./rfc6615">RFC 6615</a>, June 2012.

   [<a id="ref-RFC6728">RFC6728</a>]  Muenz, G., Claise, B., and P. Aitken, "Configuration Data
              Model for the IP Flow Information Export (IPFIX) and
              Packet Sampling (PSAMP) Protocols", <a href="./rfc6728">RFC 6728</a>,
              October 2012.







































<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


Contributors

   Juergen Quittek
   NEC
   Kurfuersten-Anlage 36
   Heidelberg 69115
   Germany

   Phone: +49 6221 90511-15
   EMail: quittek@nw.neclab.eu
   URI:   <a href="http://www.neclab.eu/">http://www.neclab.eu/</a>


   Stewart Bryant
   Cisco Systems, Inc.
   10 New Square, Bedfont Lakes
   Feltham, Middlesex  TW18 8HA
   United Kingdom

   EMail: stbryant@cisco.com


   Paul Aitken
   Cisco Systems, Inc.
   96 Commercial Quay
   Edinburgh EH6 6LX
   Scotland

   Phone: +44 131 561 3616
   EMail: paitken@cisco.com


   Jeff Meyer
   PayPal
   2211 N. First St.
   San Jose, CA  95131-2021
   US

   Phone: +1 408 976-9149
   EMail: jemeyer@paypal.com
   URI:   <a href="http://www.paypal.com">http://www.paypal.com</a>










<span class="grey">Claise &amp; Trammell            Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7012">RFC 7012</a>                 IPFIX Information Model          September 2013</span>


Authors' Addresses

   Benoit Claise (editor)
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com


   Brian Trammell (editor)
   Swiss Federal Institute of Technology Zurich
   Gloriastrasse 35
   8092 Zurich
   Switzerland

   Phone: +41 44 632 70 13
   EMail: trammell@tik.ee.ethz.ch































Claise &amp; Trammell            Standards Track                   [Page 24]
</pre>