idnits 2.17.1 draft-cheshire-mdnsext-hybrid-02.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 (Jul 11, 2013) is 3941 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 Jul 11, 2013 5 Expires: January 12, 2014 7 Hybrid Unicast/Multicast DNS-Based Service Discovery 8 draft-cheshire-mdnsext-hybrid-02 10 Abstract 12 Performing DNS-Based Service Discovery using purely Multicast DNS 13 allows discovery only of services present on the local link. Using a 14 very large local link with thousands of hosts improves service 15 discovery, but at the cost of large amounts of multicast traffic. 17 Performing DNS-Based Service Discovery using purely Unicast DNS is 18 more efficient, but requires configuration of DNS Update keys on the 19 devices offering the services, which can be onerous for simple 20 devices like printers and network cameras. 22 Hence a compromise is needed, that provides easy service discovery 23 without requiring either large amounts of multicast traffic or 24 onerous configuration. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 12, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Terminology Used in this Document . . . . . . . 3 62 3. Hybrid Proxy Operation . . . . . . . . . . . . . . . . . . . . 4 63 4. Implementation Status . . . . . . . . . . . . . . . . . . . . . 6 64 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 7. Intelectual Property Rights . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Multicast DNS [RFC6762] and its companion technology DNS-based 77 Service Discovery [RFC6763] were created to provide IP networking 78 with the ease-of-use and autoconfiguration for which AppleTalk was 79 well known [RFC6760] [ZC]. 81 Section 10 ("Populating the DNS with Information") of the DNS-SD 82 specification [RFC6763] discusses possible ways that a service's PTR, 83 SRV, TXT and address records can make their way into the DNS 84 namespace, including manual zone file configuration [RFC1034] 85 [RFC1035], DNS Update [RFC2136] [RFC3007] and proxies. 87 This document specifies a type of proxy called a Hybrid Proxy that 88 uses Multicast DNS [RFC6762] to discover Multicast DNS records on its 89 local link, and makes corresponding DNS records visible in the 90 Unicast DNS namespace. 92 2. Conventions and Terminology Used in this Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 99 Multicast DNS works between a hosts on the same link. A set of hosts 100 is considered to be "on the same link", if: 102 o when any host A from that set sends a packet to any other host B 103 in that set, using unicast, multicast, or broadcast, the entire 104 link-layer packet payload arrives unmodified, and 106 o a broadcast sent over that link by any host from that set of hosts 107 can be received by every other host in that set 109 The link-layer *header* may be modified, such as in Token Ring Source 110 Routing [802.5], but not the link-layer *payload*. In particular, if 111 any device forwarding a packet modifies any part of the IP header or 112 IP payload then the packet is no longer considered to be on the same 113 link. This means that the packet may pass through devices such as 114 repeaters, bridges, hubs or switches and still be considered to be on 115 the same link for the purpose of this document, but not through a 116 device such as an IP router that decrements the TTL or otherwise 117 modifies the IP header. 119 3. Hybrid Proxy Operation 121 In its simplest form, each local link in an organization is assigned 122 a unique Unicast DNS domain name, such as "Building 1.example.com." 123 or "4th Floor.Building 1.example.com." (Grouping multiple local 124 links under the same Unicast DNS domain name is to be specified in a 125 future companion document, but for the purposes of this document, 126 assume that each link has its own unique Unicast DNS domain name.) 128 Each link in an organization has a Hybrid Proxy which serves it. 129 This function could be performed by a router on that link, or, with 130 appropriate VLAN configuration, a single Hybrid Proxy could have a 131 logical presence on, and serve as the Hybrid Proxy for, multiple 132 links. In the organization's DNS server, NS records are used to 133 delegate ownership of each defined link name (e.g., "Building 134 1.example.com.") to the Hybrid Proxy which serves that link. 136 Domain Enumeration PTR records [RFC6763] are also created to inform 137 clients of available Device Discovery domains, e.g.,: 139 b._dns-sd._udp.example.com. PTR Building 1.example.com. 141 When a DNS-SD client issues a Unicast DNS query to discover services 142 in a particular Unicast DNS (e.g., "_printer._tcp.Building 143 1.example.com. PTR ?") the normal DNS delegation mechanism results 144 in that query being served from the delegated authoritative name 145 server for that subdomain, namely the Hybrid Proxy on the link in 146 question. Although a Hybrid Proxy implements the usual Unicast DNS 147 protocol, in contrast to a conventional Unicast DNS server that 148 generates answers according to data in its manually-configured zone 149 file, a Hybrid Proxy gets its data by performing a Multicast DNS 150 query (e.g., "_printer._tcp.local. PTR ?") on its local link, and 151 then, from the Multicast DNS replies it receives, it generates a 152 corresponding Unicast DNS reply. 154 Generating the corresponding Unicast DNS reply involves, at the very 155 least, rewriting the "local" suffix to the appropriate Unicast DNS 156 domain (e.g., "Building 1.example.com"). 158 In addition it would be desirable to suppress Unicast DNS replies for 159 records that are not useful outside the local link. For example, DNS 160 A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 161 link-local addresses [RFC4862] should be suppressed. Similarly, for 162 sites that have multiple private address [RFC1918] realms, private 163 addresses from one private address realm should not be communicated 164 to clients in a different private address realm. 166 By the same logic, DNS SRV records that reference target host names 167 that have no addresses usable by the requester should be suppressed, 168 and likewise, DNS PTR records that point to DNS names with DNS SRV 169 records that reference target host names that have no addresses 170 usable by the requester should be also be suppressed. 172 The same reachability requirement for advertised services also 173 applies to the Hybrid Proxy itself. The mechanism specified in this 174 document only works if the Hybrid Proxy is reachable from the client 175 making the request. 177 In a simple analysis, this simple approach is adequate, but it raises 178 the question of how long the Hybrid Proxy should wait to be sure that 179 it has received all the Multicast DNS replies it needs to form a 180 complete Unicast DNS reply. If it waits too little time, then it 181 risks its Unicast DNS reply being incomplete. If it waits too long, 182 then it creates a poor user experience at the client end. 184 This dilemma is solved by use of DNS Long-Lived Queries (DNS LLQ) 185 [I-D.sekar-dns-llq]. The Hybrid Proxy replies immediately to the 186 Unicast DNS query using the Multicast DNS records it already has in 187 its cache (if any). This provides a good client user experience by 188 providing a near-instantaneous response. Simultaneously, the Hybrid 189 Proxy issues a Multicast DNS query on the local link to discover if 190 there are additional Multicast DNS records it does not already have 191 in its cache (including the case where it has *no* appropriate 192 records in its cache). Should additional Multicast DNS replies be 193 received, these are then delivered to the client using DNS LLQ update 194 events. The timeliness of such LLQ updates is limited only by the 195 timeliness of the device responding to the Multicast DNS query. If 196 the Multicast DNS device responds quickly, then the LLQ update is 197 delivered quickly. If the Multicast DNS device responds slowly, then 198 the LLQ update is delivered slowly. The benefit of using LLQ is that 199 the Hybrid Proxy can respond promptly because it doesn't have to 200 delay its unicast reply to allow for the expected worst-case delay 201 receiving a Multicast DNS reply. Even in the event that a Multicast 202 DNS device takes even longer than the expected worst-case time, its 203 reply is not lost; it is delivered when it arrives, in the form of a 204 subsequent DNS LLQ update. 206 4. Implementation Status 208 Some aspects of the mechanism specified in this document already 209 exist in deployed software. Some aspects are new. This section 210 outlines which aspects already exist and which are new. 212 4.1. Already Implemented and Deployed 214 Domain enumeration discovery by the client (the "b._dns-sd._udp" 215 queries) is already implemented and deployed. 217 Unicast queries to the indicated discovery domain is already 218 implemented and deployed. 220 These are implemented and deployed in Mac OS X 10.4 and later 221 (including all versions of Apple iOS, on all iPhone and iPads), in 222 Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) 223 and later. 225 Domain enumeration discovery and unicast querying have been used for 226 several years at IETF meetings to make Terminal Room printers 227 discoverable from outside the Terminal room. When you Press Cmd-P on 228 your Mac, or select AirPrint on your iPad or iPhone, and the Terminal 229 room printers appear, that is because your client is doing unicast 230 DNS queries to the IETF DNS servers. 232 4.2. Partially Implemented 234 The current APIs make multiple domains visible to client software, 235 but most client UI today lumps all discovered services into a single 236 flat list. This is largely a chicken-and-egg problem. Application 237 writers were naturally reluctant to spend time writing domain-aware 238 UI code when few customers today would benefit from it. If Hybrid 239 Proxy deployment becomes common, then application writers will have a 240 reason to provide better UI. Existing applications will work with 241 the Hybrid Proxy, but will show all services in a single flat list. 242 Applications with improved UI will group services by domain. 244 The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in 245 this specification exists and is deployed, but has not been 246 standardized by the IETF. It is possible that the IETF may choose to 247 standardize a different or better Long-Lived Query mechanism. In 248 that case, the pragmatic deployment approach would be for vendors to 249 produce Hybrid Proxies that implement both the deployed Long-Lived 250 Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new 251 IETF Standard Long-Lived Query mechanism (as the future long-term 252 direction). 254 4.3. Not Yet Implemented 256 The translating/filtering Hybrid Proxy specified in this document. 257 Once implemented, such a Hybrid Proxy will immediately make wide-area 258 discovery available with today's existing clients and devices. 260 A mechanism to 'stitch' together multiple ".local." zones so that 261 they appear as one. Such a mechanism will be specified in a future 262 companion document. 264 5. IPv6 Considerations 266 An IPv4-only host and an IPv6-only host behave as "ships that pass in 267 the night". Even if they are on the same Ethernet, neither is aware 268 of the other's traffic. For this reason, each physical link may have 269 *two* unrelated ".local." zones, one for IPv4 and one for IPv6. 270 Since for practical purposes, a group of IPv4-only hosts and a group 271 of IPv6-only hosts on the same Ethernet act as if they were on two 272 entirely separate Ethernet segments, it is unsurprising that their 273 use of the ".local." zone should occur exactly as it would if they 274 really were on two entirely separate Ethernet segments. 276 It will be desirable to have a mechanism to 'stitch' together these 277 two unrelated ".local." zones so that they appear as one. Such 278 mechanism will need to be able to differentiate between a dual-stack 279 (v4/v6) host participating in both ".local." zones, and two different 280 hosts, one IPv4-only and the other IPv6-only, which are both trying 281 to use the same name(s). Such a mechanism will be specified in a 282 future companion document. 284 6. Security Considerations 286 A service proves its presence on a local link by its ability to 287 answer link-local multicast queries on that link. If greater 288 security is desired, then the Hybrid Proxy mechanism should not be 289 used, and instead authenticated secure DNS Update should be used 290 [RFC2136] [RFC3007]. 292 7. Intelectual Property Rights 294 Apple has submitted an IPR disclosure concerning the technique 295 proposed in this document. Details are available on the IETF IPR 296 disclosure page [IPR2119]. 298 8. IANA Considerations 300 This document has no IANA Considerations. 302 9. Acknowledgments 304 [To be filled in later.] 306 10. References 308 10.1. Normative References 310 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 311 STD 13, RFC 1034, November 1987. 313 [RFC1035] Mockapetris, P., "Domain names - implementation and 314 specification", STD 13, RFC 1035, November 1987. 316 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 317 E. Lear, "Address Allocation for Private Internets", 318 BCP 5, RFC 1918, February 1996. 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 324 Configuration of IPv4 Link-Local Addresses", RFC 3927, 325 May 2005. 327 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 328 Address Autoconfiguration", RFC 4862, September 2007. 330 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 331 December 2012. 333 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 334 Discovery", RFC 6763, December 2012. 336 [I-D.sekar-dns-llq] 337 Sekar, K., "DNS Long-Lived Queries", 338 draft-sekar-dns-llq-01 (work in progress), August 2006. 340 10.2. Informative References 342 [IPR2119] "Apple Inc.'s Statement about IPR related to 343 draft-cheshire-mdnsext-hybrid", 344 . 346 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 347 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 348 RFC 2136, April 1997. 350 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 351 Update", RFC 3007, November 2000. 353 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 354 to Replace the AppleTalk Name Binding Protocol (NBP)", 355 RFC 6760, December 2012. 357 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 358 Networking: The Definitive Guide", O'Reilly Media, Inc. , 359 ISBN 0-596-10100-7, December 2005. 361 Author's Address 363 Stuart Cheshire 364 Apple Inc. 365 1 Infinite Loop 366 Cupertino, California 95014 367 USA 369 Phone: +1 408 974 3207 370 Email: cheshire@apple.com