idnits 2.17.1 draft-lynn-mdnsext-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 10, 2012) is 4215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 228, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 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 13, 2013 Apple, Inc. 6 October 10, 2012 8 Requirements for DNS-SD/mDNS Extensions 9 draft-lynn-mdnsext-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 is market demand to 15 extend DNS-SD/mDNS to enable service discovery beyond the local link. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 13, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 The DNS-SD/mDNS Extensions Working Group (MDNSEXT) will develop 65 extensions to DNS-Based Service Discovery [DNS-SD] and Multicast DNS 66 [mDNS] protocols to enable service discovery beyond the local link. 68 DNS-SD/mDNS is widely used today for discovery and resolution of 69 services and names on a local link. In principle DNS-SD can also be 70 used in conjunction with conventional unicast DNS to enable wide-area 71 service discovery, but in practice this capability is not widely 72 used. This disconnect between customer needs and current practice 73 has led to calls for improvement, such as the Educause petition [EP]. 75 In response to this and similar evidence of market demand, several 76 companies have recently announced "Bonjour gateway" products that 77 allow service discovery beyond the local link. However, these were 78 brought to market rapidly and it's unclear whether they represent the 79 best long-term direction for service discovery protocol development. 81 Similarly, DNS-SD/mDNS in its present form is not well suited for 82 emerging technologies such as multi-link subnets like 6LoWPAN where 83 "link local" is defined as a node's first-hop neighbors, subnet- 84 scoped multicast is problematic, and battery powered devices may be 85 offline for significant periods of time. 87 For these and other reasons, it is therefore beneficial for end 88 users, network operators, vendors, and for the long-term health of 89 the Internet to bring this work into the IETF where all interested 90 parties can cooperate to develop efficient and scalable solutions. 92 This document defines the problem statement and gathers requirements 93 for DNS-SD/mDNS Extensions. 95 2. Problem Statement 97 There is no single problem statement that motivates the need to 98 extend DNS-SD/mDNS, but "service discovery beyond the local link" 99 comes closest. What follows is a roughly prioritized list of issues. 101 2.1. Multilink Naming and Discovery 103 While DNS-SD/mDNS is well-suited for zero-configuration of naming and 104 discovery of hosts and services on a local link, users are frustrated 105 by the inability to discover services on other subnets. 107 DNS-SD is a conventional use of existing DNS Resource Records and 108 can, in practice, be deployed over unicast DNS. However, this mode 109 is not commonly used. 111 This resulted in a call from network administrators in the form of 112 the Educause petition [EP]. Some highlights from that petition 113 included: 115 o Airplay does not work when Apple TV's and Apple client devices are 116 on different IP subnets. It is common for the enterprise wireless 117 and wired networks in our institutions to utilize different IP 118 subnets. 120 o Students are requesting the ability to utilize Airprint to print 121 from their Apple devices on our enterprise networks. 123 o That Apple establish a way for Apple TV's be accessible from 124 Apple's client devices across multiple IPv4 and IPv6 sub-nets. 126 o That Apple improve Bonjour technology so that it will work in 127 scalable and supportable fashion in large enterprise wireless and 128 wired networks. 130 The Educause petition [EP] asked that any enterprise Airplay / 131 Bonjour solution needs to meet the following criteria: 133 o It must scale to a range of hundreds to thousands of Airplay and 134 Bonjour enabled devices in a given environment. 136 o It must work with wired and wireless networks from different 137 vendors. 139 o It must not significantly negatively impact network traffic (wired 140 and wireless). 142 o It must be easily manageable at an enterprise scale. 144 o If it requires a separate hardware solution, that the solution 145 must be enterprise grade (rack mountable, dual power supplies, 146 etc.) 148 o It must be provided at a reasonable cost. 150 2.2. Low Power and Lossy Networks (LLNs) 152 Emerging wireless mesh networking technologies such as RPL/6LoWPAN 153 [RFC4944] [RFC6550] present several challenges for the current DNS- 154 SD/mDNS design. First, "local link" is defined as a node's one-hop 155 neighbors. This effectively means that a mesh is a multi-link 156 single-prefix subnet and that link-local multicast scope is 157 insufficient to span it. 159 Not only is subnet-scoped multicast difficult on such networks, but 160 low-power nodes may be offline for significant periods either because 161 they are "sleeping" or due to connectivity problems. In such cases 162 LLN nodes might fail to defend their names using the current design. 164 2.3. Fine-grained Discovery 166 As an illustration of this issue, consider a web server that exposes 167 several resources, each with a unique URI, at the same port. MDNSEXT 168 will consider whether implementing a fine-grained service discovery 169 mechanism is in scope. 171 2.4. Deployment Scenarios 173 The MDNSEXT working group will develop service discovery solutions 174 suitable for: 176 a. Enterprise networks 178 b. Academic/Educational/University networks 180 c. Multi-link home networks, such as those envisaged by HOMENET* 182 d. Multi-link/single prefix (mesh) networks, such as RPL/6LoWPAN LLNs 184 * It is intended that MDNSEXT develop a DNS-based solution that is 185 suitable for these four network environments, including the HOMENET 186 case. Of course, the HOMENET WG is free to evaluate whether or not 187 to adopt the MDNSEXT solution or develop an alternative. 189 3. Requirements 191 REQ01: Enable discovery of services across multiple links. 193 REQ02: Zero configuration operation possible, but not mandatory. 194 - i.e. Zero configuration operation is supported by the protocols, 195 but administrative control is also available on networks where that 196 is desired. 198 REQ03: Scalability, in terms of: 199 - Network traffic 200 - CPU and memory requirements on network entities 201 - User interface (huge flat list is not user friendly) 202 - Having a smooth continuum of operation from local link to site to 203 global, rather than vastly different incompatible modes of 204 operation at different network scales 205 - Granularity of services available on a server (extend the notion of 206 service?) 208 REQ04: Suitable for both local (zero-config) and global (minimal 209 config) use. 210 - i.e. Suitable out-of-the box defaults should enable zero- 211 configuration use on many small- to medium-sized networks, while 212 still allowing for administrative control in networks where that's 214 REQ05: Incremental deployability. 215 - Identify what changes to existing network elements will be 216 required, and attempt to minimize those changes. 217 - Don't break existing DNS-SD/mDNS functionality and devices 219 4. IANA Considerations 221 This document currently makes no request of IANA. 223 Note to RFC Editor: this section may be removed on publication as an 224 RFC. 226 5. Security Considerations 228 [TBD] 230 6. Acknowledgments 232 We gratefully acknowledge contributions and review comments made by 233 Tim Chown, Educause, Ralph Droms, and Thomas Narten. 235 7. References 237 7.1. Normative References 239 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 240 "Transmission of IPv6 Packets over IEEE 802.15.4 241 Networks", RFC 4944, September 2007. 243 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 244 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 245 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 246 Lossy Networks", RFC 6550, March 2012. 248 7.2. Informative References 250 [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service 251 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 252 progress), December 2011. 254 [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", 255 draft-cheshire-dnsext-multicastdns-15 (work in progress), 256 December 2011. 258 [EP] "Educause Petition", https://www.change.org/petitions/ 259 from-educause-higher-ed-wireless-networking-admin-group, 260 July 2012. 262 Authors' Addresses 264 Kerry Lynn (editor) 265 Consultant 267 Phone: +1 978 460 4253 268 Email: kerlyn@ieee.org 270 Stuart Cheshire 271 Apple, Inc. 272 1 Infinite Loop 273 Cupertino, California 95014 274 USA 276 Phone: +1 408 974 3207 277 Email: cheshire@apple.com