Internet-Draft Export of QUIC Information in IPFIX September 2026
Lin, et al. Expires 1 April 2027 [Page]
Workgroup:
Operations and Management Area Working Group
Internet-Draft:
draft-ietf-opsawg-ipfix-quic-header-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Lin
New H3C Technologies
Y. Liu
China Mobile
Y. Liu
ZTE
X. Li
China Telecom
A. Dogra
Cisco Systems

Export of QUIC Information in IP Flow Information Export (IPFIX)

Abstract

This document defines IP Flow Information Export (IPFIX) Information Elements and export profiles for QUIC packet, header, frame, aggregate, and connection observations. It distinguishes wire-visible information from values requiring version-specific parsing, packet-protection processing, or endpoint state, and reports observation provenance, processing outcome, and export completeness.

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 1 April 2027.

▲

Table of Contents

1. Introduction

QUIC packets are carried in UDP datagrams and exchanged for communication of QUIC endpoints [RFC9000]. A QUIC packet normally consists of a QUIC header and a QUIC payload.

The QUIC header is divided into the Long Header and the Short Header. While some properties (e.g., header form bit) are version-independent per [RFC8999], the overall structure, especially the interpretation of packet type bits, is version-specific. The Long Header contains an 8-bit first octet, a 32-bit QUIC Version, a variable-length Destination Connection ID, and a variable-length Source Connection ID. In a Version Negotiation packet, only the Header Form bit of the first octet has invariant meaning; the other seven bits are arbitrary. In QUIC versions 1 and 2 packets other than Version Negotiation, the first octet contains the Header Form bit, Fixed Bit, packet-type bits, and type-specific bits, and fields following the Connection IDs vary by packet type, for example the Token in Initial and Retry packets [RFC9000]. For QUIC versions 1 and 2, Version Negotiation, Initial, 0-RTT, Handshake, and Retry packets use the Long Header, while 1-RTT packets use the Short Header. A sender can continue to send Long Header packets while the corresponding encryption levels remain in use; availability of 1-RTT keys does not by itself imply that all Long Header traffic has stopped. The Short Header includes an 8-bit first octet, a variable-length Destination Connection ID and a Packet Number.

The QUIC payload MAY contain a sequence of Frames which begin with a Frame Type. In the generic Frame Layout, the Frame Type is followed by additional type-dependent fields. A Stream provides a lightweight, ordered byte-stream abstraction to an application. A QUIC connection can carry many concurrent Streams, so the Stream ID carried by a Frame is important: it identifies the Stream whose data the Frame carries (e.g., a STREAM frame), or the Stream that the Frame affects (e.g., RESET_STREAM, STOP_SENDING, or MAX_STREAM_DATA frame).

QUIC packets provide varying levels of cryptographic protection depending on their type [RFC9001]. Version Negotiation packets have no cryptographic protection. Retry packets are neither encrypted nor header-protected, but carry a version-specific Retry Integrity Tag. Initial packets use packet-protection keys that are publicly derivable from the Destination Connection ID of the applicable client Initial packet. Handshake, 0-RTT, and 1-RTT packets use keys derived from TLS. Header fields that remain visible on the wire can nevertheless be authenticated as AEAD associated data; this document therefore distinguishes fields that are encrypted, fields that are masked by header protection, and fields that are wire-visible.

This document specifies several new IPFIX Information Elements (IEs) within the "IPFIX Information Elements" registry [RFC7012] for purposes of getting QUIC related information. These IEs are used to export the main fields of the QUIC header and payload in a QUIC packet. Some values are normally available only to QUIC endpoints or authorized devices holding the applicable traffic keys. For supported QUIC versions, an observer with the required connection context can also derive Initial keys and process Initial packets; successful Initial processing is not peer authentication.

2. Terminology

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

This document makes use of the terms defined in [RFC7011] and [RFC9000].

The following terms are used as defined in [RFC7011]:

The following terms are used as defined in [RFC9000]:

The term "flow" in this document aligns with the IPFIX definition, not the QUIC definition.

3. Information Model and Export Profiles

QUIC introduces multiple layers of encapsulation that do not map one-to-one to traditional IPFIX flow records. A UDP datagram can contain multiple QUIC packets (via coalescing), a QUIC packet can contain multiple frames, and frames can belong to different streams. This section defines explicit export profiles to clarify the observation hierarchy and avoid semantic ambiguity.

3.1. Observation Hierarchy

The following hierarchy describes the relationship between observed QUIC entities:

  • IP Flow: A sequence of IP packets sharing common properties (e.g., 5-tuple). An IP flow may carry multiple UDP datagrams.

  • UDP Datagram: A single UDP payload that may contain one or more QUIC packets (coalesced).

  • QUIC Packet: A QUIC-layer unit with its own header and payload. Multiple QUIC packets can be coalesced into one UDP datagram. Initial, 0-RTT, Handshake, and 1-RTT packets belong to a packet number space. Version Negotiation and Retry packets do not carry packet numbers, and a confirmed Stateless Reset has no semantic packet number.

  • QUIC Frame: A structured protocol element carried in a QUIC packet payload. A QUIC packet can contain multiple frames of different types (e.g., STREAM, ACK, CRYPTO).

  • QUIC Stream: An ordered byte stream multiplexed within a QUIC connection. Multiple streams can be interleaved via STREAM frames within a single QUIC packet.

In the unsampled variants, each top-level Data Record defined by the export profiles in Section 3.3 represents exactly one entity of the hierarchy above: one IP/UDP datagram (Network-Wire Observation Profile), one QUIC packet (Endpoint Packet Observation Profile), one IP Flow or aggregation window (Flow-Aggregate Profile), or one QUIC connection (Connection-State Profile). When PSAMP packet selection is active, the sampled Network-Wire and Endpoint variants instead emit exactly one Extended Packet Report for each selected outer IP packet. Ordered child records within that report preserve the one-record-per-inner-QUIC-packet semantics and identify each child with quicPacketOffset.

RFC 7012 specifies that a non-key Information Element whose value varies within a Flow is, by default, taken from the first observed packet of the Flow (Section 5 of [RFC7012]). For packet-derived QUIC IEs this default is insufficient, because "the first observed packet" does not identify which QUIC packet supplies the value when the datagram carries multiple coalesced QUIC packets, or which frame occurrence supplies the value when a QUIC packet contains multiple frames or references multiple streams. This document therefore defines, per profile, the observation unit of each Data Record and the explicit ordinal or offset fields that identify each occurrence: quicPacketOffset (TBD15) locates an inner QUIC packet within its UDP payload, quicFrameOffset (TBD13) locates a frame within its packet payload, and sub-templates are ordered by these offsets. Where a scalar IE with per-observation cardinality would otherwise be reported at a coarser granularity, the profile either reports every occurrence (as list entries) or excludes the IE from that profile; "first observed value" is used only where a profile explicitly states it (e.g., the Flow-Aggregate Profile).

Existing IPFIX packet counters (for example, packetDeltaCount and droppedPacketDeltaCount) describe the outer IP/Flow packet layer and cannot implicitly count coalesced inner QUIC packets. Likewise, forwardingStatus (89) [RFC7270] describes forwarding disposition at that outer layer. If counting at the QUIC packet layer is required, exporters MUST use the dedicated quicPacketDeltaCount Information Element (TBD16, defined in Section 4) rather than packetDeltaCount. Discard-related monitoring (e.g., why QUIC-carrying packets are forwarded or dropped) aligns with the broader discard monitoring framework [discardmodel] and its associated IPFIX IEs [ipfix-discard-class-ie].

3.2. Detection, Provenance, and Validation

As noted in Section 3.1 of [RFC9312], there is no general passive method to distinguish QUIC from arbitrary UDP traffic, and the QUIC fixed bit is subject to greasing [RFC9287]. A UDP datagram that looks like QUIC may not be QUIC, and an exporter that relies on a fixed-bit or port heuristic MUST NOT treat that classification as authoritative.

Observation provenance and processing outcome are independent. Each packet observation in the Network-Wire and Endpoint Packet profiles therefore carries both quicObservationSource (TBD17) and quicProcessingStatus (TBD18). quicObservationSource states whether the values came from passive wire observation, endpoint protocol state, or an authorized cooperating device. quicProcessingStatus states what processing was completed or why it stopped. quicExportFlags (TBD24) independently reports whether otherwise available information was suppressed by configured export policy or truncated by a local resource or size limit. The processing result is not overwritten by an export-completeness condition. The status values are not an ordered confidence scale. In particular, endpoint-originated Version Negotiation and Retry observations do not require decryption, and a passive observer can successfully process a supported-version Initial packet when it has the required context. The Flow-Aggregate and Connection-State profiles carry the same two IEs to identify the particular admission evidence that first caused the exporter to classify the flow or connection as QUIC.

A Data Record encoded by a Template contains a value for every Field Specifier in that Template [RFC7011]. Consequently, an exporter cannot omit one field from an individual record while continuing to use the same Template. A profile in this document handles a field that is absent or unavailable in one of two ways:

  • use another announced Template that does not contain the field; or

  • include quicFieldPresence (TBD21) in the record. When the bit assigned to an accompanying field is clear, the exporter encodes the canonical placeholder required by the fixed Template (zero for a numeric field, an empty value for an octetArray, or an empty list), and the collector MUST ignore that placeholder. When the bit is set, the encoded value is semantically present; an empty octetArray can therefore represent a genuine zero-length QUIC field without being confused with absence.

quicPacketType uses its Unknown value when a type cannot be determined. Malformed, capture-truncated, unsupported-version, and authentication-failed observations use distinct quicProcessingStatus values; local suppression or truncation uses quicExportFlags. An exporter MUST NOT mark fields derived from an unsuccessful parse or failed packet-protection operation as present. Successful Initial packet protection processing under publicly derivable keys indicates that the packet is internally consistent under those keys; it is not peer authentication and does not provide integrity against an active on-path attacker.

Template IDs are dynamically scoped to the (Observation Domain ID, Exporting Process, Transport Session) tuple in which they were announced. Collectors MUST NOT infer record content, provenance, or validation result from a numeric Template ID. These properties are carried in-band by the IEs defined above and, for Destination Connection ID length context, by quicDestinationConnectionIdLengthSource (TBD19).

3.3. Export Profiles

This document defines the following export profiles. Each profile specifies its Flow Keys, granularity, sampling behavior, observation time, direction, and unavailable-field behavior, and provides an illustrative Template field layout and Data Record example. Where more than one encapsulation layer is reported (inner QUIC packets within a UDP datagram, frames within a QUIC packet), a subTemplateList [RFC6313] is used so that the hierarchy remains explicit. Except for fields whose first-observed aggregation is explicitly defined by the Flow-Aggregate Profile, per-packet scalar values are not flattened into fields of a record that covers several such objects. The Template IDs shown in the figures are examples only; actual Template IDs are dynamically assigned, and collectors MUST NOT infer the content or provenance of a record from its Template ID (see Section 3.2). The figures list fields and abstract data types, not byte-level Template encodings. An exporter MUST encode the actual Template Field Specifiers as required by [RFC7011]. In the illustrated profiles, octetArray, basicList, and subTemplateList fields use the variable-length Field Length 65535. A numeric Field Length, including any reduced-size encoding, MUST accommodate every value sent with that Template.

Except for the order of elements within an ordered structured-data list, the order of Information Elements in a Template is not significant. Exporters MAY add other Information Elements or export records using other Templates. A collector that supports a profile in this document MUST accept reordered fields, additional Information Elements, and unrelated Data Records.

Every ordinary Data Record in these profiles is scoped by the Observation Domain ID in the IPFIX Message Header. It is not repeated as observationDomainId (149) in an ordinary Data Template and is not a packet-derived Flow Key. The Connection-State Options Template uses observationDomainId as an Options Scope field, as explicitly shown. For purposes of flowId correlation, the Observation Domain ID is the Message Header value for an Endpoint Packet record and the explicit Options Scope value for a Connection-State record.

Every basicList and subTemplateList in these profiles that preserves wire order MUST use the ordered structured-data semantic defined by [RFC6313]. The field-presence and processing-status IEs are part of the record contract and are not inferred from the selected Template ID. quicExportFlags is zero when export is complete under the profile and carries independent bits when local policy suppresses otherwise available values or a local resource/size limit truncates export.

3.3.1. Network-Wire Observation Profile

This profile is intended for passive on-path observation. It reports wire-visible fields and packet boundaries; although an exporter can process supported-version Initial protection when it has the required context, this profile does not export packet numbers or frame contents.

