Export of ECN Information in IPFIX
draft-song-opsawg-ipfix-ecn-02
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 | Xueyan Song , Yao Liu , Jonathan Newton , Jason Livingood | ||
| Last updated | 2026-06-26 | ||
| 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-song-opsawg-ipfix-ecn-02
OPSAWG X. Song
Internet-Draft Y. Liu
Intended status: Standards Track ZTE Corp.
Expires: 28 December 2026 J. Newton
Vodafone
J. Livingood
Comcast
26 June 2026
Export of ECN Information in IPFIX
draft-song-opsawg-ipfix-ecn-02
Abstract
This document defines a set of IPFIX Information Elements for
monitoring Explicit Congestion Notification (ECN), specifically in
the context of the Low Latency, Low Loss, and Scalable Throughput
(L4S) service. These Information Elements allow network operators to
observe ECN codepoint usage within L4S deployments and evaluate the
corresponding traffic performance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 December 2026.
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
Song, et al. Expires 28 December 2026 [Page 1]
Internet-Draft ECN Export in IPFIX June 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Overview of ECN Format . . . . . . . . . . . . . . . . . . . 3
3.1. IPv4 ECN Field . . . . . . . . . . . . . . . . . . . . . 4
3.2. IPv6 ECN Field . . . . . . . . . . . . . . . . . . . . . 4
4. IPFIX Information Elements for ECN Monitoring . . . . . . . . 5
4.1. ipv4HeaderEcn . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Relationship with Existing IPFIX Information
Elements . . . . . . . . . . . . . . . . . . . . . . 5
4.2. ipv6HeaderEcn . . . . . . . . . . . . . . . . . . . . . . 6
4.3. mplsHeaderEcn . . . . . . . . . . . . . . . . . . . . . . 7
4.4. ipsecSaEcnMode . . . . . . . . . . . . . . . . . . . . . 7
4.5. l2tpEcnNego . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. notEctPacketDeltaCount . . . . . . . . . . . . . . . . . 8
4.7. notEctPacketTotalCount . . . . . . . . . . . . . . . . . 8
4.8. ect0PacketDeltaCount . . . . . . . . . . . . . . . . . . 9
4.9. ect0PacketTotalCount . . . . . . . . . . . . . . . . . . 9
4.10. ect1PacketDeltaCount . . . . . . . . . . . . . . . . . . 10
4.11. ect1PacketTotalCount . . . . . . . . . . . . . . . . . . 10
4.12. cePacketDeltaCount . . . . . . . . . . . . . . . . . . . 10
4.13. cePacketTotalCount . . . . . . . . . . . . . . . . . . . 11
5. Operational Considerations . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The Low Latency, Low Loss, and Scalable throughput (L4S) service,
defined in [RFC9331], introduces a new network service that enables
low latency and high throughput for traffic using Scalable congestion
controls. To deploy and operate L4S effectively, network operators
need visibility into L4S traffic patterns, performance metrics, and
interoperability with existing traffic.
Song, et al. Expires 28 December 2026 [Page 2]
Internet-Draft ECN Export in IPFIX June 2026
IP Flow Information Export (IPFIX) [RFC7011] provides a standard
protocol for exporting flow information from network devices. This
document defines a set of IPFIX Information Elements specifically
designed for monitoring L4S ECN traffic.
These Information Elements are particularly useful during the
experimental phase of L4S deployment as specified in [RFC9331],
allowing operators to gather data to examine performance and identify
nodes where remediation may be necessary to provide the best
performance.
2. Terminology
2.1. Terms Used in This Document
This document makes use of the terms defined in [RFC9331], [RFC9330]
and [RFC7011].
IPFIX: IP Flow Information Export
IPFIX Information Elements
Observation Point
L4S: Low Latency, Low Loss, and Scalable throughput (L4S) service
ECN: Explicit Congestion Notification
ECT: ECN-capable Transport
Not-ECT: Not ECN-capable transport
CE: Congestion Experienced
2.2. Requirements Language
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.
3. Overview of ECN Format
Song, et al. Expires 28 December 2026 [Page 3]
Internet-Draft ECN Export in IPFIX June 2026
3.1. IPv4 ECN Field
For IPv4 packets, the ECN field is located in the Type of Service
(TOS) byte of the IP header, specifically in bits 6 to 7. The
definition for the IPv4 TOS octet (see [RFC791]) has been superseded
by the six-bit DS (Differentiated Services) Field (see [RFC2474],
[RFC2780]). Bits 6 and 7 are listed in [RFC2474] as Currently
Unused, and are specified in [RFC2780] as approved for experimental
use for ECN. The ECN field in IPv4 header is showed as follows.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS Field, DSCP | ECN Field |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 1: ECN Fields in IPv4
ECN Codepoint values:
00: Not ECT
01: ECT(0)
10: ECT(1)
11: CE
3.2. IPv6 ECN Field
For IPv6 packets, the ECN field is located in bits 6 to 7 of IPv6
Traffic Class. The definition for the IPv6 Traffic Class octet (see
[RFC791]) has been superseded by the six-bit DS (Differentiated
Services) Field (see [RFC2474], [RFC2780]). Bits 6 and 7 are listed
in [RFC2474] as Currently Unused, and are specified in [RFC2780] as
approved for experimental use for ECN. The ECN field in IPv6 header
is showed as follows.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Fields in IPv6
Song, et al. Expires 28 December 2026 [Page 4]
Internet-Draft ECN Export in IPFIX June 2026
4. IPFIX Information Elements for ECN Monitoring
This section defines the Information Elements for ECN. Specifically,
in the context of L4S service, these Information Elements allow
network operators to have network visibility to ECN marking and
evaluate the traffic performance.
4.1. ipv4HeaderEcn
Name: ipv4HeaderEcn
ElementID: TBD1
Description: This Information Element is used for capturing the
complete ECN state of each packet, enabling detailed analysis of
congestion notification. The ECN field format is introduced in
section 3.1 of this draft. L4S traffic is identified by the
ECT(1) codepoint as specified in [RFC9331].
The Information Element encodes only these 2 bits. Therefore, its
value may range from 0 to 3.
The Information Element provides a dedicated view of the ECN
monitoring. The relationship of this information element with
existing IPFIX IEs is introduced in the section 4.1.1.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: See [RFC2474] and [RFC2780] for IPv4 ECN
field defintion.
Reference: [RFC3168], [RFC9331], this document.
4.1.1. Relationship with Existing IPFIX Information Elements
The IPFIX Information Element ipDiffServCodePoint (IE ID 195) encodes
the six-bit DSCP value from the IP header, which occupies bits 0-5 of
the DS Field. While DSCP and ECN bits are located in the same octet
(IPv4 TOS or IPv6 Traffic Class), they serve distinct purposes: DSCP
is used for packet classification and per-hop behavior selection,
whereas ECN is used for end-to-end congestion signaling.
Implementations that already export ipClassOfService (IE ID 5) or
ipDiffServCodePoint (IE ID 195) MAY derive ECN information from these
IEs by extracting bits 6-7. However, this approach has the following
limitations in L4S monitoring contexts:
Song, et al. Expires 28 December 2026 [Page 5]
Internet-Draft ECN Export in IPFIX June 2026
1, When flows are aggregated by ipClassOfService, identical ECN
states (e.g., ECT(1)) with different DSCP markings result in separate
flow records. The dedicated ECN IEs defined in this document enable
aggregation purely by ECN codepoint, providing a unified view of L4S
traffic regardless of DSCP variations.
2, DSCP values may be dynamically adjusted based on observed ECN
congestion status (e.g., degrading priority upon CE marking).
Decoupling ECN monitoring from DSCP reporting simplifies the
correlation between congestion signals and subsequent QoS policy
actions.
3, In tunneling scenarios, the outer IP header's DSCP may be
rewritten independently of the inner header's ECN state. Dedicated
ECN IEs allow independent tracking of congestion signals across
tunnel boundaries without DSCP masking effects.
Therefore, ipv4HeaderEcn, ipv6HeaderEcn (section 4.2), and the ECN
counter IEs (Sections 4.6-4.13) are complementary to, rather than
redundant with, ipDiffServCodePoint and ipClassOfService.
4.2. ipv6HeaderEcn
Name: ipv6HeaderEcn
ElementID: TBD2
Description: This element is used for capturing the complete ECN
state of each packet, enabling detailed analysis of congestion
notification. The ECN field format is introduced in section 3.2
of this draft. L4S traffic is identified by the ECT(1) codepoint
as specified in [RFC9331].
The Information Element encodes only these 2 bits. Therefore, its
value may range from 0 to 3.
As introduced in section 4.1.1, implementations that already
export ipClassOfService MAY choose to derive ECN information from
that IE, however, the dedicated Information Element enables more
efficient filtering and processing at the Collector.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: See [RFC2474] and [RFC2780] for IPv6 ECN
field defintion.
Song, et al. Expires 28 December 2026 [Page 6]
Internet-Draft ECN Export in IPFIX June 2026
Reference: [RFC3168], [RFC9331], this document.
4.3. mplsHeaderEcn
Name: mplsHeaderEcn
ElementID: TBD3
Description: The EXP field of the MPLS label header is used for ECN.
As recommended in [RFC5129], explicit congestion notification in
MPLS should use codepoints in the EXP field.
The Information Element encodes only these 3 bits. Therefore, its
value may range from 0 to 7.
It is noted that the information extraction of this information
element is only used when the MPLS domain has ECN support. The
EXP field information is only extracted from the outermost layer
of MPLS labels. The ECT(1) in EXP identifies L4S traffic.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: see [RFC5129] for detailed information for
MPLS ECN tunnel negotiation.
Reference: [RFC5129], this document.
4.4. ipsecSaEcnMode
Name: ipsecSaEcnMode
ElementID: TBD4
Description: The information element indicates whether ECN
functionality is allowed for an IPsec Security Association (SA) in
tunnel encapsulation mode. The IPsec SA Attribute value 10 is
defined for ECN tunnel negotiation as defined in section 9.2.1 of
[RFC3168]. The IE reflects the ECN negotiation state of IPsec SA
and the negotiation value includes allowed (IE value set 1) and
forbidden (IE value set 2) attribute. The allowed value indicates
ECN congestion notification enabled and the forbidden value
indicates ECN congestion notification disabled.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Song, et al. Expires 28 December 2026 [Page 7]
Internet-Draft ECN Export in IPFIX June 2026
Additional Information: See [RFC3168] for detailed information for
IPsec tunnel ECN negotiation.
Reference: [RFC5129], this document.
4.5. l2tpEcnNego
Name: l2tpEcnNego
ElementID: TBD5
Description: For L2TP tunnels, ECN processing is performed at the
L2TP encapsulation layer. [RFC9601] defines an ECN Capability AVP
(Type 103) for negotiation between L2TP Control Connection
Endpoints. The presence of this AVP indicates support for ECN
propagation. The IE value is defined to 1 for ECN AVP support and
0 for non-AVP support.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Additional Information: See [RFC9601] for detailed information for
L2TP tunnel ECN negotiation.
Reference: [RFC5129], this document.
4.6. notEctPacketDeltaCount
Name: notEctPacketDeltaCount
ElementID: TBD6
Description: The number of packets since the previous report (if
any) in this Flow with ECN codepoint set to Not-ECT (binary 00).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Additional Information: Refer to [RFC9331].
Reference: [RFC3168], [RFC9331], this document.
4.7. notEctPacketTotalCount
Name: notEctPacketTotalCount
Song, et al. Expires 28 December 2026 [Page 8]
Internet-Draft ECN Export in IPFIX June 2026
ElementID: TBD7
Description: The total number of packets of this Flow with ECN
codepoint set to Not-ECT at the Observation Point since the
Metering Process (re-)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Additional Information: Refer to [RFC9331].
Reference: [RFC3168], [RFC9331], this document.
4.8. ect0PacketDeltaCount
Name: ect0PacketDeltaCount
ElementID: TBD8
Description: The number of packets since the previous report (if
any) in this Flow with ECN codepoint set to ECT(0) (binary 01).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Additional Information: Refer to [RFC3168].
Reference: [RFC3168], [RFC9331], this document.
4.9. ect0PacketTotalCount
Name: ect0PacketTotalCount
ElementID: TBD9
Description: The total number of packets of this Flow with ECN
codepoint set to ECT(0) at the Observation Point since the
Metering Process (re-)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Additional Information: Refer to [RFC3168].
Reference: [RFC3168], [RFC9331], this document.
Song, et al. Expires 28 December 2026 [Page 9]
Internet-Draft ECN Export in IPFIX June 2026
4.10. ect1PacketDeltaCount
Name: ect1PacketDeltaCount
ElementID: TBD10
Description: The number of packets since the previous report (if
any) in this Flow with ECN codepoint set to ECT(1) (binary 10).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Additional Information: Refer to [RFC3168].
Reference: [RFC3168], [RFC9331], this document.
4.11. ect1PacketTotalCount
Name: ect1PacketTotalCount
ElementID: TBD11
Description: The total number of packets of this Flow with ECN
codepoint set to ECT(1) at the Observation Point since the
Metering Process (re-)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Additional Information: Refer to [RFC9331].
Reference: [RFC3168], [RFC9331], this document.
4.12. cePacketDeltaCount
Name: cePacketDeltaCount
ElementID: TBD12
Description: The number of packets since the previous report (if
any) in this Flow with ECN codepoint set to CE (Congestion
Experienced, binary 11).
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Song, et al. Expires 28 December 2026 [Page 10]
Internet-Draft ECN Export in IPFIX June 2026
Additional Information: Refer to [RFC9331].
Reference: [RFC3168], [RFC9331], this document.
4.13. cePacketTotalCount
Name: cePacketTotalCount
ElementID: TBD13
Description: The total number of packets of this Flow with ECN
codepoint set to CE at the Observation Point since the Metering
Process (re-)initialization for this Observation Point.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
Additional Information: Refer to [RFC9331].
Reference: [RFC3168], [RFC9331], this document.
5. Operational Considerations
The IPFIX IEs defined in this draft may have their information
extraction positions adjusted based on different ECN monitoring
purposes in the network. Among them, the basic ECN field elements
are used to reflect the ECN codepoints carried in the IPv4 header,
the IPv6 header, or the MPLS header. These fields can be flexibly
extracted at any node along the path that has IPFIX export
capability. For tunnel ECN negotiation status IEs, the IPFIX data
can only be provided by the specific tunnel endpoints that
participate in the negotiation. For cumulative statistics IEs, the
statistical data may be processed with a higher priority at traffic
aggregation or egress nodes.
In L4S deployments, CE marking may be either probabilistic or
deterministic, as determined by the specific AQM implementation. The
IEs on the statiscal count of CE-mark packets is defined to enable
operators to perfom quantitative monitoring and management of L4S
service performance, typically based on flow data that may be
acquired via packet or flow sampling. Implementations should employ
sampling methods (see [RFC5475]) that preserve the statistical
representativeness of these IEs and reduce bias risk of sampling
results.
Song, et al. Expires 28 December 2026 [Page 11]
Internet-Draft ECN Export in IPFIX June 2026
For IPsec tunnels, monitoring ECN requires exporting both outer and
inner IP header ECN fields (ipHeaderOuterEcn and ipHeaderInnerEcn),
along with ipsecSaEcnMode (see section 4.4 of this draft). Relying
solely on the outer IP header ECN field may be insufficient, as it
could be set to Not ECT due to tunnel mode restrictions. Similarly,
for L2TP tunnels, ECN monitoring should be verified the l2tpEcnNego
element (see section 4.5) except the ECN information extraction from
tunnel outer header and inner header of packets.
For MPLS tunnels, the ECN handling mechanism differs fundamentally
from IP based tunnels. ECN information is not carried in a dedicated
IP header field but is encoded within the MPLS label stack using the
EXP field, as defined in [RFC5129]. Therefore, monitoring ECN over
MPLS requires exporting the mplsHeaderEcn element defined in
Section 4.3 of this draft. This element captures the congestion
indication as conveyed within the MPLS domain, which is independent
of the inner IP packet's ECN field.
The calculation of derived metrics (e.g., L4S CE marking ratios) from
the base counters defined in the section 4 of this draft is an
implementation issue for the IPFIX Collector. Operators can utilize
the per-flow counts such as ect1PacketTotalCount and
cePacketTotalCount for such purposes. The caculation strategy is out
of the scope of this draft.
6. Security Considerations
The security considerations for IPFIX [RFC7011] apply to this
document. The elements for ECN reveal information about endpoint ECN
capabilities. Although the information may generally be not
sensitive, operators should consider applicable privacy regulations.
IPFIX records containing L4S monitoring information SHOULD be
transported using secure protocols such as TLS or DTLS and satisfy
the mutual authentication between IPFIX Exporting Processes and IPFIX
Collecting Processes as specified in [RFC7011].
While individual ECN codepoints may not be sensitive in isolation,
aggregated flow records can disclose: traffic patterns or user
behavior. ECT(1) markng may indicate L4S-capable applications,
potentially service types, such as interactive video conferencing,
cloud gaming or real-time service. And long-term collection of per-
flow ECN statistics may enable correlation with user activity
patterns, raising considerations under privacy regulations. Network
operators are expected to implement some policies such as access
control, anonymizing or aggregating ECN statics to prevent endpoint
identification.
Song, et al. Expires 28 December 2026 [Page 12]
Internet-Draft ECN Export in IPFIX June 2026
7. IANA Considerations
IANA is requested to assign the following Information Elements in the
IPFIX Information Elements registry.
+============+========================+===============+
| Element ID | Name | Reference |
+============+========================+===============+
| TBD1 | IPv4HeaderEcn | This document |
+------------+------------------------+---------------+
| TBD2 | IPv6HeaderEcn | This document |
+------------+------------------------+---------------+
| TBD3 | MPLSHeaderEcn | This document |
+------------+------------------------+---------------+
| TBD4 | ipsecSaEcnMode | This document |
+------------+------------------------+---------------+
| TBD5 | l2tpEcnNego | This document |
+------------+------------------------+---------------+
| TBD6 | notEctPacketDeltaCount | This document |
+------------+------------------------+---------------+
| TBD7 | notEctPacketTotalCount | This document |
+------------+------------------------+---------------+
| TBD8 | ect0PacketDeltaCount | This document |
+------------+------------------------+---------------+
| TBD9 | ect0PacketTotalCount | This document |
+------------+------------------------+---------------+
| TBD10 | ect1PacketDeltaCount | This document |
+------------+------------------------+---------------+
| TBD11 | ect1PacketTotalCount | This document |
+------------+------------------------+---------------+
| TBD12 | cePacketDeltaCount | This document |
+------------+------------------------+---------------+
| TBD13 | cePacketTotalCount | This document |
+------------+------------------------+---------------+
Table 1: New IPFIX Information Elements
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/info/rfc2119>.
Song, et al. Expires 28 December 2026 [Page 13]
Internet-Draft ECN Export in IPFIX June 2026
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[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/info/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/info/rfc8174>.
8.2. Informative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<https://www.rfc-editor.org/info/rfc2780>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <https://www.rfc-editor.org/info/rfc5129>.
[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/info/rfc5475>.
[RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G.
White, "Low Latency, Low Loss, and Scalable Throughput
(L4S) Internet Service: Architecture", RFC 9330,
DOI 10.17487/RFC9330, January 2023,
<https://www.rfc-editor.org/info/rfc9330>.
Song, et al. Expires 28 December 2026 [Page 14]
Internet-Draft ECN Export in IPFIX June 2026
[RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit
Congestion Notification (ECN) Protocol for Low Latency,
Low Loss, and Scalable Throughput (L4S)", RFC 9331,
DOI 10.17487/RFC9331, January 2023,
<https://www.rfc-editor.org/info/rfc9331>.
[RFC9601] Briscoe, B., "Propagating Explicit Congestion Notification
across IP Tunnel Headers Separated by a Shim", RFC 9601,
DOI 10.17487/RFC9601, August 2024,
<https://www.rfc-editor.org/info/rfc9601>.
Authors' Addresses
Xueyan Song
ZTE Corp.
Email: song.xueyan2@zte.com.cn
Yao Liu
ZTE Corp.
Email: liu.yao71@zte.com.cn
Jonathan Newton
Vodafone
Email: jonathan.newton@vodafone.com
Jason Livingood
Comcast
Email: Jason_Livingood@comcast.com
Song, et al. Expires 28 December 2026 [Page 15]