draft-ietf-dnssd-mdns-relay-01.txt		draft-ietf-dnssd-mdns-relay-02.txt
	Network Working Group T. Lemon		Network Working Group T. Lemon
	Internet-Draft Nibbhaya Consulting		Internet-Draft Nibbhaya Consulting
	Intended status: Standards Track S. Cheshire		Intended status: Standards Track S. Cheshire
	Expires: January 3, 2019 Apple Inc.		Expires: September 12, 2019 Apple Inc.
	July 2, 2018		March 11, 2019
	Multicast DNS Discovery Relay		Multicast DNS Discovery Relay
	draft-ietf-dnssd-mdns-relay-01		draft-ietf-dnssd-mdns-relay-02
	Abstract		Abstract
	This document complements the specification of the Discovery Proxy		This document complements the specification of the Discovery Proxy
	for Multicast DNS-Based Service Discovery. It describes a		for Multicast DNS-Based Service Discovery. It describes a
	lightweight relay mechanism, a Discovery Relay, which, when present		lightweight relay mechanism, a Discovery Relay, which, when present
	on a link, allows remote clients, not attached to that link, to		on a link, allows remote clients, not attached to that link, to
	perform mDNS discovery operations on that link.		perform mDNS discovery operations on that link.
	Status of This Memo		Status of This Memo
	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 January 3, 2019.		This Internet-Draft will expire on September 12, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	8.2. mDNS Link Data Discontinue . . . . . . . . . . . . . . . 14		8.2. mDNS Link Data Discontinue . . . . . . . . . . . . . . . 14
	8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 15		8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 15
	8.4. Encapsulated mDNS Message . . . . . . . . . . . . . . . . 15		8.4. Encapsulated mDNS Message . . . . . . . . . . . . . . . . 15
	8.5. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 15		8.5. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.6. Link State Request . . . . . . . . . . . . . . . . . . . 15		8.6. Link State Request . . . . . . . . . . . . . . . . . . . 15
	8.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16		8.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16
	8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16		8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16
	8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16		8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16
	8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 16		8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 16
	9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18		9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 18		9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19
	9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 19		9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 19
	9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 20		9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 20
	9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 21		9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 21
	9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 22		9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 22
	9.3. Discovery Proxy Private Configuration . . . . . . . . . . 24		9.3. Discovery Proxy Private Configuration . . . . . . . . . . 24
	9.4. Discovery Relay Private Configuration . . . . . . . . . . 24		9.4. Discovery Relay Private Configuration . . . . . . . . . . 24
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 25		10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	13.1. Normative References . . . . . . . . . . . . . . . . . . 27		13.1. Normative References . . . . . . . . . . . . . . . . . . 27
	13.2. Informative References . . . . . . . . . . . . . . . . . 28		13.2. Informative References . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	The Discovery Proxy for Multicast DNS-Based Service Discovery		The Discovery Proxy for Multicast DNS-Based Service Discovery
	[I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a		[I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a
	subnetted network through the use of Discovery Proxies, which issue		subnetted network through the use of Discovery Proxies, which issue
	Multicast DNS (mDNS) requests [RFC6762] on various multicast links in		Multicast DNS (mDNS) requests [RFC6762] on various multicast links in
	the network on behalf of a remote host performing DNS-Based Service		the network on behalf of a remote host performing DNS-Based Service
	Discovery [RFC6763].		Discovery [RFC6763].
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	received, the relay must first validate that it is a connection to an		received, the relay must first validate that it is a connection to an
	IP address to which connections are allowed. For example, it may be		IP address to which connections are allowed. For example, it may be
	that only connections to ULAs are allowed, or to the IP addresses		that only connections to ULAs are allowed, or to the IP addresses
	configured on certain interfaces. If the listener is bound to a		configured on certain interfaces. If the listener is bound to a
	specific IP address, this check is unnecessary.		specific IP address, this check is unnecessary.
	If the relay is using an IP address whitelist, the next step is for		If the relay is using an IP address whitelist, the next step is for
	the relay to verify that that the source IP address of the connection		the relay to verify that that the source IP address of the connection
	is on its whitelist. If the connection is not permitted either		is on its whitelist. If the connection is not permitted either
	because of the source address or the destination address, the		because of the source address or the destination address, the
	Discovery Relay responds to the TLS Client Hello message from the		Discovery Relay closes the connection. If possible, before closing
	Client with a TLS user_canceled alert ([I-D.ietf-tls-tls13]		the connection, the Discovery Relay first sends a TLS user_canceled
	Section 6.1).		alert ([I-D.ietf-tls-tls13] Section 6.1). Discovery Relays SHOULD
			refuse to accept TCP connections to invalid destination addresses,
			rather than accepting and then closing the connection, if this is
			possible.
	Otherwise, the Discovery Relay will attempt to complete a TLS		Otherwise, the Discovery Relay will attempt to complete a TLS
	handshake with the Client. Clients are required to send the		handshake with the Client. Clients are required to send the
	post_handshake_auth extension ([I-D.ietf-tls-tls13] Section 4.2.5).		post_handshake_auth extension ([I-D.ietf-tls-tls13] Section 4.2.5).
	If a Discovery Relay receives a ClientHello message with no		If a Discovery Relay receives a ClientHello message with no
	post_handshake_auth extension, the Discovery Relay rejects the		post_handshake_auth extension, the Discovery Relay rejects the
	connection with a certificate_required alert ([I-D.ietf-tls-tls13]		connection with a certificate_required alert ([I-D.ietf-tls-tls13]
	Section 6.2).		Section 6.2).
	Once the TLS handshake is complete, the Discovery Relay MUST request		Once the TLS handshake is complete, the Discovery Relay MUST request
	post-handshake authentication as described in ([I-D.ietf-tls-tls13]		post-handshake authentication as described in ([I-D.ietf-tls-tls13]
	Section 4.6.2). If the Client refuses to send a certificate, or the		Section 4.6.2). If the Client refuses to send a certificate, or the
	key presented does not match the key associated with the IP address		key presented does not match the key associated with the IP address
	from which the connection originated, or the CertificateVerify does		from which the connection originated, or the CertificateVerify does
	not validate, the connection is dropped with the TLS access_denied		not validate, the connection is dropped with the TLS access_denied
	alert ([I-D.ietf-tls-tls13] Section 6.2).		alert ([I-D.ietf-tls-tls13] Section 6.2).
			Clients MUST validate server certificates. If the client is
			configured with a server IP address and certificate, it can validate
			the server by comparing the certificate offered by the server to the
			certificate that was provided: they should be the same. If the
			certificate includes a Distinguished Name that is a fully-qualified
			domain name, the client SHOULD present that domain name to the server
			in an SNI request.
			Rather than being configured with an IP address and a certificate,
			the client may be configured with the server's FQDN. In this case,
			the client uses the server's FQDN as a Authentication Domain Name
			[RFC8310] Section 7.1, and uses the authentication method described
			in [RFC8310] section 8.1, if the certificate is signed by a root
			authority the client trusts, or the method described in section 8.2
			of the same document if not. If neither method is available, then a
			locally-configured copy of the server certificate can be used, as in
			the previous paragraph.
	Once the connection is established and authenticated, it is treated		Once the connection is established and authenticated, it is treated
	as a DNS TCP connection [RFC1035].		as a DNS TCP connection [RFC7766].
	Aliveness of connections between Clients and Relays is maintained as		Aliveness of connections between Clients and Relays is maintained as
	described in Section 4 of [I-D.ietf-dnsop-session-signal]. Clients		described in Section 4 of [I-D.ietf-dnsop-session-signal]. Clients
	must also honor the 'Retry Delay' TLV (section 5 of		must also honor the 'Retry Delay' TLV (section 5 of
	[I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay.		[I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay.
	Clients SHOULD avoid establishing more than one connection to a		Clients SHOULD avoid establishing more than one connection to a
	specific Discovery Relay. However, there may be situations where		specific Discovery Relay. However, there may be situations where
	multiple connections to the same Discovery Relay are unavoidable, so		multiple connections to the same Discovery Relay are unavoidable, so
	Discovery Relays MUST be willing to accept multiple connections from		Discovery Relays MUST be willing to accept multiple connections from
	skipping to change at page 18, line 45 ¶		skipping to change at page 18, line 45 ¶
	Discovery Relays within such a network will be referred to in this		Discovery Relays within such a network will be referred to in this
	section as a 'Discovery Domain'.		section as a 'Discovery Domain'.
	Depending on the context, several different candidates for		Depending on the context, several different candidates for
	configuration of Discovery Proxies and Discovery Relays may be		configuration of Discovery Proxies and Discovery Relays may be
	applicable. The simplest such mechanism is a manual configuration		applicable. The simplest such mechanism is a manual configuration
	file, but regardless of provisioning mechanism, certain configuration		file, but regardless of provisioning mechanism, certain configuration
	information needs to be communicated to the devices, as outlined		information needs to be communicated to the devices, as outlined
	below.		below.
			In the example we provide here, we only refer to configuring of IP
			addresses, private keys and certificates. It is also possible to use
			FQDNs to identify servers; this then allows for the use of DANE
			([RFC8310] Section 8.2) or PKIX authentication [RFC6125]. Which
			method is used is to some extent up to the implementation, but at a
			minimum, it should be possible to associate an IP address with a
			self-signed certificate, and it should be possible to validate both
			self-signed and PKIX-authenticated certificates, with PKIX, DANE or a
			pre-configured trust anchor.
	9.1. Provisioned Objects		9.1. Provisioned Objects
	Three types of objects must be described in order for Discovery		Three types of objects must be described in order for Discovery
	Proxies and Discovery Relays to be provisioned: Discovery Proxies,		Proxies and Discovery Relays to be provisioned: Discovery Proxies,
	Multicast Links, and Discovery Relays. "Human-readable" below means		Multicast Links, and Discovery Relays. "Human-readable" below means
	actual words or proper names that will make sense to an untrained		actual words or proper names that will make sense to an untrained
	human being. "Machine-readable" means a name that will be used by		human being. "Machine-readable" means a name that will be used by
	machines to identify the entity to which the name refers. Each		machines to identify the entity to which the name refers. Each
	entity must have a machine-readable name and may have a human-		entity must have a machine-readable name and may have a human-
	readable name. No two entities can have the same human-readable		readable name. No two entities can have the same human-readable
	skipping to change at page 20, line 22 ¶		skipping to change at page 20, line 33 ¶
	The description of a Discovery Proxy consists of:		The description of a Discovery Proxy consists of:
	name a machine-readable name used to reference this Discovery Proxy		name a machine-readable name used to reference this Discovery Proxy
	in provisioning.		in provisioning.
	hr-name an optional human-readable name which can appear in		hr-name an optional human-readable name which can appear in
	provisioning, monitoring and debugging systems. Must be unique		provisioning, monitoring and debugging systems. Must be unique
	within a Discovery Domain.		within a Discovery Domain.
	public-key a public key that identifies the Discovery Proxy. This		certificate a certificate that identifies the Discovery Proxy. This
	key can be shared across services on the Discovery Proxy Host.		certificate can be shared across services on the Discovery Proxy
	The public key is used both to uniquely identify the Discovery		Host. The public key in the certificate is used both to uniquely
	Proxy and to authenticate connections from it.		identify the Discovery Proxy and to authenticate connections from
			it. The certificate should be signed by its own private key.
	private-key the private key corresponding to the public key.		private-key the private key corresponding to the public key in the
			certificate.
	source-ip-addresses a list of IP addresses that may be used by the		source-ip-addresses a list of IP addresses that may be used by the
	Discovery Proxy when connecting to Discovery Relays. These		Discovery Proxy when connecting to Discovery Relays. These
	addresses should be addresses that are configured on the Discovery		addresses should be addresses that are configured on the Discovery
	Proxy Host. They should not be temporary addresses. All such		Proxy Host. They should not be temporary addresses. All such
	addresses must be reachable within the Discovery Domain.		addresses must be reachable within the Discovery Domain.
	public-ip-addresses a list of IP addresses that a Discovery Proxy		public-ip-addresses a list of IP addresses that a Discovery Proxy
	listens on to receive requests from clients. This is not used for		listens on to receive requests from clients. This is not used for
	interoperation with Discovery Relays, but is mentioned here for		interoperation with Discovery Relays, but is mentioned here for
	skipping to change at page 21, line 21 ¶		skipping to change at page 21, line 33 ¶
	The description of a Discovery Relay consists of:		The description of a Discovery Relay consists of:
	name a required machine-readable identifier used to reference the		name a required machine-readable identifier used to reference the
	relay		relay
	hr-name an optional human-readable name which can appear in		hr-name an optional human-readable name which can appear in
	provisioning, monitoring and debugging systems. Must be unique		provisioning, monitoring and debugging systems. Must be unique
	within a Discovery Domain.		within a Discovery Domain.
	public-key a public key that identifies the Discovery Relay. This		certificate a certificate that identifies the Discovery Relay. This
	key can be shared across services on the Discovery Relay Host.		certificate can be shared across services on the Discovery Relay
	Indeed, if a Discovery Proxy and Discovery Relay are running on		Host. Indeed, if a Discovery Proxy and Discovery Relay are
	the same host, the same key may be used for both. The public key		running on the same host, the same certificate can be used for
	uniquely identifies the Discovery Relay and is used by the		both. The public key in the certificate uniquely identifies the
	Discovery Proxy to verify that it is talking to the intended		Discovery Relay and is used by the Discovery Proxy to verify that
	Discovery Relay after a TLS connection has been established.		it is talking to the intended Discovery Relay after a TLS
			connection has been established. The certificate must either be
			signed by its own key, or have a signature chain that can be
			validated using PKIX authentication [RFC6125].
	private-key the private key corresponding to the public key.		private-key the private key corresponding to the public key in the
			certificate.
	listen-tuple a list of IP address/port tuples that may be used to		listen-tuple a list of IP address/port tuples that may be used to
	connect to the Discovery Relay. The relay may be configured to		connect to the Discovery Relay. The relay may be configured to
	listen on all addresses on a single port, but this is not		listen on all addresses on a single port, but this is not
	required, so the port as well as the address must be specified.		required, so the port as well as the address must be specified.
	multicast links a list of multicast links to which this relay is		multicast links a list of multicast links to which this relay is
	physically connected.		physically connected.
	The private key should never be distributed to other hosts; all of		The private key should never be distributed to other hosts; all of
	skipping to change at page 23, line 11 ¶		skipping to change at page 23, line 11 ¶
	by name. This approach is not required, but is simply shown as an		by name. This approach is not required, but is simply shown as an
	example. In addition, the private keys for each proxy or relay must		example. In addition, the private keys for each proxy or relay must
	appear only in that proxy or relay's configuration file.		appear only in that proxy or relay's configuration file.
	The master file contains a list of Discovery Relays, Discovery		The master file contains a list of Discovery Relays, Discovery
	Proxies and Multicast Links. Each object has a name and all the		Proxies and Multicast Links. Each object has a name and all the
	other data associated with it. We do not formally specify the format		other data associated with it. We do not formally specify the format
	of the file, but it might look something like this:		of the file, but it might look something like this:
	Relay upstairs		Relay upstairs
	public-key xxx		certificate xxx
	listen-tuple 192.0.2.1 1917		listen-tuple 192.0.2.1 1917
	listen-tuple fd00::1 1917		listen-tuple fd00::1 1917
	link upstairs-wifi		link upstairs-wifi
	link upstairs-wired		link upstairs-wired
	client-whitelist main		client-whitelist main
	Relay downstairs		Relay downstairs
	public-key yyy		certificate yyy
	listen-tuple 192.51.100.1 2088		listen-tuple 192.51.100.1 2088
	listen-tuple fd00::2 2088		listen-tuple fd00::2 2088
	link downstairs-wifi		link downstairs-wifi
	link downstairs-wired		link downstairs-wired
	client-whitelist main		client-whitelist main
	Proxy main		Proxy main
	public-key zzz		certificate zzz
	address 203.1.113.1		address 203.1.113.1
	Link upstairs-wifi		Link upstairs-wifi
	id 1		id 1
	name Upstairs Wifi		name Upstairs Wifi
	Link upstairs-wired		Link upstairs-wired
	id 2		id 2
	hr-name Upstairs Wired		hr-name Upstairs Wired
	skipping to change at page 24, line 32 ¶		skipping to change at page 24, line 32 ¶
	subscribe downstairs-wired		subscribe downstairs-wired
	When combined with the master file, this configuration is sufficient		When combined with the master file, this configuration is sufficient
	for the Discovery Proxy to identify and connect to the Discovery		for the Discovery Proxy to identify and connect to the Discovery
	Relays that serve the links it is configured to support.		Relays that serve the links it is configured to support.
	9.4. Discovery Relay Private Configuration		9.4. Discovery Relay Private Configuration
	The Discovery Relay configuration just needs to tell the Discovery		The Discovery Relay configuration just needs to tell the Discovery
	Relay what name to use to find its configuration in the master file,		Relay what name to use to find its configuration in the master file,
	and what the private key is corresponding to its public key in the		and what the private key is corresponding to its certificate (public
	master file. For example:		key) in the master file. For example:
	Relay Downstairs		Relay Downstairs
	private-key yyy		private-key yyy
	10. Security Considerations		10. Security Considerations
	Part of the purpose of the Multicast DNS Discovery Relay protocol is		Part of the purpose of the Multicast DNS Discovery Relay protocol is
	to place a simple relay, analogous to a BOOTP relay, into routers and		to place a simple relay, analogous to a BOOTP relay, into routers and
	similar devices that may not be updated frequently. The BOOTP		similar devices that may not be updated frequently. The BOOTP
	[RFC0951] protocol has been around since 1985, and continues to be		[RFC0951] protocol has been around since 1985, and continues to be
	skipping to change at page 27, line 12 ¶		skipping to change at page 27, line 12 ¶
	To be completed...		To be completed...
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-dnsop-session-signal]		[I-D.ietf-dnsop-session-signal]
	Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,		Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
	Lemon, T., and T. Pusateri, "DNS Stateful Operations",		Lemon, T., and T. Pusateri, "DNS Stateful Operations",
	draft-ietf-dnsop-session-signal-10 (work in progress),		draft-ietf-dnsop-session-signal-20 (work in progress),
	June 2018.		December 2018.
	[I-D.ietf-dnssd-hybrid]		[I-D.ietf-dnssd-hybrid]
	Cheshire, S., "Discovery Proxy for Multicast DNS-Based		Cheshire, S., "Discovery Proxy for Multicast DNS-Based
	Service Discovery", draft-ietf-dnssd-hybrid-08 (work in		Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
	progress), March 2018.		progress), March 2018.
	[I-D.ietf-tls-tls13]		[I-D.ietf-tls-tls13]
	Rescorla, E., "The Transport Layer Security (TLS) Protocol		Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", draft-ietf-tls-tls13-28 (work in progress),		Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
	March 2018.		March 2018.
	skipping to change at page 27, line 38 ¶		skipping to change at page 27, line 38 ¶
	2017.		2017.
	[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>.
	[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions		[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
	for High Performance", RFC 1323, DOI 10.17487/RFC1323, May		for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
	1992, <https://www.rfc-editor.org/info/rfc1323>.		1992, <https://www.rfc-editor.org/info/rfc1323>.
			[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
			Verification of Domain-Based Application Service Identity
			within Internet Public Key Infrastructure Using X.509
			(PKIX) Certificates in the Context of Transport Layer
			Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
			2011, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
	DOI 10.17487/RFC6762, February 2013,		DOI 10.17487/RFC6762, February 2013,
	<https://www.rfc-editor.org/info/rfc6762>.		<https://www.rfc-editor.org/info/rfc6762>.
	[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service		[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
	Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,		Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
	<https://www.rfc-editor.org/info/rfc6763>.		<https://www.rfc-editor.org/info/rfc6763>.
			[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
			D. Wessels, "DNS Transport over TCP - Implementation
			Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
			<https://www.rfc-editor.org/info/rfc7766>.
	[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking		[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
	Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April		Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
	2016, <https://www.rfc-editor.org/info/rfc7788>.		2016, <https://www.rfc-editor.org/info/rfc7788>.
			[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
			for DNS over TLS and DNS over DTLS", RFC 8310,
			DOI 10.17487/RFC8310, March 2018,
			<https://www.rfc-editor.org/info/rfc8310>.
	13.2. Informative References		13.2. Informative References
	[AdFam] "IANA Address Family Numbers Registry",		[AdFam] "IANA Address Family Numbers Registry",
	<https://www.iana.org/assignments/		<https://www.iana.org/assignments/
	address-family-numbers/>.		address-family-numbers/>.
	[I-D.ietf-mboned-ieee802-mcast-problems]		[I-D.ietf-mboned-ieee802-mcast-problems]
	Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.		Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
	Zuniga, "Multicast Considerations over IEEE 802 Wireless		Zuniga, "Multicast Considerations over IEEE 802 Wireless
	Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work		Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
	in progress), February 2018.		in progress), November 2018.
	[NOTSENT] "TCP_NOTSENT_LOWAT socket option", July 2013,		[NOTSENT] Dumazet, E., "TCP_NOTSENT_LOWAT socket option", July 2013,
	<https://lwn.net/Articles/560082/>.		<https://lwn.net/Articles/560082/>.
	[PRIO] "Prioritization Only Works When There's Pending Data to		[PRIO] Chan, W., "Prioritization Only Works When There's Pending
	Prioritize", January 2014, <https://insouciant.org/tech/		Data to Prioritize", January 2014,
	prioritization-only-works-when-theres-pending-data-to-		<https://insouciant.org/tech/prioritization-only-works-
	prioritize/>.		when-theres-pending-data-to-prioritize/>.
	[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,		[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
	DOI 10.17487/RFC0951, September 1985,		DOI 10.17487/RFC0951, September 1985,
	<https://www.rfc-editor.org/info/rfc951>.		<https://www.rfc-editor.org/info/rfc951>.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, DOI 10.17487/RFC2246, January 1999,		RFC 2246, DOI 10.17487/RFC2246, January 1999,
	<https://www.rfc-editor.org/info/rfc2246>.		<https://www.rfc-editor.org/info/rfc2246>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	skipping to change at page 29, line 14 ¶		skipping to change at page 29, line 26 ¶
	Ted Lemon		Ted Lemon
	Nibbhaya Consulting		Nibbhaya Consulting
	P.O. Box 958		P.O. Box 958
	Brattleboro, Vermont 05301		Brattleboro, Vermont 05301
	United States of America		United States of America
	Email: mellon@fugue.com		Email: mellon@fugue.com
	Stuart Cheshire		Stuart Cheshire
	Apple Inc.		Apple Inc.
	1 Infinite Loop		One Apple Park Way
	Cupertino, California 95014		Cupertino, California 95014
	USA		USA
	Phone: +1 408 974 3207		Phone: +1 (408) 996-1010
	Email: cheshire@apple.com		Email: cheshire@apple.com
End of changes. 27 change blocks.
	40 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/