QUIC Working Group

The IETF QUIC Working Group produced QUIC version 1 — a UDP-based, stream-multiplexing, encrypted transport protocol. The protocol itself is published as RFC 9000, and there are other related RFCs of note, see below.

We are now chartered to be the focal point for any QUIC-related work in the IETF. Our work covers maintenance and evolution of published specifications, the deployability of QUIC, and new extensions to QUIC.

The QUIC Working Group originated HTTP/3, the mapping of HTTP to QUIC, and the QPACK header compression scheme. These are now maintained by the HTTP Working Group.

See our contribution guidelines if you want to work with us.

Upcoming Meetings

IETF 120 Vancouver, 25 July 2024, Session I 09:30-11:30 local time

Core Specifications

The ‘core’ specifications comprising QUIC are:

RFC 8999 - Version-Independent Properties of QUIC - HTML / TXT / PDF
RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport - HTML / TXT / PDF
RFC 9001 - Using TLS to Secure QUIC - HTML / TXT / PDF
RFC 9002 - QUIC Loss Detection and Congestion Control - HTML / TXT / PDF

QUIC Extensions

QUIC can be extended in several ways. The following specifications have been formally standardized as RFCs:

RFC 9221 - An Unreliable Datagram Extension to QUIC - HTML / TXT / PDF
RFC 9287 - Greasing the QUIC Bit - HTML / TXT / PDF
RFC 9368 - Compatible Version Negotiation for QUIC - HTML / TXT / PDF
RFC 9369 - QUIC Version 2 - HTML / TXT / PDF

Applicability and Manageability

Specifications that discuss considerations for application protocol developers using QUIC, and network operators carrying QUIC:

RFC 9308 - Applicability of the QUIC Transport Protocol - HTML / TXT / PDF
RFC 9312 - Manageability of the QUIC Transport Protocol - HTML / TXT / PDF

HTTP/3 and QPACK

We originated the HTTP/3 and QPACK RFCs. Ownership of these drafts has now transferred back to the HTTP WG.

RFC 9114 - HTTP/3 - HTML / TXT / PDF
RFC 9204 - QPACK - HTML / TXT / PDF

In-progress documents

In-progress documents for continued maintenance and evolution of QUIC, as described further in our charter.

Load Balancers - Editors’ Draft / WG Draft / Repo / Open Issues
Acknowledgement Frequency - Editors’ Draft / WG Draft / Repo / Open Issues
qlog
- Main logging Schema Editors’ Draft / WG Draft / Repo / Open Issues
- QUIC event definitions Editors’ Draft / WG Draft / Repo / Open Issues
- HTTP/3 and QPACK event definitions Editors’ Draft / WG Draft / Repo / Open Issues
Multipath Editors’ Draft / WG Draft / Repo / Open Issues
Reliable Reset Editors’ Draft / WG Draft / Repo / Open Issues

Implementing QUIC

There are a range of implementations. Some focus on providing features of the core protocol, while some also include support for in-progress extensions.

Implementers should join the quicdev Slack to coordinate testing; contact the WG chairs for an invitation. Note that discussions on Slack are considered IETF contributions under “Note Well”.

Automated, continuous interop testing is performed for participating QUIC implementations. Implementers are encouraged to join this effort by making compatible Docker images of their implementations available.

Reporting Vulnerabilities

If you believe you’ve discovered a vulnerability in the QUIC protocol (or related IETF protocols) please see the IETF’s guidance on how to report these.

If you believe you’ve discovered an implementation vulnerability in a product, open source project, or service using QUIC, then you should report these directly to the responsible party. The IETF does not have a formal means to reach these parties and cannot do so on your behalf. Implementers or operators often provide their own publicly-available disclosure documents that provide contact details and guidelines for reporters. The implementations wiki may include a link to such documents under the “Vulnerability reporting” field.