RFC 9298

Proxying UDP in HTTP

📅 published August 2022, from ietf

RFC 9298: Proxying UDP in HTTP 🦋

okay bestie, here's the header situation 📋 this is a Standards Track doc 👑, written by D. Schinazi at Google LLC, dated August 2022, ISSN 2070-1721. The header doesn't say it obsoletes or updates anything, so there's nothing to report there 🫶

Abstract ✨

okay so this doc is all about proxying UDP over HTTP 🌸 kinda like how the HTTP CONNECT method lets you proxy TCP over HTTP. It defines a protocol where an HTTP client can open a tunnel for UDP traffic through an HTTP server that acts as a proxy 💖

Status of This Memo 📜

this is an Internet Standards Track document 👑 and it's a product of the IETF. It represents the consensus of the IETF community, got public review, and was approved for publication by the IESG. If you want more on Internet Standards, check Section 2 of RFC 7841 🙈

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9298 🔗

Copyright (c) 2022 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) as they stand on the publication date. please read those carefully, bestie, because they explain your rights and restrictions for this doc 🫶 Code Components pulled out of this document have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 💅

Table of Contents 🗂️

1.  Introduction
  1.1.  Conventions and Definitions
2.  Client Configuration
3.  Tunneling UDP over HTTP
  3.1.  UDP Proxy Handling
  3.2.  HTTP/1.1 Request
  3.3.  HTTP/1.1 Response
  3.4.  HTTP/2 and HTTP/3 Requests
  3.5.  HTTP/2 and HTTP/3 Responses
4.  Context Identifiers
5.  HTTP Datagram Payload Format
6.  Performance Considerations
  6.1.  MTU Considerations
  6.2.  Tunneling of ECN Marks
7.  Security Considerations
8.  IANA Considerations
  8.1.  HTTP Upgrade Token
  8.2.  Well-Known URI
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Author's Address

1. Introduction ✨

okay so HTTP already has the CONNECT method (see Section 9.3.6 of [HTTP]) for making a TCP [TCP] tunnel to a proxy 🦋. The catch is that before this spec, there was no equivalent for UDP [UDP] traffic. that's the gap this doc fills 💅

This doc describes a protocol for tunneling UDP to a server that acts as a UDP-specific proxy over HTTP 🌸. UDP tunnels are super useful for building an end-to-end virtual connection, which you can then secure with QUIC [QUIC] or another protocol running over UDP 🔐. The big difference from HTTP CONNECT is that the UDP proxy itself gets identified with an absolute URL that contains the traffic's destination ✨. Clients build those URLs with a URI Template [TEMPLATE], as described in Section 2 🧚

This protocol works with every existing version of HTTP by using HTTP Datagrams [HTTP-DGRAM] 👑. On HTTP/2 [HTTP/2] or HTTP/3 [HTTP/3], it uses HTTP Extended CONNECT, as described in [EXT-CONNECT2] and [EXT-CONNECT3] 💖. On HTTP/1.x [HTTP/1.1], it uses HTTP Upgrade, as defined in Section 7.8 of [HTTP] 🎀

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 get interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, just like they do here 🫶 so if it's lowercase, it's just regular English, not a rule 🙈

In this doc, "UDP proxy" means the HTTP server that handles the client's UDP tunneling request. It opens a UDP socket to a target server and generates the response to that request 🔥 If there are HTTP intermediaries (as defined in Section 3.7 of [HTTP]) between the client and the UDP proxy, this doc calls those "intermediaries" 🦋

One more thing: when the HTTP version you're using doesn't support multiplexing streams (like HTTP/1.1), any mention of "stream" in this doc means the entire connection 💜

2. Client Configuration 🎀

HTTP clients get configured to use a UDP proxy with a URI Template [TEMPLATE] that has the variables "target_host" and "target_port". Here are some examples, bestie 👇

https://example.org/.well-known/masque/udp/{target_host}/{target_port}/
https://proxy.example.org:4443/masque?h={target_host}&p={target_port}
https://proxy.example.org:4443/masque{?target_host,target_port}

Figure 1: URI Template Examples 🌸

