draft-ietf-dnssd-requirements-03.txt   draft-ietf-dnssd-requirements-04.txt 
DNS-SD/mDNS Extensions K. Lynn, Ed. DNS-SD/mDNS Extensions K. Lynn
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Informational S. Cheshire Intended status: Informational S. Cheshire
Expires: January 5, 2015 Apple, Inc. Expires: April 11, 2015 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
D. Migault D. Migault
Orange Orange
July 4, 2014 October 8, 2014
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-SD/mDNS Extensions
draft-ietf-dnssd-requirements-03 draft-ietf-dnssd-requirements-04
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 January 5, 2015. This Internet-Draft will expire on April 11, 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 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . 8 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
service discovery, but this capability is not yet widely deployed. service discovery, but this capability is not yet widely deployed.
This disconnect between customer needs and current practice has led This disconnect between customer needs and current practice has led
to calls for improvement, such as the Educause petition [EP]. to calls for improvement, such as the Educause 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 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.
mDNS 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 [IEEE.802.11] may be adversely affected by Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely
excessive mDNS traffic due to the higher network overhead of affected by excessive mDNS traffic due to the higher network overhead
multicast transmissions. Wireless mesh networks such as 6LoWPAN of multicast transmissions. Wireless mesh networks such as 6LoWPAN
[RFC4944] are effectively multi-link subnets [RFC4903] where [RFC4944] are effectively multi-link subnets [RFC4903] where
multicasts must be forwarded by intermediate nodes. 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. Requirements Language 1.1. Terminology and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
1.2. Terminology and Acronyms
Service: An 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, as specified in [DNS-SD], is a DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional
conventional application of DNS Resource Records and messages to application of DNS Resource Records and messages to facilitate the
facilitate the discovery and location of services. discovery and location of services.
mDNS: Multicast DNS, as specified in [mDNS], is a transport protocol mDNS: Multicast DNS [mDNS] is a mechanism that facilitates DNS-SD on
that facilitates DNS-SD on a local link in the absence of DNS a local link in the absence of traditional DNS infrastructure.
infrastructure.
SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps
mDNS) that meets the requirements set forth in this document. mDNS) that meets the requirements 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
DNS zone, that is the target of a given SSD query. DNS subdomain, that is the target of a given SSD query.
Zero Configuration: A deployment of SSD that requires no Zero Configuration: A deployment of SSD that requires no
administration (although some administration may be optional). administration (although some administration may be optional).
Incremental Deployment: An orderly transition, as a network Incremental Deployment: An orderly transition, as a network
installation evolves, from DNS-SD/mDNS to SSD. installation evolves, from DNS-SD/mDNS to SSD.
2. Problem Statement 2. Problem Statement
Service discovery beyond the local link is perhaps the most important Service discovery beyond the local link is perhaps the most important
feature currently missing from the DNS-SD/mDNS framework. Other feature currently missing from the DNS-SD/mDNS framework. Other
issues and requirements are summarized below. issues and 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 the technical issues: of their technical issues:
o Products that advertise services such as printing and multimedia o Products that advertise services such as printing and multimedia
streaming via DNS-SD/mDNS are not currently discoverable by streaming via DNS-SD/mDNS are not currently discoverable by
devices on other links. It is common practice for enterprises and devices on other links. It is common practice for enterprises and
institutions to use wireless links for client access and wired institutions to use wireless links for client access and wired
networks for server infrastructure, typically on different networks for server infrastructure, typically on different
subnets. DNS-SD used with conventional unicast DNS does work when subnets. DNS-SD used with conventional unicast DNS does work when
devices are on different links, but the resource records that devices are on different links, but the resource records that
describe the service must somehow be entered into the unicast DNS describe the service must somehow be entered into the unicast DNS
namespace. 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, but this task must be performed by a DNS administrator. zone file [static], but this task must be performed by a DNS
It is labor-intensive and brittle when IP addresses of devices administrator. It is labor-intensive and brittle when IP
change dynamically, as is common when DHCP is used. addresses of devices change dynamically, as is common when DHCP is
used.
o Automatically adding DNS-SD records using DNS Update works, but o Automatically adding DNS-SD records using DNS Update works, but
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 requires that devices be configured with the DNS Update
credentials to permit such updates, which has proven to be credentials to permit such updates, which has proven to be
onerous. onerous.
o Therefore, a mechanism is desired that populates the DNS namespace o Therefore, a mechanism is desired that populates the DNS namespace
with the appropriate DNS-SD records with less manual with the appropriate DNS-SD records with less manual
administration than typically needed for a unicast DNS server. administration than typically needed for a unicast DNS server.
The following is a summary of the technical requirements: The following is a summary of their 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).
skipping to change at page 5, line 4 skipping to change at page 4, line 45
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 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 convert it to a series of administrators block multicast traffic, or use access points that
link-layer unicast frames. transmit multicast frames using a series of link-layer unicast
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 MAC requires positive acknowledgement of unicast frames. It
does not, however, support positive acknowledgement of multicast does not, however, support positive acknowledgement of multicast
frames. As a result, it is common to observe much higher loss of frames. As a result, it is common to observe much higher loss of
multicast frames on wireless as compared to wired network multicast frames on wireless as compared to wired network
technologies. 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 RPL [RFC6550]
and 6LoWPAN present several challenges for the current DNS-SD/mDNS and 6LoWPAN present several challenges for the current DNS-SD/mDNS
design. First, Link-Local multicast scope [RFC4291] is defined as a design. First, Link-Local multicast scope [RFC4291] is defined as a
single-hop neighborhood. A single subnet prefix in a wireless mesh single-hop neighborhood. A single subnet prefix in a wireless mesh
network may often span multiple links, therefore a larger multicast network may often span multiple links, therefore a larger multicast
scope is required to span it [I-D.ietf-6man-multicast-scopes]. mDNS scope is required to span it [RFC7346]. Multicast DNS is
is not currently specified for greater than Link-Local scope. intentionally not specified for greater than Link-Local scope,
because of the additional multicast traffic that 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 to assign network contain a router may use Zero Configuration Networking [ZC] to
addresses and mDNS to provide naming and service discovery. self-assign link-local addresses [RFC3927] [RFC4862], and
Multicast DNS [mDNS] to provide naming and service discovery.
(B) Classic home or 'hotspot' networks, consisting of: (B) Classic home or 'hotspot' networks, with the following
properties:
* Single exit router: the network may have multiple 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: multiple links on the network are bridged to * One-level depth: a single physical link, or multiple physical
form a single subnet, which is connected to the default router. links bridged to form a single logical link, that is connected
to the default router. The single logical link provides a
single broadcast domain, facilitating use of link-local
Multicast DNS, and also ARP, which enables the home or
'hotspot' network to consist of just a single IPv4 subnet.
* Single administrative domain: all nodes under the same admin * Single administrative domain: all nodes under the same
entity. (However, this does not necessarily imply a network administrative authority. (However, this does not necessarily
administrator.) imply a network administrator.)
(C) Advanced home and small business networks (C) Advanced home and small business networks
[I-D.ietf-homenet-arch]: [I-D.ietf-homenet-arch]:
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 authority. A large majority of the forwarding and
security devices are configured. Large-scale conference-style security devices are configured. Large-scale conference-style
networks, which are predominantly wireless access, e.g., as networks, which are predominantly wireless access, e.g., as
available at IETF meetings, also fall within this category. 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:
skipping to change at page 7, line 13 skipping to change at page 7, line 13
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). 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: 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 or organizational structure. aligned to physical proximity (e.g. building) or
organizational structure.
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 integrate with current link scope DNS-SD/mDNS REQ5: SSD should integrate with current link scope DNS-SD/mDNS
protocols and deployments. 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.
REQ7: SSD must be capable of operating across networks that are not REQ7: SSD must be capable of operating across networks that are not
limited to a single link or network technology, including limited to a single link or network technology, including
clients and services on non-adjacent links. clients and services on non-adjacent links.
REQ8: It is desirable that a user or device, when away from such a REQ8: It is desirable that a user or device be able to discover
site, is still able to discover services within that site, services within the sites or networks to which the user or
e.g., a user discovering services in their home network while device is connected.
remote from it.
REQ9: SSD should operate efficiently in all networks, with REQ9: SSD should operate efficiently on common link layers and link
particular consideration for potentially lossy or multicast- types.
challenged wireless networks.
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 and, 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 global services are being experience whether local or remote services are being
discovered. discovered.
REQ13: The information presented by SSD should reflect reality. REQ13: The information presented by SSD should closely reflect
That is, new information should be available in a timely reality. That is, new information should be available within
fashion and stale information should not persist. a few seconds and stale information should not persist
indefinitely. In networking all information is necessarily
somewhat out-of-date by the time it reaches the receiver,
even if only by a few microseconds, or less. Thus timeliness
is always an engineering trade-off against efficiency. The
engineering decisions for SSD should appropriately balance
timeliness 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-F above) without requiring changes to the network
technology or deployment. technology or deployment.
5. Namespace Considerations 5. Namespace Considerations
The unicast DNS namespace contains globally unique names. The mDNS The traditional unicast DNS namespace contains, for the most part,
namespace contains locally unique names. Clients discovering globally unique names. Multicast DNS provides every link with its
services may need to differentiate between local and global names or own separate link-local namespace, where names are unique only within
to determine that names in different namespaces identify the same the context of that link. Clients discovering services may need to
differentiate between local and global names, and may need to
determine when names in different namespaces identify the same
service. service.
Multiple devices in different subnets may share the same label Devices on different links may have the same mDNS name (perhaps due
(perhaps due to vendor defaults) or have similarly appearing labels. to vendor defaults), because link-local mDNS names are only
guaranteed to be unique on a per-link basis. Also, even devices that
are on the same link may have similar-looking names, such as one
device with the name "Bill" and another device using the similar-
looking name "Bi11" (using the digit "1" in place of the letter "l").
This may lead to a local label disambiguation problem between This may lead to a local label disambiguation problem between
presented results. 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 a separate document
[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 be publish them over a wide area, the security issues are likely to
the union of those discussed in [mDNS] and [DNS-SD]. The following include the union of those discussed in the Multicast DNS [mDNS] and
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
As mDNS is currently restricted to a single link, the scope of the In some scenarios, the owner of the advertised service may not have a
advertisement is limited, by design, to the shared link between clear indication of the scope of its advertisement.
client and server. In a multi-link scenario, the owner of the
advertised service may not have a clear indication of the scope of
its advertisement.
If the advertisement propagates to a larger set of links than For example, since mDNS is currently restricted to a single link, the
expected, this may result in unauthorized clients (from the scope of the advertisement is limited, by design, to the shared link
perspective of the owner) discovering and then potentially attempting between client and server. If the advertisement propagates to a
to connect to the advertised service. It also discloses information larger set of links than expected, this may result in unauthorized
(about the host and service) to a larger set of potential attackers. clients (from the perspective of the owner) discovering and then
potentially attempting to connect to the advertised service. It also
discloses information (about the host and service) to a larger set of
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 or can be connected to. Specific access control service is reachable or can be connected to. Specific access control
mechanisms are out of scope of this document. 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 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 veracity 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 a human administrators either (a) manually enter resource records into
zone file, or b) configure the DNS server to authenticate a trusted a zone file, or (b) configure the DNS server to authenticate a
device (e.g., a DHCP server) that can automatically maintain such trusted device (e.g., a DHCP server) that can automatically maintain
records. such records.
An imposter 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 is
assumed to be trusted. This is not likely to be the case in foreign assumed to be trusted. This is not likely to be the case in foreign
networks. 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. Privacy Considerations 6.5. Access Control
Mobile devices such as smart phones that can expose the location of Access Control refers to the ability to restrict which users are able
their owners by registering services in arbitrary zones pose a risk to use a particular service that might be advertised via DNS-SD. In
to privacy. Such devices must not register their services in this case, "use" of a service is different from the ability to
arbitrary zones without the approval ("opt-in") of their users. "discover" or "reach" a service.
However, it should be possible to configure one or more "safe" zones
in which mobile devices may automatically register their services. While access control to an advertised service is outside the scope of
DNS-SD, we note that access control today often is provided by
existing site infrastructure (e.g. router access control lists,
firewalls) and/or by service-specific mechanisms (e.g. user
authentication to the service). For example, many networked printers
already support access controls via a user-id and password. At least
one widely deployed DNS-SD + mDNS implementation supports such access
controls for printers. So the reliance on existing service-specific
security mechanisms (i.e. outside the scope of DNS-SD) does not
create new security considerations.
6.6. Privacy Considerations
Mobile devices such as smart phones or laptops that can expose the
location of their owners by registering services in arbitrary zones
pose a risk to privacy. Such devices must not register their
services in arbitrary zones without the approval ("opt-in") of their
users. However, it should be possible to configure one or more
"safe" zones in which mobile devices may automatically register their
services.
7. IANA Considerations 7. IANA Considerations
This document currently makes no request of IANA. This document currently makes no request of IANA.
Note to RFC Editor: this section may be removed upon publication as Note to RFC Editor: this section may be removed upon publication as
an RFC. an RFC.
8. Acknowledgments 8. Acknowledgments
We gratefully acknowledge contributions and review comments made by We gratefully acknowledge contributions and review comments made by
RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
Farmer, Matthew Gast, Thomas Narten, David Thaler, and Peter Van Der Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and
Stok. Peter Van Der Stok.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Requirement Levels", BCP 14, RFC 2119, March 1997. Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[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, February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
2007. 2007.
[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, September 2007.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
August 2014.
[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]
Droms, R., "IPv6 Multicast Address Scopes", draft-ietf-
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-16 (work in progress), June 2014. ietf-homenet-arch-17 (work in progress), July 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.
skipping to change at page 11, line 41 skipping to change at page 12, line 27
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012, Layer (PHY) Specifications", IEEE Std 802.11-2012, 2012,
<http://standards.ieee.org/getieee802/ <http://standards.ieee.org/getieee802/
download/802.11-2012.pdf>. download/802.11-2012.pdf>.
[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
Networking: The Definitive Guide", O'Reilly Media, Inc. ,
ISBN 0-596-10100-7, December 2005.
Authors' Addresses Authors' Addresses
Kerry Lynn (editor) Kerry Lynn
Consultant Consultant
Phone: +1 978 460 4253 Phone: +1 978 460 4253
Email: kerlyn@ieee.org Email: kerlyn@ieee.org
Stuart Cheshire Stuart Cheshire
Apple, Inc. Apple, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino , California 95014 Cupertino , California 95014
USA USA
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 , Quebec G1R 2E1 Quebec , Quebec G1R 2E1
Canada Canada
Email: Marc.Blanchet@viagenie.ca Email: Marc.Blanchet@viagenie.ca
URI: http://www.viagenie.ca URI: http://viagenie.ca
Daniel Migault Daniel Migault
Orange Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy-les-Moulineaux 92130 Issy-les-Moulineaux 92130
France France
Phone: +33 1 45 29 60 52 Phone: +33 1 45 29 60 52
Email: mglt.biz@gmail.com Email: mglt.biz@gmail.com
 End of changes. 52 change blocks. 
104 lines changed or deleted 144 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/