Network Working Group                                           T. Lemon
Internet-Draft                                       Nibbhaya Consulting
Intended status: Informational                                D. Migault
Expires: January 3, April 26, 2019                                         Ericsson
                                                             S. Cheshire
                                                              Apple Inc.
                                                            July 2,
                                                        October 23, 2018

        Simple

           Homenet Naming and Service Discovery Architecture
                  draft-ietf-homenet-simple-naming-02
                  draft-ietf-homenet-simple-naming-03

Abstract

   This document describes how names are published and resolved on
   homenets, and how hosts are configured to use these names to discover
   services on homenets.  It presents the complete architecture, and
   describes a simple subset of that architecture that can be used in
   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 January 3, April 26, 2019.

Copyright Notice

   Copyright (c) 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   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Managed LAN versus Homenet  . . . . . . . . . . . . . . .   4
       2.1.1.  Multiple Provisioning Domains . . . . . . . . . . . .   5
     2.2.  Homenet-specific considerations . . . . . . . . . . . . .   4   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
   4.  Name  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
   5.  Authority . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Resolution   8
     5.1.  Reachability  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Link Names  . . . . .   7
   7.  Publication . . . . . . . . . . . . . . . . . .   8
     5.3.  Authoritative name service for the homenet domain . . . .   9
     5.4.  Authoritative name service for per-link subdomains of the
           homenet domain  . . .   7
     7.1.  DNS Service Discovery Registration Protocol . . . . . . .   7
     7.2.  Configuring Service Discovery . . . . . . . . . . .  10
     5.5.  Authoritative name service for the ULA reverse mapping
           domain  . . .   8
   8.  Host Configurtion . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Globally Unique Name
     5.6.  Authoritative name service for the RFC1918 reverse
           mapping domains . . . . . . . . . . . . . . . . . . . . .  10
   10. DNSSEC Validation
   6.  Resolution  . . . . . . . . . . . . . . . . . . . . . .  10
   11. Support for Multiple Provisioning Domains . . .  11
     6.1.  Round Robining  . . . . . . .  11
   12. Using the Local Namespace While Away From Home . . . . . . .  11
   13. Management Considerations . . . . . . .  13
     6.2.  Retransmission  . . . . . . . . . . .  11
   14. Privacy Considerations . . . . . . . . . .  13
     6.3.  DNS Stateful Operations and DNS Push  . . . . . . . . .  12
   15. Security Considerations .  13
     6.4.  Multicast DNS . . . . . . . . . . . . . . . . . .  12
   16. IANA considerations . . . .  14
     6.5.  Host behavior . . . . . . . . . . . . . . . . . .  12
   17. Normative References . . . .  14
   7.  Publication . . . . . . . . . . . . . . . . .  12
   Appendix A.  Existing solutions . . . . . . . .  14
     7.1.  DNSSD Service Registration Protocol . . . . . . . . .  14
   Authors' Addresses . .  14
     7.2.  Homenet Reverse Mapping Update Protocol . . . . . . . . .  15
       7.2.1.  Adding ULA reverse mappings . . . . . . . . . . . . .  15

1.  Introduction

   This document
       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 a homenet architecture document.  The term 'homenet'
   refers to a set of technologies that 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

   This document is a homenet architecture document.  The term 'homenet'
   refers to a set of technologies that allow home network users 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 knowledgeable in network operations, so
   homenets automatically configure themselves, providing connectivity
   and service discovery within the home with no operator intervention.
   This document describes the aspect of homenet automatic configuration
   that has to do with service discovery and name resolution.

   This 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
   requirements and considerations, which should give the reader a clear
   idea of the scope of the problem being solved.  It then explains how
   each requirement is addressed, and provides references for relevant
   standards documents describing the details of the implementation.
   Not all requirements are addressed by this architecture document, but
   the basic requirements are satisfied, and this document serves as a
   foundation upon which solutions to the remaining problems can be
   built.

2.  Requirements

   Name service on a local area network (LAN) requires the following:

   o  Name: a forward domain under which information about local
      services will be published

   o  Authority: a name server that is authoritative for at least one
      forward domain and one or two reverse domains that are applicable
      to that network and is capable of signing and publishing the zones
      using DNSSEC

   o  Resolution: a full-service caching DNS resolver that fully
      supports EDNS(0) and queries with the DO bit set

   o  Publication: a mechanism that
      *  allows services on the LAN to publish information about the
         services they provide

      *  allows services to publish information on how to reach them

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

   o  Host configuration: one or more automatic mechanisms (e.g.  DHCP
      or RA) that provide:

      *  caching resolver information to 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

   A managed network is one that has a (human) manager, or operator.
   The operator has authority over the network, and the authority to
   publish names in a forward DNS tree, and reverse names in the reverse
   tree.  The operator has the authority to sign the respective trees
   with DNSSEC, and acquire TLS certificates for hosts/servers within
   the network.

   On a managed LAN, many of these services can be provided by
   operators.  When a new printer is added to the network, it can be
   added to the service discovery system (the authoritative server)
   manually.  When a printer is taken out of service, it can be removed.
   In this scenario, the role of "publisher" is filled by the network
   operator.

   In many managed LANs, establishment of trust for service discovery is
   simply on the basis of a belief that the local resolver will give a
   correct answer.  Once the service has been discovered and chosen,
   there may be some security (e.g., TLS) that protects the connection
   to the service, but the trust model is often just "you're connected
   to a network you trust, so you can trust the printer that you
   discovered on this network."

   A homenet does not have an operator, so functions that would normally
   be performed by the operator have to happen automatically.  This has
   implications for trust establishment--since there is no operator
   controlling what services are published locally, some other mechanism
   is required for basic trust establishment.

