draft-ietf-homenet-simple-naming-02.txt   draft-ietf-homenet-simple-naming-03.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nibbhaya Consulting Internet-Draft Nibbhaya Consulting
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: January 3, 2019 Ericsson Expires: April 26, 2019 Ericsson
S. Cheshire S. Cheshire
Apple Inc. Apple Inc.
July 2, 2018 October 23, 2018
Simple Homenet Naming and Service Discovery Architecture Homenet Naming and Service Discovery Architecture
draft-ietf-homenet-simple-naming-02 draft-ietf-homenet-simple-naming-03
Abstract Abstract
This document describes how names are published and resolved on This document describes how names are published and resolved on
homenets, and how hosts are configured to use these names to discover homenets, and how hosts are configured to use these names to discover
services on homenets. It presents the complete architecture, and services on homenets. It presents the complete architecture, and
describes a simple subset of that architecture that can be used in describes a simple subset of that architecture that can be used in
low-cost homenet routers. low-cost homenet routers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 3, 2019. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4 2.1. Managed LAN versus Homenet . . . . . . . . . . . . . . . 4
2.2. Homenet-specific considerations . . . . . . . . . . . . . 4 2.1.1. Multiple Provisioning Domains . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Homenet-specific considerations . . . . . . . . . . . . . 5
4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Reachability . . . . . . . . . . . . . . . . . . . . . . 8
7.1. DNS Service Discovery Registration Protocol . . . . . . . 7 5.2. Link Names . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Configuring Service Discovery . . . . . . . . . . . . . . 8 5.3. Authoritative name service for the homenet domain . . . . 9
8. Host Configurtion . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Authoritative name service for per-link subdomains of the
9. Globally Unique Name . . . . . . . . . . . . . . . . . . . . 10 homenet domain . . . . . . . . . . . . . . . . . . . . . 10
10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 10 5.5. Authoritative name service for the ULA reverse mapping
11. Support for Multiple Provisioning Domains . . . . . . . . . . 11 domain . . . . . . . . . . . . . . . . . . . . . . . . . 10
12. Using the Local Namespace While Away From Home . . . . . . . 11 5.6. Authoritative name service for the RFC1918 reverse
13. Management Considerations . . . . . . . . . . . . . . . . . . 11 mapping domains . . . . . . . . . . . . . . . . . . . . . 10
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 6. Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 11
15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.1. Round Robining . . . . . . . . . . . . . . . . . . . . . 13
16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2. Retransmission . . . . . . . . . . . . . . . . . . . . . 13
17. Normative References . . . . . . . . . . . . . . . . . . . . 12 6.3. DNS Stateful Operations and DNS Push . . . . . . . . . . 13
Appendix A. Existing solutions . . . . . . . . . . . . . . . . . 14 6.4. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 6.5. Host behavior . . . . . . . . . . . . . . . . . . . . . . 14
7. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. DNSSD Service Registration Protocol . . . . . . . . . . . 14
7.2. Homenet Reverse Mapping Update Protocol . . . . . . . . . 15
7.2.1. Adding ULA reverse mappings . . . . . . . . . . . . . 15
7.2.2. Adding RFC1918 reverse mappings . . . . . . . . . . . 16
8. Host Configuration . . . . . . . . . . . . . . . . . . . . . 16
9. Globally Unique Names . . . . . . . . . . . . . . . . . . . . 16
10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . . 17
10.1. How trust is established . . . . . . . . . . . . . . . . 17
11. Homenet Delegation Registration Protocol . . . . . . . . . . 18
12. Using the Local Namespace While Away From Home . . . . . . . 19
13. Expected Host Behavior . . . . . . . . . . . . . . . . . . . 19
14. Management Considerations . . . . . . . . . . . . . . . . . . 19
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
17.1. Homenet Reverse Registration Protocol . . . . . . . . . 20
17.2. Homenet Delegation Registration Protocol . . . . . . . . 20
17.3. Unique Local Address Reserved Documentation Prefix . . . 21
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
18.1. Normative References . . . . . . . . . . . . . . . . . . 21
18.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
This document is a homenet architecture document. The term 'homenet' This document is a homenet architecture document. The term 'homenet'
refers to a set of technologies that allow home network users to have refers to a set of technologies that allow home network users to have
a local-area network (LAN) with more than one physical link and, a local-area network (LAN) with more than one physical link and,
optionally, more than one internet service provider. Home network optionally, more than one internet service provider. Home network
users are assumed not to be knowledgable in network operations, so users are assumed not to be knowledgeable in network operations, so
homenets automatically configure themselves, providing connectivity homenets automatically configure themselves, providing connectivity
and service discovery within the home with no operator intervention. and service discovery within the home with no operator intervention.
This document describes the aspect of homenet automatic configuration This document describes the aspect of homenet automatic configuration
that has to do with service discovery and name resolution. that has to do with service discovery and name resolution.
The homenet naming architecture consists of two parts: the simple This architecture provides a minimal set of features required to
naming architecture, and the advanced naming architecture. The enable seamless service discovery on a multi-link home network, but
advanced architecture provides approximate parity of features with a does not attempt to provide feature parity with a managed LAN.
managed network, including the ability to publish services on the
internet. The simple architecture provides a minimal set of features
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 document begins by presenting a motivational list of This document begins by presenting a motivational list of
requirements and considerations, which should give the reader a clear requirements and considerations, which should give the reader a clear
idea of the scope of the problem being solved. It then explains how idea of the scope of the problem being solved. It then explains how
each requirement is addressed, and provides references for relevant each requirement is addressed, and provides references for relevant
standards documents describing the details of the implementation. standards documents describing the details of the implementation.
Some requirements are not satisfied by the simple architecture; these Not all requirements are addressed by this architecture document, but
are discussed in this document, but explained in more detail in the the basic requirements are satisfied, and this document serves as a
Advanced Homenet Naming Architecture document, which is to follow. foundation upon which solutions to the remaining problems can be
built.
2. Requirements 2. Requirements
Name service on a local area network (LAN) requires the following: Name service on a local area network (LAN) requires the following:
o Name: a forward domain under which information about local o Name: a forward domain under which information about local
services will be published services will be published
o Authority: a name server that is authoritative for at least one o Authority: a name server that is authoritative for at least one
forward domain and one or two reverse domains that are applicable forward domain and one or two reverse domains that are applicable
skipping to change at page 4, line 33 skipping to change at page 5, line 5
correct answer. Once the service has been discovered and chosen, correct answer. Once the service has been discovered and chosen,
there may be some security (e.g., TLS) that protects the connection 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 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 to a network you trust, so you can trust the printer that you
discovered on this network." discovered on this network."
A homenet does not have an operator, so functions that would normally A homenet does not have an operator, so functions that would normally
be performed by the operator have to happen automatically. This has be performed by the operator have to happen automatically. This has
implications for trust establishment--since there is no operator implications for trust establishment--since there is no operator
controlling what services are published locally, some other mechanism controlling what services are published locally, some other mechanism
is required for basic trust establishment. Additionally, whereas in is required for basic trust establishment.
a managed LAN with multiple links to the Internet, the network
operator can configure the network so that multihoming is handled 2.1.1. Multiple Provisioning Domains
seamlessly, in a homenet, multihoming must be handled using multiple
provisioning domains [RFC7556]. 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].
When a host on a homenet connects to a host outside the homenet, and
the homenet is multihomed, the source address that the host uses for
connecting determines which upstream ISP connection is used. In
principle, this is not a problem, because the Internet is a fully
connected network, so any host that is on the Internet can be reached
by any host on the Internet, regardless of how that host connects to
the Internet.
Unfortunately in practice this is not always the case. Some ISPs
provide special services to their end users that are only accessible
when connected through the ISP. When such a service is discovered
using that ISP's name server, a response will be provided that will
only work if the host connects using a prefix provided by that ISP.
If another ISP's prefix is used, the connection will fail.
In the case of content delivery networks (CDNs), using the name
service of one ISP and then connecting through a second ISP may seem
to work, but may provide very poor service.
In order to address this problem, the homenet naming architecture
takes two approaches. First, for hosts that do not support
provisioning domain separation, we make sure that all ISP name
servers are consulted in such a way that Happy Eyeballs will tend to
work. Second, for hosts that do support provisioning domain
separation, we provide information to the hosts to identify
provisioning domains, and we provide a mechanism that hosts can use
to indicate which provisioning domain to use for a particular DNS
query.
2.2. Homenet-specific considerations 2.2. Homenet-specific considerations
A naming architecture for homenets therefore adds the following A naming architecture for homenets therefore adds the following
considerations: considerations:
o All of the operations mentioned here must reliably function o All of the operations mentioned here must reliably function
automatically, without any user intervention or debugging. automatically, without any user intervention or debugging.
o Because user intervention cannot be required, naming conflicts o Because user intervention cannot be required, naming conflicts
skipping to change at page 5, line 12 skipping to change at page 6, line 19
o Devices that provide services must be able to publish those o Devices that provide services must be able to publish those
services on the homenet, and those services must be available from 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 any part of the homenet, not just the link to which the device is
attached. attached.
o Homenets must address the problem of multiple provisioning o Homenets must address the problem of multiple provisioning
domains, in the sense that the DNS may give a different answer domains, in the sense that the DNS may give a different answer
depending on whether caching resolvers at one ISP or another are depending on whether caching resolvers at one ISP or another are
queried. queried.
An additional requirement from the Homenet Architecture [9] is that An additional requirement from the Homenet Architecture [RFC7556] is
hosts are not required to implement any homenet-specific capabilities that hosts are not required to implement any homenet-specific
in order to discover and access services on the homenet. This capabilities in order to discover and access services on the homenet.
architecture may define optional homenet-specific features, but hosts This architecture may define optional homenet-specific features, but
that do not implement these features must work on homenets. hosts that do not implement these features must work on homenets.
3. Terminology 3. Terminology
This document uses the following terms and abbreviations: This document uses the following terms and abbreviations:
HNR Homenet Router HNR Homenet Router
SHNR Homenet Router implementing simple homenet naming architecture SHNR Homenet Router implementing simple homenet naming architecture
AHNR Homenet Router implementing advanced homenet naming AHNR Homenet Router implementing advanced homenet naming
architecture architecture
ISP Internet Service Provider ISP Internet Service Provider
Forward Mapping A mapping between a host name or service name and
some information about that host or service.
Reverse Mapping A mapping between an IP address and the host that
has that IP address.
Homenet Domain A domain name that is used for publishing the names
of devices and services that are present on the homenet. By
default, 'home.arpa.'
4. Name 4. Name
In order for names to be published on a homenet, it is necessary that In order for names to be published on a homenet, it is necessary that
there be a set of domain names under which such names are published. there be a set of domain names under which such names are published.
These domain names, together, are referred to as the "local domains." These domain names, together, are referred to as the "local domains."
By default, homenets use the reserved domain 'home.arpa.' for By default, homenets publish names for forward lookups under the
publishing names for forward lookups. So a host called 'example' reserved domain 'home.arpa.' [RFC8375] publishing names.
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.
Homenet routers that implement advanced homenet naming may also be So a host called 'example' that published its name on the homenet
configured with a global domain. How such a domain is configured is would publish its records on the domain name 'example.home.arpa.'.
out of scope for this document, and is described in the Advanced Because 'home.arpa.' is used by all homenets, it has no global
Homenet Naming Architecture document [advanced]. meaning, and names published under the domain 'home.arpa' cannot be
used outside of the homenet on which they are published.
In addition to the name, which defaults to 'home.arpa.', names are How to publish names outside of the homenet is out of scope for this
needed for reverse lookups. These names are dependent on the IP document. However, in order to address the problem of validating
addressing used on the homenet. If the homenet is addressed with names published on the homenet using DNSSEC, it is necessary that the
IPv4, a reverse domain corresponding to the IPv4 subnet [1] section homenet have a globally valid delegation from the root. This allows
5.2.1 should be constructed. For example, if the homenet is hosts on the homenet to validate names published on the homenet using
allocating local IP addresses out of net 10 [3], a domain, '10.in- the DNS root trust anchor ([RFC4033] section 3.1).
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. It is not necessary that this delegation work for hosts off the
homenet. HNRs implementing this specification do not answer queries
from outside the homenet; however, when a validating resolver inside
the homenet attempts to validate the chain of trust up to the root
zone, the chain of trust will validate correctly, because the answer
given for internally-available zones will be signed by a DS record
that is present in the delegation externally.
If there is a valid delegation from the root, the homenet domain will
be the name of the delegated domain. By default, there will be no
delegation from the root; in this case, the homenet domainname will
be 'home.arpa.'
In addition to the homenet domain, 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 [RFC1034] section 5.2.1 should be
constructed. For example, if the homenet is allocating local IP
addresses out of net 10 [RFC1918], 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.
If the homenet is addressed with IPv6, it is expected to have a If the homenet is addressed with IPv6, it is expected to have a
unique local address prefix; subsets of this prefix will be unique local address prefix. The reverse mapping domain for hosts on
advertised on every link on the homenet. Every service on the any link in the subnet will be a subdomain of the reverse zone for
homenet that supports IPv6 is expected to be reachable at an address the subset of the ULA prefix that is being advertised on that link.
that is configured using the ULA prefix. Therefore there is no need Every service on the homenet that supports IPv6 is expected to be
for any IPv6 reverse zone to be populated other than the ULA zone. reachable at an address that is configured using the ULA prefix.
So for example if the homenet's ULA prefix is fd00:2001:db8::/48, Therefore there is no need for any IPv6 reverse zone to be populated
then the reverse domain name for the homenet would end in other than the ULA zone. So for example if the homenet's ULA prefix
'8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'. is fc00: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'.
5. Authority 5. Authority
The authority role is provided by a name server that is authoritative There are two types of authoritative name service on the homenet.
for each of the local domains. SHNRs provide authoritative service Every link on the homenet has a zone that is a subdomain of the
for the homenet using DNSSD Discovery Broker [17]. SHNRs also homenet's primary domain. Authority for these zones is local to the
provide Discovery Relay service [12]. On a homenet that has only HNR that is currently authoritative for that zone. The contents of
SHNRs, each SHNR individually provides authoritative service for the these zones are served using DNSSD Discovery Proxy
whole homenet by using Discovery relays to discover services off the [I-D.ietf-dnssd-hybrid]. Consequently, there is no need for database
local link. replication in the case that a new HNR is elected; that HNR simply
takes over the Discovery Relay function.
The Discovery Proxy model relies on each link having its own name. Name service for the homenet domain itself may be stateless or
However, homenets do not actually have a way to name local links that stateful. HNRs are not required to implement stateful service. If
will make any sense to the end user. Consequently, this mechanism one or more HNRs on the homenet are capable of providing this
will not work without some tweaks. In order to address this, service, then one of those HNRs is elected to act as the primary
homenets will use Discovery Brokers [17]. The discovery broker will nameserver for the homenet domain; one or more HNRs may also act as
be configured so that a single query for a particular service will be secondary servers.
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 Name service for reverse mapping subdomains is only provided if one
only be visible to the user in graphical user interfaces in the event or more HNRs can provide stateful service. If no such server is
that the same name is claimed by a service on two links. Services present, the reverse mapping subdomains are not served. If stateful
that are expected to be accessed by users who type in names should servers are present, the primary and secondary servers for these
use [13] if it is available. subdomains will be the same as for the homenet domain.
It is possible that local services may offer services available on IP 5.1. Reachability
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 [11].
This filtering applies to queries within the homenet; it is Whether the homenet domain is a global domain name or not, HNRs
appropriate for non-ULA addresses to be used for offering services, answering queries for domains on the homenet do not respond to
because in some cases end users may want such services to be queries from off the homenet unless configured to do so. Exposing
reachable outside of the homenet. Configuring this is however out of services on the homenet for browsing off the homenet creates many
scope for this document. opportunities for security issues; as such, even an HNR configured to
answer queries from prefixes off the homenet do not provide answers
for names of devices on the homenet unless configured to do so. How
reachability of names published on the homenet is managed is out of
scope for this document: an HNR implementing only this document
checks the source address of every query to see if it is within a
prefix belonging to the homenet; if not, the HNR does not answer the
query.
5.2. Link Names
Each link must have a name. These names are determined using HNCP.
Each router will have zero or more wired links, each of which must be
labeled. In addition, each router will have zero or more wireless
links. Each of these links will be named by the frequency band the
link supports, 2.4ghz or 5ghz.
The HNR is named using its manufacturer name. If, as is likely, two
or more HNRs from the same manufacturer are present on a homenet,
then the HNR name is made up of the manufacturer name plus as many
hexadecimal digits as are required from the HNRs link layer addresses
so as to disambiguate them.
When shipping multiple HNRs as a kit, manufacturers are advised to
arrange that each HNR has a different number in the lowest four bits
of the link-layer address. Manufacturers are also advised to print
that link layer address, in full, somewhere on the outside of the HNR
where it can be seen by the user. Since most HNRs will have more
than one interface, the manufacturer should be consistent in choosing
which link-layer address is printed on the outside and used to
identify the router.
The name given to a link is the name of the HNR, plus a hyphen ('-'),
plus name of the interface of that HNR that is attached to the link.
In the event that this name must be displayed to the user, this
should give the user enough information to figure out which link is
being referenced. In the event that the HNR that is providing
authoritative service for that link changes, the link name changes.
This should only happen if the network topology changes.
If the appearance of a new HNR requires that the name of an existing
HNR change, then the names of all the links managed by that existing
HNR change to reflect the new name.
5.3. Authoritative name service for the homenet domain
All HNRs must be capable of providing authoritative name service for
the homenet domain. HNRs that provide only stateless authoritative
service publish the information that is required for hosts to do DNS
Service Discovery over DNS, using the local resolver as a DNSSD
Discovery Broker.
Some contents are required for the homenet domain, whether it is
stateful or stateless.
o Every link on the homenet has a name that is a subdomain of the
homenet domain. The zone associated with the homenet domain
contains a delegation for each of these subdomains.
o In order for DNSSD service discovery to work, a default browsing
domain must be published. The default browsing domain is simply
the homenet domain.
o If DNSSD SRP is supported (that is, if stateful authoritative
service is present), then an SRV record must be published, along
with a list of available registration zones containing exactly one
entry, for the homenet domain ([I-D.sctl-service-registration]
section 2).
o Also if DNSSD SRP is supported, then one or more A and/or AAAA
records must be published under the name that the SRV record
points to, which should be a single label subdomain of the homenet
domain.
Both stateful and stateless authoritative servers provided by HNRs
must support DNS Stateful Operations [I-D.ietf-dnsop-session-signal]
and DNS Push [I-D.ietf-dnssd-push] for the names for which they are
authoritative.
5.4. Authoritative name service for per-link subdomains of the homenet
domain
Per-link subdomains of the homenet domain are served by DNSSD
Discovery Proxies. Although these proxies generally do caching, no
long-lived state is kept by them. DNSSD Discovery Proxies running on
HNRs must support DNS Stateful Operations and DNS Push.
5.5. Authoritative name service for the ULA reverse mapping domain
The ULA reverse mapping domain itself is only published if stateful
name service is available. It is represented as a single zone, which
contains no delegations: every reverse mapping for an address in the
ULA prefix is simply published in the ULA zone.
In order to permit registration of reverse mappings in this domain,
it must contain an SRV record for the label _homenet-rrp._tcp at the
top level, pointing to the primary server for the domain.
5.6. Authoritative name service for the RFC1918 reverse mapping domains
If IPv4 service is being provided on the homenet, and if stateful
name service is being provided on the homenet, then either one or
sixteen reverse mapping zones for the RFC1918 prefix in use must be
provided. If more than one RFC1918 prefix is in use, reverse mapping
zones for all such prefixes must be provided.
Like the ULA reverse mapping zone, the RFC1918 reverse mapping zones
must each contain an SRV record on the label _homenet-rrp._tcp at the
top level, pointing to the name of the primary server for the zone.
The RFC1918 reverse mapping zone contains the entire address space of
the RFC1918 prefix that is in use on the homenet. Section 3 of
RFC1918 defines three prefixes that may be used. The homenet will
use all of one of these three prefixes. Of these, the 172.16.0.0
prefix is subdivided on a 12-bit boundary, and therefore must be
represented as 16 separate zones. The 10.0.0.0/8 and 192.168.0.0/16
prefixes are each represented as a single zone.
The zone to be updated is therefore the 10.in-addr.arpa zone for all
addresses in 10.0.0.0/8, and the 168.192.in-addr.arpa zone for all
addresses in 192.168.0.0/16. For addresses in the 172.16.0.0/12
prefix, the zone to be updated is the subdomain of 172.in-addr.arpa
that corresponds to bits 8-11 of the prefix: a number between 16 and
31, inclusive.
Also like the ULA zone, the RFC1918 reverse mapping zones contain no
delegations: if there is a single zone, then every reverse mapping
published for an address in the RFC1918 prefix in use on the homenet
is published directly under this zone. If there are sixteen zones,
each address is published in its respective zone. Because the zone
172.in-addr.arpa is not available to be served locally, its locally
served subdomains are simply served individually with no delegation.
6. Resolution 6. Resolution
Name resolution is provided by a local DNS cache or proxy on the Name resolution on the homenet must accomplish two tasks: resolving
homenet, henceforth the "local resolver." All host queries are sent names that are published on the homenet, and resolving names that are
to this local resolver. The local resolver may either act as a full- published elsewhere. This is accomplished by providing several
service caching resolver, or as a DNS proxy. Its responsibility with functional layers.
respect to queries on the homenet is to notice queries for names for
which the local authoritative server is authoritative. Queries for 1. The set of caching nameservers provided by the ISP or ISPs
such names are handled through the local authoritative server. through which the homenet gains access to the global internet, if
Queries for all other names are resolved either by forwarding them to any (homenets can operate standalone as well).
an ISP-provided full service resolver, or by providing the full
service resolver function locally. 2. The set of stateful name servers on the homenet that are
authoritative for the homenet domain as a whole, and for any
reverse mapping zones that are provided by the homenet. This
layer is optional, and may or may not be present. If present, it
is provided by one or more HNRs on the homenet that support
stateful service.
3. The set of stateless name servers on the homenet that are
authoritative for the homenet domain as a whole. These are not
used if one or more stateful servers are present.
4. The set of stateless DNSSD Discovery Proxies that are
authoritative for each of the links in the homenet.
5. A DNS routing proxy. Hereafter we refer to this as the DNS
proxy.
The reason that these are described as layers is that it's quite
possible that all of the DNS services on the homenet might be
provided by a single service listening on port 53; how the request is
routed then depends on the question being asked. So the services
described as running on HNRs are treated as functional blocks which
may be connected internally, if the question being asked can be
answered directly by the HNR that received it, or they may be
separate name servers running on different HNRs, if the question can
be answered within the homenet, or it may be that the HNR receiving
the query forwards it to an ISP caching name server.
The routing works as follows. When a request is received (opcode=0,
Q/R=0), the DNS proxy looks at the owner name in the question part of
the message.
o If the name is a subdomain of the homenet domain, the query is
local.
o If the name is a subdomain of a locally-valid ULA reverse mapping
domain, the query is local.
o If the name is a subdomain of a locally valid RFC1918 reverse
mapping zone, the query is local.
o If the name is a subdomain of any locally-served zone, as defined
in Locally Served DNS Zones [localzones], but is not otherwise
identified as local, the response is NXDOMAIN.
o Otherwise, the query is not local.
Local queries are further divided. If the query is for a link
subdomain, the DNS proxy consults the table that maps per-link
subdomains to the HNRs that serve them. Either the HNR that serves
this link subdomain is the HNR that received the question, or not.
If it is, then the DNS proxy passes the query directly to the local
DNSSD Discovery Proxy. Otherwise, it forwards the query to the DNSSD
Discovery Proxy on the HNR that is providing Discovery Proxy service
for that link.
If the query is for the homenet subdomain, and stateful authoritative
service for the homenet subdomain is present on the homenet, then
either the HNR receiving the query provides stateful authoritative
service, or not. If it does, then the query is passed directly to
the local authoritative server. If not, then the HNR looks in the
table of authoritative servers generated by HNCP and forwards the
request to one of these servers. Queries for the reverse mapping
zones are handled the same way.
Otherwise, the query is examined to see if it contains an EDNS(0)
Provisioning Domain option. If not, it round-robined across the
resolvers provided by each ISP in such a way that each ISP is tried
in succession, and the same ISP is not asked the same question
repeatedly. If the query does contain the EDNS(0) Provisioning
Domain option, then that option is used to select which ISP's
resolvers are used for the round robin.
6.1. Round Robining
There are several cases above where there may be a choice of servers
to which to forward queries. It's assumed that when the query can be
satisfied by the HNR that received it, round robining is not
required. If there is a specific HNR that is responsible for a
particular link, then round robining is likewise not required.
However, if the query is for a stateful authoritative server, and the
HNR that received it does not provide this service, and there is more
than one HNR on the homenet that does provide the service, the HNR
that received the query round robins it across the available set of
HNRs that could answer it.
Similarly, if the query is to be sent to an ISP's resolver, and the
ISP has provided more than one resolver, round robining is done
across the set of resolvers provided by that ISP. If the query is to
be attempted at every ISP, then that is accomplished by round-
robining in such a way that each ISP is tried in succession, rather
than all the resolvers at one ISP, and then all the resolvers at the
next ISP, and so on.
6.2. Retransmission
For queries that can't be resolved locally by the HNR that received
them, retransmission as described in [RFC1035] is performed.
6.3. DNS Stateful Operations and DNS Push
DNS proxies on HNRs are required to support DNS Stateful Operations
and DNS Push. When a DNS Push operation is requested on a name that
can be satisfied by the HNR that received it, it is handled locally.
When such an operation is requested on a name that is local to the
homenet, but can't be satisfied by the HNR that received it, a DNS
Stateful operation is started with the HNR that is responsible for
it.
6.4. Multicast DNS
In addition to consulting the local resolver, hosts on the homenet
may attempt to discover services directly using Multicast DNS. HNRs
may filter out incoming Multicast DNS queries, forcing the client to
do service discovery using the DNS protocol. If such filtering is
not done, the client will be able to discover services on the link to
which it is attached, but will not be able to discover services
elsewhere.
It is believed that all currently-available hosts support DNSSD using
the DNS protocol. Support for mDNS on the local link is therefore
not required. However, if an mDNS query returns the same answer as
the DNS protocol query, this is not expected to be a problem.
6.5. Host behavior
Hosts that support the RA Provisioning Domain option direct queries
to the name server(s) of the provisioning domain they will use for
communication using the EDNS(0) provisioning domain option. In
practice this means that a host that supports PvDs will keep a set of
provisioning information for each prefix that it received from the
router, and will either choose a prefix to use based on its own
criteria, or will attempt to connect using every PvD at once or in
sequence. Answers to queries sent for a particular provisioning
domain will only be used with source addresses for prefixes that are
in that provisioning domain.
7. Publication 7. Publication
7.1. DNS Service Discovery Registration Protocol Names are published either using Multicast DNS Service Discovery
[RFC6762] or DNSSD Service Registration Protocol
([I-D.sctl-service-registration]). Reverse mappings are published
using Homenet Reverse Mapping Update Protocol Section 7.2.
The DNSSD Service Registration protocol [13] requires that DNS 7.1. DNSSD Service Registration Protocol
updates be validated on the basis that they are received on the local
link. To ensure that such registrations are actually received on
local links in the homenet, updates are sent to the local relay proxy
([12]) (XXX how?).
The relay proxy encapsulates the update and sends it to whatever HNRs that provide stateful authoritative service also publish
Discovery Proxy is listening on the link; the Discovery proxy then information acquired using DNSSD Service Registration Protocol
either consumes the update directly, or forwards it to the [I-D.sctl-service-registration]. DNSSD SRP does not explicitly
authoritative resolver for the local service discovery zone. If the support population of the reverse zone; hosts that wish to provide
registration protocol is not supported on the homenet, the Discovery reverse mapping information must first establish their hostname using
Proxy rejects the update with a ??? RCODE. DNSSD SRP; once established, the key used to authenticate the DNSSD
SRP update is also used to update the reverse name.
Homenets are not required to support Service Registration. Service Support for SRP provides several advantages over DNSSD Discovery
registration requires a stateful authoritative DNS server; this may Proxy. First, DNSSD SRP provides a secure way of claiming service
be beyond the capability of the minimal Homenet router. However, names. Second, a claimed name is valid for the entire network
more capable Homenet routers should provide this capability. In covered by the SRP service, not just an individual link, as is the
order to make this work, minimal Homenet routers MUST implement the case with mDNS. Third, SRP does not use multicast, and is therefore
split hybrid proxy [12]. This enables a Homenet with one or more more reliable on links with constrained multicast support
Homenet routers that provide a stateful registration cache to allow [I-D.ietf-mboned-ieee802-mcast-problems].
those routers to take over service, using Discovery Relays to service
links that are connected using Homenet routers with more limited
functionality.
7.2. Configuring Service Discovery Support for the DNSSD SRP service is not sufficient to achieve full
deployment of DNSSD SRP: it is also necessary that services advertise
using DNSSD SRP. Requiring such support is out of scope for this
document; our goal is simply to specify a way in which DNSSD SRP can
be supported on homenets, so that that as adoption of SRP increases
on devices providing service, it can actually be used.
Clients discovering services using DNS-SD [7] follow a two-step 7.2. Homenet Reverse Mapping Update Protocol
process. The first step is for the client device to determine in
which domain(s) to attempt to discover services. The second step is
for the client device to then seek desired service(s) in those
domain(s). For an example of the second step, given the desired
service type "IPP Printing", and the domains "local" and
"meeting.ietf.org", the client device forms the queries
"_ipp._tcp.local. PTR ?" (resolved using Multicast DNS) and
"_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and
then presents the combined list of results to the user.
The first step, determining in which domain(s) to attempt to discover This is an extension to the DNSSD Service Registration protocol. The
services, is performed in a variety of ways, as described in purpose is to allow for updates of reverse mappings. Hosts wishing
Section 11 of the DNS-Based Service Discovery specification [7]. to publish reverse mappings first publish their hostname using DNSSD
SRP. When this process has successfully completed, the host can add
reverse mappings to the ULA reverse mapping domain and to the RFC1918
reverse mapping domain, if present.
The domain "local" is generally always in the set of domains in which 7.2.1. Adding ULA reverse mappings
the client devices attempt to discover services, and other domains
for service discovery may be configured manually by the user.
The device also learns additional domains automatically from its The host first determines the ULA prefix. If there is more than one
network environment. For this automatic configuration discovery, ULA prefix active, the ULA prefix with the longest preferred lifetime
special DNS queries are formulated. To learn additional domain(s) in is used. A ULA prefix can be identified because it matches the
which to attempt to discover services, the query string prefix fc00::/7 ([RFC4193] section 3.1). The actual prefix is then
"lb._dns_sd._udp" is prepended onto three different kinds of the first 48 bits of the advertised prefix or the IP address in that
"bootstrap domain" to form DNS queries that allow the device to learn prefix.
the configuration information.
One of these bootstrap domains is the fixed string "local". The Because the ULA reverse mapping zone contains no delegations, all
device issues the query "lb._dns_sd._udp.local. PTR ?" (resolved updates go to that one zone. To determine where to send the updates,
using Multicast DNS), and if any answers are received, then they are the host first queries the SRV record under the label _homenet-
added to the set of domains in which the client devices attempt to rrp._tcp at the top of the ULA reverse mapping zone. It then uses
discover services. the name contained in the SRV record to look up A and/or AAAA records
to which to send the update.
Another kind of these bootstrap domains is name-based, derived from The update is then signed using SIG(0) with the key that was used for
the DHCPv4 "domain name" option (code 15) [4] (for IPv4) or the DNS the DNSSD SRP registration. The update is then sent using DNS Update
Search List (DNSSL) Router Advertisement option [10] (for IPv6). If [RFC2136] to one of the IP addresses received during the A/AAAA
a domain in the DNSSL is "example.com", then the device issues the resolution step. The update is sent using TCP; if a TCP connection
query "lb._dns_sd._udp.example.com. PTR ?" (resolved using Unicast to one of the addresses fails, each subsequent address is tried in
DNS), and if any answers are received, then they are likewise added succession; if none of the addresses is reachable, the update fails,
to the set of domains in which the client devices attempt to discover and may be retried after a reasonable period (on the order of an
services. hour) has elapsed.
Finally, the third kind of bootstrap domain is address-based, derived 7.2.2. Adding RFC1918 reverse mappings
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
"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
added to the set of domains in which the client devices attempt to
discover services.
Since there is an HNR on every link of a homenet, automatic RFC1918 reverse mapping updates use the same mechanism as ULA reverse
configuration could be performed by having HNRs answer the mapping updates. The host must first determine which zone to update,
"lb._dns_sd._udp.local. PTR ?" (Multicast DNS) queries. However, as described earlier in Section 5.6. Once the zone has been
because multicast is slow and unreliable on many modern network determined, the reverse mapping is updated as described in
technologies like Wi-Fi, we prefer to avoid using it. Instead we Section 7.2.1.
require that a homenet be configured to answer the name-based
bootstrap queries. By default the domain in the DNSSL communicated
to the client devices will be "home.arpa", and the homenet will be
configured to correctly answer queries such as
"lb._dns_sd._udp.example.com. PTR ?", though client devices must not
assume that the name will always be "home.arpa". A client could be
configured with any valid DNSSL, and should construct the appropriate
bootstrap queries derived from the name(s) in their configured DNS
Search List.
HNRs will answer domain enumeration queries against every IPv4 8. Host Configuration
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 Each HNR provides a Homenet DNS Proxy. When an HNR provides the DNS
"b._dns_sd._udp.<domain>" subdomain. By default, the 'home.arpa' resolver IP address to hosts on the link using RA, DHCPv4 or DHCPv6,
domain is advertised. Similarly, 'home.arpa' is advertised as the it provides its own address. The IPv4 address that it provides is a
default browsing and service registration domain under valid IPv4 address on the link to which the host is attached. The
"db._dns_sd._udp.<domain>", "r._dns_sd._udp.<domain>", IPv6 address it provides is an address in the homenet's ULA prefix
"dr._dns_sd._udp.<domain>" and "lb._dns_sd._udp.<domain>". that is valid on the link to which the host is attached.
In order for this discovery process to work, the homenet must provide When sending router advertisements, the homenet includes the PvD ID
authoritative answers for each of the domains that might be queried. RA option [I-D.ietf-intarea-provisioning-domains] in each RA.
To do this, it provides authoritative name service for the 'ip6.arpa' Because the PvD ID RA option can only be sent once per RA message, if
and 'in-addr.arpa' subdomains corresponding to each of the prefixes the homenet is connected to more than one ISP, the prefixes for each
advertised on the homenet. For example, consider a homenet with the ISP must be advertised in different RA options. In this case, the
192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56 prefix for the ULA should also be sent in a separate RA.
prefixes. This homenet will have to provide a name server that
claims to be authoritative for 1.168.192.in-addr.arpa,
6.5.4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa and
0.0.9.8.7.6.5.4.3.2.1.0.c.f.ip6.arpa.
An IPv6-only homenet would not have an authoritative server for a If the configuration received from the ISP includes a Domain Name
subdomain of in-addr.arpa. These public authoritative zones are (DHCPv4) or Domain Search List (DHCPv4 or DHCPv6) option, the domain
required for the public prefixes even if the prefixes are not name provided is used to identify the PvD. In the case of Domain
delegated. However, they need not be accessible outside of the Search List options, if there is more than one, the first one is
homenet. used. For the ULA prefix, the homenet domain is used to identify the
PvD.
It is out of the scope of this document to specify ISP behavior, but In order to facilitate DNSSD bootstrapping, any DHCPv4, DHCPv6 or RA
we note that ISPs have the option of securely delegating the zone, or Domain Search List options contain only a single domain name, the
providing an unsigned delegation, or providing no delegation. Any homenet domain. This allows hosts to quickly bootstrap DNS Service
delegation tree that does not include an unsigned delegation at or Discovery using the local domain name, as descried in [RFC6763]
above the zone cut for the ip6.arpa reverse zone for the assigned section 11.
prefix will fail to validate.
Ideally, an ISP should provide a secure delegation using a zone- 9. Globally Unique Names
signing key provided by the homenet. However, that too is out of
scope for this document. Therefore, an ISP that wishes to support
users of the simple homenet naming architecture will have to provide
an unsigned delegation. We do not wish, however, to discourage
provisioning of signed delegations when that is possible.
8. Host Configurtion Homenets are not required to have globally unique names. Homenets
operating according to this specification do not publish names in
such a way that they can be resolved by hosts that aren't on the
homenet. However, such names are useful for DNSSEC validation.
Hosts on the homenet receive a set of resolver IP addresses using There are three ways that homenets can get global names:
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 Recursive DNS Server Option ([10],
Section 5.1) in router advertisements.
All Homenet routers provide resolver information using both stateless 1. They can be manually configured by the user. How this is done is
DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional, out of scope for this document.
however if either service is offered, resolver addresses will be
provided using that mechanism as well.
9. Globally Unique Name 2. They can publish a delegation with the ISP, using a Homenet
Delegation Registration Protocol Section 11.
Automatic configuration of a globally unique name for the homenet is 3. They can publish a delegation with some other provider, using
out of scope for this document. However, homenet servers MUST allow Homenet Delegation Registration Protocol Section 11. How this is
the user to configure a globally unique name in place of the default configured is out of scope for this document.
name, 'home.arpa.' By default, even if configured with a global
name, homenet routers MUST NOT answer queries from outside of the Homenets are also not required to support global delegations for
homenet for subdomains of that name. reverse mapping of global IPv4 and IPv6 addresses. How this would be
done is out of scope for this document.
10. DNSSEC Validation 10. DNSSEC Validation
DNSSEC Validation for the 'home.arpa' zone and for the locally-served DNSSEC validation for 'home.arpa' requires installing a per-homenet
'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust trust anchor on the host, and is therefore not practical. Validation
anchor. Establishment of a trust anchor for such validation is out for locally-served reverse zones for the ULA and RFC1918 addresses
of scope for this document. would likewise require a trust anchor to be installed on the host,
and likewise are not practical.
Homenets that have been configured with a globally unique domain MUST If DNSSEC validation is to be done for the homenet, the homenet must
support DNSSEC signing of local names, and must provide a way to acquire a global name, and must be provided with a secure delegation.
generate a KSK that can be used in the secure delegation of the Secure delegations must also be provided from the homenet domain to
globally unique domain assigned to the homenet. each of the per-link subdomains.
11. Support for Multiple Provisioning Domains Each HNR on a homenet generates its own private/public key pair that
can serve as a trust anchor. These keys are shared using HNCP
[RFC7788]. HNRs MUST NOT use pre-installed keys: each HNR MUST
generate its own key. The HNR responsible for authoritative
Discovery Proxy service on a particular link signs the zone for that
link; delegations from the homenet domain zone to each per-link
subdomain zone include a DS record signed by the ZSK of the homenet
zone.
Homenets must support the Multiple Provisioning Domain Architecture 10.1. How trust is established
[9]. Hosts connected to the homenet may or may not support multiple
provisioning domains. For hosts that do not support multiple
provisioning domains, the homenet provides one or more resolvers that
will answer queries for any provisioning domain. Such hosts may
receive answers to queries that either do not work as well if the
host chooses a source address from a different provisioning domain,
or does not work at all. However, the default source address
selection policy, longest-match [CITE], will result in the correct
source address being chosen as long as the destination address has a
close match to the prefix assigned by the ISP.
Hosts that support multiple provisioning domains will be provisioned Every HNR has its own public/private key pair. A DS record for each
with one or more resolvers per provisioning domain. Such hosts can such public key is published in the delegation for the homenet
use the IP address of the resolver to determine which provisioning domain. If stateless authoritative service for the homenet zone is
domain is applicable for a particular answer. being provided, then each HNR signs its own homenet zone. The signed
zone should be very stable, although the delegations may change when
the network topology changes. The HNR can therefore sign the zone
using its private key whenever it changes. Each HNR will have a copy
of the zone signed with a different key, but since all of the ZSKs
are present in the DS RRset at the delegation point, validation will
succeed.
Each ISP has its own provisioning domain. Because ISPs connections If stateful authoritative service is being provided, the HNR that is
cannot be assumed to be persistent, the homenet has its own separate acting as primary signs the zone, and all the secondaries serve
provisioning domain. copies acquired using zone transfers. If the HNR that is primary
goes away, then a secondary becomes primary and signs the zone before
beginning to provide service. Again, since all of the HNR's public
keys exist in the DS RRset at the delegation, the zone can be
validated.
Configuration from the IPv4 DHCP server are treated as being part of 11. Homenet Delegation Registration Protocol
the homenet provisioning domain. The case where a homenet advertises
IPv4 addresses from one or more public prefixes is out of scope for
this document. Such a configuration is NOT RECOMMENDED for homenets.
Configuration for IPv6 provisioning domains is done using the Homenet Delegation Registration Protocol (HDeRP) operates similarly
Multiple Provisioning Domain RA option [CITE]. to DNSSD Service Registration Protocol. When a homenet is not
connected to an ISP that supports HDeRP, and then an ISP connection
becomes available, the HNR that is connected to the ISP determines
whether HDeRP is available. This is done by first determining the
ISP domain.
If the connection to the ISP is IPv4-only, this will be either the
DHCPv4 Domain Name option or, if not present, the only domain name in
the DHCPv4 Domain Name Search List option. If the Domain Name Search
List option contains more than one name, HDeRP is not supported by
the ISP.
If the connection to the ISP is dual-stack or IPv6-only, then the
DHCPv6 Domain Search List option obtained through DHCPv6 Prefix
Delegation is used. If it is not present, or if it contains more
than one domain name, HDeRP is not supported by the ISP.
Once the ISP domain has been discovered, the HNR looks for an SRV
record owned by the name _homenet-derp._tcp under the ISP domain. If
this is not present, HDeRP is not supported. If the SRV record is
present, then the HNR looks for A and AAAA records on the hostname
provided in the HNR. If present, these are used when attempting the
update.
The HNR then constructs a DNS update. The DNS update creates a
delegation for the zone home.arpa, with a DS record for each HNR on
the homenet, containing that HNR's public key. The HNR doing the
update lists its key as the first key in the DS RRset. The update is
signed using SIG(0) with the private key of the HNR that is
constructing it. As with DNSSD SRP, the update includes an Update
Lease EDNS(0) option, specifying a key lifetime of a week.
The HNR then attempts to connect to the hostname provided in the SRV
record, in a round-robin fashion across the set of IP addresses
discovered during the A/AAAA lookup phase. When it has successfully
connected, it sends the DNS update.
The HDeRP server validates the update by checking the SIG(0)
signature of the update against the first key in the DS RRset. If
the update is successfully validated, then the server generates a
domain name and sends a reply back to the HNR on the same TCP
connection, including the NOERROR (0) RCODE, and including in the
query section the actual domain name that was generated.
This domain name then becomes the homenet name. Subsequent updates
use the homenet name rather than 'home.arpa'. It is not necessary
that the same HNR do the update; if a different HNR does the update,
it lists its public key first in the DS RRset, and signs the update
using its private key.
The HDeRP is responsible for removing the delegation if it is not
refreshed for the length of its lifetime. HNRs should attempt to
refresh the delegation when half the lifetime has experienced, then
again at 5/8ths, and again at 7/8ths of the lifetime. If the ISP
becomes unavailable, and a different ISP becomes available that
supports HDeRP, the homenet should migrate to the new ISP.
12. 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 document does not specify 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.
13. Management Considerations 13. Expected Host Behavior
It is expected that hosts will fall into one of two categories: hosts
that are able to discover DNS-SD browsing domains, and hosts that are
not. Hosts that can discover DNS-SD browsing domains can be expected
to successfully use service discovery across the entire homenet.
Hosts that do not will only be able to discover services on the
particular local subnet of the homenet to which they happen to be
attached at any given time.
This is not considered to be a problem, since it is understood by the
authors that the vast majority of hosts that are capable of doing
mDNS discovery are also capable of doing DNS-SD discovery as
described in [RFC6763].
14. 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.
14. Privacy Considerations 15. 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.
something like HTTP token binding [15] to mitigate this risk.
15. Security Considerations 16. 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.
16. IANA considerations 17. IANA considerations
No new actions are required by IANA for this document. 17.1. Homenet Reverse Registration Protocol
Note however that this document is relying on the allocation of IANA is requested to add a new entry to the Service Names and Port
'home.arpa' described in Special Use Top Level Domain '.home.arpa' Numbers registry for homenet-rrp with a transport type of tcp. No
[16]. This document therefore can't proceed until that allocation is port number is to be assigned. The reference should be to this
done. [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO document, and the Assignee and Contact information should reference
PUBLICATION]. the authors of this document. The Description should be as follows:
17. Normative References Availability of Homenet Reverse Registration Protocol service for a
given domain is advertised using an SRV record with an owner name of
"_homenet-rrp._tcp.<domain>." in that domain, which gives the target
host and port where Homenet Reverse Registration service is provided
for the named domain.
[1] Mockapetris, P., "Domain names - concepts and facilities", 17.2. Homenet Delegation Registration Protocol
IANA is requested to add a new entry to the Service Names and Port
Numbers registry for homenet-derp with a transport type of tcp. No
port number is to be assigned. The reference should be to this
document, and the Assignee and Contact information should reference
the authors of this document. The Description should be as follows:
Availability of Homenet Delegation Registration Protocol service for
a given domain is advertised using an SRV record with an owner name
of "_homenet-derp._tcp.<domain>." in that domain, which gives the
target host and port where Homenet Delegation Registration service is
provided for the named domain.
17.3. Unique Local Address Reserved Documentation Prefix
IANA is requested to add an entry to the IPv6 Special-Purpose Address
Registry for the prefix fc00:2001:db8::/48. The Name shall be
"Unique Local Address Documentation Prefix." The reference RFC will
be this document, once published. The date will be the date the
entry was added. All other fields will be the same as for the
Documentation prefix, 2001:db8::/32.
18. References
18.1. Normative References
[I-D.ietf-dnsop-session-signal]
Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
Lemon, T., and T. Pusateri, "DNS Stateful Operations",
draft-ietf-dnsop-session-signal-16 (work in progress),
September 2018.
[I-D.ietf-dnssd-hybrid]
Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
progress), March 2018.
[I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-15 (work in progress), September
2018.
[I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-03 (work in
progress), October 2018.
[I-D.sctl-service-registration]
Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service-
registration-02 (work in progress), July 2018.
[localzones]
Internet Assigned Numbers Authority, "Locally-Served DNS
Zones", n.d., <https://www.iana.org/assignments/
locally-served-dns-zones/locally-served-dns-zones.xhtml>.
[RFC1034] 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 [RFC1035] 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] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
[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>.
[6] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC6762] 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>.
[7] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] 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>.
[8] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
Weil, "IPv6 Home Networking Architecture Principles", "Framework for Content Distribution Network
RFC 7368, DOI 10.17487/RFC7368, October 2014, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
<https://www.rfc-editor.org/info/rfc7368>. August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[9] Anipko, D., Ed., "Multiple Provisioning Domain [RFC7556] 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>.
[10] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
"IPv6 Router Advertisement Options for DNS Configuration", Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
RFC 8106, DOI 10.17487/RFC8106, March 2017, 2016, <https://www.rfc-editor.org/info/rfc7788>.
<https://www.rfc-editor.org/info/rfc8106>.
[11] Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
progress), March 2018.
[12] Cheshire, S. and T. Lemon, "Multicast DNS Discovery
Relay", draft-sctl-dnssd-mdns-relay-04 (work in progress),
March 2018.
[13] Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service-
registration-00 (work in progress), July 2017.
[14] 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.
[15] Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
tokbind-https-18 (work in progress), June 2018.
[16] Pfister, P. and T. Lemon, "Special Use Domain
'home.arpa.'", draft-ietf-homenet-dot-14 (work in
progress), September 2017.
[17] Cheshire, S. and T. Lemon, "Service Discovery Broker",
draft-sctl-discovery-broker-00 (work in progress), July
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 [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
multicast DNS beyond a single multicast domain. However, in order to 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
use this as a solution, some shortcomings need to be considered. <https://www.rfc-editor.org/info/rfc8375>.
Most obviously, it requires that every multicast domain have a 18.2. Informative References
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 [I-D.ietf-mboned-ieee802-mcast-problems]
disambiguation is that this will not be solved at a protocol level Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
for devices that do not implement the registration protocol. Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-02 (work
in progress), August 2018.
Authors' Addresses Authors' Addresses
Ted Lemon Ted Lemon
Nibbhaya Consulting Nibbhaya Consulting
P.O. Box 958 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
 End of changes. 75 change blocks. 
393 lines changed or deleted 771 lines changed or added

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