DNS-SD Extensions

The information below is for an older version of the current proposed rechartering effort
Document Proposed charter DNS Service Discovery Extensions WG (dnssdext) Snapshot
Title DNS-SD Extensions
Last updated 2013-09-14
State Draft Charter Rechartering
WG State Proposed
IESG Responsible AD √Čric Vyncke
Charter Edit AD (None)
Send notices to (None)


dnssdext Draft Charter, rev -02

Group Nam:      Extensions for Scalable DNS Service Discovery

Acronym:        dnssdext

Area:           Internet Area (int)

State:          Active



Chairs:         <TBD>

Area Director:  Ted Lemon <ted.lemon@nominum.com>

Mailing List

Address:        dnssdext@ietf.org

To Subscribe:   dnssdext-request@ietf.org

Archive:        http://www.ietf.org/mail-archive/web/dnssdext

                http://www.ietf.org/mail-archive/web/mdnsext (1st/2nd BoF)

Jabber Chat

Room Address:   xmpp:dnssdext@jabber.ietf.org

Logs:           http://jabber.ietf.org/logs/dnssdext

                http://jabber.ietf.org/logs/mdnsext (1st BoF)



Currently, zero configuration networking protocols are generally used

to discover services within the scope of a single link. In particular,

the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD

(RFC 6763), are widely used for discovery and resolution of services,

as well as names, on a single link.

The Bonjour protocol suite is commonly used in many scenarios,

including home networks, commercial and campus enterprise networks,

and may be of use in certain mesh networks. However, the zero

configuration multicast Bonjour protocols are constrained to

link-local scope, so can only be used to discover services on the same


In a typical current home network, which is commonly a single link,

users should experience the desired discovery behaviour, because all

devices share that link. However, in future multi-link home networks

(as envisaged by the homenet WG) and in routed campus or enterprise

networks, devices and thus users can only discover services on the

same links, which is a significant limitation. This has led to calls,

such as those by the Educause petition, to develop an appropriate

service discovery solution to span multiple links, or to perform

discovery across a wide area, not necessarily on directly connected

links, e.g., on links elsewhere on the same site, or links at a remote


In addition, the "Smart Energy Profile 2 Application Protocol

Standard", published by ZigBee Alliance and Homeplug Alliance

specifies the Bonjour protocols as its method of zero configuration

discovery. However, its use of wireless mesh multi-link subnets and

its use across traditional routed networks will require extensions to

the Bonjour protocols to allow operation across multiple links.

The scenarios in which multi-link service discovery is required may

be zero configuration environments, environments where administrative

configuration is supported, or a mixture of the two.

As demand for service discovery across wider area routed networks

grows, some vendors are beginning to ship their own early solutions. 

It is thus both timely and important that efforts to develop improved, 

scalable, autonomous service discovery solutions for routed networks 

are coordinated towards producing a single, standards-based solution.

The WG will consider the tradeoffs between reusing/extending existing

protocols, and developing entirely new ones. But it is highly

desirable that any new solution is backwardly compatible with existing

mDNS and DNS-SD deployments.  Any solution developed by the dnssdext

WG wil not conflict or interfere with the operation of other

zero-configuration service and naming protocols such as uPnP or LLMNR.

Integration with such protocols is out of scope for this WG.

The focus of the WG is to develop a solution for extended, scalable 

DNS-SD. This work is likely to highlight problems and challenges with 

naming protocols, as some level of coexistence will be required between 

local zero configuration name services and those forming part of the 

global DNS. It is important that these issues are captured and 

documented for further analysis; solving those problems is however not 

within the scope of this WG.

Working Group Description


To that end, the primary goals of the dnssdext WG are as follows:

1. To document a set of requirements for scalable, autonomous

   DNS-based service discovery in routed, multi-link networks in the

   following five scenarios:

   (A) Personal Area networks, e.g., one laptop and one printer.

       This is the simplest example of a service discovery network,

       and may or may not have external connectivity. 

   (B) Home networks, as envisaged by the homenet WG, consisting of 

       one or more exit routers, with one or more upstream providers 

       or networks, and an arbitrary internal topology with 

       heterogeneous media where routing is automatically configured. 

       The home network would typically be a single zero configuration 

       administrative domain with a relatively limited number of 


   (C) Wireless 'hotspot' networks, which may include wireless networks

       made available in public places, or temporary or permanent

       infrastructures targeted towards meeting or conference style

       events, e.g., as provided for IETF meetings. In such

       environments other devices may be more likely to be 'hostile'

       to the user.

   (D) Enterprise networks, consisting of larger routed networks, 

       with large numbers of devices, which may be deployments 

       spanning over multiple sites with multiple upstreams, and

       one more more administrative domains (depending on internal

       administrative delegation). The large majority of the 

       forwarding and security devices are configured. These may

       be commercial or academic networks, with differing levels 

       of administrative control over certain devices on the network,

       and BYOD devices commonplace in the amps scenario.

   (D) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix

       networks, which may or may not have external connectivity.

       The topology may use technologies including 802.11 wireless, 

       HomePlug AV and GP, and ZigBee IP. 

   It is desirable that remote service discovery is supported, e.g., 

   a user being able to discover services in their home network while

   away from the network, and that co-resident services can be 

   discovered, e.g., a printer on a hotel network while the user is

   on a separately administered network at the same location.

   It is also desirable that multiple discovery scopes are supported,

   from the point of view of announcements and discovery, be the

   scope 'site', 'building' or 'room'.  A user for example may only

   be interested in devices in the same room.

2. To develop an improved, scalable solution for service discovery 

   that can operate in multi-link networks, where devices may be

   in neighbouring or non-neighbouring links, applicable to

   the scenarios above. The solution will consider tradeoffs between

   reusing/extending existing protocols and developing entirely new


   The solution should include documentation or definition of the

   interfaces that can be implemented, separately to transport of 

   the information.

3. To publish an Informational RFC that documents challenges and

   problems encountered in the coexistence of zero configuration and 

   global DNS name services in such multi-link networks, which should 

   include consideration of both the name resolution mechanism and 

   the namespace.

It is important that the dnssdext WG takes input from stakeholders in

the scenarios it is considering. For example, the homenet WG is

currently evaluating its own requirements for naming and service

discovery; it is up to the homenet WG as to whether it wishes to

recommend adoption of the solution developed in the dnssdext WG, but

coordination between the WGs is desirable.


The WG will produce three documents: an Informational RFC on the

requirements for service discovery protocols operating on potentially

non-neighbouring multi-link networks as described above; a Standards

Track RFC documenting an extended, scalable service discovery solution 

that is applicable to those scenarios; and an Informational RFC 

describing the problems arising when developing the extended SD solution 

and how it affects the integration of local zero configuration and global 

DNS name services.


Sep 2013 Formation of the WG

Oct 2013 Adopt requirements draft as WG document

Jan 2014 Submit requirements draft to the IESG as an Informational RFC

Mar 2014 Adopt wide-area service discovery solution draft as WG


Mar 2014 Adopt Informational document on the problems and challenges

         arising for zeroconf and unicast DNS name services

Sep 2014 Submit wide-area service discovery solution draft to the IESG

         as Standards Track RFC 

Sep 2014 Submit the zeroconf and unicast DNS "problems and challenges" 

         draft to the IESG as Informational.