draft-ietf-dnssd-requirements-01.txt   draft-ietf-dnssd-requirements-02.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: August 17, 2014 Apple, Inc. Expires: December 12, 2014 Apple, Inc.
M. Blanchet M. Blanchet
Viagenie Viagenie
D. Migault D. Migault
Orange Orange
February 13, 2014 June 10, 2014
Requirements for Scalable DNS-SD/mDNS Extensions Requirements for Scalable DNS-SD/mDNS Extensions
draft-ietf-dnssd-requirements-01 draft-ietf-dnssd-requirements-02
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 August 17, 2014. This Internet-Draft will expire on December 12, 2014.
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 36 skipping to change at page 2, line 36
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. However, it is unclear which approach different ad-hoc techniques. As yet, no consensus has emerged
represents the best long-term direction for DNS-based service regarding which approach represents the best long-term direction for
discovery protocol development. DNS-based service discovery protocol development.
DNS-SD/mDNS in its present form is also not optimized for network mDNS 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 [IEEE.802.11] may be adversely affected by
excessive mDNS traffic due to the higher network overhead of excessive mDNS traffic due to the higher network overhead of
multicast transmissions. Wireless mesh networks such as 6LoWPAN multicast transmissions. Wireless mesh networks such as 6LoWPAN
[RFC4944] are effectively multi-link subnets where multicasts must be [RFC4944] are effectively multi-link subnets [RFC4903] where
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. Requirements Language
skipping to change at page 3, line 28 skipping to change at page 3, line 28
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, as specified in [DNS-SD], is a
conventional application of DNS Resource Records and messages to conventional application of DNS Resource Records and messages to
facilitate the discovery and location of services. facilitate the discovery and location of services.
mDNS: Multicast DNS, as specified in [mDNS], is a transport protocol mDNS: Multicast DNS, as specified in [mDNS], is a transport protocol
that facilitates DNS-SD on a local link in the absence of DNS that facilitates DNS-SD on a local link in the absence of DNS
infrastructure. infrastructure.
SSD: Scalable DNS-SD is a future extension of DNS-SD/mDNS that meets SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps
the requirements set forth in this document. mDNS) that meets the requirements set forth in this document.
Scope of Discovery: A node in 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 DNS-SD query. DNS zone, that is the target of a given SSD query.
Zero Configuration: A set of technologies including DNS-SD/mDNS that Zero Configuration: A deployment of SSD that requires no
enable local address and name assignment in the absence of DHCP or administration (although some administration may be optional).
DNS infrastructure. May also refer more generally to a deployment of
SSD that requires no administration.
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.
skipping to change at page 4, line 17 skipping to change at page 4, line 15
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 Entering DNS-SD records manually into a unicast DNS zone file o DNS-SD resource records may be entered manually into a unicast DNS
works, but requires a DNS administrator to do that and is fragile zone file, but this task must be performed by a DNS administrator.
when IP addresses of devices change dynamically, as is common when It is labor-intensive and brittle when IP addresses of devices
DHCP is used. 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.
skipping to change at page 5, line 43 skipping to change at page 5, line 41
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: the simplest example of a DNS-SD/mDNS (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. Such networks may not laptop and one printer, on a common link. PANs that do not
contain a router, but instead use Zero Configuration to mitigate contain a router may use Zero Configuration to assign network
the lack of infrastructure. addresses and mDNS to provide naming and service discovery.
(B) Classic home networks, consisting of: (B) Classic home 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.
skipping to change at page 6, line 33 skipping to change at page 6, line 29
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.
(E) Higher Education networks: (E) Higher Education networks:
Like D but 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: The scope of the discovery should be either automatically REQ1: For use cases A, B, and C, there should be a Zero
determined by the discovering devices or configured (selected) Configuration mode of operation. This implies that devices
in the case of multiple choices. should be able to automatically determine a default Scope of
Discovery in which to advertise and discover services.
REQ2: For use cases A, B, and C, there should be a zero
configuration mode of operation.
REQ3: For use cases D and E, there should be a way to configure the REQ2: For use cases C, D, and E, there should be a way to configure
scope of the discovery and also support both smaller (e.g., Scopes of Discovery that support a range of topologically-
department) and larger (e.g., campus-wide) discovery scopes. independent zones (e.g., from department to campus-wide). If
multiple scopes are available, there must be a way to
enumerate the choices from which a selection can be made.
REQ4: For use cases D and E, there should be an incremental way to REQ3: For use cases C, D, and E, there should be an incremental way
deploy the solution. to deploy the solution.
REQ5: SSD should integrate or at least should not break any current REQ4: SSD should integrate or at least should not break any current
link scope DNS-SD/mDNS protocols and deployments. link scope DNS-SD/mDNS protocols and deployments. SSD must
not adversely affect any other protocol.
REQ6: SSD must be capable of spanning multiple links (hops) and REQ5: SSD must be capable of spanning multiple links (hops) and
network technologies. network technologies.
REQ7: SSD must be scalable to thousands of nodes with minimal REQ6: 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.
REQ8: SSD should enable a way to provide a consistent user REQ7: SSD should enable a way to provide a consistent user
experience whether local or global services are being experience whether local or global services are being
discovered. discovered.
REQ9: The information presented by SSD should reflect reality. That REQ8: The information presented by SSD should reflect reality. That
is, new information should be available in a timely fashion is, new information should be available in a timely fashion
and stale information should not persist. and stale information should not persist.
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.
skipping to change at page 8, line 33 skipping to change at page 8, line 33
perspective of the owner) connecting to the advertised service. It perspective of the owner) connecting to the advertised service. It
also discloses information (about the host and service) to a larger also discloses information (about the host and service) to a larger
set of potential attackers. set of potential attackers.
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 client may not know if the namespaces. Without adequate feedback, a discovering client may not
target service is the correct one, therefore enabling potential know if the advertised service is the correct one, therefore enabling
attacks. [Example? KEL] 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 veracity 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 a
zone file, or b) configure the DNS server to authenticate a trusted zone file, or b) configure the DNS server to authenticate a trusted
device (e.g., a DHCP server) that can automatically maintain such device (e.g., a DHCP server) that can automatically maintain such
records. records.
An imposter may register on the local link and appear as a legitimate An imposter 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 wide area 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 no longer likely to be the case in assumed to be trusted. This is not likely to be the case in foreign
larger 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 probably rogue services, then application layer authentication should be
be considered. considered as part of any security solution. Authentication of any
particular service is outside the scope of this document.
6.5. Privacy Considerations 6.5. Privacy Considerations
Mobile devices such as smart phones that can expose the location of Mobile devices such as smart phones that can expose the location of
their owners by registering services in arbitrary zones pose a risk their owners by registering services in arbitrary zones pose a risk
to privacy. Such devices must not register their services in to privacy. Such devices must not register their services in
arbitrary zones without the approval of their operators. However, it arbitrary zones without the approval ("opt-in") of their users.
should be possible to configure one or more "safe" zones, e.g., based However, it should be possible to configure one or more "safe" zones
on subnet prefix, in which mobile devices may automatically register in which mobile devices may automatically register their services.
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, Peter Van Der Stok, and Thomas Narten. Farmer, Matthew Gast, Thomas Narten, David Thaler, and 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June
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.
[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-02 (work in progress), November 6man-multicast-scopes-06 (work in progress), June 2014.
2013.
[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-11 (work in progress), October 2013. ietf-homenet-arch-14 (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.
[IEEE.802.11] [IEEE.802.11]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
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/download/ <http://standards.ieee.org/getieee802/
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>.
Authors' Addresses Authors' Addresses
Kerry Lynn (editor) Kerry Lynn (editor)
Consultant Consultant
 End of changes. 32 change blocks. 
62 lines changed or deleted 64 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/