Simple Homenet Naming and Service Discovery Architecture
Nominum, Inc.
800 Bridge Parkway
Redwood City
California
United States of America
94065
+1 650 381 6000
ted.lemon@nominum.com
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
daniel.migault@ericsson.com
This document describes a simple name resolution and service discovery architecture for homenets. This architecture covers
local publication of names, as well as name resolution for local and global names.
Associating domain names with hosts on the Internet is a key factor in enabling communication with hosts, particularly for
service discovery. This document describes a simple way of providing name service and service discovery for homenets.
In principle, it may make sense to be able to publish names of devices on the homenet, so that services on the homenet
can be accessed outside of the homenet. Such publication is out of scope for this document. It may be desirable
to secure the homenet zone using DNSSEC. This is likewise out of scope for this document.
In order to provide name service, several provisioning mechanisms must be available:
Provisioning of a domain name under which names can be published and services advertised
Associating names that are subdomains of that name with hosts.
Advertising services available on the local network by publishing resource records on those names.
Distribution of names published in that namespace to servers that can be queried in order to resolve names
Correct advertisement of name servers that can be queried in order to resolve names
Timely removal of published names and resource records when they are no longer in use
Homenet adds the following considerations:
Some names may be published in a broader scope than others. For example, it may be desirable to advertise some homenet
services to users who are not connected to the homenet. However, it is unlikely that all services published on the home
network would be appropriate to publish outside of the home network. In many cases, no services will be appropriate to
publish outside of the network, but the ability to do so is required.
Users cannot be assumed to be skilled or knowledgeable in name service operation, or even to have any sort of mental
model of how these functions work. All of the operations mentioned here must reliably function automatically, without any
user intervention or debugging.
Because user intervention cannot be required, naming conflicts must be resolved automatically, and, to the extent
possible, transparently.
Hosts that do not implement any homenet-specific capabilities must still be able to discover and access services on the
homenet, to the extent possible.
Devices that provide services must be able to publish those services on the homenet, and those services must be
available from any part of the homenet, not just the link to which the device is attached.
Homenet explicitly supports multihoming—connecting to more than one Internet Service Provider—and therefore support for
multiple provisioning domains is required to deal with situations where the DNS may give a
different answer depending on whether caching resolvers at one ISP or another are queried.
Previous attempts to automate naming and service discovery in the context of a home network are able to function with
varying degrees of success depending on the topology of the home network. For example, Multicast DNS
can provide naming and service discovery , but only within a single
multicast domain.
The Domain Name System provides a hierarchical namespace , a mechanism for querying name servers
to resolve names , a mechanism for updating namespaces by adding and removing names
, and a mechanism for discovering services . Unfortunately, DNS provides
no mechanism for automatically provisioning new namespaces, and secure updates to namespaces require pre-shared keys,
which won't work for an unmanaged network. DHCP can be used to populate names in a DNS namespace; however at present DHCP
cannot provision service discovery information.
Hybrid Multicast DNS proposes a mechanism for extending multicast DNS beyond a
single multicast domain.. However, it has serious shortcomings as a solution to the Homenet naming problem. The most
obvious shortcoming is that it requires that every multicast domain have a separate name. This then requires that the
homenet generate names for every multicast domain, and requires that the end user have a mental model of the topology of
the network in order to guess on which link a given service may appear. [xxx is this really true at the UI?]
This document uses the following terms and abbreviations:
Homenet Router
Internet Service Provider
Global Name Registration Provider
Hosts on the homenet receive a set of resolver IP addresses using either DHCP or RA. IPv4-only hosts will receive IPv4
addresses of resolvers, if available, over DHCP. IPv6-only hosts will receive resolver IPv6 addresses using either
stateful (if available) or stateless DHCPv6, or through the domain name option in router advertisements. All homenet
routers provide resolver information using both stateless DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is
optional, however if either service is offered, resolver addresses will be provided using that mechanism as well.
Resolver IP addresses will always be IP addresses on the local link: every HNR is required to provide name resolution
service. This is necessary to allow DNS update using presence on-link as a mechanism for rejecting off-network
attacks.
DNS-SD uses several default domains for advertising local zones that are available for service discovery. These include
the '.local' domain, which is searched using mDNS, and also the IPv4 and IPv6 reverse zone corresponding to the prefixes
in use on the local network. For the homenet, no support for queries against the ".local" zone is provided by HNRs: a
".local" query will be satisfied or not by services present on the local link. This should not be an issue: all known
implementations of DNSSD will do unicast queries using the DNS protocol.
Service discovery is configured using the technique described in Section 11 of DNS-Based Service Discovery
. HNRs will answer domain enumeration ueries against every IPv4 address prefix advertised on a
homenet link, and every IPv6 address prefix advertised on a homenet link, including prefixes derived from the homenet's
ULA(s). Whenever the "<domain>" sequence appears in this section, it references each of the domains mentioned in
this paragraph.
Homenets advertise the availability of several browsing zones in the "b._dns_sd.<domain>" subdomain. By default,
the TBD1 domain is advertised. Similarly, TBD1 is advertised as the default browsing and service registration domain
under "db._dns_sd.<domain>", "r._dns_sd.<domain>", "dr._dns_sd.<domain>" and
"lb._dns_sd.<domain>".
Local names appear as subdomains of [TBD1]. These names can only be resolved within the homenet; not only is
[TBD1] not a globally unique name, but queries from outside of the homenet for any name, on or off the homenet, must
be rejected with a REFUSED response.
In addition, names can appear as subdomains of the locally-served 'in-addr.arpa' or 'ip6.addr' zone that corresponding to
the ULA that is in use on the homenet. IP addresses and names advertised locally MUST use the homenet's ULA.
It is possible that local services may number themselves using more than one of the prefixes advertised locally. Homenet
hybrid proxies MUST filter out global IP addresses, providing only ULA addresses, similar to the process described in
section 5.5.2 of . [xxx is this going to be a problem?]
The Hybrid Proxy model relies on each link having its own name. However, homenets do not actually have a way to name
local links that will make any sense to the end user. Consequently, this mechanism will not work. In order to paper
over this, some changes are required:
The Hybrid Proxy function is divided into two: relaying proxies, and aggregating proxies. There must be
exactly one querying proxy per link; there can be as few as one aggregating proxy per homenet.
Relaying proxies do no translation, for example from ".local" to "bldg1.example.com" as shown in section 5.3
of . They simply take queries over the DNS protocol for names in
subdomains of '.local', the link-specific 'ip6.addr', and the link-specific 'in-addr.arpa' zones, and
respond with the exact answers received.
There must be exactly one querying proxy per internal link on the homenet; for links that are connected to more than
one homenet router, HNCP is used to choose which router will provide the service.
Querying proxies perform translation. Machine readable names are presented as subdomains of the TBD1 domain.
Human readable names are presented as subdomains of the _hr.TBD1 domain.
Every homenet router can provide a querying proxy, or only one router can. This is determined by HNCP; all homenet
routers must provide this capability, but some homenet routers may provide enhanced querying proxy capabilities such
that homenet routers providing only those capabilities described in this document must be disabled. Therefore, all
homenet routers must be able to act as a querying proxy, or forward DNS queries to a central querying proxy, according
to what is specified through HNCP.
DNSSEC Validation for the TBD1 zone and for the locally-served 'ip6.arpa and 'in-adr.arpa' domains is not possible
without a trust anchor. Establishment of a trust anchor for such validation is out of scope for this document.
Homenets must support the Multiple Provisioning Domain Architecture . In order to support this
architecture, each homenet router that provides name resolution must provide one resolver for each provisioning domain
(PvD). Each homenet router will advertise one resolver IP address for each PvD. DNS requests to the resolver associated
with a particular PvD, e.g. using RA options will be resolved using the
external resolver(s) provisioned by the service provider responsible for that PvD.
The homenet is a separate provisioning domain from any of the service providers. The global name of the homenet can be
used as a provisioning domain identifier, if one is configured. Homenets should allow the name of the local provisioning
domain to be configured; otherwise by default it should be “Home Network xxx”, where xxx is the generated portion of the
homenet's ULA prefix, represented as a base64 string.
The resolver for the homenet PvD is offered as the primary resolver in RAs and through DHCPv4 and DHCPv6. When queries
are made to the homenet-PvD-specific resolver for names that are not local to the homenet, the resolver will use a
round-robin technique, alternating between service providers with each step in the round-robin process, and then also
between external resolvers at a particular service provider if a service provider provides more than one. The
round-robining should be done in such a way that no service provider is preferred, so if service provider A provides one
caching resolver (A), and service provider B provides two (B1, B2), the round robin order will be (A, B1, A, B2), not (A,
B1, B2).
Every resolver provided by the homenet, regardless of which provisioning domain it is intended to serve, will accept
updates for subdomains of the TBD1 and locally-served 'ip6.arpa' and 'in-addr.arpa' domains from hosts on the local
link.
This architecture does not provide a way for service discovery to be performed on the homenet by devices that are
not directly connected to a link that is part of the homenet.
This architecture is intended to be self-healing, and should not require management. That said, a great deal of debugging
and management can be done simply using the DNS service discovery protocol.
Privacy is somewhat protected in the sense that names published on the homenet are only visible to devices connected
to the homenet. This may be insufficient privacy in some cases.
The privacy of host information on the local net is left to hosts. Various mechanisms are available to hosts to ensure
that tracking does not occur if it is not desired. However, devices that need to have special permission to manage the
homenet will inevitably reveal something about themselves when doing so. It may be possible to use something like HTTP
token binding to mitigate this risk.
There are some clear issues with the security model described in this document, which will be documented in a future version
of this section. A full analysis of the avenues of attack for the security model presented here have not yet been done, and
must be done before the document is published.
This document is relying on the allocation of [TBD1] described in Special Use Top Level Domain
'.homenet' . As such, no new actions are required by IANA, but this document
can't proceed until that allocation is done. At that time, the name [TBD1] can be substituted for the name that
is eventually allocated during the processing of that document.