Requirements for DNS-SD/mDNS Extensions
draft-lynn-mdnsext-requirements-00

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]