draft-ietf-masque-connect-udp-08.txt		draft-ietf-masque-connect-udp-09.txt
	MASQUE D. Schinazi		MASQUE D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track 21 March 2022		Intended status: Standards Track 11 April 2022
	Expires: 22 September 2022		Expires: 13 October 2022
	UDP Proxying Support for HTTP		UDP Proxying Support for HTTP
	draft-ietf-masque-connect-udp-08		draft-ietf-masque-connect-udp-09
	Abstract		Abstract
	This document describes how to proxy UDP over HTTP. Similar to how		This document describes how to proxy UDP over HTTP. Similar to how
	the CONNECT method allows proxying TCP over HTTP, this document		the CONNECT method allows proxying TCP over HTTP, this document
	defines a new mechanism to proxy UDP. It is built using HTTP		defines a new mechanism to proxy UDP. When using HTTP/2 or HTTP/3,
	Extended CONNECT.		it uses Extended CONNECT; when using HTTP/1.1, it uses Upgrade.
	Discussion Venues		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this document takes place on the MASQUE WG mailing list		The latest revision of this draft can be found at https://ietf-wg-
	(masque@ietf.org), which is archived at		masque.github.io/draft-ietf-masque-connect-udp/draft-ietf-masque-
			connect-udp.html. Status information for this document may be found
			at https://datatracker.ietf.org/doc/draft-ietf-masque-connect-udp/.
			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/.		https://mailarchive.ietf.org/arch/browse/masque/.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp.		https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 22 September 2022.		This Internet-Draft will expire on 13 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 25 ¶
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3		1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
	2. Configuration of Clients . . . . . . . . . . . . . . . . . . 3		2. Configuration of Clients . . . . . . . . . . . . . . . . . . 3
	3. HTTP Exchanges . . . . . . . . . . . . . . . . . . . . . . . 4		3. HTTP Exchanges . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Proxy Handling . . . . . . . . . . . . . . . . . . . . . 4		3.1. Proxy Handling . . . . . . . . . . . . . . . . . . . . . 5
	3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 5		3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 6
	3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 6		3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 7
	3.4. HTTP Request over HTTP/2 and HTTP/3 . . . . . . . . . . . 7		3.4. HTTP Request over HTTP/2 and HTTP/3 . . . . . . . . . . . 7
	3.5. HTTP Response over HTTP/2 and HTTP/3 . . . . . . . . . . 7		3.5. HTTP Response over HTTP/2 and HTTP/3 . . . . . . . . . . 8
	3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 8		3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 8
	4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 8		4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 9
	5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 9		5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 9
	6. Performance Considerations . . . . . . . . . . . . . . . . . 10		6. Performance Considerations . . . . . . . . . . . . . . . . . 10
	6.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 10		6.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 11
	6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 11		6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 11		8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 12
	8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12		8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This document describes how to proxy UDP over HTTP. Similar to how		This document describes how to proxy UDP over HTTP. Similar to how
	the CONNECT method (see Section 9.3.6 of [HTTP]) allows proxying TCP		the CONNECT method (see Section 9.3.6 of [HTTP]) allows proxying TCP
	[TCP] over HTTP, this document defines a new mechanism to proxy UDP		[TCP] over HTTP, this document defines a new mechanism to proxy UDP
	[UDP].		[UDP].
	UDP Proxying supports all versions of HTTP and uses HTTP Datagrams		UDP Proxying supports all versions of HTTP and uses HTTP Datagrams
	[HTTP-DGRAM]. When using HTTP/2 or HTTP/3, UDP proxying uses HTTP		[HTTP-DGRAM]. When using HTTP/2 [HTTP/2] or HTTP/3 [HTTP/3], UDP
	Extended CONNECT as described in [EXT-CONNECT2] and [EXT-CONNECT3].		proxying uses HTTP Extended CONNECT as described in [EXT-CONNECT2]
	When using HTTP/1.x, UDP proxying uses HTTP Upgrade as defined in		and [EXT-CONNECT3]. When using HTTP/1.x [HTTP/1.1], UDP proxying
	Section 7.8 of [HTTP].		uses HTTP Upgrade as defined in Section 7.8 of [HTTP].
	1.1. Conventions and Definitions		1.1. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	In this document, we use the term "proxy" to refer to the HTTP server		In this document, we use the term "proxy" to refer to the HTTP server
	that opens the UDP socket and responds to the UDP proxying request.		that acts upon the client's UDP proxying request to open a UDP socket
	If there are HTTP intermediaries (as defined in Section 3.7 of		to a target server, and generates the response to this request. If
	[HTTP]) between the client and the proxy, those are referred to as		there are HTTP intermediaries (as defined in Section 3.7 of [HTTP])
			between the client and the proxy, those are referred to as
	"intermediaries" in this document.		"intermediaries" in this document.
	Note that, when the HTTP version in use does not support multiplexing		Note that, when the HTTP version in use does not support multiplexing
	streams (such as HTTP/1.1), any reference to "stream" in this		streams (such as HTTP/1.1), any reference to "stream" in this
	document represents the entire connection.		document represents the entire connection.
	2. Configuration of Clients		2. Configuration of Clients
	Clients are configured to use UDP Proxying over HTTP via an URI		Clients are configured to use UDP Proxying over HTTP via a URI
	Template [TEMPLATE] with the variables "target_host" and		Template [TEMPLATE] with the variables "target_host" and
	"target_port". Examples are shown below:		"target_port". Examples are shown below:
	https://masque.example.org/.well-known/masque/udp/{target_host}/{target_port}/		https://masque.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?h={target_host}&p={target_port}
	https://proxy.example.org:4443/masque{?target_host,target_port}		https://proxy.example.org:4443/masque{?target_host,target_port}
	Figure 1: URI Template Examples		Figure 1: URI Template Examples
	The URI template MUST be a level 3 template or lower. The URI		The following requirements apply to the URI Template:
	template MUST be in absolute form, and MUST include non-empty scheme,
	authority and path components. The path component of the URI		* The URI Template MUST be a level 3 template or lower.
	template MUST start with a slash "/". All template variables MUST be
	within the path component of the URI. The URI template MUST contain		* The URI Template MUST be in absolute form, and MUST include non-
	the two variables "target_host" and "target_port" and MAY contain		empty scheme, authority and path components.
	other variables. The URI template MUST NOT contain any non-ASCII
	unicode characters and MUST only contain ASCII characters in the		* The path component of the URI Template MUST start with a slash
	range 0x21-0x7E inclusive (note that percent-encoding is allowed).		"/".
	The URI template MUST NOT use Reserved Expansion ("+" operator),
	Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix,		* All template variables MUST be within the path component of the
	Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter		URI.
	Expansion with Semicolon-Prefix. If any of the requirements above
	are not met by a URI template, the client MUST reject its		* The URI template MUST contain the two variables "target_host" and
	configuration and fail the request without sending it to the proxy.		"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).
			* 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.
			If any of the requirements above are not met by a URI Template, the
			client MUST reject its configuration and fail the request without
			sending it to the proxy.
	Since the original HTTP CONNECT method allowed conveying the target		Since the original HTTP CONNECT method allowed conveying the target
	host and port but not the scheme, proxy authority, path, nor query,		host and port but not the scheme, proxy authority, path, nor query,
	there exist proxy configuration interfaces that only allow the user		there exist proxy configuration interfaces that only allow the user
	to configure the proxy host and the proxy port. Client		to configure the proxy host and the proxy port. Client
	implementations of this specification that are constrained by such		implementations of this specification that are constrained by such
	limitations MUST use the default template which is defined as:		limitations MAY attempt to access UDP Proxying capabilities using the
			default template, which is defined as:
	"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/		"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
	udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT		udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT
	are the configured host and port of the proxy respectively. Proxy		are the configured host and port of the proxy respectively. Proxy
	deployments SHOULD use the default template to facilitate		deployments SHOULD offer service at this location if they need to
	interoperability with such clients.		interoperate with such clients.
			Clients MAY interpret HTTP 400, 404, or 405 response codes as
			indications that the URI template is not correct. Servers MUST NOT
			return these response codes if the request is well-formed and the URI
			matches a supported template.
	3. HTTP Exchanges		3. HTTP Exchanges
	This document defines the "connect-udp" HTTP Upgrade Token. "connect-		This document defines the "connect-udp" HTTP Upgrade Token. "connect-
	udp" uses the Capsule Protocol as defined in [HTTP-DGRAM].		udp" uses the Capsule Protocol as defined in Section 3.2 of
			[HTTP-DGRAM]. The format of HTTP Datagrams is defined in Section 5.
	A "connect-udp" request requests that the recipient proxy establish a		Clients issue requests containing a "connect-udp" upgrade token to
	tunnel over a single HTTP stream to the destination target identified		initiate a UDP tunnel associated with a single HTTP stream. Tunnels
	by the "target_host" and "target_port" variables of the URI template		are commonly used to create an end-to-end virtual connection, which
	(see Section 2). If the request is successful, the proxy commits to		can then be secured using QUIC [QUIC] or another protocol running
	converting received HTTP Datagrams into UDP packets and vice versa		over UDP. The target of the tunnel is indicated by the client to the
	until the tunnel is closed. Tunnels are commonly used to create an		proxy via the "target_host" and "target_port" variables of the URI
	end-to-end virtual connection, which can then be secured using QUIC		Template (see Section 2). If the request is successful, the proxy
	[QUIC] or another protocol running over UDP.		commits to converting received HTTP Datagrams into UDP packets and
			vice versa until the tunnel is closed.
	When sending its UDP proxying request, the client SHALL perform URI		When sending its UDP proxying request, the client SHALL perform URI
	template expansion to determine the path and query of its request.		Template expansion to determine the path and query of its request.
	target_host supports using DNS names, IPv6 literals and IPv4		target_host supports using DNS names, IPv6 literals and IPv4
	literals. Note that this URI template expansion requires using pct-		literals. Note that this URI Template expansion requires using pct-
	encoding, so for example if the target_host is "2001:db8::42", it		encoding, so for example if the target_host is "2001:db8::42", it
	will be encoded in the URI as "2001%3Adb8%3A%3A42".		will be encoded in the URI as "2001%3Adb8%3A%3A42".
	A payload within a UDP proxying request message has no defined		By virtue of the definition of the Capsule Protocol (see
	semantics; a UDP proxying request with a non-empty payload is		[HTTP-DGRAM]), UDP proxying requests do not carry any message
	malformed.		content. Similarly, successful UDP proxying responses also do not
			carry any message content.
	Responses to UDP proxying requests are not cacheable.		Responses to UDP proxying requests are not cacheable.
	3.1. Proxy Handling		3.1. Proxy Handling
	Upon receiving a UDP proxying request, the recipient proxy extracts		Upon receiving a UDP proxying request, the recipient proxy extracts
	the "target_host" and "target_port" variables from the URI it has		the "target_host" and "target_port" variables from the URI it has
	reconstructed from the request headers, and establishes a tunnel by		reconstructed from the request headers, and establishes a tunnel by
	directly opening a UDP socket to the requested target.		directly opening a UDP socket to the requested target.
	Unlike TCP, UDP is connection-less. The proxy that opens the UDP		Unlike TCP, UDP is connection-less. The proxy that opens the UDP
	socket has no way of knowing whether the destination is reachable.		socket has no way of knowing whether the destination is reachable.
	Therefore it needs to respond to the request without waiting for a		Therefore it needs to respond to the request without waiting for a
	packet from the target. However, if the target_host is a DNS name,		packet from the target. However, if the target_host is a DNS name,
	the proxy MUST perform DNS resolution before replying to the HTTP		the proxy MUST perform DNS resolution before replying to the HTTP
	request. If DNS resolution fails, the proxy MUST fail the request		request. If errors occur during this process (for example, a DNS
	and SHOULD send details using the Proxy-Status header [PROXY-STATUS].		resolution failure), the proxy MUST fail the request and SHOULD send
			details using the Proxy-Status header field [PROXY-STATUS].
	Proxies can use connected UDP sockets if their operating system		Proxies can use connected UDP sockets if their operating system
	supports them, as that allows the proxy to rely on the kernel to only		supports them, as that allows the proxy to rely on the kernel to only
	send it UDP packets that match the correct 5-tuple. If the proxy		send it UDP packets that match the correct 5-tuple. If the proxy
	uses a non-connected socket, it MUST validate the IP source address		uses a non-connected socket, it MUST validate the IP source address
	and UDP source port on received packets to ensure they match the		and UDP source port on received packets to ensure they match the
	client's request. Packets that do not match MUST be discarded by the		client's request. Packets that do not match MUST be discarded by the
	proxy.		proxy.
	The lifetime of the socket is tied to the request stream. The proxy		The lifetime of the socket is tied to the request stream. The proxy
	skipping to change at page 5, line 45 ¶		skipping to change at page 6, line 23 ¶
	successful response indicates that the request has failed, and the		successful response indicates that the request has failed, and the
	client MUST therefore abort the request.		client MUST therefore abort the request.
	Proxies MUST NOT introduce fragmentation at the IP layer when		Proxies MUST NOT introduce fragmentation at the IP layer when
	forwarding HTTP Datagrams onto a UDP socket. In IPv4, the Don't		forwarding HTTP Datagrams onto a UDP socket. In IPv4, the Don't
	Fragment (DF) bit MUST be set if possible, to prevent fragmentation		Fragment (DF) bit MUST be set if possible, to prevent fragmentation
	on the path. Future extensions MAY remove these requirements.		on the path. Future extensions MAY remove these requirements.
	3.2. HTTP Request over HTTP/1.1		3.2. HTTP Request over HTTP/1.1
	When using HTTP/1.1, a UDP proxying request will meet the following		When using HTTP/1.1 [HTTP/1.1], a UDP proxying request will meet the
	requirements:		following requirements:
	* the method SHALL be "GET".		* the method SHALL be "GET".
	* the request-target SHALL use absolute-form (see Section 3.2.2 of		* the request-target SHALL use absolute-form (see Section 3.2.2 of
	[H1]).		[HTTP/1.1]).
	* the request SHALL include a single Host header containing the		* the request SHALL include a single Host header field containing
	origin of the proxy.		the origin of the proxy.
	* the request SHALL include a single "Connection" header with value		* the request SHALL include a single "Connection" header field with
	"Upgrade".		value "Upgrade" (note that this requirement is case-insensitive as
			per Section 7.6.1 of [HTTP]).
	* the request SHALL include a single "Upgrade" header with value		* the request SHALL include a single "Upgrade" header field with
	"connect-udp".		value "connect-udp".
	For example, if the client is configured with URI template		For example, if the client is configured with URI Template
	"https://proxy.example.org/.well-known/masque/		"https://proxy.example.org/.well-known/masque/
	udp/{target_host}/{target_port}/" and wishes to open a UDP proxying		udp/{target_host}/{target_port}/" and wishes to open a UDP proxying
	tunnel to target 192.0.2.42:443, it could send the following request:		tunnel to target 192.0.2.42:443, it could send the following request:
	GET https://proxy.example.org/.well-known/masque/udp/192.0.2.42/443/ HTTP/1.1		GET https://proxy.example.org/.well-known/masque/udp/192.0.2.42/443/ HTTP/1.1
	Host: proxy.example.org		Host: proxy.example.org
	Connection: upgrade		Connection: Upgrade
	Upgrade: connect-udp		Upgrade: connect-udp
	Figure 2: Example HTTP Request over HTTP/1.1		Figure 2: Example HTTP Request over HTTP/1.1
	3.3. HTTP Response over HTTP/1.1		3.3. HTTP Response over HTTP/1.1
	The proxy SHALL indicate a successful response by replying with the		The proxy SHALL indicate a successful response by replying with the
	following requirements:		following requirements:
	* the HTTP status code on the response SHALL be 101 (Switching		* the HTTP status code on the response SHALL be 101 (Switching
	Protocols).		Protocols).
	* the reponse SHALL include a single "Connection" header with value		* the reponse SHALL include a single "Connection" header field with
	"Upgrade".		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 with value		* the response SHALL include a single "Upgrade" header field with
	"connect-udp".		value "connect-udp".
	* the response SHALL NOT include any Transfer-Encoding or Content-		* the response SHALL NOT include any Transfer-Encoding or Content-
	Length header fields.		Length header fields.
	If any of these requirements are not met, the client MUST treat this		If any of these requirements are not met, the client MUST treat this
	proxying attempt as failed and abort the connection.		proxying attempt as failed and abort the connection.
	For example, the proxy could respond with:		For example, the proxy could respond with:
	HTTP/1.1 101 Switching Protocols		HTTP/1.1 101 Switching Protocols
	Connection: upgrade		Connection: Upgrade
	Upgrade: connect-udp		Upgrade: connect-udp
	Figure 3: Example HTTP Response over HTTP/1.1		Figure 3: Example HTTP Response over HTTP/1.1
	3.4. HTTP Request over HTTP/2 and HTTP/3		3.4. HTTP Request over HTTP/2 and HTTP/3
	When using HTTP/2 [H2] or HTTP/3 [H3], UDP proxying requests use HTTP		When using HTTP/2 [HTTP/2] or HTTP/3 [HTTP/3], UDP proxying requests
	pseudo-headers with the following requirements:		use 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 ":method" pseudo-header field SHALL be "CONNECT".
	* The ":protocol" pseudo-header field SHALL be "connect-udp".		* The ":protocol" pseudo-header field SHALL be "connect-udp".
	* The ":authority" pseudo-header field SHALL contain the authority		* The ":authority" pseudo-header field SHALL contain the authority
	of the proxy.		of the proxy.
	* The ":path" and ":scheme" pseudo-header fields SHALL NOT be empty.		* The ":path" and ":scheme" pseudo-header fields SHALL NOT be empty.
	Their values SHALL contain the scheme and path from the URI		Their values SHALL contain the scheme and path from the URI
	template after the URI template expansion process has been		Template after the URI template expansion process has been
	completed.		completed.
	A UDP proxying request that does not conform to these restrictions is		A UDP proxying request that does not conform to these restrictions is
	malformed (see Section 8.1.1 of [H2]).		malformed (see Section 8.1.1 of [HTTP/2]).
	For example, if the client is configured with URI template		For example, if the client is configured with URI Template
	"https://proxy.example.org/{target_host}/{target_port}/" and wishes		"https://proxy.example.org/{target_host}/{target_port}/" and wishes
	to open a UDP proxying tunnel to target 192.0.2.42:443, it could send		to open a UDP proxying tunnel to target 192.0.2.42:443, it could send
	the following request:		the following request:
	HEADERS		HEADERS
	:method = CONNECT		:method = CONNECT
	:protocol = connect-udp		:protocol = connect-udp
	:scheme = https		:scheme = https
	:path = /.well-known/masque/udp/192.0.2.42/443/		:path = /.well-known/masque/udp/192.0.2.42/443/
	:authority = proxy.example.org		:authority = proxy.example.org
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 35 ¶
	2xx (Successful) HTTP status code, without any Transfer-Encoding or		2xx (Successful) HTTP status code, without any Transfer-Encoding or
	Content-Length header fields.		Content-Length header fields.
	If any of these requirements are not met, the client MUST treat this		If any of these requirements are not met, the client MUST treat this
	proxying attempt as failed and abort the request.		proxying attempt as failed and abort the request.
	For example, the proxy could respond with:		For example, the proxy could respond with:
	HEADERS		HEADERS
	:status = 200		:status = 200
	Figure 5: Example HTTP Response over HTTP/2		Figure 5: Example HTTP Response over HTTP/2
	3.6. Note About Draft Versions		3.6. Note About Draft Versions
	[[RFC editor: please remove this section before publication.]]		[[RFC editor: please remove this section before publication.]]
	In order to allow implementations to support multiple draft versions		In order to allow implementations to support multiple draft versions
	of this specification during its development, we introduce the		of this specification during its development, we introduce the
	"connect-udp-version" header. When sent by the client, it contains a		"connect-udp-version" header field. When sent by the client, it
	list of draft numbers supported by the client (e.g., "connect-udp-		contains a list of draft numbers supported by the client (e.g.,
	version: 0, 2"). When sent by the proxy, it contains a single draft		"connect-udp-version: 0, 2"). When sent by the proxy, it contains a
	number selected by the proxy from the list provided by the client		single draft number selected by the proxy from the list provided by
	(e.g., "connect-udp-version: 2"). Sending this header is RECOMMENDED		the client (e.g., "connect-udp-version: 2"). Sending this header
	but not required. Its ABNF is:		field is RECOMMENDED but not required. The "connect-udp-version"
			header field is a List Structured Field, see Section 3.1 of
	connect-udp-version = sf-list		[STRUCT-FIELD]. Each list member MUST be an Integer.
	4. Context Identifiers		4. Context Identifiers
	This protocol allows future extensions to exchange HTTP Datagrams		This protocol allows future extensions to exchange HTTP Datagrams
	which carry different semantics from UDP payloads. Some of these		which carry different semantics from UDP payloads. Some of these
	extensions can augment UDP payloads with additional data, while		extensions can augment UDP payloads with additional data, while
	others can exchange data that is completely separate from UDP		others can exchange data that is completely separate from UDP
	payloads. In order to accomplish this, all HTTP Datagrams associated		payloads. In order to accomplish this, all HTTP Datagrams associated
	with UDP Proxying request streams start with a context ID, see		with UDP Proxying request streams start with a context ID, see
	Section 5.		Section 5.
	Context IDs are 62-bit integers (0 to 2^62-1). Context IDs are		Context IDs are 62-bit integers (0 to 2^62-1). Context IDs are
	encoded as variable-length integers, see Section 16 of [QUIC]. The		encoded as variable-length integers, see Section 16 of [QUIC]. The
	context ID value of 0 is reserved for UDP payloads, while non-zero		context ID value of 0 is reserved for UDP payloads, while non-zero
	values are dynamically allocated: non-zero even-numbered context IDs		values are dynamically allocated: non-zero even-numbered context IDs
	are client-allocated, and odd-numbered context IDs are proxy-		are client-allocated, and odd-numbered context IDs are proxy-
	allocated. The context ID namespace is tied to a given HTTP request:		allocated. The context ID namespace is tied to a given HTTP request:
	it is possible for a context ID with the same numeric value to be		it is possible for a context ID with the same numeric value to be
	simultaneously assigned different semantics in distinct requests,		simultaneously allocated in distinct requests, potentially with
	potentially with different semantics. Context IDs MUST NOT be re-		different semantics. Context IDs MUST NOT be re-allocated within a
	allocated within a given HTTP namespace but MAY be allocated in any		given HTTP namespace but MAY be allocated in any order. The context
	order. Once allocated, any context ID can be used by both client and		ID allocation restrictions to the use of even-numbered and odd-
	proxy - only allocation carries separate namespaces to avoid		numbered context IDs exist in order to avoid the need for
	requiring synchronization.		synchronisation between endpoints. However, once a context ID has
			been allocated, those restrictions do not apply to the use of the
			context ID: it can be used by any client or proxy, independent of
			which endpoint initially allocated it.
	Registration is the action by which an endpoint informs its peer of		Registration is the action by which an endpoint informs its peer of
	the semantics and format of a given context ID. This document does		the semantics and format of a given context ID. This document does
	not define how registration occurs. Future extensions MAY use HTTP		not define how registration occurs. Future extensions MAY use HTTP
	headers or capsules to register contexts. Depending on the method		header fields or capsules to register contexts. Depending on the
	being used, it is possible for datagrams to be received with Context		method being used, it is possible for datagrams to be received with
	IDs which have not yet been registered, for instance due to		Context IDs which have not yet been registered, for instance due to
	reordering of the datagram and the registration packets during		reordering of the packet containing the datagram and the packet
	transmission.		containing the registration message during transmission.
	5. HTTP Datagram Payload Format		5. HTTP Datagram Payload Format
	When associated with UDP proxying request streams, the HTTP Datagram		When HTTP Datagrams (see [HTTP-DGRAM]) are associated with UDP
	Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format		proxying request streams, the HTTP Datagram Payload field has the
	defined in Figure 6. Note that when HTTP Datagrams are encoded using		format defined in Figure 6. Note that when HTTP Datagrams are
	QUIC DATAGRAM frames, the Context ID field defined below directly		encoded using QUIC DATAGRAM frames, the Context ID field defined
	follows the Quarter Stream ID field which is at the start of the QUIC		below directly follows the Quarter Stream ID field which is at the
	DATAGRAM frame payload:		start of the QUIC DATAGRAM frame payload:
	UDP Proxying HTTP Datagram Payload {		UDP Proxying HTTP Datagram Payload {
	Context ID (i),		Context ID (i),
	Payload (..),		Payload (..),
	}		}
	Figure 6: UDP Proxying HTTP Datagram Format		Figure 6: UDP Proxying HTTP Datagram Format
	Context ID: A variable-length integer that contains the value of the		Context ID: A variable-length integer (see Section 16 of [QUIC])
	Context ID. If an HTTP/3 datagram which carries an unknown		that contains the value of the Context ID. If an HTTP/3 datagram
	Context ID is received, the receiver SHALL either drop that		which carries an unknown Context ID is received, the receiver
	datagram silently or buffer it temporarily (on the order of a		SHALL either drop that datagram silently or buffer it temporarily
	round trip) while awaiting the registration of the corresponding		(on the order of a round trip) while awaiting the registration of
	Context ID.		the corresponding Context ID.
	Payload: The payload of the datagram, whose semantics depend on		Payload: The payload of the datagram, whose semantics depend on
	value of the previous field. Note that this field can be empty.		value of the previous field. Note that this field can be empty.
	UDP packets are encoded using HTTP Datagrams with the Context ID set		UDP packets are encoded using HTTP Datagrams with the Context ID set
	to zero. When the Context ID is set to zero, the Payload field		to zero. When the Context ID is set to zero, the Payload field
	contains the unmodified payload of a UDP packet (referred to as "data		contains the unmodified payload of a UDP packet (referred to as "data
	octets" in [UDP]).		octets" in [UDP]).
	Clients MAY optimistically start sending proxied UDP packets before		Clients MAY optimistically start sending UDP packets in HTTP
	receiving the response to its UDP proxying request, noting however		Datagrams before receiving the response to its UDP proxying request.
	that those may not be processed by the proxy if it responds to the		However, implementors should note that such proxied packets may not
	request with a failure, or if the datagrams are received by the proxy		be processed by the proxy if it responds to the request with a
	before the request.		failure, or if the proxied packets are received by the proxy before
			the request.
	Endpoints MUST NOT send HTTP Datagrams with payloads longer than		By virtue of the definition of the UDP header [UDP], it is not
	65527 using Context ID zero. An endpoint that receives a DATAGRAM		possible to encode UDP payloads longer than 65527 bytes. Therefore,
	capsule using Context ID zero whose payload is longer than 65527 MUST		endpoints MUST NOT send HTTP Datagrams with a Payload field longer
	abort the stream. If a proxy knows it can only send out UDP packets		than 65527 using Context ID zero. An endpoint that receives a
	of a certain length due to its underlying link MTU, it SHOULD discard		DATAGRAM capsule using Context ID zero whose Payload field is longer
	incoming DATAGRAM capsules using Context ID zero whose payload is		than 65527 MUST abort the stream. If a proxy knows it can only send
	longer than that limit without buffering the capsule contents.		out UDP packets of a certain length due to its underlying link MTU,
			it SHOULD discard incoming DATAGRAM capsules using Context ID zero
			whose Payload field is longer than that limit without buffering the
			capsule contents.
	6. Performance Considerations		6. Performance Considerations
	Proxies SHOULD strive to avoid increasing burstiness of UDP traffic:		Proxies SHOULD strive to avoid increasing burstiness of UDP traffic:
	they SHOULD NOT queue packets in order to increase batching.		they SHOULD NOT queue packets in order to increase batching.
	When the protocol running over UDP that is being proxied uses		When the protocol running over UDP that is being proxied uses
	congestion control (e.g., [QUIC]), the proxied traffic will incur at		congestion control (e.g., [QUIC]), the proxied traffic will incur at
	least two nested congestion controllers. This can reduce performance		least two nested congestion controllers. This can reduce performance
	but the underlying HTTP connection MUST NOT disable congestion		but the underlying HTTP connection MUST NOT disable congestion
	skipping to change at page 11, line 28 ¶		skipping to change at page 12, line 15 ¶
	A UDP proxy MUST ignore ECN bits in the IP header of UDP packets		A UDP proxy MUST ignore ECN bits in the IP header of UDP packets
	received from the target, and MUST set the ECN bits to Not-ECT on UDP		received from the target, and MUST set the ECN bits to Not-ECT on UDP
	packets it sends to the target. These do not relate to the ECN		packets it sends to the target. These do not relate to the ECN
	markings of packets sent between client and proxy in any way.		markings of packets sent between client and proxy in any way.
	7. Security Considerations		7. Security Considerations
	There are significant risks in allowing arbitrary clients to		There are significant risks in allowing arbitrary clients to
	establish a tunnel to arbitrary targets, as that could allow bad		establish a tunnel to arbitrary targets, as that could allow bad
	actors to send traffic and have it attributed to the proxy. Proxies		actors to send traffic and have it attributed to the proxy. Proxies
	that support UDP proxying SHOULD restrict its use to authenticated		that support UDP proxying ought to restrict its use to authenticated
	users.		users.
	Because the CONNECT method creates a TCP connection to the target,		Because the CONNECT method creates a TCP connection to the target,
	the target has to indicate its willingness to accept TCP connections		the target has to indicate its willingness to accept TCP connections
	by responding with a TCP SYN-ACK before the proxy can send it		by responding with a TCP SYN-ACK before the proxy can send it
	application data. UDP doesn't have this property, so a UDP proxy		application data. UDP doesn't have this property, so a UDP proxy
	could send more data to an unwilling target than a CONNECT proxy.		could send more data to an unwilling target than a CONNECT proxy.
	However, in practice denial of service attacks target open TCP ports		However, in practice denial of service attacks target open TCP ports
	so the TCP SYN-ACK does not offer much protection in real scenarios.		so the TCP SYN-ACK does not offer much protection in real scenarios.
			While a proxy could potentially limit the number of UDP packets it is
			willing to forward until it has observed a response from the target,
			that is unlikely to provide any protection against denial of service
			attacks because such attacks target open UDP ports where the protocol
			running over UDP would respond, and that would be interpreted as
			willingness to accept UDP by the proxy.
			UDP sockets for UDP proxying have a different lifetime than TCP
			sockets for CONNECT, therefore implementors would be well served to
			follow the advice in Section 3.1 if they base their UDP proxying
			implementation on a preexisting implementation of CONNECT.
			The security considerations described in [HTTP-DGRAM] also apply
			here.
	8. IANA Considerations		8. IANA Considerations
	8.1. HTTP Upgrade Token		8.1. HTTP Upgrade Token
	This document will request IANA to register "connect-udp" in the HTTP		This document will request IANA to register "connect-udp" in the
	Upgrade Token Registry maintained at		"HTTP Upgrade Tokens" registry maintained at
	<https://www.iana.org/assignments/http-upgrade-tokens>.		<https://www.iana.org/assignments/http-upgrade-tokens>.
	Value: connect-udp		Value: connect-udp
	Description: Proxying of UDP Payloads		Description: Proxying of UDP Payloads
	Expected Version Tokens: None		Expected Version Tokens: None
	Reference: This document		Reference: This document
	8.2. Well-Known URI		8.2. Well-Known URI
	This document will request IANA to register "masque/udp" in the Well-		This document will request IANA to register "masque/udp" in the
	Known URIs Registry maintained at <https://www.iana.org/assignments/		"Well-Known URIs" registry maintained at
	well-known-uris/well-known-uris.xhtml>.		<https://www.iana.org/assignments/well-known-uris>.
	URI Suffix: masque/udp		URI Suffix: masque/udp
	Change Controller: IETF		Change Controller: IETF
	Reference: This document		Reference: This document
	Status: permanent (if this document is approved)		Status: permanent (if this document is approved)
	Related Information: Includes all resources identified with the path		Related Information: Includes all resources identified with the path
	prefix "/.well-known/masque/udp/"		prefix "/.well-known/masque/udp/"
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable		[DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
	Datagram Extension to QUIC", Work in Progress, Internet-		Datagram Extension to QUIC", RFC 9221,
	Draft, draft-ietf-quic-datagram-10, 4 February 2022,		DOI 10.17487/RFC9221, March 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://www.rfc-editor.org/rfc/rfc9221>.
	datagram-10>.
	[EXT-CONNECT2]		[EXT-CONNECT2]
	McManus, P., "Bootstrapping WebSockets with HTTP/2",		McManus, P., "Bootstrapping WebSockets with HTTP/2",
	RFC 8441, DOI 10.17487/RFC8441, September 2018,		RFC 8441, DOI 10.17487/RFC8441, September 2018,
	<https://www.rfc-editor.org/rfc/rfc8441>.		<https://www.rfc-editor.org/rfc/rfc8441>.
	[EXT-CONNECT3]		[EXT-CONNECT3]
	Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work		Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work
	in Progress, Internet-Draft, draft-ietf-httpbis-h3-		in Progress, Internet-Draft, draft-ietf-httpbis-h3-
	websockets-04, 8 February 2022,		websockets-04, 8 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	h3-websockets-04>.		h3-websockets-04>.
	[H1] Fielding, R. T., Nottingham, M., and J. Reschke,		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
			Semantics", Work in Progress, Internet-Draft, draft-ietf-
			httpbis-semantics-19, 12 September 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			semantics-19>.
			[HTTP-DGRAM]
			Schinazi, D. and L. Pardue, "HTTP Datagrams and the
			Capsule Protocol", Work in Progress, Internet-Draft,
			draft-ietf-masque-h3-datagram-09, 11 April 2022,
			<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
			h3-datagram-09>.
			[HTTP/1.1] Fielding, R. T., Nottingham, M., and J. Reschke,
	"HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf-		"HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-messaging-19, 12 September 2021,		httpbis-messaging-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	messaging-19>.		messaging-19>.
	[H2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress,		[HTTP/2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress,
	Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January		Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January
	2022, <https://datatracker.ietf.org/doc/html/draft-ietf-		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
	httpbis-http2bis-07>.		httpbis-http2bis-07>.
	[H3] Bishop, M., "Hypertext Transfer Protocol Version 3		[HTTP/3] Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-34, 2 February 2021,		quic-http-34, 2 February 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	http-34>.		http-34>.
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[PROXY-STATUS]
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
	httpbis-semantics-19, 12 September 2021,		Response Header Field", Work in Progress, Internet-Draft,
			draft-ietf-httpbis-proxy-status-08, 13 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		proxy-status-08>.
	[HTTP-DGRAM]
	Schinazi, D. and L. Pardue, "Using Datagrams with HTTP",
	Work in Progress, Internet-Draft, draft-ietf-masque-h3-
	datagram-07, 21 March 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
	h3-datagram-07>.
	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	<https://www.rfc-editor.org/rfc/rfc9000>.		<https://www.rfc-editor.org/rfc/rfc9000>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
			[STRUCT-FIELD]
			Nottingham, M. and P-H. Kamp, "Structured Field Values for
			HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
			<https://www.rfc-editor.org/rfc/rfc8941>.
	[TCP] Postel, J., "Transmission Control Protocol", STD 7,		[TCP] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/rfc/rfc793>.		<https://www.rfc-editor.org/rfc/rfc793>.
	[TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,		[TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
	and D. Orchard, "URI Template", RFC 6570,		and D. Orchard, "URI Template", RFC 6570,
	DOI 10.17487/RFC6570, March 2012,		DOI 10.17487/RFC6570, March 2012,
	<https://www.rfc-editor.org/rfc/rfc6570>.		<https://www.rfc-editor.org/rfc/rfc6570>.
	[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	skipping to change at page 14, line 32 ¶		skipping to change at page 15, line 37 ¶
	Briscoe, B., "Tunnelling of Explicit Congestion		Briscoe, B., "Tunnelling of Explicit Congestion
	Notification", RFC 6040, DOI 10.17487/RFC6040, November		Notification", RFC 6040, DOI 10.17487/RFC6040, November
	2010, <https://www.rfc-editor.org/rfc/rfc6040>.		2010, <https://www.rfc-editor.org/rfc/rfc6040>.
	[ICMP6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[ICMP6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,		Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<https://www.rfc-editor.org/rfc/rfc4443>.		<https://www.rfc-editor.org/rfc/rfc4443>.
	[PROXY-STATUS]
	Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
	Response Header Field", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-proxy-status-08, 13 October 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	proxy-status-08>.
	Acknowledgments		Acknowledgments
	This document is a product of the MASQUE Working Group, and the		This document is a product of the MASQUE Working Group, and the
	author thanks all MASQUE enthusiasts for their contibutions. This		author thanks all MASQUE enthusiasts for their contibutions. This
	proposal was inspired directly or indirectly by prior work from many		proposal was inspired directly or indirectly by prior work from many
	people. In particular, the author would like to thank Eric Rescorla		people. In particular, the author would like to thank Eric Rescorla
	for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas		for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas
	Pardue for their inputs on this document. The extensibility design		Pardue for their inputs on this document. The extensibility design
	in this document came out of the HTTP Datagrams Design Team, whose		in this document came out of the HTTP Datagrams Design Team, whose
	members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric		members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric
	skipping to change at page 15, line 6 ¶		skipping to change at page 16, line 4 ¶
	proposal was inspired directly or indirectly by prior work from many		proposal was inspired directly or indirectly by prior work from many
	people. In particular, the author would like to thank Eric Rescorla		people. In particular, the author would like to thank Eric Rescorla
	for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas		for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas
	Pardue for their inputs on this document. The extensibility design		Pardue for their inputs on this document. The extensibility design
	in this document came out of the HTTP Datagrams Design Team, whose		in this document came out of the HTTP Datagrams Design Team, whose
	members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric		members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric
	Rescorla, Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop,		Rescorla, Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop,
	Tommy Pauly, Victor Vasiliev, and the author of this document.		Tommy Pauly, Victor Vasiliev, and the author of this document.
	Author's Address		Author's Address
	David Schinazi		David Schinazi
	Google LLC		Google LLC
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, California 94043,		Mountain View, CA 94043
	United States of America		United States of America
	Email: dschinazi.ietf@gmail.com		Email: dschinazi.ietf@gmail.com
End of changes. 65 change blocks.
	169 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/