idnits 2.17.1 draft-cheshire-dnssd-hybrid-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 : ---------------------------------------------------------------------------- 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 (Oct 21, 2013) is 3840 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 Oct 21, 2013 5 Expires: April 24, 2014 7 Hybrid Unicast/Multicast DNS-Based Service Discovery 8 draft-cheshire-dnssd-hybrid-00 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 April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . 6 66 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 7. Intelectual Property Rights . . . . . . . . . . . . . . . . . . 8 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 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. 143 When a DNS-SD client issues a Unicast DNS query to discover services 144 in a particular Unicast DNS (e.g., "_printer._tcp.Building 145 1.example.com. PTR ?") the normal DNS delegation mechanism results 146 in that query being served from the delegated authoritative name 147 server for that subdomain, namely the Hybrid Proxy on the link in 148 question. Like a conventional Unicast DNS server, a Hybrid Proxy 149 implements the usual Unicast DNS protocol [RFC1034] [RFC1035] over 150 UDP and TCP. However, unlike a conventional Unicast DNS server that 151 generates answers according to data in its manually-configured zone 152 file, a Hybrid Proxy generates answers by performing a Multicast DNS 153 query (e.g., "_printer._tcp.local. PTR ?") on its local link, and 154 then, from the data in the Multicast DNS replies it receives, 155 generating the corresponding Unicast DNS reply. 157 Generating the corresponding Unicast DNS reply involves, at the very 158 least, rewriting the "local" suffix to the appropriate Unicast DNS 159 domain (e.g., "Building 1.example.com"). 161 In addition it would be desirable to suppress Unicast DNS replies for 162 records that are not useful outside the local link. For example, DNS 163 A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 164 link-local addresses [RFC4862] should be suppressed. Similarly, for 165 sites that have multiple private address realms [RFC1918], private 166 addresses from one private address realm should not be communicated 167 to clients in a different private address realm. 169 By the same logic, DNS SRV records that reference target host names 170 that have no addresses usable by the requester should be suppressed, 171 and likewise, DNS PTR records that point to DNS names with DNS SRV 172 records that reference target host names that have no addresses 173 usable by the requester should be also be suppressed. 175 The same reachability requirement for advertised services also 176 applies to the Hybrid Proxy itself. The mechanism specified in this 177 document only works if the Hybrid Proxy is reachable from the client 178 making the request. 180 In a simple analysis, this simple approach is adequate, but it raises 181 the question of how long the Hybrid Proxy should wait to be sure that 182 it has received all the Multicast DNS replies it needs to form a 183 complete Unicast DNS reply. If it waits too little time, then it 184 risks its Unicast DNS reply being incomplete. If it waits too long, 185 then it creates a poor user experience at the client end. 187 This dilemma is solved by use of DNS Long-Lived Queries (DNS LLQ) 188 [I-D.sekar-dns-llq]. The Hybrid Proxy replies immediately to the 189 Unicast DNS query using the Multicast DNS records it already has in 190 its cache (if any). This provides a good client user experience by 191 providing a near-instantaneous response. Simultaneously, the Hybrid 192 Proxy issues a Multicast DNS query on the local link to discover if 193 there are any additional Multicast DNS records it did not already 194 know about. Should additional Multicast DNS replies be received, 195 these are then delivered to the client using DNS LLQ update messages. 196 The timeliness of such LLQ updates is limited only by the timeliness 197 of the device responding to the Multicast DNS query. If the 198 Multicast DNS device responds quickly, then the LLQ update is 199 delivered quickly. If the Multicast DNS device responds slowly, then 200 the LLQ update is delivered slowly. The benefit of using LLQ is that 201 the Hybrid Proxy can respond promptly because it doesn't have to 202 delay its unicast reply to allow for the expected worst-case delay 203 for receiving all the Multicast DNS replies. Even if a proxy were to 204 try to provide reliability by assuming an excessively pessimistic 205 worst-case time (thereby giving a very poor user experience) there 206 would still be the risk of a slow Multicast DNS device taking even 207 longer than that (e.g, a device that is not even powered on until ten 208 seconds after the initial query is received) resulting in incomplete 209 replies. Using LLQs solves this dilemma: even very late replies are 210 not lost; they are delivered in subsequent LLQ update messages. 212 There are two factors that determine specifically how replies are 213 generated. The first factor is whether the Hybrid Proxy already has 214 at least one record in its cache that positively answers the 215 question. The second factor is whether the query from the client 216 includes the LLQ option (typical with long-lived service browsing PTR 217 queries) or not (typical with one-shot operations like SRV or address 218 record queries). 220 o No answer in cache; no LLQ option: Do local mDNS query three 221 times, and then return NXDOMAIN if no answer after three tries. 223 o No answer in cache; with LLQ option: As above, do local mDNS query 224 three times, and then return NXDOMAIN if no answer after three 225 tries. However, the query remains active for as long as the 226 client maintains the LLQ state, and if mDNS answers are received 227 later, LLQ update messages are sent. (Reasoning: We don't need to 228 rush to send an empty answer.) 230 o At least one answer in cache; no LLQ option: Send reply right away 231 to minimise delay. No local mDNS queries are performed. 232 (Reasoning: Given RRSet TTL harmonisation, if the proxy has one 233 answer in its cache, it should have all of them.) 235 o At least one answer in cache; with LLQ option: As above, send 236 reply right away to minimise delay. However, the query remains 237 active for as long as the client maintains the LLQ state, and if 238 additional mDNS answers are received later, LLQ update messages 239 are sent. (Reasoning: We want UI that is displayed very rapidly, 240 yet continues to remain accurate even as the network environment 241 changes.) 243 4. Implementation Status 245 Some aspects of the mechanism specified in this document already 246 exist in deployed software. Some aspects are new. This section 247 outlines which aspects already exist and which are new. 249 4.1. Already Implemented and Deployed 251 Domain enumeration discovery by the client (the "b._dns-sd._udp" 252 queries) is already implemented and deployed. 254 Unicast queries to the indicated discovery domain is already 255 implemented and deployed. 257 These are implemented and deployed in Mac OS X 10.4 and later 258 (including all versions of Apple iOS, on all iPhone and iPads), in 259 Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) 260 and later. 262 Domain enumeration discovery and unicast querying have been used for 263 several years at IETF meetings to make Terminal Room printers 264 discoverable from outside the Terminal room. When you Press Cmd-P on 265 your Mac, or select AirPrint on your iPad or iPhone, and the Terminal 266 room printers appear, that is because your client is doing unicast 267 DNS queries to the IETF DNS servers. 269 4.2. Partially Implemented 271 The current APIs make multiple domains visible to client software, 272 but most client UI today lumps all discovered services into a single 273 flat list. This is largely a chicken-and-egg problem. Application 274 writers were naturally reluctant to spend time writing domain-aware 275 UI code when few customers today would benefit from it. If Hybrid 276 Proxy deployment becomes common, then application writers will have a 277 reason to provide better UI. Existing applications will work with 278 the Hybrid Proxy, but will show all services in a single flat list. 279 Applications with improved UI will group services by domain. 281 The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in 282 this specification exists and is deployed, but has not been 283 standardized by the IETF. It is possible that the IETF may choose to 284 standardize a different or better Long-Lived Query mechanism. In 285 that case, the pragmatic deployment approach would be for vendors to 286 produce Hybrid Proxies that implement both the deployed Long-Lived 287 Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new 288 IETF Standard Long-Lived Query mechanism (as the future long-term 289 direction). 291 4.3. Not Yet Implemented 293 The translating/filtering Hybrid Proxy specified in this document. 294 Once implemented, such a Hybrid Proxy will immediately make wide-area 295 discovery available with today's existing clients and devices. 297 A mechanism to 'stitch' together multiple ".local." zones so that 298 they appear as one. Such a mechanism will be specified in a future 299 companion document. 301 5. IPv6 Considerations 303 An IPv4-only host and an IPv6-only host behave as "ships that pass in 304 the night". Even if they are on the same Ethernet, neither is aware 305 of the other's traffic. For this reason, each physical link may have 306 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 307 Since for practical purposes, a group of IPv4-only hosts and a group 308 of IPv6-only hosts on the same Ethernet act as if they were on two 309 entirely separate Ethernet segments, it is unsurprising that their 310 use of the ".local." zone should occur exactly as it would if they 311 really were on two entirely separate Ethernet segments. 313 It will be desirable to have a mechanism to 'stitch' together these 314 two unrelated ".local." zones so that they appear as one. Such 315 mechanism will need to be able to differentiate between a dual-stack 316 (v4/v6) host participating in both ".local." zones, and two different 317 hosts, one IPv4-only and the other IPv6-only, which are both trying 318 to use the same name(s). Such a mechanism will be specified in a 319 future companion document. 321 6. Security Considerations 323 A service proves its presence on a local link by its ability to 324 answer link-local multicast queries on that link. If greater 325 security is desired, then the Hybrid Proxy mechanism should not be 326 used, and something with stronger security should be used instead, 327 such as authenticated secure DNS Update [RFC2136] [RFC3007]. 329 7. Intelectual Property Rights 331 Apple has submitted an IPR disclosure concerning the technique 332 proposed in this document. Details are available on the IETF IPR 333 disclosure page [IPR2119]. 335 8. IANA Considerations 337 This document has no IANA Considerations. 339 9. Acknowledgments 341 Thanks to Markus Stenberg for helping develop the policy regarding 342 the four styles of unicast reply. 344 10. References 346 10.1. Normative References 348 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 349 STD 13, RFC 1034, November 1987. 351 [RFC1035] Mockapetris, P., "Domain names - implementation and 352 specification", STD 13, RFC 1035, November 1987. 354 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 355 E. Lear, "Address Allocation for Private Internets", 356 BCP 5, RFC 1918, February 1996. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 362 Configuration of IPv4 Link-Local Addresses", RFC 3927, 363 May 2005. 365 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 366 Address Autoconfiguration", RFC 4862, September 2007. 368 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 369 December 2012. 371 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 372 Discovery", RFC 6763, December 2012. 374 [I-D.sekar-dns-llq] 375 Sekar, K., "DNS Long-Lived Queries", 376 draft-sekar-dns-llq-01 (work in progress), August 2006. 378 10.2. Informative References 380 [IPR2119] "Apple Inc.'s Statement about IPR related to Hybrid 381 Unicast/Multicast DNS-Based Service Discovery", 382 . 384 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 385 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 386 RFC 2136, April 1997. 388 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 389 Update", RFC 3007, November 2000. 391 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 392 to Replace the AppleTalk Name Binding Protocol (NBP)", 393 RFC 6760, December 2012. 395 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 396 Networking: The Definitive Guide", O'Reilly Media, Inc. , 397 ISBN 0-596-10100-7, December 2005. 399 Author's Address 401 Stuart Cheshire 402 Apple Inc. 403 1 Infinite Loop 404 Cupertino, California 95014 405 USA 407 Phone: +1 408 974 3207 408 Email: cheshire@apple.com