Network Working Group                                           T. Lemon
Internet-Draft                                       Barefoot                                       Nibbhaya Consulting
Intended status: Informational                                D. Migault
Expires: May 3, September 6, 2018                                      Ericsson
                                                             S. Cheshire
                                                              Apple Inc.
                                                        October 30, 2017
                                                           March 5, 2018

        Simple Homenet Naming and Service Discovery Architecture
                  draft-ietf-homenet-simple-naming-00
                  draft-ietf-homenet-simple-naming-01

Abstract

   This document describes a simple name resolution how names are published and service
   discovery architecture for resolved on
   homenets, using the 'home.arpa' domain
   name hierarchy.  This architecture covers local publication of names,
   as well as name resolution service for local and global how hosts are configured to use these names for
   devices connected to the homenet.

   This document does not cover discovery of homenet discover
   services by devices
   not connected to on homenets.  It presents the homenet, nor DNSSEC, nor acquisition complete architecture, and
   configuration of
   describes a global name as an alternative to 'home.arpa'.
   These topics will simple subset of that architecture that can be addressed used in a separate document.
   low-cost homenet routers.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 3, September 6, 2018.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Existing solutions
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Managed LAN versus Homenet  . . . . . . . . . . . . . . .   4
   2.
     2.2.  Homenet-specific considerations . . . . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.
   4.  Name Resolution  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Configuring Resolvers
   5.  Authority . . . . . . . . . . . . . . . . . .   5
     3.2. . . . . . . . .   6
   6.  Resolution  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Publication . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  DNS Service Discovery Registration Protocol . . . . . . .   6
     3.3.   7
     7.2.  Configuring Service Discovery . . . . . . . . . . . . . .   6
     3.4.  Resolution of local names   7
   8.  Host Configurtion . . . . . . . . . . . . . . . . .   8
     3.5. . . . . .  10
   9.  Globally Unique Name  . . . . . . . . . . . . . . . . . . . .  10
     3.6.
   10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . .  10
     3.7.
   11. Support for Multiple Provisioning Domains . . . . . . . .  10
     3.8. . .  11
   12. Using the Local Namespace While Away From Home  . . . . . . .  11
   4.
   13. Management Considerations . . . . . . . . . . . . . . . . . .  11
   5.
   14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
   6.  12
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  12
   16. IANA considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  12
   17. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses
   Appendix A.  Existing solutions . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . .  13

1.  Introduction

   This document describes a simple . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document is a homenet architecture for providing name document.  The term 'homenet'
   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,
   optionally, more than one internet service provider.  Home network
   users are assumed not to be knowledgable in network operations, so
   homenets automatically configure themselves, providing connectivity
   and service discovery for homenets. within the home with no operator intervention.
   This allows hosts
   connected to document describes the aspect of homenet automatic configuration
   that has to use the Domain Name System to discover
   services do with service discovery and name resolution.

   The homenet naming architecture consists of two parts: the hosts providing those services, whether they are on
   the home network or the Internet.  In addition, simple
   naming architecture, and the advanced naming architecture.  The
   advanced architecture provides approximate parity of features with a way for hosts connected to
   managed network, including the homenet that provide
   services ability to advertise those publish services for discovery by other homenet
   hosts.

   This on the
   internet.  The simple architecture is intended to serve as provides a foundational
   architecture for naming minimal set of features
   required to enable seamless service discovery on a multi-link home networks.  It is expected that all
   Homenet routers will implement this architecture.  It satisfies
   network, but does not attempt to provide feature parity with a
   subset
   managed LAN.

   This document begins by presenting a motivational list of the
   requirements listed in IPv6 Home Networking
   Architecture Principles [7], and provides a foundation for completely
   addressing those requirements.

   This simple architecture leaves considerations, which should give the following requirements from
   RFC7368 Section 3.7 unaddressed:

   o  Acquisition of reader a global name for the homenet, to be used in place clear
   idea of 'home.arpa.'

   o  Delegation the scope of public reverse trees the problem being solved.  It then explains how
   each requirement is addressed, and provides references for prefixes delegated to relevant
   standards documents describing the
      homenet: subdomains details of 'ip6.arpa' and 'in-addr.arpa'.

   o  Publication of names on the homenet for general public use on the
      internet.

   o  Publication of names on the homenet for use implementation.
   Some requirements are not satisfied by authorized users of the homenet when connected simple architecture; these
   are discussed in this document, but explained in more detail in the
   Advanced Homenet Naming Architecture document, which is to other networks.

   o  Secure delegation, enabling DNSSEC validation of names published follow.