2.1.1.  Multiple Provisioning Domains

   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

   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.

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

   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.

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

   An additional requirement from the Homenet Architecture [RFC7556] is
   that hosts are not required to implement any homenet-specific
   capabilities in order to discover and access services on the homenet.
   This architecture may define optional homenet-specific features, but
   hosts that do not implement these features must work on homenets.

3.  Terminology

   This document uses the following terms and abbreviations:

   HNR  Homenet Router

   SHNR  Homenet Router implementing simple homenet naming architecture

   AHNR  Homenet Router implementing advanced homenet naming
      architecture

   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

   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.
   These domain names, together, are referred to as the "local domains."
   By default, homenets publish names for forward lookups under the
   reserved domain 'home.arpa.'  [RFC8375] publishing names.

   So a host called 'example' that published its name on the homenet
   would publish its records on the domain name 'example.home.arpa.'.
   Because 'home.arpa.' is used by all homenets, it has no global
   meaning, and names published under the domain 'home.arpa' cannot be
   used outside of the homenet on which they are published.

   How to publish names outside of the homenet is out of scope for this
   document.  However, in order to address the problem of validating
   names published on the homenet using DNSSEC, it is necessary that the
   homenet have a globally valid delegation from the root.  This allows
   hosts on the homenet to validate names published on the homenet using
   the DNS root trust anchor ([RFC4033] section 3.1).

   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
   unique local address prefix.  The reverse mapping domain for hosts on
   any link in the subnet will be a subdomain of the reverse zone for
   the subset of the ULA prefix that is being advertised on that link.
   Every service on the homenet that supports IPv6 is expected to be
   reachable at an address that is configured using the ULA prefix.
   Therefore there is no need for any IPv6 reverse zone to be populated
   other than the ULA zone.  So for example if the homenet's ULA prefix
   is 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

   There are two types of authoritative name service on the homenet.
   Every link on the homenet has a zone that is a subdomain of the
   homenet's primary domain.  Authority for these zones is local to the
   HNR that is currently authoritative for that zone.  The contents of
   these zones are served using DNSSD Discovery Proxy
   [I-D.ietf-dnssd-hybrid].  Consequently, there is no need for database
   replication in the case that a new HNR is elected; that HNR simply
   takes over the Discovery Relay function.

   Name service for the homenet domain itself may be stateless or
   stateful.  HNRs are not required to implement stateful service.  If
   one or more HNRs on the homenet are capable of providing this
   service, then one of those HNRs is elected to act as the primary
   nameserver for the homenet domain; one or more HNRs may also act as
   secondary servers.

   Name service for reverse mapping subdomains is only provided if one
   or more HNRs can provide stateful service.  If no such server is
   present, the reverse mapping subdomains are not served.  If stateful
   servers are present, the primary and secondary servers for these
   subdomains will be the same as for the homenet domain.

5.1.  Reachability

   Whether the homenet domain is a global domain name or not, HNRs
   answering queries for domains on the homenet do not respond to
   queries from off the homenet unless configured to do so.  Exposing
   services on the homenet for browsing off the homenet creates many
   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 have do DNS
   Service Discovery over DNS, using the local resolver as a local-area network (LAN) 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 more than 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 physical link and,
   optionally, more than
      entry, for the homenet domain ([I-D.sctl-service-registration]
      section 2).

   o  Also if DNSSD SRP is supported, then one internet 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 provider.  Home network
   users for per-link subdomains of the homenet
      domain

   Per-link subdomains of the homenet domain are assumed not 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 be knowledgable permit registration of reverse mappings in network operations, so
   homenets automatically configure themselves, providing connectivity
   and service discovery within this domain,
   it must contain an SRV record for the home with no operator intervention.
   This document describes label _homenet-rrp._tcp at the aspect of homenet automatic configuration
   that has
   top level, pointing to do with the primary server for the domain.

5.6.  Authoritative name service discovery for the RFC1918 reverse mapping domains

   If IPv4 service is being provided on the homenet, and if stateful
   name resolution.

   The homenet naming architecture consists of two parts: service is being provided on the simple
   naming architecture, and homenet, then either one or
   sixteen reverse mapping zones for the advanced naming architecture.  The
   advanced architecture provides approximate parity of features with a
   managed network, including 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 ability to publish services on ULA reverse mapping zone, the
   internet.  The simple architecture provides a minimal set of features
   required to enable seamless service discovery RFC1918 reverse mapping zones
   must each contain an SRV record 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
   requirements and considerations, which should give the reader a clear
   idea of label _homenet-rrp._tcp at the scope
   top level, pointing to the name of the problem being solved.  It then explains how
   each requirement is addressed, and provides references primary server for relevant
   standards documents describing the details zone.

   The RFC1918 reverse mapping zone contains the entire address space of
   the implementation.
   Some requirements are not satisfied by RFC1918 prefix that is in use on the simple architecture; homenet.  Section 3 of
   RFC1918 defines three prefixes that may be used.  The homenet will
   use all of one of these
   are discussed in this document, but explained in more detail in three prefixes.  Of these, the
   Advanced Homenet Naming Architecture document, which 172.16.0.0
   prefix is to follow.