okay so here are the rules the URI Template has to follow 📋

  • The URI Template MUST be a level 3 template or lower. 💅
  • The URI Template MUST be in absolute form and MUST include non-empty scheme, authority, and path components. 🫶
  • The path component of the URI Template MUST start with a slash ("/"). 🦋
  • All template variables MUST be within the path or query components of the URI. ✨
  • The URI Template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables. 🧚
  • The URI Template MUST NOT contain any non-ASCII Unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed; see Section 2.1 of [URI]). 🔐
  • The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix. 🙅‍♀️

Clients SHOULD validate the requirements above, but clients MAY use a general-purpose URI Template implementation that doesn't do this specific validation 💅 If a client spots that any of the requirements above aren't met by a URI Template, the client MUST reject its configuration and abort the request without sending it to the UDP proxy 🚫 no sending sketchy URLs, periodt 💀

Here's the backstory 🌈 The original HTTP CONNECT method could carry the target host and port, but not the scheme, proxy authority, path, or query. So there are clients out there with proxy configuration screens that only let you set a proxy host and a proxy port 🙈 Client implementations of this spec that are stuck with that limit MAY try to reach UDP proxying using the default template, which is https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/udp/{target_host}/{target_port}/, where $PROXY_HOST and $PROXY_PORT are the configured host and port of the UDP proxy 🧚 And if UDP proxy deployments want to play nice with those clients, they SHOULD offer service at that location 🫶

3. Tunneling UDP over HTTP 🦋

so to set up a UDP tunnel over HTTP, this doc defines the "connect-udp" HTTP upgrade token ✨ The resulting UDP tunnels use the Capsule Protocol (see Section 3.2 of [HTTP-DGRAM]) with HTTP Datagrams in the format defined in Section 5 💖

To start a UDP tunnel tied to a single HTTP stream, a client sends a request that includes the "connect-udp" upgrade token 👑 The client tells the UDP proxy where the tunnel is headed using the "target_host" and "target_port" variables of the URI Template, see Section 2 🌸

"target_host" can be a DNS name, an IPv6 literal, or an IPv4 literal 🌈 heads up: IPv6 scoped addressing zone identifiers are NOT supported 🙅‍♀️ Using the terms IPv6address, IPv4address, reg-name, and port from [URI], the "target_host" and "target_port" variables MUST adhere to the format in Figure 2, using the notation from [ABNF]. On top of that:

  • both the "target_host" and "target_port" variables MUST NOT be empty. 💅
  • if "target_host" contains an IPv6 literal, the colons (":") MUST be percent-encoded. For example, if the target host is "2001:db8::42", it gets encoded in the URI as "2001%3Adb8%3A%3A42". 🫶
  • "target_port" MUST represent an integer between 1 and 65535 inclusive. 🔢
target_host = IPv6address / IPv4address / reg-name
target_port = port

Figure 2: URI Template Variable Format 🧚

When it sends its UDP proxying request, the client SHALL perform URI Template expansion to figure out the path and query of its request ✨

If the request succeeds, the UDP proxy commits to converting received HTTP Datagrams into UDP packets, and vice versa, until the tunnel closes 🦋 that's the whole deal, bestie 💜

By virtue of how the Capsule Protocol is defined (see Section 3.2 of [HTTP-DGRAM]), UDP proxying requests don't carry any message content. Successful UDP proxying responses don't carry any message content either 🙈 so both sides are just skipping the body, lowkey iconic 👑

3.1. UDP Proxy Handling ✨

okay so when a UDP proxying request comes in, the recipient has two options 🧚

  • if the recipient is configured to use another HTTP proxy, it acts as an intermediary and forwards the request to another HTTP server. ngl these intermediaries may need to re-encode the request if they forward it using a different HTTP version than the one they received it on, because the request encoding changes between versions (more on that below) 🔄
  • otherwise, the recipient is the UDP proxy itself. it pulls the "target_host" and "target_port" variables out of the URI it rebuilt from the request headers, decodes their percent-encoding, and sets up a tunnel by directly opening a UDP socket to the target 🦋

okay here's the lowkey tricky part 🥺 UDP is connectionless, so the UDP proxy that opens the socket has no way of knowing whether the destination is reachable. that means it has to reply to the request without waiting for a packet from the target. BUT if "target_host" is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP request. if something goes wrong during that, the UDP proxy MUST reject the request and SHOULD send details using an appropriate Proxy-Status header field [PROXY-STATUS]. for example, if DNS resolution returns an error, the proxy can use the dns_error Proxy Error Type from Section 2.3.2 of [PROXY-STATUS] 💀

