idnits 2.17.1 draft-cheshire-dnssd-roadmap-03.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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. 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.) == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '74' on line 582 == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-08 == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-01 == Outdated reference: A later version (-03) exists of draft-sekar-dns-ul-01 == Outdated reference: A later version (-20) exists of draft-ietf-dnsop-session-signal-07 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-14 == Outdated reference: A later version (-02) exists of draft-sctl-service-registration-00 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 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 October 23, 2018 5 Expires: April 26, 2019 7 Service Discovery Road Map 8 draft-cheshire-dnssd-roadmap-03 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 related but separate 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 https://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 April 26, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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 (https://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]. 55 Over the course of several years, a rich collection of technologies 56 has developed around DNS-Based Service Discovery. These various 57 related but separate 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. Namespace of Service Types 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, the 77 client and server need to have a common language to describe what 78 they need and what they offer. They need to use the same namespace 79 of service types, otherwise they may actually speak the same 80 application protocol over the air or on the wire, and may in fact be 81 completely compatible, and yet may be unable to detect this because 82 they are using different names to refer to the same actual service. 83 Hence, having a consistent namespace of service types is the 84 essential prerequisite for any useful service discovery. 86 IANA manages the registry of Service Types [RFC6335][STR]. This 87 registry of Service Types can (and should) be used in any service 88 discovery protocol as the vocabulary for describing *all* IP-based 89 services, not only DNS-Based Service Discovery [RFC6763]. 91 In this document we focus on the use of the IANA Service Type 92 Registry [STR] in conjunction with DNS-Based Service Discovery, 93 though that should not be taken in any way to imply any criticism of 94 other service discovery protocols sharing the same namespace of 95 service types. In different circumstances different Service 96 Discovery protocols are appropriate. 98 For example, for service discovery of services potentially available 99 via a Wi-Fi access point, prior to association with that Wi-Fi access 100 point, when no IP communication has yet been established, a service 101 discovery protocol may use raw 802.11 frames, not necessarily IP, 102 UDP, or DNS-formatted messages. For Service Discovery using peer-to- 103 peer Wi-Fi technologies, without any Wi-Fi access point at all, it 104 may also be preferable to use raw 802.11 frames instead of IP, UDP, 105 or DNS-formatted messages. Service Discovery using IEEE 802.15.4 106 radios may use yet another over-the-air protocol. What is important 107 is that they all share the same vocabulary to describe all IP-based 108 services. Using the same service type vocabulary means that client 109 and server software, using agnostic APIs to consume and offer 110 services on the network, has a common language to identify those 111 services, independent of the medium or the particular service 112 discovery protocol in use on that medium. Just as TCP/IP runs on 113 many different link layers, and the concept of using an IP address to 114 identify a particular peer is consistent across many different link 115 layers, the concept of using a name from the IANA Service Type 116 Registry to identify a particular service type also needs to be 117 consistent across all IP-supporting link layers. 119 Originally, the IANA Service Type Registry [RFC6335][STR] used the 120 term "Service Name" rather than "Service Type". Later it became 121 clear that this term could be ambiguous. For a given service 122 instance on the network, there is the machine-visible name of the 123 type of service it provides, and the human-visible name of the 124 particular instance of that type of service. For clarity, this 125 document and related specifications use the term "Service Type" to 126 denote the machine-visible name of the type of service, and the term 127 "Instance Name" to denote the human-visible name of a particular 128 instance. 130 3. Service Discovery Operational Model 132 The original DNS-Based Service Discovery specification [RFC6763] used 133 the terms "register" (advertise a service), "browse" (discover 134 service instances), and "resolve" (get IP address and port for a 135 specific service instance). This terminology is reflective of the 136 thinking at the time, which viewed service discovery as a new and 137 separate step, added to existing networking code. For example, a 138 server would first open a listening socket as it always had, and then 139 "register" that listening socket with the service discovery engine. 140 Similarly, a client would first "resolve" a service instance to an IP 141 address and port, and then, having done that, "connect" to that IP 142 address and port. 144 More recent thinking in this area [RFC8305] has come to the 145 conclusion that it is preferable wherever possible to insulate 146 application software from networking details like having to decide 147 between IPv4 and IPv6, having to decide among multiple IP addresses 148 of either or both address families, and having to decide among 149 multiple available network interfaces. Consequently this document 150 and related specifications adopt newer terminology as follows: 152 1. Offer 153 2. Enumerate 154 3. Use 156 The first step, "Offer", is when a server is offering a service using 157 some application-layer protocol, on a listening TCP or UDP (or other 158 transport protocol) port, and wishes to make that known to other 159 devices. This encompasses both making a listening socket (or the 160 equivalent concept in whatever underlying networking API is being 161 used) and advertising the existence of that listening socket via a 162 service discovery mechanism. 164 The second step, "Enumerate", is when a client device wishes to 165 perform some action, but does not yet know which particular service 166 instance will be used to perform that action. For example, when a 167 user taps the "AirPrint" button on an iPhone or iPad, the iPhone or 168 iPad knows that the user wishes to print, but not which particular 169 printer to use. The desired *function* is known (IPP printing), but 170 not the particular instance. In this case, the client device needs 171 to enumerate the list of available service instances that are able to 172 perform the desired task. In some cases this list of service 173 instances is presented to a human user to choose from; in some cases 174 it is software that examines the list of available service instances 175 and determines the best one to use. This second step is the 176 operation that was called "browsing" in the original specifications. 178 The third step, "Use", is when particular service instance has been 179 selected, and the client wants to make use of that service instance. 180 This encompasses both the "resolve" step (finding IP address(es) and 181 port(s) for the service instance) and the subsequent steps to 182 establish communication with it, which may include details like 183 address family selection, interface selection, transport protocol 184 selection, etc. Ideally, application-layer code should never be 185 exposed to IP addresses at all, just as application-layer code today 186 is generally not exposed to details like MAC addresses [RFC8305]. 188 The second and third steps are intentionally separate. In the second 189 step, a limited amount of information (typically just the name) is 190 requested about a large number of service instances. In the third 191 step more detailed information (e.g, target host IP address, port 192 number, etc.) is requested about one specific service instance. 193 Requesting all the detailed information about all available service 194 instances would be inefficient and wasteful on the network. If the 195 information about services on the network is imagined as a table, 196 then the second step is requesting just one column from that table 197 (the name column) and the third step is requesting just one row from 198 that table (the information pertaining to just one named service 199 instance). 201 To give a concrete example, clicking the "+" button in the printer 202 settings on macOS is an operation performing the second step. It is 203 requesting the names of all available printers. Depending on the 204 specific use case, this step may be performed only rarely. For 205 example, a user may do this just one once, the first time they 206 configure their computer to use their preferred printer, and never 207 again. 209 Once a desired printer has been chosen and configured, subsequent 210 printing of documents is an operation performing the third step. 211 This step may be done frequently, perhaps multiple times per day. 212 This third step is important because, in a world of DHCP, IPv6 213 Stateless Autoconfiguration, and similar dynamic address allocation 214 schemes, a printer's IP address could change from day to day, and to 215 use the printer, its current address must be known. However, this 216 third step need not be performed for every printer on the network, 217 just the specific printer that is about to be used. Also, it is not 218 necessary to repeat the second step again, learning the names of 219 every printer on the network, if the client device already knows the 220 name of the printer it intends to use. 222 DNS-Based Service Discovery [RFC6763] implements these three 223 principal service discovery operations using DNS records and queries, 224 either using Multicast DNS [RFC6762] (for queries limited to the 225 local link) or conventional unicast DNS [RFC1034] [RFC1035] (for 226 queries beyond the local link). 228 Other service discovery protocol achieve the same semantics using 229 different packet formats and mechanisms. 231 One incidental benefit of using DNS as the foundation layer for 232 service discovery, in cases where that makes sense, is that both 233 Multicast DNS and conventional unicast DNS are also used provide name 234 resolution (mapping host names to IP addresses). There is some 235 efficiency and code reuse gained by using the same underlying 236 protocol for both service discovery and naming. 238 A final requirement is that the service discovery protocol should not 239 only perform discovery at a single moment in time, but should also 240 provide ongoing change notification (sometimes called "Publish & 241 Subscribe"). Clients need to be notified in a timely fashion when 242 new data of interest appears, when data of interest changes, and, 243 equally importantly, when data of interest goes away ("goodbye 244 packets"). Without support for ongoing change notification, clients 245 would be forced to resort to polling to keep data up to date, which 246 is inefficient and wasteful on the network. 248 Multicast DNS [RFC6762] implicitly includes change notification by 249 virtue of announcing record creation, update, and deletion, via IP 250 Multicast, which allows these changes to be seen by all peers on the 251 same link (i.e., same broadcast domain). 253 Conventional unicast DNS [RFC1034] [RFC1035] has historically not had 254 broad support for change notification. This capability is added via 255 the new mechanism for DNS Push Notifications [Push]. 257 When using DNS-Based Service Discovery [RFC6763] there are two 258 aspects to consider: firstly how the clients determine the 259 appropriate DNS names to query (and what query mechanisms to use) and 260 secondly how the relevant information got into the DNS namespace in 261 the first place, so as to be available when clients query for it. 263 The available namespaces are discussed broadly in Section 4 below. 264 Client operation is then discussed in detail in Section 5, and server 265 operation is discussed in detail in Section 6. 267 4. Service Discovery Namespace 269 When used with Multicast DNS [RFC6762] Service Discovery queries 270 necessarily use the ".local" parent domain reserved for this purpose 271 [SUDN]. 273 When used with conventional unicast DNS [RFC1034] [RFC1035] some 274 other domain must be used. 276 For individuals and organizations with a globally-unique domain name 277 registered to them, their globally-unique domain name, or a subdomain 278 of it, can be used for service discovery. 280 However, it would be convenient for advanced service discovery to be 281 available even to people who haven't taken the step of registering 282 and paying annually for a globally-unique domain name. For these 283 people it would be useful if devices arrived preconfigured with some 284 suitable factory-default service discovery domain, such as 285 "services.home.arpa" [RFC8375]. Services published in this factory- 286 default service discovery domain are not globally unique or globally 287 resolvable, but they can have scope larger than the single link 288 provided by Multicast DNS. 290 5. Client Configuration and Operation 292 When using DNS-Based Service Discovery [RFC6763], clients have to 293 choose what DNS names to query. 295 When used with Multicast DNS [RFC6762] on the local link, queries are 296 necessarily performed in the ".local" parent domain reserved for this 297 purpose [SUDN]. 299 For discovery beyond the local link, a unicast DNS domain must be 300 used. This unicast DNS domain can be configured manually by the 301 user, or it can be learned dynamically from the network (as has been 302 done for many years at IETF meetings to facilitate discovery of the 303 IETF Terminal Room printer, from outside the IETF Terminal Room). In 304 the DNS-SD specification [RFC6763] section 11, "Discovery of Browsing 305 and Registration Domains (Domain Enumeration)", describes how a 306 client device learns one or more recommended service discovery 307 domains from the network, using the special "lb._dns-sd._udp" query. 308 All of the details from that specification are not repeated here. 309 A walk-through describing one real-world example of how this works, 310 using discovery of the IETF Terminal Room printer as a specific 311 concrete case study, is given in Appendix A. 313 Given the service type that the user or client device is seeking (see 314 Section 2) and one or more service discovery domains to look in, the 315 client then sends its DNS queries, and processes the responses. 317 For some uses, one-shot conventional DNS queries and responses are 318 perfectly adequate, but for service discovery, where a list may be 319 displayed on a screen for a user to see, it is desirable to keep that 320 list up to date without the user having to repeatedly tap a "refresh" 321 button, and without the software repeatedly polling the network on 322 the user's behalf. 324 And early solution to provide asynchronous change notifications for 325 unicast DNS was the UDP-based protocol DNS Long-Lived Queries 326 [DNS-LLQ]. This was used, among other things, by Apple's Back to My 327 Mac Service [RFC6281] introduced in Mac OS X 10.5 Leopard in 2007. 329 A decade of operational experience has shown that an asynchronous 330 change notification protocol built on TCP is preferable for a variety 331 of reasons, so the IETF is has developed DNS Push Notifications 332 [Push]. 334 Because DNS Push Notifications is built on top of a DNS TCP 335 connection, DNS Push Notifications adopts the conventions specified 336 by DNS Stateful Operations [DSO] rather than inventing its own 337 session management mechanisms. 339 6. Server Configuration and Operation 341 Section 5 above describes how clients perform their queries. The 342 related question is how the relevant information got into the DNS 343 namespace in the first place, so as to be available when clients 344 query for it. 346 One trivial way that relevant service discovery information can get 347 into the DNS namespace is simply via manual configuration, creating 348 the necessary PTR, SRV and TXT records [RFC6763] by hand, and indeed 349 this is how the IETF Terminal Room printer has been advertised to 350 IETF meeting attendees for many years. While this is easy for the 351 experienced network operators at the IETF, it can be onerous to 352 others less familiar with how to set up DNS-SD records. 354 Hence it would be convenient to automate this process of populating 355 the DNS namespace with relevant service discovery information. Two 356 efforts are underway to address this need, the Service Discovery 357 Proxy [DisProx] (see Section 6.1) and the Service Registration 358 Protocol [RegProt] (see Section 6.4). 360 6.1. Service Discovery Proxy 362 The first technique in the direction of automatically populating the 363 DNS namespace is the Service Discovery Proxy [DisProx]. This 364 technology works with today's existing devices that advertise 365 services using Multicast DNS only (such as almost all network 366 printers sold in the last decade). A Service Discovery Proxy is a 367 device with a presence on the same link as the devices we wish to be 368 able to discover from afar. A remote client sends unicast queries to 369 the Discovery Proxy, which performs local Multicast DNS queries on 370 behalf of the remote client, and then sends back the answers it 371 discovers. 373 Because the time it takes to receive Multicast DNS responses is 374 uncertain, this mechanism benefits from being able to deliver 375 asynchronous change notifications as new answers come in, using DNS 376 Long-Lived Queries [DNS-LLQ] or the newer DNS Push Notifications 377 [Push] on top of DNS Stateful Operations [DSO]. 379 6.2. Multicast DNS Discovery Relay 381 As an alternative to having to be physically connected to the desired 382 network link, a Service Discovery Proxy [DisProx] can use a Multicast 383 DNS Discovery Relay [Relay] to give it a 'virtual' presence on a 384 remote link. Indeed, when using Discovery Relays, a single Discovery 385 Proxy can have a 'virtual' presence on hundreds of remote links. A 386 single Discovery Proxy in the data center can serve the needs of an 387 entire enterprise. This is modeled after the DHCP protocol. In 388 simple residential scenarios the DHCP server resides in the home 389 gateway, which is physically attached to the (single) local link. In 390 complex enterprise networks, it is common to have a single 391 centralized DHCP server, which resides in the data center and 392 communicates with a multitude of simple lightweight BOOTP relay 393 agents, implemented in the routers on each physical link. 395 6.3. Service Discovery Broker 397 Finally, when clients are communicating with multiple Service 398 Discovery Proxies at the same time, this can be burdensome for the 399 clients (which may be mobile and battery powered) and for the Service 400 Discovery Proxies (which may have to serve hundreds of clients). 401 This situation is remedied by use of a Service Discovery Broker 402 [Broker]. A Service Discovery Broker is an intermediary between 403 client and server. A client can issue a single query to the Service 404 Discovery Broker and have the Service Discovery Broker do the hard 405 work of issuing multiple queries on behalf of the client. And a 406 Service Discovery Broker can shield a Service Discovery Proxy from 407 excessive load by collapsing multiple duplicate queries from 408 different client down to a single query to the Service Discovery 409 Proxy. 411 6.4. Service Registration Protocol 413 The second technique in the direction of automatically populating the 414 DNS namespace is the Service Registration Protocol [RegProt]. This 415 technology is designed to enable future devices that will explicitly 416 cooperate with the network infrastructure to advertise their 417 services. 419 The Service Registration Protocol is effectively DNS Update, with 420 some minor additions. 422 One addition to the basic DNS Update protocol is the introduction of 423 a lifetime on DNS Updates, using the Dynamic DNS Update Lease EDNS(0) 424 option [DNS-UL]. This option has similar semantics to a DHCP address 425 lease, where a device is granted an address with with a certain DHCP 426 lease lifetime, and if the device fails to renew the DHCP lease 427 before it expires then the address will be reclaimed and become 428 available to be allocated to a different device. In cases where DHCP 429 is being used for address assignment, a device will generally request 430 a DNS Update Lease with the same expiration time as its DHCP address 431 lease. This way, if the device is abruptly disconnected from the 432 network, around the same time as its address gets reclaimed its DNS 433 records will also be garbage collected. 435 The second addition to the basic DNS Update protocol is the 436 introduction of information, carried using the EDNS(0) OWNER Option 437 [Owner], that tells the Service Registration server that the device 438 will be going to sleep to save power, and how the Service 439 Registration server can wake it up again on demand when needed. The 440 use of power management information in the Service Registration 441 messages allows devices to sleep to save power, which is especially 442 beneficial for battery-powered devices in the home. 444 The use of an explicit Service Registration Protocol is beneficial in 445 networks where multicast is expensive, inefficient, or outright 446 blocked, such as many Wi-Fi networks. An explicit Service 447 Registration Protocol is also beneficial in networks where multicast 448 and broadcast are supported poorly, if at all, such as some mesh 449 networks. 451 7. Security Considerations 453 As an informational document, this document introduces no new 454 Security Considerations of its own. The various referenced documents 455 each describe their own relevant Security Considerations as 456 appropriate. 458 8. Informative References 460 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 461 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 462 . 464 [RFC1035] Mockapetris, P., "Domain names - implementation and 465 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 466 November 1987, . 468 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 469 "Understanding Apple's Back to My Mac (BTMM) Service", 470 RFC 6281, DOI 10.17487/RFC6281, June 2011, 471 . 473 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 474 Cheshire, "Internet Assigned Numbers Authority (IANA) 475 Procedures for the Management of the Service Name and 476 Transport Protocol Port Number Registry", BCP 165, 477 RFC 6335, DOI 10.17487/RFC6335, August 2011, 478 . 480 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 481 to Replace the AppleTalk Name Binding Protocol (NBP)", 482 RFC 6760, DOI 10.17487/RFC6760, February 2013, 483 . 485 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 486 DOI 10.17487/RFC6762, February 2013, 487 . 489 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 490 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 491 . 493 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 494 Better Connectivity Using Concurrency", RFC 8305, 495 DOI 10.17487/RFC8305, December 2017, 496 . 498 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 499 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, 500 . 502 [Broker] Cheshire, S. and T. Lemon, "Service Discovery Broker", 503 drdraft-sctl-discovery-broker-00 (work in progress), July 504 2017. 506 [DisProx] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 507 Service Discovery", draft-ietf-dnssd-hybrid-08 (work in 508 progress), March 2018. 510 [DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", draft-sekar-dns- 511 llq-01 (work in progress), August 2006. 513 [DNS-UL] Sekar, K., "Dynamic DNS Update Leases", draft-sekar-dns- 514 ul-01 (work in progress), August 2006. 516 [DSO] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 517 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 518 draft-ietf-dnsop-session-signal-07 (work in progress), 519 March 2018. 521 [Owner] Cheshire, S. and M. Krochmal, "EDNS0 OWNER Option", draft- 522 cheshire-edns0-owner-option-01 (work in progress), July 523 2017. 525 [Push] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 526 draft-ietf-dnssd-push-14 (work in progress), March 2018. 528 [RegProt] Cheshire, S. and T. Lemon, "Service Registration Protocol 529 for DNS-Based Service Discovery", draft-sctl-service- 530 registration-00 (work in progress), July 2017. 532 [Relay] Cheshire, S. and T. Lemon, "Multicast DNS Discovery 533 Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress), 534 March 2018. 536 [STR] "Service Name and Transport Protocol Port Number 537 Registry", . 540 [SUDN] "Special-Use Domain Names Registry", 541 . 544 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 545 Networking: The Definitive Guide", O'Reilly Media, Inc. , 546 ISBN 0-596-10100-7, December 2005. 548 Appendix A. IETF Terminal Room Printer Discovery Walk-Through 550 For about a decade now, the talented IETF network staff have provided 551 off-link DNS Service Discovery for the Terminal Room printer at IETF 552 meetings three times a year. In the case of the IETF meetings the 553 necessary DNS records are entered manually, whereas this document 554 advocates for increased automation of that task, but either way the 555 process by which clients query to discover services is the same. 557 This appendix gives a detailed step-by step account of how this 558 client query process works. It starts with a client joining the Wi- 559 Fi network and doing a DHCP request, and ends with paper coming out 560 of the printer. The reason the explanation is gives the specific 561 details of every step is to avoid inadvertently having a hand-waving 562 "and then a miracle occurs" part, which misses out some important 563 detail. And one of the reasons for asking the IETF network team to 564 set this up for IETF meetings is that operational use is an important 565 reality check. When standing in front of a room, giving a 566 presentation, if you miss out some vital step, people may not notice. 567 When running an actual service used by actual people, if you miss out 568 some vital step, no paper comes out of the printer, and everyone 569 notices. 571 Using a macOS computer, at an IETF meeting, you can repeat the steps 572 illustrated here to see exactly how it works. Or you can simply 573 press Cmd-P in any application and see that "term-printer" appears as 574 an available printer, to confirm that it does in fact work. 576 First, let's see what the macOS computer learned from the local DHCP 577 server: 579 % scutil 580 > list 581 ... 582 subKey [74] = State:/Network/Service/21B5304C...54B28F4CA1D2/DHCP 583 ... 585 > show State:/Network/Service/21B5304C...54B28F4CA1D2/DHCP 586 { 587 Option_15 : 0x6d656574696e672e696574662e6f7267 588 ... 589 } 591 Option_15 is Domain Name. To see what domain name, we need to decode 592 the hexadecimal data to ASCII. 594 % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p 595 meeting.ietf.org 597 A.1. Domain Enumeration using PTR queries 599 Our DHCP domain name is meeting.ietf.org. Does meeting.ietf.org 600 recommend that we look in any Wide Area Service Discovery domains? 601 This step is called Domain Enumeration [RFC6763], and is performed 602 using a DNS PTR query for a name with the special prefix "lb._dns- 603 sd._udp": 605 % dig lb._dns-sd._udp.meeting.ietf.org. ptr 607 ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr 608 ;; global options: +cmd 609 ;; Got answer: 610 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624 611 ;; flags: qr aa rd ra; 612 QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 614 ;; QUESTION SECTION: 615 ;lb._dns-sd._udp.meeting.ietf.org. IN PTR 617 ;; ANSWER SECTION: 618 lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR meeting.ietf.org. 620 ... 622 ;; Query time: 8 msec 623 ;; SERVER: 130.129.5.6#53(130.129.5.6) 624 ;; WHEN: Wed Mar 13 10:16:40 2013 625 ;; MSG SIZE rcvd: 188 627 In the middle there in the Answer Section you'll see that the answer 628 to the PTR query is "meeting.ietf.org". In this case the answer is 629 self-referential -- "meeting.ietf.org" is inviting us to look for 630 services in "meeting.ietf.org", but the PTR record(s) could equally 631 well point at any other domain, such as "services.ietf.org", or 632 anything else. 634 Note that this answer does not depend on the client device being "on" 635 the IETF meeting network, which is in any case a loosely defined 636 concept at best. Nor does it depend on sending the DNS query to a 637 DNS server that is "on" the IETF meeting network. Any capable DNS 638 recursive resolver anywhere on the planet will give the same answer. 639 We can test this by sending the same DNS PTR query to Google's 640 8.8.8.8 public resolver: 642 % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr 644 ; <<>> DiG 9.6-ESV-R4-P3 <<>> 645 @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr 646 ; (1 server found) 647 ;; global options: +cmd 648 ;; Got answer: 649 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571 650 ;; flags: qr rd ra; QUERY:1, ANSWER:1, AUTHORITY:0, ADDITIONAL:0 652 ;; QUESTION SECTION: 653 ;lb._dns-sd._udp.meeting.ietf.org. IN PTR 655 ;; ANSWER SECTION: 656 lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR meeting.ietf.org. 658 ;; Query time: 21 msec 659 ;; SERVER: 8.8.8.8#53(8.8.8.8) 660 ;; WHEN: Wed Mar 13 10:18:27 2013 661 ;; MSG SIZE rcvd: 64 663 In the Answer Section you'll see that the answer is still 664 "meeting.ietf.org". 666 In this example, this particular test was done at the 86th IETF in 667 Orlando, Florida, in March 2013. The Google 8.8.8.8 public resolver 668 still gave the correct answer, even though it was 13 hops away: 670 % traceroute -q 1 8.8.8.8 671 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets 672 1 rtra (130.129.80.2) 1.369 ms 673 2 75-112-170-148.net.bhntampa.com (75.112.170.148) 14.494 ms 674 3 bun2.tamp20-car1.bhn.net (71.44.3.73) 19.558 ms 675 4 hun0-0-0-0-tamp20-cbr1.bhn.net (72.31.117.156) 20.730 ms 676 5 xe-8-2-0.bar1.tampa1.level3.net (4.53.172.9) 13.052 ms 677 6 ae-5-5.ebr1.miami1.level3.net (4.69.148.213) 27.413 ms 678 7 ae-1-51.edge1.miami2.level3.net (4.69.138.75) 15.552 ms 679 8 google-inc.edge1.miami2.level3.net (4.59.240.26) 48.852 ms 680 9 209.85.253.118 (209.85.253.118) 21.118 ms 681 10 216.239.48.192 (216.239.48.192) 21.890 ms 682 11 216.239.48.192 (216.239.48.192) 23.221 ms 683 12 * 684 13 google-public-dns-a.google.com (8.8.8.8) 32.961 ms 686 For the rest of this example we use the Google 8.8.8.8 public 687 resolver for all the queries. 689 In the case of IETF meetings the PTR is self-referential -- 690 meeting.ietf.org is advising us to look in meeting.ietf.org, but it 691 could easily be set up to direct us elsewhere. However, since it's 692 suggesting we look for services in meeting.ietf.org, we'll do that. 694 A.2. Instance Enumeration using PTR queries on a macOS computer 696 Once one or more service discovery domains have been determined, the 697 client then looks for instances of the desired service type. This 698 step is called Instance Enumeration and is also performed using a DNS 699 PTR queries, using a name with a prefix indicating the type of 700 service that is being sought. 702 A macOS computer with appropriate printer drivers installed will look 703 for instances of the service type "_pdl-datastream._tcp" in the 704 domain "meeting.ietf.org", as shown below. This is typically 705 performed just once, the first time the macOS computer is set up to 706 use that printer. 708 % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr 709 term-printer._pdl-datastream._tcp.meeting.ietf.org. 711 There's one printing service available here, called "term-printer". 712 That's what you see when you press the "+" button in the Print & Fax 713 Preference Pane on macOS. 715 A.3. Printing from a macOS computer 717 When the user actually prints something, macOS sends a DNS SRV query 718 for the printer name learned in the previous Instance Enumeration 719 step, to learn the target host and port for the service. This DNS 720 SRV query is then followed by address queries for the target host's 721 IPv4 and/or IPv6 addresses. The necessary address records are 722 usually included in the Additional Section of the reply to the SRV 723 query, so that these address queries can be answered from the local 724 cache, without resulting in additional packets over the air. 726 % dig +short @8.8.8.8 \ 727 term-printer._pdl-datastream._tcp.meeting.ietf.org. srv 728 0 0 9100 term-printer.meeting.ietf.org. 730 % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA 731 2001:df8::48:200:74ff:fee0:6cf8 733 This tells the computer that to use this printer, it must connect to 734 [2001:df8::48:200:74ff:fee0:6cf8]:9100, using the installed printer 735 driver, which speaks the appropriate vendor-specific printing 736 protocol for that printer. 738 A.4. Instance Enumeration using PTR queries on an iOS device 740 Printing from an iPhone or iPad is similar, except there are no 741 vendor-specific printer drivers installed. Instead, printing from an 742 iPhone or iPad uses the IETF Standard IPP printing protocol, using an 743 IPP printer that supports at least URF (Universal Raster Format). 744 Consequently, the iOS device sends its Instance Enumeration DNS PTR 745 queries using the prefix "_universal._sub._ipp._tcp" to indicate that 746 it is looking for the subset of IPP printers that support Universal 747 Raster Format. 749 % dig +short @8.8.8.8 \ 750 _universal._sub._ipp._tcp.meeting.ietf.org. ptr 751 term-printer._ipp._tcp.meeting.ietf.org. 753 An iPhone or iPad will discover that there's one URF-capable IPP- 754 based printing service available here, called "term-printer". It has 755 the same name as the pdl-datastream printing service, and exists on 756 the same physical hardware, but uses a different printing protocol. 758 A.5. Printing from an iOS device 760 When the user prints from their iPhone or iPad using AirPrint, iOS 761 does these DNS SRV and address queries: 763 % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv 764 0 0 631 term-printer.meeting.ietf.org. 766 % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa 767 2001:df8::48:200:74ff:fee0:6cf8 769 Note that the "_ipp._tcp" service has the same target hostname and 770 IPv6 address as the "_pdl-datastream" service from the macOS example, 771 but is accessed at a different TCP port on that hardware device. 773 To use this printer, the iPhone or iPad connects to 774 [2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print. 776 Author's Address 778 Stuart Cheshire 779 Apple Inc. 780 1 Infinite Loop 781 Cupertino, California 95014 782 USA 784 Phone: +1 408 974 3207 785 Email: cheshire@apple.com