idnits 2.17.1 draft-lynn-dnssd-requirements-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 date (October 22, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 105, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-6man-multicast-scopes-00 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-10 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-SD/mDNS Extensions K. Lynn, Ed. 3 Internet-Draft Consultant 4 Intended status: Informational S. Cheshire 5 Expires: April 25, 2014 Apple, Inc. 6 October 22, 2013 8 Requirements for Scalable DNS-SD/mDNS Extensions 9 draft-lynn-dnssd-requirements-00 11 Abstract 13 DNS-SD/mDNS is widely used today for discovery and resolution of 14 services and names on a local link, but there are use cases to extend 15 DNS-SD/mDNS to enable service discovery beyond the local link. This 16 document provides a problem statement and a list of requirements. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 25, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Internationalization Considerations . . . . . . . . . . . . . 6 56 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 6 57 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 DNS-Based Service Discovery [DNS-SD] in combination with its 67 companion technology Multicast DNS [mDNS] is widely used today for 68 discovery and resolution of services and names on a local link. 69 However, as users move to multi-link home or campus networks they 70 find that mDNS does not work across routers. DNS-SD can also be used 71 in conjunction with conventional unicast DNS to enable wide-area 72 service discovery, but this capability is not yet widely deployed. 73 This disconnect between customer needs and current practice has led 74 to calls for improvement, such as the Educause petition [EP]. 76 In response to this and similar evidence of market demand, several 77 products now enable service discovery beyond the local link using 78 different ad-hoc techniques. However, it is unclear which approach 79 represents the best long-term direction for DNS-based service 80 discovery protocol development. 82 DNS-SD/mDNS in its present form is also not optimized for network 83 technologies where multicast transmissions are relatively expensive. 84 Wireless networks such as [IEEE.802.11] may be adversely affected by 85 excessive mDNS traffic due to the higher network overhead of 86 multicast transmissions. Wireless mesh networks such as 6LoWPAN 87 [RFC4944] are effectively multi-link subnets where multicasts must be 88 forwarded by intermediate nodes. 90 It is in the best interests of end users, network administrators, and 91 vendors for all interested parties to cooperate within the context of 92 the IETF to develop an efficient, scalable, and interoperable 93 standards-based solution. 95 This document defines the problem statement and gathers requirements 96 for Scalable DNS-SD/mDNS Extensions. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in "Key words for use in 103 RFCs to Indicate Requirement Levels" [RFC2119]. 105 1.2. Terminology [TBD] 107 Discovery Scope 109 Zero Configuration 111 Incremental Deployment 113 2. Problem Statement 115 Service discovery beyond the local link is perhaps the most important 116 feature currently missing from the DNS-SD/mDNS framework. The issues 117 and requirements are summarized below. 119 2.1. Multilink Naming and Discovery 121 A list of desired DNS-SD/mDNS improvements from network 122 administrators in the research and education community was issued in 123 the form of the Educause petition [EP]. The following is a technical 124 summary of the issues: 126 o Products that advertise services such as printing and multimedia 127 streaming via DNS-SD/mDNS are not currently discoverable by 128 devices on other links. It is common practice for enterprises and 129 institutions to use wireless links for client access and wired 130 networks for server infrastructure, typically on different 131 subnets. DNS-SD used with conventional unicast DNS does work when 132 devices are on different links, but the resource records that 133 describe the service must somehow be entered into the unicast DNS 134 namespace. 136 o Entering DNS-SD records manually into a unicast DNS zone file 137 works, (as has been done for many years for the Terminal Room 138 printers at IETF meetings) but requires the DNS administrator to 139 know how to do that [static] and is fragile when IP addresses of 140 devices may change, as is common when DHCP is used. 142 o Automatically adding DNS-SD records using DNS Update works, but 143 requires that the DNS server be configured to allow DNS Updates, 144 and requires that devices be configured with the DNS Update 145 credentials to permit such updates, which has proven to be 146 onerous. 148 o Therefore, a mechanism is desired that populates the DNS namespace 149 with the appropriate DNS-SD records with less manual 150 administration than typically needed for a unicast DNS server. 152 The following is a technical summary of the requirements: 154 o It must scale to a range of hundreds or thousands of DNS-SD/mDNS 155 enabled devices in a given environment. 157 o It must work with wired and wireless networks from different 158 vendors. 160 o It must not significantly increase network traffic (wired or 161 wireless). 163 o It must be easily managed at an enterprise scale. 165 o It must be provided at a reasonable cost. [CapEx + OpEx. KEL] 167 2.2. IEEE 802.11 Wireless LANs 169 Multicast DNS was originally designed to run on Ethernet - the 170 dominant link-layer at the time. In shared Ethernet networks, 171 multicast frames place little additional demand on the shared network 172 medium above unicast frames. In IEEE 802.11 networks however, 173 multicast frames are transmitted at a low data rate supported by all 174 receivers. In practice, this data rate leads to a larger fraction of 175 airtime being devoted to multicast transmission. Some network 176 administrators block multicast traffic or convert it to a series of 177 link-layer unicast frames. 179 Wired links may be orders of magnitude less reliable than their wired 180 counterparts. To improve transmission reliability, the IEEE 802.11 181 MAC requires positive acknowledgement of unicast frames. It does 182 not, however, support positive acknowledgement of multicast frames. 183 As a result, it is common to observe much higher loss of multicast 184 frames on wireless as compared to wired network technologies. 186 Enabling service discovery on IEEE 802.11 networks requires that the 187 number of multicast frames be restricted to a suitably low value, or 188 replaced with unicast frames to use the MAC's reliability features. 190 2.3. Low Power and Lossy Networks (LLNs) 192 Emerging wireless mesh networking technologies such as RPL [RFC6550] 193 and 6LoWPAN present several challenges for the current DNS-SD/mDNS 194 design. First, Link-Local multicast scope [RFC4291] is defined as a 195 single-hop neighborhood. A single subnet prefix in a wireless mesh 196 network may often span multiple links, therefore a larger multicast 197 scope is required to span it [I-D.ietf-6man-multicast-scopes]. 199 Additionally, low-power nodes may be offline for significant periods 200 either because they are "sleeping" or due to connectivity problems. 201 In such cases LLN nodes might fail to respond to queries or defend 202 their names using the current design. 204 3. Basic Use Cases 206 The following use cases are defined with different constraints to 207 help distinguish and classify the target requirements. 209 (A) Personal Area networks; e.g., one laptop and one printer. 210 This is the simplest example of a DNS-SD/mDNS network. 212 (B) Classic home networks, consisting of: 214 * Single exit router: the network may have multiple upstream 215 providers or networks, but all outgoing and incoming trafic 216 goes through a single router. 218 * One level depth: all links on the network are connected to the 219 same default router. 221 * Single administrative domain: all nodes under the same admin 222 entity. 224 (C) Advanced residential and small business networks 225 [I-D.ietf-homenet-arch]: 227 Like B but consist of two or more wired and/or wireless links, 228 connected by routers, behind the single exit router. However, the 229 forwarding nodes are largely self-configuring and do not require 230 routing protocol administration. 232 (D) Enterprise networks: 234 Like C but consist of arbitrary diameter under a single 235 administrative domain. A large majority of the forwarding and 236 security devices are configured. 238 (E) Higher Education networks: 240 Like D but core network may be under a central administrative 241 domain while leaf networks are under local administrative domains. 243 (F) Mesh networks such as RPL/6LoWPAN: 245 Multi-link subnets with prefixes defined by one or more border 246 routers. May comprise network B and any part of networks C, D, or 247 E. 249 4. Internationalization Considerations 251 The solution should support rich international text, as do DNS-SD and 252 mDNS today. Users will not accept a solution that does not allow the 253 richness of service naming that they currently have with mDNS, manual 254 zone files, and DNS Update today. 256 5. Namespace Considerations 258 The unicast DNS namespace contains globally unique names. Naming 259 services over a local scope contain locally unique names. Clients 260 discovering services need to be able to differentiate global names 261 from local names. 263 6. Requirements 265 [This is a strawman proposal. MB] 267 REQ1: The scope of the discovery should be either automatically 268 found by the discovering devices and/or configured. 270 REQ2: For use cases A, B, and C, there should be a zero 271 configuration mode of operation. 273 REQ3: For use cases D and E, there should be a way to configure the 274 scope of the discovery and also support both smaller (ex: 275 department) and larger (ex: campus-wide) discovery scopes. 277 REQ4: For use cases D and E, there should be an incremental way to 278 deploy the solution. 280 REQ5: The new solution should integrate or at least should not break 281 any current link scope DNS-SD/mDNS protocols and deployments. 283 REQ6: The new solution MUST be capable of spanning multiple links 284 (hops) and network technologies. 286 REQ7: The new solution MUST be scalable to thousands of servers with 287 minimal configuration and without degrading network performance. 289 REQ8: The new solution MUST provide a consistent user experience 290 whether local or global services are being discovered. 292 7. IANA Considerations 294 This document currently makes no request of IANA. 296 Note to RFC Editor: this section may be removed on publication as an 297 RFC. 299 8. Security Considerations 301 [Not complete - initial ideas. MB/KEL] 303 If the scope of the discovery is not properly setup or constrained, 304 then information leaks will happen outside the appropriate network. 306 Visiting nodes on a network may discover more services than desired 307 by the network policies, if filtering of discovery packets was not 308 properly setup. [Is this a NAC or DNS problem? KL] 310 Depending on the chosen solution, there is a possibility of name 311 space conflicts between the DNS tree and this solution. In this 312 case, a node may not know if the target node or service is the right 313 one, therefore enabling ground for various attacks. 315 The DNS-SD/mDNS framework security considerations also apply. 317 DNSSEC can assert the validity but not the veracity of records in a 318 zone file. The trust model of the global DNS relies on the fact that 319 human administrators either a) manually enter resource records into a 320 zone file, or b) configure the DNS server to authenticate a trusted 321 device (e.g., a DHCP server) that can automatically maintain such 322 records. 324 By contrast, the "plug-and-play" nature of mDNS devices has up to now 325 depended only on physical connectivity. If a device is visible via 326 mDNS then it is assumed to be trusted. This is no longer likely to 327 be the case in larger networks. Still, the new solution SHOULD 328 leverage existing security solutions and not invent new ones. 330 Mobile devices such as smart phones that can expose the location of 331 their owners by registering services in arbitrary zones pose a risk 332 to privacy. Such devices MUST NOT register their services in 333 arbitrary zones without the approval of their operators. However, it 334 SHOULD be possible to configure one or more "home" zones, e.g., based 335 on subnet prefix, in which mobile devices may automatically register 336 their services. 338 9. Acknowledgments 340 We gratefully acknowledge contributions and review comments made by 341 RJ Atkinson, Marc Blanchet, Tim Chown, Ralph Droms, Educause, David 342 Farmer, Matthew Gast, Peter Van Der Stok, and Thomas Narten. 344 10. References 346 10.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 352 Architecture", RFC 4291, February 2006. 354 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 355 "Transmission of IPv6 Packets over IEEE 802.15.4 356 Networks", RFC 4944, September 2007. 358 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 359 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 360 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 361 Lossy Networks", RFC 6550, March 2012. 363 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 364 February 2013. 366 [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service 367 Discovery", RFC 6763, February 2013. 369 10.2. Informative References 371 [I-D.ietf-6man-multicast-scopes] 372 Droms, R., "IPv6 Multicast Address Scopes", draft-ietf- 373 6man-multicast-scopes-00 (work in progress), August 2013. 375 [I-D.ietf-homenet-arch] 376 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 377 "Home Networking Architecture for IPv6", draft-ietf- 378 homenet-arch-10 (work in progress), August 2013. 380 [EP] "Educause Petition", https://www.change.org/petitions/ 381 from-educause-higher-ed-wireless-networking-admin-group, 382 July 2012. 384 [IEEE.802.11] 385 "Information technology - Telecommunications and 386 information exchange between systems - Local and 387 metropolitan area networks - Specific requirements - Part 388 11: Wireless LAN Medium Access Control (MAC) and Physical 389 Layer (PHY) Specifications ", IEEE Std 802.11-2012, 2012, 390 . 393 [static] "Manually Adding DNS-SD Service Discovery Records to an 394 Existing Name Server", July 2013, 395 . 397 Authors' Addresses 399 Kerry Lynn (editor) 400 Consultant 402 Phone: +1 978 460 4253 403 Email: kerlyn@ieee.org 405 Stuart Cheshire 406 Apple, Inc. 407 1 Infinite Loop 408 Cupertino , California 95014 409 USA 411 Phone: +1 408 974 3207 412 Email: cheshire@apple.com