[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 draft-lynn-dnssd-requirements

DNS-SD/mDNS Extensions                                      K. Lynn, Ed.
Internet-Draft                                                Consultant
Intended status: Informational                               S. Cheshire
Expires: January 17, 2014                                    Apple, Inc.
                                                           July 16, 2013


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

Abstract

   DNS-SD/mDNS is widely used today for discovery and resolution of
   services and names on a local link, but there are use cases to extend
   DNS-SD/mDNS to enable service discovery beyond the local link.  This
   document provides a problem statement and a list of requirements.

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 January 17, 2014.

Copyright Notice

   Copyright (c) 2013 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 January 17, 2014                [Page 1]

Internet-Draft            DNSSDEXT Requirements                July 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Internationalization Considerations . . . . . . . . . . . . .   5
   5.  Namespace Considerations  . . . . . . . . . . . . . . . . . .   5
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   DNS-based service discovery [DNS-SD]/[mDNS] is widely used today for
   discovery and resolution of services and names on a local link.
   However, as users move to multi-link home or campus networks they
   find that mDNS does work across routers.  DNS-SD can also be used in
   conjunction with conventional unicast DNS to enable wide-area service
   discovery, but this capability is not yet widely deployed.  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
   products now enable service discovery beyond the local link using
   different ad-hoc techniques.  However, it's unclear which approach
   represents the best long-term direction for DNS-based service
   discovery protocol development.

   DNS-SD/mDNS in its present form is also not optimized for network
   technologies where multicast transmissions are relatively expensive.
   Wireless networks such as [IEEE.802.11] may be adversely affected by
   excessive mDNS traffic due to the higher network overhead of
   multicast transmissions.  Wireless mesh networks such as 6LoWPAN are
   effectively multi-link subnets where multicasts must be routed by
   intermediate nodes.

   It is in the best interests of end users, network administrators, and
   vendors for all interested parties to cooperate within the context of
   the IETF to develop an efficient, scalable, and interoperable
   standards-based solution.

   This document defines the problem statement and gathers requirements
   for DNS-SD/mDNS Extensions.





Lynn & Cheshire         Expires January 17, 2014                [Page 2]

Internet-Draft            DNSSDEXT Requirements                July 2013


2.  Problem Statement

   Service discovery beyond the local link is probably the most
   important feature missing currently in the DNS-SD/mDNS framework.
   The following describes some of the issues.

2.1.  Multilink Naming and Discovery

   A list of desired DNS-SD/mDNS improvements from network
   administrators in the research and education community was issued in
   the form of the Educause petition [EP].  The following is a technical
   summary of the issues:

   o  Current products advertising services such as printing and
      multimedia streaming via DNS-SD/mDNS do not work when devices are
      on different links.  It is common for enterprise-grade wireless
      and wired networks in the institutions to utilize different links.
      DNS-SD used with conventional unicast DNS does work when devices
      are on different links, but the records need to get into the
      unicast DNS namespace somehow.

   o  Entering DNS-SD records manually into a unicast DNS zone file
      works, (as has been done for many years for the Terminal Room
      printers at IETF meetings) but requires the DNS administrator to
      know how to do that [static] and is fragile when IP address of
      devices may change, as is common when DHCP is used.

   o  Automatically adding DNS-SD records using DNS Update works, but
      requires that the DNS server be configured to allow DNS Updates,
      and requires that devices be configured with the DNS Update
      credentials to permit such updates, which has proved to be overly
      onerous.

   o  Therefore, a mechanism is desired that populates the unicast DNS
      namespace with the appropriate DNS-SD records with less manual
      administration.

   The following is a technical summary of the requirements:

   o  It must scale to a range of hundreds or thousands of DNS-SD/mDNS
      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
      or wireless).




Lynn & Cheshire         Expires January 17, 2014                [Page 3]

Internet-Draft            DNSSDEXT Requirements                July 2013


   o  It must be easily manageable at an enterprise scale.

   o  If it requires a separate hardware solution, the solution must be
      enterprise grade (rack mountable, dual power supplies, etc.)

   o  It must be provided at a reasonable cost.

2.2.  Wireless LANs

   Multicast DNS was originally designed to run on Ethernet - the
   dominant link-layer at the time.  In shared Ethernet networks,
   multicast frames place little additional demand on the shared network
   medium above unicast frames.  In IEEE 802.11 networks however,
   multicast frames are transmitted at a low data rate supported by all
   receivers.  In practice, this data rate is often very low and leads
   to a larger fraction of airtime being devoted to multicast
   transmission.  Some network administrators block multicast traffic or
   convert it to a series of link-layer unicast frames.

   To improve transmission reliability, the IEEE 802.11 MAC requires
   positive acknowledgement of unicast frames.  It does not however,
   require positive acknowledgement of multicast frames.  As a result,
   it is common to observe much higher loss of multicast frames on
   802.11 than other IEEE 802 network technologies.

   Enabling service discovery on IEEE 802.11 networks requires that the
   number of multicast frames be restricted to a suitably low value, or
   replaced with unicast frames to use the MAC's reliability features.

