< 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/