Purpose:
Export wire-visible QUIC header fields for every QUIC packet that the exporter can successfully delimit within an observed IP/UDP datagram, for network-level traffic analysis, QUIC version and packet-type distribution, and Connection ID tracking.
Granularity:
One Data Record per IP/UDP datagram. Successfully delimited inner QUIC packets of a possibly coalesced datagram are reported as an ordered subTemplateList of inner QUIC-packet observations, each identified by its quicPacketOffset within the UDP payload. The parent record carries quicDatagramParseStatus (TBD22), so a collector can distinguish a complete parse from one that stopped at an unsupported version, malformed or capture-truncated data, or a local parser or processing-resource limit. For an unsupported nonzero version, the invariants in [RFC8999] do not expose the packet boundary after the Connection IDs. Unless the exporter has additional version-specific or out-of-band knowledge, it reports any preceding completely delimited packets and MAY report one terminal invariant-prefix observation at the offset where parsing stopped. It marks the datagram parse as partial and MUST NOT claim that later coalesced packets were absent. A Stateless Reset is identified from the entire UDP datagram, not from a candidate child-packet suffix. When the exporter confirms a Stateless Reset as specified in Section 10.3.1 of [RFC9000], the child list MUST contain exactly one observation: quicPacketOffset is zero, quicPacketLength is the UDP payload length, quicPacketType is 6, quicProcessingStatus is 14, and quicDatagramParseStatus is 1 (Complete). Any tentative parsing of apparent coalesced packets is superseded by that datagram-level result.
Flow Keys:
source address, destination address, protocolIdentifier, udpSourcePort, udpDestinationPort. An IPv4 Template uses sourceIPv4Address and destinationIPv4Address; an IPv6 Template uses sourceIPv6Address and destinationIPv6Address. The two address-family variants use separately assigned Template IDs. The Connection IDs are NOT Flow Keys. They are not a stable property of a connection: the Destination Connection ID that a peer uses may change with Connection ID rotation or connection migration. In addition, a passive observer cannot rely on the sender having honored the coalescing rules, so the inner packets of a single datagram cannot be assumed to belong to the same connection. The Connection IDs are therefore reported per inner packet.
Sampling Behavior:
One record per observed datagram (1:1). The base parent Template MUST be used only when packet selection is not active. If packet selection is active and this profile is emitted, the exporter MUST use a distinct PSAMP [RFC5476] Extended Packet Report Template that adds selectionSequenceId (301) while retaining the ordered QUIC child-list structure below. For every selectionSequenceId in use, the exporter MUST also export the applicable Selection Sequence, Selector, Selection Sequence Statistics, and Accuracy Report Interpretations required by Section 6.5 of [RFC5476]. Per Section 6.4 of [RFC5476], one Packet Report is exported for each selected packet in each Selection Sequence; a Packet Report includes selectionSequenceId and SHOULD include an observation-time Information Element. This profile's sampled Template applies only to a selected unfragmented IP packet carrying a complete UDP datagram admitted to the QUIC profile. If the Selection Sequence can select other protocols or IP fragments, the exporter MUST use another applicable Packet Report Template for those selected packets. selectionSequenceId identifies the Observation Point and the selector sequence, not an individual packet occurrence: when a selected packet contains a complete UDP datagram with multiple coalesced QUIC packets, this profile exports the decoded QUIC packets as ordered child records within the Extended Packet Report (each child record carrying its quicPacketOffset), rather than as separate top-level Data Records. Emitting each inner QUIC packet as a separate top-level Data Record does not conform to this profile. A separately specified profile using that model would need an explicitly scoped parent-observation identifier together with quicPacketOffset; selectionSequenceId or observationPointId alone cannot identify the containing datagram because several selected datagrams can share both values.
Observation Point and Fragmentation:
This profile MUST be emitted only for a UDP datagram carried in one unfragmented IP packet. Individual IP fragments and reassembled IP datagrams are outside this profile because its timestamp and standard packet/octet counters describe one observed outer IP packet. A separate reassembly profile would need to define its logical Observation Point, timestamp, and counter semantics. Fragmentation alone is neither capture truncation nor malformed input. quicDatagramParseStatus 3 applies only when missing captured octets prevent complete packet-boundary enumeration. If a capture-truncated packet still has a known complete boundary, the parent uses quicDatagramParseStatus 1 and that child uses quicProcessingStatus 9. quicDatagramParseStatus 4 applies only when a structural violation prevents complete packet-boundary enumeration. If a malformed packet still has a known complete boundary, the parent uses quicDatagramParseStatus 1 and that child uses quicProcessingStatus 8.
Observation Time:
observationTimeMilliseconds (323) of the outer IP packet; the inner observations do not carry separate timestamps.
Direction:
flowDirection (61) of the outer IP packet.
Unavailable Fields:
quicPacketNumber, quicFrameType, and quicStreamId are not carried in this profile. quicPacketType is set to 0 (Unknown) when the exporter cannot apply a supported version's packet-type rules. quicVersion is present only for a Long Header packet; for a Short Header packet its quicFieldPresence bit is clear and the fixed-field placeholder is zero. quicSupportedVersion is present only for Version Negotiation and is encoded as specified in Section 6.1.4. The Connection ID and Token presence bits distinguish a genuine zero-length field from a field that is absent or unavailable. A successfully delimited packet has its Packet Length bit set unless the otherwise available value is omitted for an export condition reported by quicExportFlags. For the partial terminal observation permitted when an unsupported version prevents boundary determination, that bit is clear and quicPacketLength is an ignored zero placeholder. Each inner observation carries quicObservationSource, quicProcessingStatus, and quicExportFlags. The parent quicExportFlags reports local omission from the child list; it does not change quicDatagramParseStatus when the UDP payload was parsed completely. A local parser or processing-resource limit that prevents complete packet-boundary enumeration instead produces quicDatagramParseStatus 5. If the Destination Connection ID length of a Short Header packet cannot be determined, the Destination Connection ID presence bit is clear and quicDestinationConnectionIdLengthSource is 4 (Unknown). A successfully processed supported-version Initial packet can use the passive-source and Initial-processed status combination; this does not authenticate its sender. A confirmed Stateless Reset has no semantic Version, Destination Connection ID, Source Connection ID, or Initial/Retry Token field; their presence bits are clear, their fixed-field placeholders are ignored, and quicDestinationConnectionIdLengthSource is 0 (Not applicable). Bytes that merely occupy the apparent Short Header Destination Connection ID position are unpredictable reset bytes and MUST NOT be exported as quicDestinationConnectionId.
Illustrative Field Layout / Data Record:
Illustrative field layout (example Template ID 258):
  sourceIPv4Address (8)              ipv4Address
  destinationIPv4Address (12)        ipv4Address
  protocolIdentifier (4)             unsigned8
  udpSourcePort (180)                unsigned16
  udpDestinationPort (181)           unsigned16
  ipClassOfService (5)               unsigned8
  octetDeltaCount (1)                unsigned64
  packetDeltaCount (2)               unsigned64   (set to 1)
  observationTimeMilliseconds (323)  dateTimeMilliseconds
  flowDirection (61)                 unsigned8
  quicDatagramParseStatus (TBD22)    unsigned8
  quicExportFlags (TBD24)            unsigned8
  subTemplateList (292)              subTemplateList

  Illustrative child layout (example Sub-Template ID 259):
    quicPacketOffset (TBD15)           unsigned32
    quicPacketLength (TBD23)           unsigned32
    quicObservationSource (TBD17)      unsigned8
    quicProcessingStatus (TBD18)       unsigned8
    quicExportFlags (TBD24)            unsigned8
    quicFieldPresence (TBD21)          unsigned32
    quicFirstOctet (TBD1)              unsigned8
    quicPacketType (TBD3)              unsigned8
    quicVersion (TBD2)                 unsigned32
    quicSupportedVersion (TBD4)        basicList
    quicDestinationConnectionIdLengthSource (TBD19) unsigned8
    quicDestinationConnectionId (TBD6) octetArray
    quicSourceConnectionId (TBD7)      octetArray
    quicToken (TBD20)                  octetArray

Data Record (Template ID 258), two coalesced QUIC packets:
  sourceIPv4Address            203.0.113.7
  destinationIPv4Address       192.0.2.1
  protocolIdentifier           17
  udpSourcePort                443
  udpDestinationPort           53924
  ipClassOfService             0
  octetDeltaCount              1284
  packetDeltaCount             1
  observationTimeMilliseconds  1726200000100
  flowDirection                0 (ingress)
  quicDatagramParseStatus      1 (Complete)
  quicExportFlags              0 (Complete)
  subTemplateList, 2 entries of Sub-Template 259:
    entry 0: quicPacketOffset 0, quicPacketLength 1180,
             quicObservationSource 1 (Passive wire),
             quicProcessingStatus 4 (Initial processed),
             quicExportFlags 0 (Complete),
             quicFieldPresence 0x0000009D
               (Version, Destination CID, Source CID, Token,
                Packet Length),
             quicFirstOctet 0xC3, quicPacketType 2 (Initial),
             quicVersion 0x00000001, quicSupportedVersion (empty),
             quicDestinationConnectionIdLengthSource 1 (explicit
             length field),
             quicDestinationConnectionId 0x0001020304050607,
             quicSourceConnectionId 0x2021222324252627,
             quicToken (empty, zero-length Initial Token)
    entry 1: quicPacketOffset 1180, quicPacketLength 76,
             quicObservationSource 1 (Passive wire),
             quicProcessingStatus 3
               (Supported-version packet structure parsed),
             quicExportFlags 0 (Complete),
             quicFieldPresence 0x00000084
               (Destination CID, Packet Length),
             quicFirstOctet 0x43, quicPacketType 0 (Unknown),
             quicVersion 0 (placeholder),
             quicSupportedVersion (empty),
             quicDestinationConnectionIdLengthSource 2 (learned
             connection context),
             quicDestinationConnectionId 0x0001020304050607,
             quicSourceConnectionId (empty placeholder),
             quicToken (empty placeholder)
Example arithmetic:
The two QUIC packet lengths total 1256 octets. With an assumed 8-octet UDP header and a 20-octet IPv4 header without options, the outer octetDeltaCount is therefore 1284.

3.3.2. Endpoint Packet Observation Profile

This profile is intended for QUIC endpoints, authorized devices that legitimately possess the relevant traffic keys, and passive observers that successfully process supported-version Initial packets with the required context. It exports fields available after successful packet processing or directly from endpoint protocol state.

Purpose:
Export per-QUIC-packet observations for Initial, 0-RTT, Handshake, and 1-RTT packets, including protected fields (packet number, frame types, stream IDs), for connection-level analysis such as packet sequencing and stream behavior. Packet numbers alone do not provide reliable loss measurement, since passive observation cannot determine whether all sent packets were received (see Section 4.1 of [RFC9312]). Endpoint-derived ACK or loss events and counters MAY be exported separately, with explicit completeness and sampling semantics; such export is out of scope for this document.
Base Granularity:
In the unsampled base variant, one top-level Data Record is emitted per packet that carries a packet number, with an ordered subTemplateList of frame-observation subrecords, one per completely parsed frame carried by that packet. If an unsupported frame format or local processing limit stops enumeration, the list contains the completely parsed prefix and quicProcessingStatus is respectively 12 or 13. Each frame observation carries its own quicFrameType and, where the frame type carries one, its quicStreamId. The frame subrecords are exported in the order the frames appear in the QUIC packet payload; quicFrameOffset indicates the byte position of each frame and thereby the frame order.
QUIC-Packet Record Keys:
flowId (148), quicSenderDirection, quicPacketNumberSpace, and the full quicPacketNumber. The Observation Domain ID in the IPFIX Message Header additionally scopes the record. These keys apply to the top-level packet record in the base variant and to each QUIC-packet child record in the sampled variant. Version Negotiation and Retry packets, and a confirmed Stateless Reset, are outside this profile because they have no semantic packet number. A packet number is unique within a (connection, direction, packet number space) tuple, so it is a natural key at this granularity; flowId provides the registered correlation identifier for the QUIC connection observation. For this profile, the exporter assigns one flowId that is unique within the Observation Domain and keeps it unchanged for the lifetime of that connection observation, including across path migration and IPFIX Transport Session changes.
Sampling Behavior:
The base Template is 1:1 (one record per eligible QUIC packet) and MUST be used only when packet selection is not active. PSAMP selects outer IP packets, not individual coalesced QUIC packets. If packet selection is active, the exporter MUST use a distinct Extended Packet Report Template with one parent Data Record for each selected unfragmented outer IP packet that carries a complete UDP datagram admitted to this QUIC profile, as required by Section 6.4 of [RFC5476]. The parent carries selectionSequenceId (301), the outer address and UDP fields, observationTimeMilliseconds, quicDatagramParseStatus, quicExportFlags, and an ordered subTemplateList. That list contains one child record for every eligible packet-number-bearing QUIC packet in the selected UDP datagram, in wire order. Each child adds quicPacketOffset to the fields of the base Endpoint Packet Template; the timestamp is inherited from the parent. A selected qualifying UDP packet with no eligible Endpoint child still produces its required Packet Report with an empty child list. If the Selection Sequence can select other protocols or IP fragments, the exporter MUST satisfy the one-report-per-selected-packet requirement of Section 6.4 of [RFC5476] for those packets using another applicable Packet Report Template. A fragmented outer IP packet is outside this sampled variant because one selected fragment does not represent a complete UDP datagram. For every selectionSequenceId in use, the exporter MUST export the applicable Selection Sequence, Selector, Selection Sequence Statistics, and Accuracy Report Interpretations required by Section 6.5 of [RFC5476]. Selection probabilities and accuracy describe the outer IP-packet population; they MUST NOT be presented as direct selection probabilities for inner QUIC packets.
Illustrative Sampled Layout:
Illustrative sampled parent (example Template ID 265):
  selectionSequenceId (301)          unsigned64
  sourceIPv4Address (8)              ipv4Address
  destinationIPv4Address (12)        ipv4Address
  protocolIdentifier (4)             unsigned8
  udpSourcePort (180)                unsigned16
  udpDestinationPort (181)           unsigned16
  observationTimeMilliseconds (323)  dateTimeMilliseconds
  quicDatagramParseStatus (TBD22)    unsigned8
  quicExportFlags (TBD24)            unsigned8
  subTemplateList (292)              subTemplateList

  Illustrative sampled QUIC-packet child (example Sub-Template
  ID 266):
    quicPacketOffset (TBD15)           unsigned32
    flowId (148)                       unsigned64
    quicSenderDirection (TBD11)        unsigned8
    quicPacketNumberSpace (TBD12)      unsigned8
    quicPacketNumber (TBD8)            unsigned64
    quicObservationSource (TBD17)      unsigned8
    quicProcessingStatus (TBD18)       unsigned8
    quicExportFlags (TBD24)            unsigned8
    quicFieldPresence (TBD21)          unsigned32
    quicFirstOctet (TBD1)              unsigned8
    quicPacketType (TBD3)              unsigned8
    quicVersion (TBD2)                 unsigned32
    quicDestinationConnectionId (TBD6) octetArray
    quicSourceConnectionId (TBD7)      octetArray
    quicToken (TBD20)                  octetArray
    quicPacketLength (TBD23)           unsigned32
    subTemplateList (292)              subTemplateList (frames)
