idnits 2.17.1 draft-cheshire-dnssd-roadmap-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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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 2489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC6763' on line 389 looks like a reference -- Missing reference section? 'RFC6760' on line 380 looks like a reference -- Missing reference section? 'ZC' on line 446 looks like a reference -- Missing reference section? 'Roadmap' on line 423 looks like a reference -- Missing reference section? 'RFC6335' on line 393 looks like a reference -- Missing reference section? 'SN' on line 442 looks like a reference -- Missing reference section? 'RFC6762' on line 385 looks like a reference -- Missing reference section? 'RFC1034' on line 367 looks like a reference -- Missing reference section? 'RFC1035' on line 371 looks like a reference -- Missing reference section? 'Push' on line 409 looks like a reference -- Missing reference section? 'I-D.ietf-homenet-dot' on line 400 looks like a reference -- Missing reference section? 'DNS-LLQ' on line 420 looks like a reference -- Missing reference section? 'RFC6281' on line 375 looks like a reference -- Missing reference section? 'S-Sig' on line 412 looks like a reference -- Missing reference section? 'DisProx' on line 405 looks like a reference -- Missing reference section? 'RegProt' on line 430 looks like a reference -- Missing reference section? 'Relay' on line 434 looks like a reference -- Missing reference section? 'Broker' on line 438 looks like a reference -- Missing reference section? 'DNS-UL' on line 417 looks like a reference -- Missing reference section? 'Owner' on line 426 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 21 comments (--). 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 July 2, 2017 5 Expires: January 3, 2018 7 Service Discovery Road Map 8 draft-cheshire-dnssd-roadmap-00 10 Abstract 12 Over the course of several years, a rich collection of technologies 13 has developed around DNS-Based Service Discovery, described across 14 multiple documents. This "Road Map" document gives an overview of 15 how these separate but related technologies (and their documents) fit 16 together, to facilitate Service Discovery in various environments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2018. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Road Map 52 DNS-Based Service Discovery [RFC6763] is a component of Zero 53 Configuration Networking [RFC6760] [ZC] [Roadmap]. 55 Over the course of several years, a rich collection of technologies 56 has developed around DNS-Based Service Discovery. These various 57 separate but related technologies are described across multiple 58 documents. This "Road Map" document gives an overview of how these 59 technologies (and their documents) fit together to facilitate Service 60 Discovery across a broad range of operating environments, from small 61 scale zero-configuration networks to large scale administered 62 networks, from local area to wide area, and from low-speed wireless 63 links in the kb/s range to high-speed wired links operating at 64 multiple Gb/s. 66 Not all of the available components are necessary or appropriate in 67 all scenarios. One goal of this "Road Map" document is to provide 68 guidance about which components to use depending on the problem being 69 solved. 71 2. Service Type Namespace 73 The single most important concept in Service Discovery is the 74 namespace specifying how different service types are identified. 75 This is how a client communicates what it needs, and how a server 76 communicates what it offers. For a client to discover a server, 77 client and server need to use the same namespace of service types, 78 otherwise they may actually speak the same application protocol over 79 the air or on the wire, and may in fact be completely compatible, and 80 yet may be unable to detect this because they are using different 81 names to refer to the same actual service. Hence, having a 82 consistent namespace for referring to service types is vital. 84 IANA manages the registry of Service Types [RFC6335][SN]. This 85 registry of Service Types can (and should) be used in any Service 86 Discovery protocol as the vocabulary for describing *all* IP-based 87 services, not only DNS-Based Service Discovery [RFC6763]. 89 In this document we focus on the use of the IANA Service Type 90 Registry [SN] in conjunction with DNS-Based Service Discovery, though 91 that should not be taken in any way to imply any criticism of other 92 Service Discovery protocols sharing the same namespace of service 93 types. In different circumstances different Service Discovery 94 protocols are appropriate. 96 For example, for Service Discovery of services potentially available 97 via a Wi-Fi access point, prior to association with that Wi-Fi access 98 point, when no IP link has yet been established, a Service Discovery 99 protocol may use raw 802.11 frames, not necessarily IP, UDP, or DNS- 100 formatted messages. For Service Discovery using peer-to-peer Wi-Fi 101 technologies, without any Wi-Fi access point at all, it may also be 102 preferable to use raw 802.11 frames instead of IP, UDP, or DNS- 103 formatted messages. Service Discovery using IEEE 802.15.4 radios may 104 use yet another over-the-air protocol. What is important is that 105 they all share the same vocabulary to describe all IP-based services, 106 so that client and server software, using agnostic APIs to consume 107 and offer services on the network, has a common language to identify 108 those services, independent of the medium or the particular Service 109 Discovery protocol in use on that medium. Just as TCP/IP runs on 110 many different link layers, and the concept of using an IP address to 111 identify a particular peer is consistent across many different link 112 layers, the concept of using a name from the IANA Service Type 113 Registry to identify a particular service type also needs to be 114 consistent across all IP-supporting link layers. 116 3. Service Discovery Operational Model 118 The three principal Service Discovery operations utilizing service 119 types in the IANA Service Type Registry [SN] are: 121 1. Offer 122 2. Discover/Enumerate 123 3. Use 125 The first step, "Offer", is when a server is offering a service using 126 some application-layer protocol on a listening TCP or UDP (or other 127 transport protocol) port, and wishes to make that known to other 128 devices. 130 The second step, "Discover", sometimes called, "Enumerate", is when a 131 client device wishes to perform some action, but does not yet know 132 which particular service instance will be used to perform that 133 action. For example, when a user taps the "AirPrint" button on an 134 iPhone, the iPhone knows that the user wishes to print, but not which 135 particular printer to use. The desired *function* is known (IPP 136 printing), but not the particular instance. In this case, the client 137 device needs to enumerate the list of available service instances 138 that are able to perform the desired task. In most cases this list 139 of service instances is presented to a human user to choose from; in 140 some cases it is software that examines the list of available service 141 instances and determines the best one to use. 143 The third step, "Use", is when particular service instance has been 144 selected, and the client wants to make use of that service instance, 145 by opening a TCP connection to it or by sending UDP datagrams. 147 The second and third steps are intentionally separate. In the second 148 step, a limited amount of information (typically just the name) is 149 requested about a large number of service instances. In the third 150 step more detailed information (e.g, target host IP address, port 151 number, etc.) is requested about one specific service instance. 152 Requesting all the detailed information about all available service 153 instances would be inefficient and wasteful on the network. If the 154 information about services on the network is imagined as a table, 155 then the second step is requesting just one column from that table 156 (the names) and the third step is requesting just one row from that 157 table (the information pertaining to just one named service 158 instance). 160 To give an example, clicking the "+" button in the printer settings 161 on macOS is an operation performing the second step. It is 162 requesting the names of all available printers. Once a print queue 163 has been configured for the chosen printer, subsequent printing of 164 documents is an operation performing the third step. It only needs 165 to request information about the specific printer in question. It is 166 not necessary to repeatedly discover the list of every printer on the 167 network if the device already knows which one it intends to use. 169 DNS-Based Service Discovery [RFC6763] implements these three 170 principal Service Discovery operations using DNS records and queries, 171 either using Multicast DNS [RFC6762] (for queries limited to the 172 local link) or conventional unicast DNS [RFC1034] [RFC1035] (for 173 queries beyond the local link). 175 Other Service Discovery protocol achieve the same semantics using 176 different packet formats and mechanisms. 178 One incidental benefit of using DNS as the foundation layer is that 179 Multicast DNS and conventional unicast DNS are also used provide name 180 resolution (mapping host names to IP addresses) so there is some 181 efficiency and code reuse in using the same underlying protocol for 182 both naming and service discovery. 184 A final requirement is that the Service Discovery protocol perform 185 not only discovery at a single moment in time, but also ongoing 186 change notification (sometimes called "Publish & Subscribe"). 187 Without support for ongoing change notification, clients would be 188 forced to resort to polling to keep data up to date, which is 189 inefficient and wasteful on the network. 191 Multicast DNS [RFC6762] implicitly includes change notification by 192 virtue of announcing record changes via IP Multicast, which allows 193 these changes to be seen by all peers on the same link (broadcast 194 domain). 196 Conventional unicast DNS [RFC1034] [RFC1035] has historically not had 197 broad support for change notification. This capability is added via 198 the new mechanism for DNS Push Notifications [Push]. 200 When using DNS-Based Service Discovery [RFC6763] there are two 201 aspects to consider: firstly how the clients choose what DNS names to 202 query, and what query mechanisms to use, and secondly how the 203 relevant information got into the DNS namespace in the first place, 204 so as to be available when clients query for it. 206 The available namespaces are discussed below in Section 4. Client 207 operation is discussed in Section 5 and server operation is discussed 208 in Section 6. 210 4. Service Discovery Namespace 212 When used with Multicast DNS [RFC6762] queries are automatically 213 performed in the ".local" parent domain. 215 When used with conventional unicast DNS [RFC1034] [RFC1035] some 216 other domain must be used. 218 For individuals and organizations with a globally-unique domain name 219 registered to them, their globally-unique domain name, or a subdomain 220 of it, can be used for service discovery. 222 However, it would be convenient for capable service discovery to be 223 available even to people who haven't taken the step of registering 224 and paying for a globally-unique domain name. For these people it 225 would be useful if devices arrived preconfigured with some suitable 226 factory-default service discovery domain, such as "services.homenet" 227 [I-D.ietf-homenet-dot]. Services published in this factory-default 228 service discovery domain would not be globally unique or globally 229 resolvable, but they could have scope larger than the single link 230 provided by Multicast DNS. 232 5. Client Configuration and Operation 234 When using DNS-Based Service Discovery [RFC6763], clients have to 235 choose what DNS names to query. 237 When used with Multicast DNS [RFC6762] queries are automatically 238 performed in the ".local" parent domain. 240 For discovery beyond the local link, a unicast DNS domain must be 241 used. This unicast DNS domain can be configured manually by the 242 user, or it can be learned dynamically from the network (as has been 243 done for many years at IETF meetings to facilitate discovery of the 244 IETF Terminal Room printer from outside the IETF Terminal Room 245 network). In the DNS-SD specification [RFC6763] section 11, 246 "Discovery of Browsing and Registration Domains (Domain 247 Enumeration)", describes how a client device learns one or more 248 recommended service discovery domains from the network, using the 249 special "lb._dns-sd._udp" query. 251 Given the service type that the user or client device is seeking (see 252 Section 2) and one or more service discovery domains to look in, the 253 client then sends its DNS queries, and processes the responses. 255 For some uses one-shot conventional DNS queries and responses are 256 perfectly adequate, but for service discovery, where a list may be 257 displayed on a screen for a user to see, it is desirable to keep that 258 list up to date without the user having to repeatedly tap a "refresh" 259 button, and without the software repeatedly polling the network on 260 the user's behalf. 262 And early solution to provide asynchronous change notifications for 263 unicast DNS was the UDP-based protocol DNS Long-Lived Queries 264 [DNS-LLQ]. This was used, among other things, by Apple's Back to My 265 Mac Service [RFC6281] introduced in Mac OS X 10.5 Leopard in 2007. 267 Recent experience has shown that an asynchronous change notification 268 protocol built on TCP would be preferable, so the IETF is now 269 developing DNS Push Notifications [Push]. 271 Because DNS Push Notifications is built on top of a DNS TCP 272 connection, rather than inventing its own session signaling 273 mechanisms, DNS Push Notifications adopts the conventions specified 274 by DNS Session Signaling [S-Sig]. 276 6. Server Configuration and Operation 278 Section 5 above describes how clients perform their queries. The 279 related question is how the relevant information got into the DNS 280 namespace in the first place, so as to be available when clients 281 query for it. 283 One way that relevant service discovery information can get into the 284 DNS namespace is simply via manual configuration, creating the 285 necessary PTR, SRV and TXT records [RFC6763], and indeed this is how 286 the IETF Terminal Room printer has been advertised to IETF meeting 287 attendees for many years. While this is easy for the experienced 288 network operators at the IETF, it can be onerous to others less 289 familiar with how to set up DNS-SD records. 291 Hence it would be convenient to automate this process of populating 292 the DNS namespace with relevant service discovery information. Two 293 efforts are underway to address this need, the Service Discovery 294 Proxy [DisProx] and the Service Registration Protocol [RegProt]. 296 The first effort is the Service Discovery Proxy [DisProx]. This 297 technology is designed to work with today's devices that advertise 298 services using Multicast DNS only (such as almost all network 299 printers sold in the last decade). A Service Discovery Proxy is a 300 device colocated on the same link as the devices we wish to be able 301 to discover from afar. A remote client sends unicast queries to the 302 Discovery Proxy, which performs local Multicast DNS queries on behalf 303 of the remote client, and then sends back the answers it discovers. 305 Because the time it takes to receive Multicast DNS responses is 306 uncertain, this mechanism benefits from being able to deliver 307 asynchronous change notifications as new answers come in, using DNS 308 Long-Lived Queries [DNS-LLQ] or the newer DNS Push Notifications 309 [Push] on top of DNS Session Signaling [S-Sig]. 311 As an alternative to having to be physically connected to the desired 312 network link, a Service Discovery Proxy [DisProx] can use a Multicast 313 DNS Discovery Relay [Relay] to give it a 'virtual' presence on a 314 remote link. Indeed, when using Discovery Relays, a single Discovery 315 Proxy can have a 'virtual' presence on hundreds of remote links. A 316 single Discovery Proxy in the data center can serve the needs of an 317 entire enterprise. This is modeled after the DHCP protocol. In 318 simple residential scenarios the DHCP server resides on the local 319 link. In complex enterprise networks, a single DHCP server resides 320 in the data center, using simple lightweight BOOTP relay agents 321 colocated with the routers on each physical link. 323 Finally, when clients are making TCP connections to multiple Service 324 Discovery Proxies at the same time, this can be burdensome for the 325 clients (which may be mobile and battery powered) and for the the 326 Service Discovery Proxies (which may have to serve hundreds of 327 clients). This situation is remedied by use of a Service Discovery 328 Broker [Broker]. A Service Discovery Broker is an intermediary 329 between client and server. A client can issue a single query to the 330 Service Discovery Broker and have the Service Discovery Broker do the 331 hard work of issuing multiple queries on behalf of the client. And a 332 Service Discovery Broker can shield a Service Discovery Proxy from 333 excessive load by colapsing multiple duplicate queries from different 334 client down to a single query to the Service Discovery Proxy. 336 The second effort in this space, tacking the chalenge of automating 337 the process of populating the DNS namespace with relevant service 338 discovery information, is the Service Registration Protocol 339 [RegProt]. This technology is designed to work with future devices 340 that explicitly cooperate with the network to advertise their 341 services. 343 The Service Registration Protocol is effectively DNS Update, with 344 some minor additions. 346 One addition is the introduction of a lifetime on DNS Updates, using 347 the the Dynamic DNS Update Lease EDNS(0) option [DNS-UL]. 349 The second addition is the introduction of information that tells the 350 Service Registration server that the device will be going to sleep to 351 save power, combined with information specifying how to wake it up 352 again on demand, using the EDNS(0) OWNER Option [Owner]. 354 The use of an explicit Service Registration Protocol is beneficial in 355 networks where multicast is expensive, inefficient, or outright 356 blocked, such as many Wi-Fi networks. An explicit Service 357 Registration Protocol is also beneficial in networks where multicast 358 and broadcast are supported poorly, if at all, such as mesh networks 359 like those using IEEE 802.15.4. 361 The use of power management information in the Service Registration 362 messages allows devices to sleep to save power, which is especially 363 beneficial for battery-powered devices in the home. 365 7. Informative References 367 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 368 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 369 . 371 [RFC1035] Mockapetris, P., "Domain names - implementation and 372 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 373 November 1987, . 375 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 376 "Understanding Apple's Back to My Mac (BTMM) Service", 377 RFC 6281, DOI 10.17487/RFC6281, June 2011, 378 . 380 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 381 to Replace the AppleTalk Name Binding Protocol (NBP)", 382 RFC 6760, DOI 10.17487/RFC6760, February 2013, 383 . 385 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 386 DOI 10.17487/RFC6762, February 2013, 387 . 389 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 390 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 391 . 393 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 394 Cheshire, "Internet Assigned Numbers Authority (IANA) 395 Procedures for the Management of the Service Name and 396 Transport Protocol Port Number Registry", BCP 165, 397 RFC 6335, DOI 10.17487/RFC6335, August 2011, 398 . 400 [I-D.ietf-homenet-dot] 401 Pfister, P. and T. Lemon, "Special Use Domain 402 '.home.arpa'", draft-ietf-homenet-dot-06 (work in 403 progress), June 2017. 405 [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 406 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 407 progress), March 2017. 409 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 410 draft-ietf-dnssd-push-12 (work in progress), July 2017. 412 [S-Sig] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 413 Mankin, A., and T. Pusateri, "DNS Session Signaling", 414 draft-ietf-dnsop-session-signal-03 (work in progress), 415 July 2017. 417 [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 418 ul-01 (work in progress), August 2006. 420 [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 421 llq-01 (work in progress), August 2006. 423 [Roadmap] Cheshire, S., "Service Discovery Road Map", draft- 424 cheshire-dnssd-roadmap-00 (work in progress), July 2017. 426 [Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 427 cheshire-edns0-owner-option-01 (work in progress), July 428 2017. 430 [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol 431 for DNS-Based Service Discovery", draft-sctl-service- 432 registration-00 (work in progress), July 2017. 434 [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 435 Relay", draft-sctl-dnssd-mdns-relay-00 (work in progress), 436 July 2017. 438 [Broker] Cheshire, S. and T. Lemon, "Service Discovery Broker", 439 drdraft-sctl-discovery-broker-00 (work in progress), July 440 2017. 442 [SN] "Service Name and Transport Protocol Port Number 443 Registry", . 446 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 447 Networking: The Definitive Guide", O'Reilly Media, Inc. , 448 ISBN 0-596-10100-7, December 2005. 450 Author's Address 452 Stuart Cheshire 453 Apple Inc. 454 1 Infinite Loop 455 Cupertino, California 95014 456 USA 458 Phone: +1 408 974 3207 459 Email: cheshire@apple.com