draft-ietf-dnssd-requirements-06.txt   rfc7558.txt 
DNS-SD/mDNS Extensions K. Lynn Internet Engineering Task Force (IETF) K. Lynn
Internet-Draft Verizon Request for Comments: 7558 Verizon Labs
Intended status: Informational S. Cheshire Category: Informational S. Cheshire
Expires: September 20, 2015 Apple, Inc. ISSN: 2070-1721 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
D. Migault D. Migault
Ericsson Ericsson
March 19, 2015 July 2015
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-Based Service
draft-ietf-dnssd-requirements-06 Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions
Abstract Abstract
DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is
widely used today for discovery and resolution of services and names 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 on a local link, but there are use cases to extend DNS-SD/mDNS to
enable service discovery beyond the local link. This document enable service discovery beyond the local link. This document
provides a problem statement and a list of requirements. provides a problem statement and a list of requirements for scalable
DNS-SD.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 20, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7558.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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. As
However, as users move to multi-link home or campus networks they users move to multi-link home or campus networks, however, they find
find that mDNS (by design) does not work across routers. DNS-SD can that mDNS (by design) does not work across routers. DNS-SD can also
also be used in conjunction with conventional unicast DNS to enable be used in conjunction with conventional unicast DNS to enable
wide-area service discovery, but this capability is not yet widely wide-area service discovery, but this capability is not yet widely
deployed. This disconnect between customer needs and current deployed. This disconnect between customer needs and current
practice has led to calls for improvement, such as the Educause practice has led to calls for improvement, such as the Educause
petition [EP]. petition [EP].
In response to this and similar evidence of market demand, several In response to this and similar evidence of market demand, several
products now enable service discovery beyond the local link using products now enable service discovery beyond the local link using
different ad hoc techniques. As yet, no consensus has emerged different ad hoc techniques. As of yet, no consensus has emerged
regarding which approach represents the best long-term direction for regarding which approach represents the best long-term direction for
DNS-based service discovery protocol development. DNS-based Service Discovery protocol development.
Multicast DNS in its present form is also not optimized for network Multicast DNS in its present form is also not optimized for network
technologies where multicast transmissions are relatively expensive. technologies where multicast transmissions are relatively expensive.
Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely
affected by excessive mDNS traffic due to the higher network overhead affected by excessive mDNS traffic due to the higher network overhead
of multicast transmissions. Wireless mesh networks such as 6LoWPAN of multicast transmissions. Wireless mesh networks such as IPv6 over
[RFC4944] are effectively multi-link subnets [RFC4903] where Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944] are
multicasts must be forwarded by intermediate nodes. effectively multi-link subnets [RFC4903] where multicasts must be
forwarded by intermediate nodes.
It is in the best interests of end users, network administrators, and It is in the best interests of end users, network administrators, and
vendors for all interested parties to cooperate within the context of vendors for all interested parties to cooperate within the context of
the IETF to develop an efficient, scalable, and interoperable the IETF to develop an efficient, scalable, and interoperable
standards-based solution. standards-based solution.
This document defines the problem statement and gathers requirements This document defines the problem statement and gathers requirements
for Scalable DNS-SD/mDNS Extensions. for scalable DNS-SD/mDNS extensions.
1.1. Terminology and Acronyms 1.1. Terminology and Acronyms
Service: A listening endpoint (host and port) for a given application Service: A listening endpoint (host and port) for a given application
protocol. Services are identified by Service Instance Names. protocol. Services are identified by Service Instance Names.
DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional DNS-SD: DNS-based Service Discovery [DNS-SD] is a conventional
application of DNS Resource Records and messages to facilitate the application of DNS resource records and messages to facilitate the
naming, discovery, and location of services. When used alone, it naming, discovery, and location of services. When used alone, the
generally refers to the wide-area unicast protocol. term generally refers to the wide-area unicast protocol.
mDNS: Multicast DNS [mDNS] is a mechanism that facilitates mDNS: Multicast DNS [mDNS] is a mechanism that facilitates
distributed DNS-like capabilities (including DNS-SD) on a local link distributed DNS-like capabilities (including DNS-SD) on a local link
without need of traditional DNS infrastructure. without need of traditional DNS infrastructure.
SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future
extension of DNS-SD (and perhaps mDNS) that meets the requirements extension of DNS-SD (and perhaps mDNS) that meets the requirements
set forth in this document. set forth in this document.
Scope of Discovery: A subset of a local or global namespace, e.g., a Scope of Discovery: A subset of a local or global namespace, e.g., a
skipping to change at page 4, line 5 skipping to change at page 4, line 19
written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and
requirements are summarized below. requirements are summarized below.
2.1. Multi-link Naming and Discovery 2.1. Multi-link Naming and Discovery
A list of desired DNS-SD/mDNS improvements from network A list of desired DNS-SD/mDNS improvements from network
administrators in the research and education community was issued in administrators in the research and education community was issued in
the form of the Educause petition [EP]. The following is a summary the form of the Educause petition [EP]. The following is a summary
of their technical issues: of their technical issues:
o Products that advertise services such as printing and multimedia o It is common practice for enterprises and institutions to use
wireless links for client access and wired links for server
infrastructure; typically, they are on different subnets.
Products that advertise services such as printing and multimedia
streaming via DNS-SD over mDNS are not currently discoverable by streaming via DNS-SD over mDNS are not currently discoverable by
devices on other links. It is common practice for enterprises and client devices on other links. DNS-SD used with conventional
institutions to use wireless links for client access to wired unicast DNS does work when servers and clients are on different
networks and server infrastructure, typically on other subnets. links, but the resource records that describe the services must
DNS-SD used with conventional unicast DNS does work when devices somehow be entered into the unicast DNS namespace.
are on different links, but the resource records that describe the
service must somehow be entered into the unicast DNS namespace.
o DNS-SD resource records may be entered manually into a unicast DNS o DNS-SD resource records may be entered manually into a unicast DNS
zone file [STATIC], but this task must be performed by a DNS zone file [STATIC], but this task must be performed by a DNS
administrator. It is labor-intensive and brittle when IP administrator. It is labor intensive and brittle when IP
addresses of devices change dynamically, as is common when DHCP is addresses of devices change dynamically, as is common when DHCP is
used. used.
o Automatically adding DNS-SD records using DNS Update works, but o Automatically adding DNS-SD records using DNS Update works, but it
requires that the DNS server be configured to allow DNS Updates, requires that the DNS server be configured to allow DNS Updates
and requires that devices be configured with the DNS Update and that devices be configured with the DNS Update credentials to
credentials to permit such updates, which has proven to be permit such updates, which has proven to be onerous.
onerous.
Therefore, a mechanism is desired that populates the DNS namespace Therefore, a mechanism is desired that populates the DNS namespace
with the appropriate DNS-SD records with less manual administration with the appropriate DNS-SD records with less manual administration
than typically needed for a unicast DNS server. than is typically needed for a conventional unicast DNS server.
The following is a summary of their technical requirements: The following is a summary of technical requirements:
o It must scale to a range of hundreds to thousands of DNS-SD/mDNS- o It must scale to a range of hundreds to thousands of DNS-SD/mDNS-
enabled devices in a given environment. enabled devices in a given environment.
o It must simultaneously operate over a variety of network link o It must simultaneously operate over a variety of network link
technologies, such as wired and wireless networks. technologies, such as wired and wireless networks.
o It must not significantly increase network traffic (wired or o It must not significantly increase network traffic (wired or
wireless). wireless).
o It must be cost-effective to manage at up to enterprise scale. o It must be cost-effective to manage at up to enterprise scale.
2.2. IEEE 802.11 Wireless LANs 2.2. IEEE 802.11 Wireless LANs
Multicast DNS was originally designed to run on Ethernet - the Multicast DNS was originally designed to run on Ethernet - the
dominant link-layer at the time. In shared Ethernet networks, dominant link layer at the time. In shared-medium Ethernet networks,
multicast frames place little additional demand on the shared network multicast frames place little additional demand on the shared network
medium compared to unicast frames. In IEEE 802.11 networks however, medium compared to unicast frames. In IEEE 802.11 networks, however,
multicast frames are transmitted at a low data rate supported by all multicast frames are transmitted at a low data rate supported by all
receivers. In practice, this data rate leads to a larger fraction of receivers. In practice, this data rate leads to a larger fraction of
airtime being devoted to multicast transmission. Some network airtime being devoted to multicast transmission. Some network
administrators block multicast traffic, or use access points that administrators block multicast traffic or use access points that
transmit multicast frames using a series of link-layer unicast transmit multicast frames using a series of link-layer unicast
frames. frames.
Wireless links may be orders of magnitude less reliable than their Wireless links may be orders of magnitude less reliable than their
wired counterparts. To improve transmission reliability, the IEEE wired counterparts. To improve transmission reliability, the IEEE
802.11 MAC requires positive acknowledgement of unicast frames. It 802.11 Medium Access Control (MAC) requires positive acknowledgement
does not, however, support positive acknowledgement of multicast of unicast frames. It does not, however, support positive
frames. As a result, it is common to observe much higher loss of acknowledgement of multicast frames. As a result, it is common to
multicast frames on wireless as compared to wired network observe higher loss rates of multicast frames on wireless network
technologies. technologies than on wired network technologies.
Enabling service discovery on IEEE 802.11 networks requires that the Enabling service discovery on IEEE 802.11 networks requires that the
number of multicast frames be restricted to a suitably low value, or number of multicast frames be restricted to a suitably low value or
replaced with unicast frames to use the MAC's reliability features. replaced with unicast frames to use the MAC's reliability features.
2.3. Low Power and Lossy Networks (LLNs) 2.3. Low-Power and Lossy Networks (LLNs)
Emerging wireless mesh networking technologies such as RPL [RFC6550] Emerging wireless mesh networking technologies such as the Routing
and 6LoWPAN present several challenges for the current DNS-SD/mDNS Protocol for LLNs (RPL) [RFC6550] and 6LoWPAN present several
design. First, Link-Local multicast scope [RFC4291] is defined as a challenges for the current DNS-SD/mDNS design. First, link-local
single-hop neighborhood. A wireless mesh network representing a multicast scope [RFC4291] is defined as a single-hop neighborhood. A
single logical subnet may often extend to multiple hops [RFC4903], wireless mesh network representing a single logical subnet may often
therefore a larger multicast scope is required to span it [RFC7346]. extend to multiple hops [RFC4903]; therefore, a larger multicast
Multicast DNS was intentionally not specified for greater than Link- scope is required to span it [RFC7346]. Multicast DNS was
Local scope, because of the additional off-link multicast traffic intentionally not specified for greater than link-local scope because
that would generate. of the additional off-link multicast traffic that it would generate.
Additionally, low-power nodes may be offline for significant periods Additionally, low-power nodes may be offline for significant periods
either because they are "sleeping" or due to connectivity problems. either because they are "sleeping" or due to connectivity problems.
In such cases LLN nodes might fail to respond to queries or defend In such cases, LLN nodes might fail to respond to queries or defend
their names using the current design. their names using the current design.
3. Basic Use Cases 3. Basic Use Cases
The following use cases are defined with different characteristics to The following use cases are defined with different characteristics to
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 Networking [ZC] to contain a router may use Zero Configuration Networking [ZC] to
self-assign link-local addresses [RFC3927] [RFC4862], and self-assign link-local addresses [RFC3927] [RFC4862] and Multicast
Multicast DNS [mDNS] to provide naming and service discovery, as DNS [mDNS] to provide naming and service discovery, as is
currently implemented and deployed in Mac OS X, iOS, Windows [B4W] currently implemented and deployed in Mac OS X, iOS, Windows
and Android [NSD]. [B4W], and Android [NSD].
(B) Classic home or 'hotspot' networks, with the following (B) Classic home or 'hotspot' networks, with the following
properties: properties:
* Single exit router: the network may have one or more upstream * Single exit router: The network may have one or more 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: a single physical link, or multiple physical * One-level depth: A single physical link, or multiple physical
links bridged to form a single logical link, that is connected links bridged to form a single logical link, that is connected
to the default router. The single logical link provides a to the default router. The single logical link provides a
single broadcast domain, facilitating use of link-local single broadcast domain, facilitating use of link-local
Multicast DNS, and also ARP, which enables the home or Multicast DNS, and also ARP, which enables the home or
'hotspot' network to consist of just a single IPv4 subnet. 'hotspot' network to consist of just a single IPv4 subnet.
* Single administrative domain: all nodes under the same * Single administrative domain: All nodes under the same
administrative authority. (However, this does not necessarily administrative authority. Note that this does not necessarily
imply a network administrator.) imply a network administrator.
(C) Advanced home and small business networks [RFC7368]: (C) Advanced home and small business networks [RFC7368]:
Like B, but consist of multiple wired and/or wireless links, Like B, but consists of multiple wired and/or wireless links,
connected by routers, generally behind a single exit router. connected by routers, generally behind a single exit router.
However, the forwarding nodes are largely self-configuring and do However, the forwarding nodes are largely self-configuring and do
not require routing protocol administration. Such networks should not require routing protocol administration. Such networks should
also not require DNS administration. also not require DNS administration.
(D) Enterprise networks: (D) Enterprise networks:
Consist of arbitrary network diameter under a single Consists of arbitrary network diameter under a single
administrative authority. A large majority of the forwarding and administrative authority. A large majority of the forwarding and
security devices are configured and multiple exit routers are more security devices are configured, and multiple exit routers are
common. Large-scale conference-style networks, which are more common. Large-scale conference-style networks, which are
predominantly wireless access, e.g., as available at IETF predominantly wireless access, e.g., as available at IETF
meetings, also fall within this category. 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. authority while leaf networks are under local administrative
authorities.
(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 servers Configuration mode of operation. This implies that servers
and clients should be able to automatically determine a and clients should be able to automatically determine a
default Scope of Discovery in which to advertise and discover default scope of discovery in which to advertise and discover
services, respectively. 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). independent zones (e.g., from department to campus wide).
This capability must exist in the protocol; individual This capability must exist in the protocol; individual
operators are not required to use this capability in all operators are not required to use this capability in all
cases -- in particular, use case C should support Zero cases -- in particular, use case C should support Zero
Configuration operation where that is desired. If multiple Configuration operation where that is desired. If multiple
scopes are available, there must be a way to enumerate the scopes are available, there must be a way to enumerate the
choices from which a selection can be made. In use case C, choices from which a selection can be made. In use case C,
either Zero Configuration (one flat list of resources) or either Zero Configuration (one flat list of resources) or
configured (e.g., resources sorted by room) modes of configured (e.g., resources sorted by room) modes of
operation should be available. operation should be available.
REQ3: As stated in REQ2 above, the discovery scope need not be REQ3: As stated in REQ2 above, the discovery scope need not be
aligned to network topology. For example, it may instead be aligned to network topology. For example, it may instead be
aligned to physical proximity (e.g., building) or aligned to physical proximity (e.g., building) or
organizational structure, (e.g., "Sales" vs. "Engineering"). organizational structure (e.g., "Sales" vs. "Engineering").
REQ4: For use cases C, D, and E, there should be an incremental way REQ4: For use cases C, D, and E, there should be an incremental way
to deploy the solution. to deploy the solution.
REQ5: SSD should leverage and build upon current link scope DNS-SD/ REQ5: SSD should leverage and build upon current link scope DNS-SD/
mDNS protocols and deployments. mDNS protocols and deployments.
REQ6: SSD must not adversely affect or break any other current REQ6: SSD must not adversely affect or break any other current
protocols or deployments. protocols or deployments.
skipping to change at page 8, line 9 skipping to change at page 8, line 23
clients and services on non-adjacent links. clients and services on non-adjacent links.
REQ8: It is desirable that a user or device be able to discover REQ8: It is desirable that a user or device be able to discover
services within the sites or networks to which the user or services within the sites or networks to which the user or
device is connected. device is connected.
REQ9: SSD should operate efficiently on common link layers and link REQ9: SSD should operate efficiently on common link layers and link
types. types.
REQ10: SSD should be considerate of networks where power consumption REQ10: SSD should be considerate of networks where power consumption
is a critical factor and, for example, nodes may be in a low is a critical factor; for example, nodes may be in a low-
power or sleeping state. power or sleeping state.
REQ11: SSD must be scalable to thousands of nodes with minimal REQ11: SSD must be scalable to thousands of nodes with minimal
configuration and without degrading network performance. A configuration and without degrading network performance. A
possible figure of merit is that, as the number of services possible figure of merit is that, as the number of services
increases, the amount of traffic due to SSD on a given link increases, the amount of traffic due to SSD on a given link
remains relatively constant. remains relatively constant.
REQ12: SSD should enable a way to provide a consistent user REQ12: SSD should enable a way to provide a consistent user
experience whether local or remote services are being experience whether local or remote services are being
discovered. discovered.
REQ13: The information presented by SSD should closely reflect the REQ13: The information presented by SSD should closely reflect the
current state of discoverable services on the network. That current state of discoverable services on the network. That
is, new information should be available within a few seconds is, new information should be available within a few seconds
and stale information should not persist indefinitely. In and stale information should not persist indefinitely. In
networking all information is necessarily somewhat out-of- networking, all information is necessarily somewhat out of
date by the time it reaches the receiver, even if only by a date by the time it reaches the receiver, even if only by a
few microseconds, or less. Thus timeliness is always an few microseconds or less. Thus, timeliness is always an
engineering trade-off against efficiency. The engineering engineering trade-off against efficiency. The engineering
decisions for SSD should appropriately balance timeliness decisions for SSD should appropriately balance timeliness
against network efficiency. against network efficiency.
REQ14: SSD should operate over existing networks (as described by REQ14: SSD should operate over existing networks (as described by
use cases A-F above) without requiring changes to the network use cases A through F above) without requiring changes to the
at the physical, link, or internetworking layers. network at the physical, link, or internetworking layers.
REQ15: The administrator of an advertised service should be able to REQ15: The administrator of an advertised service should be able to
control whether the service is advertised beyond the local control whether the service is advertised beyond the local
link. link.
5. Namespace Considerations 5. Namespace Considerations
The traditional unicast DNS namespace contains, for the most part, The traditional unicast DNS namespace contains, for the most part,
globally unique names. Multicast DNS provides every link with its globally unique names. Multicast DNS provides every link with its
own separate link-local namespace, where names are unique only within own separate link-local namespace, where names are unique only within
the context of that link. Clients discovering services may need to the context of that link. Clients discovering services may need to
differentiate between local and global names, and may need to differentiate between local and global names and may need to
determine when names in different namespaces identify the same determine when names in different namespaces identify the same
service. service.
Devices on different links may have the same mDNS name (perhaps due Devices on different links may have the same mDNS name (perhaps due
to vendor defaults), because link-local mDNS names are only to vendor defaults) because link-local mDNS names are only guaranteed
guaranteed to be unique on a per-link basis. This may lead to a to be unique on a per-link basis. This may lead to a local label
local label disambiguation problem when results are aggregated (e.g., disambiguation problem when results are aggregated (e.g., for
for presentation). presentation).
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 a separate document discussed in a separate document [INTEROP-LABELS].
[I-D.sullivan-dnssd-mdns-dns-interop].
6. Security Considerations 6. Security Considerations
Insofar as SSD may automatically gather DNS-SD resource records and Insofar as SSD may automatically gather DNS-SD resource records and
publish them over a wide area, the security issues are likely to publish them over a wide area, the security issues are likely to
include the union of those discussed in the Multicast DNS [mDNS] and include the union of those discussed in the Multicast DNS [mDNS] and
DNS-Based Service Discovery [DNS-SD] specifications. The following DNS-based Service Discovery [DNS-SD] specifications. The following
sections highlight potential threats that are posed by deploying DNS- sections highlight potential threats that are posed by deploying DNS-
SD over multiple links or by automating DNS-SD administration. SD over multiple links or by automating DNS-SD administration.
6.1. Scope of Discovery 6.1. Scope of Discovery
In some scenarios, the owner of the advertised service may not have a In some scenarios, the owner of the advertised service may not have a
clear indication of the scope of its advertisement. clear indication of the scope of its advertisement.
For example, since mDNS is currently restricted to a single link, the For example, since mDNS is currently restricted to a single link, the
scope of the advertisement is limited, by design, to the shared link scope of the advertisement is limited, by design, to the shared link
between client and server. If the advertisement propagates to a between client and server. If the advertisement propagates to a
larger set of links than expected, this may result in unauthorized larger set of links than expected, this may result in unauthorized
clients (from the perspective of the owner) discovering and then clients (from the perspective of the owner) discovering and then
potentially attempting to connect to the advertised service. It also potentially attempting to connect to the advertised service. It also
discloses information (about the host and service) to a larger set of discloses information (about the host and service) to a larger set of
potential attackers. potential attackers.
Note that discovery of a service does not necessarily imply that the Note that discovery of a service does not necessarily imply that the
service is reachable by, or can be connected to, or can be used by, a service is reachable by, or can be connected to, or can be used by, a
given client. Specific access control mechanisms are out of scope of given client. Specific access-control mechanisms are out of scope of
this document. this document.
If the scope of the discovery is not properly set up or constrained, If the scope of the discovery is not properly set up 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.
6.3. Authorization 6.3. Authorization
DNSSEC can assert the validity but not the accuracy of records in a DNSSEC can assert the validity but not the accuracy of records in a
zone file. The trust model of the global DNS relies on the fact that zone file. The trust model of the global DNS relies on the fact that
human administrators either (a) manually enter resource records into human administrators either (a) manually enter resource records into
a zone file, or (b) configure the DNS server to authenticate a a zone file or (b) configure the DNS server to authenticate a trusted
trusted device (e.g., a DHCP server) that can automatically maintain device (e.g., a DHCP server) that can automatically maintain such
such records. records.
An impostor may register on the local link and appear as a legitimate An impostor may register on the local link and appear as a legitimate
service. Such "rogue" services may then be automatically registered service. Such "rogue" services may then be automatically registered
in unicast DNS-SD. in unicast DNS-SD.
6.4. Authentication 6.4. Authentication
Up to now, the "plug-and-play" nature of mDNS devices has relied only Up to now, the "plug-and-play" nature of mDNS devices has relied only
on physical connectivity. If a device is visible via mDNS then it is on physical connectivity. If a device is visible via mDNS, then it
assumed to be trusted. This is not likely to be the case in foreign is assumed to be trusted. This is not likely to be the case in
networks. foreign networks.
If there is a risk that clients may be fooled by the deployment of If there is a risk that clients may be fooled by the deployment of
rogue services, then application layer authentication should be rogue services, then application-layer authentication should be
considered as part of any security solution. Authentication of any considered as part of any security solution. Authentication of any
particular service is outside the scope of this document. particular service is outside the scope of this document.
6.5. Access Control 6.5. Access Control
Access Control refers to the ability to restrict which users are able Access Control refers to the ability to restrict which users are able
to use a particular service that might be advertised via DNS-SD. In to use a particular service that might be advertised via DNS-SD. In
this case, "use" of a service is different from the ability to this case, "use" of a service is different from the ability to
"discover" or "reach" a service. "discover" or "reach" a service.
While controlling access to an advertised service is outside the While controlling access to an advertised service is outside the
scope of DNS-SD, we note that access control today often is provided scope of DNS-SD, we note that access control today often is provided
by existing site infrastructure (e.g., router access control lists, by existing site infrastructure (e.g., router access-control lists,
firewalls) and/or by service-specific mechanisms (e.g., user firewalls) and/or by service-specific mechanisms (e.g., user
authentication to the service). For example, networked printers can authentication to the service). For example, networked printers can
control access via a user-id and password. Apple's software supports control access via a user ID and password. Apple's software supports
such access control for USB printers shared via Mac OS X Printer such access control for USB printers shared via Mac OS X Printer
Sharing, as do many networked printers themselves. So the reliance Sharing, as do many networked printers themselves. So the reliance
on existing service-specific security mechanisms (i.e. outside the on existing service-specific security mechanisms (i.e., outside the
scope of DNS-SD) does not create new security considerations. scope of DNS-SD) does not create new security considerations.
6.6. Privacy Considerations 6.6. Privacy Considerations
Mobile devices such as smart phones or laptops that can expose the Mobile devices such as smart phones or laptops that can expose the
location of their owners by registering services in arbitrary zones location of their owners by registering services in arbitrary zones
pose a risk to privacy. Such devices must not register their pose a risk to privacy. Such devices must not register their
services in arbitrary zones without the approval ("opt-in") of their services in arbitrary zones without the approval ("opt-in") of their
users. However, it should be possible to configure one or more users. However, it should be possible to configure one or more
"safe" zones in which mobile devices may automatically register their "safe" zones in which mobile devices may automatically register their
services. services.
7. IANA Considerations 7. References
This document makes no request of IANA.
8. Acknowledgments
We gratefully acknowledge contributions and review comments made by 7.1. Normative References
RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and
Peter Van Der Stok.
9. References [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
9.1. Normative References [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May Configuration of IPv4 Link-Local Addresses", RFC 3927,
2005. DOI 10.17487/RFC3927, May 2005,
<http://www.rfc-editor.org/info/rfc3927>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
2007. DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Lossy Networks", RFC 6550, March 2012. Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
August 2014. DOI 10.17487/RFC7346, August 2014,
<http://www.rfc-editor.org/info/rfc7346>.
[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", RFC 7368,
October 2014.
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Discovery", RFC 6763, February 2013. Weil, "IPv6 Home Networking Architecture Principles", RFC
7368, DOI 10.17487/RFC7368, October 2014,
<http://www.rfc-editor.org/info/rfc7368>.
9.2. Informative References 7.2. Informative References
[B4W] "Bonjour for Windows", [B4W] "Bonjour (software)",
<http://en.wikipedia.org/wiki/Bonjour_(software)>. <http://en.wikipedia.org/wiki/Bonjour_(software)>.
[I-D.sullivan-dnssd-mdns-dns-interop] [EP] Badman, L., "Petitioning Apple: From Educause Higher Ed
Sullivan, A., "On Interoperation of Labels Between mDNS Wireless Networking Admin Group", July 2012,
and DNS", draft-sullivan-dnssd-mdns-dns-interop-01 (work <https://www.change.org/p/from-educause-higher-ed-
in progress), October 2014. wireless-networking-admin-group>.
[EP] "Educause Petition", https://www.change.org/petitions/
from-educause-higher-ed-wireless-networking-admin-group,
July 2012.
[IEEE.802.11] [IEEE.802.11]
"Information technology - Telecommunications and IEEE Computer Society, "IEEE Standard for Information
information exchange between systems - Local and technology - Telecommunications and information exchange
metropolitan area networks - Specific requirements - Part between systems Local and metropolitan area networks -
11: Wireless LAN Medium Access Control (MAC) and Physical Specific requirements Part 11: Wireless LAN Medium Access
Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, Control (MAC) and Physical Layer (PHY) Specifications",
<http://standards.ieee.org/getieee802/ IEEE Std 802.11,
download/802.11-2012.pdf>. <http://standards.ieee.org/about/get/802/802.11.html>.
[NSD] "NsdManager | Android Developer", June 2012, [INTEROP-LABELS]
Sullivan, A., "On Interoperation of Labels Between mDNS
and DNS", Work in Progress,
draft-sullivan-dnssd-mdns-dns-interop-01, October 2014.
[NSD] Android, "NsdManager",
<http://developer.android.com/reference/android/net/nsd/ <http://developer.android.com/reference/android/net/nsd/
NsdManager.html>. NsdManager.html>.
[STATIC] "Manually Adding DNS-SD Service Discovery Records to an [STATIC] "Manually Adding DNS-SD Service Discovery Records to an
Existing Name Server", July 2013, Existing Name Server", July 2013,
<http://www.dns-sd.org/ServerStaticSetup.html>. <http://www.dns-sd.org/ServerStaticSetup.html>.
[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration
Networking: The Definitive Guide", O'Reilly Media, Inc. , Networking: The Definitive Guide", O'Reilly Media, Inc.,
ISBN 0-596-10100-7, December 2005. ISBN 0-596-10100-7, December 2005.
Acknowedgements
We gratefully acknowledge contributions and review comments made by
RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and
Peter Van Der Stok.
Authors' Addresses Authors' Addresses
Kerry Lynn Kerry Lynn
Verizon Verizon Labs
50 Sylvan Road 50 Sylvan Road
Waltham , MA 95014 Waltham, MA 95014
USA United States
Phone: +1 781 296 9722 Phone: +1 781 296 9722
Email: kerry.lynn@verizon.com Email: kerry.lynn@verizon.com
Stuart Cheshire Stuart Cheshire
Apple, Inc. Apple, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino , CA 95014 Cupertino, CA 95014
USA United States
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
Marc Blanchet Marc Blanchet
Viagenie Viagenie
246 Aberdeen 246 Aberdeen
Quebec , QC G1R 2E1 Quebec, QC G1R 2E1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca URI: http://viagenie.ca
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 Boulevard Decarie
Montreal , QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
Phone: +1 514 452 2160 Phone: +1 514 452 2160
Email: daniel.migault@ericsson.com Email: daniel.migault@ericsson.com
 End of changes. 84 change blocks. 
182 lines changed or deleted 191 lines changed or added

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