draft-ietf-httpbis-alias-proxy-status-05.txt		draft-ietf-httpbis-alias-proxy-status-latest.txt
	HTTP Working Group T. Pauly		HTTP Working Group T. Pauly
	Internet-Draft Apple, Inc.		Internet-Draft Apple, Inc.
	Intended status: Standards Track June 20, 2023		Intended status: Standards Track November 6, 2023
	Expires: December 22, 2023		Expires: May 9, 2024
	HTTP Proxy-Status Parameter for Next-Hop Aliases		HTTP Proxy-Status Parameter for Next-Hop Aliases
	draft-ietf-httpbis-alias-proxy-status-05		draft-ietf-httpbis-alias-proxy-status-latest
	Abstract		Abstract
	This document defines the "next-hop-aliases" HTTP Proxy-Status		This document defines the "next-hop-aliases" HTTP Proxy-Status
	Parameter. This parameter carries the list of aliases and canonical		Parameter. This parameter carries the list of aliases and canonical
	names an intermediary received during DNS resolution as part		names an intermediary received during DNS resolution as part of
	establishing a connection to the next hop.		establishing a connection to the next hop.
	About This Document		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.
	Status information for this document may be found at		Status information for this document may be found at
	<https://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy-		<https://datatracker.ietf.org/doc/draft-ietf-httpbis-alias-proxy-
	status/>.		status/>.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 December 22, 2023.		This Internet-Draft will expire on May 9, 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 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 28 ¶		skipping to change at page 2, line 28 ¶
	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. Requirements . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
	2. next-hop-aliases Parameter . . . . . . . . . . . . . . . . . 3		2. next-hop-aliases Parameter . . . . . . . . . . . . . . . . . 3
	2.1. Encoding special characters . . . . . . . . . . . . . . . 4		2.1. Encoding special characters . . . . . . . . . . . . . . . 4
	3. Implementation Considerations . . . . . . . . . . . . . . . . 5		3. Implementation Considerations . . . . . . . . . . . . . . . . 5
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.1. Normative References . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . 7		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The Proxy-Status HTTP response field [PROXY-STATUS] allows		The Proxy-Status HTTP response field [PROXY-STATUS] allows
	intermediaries to convey information about how they handled the		intermediaries to convey information about how they handled the
	request in HTTP responses sent to clients. It defines a set of		request in HTTP responses sent to clients. It defines a set of
	parameters that provide information, such as the name of the next		parameters that provide information, such as the name of the next
	hop.		hop.
	[PROXY-STATUS] defines a "next-hop" parameter, which can contain a		[PROXY-STATUS] defines a "next-hop" parameter, which can contain a
	skipping to change at page 3, line 29 ¶		skipping to change at page 3, line 29 ¶
	"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.
	2. next-hop-aliases Parameter		2. next-hop-aliases Parameter
	The "next-hop-aliases" parameter's value is a String		The "next-hop-aliases" parameter's value is a String
	[STRUCTURED-FIELDS] that contains one or more DNS names in a comma-		[STRUCTURED-FIELDS] that contains one or more DNS names in a comma-
	separated list. The items in the list include all alias names and		separated list. The items in the list include all alias names and
	canonical names received in CNAME records [DNS] during the course of		canonical names received in CNAME records [DNS] during the course of
	resolving the next hop's hostname using DNS, not including the		resolving the next hop's hostname using DNS, and MAY include the
	original requested hostname itself. The names SHOULD appear in the		original requested hostname itself. The names SHOULD appear in the
	order in which they were received in DNS. If there are multiple		order in which they were received in DNS. If there are multiple
	CNAME records in the chain, the first name in the "next-hop-aliases"		CNAME records in the chain, the first name in the "next-hop-aliases"
	list would be the value in the CNAME record for the original		list would be the value in the CNAME record for the original
	hostname, and the final name in the "next-hop-aliases" list would be		hostname, and the final name in the "next-hop-aliases" list would be
	the name that ultimately resolved to one or more addresses.		the name that ultimately resolved to one or more addresses.
	The list of DNS names in "next-hop-aliases" uses a comma (",") as a		The list of DNS names in "next-hop-aliases" uses a comma (",") as a
	separator between names. Note that if a comma is included in a name		separator between names. Note that if a comma is included in a name
	itself, the comma must be encoded as described in Section 2.1.		itself, the comma must be encoded as described in Section 2.1.
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	Proxy-Status: proxy.example.net; next-hop="2001:db8::1";		Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
	next-hop-aliases="tracker.example.com,service1.example.com"		next-hop-aliases="tracker.example.com,service1.example.com"
	This indicates that proxy.example.net, which used the IP address		This indicates that proxy.example.net, which used the IP address
	"2001:db8::1" as the next hop for this request, encountered the names		"2001:db8::1" as the next hop for this request, encountered the names
	"tracker.example.com" and "service1.example.com" in the DNS		"tracker.example.com" and "service1.example.com" in the DNS
	resolution chain. Note that while this example includes both the		resolution chain. Note that while this example includes both the
	"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can		"next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can
	be included without including "next-hop".		be included without including "next-hop".
			The proxy can also include the name of the next hop as the first item
			in the list. This is particularly useful for reverse proxies when
			clients would not otherwise know the name of the next hop, and the
			"next-hop" header is used to convey an IP address.
			For example, consider a proxy "reverseproxy.example.net" that
			receives the following records when performing DNS resolution for the
			next hop "host.example.com":
			host2.example.com. CNAME service2.example.com.
			service2.example.com. AAAA 2001:db8::2
			The proxy could include the following proxy status in its response:
			Proxy-Status: reverseproxy.example.net; next-hop="2001:db8::2";
			next-hop-aliases="host2.example.com,service2.example.com"
	The "next-hop-aliases" parameter only applies when DNS was used to		The "next-hop-aliases" parameter only applies when DNS was used to
	resolve the next hop's name, and does not apply in all situations.		resolve the next hop's name, and does not apply in all situations.
	Clients can use the information in this parameter to determine how to		Clients can use the information in this parameter to determine how to
	use the connection established through the proxy, but need to		use the connection established through the proxy, but need to
	gracefully handle situations in which this parameter is not present.		gracefully handle situations in which this parameter is not present.
	The proxy MAY send the empty string ("") as the value of "next-hop-		The proxy MAY send the empty string ("") as the value of "next-hop-
	aliases" to indicate that no CNAME records were encountered when		aliases" to indicate that no CNAME records were encountered when
	resolving the next hop's name.		resolving the next hop's name.
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 25 ¶
	character itself will be percent-encoded, the name		character itself will be percent-encoded, the name
	"dot\.label.example.com" would be encoded within a "next-hop-aliases"		"dot\.label.example.com" would be encoded within a "next-hop-aliases"
	parameter as follows:		parameter as follows:
	Proxy-Status: proxy.example.net; next-hop="2001:db8::1";		Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
	next-hop-aliases="dot%5C.label.example.com,service1.example.com"		next-hop-aliases="dot%5C.label.example.com,service1.example.com"
	Upon parsing this name, "dot%5C.label" MUST be treated as a single		Upon parsing this name, "dot%5C.label" MUST be treated as a single
	label.		label.
	Similarly the "\" character in a label MUST be escaped as "\\".		Similarly the "\" character in a label MUST be escaped as "\\" and
	Other uses of "\" MUST NOT appear in the label after percent-		then percent-encoded. Other uses of "\" MUST NOT appear in the label
	decoding.		after percent-decoding. For example, if there is a DNS name
			"backslash\name.example.com", it would first be escaped as
			"backslash\\name.example.com", and then percent-encoded as follows:
			Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
			next-hop-aliases="backslash%5C%5Cname.example.com,service1.example.com"
	3. Implementation Considerations		3. Implementation Considerations
	In order to include the "next-hop-aliases" parameter, a proxy needs		In order to include the "next-hop-aliases" parameter, a proxy needs
	to have access to the chain of alias names and canonical names		to have access to the chain of alias names and canonical names
	received in CNAME records.		received in CNAME records.
	Implementations ought to note that the full chain of names might not		Implementations ought to note that the full chain of names might not
	available in common DNS resolution APIs, such as "getaddrinfo".		be available in common DNS resolution APIs, such as "getaddrinfo".
	"getaddrinfo" does have an option for "AI_CANONNAME", but this will		"getaddrinfo" does have an option for "AI_CANONNAME" (Section 6.1 of
	only return the last name in the chain (the canonical name), not the		[RFC3493]), but this will only return the last name in the chain (the
	alias names.		canonical name), not the alias names.
	An implementation MAY include incomplete information in the "next-		An implementation MAY include incomplete information in the "next-
	hop-aliases" parameter to accommodate cases where it is unable to		hop-aliases" parameter to accommodate cases where it is unable to
	include the full chain, such as only including the canonical name if		include the full chain, such as only including the canonical name if
	the implementation can only use "getaddrinfo" as described above.		the implementation can only use "getaddrinfo" as described above.
	4. Security Considerations		4. Security Considerations
	The "next-hop-aliases" parameter does not include any DNSSEC		The "next-hop-aliases" parameter does not include any DNSSEC
	information or imply that DNSSEC was used. The information included		information or imply that DNSSEC was used. The information included
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 44 ¶
	6.2. Informative References		6.2. Informative References
	[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[COOKIES] 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>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/rfc1035>.		November 1987, <https://www.rfc-editor.org/info/rfc1035>.
			[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
			Stevens, "Basic Socket Interface Extensions for IPv6",
			RFC 3493, DOI 10.17487/RFC3493, February 2003,
			<https://www.rfc-editor.org/info/rfc3493>.
	Author's Address		Author's Address
	Tommy Pauly		Tommy Pauly
	Apple, Inc.		Apple, Inc.
	Email: tpauly@apple.com		Email: tpauly@apple.com
End of changes. 11 change blocks.
	15 lines changed or deleted		42 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/