connected UDP sockets are a vibe if the operating system supports them, because the kernel then only sends the proxy UDP packets that match the correct 5-tuple 🫶 if the UDP proxy uses a non-connected socket, it MUST validate the IP source address and UDP source port on received packets to make sure they match the client's request. packets that do not match MUST be discarded by the UDP proxy 🚫

the socket's lifetime is tied to the request stream. the UDP proxy MUST keep the socket open while the request stream is open. if the operating system tells the proxy that its socket is no longer usable, it MUST close the request stream. for example, this can happen when an ICMP Destination Unreachable message is received; see Section 3.1 of [ICMP6]. UDP proxies MAY choose to close sockets after a period of inactivity, but they MUST close the request stream when closing the socket. and if they do close sockets for inactivity, they SHOULD NOT use a period lower than two minutes; see Section 4.3 of [BEHAVE] ⏳

a successful response (as defined in Sections 3.3 and 3.5) means the UDP proxy has opened a socket to the requested target and is willing to proxy UDP payloads 🎀 any response other than a successful one means the request failed, so the client MUST abort the request 🙅‍♀️

UDP proxies MUST NOT introduce fragmentation at the IP layer when forwarding HTTP Datagrams onto a UDP socket. overly large datagrams are silently dropped. in IPv4, the Don't Fragment (DF) bit MUST be set, if possible, to prevent fragmentation on the path. future extensions MAY remove these requirements 🌈

implementers of UDP proxies will benefit from reading the guidance in [UDP-USAGE] 📚

3.2. HTTP/1.1 Request

when using HTTP/1.1 [HTTP/1.1], a UDP proxying request has to meet these requirements 💅

  • the method SHALL be "GET".
  • the request SHALL include a single Host header field containing the origin of the UDP proxy.
  • the request SHALL include a Connection header field with value "Upgrade" (note that this requirement is case-insensitive as per Section 7.6.1 of [HTTP]).
  • the request SHALL include an Upgrade header field with value "connect-udp".

a UDP proxying request that does not conform to these restrictions is malformed. the recipient of such a malformed request MUST respond with an error and SHOULD use the 400 (Bad Request) status code 🙈

for example, say the client is configured with the URI Template https://example.org/.well-known/masque/udp/{target_host}/{target_port}/ and wants to open a UDP proxying tunnel to target 192.0.2.6:443. it could send this request 🎀

GET https://example.org/.well-known/masque/udp/192.0.2.6/443/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

Figure 3: Example HTTP/1.1 Request

in HTTP/1.1, this protocol uses the GET method to mimic the design of the WebSocket Protocol [WEBSOCKET] 🧚

3.3. HTTP/1.1 Response

the UDP proxy SHALL indicate a successful response by replying with the following requirements 🌸

  • the HTTP status code on the response SHALL be 101 (Switching Protocols).
  • the response SHALL include a Connection header field with value "Upgrade" (note that this requirement is case-insensitive as per Section 7.6.1 of [HTTP]).
  • the response SHALL include a single Upgrade header field with value "connect-udp".
  • the response SHALL meet the requirements of HTTP responses that start the Capsule Protocol; see Section 3.2 of [HTTP-DGRAM].

if any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the connection 💀

for example, the UDP proxy could respond with 🍓

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-udp
Capsule-Protocol: ?1

Figure 4: Example HTTP/1.1 Response

3.4. HTTP/2 and HTTP/3 Requests

when using HTTP/2 [HTTP/2] or HTTP/3 [HTTP/3], UDP proxying requests use HTTP Extended CONNECT 🔥 this requires that servers send an HTTP Setting as specified in [EXT-CONNECT2] and [EXT-CONNECT3], and that requests use HTTP pseudo-header fields with the following requirements 👑

  • The :method pseudo-header field SHALL be "CONNECT".
  • The :protocol pseudo-header field SHALL be "connect-udp".
  • The :authority pseudo-header field SHALL contain the authority of the UDP proxy.
  • The :path and :scheme pseudo-header fields SHALL NOT be empty. Their values SHALL contain the scheme and path from the URI Template after the URI Template expansion process has been completed.

a UDP proxying request that does not conform to these restrictions is malformed (see Section 8.1.1 of [HTTP/2] and Section 4.1.2 of [HTTP/3]) 🙅‍♀️

