DNS-SD/mDNS Extensions K. Lynn, Ed. Internet-Draft Consultant Intended status: Informational S. Cheshire Expires: April 13, 2013 Apple, Inc. October 10, 2012 Requirements for DNS-SD/mDNS Extensions draft-lynn-mdnsext-requirements-00 Abstract DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there is market demand to extend DNS-SD/mDNS to enable service discovery beyond the local link. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 13, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lynn & Cheshire Expires April 13, 2013 [Page 1] Internet-Draft MDNSEXT Requirements October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Lynn & Cheshire Expires April 13, 2013 [Page 2] Internet-Draft MDNSEXT Requirements October 2012 1. Introduction The DNS-SD/mDNS Extensions Working Group (MDNSEXT) will develop extensions to DNS-Based Service Discovery [DNS-SD] and Multicast DNS [mDNS] protocols to enable service discovery beyond the local link. DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link. In principle DNS-SD can also be used in conjunction with conventional unicast DNS to enable wide-area service discovery, but in practice this capability is not widely used. This disconnect between customer needs and current practice has led to calls for improvement, such as the Educause petition [EP]. In response to this and similar evidence of market demand, several companies have recently announced "Bonjour gateway" products that allow service discovery beyond the local link. However, these were brought to market rapidly and it's unclear whether they represent the best long-term direction for service discovery protocol development. Similarly, DNS-SD/mDNS in its present form is not well suited for emerging technologies such as multi-link subnets like 6LoWPAN where "link local" is defined as a node's first-hop neighbors, subnet- scoped multicast is problematic, and battery powered devices may be offline for significant periods of time. For these and other reasons, it is therefore beneficial for end users, network operators, vendors, and for the long-term health of the Internet to bring this work into the IETF where all interested parties can cooperate to develop efficient and scalable solutions. This document defines the problem statement and gathers requirements for DNS-SD/mDNS Extensions. 2. Problem Statement There is no single problem statement that motivates the need to extend DNS-SD/mDNS, but "service discovery beyond the local link" comes closest. What follows is a roughly prioritized list of issues. 2.1. Multilink Naming and Discovery While DNS-SD/mDNS is well-suited for zero-configuration of naming and discovery of hosts and services on a local link, users are frustrated by the inability to discover services on other subnets. DNS-SD is a conventional use of existing DNS Resource Records and can, in practice, be deployed over unicast DNS. However, this mode Lynn & Cheshire Expires April 13, 2013 [Page 3] Internet-Draft MDNSEXT Requirements October 2012 is not commonly used. This resulted in a call from network administrators in the form of the Educause petition [EP]. Some highlights from that petition included: o Airplay does not work when Apple TV's and Apple client devices are on different IP subnets. It is common for the enterprise wireless and wired networks in our institutions to utilize different IP subnets. o Students are requesting the ability to utilize Airprint to print from their Apple devices on our enterprise networks. o That Apple establish a way for Apple TV's be accessible from Apple's client devices across multiple IPv4 and IPv6 sub-nets. o That Apple improve Bonjour technology so that it will work in scalable and supportable fashion in large enterprise wireless and wired networks. The Educause petition [EP] asked that any enterprise Airplay / Bonjour solution needs to meet the following criteria: o It must scale to a range of hundreds to thousands of Airplay and Bonjour enabled devices in a given environment. o It must work with wired and wireless networks from different vendors. o It must not significantly negatively impact network traffic (wired and wireless). o It must be easily manageable at an enterprise scale. o If it requires a separate hardware solution, that the solution must be enterprise grade (rack mountable, dual power supplies, etc.) o It must be provided at a reasonable cost. 2.2. Low Power and Lossy Networks (LLNs) Emerging wireless mesh networking technologies such as RPL/6LoWPAN [RFC4944] [RFC6550] present several challenges for the current DNS- SD/mDNS design. First, "local link" is defined as a node's one-hop neighbors. This effectively means that a mesh is a multi-link single-prefix subnet and that link-local multicast scope is Lynn & Cheshire Expires April 13, 2013 [Page 4] Internet-Draft MDNSEXT Requirements October 2012 insufficient to span it. Not only is subnet-scoped multicast difficult on such networks, but low-power nodes may be offline for significant periods either because they are "sleeping" or due to connectivity problems. In such cases LLN nodes might fail to defend their names using the current design. 2.3. Fine-grained Discovery As an illustration of this issue, consider a web server that exposes several resources, each with a unique URI, at the same port. MDNSEXT will consider whether implementing a fine-grained service discovery mechanism is in scope. 2.4. Deployment Scenarios The MDNSEXT working group will develop service discovery solutions suitable for: a. Enterprise networks b. Academic/Educational/University networks c. Multi-link home networks, such as those envisaged by HOMENET* d. Multi-link/single prefix (mesh) networks, such as RPL/6LoWPAN LLNs * It is intended that MDNSEXT develop a DNS-based solution that is suitable for these four network environments, including the HOMENET case. Of course, the HOMENET WG is free to evaluate whether or not to adopt the MDNSEXT solution or develop an alternative. Lynn & Cheshire Expires April 13, 2013 [Page 5] Internet-Draft MDNSEXT Requirements October 2012 3. Requirements REQ01: Enable discovery of services across multiple links. REQ02: Zero configuration operation possible, but not mandatory. - i.e. Zero configuration operation is supported by the protocols, but administrative control is also available on networks where that is desired. REQ03: Scalability, in terms of: - Network traffic - CPU and memory requirements on network entities - User interface (huge flat list is not user friendly) - Having a smooth continuum of operation from local link to site to global, rather than vastly different incompatible modes of operation at different network scales - Granularity of services available on a server (extend the notion of service?) REQ04: Suitable for both local (zero-config) and global (minimal config) use. - i.e. Suitable out-of-the box defaults should enable zero- configuration use on many small- to medium-sized networks, while still allowing for administrative control in networks where that's REQ05: Incremental deployability. - Identify what changes to existing network elements will be required, and attempt to minimize those changes. - Don't break existing DNS-SD/mDNS functionality and devices 4. IANA Considerations This document currently makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations [TBD] 6. Acknowledgments We gratefully acknowledge contributions and review comments made by Tim Chown, Educause, Ralph Droms, and Thomas Narten. Lynn & Cheshire Expires April 13, 2013 [Page 6] Internet-Draft MDNSEXT Requirements October 2012 7. References 7.1. Normative References [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 7.2. Informative References [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-11 (work in progress), December 2011. [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-15 (work in progress), December 2011. [EP] "Educause Petition", https://www.change.org/petitions/ from-educause-higher-ed-wireless-networking-admin-group, July 2012. Authors' Addresses Kerry Lynn (editor) Consultant Phone: +1 978 460 4253 Email: kerlyn@ieee.org Stuart Cheshire Apple, Inc. 1 Infinite Loop Cupertino, California 95014 USA Phone: +1 408 974 3207 Email: cheshire@apple.com Lynn & Cheshire Expires April 13, 2013 [Page 7]