[要約] RFC 7558は、スケーラブルなDNSベースのサービスディスカバリ（DNS-SD）/マルチキャストDNS（mDNS）拡張の要件を定義しています。このRFCの目的は、DNS-SDおよびmDNSの拡張機能の要件を明確にし、これらのプロトコルのスケーラビリティと効率性を向上させることです。
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
スケーラブルなDNSベースのサービス検出（DNS-SD）/マルチキャストDNS（mDNS）拡張の要件
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.
マルチキャストDNS（mDNS）を介したDNSベースのサービス検出（DNS-SD）は、ローカルリンク上のサービスと名前の検出と解決に今日広く使用されていますが、DNS-SD / mDNSを拡張してサービスの検出を可能にするユースケースがありますローカルリンク。このドキュメントでは、問題の説明と、スケーラブルなDNS-SDの要件のリストを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7558で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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].
DNSベースのサービス検出[DNS-SD]とその関連技術であるマルチキャストDNS [mDNS]は、ローカルリンク上のサービスと名前の検出と解決に今日広く使用されています。ただし、ユーザーがマルチリンクのホームネットワークまたはキャンパスネットワークに移動すると、mDNS（設計上）がルーター間で機能しないことがわかります。 DNS-SDを従来のユニキャストDNSと組み合わせて使用して、広域サービスの検出を可能にすることもできますが、この機能はまだ広く導入されていません。顧客のニーズと現在の慣行との間のこの切り離しは、Educause請願[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.
これと同様の市場需要の証拠に対応して、いくつかの製品は、さまざまなアドホック技術を使用してローカルリンクを越えてサービスを発見できるようになりました。現時点では、どのアプローチがDNSベースのサービスディスカバリプロトコル開発の最良の長期的な方向性を表すのかについて、合意は生まれていません。
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.
現在の形式のマルチキャストDNSも、マルチキャスト送信が比較的高価なネットワークテクノロジー向けに最適化されていません。 Wi-Fi [IEEE.802.11]などのワイヤレスネットワークは、マルチキャスト送信のネットワークオーバーヘッドが高いため、過剰なmDNSトラフィックによって悪影響を受ける可能性があります。 IPv6 over Low-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）[RFC4944]などのワイヤレスメッシュネットワークは、効果的にマルチリンクサブネット[RFC4903]であり、中間ノードによってマルチキャストを転送する必要があります。
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.
すべての関係者がIETFのコンテキスト内で協力して、効率的でスケーラブルで相互運用可能な標準ベースのソリューションを開発することは、エンドユーザー、ネットワーク管理者、およびベンダーにとって最大の利益になります。
This document defines the problem statement and gathers requirements for scalable DNS-SD/mDNS extensions.
このドキュメントでは、問題の説明を定義し、スケーラブルなDNS-SD / mDNS拡張機能の要件を収集します。
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.
DNS-SD：DNSベースのサービス検出[DNS-SD]は、サービスの命名、検出、および場所を容易にするためのDNSリソースレコードとメッセージの従来のアプリケーションです。単独で使用する場合、この用語は一般に広域ユニキャストプロトコルを指します。
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.
mDNS：マルチキャストDNS [mDNS]は、従来のDNSインフラストラクチャを必要とせずに、ローカルリンクで分散DNSのような機能（DNS-SDを含む）を容易にするメカニズムです。
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.
SSD：Scalable Service Discovery（またはScalable DNS-SD）は、このドキュメントで説明されている要件を満たすDNS-SD（およびおそらくmDNS）の将来の拡張です。
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.
検出の範囲：特定のSSDクエリのターゲットである、DNSサブドメインなどのローカルまたはグローバル名前空間のサブセット。
Zero Configuration: A deployment of SSD that requires no administration (although some administration may be optional).
ゼロ構成：管理が不要なSSDの展開（一部の管理はオプションである場合があります）。
Incremental Deployment: An orderly transition, as a network installation evolves, from DNS-SD/mDNS to SSD.
インクリメンタルデプロイメント：ネットワークインストールが進化するにつれて、DNS-SD / mDNSからSSDへの秩序だった移行。
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.
ローカルリンクを越えたサービス検出は、おそらくDNS-SD-over-mDNSフレームワーク（「mDNS上のDNS-SD」または「DNS-SD / mDNS」とも書かれています）に現在欠けている最も重要な機能です。その他の問題と要件を以下にまとめます。
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:
研究および教育コミュニティのネットワーク管理者からの望ましいDNS-SD / mDNS改善のリストは、教育用嘆願書[EP]の形式で発行されました。以下は、それらの技術的な問題の要約です。
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 企業や機関では、クライアントアクセスにワイヤレスリンクを使用し、サーバーインフラストラクチャに有線リンクを使用するのが一般的です。通常、それらは異なるサブネット上にあります。印刷やmDNSを介したDNS-SDを介したマルチメディアストリーミングなどのサービスを宣伝する製品は、現在、他のリンク上のクライアントデバイスでは検出できません。従来のユニキャストDNSで使用されるDNS-SDは、サーバーとクライアントが異なるリンク上にある場合は機能しますが、サービスを記述するリソースレコードは、何らかの方法でユニキャストDNS名前空間に入力する必要があります。
o DNS-SD resource records may be entered manually into a unicast DNS zone file [STATIC], but this task must be performed by a DNS administrator. It is labor intensive and brittle when IP addresses of devices change dynamically, as is common when DHCP is used.
o DNS-SDリソースレコードは、ユニキャストDNSゾーンファイル[静的]に手動で入力できますが、このタスクはDNS管理者が実行する必要があります。 DHCPが使用されている場合によくあるように、デバイスのIPアドレスが動的に変化すると、労働集約的で壊れやすくなります。
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.
o DNSアップデートを使用してDNS-SDレコードを自動的に追加することはできますが、DNSサーバーがDNSアップデートを許可するように構成され、デバイスがDNSアップデート資格情報を使用してそのようなアップデートを許可する必要があります。
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.
したがって、従来のユニキャストDNSサーバーに通常必要とされるよりも少ない手動の管理で、適切なDNS-SDレコードをDNS名前空間に取り込むメカニズムが望まれます。
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 特定の環境で、数百から数千のDNS-SD / mDNS対応デバイスの範囲に拡張する必要があります。
o It must simultaneously operate over a variety of network link technologies, such as wired and wireless networks.
o 有線ネットワークや無線ネットワークなど、さまざまなネットワークリンクテクノロジで同時に動作する必要があります。
o It must not significantly increase network traffic (wired or wireless).
o ネットワークトラフィック（有線または無線）を大幅に増加させてはなりません。
o It must be cost-effective to manage at up to enterprise scale.
o 企業規模での管理は費用対効果の高いものでなければなりません。
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.
マルチキャストDNSはもともとイーサネット（当時は支配的なリンク層）で実行するように設計されていました。共有メディアイーサネットネットワークでは、マルチキャストフレームは、ユニキャストフレームと比較して、共有ネットワークメディアに追加の要求をほとんど加えません。ただし、IEEE 802.11ネットワークでは、マルチキャストフレームは、すべての受信者がサポートする低いデータレートで送信されます。実際には、このデータレートは、マルチキャスト送信に費やされる通信時間の大部分につながります。一部のネットワーク管理者は、マルチキャストトラフィックをブロックするか、一連のリンク層ユニキャストフレームを使用してマルチキャストフレームを送信するアクセスポイントを使用します。
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.
ワイヤレスリンクは、有線のリンクよりも桁違いに信頼性が低い場合があります。伝送の信頼性を向上させるために、IEEE 802.11メディアアクセスコントロール（MAC）では、ユニキャストフレームの肯定応答が必要です。ただし、マルチキャストフレームの肯定応答はサポートされていません。その結果、有線ネットワークテクノロジよりもワイヤレスネットワークテクノロジの方がマルチキャストフレームの損失率が高くなることがよくあります。
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.
IEEE 802.11ネットワークでサービス検出を有効にするには、MACの信頼性機能を使用するために、マルチキャストフレームの数を適切に低い値に制限するか、ユニキャストフレームに置き換える必要があります。
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.
LLNのルーティングプロトコル（RPL）[RFC6550]や6LoWPANなどの新しいワイヤレスメッシュネットワーキングテクノロジーは、現在のDNS-SD / mDNS設計にいくつかの課題を提示しています。まず、リンクローカルマルチキャストスコープ[RFC4291]は、シングルホップの近隣として定義されます。単一の論理サブネットを表すワイヤレスメッシュネットワークは、複数のホップに拡張されることがよくあります[RFC4903]。したがって、それをまたがるには、より大きなマルチキャストスコープが必要です[RFC7346]。マルチキャストDNSは、生成される追加のオフリンクマルチキャストトラフィックのために、リンクローカルスコープを超える範囲では意図的に指定されていません。
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.
さらに、低電力ノードは、「スリープ」しているため、または接続の問題のために、かなりの期間オフラインになる場合があります。このような場合、LLNノードは、現在の設計を使用してクエリに応答したり、名前を防御したりできない場合があります。
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].
（A）パーソナルエリアネットワーク（PAN）：ネットワークの最も単純な例は、共通リンク上の単一のクライアントとサーバー（1台のラップトップと1台のプリンターなど）で構成できます。ルーターを含まないPANは、Zero Configuration Networking [ZC]を使用してリンクローカルアドレス[RFC3927] [RFC4862]とマルチキャストDNS [mDNS]を自己割り当てし、現在Macに実装および展開されているネーミングとサービスディスカバリを提供します。 OS X、iOS、Windows [B4W]、Android [NSD]。
(B) Classic home or 'hotspot' networks, with the following properties:
（B）以下のプロパティを持つクラシックホームネットワークまたは「ホットスポット」ネットワーク：
* 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.
* 単一の出口ルーター：ネットワークには1つ以上の上流プロバイダーまたはネットワークがありますが、すべての発信および着信トラフィックは単一のルーターを通過します。
* 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.
* 1レベルの深さ：単一の物理リンク、またはデフォルトのルーターに接続されている単一の論理リンクを形成するためにブリッジされた複数の物理リンク。単一の論理リンクは単一のブロードキャストドメインを提供し、リンクローカルマルチキャストDNSとARPの使用を容易にし、ホームまたは「ホットスポット」ネットワークを単一のIPv4サブネットのみで構成できるようにします。
* 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]:
（C）高度なホームネットワークおよびスモールビジネスネットワーク[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.
Bに似ていますが、ルーターで接続された複数の有線リンクまたは無線リンク、あるいはその両方で構成され、通常は単一の出口ルーターの背後にあります。ただし、転送ノードは主に自己構成型であり、ルーティングプロトコルの管理は必要ありません。このようなネットワークでは、DNS管理も必要ありません。
(D) Enterprise networks:
（D）エンタープライズネットワーク：
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 more common. Large-scale conference-style networks, which are predominantly wireless access, e.g., as available at IETF meetings, also fall within this category.
単一の管理権限の下で任意のネットワーク直径で構成されます。転送デバイスとセキュリティデバイスの大部分が構成されており、複数の出口ルーターがより一般的です。 IETFミーティングで利用できるような、主にワイヤレスアクセスである大規模な会議スタイルのネットワークもこのカテゴリに含まれます。
(E) Higher-Education networks:
（E）高等教育ネットワーク：
Like D, but the core network may be under a central administrative authority while leaf networks are under local administrative authorities.
Dと同様ですが、コアネットワークは中央の管理権限の下にあり、リーフネットワークはローカルの管理権限の下にあります。
(F) Mesh networks such as RPL/6LoWPAN:
（F）RPL / 6LoWPANなどのメッシュネットワーク：
Multi-link subnets with prefixes defined by one or more border routers. May comprise any part of networks C, D, or E.
1つ以上の境界ルーターによって定義されたプレフィックスを持つマルチリンクサブネット。ネットワークC、D、またはEの任意の部分を構成できます。
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.
成功するSSDソリューションはすべて、スケーラビリティ、展開性、使いやすさなどの競合する目標間の適切なバランスをとる必要があります。このことを念頭に置いて、以下にリストされている要件を個別に検討することはできません。
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.
REQ1：使用例A、B、およびCの場合、ゼロ構成動作モードが必要です。これは、サーバーとクライアントが、それぞれサービスをアドバタイズおよびディスカバーするデフォルトのディスカバリーのスコープを自動的に決定できることを意味します。
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.
REQ2：ユースケースC、D、およびEの場合、トポロジー的に独立したゾーンの範囲（部門からキャンパス全体など）をサポートするディスカバリーのスコープを構成する方法が必要です。この機能はプロトコルに存在する必要があります。個々のオペレーターがすべてのケースでこの機能を使用する必要はありません。特に、ユースケースCは、必要に応じてゼロ構成操作をサポートする必要があります。複数のスコープが利用可能な場合、選択を行うための選択肢を列挙する方法が必要です。ユースケースCでは、ゼロ構成（リソースのフラットリストの1つ）または構成済み（たとえば、部屋別にソートされたリソース）モードの操作が使用可能である必要があります。
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").
REQ3：上記のREQ2で述べたように、検出スコープはネットワークトポロジーに合わせる必要はありません。たとえば、物理的な近接性（建物など）または組織構造（「営業」と「エンジニアリング」など）の代わりに配置することができます。
REQ4: For use cases C, D, and E, there should be an incremental way to deploy the solution.
REQ4：ユースケースC、D、およびEの場合、ソリューションを展開するための段階的な方法が必要です。
REQ5: SSD should leverage and build upon current link scope DNS-SD/ mDNS protocols and deployments.
REQ5：SSDは、現在のリンクスコープのDNS-SD / mDNSプロトコルおよび展開を活用および構築する必要があります。
REQ6: SSD must not adversely affect or break any other current protocols or deployments.
REQ6：SSDは、他の現在のプロトコルや展開に悪影響を及ぼしたり、それらを壊したりしてはなりません。
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.
REQ7：SSDは、隣接していないリンク上のクライアントやサービスなど、単一のリンクやネットワークテクノロジーに限定されないネットワーク全体で動作できる必要があります。
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.
REQ8：ユーザーまたはデバイスは、ユーザーまたはデバイスが接続されているサイトまたはネットワーク内のサービスを検出できることが望ましいです。
REQ9: SSD should operate efficiently on common link layers and link types.
REQ9：SSDは、一般的なリンクレイヤーとリンクタイプで効率的に動作する必要があります。
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.
REQ10：SSDは、電力消費が重要な要素であるネットワークを考慮する必要があります。たとえば、ノードが低電力またはスリープ状態にある可能性があります。
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.
REQ11：SSDは、最小限の構成で、ネットワークパフォーマンスを低下させることなく、数千のノードにまで拡張できる必要があります。考えられるメリットの数値は、サービスの数が増加しても、特定のリンク上のSSDによるトラフィック量が比較的一定のままであることです。
REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered.
REQ12：SSDは、ローカルサービスとリモートサービスのどちらが検出されている場合でも、一貫したユーザーエクスペリエンスを提供する方法を有効にする必要があります。
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.
REQ13：SSDによって提供される情報は、ネットワーク上の検出可能なサービスの現在の状態を厳密に反映する必要があります。つまり、数秒以内に新しい情報が利用可能になり、古い情報が無期限に保持されないようにする必要があります。ネットワーキングでは、たとえ数マイクロ秒以下であっても、すべての情報は受信者に到達するまでに必然的に古くなります。したがって、適時性は常に効率に対するエンジニアリングのトレードオフです。 SSDの設計上の決定により、適時性とネットワーク効率のバランスを適切に保つ必要があります。
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.
REQ14：SSDは、物理、リンク、またはインターネットワーキングレイヤーでネットワークを変更する必要なく、既存のネットワーク（上記のユースケースA〜Fで説明）で動作する必要があります。
REQ15: The administrator of an advertised service should be able to control whether the service is advertised beyond the local link.
REQ15：アドバタイズされたサービスの管理者は、サービスがローカルリンクを越えてアドバタイズされるかどうかを制御できる必要があります。
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.
従来のユニキャストDNS名前空間には、ほとんどの場合、グローバルに一意の名前が含まれています。マルチキャストDNSは、すべてのリンクに独自のリンクローカル名前空間を提供します。名前は、そのリンクのコンテキスト内でのみ一意です。サービスを検出するクライアントは、ローカル名とグローバル名を区別する必要があり、異なる名前空間の名前が同じサービスを識別する場合を決定する必要がある場合があります。
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).
リンクローカルのmDNS名はリンクごとに一意であることが保証されているだけなので、異なるリンク上のデバイスは同じmDNS名を持っている可能性があります（おそらくベンダーのデフォルトによるものです）。これは、結果が（たとえば、プレゼンテーションのために）集計されるときに、ローカルラベルの曖昧性解消の問題につながる可能性があります。
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.
SSDは、現在のDNS-SD / mDNSと同様に、サービスインスタンス名内の豊富な国際化ラベルをサポートする必要があります。 SSDは、グローバルDNS名前空間またはインフラストラクチャに悪影響を与えてはなりません。
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].
グローバルDNS名前空間でローカルサービスを公開する際の問題は、通常、ローカルリソースレコードとそれに関連付けられたラベルを一部のDNSゾーンにエクスポートすることと見なすことができます。ローカル名前空間とグローバル名前空間の間で相互運用可能なラベルの定義に関連する問題は、別のドキュメント[INTEROP-LABELS]で説明されています。
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.
SSDがDNS-SDリソースレコードを自動的に収集し、広域に公開する場合、セキュリティの問題には、マルチキャストDNS [mDNS]およびDNSベースのサービスディスカバリ[DNS-SD]仕様で説明されているものの結合が含まれる可能性があります。 。次のセクションでは、複数のリンクにDNS-SDを展開することによって、またはDNS-SD管理を自動化することによってもたらされる潜在的な脅威について説明します。
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 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.
たとえば、現在mDNSは単一のリンクに制限されているため、通知の範囲は、設計上、クライアントとサーバー間の共有リンクに制限されています。アドバタイズが予想よりも多くのリンクセットに伝播すると、（所有者の観点から）承認されていないクライアントが、アドバタイズされたサービスを検出し、接続しようとする可能性があります。また、潜在的な攻撃者のより多くのセットに（ホストとサービスに関する）情報を開示します。
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.
検出の範囲が適切に設定または制約されていない場合、適切なネットワークの外部で情報漏えいが発生します。
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.
ローカルとグローバルのDNS名前空間が競合する可能性があります。適切なフィードバックがないと、発見したクライアントは、アドバタイズされたサービスが正しいものであるかどうかを認識できないため、潜在的な攻撃が可能になります。
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.
DNSSECは、ゾーンファイル内のレコードの正確さではなく、有効性を表明できます。グローバルDNSの信頼モデルは、人間の管理者が（a）リソースレコードをゾーンファイルに手動で入力するか、または（b）DNSサーバーを構成して、自動的に維持できる信頼できるデバイス（DHCPサーバーなど）を認証することを前提としていますそのような記録。
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.
詐欺師はローカルリンクに登録し、正当なサービスとして表示される場合があります。このような「不正な」サービスは、ユニキャストDNS-SDに自動的に登録されます。
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.
これまで、mDNSデバイスの「プラグアンドプレイ」の性質は、物理的な接続にのみ依存してきました。デバイスがmDNS経由で表示される場合、そのデバイスは信頼されていると見なされます。これは、外部ネットワークでは当てはまりそうにありません。
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.
不正なサービスの展開によってクライアントが騙されるリスクがある場合は、アプリケーションレイヤー認証をセキュリティソリューションの一部と見なす必要があります。特定のサービスの認証は、このドキュメントの範囲外です。
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.
アクセス制御とは、DNS-SDを介してアドバタイズされる可能性のある特定のサービスを使用できるユーザーを制限する機能を指します。この場合、サービスの「使用」は、サービスを「検出」または「到達」する機能とは異なります。
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.
アドバタイズされたサービスへのアクセスの制御はDNS-SDの範囲外ですが、今日のアクセス制御は多くの場合、既存のサイトインフラストラクチャ（例：ルーターアクセス制御リスト、ファイアウォール）やサービス固有のメカニズム（例： 、サービスへのユーザー認証）。たとえば、ネットワークプリンタは、ユーザーIDとパスワードを使用してアクセスを制御できます。 Appleのソフトウェアは、Mac OS Xのプリンター共有を介して共有されるUSBプリンターのアクセス制御をサポートします。これは、多くのネットワークプリンター自体も同様です。そのため、既存のサービス固有のセキュリティメカニズム（つまり、DNS-SDの範囲外）に依存しても、新しいセキュリティの考慮事項は作成されません。
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.
スマートフォンやラップトップなど、任意のゾーンにサービスを登録することで所有者の位置を公開できるモバイルデバイスは、プライバシーを危険にさらします。そのようなデバイスは、ユーザーの承認（「オプトイン」）なしに、サービスを任意のゾーンに登録してはなりません。ただし、モバイルデバイスがサービスを自動的に登録できる1つ以上の「安全な」ゾーンを構成することは可能です。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[DNS-SD] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763> 。
[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <http://www.rfc-editor.org/info/rfc6762>.
[mDNS] Cheshire、S。およびM. Krochmal、「Multicast DNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<http://www.rfc-editor.org/info/rfc6762>。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <http://www.rfc-editor.org/info/rfc3927>.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4リンクローカルアドレスの動的構成」、RFC 3927、DOI 10.17487 / RFC3927、2005年5月、<http：//www.rfc-editor .org / info / rfc3927>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <http://www.rfc-editor.org/info/rfc4903>.
[RFC4903]ターラー、D。、「マルチリンクサブネットの問題」、RFC 4903、DOI 10.17487 / RFC4903、2007年6月、<http://www.rfc-editor.org/info/rfc4903>。
[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, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[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, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーイク、R。、ヴァッサー、JP。、およびR.アレクサンダー、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<http://www.rfc-editor.org/info/ rfc6550>。
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, DOI 10.17487/RFC7346, August 2014, <http://www.rfc-editor.org/info/rfc7346>.
[RFC7346] Droms、R。、「IPv6マルチキャストアドレススコープ」、RFC 7346、DOI 10.17487 / RFC7346、2014年8月、<http://www.rfc-editor.org/info/rfc7346>。
[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, <http://www.rfc-editor.org/info/rfc7368>.
[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC 7368、DOI 10.17487 / RFC7368、2014年10月、 <http://www.rfc-editor.org/info/rfc7368>。
[B4W] "Bonjour (software)", <http://en.wikipedia.org/wiki/Bonjour_(software)>.
[B4W]「こんにちは（ソフトウェア）」、<http://en.wikipedia.org/wiki/Bonjour_（ソフトウェア）>。
[EP] Badman, L., "Petitioning Apple: From Educause Higher Ed Wireless Networking Admin Group", July 2012, <https://www.change.org/p/from-educause-higher-ed-wireless-networking-admin-group>.
[EP] Badman、L。、「Petitioning Apple：From Educause Higher Ed Wireless Networking Admin Group」、2012年7月、<https://www.change.org/p/from-educause-higher-ed-wireless-networking- admin-group>。
[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, <http://standards.ieee.org/about/get/802/802.11.html>.
[IEEE.802.11] IEEE Computer Society、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network-Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、 IEEE Std 802.11、<http://standards.ieee.org/about/get/802/802.11.html>。
[INTEROP-LABELS] Sullivan, A., "On Interoperation of Labels Between mDNS and DNS", Work in Progress, draft-sullivan-dnssd-mdns-dns-interop-01, October 2014.
[INTEROP-LABELS]サリバン、A。、「mDNSとDNS間のラベルの相互運用について」、進行中の作業、draft-sullivan-dnssd-mdns-dns-interop-01、2014年10月。
[NSD] Android, "NsdManager", <http://developer.android.com/reference/android/net/nsd/ NsdManager.html>.
[NSD] Android、「NsdManager」、<http://developer.android.com/reference/android/net/nsd/ NsdManager.html>。
[STATIC] "Manually Adding DNS-SD Service Discovery Records to an Existing Name Server", July 2013, <http://www.dns-sd.org/ServerStaticSetup.html>.
[静的]「DNS-SDサービス検出レコードを既存のネームサーバーに手動で追加する」、2013年7月、<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.
[ZC] Cheshire、S。およびD. Steinberg、「Zero Configuration Networking：The Definitive Guide」、O'Reilly Media、Inc.、ISBN 0-596-10100-7、2005年12月。
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.
RJ Atkinson、Tim Chown、Guangqing Deng、Ralph Droms、Educause、David Farmer、Matthew Gast、Thomas Narten、Doug Otis、David Thaler、およびPeter Van Der Stokによるコメントとレビューを感謝します。
Authors' Addresses
著者のアドレス
Kerry Lynn Verizon Labs 50 Sylvan Road Waltham, MA 95014 United States
Kerry Lynn Verizon Labs 50 Sylvan Road Waltham、MA 95014アメリカ合衆国
Phone: +1 781 296 9722
Email: kerry.lynn@verizon.com
Stuart Cheshire Apple, Inc. 1 Infinite Loop Cupertino, CA 95014 United States
Stuart Cheshire Apple、Inc. 1 Infinite Loop Cupertino、CA 95014アメリカ合衆国
Phone: +1 408 974 3207
Email: cheshire@apple.com
Marc Blanchet Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada
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
Daniel Migault Ericsson 8400 Boulevard Decarie Montreal、QC H4P 2N2 Canada
Phone: +1 514 452 2160
Email: daniel.migault@ericsson.com