for example, if the client is configured with the URI Template https://example.org/.well-known/masque/udp/{target_host}/{target_port}/ and wants to open a UDP proxying tunnel to target 192.0.2.6:443, it could send this request ✨

HEADERS
:method = CONNECT
:protocol = connect-udp
:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/
:authority = example.org
capsule-protocol = ?1

Figure 5: Example HTTP/2 Request

3.5. HTTP/2 and HTTP/3 Responses

the UDP proxy SHALL indicate a successful response by replying with the following requirements 🫶

  • the HTTP status code on the response SHALL be in the 2xx (Successful) range.
  • the response SHALL meet the requirements of HTTP responses that start the Capsule Protocol; see Section 3.2 of [HTTP-DGRAM].

if any of these requirements are not met, the client MUST treat this proxying attempt as failed and abort the request 😭

for example, the UDP proxy could respond with 🌷

HEADERS
:status = 200
capsule-protocol = ?1

Figure 6: Example HTTP/2 Response

4. Context Identifiers 🦋

okay this part is giving main character energy 👑 the mechanism for proxying UDP in HTTP defined in this document lets future extensions exchange HTTP Datagrams that carry different semantics from UDP payloads. some of these extensions can augment UDP payloads with additional data, while others can exchange data that is completely separate from UDP payloads. to make this work, all HTTP Datagrams associated with UDP Proxying request streams start with a Context ID field; see Section 5 💖

Context IDs are 62-bit integers (0 to 2^62-1). they are encoded as variable-length integers; see Section 16 of [QUIC]. the Context ID value of 0 is reserved for UDP payloads, while non-zero values are dynamically allocated. non-zero even-numbered Context IDs are client-allocated, and odd-numbered Context IDs are proxy-allocated. the Context ID namespace is tied to a given HTTP request, so it is possible for a Context ID with the same numeric value to be simultaneously allocated in distinct requests, potentially with different semantics. Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order. the Context ID allocation restrictions on even-numbered and odd-numbered Context IDs exist to avoid the need for synchronization between endpoints. however, once a Context ID has been allocated, those restrictions do not apply to its use; it can be used by any client or UDP proxy, independent of which endpoint initially allocated it 🧚

registration is the action by which an endpoint informs its peer of the semantics and format of a given Context ID. this document does not define how registration occurs. future extensions MAY use HTTP header fields or capsules to register Context IDs. depending on the method being used, it is possible for datagrams to be received with Context IDs that have not yet been registered. for instance, this can be due to reordering of the packet containing the datagram and the packet containing the registration message during transmission 🥹

5. HTTP Datagram Payload Format 🎀

Okay bestie, when HTTP Datagrams (see Section 2 of [HTTP-DGRAM]) are attached to UDP Proxying request streams, the HTTP Datagram Payload field uses the format in Figure 7, with the notation from Section 1.3 of [QUIC] 💅. The detail that slays: when HTTP Datagrams go inside QUIC DATAGRAM frames [QUIC-DGRAM], the Context ID field we're about to talk about comes right after the Quarter Stream ID field. That one sits at the very start of the QUIC DATAGRAM frame payload. See Section 2.1 of [HTTP-DGRAM] 🦋

UDP Proxying HTTP Datagram Payload {
  Context ID (i),
  UDP Proxying Payload (..),
}
             Figure 7: UDP Proxying HTTP Datagram Format
  • Context ID: a variable-length integer (see Section 16 of [QUIC]) holding the value of the Context ID. If an HTTP/3 Datagram shows up carrying a Context ID you don't recognise, the receiver SHALL either drop it silently or buffer it for a little while (on the order of a round trip) until that Context ID gets registered. Main character energy: wait for the paperwork 🧚
  • UDP Proxying Payload: the payload of the datagram. What it means depends on the Context ID right before it. It can be empty, and that's totally valid 🌸

UDP packets are sent as HTTP Datagrams with the Context ID set to zero. When the Context ID is zero, the UDP Proxying Payload field holds the unmodified payload of a UDP packet (the "data octets" from [UDP]) ✨