2.3.  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
   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 respond to queries or defend their names
   using the current design.

3.  Use Cases






Lynn & Cheshire         Expires January 17, 2014                [Page 4]

Internet-Draft            DNSSDEXT Requirements                July 2013


   The following use cases are defined with different constraints to
   help distinguish and classify the target requirements.  [This is a
   strawman proposal.  MB]

      (A) Personal Area networks, e.g., one laptop and one printer.
      This is the simplest example of an mDNS network.

      (B) Home networks, consisting of:

      *  Single exit router: the network may have multiple upstream
         providers or networks, but all outgoing and incoming trafic
         goes through a single router.

      *  One level depth: all links on the network are connected to the
         same default router.

      *  Single administrative domain: all nodes under the same admin
         entity.

      (C) Like B but may have a tree of links behind the single exit
      router.  However, the forwarding nodes are almost self-configured
      and do not require routing protocol administrators.

      (D) Enterprise networks, consisting of:

      *  Any depth of the forwarding tree, under a single administrative
         domain.  The large majority of the forwarding and security
         devices are configured.

      (E) Higher Education networks, consisting of:

      *  Any depth of the forwarding tree, core network under a central
         administrative domain but leaf networks under multiple
         administrative entities.  The large majority of the forwarding
         and security devices are configured.

      (F) Mesh networks such as RPL/6LoWPAN, multi-link but single
      prefix networks.

4.  Internationalization Considerations

   The solution should support rich international text, as do DNS-SD and
   mDNS today.  Users will not accept a solution that does not allow the
   richness of service naming that they currently have with mDNS, manual
   zone files, and DNS Update today.

5.  Namespace Considerations




Lynn & Cheshire         Expires January 17, 2014                [Page 5]

Internet-Draft            DNSSDEXT Requirements                July 2013


   The unicast DNS namespace is (somewhat) global.  Naming services over
   a local scope is local.  Clients discovering services need to be able
   to differentiate global names from local names.

6.  Requirements

   [This is a strawman proposal.  MB]

   REQ1:  The scope of the discovery should be either automatically
      found by the discovering devices and/or configured.

   REQ2:  For use cases A, B and C, there should be a zero configuration
      operation.

   REQ3:  For use cases D and E, there should be a way to configure the
      scope of the discovery and also support both smaller (ex:
      department) and larger (ex: campus-wide) discovery.

   REQ4:  For use cases D and E, there should be an incremental way to
      deploy the solution.

   REQ5:  The new solution should integrate or at least should not break
      any current link scope DNS-SD/mDNS protocols and deployments.

7.  IANA Considerations

   This document currently makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

   [Not complete - initial ideas.  MB]

   If the scope of the discovery is not properly setup or constrained,
   then information leaks will happen outside the appropriate network.

   Visiting nodes on a network may discover more services than desired
   by the network policies, if filtering of discovery packets was not
   properly setup.  [Is this a NAC or DNS problem?  KL]

   Depending on the chosen solution, there is a possibility of name
   space conflicts between the DNS tree and this solution.  In this
   case, a node may not know if the target node or service is the right
   one, therefore enabling ground for various attacks.

   The [DNS-SD]/[mDNS] framework security considerations also apply.



Lynn & Cheshire         Expires January 17, 2014                [Page 6]

Internet-Draft            DNSSDEXT Requirements                July 2013


9.  Acknowledgments

   We gratefully acknowledge contributions and review comments made by
   Marc Blanchet, Tim Chown, Ralph Droms, Educause, Matthew Gast, and
   Thomas Narten.














































Lynn & Cheshire         Expires January 17, 2014                [Page 7]

Internet-Draft            DNSSDEXT Requirements                July 2013


10.  References

10.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.

   [mDNS]     Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [DNS-SD]   Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

10.2.  Informative References

   [EP]       "Educause Petition", https://www.change.org/petitions/
              from-educause-higher-ed-wireless-networking-admin-group,
              July 2012.

   [IEEE.802.11]
              "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications ", IEEE Std 802.11-2012, 2012,
              <http://standards.ieee.org/getieee802/download/
              802.11-2012.pdf>.

   [static]   "Manually Adding DNS-SD Service Discovery Records to an
              Existing Name Server", July 2013,
              <http://www.dns-sd.org/ServerStaticSetup.html>.

Authors' Addresses

   Kerry Lynn (editor)
   Consultant

   Phone: +1 978 460 4253
   Email: kerlyn@ieee.org






Lynn & Cheshire         Expires January 17, 2014                [Page 8]

Internet-Draft            DNSSDEXT Requirements                July 2013


   Stuart Cheshire
   Apple, Inc.
   1 Infinite Loop
   Cupertino , California   95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com











































Lynn & Cheshire         Expires January 17, 2014                [Page 9]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/