* [Cerowrt-devel] Fwd: [homenet] Fwd: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd)
[not found] ` <EMEW3|8aa948fcc354e31ce75d7c68fdd271a7p9P8sD03tjc|ecs.soton.ac.uk|1251F91C-E0D0-452E-B397-BDFDC9818419@ecs.soton.ac.uk>
@ 2013-10-26 17:55 ` Dave Taht
0 siblings, 0 replies; only message in thread
From: Dave Taht @ 2013-10-26 17:55 UTC (permalink / raw)
To: cerowrt-devel, Dnsmasq-discuss
The problems cerowrt has with multicast dns over multiple interfaces
are kind of universal.
A new ietf working group is being formed to address the problems with
service discovery beyond the local link and finally (I hope) re-unify
mdns with regular DNS. See below for the announcement. One set of
ideas also on the table is hybrid mdns:
http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02
I'd really welcome a means of doing service discovery over routed
links that was sane. To me, though, the grand unification of dns,
needs a daemon written that integrates with things like dnsmasq much
better than mdnsresponder or avahi currently do.
There's a ton of things that are hard. For example dns parsing libs
are generally all pretty limited, with the most comprehensive survey
I've seen
http://boston.conman.org/2010/12/06.1
and that's just the tip of the iceberg. What else is hard?
The proxy needs to be small enough to run on routers, and powerful
enough to scale to college campuses. I think there are some commercial
possibilities, but not a lot, so it seems likely that hybrid dns needs
to be an open source project.
While I know there are quite a few people annoyed at present multicast
dns behavior over local links - I don't know who would be interested
in getting to exchange ideas from this wg and turn them into viable
code, or who could fund the work?
---------- Forwarded message ----------
From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Sat, Oct 26, 2013 at 12:54 AM
Subject: [homenet] Fwd: WG Action: Formed Extensions for Scalable DNS
Service Discovery (dnssd)
To: "homenet@ietf.org Group" <homenet@ietf.org>
Hi,
For those who may have missed the announcement, the new dnssd WG has
now been formed, see below.
During the BoF phase the group was formerly known as mdnsext. The
name of the mail list has thus also changed from mdnsext@ietf.org to
dnssd@ietf.org (all subsrcibers of the former should have been moved
to the latter).
dnssd meets on Friday from 11:00am in Vancouver. The provisional agenda is here:
https://datatracker.ietf.org/meeting/88/agenda/dnssd/
Tim
Begin forwarded message:
From: The IESG <iesg-secretary@ietf.org>
Subject: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd)
Date: 25 October 2013 18:06:40 BST
To: IETF-Announce <ietf-announce@ietf.org>
Cc: dnssd WG <dnssd@ietf.org>
Reply-To: ietf@ietf.org
A new IETF working group has been formed in the Internet Area. For
additional information please contact the Area Directors or the WG
Chairs.
Extensions for Scalable DNS Service Discovery (dnssd)
------------------------------------------------
Current Status: Proposed WG
Chairs:
Ralph Droms <rdroms.ietf@gmail.com>
Tim Chown <tjc@ecs.soton.ac.uk>
Assigned Area Director:
Ted Lemon <ted.lemon@nominum.com>
Mailing list
Address: dnssd@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd
Archive: http://www.ietf.org/mail-archive/web/dnssd
Charter:
Background
----------
Zero configuration networking protocols are currently well suited to
discover services within the scope of a single link. In particular,
the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
referred to using Apple Computer Inc.'s trademark, Bonjour) are
widely used for DNS-based service discovery and host name resolution
on a single link.
The DNS-SD/mDNS protocol suite is used in many scenarios including
home, campus, and enterprise networks. However, the zero configuration
mDNS protocol is constrained to link-local multicast scope by design,
and therefore cannot be used to discover services on remote links.
In a home network that consists of a single (possibly bridged) link,
users experience the expected discovery behavior; available services
appear because all devices share a common link. However, in multi-link
home networks (as envisaged by the homenet WG) or in routed campus or
enterprise networks, devices and users can only discover services on
the same link, which is a significant limitation. This has led to
calls, such as 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.
In addition, the "Smart Energy Profile 2 Application Protocol Standard",
published by ZigBee Alliance and HomePlug Powerline Alliance specifies
the DNS-SD/mDNS protocol suite as the basis for its method of zero
configuration service discovery. However, its use of wireless mesh
multi-link subnets in conjunction with traditional routed networks will
require extensions to the DNS-SD/mDNS 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 proprietary 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.
Working Group Description
-------------------------
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.
The WG will consider the tradeoffs between reusing/extending existing
protocols and developing entirely new ones. It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNS
deployments. Any solution developed by the dnssd WG must 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.
Current zero configuration discovery protocols are constrained to
operate within a single link, which implicitly limits the scope of
discovery. In extending service discovery protocols to operate over
multiple links, devices will inherently become discoverable over a
wider area, which may introduce security or privacy concerns. The WG
will consider such concerns when exploring the solution space for
multi-link service discovery.
To that end, the primary goals of the dnssd 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
devices.
(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 campus scenario.
(E) Mesh networks such as RPL/6LoWPAN, with one or more links per
routable prefix, which may or may not have external connectivity.
The topology may use technologies including 802.11 wireless,
HomePlug AV and GP, and ZigBee IP.
In the above scenarios, the aim is to facilitate service discovery
across the defined site. It is also desirable that a user or device,
when away from such a site, is still able to discover services
within that site, e.g. a user discovering services in their home
network while remote from it.
It is also desirable that multiple discovery scopes are supported,
from the point of view of either performing discovery within a
specified scope or advertisement within a specified scope, and
being able to discover (enumerate) the set of scopes such that
an application could then choose to do either. It should be noted
that scope in this sense might refer to 'building' or 'room' and thus
might have no correlation to network topology.
2. To develop an improved, scalable solution for service discovery
that can operate in multi-link networks, where devices may be
in neighboring or non-neighboring links, applicable to
the scenarios above. The solution will consider tradeoffs between
reusing/extending existing protocols and developing entirely new
protocols.
The solution should include documentation or definition of the
interfaces that can be implemented, separately to transport of
the information.
3. To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
It is important that the dnssd 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 dnssd WG, but
coordination between the WGs is desirable.
Milestones:
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
document
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.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply [flat|nested] only message in thread