2.  Requirements

   Name service subdivided on a local area network (LAN) requires the following:

   o  Name: a forward domain under which information about local
      services will 12-bit boundary, and therefore must be published

   o  Authority:
   represented as 16 separate zones.  The 10.0.0.0/8 and 192.168.0.0/16
   prefixes are each represented as a name server that single zone.

   The zone to be updated is authoritative therefore the 10.in-addr.arpa zone for at least one
      forward domain all
   addresses in 10.0.0.0/8, and one or two reverse domains that are applicable 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 that network and be updated is capable the subdomain of 172.in-addr.arpa
   that corresponds to bits 8-11 of signing and publishing the zones
      using DNSSEC

   o  Resolution: prefix: a full-service caching DNS resolver that fully
      supports EDNS(0) number between 16 and queries with
   31, inclusive.

   Also like the DO bit set

   o  Publication: a mechanism that

      *  allows services on ULA zone, the LAN to publish information about RFC1918 reverse mapping zones contain no
   delegations: if there is a single zone, then every reverse mapping
   published for an address in the
         services they provide

      *  allows services to publish information RFC1918 prefix in use on how to reach them

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

   o  Host configuration: one or more automatic mechanisms (e.g.  DHCP
      or RA) that provide:

      *  caching resolver information 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 hosts be served locally, its locally
   served subdomains are simply served individually with no delegation.

6.  Resolution

   Name resolution on the LAN

      *  information about how services homenet must accomplish two tasks: resolving
   names that are published on the LAN can publish
         information

   o  Trust: some basis for trusting the information homenet, and resolving names that are
   published elsewhere.  This is accomplished by providing several
   functional layers.

   1.  The set of caching nameservers provided by the service discovery system

2.1.  Managed LAN versus Homenet

   A managed network is one that has a (human) manager, ISP or operator.
   The operator has authority over the network, and ISPs
       through which the authority homenet gains access to
   publish names in a forward DNS tree, and reverse names in the reverse
   tree. global internet, if
       any (homenets can operate standalone as well).

   2.  The operator has the authority to sign set of stateful name servers on the respective trees
   with DNSSEC, and acquire TLS certificates homenet that are
       authoritative for hosts/servers within the network.

   On homenet domain as a managed LAN, many of these services can be whole, and for any
       reverse mapping zones that are 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 homenet.  This
       layer is taken out of service, it can optional, and may or may not be removed.
   In this scenario, the role of "publisher" present.  If present, it
       is filled provided by one or more HNRs on the network
   operator.

   In many managed LANs, establishment homenet that support
       stateful service.

   3.  The set of trust for service discovery is
   simply stateless name servers on the basis of a belief homenet that are
       authoritative for the local resolver will give homenet domain as a
   correct answer.  Once the service has been discovered and chosen,
   there may be some security (e.g., TLS) whole.  These are not
       used if one or more stateful servers are present.

   4.  The set of stateless DNSSD Discovery Proxies that protects the connection
   to are
       authoritative for each of the service, but links in the trust model is often just "you're connected homenet.

   5.  A DNS routing proxy.  Hereafter we refer to a network you trust, so you can trust this as the printer DNS
       proxy.

   The reason that you
   discovered these are described as layers is that it's quite
   possible that all of the DNS services on this network."

   A the homenet does not have an operator, so functions that would normally might be performed
   provided by a single service listening on port 53; how the operator have to happen automatically.  This has
   implications for trust establishment--since there request is no operator
   controlling what
   routed then depends on the question being asked.  So the services
   described as running on HNRs are published locally, some other mechanism
   is required for basic trust establishment.  Additionally, whereas in
   a managed LAN with multiple links to treated as functional blocks which
   may be connected internally, if the Internet, question being asked can be
   answered directly by the network
   operator HNR that received it, or they may be
   separate name servers running on different HNRs, if the question can configure
   be answered within the network so homenet, or it may be that multihoming the HNR receiving
   the query forwards it to an ISP caching name server.

   The routing works as follows.  When a request is handled
   seamlessly, received (opcode=0,
   Q/R=0), the DNS proxy looks at the owner name 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 question part of
   the operations mentioned here must reliably function
      automatically, without any user intervention or debugging. message.

   o  Because user intervention cannot be required, naming conflicts
      must be resolved automatically, and, to  If the name is a subdomain of the homenet domain, the extent possible,
      transparently. query is
      local.

   o  Devices that provide services must be able to publish those
      services on  If the homenet, and those services must be available from
      any part name is a subdomain of a locally-valid ULA reverse mapping
      domain, the homenet, not just query is local.

   o  If the link to which name is a subdomain of a locally valid RFC1918 reverse
      mapping zone, the device query is
      attached. local.

   o  Homenets must address  If the problem name is a subdomain of multiple provisioning
      domains, any locally-served zone, as defined
      in Locally Served DNS Zones [localzones], but is not otherwise
      identified as local, the sense that response is NXDOMAIN.

   o  Otherwise, the DNS may give a different answer
      depending on whether caching resolvers at one ISP or another query is not local.

   Local queries are
      queried.

   An additional requirement from further divided.  If the Homenet Architecture [9] query is for a link
   subdomain, the DNS proxy consults the table that
   hosts are not required to implement any homenet-specific capabilities
   in order maps per-link
   subdomains to discover and access services on the homenet.  This
   architecture may define optional homenet-specific features, but hosts HNRs that do not implement these features must work on homenets.

