idnits 2.17.1 draft-cheshire-dnssd-hybrid-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 22, 2014) is 3744 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-sekar-dns-llq-01 ** Downref: Normative reference to an Informational draft: draft-sekar-dns-llq (ref. 'I-D.sekar-dns-llq') Summary: 1 error (**), 0 flaws (~~), 3 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: Standards Track January 22, 2014 5 Expires: July 26, 2014 7 Hybrid Unicast/Multicast DNS-Based Service Discovery 8 draft-cheshire-dnssd-hybrid-01 10 Abstract 12 Performing DNS-Based Service Discovery using purely link-local 13 Multicast DNS enables discovery of services that are on the local 14 link, but not (without some kind of proxy or similar special support) 15 of services that are outside the local link. Using a very large 16 local link with thousands of hosts improves service discovery, but at 17 the cost of large amounts of multicast traffic. 19 Performing DNS-Based Service Discovery using purely Unicast DNS is 20 more efficient, but requires configuration of DNS Update keys on the 21 devices offering the services, which can be onerous for simple 22 devices like printers and network cameras. 24 Hence a compromise is needed, that provides easy service discovery 25 without requiring either large amounts of multicast traffic or 26 onerous configuration. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 26, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology Used in this Document . . . . . . 3 64 3. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 4 65 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 66 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. Intelectual Property Rights . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 Multicast DNS [RFC6762] and its companion technology DNS-based 79 Service Discovery [RFC6763] were created to provide IP networking 80 with the ease-of-use and autoconfiguration for which AppleTalk was 81 well known [RFC6760] [ZC]. 83 Section 10 ("Populating the DNS with Information") of the DNS-SD 84 specification [RFC6763] discusses possible ways that a service's PTR, 85 SRV, TXT and address records can make their way into the DNS 86 namespace, including manual zone file configuration [RFC1034] 87 [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies. 89 This document specifies a type of proxy called a Hybrid Proxy that 90 uses Multicast DNS [RFC6762] to discover Multicast DNS records on its 91 local link, and makes corresponding DNS records visible in the 92 Unicast DNS namespace. 94 2. Conventions and Terminology Used in this Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in 99 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 101 Multicast DNS works between a hosts on the same link. A set of hosts 102 is considered to be "on the same link", if: 104 o when any host A from that set sends a packet to any other host B 105 in that set, using unicast, multicast, or broadcast, the entire 106 link-layer packet payload arrives unmodified, and 108 o a broadcast sent over that link by any host from that set of hosts 109 can be received by every other host in that set 111 The link-layer *header* may be modified, such as in Token Ring Source 112 Routing [802.5], but not the link-layer *payload*. In particular, if 113 any device forwarding a packet modifies any part of the IP header or 114 IP payload then the packet is no longer considered to be on the same 115 link. This means that the packet may pass through devices such as 116 repeaters, bridges, hubs or switches and still be considered to be on 117 the same link for the purpose of this document, but not through a 118 device such as an IP router that decrements the TTL or otherwise 119 modifies the IP header. 121 3. Hybrid Proxy Operation 123 In its simplest form, each local link in an organization is assigned 124 a unique Unicast DNS domain name, such as "Building 1.example.com." 125 or "4th Floor.Building 1.example.com." (Grouping multiple local 126 links under the same Unicast DNS domain name is to be specified in a 127 future companion document, but for the purposes of this document, 128 assume that each link has its own unique Unicast DNS domain name.) 130 Each link in an organization has a Hybrid Proxy which serves it. 131 This function could be performed by a router on that link, or, with 132 appropriate VLAN configuration, a single Hybrid Proxy could have a 133 logical presence on, and serve as the Hybrid Proxy for, multiple 134 links. In the organization's DNS server, NS records are used to 135 delegate ownership of each defined link name (e.g., "Building 136 1.example.com.") to the Hybrid Proxy which serves that link. 138 Domain Enumeration PTR records [RFC6763] are also created to inform 139 clients of available Device Discovery domains, e.g.,: 141 b._dns-sd._udp.example.com. PTR Building 1.example.com. 142 PTR Building 2.example.com. 143 PTR Building 3.example.com. 144 PTR Building 4.example.com. 146 lb._dns-sd._udp.example.com. PTR Building 1.example.com. 148 When a DNS-SD client issues a Unicast DNS query to discover services 149 in a particular Unicast DNS (e.g., "_printer._tcp.Building 150 1.example.com. PTR ?") the normal DNS delegation mechanism results 151 in that query being served from the delegated authoritative name 152 server for that subdomain, namely the Hybrid Proxy on the link in 153 question. Like a conventional Unicast DNS server, a Hybrid Proxy 154 implements the usual Unicast DNS protocol [RFC1034] [RFC1035] over 155 UDP and TCP. However, unlike a conventional Unicast DNS server that 156 generates answers from the data in its manually-configured zone file, 157 a Hybrid Proxy generates answers by performing a Multicast DNS query 158 (e.g., "_printer._tcp.local. PTR ?") on its local link, and then, 159 from the data in the Multicast DNS replies it receives, generating 160 the corresponding Unicast DNS reply. 162 3.1. Data Translation 164 Generating the corresponding Unicast DNS reply involves, at the very 165 least, rewriting the "local" suffix to the appropriate Unicast DNS 166 domain (e.g., "Building 1.example.com"). 168 In addition it would be desirable to suppress Unicast DNS replies for 169 records that are not useful outside the local link. For example, DNS 170 A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 171 link-local addresses [RFC4862] should be suppressed. Similarly, for 172 sites that have multiple private address realms [RFC1918], private 173 addresses from one private address realm should not be communicated 174 to clients in a different private address realm. 176 By the same logic, DNS SRV records that reference target host names 177 that have no addresses usable by the requester should be suppressed, 178 and likewise, DNS PTR records that point to DNS names with DNS SRV 179 records that reference target host names that have no addresses 180 usable by the requester should be also be suppressed. 182 The same reachability requirement for advertised services also 183 applies to the Hybrid Proxy itself. The mechanism specified in this 184 document only works if the Hybrid Proxy is reachable from the client 185 making the request. 187 3.1.1. Application-Specific Data Translation 189 There may be cases where Application-Specific Data Translation is 190 appropriate. 192 For example, AirPrint printers tend to advertise fairly verbose 193 information about their capabilities in their DNS-SD TXT record. 194 This information is a legacy from LPR printing, because LPR does not 195 have in-band capability negotiation, so all of this information is 196 put in the DNS-SD TXT record instead. IPP printing does have in-band 197 capability negotiation, but for convenience printers tend to include 198 the same capability information in their IPP DNS-SD TXT records as 199 well. For local mDNS use this extra TXT record information is 200 inefficient, but not fatal. However, when a Hybrid Proxy aggregates 201 data from multiple printers on a link, and sends it via unicast (via 202 UDP or TCP) this amount of unnecessary TXT record information can 203 result in large replies. Therefore, a Hybrid Proxy that is aware of 204 the specifics of an application-layer protocol such as Apple's 205 AirPrint (which uses IPP) can elide unnecessary key/value pairs from 206 the DNS-SD TXT record for better network efficiency. 208 Note that this kind of Application-Specific Data Translation is 209 expected to be very rare. It is the exception, rather than the rule. 210 This is an example of a common theme in computing. It is frequently 211 the case that it is wise to start with a clean, layered design, with 212 clear boundaries. Then, in certain special cases, those layer 213 boundaries may be violated, where the performance and efficiency 214 benefits outweigh the inelegance of the layer violation. 216 As in other similar situations, these layer violations optional. 217 They are done only for efficiency reasons, and are not required for 218 correct operation. A Hybrid Proxy can operate solely at the mDNS 219 layer, without any knowledge of DNS-SD semantics, or of any DNS-SD 220 client semantics. 222 3.2. Answer Aggregation 224 In a simple analysis, simply gathering multicast answers and 225 forwarding them in a unicast reply seems adequate, but it raises the 226 question of how long the Hybrid Proxy should wait to be sure that it 227 has received all the Multicast DNS replies it needs to form a 228 complete Unicast DNS reply. If it waits too little time, then it 229 risks its Unicast DNS reply being incomplete. If it waits too long, 230 then it creates a poor user experience at the client end. 232 This dilemma is solved by use of DNS Long-Lived Queries (DNS LLQ) 233 [I-D.sekar-dns-llq]. The Hybrid Proxy replies immediately to the 234 Unicast DNS query using the Multicast DNS records it already has in 235 its cache (if any). This provides a good client user experience by 236 providing a near-instantaneous response. Simultaneously, the Hybrid 237 Proxy issues a Multicast DNS query on the local link to discover if 238 there are any additional Multicast DNS records it did not already 239 know about. Should additional Multicast DNS replies be received, 240 these are then delivered to the client using DNS LLQ update messages. 241 The timeliness of such LLQ updates is limited only by the timeliness 242 of the device responding to the Multicast DNS query. If the 243 Multicast DNS device responds quickly, then the LLQ update is 244 delivered quickly. If the Multicast DNS device responds slowly, then 245 the LLQ update is delivered slowly. The benefit of using LLQ is that 246 the Hybrid Proxy can respond promptly because it doesn't have to 247 delay its unicast reply to allow for the expected worst-case delay 248 for receiving all the Multicast DNS replies. Even if a proxy were to 249 try to provide reliability by assuming an excessively pessimistic 250 worst-case time (thereby giving a very poor user experience) there 251 would still be the risk of a slow Multicast DNS device taking even 252 longer than that (e.g, a device that is not even powered on until ten 253 seconds after the initial query is received) resulting in incomplete 254 replies. Using LLQs solves this dilemma: even very late replies are 255 not lost; they are delivered in subsequent LLQ update messages. 257 There are two factors that determine specifically how replies are 258 generated. The first factor is whether the Hybrid Proxy already has 259 at least one record in its cache that positively answers the 260 question. The second factor is whether the query from the client 261 includes the LLQ option (typical with long-lived service browsing PTR 262 queries) or not (typical with one-shot operations like SRV or address 263 record queries). 265 o No answer in cache; no LLQ option: Do local mDNS query three 266 times, and then return NXDOMAIN if no answer after three tries. 268 o No answer in cache; with LLQ option: As above, do local mDNS query 269 three times, and then return NXDOMAIN if no answer after three 270 tries. However, the query remains active for as long as the 271 client maintains the LLQ state, and if mDNS answers are received 272 later, LLQ update messages are sent. (Reasoning: We don't need to 273 rush to send an empty answer.) 275 o At least one answer in cache; no LLQ option: Send reply right away 276 to minimise delay. No local mDNS queries are performed. 277 (Reasoning: Given RRSet TTL harmonisation, if the proxy has one 278 answer in its cache, it should have all of them.) 280 o At least one answer in cache; with LLQ option: As above, send 281 reply right away to minimise delay. However, the query remains 282 active for as long as the client maintains the LLQ state, and if 283 additional mDNS answers are received later, LLQ update messages 284 are sent. (Reasoning: We want UI that is displayed very rapidly, 285 yet continues to remain accurate even as the network environment 286 changes.) 288 4. Implementation Status 290 Some aspects of the mechanism specified in this document already 291 exist in deployed software. Some aspects are new. This section 292 outlines which aspects already exist and which are new. 294 4.1. Already Implemented and Deployed 296 Domain enumeration discovery by the client (the "b._dns-sd._udp" 297 queries) is already implemented and deployed. 299 Unicast queries to the indicated discovery domain is already 300 implemented and deployed. 302 These are implemented and deployed in Mac OS X 10.4 and later 303 (including all versions of Apple iOS, on all iPhone and iPads), in 304 Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) 305 and later. 307 Domain enumeration discovery and unicast querying have been used for 308 several years at IETF meetings to make Terminal Room printers 309 discoverable from outside the Terminal room. When you Press Cmd-P on 310 your Mac, or select AirPrint on your iPad or iPhone, and the Terminal 311 room printers appear, that is because your client is doing unicast 312 DNS queries to the IETF DNS servers. 314 4.2. Partially Implemented 316 The current APIs make multiple domains visible to client software, 317 but most client UI today lumps all discovered services into a single 318 flat list. This is largely a chicken-and-egg problem. Application 319 writers were naturally reluctant to spend time writing domain-aware 320 UI code when few customers today would benefit from it. If Hybrid 321 Proxy deployment becomes common, then application writers will have a 322 reason to provide better UI. Existing applications will work with 323 the Hybrid Proxy, but will show all services in a single flat list. 324 Applications with improved UI will group services by domain. 326 The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in 327 this specification exists and is deployed, but has not been 328 standardized by the IETF. It is possible that the IETF may choose to 329 standardize a different or better Long-Lived Query mechanism. In 330 that case, the pragmatic deployment approach would be for vendors to 331 produce Hybrid Proxies that implement both the deployed Long-Lived 332 Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new 333 IETF Standard Long-Lived Query mechanism (as the future long-term 334 direction). 336 4.3. Not Yet Implemented 338 The translating/filtering Hybrid Proxy specified in this document. 339 Once implemented, such a Hybrid Proxy will immediately make wide-area 340 discovery available with today's existing clients and devices. 342 A mechanism to 'stitch' together multiple ".local." zones so that 343 they appear as one. Such a mechanism will be specified in a future 344 companion document. 346 5. IPv6 Considerations 348 An IPv4-only host and an IPv6-only host behave as "ships that pass in 349 the night". Even if they are on the same Ethernet, neither is aware 350 of the other's traffic. For this reason, each physical link may have 351 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 352 Since for practical purposes, a group of IPv4-only hosts and a group 353 of IPv6-only hosts on the same Ethernet act as if they were on two 354 entirely separate Ethernet segments, it is unsurprising that their 355 use of the ".local." zone should occur exactly as it would if they 356 really were on two entirely separate Ethernet segments. 358 It will be desirable to have a mechanism to 'stitch' together these 359 two unrelated ".local." zones so that they appear as one. Such 360 mechanism will need to be able to differentiate between a dual-stack 361 (v4/v6) host participating in both ".local." zones, and two different 362 hosts, one IPv4-only and the other IPv6-only, which are both trying 363 to use the same name(s). Such a mechanism will be specified in a 364 future companion document. 366 6. Security Considerations 368 A service proves its presence on a local link by its ability to 369 answer link-local multicast queries on that link. If greater 370 security is desired, then the Hybrid Proxy mechanism should not be 371 used, and something with stronger security should be used instead, 372 such as authenticated secure DNS Update [RFC2136] [RFC3007]. 374 7. Intelectual Property Rights 376 Apple has submitted an IPR disclosure concerning the technique 377 proposed in this document. Details are available on the IETF IPR 378 disclosure page [IPR2119]. 380 8. IANA Considerations 382 This document has no IANA Considerations. 384 9. Acknowledgments 386 Thanks to Markus Stenberg for helping develop the policy regarding 387 the four styles of unicast reply. 389 10. References 391 10.1. Normative References 393 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 394 STD 13, RFC 1034, November 1987. 396 [RFC1035] Mockapetris, P., "Domain names - implementation and 397 specification", STD 13, RFC 1035, November 1987. 399 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 400 E. Lear, "Address Allocation for Private Internets", 401 BCP 5, RFC 1918, February 1996. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 407 Configuration of IPv4 Link-Local Addresses", RFC 3927, 408 May 2005. 410 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 411 Address Autoconfiguration", RFC 4862, September 2007. 413 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 414 December 2012. 416 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 417 Discovery", RFC 6763, December 2012. 419 [I-D.sekar-dns-llq] 420 Sekar, K., "DNS Long-Lived Queries", 421 draft-sekar-dns-llq-01 (work in progress), August 2006. 423 10.2. Informative References 425 [IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid 426 Unicast/Multicast DNS-Based Service Discovery", 427 . 429 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 430 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 431 RFC 2136, April 1997. 433 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 434 Update", RFC 3007, November 2000. 436 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 437 to Replace the AppleTalk Name Binding Protocol (NBP)", 438 RFC 6760, December 2012. 440 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 441 Networking: The Definitive Guide", O'Reilly Media, Inc. , 442 ISBN 0-596-10100-7, December 2005. 444 Author's Address 446 Stuart Cheshire 447 Apple Inc. 448 1 Infinite Loop 449 Cupertino, California 95014 450 USA 452 Phone: +1 408 974 3207 453 Email: cheshire@apple.com