Observation Time:
observationTimeMilliseconds (323) per QUIC packet in the base variant; in the sampled variant, all QUIC-packet children inherit the timestamp of their enclosing selected outer IP-packet report.
Direction:
quicSenderDirection (TBD11): 0 = client-to-server, 1 = server-to-client.
Unavailable Fields:
quicPacketNumberSpace and quicPacketNumber are always present because this profile contains only packet-number-bearing types. The quicFieldPresence bitmap states whether quicVersion, either Connection ID, quicToken, quicPacketLength, and a frame's quicStreamId are semantically present. A Short Header packet therefore carries a zero placeholder for quicVersion and an empty placeholder for quicSourceConnectionId, with both presence bits clear. A frame that does not carry a Stream ID uses a zero placeholder with the Stream ID presence bit clear; Stream ID zero on a frame that carries a Stream ID has the bit set. Packet-protection failure cannot supply the mandatory packet number and therefore MUST NOT be encoded with this Endpoint Packet Template. It can be reported with the Network-Wire profile or with a separately announced failure Template that omits unavailable protected fields and carries quicProcessingStatus. If plaintext is available but an unsupported frame type or frame format prevents the exporter from determining the next frame boundary, the exporter emits only the preceding completely parsed frame records and sets quicProcessingStatus to 12. A local parser or processing-resource limit that stops frame enumeration similarly uses status 13. The exporter MUST NOT classify the packet as malformed solely because its local decoder does not support that frame or exhausts a local processing limit. If otherwise available optional fields or frame child records are suppressed or truncated during export, quicExportFlags reports that independently of the processing result. In the sampled variant, the parent quicDatagramParseStatus reports whether the exporter completely enumerated packet boundaries in the selected UDP datagram, and the parent quicExportFlags reports local omission from the QUIC-packet child list. A child status and flags continue to describe only that child packet and its nested frame list.
Illustrative Field Layout / Data Record:
Illustrative field layout (example Template ID 260):
  flowId (148)                        unsigned64
  quicSenderDirection (TBD11)         unsigned8
  quicPacketNumberSpace (TBD12)       unsigned8
  quicPacketNumber (TBD8)             unsigned64
  quicObservationSource (TBD17)       unsigned8
  quicProcessingStatus (TBD18)        unsigned8
  quicExportFlags (TBD24)             unsigned8
  quicFieldPresence (TBD21)           unsigned32
  quicFirstOctet (TBD1)               unsigned8
  quicPacketType (TBD3)               unsigned8
  quicVersion (TBD2)                  unsigned32
  quicDestinationConnectionId (TBD6)  octetArray
  quicSourceConnectionId (TBD7)       octetArray
  quicToken (TBD20)                   octetArray
  quicPacketLength (TBD23)            unsigned32
  observationTimeMilliseconds (323)   dateTimeMilliseconds
  subTemplateList (292)               subTemplateList

  Child layout (example Sub-Template ID 261, packet order):
    quicFieldPresence (TBD21) unsigned32
    quicFrameType (TBD9)      unsigned64
    quicStreamId (TBD10)      unsigned64
    quicFrameOffset (TBD13)   unsigned32
    quicFrameLength (TBD14)   unsigned32

Data Record (Template ID 260):
  flowId                        4096
  quicSenderDirection           0 (client-to-server)
  quicPacketNumberSpace         2 (Application Data)
  quicPacketNumber              1847
  quicObservationSource         2 (Endpoint protocol state)
  quicProcessingStatus          5 (Protected content available)
  quicExportFlags               0 (Complete)
  quicFieldPresence             0x00000084
                                  (Destination CID, Packet Length)
  quicFirstOctet                0x40
  quicPacketType                5 (1-RTT)
  quicVersion                   0 (placeholder; no Version field
                                   in Short Header)
  quicDestinationConnectionId   0x0001020304050607
  quicSourceConnectionId        (empty placeholder)
  quicToken                     (empty placeholder)
  quicPacketLength              492
  observationTimeMilliseconds   1726200000400
  subTemplateList, 3 entries of Sub-Template 261:
    entry 0: quicFieldPresence 0x00000020 (Stream ID),
             quicFrameType 0x0E (STREAM), quicStreamId 0x02,
             quicFrameOffset 0,   quicFrameLength 400
    entry 1: quicFieldPresence 0, quicFrameType 0x02 (ACK),
             quicStreamId 0 (placeholder),
             quicFrameOffset 400, quicFrameLength 48
    entry 2: quicFieldPresence 0x00000020 (Stream ID),
             quicFrameType 0x0E (STREAM), quicStreamId 0x04,
             quicFrameOffset 448, quicFrameLength 18
Example arithmetic:
The three frame extents total 466 plaintext octets. The example assumes a 10-octet Short Header (first octet, 8-octet Destination Connection ID, and 1-octet truncated packet number) and a 16-octet authentication tag, giving a 492-octet QUIC packet.

3.3.3. Flow-Aggregate Profile

This profile is intended for aggregated statistics over a flow lifetime or a fixed time window, reducing export overhead. It carries counters, timing, explicitly identified first-observed context, and the evidence used to classify the flow as QUIC; other per-packet scalar fields are not exported.

Purpose:
Export aggregated counters and timing with explicit aggregation semantics, avoiding ambiguity from the default "first observed value" semantics for non-key properties in Section 5 of [RFC7012].
Flow Keys:
source address, destination address, protocolIdentifier, udpSourcePort, udpDestinationPort. The Observation Domain ID in the IPFIX Message Header additionally scopes the record. IPv4 and IPv6 use separate Templates with the corresponding address IEs.
Direction:
This profile is unidirectional. The ordered source/destination 5-tuple identifies one direction, and flowDirection (61) reports ingress or egress relative to the Observation Point. An exporter that implements a true biflow representation instead MUST use the direction-assignment, reverse-IE, reverse-counter, and biflowDirection conventions of [RFC5103] and a separately defined Template.
Measurement Interval:
The interval is either the full flow lifetime (from the first to the last observed packet of the flow at the Observation Point) or a fixed aggregation window configured on the exporter; flowStartMilliseconds (152) and flowEndMilliseconds (153) report the first and last observed packet times within the exported interval, per their registered definitions. If the interval is a fixed window, a flow spanning several windows yields one record per window, but flowEndMilliseconds remains the time of the last observed packet in that window. A configured window-closing time, if exported, uses a separate IE defined for that purpose and MUST NOT be substituted for flowEndMilliseconds. Every record includes flowEndReason (136). A fixed window that closes while the Flow continues uses value 2 (active timeout); a full-lifetime record uses the actual registered end reason.
Selection Effects:
The base Template is used only when packet selection is not active. If selection is active at the Observation Point, the exporter MUST use a distinct sampled Template that adds selectionSequenceId (301) to the record and to the sampled variant's Flow Key. It MUST create a separate aggregate for each Selection Sequence and MUST NOT combine packets from different selectionSequenceId values. For every selectionSequenceId in use, the exporter MUST export the applicable Selection Sequence, Selector, Selection Sequence Statistics, and Accuracy Report Interpretations required by Section 6.5 of [RFC5476]. This aggregate record supplements and MUST NOT replace the Packet Report that Section 6.4 of [RFC5476] requires for every selected outer IP packet in every Selection Sequence. Those Packet Reports use the sampled Network-Wire or Endpoint variant when applicable, or another suitable Packet Report Template. The counters are not compensated for unselected packets. Counters, context-packet values, classification evidence, and start/end times all describe the selected packet stream for that Selection Sequence.
QUIC Classification Evidence:
The exporter MUST NOT emit this profile based solely on a port, fixed-bit heuristic, or version-independent prefix parse. It MUST first obtain endpoint evidence or parse a packet using a supported QUIC version. The record carries quicObservationSource and quicProcessingStatus for the first observation that satisfied that admission rule. These IEs describe classification evidence; they do not assert that every packet included in the counters received the same processing.
Sampling Behavior:
This aggregate Template does not itself provide per-packet export; packets in the applicable unselected or selected stream are aggregated, and the record is exported at Flow end or at the end of a fixed aggregation window. The separate PSAMP Packet Reports required above remain mandatory when selection is active.
Aggregation Semantics:

Existing IPFIX packet counters count the packets of the defined Flow at the Observation Point; they do not implicitly count the QUIC packets coalesced within a UDP datagram. The semantics below make each counter's layer explicit:

packetDeltaCount (2):
sum of outer IP packets.
quicPacketDeltaCount (TBD16):
number of successfully delimited inner QUIC packets during the interval. The value is present only when the exporter can provide a complete count under the stated selection method.
octetDeltaCount (1):
sum of outer IP packet lengths in octets.
quicVersion / quicSourceConnectionId / quicDestinationConnectionId:
values from one context packet: the first completely parsed, supported-version Long Header packet included in the record's unselected or selected packet stream. These three fields are exported atomically, and their presence bits are all set even when either Connection ID has a genuine zero length. If no such context packet exists, or if any member of the tuple cannot be exported, all three presence bits are clear and the fixed fields carry ignored placeholders. The Version is the packet's exact wire Version field, not a negotiated or inferred connection-version value. If the Connection IDs rotate later, those later values are not reported in this profile.
Unavailable Fields:
quicFirstOctet, quicPacketType, quicPacketNumber, quicFrameType, and quicStreamId vary per packet and MUST NOT be exported in this profile. quicDestinationConnectionIdLengthSource is not exported in this profile because the aggregate Destination Connection ID, when present, always comes from the explicit length field in the context Long Header packet. If the exporter does not count inner QUIC packets, or cannot assert that its count is complete under the stated selection method, the quicPacketDeltaCount presence bit is clear and the fixed field carries zero as an ignored placeholder. The presence bitmap also identifies whether the complete Version and Connection ID tuple from the context Long Header packet was exported. A nonzero quicExportFlags value indicates that at least one otherwise available field in the record was suppressed by local export policy or truncated by an export-resource or size limit; it does not identify which clear presence bit was affected.
Illustrative Field Layout / Data Record:
Illustrative field layout (example Template ID 262):
  sourceIPv6Address (27)             ipv6Address
  destinationIPv6Address (28)        ipv6Address
  protocolIdentifier (4)             unsigned8
  udpSourcePort (180)                unsigned16
  udpDestinationPort (181)           unsigned16
  quicFieldPresence (TBD21)          unsigned32
  quicObservationSource (TBD17)      unsigned8
  quicProcessingStatus (TBD18)       unsigned8
  quicExportFlags (TBD24)            unsigned8
  packetDeltaCount (2)               unsigned64   (sum)
  quicPacketDeltaCount (TBD16)       unsigned64   (sum)
  octetDeltaCount (1)                unsigned64   (sum)
  quicVersion (TBD2)                 unsigned32   (first)
  quicSourceConnectionId (TBD7)      octetArray   (first)
  quicDestinationConnectionId (TBD6) octetArray   (first)
  flowStartMilliseconds (152)        dateTimeMilliseconds
  flowEndMilliseconds (153)          dateTimeMilliseconds
  flowEndReason (136)                 unsigned8
  flowDirection (61)                 unsigned8

Data Record (Template ID 262):
  sourceIPv6Address            2001:db8::1
  destinationIPv6Address       2001:db8::2
  protocolIdentifier           17
  udpSourcePort                53924
  udpDestinationPort           443
  quicFieldPresence            0x0000004D
                                 (Version, Source CID,
                                  Destination CID,
                                  QUIC Packet Count)
  quicObservationSource        1 (Passive wire)
  quicProcessingStatus         3 (Supported-version parsed)
  quicExportFlags              0 (Complete)
  packetDeltaCount             912
  quicPacketDeltaCount         947
  octetDeltaCount              402118
  quicVersion                  0x00000001
  quicSourceConnectionId       0x2021222324252627
  quicDestinationConnectionId  0x0001020304050607
  flowStartMilliseconds        1726200000000
  flowEndMilliseconds          1726200030000
  flowEndReason                2 (active timeout; fixed window)
  flowDirection                0 (ingress)

3.3.4. Optional Connection-State Profile

This optional profile uses an Options Template [RFC7011] to export connection-level metadata that does not fit into per-packet or per-flow records.

Purpose:
Export QUIC connection observations, such as the first Long Header Version field seen, a complete observed QUIC-packet count when available, and the first and last observation times, correlated to the initial client-to-server 5-tuple. The Original, Chosen, and Negotiated Versions defined by [RFC9368] are distinct endpoint connection state and are not represented by quicVersion. Additional connection-state IEs (e.g., ALPN, migration and Connection ID rotation counters) are out of scope for this document and MAY be added by future work.
Options Scope:
observationDomainId, the initial client-to-server 5-tuple, and flowId (148). IPv4 and IPv6 use separate Options Templates with their corresponding address IEs. The scoped observationDomainId identifies the Observation Domain of the correlated Endpoint Packet records, and flowId MUST equal the value carried by those records. The exporter assigns flowId from connection-specific state, keeps it unchanged for the lifetime of the connection observation (including across migration and IPFIX Transport Session changes), and MUST NOT derive it solely from a 5-tuple or Connection ID. The Observation Domain ID in the IPFIX Message Header carrying this Options Record MUST be zero or equal to the scoped observationDomainId; a different nonzero value would create a contradictory implicit scope.
Options:
quicVersion (first observed Long Header Version field), quicPacketDeltaCount (total successfully delimited QUIC packets when the exporter can provide a complete count), and flowStartMilliseconds and flowEndMilliseconds (first and last observed packet times), and flowEndReason (the reason this connection observation interval ended).
Sampling Behavior:
The base Options Template covers the unselected observed packet stream. If packet selection is active, the exporter MUST use a distinct sampled Options Template that adds selectionSequenceId (301) to the Options Scope, and MUST emit a separate Options Record for each represented (connection observation, Selection Sequence) pair. For every selectionSequenceId in use, the exporter MUST export the applicable Selection Sequence, Selector, Selection Sequence Statistics, and Accuracy Report Interpretations required by Section 6.5 of [RFC5476]. This Options Record supplements and MUST NOT replace the Packet Report that Section 6.4 of [RFC5476] requires for every selected outer IP packet in every Selection Sequence. Those Packet Reports use the sampled Network-Wire or Endpoint variant when applicable, or another suitable Packet Report Template. Counters, first-observed values, classification evidence, and start/end times in that sampled record describe only the selected packet stream. One Options Record per scope is exported when the connection observation terminates because the connection end was detected, the idle timer expired, an external event forced termination, or resources were exhausted. A value exported after idle timeout covers only the completed observation interval represented by that record.
Termination Reason:
For purposes of flowEndReason (136), the scoped connection observation is the Flow being terminated. The exporter MUST use value 1 (idle timeout) when it expires connection state because no packet was observed before the configured idle timeout. It MUST use value 3 (end of Flow detected) only when endpoint state, authenticated packet evidence, or a Stateless Reset confirmed by the token-matching procedure in Section 10.3.1 of [RFC9000] indicates that the QUIC connection ended. It uses value 4 (forced end) or value 5 (lack of resources) when the corresponding registered reason terminates the observation. The exporter MUST NOT report value 3 merely because its idle timer expired.
QUIC Classification Evidence:
The exporter MUST NOT create a connection observation from heuristic or version-independent prefix evidence alone. The Options Record carries quicObservationSource and quicProcessingStatus for the first endpoint observation or supported-version parse that established the connection as QUIC. These values describe admission evidence, not every packet in the connection interval. A supported-version parse is sufficient only to admit an individual packet as QUIC evidence; it does not establish that packets observed across Connection ID rotation or path migration belong to one connection. Before assigning flowId or aggregating a packet into this profile, the exporter MUST have connection-specific state sufficient to make that association. It MUST NOT merge observations based only on packet syntax, a 5-tuple, or a matching Connection ID.
Unavailable Fields:
quicFieldPresence identifies whether quicVersion and quicPacketDeltaCount are present. A clear bit causes the corresponding fixed field to contain an ignored zero placeholder. The time fields are always the first and last observed packet times for the interval. quicExportFlags independently reports local suppression or truncation of otherwise available values.
Illustrative Field Layout / Data Record:
Illustrative layout (example Options Template ID 264):
  Options Scope:
    observationDomainId (149)           unsigned32
    sourceIPv6Address (27)              ipv6Address
    destinationIPv6Address (28)         ipv6Address
    protocolIdentifier (4)              unsigned8
    udpSourcePort (180)                 unsigned16
    udpDestinationPort (181)            unsigned16
    flowId (148)                         unsigned64

  Non-Scope:
    quicFieldPresence (TBD21)           unsigned32
    quicObservationSource (TBD17)       unsigned8
    quicProcessingStatus (TBD18)        unsigned8
    quicExportFlags (TBD24)              unsigned8
    quicVersion (TBD2)                  unsigned32
    quicPacketDeltaCount (TBD16)        unsigned64
    flowStartMilliseconds (152)         dateTimeMilliseconds
    flowEndMilliseconds (153)           dateTimeMilliseconds
    flowEndReason (136)                  unsigned8