3.  Terminology

   This document uses serve them.  Either the following terms and 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

   In order for names to be published on a homenet, it that serves
   this link subdomain is necessary the HNR that
   there be a set of domain names under which such names are published.
   These domain names, together, are referred received the question, or not.
   If it is, then the DNS proxy passes the query directly to as the "local domains."
   By default, homenets use local
   DNSSD Discovery Proxy.  Otherwise, it forwards the query to the DNSSD
   Discovery Proxy on the reserved domain 'home.arpa.' for
   publishing names HNR that is providing Discovery Proxy service
   for forward lookups.  So a host called 'example' that published its name on link.

   If the query is for the homenet would publish its records subdomain, and stateful authoritative
   service for the homenet subdomain is present on the domain name 'example.home.arpa.'.  Because 'home.arpa.' homenet, then
   either the HNR receiving the query provides stateful authoritative
   service, or not.  If it does, then the query is used passed directly to
   the local authoritative server.  If not, then the HNR looks in the
   table of authoritative servers generated by all homenets, it has no global meaning, HNCP and names published under forwards the domain 'home.arpa' cannot be used outside
   request to one of these servers.  Queries for the homenet on which
   they reverse mapping
   zones are published.

   Homenet routers that implement advanced homenet naming may also be
   configured with a global domain.  How 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 domain is configured way that each ISP is
   out of scope for this document, tried
   in succession, and the same ISP is described in not asked the Advanced
   Homenet Naming Architecture document [advanced].

   In addition to same question
   repeatedly.  If the name, which defaults query does contain the EDNS(0) Provisioning
   Domain option, then that option is used to 'home.arpa.', names are
   needed for reverse lookups.  These names select which ISP's
   resolvers are dependent on the IP
   addressing used on the homenet.  If for the homenet is addressed with
   IPv4, round robin.

6.1.  Round Robining

   There are several cases above where there may be a reverse domain corresponding choice of servers
   to which to forward queries.  It's assumed that when the IPv4 subnet [1] section
   5.2.1 should query can be constructed.  For example, if
   satisfied by the homenet HNR that received it, round robining is not
   required.  If there is
   allocating local IP addresses out of net 10 [3], a domain, '10.in-
   addr.arpa' would be specific HNR that is responsible for a
   particular link, then round robining is likewise not required.  Like 'home.arpa.', '10.in-addr.arpa'
   However, if the query is for a locally-served zone, stateful authoritative server, and has no validity outside of the homenet.

   If
   HNR that received it does not provide this service, and there is more
   than one HNR on the homenet is addressed with IPv6, 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 expected to have a
   unique local address prefix; subsets of this prefix will be
   advertised on every link on sent to an ISP's resolver, and the homenet.  Every service on
   ISP has provided more than one resolver, round robining is done
   across the
   homenet set of resolvers provided by that supports IPv6 ISP.  If the query is expected to
   be reachable attempted at an address every ISP, then that is configured using the ULA prefix.  Therefore there accomplished by round-
   robining in such a way that each ISP is no need
   for any IPv6 reverse zone to be populated other tried in succession, rather
   than all the ULA zone.
   So for example if the homenet's ULA prefix is fd00:2001:db8::/48, resolvers at one ISP, and then all the reverse domain name for resolvers at the homenet would end
   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
   '8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa'.

