draft-ietf-dnssd-mdns-relay-02.txt   draft-ietf-dnssd-mdns-relay-03.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nibbhaya Consulting Internet-Draft S. Cheshire
Intended status: Standards Track S. Cheshire Intended status: Standards Track Apple Inc.
Expires: September 12, 2019 Apple Inc. Expires: January 14, 2021 July 13, 2020
March 11, 2019
Multicast DNS Discovery Relay Multicast DNS Discovery Relay
draft-ietf-dnssd-mdns-relay-02 draft-ietf-dnssd-mdns-relay-03
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 34
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 September 12, 2019. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 24 skipping to change at page 2, line 22
4. Connections between Clients and Relays (details) . . . . . . 8 4. Connections between Clients and Relays (details) . . . . . . 8
5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 10 5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 10
6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 12 6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 12
7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 13 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 13
8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. mDNS Link Data Request . . . . . . . . . . . . . . . . . 14 8.1. mDNS Link Data Request . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . . 17
9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19
9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 19 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 20
9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 20 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 21
9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 21 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 22
9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 22 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 23
9.3. Discovery Proxy Private Configuration . . . . . . . . . . 24 9.3. Discovery Proxy Private Configuration . . . . . . . . . . 25
9.4. Discovery Relay Private Configuration . . . . . . . . . . 24 9.4. Discovery Relay Private Configuration . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 [RFC8766] is a mechanism for discovering services on a subnetted
subnetted network through the use of Discovery Proxies, which issue network through the use of Discovery Proxies, which issue Multicast
Multicast DNS (mDNS) requests [RFC6762] on various multicast links in DNS (mDNS) requests [RFC6762] on various multicast links in the
the network on behalf of a remote host performing DNS-Based Service network on behalf of a remote host performing DNS-Based Service
Discovery [RFC6763]. Discovery [RFC6763].
In the original Discovery Proxy specification, it is imagined that In the original Discovery Proxy specification, it is imagined that
for every multicast link on which services will be discovered, a host for every multicast link on which services will be discovered, a host
will be present running a full Discovery Proxy. This document will be present running a full Discovery Proxy. This document
introduces a lightweight Discovery Relay that can be used to provide introduces a lightweight Discovery Relay that can be used in
discovery services on a multicast link without requiring a full conjunction with a Discovery Proxy to provide discovery services on a
Discovery Proxy on every multicast link. multicast link without requiring a full Discovery Proxy on every
multicast link.
Since the primary purpose of a Discovery Relay is providing remote The primary purpose of a Discovery Relay is providing remote virtual
virtual interface functionality to Discovery Proxies, this document interface functionality to Discovery Proxies, and this document is
is written with that usage in mind. However, in principle, a written with that usage in mind. However, in principle, a Discovery
Discovery Relay could be used by any properly authorized client. In Relay could be used by any properly authorized client. In the
the context of this specification, a Discovery Proxy is a client to context of this specification, a Discovery Proxy is a client to the
the Discovery Relay. This document uses the terms "Discovery Proxy" Discovery Relay. This document uses the terms "Discovery Proxy" and
and "Client" somewhat interchangably; the term "Client" is used when "Client" somewhat interchangably; the term "Client" is used when we
we are talking about the communication between the Client and the are talking about the communication between the Client and the Relay,
Relay, and the term "Discovery Proxy" when we are referring and the term "Discovery Proxy" when we are referring specifically to
specifically to a Discovery Relay Client that also happens to be a Discovery Relay Client that also happens to be a Discovery Proxy.
acting as a Discovery Proxy. One example of another kind of device that can be a client of a
Discovery Relay is an Advertising Proxy [AdProx].
The Discovery Relay operates by listening for TCP connections from The Discovery Relay operates by listening for TCP connections from
Clients. When a Client connects, the connection is authenticated and Clients. When a Client connects, the connection is authenticated and
secured using TLS. The Client can then specify one or more multicast secured using TLS. The Client can then specify one or more multicast
links from which it wishes to receive mDNS traffic. The Client can links from which it wishes to receive mDNS traffic. The Client can
also send messages to be transmitted on its behalf on one or more of also send messages to be transmitted on its behalf on one or more of
those multicast links. DNS Stateful Operations (DSO) those multicast links. DNS Stateful Operations (DSO) [RFC8490] is
[I-D.ietf-dnsop-session-signal] is used as a framework for conveying used as a framework for conveying interface and IP header information
interface and IP header information associated with each message. associated with each message. DSO formats its messages using type-
DSO formats its messages using type-length-value (TLV) data length-value (TLV) data structures. This document defines additional
structures. This document defines additional DSO TLV types, used to DSO TLV types, used to implement the Discovery Relay functionality.
implement the Discovery Relay functionality.
The Discovery Relay functions essentially as a set of one or more The Discovery Relay functions essentially as a set of one or more
remote virtual interfaces for the Client, one on each multicast link remote virtual interfaces for the Client, one on each multicast link
to which the Discovery Relay is connected. In a complex network, it to which the Discovery Relay is connected. In a complex network, it
is possible that more than one Discovery Relay will be connected to is possible that more than one Discovery Relay will be connected to
the same multicast link; in this case, the Client ideally should only the same multicast link; in this case, the Client ideally should only
be using one such Relay Proxy per multicast link, since using more be using one such Relay Proxy per multicast link, since using more
than one will generate duplicate traffic. than one will generate duplicate traffic.
How such duplication is detected and avoided is out of scope for this How such duplication is detected and avoided is out of scope for this
document; in principle it could be detected using HNCP [RFC7788] or document; in principle it could be detected using HNCP [RFC7788] or
configured using some sort of orchestration software in conjunction configured using some sort of orchestration software in conjunction
with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069].
Use of a Discovery Relay can be considered similar to using Virtual
LAN (VLAN) trunk ports to give a Discovery Proxy device a virtual
presence on multiple links or broadcast domains. The difference is
that while a VLAN trunk port operates at the link layer and delivers
all link-layer traffic to the Discovery Proxy device, a Discovery
Relay operates further up the network stack and selectively delivers
only relevant Multicast DNS traffic. Also, VLAN trunk ports are
generally only available within a single administrative domain and
require link-layer configuration and connectivity, whereas the
Discovery Relay protocol, which runs over TCP, can be used between
any two devices with IP connectivity to each other.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
The following definitions may be of use: The following definitions may be of use:
Client A network service that uses a Discovery Relay to send and Client A network service that uses a Discovery Relay to send and
receive mDNS multicast traffic on a remote link, to enable it to receive mDNS multicast traffic on a remote link, to enable it to
communicate with mDNS Agents on that remote link. communicate with mDNS Agents on that remote link.
mDNS Agent A host which sends and/or responds to mDNS queries mDNS Agent A host which sends and/or responds to mDNS queries
directly on its local link(s). Examples include network cameras, directly on its local link(s). Examples include network cameras,
networked printers, networked home electronics, etc. networked printers, networked home electronics, etc.
Discovery Proxy A network service which receives well-formed Discovery Proxy A network service which receives well-formed
questions using the DNS protocol, performs multicast DNS queries questions using the DNS protocol, performs multicast DNS queries
to answer those questions, and responds with those answers using to find answers to those questions, and responds with those
the DNS protocol. A Discovery Proxy that can communicate with answers using the DNS protocol. A Discovery Proxy that can
remote mDNS Agents, using the services of a Discovery Relay, is a communicate with remote mDNS Agents, using the services of a
Client of the Discovery Relay. Discovery Relay, is a Client of the Discovery Relay.
Discovery Relay A network service which relays mDNS messages Discovery Relay A network service which relays mDNS messages
received on a local link to a Client, and on behalf of that Client received on a local link to a Client, and on behalf of that Client
can transmit mDNS messages on a local link. can transmit mDNS messages on a local link.
multicast link A maximal set of network connection points, such that multicast link A maximal set of network connection points, such that
any host connected to any connection point in the set may send a any host connected to any connection point in the set may send a
packet with a link-local multicast destination address packet with a link-local multicast destination address
(specifically the mDNS link-local multicast destination address (specifically the mDNS link-local multicast destination address
[RFC6762]) that will be received by all hosts connected to all [RFC6762]) that will be received by all hosts connected to all
skipping to change at page 6, line 5 skipping to change at page 5, line 42
Relay may accept connections. Relay may accept connections.
silently discard When a message that is not supported or not silently discard When a message that is not supported or not
permitted is received, and the required response to that message permitted is received, and the required response to that message
is to "silently discard" it, that means that no response is sent is to "silently discard" it, that means that no response is sent
by the service that is discarding the message to the service that by the service that is discarding the message to the service that
sent it. The service receiving the message may log the event, and sent it. The service receiving the message may log the event, and
may also count such events: "silently" does not preclude such may also count such events: "silently" does not preclude such
behavior. behavior.
Take care when reading this document not to confuse the terms
"Discovery Proxy" and "Discovery Relay". A Discovery Proxy [RFC8766]
provides Multicast DNS discovery service to remote clients. A
Discovery Relay is a simple software entity that provides virtual
link connectivity to one or more Discovery Proxies or other Discovery
Relay clients.
3. Protocol Overview 3. Protocol Overview
This document describes a way for Clients to communicate with mDNS This document describes a way for a Client to communicate with mDNS
agents on remote multicast links to which they are not directly agents on remote multicast links to which the client is not directly
connected, using a Discovery Relay. As such, there are two parts to connected, using a Discovery Relay. As such, there are two parts to
the protocol: connections between Clients and Discovery Relays, and the protocol: connections between Clients and Discovery Relays, and
communications between Discovery Relays and mDNS agents. communications between Discovery Relays and mDNS agents.
3.1. Connections between Clients and Relays (overview) 3.1. Connections between Clients and Relays (overview)
Discovery Relays listen for incoming connection requests. Discovery Relays listen for incoming connection requests.
Connections between Clients and Discovery Relays are established by Connections between Clients and Discovery Relays are established by
Clients. Connections are authenticated and encrypted using TLS, with Clients. Connections are authenticated and encrypted using TLS, with
both client and server certificates. Connections are long-lived: a both client and server certificates. Connections are long-lived: a
Client is expected to send many queries over a single connection, and Client is expected to send many queries over a single connection, and
Discovery Relays will forward all mDNS traffic from subscribed Discovery Relays will forward all mDNS traffic from subscribed
interfaces over the connection. interfaces over the connection.
The stream encapsulated in TLS will carry DNS frames as in the DNS The stream encapsulated in TLS will carry DNS frames as in the DNS
TCP protocol [RFC1035] Section 4.2.2. However, all messages will be TCP protocol [RFC1035] Section 4.2.2. However, all messages will be
DSO messages [I-D.ietf-dnsop-session-signal]. There will be four DSO messages [RFC8490]. There will be four types of such messages
types of such messages between Discovery Relays and Clients: between Discovery Relays and Clients:
o Control messages from Client to Relay o Control messages from Client to Relay
o Link status messages from Relay to Client o Link status messages from Relay to Client
o Encapsulated mDNS query messages from Client to Relay o Encapsulated mDNS messages from Client to Relay
o Encapsulated mDNS response messages from Relay to Client o Encapsulated mDNS messages from Relay to Client
Clients can send four different control messages to Relays: Link Clients can send four different control messages to Relays: Link
State Request, Link State Discontinue, Link Data Request and Link State Request, Link State Discontinue, Link Data Request and Link
Data Discontinue. The first two are used by the Client to request Data Discontinue. The first two are used by the Client to request
that the Relay report on the set of links that can be requested, and that the Relay report on the set of links that can be requested, and
to request that it discontinue such reporting. The second two are to request that it discontinue such reporting. The second two are
used by the Client to indicate to the Discovery Relay that mDNS used by the Client to indicate to the Discovery Relay that mDNS
messages from one or more specified multicast links are to be relayed messages from one or more specified multicast links are to be relayed
to the Client, and to subsequently stop such relaying. to the Client, and to subsequently stop such relaying.
Link Status messages from a Discovery Relay to the Client inform the Link Status messages from a Discovery Relay to the Client inform the
Client that a link has become available, or that a formerly-available Client that a link has become available, or that a formerly-available
link is no longer available. link is no longer available.
Encapsulated mDNS response messages from a Discovery Relay to a Encapsulated mDNS messages from a Discovery Relay to a Client are
Client are sent whenever an mDNS response message is received on a sent whenever an mDNS message is received on a multicast link to
multicast link to which the Discovery Relay has subscribed. which the Discovery Relay has subscribed.
Encapsulated query mDNS messages from a Client to a Discovery Relay Encapsulated mDNS messages from a Client to a Discovery Relay cause
cause the Discovery Relay to transmit the mDNS query message on the the Discovery Relay to transmit the mDNS message on the specified
specified multicast link to which the Discovery Relay host is multicast link to which the Discovery Relay host is directly
directly attached. attached.
During periods with no traffic flowing, Clients are responsible for During periods with no traffic flowing, Clients are responsible for
generating any necessary keepalive traffic, as stated in the DSO generating any necessary keepalive traffic, as stated in the DSO
specification [I-D.ietf-dnsop-session-signal]. specification [RFC8490].
3.2. mDNS Messages On Multicast Links 3.2. mDNS Messages On Multicast Links
Discovery Relays listen for mDNS traffic on all configured multicast Discovery Relays listen for mDNS traffic on all configured multicast
links that have at least one active subscription from a Client. When links that have at least one active subscription from a Client. When
an mDNS response message is received on a multicast link, it is an mDNS message is received on a multicast link, it is forwarded on
forwarded on every open Client connection that is subscribed to mDNS every open Client connection that is subscribed to mDNS traffic on
traffic on that multicast link. In the event of congestion, where a that multicast link. In the event of congestion, where a particular
particular Client connection has no buffer space for an mDNS message Client connection has no buffer space for an mDNS message that would
that would otherwise be forwarded to it, the mDNS message is not otherwise be forwarded to it, the mDNS message is not forwarded to
forwarded to it. Normal mDNS retry behavior is used to recover from it. Normal mDNS retry behavior is used to recover from this sort of
this sort of packet loss. Discovery Relays are not expected to packet loss. Discovery Relays are not expected to buffer more than a
buffer more than a few mDNS packets. Excess mDNS packets are few mDNS packets. Excess mDNS packets are silently discarded. In
silently discarded. In practice this is not expected to be a issue. practice this is not expected to be a issue. Particularly on
Particularly on networks like Wi-Fi, multicast packets are networks like Wi-Fi, multicast packets are transmitted at rates ten
transmitted at rates ten or even a hundred times slower than unicast or even a hundred times slower than unicast packets. This means that
packets. This means that even at peak multicast packets rates, it is even at peak multicast packets rates, it is likely that a unicast TCP
likely that a unicast TCP connection will able to carry those packets connection will able to carry those packets with ease.
with ease.
Clients send encapsulated mDNS query messages they wish to have sent Clients send encapsulated mDNS messages they wish to have sent on
on their behalf on remote multicast link(s) on which the Client has their behalf on remote multicast link(s) on which the Client has an
an active subscription. A Discovery Relay will not transmit mDNS active subscription. A Discovery Relay will not transmit mDNS
query packets on any multicast link on which the Client does not have packets on any multicast link on which the Client does not have an
an active subscription, since it makes no sense for a Client to ask active subscription, since it makes no sense for a Client to ask to
to have a query sent on its behalf if it's not able to receive the have a query sent on its behalf if it's not able to receive the
responses to that query. responses to that query.
4. Connections between Clients and Relays (details) 4. Connections between Clients and Relays (details)
When a Discovery Relay starts, it opens a passive TCP listener to When a Discovery Relay starts, it opens a passive TCP listener to
receive incoming connection requests from Clients. This listener may receive incoming connection requests from Clients. This listener may
be bound to one or more source IP addresses, or to the wildcard be bound to one or more source IP addresses, or to the wildcard
address, depending on the implementation. When a connection is address, depending on the implementation. When a connection is
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 closes the connection. If possible, before closing Discovery Relay closes the connection. If possible, before closing
the connection, the Discovery Relay first sends a TLS user_canceled the connection, the Discovery Relay first sends a TLS user_canceled
alert ([I-D.ietf-tls-tls13] Section 6.1). Discovery Relays SHOULD alert ([RFC8446] Section 6.1). Discovery Relays SHOULD refuse to
refuse to accept TCP connections to invalid destination addresses, accept TCP connections to invalid destination addresses, rather than
rather than accepting and then closing the connection, if this is accepting and then closing the connection, if this is possible.
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 ([RFC8446] Section 4.2.5). If a
If a Discovery Relay receives a ClientHello message with no 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 ([RFC8446] 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 ([RFC8446] Section 4.6.2). If the
Section 4.6.2). If the Client refuses to send a certificate, or the Client refuses to send a certificate, or the key presented does not
key presented does not match the key associated with the IP address match the key associated with the IP address from which the
from which the connection originated, or the CertificateVerify does connection originated, or the CertificateVerify does not validate,
not validate, the connection is dropped with the TLS access_denied the connection is dropped with the TLS access_denied alert ([RFC8446]
alert ([I-D.ietf-tls-tls13] Section 6.2). Section 6.2).
Clients MUST validate server certificates. If the client is Clients MUST validate server certificates. If the client is
configured with a server IP address and certificate, it can validate configured with a server IP address and certificate, it can validate
the server by comparing the certificate offered by the server to the the server by comparing the certificate offered by the server to the
certificate that was provided: they should be the same. If the certificate that was provided: they should be the same. If the
certificate includes a Distinguished Name that is a fully-qualified certificate includes a Distinguished Name that is a fully-qualified
domain name, the client SHOULD present that domain name to the server domain name, the client SHOULD present that domain name to the server
in an SNI request. in an SNI request.
Rather than being configured with an IP address and a certificate, Rather than being configured with an IP address and a certificate,
skipping to change at page 9, line 19 skipping to change at page 9, line 16
in [RFC8310] section 8.1, if the certificate is signed by a root 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 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 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 locally-configured copy of the server certificate can be used, as in
the previous paragraph. 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 [RFC7766]. 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 the DSO specification [RFC8490]. Clients
must also honor the 'Retry Delay' TLV (section 5 of must also honor the 'Retry Delay' TLV (section 5 of [RFC8490]) if
[I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay. 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
the same Client. the same Client.
In order to know what links to request, the Client can be configured In order to know what links to request, the Client can be configured
with a list of links supported by the Relay. However, in some with a list of links supported by the Relay. However, in some
networking contexts, dynamic changes in the availability of links are networking contexts, dynamic changes in the availability of links are
skipping to change at page 10, line 22 skipping to change at page 10, line 22
indicating the multicast link from which traffic is requested. indicating the multicast link from which traffic is requested.
When an mDNS Link Data Request message is received, the Discovery When an mDNS Link Data Request message is received, the Discovery
Relay validates that it recognizes the link identifier, and that Relay validates that it recognizes the link identifier, and that
forwarding is enabled for that link. If both checks are successful, forwarding is enabled for that link. If both checks are successful,
it MUST send a response with RCODE=0 (NOERROR). If the link it MUST send a response with RCODE=0 (NOERROR). If the link
identifier is not recognized, it sends a response with RCODE=3 identifier is not recognized, it sends a response with RCODE=3
(NXDOMAIN/Name Error). If forwarding from that link to the Client is (NXDOMAIN/Name Error). If forwarding from that link to the Client is
not enabled, it sends a response with RCODE=5 (REFUSED). If the not enabled, it sends a response with RCODE=5 (REFUSED). If the
relay cannot satisfy the request for some other reason, for example relay cannot satisfy the request for some other reason, for example
resource exhaustion, it sends a response with RCODE=2 (SERVFAIL). It resource exhaustion, it sends a response with RCODE=2 (SERVFAIL).
is not an error to request a recognized link identifier which is not
yet available; the Discovery Relay accepts the request, and begins
forwarding packets when the link becomes available.
If the requested link is valid, the Relay begins forwarding all mDNS If the requested link is valid, the Relay begins forwarding all mDNS
response messages from that link to the Client. Delivery is not messages from that link to the Client. Delivery is not guaranteed:
guaranteed: if there is no buffer space, packets will be dropped. It if there is no buffer space, packets will be dropped. It is expected
is expected that regular mDNS retry processing will take care of that regular mDNS retry processing will take care of retransmission
retransmission of lost packets. The amount of buffer space is of lost packets. The amount of buffer space is implementation
implementation dependent, but generally should not be more than the dependent, but generally should not be more than the bandwidth delay
bandwidth delay product of the TCP connection [RFC1323]. The product of the TCP connection [RFC7323]. The Discovery Relay should
Discovery Relay should use the TCP_NOTSENT_LOWAT mechanism use the TCP_NOTSENT_LOWAT mechanism [NOTSENT][PRIO] or equivalent, to
[NOTSENT][PRIO] or equivalent, to avoid building up a backlog of data avoid building up a backlog of data in excess of the amount necessary
in excess of the amount necessary to have in flight to fill the to have in flight to fill the bandwidth delay product of the TCP
bandwidth delay product of the TCP connection. connection.
Encapsulated mDNS response messages from Relays to Clients are framed Encapsulated mDNS messages from Relays to Clients are framed within
within DSO messages. Each DSO message can contain multiple TLVs, but DSO messages. Each DSO message can contain multiple TLVs, but only a
only a single encapsulated mDNS message is conveyed per DSO message. single encapsulated mDNS message is conveyed per DSO message. Each
Each forwarded mDNS response message is sent in an Encapsulated mDNS forwarded mDNS message is sent in an Encapsulated mDNS Message TLV
Message TLV (Section 8.4). The source IP address and port of the (Section 8.4). The source IP address and port of the message MUST be
message MUST be encoded in an IP Source TLV (Section 8.5). The encoded in an IP Source TLV (Section 8.5). The multicast link on
multicast link on which the message was received MUST be encoded in a which the message was received MUST be encoded in a Link Identifier
Link Identifier TLV (Section 8.3). As described in the DSO TLV (Section 8.3). As described in the DSO specification [RFC8490],
specification [I-D.ietf-dnsop-session-signal], a Client MUST silently a Client MUST silently ignore unrecognized Additional TLVs in mDNS
ignore unrecognized Additional TLVs in mDNS messages, and MUST NOT messages, and MUST NOT discard mDNS messages that include
discard mDNS messages that include unrecognized Additional TLVs. unrecognized Additional TLVs.
A Client may discontinue listening for mDNS messages on a particular A Client may discontinue listening for mDNS messages on a particular
multicast link by sending a DSO message containing an mDNS Link Data multicast link by sending a DSO message containing an mDNS Link Data
Discontinue TLV (Section 8.2). Subsequent messages from that link Discontinue TLV (Section 8.2). The Discovery Relay MUST discontinue
that had previously been queued may arrive after listening has been forwarding mDNS messages when the Link Data Discontinue request is
discontinued. The Client should silently discard such messages. The received. However, messages from that link that had previously been
Discovery Relay MUST discontinue generating such messages as soon as queued may arrive after the Client has discontinued its listening.
the request is received. The Discovery Relay does not respond to The Client should silently discard such messages. The Discovery
this message other than to discontinue forwarding mDNS messages from Relay does not respond to the Link Data Discontinue message other
the specified links. than to discontinue forwarding mDNS messages from the specified
links.
6. Traffic from Clients to Relays 6. Traffic from Clients to Relays
Like mDNS traffic from relays, each mDNS query message sent by a Like mDNS traffic from relays, each mDNS message sent by a Client to
Client to a Discovery Relay is communicated in an Encapsulated mDNS a Discovery Relay is communicated in an Encapsulated mDNS Message TLV
Message TLV (Section 8.4) within a DSO message. Each message MUST (Section 8.4) within a DSO message. Each message MUST contain
contain exactly one Link Identifier TLV (Section 8.3). The Discovery exactly one Link Identifier TLV (Section 8.3). The Discovery Relay
Relay will transmit the mDNS query message to the mDNS port and will transmit the mDNS message to the mDNS port and multicast address
multicast address on the link specified in the message using the on the link specified in the message using the specified IP address
specified IP address family. family.
Although the communication between Clients and Relays uses the DNS Although the communication between Clients and Relays uses the DNS
stream protocol and DNS Stateless Operations, there is no case in stream protocol and DNS Stateless Operations, there is no case in
which a Client would legitimately send a DNS query (something other which a Client would legitimately send a DNS query (or anything else
than a DSO message) to a Relay. Therefore, if a Relay receives a other than a DSO message) to a Relay. Therefore, if a Relay receives
message other than a DSO message, it MUST respond with a REFUSED any message other than a DSO message, it MUST immediately abort that
result code. The reason not to simply drop the connection is that it DSO session with a TCP reset (RST).
might result in a continual reconnection loop.
When defining this behavior, the working group considered making it When defining this behavior, the working group considered making it
possible to specify more than one link identifier in an mDNSMessage possible to specify more than one link identifier in an mDNSMessage
TLV. A superficial evaluation of this suggests that this would be a TLV. A superficial evaluation of this suggested that this might be a
useful optimization, since when a query is issued, it will often be useful optimization, since when a query is issued, it will often be
issued to all links. However, because of the way mDNS handles issued to all links. However, on many link types, like Wi-Fi,
retries, it will almost never be the case that the exact same message multicast traffic is expensive
will be sent on more than one link. Therefore, the complexity that [I-D.ietf-mboned-ieee802-mcast-problems] and should be generated
this optimization adds is in no way justified by the potential frugally, so providing convenient ways to generate additional
benefit, and this idea has been abandoned. multicast traffic was determined to be an unwise optimization. In
addition, because of the way mDNS handles retries, it will almost
never be the case that the exact same message will be sent on more
than one link. Therefore, the complexity that this optimization adds
is not justified by the potential benefit, and this idea has been
abandoned.
7. Discovery Proxy Behavior 7. Discovery Proxy Behavior
Discovery Proxies treat multicast links for which Discovery Relay Discovery Proxies treat multicast links for which Discovery Relay
service is being used as if they were virtual interfaces; in other service is being used as if they were virtual interfaces; in other
words, a Discovery Proxy serving multiple remote multicast links words, a Discovery Proxy serving multiple remote multicast links
using multiple Discovery Relays behaves the same as a Discovery Proxy using multiple remote Discovery Relays behaves the same as a
serving multiple local multicast links using multiple physical Discovery Proxy serving multiple local multicast links using multiple
network interfaces. In this section we refer to multicast links local physical network interfaces. In this section we refer to
served directly by the Discovery Proxy as locally-connected links, multicast links served directly by the Discovery Proxy as locally-
and multicast links served through the Discovery Relay as relay- connected links, and multicast links served through the Discovery
connected links. Relay as relay-connected links. A relay-connected link can be
thought of as similar to a link that a Discovery Proxy connects to
using a USB Ethernet interface, just with a very long USB cable (that
runs over TCP).
When a Discovery Proxy receives a DNSSD query from a Client via When a Discovery Proxy receives a DNS query from a DNS client via
unicast, it will generate mDNS query messages on the relevant unicast, it will generate corresponding mDNS query messages on the
multicast link(s) for which it is acting as a proxy. For locally- relevant multicast link(s) for which it is acting as a proxy. For
connected link(s), those query messages will be sent directly. For locally-connected link(s), those query messages will be sent
relay-connected link(s), the query messages will be sent through the directly. For relay-connected link(s), the query messages will be
Discovery Relay that is being used to serve that multicast link. sent through the Discovery Relay that is being used to serve that
multicast link.
Responses from devices on locally-connected links are processed Responses from devices on locally-connected links are processed
normally. Responses from devices on relay-connected links are normally. Responses from devices on relay-connected links are
received by the Discovery Relay, encapsulated, and forwarded to the received by the Discovery Relay, encapsulated, and forwarded to the
Client; the Client then processes these messages using the link- Client; the Client then processes these messages using the link-
identifying information included in the encapsulation. identifying information included in the encapsulation.
Discovery Proxies do not generally respond to mDNS queries on relay-
connected links. The one exception is responding to the Domain
Enumeration queries used to bootstrap unicast service discovery
("lb._dns-sd._udp.local", etc.) [RFC6763]. Apart from these Domain
Enumeration queries, if any other mDNS query is received from a
Discovery Relay, the Discovery Proxy silently discards it.
In principle it could be the case that some device is capable of In principle it could be the case that some device is capable of
performing service discovery using Multicast DNS, but not using performing service discovery using Multicast DNS, but not using
traditional unicast DNS. Responding to mDNS queries received from traditional unicast DNS. Responding to mDNS queries received from
the Discovery Relay could address this use case. However, continued the Discovery Relay could address this use case. However, continued
reliance on multicast is counter to the goals of the current work in reliance on multicast is counter to the goals of the current work in
service discovery, and to benefit from wide-area service discovery service discovery, and to benefit from wide-area service discovery
such client devices should be updated to support service discovery such client devices should be updated to support service discovery
using unicast queries. using unicast queries.
8. DSO TLVs 8. DSO TLVs
skipping to change at page 14, line 31 skipping to change at page 14, line 31
The mDNS Link Data Request TLV can only be used as a primary TLV, and The mDNS Link Data Request TLV can only be used as a primary TLV, and
requires an acknowledgement. requires an acknowledgement.
At most one mDNS Link Data Request TLV may appear in a DSO message. At most one mDNS Link Data Request TLV may appear in a DSO message.
To request multiple link subscriptions, multiple separate DSO To request multiple link subscriptions, multiple separate DSO
messages are sent, each containing a single mDNS Link Data Request messages are sent, each containing a single mDNS Link Data Request
TLV. TLV.
A Client MUST NOT request a link if it already has an active A Client MUST NOT request a link if it already has an active
subscription to that link on the same DSO connection. If a Discovery subscription to that link on the same DSO connection. If a Discovery
Relay receives a duplicate link subscription request, it SHOULD Relay receives a duplicate link subscription request, it MUST
immediately abort that DSO session. immediately abort that DSO session with a TCP reset (RST).
8.2. mDNS Link Data Discontinue 8.2. mDNS Link Data Discontinue
The mDNS Link Data Discontinue TLV is used by Clients to unsubscribe The mDNS Link Data Discontinue TLV is used by Clients to unsubscribe
to mDNS messages on the specified multicast link. DSO-TYPE is TBD-D. to mDNS messages on the specified multicast link. DSO-TYPE is TBD-D.
DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family
followed by the 32-bit link identifier, a 32-bit unsigned integer in followed by the 32-bit link identifier, a 32-bit unsigned integer in
network (big endian) byte order, as described in Section 9. network (big endian) byte order, as described in Section 9.
The mDNS Link Data Discontinue TLV can only be used as a primary TLV, The mDNS Link Data Discontinue TLV can only be used as a DSO
and is not acknowledged. unidirectional message TLV, and is not acknowledged.
At most one mDNS Link Data Discontinue TLV may appear in a DSO At most one mDNS Link Data Discontinue TLV may appear in a DSO
message. To unsubscribe from multiple links, multiple separate DSO message. To unsubscribe from multiple links, multiple separate DSO
messages are sent, each containing a single mDNS Link Data messages are sent, each containing a single mDNS Link Data
Discontinue TLV. Discontinue TLV.
8.3. Link Identifier 8.3. Link Identifier
This option is used both in DSO messages from Discovery Relays to This option is used both in DSO messages from Discovery Relays to
Clients that contain received mDNS messages, and from Clients to Clients that contain received mDNS messages, and from Clients to
Discovery Relays that contain mDNS messages to be transmitted on the Discovery Relays that contain mDNS messages to be transmitted on the
multicast link. In the former case, it indicates the multicast link multicast link. In the former case, it indicates the multicast link
on which the message was received; in the latter case, it indicates on which the message was received; in the latter case, it indicates
the multicast link on which the message should be transmitted. DSO- the multicast link on which the message should be transmitted. DSO-
TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit
address family followed by the link identifier, a 32-bit unsigned address family followed by the link identifier, a 32-bit unsigned
integer in network (big endian) byte order, as described in integer in network (big endian) byte order, as described in
Section 9. Section 9.
The Link Identifier TLV can only be used as an additional TLV. The Link Identifier TLV can only be used as an additional TLV. The
Link Identifier TLV can only appear at most once in a Discovery Relay
DSO message.
8.4. Encapsulated mDNS Message 8.4. Encapsulated mDNS Message
The Encapsulated mDNS Message TLV is used to communicate an mDNS The Encapsulated mDNS Message TLV is used to communicate an mDNS
message that a Relay is forwarding from a multicast link to a Client, message that a Relay is forwarding from a multicast link to a Client,
or that a Client is sending to a Relay for transmission on a or that a Client is sending to a Relay for transmission on a
multicast link. Only the application-layer payload of the mDNS multicast link. Only the application-layer payload of the mDNS
message is carried in the DSO "Encapsulated mDNS Message" TLV, i.e., message is carried in the DSO "Encapsulated mDNS Message" TLV, i.e.,
just the DNS message itself, beginning with the DNS Message ID, not just the DNS message itself, beginning with the DNS Message ID, not
the IP or UDP headers. The DSO-TYPE for this TLV is TBD-M. DSO- the IP or UDP headers. The DSO-TYPE for this TLV is TBD-M. DSO-
LENGTH is the length of the encapsulated mDNS message. DSO-DATA is LENGTH is the length of the encapsulated mDNS message. DSO-DATA is
the content of the encapsulated mDNS message. the content of the encapsulated mDNS message.
The Encapsulated mDNS Message TLV can only be used as a primary TLV, The Encapsulated mDNS Message TLV can only be used as a DSO
and is not acknowledged. unidirectional message TLV, and is not acknowledged.
8.5. IP Source 8.5. IP Source
The IP Source TLV is used to report the IP source address and port The IP Source TLV is used to report the IP source address and port
from which an mDNS message was received. This TLV is present in DSO from which an mDNS message was received. This TLV is present in DSO
messages from Discovery Relays to Clients that contain encapsulated messages from Discovery Relays to Clients that contain encapsulated
mDNS messages. DSO-TYPE is TBD-S. DSO-LENGTH is either 6, for an mDNS messages. DSO-TYPE is TBD-S. DSO-LENGTH is either 6, for an
IPv4 address, or 18, for an IPv6 address. DSO-DATA is the two-byte IPv4 address, or 18, for an IPv6 address. DSO-DATA is the two-byte
source port, followed by the 4- or 16-byte IP Address, both in the source port, followed by the 4- or 16-byte IP Address. Both port and
canonical byte order (i.e., the same representation as used in the address are in the canonical byte order (i.e., the same
UDP and IP packet headers, with no byte swapping). representation as used in the UDP and IP packet headers, with no byte
swapping).
The IP Source TLV can only be used as an additional TLV. The IP Source TLV can only be used as an additional TLV. The IP
Source TLV can only appear at most once in a Discovery Relay DSO
message.
8.6. Link State Request 8.6. Link State Request
The Link State Request TLV requests that the Discovery Relay report The Link State Request TLV requests that the Discovery Relay report
link changes. When the relay is reporting link changes and a new link changes. When the relay is reporting link changes and a new
link becomes available, it sends a Link Available message to the link becomes available, it sends a Link Available message to the
Client. When a link becomes unavailable, it sends a Link Unavailable Client. When a link becomes unavailable, it sends a Link Unavailable
message to the Client. If there are links available when the request message to the Client. If there are links available when the request
is received, then for each such link the relay immediately sends a is received, then for each such link the relay immediately sends a
Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH
skipping to change at page 16, line 22 skipping to change at page 16, line 28
a Link Available TLV: it is just a response to the Link State Request a Link Available TLV: it is just a response to the Link State Request
message. message.
8.7. Link State Discontinue 8.7. Link State Discontinue
The Link State Discontinue TLV requests that the Discovery Relay stop The Link State Discontinue TLV requests that the Discovery Relay stop
reporting on the availability of links supported by the relay. This reporting on the availability of links supported by the relay. This
cancels the effect of a Link State Request TLV. DSO-TYPE is TBD-Q. cancels the effect of a Link State Request TLV. DSO-TYPE is TBD-Q.
DSO-LENGTH is 0. DSO-LENGTH is 0.
The mDNS Link State Discontinue TLV can only be used as a primary The mDNS Link State Discontinue TLV can only be used as a DSO
TLV, and is not acknowledged. unidirectional message TLV, and is not acknowledged.
8.8. Link Available 8.8. Link Available
The Link Available TLV is used by Discovery Relays to indicate to The Link Available TLV is used by Discovery Relays to indicate to
Clients that a new link has become available. The format is the same Clients that a new link has become available. The format is the same
as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available
TLV may be accompanied by one or more Link Prefix TLVs which indicate TLV may be accompanied by one or more Link Prefix TLVs which indicate
IP prefixes the Relay knows to be present on the link. IP prefixes the Relay knows to be present on the link.
The mDNS Link Available TLV can only be used as a primary TLV, and is The mDNS Link Available TLV can only be used as a DSO unidirectional
not acknowledged. message TLV, and is not acknowledged.
8.9. Link Unavailable 8.9. Link Unavailable
The Link Unavailable TLV is used by Discovery Relays to indicate to The Link Unavailable TLV is used by Discovery Relays to indicate to
Clients that an existing link has become unavailable. The format is Clients that an existing link has become unavailable. The format is
the same as the Link Identifier TLV. DSO-TYPE is TBD-U. the same as the Link Identifier TLV. DSO-TYPE is TBD-U.
The mDNS Link Unavailable TLV can only be used as a primary TLV, and The mDNS Link Unavailable TLV can only be used as a DSO
is not acknowledged. unidirectional message TLV, and is not acknowledged.
8.10. Link Prefix 8.10. Link Prefix
The Link Prefix TLV represents an IP address or prefix configured on The Link Prefix TLV represents an IP address or prefix configured on
a link. The length is 17 for an IPv6 address or prefix, and 5 for an a link. The length is 17 for an IPv6 address or prefix, and 5 for an
IPv4 address or prefix. The TLV consists of a prefix length, between IPv4 address or prefix. The TLV consists of a prefix length, between
0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a 0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a
single byte. This is followed by the IP address, either four or single byte. This is followed by the IP address, either four or
sixteen bytes. DSO-TYPE is TBD-K. sixteen bytes. DSO-TYPE is TBD-K.
skipping to change at page 19, line 31 skipping to change at page 20, line 16
The description of a multicast link consists of: The description of a multicast link consists of:
link-identifier A 32-bit identifier that uniquely identifies that link-identifier A 32-bit identifier that uniquely identifies that
link within the Discovery Domain. Each link MUST have exactly one link within the Discovery Domain. Each link MUST have exactly one
such identifier. Link Identifiers do not have any special such identifier. Link Identifiers do not have any special
semantics, and are not intended to be human-readable. semantics, and are not intended to be human-readable.
ldh-name A fully-qualified domain name for the multicast link that ldh-name A fully-qualified domain name for the multicast link that
is used to form an LDH domain name as described in section 5.3 of is used to form an LDH domain name as described in section 5.3 of
the Discovery Proxy specification [I-D.ietf-dnssd-hybrid]. This the Discovery Proxy specification [RFC8766]. This name is used to
name is used to identify the link during provisioning, and must be identify the link during provisioning, and must be present.
present.
hr-name A human-readable user-friendly fully-qualified domain name hr-name A human-readable user-friendly fully-qualified domain name
for the multicast link. This name MUST be unique within the for the multicast link. This name MUST be unique within the
Discovery Domain. Each multicast link MUST have exactly one such Discovery Domain. Each multicast link MUST have exactly one such
name. The hr-name MAY be the same as the ldh-name. (The hr-name name. The hr-name MAY be the same as the ldh-name. (The hr-name
is allowed to contain spaces, punctuation and rich text, but it is is allowed to contain spaces, punctuation and rich text, but it is
not required to do so.) not required to do so.)
The ldh-name and hr-name can be used to form the LDH and human- The ldh-name and hr-name can be used to form the LDH and human-
readable domain names as described in [I-D.ietf-dnssd-hybrid], readable domain names as described in [RFC8766], section 5.3.
section 5.3.
Note that the ldh-name and hr-name can be used in two different ways. Note that the ldh-name and hr-name can be used in two different ways.
On a small home network with little or no human administrative On a small home network with little or no human administrative
configuration, link names may be directly visible to the user. For configuration, link names may be directly visible to the user. For
example, a search in 'home.arpa' on a small home network may discover example, a search in 'home.arpa' on a small home network may discover
services on both ethernet.home.arpa and wi-fi.home.arpa. In the case services on both ethernet.home.arpa and wi-fi.home.arpa. In the case
of a home user who has one Ethernet-connected printer and one Wi-Fi- of a home user who has one Ethernet-connected printer and one Wi-Fi-
connected printer, discovering that they have one printer on connected printer, discovering that they have one printer on
ethernet.home.arpa and another on wi-fi.home.arpa is understandable ethernet.home.arpa and another on wi-fi.home.arpa is understandable
and meaningful. and meaningful.
On a large corporate network with hundreds of Wi-Fi access points, On a large corporate network with hundreds of Wi-Fi access points,
the individual link names of the hundreds of multicast links are less the individual link names of the hundreds of multicast links are less
likely to be useful to end users. In these cases, Discovery Broker likely to be useful to end users. In these cases, Discovery Broker
functionality [I-D.sctl-discovery-broker] is used to translate the functionality [I-D.sctl-discovery-broker] may be used to translate
many link names to something more meaningful to users. For example, the many link names to something more meaningful to users. For
in a building with 50 Wi-Fi access points, each with their own link example, in a building with 50 Wi-Fi access points, each with their
names, services on all the different physical links may be presented own link names, services on all the different physical links may be
to the user as appearing in 'headquarters.example.com'. In this presented to the user as appearing in 'headquarters.example.com'. In
case, the individual link names can be thought of similar to MAC this case, the individual link names can be thought of similar to MAC
addresses or IPv6 addresses. They are used internally by the addresses or IPv6 addresses. They are used internally by the
software as unique identifiers, but generally are not exposed to end software as unique identifiers, but generally are not exposed to end
users. users.
9.1.2. Discovery Proxy 9.1.2. Discovery Proxy
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.
skipping to change at page 21, line 38 skipping to change at page 22, line 21
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.
certificate a certificate that identifies the Discovery Relay. This certificate a certificate that identifies the Discovery Relay. This
certificate can be shared across services on the Discovery Relay certificate can be shared across services on the Discovery Relay
Host. Indeed, if a Discovery Proxy and Discovery Relay are Host. Indeed, if a Discovery Proxy and Discovery Relay are
running on the same host, the same certificate can be used for running on the same host, the same certificate can be used for
both. The public key in the certificate uniquely identifies the both. The public key in the certificate uniquely identifies the
Discovery Relay and is used by the Discovery Proxy to verify that Discovery Relay and is used by a Discovery Relay Client (e.g., a
it is talking to the intended Discovery Relay after a TLS Discovery Proxy) to verify that it is talking to the intended
connection has been established. The certificate must either be Discovery Relay after a TLS connection has been established. The
signed by its own key, or have a signature chain that can be certificate must either be signed by its own key, or have a
validated using PKIX authentication [RFC6125]. signature chain that can be validated using PKIX authentication
[RFC6125].
private-key the private key corresponding to the public key in the private-key the private key corresponding to the public key in the
certificate. 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
skipping to change at page 23, line 32 skipping to change at page 24, line 32
link downstairs-wifi link downstairs-wifi
link downstairs-wired link downstairs-wired
client-whitelist main client-whitelist main
Proxy main Proxy main
certificate 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 hr-name Upstairs Wifi
Link upstairs-wired Link upstairs-wired
id 2 id 2
hr-name Upstairs Wired hr-name Upstairs Wired
Link downstairs-wifi Link downstairs-wifi
id 3 id 3
name Downstairs Wifi hr-name Downstairs Wifi
Link downstairs-wired Link downstairs-wired
id 4 id 4
hr-name Downstairs Wired hr-name Downstairs Wired
9.3. Discovery Proxy Private Configuration 9.3. Discovery Proxy Private Configuration
The Discovery Proxy configuration contains enough information to The Discovery Proxy configuration contains enough information to
identify which Discovery Proxy is being configured, enumerate the identify which Discovery Proxy is being configured, enumerate the
list of multicast links it is intended to serve, and provide keying list of multicast links it is intended to serve, and provide keying
skipping to change at page 25, line 19 skipping to change at page 26, line 19
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
useful today. The BOOTP protocol uses no encryption, and in many useful today. The BOOTP protocol uses no encryption, and in many
enterprise networks this is considered acceptable. In contrast, the enterprise networks this is considered acceptable. In contrast, the
Discovery Relay protocol requires TLS 1.3. A concern is that after Discovery Relay protocol requires TLS 1.3. A concern is that after
20 or 30 years, TLS 1.3, or some of the encryption algorithms it 20 or 30 years, TLS 1.3, or some of the encryption algorithms it
uses, may become obsolete, rendering devices that require it uses, may become obsolete, rendering devices that require it
unusable. Our assessment is that TLS 1.3 probably will be around for unusable. Our assessment is that TLS 1.3 probably will be around for
many years to come. TLS 1.0 [RFC2246] was used for about a decade, many years to come. TLS 1.0 [RFC2246] was used for about a decade,
and similarly TLS 1.2 [RFC5246] was also used for about a decade. We and similarly TLS 1.2 [RFC5246] was also used for about a decade. We
expect TLS 1.3 [I-D.ietf-tls-tls13] to have at least that lifespan. expect TLS 1.3 [RFC8446] to have at least that lifespan. In
In addition, recent IETF efforts are pushing for better software addition, recent IETF efforts are pushing for better software update
update practices for devices like routers, for other security practices for devices like routers, for other security reasons,
reasons, making it likely that in ten years time it will be less making it likely that in ten years time it will be less common to be
common to be using routers that haven't had a software update for ten using routers that haven't had a software update for ten years.
years. However, authors of encryption specifications and libraries However, authors of encryption specifications and libraries should be
should be aware of the potential backwards compatibility issues if an aware of the potential backwards compatibility issues if an
encryption algorithm becomes deprecated. This specification encryption algorithm becomes deprecated. This specification
RECOMMENDS that if an encryption algorithm becomes deprecated, then RECOMMENDS that if an encryption algorithm becomes deprecated, then
rather than remove that encryption algorithm entirely, encryption rather than remove that encryption algorithm entirely, encryption
libraries should disable that encryption algorithm by default, but libraries should disable that encryption algorithm by default, but
leave the code present with an option for client software to enable leave the code present with an option for client software to enable
it in special cases, such as a recent Client talking to an ancient it in special cases, such as a recent Client talking to an ancient
Discovery Relay. Using no encryption, like BOOTP, would eliminate Discovery Relay. Using no encryption, like BOOTP, would eliminate
this backwards compatibility concern, but we feel that in such a this backwards compatibility concern, but we feel that in such a
future hypothetical scenario, using even a weak encryption algorithm future hypothetical scenario, using even a weak encryption algorithm
still makes passive eavesdropping and tampering harder, and is still makes passive eavesdropping and tampering harder, and is
preferable to using no encryption at all. preferable to using no encryption at all.
11. IANA Considerations 11. IANA Considerations
The IANA is kindly requested to update the DSO Type Codes Registry The IANA is kindly requested to update the DSO Type Codes Registry
[I-D.ietf-dnsop-session-signal] by allocating codes for each of the [RFC8490] by allocating codes for each of the TBD type codes listed
TBD type codes listed in the following table, and by updating this in the following table, and by updating this document, here and in
document, here and in Section 8. Each type code should list this Section 8. Each type code should list this document as its reference
document as its reference document. document.
+--------+----------+---------------------------+ +----------+----------+---------------------------+
| Opcode | Status | Name | | DSO-TYPE | Status | Name |
+--------+----------+---------------------------+ +----------+----------+---------------------------+
| TBD-R | Standard | Link Data Request | | TBD-R | Standard | Link Data Request |
| TBD-D | Standard | Link Data Discontinue | | TBD-D | Standard | Link Data Discontinue |
| TBD-L | Standard | Link Identifier | | TBD-L | Standard | Link Identifier |
| TBD-M | Standard | Encapsulated mDNS Message | | TBD-M | Standard | Encapsulated mDNS Message |
| TBD-S | Standard | IP Source | | TBD-S | Standard | IP Source |
| TBD-P | Standard | Link State Request | | TBD-P | Standard | Link State Request |
| TBD-Q | Standard | Link State Discontinue | | TBD-Q | Standard | Link State Discontinue |
| TBD-V | Standard | Link Available | | TBD-V | Standard | Link Available |
| TBD-U | Standard | Link Unavailable | | TBD-U | Standard | Link Unavailable |
| TBD-K | Standard | Link Prefix | | TBD-K | Standard | Link Prefix |
+--------+----------+---------------------------+ +----------+----------+---------------------------+
DSO Type Codes to be allocated DSO Type Codes to be allocated
12. Acknowledgments 12. Acknowledgments
To be completed... Thanks to Derek Atkins for the secdir early review.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-dnsop-session-signal]
Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-20 (work in progress),
December 2018.
[I-D.ietf-dnssd-hybrid]
Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
progress), March 2018.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[I-D.sctl-discovery-broker]
Cheshire, S. and T. Lemon, "Service Discovery Broker",
draft-sctl-discovery-broker-00 (work in progress), July
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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
for High Performance", RFC 1323, DOI 10.17487/RFC1323, May Requirement Levels", BCP 14, RFC 2119,
1992, <https://www.rfc-editor.org/info/rfc1323>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 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
skipping to change at page 28, line 9 skipping to change at page 28, line 38
<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>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>.
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
D. Wessels, "DNS Transport over TCP - Implementation D. Wessels, "DNS Transport over TCP - Implementation
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
<https://www.rfc-editor.org/info/rfc7766>. <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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
for DNS over TLS and DNS over DTLS", RFC 8310, for DNS over TLS and DNS over DTLS", RFC 8310,
DOI 10.17487/RFC8310, March 2018, DOI 10.17487/RFC8310, March 2018,
<https://www.rfc-editor.org/info/rfc8310>. <https://www.rfc-editor.org/info/rfc8310>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
RFC 8490, DOI 10.17487/RFC8490, March 2019,
<https://www.rfc-editor.org/info/rfc8490>.
[RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June
2020, <https://www.rfc-editor.org/info/rfc8766>.
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-
address-family-numbers/>. numbers/>.
[AdProx] Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", draft-sctl-advertising-
proxy-00 (work in progress), July 2020.
[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-04 (work Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work
in progress), November 2018. in progress), December 2019.
[I-D.sctl-discovery-broker]
Cheshire, S. and T. Lemon, "Service Discovery Broker",
draft-sctl-discovery-broker-00 (work in progress), July
2017.
[NOTSENT] Dumazet, E., "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] Chan, W., "Prioritization Only Works When There's Pending [PRIO] Chan, W., "Prioritization Only Works When There's Pending
Data to Prioritize", January 2014, Data to Prioritize", January 2014,
<https://insouciant.org/tech/prioritization-only-works- <https://insouciant.org/tech/prioritization-only-works-
when-theres-pending-data-to-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,
skipping to change at page 29, line 17 skipping to change at page 30, line 30
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[TR-069] Broadband Forum, "CPE WAN Management Protocol", November [TR-069] Broadband Forum, "CPE WAN Management Protocol", November
2013, <https://www.broadband-forum.org/technical/download/ 2013, <https://www.broadband-forum.org/technical/download/
TR-069_Amendment-5.pdf>. TR-069_Amendment-5.pdf>.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nibbhaya Consulting Apple Inc.
P.O. Box 958 One Apple Park Way
Brattleboro, Vermont 05301 Cupertino, California 95014
United States of America United States of America
Email: mellon@fugue.com Phone: +1 (408) 996-1010
Email: elemon@apple.com
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
USA United States of America
Phone: +1 (408) 996-1010 Phone: +1 (408) 996-1010
Email: cheshire@apple.com Email: cheshire@apple.com
 End of changes. 69 change blocks. 
264 lines changed or deleted 303 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/