idnits 2.17.1 draft-ietf-masque-connect-udp-06.txt: -(569): 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 (25 October 2021) is 885 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-05 -- 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) Summary: 2 errors (**), 0 flaws (~~), 5 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 25 October 2021 5 Expires: 28 April 2022 7 UDP Proxying Support for HTTP 8 draft-ietf-masque-connect-udp-06 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 28 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 it will attempt to use HTTP Datagram Contexts and then 337 register its context ID (or lack thereof) using the corresponding 338 registration capsule, see [HTTP-DGRAM]. 340 When sending a registration capsule using the "Datagram Format Type" 341 set to UDP_PAYLOAD, the "Datagram Format Additional Data" field SHALL 342 be empty. Servers MUST NOT register contexts using the UDP_PAYLOAD 343 HTTP Datagram Format Type. Clients MUST NOT register more than one 344 context using the UDP_PAYLOAD HTTP Datagram Format Type. Endpoints 345 MUST NOT close contexts using the UDP_PAYLOAD HTTP Datagram Format 346 Type. If an endpoint detects a violation of any of these 347 requirements, it MUST abort the stream. 349 Clients MAY optimistically start sending proxied UDP packets before 350 receiving the response to its UDP proxying request, noting however 351 that those may not be processed by the proxy if it responds to the 352 request with a failure, or if the datagrams are received by the proxy 353 before the request. 355 Extensions to this mechanism MAY define new HTTP Datagram Format 356 Types in order to use different semantics or encodings for UDP 357 payloads. 359 5. Performance Considerations 361 Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: 362 they SHOULD NOT queue packets in order to increase batching. 364 When the protocol running over UDP that is being proxied uses 365 congestion control (e.g., [QUIC]), the proxied traffic will incur at 366 least two nested congestion controllers. This can reduce performance 367 but the underlying HTTP connection MUST NOT disable congestion 368 control unless it has an out-of-band way of knowing with absolute 369 certainty that the inner traffic is congestion-controlled. 371 If a client or proxy with a connection containing a UDP proxying 372 request stream disables congestion control, it MUST NOT signal ECN 373 support on that connection. That is, it MUST mark all IP headers 374 with the Not-ECT codepoint. It MAY continue to report ECN feedback 375 via ACK_ECN frames, as the peer may not have disabled congestion 376 control. 378 When the protocol running over UDP that is being proxied uses loss 379 recovery (e.g., [QUIC]), and the underlying HTTP connection runs over 380 TCP, the proxied traffic will incur at least two nested loss recovery 381 mechanisms. This can reduce performance as both can sometimes 382 independently retransmit the same data. To avoid this, HTTP/3 383 datagrams SHOULD be used. 385 5.1. MTU Considerations 387 When using HTTP/3 with the QUIC Datagram extension [DGRAM], UDP 388 payloads are transmitted in QUIC DATAGRAM frames. Since those cannot 389 be fragmented, they can only carry payloads up to a given length 390 determined by the QUIC connection configuration and the path MTU. If 391 a proxy is using QUIC DATAGRAM frames and it receives a UDP payload 392 from the target that will not fit inside a QUIC DATAGRAM frame, the 393 proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that 394 defeats the end-to-end unreliability characteristic that methods such 395 as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend 396 on [RFC8899]. In this scenario, the proxy SHOULD drop the UDP 397 payload and send an ICMP "Packet Too Big" message to the target 398 [RFC4443]. 400 5.2. Tunneling of ECN Marks 402 UDP proxying does not create an IP-in-IP tunnel, so the guidance in 403 [RFC6040] about transferring ECN marks between inner and outer IP 404 headers does not apply. There is no inner IP header in UDP proxying 405 tunnels. 407 Note that UDP proxying clients do not have the ability in this 408 specification to control the ECN codepoints on UDP packets the proxy 409 sends to the server, nor can proxies communicate the markings of each 410 UDP packet from server to proxy. 412 A UDP proxy MUST ignore ECN bits in the IP header of UDP packets 413 received from the server, and MUST set the ECN bits to Not-ECT on UDP 414 packets it sends to the server. These do not relate to the ECN 415 markings of packets sent between client and proxy in any way. 417 6. Security Considerations 419 There are significant risks in allowing arbitrary clients to 420 establish a tunnel to arbitrary servers, as that could allow bad 421 actors to send traffic and have it attributed to the proxy. Proxies 422 that support UDP proxying SHOULD restrict its use to authenticated 423 users. 425 Because the CONNECT method creates a TCP connection to the target, 426 the target has to indicate its willingness to accept TCP connections 427 by responding with a TCP SYN-ACK before the proxy can send it 428 application data. UDP doesn't have this property, so a UDP proxy 429 could send more data to an unwilling target than a CONNECT proxy. 430 However, in practice denial of service attacks target open TCP ports 431 so the TCP SYN-ACK does not offer much protection in real scenarios. 432 Proxies MUST NOT introspect the contents of UDP payloads as that 433 would lead to ossification of UDP-based protocols by proxies. 435 7. IANA Considerations 437 7.1. HTTP Upgrade Token 439 This document will request IANA to register "connect-udp" in the HTTP 440 Upgrade Token Registry maintained at 441 . 443 Value: connect-udp 445 Description: Proxying of UDP Payloads. 447 Expected Version Tokens: None. 449 Reference: This document. 451 7.2. Datagram Format Type 453 This document will request IANA to register UDP_PAYLOAD in the "HTTP 454 Datagram Format Types" registry established by [HTTP-DGRAM]. 456 +=============+==========+===============+ 457 | Type | Value | Specification | 458 +=============+==========+===============+ 459 | UDP_PAYLOAD | 0xff6f00 | This Document | 460 +-------------+----------+---------------+ 462 Table 1: Registered Datagram Format Type 464 8. References 466 8.1. Normative References 468 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 469 Datagram Extension to QUIC", Work in Progress, Internet- 470 Draft, draft-ietf-quic-datagram-06, 5 October 2021, 471 . 474 [EXT-CONNECT2] 475 McManus, P., "Bootstrapping WebSockets with HTTP/2", 476 RFC 8441, DOI 10.17487/RFC8441, September 2018, 477 . 479 [EXT-CONNECT3] 480 Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work 481 in Progress, Internet-Draft, draft-ietf-httpbis-h3- 482 websockets-00, 9 September 2021, 483 . 486 [H2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 487 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 488 DOI 10.17487/RFC7540, May 2015, 489 . 491 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 492 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 493 quic-http-34, 2 February 2021, 494 . 497 [HTTP-DGRAM] 498 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 499 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 500 datagram-05, 25 October 2021, 501 . 504 [MESSAGING] 505 Fielding, R. T., Nottingham, M., and J. Reschke, 506 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 507 httpbis-messaging-19, 12 September 2021, 508 . 511 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 512 Multiplexed and Secure Transport", RFC 9000, 513 DOI 10.17487/RFC9000, May 2021, 514 . 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, 518 DOI 10.17487/RFC2119, March 1997, 519 . 521 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 522 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 523 May 2017, . 525 [SEMANTICS] 526 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 527 Semantics", Work in Progress, Internet-Draft, draft-ietf- 528 httpbis-semantics-19, 12 September 2021, 529 . 532 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 533 RFC 793, DOI 10.17487/RFC0793, September 1981, 534 . 536 [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 537 and D. Orchard, "URI Template", RFC 6570, 538 DOI 10.17487/RFC6570, March 2012, 539 . 541 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 542 DOI 10.17487/RFC0768, August 1980, 543 . 545 8.2. Informative References 547 [BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address 548 Translation (NAT) Behavioral Requirements for Unicast 549 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 550 2007, . 552 [PROXY-STATUS] 553 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 554 Response Header Field", Work in Progress, Internet-Draft, 555 draft-ietf-httpbis-proxy-status-08, 13 October 2021, 556 . 559 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 560 Control Message Protocol (ICMPv6) for the Internet 561 Protocol Version 6 (IPv6) Specification", STD 89, 562 RFC 4443, DOI 10.17487/RFC4443, March 2006, 563 . 565 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 566 Notification", RFC 6040, DOI 10.17487/RFC6040, November 567 2010, . 569 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 570 Völker, "Packetization Layer Path MTU Discovery for 571 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 572 September 2020, . 574 Acknowledgments 576 This document is a product of the MASQUE Working Group, and the 577 author thanks all MASQUE enthusiasts for their contibutions. This 578 proposal was inspired directly or indirectly by prior work from many 579 people. In particular, the author would like to thank Eric Rescorla 580 for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas 581 Pardue for their inputs on this document. 583 Author's Address 585 David Schinazi 586 Google LLC 587 1600 Amphitheatre Parkway 588 Mountain View, California 94043, 589 United States of America 591 Email: dschinazi.ietf@gmail.com