2.  Requirements

   Name service on a local area network (LAN) requires the homenet.

   A later document following:

   o  Name: a forward domain under which information about local
      services will describe additional functionality that can be
   implemented on more capable home network routers, so that published

   o  Authority: a home
   network name server that has is authoritative for at least one such router, a
      forward and one or more routers two reverse domains 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 are applicable to discover services on
   any that
      network are:

   o  A domain name  Resolution: a full-service caching DNS resolver

   o  Publication: a mechanism that represents the network, under which names can
      be published and

      *  allows services advertised

   o  The ability on the LAN to publish names that identify hosts and services.

   o  Advertising locally available information about the
         services they provide

      *  allows services by publishing resource
      records.

   o  A service that can be queried for names and resources records in
      order to discover and use services.

   o  Advertisement publish information on how to reach them

      *  manages the lifetime of that service such information, so that hosts can send queries it persists
         long enough to
      it. prevent spoofing, but protects end users from
         seeing stale information

   o  Timely removal of published names and resource records when they
      are no longer in use

   A simple homenet naming architecture adds the following
   considerations:

   1.  Users cannot be assumed to be skilled  Host configuration: one or knowledgeable in name
       service operation, more automatic mechanisms (e.g.  DHCP
      or even RA) that provide:

      *  caching resolver information to have any sort of mental model of hosts on the LAN

      *  information about how services on the LAN can publish
         information

   o  Trust: some basis for trusting the information that is provided by
      the service discovery system

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 work. 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:

   o  All of the operations mentioned here must reliably function
      automatically, without any user intervention or debugging.

   2.

   o  Because user intervention cannot be required, naming conflicts
      must be resolved automatically, and, to the extent possible,
      transparently.

   3.  Hosts are not required to implement any homenet-specific
       capabilities in order to discover and access services on the
       homenet.

   4.

   o  Devices that provide services must be able to publish those
      services on the homenet, and those services must be available from
      any part of the homenet, not just the link to which the device is
      attached.

   5.  Homenet explicitly supports multihoming: connecting to more than
       one Internet Service Provider.  It therefore

   o  Homenets must address the problem of multiple provisioning domains [8],
      domains, in the sense that the DNS may give a different answer
      depending on whether caching resolvers at one ISP or another are
      queried.

1.1.  Existing solutions

   Previous attempts to automate naming and service discovery in

   An additional requirement from the
   context of a home network Homenet Architecture [9] is that
   hosts are able not required to function with varying degrees
   of success depending implement any homenet-specific capabilities
   in order to discover and access services on the topology of the home network.
   Unfortunately, these solutions homenet.  This
   architecture may define optional homenet-specific features, but hosts
   that do not fully address the requirements
   of implement these features must work on homenets.

   For example, Multicast DNS [5] can provide naming

3.  Terminology

   This document uses the following terms and service
   discovery [6], but only within a single multicast domain.

   The Domain abbreviations:

   HNR  Homenet Router

   SHNR  Homenet Router implementing simple homenet naming architecture

   AHNR  Homenet Router implementing advanced homenet naming
      architecture

   ISP  Internet Service Provider

