Internet DRAFT - draft-tldm-simple-homenet-naming
draft-tldm-simple-homenet-naming
Network Working Group T. Lemon
Internet-Draft Nominum, Inc.
Intended status: Informational D. Migault
Expires: January 4, 2018 Ericsson
July 3, 2017
Simple Homenet Naming and Service Discovery Architecture
draft-tldm-simple-homenet-naming-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Lemon & Migault Expires January 4, 2018 [Page 1]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 4
3.2. Configuring Service Discovery . . . . . . . . . . . . . . 5
3.3. Resolution of local names . . . . . . . . . . . . . . . . 5
3.4. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 6
3.5. Support for Multiple Provisioning Domains . . . . . . . . 6
3.6. Using the Local Namespace While Away From Home . . . . . 7
4. Management Considerations . . . . . . . . . . . . . . . . . . 7
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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:
o Provisioning of a domain name under which names can be published
and services advertised
o Associating names that are subdomains of that name with hosts.
o Advertising services available on the local network by publishing
resource records on those names.
o Distribution of names published in that namespace to servers that
can be queried in order to resolve names
o Correct advertisement of name servers that can be queried in order
to resolve names
Lemon & Migault Expires January 4, 2018 [Page 2]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
o Timely removal of published names and resource records when they
are no longer in use
Homenet adds the following considerations:
1. 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.
2. 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.
3. Because user intervention cannot be required, naming conflicts
must be resolved automatically, and, to the extent possible,
transparently.
4. 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.
5. 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.
6. Homenet explicitly supports multihoming--connecting to more than
one Internet Service Provider--and therefore support for multiple
provisioning domains [6] 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.
1.1. Existing solutions
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 [4] can provide naming and service discovery
[5], but only within a single multicast domain.
The Domain Name System provides a hierarchical namespace [1], a
mechanism for querying name servers to resolve names [2], a mechanism
Lemon & Migault Expires January 4, 2018 [Page 3]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
for updating namespaces by adding and removing names [3], and a
mechanism for discovering services [5]. 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 [7] 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 in degenerate cases 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.
2. Terminology
This document uses the following terms and abbreviations:
HNR Homenet Router
ISP Internet Service Provider
GNRP Global Name Registration Provider
3. Name Resolution
3.1. Configuring Resolvers
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.
Lemon & Migault Expires January 4, 2018 [Page 4]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
3.2. Configuring Service Discovery
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 [5]. HNRs will answer
domain enumeration queries 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 'home.arpa' domain
is advertised. Similarly, 'home.arpa' 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>".
3.3. Resolution of local names
Local names appear as subdomains of ['home.arpa']. These names can
only be resolved within the homenet; not only is ['home.arpa'] 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 RFC1918
IPv4 prefix and the IPv6 ULA that is in use on the homenet. IP
addresses and names advertised locally MUST use addresses in the
homenet's ULA prefix and/or RFC1918 prefix.
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 [7]. [xxx is
this going to be a problem?]
Lemon & Migault Expires January 4, 2018 [Page 5]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
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 without some tweaks. In order to address this,
homenets will use Discovery Brokers [11]. The discovery broker will
be configured so that a single query for a particular service will be
successful in providing the information required to access that
service, regardless of the link it is on.
Artificial link names will be generated using HNCP. These should
only be visible to the user in graphical user interfaces in the event
that the same name is claimed by a service on two links. Services
that are expected to be accessed by users who type in names should
use [12] if it is available.
Homenets are not required to support Service Registration. Service
registration requires a stateful DNS server; this may be beyond the
capability of the minimal homenet router. However, more capable
homenet routers should provide this capability. In order to make
this work, minimal homenet routers MUST implement the split hybrid
proxy described in [13]. This enables a homenet with one or more
homenet routers that provide a stateful registration cache to allow
those routers to take over service, using Discovery Relays to service
links that are connected using homenet routers with more limited
functionality.
3.4. DNSSEC Validation
DNSSEC Validation for the 'home.arpa' 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.
3.5. Support for Multiple Provisioning Domains
Homenets must support the Multiple Provisioning Domain Architecture
[6]. 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 [8] 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
Lemon & Migault Expires January 4, 2018 [Page 6]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
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 'home.arpa' and locally-served 'ip6.arpa' and 'in-
addr.arpa' domains from hosts on the local link.
3.6. Using the Local Namespace While Away From Home
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.
4. Management Considerations
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.
5. Privacy Considerations
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 [9] to mitigate this risk.
Lemon & Migault Expires January 4, 2018 [Page 7]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
6. Security Considerations
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.
7. IANA considerations
This document is relying on the allocation of 'home.arpa' described
in Special Use Top Level Domain '.home.arpa' [10]. As such, no new
actions are required by IANA, but this document can't proceed until
that allocation is done.
8. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[3] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<http://www.rfc-editor.org/info/rfc2136>.
[4] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[5] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[6] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<http://www.rfc-editor.org/info/rfc7556>.
[7] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-06 (work in
progress), March 2017.
Lemon & Migault Expires January 4, 2018 [Page 8]
Internet-Draft Simple Homenet Naming/SD Arch July 2017
[8] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
for multiple provisioning domains in IPv6 Neighbor
Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03
(work in progress), February 2016.
[9] Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "Token Binding over HTTP", draft-ietf-tokbind-
https-09 (work in progress), April 2017.
[10] Pfister, P. and T. Lemon, "Special Use Domain
'.home.arpa'", draft-ietf-homenet-dot-07 (work in
progress), June 2017.
[11] Cheshire, S. and T. Lemon, "Service Discovery Broker",
draft-sctl-discovery-broker-00 (work in progress), July
2017.
[12] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017.
[13] Cheshire, S. and T. Lemon, "Multicast DNS Discovery
Relay", draft-sctl-mdns-relay-00 (work in progress), July
2017.
Authors' Addresses
Ted Lemon
Nominum, Inc.
800 Bridge Parkway
Redwood City, California 94065
United States of America
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Email: daniel.migault@ericsson.com
Lemon & Migault Expires January 4, 2018 [Page 9]
