draft-ietf-homenet-simple-naming-00.txt   draft-ietf-homenet-simple-naming-01.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Barefoot Consulting Internet-Draft Nibbhaya Consulting
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: May 3, 2018 Ericsson Expires: September 6, 2018 Ericsson
S. Cheshire S. Cheshire
Apple Inc. Apple Inc.
October 30, 2017 March 5, 2018
Simple Homenet Naming and Service Discovery Architecture Simple Homenet Naming and Service Discovery Architecture
draft-ietf-homenet-simple-naming-00 draft-ietf-homenet-simple-naming-01
Abstract Abstract
This document describes a simple name resolution and service This document describes how names are published and resolved on
discovery architecture for homenets, using the 'home.arpa' domain homenets, and how hosts are configured to use these names to discover
name hierarchy. This architecture covers local publication of names, services on homenets. It presents the complete architecture, and
as well as name resolution service for local and global names for describes a simple subset of that architecture that can be used in
devices connected to the homenet. low-cost homenet routers.
This document does not cover discovery of homenet services by devices
not connected to the homenet, nor DNSSEC, nor acquisition and
configuration of a global name as an alternative to 'home.arpa'.
These topics will be addressed in a separate document.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 3, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
1.1. Existing solutions . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4
3. Name Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Homenet-specific considerations . . . . . . . . . . . . . 4
3.1. Configuring Resolvers . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DNS Service Discovery Registration Protocol . . . . . . . 6 4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Configuring Service Discovery . . . . . . . . . . . . . . 6 5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Resolution of local names . . . . . . . . . . . . . . . . 8 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Globally Unique Name . . . . . . . . . . . . . . . . . . 10 7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . 10 7.1. DNS Service Discovery Registration Protocol . . . . . . . 7
3.7. Support for Multiple Provisioning Domains . . . . . . . . 10 7.2. Configuring Service Discovery . . . . . . . . . . . . . . 7
3.8. Using the Local Namespace While Away From Home . . . . . 11 8. Host Configurtion . . . . . . . . . . . . . . . . . . . . . . 10
4. Management Considerations . . . . . . . . . . . . . . . . . . 11 9. Globally Unique Name . . . . . . . . . . . . . . . . . . . . 10
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Support for Multiple Provisioning Domains . . . . . . . . . . 11
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 12. Using the Local Namespace While Away From Home . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 12 13. Management Considerations . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
15. Security Considerations . . . . . . . . . . . . . . . . . . . 12
16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
17. Normative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Existing solutions . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes a simple architecture for providing name This document is a homenet architecture document. The term 'homenet'
service and service discovery for homenets. This allows hosts refers to a set of technologies that allow home network users to have
connected to the homenet to use the Domain Name System to discover a local-area network (LAN) with more than one physical link and,
services and the hosts providing those services, whether they are on optionally, more than one internet service provider. Home network
the home network or the Internet. In addition, the architecture users are assumed not to be knowledgable in network operations, so
provides a way for hosts connected to the homenet that provide homenets automatically configure themselves, providing connectivity
services to advertise those services for discovery by other homenet and service discovery within the home with no operator intervention.
hosts. This document describes the aspect of homenet automatic configuration
that has to do with service discovery and name resolution.
This simple architecture is intended to serve as a foundational The homenet naming architecture consists of two parts: the simple
architecture for naming on home networks. It is expected that all naming architecture, and the advanced naming architecture. The
Homenet routers will implement this architecture. It satisfies a advanced architecture provides approximate parity of features with a
subset of the requirements listed in IPv6 Home Networking managed network, including the ability to publish services on the
Architecture Principles [7], and provides a foundation for completely internet. The simple architecture provides a minimal set of features
addressing those requirements. required to enable seamless service discovery on a multi-link home
network, but does not attempt to provide feature parity with a
managed LAN.
This simple architecture leaves the following requirements from This document begins by presenting a motivational list of
RFC7368 Section 3.7 unaddressed: requirements and considerations, which should give the reader a clear
idea of the scope of the problem being solved. It then explains how
each requirement is addressed, and provides references for relevant
standards documents describing the details of the implementation.
Some requirements are not satisfied by the simple architecture; these
are discussed in this document, but explained in more detail in the
Advanced Homenet Naming Architecture document, which is to follow.
o Acquisition of a global name for the homenet, to be used in place 2. Requirements
of 'home.arpa.'
o Delegation of public reverse trees for prefixes delegated to the Name service on a local area network (LAN) requires the following:
homenet: subdomains of 'ip6.arpa' and 'in-addr.arpa'.
o Publication of names on the homenet for general public use on the o Name: a forward domain under which information about local
internet. services will be published
o Publication of names on the homenet for use by authorized users of o Authority: a name server that is authoritative for at least a
the homenet when connected to other networks. forward and one or two reverse domains that are applicable to that
network
o Secure delegation, enabling DNSSEC validation of names published o Resolution: a full-service caching DNS resolver
on the homenet.
A later document will describe additional functionality that can be o Publication: a mechanism that
implemented on more capable home network routers, so that a home
network that has at least one such router, and one or more routers
that only implement the architecture described in this document, can
work together to provide the full feature set described in RFC 7368.
In general, the set of capabilities required to discover services on * allows services on the LAN to publish information about the
any network are: services they provide
o A domain name that represents the network, under which names can * allows services to publish information on how to reach them
be published and services advertised
o The ability to publish names that identify hosts and services. * manages the lifetime of such information, so that it persists
long enough to prevent spoofing, but protects end users from
seeing stale information
o Advertising locally available services by publishing resource o Host configuration: one or more automatic mechanisms (e.g. DHCP
records. or RA) that provide:
o A service that can be queried for names and resources records in * caching resolver information to hosts on the LAN
order to discover and use services.
o Advertisement of that service so that hosts can send queries to * information about how services on the LAN can publish
it. information
o Timely removal of published names and resource records when they o Trust: some basis for trusting the information that is provided by
are no longer in use the service discovery system
A simple homenet naming architecture adds the following 2.1. Managed LAN versus Homenet
On a managed LAN, many of these services can be provided by
operators. When a new printer is added to the network, it can be
added to the service discovery system (the authoritative server)
manually. When a printer is taken out of service, it can be removed.
In this scenario, the role of "publisher" is filled by the network
operator.
In many managed LANs, establishment of trust for service discovery is
simply on the basis of a belief that the local resolver will give a
correct answer. Once the service has been discovered and chosen,
there may be some security (e.g., TLS) that protects the connection
to the service, but the trust model is often just "you're connected
to a network you trust, so you can trust the printer that you
discovered on this network."
A homenet does not have an operator, so functions that would normally
be performed by the operator have to happen automatically. This has
implications for trust establishment--since there is no operator
controlling what services are published locally, some other mechanism
is required for basic trust establishment. Additionally, whereas in
a managed LAN with multiple links to the Internet, the network
operator can configure the network so that multihoming is handled
seamlessly, in a homenet, multihoming must be handled using multiple
provisioning domains [RFC7556].
2.2. Homenet-specific considerations
A naming architecture for homenets therefore adds the following
considerations: considerations:
1. Users cannot be assumed to be skilled or knowledgeable in name o All of the operations mentioned here must reliably function
service operation, or even to have any sort of mental model of automatically, without any user intervention or debugging.
how these functions work. All of the operations mentioned here
must reliably function automatically, without any user
intervention or debugging.
2. Because user intervention cannot be required, naming conflicts o Because user intervention cannot be required, naming conflicts
must be resolved automatically, and, to the extent possible, must be resolved automatically, and, to the extent possible,
transparently. transparently.
3. Hosts are not required to implement any homenet-specific o Devices that provide services must be able to publish those
capabilities in order to discover and access services on the services on the homenet, and those services must be available from
homenet. any part of the homenet, not just the link to which the device is
attached.
4. Devices that provide services must be able to publish those o Homenets must address the problem of multiple provisioning
services on the homenet, and those services must be available domains, in the sense that the DNS may give a different answer
from any part of the homenet, not just the link to which the depending on whether caching resolvers at one ISP or another are
device is attached. queried.
5. Homenet explicitly supports multihoming: connecting to more than An additional requirement from the Homenet Architecture [9] is that
one Internet Service Provider. It therefore must address the hosts are not required to implement any homenet-specific capabilities
problem of multiple provisioning domains [8], in the sense that in order to discover and access services on the homenet. This
the DNS may give a different answer depending on whether caching architecture may define optional homenet-specific features, but hosts
resolvers at one ISP or another are queried. that do not implement these features must work on homenets.
1.1. Existing solutions 3. Terminology
Previous attempts to automate naming and service discovery in the This document uses the following terms and abbreviations:
context of a home network are able to function with varying degrees
of success depending on the topology of the home network.
Unfortunately, these solutions do not fully address the requirements
of homenets.
For example, Multicast DNS [5] can provide naming and service HNR Homenet Router
discovery [6], but only within a single multicast domain.
The Domain Name System provides a hierarchical namespace [1], a SHNR Homenet Router implementing simple homenet naming architecture
mechanism for querying name servers to resolve names [2], a mechanism
for updating namespaces by adding and removing names [4], and a
mechanism for discovering services [6]. Unfortunately, DNS provides
no mechanism for automatically provisioning new namespaces, and
secure updates to namespaces require that the host submitting the
update have a public or symmetric key that is known to the network
and authorized for updates. In an unmanaged network, the publication
of and authorization of these keys is an unsolved problem.
Some managed networks get around this problem by having the DHCP AHNR Homenet Router implementing advanced homenet naming
server do DNS updates. However, this doesn't really work, because architecture
DHCP doesn't provide a mechanism for updating service discovery
records: it only supports publishing A and AAAA records.
This partially solves the trust problem: DHCP can validate that a ISP Internet Service Provider
device is at least connected to a network link that is actually part
of the managed network. This prevents an off-network attacker from
registering a name, but provides no mechanism for actually validating
the identity of the host registering the name. For example, it would
be easy for an attacker on the network to steal a registered name.
Hybrid Multicast DNS [10] proposes a mechanism for extending 4. Name
multicast DNS beyond a single multicast domain. However, in order to
use this as a solution, some shortcomings need to be considered.
Most obviously, it requires that every multicast domain have a
separate name. This then requires that the homenet generate names
for every multicast domain. These names would then be revealed to
the end user. But since they would be generated automatically and
arbitrarily, they would likely cause confusion rather than clarity,
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.
At present, the approach we intend to take with respect to In order for names to be published on a homenet, it is necessary that
disambiguation is that this will not be solved at a protocol level there be a set of domain names under which such names are published.
for devices that do not implement the registration protocol. These domain names, together, are referred to as the "local domains."
By default, homenets use the reserved domain 'home.arpa.' for
publishing names for forward lookups. So a host called 'example'
that published its name on the homenet would publish its records on
the domain name 'example.home.arpa.'. Because 'home.arpa.' is used
by all homenets, it has no global meaning, and names published under
the domain 'home.arpa' cannot be used outside of the homenet on which
they are published.
2. Terminology Homenet routers that implement advanced homenet naming may also be
configured with a global domain. How such a domain is configured is
out of scope for this document, and is described in the Advanced
Homenet Naming Architecture document [advanced].
This document uses the following terms and abbreviations: In addition to the name, which defaults to 'home.arpa.', names are
needed for reverse lookups. These names are dependent on the IP
addressing used on the homenet. If the homenet is addressed with
IPv4, a reverse domain corresponding to the IPv4 subnet [1] section
5.2.1 should be constructed. For example, if the homenet is
allocating local IP addresses out of net 10 [3], a domain, '10.in-
addr.arpa' would be required. Like 'home.arpa.', '10.in-addr.arpa'
is a locally-served zone, and has no validity outside of the homenet.
HNR Homenet Router If the homenet is addressed with IPv6, it is expected to have a
unique local address prefix; subsets of this prefix will be
advertised on every link on the homenet. Every service on the
homenet that supports IPv6 is expected to be reachable at an address
that is configured using the ULA prefix. Therefore there is no need
for any IPv6 reverse zone to be populated other than the ULA zone.
So for example if the homenet's ULA prefix is fd00:2001:db8::/48,
then the reverse domain name for the homenet would end in
'8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'.
ISP Internet Service Provider 5. Authority
3. Name Resolution The authority role is provided by a name server that is authoritative
for each of the local domains. SHNRs provide authoritative service
for the homenet using DNSSD Discovery Broker [17]. SHNRs also
provide Discovery Relay service [12]. On a homenet that has only
SHNRs, each SHNR individually provides authoritative service for the
whole homenet by using Discovery relays to discover services off the
local link.
3.1. Configuring Resolvers The Discovery 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 [17]. 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.
Hosts on the homenet receive a set of resolver IP addresses using Artificial link names will be generated using HNCP. These should
either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of only be visible to the user in graphical user interfaces in the event
resolvers, if available, over DHCP. IPv6-only hosts will receive that the same name is claimed by a service on two links. Services
resolver IPv6 addresses using either stateful (if available) or that are expected to be accessed by users who type in names should
stateless DHCPv6, or through the Recursive DNS Server Option ([9], use [13] if it is available.
Section 5.1) in router advertisements.
All Homenet routers provide resolver information using both stateless It is possible that local services may offer services available on IP
DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional, addresses in public as well as ULA prefixes. Homenet hybrid proxies
however if either service is offered, resolver addresses will be MUST filter out global IP addresses, providing only ULA addresses,
provided using that mechanism as well. similar to the process described in section 5.5.2 of [11].
3.2. DNS Service Discovery Registration Protocol This filtering applies to queries within the homenet; it is
appropriate for non-ULA addresses to be used for offering services,
because in some cases end users may want such services to be
reachable outside of the homenet. Configuring this is however out of
scope for this document.
The DNSSD Service Registration protocol [12] requires that DNS 6. Resolution
Name resolution is provided by a local DNS cache or proxy on the
homenet, henceforth the "local resolver." All host queries are sent
to this local resolver. The local resolver may either act as a full-
service caching resolver, or as a DNS proxy. Its responsibility with
respect to queries on the homenet is to notice queries for names for
which the local authoritative server is authoritative. Queries for
such names are handled through the local authoritative server.
Queries for all other names are resolved either by forwarding them to
an ISP-provided full service resolver, or by providing the full
service resolver function locally.
7. Publication
7.1. DNS Service Discovery Registration Protocol
The DNSSD Service Registration protocol [13] requires that DNS
updates be validated on the basis that they are received on the local updates be validated on the basis that they are received on the local
link. To ensure that such registrations are actually received on link. To ensure that such registrations are actually received on
local links in the homenet, updates are sent to the local relay proxy local links in the homenet, updates are sent to the local relay proxy
([11]) (XXX how?). ([12]) (XXX how?).
The relay proxy encapsulates the update and sends it to whatever The relay proxy encapsulates the update and sends it to whatever
Discovery Proxy is listening on the link; the Discovery proxy then Discovery Proxy is listening on the link; the Discovery proxy then
either consumes the update directly, or forwards it to the either consumes the update directly, or forwards it to the
authoritative resolver for the local service discovery zone. If the authoritative resolver for the local service discovery zone. If the
registration protocol is not supported on the homenet, the Discovery registration protocol is not supported on the homenet, the Discovery
Proxy rejects the update with a ??? RCODE. Proxy rejects the update with a ??? RCODE.
3.3. Configuring Service Discovery Homenets are not required to support Service Registration. Service
registration requires a stateful authoritative 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 [12]. 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.
Clients discovering services using DNS-SD [6] follow a two-step 7.2. Configuring Service Discovery
Clients discovering services using DNS-SD [7] follow a two-step
process. The first step is for the client device to determine in process. The first step is for the client device to determine in
which domain(s) to attempt to discover services. The second step is which domain(s) to attempt to discover services. The second step is
for the client device to then seek desired service(s) in those for the client device to then seek desired service(s) in those
domain(s). For an example of the second step, given the desired domain(s). For an example of the second step, given the desired
service type "IPP Printing", and the domains "local" and service type "IPP Printing", and the domains "local" and
"meeting.ietf.org", the client device forms the queries "meeting.ietf.org", the client device forms the queries
"_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and "_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and
"_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and
then presents the combined list of results to the user. then presents the combined list of results to the user.
The first step, determining in which domain(s) to attempt to discover The first step, determining in which domain(s) to attempt to discover
services, is performed in a variety of ways, as described in services, is performed in a variety of ways, as described in
Section 11 of the DNS-Based Service Discovery specification [6]. Section 11 of the DNS-Based Service Discovery specification [7].
The domain "local" is generally always in the set of domains in which The domain "local" is generally always in the set of domains in which
the client devices attempt to discover services, and other domains the client devices attempt to discover services, and other domains
for service discovery may be configured manually by the user. for service discovery may be configured manually by the user.
The device also learns additional domains automatically from its The device also learns additional domains automatically from its
network environment. For this automatic configuration discovery, network environment. For this automatic configuration discovery,
special DNS queries are formulated. To learn additional domain(s) in special DNS queries are formulated. To learn additional domain(s) in
which to attempt to discover services, the query string which to attempt to discover services, the query string
"lb._dns_sd._udp" is prepended onto three different kinds of "lb._dns_sd._udp" is prepended onto three different kinds of
"bootstrap domain" to form DNS queries that allow the device to learn "bootstrap domain" to form DNS queries that allow the device to learn
the configuration information. the configuration information.
One of these bootstrap domains is the fixed string "local". The One of these bootstrap domains is the fixed string "local". The
device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved
using Multicast DNS), and if any answers are received, then they are using Multicast DNS), and if any answers are received, then they are
added to the set of domains in which the client devices attempt to added to the set of domains in which the client devices attempt to
discover services. discover services.
Another kind of these bootstrap domains is name-based, derived from Another kind of these bootstrap domains is name-based, derived from
the DHCPv4 "domain name" option (code 15) [3] (for IPv4) or the DNS the DHCPv4 "domain name" option (code 15) [4] (for IPv4) or the DNS
Search List (DNSSL) Router Advertisement option [9] (for IPv6). If a Search List (DNSSL) Router Advertisement option [10] (for IPv6). If
domain in the DNSSL is "example.com", then the device issues the a domain in the DNSSL is "example.com", then the device issues the
query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast
DNS), and if any answers are received, then they are likewise added DNS), and if any answers are received, then they are likewise added
to the set of domains in which the client devices attempt to discover to the set of domains in which the client devices attempt to discover
services. services.
Finally, the third kind of bootstrap domain is address-based, derived Finally, the third kind of bootstrap domain is address-based, derived
from the device's IP address(es) themselves. If the device has IP from the device's IP address(es) themselves. If the device has IP
address 192.168.1.100/24, then the device issues the query address 192.168.1.100/24, then the device issues the query
"lb._dns_sd._udp.0.1.168.192.in-addr.arpa. PTR ?" (resolved using "lb._dns_sd._udp.0.1.168.192.in-addr.arpa. PTR ?" (resolved using
Unicast DNS), and if any answers are received, then they are also Unicast DNS), and if any answers are received, then they are also
skipping to change at page 8, line 39 skipping to change at page 10, line 14
above the zone cut for the ip6.arpa reverse zone for the assigned above the zone cut for the ip6.arpa reverse zone for the assigned
prefix will fail to validate. prefix will fail to validate.
Ideally, an ISP should provide a secure delegation using a zone- Ideally, an ISP should provide a secure delegation using a zone-
signing key provided by the homenet. However, that too is out of signing key provided by the homenet. However, that too is out of
scope for this document. Therefore, an ISP that wishes to support scope for this document. Therefore, an ISP that wishes to support
users of the simple homenet naming architecture will have to provide users of the simple homenet naming architecture will have to provide
an unsigned delegation. We do not wish, however, to discourage an unsigned delegation. We do not wish, however, to discourage
provisioning of signed delegations when that is possible. provisioning of signed delegations when that is possible.
3.4. Resolution of local names 8. Host Configurtion
By default, 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. The intended use case for local names is
that hosts will attempt to discover or contact other hosts on the
homenet that are offering services.
In addition, names of devices on the homenet can appear in the
resource records of names that are subdomains of the locally-served
'in-addr.arpa' or 'ip6.arpa zone that corresponding to the RFC1918
IPv4 prefix and the IPv6 ULA that is in use on the homenet. Names
ending in 'home.arpa' should never appear in RRDATA for names that
are subdomains of reverse mappings for global IP addresses. This
should not cause operational problems, since connections between
devices on the homenet can be expected to use addresses in the
homenet's ULA prefix.
ISP-provided addresses cannot be assumed to be stable. Not only is
it possible that the ISP policy is to change addresses over time, but
the connection to the ISP may not always be available. The homenet's
ULA prefix and RFC1918 prefix, however, can be assumed to be stable.
Therefore, 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 offer services available on IP
addresses in public as well as ULA prefixes. Homenet hybrid proxies
MUST filter out global IP addresses, providing only ULA addresses,
similar to the process described in section 5.5.2 of [10].
This filtering applies to queries within the homenet; it is
appropriate for non-ULA addresses to be used for offering services,
because in some cases end users may want such services to be
reachable outside of the homenet. Configuring this is however out of
scope for this document.
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 [16]. 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 Hosts on the homenet receive a set of resolver IP addresses using
only be visible to the user in graphical user interfaces in the event either DHCP or RA. IPv4-only hosts will receive IPv4 addresses of
that the same name is claimed by a service on two links. Services resolvers, if available, over DHCP. IPv6-only hosts will receive
that are expected to be accessed by users who type in names should resolver IPv6 addresses using either stateful (if available) or
use [12] if it is available. stateless DHCPv6, or through the Recursive DNS Server Option ([10],
Section 5.1) in router advertisements.
Homenets are not required to support Service Registration. Service All Homenet routers provide resolver information using both stateless
registration requires a stateful authoritative DNS server; this may DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional,
be beyond the capability of the minimal Homenet router. However, however if either service is offered, resolver addresses will be
more capable Homenet routers should provide this capability. In provided using that mechanism as well.
order to make this work, minimal Homenet routers MUST implement the
split hybrid proxy [11]. 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.5. Globally Unique Name 9. Globally Unique Name
Automatic configuration of a globally unique name for the homenet is Automatic configuration of a globally unique name for the homenet is
out of scope for this document. However, homenet servers MUST allow out of scope for this document. However, homenet servers MUST allow
the user to configure a globally unique name in place of the default the user to configure a globally unique name in place of the default
name, 'home.arpa.' By default, even if configured with a global name, 'home.arpa.' By default, even if configured with a global
name, homenet routers MUST NOT answer queries from outside of the name, homenet routers MUST NOT answer queries from outside of the
homenet for subdomains of that name. homenet for subdomains of that name.
3.6. DNSSEC Validation 10. DNSSEC Validation
DNSSEC Validation for the 'home.arpa' zone and for the locally-served 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 'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust
anchor. Establishment of a trust anchor for such validation is out anchor. Establishment of a trust anchor for such validation is out
of scope for this document. of scope for this document.
Homenets that have been configured with a globally unique domain MUST Homenets that have been configured with a globally unique domain MUST
support DNSSEC signing of local names, and must provide a way to support DNSSEC signing of local names, and must provide a way to
generate a KSK that can be used in the secure delegation of the generate a KSK that can be used in the secure delegation of the
globally unique domain assigned to the homenet. globally unique domain assigned to the homenet.
3.7. Support for Multiple Provisioning Domains 11. Support for Multiple Provisioning Domains
Homenets must support the Multiple Provisioning Domain Architecture Homenets must support the Multiple Provisioning Domain Architecture
[8]. Hosts connected to the homenet may or may not support multiple [9]. Hosts connected to the homenet may or may not support multiple
provisioning domains. For hosts that do not support multiple provisioning domains. For hosts that do not support multiple
provisioning domains, the homenet provides one or more resolvers that provisioning domains, the homenet provides one or more resolvers that
will answer queries for any provisioning domain. Such hosts may will answer queries for any provisioning domain. Such hosts may
receive answers to queries that either do not work as well if the receive answers to queries that either do not work as well if the
host chooses a source address from a different provisioning domain, host chooses a source address from a different provisioning domain,
or does not work at all. However, the default source address or does not work at all. However, the default source address
selection policy, longest-match [CITE], will result in the correct selection policy, longest-match [CITE], will result in the correct
source address being chosen as long as the destination address has a source address being chosen as long as the destination address has a
close match to the prefix assigned by the ISP. close match to the prefix assigned by the ISP.
skipping to change at page 11, line 13 skipping to change at page 11, line 36
provisioning domain. provisioning domain.
Configuration from the IPv4 DHCP server are treated as being part of Configuration from the IPv4 DHCP server are treated as being part of
the homenet provisioning domain. The case where a homenet advertises the homenet provisioning domain. The case where a homenet advertises
IPv4 addresses from one or more public prefixes is out of scope for IPv4 addresses from one or more public prefixes is out of scope for
this document. Such a configuration is NOT RECOMMENDED for homenets. this document. Such a configuration is NOT RECOMMENDED for homenets.
Configuration for IPv6 provisioning domains is done using the Configuration for IPv6 provisioning domains is done using the
Multiple Provisioning Domain RA option [CITE]. Multiple Provisioning Domain RA option [CITE].
3.8. Using the Local Namespace While Away From Home 12. Using the Local Namespace While Away From Home
This architecture does not provide a way for service discovery to be This architecture does not provide a way for service discovery to be
performed on the homenet by devices that are not directly connected performed on the homenet by devices that are not directly connected
to a link that is part of the homenet. to a link that is part of the homenet.
4. Management Considerations 13. Management Considerations
This architecture is intended to be self-healing, and should not This architecture is intended to be self-healing, and should not
require management. That said, a great deal of debugging and require management. That said, a great deal of debugging and
management can be done simply using the DNS Service Discovery management can be done simply using the DNS Service Discovery
protocol. protocol.
5. Privacy Considerations 14. Privacy Considerations
Privacy is somewhat protected in the sense that names published on Privacy is somewhat protected in the sense that names published on
the homenet are only visible to devices connected to the homenet. the homenet are only visible to devices connected to the homenet.
This may be insufficient privacy in some cases. This may be insufficient privacy in some cases.
The privacy of host information on the homenet is left to hosts. The privacy of host information on the homenet is left to hosts.
Various mechanisms are available to hosts to ensure that tracking Various mechanisms are available to hosts to ensure that tracking
does not occur if it is not desired. However, devices that need to does not occur if it is not desired. However, devices that need to
have special permission to manage the homenet will inevitably reveal have special permission to manage the homenet will inevitably reveal
something about themselves when doing so. It may be possible to use something about themselves when doing so. It may be possible to use
something like HTTP token binding [14] to mitigate this risk. something like HTTP token binding [15] to mitigate this risk.
6. Security Considerations 15. Security Considerations
There are some clear issues with the security model described in this There are some clear issues with the security model described in this
document, which will be documented in a future version of this document, which will be documented in a future version of this
section. A full analysis of the avenues of attack for the security 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 model presented here have not yet been done, and must be done before
the document is published. the document is published.
7. IANA considerations 16. IANA considerations
No new actions are required by IANA for this document. No new actions are required by IANA for this document.
Note however that this document is relying on the allocation of Note however that this document is relying on the allocation of
'home.arpa' described in Special Use Top Level Domain '.home.arpa' 'home.arpa' described in Special Use Top Level Domain '.home.arpa'
[16]. This document therefore can't proceed until that allocation is
[15]. This document therefore can't proceed until that allocation is
done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO
PUBLICATION]. PUBLICATION].
8. Normative References 17. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", [1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[4] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, [5] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997, RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>. <https://www.rfc-editor.org/info/rfc2136>.
[5] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [6] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>. <https://www.rfc-editor.org/info/rfc6762>.
[6] Cheshire, S. and M. Krochmal, "DNS-Based Service [7] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[7] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. [8] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles", Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014, RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>. <https://www.rfc-editor.org/info/rfc7368>.
[8] Anipko, D., Ed., "Multiple Provisioning Domain [9] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<https://www.rfc-editor.org/info/rfc7556>. <https://www.rfc-editor.org/info/rfc7556>.
[9] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [10] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[10] Cheshire, S., "Discovery Proxy for Multicast DNS-Based [11] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-07 (work in Service Discovery", draft-ietf-dnssd-hybrid-07 (work in
progress), September 2017. progress), September 2017.
[11] Cheshire, S. and T. Lemon, "Multicast DNS Discovery [12] Cheshire, S. and T. Lemon, "Multicast DNS Discovery
Relay", draft-sctl-dnssd-mdns-relay-01 (work in progress), Relay", draft-sctl-dnssd-mdns-relay-02 (work in progress),
October 2017. November 2017.
[12] Cheshire, S. and T. Lemon, "Service Registration Protocol [13] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017. registration-00 (work in progress), July 2017.
[13] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support [14] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
for multiple provisioning domains in IPv6 Neighbor for multiple provisioning domains in IPv6 Neighbor
Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-03
(work in progress), February 2016. (work in progress), February 2016.
[14] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, [15] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
N., and J. Hodges, "Token Binding over HTTP", draft-ietf- N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
tokbind-https-10 (work in progress), July 2017. tokbind-https-12 (work in progress), January 2018.
[15] Pfister, P. and T. Lemon, "Special Use Domain [16] Pfister, P. and T. Lemon, "Special Use Domain
'home.arpa.'", draft-ietf-homenet-dot-14 (work in 'home.arpa.'", draft-ietf-homenet-dot-14 (work in
progress), September 2017. progress), September 2017.
[16] Cheshire, S. and T. Lemon, "Service Discovery Broker", [17] Cheshire, S. and T. Lemon, "Service Discovery Broker",
draft-sctl-discovery-broker-00 (work in progress), July draft-sctl-discovery-broker-00 (work in progress), July
2017. 2017.
Appendix A. 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.
Unfortunately, these solutions do not fully address the requirements
of homenets.
For example, Multicast DNS [6] can provide naming and service
discovery [7], 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
for updating namespaces by adding and removing names [5], and a
mechanism for discovering services [7]. Unfortunately, DNS provides
no mechanism for automatically provisioning new namespaces, and
secure updates to namespaces require that the host submitting the
update have a public or symmetric key that is known to the network
and authorized for updates. In an unmanaged network, the publication
of and authorization of these keys is an unsolved problem.
Some managed networks get around this problem by having the DHCP
server do DNS updates. However, this doesn't really work, because
DHCP doesn't provide a mechanism for updating service discovery
records: it only supports publishing A and AAAA records.
This partially solves the trust problem: DHCP can validate that a
device is at least connected to a network link that is actually part
of the managed network. This prevents an off-network attacker from
registering a name, but provides no mechanism for actually validating
the identity of the host registering the name. For example, it would
be easy for an attacker on the network to steal a registered name.
Hybrid Multicast DNS [11] proposes a mechanism for extending
multicast DNS beyond a single multicast domain. However, in order to
use this as a solution, some shortcomings need to be considered.
Most obviously, it requires that every multicast domain have a
separate name. This then requires that the homenet generate names
for every multicast domain. These names would then be revealed to
the end user. But since they would be generated automatically and
arbitrarily, they would likely cause confusion rather than clarity,
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.
At present, the approach we intend to take with respect to
disambiguation is that this will not be solved at a protocol level
for devices that do not implement the registration protocol.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Barefoot Consulting Nibbhaya Consulting
P.O. Box 958
Brattleboro, Vermont 05301 Brattleboro, Vermont 05301
United States of America United States of America
Email: mellon@fugue.com Email: mellon@fugue.com
Daniel Migault Daniel Migault
Ericsson Ericsson
8400 boulevard Decarie 8400 boulevard Decarie
Montreal, QC H4P 2N2 Montreal, QC H4P 2N2
Canada Canada
 End of changes. 85 change blocks. 
256 lines changed or deleted 330 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/