Options Record:
  Scope: observationDomainId 1, 2001:db8::1 -> 2001:db8::2,
         protocolIdentifier 17, udpSourcePort 53924,
         udpDestinationPort 443, flowId 4096
  quicFieldPresence          0x00000041
                               (Version, QUIC Packet Count)
  quicObservationSource      2 (Endpoint protocol state)
  quicProcessingStatus       5 (Protected content available)
  quicExportFlags            0 (Complete)
  quicVersion                0x00000001
  quicPacketDeltaCount       1894
  flowStartMilliseconds      1726200000000
  flowEndMilliseconds        1726200030000
  flowEndReason              3 (end of Flow detected)

4. New IPFIX QUIC Information Elements

This section specifies the new IPFIX QUIC IEs.

quicFirstOctet
The raw first octet of the observed QUIC packet, as seen on the wire, before any header protection removal; this is evidence, not an interpreted value. For protected v1 and v2 Long Header packets, the low four bits are masked by header protection; for a protected Short Header packet, the low five bits are masked. Retry is not header-protected, and only the most significant bit of a Version Negotiation first octet has invariant meaning. The packet-type mapping is version-specific, so the raw value SHOULD NOT be interpreted using the mapping of a version that is not known to be in use (e.g., QUIC v2 [RFC9369] intentionally remaps type bit values relative to QUIC v1). For Short Header packets, the first octet has no packet-type field, and a passive observer generally cannot distinguish a Stateless Reset from a normal Short Header packet without the reset token and connection state. Consumers that need a normalized packet type SHOULD use quicPacketType, which is only populated when the version and the required context are known.
quicVersion
The exact 32-bit Version field present in the Long Header of the observed QUIC packet. The Version field is wire-visible. For a Version Negotiation packet, this field is 0x00000000; the supported versions advertised in the Version Negotiation payload are a separate repeated quantity and are exported with quicSupportedVersion. Short Header packets do not carry this field; their quicVersion presence bit is clear. The Original, Chosen, and Negotiated Versions of a connection are distinct endpoint state [RFC9368] and are not exported by this IE.
quicPacketType
The normalized QUIC packet type, populated only when the exporter can determine it from quicFirstOctet and the QUIC version in use, with the required context. Value 0 (Unknown) is used when the version is not known or the type cannot be determined; the raw first octet remains available in quicFirstOctet. Value assignments: 0 = Unknown; 1 = Version Negotiation; 2 = Initial; 3 = 0-RTT; 4 = Handshake; 5 = 1-RTT (Short Header); 6 = Stateless Reset (only when the exporter identifies the entire received UDP datagram according to Section 10.3.1 of [RFC9000] and reports quicProcessingStatus 14); 7 = Retry. Confirmation requires comparing the datagram's final 16 octets only with eligible tokens for the remote address: tokens associated with Connection IDs that were used and have not been retired. Version Negotiation is identified by its invariant zero Version field. Retry is identified only when the exporter supports the packet's version and its type mapping. A Short Header is classified as 1-RTT only when endpoint state or successful packet-protection processing establishes that classification. These values are normalized categories, not the raw Long Header type-bit values. The exporter applies the mapping defined by the supported version; packets of unknown versions are exported as Unknown rather than reinterpreted using another version's mapping.
quicSupportedVersion
The list of supported versions advertised in the payload of a Version Negotiation packet, encoded as a basicList [RFC6313]. The list uses the ordered semantic, identifies quicSupportedVersionValue (TBD5) as the contained IE, and uses an element length of four octets. This is a separate repeated quantity from the 32-bit Version field in the packet header (quicVersion), which is 0x00000000 in a Version Negotiation packet. The list is present only for Version Negotiation; a fixed Template uses an empty placeholder and a clear presence bit for other packet types. The negotiated and original versions of a connection are endpoint connection state and are not exported by this IE.
quicSupportedVersionValue
One 32-bit version identifier contained in a quicSupportedVersion basicList. It represents a Supported Version field from the Version Negotiation packet payload and is not the packet header's Version field.
quicDestinationConnectionId
The wire-visible Destination Connection ID included in the Long Header or Short Header of a QUIC packet. The Destination Connection ID is chosen by the recipient of the packet and is used to provide consistent routing. Since the length of the Destination Connection ID is not included in a 1-RTT packet (Short Header), its Destination Connection ID can be obtained only from reliable connection- and direction-specific context, such as a peer-issued Connection ID observed in an applicable Long Header, endpoint state, successfully processed NEW_CONNECTION_ID frames, or management configuration. Exporters MUST NOT infer it from an arbitrary prior Long Header Destination Connection ID. Exporters of the Network-Wire Observation Profile SHOULD report quicDestinationConnectionIdLengthSource (TBD19) together with this IE so that consumers can assess how the length and context of the value were determined; in the Endpoint Packet Profile, the provenance is indicated by quicObservationSource and quicProcessingStatus.
quicSourceConnectionId
The wire-visible Source Connection ID included in the Long Header of a QUIC packet. The Source Connection ID is used to set the Destination Connection ID used by the peer during connection establishment. A Short Header packet does not carry a Source Connection ID. For such a packet, a fixed record layout exports an empty placeholder and clears the Source Connection ID bit in quicFieldPresence. An actually present zero-length Source Connection ID is encoded as empty with that bit set. A collector MUST NOT supply a value for it when only Short Header packets of a connection have been observed.
quicPacketNumber
The full QUIC packet number assigned by the sending endpoint, or reconstructed for a received packet according to the applicable QUIC version's packet-number decoding procedure, an integer in the range 0 to 2^62-1 as defined in Section 12.3 of [RFC9000]. It does not carry the header-protection-masked octets observed on the wire, nor the 1-to-4-byte truncated packet number obtained after removing header protection. For a received packet, removing header protection reveals the Packet Number Length bits and the truncated packet number; a candidate full packet number is then reconstructed using the expected packet-number state and used to form the AEAD nonce. A receiver-derived value MUST be exported as quicPacketNumber only after packet-protection processing succeeds. The enclosing record MUST unambiguously identify the QUIC connection observation, sending endpoint or direction, and packet-number space; QUIC v1 and v2 have Initial, Handshake, and Application Data packet-number spaces, and 0-RTT and 1-RTT packets share the Application Data packet-number space. Extraction capability depends on the supported QUIC version, sufficient captured bytes, connection context, and access to the applicable keys: for QUIC v1 and v2, the Packet Number Length bits and the encoded packet number field are header-protected in Initial, Handshake, 0-RTT, and 1-RTT packets. An observer supporting the applicable version and possessing the relevant client Initial Destination Connection ID can derive the version-specific Initial keys, but successful Initial packet processing does not authenticate the peer because those keys are publicly derivable; processing Handshake, 0-RTT, and 1-RTT packets requires the corresponding traffic secrets or keys derived from them; and locating the packet number field in a Short Header packet additionally requires knowledge of the Destination Connection ID length. A packet number field is present in Initial, 0-RTT, Handshake, and 1-RTT packets; Version Negotiation and Retry packets do not contain one. An identified Stateless Reset has no semantic packet number, although it is deliberately formatted to resemble a Short Header packet. These rules apply to QUIC v1 and v2; they MUST NOT be applied to an unknown future QUIC version without its version-specific specification. If IPFIX reduced-size encoding [RFC7011] is used, its field length is fixed in the Template and MUST accommodate every value exported using that Template; it is independent of QUIC's per-packet 1-to-4-byte packet-number encoding. The exported value does not by itself support loss inference: packet-number gaps alone do not prove loss or incomplete reception, because packet numbers may be intentionally skipped, packets may be reordered, and the Observation Point or a sampling process may miss packets (see Section 4.1 of [RFC9312]).
quicFrameType
The Frame Type decoded from the plaintext payload of a successfully processed QUIC packet. In supported versions, permitted Initial frame types can be obtained by a passive observer that has the applicable client Initial Destination Connection ID and sufficient capture and packet-number context. Other encryption levels normally require the corresponding traffic keys. The Frame Type value uses a variable-length integer encoding which means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. Some Frame Types are defined in section 12.4 of [RFC9000].
quicStreamId
The protected Stream ID included in the Frame related to Stream such as RESET_STREAM frame, STOP_SENDING frame, STREAM frame and MAX_STREAM_DATA frame. For frame types that do not carry a Stream ID (e.g., ACK, CRYPTO), this IE is exported as a zero placeholder and its quicFieldPresence bit is clear. A frame that carries Stream ID zero exports zero with the bit set. A stream ID is a 62-bit integer (0 to 2^62-1) that is unique for all streams on a connection. Stream IDs are encoded as variable-length integers, which means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. The two least significant bits from a stream ID identify the stream types defined in section 2.1 of [RFC9000].
quicSenderDirection
Indicates the sender direction of the QUIC packet within a connection. Value 0 indicates client-to-server; value 1 indicates server-to-client.
quicPacketNumberSpace
Indicates the QUIC packet number space of the observed packet. Value 0 indicates Initial space; value 1 indicates Handshake space; value 2 indicates Application Data space (0-RTT and 1-RTT).
quicFrameOffset
The octet offset of a QUIC frame relative to the first plaintext octet of the QUIC packet payload. It is used in the frame subTemplateList to indicate the position of each frame and is distinct from quicPacketOffset, which locates a coalesced QUIC packet within a UDP payload.
quicFrameLength
The total encoded plaintext extent of a QUIC frame, in octets, from the first Frame Type octet through the final octet of that frame. This is not a frame-specific Length field; QUIC has no generic frame-length prefix.
quicPacketOffset
The byte offset of a coalesced QUIC packet within the UDP payload of the enclosing IP/UDP datagram. It is used in the inner QUIC-packet subTemplateList of the Network-Wire Observation Profile and of the sampled Endpoint Packet Observation Profile to identify each reported QUIC packet carried by a (possibly coalesced) datagram. The first inner packet has an offset of 0.
quicPacketDeltaCount
The number of completely delimited QUIC packets in the IP/UDP datagrams included in the record's measurement interval. This counter is independent of the number of structured-data child records and is distinct from packetDeltaCount, which counts outer IP packets.
quicObservationSource
Identifies the source of the observation independently of processing outcome: 0 = Unknown; 1 = Passive wire observation; 2 = Endpoint protocol state; 3 = Authorized cooperating device supplied with the applicable context or keys. In aggregate and connection records, it identifies the source of the admission evidence defined by that profile.
quicProcessingStatus
Identifies the processing result independently of source. Values cover heuristic classification, raw capture, supported-version parsing, successful Initial processing, protected-content availability, Retry Integrity Tag validation, Stateless Reset token confirmation, unsupported versions, malformed and capture-truncated input, packet-protection failure, Retry Integrity Tag failure, incomplete frame parsing caused by an unsupported frame type or format, and incomplete packet-field or frame parsing caused by a local parser or processing-resource limit. These values are mutually descriptive statuses, not an increasing confidence scale. In aggregate and connection records, the value describes the admission evidence defined by that profile.
quicDestinationConnectionIdLengthSource
Indicates how the exporter determined the length and context of a Destination Connection ID field for the observed packet, or that no applicable length was available. This is significant for Short Header packets, whose header does not carry an explicit Destination Connection ID length. Value assignments: 0 = Not applicable because the packet has no semantic Destination Connection ID field; 1 = Explicit length field (the length was taken from the explicit Destination Connection ID length field of the observed Long Header packet); 2 = Learned from connection- and direction-specific protocol context; 3 = Management configuration (the value or its length was provisioned to the exporter); 4 = Unknown (the length could not be determined; the Destination Connection ID presence bit is then clear).
quicToken
The raw Token octets carried in the type-specific field of the observed Long Header packet, as present on the wire. In an Initial packet, this is the Token following the Token Length field (Section 17.2.2 of [RFC9000]); in a Retry packet, this is the Retry Token. The Token is not header-protected and is therefore observable by a passive exporter. For packets of other types (Version Negotiation, Handshake, 0-RTT, Short Header), and for Initial packets whose Token Length is zero, a fixed Template uses an empty value and quicFieldPresence distinguishes absence from a genuinely present zero-length Token. The Token content is chosen by the server and MAY be encrypted or integrity-protected by the server; it can encode client address-validation state, and its export raises privacy considerations (see Section 5). This IE does not by itself allow the exporter or the collector to validate the Token; it is exported as observational evidence.
quicFieldPresence
A flags IE that states which accompanying optional fields in the same record are semantically present. It distinguishes valid zero values and zero-length fields from fixed-Template placeholders.
quicDatagramParseStatus
Indicates whether a Network-Wire or sampled Endpoint parent record completely enumerated and delimited the observed UDP payload or stopped because of an unsupported version, capture truncation, malformed input, or a local parser or processing-resource limit. This status describes parsing, not whether parsed child records were all exported.
quicPacketLength
The total wire length in octets of one successfully delimited QUIC packet, from its first header octet through its final octet. It excludes the enclosing UDP and IP headers.
quicExportFlags
Independent flags stating whether otherwise available information in the same record or its child list was truncated by a local resource or size limit in the export path, suppressed by configured export policy, or both. A zero value means export was complete under the profile.

