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