Proxying Bound UDP in HTTP
draft-ietf-masque-connect-udp-listen-14

MASQUE                                                       D. Schinazi
Internet-Draft                                                  A. Singh
Intended status: Standards Track                              Google LLC
Expires: 5 February 2027                                   4 August 2026

                       Proxying Bound UDP in HTTP
                draft-ietf-masque-connect-udp-listen-14

Abstract

   The mechanism defined in "Proxying UDP in HTTP" (RFC 9298) only
   allows each UDP proxying request to transmit to a specific host and
   port.  This is well suited for UDP client-server protocols such as
   HTTP/3, but is not sufficient for some UDP peer-to-peer protocols
   like WebRTC.  This document defines an extension to that mechanism
   that enables such use cases.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://ietf-wg-
   masque.github.io/draft-ietf-masque-connect-udp-listen/draft-ietf-
   masque-connect-udp-listen.html.  Status information for this document
   may be found at https://datatracker.ietf.org/doc/draft-ietf-masque-
   connect-udp-listen/.

   Discussion of this document takes place on the MASQUE Working Group
   mailing list (mailto:masque@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/masque/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/masque/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp-
   listen.

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/.

Schinazi & Singh         Expires 5 February 2027                [Page 1]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   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 5 February 2027.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   3
   2.  Bound UDP Proxying Mechanism  . . . . . . . . . . . . . . . .   3
   3.  Context Identifiers . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The COMPRESSION_ASSIGN capsule  . . . . . . . . . . . . .   5
     3.2.  The COMPRESSION_ACK capsule . . . . . . . . . . . . . . .   6
     3.3.  The COMPRESSION_CLOSE capsule . . . . . . . . . . . . . .   7
   4.  Uncompressed Operation  . . . . . . . . . . . . . . . . . . .   8
   5.  Compressed Operation  . . . . . . . . . . . . . . . . . . . .   9
   6.  The Connect-UDP-Bind Header Field . . . . . . . . . . . . . .   9
   7.  The Proxy-Public-Address Response Header Field  . . . . . . .   9
   8.  Proxy Behavior  . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Restricting IPs . . . . . . . . . . . . . . . . . . . . .  10
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   10. Operational Considerations  . . . . . . . . . . . . . . . . .  11
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  HTTP Fields  . . . . . . . . . . . . . . . . . . . . . .  12
     11.2.  Capsules . . . . . . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . .  15
   Appendix B.  Comparison with CONNECT-IP . . . . . . . . . . . . .  17
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Schinazi & Singh         Expires 5 February 2027                [Page 2]
Internet-Draft              CONNECT-UDP Bind                 August 2026

1.  Introduction

   The mechanism to proxy UDP in HTTP [CONNECT-UDP] allows creating
   tunnels for communicating UDP payloads [UDP] to a fixed host and
   port; this enables proxying of HTTP/3 connections, since they run
   over UDP.  Similarly, the HTTP CONNECT method (see Section 9.3.6 of
   [HTTP]) allows proxying HTTP/1.x and HTTP/2, which run over TCP.
   Combining both allows proxying the majority of a Web browser's HTTP
   traffic.  However, WebRTC [WebRTC] relies on Interactive Connectivity
   Establishment (ICE; see [ICE]) to provide connectivity between two
   Web browsers, and ICE relies on the ability to send and receive UDP
   packets to multiple hosts.  While in theory it might be possible to
   accomplish this using multiple UDP proxying HTTP requests, HTTP
   semantics [HTTP] do not guarantee that distinct requests will be
   handled by the same server.  This can lead to the UDP packets being
   sent from distinct IP addresses, thereby preventing ICE from
   operating correctly.  Consequently, UDP proxying requests cannot
   enable WebRTC connectivity between peers.

   This document describes an extension to UDP Proxying in HTTP that
   allows sending and receiving UDP payloads to multiple hosts within
   the scope of a single UDP proxying HTTP request.

1.1.  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.

   This document uses terminology from [CONNECT-UDP] and notational
   conventions from [QUIC].  This document uses the terms Boolean, List,
   and String from Section 3 of [STRUCTURED-FIELDS] to specify syntax
   and parsing.  This document uses Augmented Backus-Naur Form (ABNF)
   and parsing/serialization behaviors from [ABNF].

2.  Bound UDP Proxying Mechanism

   In unextended UDP proxying requests (i.e., requests that use the
   mechanism defined in [CONNECT-UDP] without the extension defined in
   this document), the target host is encoded in the HTTP request path
   or query.  For bound UDP proxying (i.e., the mechanism defined in
   this document), the target is either conveyed in each HTTP Datagram
   (see Section 4), or registered via capsules and then compressed (see
   Sections 3 and 5).

Schinazi & Singh         Expires 5 February 2027                [Page 3]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   When performing URI Template Expansion of the UDP proxying template
   (see Section 3 of [CONNECT-UDP]), the client follows the same
   template as unextended UDP proxying and sets the "target_host" and
   the "target_port" variables to one of its targets.  It adds the
   Connect-UDP-Bind header field as specified in Section 6 to request
   bind.  If the proxy supports bound UDP proxying, it returns the
   Connect-UDP-Bind response header field value set to true.

   When "target_host" and "target_port" are set to a valid target (i.e.,
   they follow the requirements in Section 3 of [CONNECT-UDP]), the
   client is requesting bound UDP proxying but would accept fallback to
   unextended UDP proxying to that target.  If the client does not have
   a specific target, or if it wants bound UDP proxying without
   fallback, it sets both the "target_host" and the "target_port"
   variables to the '*' character (ASCII character 0x2A).  Note that the
   '*' character MUST be percent-encoded before sending, per
   Section 3.2.2 of [TEMPLATE].

   If only one of the "target_host" and the "target_port" variables is
   set to the '*' character, the request is malformed.  The recipient of
   such a malformed request MUST respond with an error and SHOULD use
   the 400 (Bad Request) status code.

3.  Context Identifiers

   As with unextended UDP proxying, the semantics of HTTP Datagrams are
   conveyed by Context IDs (see Section 4 of [CONNECT-UDP]).  Endpoints
   first allocate a new Context ID (per [CONNECT-UDP], clients allocate
   even Context IDs while proxies allocate odd ones), and then use the
   COMPRESSION_ASSIGN capsule (see Section 3.1) to convey the semantics
   of the new Context ID to their peer.  This process is known as
   registering the Context ID.

   Each Context ID can have either compressed or uncompressed semantics.
   The uncompressed variant encodes the target IP address and port into
   each HTTP Datagram.  Conversely, the compressed variant exchanges the
   target IP address and port once in the capsule during registration,
   and then relies on shared state to map from the Context ID to the IP
   address and port.

   Context ID 0 was reserved by unextended UDP proxying to represent UDP
   payloads sent to and from the "target_host" and "target_port" from
   the URI template.  When the mechanism from this document is in use:

   *  if the "target_host" and "target_port" variables are set to '*',
      then Context ID 0 MUST NOT be used in HTTP Datagrams.  If one is
      received, the recipient MUST abort the request stream.

Schinazi & Singh         Expires 5 February 2027                [Page 4]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   *  otherwise, HTTP Datagrams with Context ID 0 have the same
      semantics as in unextended UDP proxying.

3.1.  The COMPRESSION_ASSIGN capsule

   The Compression Assign capsule (capsule type 0x11) is used to
   register the semantics of a Context ID.  It has the following format:

   COMPRESSION_ASSIGN Capsule {
     Type (i) = 0x11,
     Length (i),
     Context ID (i),
     IP Version (8),
     [IP Address (32..128)],
     [UDP Port (16)],
   }

                Figure 1: Compression Assign Capsule Format

   It contains the following fields:

   IP Version:  The IP Version of the following IP Address field.  MUST
      be 0, 4 or 6.  Setting this to zero indicates that this capsule
      registers an uncompressed Context ID.  Otherwise, the capsule
      registers a compressed Context ID for the IP address and UDP port
      it carries.

   IP Address:  The IP Address of this context.  This field is omitted
      if the IP Version field is set to 0.  Otherwise, it has a length
      of 32 bits when the corresponding IP Version field value is 4, and
      128 when the IP Version is 6.

   UDP Port:  The UDP Port of this context, in network byte order.  This
      field is omitted if the IP Version field is set to 0.

   When an endpoint receives a COMPRESSION_ASSIGN capsule, it MUST
   either accept or reject the corresponding registration:

   *  if it accepts the registration, first the receiver MUST save the
      mapping from Context ID to address and port (or save the fact that
      this Context ID is uncompressed).  Second, the receiver MUST
      return a COMPRESSION_ACK capsule with the Context ID set to the
      one from the received COMPRESSION_ASSIGN capsule back to its peer,
      indicating it has accepted the registration.

   *  if it rejects the registration, the receiver MUST respond by
      sending a COMPRESSION_CLOSE capsule with the Context ID set to the
      one from the received COMPRESSION_ASSIGN capsule.

Schinazi & Singh         Expires 5 February 2027                [Page 5]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   As mandated in Section 4 of [CONNECT-UDP], clients can only allocate
   even Context IDs, while proxies can only allocate odd ones.  Since
   the value 0 was reserved by unextended UDP proxying, the Context ID
   value of COMPRESSION_ASSIGN can never be zero.

   Endpoints MUST NOT send two COMPRESSION_ASSIGN capsules with the same
   Context ID.  If a recipient detects a repeated Context ID, it MUST
   treat the capsule as malformed.  Receipt of a malformed capsule MUST
   be treated as an error processing the Capsule Protocol, as defined in
   Section 3.3 of [HTTP-DGRAM].

   If the uncompressed Context ID is closed, the proxy MUST NOT open new
   compressed Context IDs.  Allowing the proxy to do so would permit
   traffic from source tuples not selected by the client, defeating the
   IP restriction described in Section 8.1.  Note that compressed
   Context IDs that were established prior to the closing of the
   uncompressed Context ID are not impacted.

   Only one Context ID can be used per (IP address, port) tuple.
   Endpoints MUST NOT register a Context ID for a tuple for which there
   is already an existing Context ID.  This can however happen if both
   endpoints register Context IDs simultaneously for the same tuple
   before learning that the peer also opened one.  If an endpoint
   detects that both it and its peer have opened a Context ID for the
   same tuple, the endpoint MUST close the Context ID that was opened by
   the proxy.  If an endpoint receives a COMPRESSION_ASSIGN capsule
   whose tuple matches another open Context ID that was opened by its
   peer, it MUST treat the capsule as malformed.

   Endpoints MAY pre-emptively use Context IDs not yet acknowledged by
   the peer via COMPRESSION_ACK, knowing that those HTTP Datagrams can
   be dropped if they arrive before the corresponding COMPRESSION_ASSIGN
   capsule, or if the peer rejects the registration.

3.2.  The COMPRESSION_ACK capsule

   The Compression Acknowledgment capsule (capsule type 0x12) serves to
   confirm registration of a Context ID that was received via a
   COMPRESSION_ASSIGN capsule.

   COMPRESSION_ACK Capsule {
     Type (i) = 0x12,
     Length (i),
     Context ID (i),
   }

            Figure 2: Compression Acknowledgment Capsule Format

Schinazi & Singh         Expires 5 February 2027                [Page 6]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   An endpoint can only send a COMPRESSION_ACK capsule if it received a
   COMPRESSION_ASSIGN capsule with the same Context ID.  If an endpoint
   receives a COMPRESSION_ACK capsule for a Context ID it did not
   attempt to register via COMPRESSION_ASSIGN, that capsule is
   considered malformed.

3.3.  The COMPRESSION_CLOSE capsule

   The Compression Close capsule (capsule type 0x13) serves two
   purposes.  It can be sent as a direct response to a received
   COMPRESSION_ASSIGN capsule, to indicate that the registration was
   rejected.  It can also be sent later to indicate the closure of a
   previously assigned registration.

   COMPRESSION_CLOSE Capsule {
     Type (i) = 0x13,
     Length (i),
     Context ID (i),
   }

                 Figure 3: Compression Close Capsule Format

   Once an endpoint has either sent or received a COMPRESSION_CLOSE for
   a given Context ID, it MUST NOT send any further datagrams with that
   Context ID.  (Note that, due to reordering, an endpoint can receive
   datagrams with a Context ID that has previously been closed; these
   MUST be discarded silently.)

   Since the value 0 was reserved by unextended UDP proxying, a
   COMPRESSION_CLOSE capsule with Context ID set to zero is malformed.

   Endpoints MAY close any Context ID regardless of which endpoint
   registered it.  This is useful for example, when a mapping is unused
   for a long time.  Another potential use is restricting some targets
   (see Section 8.1).

   Once a registration is closed, endpoints can instead use an
   uncompressed Context ID to exchange UDP payloads for the given
   target, if such a Context has been registered (see Section 4).

   Once a Context ID has been closed, that ID cannot be reused; see
   Section 4 of [CONNECT-UDP].

Schinazi & Singh         Expires 5 February 2027                [Page 7]
Internet-Draft              CONNECT-UDP Bind                 August 2026

4.  Uncompressed Operation

   If the client wishes to send or receive uncompressed datagrams, it
   MUST first send a COMPRESSION_ASSIGN capsule (see Figure 1) to the
   proxy with the IP Version set to zero.  This registers the Context ID
   as having uncompressed semantics: all HTTP Datagrams with this
   Context ID have the following format:

   Uncompressed Bound UDP Proxying Payload {
     IP Version (8),
     IP Address (32..128),
     UDP Port (16),
     UDP Payload (..),
   }

       Figure 4: Uncompressed Bound UDP Proxying HTTP Datagram Format

   It contains the following fields:

   IP Version:  The IP Version of the following IP Address field.  MUST
      be 4 or 6.

   IP Address:  The IP Address of this proxied UDP packet.  When sent
      from client to proxy, this is the target host to which the proxy
      will send this UDP payload.  When sent from proxy to client, this
      represents the source IP address of the UDP packet received by the
      proxy.  This field has a length of 32 bits when the corresponding
      IP Version field value is 4, and 128 when the IP Version is 6.

   UDP Port:  The UDP Port of this proxied UDP packet in network byte
      order.  When sent from client to proxy, this is the target port to
      which the proxy will send this UDP payload.  When sent from proxy
      to client, this represents the source UDP port of the UDP packet
      received by the proxy.

   UDP Payload:  The unmodified UDP Payload of this proxied UDP packet
      (referred to as "data octets" in [UDP]).

   A client MUST NOT open an uncompressed Context ID if one is already
   open.  If a server receives a request to open an uncompressed Context
   ID and it already has one open, then the server MUST treat the second
   capsule as malformed.  Note that it's possible for the client to
   close the uncompressed Context ID and reopen it later with a
   different Context ID, as long as there aren't two uncompressed
   Context IDs open at the same time.  Only the client can request
   uncompressed Context IDs.  If a client receives a COMPRESSION_ASSIGN
   capsule with the IP Version set to 0, it MUST treat it as malformed.

Schinazi & Singh         Expires 5 February 2027                [Page 8]
Internet-Draft              CONNECT-UDP Bind                 August 2026

5.  Compressed Operation

   Endpoints MAY choose to compress the IP address and port information
   per datagram for a given target using Context IDs.  This is
   accomplished by registering a compressed Context ID using the
   COMPRESSION_ASSIGN capsule (see Figure 1).

   If the Context ID in an HTTP Datagram matches one previously
   registered for compressed operation, the rest of the HTTP Datagram
   represents the UDP payload:

   Compressed Bound UDP Proxying Payload {
     UDP Payload (..),
   }

        Figure 5: Compressed Bound UDP Proxying HTTP Datagram Format

   It contains the following field:

   UDP Payload:  The unmodified UDP Payload of this proxied UDP packet
      (referred to as "data octets" in [UDP]).

6.  The Connect-UDP-Bind Header Field

   The "Connect-UDP-Bind" header field’s value is a Boolean Structured
   Field set to true.  Clients and proxy both indicate support for this
   extension by sending the Connect-UDP-Bind header field with a value
   of ?1.  Once an endpoint has both sent and received the Connect-UDP-
   Bind header field set to true, this extension is enabled.  Any other
   value type MUST be handled as if the field were not present by the
   recipients (for example, if this field is defined multiple times, its
   type becomes a List and therefore is to be ignored).  This document
   does not define any parameters for the Connect-UDP-Bind header field
   value, but future documents might define parameters.  Receivers MUST
   ignore unknown parameters.

7.  The Proxy-Public-Address Response Header Field

   Upon accepting the request, the proxy MUST select at least one public
   IP address to bind.  The proxy MAY assign more addresses.  For each
   selected address, it MUST select an open port to bind to this
   request.  From then and until the tunnel is closed, the proxy SHALL
   send packets received on these (IP address, port) tuples to the
   client.  The proxy MUST communicate the selected addresses and ports
   to the client using the "Proxy-Public-Address" header field.  The
   header field is a List.  Each member of the List is a String,
   comprised of the ip-port tuple.  The format of the String is defined
   using IP-literal, IPv4address, and port from Section 3.2 of [URI].

Schinazi & Singh         Expires 5 February 2027                [Page 9]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   ip-port-tuple = DQUOTE ( IP-literal / IPv4address ) ":" port DQUOTE

                       Figure 6: Proxy Address Format

   When a single (IP address, port) tuple is provided in the Proxy-
   Public-Address field, the proxy MUST use the same public IP address
   and port for the lifetime of the tunnel.  When multiple tuples are
   provided, maintaining address stability per address family for the
   duration of the tunnel is RECOMMENDED.

   Note that since the addresses are conveyed in HTTP response headers,
   a subsequent change of addresses on the proxy cannot be conveyed to
   the client.

   If the proxy only shares IP addresses from a single address family,
   that indicates that the proxy only supports that family.  The client
   SHOULD NOT attempt to register compressed Context IDs or send
   uncompressed datagrams intended for targets whose IP address families
   were not indicated via the IP addresses listed in the Proxy-Public-
   Address header field, as the proxy will drop those datagrams and
   reject those registrations.

8.  Proxy Behavior

   After accepting the bound UDP proxying request, the proxy uses an
   assigned IP address and port to transmit UDP payloads received from
   the client to the target IP Address and UDP Port specified in each
   HTTP Datagram received from the client.  The proxy uses the same
   ports to listen for UDP packets from any authorized target and
   forwards them to the client by encapsulating them in HTTP Datagrams,
   using the corresponding Context ID.

   If the proxy receives UDP payloads that don't correspond to any
   registration (i.e., no compression for the given target was ever
   established and there is no uncompressed registration), the proxy
   will either drop the datagram or temporarily buffer it (see Section 5
   of [CONNECT-UDP]).

8.1.  Restricting IPs

   If a client does not wish to receive datagrams from unknown senders,
   it can close the uncompressed Context ID (or not open it in the first
   place).  In that scenario, the proxy effectively acts as a firewall
   against unwanted or unknown IPs.

Schinazi & Singh         Expires 5 February 2027               [Page 10]
Internet-Draft              CONNECT-UDP Bind                 August 2026

9.  Security Considerations

   The security considerations described in Section 7 of [CONNECT-UDP]
   also apply here.  Since Traversal Using Relays around NAT (TURN) can
   be run over this mechanism, implementors will benefit from reviewing
   the security considerations in Section 21 of [TURN].

   Since unextended UDP proxying requests carry the target as part of
   the request, the proxy can protect against unauthorized targets by
   rejecting requests before creating the tunnel, and communicate the
   rejection reason in response header fields.  The uncompressed Context
   ID allows transporting datagrams to and from any target.  Clients
   that keep the uncompressed Context ID open need to be able to receive
   from all targets.  If the UDP proxy were to reject unextended UDP
   proxying requests to some targets (as recommended in Section 7 of
   [CONNECT-UDP]), then for bound UDP proxying requests where the
   uncompressed Context ID is open, the UDP proxy needs to perform
   checks on the target of each uncompressed Context ID datagram it
   receives.  Similarly, the UDP proxy needs to perform checks on the IP
   address and port of received COMPRESSION_ASSIGN capsules and reject
   the registration of compressed Context IDs to disallowed targets.

   When an endpoint accepts the registration of a Context ID, it will
   need to store it in memory.  To prevent unbounded memory growth,
   endpoints MUST place a limit on how many Context IDs can be open
   simultaneously and reject registrations beyond the limit.

   Note that if the compression response (COMPRESSION_ACK or
   COMPRESSION_CLOSE) cannot be immediately sent due to flow or
   congestion control, an upper limit on how many compression responses
   the endpoint is willing to buffer MUST be set to prevent memory
   exhaustion.  The proxy MUST abort the request stream if this limit is
   reached.

10.  Operational Considerations

   When moving traffic between uncompressed and compressed Context IDs,
   the effective MTU will change.  This can hinder Datagram
   Packetization Layer PMTU Discovery (DPLPMTUD) between the client and
   the target [DPLPMTUD].  To avoid that, if an endpoint intends to use
   compression, it SHOULD request it as early as possible.

   Since this mechanism effectively allows clients to share the IP
   address of the proxy, implementers may wish to review [IP-SHARING].

Schinazi & Singh         Expires 5 February 2027               [Page 11]
Internet-Draft              CONNECT-UDP Bind                 August 2026

11.  IANA Considerations

11.1.  HTTP Fields

   This document requests IANA to register the following new items in
   the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry
   maintained at <https://www.iana.org/assignments/http-fields>:

                +======================+=================+
                | Field Name           | Structured Type |
                +======================+=================+
                | Connect-UDP-Bind     | Item            |
                +----------------------+-----------------+
                | Proxy-Public-Address | List            |
                +----------------------+-----------------+

                           Table 1: New Fields

   All of these new entries use the following values for these fields:

   Status:  provisional (permanent if this document is approved)
   Reference:  This document
   Comments:  None

11.2.  Capsules

   This document requests IANA to register the following new items to
   the "HTTP Capsule Types" registry maintained at
   <https://www.iana.org/assignments/masque>:

                      +=======+====================+
                      | Value | Capsule Type       |
                      +=======+====================+
                      | 0x11  | COMPRESSION_ASSIGN |
                      +-------+--------------------+
                      | 0x12  | COMPRESSION_ACK    |
                      +-------+--------------------+
                      | 0x13  | COMPRESSION_CLOSE  |
                      +-------+--------------------+

                          Table 2: New Capsules

   All of these new entries use the following values for these fields:

   Status:  provisional (permanent if this document is approved)
   Reference:  This document
   Change Controller:  IETF
   Contact:  MASQUE Working Group masque@ietf.org

Schinazi & Singh         Expires 5 February 2027               [Page 12]
Internet-Draft              CONNECT-UDP Bind                 August 2026

      (mailto:masque@ietf.org)
   Notes:  None

12.  References

12.1.  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [CONNECT-UDP]
              Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
              DOI 10.17487/RFC9298, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9298>.

   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [HTTP-DGRAM]
              Schinazi, D. and L. Pardue, "HTTP Datagrams and the
              Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
              2022, <https://www.rfc-editor.org/rfc/rfc9297>.

   [QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [STRUCTURED-FIELDS]
              Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
              <https://www.rfc-editor.org/rfc/rfc9651>.

Schinazi & Singh         Expires 5 February 2027               [Page 13]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6570>.

   [UDP]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC768, August 1980,
              <https://www.rfc-editor.org/rfc/rfc768>.

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

12.2.  Informative References

   [CONNECT-IP]
              Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
              Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
              RFC 9484, DOI 10.17487/RFC9484, October 2023,
              <https://www.rfc-editor.org/rfc/rfc9484>.

   [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
              Völker, "Packetization Layer Path MTU Discovery for
              Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
              September 2020, <https://www.rfc-editor.org/rfc/rfc8899>.

   [ICE]      Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
              Connectivity Establishment (ICE): A Protocol for Network
              Address Translator (NAT) Traversal", RFC 8445,
              DOI 10.17487/RFC8445, July 2018,
              <https://www.rfc-editor.org/rfc/rfc8445>.

   [IP-SHARING]
              Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
              P. Roberts, "Issues with IP Address Sharing", RFC 6269,
              DOI 10.17487/RFC6269, June 2011,
              <https://www.rfc-editor.org/rfc/rfc6269>.

   [TURN]     Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J.
              Rosenberg, "Traversal Using Relays around NAT (TURN):
              Relay Extensions to Session Traversal Utilities for NAT
              (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8656>.

   [WebRTC]   "WebRTC", W3C Recommendation, 26 January 2021,
              <https://www.w3.org/TR/webrtc/>.

Schinazi & Singh         Expires 5 February 2027               [Page 14]
Internet-Draft              CONNECT-UDP Bind                 August 2026

Appendix A.  Example

   In the example below, the client is configured with URI Template
   "https://example.org/.well-known/masque/
   udp/{target_host}/{target_port}/" and listens for traffic on the
   proxy, eventually decides that it no longer wants to listen for
   connections from new targets, and limits its communication with only
   203.0.113.11:60000 and no other UDP target.

   Client                                             Server

   STREAM(44): HEADERS            -------->
     :method = CONNECT
     :protocol = connect-udp
     :scheme = https
     :path = /.well-known/masque/udp/%2A/%2A/
     :authority = proxy.example.org
     connect-udp-bind = ?1
     capsule-protocol = ?1

              <--------  STREAM(44): HEADERS
                           :status = 200
                           connect-udp-bind = ?1
                           capsule-protocol = ?1
                           proxy-public-address = "192.0.2.45:54321",  \
                                              "[2001:db8::1234]:54321"

  // Register Context ID 2 to be used for uncompressed UDP payloads
  // to/from any target.

   CAPSULE                       -------->
     Type = COMPRESSION_ASSIGN
     Context ID = 2
     IP Version = 0

  // Proxy confirms registration.

              <-------- CAPSULE
                          Type = COMPRESSION_ACK
                          Context ID = 2

  // Target talks to Client using the uncompressed Context ID.

              <--------  DATAGRAM
                           Quarter Stream ID = 11
                           Context ID = 2
                           IP Version = 4
                           IP Address = 192.0.2.42

Schinazi & Singh         Expires 5 February 2027               [Page 15]
Internet-Draft              CONNECT-UDP Bind                 August 2026

                           UDP Port = 50000
                           UDP Payload = Encapsulated UDP Payload

  // Client responds on the same uncompressed Context ID.

   DATAGRAM                       -------->
     Quarter Stream ID = 11
     Context ID = 2
     IP Version = 4
     IP Address = 192.0.2.42
     UDP Port = 50000
     UDP Payload = Encapsulated UDP Payload

  // Another target talks to Client using the uncompressed Context ID.

              <--------  DATAGRAM
                           Quarter Stream ID = 11
                           Context ID = 2
                           IP Version = 4
                           IP Address = 203.0.113.11
                           UDP Port = 60000
                           UDP Payload = Encapsulated UDP Payload

  // Client responds on the same uncompressed Context ID.

   DATAGRAM                       -------->
     Quarter Stream ID = 11
     Context ID = 2
     IP Version = 4
     IP Address = 203.0.113.11
     UDP Port = 60000
     UDP Payload = Encapsulated UDP Payload

  // Register 203.0.113.11:60000 to compress it in the future.

   CAPSULE                       -------->
     Type = COMPRESSION_ASSIGN
     Context ID = 4
     IP Version = 4
     IP Address = 203.0.113.11
     UDP Port = 60000

  // Proxy confirms registration.

              <-------- CAPSULE
                          Type = COMPRESSION_ACK
                          Context ID = 4

Schinazi & Singh         Expires 5 February 2027               [Page 16]
Internet-Draft              CONNECT-UDP Bind                 August 2026

  // Omit IP address and port for future packets intended for
  // 203.0.113.11:60000 hereon.

   DATAGRAM                       -------->
     Context ID = 4
     UDP Payload = Encapsulated UDP Payload

              <--------  DATAGRAM
                          Context ID = 4
                          UDP Payload = Encapsulated UDP Payload

  // Request packets without a corresponding compressed Context
  // to be dropped by closing the uncompressed Context ID.

   CAPSULE                       -------->
     Type = COMPRESSION_CLOSE
     Context ID = 2

  // Context ID 4 = 203.0.113.11:60000 traffic is accepted,
  // and other traffic is dropped at the proxy.

Appendix B.  Comparison with CONNECT-IP

   While the use cases described in Section 1 could be supported using
   IP proxying in HTTP [CONNECT-IP], it would require that every HTTP
   Datagram carries a complete IP header.  This would lead to both
   inefficiencies in the wire encoding and reduction in available
   Maximum Transmission Unit (MTU).  Furthermore, Web browsers would
   need to support IPv4 and IPv6 header generation, parsing, validation
   and error handling.

Acknowledgments

   This proposal is the result of many conversations with MASQUE working
   group participants.  In particular, the authors would like to thank
   Alejandro Sedeño, Ben Schwartz, Ines Robles, Lucas Pardue, Mike
   Bishop, Magnus Westerlund, Marius Kleidl, Mark Nottingham, Marten
   Seemann, Tommy Pauly, and Yaroslav Rosomakho for their reviews.

Authors' Addresses

   David Schinazi
   Google LLC
   Email: dschinazi.ietf@gmail.com

   Abhi Singh
   Google LLC

Schinazi & Singh         Expires 5 February 2027               [Page 17]
Internet-Draft              CONNECT-UDP Bind                 August 2026

   Email: abhisinghietf@gmail.com

Schinazi & Singh         Expires 5 February 2027               [Page 18]