From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7558.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7558.txt (limited to 'doc/rfc/rfc7558.txt') diff --git a/doc/rfc/rfc7558.txt b/doc/rfc/rfc7558.txt new file mode 100644 index 0000000..653d9fc --- /dev/null +++ b/doc/rfc/rfc7558.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) K. Lynn +Request for Comments: 7558 Verizon Labs +Category: Informational S. Cheshire +ISSN: 2070-1721 Apple, Inc. + M. Blanchet + Viagenie + D. Migault + Ericsson + July 2015 + + + Requirements for Scalable DNS-Based Service + Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions + +Abstract + + DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is + widely used today for discovery and resolution of services and names + on a local link, but there are use cases to extend DNS-SD/mDNS to + enable service discovery beyond the local link. This document + provides a problem statement and a list of requirements for scalable + DNS-SD. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + 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. + + 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. + + + + + + + + + + + + + +Lynn, et al. Informational [Page 1] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Namespace Considerations . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + +1. Introduction + + DNS-based Service Discovery [DNS-SD] in combination with its + companion technology Multicast DNS [mDNS] is widely used today for + discovery and resolution of services and names on a local link. As + users move to multi-link home or campus networks, however, they find + that mDNS (by design) does not work across routers. DNS-SD can also + be used in conjunction with conventional unicast DNS to enable + wide-area service discovery, but this capability is not yet widely + deployed. This disconnect between customer needs and current + practice has led to calls for improvement, such as the Educause + petition [EP]. + + In response to this and similar evidence of market demand, several + products now enable service discovery beyond the local link using + different ad hoc techniques. As of yet, no consensus has emerged + regarding which approach represents the best long-term direction for + DNS-based Service Discovery protocol development. + + + + + + +Lynn, et al. Informational [Page 2] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + Multicast DNS in its present form is also not optimized for network + technologies where multicast transmissions are relatively expensive. + Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely + affected by excessive mDNS traffic due to the higher network overhead + of multicast transmissions. Wireless mesh networks such as IPv6 over + Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944] are + 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 + vendors for all interested parties to cooperate within the context of + the IETF to develop an efficient, scalable, and interoperable + standards-based solution. + + This document defines the problem statement and gathers requirements + for scalable DNS-SD/mDNS extensions. + +1.1. Terminology and Acronyms + + Service: A listening endpoint (host and port) for a given application + protocol. Services are identified by Service Instance Names. + + DNS-SD: DNS-based Service Discovery [DNS-SD] is a conventional + application of DNS resource records and messages to facilitate the + naming, discovery, and location of services. When used alone, the + term generally refers to the wide-area unicast protocol. + + mDNS: Multicast DNS [mDNS] is a mechanism that facilitates + distributed DNS-like capabilities (including DNS-SD) on a local link + without need of traditional DNS infrastructure. + + SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future + extension of DNS-SD (and perhaps mDNS) that meets the requirements + set forth in this document. + + Scope of Discovery: A subset of a local or global namespace, e.g., a + DNS subdomain, that is the target of a given SSD query. + + Zero Configuration: A deployment of SSD that requires no + administration (although some administration may be optional). + + Incremental Deployment: An orderly transition, as a network + installation evolves, from DNS-SD/mDNS to SSD. + + + + + + + + +Lynn, et al. Informational [Page 3] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + +2. Problem Statement + + Service discovery beyond the local link is perhaps the most important + feature currently missing from the DNS-SD-over-mDNS framework (also + written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and + requirements are summarized below. + +2.1. Multi-link Naming and Discovery + + A list of desired DNS-SD/mDNS improvements from network + administrators in the research and education community was issued in + the form of the Educause petition [EP]. The following is a summary + of their technical issues: + + 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 + client devices on other links. DNS-SD used with conventional + unicast DNS does work when servers and clients are on different + links, but the resource records that describe the services must + somehow be entered into the unicast DNS namespace. + + 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 + administrator. It is labor intensive and brittle when IP + addresses of devices change dynamically, as is common when DHCP is + used. + + o Automatically adding DNS-SD records using DNS Update works, but it + requires that the DNS server be configured to allow DNS Updates + and that devices be configured with the DNS Update credentials to + permit such updates, which has proven to be onerous. + + Therefore, a mechanism is desired that populates the DNS namespace + with the appropriate DNS-SD records with less manual administration + than is typically needed for a conventional unicast DNS server. + + The following is a summary of technical requirements: + + o It must scale to a range of hundreds to thousands of DNS-SD/mDNS- + enabled devices in a given environment. + + o It must simultaneously operate over a variety of network link + technologies, such as wired and wireless networks. + + + + + +Lynn, et al. Informational [Page 4] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + o It must not significantly increase network traffic (wired or + wireless). + + o It must be cost-effective to manage at up to enterprise scale. + +2.2. IEEE 802.11 Wireless LANs + + Multicast DNS was originally designed to run on Ethernet - the + dominant link layer at the time. In shared-medium Ethernet networks, + multicast frames place little additional demand on the shared network + medium compared to unicast frames. In IEEE 802.11 networks, however, + multicast frames are transmitted at a low data rate supported by all + receivers. In practice, this data rate leads to a larger fraction of + airtime being devoted to multicast transmission. Some network + administrators block multicast traffic or use access points that + transmit multicast frames using a series of link-layer unicast + frames. + + Wireless links may be orders of magnitude less reliable than their + wired counterparts. To improve transmission reliability, the IEEE + 802.11 Medium Access Control (MAC) requires positive acknowledgement + of unicast frames. It does not, however, support positive + acknowledgement of multicast frames. As a result, it is common to + observe higher loss rates of multicast frames on wireless network + technologies than on wired network technologies. + + Enabling service discovery on IEEE 802.11 networks requires that the + number of multicast frames be restricted to a suitably low value or + replaced with unicast frames to use the MAC's reliability features. + +2.3. Low-Power and Lossy Networks (LLNs) + + Emerging wireless mesh networking technologies such as the Routing + Protocol for LLNs (RPL) [RFC6550] and 6LoWPAN present several + challenges for the current DNS-SD/mDNS design. First, link-local + multicast scope [RFC4291] is defined as a single-hop neighborhood. A + wireless mesh network representing a single logical subnet may often + extend to multiple hops [RFC4903]; therefore, a larger multicast + scope is required to span it [RFC7346]. Multicast DNS was + intentionally not specified for greater than link-local scope because + of the additional off-link multicast traffic that it would generate. + + Additionally, low-power nodes may be offline for significant periods + either because they are "sleeping" or due to connectivity problems. + In such cases, LLN nodes might fail to respond to queries or defend + their names using the current design. + + + + + +Lynn, et al. Informational [Page 5] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + +3. Basic Use Cases + + The following use cases are defined with different characteristics to + help motivate, distinguish, and classify the target requirements. + They cover a spectrum of increasing deployment and administrative + complexity. + + (A) Personal Area Networks (PANs): The simplest example of a + network may consist of a single client and server, e.g., one + laptop and one printer, on a common link. PANs that do not + contain a router may use Zero Configuration Networking [ZC] to + self-assign link-local addresses [RFC3927] [RFC4862] and Multicast + DNS [mDNS] to provide naming and service discovery, as is + currently implemented and deployed in Mac OS X, iOS, Windows + [B4W], and Android [NSD]. + + (B) Classic home or 'hotspot' networks, with the following + properties: + + * Single exit router: The network may have one or more upstream + providers or networks, but all outgoing and incoming traffic + goes through a single router. + + * One-level depth: A single physical link, or multiple physical + 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 + administrative authority. Note that this does not necessarily + imply a network administrator. + + (C) Advanced home and small business networks [RFC7368]: + + Like B, but consists of multiple wired and/or wireless links, + connected by routers, generally behind a single exit router. + However, the forwarding nodes are largely self-configuring and do + not require routing protocol administration. Such networks should + also not require DNS administration. + + (D) Enterprise networks: + + Consists of arbitrary network diameter under a single + administrative authority. A large majority of the forwarding and + security devices are configured, and multiple exit routers are + + + + +Lynn, et al. Informational [Page 6] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + more common. Large-scale conference-style networks, which are + predominantly wireless access, e.g., as available at IETF + meetings, also fall within this category. + + (E) Higher-Education networks: + + Like D, but the core network may be under a central administrative + authority while leaf networks are under local administrative + authorities. + + (F) Mesh networks such as RPL/6LoWPAN: + + Multi-link subnets with prefixes defined by one or more border + routers. May comprise any part of networks C, D, or E. + +4. Requirements + + Any successful SSD solution(s) will have to strike the proper balance + between competing goals such as scalability, deployability, and + usability. With that in mind, none of the requirements listed below + should be considered in isolation. + + REQ1: For use cases A, B, and C, there should be a Zero + Configuration mode of operation. This implies that servers + and clients should be able to automatically determine a + default scope of discovery in which to advertise and discover + services, respectively. + + REQ2: For use cases C, D, and E, there should be a way to configure + scopes of discovery that support a range of topologically + independent zones (e.g., from department to campus wide). + This capability must exist in the protocol; individual + operators are not required to use this capability in all + cases -- in particular, use case C should support Zero + Configuration operation where that is desired. If multiple + scopes are available, there must be a way to enumerate the + choices from which a selection can be made. In use case C, + either Zero Configuration (one flat list of resources) or + configured (e.g., resources sorted by room) modes of + operation should be available. + + REQ3: As stated in REQ2 above, the discovery scope need not be + aligned to network topology. For example, it may instead be + aligned to physical proximity (e.g., building) or + organizational structure (e.g., "Sales" vs. "Engineering"). + + REQ4: For use cases C, D, and E, there should be an incremental way + to deploy the solution. + + + +Lynn, et al. Informational [Page 7] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + REQ5: SSD should leverage and build upon current link scope DNS-SD/ + mDNS protocols and deployments. + + REQ6: SSD must not adversely affect or break any other current + protocols or deployments. + + REQ7: SSD must be capable of operating across networks that are not + limited to a single link or network technology, including + clients and services on non-adjacent links. + + REQ8: It is desirable that a user or device be able to discover + services within the sites or networks to which the user or + device is connected. + + REQ9: SSD should operate efficiently on common link layers and link + types. + + REQ10: SSD should be considerate of networks where power consumption + is a critical factor; for example, nodes may be in a low- + power or sleeping state. + + REQ11: SSD must be scalable to thousands of nodes with minimal + configuration and without degrading network performance. A + possible figure of merit is that, as the number of services + increases, the amount of traffic due to SSD on a given link + remains relatively constant. + + REQ12: SSD should enable a way to provide a consistent user + experience whether local or remote services are being + discovered. + + REQ13: The information presented by SSD should closely reflect the + current state of discoverable services on the network. That + is, new information should be available within 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 + use cases A through F above) without requiring changes to the + network at the physical, link, or internetworking layers. + + + + + + +Lynn, et al. Informational [Page 8] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + REQ15: The administrator of an advertised service should be able to + control whether the service is advertised beyond the local + link. + +5. Namespace Considerations + + The traditional unicast DNS namespace contains, for the most part, + globally unique names. Multicast DNS provides every link with its + own separate link-local namespace, where names are unique only within + 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. + + Devices on different links may have the same mDNS name (perhaps due + to vendor defaults) because link-local mDNS names are only guaranteed + to be unique on a per-link basis. This may lead to a local label + disambiguation problem when results are aggregated (e.g., for + presentation). + + SSD should support rich internationalized labels within Service + Instance Names, as DNS-SD/mDNS does today. SSD must not negatively + impact the global DNS namespace or infrastructure. + + The problem of publishing local services in the global DNS namespace + may be generally viewed as exporting local resource records and their + associated labels into some DNS zone. The issues related to defining + labels that are interoperable between local and global namespaces are + discussed in a separate document [INTEROP-LABELS]. + +6. Security Considerations + + Insofar as SSD may automatically gather DNS-SD resource records and + publish them over a wide area, the security issues are likely to + 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- + SD over multiple links or by automating DNS-SD administration. + +6.1. Scope of Discovery + + In some scenarios, the owner of the advertised service may not have a + clear indication of the scope of its advertisement. + + For example, since mDNS is currently restricted to a single link, the + scope of the advertisement is limited, by design, to the shared link + between client and server. If the advertisement propagates to a + larger set of links than expected, this may result in unauthorized + + + +Lynn, et al. Informational [Page 9] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + 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 + 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 + this document. + + If the scope of the discovery is not properly set up or constrained, + then information leaks will happen outside the appropriate network. + +6.2. Multiple Namespaces + + There is a possibility of conflicts between the local and global DNS + namespaces. Without adequate feedback, a discovering client may not + know if the advertised service is the correct one, therefore enabling + potential attacks. + +6.3. Authorization + + 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 + human administrators either (a) manually enter resource records into + a zone file or (b) configure the DNS server to authenticate a trusted + device (e.g., a DHCP server) that can automatically maintain such + records. + + An impostor may register on the local link and appear as a legitimate + service. Such "rogue" services may then be automatically registered + in unicast DNS-SD. + +6.4. Authentication + + 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 assumed to be trusted. This is not likely to be the case in + foreign networks. + + If there is a risk that clients may be fooled by the deployment of + rogue services, then application-layer authentication should be + considered as part of any security solution. Authentication of any + particular service is outside the scope of this document. + + + + + + + +Lynn, et al. Informational [Page 10] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + +6.5. Access Control + + 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 + this case, "use" of a service is different from the ability to + "discover" or "reach" a service. + + While controlling access 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, networked printers can + control access via a user ID and password. Apple's software supports + such access control for USB printers shared via Mac OS X Printer + Sharing, as do many networked printers themselves. 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. References + +7.1. Normative References + + [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + . + + [mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, + DOI 10.17487/RFC6762, February 2013, + . + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + DOI 10.17487/RFC3927, May 2005, + . + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . + + + +Lynn, et al. Informational [Page 11] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + . + + [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, + DOI 10.17487/RFC4903, June 2007, + . + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + . + + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., + Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, + JP., and R. Alexander, "RPL: IPv6 Routing Protocol for + Low-Power and Lossy Networks", RFC 6550, + DOI 10.17487/RFC6550, March 2012, + . + + [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, + DOI 10.17487/RFC7346, August 2014, + . + + [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. + Weil, "IPv6 Home Networking Architecture Principles", RFC + 7368, DOI 10.17487/RFC7368, October 2014, + . + +7.2. Informative References + + [B4W] "Bonjour (software)", + . + + [EP] Badman, L., "Petitioning Apple: From Educause Higher Ed + Wireless Networking Admin Group", July 2012, + . + + [IEEE.802.11] + IEEE Computer Society, "IEEE Standard for Information + technology - Telecommunications and information exchange + between systems Local and metropolitan area networks - + Specific requirements Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", + IEEE Std 802.11, + . + + + +Lynn, et al. Informational [Page 12] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + + [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", + . + + [STATIC] "Manually Adding DNS-SD Service Discovery Records to an + Existing Name Server", July 2013, + . + + [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration + Networking: The Definitive Guide", O'Reilly Media, Inc., + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lynn, et al. Informational [Page 13] + +RFC 7558 Scalable DNS-SD Requirements July 2015 + + +Authors' Addresses + + Kerry Lynn + Verizon Labs + 50 Sylvan Road + Waltham, MA 95014 + United States + + Phone: +1 781 296 9722 + Email: kerry.lynn@verizon.com + + + Stuart Cheshire + Apple, Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States + + Phone: +1 408 974 3207 + Email: cheshire@apple.com + + + Marc Blanchet + Viagenie + 246 Aberdeen + Quebec, QC G1R 2E1 + Canada + + Email: Marc.Blanchet@viagenie.ca + URI: http://viagenie.ca + + + Daniel Migault + Ericsson + 8400 Boulevard Decarie + Montreal, QC H4P 2N2 + Canada + + Phone: +1 514 452 2160 + Email: daniel.migault@ericsson.com + + + + + + + + + + + +Lynn, et al. Informational [Page 14] + -- cgit v1.2.3