Here's a fun limit: because of the UDP header [UDP], a UDP payload can't be longer than 65527 bytes. So endpoints MUST NOT send HTTP Datagrams with a UDP Proxying Payload longer than 65527 using Context ID zero 🙈 If an endpoint gets a Context ID zero HTTP Datagram with a UDP Proxying Payload longer than 65527, it MUST abort the corresponding stream. If a UDP proxy knows its underlying link MTU only lets it send UDP packets of a certain length, it has no choice but to throw away incoming Context ID zero HTTP Datagrams whose UDP Proxying Payload is longer than that limit. If that discarded HTTP Datagram came in a DATAGRAM capsule, the receiver SHOULD discard the capsule without buffering its contents 💀

If a UDP proxy gets an HTTP Datagram before it has the corresponding request, it SHALL either drop that HTTP Datagram silently or buffer it temporarily (on the order of a round trip) while it waits for the request to show up 🫶

Buffering eats resources, so be careful, babe 💜 Whether you're holding datagrams because the request hasn't arrived or because the Context ID isn't known yet, it costs memory. Receivers that buffer datagrams SHOULD apply buffering limits to lower the risk of resource exhaustion. For example, receivers can cap the total number of buffered datagrams or the cumulative size of buffered datagrams, per stream, per context, or per connection.

A client MAY optimistically start sending UDP packets in HTTP Datagrams before it gets the response to its UDP proxying request. Just know that those proxied packets might not get processed by the UDP proxy if it answers the request with a failure, or if the packets arrive before the request and the UDP proxy decides not to buffer them 🌈

6. Performance Considerations 🚀

Bursty traffic can lead to losses that are correlated in time, and that can make congestion controllers in UDP-based protocols respond in not-so-great ways 😭 So UDP proxies SHOULD strive to avoid making UDP traffic burstier. They SHOULD NOT queue packets just to batch them up.

When the protocol running over the proxied UDP uses congestion control (e.g., [QUIC]), the proxied traffic ends up with at least two nested congestion controllers. The underlying HTTP connection MUST NOT disable congestion control unless it has an out-of-band way of knowing, with absolute certainty, that the inner traffic is congestion-controlled. Be careful with that one, it's a big deal 👑

If a client or UDP proxy with a connection containing a UDP Proxying request stream disables congestion control, it MUST NOT signal Explicit Congestion Notification (ECN) [ECN] support on that connection. Put plainly, it MUST mark all IP headers with the Not-ECT codepoint. It MAY keep reporting ECN feedback via QUIC ACK_ECN frames or the TCP ECE bit, since the peer may not have disabled congestion control 🍓

When the protocol running over the proxied UDP uses loss recovery (e.g., [QUIC]) and the underlying HTTP connection runs over TCP, the proxied traffic gets at least two nested loss recovery mechanisms. That can hurt performance because both can sometimes retransmit the same data on their own. To avoid this, UDP proxying SHOULD be performed over HTTP/3 so it can use the QUIC DATAGRAM frame ✨

6.1. MTU Considerations 📏

When you use HTTP/3 with the QUIC Datagram extension [QUIC-DGRAM], UDP payloads get sent in QUIC DATAGRAM frames. Those can't be fragmented, so they can only carry payloads up to a certain length, set by the QUIC connection configuration and the Path MTU (PMTU) 🫠 If a UDP proxy is using QUIC DATAGRAM frames and gets a UDP payload from the target that won't fit inside one, the UDP proxy SHOULD NOT send that payload in a DATAGRAM capsule. Doing that would defeat the end-to-end unreliability that methods like Datagram Packetization Layer PMTU Discovery (DPLPMTUD) depend on [DPLPMTUD]. In this situation, the UDP proxy SHOULD drop the UDP payload and send an ICMP Packet Too Big message to the target; see Section 3.2 of [ICMP6] 🧚

6.2. Tunneling of ECN Marks 🦋

UDP proxying doesn't create an IP-in-IP tunnel, so the guidance in [ECN-TUNNEL] about moving ECN marks between inner and outer IP headers doesn't apply. There's no inner IP header in UDP proxying tunnels, period 🙅‍♀️

In this specification, note that UDP proxying clients can't control the ECN codepoints on the UDP packets the UDP proxy sends to the target. UDP proxies also can't tell clients what markings each UDP packet had coming from the target 💅

A UDP proxy MUST ignore the ECN bits in the IP header of UDP packets it receives from the target, and it MUST set the ECN bits to Not-ECT on UDP packets it sends to the target. None of this relates to the ECN markings on packets sent between the client and the UDP proxy, in any way 💖

