Ordered Information Element Export in IP Flow Information Export (IPFIX)
draft-claise-opsawg-ipfix-ordered-ie-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Benoît Claise , Paul Aitken , Holger Keller , Yao Liu | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-claise-opsawg-ipfix-ordered-ie-01
OPSAWG B. Claise
Internet-Draft Everything OPS & Arrcus
Updates: 7011, 5476, 6183 (if approved) P. Aitken
Intended status: Standards Track Ciena
Expires: 7 January 2027 H. Keller
Deutsche Telekom
Y. Liu
ZTE Corporation
6 July 2026
Ordered Information Element Export in IP Flow Information Export (IPFIX)
draft-claise-opsawg-ipfix-ordered-ie-01
Abstract
The IP Flow Information Export (IPFIX) protocol allows the same
Information Element to appear multiple times in a Template Record.
RFC 7011 states that multiple occurrences of the same Information
Element SHOULD follow the logical order of their treatments by the
Metering Process; however, no protocol mechanism exists for the
Exporting Process to explicitly signal to the Collecting Process that
this ordering is guaranteed. Without such a guarantee, the
Collecting Process cannot safely interpret repeated Information
Elements as ordered observations. This document describes the
problem, presents use cases, analyzes candidate solutions, and
specifies a mechanism -- a new Ordered Set type -- that establishes
an end-to-end ordering guarantee: the Metering Process records
repeated Information Element values in the order the corresponding
observations are made, the Exporting Process preserves and signals
this guarantee, and the Collecting Process interprets the n-th
occurrence of an Information Element as corresponding to the n-th
observation by the Metering Process at the Observation Point. This
document updates RFC 7011, RFC 5476, and RFC 6183.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-claise-opsawg-ipfix-ordered-
ie/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Claise, et al. Expires 7 January 2027 [Page 1]
Internet-Draft IPFIX Ordered IE July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement & Use Cases . . . . . . . . . . . . . . . . 8
3.1. The Ordering Ambiguity . . . . . . . . . . . . . . . . . 8
3.2. Information Element Proliferation . . . . . . . . . . . . 9
3.3. Ordering Ambiguity in PSAMP Options Template Records . . 10
3.4. Multi-Layer Encapsulated Traffic . . . . . . . . . . . . 11
4. New Ordered Set Specifications . . . . . . . . . . . . . . . 13
4.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Template Withdrawal . . . . . . . . . . . . . . . . . . . 14
4.3. Normative Behavior . . . . . . . . . . . . . . . . . . . 15
4.4. Updates to RFC 7011 . . . . . . . . . . . . . . . . . . . 16
4.5. Updates to RFC 5476 . . . . . . . . . . . . . . . . . . . 19
4.6. Updates to RFC 6183 . . . . . . . . . . . . . . . . . . . 19
4.7. New IPFIX Information Elements . . . . . . . . . . . . . 20
5. Operational Considerations . . . . . . . . . . . . . . . . . 20
5.1. Deployment and Coexistence . . . . . . . . . . . . . . . 21
5.2. Configuration . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Verification of Correct Operation . . . . . . . . . . . . 21
Claise, et al. Expires 7 January 2027 [Page 2]
Internet-Draft IPFIX Ordered IE July 2026
5.4. Fault Management . . . . . . . . . . . . . . . . . . . . 22
5.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. IPFIX Set IDs Registry . . . . . . . . . . . . . . . . . 23
7.2. IPFIX Information Elements Registry . . . . . . . . . . . 23
7.2.1. mplsLabelStackSection . . . . . . . . . . . . . . . . 24
7.2.2. mplsLabelType . . . . . . . . . . . . . . . . . . . . 25
7.2.3. mplsLabelIPv4Address . . . . . . . . . . . . . . . . 25
7.2.4. mplsLabelPrefixLength . . . . . . . . . . . . . . . . 26
7.2.5. mplsLabelIPv6Address . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Solution Space . . . . . . . . . . . . . . . . . . . 29
A.1. Updating RFC 7011 SHOULD to MUST Alone (Rejected) . . . . 29
A.2. RFC 6313 Structured Data with the "ordered" Semantic
(Rejected) . . . . . . . . . . . . . . . . . . . . . . . 30
A.3. New IPFIX Version 11 (Rejected) . . . . . . . . . . . . . 31
A.4. Marker Information Element (Evaluated) . . . . . . . . . 31
A.5. Options Template Indicator (Evaluated) . . . . . . . . . 32
A.6. New Ordered Set Type . . . . . . . . . . . . . . . . . . 32
Appendix B. Migration from Positional to Generic Information
Elements . . . . . . . . . . . . . . . . . . . . . . . . 34
B.1. MPLS Information Elements . . . . . . . . . . . . . . . . 34
B.2. IEEE 802.1ad Q-in-Q Information Elements . . . . . . . . 36
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
The IPFIX protocol [RFC7011] ("Specification of the IP Flow
Information Export (IPFIX) Protocol for the Exchange of Flow
Information") exports Flow information from an Exporting Process to
one or more Collecting Processes. An (Options) Template Record
defines the structure of a Data Record by specifying an ordered list
of Information Elements.
When the same Information Element appears more than once in a
Template Record, Section 8 of [RFC7011] states:
If an Information Element is required more than once in a
Template, the different occurrences of this Information Element
SHOULD follow the logical order of their treatments by the
Metering Process.
Claise, et al. Expires 7 January 2027 [Page 3]
Internet-Draft IPFIX Ordered IE July 2026
The use of SHOULD rather than MUST means that an Exporting Process is
not required to guarantee this ordering. Furthermore, Section 4.2
and Section 4.3 of [RFC7011] each explicitly state that "the order of
the Information Elements in the Template Records is not guaranteed."
Nevertheless, the Metering Process SHOULD record repeated Information
Element values in the order in which the corresponding observations
are made, as this is the natural basis for any ordering guarantee.
It is important to note that IPFIX is fundamentally an export
protocol: [RFC7011] defines the behavior of the Exporting Process and
the Collecting Process in detail, but places very few normative
constraints on the Metering Process. The IPFIX architecture
[RFC5470] ("Architecture for IP Flow Information Export") explicitly
scopes IPFIX as governing "the export of measured IP Flow information
from an IPFIX Exporting Process to a Collecting Process" and defines
the Metering Process as an internal component of the IPFIX Device --
alongside the Exporting Process, but not a protocol peer (see
Figure 2 of [RFC5470]). An end-to-end ordering guarantee requires
that all three components act consistently: the Metering Process
records values in the order in which they are observed at the
Observation Point, the Exporting Process preserves that order during
export, and the Collecting Process interprets the received ordering
accordingly.
There is consequently no IPFIX protocol mechanism by which the
Exporting Process can signal to the Collecting Process that the
ordering of repeated Information Elements is guaranteed to reflect
the Metering Process observation order -- even when the Metering
Process correctly records those observations in order. Without such
a signal, a Collecting Process cannot safely interpret the n-th
occurrence of an Information Element as corresponding to the n-th
observation made by the Metering Process at the Observation Point.
This limitation has several practical consequences, of which the
following are the most prominent:
1. Information Element Proliferation: position-specific Information
Elements accumulate in the IANA IPFIX registry to work around the
missing ordering guarantee (see Section 3.2).
2. Multi-Layer Encapsulation Ambiguity: without an ordering
guarantee, the Collecting Process cannot determine which
encapsulation layer a given Information Element occurrence
corresponds to (see Section 3.4).
The ordering problem also arises in the Packet Sampling (PSAMP)
protocol family [RFC5474] [RFC5475] [RFC5476], which uses IPFIX as
its export protocol and relies on IPFIX IEs to describe packet
Claise, et al. Expires 7 January 2027 [Page 4]
Internet-Draft IPFIX Ordered IE July 2026
selection and observation metadata. PSAMP defines a Composite
Selector as an ordered sequence of Primitive Selectors applied in
succession to a Packet Stream. Section 6.5.1 of [RFC5476] already
requires that selectorId Information Elements in the Selection
Sequence Report Options Template MUST be listed in the order the
corresponding Primitive Selectors are applied -- making the ordering
requirement for Options Template Records older than this document.
However, this requirement cannot be enforced at the IPFIX protocol
level: the Options Template Set (Set ID 3) of [RFC7011] provides no
mechanism for the Exporting Process to signal to the Collecting
Process that the ordering of repeated selectorId occurrences is
guaranteed. The Ordered Options Template Set (Set ID 5) defined in
this document closes this gap.
[RFC6313] ("Export of Structured Data in IP Flow Information Export
(IPFIX)") has sometimes been cited as a solution to this problem,
through the "ordered" semantic defined for its basicList and
subTemplateMultiList structured data types. However, as analyzed in
detail in Appendix A.2, the [RFC6313] "ordered" semantic is an export
ordering guarantee only -- it does not assert that the order reflects
the Metering Process observation order at the Observation Point.
Furthermore, [RFC6313] structured data still falls under the SHOULD
of Section 8 of [RFC7011] and does not upgrade it to a MUST.
[RFC6313] therefore does not solve the problem described in this
document.
This document specifies a mechanism to address these use cases by
providing an explicit ordering guarantee for repeated Information
Elements in an IPFIX (Options) Template Record. The scope of this
document is deliberately limited to this specific problem. Other
potential IPFIX improvements are explicitly out of scope.
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.
2.1. Terminology
This document uses the IPFIX-specific terminology defined in
[RFC7011], the PSAMP-specific terminology defined in [RFC5476], and
the IPFIX Mediation terminology defined in [RFC6183]. As in
[RFC7011], the first letter of each IPFIX-specific term is
capitalized.
Claise, et al. Expires 7 January 2027 [Page 5]
Internet-Draft IPFIX Ordered IE July 2026
The following terms are used as defined in [RFC7011]:
Collecting Process: The process in a Collector that receives and
processes IPFIX Messages.
Data Record: A record that contains values of the parameters
corresponding to a Template Record.
Data Set: A Set that contains one or more Data Records defined by
the same Template Record.
Exporting Process: The process in an Exporter that sends IPFIX
Messages to a Collecting Process.
Flow Record: A record that contains information about a specific
Flow.
Information Element: A protocol-independent description of an
attribute that has been observed or metered.
Metering Process: The process that generates Flow Records from
packet observations at an Observation Point.
Observation Domain: The largest set of Observation Points for which
Flow information can be aggregated by a Metering Process.
Observation Point: A location in the network where IP packets can be
observed.
Options Template Record: A Template Record that defines the
structure of an Options Data Record.
Options Template Set: A collection of one or more Options Template
Records that have been grouped together in an IPFIX Message.
Set: A collection of records that have a similar structure, prefixed
by a header.
Template Record: A record that defines the structure of a Data
Record.
Template Set: A collection of one or more Template Records that have
been grouped together in an IPFIX Message.
Transport Session: In SCTP, the Transport Session is the SCTP
association. In TCP, the Transport Session is the TCP connection.
In UDP, the Transport Session is the UDP session, uniquely
identified by the combination of IP addresses and UDP ports used.
Claise, et al. Expires 7 January 2027 [Page 6]
Internet-Draft IPFIX Ordered IE July 2026
Note: A Flow Record is a specific type of Data Record. Options Data
Records, which carry metadata rather than Flow measurements, are also
Data Records but not Flow Records.
The following term is modified from [RFC7011]:
Set ID: A field in the Set header that identifies the Set type.
Value 2 identifies a Template Set, value 3 an Options Template
Set, values 4 and 5 identify Ordered Template Sets and Ordered
Options Template Sets respectively as defined in this document,
and values 256 and above identify Data Sets. Values 6-255 are
reserved for future use.
The following terms are used as defined in [RFC5476]:
Composite Selector: An ordered composition of Selectors, in which
the output Packet Stream issuing from one Selector forms the input
Packet Stream to the succeeding Selector.
Primitive Selector: A Selector that applies exactly one selection
method and is the elemental component of a Composite Selector.
Selection Sequence: A specific combination of an Observation Point
and a Composite Selector, identified by a selectionSequenceId
Information Element.
The following term is used as defined in [RFC6183]:
IPFIX Mediator: An IPFIX Device that receives IPFIX Messages from
one or more Exporting Processes or other IPFIX Mediators,
optionally transforms them through one or more Intermediate
Processes, and forwards the results to one or more Collecting
Processes.
The following new terms are defined in this document:
Ordered Template Set: A Set with Set ID 4 that carries Ordered
Template Records. It uses the same wire format as the Template
Set (Set ID 2) defined in [RFC7011], with the addition that the
ordering of repeated Information Elements in the corresponding
Data Records is guaranteed to reflect the Metering Process
observation order at the Observation Point.
Ordered Options Template Set: A Set with Set ID 5 that carries
Ordered Options Template Records. It uses the same wire format as
the Options Template Set (Set ID 3) defined in [RFC7011], with the
same ordering guarantee as an Ordered Template Set.
Claise, et al. Expires 7 January 2027 [Page 7]
Internet-Draft IPFIX Ordered IE July 2026
Ordered Template Record: A Template Record transmitted in an Ordered
Template Set (Set ID 4). The order of Information Elements in an
Ordered Template Record is significant: when the same Information
Element appears more than once, its occurrences MUST reflect the
order in which the corresponding values are observed by the
Metering Process at the Observation Point.
Ordered Options Template Record: An Options Template Record
transmitted in an Ordered Options Template Set (Set ID 5), with
the same ordering guarantee as an Ordered Template Record.
Ordered Data Set: A Data Set whose Template ID refers to an Ordered
Template Record or an Ordered Options Template Record. The
ordering of fields in each Data Record within the Set reflects the
Metering Process observation order.
3. Problem Statement & Use Cases
3.1. The Ordering Ambiguity
The IPFIX protocol allows any Information Element to appear multiple
times in a Template Record. Section 8 of [RFC7011] provides the
following guidance and example:
If an Information Element is required more than once in a
Template, the different occurrences of this Information Element
SHOULD follow the logical order of their treatments by the
Metering Process. For example, when exporting the two source IP
addresses of an IPv4-in-IPv4 packet, the first sourceIPv4Address
Information Element occurrence should be the IPv4 address of the
outer header, while the second occurrence should be the address of
the inner header.
The use of SHOULD rather than MUST means that a conformant Exporting
Process is not required to respect this ordering. Even when the
Exporting Process does follow the ordering by convention, there is no
protocol field by which it can communicate this intent to the
Collecting Process.
Furthermore, the ordering of Information Elements may be affected by
optimizations within the Metering Process itself (for example,
software that processes packet headers from different encapsulation
layers in parallel rather than in strict observation order) or by
optimizations that intervene between the Metering Process and the
Exporting Process. Section 2.2 ("IPFIX Limitations") of [RFC6313]
notes that "some encoding optimizations are based on the permutation
of Information Element order", which conflicts with any strict
ordering requirement applied universally to all existing IPFIX Sets.
Claise, et al. Expires 7 January 2027 [Page 8]
Internet-Draft IPFIX Ordered IE July 2026
3.2. Information Element Proliferation
The absence of an ordering guarantee has led implementors to define
position-specific Information Elements, effectively polluting the
IANA IPFIX registry [IANA.IPFIX] with entries that exist solely to
work around the lack of an ordering mechanism. The MPLS label stack
is the most prominent example. Rather than using a single
mplsLabelStackSection (IPFIX IE TBD1) Information Element appearing
multiple times in ordered fashion, the IPFIX Information Elements
registry [RFC7012] ("Information Model for IP Flow Information Export
(IPFIX)") defines ten separate Information Elements:
* mplsTopLabelStackSection (IPFIX IE 70)
* mplsLabelStackSection2 (IPFIX IE 71)
* mplsLabelStackSection3 (IPFIX IE 72)
* mplsLabelStackSection4 (IPFIX IE 73)
* mplsLabelStackSection5 (IPFIX IE 74)
* mplsLabelStackSection6 (IPFIX IE 75)
* mplsLabelStackSection7 (IPFIX IE 76)
* mplsLabelStackSection8 (IPFIX IE 77)
* mplsLabelStackSection9 (IPFIX IE 78)
* mplsLabelStackSection10 (IPFIX IE 79)
This approach has some drawbacks:
* It consumes ten Information Element identifiers where one could
suffice.
* It artificially limits the exportable label stack depth to ten
entries.
* It cannot be generalized to other stacked or layered structures
without defining further sets of numbered Information Elements.
The same pattern extends beyond the label stack entries. A cluster
of Information Elements exists for attributes of the top-of-stack
label only: mplsTopLabelType (IPFIX IE 46), mplsTopLabelIPv4Address
(IPFIX IE 47), mplsTopLabelPrefixLength (IPFIX IE 91),
mplsTopLabelIPv6Address (IPFIX IE 140), mplsTopLabelTTL (IPFIX IE
Claise, et al. Expires 7 January 2027 [Page 9]
Internet-Draft IPFIX Ordered IE July 2026
200), mplsTopLabelExp (IPFIX IE 203), and postMplsTopLabelExp (IPFIX
IE 237). These exist because no general mechanism allows expressing
"the attribute of the label at stack position N." With ordered
export, a single repeated Information Element per attribute would
suffice.
A Metering Process observing MPLS traffic may observe a label stack
of arbitrary depth. An operator may wish to export the entire label
stack as a sequence of mplsLabelStackSection values, where the first
occurrence corresponds to the top of the stack, the second to the
next label, and so on.
With the mechanism specified in this document, the Exporting Process
can use a single mplsLabelStackSection Information Element repeated N
times in an Ordered Template Record and signal that the sequence
reflects the top-to-bottom order of the label stack as observed by
the Metering Process. This eliminates the need for the ten numbered
label-stack Information Elements. Since N is a free parameter
determined by the Exporting Process, label stacks of depth greater
than ten can be exported in full. This lifts the artificial cap
inherent in the positional naming scheme.
3.3. Ordering Ambiguity in PSAMP Options Template Records
The ordering requirement extends beyond Template Records: it also
applies to Options Template Records used by the Packet Sampling
(PSAMP) protocol [RFC5474] ("A Framework for Packet Selection and
Reporting") [RFC5475] ("Sampling and Filtering Techniques for IP
Packet Selection") [RFC5476] ("Packet Sampling (PSAMP) Protocol
Specifications"). This is the primary use case for the Ordered
Options Template Set (Set ID 5) specified in this document.
PSAMP defines a Composite Selector as "an ordered composition of
Selectors, in which the output Packet Stream issuing from one
Selector forms the input Packet Stream to the succeeding Selector"
([RFC5476]). The word "ordered" in the definition is architecturally
significant: a Composite Selector is a sequence, not a set.
The ordering matters semantically. Section 8.1 of [RFC5475]
demonstrates that filtering followed by sampling and sampling
followed by filtering produce different statistical results:
* Filter then Sample: the filter creates population subsets with
potentially different intensities, allowing the sampling rate to
be tuned per subset. Packets not matching the filter never load
the Sampling function.
Claise, et al. Expires 7 January 2027 [Page 10]
Internet-Draft IPFIX Ordered IE July 2026
* Sample then Filter: the same sampling rate is applied to the
entire stream before filtering; packets ultimately discarded by
the filter still consume sampling capacity.
A Composite Selector is exported using the Selection Sequence Report
Options Template defined in Section 6.5.1 of [RFC5476]. When the
Selection Sequence consists of multiple Primitive Selectors, the
selectorId Information Element appears once per Primitive Selector in
the same Options Template Record. Section 6.5.1 of [RFC5476] is
explicit:
"the selectorId's MUST be identified in the order they are used."
Section 6.5.1 of [RFC5476] illustrates this with a concrete example:
Selection Sequence 7 (Filter selectorId 5, then Sampler selectorId
10) and Selection Sequence 9 (Sampler selectorId 10, then Filter
selectorId 5) are distinct, produce different results, and are
differentiated solely by the order of the two selectorId occurrences
in the Options Template Record.
RFC 5476 therefore already requires ordered Options Template Records,
and a PSAMP-aware Collecting Process can infer this guarantee from
receipt of the Selection Sequence Report Options Template. However,
IPFIX-layer components that do not implement PSAMP -- forwarders,
middleboxes, or generic analysis tools -- have no means to apply that
constraint. The Ordered Options Template Set (Set ID 5) specified in
this document expresses the ordering guarantee at the IPFIX protocol
level, making it visible to any IPFIX component regardless of PSAMP
awareness.
3.4. Multi-Layer Encapsulated Traffic
Modern networks increasingly carry traffic with multiple
encapsulation layers. SRv6 deployments, in particular, may result in
packets with two or three nested IPv6 headers, each with its own
source and destination addresses. When an Exporting Process exports
fields from such packets, repeating Information Elements such as
sourceIPv6Address and destinationIPv6Address, the Collecting Process
has no way to determine which occurrence corresponds to which
encapsulation layer unless an ordering guarantee is explicitly
provided.
Claise, et al. Expires 7 January 2027 [Page 11]
Internet-Draft IPFIX Ordered IE July 2026
This problem is described in [I-D.liu-opsawg-ipfix-muti-layer], which
proposes several mechanisms to address the specific case of
encapsulation layer identification. That draft brings renewed
attention to an ordering ambiguity that has been present in IPFIX
since [RFC7011] was first published. The present document addresses
the underlying, more general problem of ordered Information Element
export, of which multi-layer encapsulation is one important use case.
When a packet carries multiple IP encapsulation layers -- for
example, an SRv6 packet where a Provider Edge adds an outer IPv6
header encapsulating an inner IPv6 packet from the customer -- an
Exporting Process may wish to export fields from multiple layers.
With the mechanism specified in this document, the Exporting Process
can include destinationIPv6Address twice in an Ordered Template
Record and signal that the first occurrence corresponds to the
outermost encapsulation layer and the second to the innermost,
reflecting the order observed by the Metering Process.
This use case covers IPv4-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6, and
any other IP-in-IP encapsulation scenario, as well as SRv6 traffic
with nested Segment Routing Headers as described in [RFC9487]
("Export of Segment Routing over IPv6 Information in IP Flow
Information Export (IPFIX)"). Further examples include:
* MAC-in-MAC (IEEE 802.1ah Provider Backbone Bridging): both
sourceMacAddress and destinationMacAddress repeat -- once for the
outer backbone MAC (B-MAC) and once for the inner customer MAC
(C-MAC).
* VXLAN [RFC7348] ("Virtual eXtensible Local Area Network (VXLAN): A
Framework for Overlaying Virtualized Layer 2 Networks over Layer 3
Networks") and GENEVE [RFC8926] ("Geneve: Generic Network
Virtualization Encapsulation"): outer IP transport addresses (UDP/
IP encapsulation) and inner tenant IP addresses both map to
Information Elements such as sourceIPv4Address and
destinationIPv4Address; without an ordering guarantee the
Collecting Process cannot distinguish transport layer from tenant
layer.
* GRE: outer and inner IP header fields repeat for the same
Information Elements, with the same ambiguity.
Claise, et al. Expires 7 January 2027 [Page 12]
Internet-Draft IPFIX Ordered IE July 2026
* IEEE 802.1ad Q-in-Q (stacked VLAN tags): vlanId (IPFIX IE 58)
repeats for each VLAN layer -- the outer Service VLAN (S-TAG) and
inner Customer VLAN (C-TAG). Workaround IPFIX IEs dot1qVlanId
(IPFIX IE 243) and dot1qCustomerVlanId (IPFIX IE 245) already
exist in the IANA IPFIX registry [IANA.IPFIX] as positional
substitutes, following the same pattern as the MPLS label stack
IPFIX IEs.
Without the mechanism specified in this document, unambiguous export
of these layered fields would require defining new position-specific
Information Elements, perpetuating the same registry proliferation
already seen with MPLS and IEEE 802.1ad.
The mechanism specified in this document addresses the common case
where all encapsulation layers are exported consecutively, with the
n-th occurrence of an Information Element corresponding to the n-th
layer. Cases where only a sparse subset of layers is exported, or
where backward compatibility with Collecting Processes that do not
support Ordered Sets is required, may benefit from the explicit
layer-marking approach described in
[I-D.liu-opsawg-ipfix-muti-layer], which is complementary to the
mechanism defined here.
4. New Ordered Set Specifications
The solution is the New Ordered Set Type: the definition of two new
Ordered Set types, Ordered Template Set (Set ID 4) and Ordered
Options Template Set (Set ID 5).
The rationale is as follows:
1. Explicit protocol semantics: A dedicated Set type provides an
unambiguous, per-Set signal that ordering is guaranteed. The
Collecting Process requires no additional correlation or
inference to determine whether a given Template is ordered.
2. Implementation practicality: The RFC 6313 structured data
approach is technically sound, but its usefulness depends on the
availability of [RFC6313] implementations, which are not known to
be widespread. The New Ordered Set Type requires a more targeted
change to existing IPFIX implementations.
3. Clean protocol design: Ordered data is a distinct semantic
concept that warrants a first-class protocol signal. A new Set
type is the natural extension point within the IPFIX message
format, consistent with the principle that Set IDs 4 through 255
are reserved in [RFC7011] for exactly this purpose.
Claise, et al. Expires 7 January 2027 [Page 13]
Internet-Draft IPFIX Ordered IE July 2026
4. Backwards compatibility: The existing Set IDs 2, 3, and 256 to
65535 are unaffected. Exporting Processes that do not require
ordered export continue to use the existing Set IDs without
modification.
Analysis of alternative approaches is provided in Appendix A.
4.1. Wire Format
The Ordered Template Set (Set ID 4) uses exactly the same wire format
as the Template Set (Set ID 2) defined in Section 3.4.1 of [RFC7011].
The Ordered Options Template Set (Set ID 5) uses exactly the same
wire format as the Options Template Set (Set ID 3) defined in
Section 3.4.2 of [RFC7011]. The Set ID value is the sole
distinguishing element: it signals to the Collecting Process that the
ordering of repeated Information Elements in corresponding Data
Records is guaranteed.
No new header fields, flags, or record structures are introduced.
Implementations that already support Set ID 2 and Set ID 3 can
support Set ID 4 and Set ID 5 by reusing the same parsing code and
adding the ordering semantic to the Template Records so identified.
4.2. Template Withdrawal
The Template Withdrawal mechanism defined in Section 8.1 of [RFC7011]
applies without modification to Ordered Template Records and Ordered
Options Template Records.
An Ordered Template Record is withdrawn by sending an Ordered
Template Set (Set ID 4) containing a Template Record with the target
Template ID and a Field Count of 0. An Ordered Options Template
Record is withdrawn by sending an Ordered Options Template Set (Set
ID 5) with a Field Count of 0.
Upon receipt of a withdrawal, the Collecting Process MUST cease
treating Data Sets referencing the withdrawn Template ID as Ordered
Data Sets and MUST discard all stored information about that Template
Record. This applies to the IPFIX transport state only; it does not
retroactively alter the ordering interpretation of Data Records
already received and decoded under that Template ID.
Claise, et al. Expires 7 January 2027 [Page 14]
Internet-Draft IPFIX Ordered IE July 2026
A withdrawn Ordered Template ID MAY be reused by the Exporting
Process within the same Transport Session and Observation Domain,
consistent with Section 8.1 of [RFC7011]. If the Template ID is
subsequently registered via an unordered Template Set (Set ID 2), the
Collecting Process MUST treat it as unordered. If registered again
via an Ordered Template Set (Set ID 4), the ordering guarantee
applies anew. The same applies for Options Template Records (Set IDs
3 and 5).
4.3. Normative Behavior
The Exporting Process MUST preserve the Metering Process observation
order when constructing Data Records for an Ordered Data Set.
A Collecting Process identifies an Ordered Data Set by tracking the
Set ID under which the corresponding Template Record was received.
If the Template was received in an Ordered Template Set (Set ID 4) or
an Ordered Options Template Set (Set ID 5), all subsequent Data Sets
referencing that Template ID MUST be treated as Ordered Data Sets.
If the Template was received in a Template Set (Set ID 2) or an
Options Template Set (Set ID 3), the ordering of repeated Information
Elements in the corresponding Data Records is not guaranteed.
Section 3.4.1 of [RFC7011] requires Template IDs to be unique within
an Observation Domain and Transport Session. A given Template ID can
therefore appear in only one Set type -- it cannot be registered as
both an Ordered Template Set (Set ID 4) and a Template Set (Set ID
2), nor as both Set ID 5 and Set ID 3. There is consequently no
ambiguity in the Collecting Process's per-Template-ID tracking of the
ordering guarantee.
The Collecting Process MUST interpret the n-th occurrence of an
Information Element in a Data Record from an Ordered Data Set as
corresponding to the n-th observation of that Information Element by
the Metering Process at the Observation Point.
This ordering guarantee applies independently to each Information
Element: the n-th occurrence of IE X corresponds to the n-th
observation of IE X, and the n-th occurrence of IE Y corresponds to
the n-th observation of IE Y. The guarantee does not impose any
relative ordering between occurrences of different Information
Elements.
Claise, et al. Expires 7 January 2027 [Page 15]
Internet-Draft IPFIX Ordered IE July 2026
This guarantee covers the ordering of exported occurrences only. The
Exporting Process is expected to export all observations
consecutively; where only a sparse subset of layers is exported, the
Collecting Process cannot determine whether exported occurrences are
contiguous from the first observation. For sparse export scenarios,
the explicit layer-marking approach of
[I-D.liu-opsawg-ipfix-muti-layer] is more appropriate.
An IPFIX Mediator [RFC6183] [RFC7014] that receives Ordered Template
Sets (Set ID 4) or Ordered Options Template Sets (Set ID 5) MUST
preserve the ordering guarantee when forwarding. The Mediator MUST
forward the corresponding Template Records in Ordered Template Sets
or Ordered Options Template Sets, and MUST preserve the observation
order of fields in the corresponding Data Records. A Mediator that
cannot preserve the ordering guarantee MUST NOT forward Ordered
Template Sets as unordered Template Sets (Set ID 2 or Set ID 3).
4.4. Updates to RFC 7011
The following [RFC7011] updates are required.
The following text in Section 8 of [RFC7011]:
OLD:
If an Information Element is required more than once in a
Template, the different occurrences of this Information Element
SHOULD follow the logical order of their treatments by the
Metering Process. For example, if a selected packet goes through
two hash functions, and if the two hash values are sent within a
single Template, the first occurrence of the hash value should
belong to the first hash function in the Metering Process. For
example, when exporting the two source IP addresses of an IPv4-in-
IPv4 packet, the first sourceIPv4Address Information Element
occurrence should be the IPv4 address of the outer header, while
the second occurrence should be the address of the inner header.
Collecting Processes MUST properly handle Templates with multiple
identical Information Elements.
NEW:
If an Information Element is required more than once in a Template
transmitted in a Template Set (Set ID 2) or Options Template Set
(Set ID 3), the different occurrences of this Information Element
SHOULD follow the logical order of their treatments by the
Metering Process. For example, if a selected packet goes through
two hash functions, and if the two hash values are sent within a
single Template, the first occurrence of the hash value should
Claise, et al. Expires 7 January 2027 [Page 16]
Internet-Draft IPFIX Ordered IE July 2026
belong to the first hash function in the Metering Process. For
example, when exporting the two source IP addresses of an IPv4-in-
IPv4 packet, the first sourceIPv4Address Information Element
occurrence should be the IPv4 address of the outer header, while
the second occurrence should be the address of the inner header.
Collecting Processes MUST properly handle Templates with multiple
identical Information Elements.
If the Template Record is transmitted in an Ordered Template Set
(Set ID 4) or an Ordered Options Template Set (Set ID 5), the
Metering Process MUST record the repeated Information Element
values in the order in which the corresponding observations are
made at the Observation Point, the Exporting Process MUST preserve
and follow this order when constructing the corresponding Data
Records, and the Collecting Process MUST interpret the n-th
occurrence as corresponding to the n-th observation by the
Metering Process at the Observation Point. The Metering Process
MUST record observations from outermost to innermost for
encapsulated traffic and from top to bottom for label stacks.
The following sentence in Section 4.2 of [RFC7011]:
OLD:
Since the Metering Process Reliability Statistics Options Template
contains two identical timestamp Information Elements, and since
the order of the Information Elements in the Template Records is
not guaranteed, the Collecting Process interprets the time
interval of ignored packets as the range between the two values;
see Section 5.2 for wraparound considerations.
NEW:
Since the Metering Process Reliability Statistics Options Template
contains two identical timestamp Information Elements, and since
the order of the Information Elements in Options Template Records
transmitted in Sets with Set ID 3 is not guaranteed, whereas the
order in Options Template Records transmitted in Sets with Set ID
5 is guaranteed to reflect the Metering Process observation order,
the Collecting Process interprets the time interval of ignored
packets as the range between the two values; see Section 5.2 for
wraparound considerations.
The following sentence in Section 4.3 of [RFC7011]:
OLD:
Claise, et al. Expires 7 January 2027 [Page 17]
Internet-Draft IPFIX Ordered IE July 2026
Since the Exporting Process Reliability Statistics Options
Template contains two identical timestamp Information Elements,
and since the order of the Information Elements in the Template
Records is not guaranteed, the Collecting Process interprets the
time interval of dropped packets as the range between the two
values; see Section 5.2 for wraparound considerations.
NEW:
Since the Exporting Process Reliability Statistics Options
Template contains two identical timestamp Information Elements,
and since the order of the Information Elements in Options
Template Records transmitted in Sets with Set ID 3 is not
guaranteed, whereas the order in Options Template Records
transmitted in Sets with Set ID 5 is guaranteed to reflect the
Metering Process observation order, the Collecting Process
interprets the time interval of dropped packets as the range
between the two values; see Section 5.2 for wraparound
considerations.
The following sentence in Section 3.3.2 of [RFC7011]:
OLD:
Values from 4 to 255 are reserved for future use.
NEW:
Values 4 and 5 are used for Ordered Template Sets and Ordered
Options Template Sets, respectively, as specified in this
document. Values from 6 to 255 are reserved for future use.
The following normative text is added to Section 3.3.2 of [RFC7011],
after the sentence "The Length value MUST be used to determine the
position of the next Set.":
NEW:
A Collecting Process that receives a Set with an unknown Set ID
SHOULD log a warning to assist operators in detecting
configuration or capability mismatches between Exporting and
Collecting Processes.
Claise, et al. Expires 7 January 2027 [Page 18]
Internet-Draft IPFIX Ordered IE July 2026
4.5. Updates to RFC 5476
Section 6.5.1 of [RFC5476] already mandates that selectorId
occurrences in a Selection Sequence Report Interpretation Options
Template Record MUST be listed in the order the corresponding
Primitive Selectors are applied. However, [RFC5476] predates the
Ordered Options Template Set mechanism defined in this document, and
therefore uses the regular Options Template Set (Set ID 3), which
provides no protocol-level signal to the Collecting Process that the
ordering is guaranteed.
The following sentence in Section 6.5.1 of [RFC5476]:
OLD:
If multiple Selectors are contained in the Selection Sequence
Report Interpretation, the selectorId's MUST be identified in the
order they are used.
NEW:
If multiple Selectors are contained in the Selection Sequence
Report Interpretation, the selectorId's MUST be identified in the
order they are used. The corresponding Options Template Record
MUST be transmitted in an Ordered Options Template Set (Set ID 5)
as defined in [this document], so that the Collecting Process
receives an explicit signal that the ordering of selectorId
occurrences reflects the Composite Selector application order.
4.6. Updates to RFC 6183
[RFC6183] ("IP Flow Information Export (IPFIX) Mediation: Framework")
defines the behavior of IPFIX Mediators but predates the Ordered
Template Set mechanism defined in this document. This document adds
the following normative requirement to Mediator behavior:
An IPFIX Mediator that receives Ordered Template Sets (Set ID 4) or
Ordered Options Template Sets (Set ID 5) MUST preserve the ordering
guarantee when forwarding. The Mediator MUST forward the
corresponding Template Records in Ordered Template Sets or Ordered
Options Template Sets, and MUST preserve the observation order of
fields in the corresponding Data Records. A Mediator that cannot
preserve the ordering guarantee MUST NOT forward Ordered Template
Sets as unordered Template Sets (Set ID 2 or Set ID 3).
Claise, et al. Expires 7 January 2027 [Page 19]
Internet-Draft IPFIX Ordered IE July 2026
4.7. New IPFIX Information Elements
Five new IPFIX Information Elements are required to support ordered
export for MPLS label stacks and label attributes; their full
definitions are in the IANA Considerations of this document. For
other protocol layers, no new IPFIX IEs are required: vlanId (IPFIX
IE 58) and postVlanId (IPFIX IE 59) already serve IEEE 802.1ad Q-in-
Q; sourceMacAddress (IPFIX IE 56) and destinationMacAddress (IPFIX IE
80) already serve MAC-in-MAC; and IP-level IPFIX IEs
(sourceIPv4Address, destinationIPv4Address, and their IPv6
equivalents) already serve VXLAN, GENEVE, GRE, and IP-in-IP
encapsulation. In each of these cases, the existing IPFIX IEs can
simply be repeated in an Ordered Template Record.
Note 1: No separate generic IPFIX IEs for TTL and TC (Exp) are
defined in this document, because the TTL and TC (Exp) fields are
already encoded as subfields of the 4-octet label stack entry
exported by mplsLabelStackSection (TBD1). mplsTopLabelTTL (IPFIX
IE 200) and mplsTopLabelExp (IPFIX IE 203) are therefore
superseded by mplsLabelStackSection when used with ordered export;
see Appendix B.
Note 2: The existing positional IPFIX IEs
mplsTopLabelStackSection (IE 70) through mplsLabelStackSection10
(IE 79) encode only 3 octets (label, TC, and S fields), omitting
the TTL field. mplsLabelStackSection (TBD1) encodes the full
4-octet label stack entry as defined in Section 2.1 of [RFC3032],
making a separate TTL Information Element unnecessary at any stack
depth.
The generic IPFIX IEs defined in this document do not immediately
obsolete the existing positional IPFIX IEs. Implementations that do
not support ordered export (Set IDs 4 and 5) continue to require the
positional IPFIX IEs. Once ordered export is widely deployed, the
positional IPFIX IEs listed in Appendix B -- as well as the Q-in-Q
workaround IPFIX IEs (dot1qVlanId IE 243, dot1qPriority IE 244,
dot1qCustomerVlanId IE 245, dot1qCustomerPriority IE 246,
postDot1qVlanId IE 254, postDot1qCustomerVlanId IE 255) -- may be
deprecated in a future document.
5. Operational Considerations
This section follows the guidelines of [I-D.opsarea-rfc5706bis]
("Guidelines for Considering Operations and Management of New
Protocols and Protocol Extensions") for documenting operational and
management considerations in IETF specifications. This document is a
protocol extension to [RFC7011]; operational and management
considerations that are not specific to ordered export are inherited
Claise, et al. Expires 7 January 2027 [Page 20]
Internet-Draft IPFIX Ordered IE July 2026
from [RFC7011] and are not repeated here.
5.1. Deployment and Coexistence
Ordered export is strictly additive. Existing Set IDs 2 and 3 are
unaffected, and Exporting Processes that do not require ordered
export continue to operate without modification. Deployment can
therefore proceed incrementally: ordered export can be enabled on a
per-Template basis toward specific Collecting Processes, without
disrupting any existing IPFIX infrastructure.
Operators SHOULD enable ordered export only toward Collecting
Processes that are known to support Set ID 4 and Set ID 5.
Deployment against unaware Collecting Processes may result in silent
loss of entire Ordered Sets, as discussed in Section 5.4.
5.2. Configuration
An Exporting Process is configured to use an Ordered Template Set
(Set ID 4) or an Ordered Options Template Set (Set ID 5) for specific
Template Records. No protocol-level negotiation is currently
defined. Operators are responsible for ensuring that the Collecting
Process is capable of processing the selected Set IDs before enabling
ordered export.
Ordered export may allow simplification of existing Template Records:
where a deployment previously required multiple position-specific
Information Elements (e.g., mplsTopLabelStackSection through
mplsLabelStackSection10), a single repeated Information Element in an
Ordered Template Record may suffice. This can reduce the number of
Information Element identifiers consumed and the size of Template
Records.
5.3. Verification of Correct Operation
End-to-end verification of ordered export requires confirming correct
behavior across all three components of the ordering chain:
* Metering Process: records repeated Information Element values in
the order they are observed. This is internal to the
implementation and is not directly observable on the wire.
* Exporting Process: transmits Ordered Template Sets (Set ID 4 or 5)
and constructs the corresponding Data Records with field values in
Metering Process observation order. This can be verified by
inspecting the IPFIX Messages on the wire.
Claise, et al. Expires 7 January 2027 [Page 21]
Internet-Draft IPFIX Ordered IE July 2026
* Collecting Process: tracks which Template IDs were received in
Ordered Template Sets and interprets the n-th occurrence of a
repeated Information Element as the n-th Metering Process
observation. Correct interpretation can be verified by comparing
collected data against known traffic (e.g., known MPLS label stack
or encapsulation layer ordering in a test environment).
5.4. Fault Management
The primary fault scenario for ordered export is a mismatch between
the Exporting Process and the Collecting Process: the Exporting
Process sends Ordered Sets that the Collecting Process does not
understand. Section 3.3.2 of [RFC7011] mandates that "the Length
value MUST be used to determine the position of the next Set,"
providing the mechanism for a Collecting Process that does not
support Set ID 4 or 5 to skip the unknown Set and continue processing
normally. However, [RFC7011] does not specify what a Collecting
Process MUST or SHOULD do upon receipt of an unknown Set ID --
whether to skip silently, log the event, or terminate the Transport
Session. As a result, a RFC 7011 compliant Collecting Process may
silently discard the Set without any notification to the Exporting
Process or to the operator. This document addresses this gap; see
Section 4.4.
Operators SHOULD monitor for unexpected loss of Flow Records that may
indicate silent Set discard at an unaware Collecting Process. If
suspected, ordered export SHOULD be disabled for that destination
until the Collecting Process is confirmed to support Set ID 4 and Set
ID 5.
5.5. Performance
The ordered export mechanism specified in this document introduces no
additional overhead on the wire: Ordered Template Sets and Ordered
Options Template Sets use the same wire format as their Set ID 2 and
Set ID 3 counterparts. The only additional cost is the Collecting
Process maintaining per-Template-ID state to track whether each
Template was received in an Ordered or unordered Set, which is
negligible.
The Metering Process, Exporting Process, and IPFIX Mediators may
incur an implementation cost to preserve observation order when
recording repeated Information Element values, depending on its
internal architecture. This is an implementation consideration and
is outside the scope of this document.
Claise, et al. Expires 7 January 2027 [Page 22]
Internet-Draft IPFIX Ordered IE July 2026
6. Security Considerations
This document does not change the trust model of the IPFIX protocol.
The security considerations of [RFC7011] apply.
An Exporting Process that uses an Ordered Template Set (Set ID 4 or
5) but fails to preserve the Metering Process observation order will
cause the Collecting Process to misinterpret the exported data. In
particular, analytics systems that rely on the ordering to identify
encapsulation layers or label stack positions may produce incorrect
results. Operators SHOULD ensure that the Exporting Process and
Metering Process are correctly coordinated before using ordered
export.
7. IANA Considerations
7.1. IPFIX Set IDs Registry
This document requests IANA to allocate the following values in the
"IPFIX Set IDs" subregistry of the "IP Flow Information Export
(IPFIX) Entities" registry [IANA.IPFIX]:
+=======+==============================+===============+
| Value | Name | Reference |
+=======+==============================+===============+
| 4 | Ordered Template Set | This document |
+-------+------------------------------+---------------+
| 5 | Ordered Options Template Set | This document |
+-------+------------------------------+---------------+
Table 1
7.2. IPFIX Information Elements Registry
This document requests IANA to allocate the following Information
Elements in the "IPFIX Information Elements" registry [IANA.IPFIX]:
Claise, et al. Expires 7 January 2027 [Page 23]
Internet-Draft IPFIX Ordered IE July 2026
+===========+=======================+
| ElementID | Name |
+===========+=======================+
| TBD1 | mplsLabelStackSection |
+-----------+-----------------------+
| TBD2 | mplsLabelType |
+-----------+-----------------------+
| TBD3 | mplsLabelIPv4Address |
+-----------+-----------------------+
| TBD4 | mplsLabelPrefixLength |
+-----------+-----------------------+
| TBD5 | mplsLabelIPv6Address |
+-----------+-----------------------+
Table 2
7.2.1. mplsLabelStackSection
ElementID: TBD1
Name: mplsLabelStackSection
Abstract Data Type: octetArray
Data Type Semantics: default
Description: The contents of a label stack entry at any position in
the MPLS label stack, encoded as the 4-octet MPLS label stack
entry format defined in Section 2.1 of [RFC3032]. The encoding
comprises a 20-bit label value, a 3-bit Traffic Class (TC) field,
a 1-bit Stack Bottom (S) flag, and an 8-bit Time to Live (TTL)
field. When this Information Element appears multiple times in an
Ordered Template Record, the N-th occurrence corresponds to the
label stack entry at stack position N (counting from the top) as
observed by the Metering Process at the Observation Point.
Additional Information: See Section 2.1 of [RFC3032] for the MPLS
label stack entry encoding. The ten positional IPFIX IEs
mplsTopLabelStackSection (IPFIX IE 70) through
mplsLabelStackSection10 (IPFIX IE 79) exist to work around the
absence of an ordered export mechanism and are superseded by this
IPFIX IE when used with the ordered export mechanism specified in
this document.
Reference: This document
Claise, et al. Expires 7 January 2027 [Page 24]
Internet-Draft IPFIX Ordered IE July 2026
7.2.2. mplsLabelType
ElementID: TBD2
Name: mplsLabelType
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Description: The type of the MPLS label at the given stack position,
using the same encoding as mplsTopLabelType (IPFIX IE 46). Values
are assigned by IANA in the "Multi-Protocol Label Switching (MPLS)
Label Types" registry. When this Information Element appears
multiple times in an Ordered Template Record, the N-th occurrence
corresponds to the label type at stack position N (counting from
the top) as observed by the Metering Process at the Observation
Point.
Additional Information: See the IANA registry "Multi-Protocol Label
Switching (MPLS) Label Types" for the list of values.
Reference: This document
7.2.3. mplsLabelIPv4Address
ElementID: TBD3
Name: mplsLabelIPv4Address
Abstract Data Type: ipv4Address
Data Type Semantics: default
Description: The IPv4 address of the system that the MPLS label at
the given stack position will cause this Flow to be forwarded to,
using the same encoding as mplsTopLabelIPv4Address (IPFIX IE 47).
When this Information Element appears multiple times in an Ordered
Template Record, the N-th occurrence corresponds to the next-hop
IPv4 address for the label at stack position N (counting from the
top) as observed by the Metering Process at the Observation Point.
Additional Information: mplsTopLabelIPv4Address (IPFIX IE 47) exists
to work around the absence of an ordered export mechanism and is
superseded by this IPFIX IE when used with the ordered export
mechanism specified in this document.
Reference: This document
Claise, et al. Expires 7 January 2027 [Page 25]
Internet-Draft IPFIX Ordered IE July 2026
7.2.4. mplsLabelPrefixLength
ElementID: TBD4
Name: mplsLabelPrefixLength
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Description: The prefix length of the IPv4 subnet that the MPLS
label at the given stack position will cause the Flow to be
forwarded to, using the same encoding as mplsTopLabelPrefixLength
(IPFIX IE 91). When this Information Element appears multiple
times in an Ordered Template Record, the N-th occurrence
corresponds to the prefix length for the label at stack position N
(counting from the top) as observed by the Metering Process at the
Observation Point.
Units: bits
Range: 0-32
Additional Information: mplsTopLabelPrefixLength (IPFIX IE 91)
exists to work around the absence of an ordered export mechanism
and is superseded by this IPFIX IE when used with the ordered
export mechanism specified in this document.
Reference: This document
7.2.5. mplsLabelIPv6Address
ElementID: TBD5
Name: mplsLabelIPv6Address
Abstract Data Type: ipv6Address
Data Type Semantics: default
Description: The IPv6 address of the system that the MPLS label at
the given stack position will cause this Flow to be forwarded to,
using the same encoding as mplsTopLabelIPv6Address (IPFIX IE 140).
When this Information Element appears multiple times in an Ordered
Template Record, the N-th occurrence corresponds to the next-hop
IPv6 address for the label at stack position N (counting from the
top) as observed by the Metering Process at the Observation Point.
Claise, et al. Expires 7 January 2027 [Page 26]
Internet-Draft IPFIX Ordered IE July 2026
Additional Information: mplsTopLabelIPv6Address (IPFIX IE 140)
exists to work around the absence of an ordered export mechanism
and is superseded by this IPFIX IE when used with the ordered
export mechanism specified in this document.
Reference: This document
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/rfc/rfc3032>.
[RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
Sampling (PSAMP) Protocol Specifications", RFC 5476,
DOI 10.17487/RFC5476, March 2009,
<https://www.rfc-editor.org/rfc/rfc5476>.
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
"IP Flow Information Export (IPFIX) Mediation: Framework",
RFC 6183, DOI 10.17487/RFC6183, April 2011,
<https://www.rfc-editor.org/rfc/rfc6183>.
[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, September 2013,
<https://www.rfc-editor.org/rfc/rfc7011>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
Claise, et al. Expires 7 January 2027 [Page 27]
Internet-Draft IPFIX Ordered IE July 2026
[I-D.liu-opsawg-ipfix-muti-layer]
Liu, Y. and T. Zhou, "Export of Multiple Encapsulation
Layer Information in IPFIX", Work in Progress, Internet-
Draft, draft-liu-opsawg-ipfix-muti-layer-02, 31 March
2026, <https://datatracker.ietf.org/doc/html/draft-liu-
opsawg-ipfix-muti-layer-02>.
[I-D.opsarea-rfc5706bis]
Claise, B., Clarke, J., Farrel, A., Barguil, S.,
Pignataro, C., and R. Chen, "Guidelines for Considering
Operations and Management in IETF Specifications", Work in
Progress, Internet-Draft, draft-opsarea-rfc5706bis-06, 20
October 2025, <https://datatracker.ietf.org/doc/html/
draft-opsarea-rfc5706bis-06>.
[IANA.IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities",
<https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470,
DOI 10.17487/RFC5470, March 2009,
<https://www.rfc-editor.org/rfc/rfc5470>.
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474,
March 2009, <https://www.rfc-editor.org/rfc/rfc5474>.
[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, March 2009,
<https://www.rfc-editor.org/rfc/rfc5475>.
[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, July 2011,
<https://www.rfc-editor.org/rfc/rfc6313>.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/rfc/rfc7012>.
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,
September 2013, <https://www.rfc-editor.org/rfc/rfc7014>.
Claise, et al. Expires 7 January 2027 [Page 28]
Internet-Draft IPFIX Ordered IE July 2026
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/rfc/rfc7348>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/rfc/rfc8926>.
[RFC9487] Graf, T., Claise, B., and P. Francois, "Export of Segment
Routing over IPv6 Information in IP Flow Information
Export (IPFIX)", RFC 9487, DOI 10.17487/RFC9487, November
2023, <https://www.rfc-editor.org/rfc/rfc9487>.
Appendix A. Solution Space
This section analyzes candidate solutions. The analysis is presented
to inform discussion and justify the specification in Section 4.
Note: The detailed analysis in this section is intended to support
Working Group discussion. Once the Working Group has reached
consensus on the solution, this section may be condensed into a
summary.
A.1. Updating RFC 7011 SHOULD to MUST Alone (Rejected)
The most minimal approach would be to update Section 8 of [RFC7011]
by strengthening the existing SHOULD to a MUST, requiring all
Exporting Processes to guarantee that repeated Information Elements
follow the Metering Process observation order.
The fundamental limitation of this approach is that it constrains the
Exporting Process but provides no signal to the Collecting Process.
Even if every Exporting Process were compliant with the updated
requirement, the Collecting Process would still have no per-Template
indication of whether a given Template Record was sent by an updated
Exporting Process (ordering guaranteed) or by an older implementation
that predates the update (ordering not guaranteed). Without such a
signal, the Collecting Process cannot safely interpret the n-th
occurrence of a repeated Information Element as the n-th Metering
Process observation.
Two additional considerations reinforce the rejection. First,
Sections 4.2 and 4.3 of [RFC7011] explicitly state that "the order of
the Information Elements in the Template Records is not guaranteed";
Claise, et al. Expires 7 January 2027 [Page 29]
Internet-Draft IPFIX Ordered IE July 2026
a SHOULD-to-MUST change in Section 8 alone would leave these
statements in direct conflict with the new requirement. Second,
Section 2.2 ("IPFIX Limitations") of [RFC6313] notes that "some
encoding optimizations are based on the permutation of Information
Element order"; a universal MUST would prohibit such optimizations
across all Templates containing repeated Information Elements,
regardless of whether ordering is semantically significant. This
approach is therefore rejected.
A.2. RFC 6313 Structured Data with the "ordered" Semantic (Rejected)
This option is analyzed in detail because [RFC6313] has been cited as
a solution to the ordering problem (see Introduction). The analysis
below shows that it does not provide the required guarantee and is
therefore rejected.
[RFC6313] defines structured data types -- basicList,
subTemplateList, and subTemplateMultiList -- and associates them with
list semantics. One defined semantic is:
The "ordered" structured data type semantic specifies that
elements from the list in the structured data are ordered.
Using this mechanism, an Exporting Process could encode a sequence of
ordered MPLS label values as a basicList with the "ordered" semantic:
(basicList, ordered, mplsLabelStackSection,
<label1>, <label2>, <label3>)
Similarly, multi-layer encapsulation fields could be encoded in a
subTemplateMultiList with the "ordered" semantic.
The fundamental limitation of this approach is that the [RFC6313]
"ordered" semantic is an export ordering guarantee, not a Metering
Process observation ordering guarantee. Section 4.4.6 of [RFC6313]
states only that "elements from the list in the structured data are
ordered" -- it does not state that the order reflects the sequence in
which the Metering Process makes its observations. Furthermore,
[RFC6313] structured data, when carried in an IPFIX Template Record,
still falls under the general rule of Section 8 of [RFC7011]: "the
different occurrences of this Information Element SHOULD follow the
logical order of their treatments by the Metering Process."
[RFC6313] does not upgrade this SHOULD to a MUST, nor does it bind
the "ordered" semantic to Metering Process observation order. Since
IPFIX is an export protocol, governing the wire format between the
Exporting Process and the Collecting Process, it cannot by itself
make claims about the internal behavior of the Metering Process. A
Collecting Process that receives a basicList or subTemplateMultiList
Claise, et al. Expires 7 January 2027 [Page 30]
Internet-Draft IPFIX Ordered IE July 2026
with the "ordered" semantic therefore cannot safely conclude that
element N corresponds to the N-th observation by the Metering
Process. This is precisely the guarantee this document requires, and
[RFC6313] does not provide it. This approach is therefore rejected.
A.3. New IPFIX Version 11 (Rejected)
A new IPFIX version implies a broad overhaul of the protocol and
would carry community expectations far beyond the narrow scope of
this document. The risk of scope creep is significant.
Beyond scope, a version bump would be far more disruptive than new
Set IDs. A Collecting Process that receives an IPFIX Message with an
unknown version number has no choice but to discard the entire
message. This means that introducing a new IPFIX version would cause
every existing Collecting Process to reject all IPFIX Messages --
including those carrying unordered Data Sets -- until it is updated
to support the new version. The deployment impact would be severe
and disproportionate to the problem being solved.
By contrast, new Set IDs are additive. Section 3.3.2 of [RFC7011]
reserves Set IDs 4 through 255 for future use and mandates that "the
Length value MUST be used to determine the position of the next Set."
A Collecting Process that does not support Set ID 4 or 5 can
therefore use the Set Length field to skip the unknown Set and
continue processing the remainder of the IPFIX Message normally. All
prior IPFIX extensions -- including [RFC6313] -- have been deployed
without requiring a version bump. This approach is therefore
rejected.
A.4. Marker Information Element (Evaluated)
Define a new Information Element whose presence in an (Options)
Template Record indicates that the Information Elements following it
(until the next marker) are to be interpreted as ordered. This
approach is similar to the encapLayerTop and encapLayer2 Information
Elements proposed in [I-D.liu-opsawg-ipfix-muti-layer] for
encapsulation layer identification.
Advantages:
* A Collecting Process that does not understand the marker
Information Element MAY discard only that one Information Element
(per Section 9 of [RFC7011]), retaining the other fields in the
Data Record.
Disadvantages:
Claise, et al. Expires 7 January 2027 [Page 31]
Internet-Draft IPFIX Ordered IE July 2026
* The semantic of other Information Elements becomes dependent on
the presence and position of the marker Information Element,
creating an implicit dependency between IPFIX IEs that is not
expressible in the IPFIX Information Model [RFC7012].
* The approach is less clean than a dedicated Set type from a
protocol design perspective.
A.5. Options Template Indicator (Evaluated)
Define a new Options Template Record with a scope of Template ID,
containing a bitmap Information Element that identifies, for each
field in the referenced Template Record, whether that field belongs
to an ordered sequence. This is analogous to the flowKeyIndicator
Information Element (IPFIX IE 173), which uses an Options Template to
convey which fields of a referenced Template Record are Flow Keys.
Advantages:
* Does not require changes to the Data Set format.
* The Options Template Record can be transmitted once per Template
and cached by the Collecting Process.
Disadvantages:
* Requires the Collecting Process to correlate the Options Template
record with the Data Template before it can correctly interpret
Data Records, adding a level of indirection and a potential for
synchronization issues.
* More complex to implement than a dedicated Set type.
A.6. New Ordered Set Type
Define new Set IDs to indicate that the ordering of Information
Elements within the corresponding Data Records is guaranteed to
reflect the Metering Process observation order. This approach
extends the existing Set ID structure of [RFC7011]:
Claise, et al. Expires 7 January 2027 [Page 32]
Internet-Draft IPFIX Ordered IE July 2026
+========+====================================+
| Set ID | Name |
+========+====================================+
| 2 | Template Set (existing) |
+--------+------------------------------------+
| 3 | Options Template Set (existing) |
+--------+------------------------------------+
| 4 | Ordered Template Set (new) |
+--------+------------------------------------+
| 5 | Ordered Options Template Set (new) |
+--------+------------------------------------+
Table 3
Ordered Template Records (Set ID 4) and Ordered Options Template
Records (Set ID 5) use the same wire format as their existing
counterparts (Set ID 2 and Set ID 3 respectively), with the addition
of the ordering semantic on the corresponding Data Records.
Advantages:
* Provides an explicit, unambiguous per-Set signal that ordering is
guaranteed, without relying on the Collecting Process to parse an
in-band marker or to maintain an out-of-band correlation table.
* No [RFC6313] structured data complexity is required; existing flat
Template and Data Record formats are reused.
* Backwards compatible: existing Set IDs 2 and 3 are unaffected and
continue to be used for cases where ordering is not guaranteed or
not relevant.
* Generalizable to any stacked or layered protocol structure without
requiring new position-specific Information Element definitions.
Disadvantages:
* Requires both Exporting Process and Collecting Process updates to
support the new Set IDs.
* A Collecting Process that does not support Set ID 4 or 5 may
discard the entire Set upon receipt, resulting in a complete loss
of the Data Records in that Set without any log information.
Section 3.3.2 of [RFC7011] does not specify the behavior of a
Collecting Process upon receipt of an unknown Set ID.
Claise, et al. Expires 7 January 2027 [Page 33]
Internet-Draft IPFIX Ordered IE July 2026
Appendix B. Migration from Positional to Generic Information Elements
This appendix is informative. It provides guidance for migrating
existing deployments from positional Information Elements to generic
Information Elements used with the ordered export mechanism specified
in this document.
Positional Information Elements were defined as a workaround for the
absence of an ordering guarantee in IPFIX (see Section 3.2). With
ordered export, a single generic Information Element repeated N times
in an Ordered Template Record replaces N positional Information
Elements, where the N-th occurrence corresponds to the N-th
observation at the Observation Point.
Migration requires both Exporting Process and Collecting Process
updates to support Ordered Template Sets (Set ID 4) or Ordered
Options Template Sets (Set ID 5). Until ordered export is
universally deployed, both positional and generic forms must be
supported concurrently.
B.1. MPLS Information Elements
The following positional IPFIX IEs for MPLS label stacks and label
attributes are replaced by the generic IEs defined in this document
when used with ordered export.
+========================+===+=====================+====+===========+
|Positional IE |IE |Generic IE |IE |Notes |
| |ID | |ID | |
+========================+===+=====================+====+===========+
|mplsTopLabelType |46 |mplsLabelType |TBD2|Top-of- |
| | | | |stack only;|
| | | | |generic IE |
| | | | |covers |
| | | | |position N |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelIPv4Address |47 |mplsLabelIPv4Address |TBD3|Top-of- |
| | | | |stack only;|
| | | | |generic IE |
| | | | |covers |
| | | | |position N |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelStackSection|70 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |1 (top of |
| | | | |stack) |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection2 |71 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |2 |
Claise, et al. Expires 7 January 2027 [Page 34]
Internet-Draft IPFIX Ordered IE July 2026
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection3 |72 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |3 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection4 |73 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |4 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection5 |74 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |5 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection6 |75 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |6 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection7 |76 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |7 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection8 |77 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |8 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection9 |78 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |9 |
+------------------------+---+---------------------+----+-----------+
|mplsLabelStackSection10 |79 |mplsLabelStackSection|TBD1|Occurrence |
| | | | |10 |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelPrefixLength|91 |mplsLabelPrefixLength|TBD4|Top-of- |
| | | | |stack only;|
| | | | |generic IE |
| | | | |covers |
| | | | |position N |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelIPv6Address |140|mplsLabelIPv6Address |TBD5|Top-of- |
| | | | |stack only;|
| | | | |generic IE |
| | | | |covers |
| | | | |position N |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelTTL |200|mplsLabelStackSection|TBD1|TTL is |
| | | | |encoded in |
| | | | |octet 4 of |
| | | | |the 4-octet|
| | | | |label stack|
| | | | |entry |
+------------------------+---+---------------------+----+-----------+
|mplsTopLabelExp |203|mplsLabelStackSection|TBD1|TC (Exp) is|
| | | | |encoded in |
| | | | |bits 21-23 |
| | | | |of the |
Claise, et al. Expires 7 January 2027 [Page 35]
Internet-Draft IPFIX Ordered IE July 2026
| | | | |4-octet |
| | | | |label stack|
| | | | |entry |
+------------------------+---+---------------------+----+-----------+
|postMplsTopLabelExp |237|(not in scope) |-- |Post-policy|
| | | | |TC; no |
| | | | |generic |
| | | | |replacement|
| | | | |defined in |
| | | | |this |
| | | | |document |
+------------------------+---+---------------------+----+-----------+
Table 4
B.2. IEEE 802.1ad Q-in-Q Information Elements
The following positional IPFIX IEs for IEEE 802.1ad Q-in-Q (stacked
VLAN tags) are replaced by repeated use of the existing vlanId (IPFIX
IE 58) and postVlanId (IPFIX IE 59) Information Elements in an
Ordered Template Record. No new generic IPFIX IEs are required for
VLAN IDs.
Claise, et al. Expires 7 January 2027 [Page 36]
Internet-Draft IPFIX Ordered IE July 2026
+=========================+=====+============+====+===============+
| Positional IE | IE | Generic IE | IE | Notes |
| | ID | | ID | |
+=========================+=====+============+====+===============+
| dot1qVlanId | 243 | vlanId | 58 | Occurrence 1 |
| | | | | (outer S-TAG) |
+-------------------------+-----+------------+----+---------------+
| dot1qPriority | 244 | (not in | -- | No generic |
| | | scope) | | priority IE |
| | | | | defined in |
| | | | | this document |
+-------------------------+-----+------------+----+---------------+
| dot1qCustomerVlanId | 245 | vlanId | 58 | Occurrence 2 |
| | | | | (inner C-TAG) |
+-------------------------+-----+------------+----+---------------+
| dot1qCustomerPriority | 246 | (not in | -- | No generic |
| | | scope) | | priority IE |
| | | | | defined in |
| | | | | this document |
+-------------------------+-----+------------+----+---------------+
| postDot1qVlanId | 254 | postVlanId | 59 | Occurrence 1 |
| | | | | (outer S-TAG, |
| | | | | post-NAT) |
+-------------------------+-----+------------+----+---------------+
| postDot1qCustomerVlanId | 255 | postVlanId | 59 | Occurrence 2 |
| | | | | (inner C-TAG, |
| | | | | post-NAT) |
+-------------------------+-----+------------+----+---------------+
Table 5
Acknowledgements
The authors thank Yao Liu and Taoran Zhou for their work on
[I-D.liu-opsawg-ipfix-muti-layer], which identified the multi-layer
encapsulation use case and motivated the broader problem statement
addressed in this document.
Authors' Addresses
Benoit Claise
Everything OPS & Arrcus
Email: benoit@everything-ops.net
Paul Aitken
Ciena
Email: paitken@ciena.com
Claise, et al. Expires 7 January 2027 [Page 37]
Internet-Draft IPFIX Ordered IE July 2026
Holger Keller
Deutsche Telekom
Email: holger.keller@telekom.de
Yao Liu
ZTE Corporation
Email: liu.yao71@zte.com.cn
Claise, et al. Expires 7 January 2027 [Page 38]