5.  Authority

   The authority role [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 provided by requested on a name server that is authoritative
   for each of the local domains.  SHNRs provide authoritative service
   for to the homenet using DNSSD Discovery Broker [17].  SHNRs also
   provide Discovery Relay service [12].  On
   homenet, but can't be satisfied by the HNR that received it, a homenet DNS
   Stateful operation is started with the HNR that has only
   SHNRs, each SHNR individually provides authoritative service is responsible for
   it.

6.4.  Multicast DNS

   In addition to consulting the local resolver, hosts on the
   whole homenet by using Discovery relays
   may attempt to discover services off directly using Multicast DNS.  HNRs
   may filter out incoming Multicast DNS queries, forcing the
   local link.

   The Discovery Proxy model relies on each link having its own name.
   However, homenets client to
   do service discovery using the DNS protocol.  If such filtering is
   not actually have a way to name local links that done, the client will make any sense be able to discover services on the end user.  Consequently, this mechanism
   will not work without some tweaks.  In order link to address this,
   homenets will use Discovery Brokers [17].  The discovery broker
   which it is attached, but will not be configured so able to discover services
   elsewhere.

   It is believed that a single query all currently-available hosts support DNSSD using
   the DNS protocol.  Support for a particular service will be
   successful in providing mDNS on the information required 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 access be a problem.

6.5.  Host behavior

   Hosts that
   service, regardless support the RA Provisioning Domain option direct queries
   to the name server(s) of the link it is on.

   Artificial link names provisioning domain they will be generated use for
   communication using HNCP.  These should
   only be visible to the user in graphical user interfaces in the event 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 same name is claimed by
   router, and will either choose a service on two links.  Services
   that are expected prefix to be accessed by users who type in names should use [13] if it is available.

   It is possible that local services may offer services available based on IP
   addresses in public as well as ULA prefixes.  Homenet hybrid proxies
   MUST filter out global IP addresses, providing only ULA addresses,
   similar its own
   criteria, or will attempt to the process described connect using every PvD at once or in section 5.5.2 of [11].

   This filtering applies
   sequence.  Answers to queries within the homenet; it is
   appropriate sent for non-ULA addresses to a particular provisioning
   domain will only be used with source addresses for offering services,
   because prefixes that are
   in some cases end users may want such services to be
   reachable outside of the homenet.  Configuring this is however out of
   scope for this document.

6.  Resolution

   Name resolution is provided by a local that provisioning domain.

7.  Publication

   Names are published either using Multicast DNS cache Service Discovery
   [RFC6762] or proxy on DNSSD Service Registration Protocol
   ([I-D.sctl-service-registration]).  Reverse mappings are published
   using Homenet Reverse Mapping Update Protocol Section 7.2.

7.1.  DNSSD Service Registration Protocol

   HNRs that provide stateful authoritative service also publish
   information acquired using DNSSD Service Registration Protocol
   [I-D.sctl-service-registration].  DNSSD SRP does not explicitly
   support population of the
   homenet, henceforth reverse zone; hosts that wish to provide
   reverse mapping information must first establish their hostname using
   DNSSD SRP; once established, the "local resolver."  All host queries are sent key used to this local resolver.  The local resolver may either act as authenticate the DNSSD
   SRP update is also used to update the reverse name.

   Support for SRP provides several advantages over DNSSD Discovery
   Proxy.  First, DNSSD SRP provides a full- secure way of claiming service caching resolver, or as
   names.  Second, a DNS proxy.  Its responsibility claimed name is valid for the entire network
   covered by the SRP service, not just an individual link, as is the
   case with
   respect to queries mDNS.  Third, SRP does not use multicast, and is therefore
   more reliable on links with constrained multicast support
   [I-D.ietf-mboned-ieee802-mcast-problems].

   Support for the homenet DNSSD SRP service is not sufficient to notice queries for names for
   which the local authoritative server achieve full
   deployment of DNSSD SRP: it is authoritative.  Queries for also necessary that services advertise
   using DNSSD SRP.  Requiring such names are handled through the local authoritative server.
   Queries support is out of scope for all other names are resolved either by forwarding them this
   document; our goal is simply to
   an ISP-provided full service resolver, or by providing the full
   service resolver function locally.

7.  Publication

7.1.  DNS Service Discovery Registration Protocol

   The specify a way in which DNSSD Service Registration protocol [13] requires that DNS
   updates SRP can
   be validated supported on the basis homenets, so that they are received on the local
   link.  To ensure that such registrations are actually received as adoption of SRP increases
   on
   local links in devices providing service, it can actually be used.

7.2.  Homenet Reverse Mapping Update Protocol

   This is an extension to the homenet, DNSSD Service Registration protocol.  The
   purpose is to allow for updates are sent of reverse mappings.  Hosts wishing
   to publish reverse mappings first publish their hostname using DNSSD
   SRP.  When this process has successfully completed, the local relay proxy
   ([12]) (XXX how?).

   The relay proxy encapsulates host can add
   reverse mappings to the update ULA reverse mapping domain and sends it to whatever
   Discovery Proxy the RFC1918
   reverse mapping domain, if present.

7.2.1.  Adding ULA reverse mappings

   The host first determines the ULA prefix.  If there is listening on more than one
   ULA prefix active, the link; ULA prefix with the Discovery proxy longest preferred lifetime
   is used.  A ULA prefix can be identified because it matches the
   prefix fc00::/7 ([RFC4193] section 3.1).  The actual prefix is then
   either consumes
   the update directly, first 48 bits of the advertised prefix or forwards it to the
   authoritative resolver for IP address in that
   prefix.

   Because the local service discovery ULA reverse mapping zone contains no delegations, all
   updates go to that one zone.  If  To determine where to send the
   registration protocol is not supported on updates,
   the homenet, host first queries the Discovery
   Proxy rejects SRV record under 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 label _homenet-
   rrp._tcp at the capability top 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 ULA reverse mapping zone.  It then uses
   the
   split hybrid proxy [12].  This enables a Homenet with one or more
   Homenet routers that provide a stateful registration cache name contained in the SRV record to allow
   those routers look up A and/or AAAA records
   to take over service, using Discovery Relays which 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. send the update.

   The first step update is then signed using SIG(0) with the key that was used for
   the client device to determine in
   which domain(s) to attempt to discover services. DNSSD SRP registration.  The second step update is
   for the client device to then seek desired service(s) in those
   domain(s).  For an example sent using DNS Update
   [RFC2136] to one of the second step, given IP addresses received during the desired
   service type "IPP Printing", and A/AAAA
   resolution step.  The update is sent using TCP; if a TCP connection
   to one of the domains "local" and
   "meeting.ietf.org", addresses fails, each subsequent address is tried in
   succession; if none of the client device forms addresses is reachable, the queries
   "_ipp._tcp.local.  PTR ?" (resolved using Multicast DNS) and
   "_ipp._tcp.meeting.ietf.org PTR. ?" (resolved using Unicast DNS) update fails,
   and
   then presents may be retried after a reasonable period (on the combined list order of results to an
   hour) has elapsed.

7.2.2.  Adding RFC1918 reverse mappings

   RFC1918 reverse mapping updates use the user. same mechanism as ULA reverse
   mapping updates.  The host must first step, determining in determine which domain(s) to attempt zone to discover
   services, is performed update,
   as described earlier in a variety of ways, Section 5.6.  Once the zone has been
   determined, the reverse mapping is updated as described in
   Section 11 of 7.2.1.

8.  Host Configuration

   Each HNR provides a Homenet DNS Proxy.  When an HNR provides the DNS
   resolver IP address to hosts on the DNS-Based Service Discovery specification [7]. link using RA, DHCPv4 or DHCPv6,
   it provides its own address.  The domain "local" IPv4 address that it provides is generally always in the set of domains in which a
   valid IPv4 address on the client devices attempt link to discover services, and other domains
   for service discovery may be configured manually by which the user. host is attached.  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)
   IPv6 address it provides is an address 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 homenet's ULA prefix
   that allow is valid on the device link to learn which the configuration information.

   One of these bootstrap domains host is attached.

   When sending router advertisements, the fixed string "local".  The
   device issues homenet includes the query "lb._dns_sd._udp.local.  PTR ?" (resolved
   using Multicast DNS), and PvD ID
   RA option [I-D.ietf-intarea-provisioning-domains] in each RA.
   Because the PvD ID RA option can only be sent once per RA message, if any answers are received, then they are
   added
   the homenet is connected to more than one ISP, the set of domains prefixes for each
   ISP must be advertised in which different RA options.  In this case, the client devices attempt to
   discover services.

   Another kind of these bootstrap domains is name-based, derived
   prefix for the ULA should also be sent in a separate RA.

   If the configuration received from the DHCPv4 "domain name" option (code 15) [4] (for IPv4) ISP includes a Domain Name
   (DHCPv4) or the DNS Domain Search List (DNSSL) Router Advertisement option [10] (for IPv6).  If
   a domain in (DHCPv4 or DHCPv6) option, the DNSSL domain
   name provided 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 used to identify the set of domains in which the client devices attempt to discover
   services.

   Finally, PvD.  In the third kind case of bootstrap domain Domain
   Search List options, if there is address-based, derived
   from more than one, the device's IP address(es) themselves.  If first one is
   used.  For the device has IP
   address 192.168.1.100/24, then ULA prefix, the device issues homenet domain is used to identify the query
   "lb._dns_sd._udp.0.1.168.192.in-addr.arpa.  PTR ?" (resolved using
   Unicast DNS), and if
   PvD.

   In order to facilitate DNSSD bootstrapping, any answers are received, then they are also
   added DHCPv4, DHCPv6 or RA
   Domain Search List options contain only a single domain name, the
   homenet domain.  This allows hosts to quickly bootstrap DNS Service
   Discovery using the set of domains local domain name, as descried in which the client devices attempt [RFC6763]
   section 11.