5. Security Considerations

The security of the exported data depends on the security of the IPFIX protocol and its transport. As described in Section 11 of [RFC7011], the IPFIX protocol relies on the transport layer for confidentiality and integrity, and it does not define an in-band session authentication mechanism. Authentication of the exporter by the collector MUST therefore be provided by the underlying transport (e.g., IPFIX over TLS) or by a security gateway, and the transport session SHOULD be protected against disclosure and tampering. Beyond in-flight protection, deployments SHOULD apply authentication and authorization to the collector itself: only authorized consumers SHOULD be permitted to query, store, or forward the exported Data Records, and the access controls applied to the collector SHOULD reflect the sensitivity of the QUIC-specific values exported through it.

QUIC packet types have different protection properties. Version Negotiation has no intrinsic confidentiality or integrity protection. Retry is neither encrypted nor header-protected; its version-specific Retry Integrity Tag detects accidental corruption and limits valid generation to an entity that observed the relevant Initial packet, but does not authenticate the server against an active on-path attacker. Initial uses packet protection under publicly derivable keys and is not considered to provide confidentiality or integrity protection against attackers. Handshake, 0-RTT, and 1-RTT packets use traffic secrets or keys derived from TLS. Visible header bytes of a successfully protected packet can still be authenticated as AEAD associated data. These distinctions are described in [RFC9001]. See the Security and Privacy Considerations of [RFC9000] and the manageability considerations of [RFC9312].

A sufficiently captured Long Header exposes both Connection IDs. A Short Header exposes Destination Connection ID octets only to an observer that knows the connection-specific length; it carries no Source Connection ID. Connection IDs are useful, bounded correlation evidence, but they are not a stable connection key: a QUIC endpoint may maintain several active Connection IDs and may change the Destination Connection ID it uses for a peer at any time during a connection, for example during connection migration [RFC9000]. CID-based correlation is additionally limited by Connection ID rotation, address and port migration (the same connection may be observed under different CIDs before and after a path change), zero-length Connection IDs (which provide no correlation evidence at all), and multiple observation points (which may not agree on which packets belong to the same connection). Exporting these identifiers can therefore create additional linkability: a collector can use them to correlate packets belonging to the same QUIC connection before and after an address or port change, including across NAT rebinding and path migration. Deployments exporting these identifiers SHOULD apply access control and retention policies appropriate for identifiers that can correlate traffic belonging to the same QUIC connection. Where endpoint-derived association is available, flowId (148) provides the registered, explicitly scoped correlation mechanism used by this document. An exporter MUST assign flowId from its connection-observation state and MUST NOT derive it solely from a 5-tuple or wire-visible Connection ID. Endpoint- or key-derived quicStreamId and quicPacketNumber values likewise require access controls appropriate to their additional linkability.

quicToken (TBD20) exports the raw Token octets of an Initial or Retry packet. A Token is chosen by the server and can carry or index address-validation state. Its content is opaque to an exporter or collector that lacks the server's token-protection context, so exporting it does not by itself enable the collector to interpret or validate that state. Depending on the server's token construction, address binding, and token lifetime, disclosure can nevertheless enable replay that bypasses address validation and can contribute to amplification attacks; see Sections 8.1.4 and 21.3 of [RFC9000]. Nevertheless, repeated raw Token values and combinations with other observations can add correlation capability across packets, connections, or observation points. Deployments exporting quicToken SHOULD treat it as sensitive correlation data and SHOULD apply access control, minimization, and retention policies accordingly; where token contents are not needed for the operational purpose, exporters SHOULD NOT export quicToken.

Cross-observation-point correlation extends the linkability described above. Because Connection IDs are wire-visible, the same QUIC connection can be observed under the same or different Connection IDs at multiple observation points (for example, at the network edge and at a datacenter ingress, or before and after a client moves behind a different NAT), and a collector that aggregates records from several points can correlate the same connection across those points and combine it with other data sources. flowId mitigates this by providing a correlation value assigned from exporter connection state rather than from wire-visible identifiers. It is unique only within its Observation Domain, as specified by the registered IE definition, and is non-reversible under [RFC5103]. Collectors combining records from different Exporting Processes or Observation Domains MUST NOT assume that equal flowId values identify the same connection.

The Information Elements specified in this document can weaken this protection when they are populated from plaintext QUIC content. In particular, quicPacketNumber and quicFrameType can be obtained from a supported-version Initial packet by a passive observer that has the applicable client Initial Destination Connection ID, complete capture, direction and packet-number context, and successful packet processing. Processing Handshake, 0-RTT, and 1-RTT content requires the corresponding traffic secrets or derived keys. Stream-related frames are not permitted in Initial packets, so quicStreamId remains endpoint- or traffic-key-derived. Exporting these values may reveal information about user activity that QUIC is designed to protect, and may make user activity linkable across flows and observation points.

Operators deploying these IEs SHOULD apply data minimization: export only the Information Elements required for the intended use, limit the retention period of exported QUIC-specific values (Connection IDs, packet numbers, stream identifiers), and restrict access to the exported records. Exporters MUST NOT export QUIC secrets or keying material, including handshake secrets, traffic keys, Initial secrets, header-protection keys, or Stateless Reset tokens.

Stateless reset tokens allow termination of the associated connection and are therefore sensitive connection state. An exporter that confirms a Stateless Reset MUST protect stored tokens, MUST perform the comparison without leaking token values as required by Section 10.3.1 of [RFC9000], and MUST NOT export the matched token as quicToken. quicToken represents only the Initial or Retry Token field.

Several of the Information Elements defined in this document carry variable-length or list data: quicDestinationConnectionId and quicSourceConnectionId (octetArray), quicToken (octetArray), quicSupportedVersion (basicList), and the nested frame sub-template records (subTemplateList). Unbounded values in these fields could be used to consume excessive resources at the collector or to smuggle arbitrary data through the export channel. Exporters SHOULD therefore impose local limits on total structured-data bytes, the number of version entries, frames and inner packets, nesting, and parser work. A 20-octet Connection ID limit applies to packets encoded by QUIC v1 and v2, but the invariant Long Header format of [RFC8999] permits Connection ID lengths from 0 through 255 octets in Version Negotiation or an unknown or future version. Version Negotiation has no separate protocol-defined entry-count maximum; its complete 32-bit entries occupy the packet remainder after the Source Connection ID. A Token is bounded by the bytes remaining in the observed packet. When a parser-work or processing-resource limit prevents complete parsing of an emitted packet observation, that observation uses quicProcessingStatus 13. If that limit also prevents complete packet-boundary enumeration in the Network-Wire profile, the parent record uses quicDatagramParseStatus 5. When otherwise available information exceeds a local export or representation limit, the exporter MUST report local truncation through quicExportFlags and clear any affected presence bit. It MUST NOT label the packet malformed solely because of either local limit. Collectors SHOULD validate the lengths declared in templates and reject records whose implied size is implausible, in order to protect against a misconfigured or malicious exporter.

6. IANA Considerations

6.1. New IPFIX QUIC Information Elements

This document requests IANA to add new IPFIX QUIC IEs to the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX]. The registration of each IE follows the process and format specified in [RFC7012], and the encoding of list-typed elements (e.g., quicSupportedVersion) follows [RFC6313]. The IE definitions in this document were written following the guidelines in [RFC7013]. Each IE description in this document independently states its derivation, applicability, scope, aggregation behavior, range/length, and the behavior when the value is unavailable, so that a reader can understand the IE from its registry entry alone.

IANA is requested to assign the lowest available Element IDs in the range specified by [RFC7013], replace every TBD label appearing in Table 1 throughout these registrations, set the Status of every new IE to current, set its initial Revision to 0, and set its Date to the date on which the registration is made. The RFC Editor is requested to replace each remaining such TBD label in this document with the corresponding Element ID assigned by IANA.

Table 1 lists the new IPFIX QUIC IEs:

+============+==========================================+
| Element ID | Name                                     |
+============+==========================================+
| TBD1       | quicFirstOctet                           |
+------------+------------------------------------------+
| TBD2       | quicVersion                              |
+------------+------------------------------------------+
| TBD3       | quicPacketType                           |
+------------+------------------------------------------+
| TBD4       | quicSupportedVersion                     |
+------------+------------------------------------------+
| TBD5       | quicSupportedVersionValue                |
+------------+------------------------------------------+
| TBD6       | quicDestinationConnectionId              |
+------------+------------------------------------------+
| TBD7       | quicSourceConnectionId                   |
+------------+------------------------------------------+
| TBD8       | quicPacketNumber                         |
+------------+------------------------------------------+
| TBD9       | quicFrameType                            |
+------------+------------------------------------------+
| TBD10      | quicStreamId                             |
+------------+------------------------------------------+
| TBD11      | quicSenderDirection                      |
+------------+------------------------------------------+
| TBD12      | quicPacketNumberSpace                    |
+------------+------------------------------------------+
| TBD13      | quicFrameOffset                          |
+------------+------------------------------------------+
| TBD14      | quicFrameLength                          |
+------------+------------------------------------------+
| TBD15      | quicPacketOffset                         |
+------------+------------------------------------------+
| TBD16      | quicPacketDeltaCount                     |
+------------+------------------------------------------+
| TBD17      | quicObservationSource                    |
+------------+------------------------------------------+
| TBD18      | quicProcessingStatus                     |
+------------+------------------------------------------+
| TBD19      | quicDestinationConnectionIdLengthSource  |
+------------+------------------------------------------+
| TBD20      | quicToken                                |
+------------+------------------------------------------+
| TBD21      | quicFieldPresence                        |
+------------+------------------------------------------+
| TBD22      | quicDatagramParseStatus                  |
+------------+------------------------------------------+
| TBD23      | quicPacketLength                         |
+------------+------------------------------------------+
| TBD24      | quicExportFlags                          |
+------------+------------------------------------------+

Table 1: New QUIC IEs in the "IPFIX Information Elements" Registry

6.1.1. quicFirstOctet

Name:
quicFirstOctet
ElementID:
TBD1
Description:
The raw first octet of the observed QUIC packet, as seen on the wire, before any header protection removal; this is evidence, not an interpreted value. The Header Form bit is invariant, but the meaning of the other bits is version-specific. For protected QUIC v1 and v2 Long Header packets, the low four bits are masked by header protection; for a protected Short Header packet, the low five bits are masked. Retry and Version Negotiation packets are not header-protected, and only the most significant bit of a Version Negotiation first octet has invariant meaning. A Short Header first octet has no packet-type field, and a passive observer generally cannot distinguish a Stateless Reset from a normal Short Header packet without the reset token and connection state. For a normalized packet type, see quicPacketType.
Abstract Data Type:
unsigned8
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the wire; no decryption required. Applicability: all Long and Short Header QUIC packets. Scope: one value per QUIC-packet observation in the Network-Wire Observation and Endpoint Packet Observation profiles. Aggregation: one value per observed packet. Range: 0x00-0xFF. The value is the on-wire octet; an exporter MUST NOT replace it with the octet obtained after header-protection removal. An exporter cannot create a packet observation when capture truncation prevents access to the first octet. See Section 5 of [RFC9001] for header protection, [RFC8999] for invariant fields, and Sections 17.2 and 17.3 of [RFC9000] for QUIC v1 packet formats.
Reference:
[this document]

6.1.2. quicVersion

Name:
quicVersion
ElementID:
TBD2
Description:
The exact 32-bit Version field present in the Long Header of the observed QUIC packet. The field is wire-visible and is not header-protected. It is 0x00000000 in a Version Negotiation packet. Short Header packets do not contain a Version field; an exporter MUST NOT substitute a version learned from connection state. The Original, Chosen, and Negotiated Versions of a connection are distinct endpoint state [RFC9368] and are not exported by this IE.
Abstract Data Type:
unsigned32
Data Type Semantics:
identifier
Additional Information:
Derivation: read directly from the Long Header (passive); no decryption is required. Applicability: Long Header packets only. Scope: one value per packet observation in a profile that carries this IE. Aggregation: one value per observed packet; a coarser-granularity profile defines separately which packet supplies its value. Range: 0x00000000-0xFFFFFFFF; 0x00000000 means Version Negotiation and MUST NOT be used to mean "unknown". In a fixed Template, a Short Header packet or an unavailable Long Header field is encoded with the numeric placeholder zero and the Version bit in quicFieldPresence clear; a collector MUST ignore that placeholder. A genuine Version Negotiation field has value zero with the Version bit set. See the assignments in the "QUIC Versions" IANA registry at https://www.iana.org/assignments/quic/quic.xhtml#quic-versions. See also [RFC8999] for the invariant Long Header Version field and [RFC9000] for QUIC v1 packet formats.
Reference:
[this document]

6.1.3. quicPacketType

Name:
quicPacketType
ElementID:
TBD3
Description:
The normalized, version-independent category of the observed QUIC packet. Assigned values are maintained in the quicPacketType Values subregistry.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: derived (not read directly from the wire) by interpreting invariant fields, quicFirstOctet, the supported QUIC version's packet-type rules, and any required connection context. Applicability: all observed QUIC packets. Scope: one value per packet observation in the Network-Wire Observation and Endpoint Packet Observation profiles. Aggregation: one value per observed packet. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.1. Exporters MUST NOT apply the type-bit mapping of a known version to a packet of an unknown or different version. In particular, QUIC v2 [RFC9369] remaps the Long Header type bits relative to QUIC v1. A Short Header packet is classified as 1-RTT only when endpoint protocol state or successful packet-protection processing establishes that classification; an apparent Short Header without that result is Unknown. A packet that merely resembles a Stateless Reset, including a candidate whose token does not match under Section 10.3.1 of [RFC9000], is likewise not assigned value 6. Value 6 is reported only when the exporter identifies the entire received UDP datagram using that procedure: its final 16 octets match an eligible token associated with the remote address and a Connection ID that was used and has not been retired. An observation with value 6 MUST carry quicProcessingStatus value 14. A Stateless Reset consumes the entire UDP datagram and has no semantic Destination Connection ID; apparent Connection ID-position bytes are unpredictable reset bytes and are not exported as quicDestinationConnectionId.
Reference:
[this document]

6.1.4. quicSupportedVersion

