idnits 2.17.1 draft-ietf-masque-connect-udp-05.txt: -(570): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 October 2021) is 926 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-06 == Outdated reference: A later version (-04) exists of draft-ietf-httpbis-h3-websockets-00 ** Obsolete normative reference: RFC 7540 (ref. 'H2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-04 -- Possible downref: Normative reference to a draft: ref. 'MESSAGING' -- Possible downref: Normative reference to a draft: ref. 'SEMANTICS' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-08) exists of draft-ietf-httpbis-proxy-status-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Standards Track 7 October 2021 5 Expires: 10 April 2022 7 UDP Proxying Support for HTTP 8 draft-ietf-masque-connect-udp-05 10 Abstract 12 This document describes how to proxy UDP over HTTP. Similar to how 13 the CONNECT method allows proxying TCP over HTTP, this document 14 defines a new mechanism to proxy UDP. It is built using HTTP 15 Extended CONNECT. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the MASQUE WG mailing list 22 (masque@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/masque/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 10 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 63 2. Configuration of Clients . . . . . . . . . . . . . . . . . . 3 64 3. HTTP Exchanges . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Proxy Handling . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 5 67 3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 5 68 3.4. HTTP Request over HTTP/2 and HTTP/3 . . . . . . . . . . . 6 69 3.5. HTTP Response over HTTP/2 and HTTP/3 . . . . . . . . . . 7 70 3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 7 71 4. Encoding of Proxied UDP Packets . . . . . . . . . . . . . . . 7 72 5. Performance Considerations . . . . . . . . . . . . . . . . . 8 73 5.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 9 74 5.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 10 78 7.2. Datagram Format Type . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 8.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 This document describes how to proxy UDP over HTTP. Similar to how 88 the CONNECT method (see Section 9.3.6 of [SEMANTICS]) allows proxying 89 TCP [TCP] over HTTP, this document defines a new mechanism to proxy 90 UDP [UDP]. 92 UDP Proxying supports all versions of HTTP and uses HTTP Datagrams 93 [HTTP-DGRAM]. When using HTTP/2 or HTTP/3, UDP proxying uses HTTP 94 Extended CONNECT as described in [EXT-CONNECT2] and [EXT-CONNECT3]. 95 When using HTTP/1.x, UDP proxying uses HTTP Upgrade as defined in 96 Section 7.8 of [SEMANTICS]. 98 1.1. Conventions and Definitions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 In this document, we use the term "proxy" to refer to the HTTP server 107 that opens the UDP socket and responds to the UDP proxying request. 108 If there are HTTP intermediaries (as defined in Section 3.7 of 109 [SEMANTICS]) between the client and the proxy, those are referred to 110 as "intermediaries" in this document. 112 Note that, when the HTTP version in use does not support multiplexing 113 streams (such as HTTP/1.1), any reference to "stream" in this 114 document represents the entire connection. 116 2. Configuration of Clients 118 Clients are configured to use UDP Proxying over HTTP via an URI 119 Template [TEMPLATE]. The URI template MUST contain exactly two 120 variables: "target_host" and "target_port". Examples are shown 121 below: 123 https://masque.example.org/{target_host}/{target_port}/ 124 https://proxy.example.org:4443/masque?h={target_host}&p={target_port} 125 https://proxy.example.org:4443/masque{?target_host,target_port} 127 Figure 1: URI Template Examples 129 Since the original HTTP CONNECT method allowed conveying the target 130 host and port but not the scheme, proxy authority, path, nor query, 131 there exist proxy configuration interfaces that only allow the user 132 to configure the proxy host and the proxy port. Client 133 implementations of this specification that are constrained by such 134 limitations MUST use the default template which is defined as: 135 "https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where 136 $PROXY_HOST and $PROXY_PORT are the configured host and port of the 137 proxy respectively. Proxy deployments SHOULD use the default 138 template to facilitate interoperability with such clients. 140 3. HTTP Exchanges 142 This document defines the "connect-udp" HTTP Upgrade Token. "connect- 143 udp" uses the Capsule Protocol as defined in [HTTP-DGRAM]. 145 A "connect-udp" request requests that the recipient establish a 146 tunnel over a single HTTP stream to the destination target server 147 identified by the "target_host" and "target_port" variables of the 148 URI template (see Section 2). If the request is successful, the 149 proxy commits to converting received HTTP Datagrams into UDP packets 150 and vice versa until the tunnel is closed. Tunnels are commonly used 151 to create an end-to-end virtual connection, which can then be secured 152 using QUIC [QUIC] or another protocol running over UDP. 154 When sending its UDP proxying request, the client SHALL perform URI 155 template expansion to determine the path and query of its request. 156 target_host supports using DNS names, IPv6 literals and IPv4 157 literals. Note that this URI template expansion requires using pct- 158 encoding, so for example if the target_host is "2001:db8::42", it 159 will be encoded in the URI as "2001%3Adb8%3A%3A42". 161 A payload within a UDP proxying request message has no defined 162 semantics; a UDP proxying request with a non-empty payload is 163 malformed. 165 Responses to UDP proxying requests are not cacheable. 167 3.1. Proxy Handling 169 Upon receiving a UDP proxying request, the recipient proxy extracts 170 the "target_host" and "target_port" variables from the URI it has 171 reconstructed from the request headers, and establishes a tunnel by 172 directly opening a UDP socket to the requested target. 174 Unlike TCP, UDP is connection-less. The proxy that opens the UDP 175 socket has no way of knowing whether the destination is reachable. 176 Therefore it needs to respond to the request without waiting for a 177 packet from the target. However, if the target_host is a DNS name, 178 the proxy MUST perform DNS resolution before replying to the HTTP 179 request. If DNS resolution fails, the proxy MUST fail the request 180 and SHOULD send details using the Proxy-Status header [PROXY-STATUS]. 182 Proxies can use connected UDP sockets if their operating system 183 supports them, as that allows the proxy to rely on the kernel to only 184 send it UDP packets that match the correct 5-tuple. If the proxy 185 uses a non-connected socket, it MUST validate the IP source address 186 and UDP source port on received packets to ensure they match the 187 client's request. Packets that do not match MUST be discarded by the 188 proxy. 190 The lifetime of the socket is tied to the request stream. The proxy 191 MUST keep the socket open while the request stream is open. If a 192 proxy is notified by its operating system that its socket is no 193 longer usable, it MUST close the request stream. Proxies MAY choose 194 to close sockets due to a period of inactivity, but they MUST close 195 the request stream before closing the socket. Proxies that close 196 sockets after a period of inactivity SHOULD NOT use a period lower 197 than two minutes, see Section 4.3 of [BEHAVE]. 199 A successful response (as defined in Section 3.3 and Section 3.5) 200 indicates that the proxy has opened a socket to the requested target 201 and is willing to proxy UDP payloads. Any response other than a 202 successful response indicates that the request has failed, and the 203 client MUST therefore abort the request. 205 3.2. HTTP Request over HTTP/1.1 207 When using HTTP/1.1, a UDP proxying request will meet the following 208 requirements: 210 * the method SHALL be "CONNECT". 212 * the request-target SHALL use absolute-form (see Section 3.2.2 of 213 [MESSAGING]). 215 * the request SHALL include a single Host header containing the 216 origin of the proxy. 218 * the request SHALL include a single "Connection" header with value 219 "Upgrade". 221 * the request SHALL include a single "Upgrade" header with value 222 "connect-udp". 224 For example, if the client is configured with URI template 225 "https://proxy.example.org/{target_host}/{target_port}/" and wishes 226 to open a UDP proxying tunnel to target 192.0.2.42:443, it could send 227 the following request: 229 CONNECT https://proxy.example.org/192.0.2.42/443/ HTTP/1.1 230 Host: proxy.example.org 231 Connection: upgrade 232 Upgrade: connect-udp 234 Figure 2: Example HTTP Request over HTTP/1.1 236 3.3. HTTP Response over HTTP/1.1 238 The proxy SHALL indicate a successful response by replying with the 239 following requirements: 241 * the HTTP status code on the response SHALL be 101 (Switching 242 Protocols). 244 * the reponse SHALL include a single "Connection" header with value 245 "Upgrade". 247 * the response SHALL include a single "Upgrade" header with value 248 "connect-udp". 250 * the response SHALL NOT include any Transfer-Encoding or Content- 251 Length header fields. 253 If any of these requirements are not met, the client MUST treat this 254 proxying attempt as failed and abort the connection. 256 For example, the proxy could respond with: 258 HTTP/1.1 101 Switching Protocols 259 Connection: upgrade 260 Upgrade: connect-udp 262 Figure 3: Example HTTP Response over HTTP/1.1 264 3.4. HTTP Request over HTTP/2 and HTTP/3 266 When using HTTP/2 [H2] or HTTP/3 [H3], UDP proxying requests use HTTP 267 pseudo-headers with the following requirements: 269 * The ":method" pseudo-header field SHALL be "CONNECT". 271 * The ":protocol" pseudo-header field SHALL be "connect-udp". 273 * The ":authority" pseudo-header field SHALL contain the authority 274 of the proxy. 276 * The ":path" and ":scheme" pseudo-header fields SHALL NOT be empty. 277 Their values SHALL contain the scheme and path from the URI 278 template after the URI template expansion process has been 279 completed. 281 A UDP proxying request that does not conform to these restrictions is 282 malformed (see Section 8.1.2.6 of [H2]). 284 For example, if the client is configured with URI template 285 "https://proxy.example.org/{target_host}/{target_port}/" and wishes 286 to open a UDP proxying tunnel to target 192.0.2.42:443, it could send 287 the following request: 289 HEADERS 290 :method = CONNECT 291 :protocol = connect-udp 292 :scheme = https 293 :path = /192.0.2.42/443/ 294 :authority = proxy.example.org 296 Figure 4: Example HTTP Request over HTTP/2 298 3.5. HTTP Response over HTTP/2 and HTTP/3 300 The proxy SHALL indicate a successful response by replying with any 301 2xx (Successful) HTTP status code, without any Transfer-Encoding or 302 Content-Length header fields. 304 If any of these requirements are not met, the client MUST treat this 305 proxying attempt as failed and abort the request. 307 For example, the proxy could respond with: 309 HEADERS 310 :status = 200 312 Figure 5: Example HTTP Response over HTTP/2 314 3.6. Note About Draft Versions 316 [[RFC editor: please remove this section before publication.]] 318 In order to allow implementations to support multiple draft versions 319 of this specification during its development, we introduce the 320 "connect-udp-version" header. When sent by the client, it contains a 321 list of draft numbers supported by the client (e.g., "connect-udp- 322 version: 0, 2"). When sent by the proxy, it contains a single draft 323 number selected by the proxy from the list provided by the client 324 (e.g., "connect-udp-version: 2"). Sending this header is RECOMMENDED 325 but not required. 327 4. Encoding of Proxied UDP Packets 329 UDP packets are encoded using HTTP Datagrams [HTTP-DGRAM] with the 330 UDP_PAYLOAD HTTP Datagram Format Type (see value in Section 7.2). 331 When using the UDP_PAYLOAD HTTP Datagram Format Type, the payload of 332 a UDP packet (referred to as "data octets" in [UDP]) is sent 333 unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram. 335 In order to use HTTP Datagrams, the client will first decide whether 336 or not to use HTTP Datagram Contexts and then register its context ID 337 (or lack thereof) using the corresponding registration capsule, see 338 [HTTP-DGRAM]. 340 When sending a REGISTER_DATAGRAM_CONTEXT or 341 REGISTER_DATAGRAM_NO_CONTEXT capsule using the "Datagram Format Type" 342 set to UDP_PAYLOAD, the "Datagram Format Additional Data" field SHALL 343 be empty. Servers MUST NOT register contexts using the UDP_PAYLOAD 344 HTTP Datagram Format Type. Clients MUST NOT register more than one 345 context using the UDP_PAYLOAD HTTP Datagram Format Type. Endpoints 346 MUST NOT close contexts using the UDP_PAYLOAD HTTP Datagram Format 347 Type. If an endpoint detects a violation of any of these 348 requirements, it MUST abort the stream. 350 Clients MAY optimistically start sending proxied UDP packets before 351 receiving the response to its UDP proxying request, noting however 352 that those may not be processed by the proxy if it responds to the 353 request with a failure, or if the datagrams are received by the proxy 354 before the request. 356 Extensions to this mechanism MAY define new HTTP Datagram Format 357 Types in order to use different semantics or encodings for UDP 358 payloads. 360 5. Performance Considerations 362 Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: 363 they SHOULD NOT queue packets in order to increase batching. 365 When the protocol running over UDP that is being proxied uses 366 congestion control (e.g., [QUIC]), the proxied traffic will incur at 367 least two nested congestion controllers. This can reduce performance 368 but the underlying HTTP connection MUST NOT disable congestion 369 control unless it has an out-of-band way of knowing with absolute 370 certainty that the inner traffic is congestion-controlled. 372 If a client or proxy with a connection containing a UDP proxying 373 request stream disables congestion control, it MUST NOT signal ECN 374 support on that connection. That is, it MUST mark all IP headers 375 with the Not-ECT codepoint. It MAY continue to report ECN feedback 376 via ACK_ECN frames, as the peer may not have disabled congestion 377 control. 379 When the protocol running over UDP that is being proxied uses loss 380 recovery (e.g., [QUIC]), and the underlying HTTP connection runs over 381 TCP, the proxied traffic will incur at least two nested loss recovery 382 mechanisms. This can reduce performance as both can sometimes 383 independently retransmit the same data. To avoid this, HTTP/3 384 datagrams SHOULD be used. 386 5.1. MTU Considerations 388 When using HTTP/3 with the QUIC Datagram extension [DGRAM], UDP 389 payloads are transmitted in QUIC DATAGRAM frames. Since those cannot 390 be fragmented, they can only carry payloads up to a given length 391 determined by the QUIC connection configuration and the path MTU. If 392 a proxy is using QUIC DATAGRAM frames and it receives a UDP payload 393 from the target that will not fit inside a QUIC DATAGRAM frame, the 394 proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that 395 defeats the end-to-end unreliability characteristic that methods such 396 as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend 397 on [RFC8899]. In this scenario, the proxy SHOULD drop the UDP 398 payload and send an ICMP "Packet Too Big" message to the target 399 [RFC4443]. 401 5.2. Tunneling of ECN Marks 403 UDP proxying does not create an IP-in-IP tunnel, so the guidance in 404 [RFC6040] about transferring ECN marks between inner and outer IP 405 headers does not apply. There is no inner IP header in UDP proxying 406 tunnels. 408 Note that UDP proxying clients do not have the ability in this 409 specification to control the ECN codepoints on UDP packets the proxy 410 sends to the server, nor can proxies communicate the markings of each 411 UDP packet from server to proxy. 413 A UDP proxy MUST ignore ECN bits in the IP header of UDP packets 414 received from the server, and MUST set the ECN bits to Not-ECT on UDP 415 packets it sends to the server. These do not relate to the ECN 416 markings of packets sent between client and proxy in any way. 418 6. Security Considerations 420 There are significant risks in allowing arbitrary clients to 421 establish a tunnel to arbitrary servers, as that could allow bad 422 actors to send traffic and have it attributed to the proxy. Proxies 423 that support UDP proxying SHOULD restrict its use to authenticated 424 users. 426 Because the CONNECT method creates a TCP connection to the target, 427 the target has to indicate its willingness to accept TCP connections 428 by responding with a TCP SYN-ACK before the proxy can send it 429 application data. UDP doesn't have this property, so a UDP proxy 430 could send more data to an unwilling target than a CONNECT proxy. 431 However, in practice denial of service attacks target open TCP ports 432 so the TCP SYN-ACK does not offer much protection in real scenarios. 433 Proxies MUST NOT introspect the contents of UDP payloads as that 434 would lead to ossification of UDP-based protocols by proxies. 436 7. IANA Considerations 438 7.1. HTTP Upgrade Token 440 This document will request IANA to register "connect-udp" in the HTTP 441 Upgrade Token Registry maintained at 442 . 444 Value: connect-udp 446 Description: Proxying of UDP Payloads. 448 Expected Version Tokens: None. 450 Reference: This document. 452 7.2. Datagram Format Type 454 This document will request IANA to register UDP_PAYLOAD in the "HTTP 455 Datagram Format Types" registry established by [HTTP-DGRAM]. 457 +=============+==========+===============+ 458 | Type | Value | Specification | 459 +=============+==========+===============+ 460 | UDP_PAYLOAD | 0xff6f00 | This Document | 461 +-------------+----------+---------------+ 463 Table 1: Registered Datagram Format Type 465 8. References 467 8.1. Normative References 469 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 470 Datagram Extension to QUIC", Work in Progress, Internet- 471 Draft, draft-ietf-quic-datagram-06, 5 October 2021, 472 . 475 [EXT-CONNECT2] 476 McManus, P., "Bootstrapping WebSockets with HTTP/2", 477 RFC 8441, DOI 10.17487/RFC8441, September 2018, 478 . 480 [EXT-CONNECT3] 481 Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work 482 in Progress, Internet-Draft, draft-ietf-httpbis-h3- 483 websockets-00, 9 September 2021, 484 . 487 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 488 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 489 DOI 10.17487/RFC7540, May 2015, 490 . 492 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 493 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 494 quic-http-34, 2 February 2021, 495 . 498 [HTTP-DGRAM] 499 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 500 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 501 datagram-04, 6 October 2021, 502 . 505 [MESSAGING] 506 Fielding, R. T., Nottingham, M., and J. Reschke, 507 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 508 httpbis-messaging-19, 12 September 2021, 509 . 512 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 513 Multiplexed and Secure Transport", RFC 9000, 514 DOI 10.17487/RFC9000, May 2021, 515 . 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 523 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 524 May 2017, . 526 [SEMANTICS] 527 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 528 Semantics", Work in Progress, Internet-Draft, draft-ietf- 529 httpbis-semantics-19, 12 September 2021, 530 . 533 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 534 RFC 793, DOI 10.17487/RFC0793, September 1981, 535 . 537 [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 538 and D. Orchard, "URI Template", RFC 6570, 539 DOI 10.17487/RFC6570, March 2012, 540 . 542 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 543 DOI 10.17487/RFC0768, August 1980, 544 . 546 8.2. Informative References 548 [BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address 549 Translation (NAT) Behavioral Requirements for Unicast 550 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 551 2007, . 553 [PROXY-STATUS] 554 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 555 Response Header Field", Work in Progress, Internet-Draft, 556 draft-ietf-httpbis-proxy-status-06, 16 August 2021, 557 . 560 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 561 Control Message Protocol (ICMPv6) for the Internet 562 Protocol Version 6 (IPv6) Specification", STD 89, 563 RFC 4443, DOI 10.17487/RFC4443, March 2006, 564 . 566 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 567 Notification", RFC 6040, DOI 10.17487/RFC6040, November 568 2010, . 570 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 571 Völker, "Packetization Layer Path MTU Discovery for 572 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 573 September 2020, . 575 Acknowledgments 577 This document is a product of the MASQUE Working Group, and the 578 author thanks all MASQUE enthusiasts for their contibutions. This 579 proposal was inspired directly or indirectly by prior work from many 580 people. In particular, the author would like to thank Eric Rescorla 581 for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas 582 Pardue for their inputs on this document. 584 Author's Address 586 David Schinazi 587 Google LLC 588 1600 Amphitheatre Parkway 589 Mountain View, California 94043, 590 United States of America 592 Email: dschinazi.ietf@gmail.com