9.  Globally Unique Names

   Homenets are not required to
   discover services.

   Since there is an HNR on every link of have globally unique names.  Homenets
   operating according to this specification do not publish names in
   such a homenet, automatic
   configuration could way that they can be performed resolved by having HNRs answer hosts that aren't on the
   "lb._dns_sd._udp.local.  PTR ?" (Multicast DNS) queries.
   homenet.  However,
   because multicast such names are useful for DNSSEC validation.

   There are three ways that homenets can get global names:

   1.  They can be manually configured by the user.  How this is slow and unreliable on many modern network
   technologies like Wi-Fi, we prefer to avoid done is
       out of scope for this document.

   2.  They can publish a delegation with the ISP, using it.  Instead we
   require that a homenet be Homenet
       Delegation Registration Protocol Section 11.

   3.  They can publish a delegation with some other provider, using
       Homenet Delegation Registration Protocol Section 11.  How this is
       configured is out of scope for this document.

   Homenets are also not required to answer the name-based
   bootstrap queries.  By default support global delegations for
   reverse mapping of global IPv4 and IPv6 addresses.  How this would be
   done is out of scope for this document.

10.  DNSSEC Validation

   DNSSEC validation for 'home.arpa' requires installing a per-homenet
   trust anchor on the domain in host, and is therefore not practical.  Validation
   for locally-served reverse zones for the DNSSL communicated ULA and RFC1918 addresses
   would likewise require a trust anchor to the client devices will be "home.arpa", installed on the host,
   and likewise are not practical.

   If DNSSEC validation is to be done for the homenet, 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
   acquire a global name, and must be
   configured provided with any valid DNSSL, and should construct the appropriate
   bootstrap queries derived a secure delegation.
   Secure delegations must also be provided from the name(s) in their configured DNS
   Search List.

   HNRs will answer homenet domain enumeration queries against every IPv4
   address prefix advertised to
   each of the per-link subdomains.

   Each HNR on a homenet link, and every IPv6 address
   prefix advertised 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 homenet link, including prefixes derived from particular link signs the homenet's ULA(s).  Whenever zone for that
   link; delegations from the "<domain>" sequence appears in
   this section, it references homenet domain zone to each of the domains mentioned in this
   paragraph.

   Homenets advertise per-link
   subdomain zone include a DS record signed by the availability ZSK of several browsing zones in the
   "b._dns_sd._udp.<domain>" subdomain.  By default, the 'home.arpa'
   domain homenet
   zone.