Name:
quicSupportedVersion
ElementID:
TBD4
Description:
The list of supported versions advertised in the payload of a Version Negotiation packet, encoded as a basicList of quicSupportedVersionValue (TBD5) elements. The basicList uses the ordered semantic, and every element has a length of four octets. Entries retain their wire order, including duplicate and reserved-version values. This is a separate repeated quantity from the 32-bit Version field in the packet header (quicVersion), which is 0x00000000 in a Version Negotiation packet.
Abstract Data Type:
basicList
Data Type Semantics:
list
Additional Information:
Derivation: parsed from the Version Negotiation payload (passive); the list starts immediately after the Source Connection ID and extends to the end of the packet. QUIC does not encode a separate entry count or list length. The remaining extent therefore has to be a non-zero multiple of four octets for a valid Version Negotiation packet. Applicability: Version Negotiation packets only. Scope: one list per packet observation in the Network-Wire Observation Profile. Aggregation: one ordered list per observed Version Negotiation packet. In a fixed Template, other packet types or an unavailable or malformed list use an empty-list placeholder with the Supported Version bit in quicFieldPresence clear; a collector MUST ignore that placeholder. When the list is exported as present, the bit is set and the list contains every complete 32-bit entry without deduplication or filtering. If configured policy or an export-path limit omits any otherwise available entry, the presence bit is clear, the fixed Template carries an empty list, and the applicable quicExportFlags bit is set. If a local parser or processing-resource limit stops list parsing, the same empty-list representation is used and quicProcessingStatus is 13. A partial advertised list MUST NOT be represented as complete. A malformed Version Negotiation list that occupies a known packet remainder does not by itself make packet-boundary enumeration incomplete: the parent uses quicDatagramParseStatus 1 and the child uses quicProcessingStatus 8. See Section 17.2.1 of [RFC9000] for the Version Negotiation packet format. See Section 4.5.1 of [RFC6313] for the basicList encoding.
Reference:
[this document]

6.1.5. quicSupportedVersionValue

Name:
quicSupportedVersionValue
ElementID:
TBD5
Description:
One exact 32-bit Supported Version value from the payload of a QUIC Version Negotiation packet. It is the scalar element contained by quicSupportedVersion and is distinct from the packet header's Version field.
Abstract Data Type:
unsigned32
Data Type Semantics:
identifier
Additional Information:
Derivation: read as one four-octet entry from the Version Negotiation packet payload after the Source Connection ID. Applicability and scope: one list element for each complete entry in quicSupportedVersion; it is not a standalone negotiated-version assertion. Aggregation: not aggregated. Range: 0 to 2^32-1. Each occurrence in the basicList MUST use a field length of four octets. The exporter MUST preserve the wire order, duplicates, and reserved or unrecognized values in the enclosing list and MUST NOT substitute the header Version field. A trailing payload fragment shorter than four octets is malformed and is not exported as a list element. Values are interpreted using the "QUIC Versions" IANA registry at https://www.iana.org/assignments/quic/quic.xhtml#quic-versions; reserved and unrecognized values are nevertheless retained as observed.
Reference:
[this document]

6.1.6. quicDestinationConnectionId

Name:
quicDestinationConnectionId
ElementID:
TBD6
Description:
The wire-visible Destination Connection ID field of the observed QUIC packet, represented as an octetArray. Long Headers carry an explicit Destination Connection ID length; Short Headers do not, so their field can be exported only when the exporter has reliable connection- and direction-specific length context. QUIC v1 and v2 Connection IDs are at most 20 octets. The version-independent Long Header permits lengths from 0 through 255 octets, while [RFC8999] does not constrain the Short Header Destination Connection ID length. An exporter MUST apply the constraints of the applicable supported version and MUST NOT apply the v1 or v2 limit to Version Negotiation or another version.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the Long Header (explicit length field). For a Short Header, the field boundary is obtained from reliable connection-specific context for the receiving endpoint, such as endpoint state, management configuration, or knowledge of a recipient-selected Connection ID and its direction. An exporter MUST NOT assume that the length of an arbitrary Connection ID seen in a prior Long Header is the applicable Short Header length; Connection ID rotation can require NEW_CONNECTION_ID or equivalent endpoint context. Applicability: Long and Short Header packets, including a genuinely zero-length field, and the value from the context Long Header packet defined by the Flow-Aggregate Profile. Scope: one value per packet observation in the Network-Wire and Endpoint Packet Observation profiles; in the Flow-Aggregate Profile, one value from the record's context packet. Aggregation: one value per observed packet in packet profiles; taken from the context packet in the Flow-Aggregate Profile. Length: 0 to 20 octets for packets encoded by QUIC v1 and v2; for another supported version, the range specified by that version; 0 to 255 octets for Version Negotiation or when parsing only the version-independent Long Header structure of an unknown version. A Short Header value under another supported version uses that version's range; the version-independent Short Header format sets no limit. When the field is present and has zero length, its presence bit is set and an empty octetArray is the value. When a Short Header field boundary cannot be determined, or capture truncation prevents reading a declared Long Header field, the Destination Connection ID presence bit is clear and a fixed Template carries an empty placeholder that the collector MUST ignore. quicDestinationConnectionIdLengthSource (TBD19) reports the method used to obtain the field boundary. See [RFC8999] for the invariant Long Header encoding and Sections 5.1, 17.2, and 17.3 of [RFC9000] for QUIC v1 Connection IDs.
Reference:
[this document]

6.1.7. quicSourceConnectionId

Name:
quicSourceConnectionId
ElementID:
TBD7
Description:
The wire-visible Source Connection ID field of the observed QUIC Long Header packet, represented as an octetArray. A Short Header does not contain a Source Connection ID. QUIC v1 and v2 Connection IDs are at most 20 octets. The version-independent Long Header permits lengths from 0 through 255 octets. An exporter MUST apply the constraints of the applicable supported version and MUST NOT apply the v1 or v2 limit to Version Negotiation or another version.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the Long Header; the Source field boundary is given by its explicit length octet and no decryption is required. Applicability: Long Header packets and the value from the context Long Header packet defined by the Flow-Aggregate Profile. Scope: one value per packet observation in the Network-Wire and Endpoint Packet Observation profiles; in the Flow-Aggregate Profile, one value from the record's context packet. Aggregation: one value per observed packet in packet profiles; taken from the context packet in the Flow-Aggregate Profile. Length: 0 to 20 octets for packets encoded by QUIC v1 and v2; for another supported version, the range specified by that version; 0 to 255 octets for Version Negotiation or when parsing only the version-independent Long Header structure of an unknown version. A present zero-length field has its Source Connection ID presence bit set and an empty octetArray value. A Short Header, or a capture-truncated Long Header for which the declared field cannot be read, has the presence bit clear; a fixed Template then carries an empty placeholder that the collector MUST ignore. See [RFC8999] for the invariant Long Header encoding and Sections 5.1 and 17.2 of [RFC9000] for QUIC v1 Connection IDs.
Reference:
[this document]

6.1.8. quicPacketNumber

Name:
quicPacketNumber
ElementID:
TBD8
Description:
The full QUIC packet number assigned by the sending endpoint or reconstructed for a received packet according to the applicable QUIC version's packet-number decoding procedure, an unsigned64 integer in the range 0 to 2^62-1. It does not carry the header-protection-masked octets observed on the wire, nor the 1-to-4-byte truncated packet number obtained after removing header protection. A receiver-derived value is exported only after packet-protection processing succeeds. The enclosing record MUST unambiguously identify the QUIC connection observation, sending endpoint or direction, and packet-number space; QUIC v1 and v2 have Initial, Handshake, and Application Data packet-number spaces, and 0-RTT and 1-RTT packets share the Application Data packet-number space. A packet number field is present in Initial, 0-RTT, Handshake, and 1-RTT packets; Version Negotiation and Retry packets do not contain one. An identified Stateless Reset has no semantic packet number, although it is deliberately formatted to resemble a Short Header packet. If IPFIX reduced-size encoding is used, its field length is fixed in the Template and must accommodate every value exported using that Template; it is independent of QUIC's per-packet 1-to-4-byte packet-number encoding. This element does not by itself support loss inference (see Section 4.1 of [RFC9312]).
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the sending endpoint, or for a received packet reconstructed from the truncated packet number revealed by header-protection removal according to the applicable QUIC version's packet-number decoding procedure; not the header-protection-masked wire octets and not the 1-to-4-byte truncated value. A received or passively observed value is valid only after packet-protection processing succeeds and the exporter can track the (connection, sender direction, packet-number space) state. Version-specific Initial secrets are publicly derivable from the client's Initial Destination Connection ID, so a passive exporter can obtain an Initial packet number when it has the required version and connection context; successful Initial processing does not authenticate the peer. Handshake, 0-RTT, and 1-RTT packets require the corresponding traffic secrets, and locating the packet number in a Short Header additionally requires reliable Destination Connection ID length context. Applicability: Initial, 0-RTT, Handshake, and 1-RTT packets. Version Negotiation and Retry have no packet-number field, and a confirmed Stateless Reset has no semantic packet number. These rules apply to QUIC v1 and v2 and MUST NOT be applied to an unknown future version without its version-specific specification. Scope: one value per QUIC-packet observation record in the Endpoint Packet Observation Profile, whether a top-level record in the base variant or a child record in the sampled variant; that record identifies the connection observation, sender direction, and packet-number space. The Flow-Aggregate and Connection-State profiles do not carry this IE. Aggregation: one value per observed packet. Range: 0 to 2^62-1; the value is the reconstructed full packet number. If the value cannot be obtained and validated, the exporter MUST NOT emit an Endpoint Packet Observation record containing it. If IPFIX reduced-size encoding is used, the field length selected by the Template has to accommodate every value exported with that Template and is independent of QUIC's 1-to-4-octet truncated encoding. See Section 12.3 of [RFC9000] for more details about the Packet Number.
Reference:
[this document]

6.1.9. quicFrameType

Name:
quicFrameType
ElementID:
TBD9
Description:
The QUIC variable-length integer that identifies the frame type. It is represented as an unsigned64 value in the range 0 to 2^62-1. Values are assigned in the "QUIC Frame Types" IANA registry.
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: parse the frame's type field from plaintext supplied by the sending endpoint or obtained after successful packet-protection processing of a received or passively observed packet. An endpoint or authorized device with the applicable traffic secrets can obtain this value. A passive exporter can also obtain it from a supported-version Initial packet after successful Initial packet-protection processing with the publicly derivable Initial secrets; that success does not authenticate the peer. Applicability: every successfully parsed frame in an Initial, 0-RTT, Handshake, or 1-RTT packet. A packet can contain multiple frames, and each occurrence is reported in its own frame-observation subrecord. Scope: one value per frame in the Endpoint Packet Observation Profile. Aggregation: one value per frame occurrence; frame order is preserved by the containing profile. Range: 0 to 2^62-1, subject to assignments in the "QUIC Frame Types" IANA registry. If packet protection does not succeed, the exporter MUST NOT emit frame-observation records derived from the unauthenticated plaintext. If frame parsing stops after a prefix of complete frames, the exporter MAY emit records for that prefix but MUST NOT emit a record for the undelimited frame or infer any later frame; quicProcessingStatus reports why parsing stopped. See the assignments in the "QUIC Frame Types" IANA registry at https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types. See also [RFC9000] for QUIC frame encoding.
Reference:
[this document]

6.1.10. quicStreamId

Name:
quicStreamId
ElementID:
TBD10
Description:
The QUIC Stream ID carried by a frame that contains a Stream ID field, represented as an unsigned64 value in the range 0 to 2^62-1. The two least significant bits identify the stream initiator and whether the stream is unidirectional or bidirectional, as defined in Section 2.1 of [RFC9000].
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: parse the Stream ID field from plaintext supplied by the sending endpoint or obtained after successful packet-protection processing of a received packet. Applicability: only frame types whose format contains a Stream ID field, including STREAM, RESET_STREAM, STOP_SENDING, MAX_STREAM_DATA, STREAM_DATA_BLOCKED, and their registered extensions as applicable. The base QUIC v1 frame types that contain a Stream ID are not permitted in Initial or Handshake packets, so passive Initial processing does not by itself make Stream IDs available; observing them in 0-RTT or 1-RTT packets requires endpoint state or the applicable traffic secrets. Scope: one value per frame observation in the Endpoint Packet Observation Profile. Aggregation: one value per frame occurrence that contains a Stream ID. Range: 0 to 2^62-1. In the fixed frame-observation Template, a frame without a Stream ID uses numeric placeholder zero with the Stream ID bit in quicFieldPresence clear; a genuine Stream ID of zero has the bit set. A collector MUST ignore the placeholder when the bit is clear. If packet protection fails, the exporter MUST NOT emit a frame observation containing this IE. If parsing stops at a later frame, preceding completely parsed frame observations remain valid, but no Stream ID is emitted for the undelimited frame or any inferred later frame. See Section 2.1 of [RFC9000] for Stream ID semantics.
Reference:
[this document]

6.1.11. quicSenderDirection

Name:
quicSenderDirection
ElementID:
TBD11
Description:
Indicates the sender direction of the QUIC packet relative to the client and server roles of the connection. Assigned values are maintained in the quicSenderDirection Values subregistry.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: determined from the packet's sender and the exporter's connection-specific knowledge of which endpoint initiated the connection; it is not a QUIC protocol field. The exporter MUST retain the role association across address changes and MUST NOT infer it solely from a particular address-port tuple. Applicability: every QUIC-packet observation record in the Endpoint Packet Observation Profile, whether a top-level record in the base variant or a child record in the sampled variant. Scope: one value per packet observation. Aggregation: one value per observed packet. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.6. This IE is a Flow Key and is mandatory in that profile. If the sender role cannot be determined, the exporter cannot emit the packet using the Endpoint Packet Observation Profile. The Flow-Aggregate Profile instead uses the ordered source/destination 5-tuple and flowDirection; the Connection-State Profile is scoped to the connection rather than to one sender direction.
Reference:
[this document]

6.1.12. quicPacketNumberSpace

Name:
quicPacketNumberSpace
ElementID:
TBD12
Description:
Identifies the QUIC packet-number space of the observed packet. Assigned values are maintained in the quicPacketNumberSpace Values subregistry. 0-RTT and 1-RTT packets share the Application Data packet-number space.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: determined by the exporter from the QUIC packet type using the applicable version's packet formats. For QUIC v1 and v2, Initial packets use value 0, Handshake packets use value 1, and 0-RTT and 1-RTT packets use value 2. Applicability: Initial, 0-RTT, Handshake, and 1-RTT packets. Version Negotiation and Retry packets have no packet-number field, and a confirmed Stateless Reset has no semantic packet number, so none is assigned a space. Scope: one value per QUIC-packet observation record in the Endpoint Packet Observation Profile, whether a top-level record in the base variant or a child record in the sampled variant. Aggregation: one value per observed packet. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.5. This IE is a Flow Key and is mandatory in that profile. The Flow-Aggregate and Connection-State profiles do not carry it. An exporter MUST NOT apply the v1/v2 mapping to an unknown future version without its version-specific specification. See Section 12.3 of [RFC9000] for QUIC packet-number spaces.
Reference:
[this document]

