Jump to content

RFC 9000

For implications on Internet governance, see QUIC and HTTP/3.

RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, is an IETF standards-track RFC that defines the core QUIC transport protocol. QUIC provides applications with flow-controlled streams over UDP, enabling secure, multiplexed, low-latency connections with support for connection migration and integrated congestion control. It was published in May 2021 as the main output of the IETF QUIC Working Group.[1][2] Subsequent RFCs extend QUIC with new versions, manageability guidelines and additional features, but RFC 9000 remains the reference document for the core transport semantics and wire format of IETF QUIC.[3][4]

Background[edit | edit source]

QUIC originated as a Google transport protocol (gQUIC) deployed experimentally from 2012, aiming to reduce web latency and to move congestion control and transport evolution into user space over UDP.[5] Early deployments carried HTTP traffic between Chrome and Google services and demonstrated performance gains over TCP+TLS+HTTP/2 by avoiding head-of-line blocking at the connection level and shortening connection setup.[6]

In 2016 the IETF chartered the QUIC Working Group to standardise a version of QUIC distinct from gQUIC, with encrypted transport headers, a stable wire image and a versioning scheme resilient to middlebox ossification.[5][7] RFC 9000 and its companion documents (RFC 8999, 9001, 9002) were published in May 2021 and define "IETF QUIC", which underpins HTTP/3 and other newer application protocols.[1][8][3]

Protocol Overview[edit | edit source]

RFC 9000 specifies a connection-oriented transport protocol running over UDP. Endpoints maintain QUIC connections identified by versioned wire formats and opaque connection IDs, decoupling logical connections from the underlying IP address and UDP port, enabling migration across network paths (for example, when a mobile device changes access networks).[1][8][4]

Within a connection, QUIC provides lightweight, flow-controlled streams that carry ordered byte streams in each direction. Streams are multiplexed into QUIC packets using typed frames, and loss or blocking on one stream does not stall others, removing the connection-level head-of-line blocking that affects HTTP/2 over TCP.[1][9][5] The specification defines separate flow-control windows for streams and for the connection as a whole, allowing endpoints to limit resource usage and to prioritise streams.

Connection establishment and security are tightly integrated with cryptography. RFC 9000 mandates that QUIC be secured by a cryptographic handshake and references RFC 9001, which defines the mandatory mapping of QUIC to TLS 1.3.[1][10] The TLS 1.3 handshake provides 1-RTT connection setup for new peers and 0-RTT resumption in many cases, while deriving the traffic keys used to encrypt almost all QUIC headers and payloads.[10] Only a small, version-invariant portion of the header remains visible on the wire, as captured by RFC 8999.[8]

Loss detection and congestion control are part of the QUIC transport design, but the detailed algorithms are delegated to RFC 9002.[11] RFC 9002 specifies acknowledgement handling, packet number spaces and congestion-control behaviour inspired by TCP NewReno and CUBIC, adapted for QUIC’s encrypted headers and multiple packet number spaces.[11][3]

Security and Privacy Properties[edit | edit source]

From the outset, QUIC is specified as an always-encrypted transport. Application data and most control information are protected using Authenticated Encryption with Associated Data algorithms and keys established by TLS 1.3, providing confidentiality, integrity and peer authentication properties that are comparable to or stronger than TCP+TLS.[1][10] Header protection conceals fields such as packet numbers from passive observers, reducing the amount of transport metadata exposed to on-path devices and limiting opportunities for protocol ossification and interference by middleboxes.[8][7]

The protocol includes anti-amplification limits and address validation mechanisms designed to mitigate reflection and amplification attacks, particularly during connection establishment. Servers can require clients to prove reachability of their source address (e.g. using Retry packets) before sending significantly more data than they have received.[1] Together with connection IDs and path validation procedures, these mechanisms help QUIC operate robustly in the presence of NATs, address translation and mobility, while constraining abuse of spoofed addresses.

Deployment and Applications[edit | edit source]

RFC 9000 is the transport foundation for HTTP/3, standardised in RFC 9114 as a mapping of HTTP semantics onto QUIC streams.[9] HTTP/3 reuses QUIC’s stream multiplexing, flow control, and low-latency connection establishment to improve Web performance compared with HTTP/2 over TCP.[9][5] Measurements by operators such as Cloudflare and independent studies show increasing shares of HTTP traffic using HTTP/3/QUIC as browsers and servers enable it by default.[12][13]

Beyond HTTP, QUIC is used as a general-purpose transport for other protocols. RFC 9250 specifies DNS over QUIC (DoQ), using QUIC to encrypt DNS queries and responses with latency characteristics similar to classic DNS over UDP but with transport-level confidentiality.[14] Operator and vendor reports describe growing, though still limited, deployment of DoQ in recursive resolvers and authoritative servers.[15][16]

Major browsers (Chrome, Edge, Firefox, Safari) and large content providers (including Google, Meta and others) support QUIC, and operating-system and application stacks expose APIs or libraries that implement RFC 9000 and its extensions.[5][17][18]

References[edit | edit source]

  1. ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 J. Iyengar, M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, IETF, May 2021.
  2. ↑ RFC Editor, "Information on RFC 9000" (accessed 2025-12-08).
  3. ↑ 3.0 3.1 3.2 Y.-X. Chen et al., "RFC 9000 and its Siblings: An Overview of QUIC Standards", Technische Universität München, 2024.
  4. ↑ 4.0 4.1 IANA, "QUIC Parameters" (accessed 2025-12-08).
  5. ↑ 5.0 5.1 5.2 5.3 5.4 "QUIC", Wikipedia (accessed 2025-12-08).
  6. ↑ S. Carrel-Billiard, "QUIC Analysis – A UDP-Based Multiplexed and Secure Transport", Michelin, 30 June 2022.
  7. ↑ 7.0 7.1 "Demystifying QUIC from the Specifications", arXiv preprint 2511.08375, 11 November 2025.
  8. ↑ 8.0 8.1 8.2 8.3 M. Thomson, "Version-Independent Properties of QUIC", RFC 8999, IETF, May 2021.
  9. ↑ 9.0 9.1 9.2 J. Bishop, "HTTP/3", RFC 9114, IETF, June 2022.
  10. ↑ 10.0 10.1 10.2 M. Thomson, S. Turner, "Using TLS to Secure QUIC", RFC 9001, IETF, May 2021.
  11. ↑ 11.0 11.1 IETF, "QUIC Loss Detection and Congestion Control", RFC 9002, IETF, May 2021.
  12. ↑ Cloudflare, "A Cloudflare view of HTTP usage trends", 6 June 2022.
  13. ↑ "Usage of HTTP/3 for websites", W3Techs (accessed 2025-12-08).
  14. ↑ C. Huitema et al., "DNS over Dedicated QUIC Connections", RFC 9250, IETF, May 2022.
  15. ↑ NLnet Labs, "DNS-over-QUIC in Unbound", 17 October 2024.
  16. ↑ SIDN, "New DNS over QUIC protocol makes encrypted DNS traffic faster and more efficient", 25 August 2022.
  17. ↑ "QUIC", Wikipédia em português (accessed 2025-12-08).
  18. ↑ Microsoft, ".NET QUIC overview" (accessed 2025-12-08).

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Hypertext Transfer Protocol. Application-level protocol for distributed, collaborative, hypermedia information systems (RFC 2616).

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

Application Programming Interface is a set of rules or protocols that enables software applications to communicate with each other to exchange data, features and functionality (IBM).

Retrieved from "https://icannwiki.org/index.php?title=RFC_9000&oldid=1398561"
Semantic properties for "RFC 9000"
RDF feed