10.1.  How trust is advertised.  Similarly, 'home.arpa' established

   Every HNR has its own public/private key pair.  A DS record for each
   such public key is advertised as published in 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 delegation 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
   domain.  If stateless authoritative name service for the 'ip6.arpa'
   and 'in-addr.arpa' subdomains corresponding to homenet zone is
   being provided, then each of HNR signs its own homenet zone.  The signed
   zone should be very stable, although the prefixes
   advertised on delegations may change when
   the homenet.  For example, consider a homenet with network topology changes.  The HNR can therefore sign the
   192.168.1.0/24, 2001:db8:1234:5600::/56 and fc01:2345:6789:1000::/56
   prefixes.  This homenet zone
   using its private key whenever it changes.  Each HNR 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 copy
   of in-addr.arpa.  These public authoritative zones are
   required for the public prefixes even if zone signed with a different key, but since all of the prefixes ZSKs
   are not
   delegated.  However, they need not be accessible outside of present in the
   homenet.

   It DS RRset at the delegation point, validation will
   succeed.

   If stateful authoritative service is out of being provided, the scope of this document to specify ISP behavior, but
   we note HNR that ISPs have the option of securely delegating is
   acting as primary signs 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 and all the assigned
   prefix will fail to validate.

   Ideally, an ISP should provide a secure delegation secondaries serve
   copies acquired using a zone-
   signing key provided by zone transfers.  If the homenet.  However, HNR that too is out of
   scope for this document.  Therefore, an ISP that wishes to support
   users of primary
   goes away, then a secondary becomes primary and signs the simple homenet naming architecture will have zone before
   beginning to provide
   an unsigned delegation.  We do not wish, however, to discourage
   provisioning of signed delegations when that is possible.

8.  Host Configurtion

   Hosts on the homenet receive a set of resolver IP addresses using
   either DHCP or RA.  IPv4-only hosts will receive IPv4 addresses service.  Again, since all 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) HNR's public
   keys exist in router advertisements.

   All Homenet routers provide resolver information using both stateless
   DHCPv6 and RA; support for stateful DHCPv6 the DS RRset at the delegation, the zone can be
   validated.

11.  Homenet Delegation Registration Protocol

   Homenet Delegation Registration Protocol (HDeRP) operates similarly
   to DNSSD Service Registration Protocol.  When a homenet is not
   connected to an ISP that supports HDeRP, and DHCPv4 then an ISP connection
   becomes available, the HNR that is optional,
   however if either service connected to the ISP determines
   whether HDeRP is offered, resolver addresses available.  This is done by first determining the
   ISP domain.

   If the connection to the ISP is IPv4-only, this will be
   provided using that mechanism as well.

9.  Globally Unique either the
   DHCPv4 Domain Name

   Automatic configuration of a globally unique option or, if not present, the only domain name for in
   the homenet DHCPv4 Domain Name Search List option.  If the Domain Name Search
   List option contains more than one name, HDeRP is
   out of scope for this document.  However, homenet servers MUST allow not supported by
   the user ISP.

   If the connection to configure a globally unique name in place of the default
   name, 'home.arpa.'  By default, even 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 configured with a global it contains more
   than one domain name, homenet routers MUST NOT answer queries from outside of HDeRP is not supported by the
   homenet for subdomains of that name.

10.  DNSSEC Validation

   DNSSEC Validation for ISP.

   Once the 'home.arpa' zone and ISP domain has been discovered, the HNR looks for an SRV
   record owned by the locally-served
   'ip6.arpa and 'in-adr.arpa' domains name _homenet-derp._tcp under the ISP domain.  If
   this is not possible without 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 trust
   anchor.  Establishment of DNS update.  The DNS update creates a trust anchor
   delegation for the zone home.arpa, with a DS record for such validation 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 out
   signed using SIG(0) with the private key of scope for this document.

   Homenets the HNR that have been configured is
   constructing it.  As with DNSSD SRP, the update includes an Update
   Lease EDNS(0) option, specifying a globally unique domain MUST
   support DNSSEC signing key lifetime of local names, and must provide a way week.

   The HNR then attempts to
   generate a KSK that can be used connect to the hostname provided in the secure delegation of SRV
   record, in a round-robin fashion across the
   globally unique domain assigned to set of IP addresses
   discovered during the homenet.