7. Security Considerations 🚨

Okay, this section is serious, so get comfy 🙈 There are significant risks in letting arbitrary clients set up a tunnel to arbitrary targets. Bad actors could send traffic and have it attributed to the UDP proxy! HTTP servers that support UDP proxying ought to restrict its use to authenticated users 🔐

Some software and network deployments do access control checks based on the source IP address of incoming requests. For example, some software allows unauthenticated configuration changes if they came from 127.0.0.1. That software could be running on the same host as the UDP proxy, or in the same broadcast domain. Proxied UDP traffic would then arrive with a source IP address belonging to the UDP proxy. If that source address is used for access control, UDP proxying clients could use the UDP proxy to escalate their access privileges beyond what they'd otherwise have. That could lead to unauthorized access by UDP proxying clients, unless the UDP proxy disallows UDP proxying requests to vulnerable targets, such as the UDP proxy's own addresses and localhost, link-local, multicast, and broadcast addresses. UDP proxies can use the destination_ip_prohibited Proxy Error Type from Section 2.3.5 of [PROXY-STATUS] when they reject such requests 🛑

UDP proxies have a lot in common with TCP CONNECT proxies when it comes to being abused as infrastructure for denial-of-service (DoS) attacks. Both can hide the attacker's source address from the attack target. In the case of a stateless volumetric attack (e.g., a TCP SYN flood or a UDP flood), both types of proxies pass the traffic on to the target host. With stateful volumetric attacks (e.g., HTTP flooding) sent over a TCP CONNECT proxy, the proxy only sends data if the target has indicated it's willing to accept data by responding with a TCP SYN-ACK. Once the path to the target is flooded, the TCP CONNECT proxy stops getting replies from the target and stops sending data. UDP doesn't establish shared state between the UDP proxy and the target, though, so the UDP proxy could keep sending data to the target in that situation 😬 A UDP proxy could limit how many UDP packets it forwards until it has seen a response from the target. But that gives limited protection against DoS attacks when they target open UDP ports where the protocol running over UDP would respond, and that response would be read by the UDP proxy as willingness to accept UDP. Such a packet limit could also cause problems for valid traffic 🥲

The security considerations described in Section 4 of [HTTP-DGRAM] also apply here. Since it's possible to tunnel IP packets over UDP, the guidance in [TUNNEL-SECURITY] can apply too 🫶

8. IANA Considerations 🌷

8.1. HTTP Upgrade Token 🎀

IANA has registered "connect-udp" in the "HTTP Upgrade Tokens" registry, which lives at https://www.iana.org/assignments/http-upgrade-tokens. Here's the entry:

Value:  connect-udp
Description:  Proxying of UDP Payloads
Expected Version Tokens:  None
Reference:  RFC 9298

8.2. Well-Known URI 🌈

IANA has registered "masque" in the "Well-Known URIs" registry, which lives at https://www.iana.org/assignments/well-known-uris. Here's the entry:

URI Suffix:  masque
Change Controller:  IETF
Reference:  RFC 9298
Status:  permanent
Related Information:  Includes all resources identified with the path
   prefix "/.well-known/masque/udp/"

9. References ✨

9.1. Normative References

okay bestie, these are the ones you REALLY need to read before anything else 📚💅

9.2. Informative References

these ones are the extra reading for when you're curious and wanna go deeper 🦋🌸

Acknowledgments

this doc is a product of the MASQUE Working Group, and the author thanks all the MASQUE enthusiasts for their contributions 🫶 this proposal was inspired directly or indirectly by prior work from so many people, in particular [HELIUM] by Ben Schwartz, [HiNT] by Lucas Pardue, and the original MASQUE Protocol [MASQUE-ORIGINAL] by the author of this document 🌈

the author would like to thank Eric Rescorla for suggesting the use of an HTTP method to proxy UDP ✨ the author is also indebted to Mark Nottingham and Lucas Pardue for the many improvements they contributed to this document 💜 the extensibility design in this document came out of the HTTP Datagrams Design Team, whose members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric Rescorla, Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop, Tommy Pauly, Victor Vasiliev, and the author of this document 👑

Author's Address

David Schinazi
Google LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: dschinazi.ietf@gmail.com

and that's the whole spec, bestie!! thank u for coming to my networking TED talk 🎀🦋💖

📦 where this page comes from