draft-ietf-dnssd-requirements-02.txt   draft-ietf-dnssd-requirements-03.txt 
DNS-SD/mDNS Extensions K. Lynn, Ed. DNS-SD/mDNS Extensions K. Lynn, Ed.
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Informational S. Cheshire Intended status: Informational S. Cheshire
Expires: December 12, 2014 Apple, Inc. Expires: January 5, 2015 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
D. Migault D. Migault
Orange Orange
June 10, 2014 July 4, 2014
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-SD/mDNS Extensions
draft-ietf-dnssd-requirements-02 draft-ietf-dnssd-requirements-03
Abstract Abstract
DNS-SD/mDNS is widely used today for discovery and resolution of 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 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 DNS-SD/mDNS to enable service discovery beyond the local link. This
document provides a problem statement and a list of requirements. document provides a problem statement and a list of requirements.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Namespace Considerations . . . . . . . . . . . . . . . . . . 7 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
DNS-Based Service Discovery [DNS-SD] in combination with its DNS-Based Service Discovery [DNS-SD] in combination with its
companion technology Multicast DNS [mDNS] is widely used today for companion technology Multicast DNS [mDNS] is widely used today for
discovery and resolution of services and names on a local link. discovery and resolution of services and names on a local link.
However, as users move to multi-link home or campus networks they However, as users move to multi-link home or campus networks they
find that mDNS does not work across routers. DNS-SD can also be used find that mDNS does not work across routers. DNS-SD can also be used
in conjunction with conventional unicast DNS to enable wide-area in conjunction with conventional unicast DNS to enable wide-area
skipping to change at page 5, line 47 skipping to change at page 5, line 47
help motivate, distinguish, and classify the target requirements. help motivate, distinguish, and classify the target requirements.
They cover a spectrum of increasing deployment and administrative They cover a spectrum of increasing deployment and administrative
complexity. complexity.
(A) Personal Area networks (PANs): the simplest example of a (A) Personal Area networks (PANs): the simplest example of a
network may consist of a single client and server, e.g., one network may consist of a single client and server, e.g., one
laptop and one printer, on a common link. PANs that do not laptop and one printer, on a common link. PANs that do not
contain a router may use Zero Configuration to assign network contain a router may use Zero Configuration to assign network
addresses and mDNS to provide naming and service discovery. addresses and mDNS to provide naming and service discovery.
(B) Classic home networks, consisting of: (B) Classic home or 'hotspot' networks, consisting of:
* Single exit router: the network may have multiple upstream * Single exit router: the network may have multiple upstream
providers or networks, but all outgoing and incoming traffic providers or networks, but all outgoing and incoming traffic
goes through a single router. goes through a single router.
* One-level depth: multiple links on the network are bridged to * One-level depth: multiple links on the network are bridged to
form a single subnet, which is connected to the default router. form a single subnet, which is connected to the default router.
* Single administrative domain: all nodes under the same admin * Single administrative domain: all nodes under the same admin
entity. (However, this does not necessarily imply a network entity. (However, this does not necessarily imply a network
skipping to change at page 6, line 25 skipping to change at page 6, line 25
Like B but consist of multiple wired and/or wireless links, Like B but consist of multiple wired and/or wireless links,
connected by routers, behind the single exit router. However, the connected by routers, behind the single exit router. However, the
forwarding nodes are largely self-configuring and do not require forwarding nodes are largely self-configuring and do not require
routing protocol administration. Such networks should also not routing protocol administration. Such networks should also not
require DNS administration. require DNS administration.
(D) Enterprise networks: (D) Enterprise networks:
Like C but consist of arbitrary network diameter under a single Like C but consist of arbitrary network diameter under a single
administrative domain. A large majority of the forwarding and administrative domain. A large majority of the forwarding and
security devices are configured. security devices are configured. Large-scale conference-style
networks, which are predominantly wireless access, e.g., as
available at IETF meetings, also fall within this category.
(E) Higher Education networks: (E) Higher Education networks:
Like D but the core network may be under a central administrative Like D but the core network may be under a central administrative
domain while leaf networks are under local administrative domains. domain while leaf networks are under local administrative domains.
(F) Mesh networks such as RPL/6LoWPAN: (F) Mesh networks such as RPL/6LoWPAN:
Multi-link subnets with prefixes defined by one or more border Multi-link subnets with prefixes defined by one or more border
routers. May comprise any part of networks C, D, or E. routers. May comprise any part of networks C, D, or E.
4. Requirements 4. Requirements
Any successful SSD solution(s) will have to strike the proper balance Any successful SSD solution(s) will have to strike the proper balance
between competing goals such as scalability, deployability, and between competing goals such as scalability, deployability, and
usability. With that in mind, none of the requirements listed below usability. With that in mind, none of the requirements listed below
should be considered in isolation. should be considered in isolation.
REQ1: For use cases A, B, and C, there should be a Zero REQ1: For use cases A, B, and C, there should be a Zero
Configuration mode of operation. This implies that devices Configuration mode of operation. This implies that servers
should be able to automatically determine a default Scope of and clients should be able to automatically determine a
Discovery in which to advertise and discover services. default Scope of Discovery in which to advertise and discover
services, respectively.
REQ2: For use cases C, D, and E, there should be a way to configure REQ2: For use cases C, D, and E, there should be a way to configure
Scopes of Discovery that support a range of topologically- Scopes of Discovery that support a range of topologically-
independent zones (e.g., from department to campus-wide). If independent zones (e.g., from department to campus-wide). If
multiple scopes are available, there must be a way to multiple scopes are available, there must be a way to
enumerate the choices from which a selection can be made. enumerate the choices from which a selection can be made.
REQ3: For use cases C, D, and E, there should be an incremental way REQ3: As stated in REQ2 above, the discovery scope need not be
to deploy the solution. aligned to network topology. For example, it may instead be
aligned to physical proximity or organizational structure.
REQ4: SSD should integrate or at least should not break any current REQ4: For use cases C, D, and E, there should be an incremental way
link scope DNS-SD/mDNS protocols and deployments. SSD must to deploy the solution.
not adversely affect any other protocol.
REQ5: SSD must be capable of spanning multiple links (hops) and REQ5: SSD should integrate with current link scope DNS-SD/mDNS
network technologies. protocols and deployments.
REQ6: SSD must be scalable to thousands of nodes with minimal REQ6: SSD must not adversely affect or break any other current
configuration and without degrading network performance. A protocols or deployments.
possible figure of merit is that, as the number of services
increases, the amount of traffic due to SSD on a given link
remains relatively constant.
REQ7: SSD should enable a way to provide a consistent user REQ7: SSD must be capable of operating across networks that are not
experience whether local or global services are being limited to a single link or network technology, including
discovered. clients and services on non-adjacent links.
REQ8: The information presented by SSD should reflect reality. That REQ8: It is desirable that a user or device, when away from such a
is, new information should be available in a timely fashion site, is still able to discover services within that site,
and stale information should not persist. e.g., a user discovering services in their home network while
remote from it.
REQ9: SSD should operate efficiently in all networks, with
particular consideration for potentially lossy or multicast-
challenged wireless networks.
REQ10: SSD should be considerate of networks where power consumption
is a critical factor and, for example, nodes may be in a low
power or sleeping state.
REQ11: SSD must be scalable to thousands of nodes with minimal
configuration and without degrading network performance. A
possible figure of merit is that, as the number of services
increases, the amount of traffic due to SSD on a given link
remains relatively constant.
REQ12: SSD should enable a way to provide a consistent user
experience whether local or global services are being
discovered.
REQ13: The information presented by SSD should reflect reality.
That is, new information should be available in a timely
fashion and stale information should not persist.
REQ14: SSD should operate over existing networks (as described by
use cases A-F above) without requiring changes to the network
technology or deployment.
5. Namespace Considerations 5. Namespace Considerations
The unicast DNS namespace contains globally unique names. The mDNS The unicast DNS namespace contains globally unique names. The mDNS
namespace contains locally unique names. Clients discovering namespace contains locally unique names. Clients discovering
services may need to differentiate between local and global names or services may need to differentiate between local and global names or
to determine that names in different namespaces identify the same to determine that names in different namespaces identify the same
service. service.
Multiple devices in different subnets may share the same label
(perhaps due to vendor defaults) or have similarly appearing labels.
This may lead to a local label disambiguation problem between
presented results.
SSD should support rich internationalized labels within Service SSD should support rich internationalized labels within Service
Instance Names, as DNS-SD/mDNS does today. SSD must not negatively Instance Names, as DNS-SD/mDNS does today. SSD must not negatively
impact the global DNS namespace or infrastructure. impact the global DNS namespace or infrastructure.
The problem of publishing local services in the global DNS namespace The problem of publishing local services in the global DNS namespace
may be generally viewed as exporting local resource records and their may be generally viewed as exporting local resource records and their
associated labels into some DNS zone. The issues related to defining associated labels into some DNS zone. The issues related to defining
labels that are interoperable between local and global namespaces are labels that are interoperable between local and global namespaces are
discussed in [I-D.sullivan-dnssd-mdns-dns-interop]. discussed in [I-D.sullivan-dnssd-mdns-dns-interop].
skipping to change at page 8, line 23 skipping to change at page 9, line 7
6.1. Scope of Discovery 6.1. Scope of Discovery
As mDNS is currently restricted to a single link, the scope of the As mDNS is currently restricted to a single link, the scope of the
advertisement is limited, by design, to the shared link between advertisement is limited, by design, to the shared link between
client and server. In a multi-link scenario, the owner of the client and server. In a multi-link scenario, the owner of the
advertised service may not have a clear indication of the scope of advertised service may not have a clear indication of the scope of
its advertisement. its advertisement.
If the advertisement propagates to a larger set of links than If the advertisement propagates to a larger set of links than
expected, this may result in unauthorized clients (from the expected, this may result in unauthorized clients (from the
perspective of the owner) connecting to the advertised service. It perspective of the owner) discovering and then potentially attempting
also discloses information (about the host and service) to a larger to connect to the advertised service. It also discloses information
set of potential attackers. (about the host and service) to a larger set of potential attackers.
Note that discovery of a service does not necessarily imply that the
service is reachable or can be connected to. Specific access control
mechanisms are out of scope of this document.
If the scope of the discovery is not properly setup or constrained, If the scope of the discovery is not properly setup or constrained,
then information leaks will happen outside the appropriate network. then information leaks will happen outside the appropriate network.
6.2. Multiple Namespaces 6.2. Multiple Namespaces
There is a possibility of conflicts between the local and global DNS There is a possibility of conflicts between the local and global DNS
namespaces. Without adequate feedback, a discovering client may not namespaces. Without adequate feedback, a discovering client may not
know if the advertised service is the correct one, therefore enabling know if the advertised service is the correct one, therefore enabling
potential attacks. potential attacks.
skipping to change at page 10, line 24 skipping to change at page 11, line 12
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013. February 2013.
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
9.2. Informative References 9.2. Informative References
[I-D.ietf-6man-multicast-scopes] [I-D.ietf-6man-multicast-scopes]
Droms, R., "IPv6 Multicast Address Scopes", draft-ietf- Droms, R., "IPv6 Multicast Address Scopes", draft-ietf-
6man-multicast-scopes-06 (work in progress), June 2014. 6man-multicast-scopes-07 (work in progress), June 2014.
[I-D.ietf-homenet-arch] [I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft- "IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-14 (work in progress), June 2014. ietf-homenet-arch-16 (work in progress), June 2014.
[I-D.sullivan-dnssd-mdns-dns-interop] [I-D.sullivan-dnssd-mdns-dns-interop]
Sullivan, A., "Requirements for Labels to Interoperate Sullivan, A., "Requirements for Labels to Interoperate
Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns- Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns-
interop-00 (work in progress), January 2014. interop-00 (work in progress), January 2014.
[EP] "Educause Petition", https://www.change.org/petitions/ [EP] "Educause Petition", https://www.change.org/petitions/
from-educause-higher-ed-wireless-networking-admin-group, from-educause-higher-ed-wireless-networking-admin-group,
July 2012. July 2012.
 End of changes. 20 change blocks. 
42 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/