6.1.13. quicFrameOffset

Name:
quicFrameOffset
ElementID:
TBD13
Description:
The offset, in octets, of the first Frame Type octet of a QUIC frame from the first octet of the plaintext payload of the containing QUIC packet. The first frame has an offset of zero.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from endpoint plaintext protocol state or while parsing the plaintext packet payload after successful packet-protection processing. For a supported-version Initial packet, a passive observer can do this when it has the required client Initial Destination Connection ID, captured bytes, and packet-number context; other encryption levels normally require the corresponding traffic keys. Applicability and scope: one value per completely parsed frame in the frame subTemplateList of the Endpoint Packet Observation Profile. Aggregation: not aggregated; frame records are ordered by this offset. Range: 0 to 2^32-1. The value MUST be less than the plaintext payload length of the containing packet. If the start of a frame cannot be determined, the exporter MUST NOT emit a frame record for it; the packet's quicProcessingStatus reports why processing stopped.
Reference:
[this document]

6.1.14. quicFrameLength

Name:
quicFrameLength
ElementID:
TBD14
Description:
The total encoded plaintext extent, in octets, of a QUIC frame, from its first Frame Type octet through its final octet in the containing packet. This is not a frame-specific Length field; QUIC has no generic frame length prefix.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from endpoint plaintext protocol state or while parsing the plaintext packet payload after successful packet-protection processing. For a supported-version Initial packet, a passive observer can do this when it has the required client Initial Destination Connection ID, captured bytes, and packet-number context; other encryption levels normally require the corresponding traffic keys. Applicability and scope: one value per completely parsed frame in the frame subTemplateList of the Endpoint Packet Observation Profile. Aggregation: not aggregated. Range: 1 to 2^32-1. The extent includes the encoded Frame Type and every encoded field and payload octet belonging to the frame; it is not merely the value of a frame-specific Length field. The extent MUST fit within the plaintext payload of the containing packet. If the complete extent cannot be determined, the exporter MUST NOT emit a frame record for it; the packet's quicProcessingStatus reports why processing stopped.
Reference:
[this document]

6.1.15. quicPacketOffset

Name:
quicPacketOffset
ElementID:
TBD15
Description:
The offset, in octets, of the first header octet of a QUIC packet from the first octet of the enclosing UDP payload. The first packet in the UDP payload has an offset of zero.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from the position of a packet whose start the exporter has determined in the captured UDP payload; no QUIC payload decryption is required. Applicability and scope: one value per QUIC packet start that the exporter has determined in the Network-Wire Observation Profile's or sampled Endpoint Packet Observation Profile's packet subTemplateList. The first candidate packet begins at offset zero even when an unsupported version prevents determining its end. Aggregation: not aggregated; packet records are ordered by this offset. Range: 0 to 2^32-1. The value MUST be less than the UDP payload length. An exporter MUST NOT infer a later packet offset by applying the length rules of a QUIC version it does not support. If a packet start or the preceding packet boundary cannot be determined, the exporter MUST NOT emit a packet record for that undetermined occurrence; quicDatagramParseStatus on the parent record reports the incomplete enumeration. This IE is distinct from quicFrameOffset, which is relative to the first plaintext payload octet of a QUIC packet.
Reference:
[this document]

6.1.16. quicPacketDeltaCount

Name:
quicPacketDeltaCount
ElementID:
TBD16
Description:
The number of completely delimited QUIC packets assigned to the observation represented by the enclosing record during the exported observation interval. This is a QUIC-packet counter and is distinct from packetDeltaCount, which counts outer IP packets.
Abstract Data Type:
unsigned64
Data Type Semantics:
deltaCounter
Units:
packets
Additional Information:
Derivation: incremented once for every completely delimited QUIC packet assigned to the observation represented by the enclosing record. When PSAMP packet selection is active, only QUIC packets completely delimited in the UDP payload of outer IP packets selected under the reported Selection Sequence are eligible. The counter is independent of whether a structured-data child record is exported for that packet. Applicability: the Flow-Aggregate and Connection-State profiles. Scope: the observation interval and directionality represented by the enclosing record; the Flow-Aggregate Profile is unidirectional, while the Connection-State Profile covers the connection observation identified by its Options Scope. Aggregation: one delta value per interval; when selection is active, it counts only those eligible inner packets of selected outer IP packets. Range: 0 to 2^64-1. The exporter MUST set the quicPacketDeltaCount bit in quicFieldPresence only when the count is complete for the interval under that selection method. Otherwise, a fixed Template carries zero as an ignored placeholder and the presence bit is clear. A zero value with the presence bit set is a complete count of zero.
Reference:
[this document]

6.1.17. quicObservationSource

Name:
quicObservationSource
ElementID:
TBD17
Description:
Identifies the source from which a QUIC packet observation was obtained. It reports provenance independently of the processing result in quicProcessingStatus and is not a confidence scale.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned from the component that supplied the exported values. Applicability and scope: one value per packet observation in the Network-Wire and Endpoint Packet Observation profiles. In the Flow-Aggregate and Connection-State profiles, one value identifies the source of the first observation that satisfied the profile's QUIC-admission rule. Aggregation: not aggregated. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.2. Value assignments: 0 = Unknown; 1 = Passive wire observation; 2 = Endpoint protocol state, including a terminating QUIC proxy acting as an endpoint for the observed connection; 3 = Authorized cooperating device that is not an endpoint and that was supplied the applicable connection context or keys. Value 0 is used when the source cannot be determined. An exporter MUST report the actual source and MUST NOT change it merely because processing progressed further. For example, successful passive Initial processing remains source 1, while the success is reported by quicProcessingStatus. See Section 3.1 of [RFC9312] for the limits of passive QUIC detection.
Reference:
[this document]

6.1.18. quicProcessingStatus

Name:
quicProcessingStatus
ElementID:
TBD18
Description:
Identifies the processing result for a QUIC packet observation independently of quicObservationSource. The numeric values are discrete outcomes and do not form an increasing confidence scale.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter from the processing actually performed and the condition, if any, that stopped it. Applicability and scope: one value per packet observation in the Network-Wire and Endpoint Packet Observation profiles. In the Flow-Aggregate and Connection-State profiles, one value records the processing result for the first observation that satisfied the profile's QUIC-admission rule. Aggregation: not aggregated. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.3. Value assignments: 0 = Unknown, not attempted, or not applicable; 1 = Heuristic classification only; 2 = Version-independent fields parsed from raw wire evidence; 3 = Supported-version packet structure parsed; 4 = Initial packet protection successfully processed; 5 = Protected content available from endpoint state or from the applicable non-Initial traffic keys; 6 = Retry Integrity Tag validated; 7 = Unsupported version prevented the required version-specific processing; 8 = Structurally malformed packet; 9 = Capture truncated; 10 = Packet-protection or payload-authentication failure; 11 = Retry Integrity Tag validation failure; 12 = Unsupported frame type or frame format prevented complete frame enumeration after plaintext became available; 13 = A local parser or processing-resource limit prevented complete protocol parsing; 14 = The entire received UDP datagram was identified as a Stateless Reset by applying Section 10.3.1 of [RFC9000]: its final 16 octets matched an eligible token for the remote address, associated with a Connection ID that was used and had not been retired. Status 12 applies to an Endpoint Packet Observation for which frame enumeration was attempted. Status 13 can apply to packet-field or frame parsing. The exporter MUST use the status that describes the values represented in the record and MUST NOT report fields whose derivation depended on an operation that failed. Status 4 indicates only successful processing under publicly derivable Initial keys and does not authenticate the peer. Status 6 likewise has only the security properties of the version-specific Retry Integrity Tag. When several conditions could apply, the exporter reports the condition that terminated the processing represented by the record: capture truncation when required captured octets are missing; malformed input only after a supported parser detects a structural violation; unsupported version when sufficient invariant fields are present but no applicable version parser exists; an authentication-failure value only when that validation was attempted; unsupported frame parsing only when plaintext is available but the local decoder cannot determine an encountered frame's complete extent; Stateless Reset confirmation only after the complete datagram-level token check described above. A record with status 14 MUST use quicObservationSource 2 (Endpoint protocol state) or 3 (Authorized cooperating device); token state is not passive wire evidence. Lack of local support for a frame type or format, or exhaustion of a local processing limit, does not make the packet malformed. Local policy suppression and local export-resource or representation-size limits are independent export outcomes reported in quicExportFlags; they MUST NOT overwrite this processing result.
Reference:
[this document]

6.1.19. quicDestinationConnectionIdLengthSource

Name:
quicDestinationConnectionIdLengthSource
ElementID:
TBD19
Description:
Indicates how the exporter determined the length and context of a Destination Connection ID field for the observed packet, or that no applicable length was available. This is significant for Short Header packets, whose header does not carry an explicit Destination Connection ID length.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter based on the actual mechanism used to determine the Destination Connection ID length; the exporter MUST report the actual source used. Applicability: packet observations whose fixed Template includes this IE. Values 1 through 3 apply when a Destination Connection ID is semantically present: for Long Header packets, the explicit length field is the source (value 1); for Short Header packets, the length must come from learned connection context or management configuration (values 2 and 3). Value 0 applies when the packet has no semantic Destination Connection ID field. Value 4 applies when a field may exist but its length cannot be determined. Scope: one value per packet observation that includes this IE. Aggregation: not aggregated. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.4. Value assignments: 0 = Not applicable because no Destination Connection ID is semantically present; 1 = Explicit Long Header length field; 2 = Learned connection context, including a peer-issued Connection ID associated with the applicable connection and direction; 3 = Management configuration; 4 = Unknown because the length could not be determined. When value 0 or 4 is reported, the quicDestinationConnectionId presence bit is clear and a fixed Template carries an empty ignored placeholder. When a present Destination Connection ID has zero length, the presence bit is set even though its octetArray is empty, and this IE reports the applicable source value 1, 2, or 3.
Reference:
[this document]

6.1.20. quicToken

Name:
quicToken
ElementID:
TBD20
Description:
The raw Token octets carried in a type-specific field of a supported-version Long Header packet, as present on the wire. For QUIC version 1, this is the Token following the Token Length field of an Initial packet or the Retry Token preceding the Retry Integrity Tag. The content is opaque observational evidence; this IE does not assert that the Token is valid.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the wire according to the packet format of the supported QUIC version; no QUIC payload decryption is required. Applicability for QUIC versions 1 and 2: Initial and Retry packets only. Version Negotiation, 0-RTT, Handshake, and Short Header packets do not carry this field. Scope: one value per packet observation. Aggregation: not aggregated. Length: for an Initial packet, the value has the length encoded by Token Length and that length MUST NOT exceed the bytes remaining in the delimited packet; for a Retry packet, the value occupies the bytes after the Source Connection ID and before the version-defined 16-octet Retry Integrity Tag. These rules MUST NOT be applied to an unknown future version. When the field is present, including an Initial Token whose encoded length is zero, the quicToken presence bit is set; a present zero-length Token is encoded as an empty octetArray. For packet types without the field, or when its complete extent cannot be established because the version is unsupported, capture is truncated, the packet is malformed, or local export limits prevent complete export, the bit is clear and a fixed Template carries an empty ignored placeholder. quicProcessingStatus reports protocol or capture failure; quicExportFlags reports a local export limit. See Sections 17.2.2 and 17.2.5 of [RFC9000].
Reference:
[this document]

6.1.21. quicFieldPresence

Name:
quicFieldPresence
ElementID:
TBD21
Description:
A bitmap that identifies which accompanying optional QUIC fields in the same Data Record are semantically present. It distinguishes an absent or unavailable field from a valid zero numeric value or zero-length value encoded in a fixed Template.
Abstract Data Type:
unsigned32
Data Type Semantics:
flags
Additional Information:
Derivation: set by the exporter for the particular Data Record. Applicability and scope: the bits apply only to the corresponding fields in that same Data Record, including a frame child record when used there. Aggregation: not aggregated. Range: the following masks are assigned in the Section 6.2.8: 0x00000001 = quicVersion; 0x00000002 = quicSupportedVersion; 0x00000004 = quicDestinationConnectionId; 0x00000008 = quicSourceConnectionId; 0x00000010 = quicToken; 0x00000020 = quicStreamId; 0x00000040 = quicPacketDeltaCount; 0x00000080 = quicPacketLength. Masks 0x00000100 through 0x80000000 are unassigned. An exporter MUST set an assigned bit only when the corresponding IE occurs in the same record and carries a semantically present complete value. When an assigned bit is clear and a fixed Template contains that IE, the exporter encodes zero for a numeric IE, an empty octetArray, or an empty list, as applicable, and the collector MUST ignore that placeholder. When the bit is set, zero or an empty value is the actual value. Exporters MUST set unassigned bits to zero; collectors MUST ignore bits they do not recognize so that future assignments remain interoperable.
Reference:
[this document]

6.1.22. quicDatagramParseStatus

Name:
quicDatagramParseStatus
ElementID:
TBD22
Description:
Identifies whether a parent datagram record in the Network-Wire Observation Profile or sampled Endpoint Packet Observation Profile completely enumerated and delimited the QUIC packets in the enclosing UDP payload and, if not, why packet-boundary enumeration stopped.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter after processing one UDP payload. Applicability and scope: one value on the parent datagram record of the Network-Wire Observation Profile or sampled Endpoint Packet Observation Profile. Aggregation: not aggregated. Range: 0 to 254; value 255 is Reserved and MUST NOT be exported. Assigned values are maintained in the Section 6.2.7. Value assignments: 0 = Unknown or not reported; 1 = Complete, meaning every octet of the UDP payload was accounted for by completely delimited QUIC packets; 2 = Partial because an unsupported QUIC version prevented determination of a packet boundary; 3 = Partial because capture truncation prevented complete packet-boundary enumeration; 4 = Partial because malformed input prevented complete packet-boundary enumeration; 5 = Partial because a local parser or processing-resource limit prevented complete packet-boundary enumeration. A child packet record normally represents a completely delimited packet. As the sole exception, the Network-Wire Observation Profile permits an exporter to emit one terminal partial child record at the offset where parsing stopped when the packet's complete invariant Long Header prefix was captured but an unsupported version prevents boundary determination. In that record the quicPacketLength presence bit is clear, fields beyond the invariant prefix are absent, and quicProcessingStatus reports the unsupported version. No child record after that offset can be inferred. This IE describes completeness of packet-boundary enumeration, regardless of whether all parsed child records were exported. Export omission is reported by quicExportFlags. This IE does not report cryptographic validation of individual packets, which is reported by quicProcessingStatus.
Reference:
[this document]

