draft-ietf-masque-connect-udp-07.txt		draft-ietf-masque-connect-udp-08.txt
	MASQUE D. Schinazi		MASQUE D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track 5 March 2022		Intended status: Standards Track 21 March 2022
	Expires: 6 September 2022		Expires: 22 September 2022
	UDP Proxying Support for HTTP		UDP Proxying Support for HTTP
	draft-ietf-masque-connect-udp-07		draft-ietf-masque-connect-udp-08
	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. It is built using HTTP
	Extended CONNECT.		Extended CONNECT.
	Discussion Venues		Discussion Venues
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 6 September 2022.		This Internet-Draft will expire on 22 September 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 23 ¶		skipping to change at page 2, line 23 ¶
	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 . . . . . . . . . . . . . . . . . . . . . 4
	3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 5		3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 5
	3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 6		3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 6
	3.4. HTTP Request over HTTP/2 and HTTP/3 . . . . . . . . . . . 6		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 . . . . . . . . . . 7
	3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 7		3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 8
	4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 8		4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . . 10
	6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 10		6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 11		8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Appendix A. Example Extensions . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	A.1. Registering Contexts with Headers . . . . . . . . . . . . 14		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
	A.2. Registering Contexts with Capsules . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
	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 or HTTP/3, UDP proxying uses HTTP
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 26 ¶
	[HTTP]) between the client and the proxy, those are referred to as		[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 an URI
	Template [TEMPLATE]. The URI template MUST contain exactly two		Template [TEMPLATE] with the variables "target_host" and
	variables: "target_host" and "target_port". Examples are shown		"target_port". Examples are shown below:
	below:
	https://masque.example.org/{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
			template MUST be in absolute form, and MUST include non-empty scheme,
			authority and path components. The path component of the URI
			template MUST start with a slash "/". All template variables MUST be
			within the path component of the URI. The URI template MUST contain
			the two variables "target_host" and "target_port" and MAY contain
			other variables. The URI template MUST NOT contain any non-ASCII
			unicode characters and MUST only contain ASCII characters in the
			range 0x21-0x7E inclusive (note that percent-encoding is allowed).
			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 MUST use the default template which is defined as:
	"https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where		"https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/
	$PROXY_HOST and $PROXY_PORT are the configured host and port of the		udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT
	proxy respectively. Proxy deployments SHOULD use the default		are the configured host and port of the proxy respectively. Proxy
	template to facilitate interoperability with such clients.		deployments SHOULD use the default template to facilitate
			interoperability with such clients.
	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 [HTTP-DGRAM].
	A "connect-udp" request requests that the recipient proxy establish a		A "connect-udp" request requests that the recipient proxy establish a
	tunnel over a single HTTP stream to the destination target identified		tunnel over a single HTTP stream to the destination target identified
	by the "target_host" and "target_port" variables of the URI template		by the "target_host" and "target_port" variables of the URI template
	(see Section 2). If the request is successful, the proxy commits to		(see Section 2). If the request is successful, the proxy commits to
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 48 ¶
	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, a UDP proxying request will meet the following
	requirements:		requirements:
	* the method SHALL be "CONNECT".		* 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]).		[H1]).
	* the request SHALL include a single Host header containing the		* the request SHALL include a single Host header containing the
	origin of the proxy.		origin of the proxy.
	* the request SHALL include a single "Connection" header with value		* the request SHALL include a single "Connection" header with value
	"Upgrade".		"Upgrade".
	* the request SHALL include a single "Upgrade" header with value		* the request SHALL include a single "Upgrade" header with value
	"connect-udp".		"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/{target_host}/{target_port}/" and wishes		"https://proxy.example.org/.well-known/masque/
	to open a UDP proxying tunnel to target 192.0.2.42:443, it could send		udp/{target_host}/{target_port}/" and wishes to open a UDP proxying
	the following request:		tunnel to target 192.0.2.42:443, it could send the following request:
	CONNECT https://proxy.example.org/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 with value
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 34 ¶
	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 = /192.0.2.42/443/		:path = /.well-known/masque/udp/192.0.2.42/443/
	:authority = proxy.example.org		:authority = proxy.example.org
	Figure 4: Example HTTP Request over HTTP/2		Figure 4: Example HTTP Request over HTTP/2
	3.5. HTTP Response over HTTP/2 and HTTP/3		3.5. HTTP Response over HTTP/2 and HTTP/3
	The proxy SHALL indicate a successful response by replying with any		The proxy SHALL indicate a successful response by replying with any
	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.
	skipping to change at page 8, line 38 ¶		skipping to change at page 9, line 7 ¶
	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 assigned different semantics in distinct requests,
	potentially with different semantics. Context IDs MUST NOT be re-		potentially with different semantics. Context IDs MUST NOT be re-
	allocated within a given HTTP namespace but MAY be allocated in any		allocated within a given HTTP namespace but MAY be allocated in any
	order. Once allocated, any context ID can be used by both client and		order. Once allocated, any context ID can be used by both client and
	proxy - only allocation carries separate namespaces to avoid		proxy - only allocation carries separate namespaces to avoid
	requiring synchronization.		requiring synchronization.
	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, though some examples of how it		not define how registration occurs. Future extensions MAY use HTTP
	might occur are provided in Appendix A. Depending on the method		headers or capsules to register contexts. Depending on the method
	being used, it is possible for datagrams to be received with Context		being used, it is possible for datagrams to be received with Context
	IDs which have not yet been registered, for instance due to		IDs which have not yet been registered, for instance due to
	reordering of the datagram and the registration packets during		reordering of the datagram and the registration packets during
	transmission.		transmission.
	5. HTTP Datagram Payload Format		5. HTTP Datagram Payload Format
	When associated with UDP proxying request streams, the HTTP Datagram		When associated with UDP proxying request streams, the HTTP Datagram
	Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format		Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format
	defined in Figure 6. Note that when HTTP Datagrams are encoded using		defined in Figure 6. Note that when HTTP Datagrams are encoded using
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 49 ¶
	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 HTTP
	Upgrade Token Registry maintained at		Upgrade Token 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
			This document will request IANA to register "masque/udp" in the Well-
			Known URIs Registry maintained at <https://www.iana.org/assignments/
			well-known-uris/well-known-uris.xhtml>.
			URI Suffix: masque/udp
			Change Controller: IETF
			Reference: This document
			Status: permanent (if this document is approved)
			Related Information: Includes all resources identified with the path
			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", Work in Progress, Internet-
	Draft, draft-ietf-quic-datagram-10, 4 February 2022,		Draft, draft-ietf-quic-datagram-10, 4 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	datagram-10>.		datagram-10>.
	skipping to change at page 12, line 49 ¶		skipping to change at page 13, line 25 ¶
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-19, 12 September 2021,		httpbis-semantics-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		semantics-19>.
	[HTTP-DGRAM]		[HTTP-DGRAM]
	Schinazi, D. and L. Pardue, "Using Datagrams with HTTP",		Schinazi, D. and L. Pardue, "Using Datagrams with HTTP",
	Work in Progress, Internet-Draft, draft-ietf-masque-h3-		Work in Progress, Internet-Draft, draft-ietf-masque-h3-
	datagram-06, 4 March 2022,		datagram-07, 21 March 2022,
	<https://datatracker.ietf.org/doc/html/draft-ietf-masque-		<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
	h3-datagram-06>.		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>.
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 39 ¶
	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]		[PROXY-STATUS]
	Nottingham, M. and P. Sikora, "The Proxy-Status HTTP		Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
	Response Header Field", Work in Progress, Internet-Draft,		Response Header Field", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-proxy-status-08, 13 October 2021,		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-
	proxy-status-08>.		proxy-status-08>.
	Appendix A. Example Extensions
	Extensions can define new semantics for the payload of HTTP
	Datagrams. The extension can then have an endpoint pick an available
	locally-allocated context ID (see Section 4) and register that
	context ID with their peer.
	Note that this appendix only exists to help illustrate MASQUE Working
	Group discussions while designing extensions. This appendix will be
	removed before MASQUE Working Group Last Call.
	A.1. Registering Contexts with Headers
	Extensions can define a new HTTP header to register a context ID with
	the peer endpoint.
	As an example, take an extension that conveys the time at which a UDP
	packet was received. The extension would first define the format of
	its HTTP Datagram Payload field:
	UDP with Timestamp HTTP Datagrams {
	Context ID (i),
	Timestamp (64),
	UDP Payload (..),
	}
	Figure 7: Example: Format of UDP Payload with Timestamp
	The extension would also define a new HTTP header (Example-UDP-
	Timestamps) that includes a context ID value. Proxies that
	understand this new HTTP header would be able to consequently handle
	and parse datagrams with the context ID, while all other proxies
	would silently drop the datagrams.
	This specific extension would restrict registrations to the client,
	and have them be bidirectional in the sense that the client
	registering a context ID also indicates support for receiving on it.
	Other extensions could allow proxy registrations, and/or
	unidirectional registrations in the sense that registration would
	only imply usage in one direction.
	HEADERS
	:method = CONNECT
	:protocol = connect-udp
	:scheme = https
	:path = /192.0.2.42/443/
	:authority = proxy.example.org
	example-udp-timestamps = 42
	Figure 8: Example: Registration via header
	In this example request, HTTP Datagrams with context ID zero would
	only contain the UDP payload, whereas HTTP Datagrams with context ID
	42 would also contain a timestamp.
	A.2. Registering Contexts with Capsules
	Extensions can define a new Capsule type (see [HTTP-DGRAM]) to
	register a context ID with the peer endpoint.
	As an example, take an extension that compresses QUIC Connection IDs
	when the client is running QUIC over a UDP proxying tunnel. The
	extension would first define the transform applied to UDP payloads
	when compressing and decompressing, such as removing the bytes of the
	connection ID.
	The extension would also define a new capsule type
	(EXAMPLE_REGISTER_COMPRESSED_QUIC_CID) that includes a context ID
	value and the connection ID to compress. Endpoints that understand
	this new capsule type would be able to consequently handle and parse
	datagrams on the context ID, while all other endpoints would ignore
	the datagrams.
	EXAMPLE_REGISTER_COMPRESSED_QUIC_CID Capsule {
	Type (i) = EXAMPLE_REGISTER_COMPRESSED_QUIC_CID,
	Length (i),
	Context ID (i),
	QUIC Connection ID (..),
	}
	Figure 9: Example: Registration via capsule
	This example extension would most likely also define a new HTTP
	header to indicate support.
	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
End of changes. 23 change blocks.
	128 lines changed or deleted		73 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/