Internet Engineering Task Force S. Cheshire
Internet-Draft Apple Inc.
Intended status: Informational T. Lemon
Expires: January 3, 2018 Nominum, Inc.
July 2, 2017
Service Discovery Broker
draft-sctl-discovery-broker-00
Abstract
DNS-Based Service Discovery allows clients to discover available
services using unicast DNS queries. In simple configurations these
unicast DNS queries go directly to the appropriate authoritative
server(s). In large networks that have complicated topology, or
many client devices, or both, it can be advantageous to have an
intermediary between the clients and authoritative servers. This
intermediary, called a Discovery Broker, serves several purposes.
A Discovery Broker can reduce load on both the servers and the
clients, and gives the option of presenting clients with service
discovery organized around logical, rather than physical, topology.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Cheshire & Lemon Expires January 3, 2018 [Page 1]
Internet-Draft Service Discovery Broker July 2017
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
DNS-Based Service Discovery (DNS-SD) [RFC6763] is a component of Zero
Configuration Networking [RFC6760] [ZC] [Roadmap].
DNS-SD operates on a single network link (broadcast domain) using
Multicast DNS [RFC6762]. DNS-SD can span multiple links using
unicast DNS.
In the DNS-SD specification [RFC6763] section 11, "Discovery of
Browsing and Registration Domains (Domain Enumeration)", describes
how client devices are automatically configured with the appropriate
unicast DNS domains in which to perform their service discovery
queries. When used in conjunction with a Discovery Proxy [DisProx]
this allows clients to discover services on remote links, even when
the devices providing those services support only the basic Multicast
DNS form of DNS-Based Service Discovery. A Discovery Broker is a
companion technology that operates in conjunction with existing
authoritative DNS servers (such as a Discovery Proxy [DisProx]) and
existing clients performing service discovery using unicast DNS
queries.
Cheshire & Lemon Expires January 3, 2018 [Page 2]
Internet-Draft Service Discovery Broker July 2017
2. Problem Statement
The following description of how a Discovery Broker works is
illustrated using the example of a long rectangular office building.
The building is large enough to have hundreds or even thousands of
employees working there, the network is large enough that it would be
impractical to operate it as a single link (a single broadcast
domain, with a single IPv4 subnet or IPv6 network prefix).
Suppose, for this example, that the network is divided into twelve
separate links, connected by routers. Each link has its own IPv6
network prefix. The division of the network into twelve sections of
roughly equal size is somewhat arbitrary, and does not necessarily
follow any physical boundaries in the building that are readily
apparent to its inhabitants. Two people in adjacent offices on the
same corridor may have Ethernet ports connected to different links.
Indeed, two devices in the same office, connected to the company
network using secure Wi-Fi, may inadvertently associate with
different access points, which happen to be connected to different
wired links with different IPv6 network prefixes.
If this network were operated the way most networks have historically
been operated, it would use only Multicast DNS Service Discovery, and
adjacent devices that happen to connect to different underlying links
would be unable to discover each other. And this would not be a rare
occurrence. Since this example building contains eleven invisible
boundaries between the twelve different links, anyone close to one of
those invisible boundaries will have a population of nearby devices
that are not discoverable on the network, because they're on a
different link. For example, a shared printer in a corridor outside
one person's office may not be discoverable by the person in the very
next office.
One path to solving this problem is as follows:
1. Install a Discovery Proxy [DisProx] on each of the twelve links.
2. Create twelve named subdomains, such as, "services1.example.com",
"services2.example.com", "services3.example.com", and so on.
3. Delegate each named subdomain to the corresponding Discovery
Proxy on that link.
4. Create entries in the 'ip6.arpa' reverse mapping zone directing
clients on each link to perform service discovery queries in the
appropriate named subdomains, as documented in section 11 of the
DNS-SD specification [RFC6763].
Cheshire & Lemon Expires January 3, 2018 [Page 3]
Internet-Draft Service Discovery Broker July 2017
In step 4 above, it might be tempting to add only a single record in
each reverse mapping domain referencing the corresponding services
subdomain. This would work, but it would only facilitate each client
discovering the same services it could already discover using
Multicast DNS [RFC6762]. In some cases even this is useful, such as
when using Wi-Fi Access Points with multicast disabled for
efficiency. In such cases this configuration would allow wireless
clients to discover services on the wired network segment without
having to use costly Wi-Fi multicast.
But for this example we want to achieve more than just equivalency
with Multicast DNS.
In this example, each reverse mapping domain is populated with the
name of its own services subdomain, plus its neighbors. The reverse
mapping domain for the first link has two "lb._dns-sd._udp" PTR
records, referencing "services1.example.com" and
"services2.example.com". The second link references services1,
services2, and services3. The third link references services2,
services3, and services4. This continues along the building, until
the last link, which references services11 and services12.
In this way a "sliding window" is created, where devices on each link
are directed to look for services both on that link and on its two
immediate neighbors. Depending on the physical and logical
topologies of the building and its network, it may be appropriate to
direct clients to query in more than three services subdomains. If
the building were a ring instead of a linear rectangle, then the
network topology would "wrap around", so that links 1 and 12 would be
neighbors.
This solves the problem of being unable to discover a nearby device
because it happens to be just the other side of one of the twelve
arbitrary invisible network link boundaries.
For many cases this solution is adequate, but there is an issue to
consider. In the example above, a client device on link 5 has TCP
connections to three Discovery Proxies, on links 4, 5 and 6. In a
more complex setup each client could have many more TCP connections
to different Discovery Proxies.
Similarly, if there are a many clients, each Discovery Proxy could be
required to handle thousands of simultaneous TCP connections from
clients.
The solution to these two problems is the Discovery Broker.
Cheshire & Lemon Expires January 3, 2018 [Page 4]
Internet-Draft Service Discovery Broker July 2017
3. Discovery Broker Operation
The Discovery Broker is an intermediary between the client devices
and the Discovery Proxies. It is a kind of multiplexing crossbar
switch. It shields the clients from having to connect to multiple
Discovery Proxies, and it shields the Discovery Proxies from having
to accept connections from thousands of clients.
Each client needs only a single TCP connection to a single Discovery
Broker, rather than multiple TCP connections directly to multiple
Discovery Proxies. This eases the load on client devices, which may
be mobile and battery-powered.
Each Discovery Proxy needs to support connections to at most a small
number of Discovery Brokers. The burden of supporting thousands of
clients is taken by the Discovery Broker, which can be a powerful
server in a data center. This eases the load on the Discovery Proxy,
which may be implemented in a device with limited RAM and CPU
resources, like a Wi-Fi access point or IP router.
Recall that a Discovery Proxy [DisProx] is a special kind of
authoritative DNS server [RFC1034] [RFC1035]. Externally it behaves
like a traditional authoritative DNS server, except that instead of
getting its zone data from a manually-administered zone file, it
learns its zone data dynamically as a result of performing Multicast
DNS queries on its local link.
A Discovery Broker is a similar concept, except that it learns its
zone data dynamically as a result of performing *unicast* DNS
queries. For example, a Discovery Broker could be configured so that
the answer for "<something>.discovery5.example.com" is obtained by
performing corresponding unicast DNS queries:
<something>.services4.example.com
<something>.services5.example.com
<something>.services6.example.com
and then returning the union of the results as the answer. The rdata
of the returned answers is not rewritten or modified in any way by
the Discovery Broker.
Cheshire & Lemon Expires January 3, 2018 [Page 5]
Internet-Draft Service Discovery Broker July 2017
4. Protocol Transparency
From the point of view of an authoritative DNS server such as a
Discovery Proxy, the protocol a Discovery Broker uses to make
requests of it is the exact same DNS protocol that any other client
would use to make requests of it (which may be traditional one-shot
DNS queries [RFC1034] [RFC1035] or long-lived DNS Push Notifications
[Push]).
A Discovery Broker making requests is no different from any other
client making requests. The fact that the Discovery Broker may be
making a single request on behalf of thousands of clients making the
same request, thereby shielding the Discovery Proxy from excessive
traffic burden, is invisible to the Discovery Proxy.
This means that an authoritative DNS server such as a Discovery Proxy
does not have to be aware that it is being queried by a Discovery
Broker. In some scenarios a Discovery Proxy may be deployed with
clients talking to it directly; in other scenarios the same Discovery
Proxy product may be deployed with clients talking via a Discovery
Broker. The Discovery Proxy simply answers queries as usual in both
cases.
Similarly, from the point of view of a client, the protocol it uses
to talk to a Discovery Broker is the exact same DNS protocol it uses
to talk to a Discovery Proxy or any other authoritative DNS server.
This means that the client does not have to be aware that it is using
a Discovery Broker. The client simply sends service discovery
queries as usual, according to configuration it received from the
network or otherwise, and receives answers as usual. A Discovery
Broker may be employed to shield a Discovery Proxy from excessive
traffic burden, but this is transparent to a client.
Another benefit for the client is that by having the Discovery Broker
query multiple subdomains and aggregate the results, it saves the
client from having to do multiple separate queries of its own.
Cheshire & Lemon Expires January 3, 2018 [Page 6]
Internet-Draft Service Discovery Broker July 2017
5. Logical vs. Physical Topology
In the example so far, we have focussed on facilitating discovery of
devices and services that are physically nearby.
Another application of the Discovery Broker is to facilitate
discovery of devices and services according to other logical
relationships.
For example, it might be considered desirable for the company's two
file servers to be discoverable company-wide, but for its many
printers to only be discovered (by default) by devices on nearby
network links.
As another example, company policy may block access to certain
resources from Wi-Fi; in such cases it would make sense to implement
consistent policies at the service discovery layer, to avoid the user
frustration of services being discoverable on Wi-Fi that are not
usable from Wi-Fi.
Such policies, and countless variations thereon, may be implemented
in a Discovery Broker, limited only by the imagination of the vendor
creating the Discovery Broker implementation.
Cheshire & Lemon Expires January 3, 2018 [Page 7]
Internet-Draft Service Discovery Broker July 2017
6. Recursive Application
Due to the Protocol Transparency property described above, multiple
Discovery Brokers may be "stacked" in whatever combinations are
useful. A Discovery Broker makes queries in exactly the same way a
client would, and a Discovery Broker accepts queries in exactly the
same way a Discovery Proxy (or other authoritative DNS server) would.
This means that a Discovery Broker talking to another Discovery
Broker is no different from client-to-broker or broker-to-proxy
communication, or indeed, direct client-to-proxy communication. The
arrows in the chart below are all instances of the same communication
protocol.
client -> proxy
client -> broker -> proxy
client -> broker -> broker -> proxy
This makes it possible to combine Discovery Brokers with different
functionality. A Discovery Broker performing physical aggregation
could be used in conjunction with a Discovery Broker performing
policy-based filtering, as illustrated below:
------------ --------------- -------------
| Ethernet | --> | Aggregating | --> | Discovery |
| Client | | Broker | | Proxy |
------------ --------------- -------------
------------ ------------- --------------- -------------
| Wi-Fi | --> | Filtering | --> | Aggregating | --> | Discovery |
| Client | | Broker | | Broker | | Proxy |
------------ ------------- --------------- -------------
Cheshire & Lemon Expires January 3, 2018 [Page 8]
Internet-Draft Service Discovery Broker July 2017
7. Security Considerations
Discovery (or non-discovery) of services is not a substitute for
suitable access control. Servers listening on open ports are
generally discoverable via a brute-force port scan anyway; DNS-Based
Service Discovery makes access to these services easier for
legitimate users.
8. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)",
RFC 6760, DOI 10.17487/RFC6760, February 2013,
<http://www.rfc-editor.org/info/rfc6760>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[Roadmap] Cheshire, S., "Service Discovery Road Map", draft-
cheshire-dnssd-roadmap-00 (work in progress), July 2017.
[DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-06 (work in
progress), March 2017.
[Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-12 (work in progress), July 2017.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc. ,
ISBN 0-596-10100-7, December 2005.
Cheshire & Lemon Expires January 3, 2018 [Page 9]
Internet-Draft Service Discovery Broker July 2017
Authors' Addresses
Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino, California 95014
USA
Phone: +1 408 974 3207
Email: cheshire@apple.com
Ted Lemon
Nominum, Inc.
800 Bridge Parkway
Redwood City, California 94065
United States of America
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Cheshire & Lemon Expires January 3, 2018 [Page 10]