4.  Name System provides a hierarchical namespace [1], a
   mechanism

   In order for querying name servers to resolve names [2], to be published on a mechanism
   for updating namespaces by adding and removing names [4], and homenet, it is necessary that
   there be a
   mechanism for discovering services [6].  Unfortunately, DNS provides
   no mechanism for automatically provisioning new namespaces, and
   secure updates set of domain names under which such names are published.
   These domain names, together, are referred to namespaces require that as the host submitting "local domains."
   By default, homenets use the
   update have reserved domain 'home.arpa.' for
   publishing names for forward lookups.  So a public or symmetric key host called 'example'
   that is known to published its name on the network
   and authorized for updates.  In an unmanaged network, homenet would publish its records on
   the publication
   of and authorization of these keys domain name 'example.home.arpa.'.  Because 'home.arpa.' is an unsolved problem.

   Some managed networks get around this problem used
   by having all homenets, it has no global meaning, and names published under
   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 domain 'home.arpa' cannot be used outside of the trust problem: DHCP can validate homenet on which
   they are published.

   Homenet routers that implement advanced homenet naming may also be
   configured with a
   device is at least connected to global domain.  How such a network link that domain is actually part configured is
   out of scope for this document, and is described in the Advanced
   Homenet Naming Architecture document [advanced].

   In addition to the managed network.  This prevents an off-network attacker from
   registering a name, but provides no mechanism which defaults to 'home.arpa.', names are
   needed for actually validating reverse lookups.  These names are dependent on the identity of IP
   addressing used on the host registering homenet.  If the name. homenet is addressed with
   IPv4, a reverse domain corresponding to the IPv4 subnet [1] section
   5.2.1 should be constructed.  For example, it if the homenet is
   allocating local IP addresses out of net 10 [3], a domain, '10.in-
   addr.arpa' would be easy for an attacker on required.  Like 'home.arpa.', '10.in-addr.arpa'
   is a locally-served zone, and has no validity outside of the network homenet.

   If the homenet is addressed with IPv6, it is expected to steal a registered name.

   Hybrid Multicast DNS [10] proposes a mechanism for extending
   multicast DNS beyond have a single multicast domain.  However, in order to
   use
   unique local address prefix; subsets of this as a solution, some shortcomings need to prefix will be considered.
   Most obviously, it requires that
   advertised on every multicast domain have a
   separate name.  This then requires that link on the homenet.  Every service on the
   homenet generate names
   for every multicast domain.  These names would then be revealed that supports IPv6 is expected 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 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 user have in
   '8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'.

5.  Authority

   The authority role is provided by a mental
   model name server that is authoritative
   for each of the topology of local domains.  SHNRs provide authoritative service
   for the network in order to guess on which link homenet using DNSSD Discovery Broker [17].  SHNRs also
   provide Discovery Relay service [12].  On a given homenet that has only
   SHNRs, each SHNR individually provides authoritative service may appear.

   At present, for the approach we intend
   whole homenet by using Discovery relays to take with respect discover services off the
   local link.

   The Discovery Proxy model relies on each link having its own name.
   However, homenets do not actually have a way to
   disambiguation is 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 solved at configured so that a protocol level single query for devices that do not implement the registration protocol.

2.  Terminology

   This document uses the following terms and abbreviations:

   HNR  Homenet Router

   ISP  Internet Service Provider

3.  Name Resolution

3.1.  Configuring Resolvers

   Hosts on the homenet receive a set of resolver IP addresses using
   either DHCP or RA.  IPv4-only hosts particular service will receive IPv4 addresses be
   successful in providing the information required to access that
   service, regardless 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 ([9],
   Section 5.1) in router advertisements.

   All Homenet routers provide resolver information using both stateless
   DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is optional,
   however if either service link it is offered, resolver addresses on.

   Artificial link names will be
   provided generated using that mechanism as well.

3.2.  DNS Service Discovery Registration Protocol

   The DNSSD Service Registration protocol [12] requires that DNS
   updates HNCP.  These should
   only be validated on visible to the basis that they are received on user in graphical user interfaces in the local
   link.  To ensure event
   that such registrations are actually received on
   local links in the homenet, updates same name is claimed by a service on two links.  Services
   that are sent expected to the local relay proxy
   ([11]) (XXX how?).

   The relay proxy encapsulates the update and sends be accessed by users who type in names should
   use [13] if it to whatever
   Discovery Proxy is listening available.

   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 link; the Discovery proxy then
   either consumes process described in section 5.5.2 of [11].

   This filtering applies to queries within the update directly, or forwards homenet; it is
   appropriate for non-ULA addresses to the
   authoritative resolver be used for offering services,
   because in some cases end users may want such services to be
   reachable outside of the local service discovery zone.  If the
   registration protocol homenet.  Configuring this is not supported however out of
   scope for this document.

