Unbound DATA for CONNECT in HTTP/3

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 23 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[HTTP/3] transmits message content on client-initiated bidirectional QUIC streams. On these streams, the request and response messages are carried using a sequence of HTTP/3 frames. The DATA frame is used to encapsulate octets of the opaque data associated with CONNECT and its extensions.¶

CONNECT and extended CONNECT establish long-lived bidirectional tunnels. These tunnels commonly carry transport protocols (TCP [CONNECT-TCP], UDP [CONNECT-UDP], IP [CONNECT-IP], Ethernet [CONNECT-ETHERNET], [WebSockets], [WebTransport]) that produce arbitrarily fragmented and continuous byte streams. Senders therefore generate large numbers of DATA frames whose boundaries have no semantic meaning. Although DATA frames are lightweight, each adds framing overhead and requires the sender to manage frame boundaries. For long-lived or high-volume streams, this overhead is unnecessary because the end of the QUIC stream already provides a natural message boundary.¶

According to Section 4.4 of [HTTP/3], once HTTP/3 CONNECT tunnel is established, the stream carries opaque bytes until the QUIC FIN. CONNECT streams do not carry trailers and no additional HTTP frames are defined after tunnel establishment. Therefore, ceasing frame parsing after UNBOUND_DATA does not change HTTP semantics and only removes framing overhead.¶

This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that endpoints use to negotiate support. Once an UNBOUND_DATA frame is sent on a CONNECT stream, all subsequent octets on that stream are interpreted as data. This mechanism eliminates the need to encapsulate each portion of the tunnel payload in separate DATA frames.¶

The goals of UNBOUND_DATA are:¶

• Reduce framing overhead for CONNECT tunnels carrying continuous byte streams.¶

• Simplify sender and receiver state machines by eliminating repeated DATA frame headers.¶

• Enable efficient transport of tunneled protocols carried over CONNECT streams.¶

The use of UNBOUND_DATA does not alter HTTP semantics, flow control, or prioritization; it is strictly a framing optimization.¶

2. Conventions and Definitions

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

3. Capability Negotiation

Endpoints indicate support for unbound data transmission by sending the SETTINGS_ENABLE_UNBOUND_DATA (0x282cf6bb) setting with a value of 1.¶

The valid values of the SETTINGS_ENABLE_UNBOUND_DATA setting are 0 and 1. If the SETTINGS_ENABLE_UNBOUND_DATA setting is received with a different value, the receiver MUST treat it as a connection error of type H3_SETTINGS_ERROR.¶

A value of 1 indicates that the sender of the SETTINGS frame is willing to receive UNBOUND_DATA frames.¶

Endpoints MUST NOT send an UNBOUND_DATA frame to a peer that has not advertised SETTINGS_ENABLE_UNBOUND_DATA with a value of 1. Endpoints that receive an UNBOUND_DATA frame without having advertised support MUST treat it as a connection error of type H3_FRAME_UNEXPECTED.¶

The SETTINGS_ENABLE_UNBOUND_DATA parameter is directional: each endpoint independently advertises whether it accepts receiving UNBOUND_DATA. An endpoint that has not indicated support cannot be assumed to understand or correctly process the frame.¶

4. UNBOUND_DATA Frame

The UNBOUND_DATA frame (type=0x2a937388) is used on CONNECT streams to indicate that all subsequent octets on the stream are interpreted as data.¶

UNBOUND_DATA Frame {
  Type (i) = 0x2a937388,
  Length (8) = 0,
}

5. Stream State Transitions

The use of the UNBOUND_DATA frame modifies the sequence of frames exchanged on request and response streams.¶

In normal operation, a CONNECT request or response is carried as a sequence of one or more DATA frames:¶

When UNBOUND_DATA is used, the sender signals that all subsequent octets on the stream are data. Regular DATA frames MAY be sent on a stream prior to the UNBOUND_DATA. After the UNBOUND_DATA frame, the sender cannot send any further HTTP/3 frames on the stream. The end of the tunnel is signaled by the QUIC stream FIN:¶

6. Security Considerations

The introduction of UNBOUND_DATA does not alter the security properties of HTTP/3 or QUIC. It only changes how the CONNECT payload is framed on request and response streams.¶

7. IANA Considerations

8. References

Acknowledgments

This specification originated from discussions with Christian Huitema and Alan Frindell, whose ideas and feedback helped shape the approach described in this document. The authors also thank Lucas Pardue for providing valuable initial feedback.¶

Authors' Addresses