draft-ietf-dnssd-requirements-04.txt		draft-ietf-dnssd-requirements-05.txt
	DNS-SD/mDNS Extensions K. Lynn		DNS-SD/mDNS Extensions K. Lynn
	Internet-Draft Consultant		Internet-Draft Verizon
	Intended status: Informational S. Cheshire		Intended status: Informational S. Cheshire
	Expires: April 11, 2015 Apple, Inc.		Expires: September 5, 2015 Apple, Inc.
	M. Blanchet		M. Blanchet
	Viagenie		Viagenie
	D. Migault		D. Migault
	Orange		Ericsson
	October 8, 2014		March 4, 2015
	Requirements for Scalable DNS-SD/mDNS Extensions		Requirements for Scalable DNS-SD/mDNS Extensions
	draft-ietf-dnssd-requirements-04		draft-ietf-dnssd-requirements-05
	Abstract		Abstract
	DNS-SD/mDNS is widely used today for discovery and resolution of		DNS-SD over 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
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 11, 2015.		This Internet-Draft will expire on September 5, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5		3. Basic Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8		5. Namespace Considerations . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	DNS-Based Service Discovery [DNS-SD] in combination with its		DNS-Based Service Discovery [DNS-SD] in combination with its
	companion technology Multicast DNS [mDNS] is widely used today for		companion technology Multicast DNS [mDNS] is widely used today for
	discovery and resolution of services and names on a local link.		discovery and resolution of services and names on a local link.
	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 (by design) does not work across routers. DNS-SD can
	in conjunction with conventional unicast DNS to enable wide-area		also be used in conjunction with conventional unicast DNS to enable
	service discovery, but this capability is not yet widely deployed.		wide-area service discovery, but this capability is not yet widely
	This disconnect between customer needs and current practice has led		deployed. This disconnect between customer needs and current
	to calls for improvement, such as the Educause petition [EP].		practice has led to calls for improvement, such as the Educause
			petition [EP].
	In response to this and similar evidence of market demand, several		In response to this and similar evidence of market demand, several
	products now enable service discovery beyond the local link using		products now enable service discovery beyond the local link using
	different ad-hoc techniques. As yet, no consensus has emerged		different ad hoc techniques. As yet, no consensus has emerged
	regarding which approach represents the best long-term direction for		regarding which approach represents the best long-term direction for
	DNS-based service discovery protocol development.		DNS-based service discovery protocol development.
	Multicast DNS in its present form is also not optimized for network		Multicast DNS in its present form is also not optimized for network
	technologies where multicast transmissions are relatively expensive.		technologies where multicast transmissions are relatively expensive.
	Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely		Wireless networks such as Wi-Fi [IEEE.802.11] may be adversely
	affected by excessive mDNS traffic due to the higher network overhead		affected by excessive mDNS traffic due to the higher network overhead
	of multicast transmissions. Wireless mesh networks such as 6LoWPAN		of multicast transmissions. Wireless mesh networks such as 6LoWPAN
	[RFC4944] are effectively multi-link subnets [RFC4903] where		[RFC4944] are effectively multi-link subnets [RFC4903] where
	multicasts must be forwarded by intermediate nodes.		multicasts must be forwarded by intermediate nodes.
	skipping to change at page 3, line 15		skipping to change at page 3, line 17
	This document defines the problem statement and gathers requirements		This document defines the problem statement and gathers requirements
	for Scalable DNS-SD/mDNS Extensions.		for Scalable DNS-SD/mDNS Extensions.
	1.1. Terminology and Acronyms		1.1. Terminology and Acronyms
	Service: A listening endpoint (host and port) for a given application		Service: A listening endpoint (host and port) for a given application
	protocol. Services are identified by Service Instance Names.		protocol. Services are identified by Service Instance Names.
	DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional		DNS-SD: DNS-Based Service Discovery [DNS-SD] is a conventional
	application of DNS Resource Records and messages to facilitate the		application of DNS Resource Records and messages to facilitate the
	discovery and location of services.		naming, discovery, and location of services. When used alone, it
			generally refers to the wide-area unicast protocol.
	mDNS: Multicast DNS [mDNS] is a mechanism that facilitates DNS-SD on		mDNS: Multicast DNS [mDNS] is a mechanism that facilitates
	a local link in the absence of traditional DNS infrastructure.		distributed DNS-like capabilities (including DNS-SD) on a local link
			without need of traditional DNS infrastructure.
	SSD: Scalable DNS-SD is a future extension of DNS-SD (and perhaps		SSD: Scalable Service Discovery (or Scalable DNS-SD) is a future
	mDNS) that meets the requirements set forth in this document.		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		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.		DNS subdomain, that is the target of a given SSD query.
	Zero Configuration: A deployment of SSD that requires no		Zero Configuration: A deployment of SSD that requires no
	administration (although some administration may be optional).		administration (although some administration may be optional).
	Incremental Deployment: An orderly transition, as a network		Incremental Deployment: An orderly transition, as a network
	installation evolves, from DNS-SD/mDNS to SSD.		installation evolves, from DNS-SD/mDNS to SSD.
	2. Problem Statement		2. Problem Statement
	Service discovery beyond the local link is perhaps the most important		Service discovery beyond the local link is perhaps the most important
	feature currently missing from the DNS-SD/mDNS framework. Other		feature currently missing from the DNS-SD-over-mDNS framework (also
	issues and requirements are summarized below.		written as "DNS-SD over mDNS" or "DNS-SD/mDNS"). Other issues and
			requirements are summarized below.
	2.1. Multi-link Naming and Discovery		2.1. Multi-link Naming and Discovery
	A list of desired DNS-SD/mDNS improvements from network		A list of desired DNS-SD/mDNS improvements from network
	administrators in the research and education community was issued in		administrators in the research and education community was issued in
	the form of the Educause petition [EP]. The following is a summary		the form of the Educause petition [EP]. The following is a summary
	of their technical issues:		of their technical issues:
	o Products that advertise services such as printing and multimedia		o Products that advertise services such as printing and multimedia
	streaming via DNS-SD/mDNS are not currently discoverable by		streaming via DNS-SD over mDNS are not currently discoverable by
	devices on other links. It is common practice for enterprises and		devices on other links. It is common practice for enterprises and
	institutions to use wireless links for client access and wired		institutions to use wireless links for client access and wired
	networks for server infrastructure, typically on different		networks for server infrastructure, typically on different
	subnets. DNS-SD used with conventional unicast DNS does work when		subnets. DNS-SD used with conventional unicast DNS does work when
	devices are on different links, but the resource records that		devices are on different links, but the resource records that
	describe the service must somehow be entered into the unicast DNS		describe the service must somehow be entered into the unicast DNS
	namespace.		namespace.
	o DNS-SD resource records may be entered manually into a unicast DNS		o DNS-SD resource records may be entered manually into a unicast DNS
	zone file [static], but this task must be performed by a DNS		zone file [STATIC], but this task must be performed by a DNS
	administrator. It is labor-intensive and brittle when IP		administrator. It is labor-intensive and brittle when IP
	addresses of devices change dynamically, as is common when DHCP is		addresses of devices change dynamically, as is common when DHCP is
	used.		used.
	o Automatically adding DNS-SD records using DNS Update works, but		o Automatically adding DNS-SD records using DNS Update works, but
	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		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
	administration than typically needed for a unicast DNS server.		than typically needed for a unicast DNS server.
	The following is a summary of their technical requirements:		The following is a summary of their technical requirements:
	o It must scale to a range of hundreds to thousands of DNS-SD/mDNS		o It must scale to a range of hundreds to thousands of DNS-SD/mDNS-
	enabled devices in a given environment.		enabled devices in a given environment.
	o It must simultaneously operate over a variety of network link		o It must simultaneously operate over a variety of network link
	technologies, such as wired and wireless networks.		technologies, such as wired and wireless networks.
	o It must not significantly increase network traffic (wired or		o It must not significantly increase network traffic (wired or
	wireless).		wireless).
	o It must be cost-effective to manage at up to enterprise scale.		o It must be cost-effective to manage at up to enterprise scale.
	skipping to change at page 5, line 18		skipping to change at page 5, line 25
	Enabling service discovery on IEEE 802.11 networks requires that the		Enabling service discovery on IEEE 802.11 networks requires that the
	number of multicast frames be restricted to a suitably low value, or		number of multicast frames be restricted to a suitably low value, or
	replaced with unicast frames to use the MAC's reliability features.		replaced with unicast frames to use the MAC's reliability features.
	2.3. Low Power and Lossy Networks (LLNs)		2.3. Low Power and Lossy Networks (LLNs)
	Emerging wireless mesh networking technologies such as RPL [RFC6550]		Emerging wireless mesh networking technologies such as RPL [RFC6550]
	and 6LoWPAN present several challenges for the current DNS-SD/mDNS		and 6LoWPAN present several challenges for the current DNS-SD/mDNS
	design. First, Link-Local multicast scope [RFC4291] is defined as a		design. First, Link-Local multicast scope [RFC4291] is defined as a
	single-hop neighborhood. A single subnet prefix in a wireless mesh		single-hop neighborhood. A wireless mesh network representing a
	network may often span multiple links, therefore a larger multicast		single logical subnet may often extend to multiple hops [RFC4903],
	scope is required to span it [RFC7346]. Multicast DNS is		therefore a larger multicast scope is required to span it [RFC7346].
	intentionally not specified for greater than Link-Local scope,		Multicast DNS was intentionally not specified for greater than Link-
	because of the additional multicast traffic that would generate.		Local scope, because of the additional off-link multicast traffic
			that would generate.
	Additionally, low-power nodes may be offline for significant periods		Additionally, low-power nodes may be offline for significant periods
	either because they are "sleeping" or due to connectivity problems.		either because they are "sleeping" or due to connectivity problems.
	In such cases LLN nodes might fail to respond to queries or defend		In such cases LLN nodes might fail to respond to queries or defend
	their names using the current design.		their names using the current design.
	3. Basic Use Cases		3. Basic Use Cases
	The following use cases are defined with different characteristics to		The following use cases are defined with different characteristics to
	help motivate, distinguish, and classify the target requirements.		help motivate, distinguish, and classify the target requirements.
	They cover a spectrum of increasing deployment and administrative		They cover a spectrum of increasing deployment and administrative
	complexity.		complexity.
	(A) Personal Area networks (PANs): the simplest example of a		(A) Personal Area networks (PANs): the simplest example of a
	network may consist of a single client and server, e.g., one		network may consist of a single client and server, e.g., one
	laptop and one printer, on a common link. PANs that do not		laptop and one printer, on a common link. PANs that do not
	contain a router may use Zero Configuration Networking [ZC] to		contain a router may use Zero Configuration Networking [ZC] to
	self-assign link-local addresses [RFC3927] [RFC4862], and		self-assign link-local addresses [RFC3927] [RFC4862], and
	Multicast DNS [mDNS] to provide naming and service discovery.		Multicast DNS [mDNS] to provide naming and service discovery, as
			currently implemented and deployed in Mac OS X, iOS, Windows [B4W]
			and Android [NSD].
	(B) Classic home or 'hotspot' networks, with the following		(B) Classic home or 'hotspot' networks, with the following
	properties:		properties:
	* Single exit router: the network may have one or more upstream		* Single exit router: the network may have one or more upstream
	providers or networks, but all outgoing and incoming traffic		providers or networks, but all outgoing and incoming traffic
	goes through a single router.		goes through a single router.
	* One-level depth: a single physical link, or multiple physical		* One-level depth: a single physical link, or multiple physical
	links bridged to form a single logical link, that is connected		links bridged to form a single logical link, that is connected
	to the default router. The single logical link provides a		to the default router. The single logical link provides a
	single broadcast domain, facilitating use of link-local		single broadcast domain, facilitating use of link-local
	Multicast DNS, and also ARP, which enables the home or		Multicast DNS, and also ARP, which enables the home or
	'hotspot' network to consist of just a single IPv4 subnet.		'hotspot' network to consist of just a single IPv4 subnet.
	* Single administrative domain: all nodes under the same		* Single administrative domain: all nodes under the same
	administrative authority. (However, this does not necessarily		administrative authority. (However, this does not necessarily
	imply a network administrator.)		imply a network administrator.)
	(C) Advanced home and small business networks		(C) Advanced home and small business networks [RFC7368]:
	[I-D.ietf-homenet-arch]:
	Like B but consist of multiple wired and/or wireless links,		Like B, but consist of multiple wired and/or wireless links,
	connected by routers, behind the single exit router. However, the		connected by routers, generally behind a single exit router.
	forwarding nodes are largely self-configuring and do not require		However, the forwarding nodes are largely self-configuring and do
	routing protocol administration. Such networks should also not		not require routing protocol administration. Such networks should
	require DNS administration.		also not require DNS administration.
	(D) Enterprise networks:		(D) Enterprise networks:
	Like C but consist of arbitrary network diameter under a single		Consist of arbitrary network diameter under a single
	administrative authority. A large majority of the forwarding and		administrative authority. A large majority of the forwarding and
	security devices are configured. Large-scale conference-style		security devices are configured and multiple exit routers are more
	networks, which are predominantly wireless access, e.g., as		common. Large-scale conference-style networks, which are
	available at IETF meetings, also fall within this category.		predominantly wireless access, e.g., as available at IETF
			meetings, also fall within this category.
	(E) Higher Education networks:		(E) Higher Education networks:
	Like D but the core network may be under a central administrative		Like D but the core network may be under a central administrative
	domain while leaf networks are under local administrative domains.		domain while leaf networks are under local administrative domains.
	(F) Mesh networks such as RPL/6LoWPAN:		(F) Mesh networks such as RPL/6LoWPAN:
	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.
	skipping to change at page 7, line 7		skipping to change at page 7, line 20
	should be considered in isolation.		should be considered in isolation.
	REQ1: For use cases A, B, and C, there should be a Zero		REQ1: For use cases A, B, and C, there should be a Zero
	Configuration mode of operation. This implies that servers		Configuration mode of operation. This implies that servers
	and clients should be able to automatically determine a		and clients should be able to automatically determine a
	default Scope of Discovery in which to advertise and discover		default Scope of Discovery in which to advertise and discover
	services, respectively.		services, respectively.
	REQ2: For use cases C, D, and E, there should be a way to configure		REQ2: For use cases C, D, and E, there should be a way to configure
	Scopes of Discovery that support a range of topologically-		Scopes of Discovery that support a range of topologically-
	independent zones (e.g., from department to campus-wide). If		independent zones (e.g., from department to campus-wide).
	multiple scopes are available, there must be a way to		This capability must exist in the protocol; individual
	enumerate the choices from which a selection can be made.		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		REQ3: As stated in REQ2 above, the discovery scope need not be
	aligned to network topology. For example, it may instead be		aligned to network topology. For example, it may instead be
	aligned to physical proximity (e.g. building) or		aligned to physical proximity (e.g., building) or
	organizational structure.		organizational structure, (e.g., "Sales" vs. "Engineering").
	REQ4: For use cases C, D, and E, there should be an incremental way		REQ4: For use cases C, D, and E, there should be an incremental way
	to deploy the solution.		to deploy the solution.
	REQ5: SSD should integrate with current link scope DNS-SD/mDNS		REQ5: SSD should leverage and build upon current link scope DNS-SD/
	protocols and deployments.		mDNS protocols and deployments.
	REQ6: SSD must not adversely affect or break any other current		REQ6: SSD must not adversely affect or break any other current
	protocols or deployments.		protocols or deployments.
	REQ7: SSD must be capable of operating across networks that are not		REQ7: SSD must be capable of operating across networks that are not
	limited to a single link or network technology, including		limited to a single link or network technology, including
	clients and services on non-adjacent links.		clients and services on non-adjacent links.
	REQ8: It is desirable that a user or device be able to discover		REQ8: It is desirable that a user or device be able to discover
	services within the sites or networks to which the user or		services within the sites or networks to which the user or
	skipping to change at page 7, line 50		skipping to change at page 8, line 22
	REQ11: SSD must be scalable to thousands of nodes with minimal		REQ11: SSD must be scalable to thousands of nodes with minimal
	configuration and without degrading network performance. A		configuration and without degrading network performance. A
	possible figure of merit is that, as the number of services		possible figure of merit is that, as the number of services
	increases, the amount of traffic due to SSD on a given link		increases, the amount of traffic due to SSD on a given link
	remains relatively constant.		remains relatively constant.
	REQ12: SSD should enable a way to provide a consistent user		REQ12: SSD should enable a way to provide a consistent user
	experience whether local or remote services are being		experience whether local or remote services are being
	discovered.		discovered.
	REQ13: The information presented by SSD should closely reflect		REQ13: The information presented by SSD should closely reflect the
	reality. That is, new information should be available within		current state of discoverable services on the network. That
	a few seconds and stale information should not persist		is, new information should be available within a few seconds
	indefinitely. In networking all information is necessarily		and stale information should not persist indefinitely. In
	somewhat out-of-date by the time it reaches the receiver,		networking all information is necessarily somewhat out-of-
	even if only by a few microseconds, or less. Thus timeliness		date by the time it reaches the receiver, even if only by a
	is always an engineering trade-off against efficiency. The		few microseconds, or less. Thus timeliness is always an
	engineering decisions for SSD should appropriately balance		engineering trade-off against efficiency. The engineering
	timeliness against network efficiency.		decisions for SSD should appropriately balance timeliness
			against network efficiency.
	REQ14: SSD should operate over existing networks (as described by		REQ14: SSD should operate over existing networks (as described by
	use cases A-F above) without requiring changes to the network		use cases A-F above) without requiring changes to the network
	technology or deployment.		at the physical, link, or internetworking layers.
	5. Namespace Considerations		5. Namespace Considerations
	The traditional unicast DNS namespace contains, for the most part,		The traditional unicast DNS namespace contains, for the most part,
	globally unique names. Multicast DNS provides every link with its		globally unique names. Multicast DNS provides every link with its
	own separate link-local namespace, where names are unique only within		own separate link-local namespace, where names are unique only within
	the context of that link. Clients discovering services may need to		the context of that link. Clients discovering services may need to
	differentiate between local and global names, and may need to		differentiate between local and global names, and may need to
	determine when names in different namespaces identify the same		determine when names in different namespaces identify the same
	service.		service.
	skipping to change at page 9, line 22		skipping to change at page 9, line 43
	For example, since mDNS is currently restricted to a single link, the		For example, since mDNS is currently restricted to a single link, the
	scope of the advertisement is limited, by design, to the shared link		scope of the advertisement is limited, by design, to the shared link
	between client and server. If the advertisement propagates to a		between client and server. If the advertisement propagates to a
	larger set of links than expected, this may result in unauthorized		larger set of links than expected, this may result in unauthorized
	clients (from the perspective of the owner) discovering and then		clients (from the perspective of the owner) discovering and then
	potentially attempting to connect to the advertised service. It also		potentially attempting to connect to the advertised service. It also
	discloses information (about the host and service) to a larger set of		discloses information (about the host and service) to a larger set of
	potential attackers.		potential attackers.
	Note that discovery of a service does not necessarily imply that the		Note that discovery of a service does not necessarily imply that the
	service is reachable or can be connected to. Specific access control		service is reachable by, or can be connected to, or can be used by, a
	mechanisms are out of scope of this document.		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,		If the scope of the discovery is not properly set up or constrained,
	then information leaks will happen outside the appropriate network.		then information leaks will happen outside the appropriate network.
	6.2. Multiple Namespaces		6.2. Multiple Namespaces
	There is a possibility of conflicts between the local and global DNS		There is a possibility of conflicts between the local and global DNS
	namespaces. Without adequate feedback, a discovering client may not		namespaces. Without adequate feedback, a discovering client may not
	know if the advertised service is the correct one, therefore enabling		know if the advertised service is the correct one, therefore enabling
	potential attacks.		potential attacks.
	skipping to change at page 10, line 24		skipping to change at page 10, line 44
	considered as part of any security solution. Authentication of any		considered as part of any security solution. Authentication of any
	particular service is outside the scope of this document.		particular service is outside the scope of this document.
	6.5. Access Control		6.5. Access Control
	Access Control refers to the ability to restrict which users are able		Access Control refers to the ability to restrict which users are able
	to use a particular service that might be advertised via DNS-SD. In		to use a particular service that might be advertised via DNS-SD. In
	this case, "use" of a service is different from the ability to		this case, "use" of a service is different from the ability to
	"discover" or "reach" a service.		"discover" or "reach" a service.
	While access control to an advertised service is outside the scope of		While controlling access to an advertised service is outside the
	DNS-SD, we note that access control today often is provided by		scope of DNS-SD, we note that access control today often is provided
	existing site infrastructure (e.g. router access control lists,		by existing site infrastructure (e.g., router access control lists,
	firewalls) and/or by service-specific mechanisms (e.g. user		firewalls) and/or by service-specific mechanisms (e.g., user
	authentication to the service). For example, many networked printers		authentication to the service). For example, networked printers can
	already support access controls via a user-id and password. At least		control access via a user-id and password. Apple's software supports
	one widely deployed DNS-SD + mDNS implementation supports such access		such access control for USB printers shared via Mac OS X Printer
	controls for printers. So the reliance on existing service-specific		Sharing, as do many networked printers themselves. So the reliance
	security mechanisms (i.e. outside the scope of DNS-SD) does not		on existing service-specific security mechanisms (i.e. outside the
	create new security considerations.		scope of DNS-SD) does not create new security considerations.
	6.6. Privacy Considerations		6.6. Privacy Considerations
	Mobile devices such as smart phones or laptops that can expose the		Mobile devices such as smart phones or laptops that can expose the
	location of their owners by registering services in arbitrary zones		location of their owners by registering services in arbitrary zones
	pose a risk to privacy. Such devices must not register their		pose a risk to privacy. Such devices must not register their
	services in arbitrary zones without the approval ("opt-in") of their		services in arbitrary zones without the approval ("opt-in") of their
	users. However, it should be possible to configure one or more		users. However, it should be possible to configure one or more
	"safe" zones in which mobile devices may automatically register their		"safe" zones in which mobile devices may automatically register their
	services.		services.
	7. IANA Considerations		7. IANA Considerations
	This document currently makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed upon publication as
	an RFC.
	8. Acknowledgments		8. Acknowledgments
	We gratefully acknowledge contributions and review comments made by		We gratefully acknowledge contributions and review comments made by
	RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David		RJ Atkinson, Tim Chown, Guangqing Deng, Ralph Droms, Educause, David
	Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and		Farmer, Matthew Gast, Thomas Narten, Doug Otis, David Thaler, and
	Peter Van Der Stok.		Peter Van Der Stok.
	9. References		9. References
	skipping to change at page 11, line 41		skipping to change at page 12, line 13
	Networks", RFC 4944, September 2007.		Networks", RFC 4944, September 2007.
	[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,		[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
	Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.		Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
	Alexander, "RPL: IPv6 Routing Protocol for Low-Power and		Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
	Lossy Networks", RFC 6550, March 2012.		Lossy Networks", RFC 6550, March 2012.
	[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,		[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
	August 2014.		August 2014.
			[RFC7368] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
			"IPv6 Home Networking Architecture Principles", RFC 7368,
			October 2014.
	[mDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,		[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-homenet-arch]		[B4W] "Bonjour for Windows",
	Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,		<http://en.wikipedia.org/wiki/Bonjour_(software)>.
	"IPv6 Home Networking Architecture Principles", draft-
	ietf-homenet-arch-17 (work in progress), July 2014.
	[I-D.sullivan-dnssd-mdns-dns-interop]		[I-D.sullivan-dnssd-mdns-dns-interop]
	Sullivan, A., "Requirements for Labels to Interoperate		Sullivan, A., "On Interoperation of Labels Between mDNS
	Between mDNS and DNS", draft-sullivan-dnssd-mdns-dns-		and DNS", draft-sullivan-dnssd-mdns-dns-interop-01 (work
	interop-00 (work in progress), January 2014.		in progress), October 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/		<http://standards.ieee.org/getieee802/
	download/802.11-2012.pdf>.		download/802.11-2012.pdf>.
	[static] "Manually Adding DNS-SD Service Discovery Records to an		[NSD] "NsdManager | Android Developer", June 2012,
			<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,		Existing Name Server", July 2013,
	<http://www.dns-sd.org/ServerStaticSetup.html>.		<http://www.dns-sd.org/ServerStaticSetup.html>.
	[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration		[ZC] Cheshire, S. and D. Steinberg, "Zero Configuration
	Networking: The Definitive Guide", O'Reilly Media, Inc. ,		Networking: The Definitive Guide", O'Reilly Media, Inc. ,
	ISBN 0-596-10100-7, December 2005.		ISBN 0-596-10100-7, December 2005.
	Authors' Addresses		Authors' Addresses
	Kerry Lynn		Kerry Lynn
	Consultant		Verizon
			50 Sylvan Road
			Waltham , MA 95014
			USA
	Phone: +1 978 460 4253		Phone: +1 781 296 9722
	Email: kerlyn@ieee.org		Email: kerry.lynn@verizon.com
	Stuart Cheshire		Stuart Cheshire
	Apple, Inc.		Apple, Inc.
	1 Infinite Loop		1 Infinite Loop
	Cupertino , California 95014		Cupertino , CA 95014
	USA		USA
	Phone: +1 408 974 3207		Phone: +1 408 974 3207
	Email: cheshire@apple.com		Email: cheshire@apple.com
	Marc Blanchet		Marc Blanchet
	Viagenie		Viagenie
	246 Aberdeen		246 Aberdeen
	Quebec , Quebec G1R 2E1		Quebec , QC G1R 2E1
	Canada		Canada
	Email: Marc.Blanchet@viagenie.ca		Email: Marc.Blanchet@viagenie.ca
	URI: http://viagenie.ca		URI: http://viagenie.ca
	Daniel Migault		Daniel Migault
	Orange		Ericsson
	38-40 rue du General Leclerc		8400 boulevard Decarie
	Issy-les-Moulineaux 92130		Montreal , QC H4P 2N2
	France		Canada
	Phone: +33 1 45 29 60 52		Phone: +1 514 452 2160
	Email: mglt.biz@gmail.com		Email: daniel.migault@ericsson.com
End of changes. 45 change blocks.
	98 lines changed or deleted		122 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/