6.  Resolution

   Name resolution is provided by a local DNS cache or proxy on the
   homenet, henceforth the Discovery
   Proxy rejects the update with "local resolver."  All host queries are sent
   to this local resolver.  The local resolver may either act as a ??? RCODE.

3.3.  Configuring Service Discovery

   Clients discovering services using DNS-SD [6] follow full-
   service caching resolver, or as a two-step
   process.  The first step is for DNS proxy.  Its responsibility with
   respect to queries on the client device homenet is to determine in notice queries for names for
   which domain(s) to attempt to discover services.  The second step the local authoritative server is authoritative.  Queries for
   such names are handled through the client device local authoritative server.
   Queries for all other names are resolved either by forwarding them to then seek desired service(s) in those
   domain(s).  For
   an example of the second step, given the desired ISP-provided full service type "IPP Printing", and resolver, or by providing the domains "local" and
   "meeting.ietf.org", 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 client device forms basis that they are received on the queries
   "_ipp._tcp.local.  PTR ?" (resolved using Multicast DNS) and
   "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) and
   then presents local
   link.  To ensure that such registrations are actually received on
   local links in the combined list of results homenet, updates are sent to the user. local relay proxy
   ([12]) (XXX how?).

   The first step, determining in which domain(s) to attempt relay proxy encapsulates the update and sends it to discover
   services, whatever
   Discovery Proxy is performed in a variety of ways, as listening on the link; the Discovery proxy then
   either consumes the update directly, or forwards it to the
   authoritative resolver for the local service discovery zone.  If the
   registration protocol is not supported on the homenet, the Discovery
   Proxy rejects the update with a ??? RCODE.

   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.

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
   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
   services, is performed in a variety of ways, as described in
   Section 11 of the DNS-Based Service Discovery specification [6]. [7].

   The domain "local" is generally always in the set of domains in which
   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
   network environment.  For this automatic configuration discovery,
   special DNS queries are formulated.  To learn additional domain(s) in
   which to attempt to discover services, the query string
   "lb._dns_sd._udp" is prepended onto three different kinds of
   "bootstrap domain" to form DNS queries that allow the device to learn
   the configuration information.

   One of these bootstrap domains is the fixed string "local".  The
   device issues the query "lb._dns_sd._udp.local.  PTR ?" (resolved
   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
   discover services.

   Another kind of these bootstrap domains is name-based, derived from
   the DHCPv4 "domain name" option (code 15) [3] [4] (for IPv4) or the DNS
   Search List (DNSSL) Router Advertisement option [9] [10] (for IPv6).  If
   a domain in the DNSSL is "example.com", then the device issues the
   query "lb._dns_sd._udp.example.com.  PTR ?" (resolved using Unicast
   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
   services.

   Finally, the third kind of bootstrap domain is address-based, derived
   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
   configuration could be performed by having HNRs answer the
   "lb._dns_sd._udp.local.  PTR ?" (Multicast DNS) queries.  However,
   because multicast is slow and unreliable on many modern network
   technologies like Wi-Fi, we prefer to avoid using it.  Instead we
   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
   address prefix advertised on a homenet link, and every IPv6 address
   prefix advertised on a homenet link, including prefixes derived from
   the homenet's ULA(s).  Whenever the "<domain>" sequence appears in
   this section, it references each of the domains mentioned in this
   paragraph.

   Homenets advertise the availability of several browsing zones in the
   "b._dns_sd._udp.<domain>" subdomain.  By default, the 'home.arpa'
   domain is advertised.  Similarly, 'home.arpa' is advertised as the
   default browsing and service registration domain under
   "db._dns_sd._udp.<domain>", "r._dns_sd._udp.<domain>",
   "dr._dns_sd._udp.<domain>" and "lb._dns_sd._udp.<domain>".

   In order for this discovery process to work, the homenet must provide
   authoritative answers for each of the domains that might be queried.
   To do this, it provides authoritative name service for the 'ip6.arpa'
   and 'in-addr.arpa' subdomains corresponding to each of the prefixes
   advertised on the homenet.  For example, consider a homenet with the
   192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56
   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
   subdomain of in-addr.arpa.  These public authoritative zones are
   required for the public prefixes even if the prefixes are not
   delegated.  However, they need not be accessible outside of the
   homenet.

   It is out of the scope of this document to specify ISP behavior, but
   we note that ISPs have the option of securely delegating the zone, or
   providing an unsigned delegation, or providing no delegation.  Any
   delegation tree that does not include an unsigned delegation at or
   above the zone cut for the ip6.arpa reverse zone for the assigned
   prefix will fail to validate.

   Ideally, an ISP should provide a secure delegation using a zone-
   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.

3.4.  Resolution

8.  Host Configurtion

   Hosts on the homenet receive a set of local names

   By default, Local names appear as subdomains resolver IP addresses using
   either DHCP or RA.  IPv4-only hosts will receive IPv4 addresses of 'home.arpa'.  These
   names can only be resolved within
   resolvers, if available, over DHCP.  IPv6-only hosts will receive
   resolver IPv6 addresses using either stateful (if available) or
   stateless DHCPv6, or through the homenet; not only Recursive DNS Server Option ([10],
   Section 5.1) in router advertisements.

   All Homenet routers provide resolver information using both stateless
   DHCPv6 and RA; support for stateful DHCPv6 and DHCPv4 is
   'home.arpa' not optional,
   however if either service is offered, resolver addresses will be
   provided using that mechanism as well.

9.  Globally Unique Name

   Automatic configuration of a globally unique name, but queries from outside of name for the homenet is
   out of scope for any name, on or off this document.  However, homenet servers MUST allow
   the homenet, must be rejected
   with a REFUSED response.  The intended use case for local names is
   that hosts will attempt user to discover or contact other hosts on configure a globally unique name in place of the default
   name, 'home.arpa.'  By default, even if configured with a global
   name, homenet that are offering services.

   In addition, names routers MUST NOT answer queries from outside of devices on the
   homenet can appear in the
   resource records of names that are for subdomains of the locally-served
   'in-addr.arpa' or 'ip6.arpa zone that corresponding to name.

10.  DNSSEC Validation

   DNSSEC Validation for the RFC1918
   IPv4 prefix 'home.arpa' zone and for the IPv6 ULA that locally-served
   'ip6.arpa and 'in-adr.arpa' domains 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 without a trust
   anchor.  Establishment of [10].

   This filtering applies to queries within the homenet; it is
   appropriate for non-ULA addresses to be used a trust anchor for offering services,
   because in some cases end users may want such services to be
   reachable outside of the homenet.  Configuring this validation 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

   Homenets that have been configured with a way to name globally unique domain MUST
   support DNSSEC signing of 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 names, and must provide a single query for way to
   generate a particular service will KSK that can be
   successful used in providing the information required to access that
   service, regardless secure delegation of the link it is on.

   Artificial link names will be generated using HNCP.  These should
   only be visible
   globally unique domain assigned to the user in graphical user interfaces in homenet.

11.  Support for Multiple Provisioning Domains

   Homenets must support the event
   that Multiple Provisioning Domain Architecture
   [9].  Hosts connected to the same name is claimed by a service on two links.  Services homenet may or may not support multiple
   provisioning domains.  For hosts that are expected to be accessed by users who type in names should
   use [12] if it is available.

   Homenets are do 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 multiple
   provisioning domains, the
   split hybrid proxy [11].  This enables a Homenet with homenet provides one or more
   Homenet routers resolvers that provide a stateful registration cache to allow
   those routers to take over service, using Discovery Relays
   will answer queries for any provisioning domain.  Such hosts may
   receive answers to service
   links queries that are connected using Homenet routers with more limited
   functionality.

3.5.  Globally Unique Name

   Automatic configuration of a globally unique name for the homenet is
   out of scope for this document.  However, homenet servers MUST allow either do not work as well if the user to configure
   host chooses a globally unique name in place of the default
   name, 'home.arpa.'  By default, even if configured with a global
   name, homenet routers MUST NOT answer queries from outside of the
   homenet for subdomains of that name.

3.6.  DNSSEC Validation

   DNSSEC Validation for the 'home.arpa' zone and for the locally-served
   'ip6.arpa and 'in-adr.arpa' domains is not possible without a trust
   anchor.  Establishment of a trust anchor for such validation is out
   of scope for this document.

   Homenets that have been configured with a globally unique domain MUST
   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
   globally unique domain assigned to the homenet.

3.7.  Support for Multiple Provisioning Domains

   Homenets must support the Multiple Provisioning Domain Architecture
   [8].  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, 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
   with one or more resolvers per provisioning domain.  Such hosts can
   use the IP address of the resolver to determine which provisioning
   domain is applicable for a particular answer.

   Each ISP has its own provisioning domain.  Because ISPs connections
   cannot be assumed to be persistent, the homenet has its own separate
   provisioning domain.

   Configuration from the IPv4 DHCP server are treated as being part of
   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
   Multiple Provisioning Domain RA option [CITE].

3.8.

12.  Using the Local Namespace While Away From Home

   This architecture does not provide a way for service discovery to be
   performed on the homenet by devices that are not directly connected
   to a link that is part of the homenet.

4.

13.  Management Considerations

   This architecture is intended to be self-healing, and should not
   require management.  That said, a great deal of debugging and
   management can be done simply using the DNS Service Discovery
   protocol.

5.

14.  Privacy Considerations

   Privacy is somewhat protected in the sense that names published on
   the homenet are only visible to devices connected to the homenet.
   This may be insufficient privacy in some cases.

   The privacy of host information on the homenet is left to hosts.
   Various mechanisms are available to hosts to ensure that tracking
   does not occur if it is not desired.  However, devices that need to
   have special permission to manage the homenet will inevitably reveal
   something about themselves when doing so.  It may be possible to use
   something like HTTP token binding [14] [15] to mitigate this risk.

6.

15.  Security Considerations

   There are some clear issues with the security model described in this
   document, which will be documented in a future version of this
   section.  A full analysis of the avenues of attack for the security
   model presented here have not yet been done, and must be done before
   the document is published.

7.

16.  IANA considerations

   No new actions are required by IANA for this document.

   Note however that this document is relying on the allocation of
   'home.arpa' described in Special Use Top Level Domain '.home.arpa'

   [15].
   [16].  This document therefore can't proceed until that allocation is
   done.  [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO
   PUBLICATION].

8.

17.  Normative References

   [1]        Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [2]        Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [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,
              <https://www.rfc-editor.org/info/rfc2132>.

   [4]

   [5]        Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [5]

   [6]        Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [6]

   [7]        Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [7]

   [8]        Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
              Weil, "IPv6 Home Networking Architecture Principles",
              RFC 7368, DOI 10.17487/RFC7368, October 2014,
              <https://www.rfc-editor.org/info/rfc7368>.

   [8]

   [9]        Anipko, D., Ed., "Multiple Provisioning Domain
              Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
              <https://www.rfc-editor.org/info/rfc7556>.

   [9]

   [10]       Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 8106, DOI 10.17487/RFC8106, March 2017,
              <https://www.rfc-editor.org/info/rfc8106>.

   [10]

   [11]       Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", draft-ietf-dnssd-hybrid-07 (work in
              progress), September 2017.

   [11]

   [12]       Cheshire, S. and T. Lemon, "Multicast DNS Discovery
              Relay", draft-sctl-dnssd-mdns-relay-01 draft-sctl-dnssd-mdns-relay-02 (work in progress),
              October
              November 2017.

   [12]

   [13]       Cheshire, S. and T. Lemon, "Service Registration Protocol
              for DNS-Based Service Discovery", draft-sctl-service-
              registration-00 (work in progress), July 2017.

   [13]

   [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.

   [14]

   [15]       Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper,
              N., and J. Hodges, "Token Binding over HTTP", draft-ietf-
              tokbind-https-10
              tokbind-https-12 (work in progress), July 2017.

   [15] January 2018.

   [16]       Pfister, P. and T. Lemon, "Special Use Domain
              'home.arpa.'", draft-ietf-homenet-dot-14 (work in
              progress), September 2017.

   [16]

   [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
   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

   Ted Lemon
   Barefoot
   Nibbhaya Consulting
   P.O. Box 958
   Brattleboro, Vermont  05301
   United States of America

   Email: mellon@fugue.com

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC H4P 2N2
   Canada

   Email: daniel.migault@ericsson.com

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014
   USA

   Phone: +1 408 974 3207
   Email: cheshire@apple.com