11.  Support for Multiple Provisioning Domains

   Homenets must support A/AAAA lookup phase.  When it has successfully
   connected, it sends the Multiple Provisioning Domain Architecture
   [9].  Hosts connected to DNS update.

   The HDeRP server validates the homenet may or may not support multiple
   provisioning domains.  For hosts that do not support multiple
   provisioning domains, update by checking 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 SIG(0)
   signature of the
   host chooses a source address from a different provisioning domain,
   or does not work at all.  However, update against the default source address
   selection policy, longest-match [CITE], will result first key in the correct
   source address being chosen as long as DS RRset.  If
   the destination address has update is successfully validated, then the server generates a
   domain name and sends a
   close match reply back to the prefix assigned by HNR on the ISP.

   Hosts same TCP
   connection, including the NOERROR (0) RCODE, and including in the
   query section the actual domain name that support multiple provisioning domains will be provisioned
   with one or more resolvers per provisioning domain.  Such hosts can was generated.

   This domain name then becomes the homenet name.  Subsequent updates
   use the IP address of homenet name rather than 'home.arpa'.  It is not necessary
   that the same HNR do the resolver to determine which provisioning
   domain is applicable for update; if a particular answer.

   Each ISP has its own provisioning domain.  Because ISPs connections
   cannot be assumed to be persistent, different HNR does the homenet has update,
   it lists its own separate
   provisioning domain.

   Configuration from public key first in the IPv4 DHCP server are treated as being part of DS RRset, and signs the homenet provisioning domain. update
   using its private key.

   The case where a homenet advertises
   IPv4 addresses from one or more public prefixes HDeRP is out of scope responsible for
   this document.  Such a configuration removing the delegation if it is NOT RECOMMENDED for homenets.

   Configuration not
   refreshed for IPv6 provisioning domains is done using the
   Multiple Provisioning Domain RA option [CITE]. 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

   This architecture document does not provide specify 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.

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
   require management.  That said, a great deal of debugging and
   management can be done simply using the DNS Service Discovery
   protocol.

14.

15.  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 [15] to mitigate this risk.

15.

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

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'
   [16].  This document therefore can't proceed until that allocation is
   done.  [RFC EDITOR PLEASE REMOVE THIS PARAGRAPH PRIOR TO
   PUBLICATION].

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

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

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

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

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

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

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

   [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. 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 T. Lemon, "Service must be done before
   the document is published.

17.  IANA considerations

17.1.  Homenet Reverse Registration Protocol
              for DNS-Based

   IANA is requested to add a new entry to the Service Discovery", draft-sctl-service-
              registration-00 (work in progress), July 2017.

   [14]       Korhonen, J., Krishnan, S., Names and S. Gundavelli, "Support Port
   Numbers registry 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 homenet-rrp with a transport type of tcp.  No
   port number is to automate naming be assigned.  The reference should be to this
   document, and service discovery in the
   context Assignee and Contact information should reference
   the authors of this document.  The Description should be as follows:

   Availability of Homenet Reverse Registration Protocol service for a home network are able to function
   given domain is advertised using an SRV record with varying degrees
   of success depending on the topology an owner name of
   "_homenet-rrp._tcp.<domain>." in that domain, which gives the home network.
   Unfortunately, these solutions do not fully address the requirements
   of homenets.

   For example, Multicast DNS [6] can provide naming target
   host and port where Homenet Reverse Registration service
   discovery [7], but only within a single multicast domain.

   The Domain Name System provides a hierarchical namespace [1], a
   mechanism is provided
   for querying name servers the named domain.

17.2.  Homenet Delegation Registration Protocol

   IANA is requested to resolve names [2], a mechanism
   for updating namespaces by adding and removing names [5], and add a
   mechanism for discovering services [7].  Unfortunately, DNS provides
   no mechanism for automatically provisioning new namespaces, and
   secure updates entry to namespaces require that the host submitting the
   update have Service Names and Port
   Numbers registry for homenet-derp with a public or symmetric key that transport type of tcp.  No
   port number is known to be assigned.  The reference should be to this
   document, and the network Assignee and authorized for updates.  In an unmanaged network, Contact information should reference
   the publication authors of and authorization this document.  The Description should be as follows:

   Availability of these keys Homenet Delegation Registration Protocol service for
   a given domain is advertised using an unsolved problem.

   Some managed networks get around this problem by having SRV record with an owner name
   of "_homenet-derp._tcp.<domain>." in that domain, which gives 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
   target host and AAAA records.

   This partially solves port where Homenet Delegation Registration service is
   provided for the trust problem: DHCP can validate that a
   device named domain.

17.3.  Unique Local Address Reserved Documentation Prefix

   IANA is at least connected requested to a network link that is actually part
   of the managed network.  This prevents add an off-network attacker from
   registering a name, but provides no mechanism entry to the IPv6 Special-Purpose Address
   Registry for actually validating the identity of 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 host registering date the name.  For example, it would
   entry was added.  All other fields will be easy the same as for an attacker on the network to steal a registered name.

   Hybrid Multicast DNS [11] proposes a mechanism
   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 extending
   multicast DNS beyond a single multicast domain.  However, Multicast DNS-Based
              Service Discovery", draft-ietf-dnssd-hybrid-08 (work 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
              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
   for every multicast domain.  These - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names would then be revealed to
   the end user.  But since they would be generated automatically - implementation and
   arbitrarily, they would likely cause confusion rather than clarity,
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

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

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

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

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

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for devices that do not implement the registration protocol. Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <https://www.rfc-editor.org/info/rfc7336>.

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

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC8375]  Pfister, P. and T. Lemon, "Special-Use Domain
              'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
              <https://www.rfc-editor.org/info/rfc8375>.

18.2.  Informative References

   [I-D.ietf-mboned-ieee802-mcast-problems]
              Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
              Zuniga, "Multicast Considerations over IEEE 802 Wireless
              Media", draft-ietf-mboned-ieee802-mcast-problems-02 (work
              in progress), August 2018.

Authors' Addresses

   Ted Lemon
   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