QUIC Transport for Network Telemetry
draft-netana-opsawg-telemetry-over-quic-00
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 , Thomas Graf , Paolo Lucente , Holger Keller , Alan DeKok | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | radext at IETF-126 , opsarea at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-netana-opsawg-telemetry-over-quic-00
OPSAWG B. Claise
Internet-Draft Everything OPS & Arrcus
Intended status: Informational T. Graf
Expires: 4 January 2027 Swisscom
P. Lucente
NTT
H. Keller
Deutsche Telekom
A. DeKok
InkBridge Networks
3 July 2026
QUIC Transport for Network Telemetry
draft-netana-opsawg-telemetry-over-quic-00
Abstract
This document describes the use of the QUIC transport protocol as a
common transport substrate for operational Network Telemetry
protocols that currently rely on UDP. Specifically, it discusses
carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and
RADIUS Accounting over QUIC connections. For telemetry protocols
whose data plane is inherently loss-tolerant (where a missing sample
is preferable to a delayed retransmission) this document recommends
use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames).
A primary motivation for this work is the unification of transport-
layer security across heterogeneous telemetry protocols. Protocols
that currently have no mandatory transport security (syslog over UDP)
or optional-only security (IPFIX over UDP with DTLS) or weak security
(RADIUS with MD5 obfuscation) would all benefit from the mandatory
TLS 1.3 mutual authentication that QUIC provides. This document
specifically addresses the operational advantages of managing a
single PKI certificate lifecycle per Network Node to authenticate all
telemetry streams.
This document is intended as a framework and applicability statement.
Per-protocol bindings that require normative specification are
expected to be chartered in their respective IETF working groups.
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 4 January 2027 [Page 1]
Internet-Draft Telemetry over QUIC 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 4 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
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. QUIC and RFC 9221 DATAGRAM Frames . . . . . . . . . . . . 8
3.2. Why DATAGRAM Frames for Telemetry . . . . . . . . . . . . 9
3.3. Relationship to DTLS . . . . . . . . . . . . . . . . . . 10
4. Problem Statement: Security Gaps in UDP Telemetry . . . . . . 11
4.1. Protocols with No or Optional Transport Security . . . . 11
4.2. RADIUS Authentication Weakness . . . . . . . . . . . . . 11
4.3. Absence of Unified Certificate Management . . . . . . . . 12
5. Framework: Telemetry over QUIC DATAGRAM Frames . . . . . . . 12
5.1. Connection Model . . . . . . . . . . . . . . . . . . . . 12
5.2. Application-Layer Protocol Negotiation (ALPN)
Identification . . . . . . . . . . . . . . . . . . . . . 12
5.3. Telemetry Payload Format . . . . . . . . . . . . . . . . 13
5.4. Stream/Datagram Split . . . . . . . . . . . . . . . . . . 13
5.5. max_datagram_frame_size Negotiation . . . . . . . . . . . 14
Claise, et al. Expires 4 January 2027 [Page 2]
Internet-Draft Telemetry over QUIC July 2026
5.6. Connection Lifecycle and Keepalive . . . . . . . . . . . 14
6. Certificate Management Advantages . . . . . . . . . . . . . . 14
6.1. Unified Network Node Identity . . . . . . . . . . . . . . 14
6.2. Single Certificate Lifecycle . . . . . . . . . . . . . . 15
6.3. Elimination of RADIUS MD5 Dependency . . . . . . . . . . 15
6.4. Connection Migration and Failover . . . . . . . . . . . . 15
6.5. Comparison with Current Security Mechanisms . . . . . . . 16
7. Per-Protocol Mappings . . . . . . . . . . . . . . . . . . . . 16
7.1. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1.1. Template Records . . . . . . . . . . . . . . . . . . 16
7.1.2. Data Records . . . . . . . . . . . . . . . . . . . . 17
7.1.3. Relationship to draft-llg-opsawg-ipfix-over-quic . . 17
7.2. Syslog . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. YANG-Push UDP-Notif . . . . . . . . . . . . . . . . . . . 17
7.3.1. Distributed Notifications . . . . . . . . . . . . . . 18
7.4. RADIUS Accounting . . . . . . . . . . . . . . . . . . . . 18
7.4.1. RADIUS Authentication Requests . . . . . . . . . . . 19
7.4.2. RADIUS Status-Server . . . . . . . . . . . . . . . . 19
8. Operational Considerations . . . . . . . . . . . . . . . . . 19
8.1. Collector Scalability . . . . . . . . . . . . . . . . . . 19
8.2. Connection Re-establishment . . . . . . . . . . . . . . . 20
8.3. Interaction with Distributed Export . . . . . . . . . . . 20
8.4. Impact on Network Node Resources . . . . . . . . . . . . 20
8.5. Legacy UDP Interoperability . . . . . . . . . . . . . . . 20
8.6. Quasi-Anycast . . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10.1. ALPN Protocol Identifiers . . . . . . . . . . . . . . . 23
10.2. Telemetry Type Registry . . . . . . . . . . . . . . . . 23
10.3. UDP Port Numbers . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
Network operators depend on a diverse set of telemetry protocols to
monitor and manage their infrastructure, exporting operational data
on which capacity planning, fault detection, and security analysis
depend.
Some of the protocols are connectionless, such as YANG-Push UDP-Notif
[RFC8639] [RFC8641] [I-D.ietf-netconf-udp-notif], IP Flow Information
Export (IPFIX) [RFC7011], Syslog [RFC5424], RADIUS [RFC2865] or
RADIUS Accounting [RFC2866] while some others are connection-
oriented, such as BMP [RFC7854] or NETCONF [RFC6241].
Claise, et al. Expires 4 January 2027 [Page 3]
Internet-Draft Telemetry over QUIC July 2026
These protocols share a common characteristic: many of their current
deployments use UDP as the transport, accepting the possibility of
packet loss in exchange for low overhead and high throughput. This
is a rational design choice for telemetry data where a stale or
retransmitted sample provides less value than a fresh one received in
a timely manner.
However, this same UDP deployment model brings significant
operational liabilities:
* No mandatory transport-layer security. An attacker on the path
can inject or spoof telemetry records. Syslog over UDP has no
transport security at all. IPFIX over UDP optionally supports
DTLS [RFC6347] but deployment is uncommon; plain UDP is the norm.
* No confidentiality. Telemetry data, which may include flow
records, routing state, and accounting data, is transmitted in the
clear.
* Weak authentication. RADIUS [RFC2865] uses MD5 to obfuscate the
User-Password attribute, and both RADIUS [RFC2865] and RADIUS
Accounting [RFC2866] use an MD5-based shared-secret mechanism to
compute the Request/Response Authenticator field. These MD5 uses
are widely acknowledged to be cryptographically inadequate.
[I-D.ietf-radext-radiusdtls-bis] defines TLS as a transport for
RADIUS, but still uses MD5. [RFC9765] uses TLS as a transport,
removes the use of MD5, but is experimental.
* Fragmented certificate management. When operators do deploy
security (e.g., DTLS for IPFIX [RFC6347] or [RFC9147]), each
protocol requires a separate security association and a separate
certificate or key lifecycle.
The QUIC protocol [RFC9000], with its mandatory TLS 1.3 integration
[RFC9001], addresses all of these liabilities. The Unreliable
Datagram Extension to QUIC [RFC9221] further allows applications to
send data without retransmission semantics while retaining the
security, congestion awareness, and connection migration properties
of the QUIC connection. This combination makes QUIC DATAGRAM frames
a natural replacement for the UDP transport used by loss-tolerant
telemetry protocols. For example, losing a YANG-Push UDP-Notif
Notification Message is generally acceptable for network monitoring
applications, but may not be for security-sensitive applications.
This document is motivated by the observation that the IETF community
is producing several independent drafts mapping specific protocols to
QUIC (see Section 1.2). Rather than leaving certificate management,
Claise, et al. Expires 4 January 2027 [Page 4]
Internet-Draft Telemetry over QUIC July 2026
connection lifecycle, and operational guidance to be re-specified
independently in each protocol draft, this document defines a common
framework, or at least a common problem space.
1.1. Applicability
This document covers protocols that satisfy all three of the
following criteria:
1. The protocol currently has a defined UDP transport profile.
2. The protocol's data plane is inherently loss-tolerant; that is,
retransmission of a missing record either provides no value
(stale sample), is already handled at the application layer
(e.g., IPFIX Template Record retransmission), or occasional
record loss is acceptable for the target application (e.g.,
network monitoring).
3. The protocol does not require sub-millisecond latency for
telemetry data transmission that would be defeated by the QUIC
software stack.
Protocols that do not satisfy criterion 3 (e.g., NTP, PTP) are out of
scope for this document.
1.2. Related Work
The following IETF drafts address individual protocol mappings to
QUIC:
* NETCONF over QUIC [I-D.ietf-netconf-over-quic]: uses QUIC streams
for reliable NETCONF messaging.
* BMP over QUIC [I-D.liu-grow-bmp-over-quic]: BGP Monitoring
Protocol over QUIC streams.
* RPKI-RTR over QUIC [I-D.liu-sidrops-rpki-rtr-over-quic]: RPKI to
Router Protocol over QUIC.
* IPFIX over QUIC [I-D.llg-opsawg-ipfix-over-quic]: IPFIX over QUIC.
* BGP over QUIC [I-D.retana-idr-bgp-quic]: BGP session over QUIC.
* RADIUS over QUIC [I-D.yl-radext-quic-transport]: RADIUS transport
over QUIC streams.
* PCEP over QUIC [I-D.yang-pce-pcep-over-quic]: Path Computation
Element Communication Protocol over QUIC.
Claise, et al. Expires 4 January 2027 [Page 5]
Internet-Draft Telemetry over QUIC July 2026
This document complements those drafts by providing a shared
framework specifically for the UDP-based, loss-tolerant telemetry
subset.
1.3. 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.
2. Terminology
As in [RFC7011], the first letter of each term defined in this
section is capitalized throughout this document.
The following term is used as defined in [RFC9232]:
Network Telemetry:
The process and instrumentation for acquiring and utilizing
network data remotely for network monitoring and operation. A
general term for a large set of network visibility techniques and
protocols, concerning aspects like data generation, collection,
correlation, and consumption.
The following terms are used as defined in [RFC7011]:
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.
Exporter:
A device that runs an Exporting Process, sending IPFIX Messages to
one or more Collecting Processes.
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.
Observation Domain:
Claise, et al. Expires 4 January 2027 [Page 6]
Internet-Draft Telemetry over QUIC July 2026
The largest set of Observation Points for which Flow information
can be aggregated by a Metering Process.
Options Template Set:
A collection of one or more Options Template Records that have
been grouped together in an IPFIX Message.
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.
The following terms are used as defined in [RFC8639], [RFC8641], and
[I-D.ietf-netconf-udp-notif]:
Message Publisher ID:
A field in the UDP-Notif shim header that identifies the
originating publisher process within a distributed notification
architecture (for example, a line card process).
On-Change Subscription:
A subscription that delivers information to a Receiver whenever a
change in a datastore is detected.
Periodic Subscription:
A subscription that delivers information to a Receiver at periodic
intervals.
Notification Message:
Information intended for a Receiver indicating that one or more
events have occurred.
Publisher:
An actor that pushes subscribed event stream data to Receivers.
In this document, the Publisher corresponds to the network device
exporting Network Telemetry.
Receiver:
An actor that receives subscribed event stream data. In this
document, the Receiver corresponds to the Network Telemetry
collector.
The following terms are used as defined in [RFC9000] and [RFC9221]:
Connection ID:
Claise, et al. Expires 4 January 2027 [Page 7]
Internet-Draft Telemetry over QUIC July 2026
An identifier assigned to a QUIC connection that decouples the
connection from the underlying network address (IP address and
port tuple), enabling connection migration.
DATAGRAM frame:
An unreliable, unordered data unit defined in [RFC9221] and
carried within a QUIC connection. Lost DATAGRAM frames are not
retransmitted by the transport; however, they are subject to
congestion control.
STREAM frame:
A reliable, ordered data unit defined in [RFC9000] and carried
within a QUIC connection. Lost STREAM frame data is retransmitted
transparently by the QUIC transport.
The following terms are used in later in this document:
Session Initiator: The Network Node that actively opens the QUIC
session; the session initiator is responsible for starting the
connection, performing the TLS handshake, and for detecting and
recovering from session silence by re-establishing the session
when required. The following term is defined in this document:
Network Node: Any IP-connected network element -- including routers,
switches, servers, and appliances -- that generates and exports
Network Telemetry data. In this document, Network Node is the
entity that acts as Publisher ([RFC8639], in YANG-Push contexts),
Exporter ([RFC7011], in IPFIX contexts), Originator ([RFC5424], in
syslog contexts), or RADIUS client (in RADIUS contexts),
originating telemetry data and transmitting it to a collector over
QUIC.
3. Background
3.1. QUIC and RFC 9221 DATAGRAM Frames
QUIC [RFC9000] is a UDP-based, multiplexed, secure transport
protocol. Every QUIC connection requires completion of a TLS 1.3
handshake [RFC9001], which authenticates both endpoints (optionally
mutual) and derives the session keys used to protect all subsequent
packets.
QUIC supports two data-carrying abstractions:
* STREAM frames: provide reliable, ordered delivery semantics
equivalent to TCP. Lost packets are detected and retransmitted.
Claise, et al. Expires 4 January 2027 [Page 8]
Internet-Draft Telemetry over QUIC July 2026
* DATAGRAM frames ([RFC9221]): provide unreliable delivery within
the established, encrypted, congestion- aware QUIC connection.
Lost packets are not retransmitted. The application is optionally
notified of loss (implementation- dependent).
Support for DATAGRAM frames is negotiated via the
max_datagram_frame_size transport parameter during the QUIC
handshake. Endpoints that do not include this parameter do not
support DATAGRAM frames on that connection.
3.2. Why DATAGRAM Frames for Telemetry
Telemetry data streams such as IPFIX Flow Records, syslog messages,
YANG-Push UDP-Notif periodic notifications, or RADIUS accounting
share the property that a delayed retransmission has less value than
a fresh observation. For these streams, DATAGRAM frames are the
correct primitive:
* Loss of a DATAGRAM frame does not block delivery of subsequent
frames (no head-of-line blocking at the transport layer).
* Unlike raw UDP, DATAGRAM frames are subject to the connection's
congestion controller ([RFC9002]). A Network Node under load will
back off rather than continue to flood the network.
* DATAGRAM frames are encrypted, authenticated, and integrity-
protected by the same TLS 1.3 session keys as all other QUIC
packets. The QUIC handshake authenticates the communicating
parties via TLS 1.3 certificates. IPFIX Flow Records and syslog
messages carried over plain UDP are designed for use within
limited domains ([RFC8799]) where the network path is considered
trusted; they are neither encrypted nor source-authenticated.
Where such records drive traffic engineering decisions -- route
optimization, load balancing, anomaly-triggered policy changes --
or inform network monitoring, an on-path attacker within or at the
boundary of the limited domain can inject forged records to
influence those decisions or simply discredit monitoring results
by introducing spurious data. Once the QUIC handshake completes,
every DATAGRAM frame is automatically confidential, its origin
cryptographically authenticated, and any in-transit modification
is detected and discarded, at no additional configuration cost.
* A single QUIC connection may carry multiple logical telemetry
streams, distinguished by application-layer demultiplexing within
the DATAGRAM payload. This eliminates the need for per-protocol
UDP sockets and separate security associations.
Claise, et al. Expires 4 January 2027 [Page 9]
Internet-Draft Telemetry over QUIC July 2026
* All telemetry protocols multiplexed on a single QUIC connection
share one TLS 1.3 handshake and one certificate lifecycle. A
Network Node exporting IPFIX, syslog, and YANG-Push notifications
simultaneously via a single QUIC connection requires only one set
of cryptographic keys and one certificate, rather than separate
TLS contexts and key material per protocol.
* The cost of issuing and maintaining certificates may depend on the
number of certificates required. In large-scale deployments,
requiring separate certificates for each protocol or application
instead of a single certificate per Network Node can significantly
increase operational costs, particularly when certificate
licensing or management fees are charged on a per-certificate
basis. These cost implications SHOULD be considered when defining
certificate deployment models, especially for deployments
consisting of a large number of Network Nodes.
* With UDP-based telemetry, the Collector identifies the originating
Network Node by the source IP address of the UDP socket --
typically the IP address of the outgoing interface. If that
interface fails over, the source IP changes and the Collector
loses track of the Network Node, unless the Network Node is
explicitly configured to bind to a stable address (e.g., "source
interface loopback0"). The QUIC Connection ID ([RFC9000])
provides a stable, transport-layer Network Node identifier that
persists across address changes, eliminating this source-address
configuration dependency.
For protocol components that require reliability (notably IPFIX
Template Records), QUIC STREAM frames on the same connection provide
reliable delivery without a separate TCP connection.
3.3. Relationship to DTLS
DTLS [RFC6347] has been specified as a security layer for UDP-based
telemetry (e.g., IPFIX over DTLS [RFC7011]). DTLS 1.2 [RFC6347] is
the version referenced in existing protocol security specifications;
DTLS 1.3 [RFC9147] is the current specification. QUIC mandates TLS
1.3 [RFC9001] for all connections, and as a result offers the
following advantages relative to DTLS 1.2, with notes where DTLS 1.3
narrows the gap:
* QUIC's 1-RTT handshake for new connections is faster than the
2-RTT full handshake required by DTLS 1.2 [RFC6347]. DTLS 1.3
[RFC9147] also achieves 1-RTT for new connections, so this
advantage applies primarily to deployments that have not yet
migrated to DTLS 1.3.
Claise, et al. Expires 4 January 2027 [Page 10]
Internet-Draft Telemetry over QUIC July 2026
* QUIC's 0-RTT resumption allows loss-tolerant data to begin flowing
before the handshake completes for resumed connections. DTLS 1.2
[RFC6347] does not support 0-RTT resumption. DTLS 1.3 [RFC9147]
does support 0-RTT resumption (Section 5 of [RFC9147]), so this
advantage does not apply when comparing against DTLS 1.3
deployments.
* Connection migration, driven by the Connection ID mechanism,
allows telemetry streams to survive network address changes (e.g.,
line card failover, management plane IP renumbering) without
session restart.
* A single QUIC connection replaces multiple parallel DTLS sessions
when a Network Node exports several telemetry streams to the same
collector.
4. Problem Statement: Security Gaps in UDP Telemetry
4.1. Protocols with No or Optional Transport Security
Syslog over UDP [RFC5426] defines no transport security in its base
UDP profile. IPFIX over UDP (RFC 7011 Section 10.4) optionally
supports DTLS [RFC9147] for transport security, but this is not
mandatory and in practice most deployments use plain UDP without
DTLS, relying instead on network-layer access control (ACLs, routing
policy) as a substitute for authentication. This provides no
protection against on-path attackers and is invisible to the
receiving collector, which cannot verify the origin of records.
4.2. RADIUS Authentication Weakness
RADIUS [RFC2865] uses MD5 with a shared secret to obfuscate the User-
Password attribute. Both RADIUS [RFC2865] and RADIUS Accounting
[RFC2866] derive the Request Authenticator and Response Authenticator
fields using an MD5 hash of the packet contents and the shared
secret. The MD5 weaknesses involved are well-documented and widely
acknowledged. While RADIUS over TLS (RadSec,
[I-D.ietf-radext-radiusdtls-bis]) exists, adoption has been limited
by operational complexity and the need to manage separate TLS
contexts for RADIUS alongside existing TLS deployments on the same
Network Node.
[I-D.ietf-radext-radiusdtls-bis] also maintains the use of MD5, which
is only removed in [RFC9765], which is experimental.
Claise, et al. Expires 4 January 2027 [Page 11]
Internet-Draft Telemetry over QUIC July 2026
4.3. Absence of Unified Certificate Management
Even where individual protocols support transport security, operators
face the burden of managing separate security contexts per protocol:
* A Network Node exporting IPFIX over DTLS, syslog over TLS
([RFC5425]), and YANG-Push over HTTPS requires three separate
certificate deployments, three renewal cycles, and three
independent revocation verification paths (whether via Certificate
Revocation Lists (CRL) or Online Certificate Status Protocol
(OCSP) queries) for what is functionally the same Network Node
identity.
* Certificate rotation in one protocol does not benefit the others.
* Monitoring certificate expiry requires per-protocol tooling.
This fragmentation is a significant operational burden, particularly
at scale.
5. Framework: Telemetry over QUIC DATAGRAM Frames
5.1. Connection Model
A QUIC connection for Network Telemetry is established from the
Network Node to the telemetry collector (Receiver). This follows the
same direction as the data flow for push-based Network Telemetry.
QUIC mandates TLS 1.3 ([RFC9001]). Mutual authentication (both
client and server certificates) SHOULD be used. The Network Node
certificate authenticates the Exporter; the collector certificate
authenticates the Receiver.
The QUIC connection carries all telemetry streams between a given
Network Node-to-collector pair. STREAM frames and DATAGRAM frames
co-exist on the same connection. The application layer MUST provide
a demultiplexing header in the DATAGRAM payload to identify the
protocol and stream identity (see Section 5.3).
5.2. Application-Layer Protocol Negotiation (ALPN) Identification
Each telemetry protocol using this framework SHOULD register a
dedicated ALPN [RFC9001] identifier. Recommended identifiers are
specified in Section 10. An implementation MAY use the generic
"telq" ALPN when multiplexing multiple protocols on a single
connection, with per-protocol identification delegated to the
DATAGRAM payload header.
Claise, et al. Expires 4 January 2027 [Page 12]
Internet-Draft Telemetry over QUIC July 2026
5.3. Telemetry Payload Format
A two-byte Telemetry Type field prepended to each QUIC frame payload
identifies the encapsulated telemetry protocol. This header applies
to both DATAGRAM frames (unreliable telemetry data) and STREAM frames
(reliable control and state-change data, such as IPFIX Template
Records, YANG-Push on-change notifications, and subscription state
change notifications). This allows a single QUIC connection to carry
multiple telemetry protocols without ambiguity, regardless of the
reliability mechanism used.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Telemetry Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-Specific Payload |
| (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: QUIC Frame Payload Format
Telemetry Type values are defined in Section 10. The protocol-
specific payload for each protocol is identical to the payload that
would be transmitted in the corresponding UDP datagram. No further
encapsulation is required. This design allows existing encoder/
decoder implementations to function without modification when the UDP
socket is replaced by a QUIC DATAGRAM or STREAM API.
5.4. Stream/Datagram Split
For protocols that mix reliable and unreliable data, the following
split applies:
* Protocol control information, Template Records, and configuration
messages MUST be carried on QUIC STREAM frames to ensure reliable
delivery.
* Telemetry data records (Flow Records, log messages, notification
updates, accounting records) SHOULD be carried on QUIC DATAGRAM
frames.
An implementation MAY carry all data on QUIC STREAM frames if the
application requires guaranteed delivery. This is a per-deployment
configuration choice, not a protocol violation.
Claise, et al. Expires 4 January 2027 [Page 13]
Internet-Draft Telemetry over QUIC July 2026
5.5. max_datagram_frame_size Negotiation
Endpoints MUST advertise a max_datagram_frame_size sufficient to
accommodate the largest expected telemetry record without
fragmentation. A value of 65535 is RECOMMENDED as a safe upper
bound. Per [RFC9221], DATAGRAM frames larger than the negotiated
maximum may not be sent; implementations MUST either fragment at the
application layer or fall back to STREAM frames for oversized
records.
5.6. Connection Lifecycle and Keepalive
Unlike TCP-based telemetry protocols (gRPC/gNMI, NETCONF), a QUIC
connection silently expires when no packets are exchanged within the
idle timeout. The Session Initiator SHOULD monitor for the absence
of expected telemetry and re-establish the QUIC session when the peer
remains silent beyond its configured reporting interval.
QUIC idle timeout is configured via the max_idle_timeout transport
parameter. For long-lived telemetry sessions, implementations SHOULD
send QUIC PING frames at an interval not exceeding half the
max_idle_timeout to maintain the connection and any intermediate NAT
bindings. According to section 3.2 of [RFC9308], it is recommended
to set the interval to 30 seconds to ensure that possible NAT states
in transit remain active, while section 10.1 of [RFC9000] states that
the PING frames interval should be set so that at least 3 PING frames
can be sent before max_idle_timeout is reached. Therefore, a
recommended idle timeout for telemetry connections is 120 seconds,
with PING frames sent at 30-second intervals.
6. Certificate Management Advantages
This section describes the specific operational improvements that
arise from consolidating UDP-based Network Telemetry under a single
QUIC connection with TLS 1.3 mutual authentication.
6.1. Unified Network Node Identity
A Network Node that currently exports IPFIX, Syslog, and YANG-Push
UDP-Notif over UDP has no cryptographic Network Node identity in
those channels. Under this framework, a single X.509 certificate
issued to the Network Node (identified by its Common Name or Subject
Alternative Name) authenticates the Network Node for all telemetry
streams carried on the QUIC connection. The collector need only
maintain one trust anchor per Network Node, independent of how many
telemetry protocols that Network Node exports.
Claise, et al. Expires 4 January 2027 [Page 14]
Internet-Draft Telemetry over QUIC July 2026
6.2. Single Certificate Lifecycle
Certificate issuance, renewal, and revocation are managed once per
Network Node, not once per protocol. This has direct operational
consequences:
* Automated certificate management tools (e.g., ACME, EST) need to
manage one certificate per Network Node for all Network Telemetry,
rather than one per protocol per Network Node.
* Certificate expiry monitoring requires one alert per Network Node.
* Key rotation is performed once; all telemetry protocols on the
renewed connection immediately benefit from the new key material
via QUIC's post-handshake key update mechanism.
* OCSP stapling (supported in TLS 1.3 and thus in QUIC [RFC9001])
provides revocation status to the collector without requiring the
collector to independently query an OCSP responder per protocol.
6.3. Elimination of RADIUS MD5 Dependency
RADIUS Accounting [RFC2866] derives the Accounting-Request
Authenticator as an MD5 hash over the packet contents and the shared
secret ([RFC2866] Section 3), providing only weak integrity
protection. By mapping RADIUS Accounting messages to QUIC DATAGRAM
frames, this MD5-based shared-secret dependency is replaced by AEAD
encryption (AES-128-GCM or ChaCha20-Poly1305) derived from the TLS
1.3 handshake. No shared secret configuration is required. The
collector authenticates the Network Node by its certificate; the
Network Node authenticates the collector by its certificate.
6.4. Connection Migration and Failover
When a Network Node's management plane IP address changes -- due to
interface failover or ECMP re-hashing -- a TCP-based telemetry
session breaks and requires a new TLS handshake (and certificate
verification) on the replacement connection. Under QUIC, Connection
IDs decouple the session identity from the underlying IP/port
4-tuple. The connection, and its associated authenticated identity,
survives the address change. No certificate re-validation is
required for the migrated path.
Claise, et al. Expires 4 January 2027 [Page 15]
Internet-Draft Telemetry over QUIC July 2026
6.5. Comparison with Current Security Mechanisms
+===========+========================+======================+
| Protocol | Current UDP Security | Under This Framework |
+===========+========================+======================+
| IPFIX | DTLS (optional, | TLS 1.3 mutual auth, |
| | [RFC6347] / [RFC9147]) | AEAD |
+-----------+------------------------+----------------------+
| Syslog | None ([RFC5426] UDP) | TLS 1.3 mutual auth, |
| | | AEAD |
+-----------+------------------------+----------------------+
| YANG-Push | Optional DTLS | TLS 1.3 mutual auth, |
| UDP-Notif | | AEAD |
+-----------+------------------------+----------------------+
| RADIUS | MD5 obfuscation | TLS 1.3 mutual auth, |
| Acct | | AEAD |
+-----------+------------------------+----------------------+
Table 1: Security Comparison for UDP Telemetry Protocols
7. Per-Protocol Mappings
7.1. IPFIX
IPFIX [RFC7011] uses a Template/Data Record architecture. Template
Records define the Information Elements present in Data Records. A
Receiver that has not received the relevant Template Record cannot
decode Data Records.
7.1.1. Template Records
Template Records MUST be carried on QUIC STREAM frames. The stream
MUST be a unidirectional stream initiated by the Exporter. Template
Records within this stream follow the normal IPFIX encoding with Set
ID 2 (Template Set) or Set ID 3 (Options Template Set). The reliable
delivery semantics of QUIC streams ensure that the Receiver obtains
all templates before or concurrent with the first Data Records
referencing them.
This is architecturally equivalent to the TCP-based IPFIX transport
(RFC 7011 Section 10.3), replacing the TCP byte stream with a QUIC
stream.
Claise, et al. Expires 4 January 2027 [Page 16]
Internet-Draft Telemetry over QUIC July 2026
7.1.2. Data Records
IPFIX Data Records SHOULD be carried on QUIC DATAGRAM frames. Each
DATAGRAM frame payload, after the two-byte Telemetry Type header
defined in Section 5.3, contains one or more IPFIX Data Sets encoded
according to RFC 7011.
Loss of a DATAGRAM frame results in loss of the contained Flow
Records, consistent with the existing behavior of the IPFIX UDP
transport (RFC 7011 Section 10.2).
The Observation Domain ID is preserved in each IPFIX Message Header
within the DATAGRAM payload. No mapping between QUIC stream
identifiers and IPFIX Observation Domain IDs is required.
7.1.3. Relationship to draft-llg-opsawg-ipfix-over-quic
[I-D.llg-opsawg-ipfix-over-quic] defines a more complete IPFIX
binding to QUIC, potentially including stream-per-template-set
designs. This document focuses on the DATAGRAM-based data plane as
the direct replacement for the UDP export profile, and defers
normative detail to that draft.
7.2. Syslog
Syslog over UDP [RFC5426] sends syslog messages as individual UDP
datagrams. Each syslog message is self-contained, making it directly
suitable for DATAGRAM frame transport.
Each DATAGRAM frame payload, after the Telemetry Type header,
contains exactly one syslog message encoded per RFC 5424 [RFC5424].
The message format is unchanged from the UDP transport.
Syslog over TLS [RFC5425] provides a reference for certificate- based
authentication of syslog. Under this framework, the same PKI
infrastructure is used, but via the QUIC connection rather than a
separate TLS-over-TCP session.
7.3. YANG-Push UDP-Notif
This section covers YANG-Push exclusively in its UDP-based transport
variant: YANG-Push UDP-Notif [I-D.ietf-netconf-udp-notif]. Other
YANG-Push transports (HTTPS-Notif, NETCONF) are TCP-based and out of
scope for this document. YANG-Push UDP-Notif sends Notification
Messages as UDP datagrams with a shim header providing message
segmentation and sequence numbering.
Claise, et al. Expires 4 January 2027 [Page 17]
Internet-Draft Telemetry over QUIC July 2026
Under this framework, YANG-Push UDP-Notif messages are carried in
QUIC DATAGRAM frames using the UDP-Notif shim header unchanged. The
shim header's sequence number field provides loss detection at the
application layer, consistent with its use in the UDP transport.
Three notification types warrant different treatment:
* push-update notifications: data samples are time-bound and stale
if retransmitted. DATAGRAM frames SHOULD be used.
* push-change-update notifications: missed change notifications
result in the collector maintaining an incorrect view of Network
Node state. For On-Change Subscriptions, implementations SHOULD
use QUIC STREAM frames to ensure reliable delivery.
* subscription state change notifications: missed subscription state
change notifications result in the collector maintaining an
incorrect view of YANG-Push subscription state. For subscription
state change notifications, implementations SHOULD use QUIC STREAM
frames to ensure reliable delivery.
This per-subscription-type split is the primary rationale for using
this framework for YANG-Push: the DATAGRAM/STREAM choice maps
directly onto the existing periodic/on-change distinction, while the
UDP-Notif shim header is preserved unchanged.
7.3.1. Distributed Notifications
The Distributed Notifications architecture
[I-D.ietf-netconf-distributed-notif] allows line card processes to
export directly to collectors without routing through the Route
Processor. QUIC DATAGRAM frames are well-suited to this model: each
line card process opens a QUIC connection to the collector and sends
DATAGRAM frames. The Message Publisher ID in the shim header
identifies the originating process.
7.4. RADIUS Accounting
RADIUS Accounting [RFC2866] uses UDP transport with MD5-based message
authentication. Accounting-Request and Accounting-Response messages
are self-contained.
Under this framework:
* Accounting-Request messages are carried in QUIC DATAGRAM frames.
* The base RADIUS protocol is updated to use RADIUS/1.1 [RFC9765].
Most notably:
Claise, et al. Expires 4 January 2027 [Page 18]
Internet-Draft Telemetry over QUIC July 2026
* RADIUS packets no longer use MD5 for authentication ([RFC9765],
Section 4).
* RADIUS attributes are no longer obfuscated [RFC9765], Section 5.
* RADIUS/1.1 allows more than 256 packets to be outstanding over one
connection.
* Accounting-Response messages from the collector to the Network
Node travel in the reverse direction. As QUIC DATAGRAM frames are
bidirectional, the collector responds using a DATAGRAM frame on
the same connection.
[I-D.yl-radext-quic-transport] defines an alternative RADIUS mapping
over QUIC STREAM frames, providing reliable delivery semantics for
RADIUS. The present document's DATAGRAM approach is appropriate for
high-volume accounting scenarios where occasional record loss is
acceptable. Implementations MUST choose one approach per connection
based on deployment requirements.
7.4.1. RADIUS Authentication Requests
RADIUS can also transport Access-Request packets, and responses to
those packets. While it is possible to transport those packets via
this specification, that behavior is not addressed here.
7.4.2. RADIUS Status-Server
RADIUS also provides for connection oriented status checks via the
Status-Server packet [RFC5997]. Where implementations of this
specification need [RFC3539] application-layer watchdog signaling,
QUIC PING frames MUST be used instead of Status-Server packets.
8. Operational Considerations
8.1. Collector Scalability
A single collector may receive QUIC connections from a large number
of Network Nodes. Each QUIC connection carries its own TLS context.
Collectors MUST be designed to handle large numbers of concurrent
QUIC connections efficiently. Connection-level flow control
(MAX_DATA) SHOULD be tuned to accommodate bursty telemetry export
patterns.
Claise, et al. Expires 4 January 2027 [Page 19]
Internet-Draft Telemetry over QUIC July 2026
8.2. Connection Re-establishment
If a QUIC connection is lost (idle timeout, network failure, Network
Node reboot), the Network Node MUST re-establish the connection and
re-transmit any stateful protocol information (e.g., IPFIX Template
Records) before resuming DATAGRAM-based data export. Network Nodes
SHOULD implement exponential backoff for re-establishment attempts.
8.3. Interaction with Distributed Export
In distributed architectures (e.g., line card direct export), each
line card process MAY maintain a separate QUIC connection to the
collector, or MAY share a connection with the Route Processor. The
Message Publisher ID in YANG-Push UDP-Notif
[I-D.ietf-netconf-udp-notif] identifies the originating Publisher
process (e.g., a line card process) regardless of the connection
topology. Similarly, in a distributed router architecture, IPFIX
[RFC7011] deployments have each line card run its own Metering
Process with a distinct Observation Domain ID carried in each IPFIX
Message Header, identifying the originating Observation Domain
regardless of the connection topology.
8.4. Impact on Network Node Resources
QUIC connections consume memory and CPU for TLS context, congestion
state, and Connection ID management. Network Nodes with high line
card counts and multiple telemetry protocols should evaluate the
resource impact of maintaining one QUIC connection per collector per
line card against the resource savings of multiplexing protocols on
fewer connections.
8.5. Legacy UDP Interoperability
Network Nodes that do not support QUIC MUST continue to support their
existing UDP transport profiles. This framework does not deprecate
UDP transport for any protocol. QUIC transport availability SHOULD
be advertised via the YANG capabilities model [RFC9196] to allow
collectors to negotiate the preferred transport.
8.6. Quasi-Anycast
A telemetry collector MAY be reachable via an anycast address for
initial QUIC rendezvous, with the connection subsequently migrated to
a stable unicast address using QUIC Preferred Address. This document
refers to that deployment model as Quasi-Anycast. The term describes
an operational pattern, not a new anycast routing semantic, and is
consistent with the service and routing terminology of [RFC4786] and
[RFC7094].
Claise, et al. Expires 4 January 2027 [Page 20]
Internet-Draft Telemetry over QUIC July 2026
In such deployments, the server SHOULD advertise a Preferred Address
only when the backend can accept the migrated connection state and
the client can successfully validate the new path. The client MUST
validate the new path before sending non-probing packets to it.
Operators SHOULD use this pattern when anycast is desirable for
discovery or nearest-ingress selection, but a long-lived telemetry
session benefits from stable backend affinity. ## Manual Certificate
Lifecycle
In smaller deployments, automated certificate lifecycle management
may not be available, and certificate provisioning, renewal, and
replacement are performed manually. A single Network Node may use
multiple certificates for different applications or protocol stacks.
Since certificates are commonly managed and activated independently
by each consuming application, certificate rollover may occur at
different points in time. During such transition periods, some
applications may continue to rely on legacy configurations, including
unsecured UDP-based transport, until certificate updates have been
completed consistently across all consumers. Implementations SHOULD
minimize the duration of such transition periods and SHOULD provide
mechanisms to coordinate certificate replacement across all affected
applications.
9. Security Considerations
The security properties of all telemetry data transported using this
framework are determined by the QUIC connection's TLS 1.3 handshake.
The considerations in [RFC9000], [RFC9001], and [RFC9221] apply.
Mutual certificate authentication SHOULD be used for all deployments.
A collector that does not authenticate the Network Node certificate
cannot trust the origin of telemetry records. A Network Node that
does not authenticate the collector certificate may export sensitive
operational data to an adversary.
Certificate revocation MUST be checked. OCSP stapling is RECOMMENDED
as the revocation mechanism because it allows the Network Node to
provide proof of validity at connection establishment without
requiring the collector to query an OCSP responder separately.
DATAGRAM frames, like all QUIC packet payloads, are AEAD-protected.
An on-path observer cannot read or modify DATAGRAM frame contents.
The QUIC invariants (Connection IDs, packet type bits) are observable
but do not reveal telemetry content.
0-RTT connection resumption ([RFC9001] Section 4.6.1) allows early
data, including telemetry DATAGRAM frames, to be sent before the
handshake completes. 0-RTT data does not provide forward secrecy and
Claise, et al. Expires 4 January 2027 [Page 21]
Internet-Draft Telemetry over QUIC July 2026
is susceptible to replay attacks. For telemetry protocols, replay of
a periodic sample record is generally harmless but implementations
SHOULD document their 0-RTT behavior and MAY disable 0-RTT for
security-sensitive deployments.
The replacement of RADIUS Accounting's MD5-based message
authenticator (Section 7.4) with QUIC's AEAD protection is a security
improvement. Implementations should ensure that existing RADIUS
processing pipelines do not rely on the MD5 Message-Authenticator for
any purpose other than transport-level authentication.
Using a single certificate across multiple protocols or applications
increases the impact of a certificate compromise. An attacker
obtaining the corresponding private key can potentially impersonate
the Network Node towards all relying parties that trust this
certificate, instead of only affecting a single protocol or
application. Conversely, using separate certificates can limit the
scope of a compromise, but increases the operational effort required
for certificate lifecycle management and incident response. A
Network Node may communicate with multiple client systems, such as
telemetry collectors, management systems, and application-specific
consumers. When a compromised certificate is replaced, all affected
relying parties need to update their trust configuration in a
coordinated manner to maintain authenticated communication. This
coordination is particularly relevant when migrating unreliable UDP-
based communication to QUIC DATAGRAM. [RFC9221] specifies that
DATAGRAM frames do not provide explicit flow control and may be
dropped by the receiver if they cannot be processed. It also
specifies that DATAGRAM frames are subject to QUIC congestion control
and may be delayed or dropped when congestion control does not allow
immediate transmission. Consequently, applications using QUIC
DATAGRAM cannot assume that certificate-related transition messages,
telemetry data, or other operational signals carried over DATAGRAM
frames are reliably delivered. Therefore, certificate rollover and
compromise recovery procedures SHOULD NOT rely solely on unreliable
datagram delivery for critical state synchronization.
Implementations SHOULD provide a reliable and authenticated
mechanism, for example using QUIC streams or another reliable
management channel, to coordinate certificate replacement, revocation
handling, and trust-store updates across affected Network Nodes and
client systems. While certificate renewal due to expiration is a
routine operational process, emergency certificate replacement
following a compromise typically requires substantially greater
coordination and operational effort. These considerations SHOULD be
taken into account when selecting between per-Network Node and per-
protocol certificate deployment models.
Claise, et al. Expires 4 January 2027 [Page 22]
Internet-Draft Telemetry over QUIC July 2026
10. IANA Considerations
10.1. ALPN Protocol Identifiers
This document requests that IANA register the following Application-
Layer Protocol Negotiation (ALPN) protocol identifiers in the "TLS
Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry:
+====================================+=================+===========+
| Identification Sequence | Protocol | Reference |
+====================================+=================+===========+
| 0x69 0x70 0x66 0x78 0x71 ("ipfxq") | IPFIX over QUIC | This |
| | | document |
+------------------------------------+-----------------+-----------+
| 0x73 0x79 0x73 0x71 ("sysq") | Syslog over | This |
| | QUIC | document |
+------------------------------------+-----------------+-----------+
| 0x79 0x70 0x71 ("ypq") | YANG-Push over | This |
| | QUIC | document |
+------------------------------------+-----------------+-----------+
| 0x72 0x61 0x64 0x71 ("radq") | RADIUS over | This |
| | QUIC | document |
+------------------------------------+-----------------+-----------+
| 0x74 0x65 0x6c 0x71 ("telq") | Generic | This |
| | Telemetry | document |
+------------------------------------+-----------------+-----------+
Table 2: Requested ALPN Identifiers
10.2. Telemetry Type Registry
This document requests that IANA create a new registry "QUIC
Telemetry Type Values" under the "QUIC" registry group with the
following initial values:
Claise, et al. Expires 4 January 2027 [Page 23]
Internet-Draft Telemetry over QUIC July 2026
+========+=====================+==============================+
| Value | Protocol | Reference |
+========+=====================+==============================+
| 0x0001 | IPFIX | [RFC7011] |
+--------+---------------------+------------------------------+
| 0x0002 | Syslog | [RFC5424] |
+--------+---------------------+------------------------------+
| 0x0003 | YANG-Push UDP-Notif | [I-D.ietf-netconf-udp-notif] |
+--------+---------------------+------------------------------+
| 0x0004 | RADIUS Accounting | [RFC2866] |
+--------+---------------------+------------------------------+
| 0xFFFF | Reserved | This document |
+--------+---------------------+------------------------------+
Table 3: QUIC Telemetry Type Values
New values are assigned by Expert Review.
10.3. UDP Port Numbers
This document does not request new UDP port numbers. QUIC-based
Network Telemetry operates over existing QUIC port allocations.
11. References
11.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>.
[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>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
Claise, et al. Expires 4 January 2027 [Page 24]
Internet-Draft Telemetry over QUIC July 2026
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", RFC 9221,
DOI 10.17487/RFC9221, March 2022,
<https://www.rfc-editor.org/rfc/rfc9221>.
11.2. Informative References
[I-D.ietf-netconf-distributed-notif]
Zhou, T., Zheng, G., Voit, E., Graf, T., and P. Francois,
"Subscription to Notifications in a Distributed
Architecture", Work in Progress, Internet-Draft, draft-
ietf-netconf-distributed-notif-19, 13 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
distributed-notif-19>.
[I-D.ietf-netconf-over-quic]
Dai, J., Yu, S., Cheng, W., Blanchet, M., and P.
Andersson, "NETCONF over QUIC", Work in Progress,
Internet-Draft, draft-ietf-netconf-over-quic-09, 27 June
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
netconf-over-quic-09>.
[I-D.ietf-netconf-udp-notif]
Feng, A. H., Francois, P., Zhou, T., Graf, T., and P.
Lucente, "UDP-based Transport for Configured
Subscriptions", Work in Progress, Internet-Draft, draft-
ietf-netconf-udp-notif-25, 28 January 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
udp-notif-25>.
[I-D.ietf-radext-radiusdtls-bis]
Rieckers, J., Cullen, M., and S. Winter, "RadSec: RADIUS
over Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", Work in Progress, Internet-Draft,
draft-ietf-radext-radiusdtls-bis-16, 5 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-
radiusdtls-bis-16>.
[I-D.liu-grow-bmp-over-quic]
Liu, Y., Lin, C., Graf, T., Lucente, P., and M. K.
Srivastava, "Using BMP over QUIC connection", Work in
Progress, Internet-Draft, draft-liu-grow-bmp-over-quic-06,
2 March 2026, <https://datatracker.ietf.org/doc/html/
draft-liu-grow-bmp-over-quic-06>.
[I-D.liu-sidrops-rpki-rtr-over-quic]
Yue, Lin, C., Roy, J., Ma, D., and Y. Liu, "RPKI to Router
Protocol over QUIC", Work in Progress, Internet-Draft,
Claise, et al. Expires 4 January 2027 [Page 25]
Internet-Draft Telemetry over QUIC July 2026
draft-liu-sidrops-rpki-rtr-over-quic-03, 27 February 2026,
<https://datatracker.ietf.org/doc/html/draft-liu-sidrops-
rpki-rtr-over-quic-03>.
[I-D.llg-opsawg-ipfix-over-quic]
Liu, Y., Lin, C., Graf, T., and B. Claise, "IPFIX Protocol
over QUIC", Work in Progress, Internet-Draft, draft-llg-
opsawg-ipfix-over-quic-03, 23 June 2026,
<https://datatracker.ietf.org/doc/html/draft-llg-opsawg-
ipfix-over-quic-03>.
[I-D.retana-idr-bgp-quic]
Retana, A., Qu, Y., Haas, J., Chen, S., and J. Tantsura,
"BGP over QUIC", Work in Progress, Internet-Draft, draft-
retana-idr-bgp-quic-09, 24 June 2026,
<https://datatracker.ietf.org/doc/html/draft-retana-idr-
bgp-quic-09>.
[I-D.yang-pce-pcep-over-quic]
Yang, F., Lin, C., Sidor, S., and T. Han, "PCEP over
QUIC", Work in Progress, Internet-Draft, draft-yang-pce-
pcep-over-quic-04, 25 April 2026,
<https://datatracker.ietf.org/doc/html/draft-yang-pce-
pcep-over-quic-04>.
[I-D.yl-radext-quic-transport]
Yue, Lin, C., and F. Yang, "RADIUS over QUIC", Work in
Progress, Internet-Draft, draft-yl-radext-quic-transport-
04, 12 May 2026, <https://datatracker.ietf.org/doc/html/
draft-yl-radext-quic-transport-04>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/rfc/rfc2865>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/rfc/rfc2866>.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539,
DOI 10.17487/RFC3539, June 2003,
<https://www.rfc-editor.org/rfc/rfc3539>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/rfc/rfc4786>.
Claise, et al. Expires 4 January 2027 [Page 26]
Internet-Draft Telemetry over QUIC July 2026
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<https://www.rfc-editor.org/rfc/rfc5424>.
[RFC5425] Miao, F., Ed., Ma, Y., Ed., and J. Salowey, Ed.,
"Transport Layer Security (TLS) Transport Mapping for
Syslog", RFC 5425, DOI 10.17487/RFC5425, March 2009,
<https://www.rfc-editor.org/rfc/rfc5425>.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, DOI 10.17487/RFC5426, March 2009,
<https://www.rfc-editor.org/rfc/rfc5426>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, DOI 10.17487/RFC5997, August 2010,
<https://www.rfc-editor.org/rfc/rfc5997>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.
[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>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014,
<https://www.rfc-editor.org/rfc/rfc7094>.
[RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/rfc/rfc7854>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/rfc/rfc8639>.
Claise, et al. Expires 4 January 2027 [Page 27]
Internet-Draft Telemetry over QUIC July 2026
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/rfc/rfc8799>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9196] Lengyel, B., Clemm, A., and B. Claise, "YANG Modules
Describing Capabilities for Systems and Datastore Update
Notifications", RFC 9196, DOI 10.17487/RFC9196, February
2022, <https://www.rfc-editor.org/rfc/rfc9196>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/rfc/rfc9232>.
[RFC9308] Kühlewind, M. and B. Trammell, "Applicability of the QUIC
Transport Protocol", RFC 9308, DOI 10.17487/RFC9308,
September 2022, <https://www.rfc-editor.org/rfc/rfc9308>.
[RFC9765] DeKok, A., "RADIUS/1.1: Leveraging Application-Layer
Protocol Negotiation (ALPN) to Remove MD5", RFC 9765,
DOI 10.17487/RFC9765, April 2025,
<https://www.rfc-editor.org/rfc/rfc9765>.
Appendix A. Acknowledgements
The authors would like to thank the authors and contributors of the
related drafts referenced in this document, particularly those
working on IPFIX over QUIC, NETCONF over QUIC, and UDP-Notif, for
their foundational work that motivates this framework document.
The authors also thank the QUIC Working Group for the development of
RFC 9221, without which this framework would not be possible.
Appendix B. Open Issues
The following issues are identified for future resolution:
Claise, et al. Expires 4 January 2027 [Page 28]
Internet-Draft Telemetry over QUIC July 2026
1. Should this document define normative per-protocol bindings, or
remain informational and defer normative content to individual
WG-chartered documents?
2. The Telemetry Type header format (Section 5.3) should be
discussed with the relevant WGs to avoid conflicts with existing
shim headers (e.g., the UDP-Notif shim, IPFIX Message Header).
3. The RADIUS Accounting mapping (Section 7.4) interacts with work
in RADEXT WG. Coordination with [I-D.yl-radext-quic-transport]
is needed to determine whether DATAGRAM and STREAM profiles
should be in separate documents.
4. YANG module augmentations for advertising QUIC telemetry
transport capability per [RFC9196] are not defined in this
version and should be added in a future revision.
Authors' Addresses
Benoît Claise
Everything OPS & Arrcus
Belgium
Email: benoit@everything-ops.net
Thomas Graf
Swisscom
Email: thomas.graf@swisscom.com
Paolo Lucente
NTT
Email: paolo@ntt.net
Holger Keller
Deutsche Telekom
Email: holger.keller@telekom.de
Alan DeKok
InkBridge Networks
Email: alan.dekok@inkbridge.io
Claise, et al. Expires 4 January 2027 [Page 29]