6.1.23. quicPacketLength

Name:
quicPacketLength
ElementID:
TBD23
Description:
The total wire length, in octets, of one completely delimited QUIC packet, from its first header octet through its final octet. It excludes the enclosing UDP and IP headers.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from packet boundaries determined under the applicable supported QUIC version and available connection context. For a confirmed Stateless Reset, the boundary is the entire UDP payload as specified in Section 10.3 of [RFC9000]. Applicability and scope: one value per completely delimited packet in the Network-Wire or Endpoint Packet Observation Profile. Aggregation: not aggregated. Range: 1 to 2^32-1. For packet formats with an explicit Length field, the exporter applies the length rules of the supported version. A Version Negotiation packet, a Retry packet, or a Short Header packet occupies the applicable remainder of its UDP payload under the version's packet coalescing rules. An exporter MUST NOT apply these rules to an unknown future version. When the complete boundary cannot be determined, the quicPacketLength bit in quicFieldPresence is clear and a fixed Template carries zero as an ignored placeholder; the appropriate processing or datagram parse status reports the reason. When the packet length is otherwise available but local export policy or a resource limit prevents its export, the presence bit is clear and quicExportFlags reports that independent export outcome. A zero value is never a present packet length.
Reference:
[this document]

6.1.24. quicExportFlags

Name:
quicExportFlags
ElementID:
TBD24
Description:
Flags reporting whether otherwise available QUIC information in the same record or a child list directly carried by that record was not exported because of a local resource or size limit in the export path, configured export-policy suppression, or both.
Abstract Data Type:
unsigned8
Data Type Semantics:
flags
Additional Information:
Derivation: assigned by the exporter from conditions in its local export path. Applicability and scope: one value per top-level record in every profile defined by this document. Network-Wire and sampled Endpoint inner-packet records also carry this IE for omissions scoped to that packet. A value in a record describes omissions from fields in that record and from child lists directly carried by it. Aggregation: not aggregated. A zero value means that export was complete under the applicable profile. Bit 0 (mask 0x01) means that a local export-resource, representation-size, or record-size limit prevented complete export. Bit 1 (mask 0x02) means that configured export policy suppressed otherwise available information. The bits can be set together. Bits 2 through 7 are unassigned; exporters MUST set them to zero, and collectors MUST ignore bits they do not recognize. Assignments are maintained in the Section 6.2.9. If an affected field has a quicFieldPresence bit, that bit is clear and its fixed- Template placeholder is ignored. If a child list is affected, this IE is set in the record containing that list. A complete Network-Wire parse followed by export truncation or policy suppression therefore has quicDatagramParseStatus 1 and a nonzero quicExportFlags value. This IE reports an export outcome; it does not replace quicObservationSource or quicProcessingStatus.
Reference:
[this document]

6.2. QUIC IPFIX Value Subregistries

In accordance with Section 4.7 of [RFC7013], IANA is requested to create the following subregistries under the "IPFIX Information Elements" registry. An enumeration registry has Value, Name, and Reference columns. A flags registry has Bit, Mask, Name (or Accompanying Information Element), and Reference columns. Only entries or bit positions marked Unassigned are available for future assignment; each such assignment requires Expert Review as defined by [RFC8126] and a stable public reference. An entry marked Reserved is not available under that policy. The designated experts are requested to verify that a new assignment has a stable, interoperable meaning, does not duplicate an existing value, and, where it interprets a QUIC protocol construct, is supported by an appropriate QUIC specification. The initial assigned and Reserved entries below have this document as their reference; two hyphens identify an Unassigned range that has no reference.

An exporter MUST NOT emit an enumeration value marked Unassigned or Reserved. A collector that does not yet recognize a subsequently assigned value MUST preserve its numeric value and MUST NOT reinterpret it as the registry's Unknown value.

6.2.1. quicPacketType Values (Value TBD3) 

Value  Name                 Reference
0      Unknown              [this document]
1      Version Negotiation  [this document]
2      Initial              [this document]
3      0-RTT                [this document]
4      Handshake            [this document]
5      1-RTT                [this document]
6      Stateless Reset      [this document]
7      Retry                [this document]
8-254  Unassigned           --
255    Reserved             [this document]

6.2.2. quicObservationSource Values (Value TBD17) 

Value  Name                                      Reference
0      Unknown                                   [this document]
1      Passive wire observation                  [this document]
2      Endpoint protocol state                   [this document]
3      Authorized cooperating non-endpoint device [this document]
4-254  Unassigned                                --
255    Reserved                                  [this document]

6.2.3. quicProcessingStatus Values (Value TBD18) 

Value  Name                                      Reference
0      Unknown/not attempted/not applicable      [this document]
1      Heuristic classification only             [this document]
2      Version-independent fields parsed         [this document]
3      Supported-version structure parsed        [this document]
4      Initial protection processed              [this document]
5      Protected content available               [this document]
6      Retry Integrity Tag validated              [this document]
7      Unsupported version                       [this document]
8      Structurally malformed packet             [this document]
9      Capture truncated                         [this document]
10     Packet/payload authentication failure     [this document]
11     Retry Integrity Tag validation failure    [this document]
12     Unsupported frame type or format          [this document]
13     Local parser or processing-resource limit [this document]
14     Stateless Reset datagram confirmed        [this document]
15-254 Unassigned                                --
255    Reserved                                  [this document]

6.2.4. quicDestinationConnectionIdLengthSource Values (Value TBD19) 

Value  Name                               Reference
0      Not applicable                     [this document]
1      Explicit Long Header length field  [this document]
2      Learned connection context         [this document]
3      Management configuration           [this document]
4      Unknown                            [this document]
5-254  Unassigned                         --
255    Reserved                           [this document]

6.2.5. quicPacketNumberSpace Values (Value TBD12) 

Value  Name              Reference
0      Initial           [this document]
1      Handshake         [this document]
2      Application Data  [this document]
3-254  Unassigned        --
255    Reserved          [this document]

6.2.6. quicSenderDirection Values (Value TBD11) 

Value  Name              Reference
0      Client-to-server  [this document]
1      Server-to-client  [this document]
2-254  Unassigned        --
255    Reserved          [this document]

6.2.7. quicDatagramParseStatus Values (Value TBD22) 

Value  Name                                      Reference
0      Unknown or not reported                   [this document]
1      Complete                                  [this document]
2      Partial: unsupported version              [this document]
3      Partial: capture blocked delimitation     [this document]
4      Partial: malformed input blocked delimitation [this document]
5      Partial: local parser/resource limit      [this document]
6-254  Unassigned                                --
255    Reserved                                  [this document]

6.2.8. quicFieldPresence Bit Assignments (Value TBD21) 

Bit   Mask        Accompanying IE              Reference
0     0x00000001  quicVersion                  [this document]
1     0x00000002  quicSupportedVersion         [this document]
2     0x00000004  quicDestinationConnectionId  [this document]
3     0x00000008  quicSourceConnectionId       [this document]
4     0x00000010  quicToken                    [this document]
5     0x00000020  quicStreamId                 [this document]
6     0x00000040  quicPacketDeltaCount         [this document]
7     0x00000080  quicPacketLength             [this document]
8-31              Unassigned                   --

6.2.9. quicExportFlags Bit Assignments (Value TBD24) 

Bit  Mask  Name                                  Reference
0    0x01  Local export-resource/size truncation [this document]
1    0x02  Configured export-policy suppression  [this document]
2-7        Unassigned                            --

7. Operational Considerations

A Short Header does not encode its Destination Connection ID length. Therefore, an exporter can report a Short Header Destination Connection ID only when it has already associated the packet with a connection and knows the length selected by the receiving endpoint. During connection establishment, a peer's Source Connection ID can supply a Connection ID that the other peer subsequently uses as a Destination Connection ID, but an exporter MUST establish the applicable connection and direction before using that information. It MUST NOT treat an arbitrary prior Long Header Destination Connection ID as the length context for a later Short Header. Connection ID rotation can introduce values in protected NEW_CONNECTION_ID frames, so following later rotations generally requires endpoint protocol state, the applicable traffic keys, or deployment configuration. If the exporter lacks reliable connection and length context, it MUST clear the Destination Connection ID presence bit and MUST NOT guess the value.

Availability of QUIC fields depends on packet type and processing context. Version Negotiation packets have neither packet protection nor header protection. Retry packets also have neither packet protection nor header protection and carry no packet number; their version-specific Retry Integrity Tag is a separate integrity mechanism. Initial packets use packet protection and header protection, but for QUIC versions 1 and 2 the keys are derived from public version-specific constants and the Destination Connection ID of the client's Initial packet. Consequently, a passive observer can process a supported-version Initial packet when it has that Destination Connection ID, direction and packet-number context, and sufficient captured bytes. Successful Initial processing does not authenticate the peer and does not provide confidentiality from an on-path observer. Processing Handshake, 0-RTT, and 1-RTT packets requires the corresponding traffic secrets or keys derived from them. A Stateless Reset has no semantic packet number or frame sequence.

quicFirstOctet is available only when the first packet octet was captured. quicVersion and the two Connection ID length fields are invariant only in a sufficiently complete Long Header [RFC8999]. A Short Header Destination Connection ID requires the connection-specific length context described above. quicPacketType requires the applicable version-specific mapping, except that a zero Long Header Version field identifies Version Negotiation. An exporter MUST classify a Short Header as Unknown unless endpoint state or successful packet-protection processing establishes 1-RTT, and it MUST classify a possible Stateless Reset as Unknown unless the entire UDP datagram satisfies the token-matching procedure in Section 10.3.1 of [RFC9000]. A confirmed Stateless Reset consumes the entire datagram and has no semantic Destination Connection ID, Source Connection ID, Version, packet number, or frame sequence.

In a successfully processed supported-version Initial packet, a passive observer can reconstruct quicPacketNumber and decode permitted Initial frame types, offsets, and lengths. Valid Initial packets do not carry stream-related frames, so Initial processing does not make quicStreamId available. Values from other protected packets require endpoint protocol state or the corresponding traffic keys. An endpoint can also export sender-side semantic values from protocol state before wire protection is applied; such values are not raw observations and MUST be marked with the corresponding quicObservationSource and quicProcessingStatus.

quicObservationSource records where exported semantic values originated, and quicProcessingStatus records the processing result. The two IEs are independent and neither is an ordered confidence score. Exporters MUST preserve failure outcomes such as unsupported version, malformed input, capture truncation, packet-protection failure, and Retry Integrity Tag failure instead of reporting them as successful lower-level processing. A device that receives traffic secrets through a deployment-specific mechanism MUST protect them and MUST NOT log or export them in IPFIX records, as noted in Section 5.

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5103]
Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, DOI 10.17487/RFC5103, , <https://www.rfc-editor.org/info/rfc5103>.
[RFC5476]
Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, DOI 10.17487/RFC5476, , <https://www.rfc-editor.org/info/rfc5476>.
[RFC6313]
Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, , <https://www.rfc-editor.org/info/rfc6313>.
[RFC7011]
Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, , <https://www.rfc-editor.org/info/rfc7011>.
[RFC7012]
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, , <https://www.rfc-editor.org/info/rfc7012>.
[RFC7013]
Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements", BCP 184, RFC 7013, DOI 10.17487/RFC7013, , <https://www.rfc-editor.org/info/rfc7013>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8999]
Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, , <https://www.rfc-editor.org/info/rfc8999>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/info/rfc9000>.
[RFC9001]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/info/rfc9001>.
[RFC9287]
Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, , <https://www.rfc-editor.org/info/rfc9287>.
[RFC9368]
Schinazi, D. and E. Rescorla, "Compatible Version Negotiation for QUIC", RFC 9368, DOI 10.17487/RFC9368, , <https://www.rfc-editor.org/info/rfc9368>.
[RFC9369]
Duke, M., "QUIC Version 2", RFC 9369, DOI 10.17487/RFC9369, , <https://www.rfc-editor.org/info/rfc9369>.

8.2. Informative References

[IANA-IPFIX]
"IANA, "IP Flow Information Export (IPFIX) Entities"", <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC7270]
Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10.17487/RFC7270, , <https://www.rfc-editor.org/info/rfc7270>.
[RFC9312]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, , <https://www.rfc-editor.org/info/rfc9312>.
[discardmodel]
Evans, J., Pylypenko, O., Haas, J., Kadosh, A., and M. Boucadair, "Information and Data Models for Packet Discard Reporting", Work in Progress draft-ietf-opsawg-discardmodel, , <https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/>.
[ipfix-discard-class-ie]
Evans, J., Pylypenko, O., and K. Cheaito, "Information Element for Flow Discard Classification", Work in Progress draft-evans-opsawg-ipfix-discard-class-ie, , <https://datatracker.ietf.org/doc/draft-evans-opsawg-ipfix-discard-class-ie/>.

Acknowledgements

The authors would like to thank Mohamed Boucadair, Benoit Claise, Chongfeng Xie, Jing Wang, Yarong Wang, Yanrong Liang, Winnie, Saumya Dikshit, Wisdom Tan, Jiangbo Wang, Bing Liu, Xueyan Song, Xiao Min, Gao Xing, Liyan Gong, David Wright, Yujia Gao, Qian Cao, Alex Lee, Shengnan Yue, Yimi Zhang, Guozhen Dong, Hongwei Li, Allan Michael, JunFang Wang, Paul Aitken, Haiyang Zhang, and Liurubing for their support and detailed reviews.

Authors' Addresses

Changwang Lin
New H3C Technologies
8 Yongjia North Road
Beijing
Haidian District, 100094
China
Yisong Liu
China Mobile
32 Xuanwumen West Street
Beijing
Xicheng District, 100053
China
Yao Liu
ZTE
Nanjing
China
Xueting Li
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Aditya Dogra
Cisco Systems
Sarjapur Outer Ring Road
Bangalore 560103
Karnataka
India