idnits 2.17.00 (12 Aug 2021) /tmp/idnits53029/draft-sctl-discovery-broker-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2017) is 1777 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-cheshire-dnssd-roadmap-00 == Outdated reference: draft-ietf-dnssd-hybrid has been published as RFC 8766 == Outdated reference: draft-ietf-dnssd-push has been published as RFC 8765 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Lemon 5 Expires: January 3, 2018 Nominum, Inc. 6 July 2, 2017 8 Service Discovery Broker 9 draft-sctl-discovery-broker-00 11 Abstract 13 DNS-Based Service Discovery allows clients to discover available 14 services using unicast DNS queries. In simple configurations these 15 unicast DNS queries go directly to the appropriate authoritative 16 server(s). In large networks that have complicated topology, or 17 many client devices, or both, it can be advantageous to have an 18 intermediary between the clients and authoritative servers. This 19 intermediary, called a Discovery Broker, serves several purposes. 20 A Discovery Broker can reduce load on both the servers and the 21 clients, and gives the option of presenting clients with service 22 discovery organized around logical, rather than physical, topology. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 DNS-Based Service Discovery (DNS-SD) [RFC6763] is a component of Zero 59 Configuration Networking [RFC6760] [ZC] [Roadmap]. 61 DNS-SD operates on a single network link (broadcast domain) using 62 Multicast DNS [RFC6762]. DNS-SD can span multiple links using 63 unicast DNS. 65 In the DNS-SD specification [RFC6763] section 11, "Discovery of 66 Browsing and Registration Domains (Domain Enumeration)", describes 67 how client devices are automatically configured with the appropriate 68 unicast DNS domains in which to perform their service discovery 69 queries. When used in conjunction with a Discovery Proxy [DisProx] 70 this allows clients to discover services on remote links, even when 71 the devices providing those services support only the basic Multicast 72 DNS form of DNS-Based Service Discovery. A Discovery Broker is a 73 companion technology that operates in conjunction with existing 74 authoritative DNS servers (such as a Discovery Proxy [DisProx]) and 75 existing clients performing service discovery using unicast DNS 76 queries. 78 2. Problem Statement 80 The following description of how a Discovery Broker works is 81 illustrated using the example of a long rectangular office building. 82 The building is large enough to have hundreds or even thousands of 83 employees working there, the network is large enough that it would be 84 impractical to operate it as a single link (a single broadcast 85 domain, with a single IPv4 subnet or IPv6 network prefix). 87 Suppose, for this example, that the network is divided into twelve 88 separate links, connected by routers. Each link has its own IPv6 89 network prefix. The division of the network into twelve sections of 90 roughly equal size is somewhat arbitrary, and does not necessarily 91 follow any physical boundaries in the building that are readily 92 apparent to its inhabitants. Two people in adjacent offices on the 93 same corridor may have Ethernet ports connected to different links. 94 Indeed, two devices in the same office, connected to the company 95 network using secure Wi-Fi, may inadvertently associate with 96 different access points, which happen to be connected to different 97 wired links with different IPv6 network prefixes. 99 If this network were operated the way most networks have historically 100 been operated, it would use only Multicast DNS Service Discovery, and 101 adjacent devices that happen to connect to different underlying links 102 would be unable to discover each other. And this would not be a rare 103 occurrence. Since this example building contains eleven invisible 104 boundaries between the twelve different links, anyone close to one of 105 those invisible boundaries will have a population of nearby devices 106 that are not discoverable on the network, because they're on a 107 different link. For example, a shared printer in a corridor outside 108 one person's office may not be discoverable by the person in the very 109 next office. 111 One path to solving this problem is as follows: 113 1. Install a Discovery Proxy [DisProx] on each of the twelve links. 115 2. Create twelve named subdomains, such as, "services1.example.com", 116 "services2.example.com", "services3.example.com", and so on. 118 3. Delegate each named subdomain to the corresponding Discovery 119 Proxy on that link. 121 4. Create entries in the 'ip6.arpa' reverse mapping zone directing 122 clients on each link to perform service discovery queries in the 123 appropriate named subdomains, as documented in section 11 of the 124 DNS-SD specification [RFC6763]. 126 In step 4 above, it might be tempting to add only a single record in 127 each reverse mapping domain referencing the corresponding services 128 subdomain. This would work, but it would only facilitate each client 129 discovering the same services it could already discover using 130 Multicast DNS [RFC6762]. In some cases even this is useful, such as 131 when using Wi-Fi Access Points with multicast disabled for 132 efficiency. In such cases this configuration would allow wireless 133 clients to discover services on the wired network segment without 134 having to use costly Wi-Fi multicast. 136 But for this example we want to achieve more than just equivalency 137 with Multicast DNS. 139 In this example, each reverse mapping domain is populated with the 140 name of its own services subdomain, plus its neighbors. The reverse 141 mapping domain for the first link has two "lb._dns-sd._udp" PTR 142 records, referencing "services1.example.com" and 143 "services2.example.com". The second link references services1, 144 services2, and services3. The third link references services2, 145 services3, and services4. This continues along the building, until 146 the last link, which references services11 and services12. 148 In this way a "sliding window" is created, where devices on each link 149 are directed to look for services both on that link and on its two 150 immediate neighbors. Depending on the physical and logical 151 topologies of the building and its network, it may be appropriate to 152 direct clients to query in more than three services subdomains. If 153 the building were a ring instead of a linear rectangle, then the 154 network topology would "wrap around", so that links 1 and 12 would be 155 neighbors. 157 This solves the problem of being unable to discover a nearby device 158 because it happens to be just the other side of one of the twelve 159 arbitrary invisible network link boundaries. 161 For many cases this solution is adequate, but there is an issue to 162 consider. In the example above, a client device on link 5 has TCP 163 connections to three Discovery Proxies, on links 4, 5 and 6. In a 164 more complex setup each client could have many more TCP connections 165 to different Discovery Proxies. 167 Similarly, if there are a many clients, each Discovery Proxy could be 168 required to handle thousands of simultaneous TCP connections from 169 clients. 171 The solution to these two problems is the Discovery Broker. 173 3. Discovery Broker Operation 175 The Discovery Broker is an intermediary between the client devices 176 and the Discovery Proxies. It is a kind of multiplexing crossbar 177 switch. It shields the clients from having to connect to multiple 178 Discovery Proxies, and it shields the Discovery Proxies from having 179 to accept connections from thousands of clients. 181 Each client needs only a single TCP connection to a single Discovery 182 Broker, rather than multiple TCP connections directly to multiple 183 Discovery Proxies. This eases the load on client devices, which may 184 be mobile and battery-powered. 186 Each Discovery Proxy needs to support connections to at most a small 187 number of Discovery Brokers. The burden of supporting thousands of 188 clients is taken by the Discovery Broker, which can be a powerful 189 server in a data center. This eases the load on the Discovery Proxy, 190 which may be implemented in a device with limited RAM and CPU 191 resources, like a Wi-Fi access point or IP router. 193 Recall that a Discovery Proxy [DisProx] is a special kind of 194 authoritative DNS server [RFC1034] [RFC1035]. Externally it behaves 195 like a traditional authoritative DNS server, except that instead of 196 getting its zone data from a manually-administered zone file, it 197 learns its zone data dynamically as a result of performing Multicast 198 DNS queries on its local link. 200 A Discovery Broker is a similar concept, except that it learns its 201 zone data dynamically as a result of performing *unicast* DNS 202 queries. For example, a Discovery Broker could be configured so that 203 the answer for ".discovery5.example.com" is obtained by 204 performing corresponding unicast DNS queries: 206 .services4.example.com 207 .services5.example.com 208 .services6.example.com 210 and then returning the union of the results as the answer. The rdata 211 of the returned answers is not rewritten or modified in any way by 212 the Discovery Broker. 214 4. Protocol Transparency 216 From the point of view of an authoritative DNS server such as a 217 Discovery Proxy, the protocol a Discovery Broker uses to make 218 requests of it is the exact same DNS protocol that any other client 219 would use to make requests of it (which may be traditional one-shot 220 DNS queries [RFC1034] [RFC1035] or long-lived DNS Push Notifications 221 [Push]). 223 A Discovery Broker making requests is no different from any other 224 client making requests. The fact that the Discovery Broker may be 225 making a single request on behalf of thousands of clients making the 226 same request, thereby shielding the Discovery Proxy from excessive 227 traffic burden, is invisible to the Discovery Proxy. 229 This means that an authoritative DNS server such as a Discovery Proxy 230 does not have to be aware that it is being queried by a Discovery 231 Broker. In some scenarios a Discovery Proxy may be deployed with 232 clients talking to it directly; in other scenarios the same Discovery 233 Proxy product may be deployed with clients talking via a Discovery 234 Broker. The Discovery Proxy simply answers queries as usual in both 235 cases. 237 Similarly, from the point of view of a client, the protocol it uses 238 to talk to a Discovery Broker is the exact same DNS protocol it uses 239 to talk to a Discovery Proxy or any other authoritative DNS server. 241 This means that the client does not have to be aware that it is using 242 a Discovery Broker. The client simply sends service discovery 243 queries as usual, according to configuration it received from the 244 network or otherwise, and receives answers as usual. A Discovery 245 Broker may be employed to shield a Discovery Proxy from excessive 246 traffic burden, but this is transparent to a client. 248 Another benefit for the client is that by having the Discovery Broker 249 query multiple subdomains and aggregate the results, it saves the 250 client from having to do multiple separate queries of its own. 252 5. Logical vs. Physical Topology 254 In the example so far, we have focussed on facilitating discovery of 255 devices and services that are physically nearby. 257 Another application of the Discovery Broker is to facilitate 258 discovery of devices and services according to other logical 259 relationships. 261 For example, it might be considered desirable for the company's two 262 file servers to be discoverable company-wide, but for its many 263 printers to only be discovered (by default) by devices on nearby 264 network links. 266 As another example, company policy may block access to certain 267 resources from Wi-Fi; in such cases it would make sense to implement 268 consistent policies at the service discovery layer, to avoid the user 269 frustration of services being discoverable on Wi-Fi that are not 270 usable from Wi-Fi. 272 Such policies, and countless variations thereon, may be implemented 273 in a Discovery Broker, limited only by the imagination of the vendor 274 creating the Discovery Broker implementation. 276 6. Recursive Application 278 Due to the Protocol Transparency property described above, multiple 279 Discovery Brokers may be "stacked" in whatever combinations are 280 useful. A Discovery Broker makes queries in exactly the same way a 281 client would, and a Discovery Broker accepts queries in exactly the 282 same way a Discovery Proxy (or other authoritative DNS server) would. 283 This means that a Discovery Broker talking to another Discovery 284 Broker is no different from client-to-broker or broker-to-proxy 285 communication, or indeed, direct client-to-proxy communication. The 286 arrows in the chart below are all instances of the same communication 287 protocol. 289 client -> proxy 291 client -> broker -> proxy 293 client -> broker -> broker -> proxy 295 This makes it possible to combine Discovery Brokers with different 296 functionality. A Discovery Broker performing physical aggregation 297 could be used in conjunction with a Discovery Broker performing 298 policy-based filtering, as illustrated below: 300 ------------ --------------- ------------- 301 | Ethernet | --> | Aggregating | --> | Discovery | 302 | Client | | Broker | | Proxy | 303 ------------ --------------- ------------- 305 ------------ ------------- --------------- ------------- 306 | Wi-Fi | --> | Filtering | --> | Aggregating | --> | Discovery | 307 | Client | | Broker | | Broker | | Proxy | 308 ------------ ------------- --------------- ------------- 310 7. Security Considerations 312 Discovery (or non-discovery) of services is not a substitute for 313 suitable access control. Servers listening on open ports are 314 generally discoverable via a brute-force port scan anyway; DNS-Based 315 Service Discovery makes access to these services easier for 316 legitimate users. 318 8. Informative References 320 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 321 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 322 . 324 [RFC1035] Mockapetris, P., "Domain names - implementation and 325 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 326 November 1987, . 328 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 329 to Replace the AppleTalk Name Binding Protocol (NBP)", 330 RFC 6760, DOI 10.17487/RFC6760, February 2013, 331 . 333 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 334 DOI 10.17487/RFC6762, February 2013, 335 . 337 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 338 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 339 . 341 [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- 342 cheshire-dnssd-roadmap-00 (work in progress), July 2017. 344 [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 345 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 346 progress), March 2017. 348 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 349 draft-ietf-dnssd-push-12 (work in progress), July 2017. 351 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 352 Networking: The Definitive Guide", O'Reilly Media, Inc. , 353 ISBN 0-596-10100-7, December 2005. 355 Authors' Addresses 357 Stuart Cheshire 358 Apple Inc. 359 1 Infinite Loop 360 Cupertino, California 95014 361 USA 363 Phone: +1 408 974 3207 364 Email: cheshire@apple.com 366 Ted Lemon 367 Nominum, Inc. 368 800 Bridge Parkway 369 Redwood City, California 94065 370 United States of America 372 Phone: +1 650 381 6000 373 Email: ted.lemon@nominum.com