draft-ietf-httpbis-connect-tcp-06.txt		draft-ietf-httpbis-connect-tcp-latest.txt
	httpbis Working Group B. Schwartz		httpbis Working Group B. Schwartz
	Internet-Draft Meta Platforms, Inc.		Internet-Draft Meta Platforms, Inc.
	Intended status: Standards Track October 21, 2024		Intended status: Standards Track December 12, 2024
	Expires: April 24, 2025		Expires: June 15, 2025
	Template-Driven HTTP CONNECT Proxying for TCP		Template-Driven HTTP CONNECT Proxying for TCP
	draft-ietf-httpbis-connect-tcp-06		draft-ietf-httpbis-connect-tcp-latest
	Abstract		Abstract
	TCP proxying using HTTP CONNECT has long been part of the core HTTP		TCP proxying using HTTP CONNECT has long been part of the core HTTP
	specification. However, this proxying functionality has several		specification. However, this proxying functionality has several
	important deficiencies in modern HTTP environments. This		important deficiencies in modern HTTP environments. This
	specification defines an alternative HTTP proxy service configuration		specification defines an alternative HTTP proxy service configuration
	for TCP connections. This configuration is described by a URI		for TCP connections. This configuration is described by a URI
	Template, similar to the CONNECT-UDP and CONNECT-IP protocols.		Template, similar to the CONNECT-UDP and CONNECT-IP protocols.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 April 24, 2025.		This Internet-Draft will expire on June 15, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 14 ¶		skipping to change at page 2, line 14 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2		1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 5		3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 5
	3.3. Use of Relevant Headers . . . . . . . . . . . . . . . . . 6		3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 6
	3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6		3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 6
	3.3.2. Authentication Headers . . . . . . . . . . . . . . . 6		3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7
	3.4. Use of the Capsule Protocol . . . . . . . . . . . . . . . 7		3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 7
	4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7		4. Additional Connection Setup Behaviors . . . . . . . . . . . . 7
	4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 7		4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 8
	4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 8		4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 8
	5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Operational Considerations . . . . . . . . . . . . . . . . . 10		7. Operational Considerations . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. New Upgrade Tokens . . . . . . . . . . . . . . . . . . . 10		8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 10
	8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 10		8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 11
	8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 11		8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	1.1. History		1.1. History
	HTTP has used the CONNECT method for proxying TCP connections since		HTTP has used the CONNECT method for proxying TCP connections since
	HTTP/1.1. When using CONNECT, the request target specifies a host		HTTP/1.1. When using CONNECT, the request target specifies a host
	and port number, and the proxy forwards TCP payloads between the		and port number, and the proxy forwards TCP payloads between the
	client and this destination ([RFC9110], Section 9.3.6). To date,		client and this destination ([RFC9110], Section 9.3.6). To date,
	this is the only mechanism defined for proxying TCP over HTTP. In		this is the only mechanism defined for proxying TCP over HTTP. In
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	multiple distinct proxy services, as the server cannot distinguish		multiple distinct proxy services, as the server cannot distinguish
	them by path (as with distinct resources) or by origin (as in		them by path (as with distinct resources) or by origin (as in
	"virtual hosting").		"virtual hosting").
	The absence of an explicit origin for the proxy also rules out the		The absence of an explicit origin for the proxy also rules out the
	usual defenses against server port misdirection attacks (see		usual defenses against server port misdirection attacks (see
	Section 7.4 of [RFC9110]) and creates ambiguity about the use of		Section 7.4 of [RFC9110]) and creates ambiguity about the use of
	origin-scoped response header fields (e.g., "Alt-Svc" [RFC7838],		origin-scoped response header fields (e.g., "Alt-Svc" [RFC7838],
	"Strict-Transport-Security" [RFC6797]).		"Strict-Transport-Security" [RFC6797]).
			Classic HTTP CONNECT requests cannot carry in-stream metadata. For
			example, the WRAP_UP capsule [I-D.schinazi-httpbis-wrap-up] cannot be
			used with Classic HTTP CONNECT.
	1.3. Overview		1.3. Overview
	This specification describes an alternative mechanism for proxying		This specification describes an alternative mechanism for proxying
	TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service		TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service
	is identified by a URI Template. Proxy interactions reuse standard		is identified by a URI Template. Proxy interactions reuse standard
	HTTP components and semantics, avoiding changes to the core HTTP		HTTP components and semantics, avoiding changes to the core HTTP
	protocol.		protocol.
	2. Conventions and Definitions		2. Conventions and Definitions
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 13 ¶
	capitals, as shown here.		capitals, as shown here.
	3. Specification		3. Specification
	A template-driven TCP transport proxy for HTTP is identified by a URI		A template-driven TCP transport proxy for HTTP is identified by a URI
	Template [RFC6570] containing variables named "target_host" and		Template [RFC6570] containing variables named "target_host" and
	"target_port". This URI Template and its variable values MUST meet		"target_port". This URI Template and its variable values MUST meet
	all the same requirements as for UDP proxying ([RFC9298], Section 2),		all the same requirements as for UDP proxying ([RFC9298], Section 2),
	and are subject to the same validation rules. The client MUST		and are subject to the same validation rules. The client MUST
	substitute the destination host and port number into this template to		substitute the destination host and port number into this template to
	produce the request URI.		produce the request URI. The derived URI serves as the destination
			of a Capsule Protocol connection using the Upgrade Token "connect-
			tcp" (see registration in Section 8.1).
			When using "connect-tcp", TCP payload data is sent in the payload of
			a new Capsule Type named DATA (see registration in Section 8.3). The
			ordered concatenation of DATA capsule payloads represents the TCP
			payload data.
			An intermediary MAY merge and split successive DATA capsules, subject
			to the following requirements:
			o There are no intervening capsules of other types.
			o The order of payload content is preserved.
	3.1. In HTTP/1.1		3.1. In HTTP/1.1
	In HTTP/1.1, the client uses the proxy by issuing a request as		In HTTP/1.1, the client uses the proxy by issuing a request as
	follows:		follows:
	o The method SHALL be "GET".		o The method SHALL be "GET".
			o The request's target SHALL correspond to the URI derived from
			expansion of the proxy's URI Template.
	o The request SHALL include a single "Host" header field containing		o The request SHALL include a single "Host" header field containing
	the origin of the proxy.		the origin of the proxy.
	o The request SHALL include a "Connection" header field with the		o The request SHALL include a "Connection" header field with the
	value "Upgrade". (Note that this requirement is case-insensitive		value "Upgrade". (Note that this requirement is case-insensitive
	as per Section 7.6.1 of [RFC9110].)		as per Section 7.6.1 of [RFC9110].)
	o The request SHALL include an "Upgrade" header field with the value		o The request SHALL include an "Upgrade" header field with the value
	"connect-tcp".		"connect-tcp".
	o The request's target SHALL correspond to the URI derived from		o The request SHOULD include a "Capsule-Protocol: ?1" header.
	expansion of the proxy's URI Template.
	If the request is well-formed and permissible, the proxy MUST attempt		If the request is well-formed and permissible, the proxy MUST attempt
	to establish the TCP connection before sending any response status		to establish the TCP connection before sending any response status
	code other than "100 (Continue)" (see Section 4.2). If the TCP		code other than "100 (Continue)" (see Section 4.2). If the TCP
	connection is successful, the response SHALL be as follows:		connection is successful, the response SHALL be as follows:
	o The HTTP status code SHALL be "101 (Switching Protocols)".		o The HTTP status code SHALL be "101 (Switching Protocols)".
	o The response SHALL include a "Connection" header field with the		o The response SHALL include a "Connection" header field with the
	value "Upgrade".		value "Upgrade".
	o The response SHALL include a single "Upgrade" header field with		o The response SHALL include a single "Upgrade" header field with
	the value "connect-tcp".		the value "connect-tcp".
			o The response SHOULD include a "Capsule-Protocol: ?1" header.
	If the request is malformed or impermissible, the proxy MUST return a		If the request is malformed or impermissible, the proxy MUST return a
	4XX error code. If a TCP connection was not established, the proxy		4XX error code. If a TCP connection was not established, the proxy
	MUST NOT switch protocols to "connect-tcp", and the client MAY reuse		MUST NOT switch protocols to "connect-tcp", and the client MAY reuse
	this connection for additional HTTP requests.		this connection for additional HTTP requests.
	After a success response is returned, the connection SHALL conform to
	all the usual requirements for classic CONNECT proxies in HTTP/1.1
	([RFC9110], Section 9.3.6). Additionally, if the proxy observes a
	connection error from the client (e.g., a TCP RST, TCP timeout, or
	TLS error), it SHOULD send a TCP RST to the target. If the proxy
	observes a connection error from the target, it SHOULD send a TLS
	"internal_error" alert to the client, or set the TCP RST bit if TLS
	is not in use. These behaviors avoid truncation of transfers between
	the client and the target on vulnerable protocols (e.g., HTTP/1.1
	without TLS) while preserving the confidentiality and integrity
	guarantees of the "https" scheme.
	Client Proxy		Client Proxy
	GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1		GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1
	Host: example.com		Host: example.com
	Connection: Upgrade		Connection: Upgrade
	Upgrade: connect-tcp		Upgrade: connect-tcp
			Capsule-Protocol: ?1
	** Proxy establishes a TCP connection to 192.0.2.1:443 **		** Proxy establishes a TCP connection to 192.0.2.1:443 **
	HTTP/1.1 101 Switching Protocols		HTTP/1.1 101 Switching Protocols
	Connection: Upgrade		Connection: Upgrade
	Upgrade: connect-tcp		Upgrade: connect-tcp
			Capsule-Protocol: ?1
	Templated TCP proxy example in HTTP/1.1		Templated TCP proxy example in HTTP/1.1
	3.2. In HTTP/2 and HTTP/3		3.2. In HTTP/2 and HTTP/3
	In HTTP/2 and HTTP/3, the proxy MUST include		In HTTP/2 and HTTP/3, the proxy MUST include
	SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441]		SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441]
	[RFC9220]. The client uses the proxy by issuing an "extended		[RFC9220]. The client uses the proxy by issuing an "extended
	CONNECT" request as follows:		CONNECT" request as follows:
	skipping to change at page 5, line 42 ¶		skipping to change at page 6, line 9 ¶
	o The :protocol pseudo-header field SHALL be "connect-tcp".		o The :protocol pseudo-header field SHALL be "connect-tcp".
	o The :authority pseudo-header field SHALL contain the authority of		o The :authority pseudo-header field SHALL contain the authority of
	the proxy.		the proxy.
	o The :path and :scheme pseudo-header fields SHALL contain the path		o The :path and :scheme pseudo-header fields SHALL contain the path
	and scheme of the request URI derived from the proxy's URI		and scheme of the request URI derived from the proxy's URI
	Template.		Template.
	From this point on, the request and response SHALL conform to all the
	usual requirements for classic CONNECT proxies in this HTTP version
	(see Section 8.5 of [RFC9113] and Section 4.4 of [RFC9114]).
	A templated TCP proxying request that does not conform to all of		A templated TCP proxying request that does not conform to all of
	these requirements represents a client error (see [RFC9110],		these requirements represents a client error (see [RFC9110],
	Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113]		Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113]
	and Section 4.1.2 of [RFC9114]).		and Section 4.1.2 of [RFC9114]).
	HEADERS		HEADERS
	:method = CONNECT		:method = CONNECT
	:scheme = https		:scheme = https
	:authority = request-proxy.example		:authority = request-proxy.example
	:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443		:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443
	:protocol = connect-tcp		:protocol = connect-tcp
			capsule-protocol = ?1
	...		...
	Templated TCP proxy example in HTTP/2		Templated TCP proxy example in HTTP/2
	3.3. Use of Relevant Headers		3.3. Use of Other Relevant Headers
	3.3.1. Origin-scoped Headers		3.3.1. Origin-scoped Headers
	Ordinary HTTP headers apply only to the single resource identified in		Ordinary HTTP headers apply only to the single resource identified in
	the request or response. An origin-scoped HTTP header is a special		the request or response. An origin-scoped HTTP header is a special
	response header that is intended to change the client's behavior for		response header that is intended to change the client's behavior for
	subsequent requests to any resource on this origin.		subsequent requests to any resource on this origin.
	Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an		Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an
	unambiguous origin of its own. Origin-scoped headers apply to this		unambiguous origin of its own. Origin-scoped headers apply to this
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 21 ¶
	not use the "407 (Proxy Authentication Required)" response code and		not use the "407 (Proxy Authentication Required)" response code and
	related header fields ([RFC9110], Section 11.7) because they do not		related header fields ([RFC9110], Section 11.7) because they do not
	traverse HTTP gateways (see Section 7).		traverse HTTP gateways (see Section 7).
	Clients SHOULD assume that all proxy resources generated by a single		Clients SHOULD assume that all proxy resources generated by a single
	template share a protection space (i.e., a realm) ([RFC9110],		template share a protection space (i.e., a realm) ([RFC9110],
	Section 11.5). For many authentication schemes, this will allow the		Section 11.5). For many authentication schemes, this will allow the
	client to avoid waiting for a "401 (Unauthorized)" response before		client to avoid waiting for a "401 (Unauthorized)" response before
	each new connection through the proxy.		each new connection through the proxy.
	3.4. Use of the Capsule Protocol		3.4. Closing Connections
	When using the "connect-tcp" Upgrade Token, templated TCP proxies do		In each HTTP version, any requirements related to closing connections
	not use the Capsule Protocol [RFC9297]. Clients MAY request use of		in Classic HTTP CONNECT also apply to "connect-tcp", with the
	the Capsule Protocol by offering the Upgrade Token "connect-tcp-		following modifications:
	capsule" instead. When offering or accepting the "connect-tcp-
	capsule" Upgrade Token, clients and servers SHOULD including a
	"Capsule-Protocol: ?1" header to facilitate processing by
	intermediaries.
	Clients of this specification MAY implement "connect-tcp", "connect-		o In HTTP/1.1, endpoints SHOULD close the connection in an error
	tcp-capsule", or both. Accordingly, a templated TCP proxy server		state to indicate receipt of a TCP connection error (e.g., a TCP
	MUST implement both Upgrade Tokens unless its use is restricted to a		RST or timeout). Acceptable error states include sending an
	subset of compatible clients.		incomplete DATA capsule (as defined in Section 3.3 of [RFC9297]),
			a TLS Error Alert ([RFC8446], Section 6.2), or a TCP RST (if TLS
			is not in use). When a connection is terminated in an error
			state, the receiving endpoint SHOULD send a TCP RST if the
			underlying TCP implementation permits it.
	When using "connect-tcp-capsule", TCP payload data is sent in the		o In HTTP/2 and HTTP/3, senders MAY use an incomplete DATA capsule
	payload of a new Capsule Type named DATA (Section 8.3). The ordered		to indicate a TCP connection error, instead of (or in addition to)
	concatenation of DATA capsule payloads represents the main payload		the signals defined for TCP connection errors in Classic HTTP
	data stream in any protocol where this is well-defined.		CONNECT. Recipients MUST recognize any incomplete capsule as a
	Intermediaries MAY split or merge DATA capsules. Endpoints MAY		TCP connection error.
	indicate a TCP connection error by sending an incomplete DATA
	capsule, as an alternative to using TCP, TLS, or HTTP stream errors.		o Intermediaries MUST propagate connection shutdown errors,
			including when translating between different HTTP versions.
	4. Additional Connection Setup Behaviors		4. Additional Connection Setup Behaviors
	This section discusses some behaviors that are permitted or		This section discusses some behaviors that are permitted or
	recommended in order to enhance the performance or functionality of		recommended in order to enhance the performance or functionality of
	connection setup.		connection setup.
	4.1. Latency optimizations		4.1. Latency optimizations
	When using this specification in HTTP/2 or HTTP/3, clients MAY start		When using this specification in HTTP/2 or HTTP/3, clients MAY start
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 43 ¶
	o forward the "connect-tcp" protocol to the origin.		o forward the "connect-tcp" protocol to the origin.
	o convert "connect-tcp" requests between all supported HTTP server		o convert "connect-tcp" requests between all supported HTTP server
	and client versions.		and client versions.
	o allow any "Proxy-Status" headers to traverse the gateway.		o allow any "Proxy-Status" headers to traverse the gateway.
	8. IANA Considerations		8. IANA Considerations
	8.1. New Upgrade Tokens		8.1. New Upgrade Token
	IF APPROVED, IANA is requested to add the following entries to the		IF APPROVED, IANA is requested to add the following entry to the HTTP
	HTTP Upgrade Token Registry:		Upgrade Token Registry:
	+-----------------------+-----------------------------+-------------+		+---------------+--------------------------+-----------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-----------------------+-----------------------------+-------------+		+---------------+--------------------------+-----------------+
	| "connect-tcp" | Proxying of TCP payloads | (This |		| "connect-tcp" | Proxying of TCP payloads | (This document) |
	| | | document) |		+---------------+--------------------------+-----------------+
	| | | |
	| "connect-tcp-capsule" | Proxying of TCP payloads in | (This |
	| | HTTP Capsules | document) |
	+-----------------------+-----------------------------+-------------+
	For interoperability testing of this draft version, implementations		For interoperability testing of this draft version, implementations
	SHALL use the values "connect-tcp-06" and "connect-tcp-capsule-06.		SHALL use the value "connect-tcp-07".
	8.2. New MASQUE Default Template		8.2. New MASQUE Default Template
	IF APPROVED, IANA is requested to add the following entry to the		IF APPROVED, IANA is requested to add the following entry to the
	"MASQUE URI Suffixes" registry:		"MASQUE URI Suffixes" registry:
	+--------------+--------------+-----------------+		+--------------+--------------+-----------------+
	| Path Segment | Description | Reference |		| Path Segment | Description | Reference |
	+--------------+--------------+-----------------+		+--------------+--------------+-----------------+
	| tcp | TCP Proxying | (This document) |		| tcp | TCP Proxying | (This document) |
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 30 ¶
	IF APPROVED, IANA is requested to add the following entry to the		IF APPROVED, IANA is requested to add the following entry to the
	"HTTP Capsule Types" registry:		"HTTP Capsule Types" registry:
	+-------+---------+-----------+--------------+------------+---------+		+-------+---------+-----------+--------------+------------+---------+
	| Value | Capsule | Status | Reference | Change | Contact |		| Value | Capsule | Status | Reference | Change | Contact |
	| | Type | | | Controller | |		| | Type | | | Controller | |
	+-------+---------+-----------+--------------+------------+---------+		+-------+---------+-----------+--------------+------------+---------+
	| (TBD) | DATA | permanent | (This | IETF | HTTPBIS |		| (TBD) | DATA | permanent | (This | IETF | HTTPBIS |
	| | | | document), | | |		| | | | document), | | |
	| | | | Section 3.4 | | |		| | | | Section 3 | | |
	+-------+---------+-----------+--------------+------------+---------+		+-------+---------+-----------+--------------+------------+---------+
	For this draft version of the protocol, the Capsule Type value		For this draft version of the protocol, the Capsule Type value
	"0xb739a6d0" shall be used provisionally for testing, under the name		"0x2028d7ee" shall be used provisionally for testing, under the name
	"DATA-05".		"DATA-07".
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[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/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 26 ¶
	Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,		Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
	Kuehlewind, M., and M. Westerlund, "Proxying IP in HTTP",		Kuehlewind, M., and M. Westerlund, "Proxying IP in HTTP",
	RFC 9484, DOI 10.17487/RFC9484, October 2023,		RFC 9484, DOI 10.17487/RFC9484, October 2023,
	<https://www.rfc-editor.org/info/rfc9484>.		<https://www.rfc-editor.org/info/rfc9484>.
	[CONNECT-UDP]		[CONNECT-UDP]
	Schinazi, D., "Proxying UDP in HTTP", RFC 9298,		Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
	DOI 10.17487/RFC9298, August 2022,		DOI 10.17487/RFC9298, August 2022,
	<https://www.rfc-editor.org/info/rfc9298>.		<https://www.rfc-editor.org/info/rfc9298>.
			[I-D.schinazi-httpbis-wrap-up]
			Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",
			draft-schinazi-httpbis-wrap-up-01 (work in progress),
			October 2024.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,		Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,		DOI 10.17487/RFC6797, November 2012,
	<https://www.rfc-editor.org/info/rfc6797>.		<https://www.rfc-editor.org/info/rfc6797>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
End of changes. 33 change blocks.
	71 lines changed or deleted		82 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/