Subject: Re: [homenet] I-D Action: draft-ietf-homenet-simple-naming-03.txt

From: Daniel Migault <[email-masked]>
Date: Tue, 6 Nov 2018 01:36:07 -0500

Hi,

Please find my comments of the dratf.

Yours
Daniel

           Homenet Naming and Service Discovery Architecture
                  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 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

Lemon, et al.            Expires April 26, 2019                 [Page 1]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Managed LAN versus Homenet  . . . . . . . . . . . . . . .   4
       2.1.1.  Multiple Provisioning Domains . . . . . . . . . . . .   5
     2.2.  Homenet-specific considerations . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Name  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Authority . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Reachability  . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Link Names  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Authoritative name service for the homenet domain . . . .   9
     5.4.  Authoritative name service for per-link subdomains of the
           homenet domain  . . . . . . . . . . . . . . . . . . . . .  10
     5.5.  Authoritative name service for the ULA reverse mapping
           domain  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.6.  Authoritative name service for the RFC1918 reverse
           mapping domains . . . . . . . . . . . . . . . . . . . . .  10
   6.  Resolution  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Round Robining  . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Retransmission  . . . . . . . . . . . . . . . . . . . . .  13
     6.3.  DNS Stateful Operations and DNS Push  . . . . . . . . . .  13
     6.4.  Multicast DNS . . . . . . . . . . . . . . . . . . . . . .  14
     6.5.  Host behavior . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Publication . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  DNSSD Service Registration Protocol . . . . . . . . . . .  14
     7.2.  Homenet Reverse Mapping Update Protocol . . . . . . . . .  15
       7.2.1.  Adding ULA reverse mappings . . . . . . . . . . . . .  15
       7.2.2.  Adding RFC1918 reverse mappings . . . . . . . . . . .  16
   8.  Host Configuration  . . . . . . . . . . . . . . . . . . . . .  16
   9.  Globally Unique Names . . . . . . . . . . . . . . . . . . . .  16
   10. DNSSEC Validation . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  How trust is established . . . . . . . . . . . . . . . .  17
   11. Homenet Delegation Registration Protocol  . . . . . . . . . .  18
   12. Using the Local Namespace While Away From Home  . . . . . . .  19
   13. Expected Host Behavior  . . . . . . . . . . . . . . . . . . .  19
   14. Management Considerations . . . . . . . . . . . . . . . . . .  19
   15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  20
   16. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   17. IANA considerations . . . . . . . . . . . . . . . . . . . . .  20
     17.1.  Homenet Reverse Registration Protocol  . . . . . . . . .  20
     17.2.  Homenet Delegation Registration Protocol . . . . . . . .  20
     17.3.  Unique Local Address Reserved Documentation Prefix . . .  21

Lemon, et al.            Expires April 26, 2019                 [Page 2]

Internet-Draft           Homenet Naming/SD Arch             October 2018

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

<mglt>
In my opinion, the assumption on the end user is a bit too strong. I
would rather say they may not be knowledgeable. In addition,
independently of the level of knowledge, we all appreciate that tings
wok out of the box. I would thus also soften the "no operator
intervention" to "reduced operator intervention".

This is a general statement and from this general statement, the goal of
our draft is too provide a way to configure the home network with NO
operator intervention. The naming architecture achieving this goal is
designated as the simple naming architecture. The downside may be that
we come with less flexibility, but this flexibility is expected to be
addressed either by device specific GUIs or be addressed in a future
document.
</mglt>

   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.

<mglt>
I my opinion the text above is clear an fine.
</mglt>

2.  Requirements

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

<mglt>
I believe the list is composed of heterogeneous elements. I would maybe
split the list into subsists. I believe that would help the reader to
structure the architecture.
</mglt>

   o  Name: a forward domain under which information about local
      services will be published
<mglt>
I am not sure forward domain is very clear for everyone. In addition in
a context of homenet Name may also be associated to the homenet domain.
I am wondering if hostname  would not be clearer even though it may
designate services. In any case, I believe that more explanation's
needed here to help the reader not misinterpreting.

Maybe we could also define a Reverse Homenet Domain as well.
</mglt>
   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
<mglt>
I believe the intention of Authority, Resolution, Publication is to
provide a high level of the functionality that are needed. I believe
thus that these should be clearly indicated as functions, so we can
refer to them later in the document.

The one piece I guess might be confusing is that zone handling requires
some manual configuration, which has been mentioned as out-of-scope of
the draft. My understanding of the simple naming architecture is also
that there is no authoritative servers with zones. We should clarify how
the document specifically considers this function.

This is actually a general comment of the document I have. We are
focused on the simple naming architecture which is minimal. As it is
expected to be minimalist, we sometime expose why one of the other
functionality is not provided. Such explanations are I believe useful,
but state that we expect other functionalities to become very common
(authoritative servers, brokers for example). There are also some
functions mentioned as optional. As a result, I believe the message for
an implementer may be unclear.

While the discussions are useful for understanding I believe it would
help to clarify those discussions with figures, and summarizing clearly
what is in scope of the simple homenet architecture.

Similarly, it would be clarifying to define the functions that HNR need
to implement.
</mglt>

   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

Lemon, et al.            Expires April 26, 2019                 [Page 3]

Internet-Draft           Homenet Naming/SD Arch             October 2018

      *  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
<mglt>

I am reading caching resolver as the Resolution defined above. If that
is correct, I believe we should use the terminology we defined above.

</mglt>

      *  information about how services on the LAN can publish
         information
<mglt>
Idem, I believe that we should clearly indicate the relation with the
Publication mechanism.
</mglt>

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

<mglt>

I am wondering whether mechanism used to  interact with the various
functions. DNS, DNSSD shoudl be specified here. It may be also good to
specify mdns is not expected to be used by the Client.

While these pieces of information are mentioned later, My impression is
that the first sections of the document may not provide a sufficient
clear global picture of the architecture, at least sufficient so that
the reader understands clearly the document structure as well as the
high level description of the architecture. In my opinion, the current
document may be missing a gradual description.
</mglt>

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.

<mglt>

I believe handling of certificates needs more explanation as TLS has
just been introduced here.

</mglt>

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

<mglt>

In my opinion the use of TLS has no relation with the trust associated
to the naming service. TLS may provide some way to mitigate a rogue
naming service.  I believe with could remove the text related to TLS.

</mglt>

   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

Lemon, et al.            Expires April 26, 2019                 [Page 4]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   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.

<mglt>
My understanding is that this might be against BCP38.
</mglt>

   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.

<mglt>

>From the sentence above, it is unclear to me if "we" designates the host
using a well known mechanism or if this designates a mechanisms that we
describe in the document.

</mglt>

2.2.  Homenet-specific considerations

<mglt>

I think the intent of this section is to provide the characteristics of
the Simple homenet architecture. However, optional configurations as
well as (minor) extensions are part of a (generic) naming architecture
or the simple naming architecture. Maybe at that level, we could split
the section with generic homenet considerations followed by a clear
focus on the simple naming architecture.

</mglt>

   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.

<mglt>

This is true for the simple naming architecture. But not for a generic
architecture. If we want to address a generic architecture, "All" may be
replaced by "as much as possible" or "Most". If we are targeting the
simple naming architecture, maybe we could specify it in the title.

</mglt>

Lemon, et al.            Expires April 26, 2019                 [Page 5]

Internet-Draft           Homenet Naming/SD Arch             October 2018

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

<mglt>
I believe that automatic resolution includes transparently. So I would
also remove the  "and to the extend ..... transparently."

</mglt>

   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.

<mglt>

The text contains two points. I am wondering whether we would like to
keep them in a single item or two items. I am fine either way.

</mglt>

   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.

<mglt>

Maybe mentioning the minimal mechanisms the host needs to implement.
This includes DNS(SEC) and DNSSD, other mechanisms are optional.

</mglt>

<mglt>

I believe we should also mention that we only care about resolution from
nodes within the homenet to names within the homenet. We do not expect
nodes from outside the homenet to reach a node inside the homenet. In my
opinion, this is an important assumption.

</mglt>

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

<mglt>
Maybe a  Homenet Naming Architecture and the Simple Homenet Naming
Architecture could be defined.
</mglt>

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

Lemon, et al.            Expires April 26, 2019                 [Page 6]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   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.

<mglt>
I am not sure that is correct, a trusted anchor would be sufficient.
</mglt>

  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.

<mglt>
I think that is "works"
</mglt>

    HNRs implementing this specification do not answer queries
   from outside the homenet;

<mglt>

My interpretation is that if HNR were responding queries from outside
the homenet these would become open resolvers. I think that is pretty
obvious this is not a common practise, thus I wool remove

</mglt>

   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.

<mglt>
It seems that the text above adds little information and could be removed.
</mglt>

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

<mglt>

I suggest we add that to enable DNSSEC a specific mechanisms needs to be
added so the KSK can be distributed within the homenet.

</mglt>

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

<mglt>

I believe that we should specify how DNSSEC resolution could be
performed her as this is a global domain. Just to keep the same
structure as the forward domains.

</mglt>

Lemon, et al.            Expires April 26, 2019                 [Page 7]

Internet-Draft           Homenet Naming/SD Arch             October 2018

5.  Authority

   There are two types of authoritative name service on the homenet.

<mglt>

I believe we should identify these authoritative name services. I am not
sure the types should emphasize on stateful, stateless versus
link-local, homenet domain.  Maybe the second one would be closer to our
document.
</mglt>

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

<mglt>
I believe a short explanation would be clarifying for the reader. I
would suggest we add something around: The zones are served by the HNR
unicast DNS with its zones automatically populated using mDNS.

If we are using stateless/stateful later I believe it would be better to
specify this service is stateless.

</mgtl>

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.

<mglt>

I believe we should provide here some additional explanation to the
reader and especially how this would work when this is stateless. There
a huge gap between the state full and stateless and I believe that would
be appropriated to provide a high level view of what is behind this.

I suggest something around:

Stateful authoritative servers are typical authoritative DNS servers.
Stateless authoritative servers are performed via Service Discorvey
Brokers that aggregate or coordinate dynamically the various Discovery
Proxies  over the various links

</mglt>

   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

<mglt>I suggest that a reference of
draft-ietf-homenet-front-end-naming-delegation-07 is added.
</mglt>

: 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.
<mglt>
I think it would be more readable if we are adding some motivations. I
propose something around:

Discovery Proxies populates zones with devices and services found on on
the link. As such collected information using mDNS is made available to
the unicast DNS. Such mechanism requires links to be assigned names. In
order to assign automatically  a domain name to the link, the simple
naming architecture selects the HNR responsible for the link using HNCP
and ensure that each HNR uniquely assigns a name to the link.

</mglt>

These names are determined using HNCP.

<mglt>

I understand HNCP selects the HNR and HNR have little collisions, in
which case, this is not exactly the name that is determined by HNCP.

</mglt>

   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.

Lemon, et al.            Expires April 26, 2019                 [Page 8]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   The HNR is named using its manufacturer name.  If, as is likely, two
   or more HNRs from the same manufacturer are present on a homenet,
   then the HNR name is made up of the manufacturer name plus as many
   hexadecimal digits as are required from the HNRs link layer addresses
   so as to disambiguate them.

   When shipping multiple HNRs as a kit, manufacturers are advised to
   arrange that each HNR has a different number in the lowest four bits
   of the link-layer address.  Manufacturers are also advised to print
   that link layer address, in full, somewhere on the outside of the HNR
   where it can be seen by the user.  Since most HNRs will have more
   than one interface, the manufacturer should be consistent in choosing
   which link-layer address is printed on the outside and used to
   identify the router.

   The name given to a link is the name of the HNR, plus a hyphen ('-'),
   plus name of the interface of that HNR that is attached to the link.
   In the event that this name must be displayed to the user, this
   should give the user enough information to figure out which link is
   being referenced.  In the event that the HNR that is providing
   authoritative service for that link changes, the link name changes.
   This should only happen if the network topology changes.

   If the appearance of a new HNR requires that the name of an existing
   HNR change, then the names of all the links managed by that existing
   HNR change to reflect the new name.

5.3.  Authoritative name service for the homenet domain

   All HNRs must be capable of providing authoritative name service for
   the homenet domain.  HNRs that provide only stateless authoritative
   service publish the information that is required for hosts to do DNS
   Service Discovery over DNS, using the local resolver as a DNSSD
   Discovery Broker.

<mglt>

I believe the relation between resolver and broker needs to be
clarified. Typically the Broker performs a kind of resolution by
coordinating all Proxies. This could be seen as a resolution. In this
case the client sends the request to the broker. On the other hand the
client could also send its query to the local resolver that forward it
to the Broker. I thing that is the latest we mean here, but we need to
elaborate a bit how the resolver knows a query is sent to the broker or
an authoritative stateful service.

</mglt>

   Some contents are required for the homenet domain, whether it is
   stateful or stateless.

   o  Every link on the homenet has a name that is a subdomain of the
      homenet domain.  The zone associated with the homenet domain
      contains a delegation for each of these subdomains.
<mglt>

This is likely to be the most common case, but this would require a
mechanism where the homenet domain name is distribute to all the HNR.

The statement is true for the simple naming architecture because we
assume that the homenet domain is statically configured as home.arpa. I
believe that the situation where HNR are using homnet domain while some
other are using the home.arpa is likely to happen.

In any case, it seems that more than a single homnet domain may be used.
I would suggest that we consider a set of homenet domain names.

</mglt >

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

The simple naming architecture only have a single homenet domain. If the
domain is limited to this case. we maybe should use home.arpa instead of
the term homenet domain. In the case a homenet domain other than
home.arpa is considered, it would be good to clarify whether home.arpa
or example.com is the default. I suspect example.com will be. That said,
both may be listed in db._dns-sd._udp. and I believe that should also be
specified.

</mglt>

   o  If DNSSD SRP is supported (that is, if stateful authoritative
      service is present), then an SRV record must be published, along

Lemon, et al.            Expires April 26, 2019                 [Page 9]

Internet-Draft           Homenet Naming/SD Arch             October 2018

      with a list of available registration zones containing exactly one
      entry, for the homenet domain ([I-D.sctl-service-registration]
      section 2).

   o  Also if DNSSD SRP is supported, then one or more A and/or AAAA
      records must be published under the name that the SRV record
      points to, which should be a single label subdomain of the homenet
      domain.

<mglt>

What may be confusing for the user is the gap between a *generic
architecture" and the simple one. Maybe the document should clearly
state what is related to the simple naming architecture and what is part
of the generic architecture. One approach could be to have a more
generic description and at the end of the sections mentioning in the
simple naming architecture this is how this is implemented.

</mglt>

   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.

<mglt>

I am not sure "must" should not be read MUST or SHOULD. I am still
wondering whether such mechanisms could not be used with HTTP.

</mglt>

5.4.  Authoritative name service for per-link subdomains of the homenet
      domain

   Per-link subdomains of the homenet domain are served by DNSSD
   Discovery Proxies.  Although these proxies generally do caching, no
   long-lived state is kept by them.  DNSSD Discovery Proxies running on
   HNRs must support DNS Stateful Operations and DNS Push.

<mglt>

This is a very editorial comment, but this section repeats things that
have already been said previously, so I believe we coudl refactor.

On the other hand, I believe that it is good to have some subsection
regarding the different authoritative servers. Thus I would suggest to
move information provided before to these sections.

I could be clarified how the zone is populated. More specifically, there
is no need to update the zone, but each devices updates the zone using
mdns.

</mglt>

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.

<mglt>

I am questioning the requirement to be stateful. If this means having a
zone file, I am not sure this is required especially regarding
draft-howard-isp-ip6rdns. In that sense we can say it is expected to be
implemented with a zone, but other alternatives may exist as well.

</mglt>
   In order to permit registration of reverse mappings in this domain,
   it must contain an SRV record for the label _homenet-rrp._tcp at the
   top level, pointing to the primary server for the domain.

<mglt>

I believe _homenet-rrp._tcp requires a bit more explanation's here. As
it is described latter, I suppose we could remove the text.

I believe this information is mostly necessary for provisioning the zone
and not for the resolution. It may also be reasonable to assume in a
simple naming architecture that the update is performed directly on the
authoritative DNS server in which case we may have a default rule saying
unless the _homenet-rrp._tcp exists updates could be performed at
prefix.in-addr.arpa. which could be resolved in a similar manner as
homenet.arpa.

</mglt>

5.6.  Authoritative name service for the RFC1918 reverse mapping domains

   If IPv4 service is being provided on the homenet, and if stateful
   name service is being provided on the homenet, then either one or
   sixteen reverse mapping zones for the RFC1918 prefix in use must be
   provided.  If more than one RFC1918 prefix is in use, reverse mapping
   zones for all such prefixes must be provided.

   Like the ULA reverse mapping zone, the RFC1918 reverse mapping zones
   must each contain an SRV record on the label _homenet-rrp._tcp at the
   top level, pointing to the name of the primary server for the zone.

   The RFC1918 reverse mapping zone contains the entire address space of
   the RFC1918 prefix that is in use on the homenet.  Section 3 of
   RFC1918 defines three prefixes that may be used.  The homenet will

Lemon, et al.            Expires April 26, 2019                [Page 10]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   use all of one of these three prefixes.  Of these, the 172.16.0.0
   prefix is subdivided on a 12-bit boundary, and therefore must be
   represented as 16 separate zones.  The 10.0.0.0/8 and 192.168.0.0/16
   prefixes are each represented as a single zone.

   The zone to be updated is therefore the 10.in-addr.arpa zone for all
   addresses in 10.0.0.0/8, and the 168.192.in-addr.arpa zone for all
   addresses in 192.168.0.0/16.  For addresses in the 172.16.0.0/12
   prefix, the zone to be updated is the subdomain of 172.in-addr.arpa
   that corresponds to bits 8-11 of the prefix: a number between 16 and
   31, inclusive.

   Also like the ULA zone, the RFC1918 reverse mapping zones contain no
   delegations: if there is a single zone, then every reverse mapping
   published for an address in the RFC1918 prefix in use on the homenet
   is published directly under this zone.  If there are sixteen zones,
   each address is published in its respective zone.  Because the zone
   172.in-addr.arpa is not available to be served locally, its locally
   served subdomains are simply served individually with no delegation.

<mglt>

I believe that individual IP addresses need to be registered. I believe
that some details should be provided here as well. If that is described
later, a reference to the section would probably help the reader.

</mglt>

6.  Resolution

   Name resolution on the homenet must accomplish two tasks: resolving
   names that are published on the homenet, and resolving names that are
   published elsewhere.  This is accomplished by providing several
   functional layers.

<mglt>

I believe that elsewhere should be more specific. The two
cases are "internal resolution" versus "Internet resolution". Where
"internet resolution" means that the name belongs to the global naming
space AND the IP address is not private. "internal resolution" means the
name is not part of the global naming space or the name is part of the
global naming space and the address is private. In most cases, the
internal view also includes the public one. Maybe a reference to the
front-end naming architecture could be useful.

Of course the text needs to be clarified, but I believe more explanation is
required.

I see some clarifying text coming after. Maybe we could  move that text up.
</mglt>

   1.  The set of caching nameservers provided by the ISP or ISPs
       through which the homenet gains access to the global internet, if
       any (homenets can operate standalone as well).

   2.  The set of stateful name servers on the homenet that are
       authoritative for the homenet domain as a whole, and for any
       reverse mapping zones that are provided by the homenet.  This
       layer is optional, and may or may not be present.  If present, it
       is provided by one or more HNRs on the homenet that support
       stateful service.

   3.  The set of stateless name servers on the homenet that are
       authoritative for the homenet domain as a whole.  These are not
       used if one or more stateful servers are present.
<mglt>
These servers have not been described.
</mglt>

   4.  The set of stateless DNSSD Discovery Proxies that are
       authoritative for each of the links in the homenet.

   5.  A DNS routing proxy.  Hereafter we refer to this as the DNS
       proxy.
<mglt>

It is the first time DNS routing proxy appears, so I believe we should
define it a bit more. Maybe it should be mentioned in the terminology
as well as in the architecture function description.
</mglt>

Lemon, et al.            Expires April 26, 2019                [Page 11]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   The reason that these are described as layers is that it's quite
   possible that all of the DNS services on the homenet might be
   provided by a single service listening on port 53;
<mglt>

I believe that a diagram with boxes, internal, external resolution,
brokers, proxies would help the reading.

</mglt>

   how the request is
   routed then depends on the question being asked.  So the services
   described as running on HNRs are treated as functional blocks which
   may be connected internally, if the question being asked can be
   answered directly by the HNR that received it, or they may be
   separate name servers running on different HNRs, if the question can
   be answered within the homenet, or it may be that the HNR receiving
   the query forwards it to an ISP caching name server.

   The routing works as follows.  When a request is received (opcode=0,
   Q/R=0), the DNS proxy looks at the owner name in the question part of
   the message.

   o  If the name is a subdomain of the homenet domain, the query is
      local.

   o  If the name is a subdomain of a locally-valid ULA reverse mapping
      domain, the query is local.

<mglt>

While I agree with the statement, the ULA is only available in the
response.

there is a need to specify how resolution of homenet devices that are
both internal and non local can be done. I guess that the way to do that
would be that internal and external. There are different views. It
should be clear that this document does not considers these, but that is
an important point to specify so future document do not miss this point.
</mglt>

   o  If the name is a subdomain of a locally valid RFC1918 reverse
      mapping zone, the query is local.

   o  If the name is a subdomain of any locally-served zone, as defined
      in Locally Served DNS Zones [localzones], but is not otherwise
      identified as local, the response is NXDOMAIN.

   o  Otherwise, the query is not local.

   Local queries are further divided.  If the query is for a link
   subdomain, the DNS proxy consults the table that maps per-link
   subdomains to the HNRs that serve them.

<mglt>

It is unclear to me how a query could match the link subdomain.
Typically, I expected that the resolver first looks at the authoritative
server of the homenet, the proxies and then at the Discovery broker that
would look at every links.

</mglt>

  Either the HNR that serves
   this link subdomain is the HNR that received the question, or not.
   If it is, then the DNS proxy passes the query directly to the local
   DNSSD Discovery Proxy.  Otherwise, it forwards the query to the DNSSD
   Discovery Proxy on the HNR that is providing Discovery Proxy service
   for that link.

   If the query is for the homenet subdomain, and stateful authoritative
   service for the homenet subdomain is present on the homenet, then
   either the HNR receiving the query provides stateful authoritative
   service, or not.  If it does, then the query is passed directly to
   the local authoritative server.  If not, then the HNR looks in the
   table of authoritative servers generated by HNCP and forwards the
   request to one of these servers.

<mglt>

>From the description above, it seems there is a translation between
example.home.arpa and example.link.home.arpa. If that is the case, i
believe that more explanation would be needed.

I also believe that illustrative examples would be welcome.
</mglt>

  Queries for the reverse mapping
   zones are handled the same way.

Lemon, et al.            Expires April 26, 2019                [Page 12]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   Otherwise, the query is examined to see if it contains an EDNS(0)
   Provisioning Domain option.  If not, it round-robined across the
   resolvers provided by each ISP in such a way that each ISP is tried
   in succession, and the same ISP is not asked the same question
   repeatedly.  If the query does contain the EDNS(0) Provisioning
   Domain option, then that option is used to select which ISP's
   resolvers are used for the round robin.

6.1.  Round Robining

   There are several cases above where there may be a choice of servers
   to which to forward queries.  It's assumed that when the query can be
   satisfied by the HNR that received it, round robining is not
   required.  If there is a specific HNR that is responsible for a
   particular link, then round robining is likewise not required.
   However, if the query is for a stateful authoritative server, and the
   HNR that received it does not provide this service, and there is more
   than one HNR on the homenet that does provide the service, the HNR
   that received the query round robins it across the available set of
   HNRs that could answer it.

   Similarly, if the query is to be sent to an ISP's resolver, and the
   ISP has provided more than one resolver, round robining is done
   across the set of resolvers provided by that ISP.  If the query is to
   be attempted at every ISP, then that is accomplished by round-
   robining in such a way that each ISP is tried in succession, rather
   than all the resolvers at one ISP, and then all the resolvers at the
   next ISP, and so on.

6.2.  Retransmission

   For queries that can't be resolved locally by the HNR that received
   them, retransmission as described in [RFC1035] is performed.

<mglt>

It seems that this section can be removed. I understand that HNR is
queried with DNS and I read the text as it uses DNS which follows the
rules of DNS. I might be missing something

</mglt>

6.3.  DNS Stateful Operations and DNS Push

   DNS proxies on HNRs are required to support DNS Stateful Operations
   and DNS Push.  When a DNS Push operation is requested on a name that
   can be satisfied by the HNR that received it, it is handled locally.
   When such an operation is requested on a name that is local to the
   homenet, but can't be satisfied by the HNR that received it, a DNS
   Stateful operation is started with the HNR that is responsible for
   it.

Lemon, et al.            Expires April 26, 2019                [Page 13]

Internet-Draft           Homenet Naming/SD Arch             October 2018

6.4.  Multicast DNS

   In addition to consulting the local resolver, hosts on the homenet
   may attempt to discover services directly using Multicast DNS.

<mglt>
This is a nit, but I believe we could also write directly what we are
willing to say, that is Hosts on the homent MUST NOT attempt discover
services using multicast DNS.

</mglt>

HNRs
   may filter out incoming Multicast DNS queries, forcing the client to
   do service discovery using the DNS protocol.  If such filtering is
   not done, the client will be able to discover services on the link to
   which it is attached, but will not be able to discover services
   elsewhere.

<mglt>
I do not see the text preventing mDNS but only restricting it to the
link - which is the case.
</mglt>

   It is believed that all currently-available hosts support DNSSD using
   the DNS protocol.  Support for mDNS on the local link is therefore
   not required.  However, if an mDNS query returns the same answer as
   the DNS protocol query, this is not expected to be a problem.

<mglt>

I believe the text should be more normative. In addition describing the
case that does not should be complemented with the cases where issues
are found. If the coexistence is tolerate, then conflict resolution
should be provided in my opinion.

I am not sure this has been stated in the draft, but it seems that we
should clearly specify that the purpose of Discovery Proxies is to
enable connectivity with legacy devices.

</mglt>

6.5.  Host behavior

   Hosts that support the RA Provisioning Domain option direct queries
   to the name server(s) of the provisioning domain they will use for
   communication using the EDNS(0) provisioning domain option.  In
   practice this means that a host that supports PvDs will keep a set of
   provisioning information for each prefix that it received from the
   router, and will either choose a prefix to use based on its own
   criteria, or will attempt to connect using every PvD at once or in
   sequence.  Answers to queries sent for a particular provisioning
   domain will only be used with source addresses for prefixes that are
   in that provisioning domain.

<mglt>

I believe we need also some text that describes how the host is expected
to have the resolver information as well as other functions necessary
for the resolution. homenet domains, broker... If the host does not need
these information this should also in my opinion be clearly stated.

</mglt>

7.  Publication

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

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

<mglt> I believe more detail should be provided here of the type of
informations.</mglt>

 DNSSD SRP does not explicitly
   support population of the reverse zone; hosts that wish to provide
   reverse mapping information must first establish their hostname using
   DNSSD SRP; once established, the key used to authenticate the DNSSD
   SRP update is also used to update the reverse name.

<mglt>
I believe the explanation should be a little more explicit and the
binding. It would be good to expose how the key is generated with SRP as
well as how the reverse dns can check the same key is being used i.e
SIG(0)).

In my opinion the text would better fit at the next section. It seems
that the text is being repeated.

</mglt>

   Support for SRP provides several advantages over DNSSD Discovery
   Proxy.  First, DNSSD SRP provides a secure way of claiming service
   names.  Second, a claimed name is valid for the entire network

Lemon, et al.            Expires April 26, 2019                [Page 14]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   covered by the SRP service, not just an individual link, as is the
   case with 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 DNSSD SRP service is not sufficient to achieve full
   deployment of DNSSD SRP: it is also necessary that services advertise
   using DNSSD SRP.  Requiring such support is out of scope for this
   document; our goal is simply to specify a way in which DNSSD SRP can
   be supported on homenets, so that that as adoption of SRP increases
   on devices providing service, it can actually be used.

<mglt>
In my opinion this text should be in the introduction of section 7.
</mglt>

7.2.  Homenet Reverse Mapping Update Protocol

   This is an extension to the DNSSD Service Registration protocol.  The
   purpose is to allow for updates of reverse mappings.  Hosts wishing
   to publish reverse mappings first publish their hostname using DNSSD
   SRP.  When this process has successfully completed, the host can add
   reverse mappings to the ULA reverse mapping domain and to the RFC1918
   reverse mapping domain, if present.

7.2.1.  Adding ULA reverse mappings

   The host first determines the ULA prefix.  If there is more than one
   ULA prefix active, the ULA prefix with the 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
   the first 48 bits of the advertised prefix or the IP address in that
   prefix.

   Because the ULA reverse mapping zone contains no delegations, all
   updates go to that one zone.  To determine where to send the updates,
   the host first queries the SRV record under the label _homenet-
   rrp._tcp at the top of the ULA reverse mapping zone.  It then uses
   the name contained in the SRV record to look up A and/or AAAA records
   to which to send the update.

   The update is then signed using SIG(0) with the key that was used for
   the DNSSD SRP registration.  The update is then sent using DNS Update
   [RFC2136] to one of the IP addresses received during the A/AAAA
   resolution step.  The update is sent using TCP; if a TCP connection
   to one of the addresses fails, each subsequent address is tried in
   succession; if none of the addresses is reachable, the update fails,
   and may be retried after a reasonable period (on the order of an
   hour) has elapsed.

Lemon, et al.            Expires April 26, 2019                [Page 15]

Internet-Draft           Homenet Naming/SD Arch             October 2018

7.2.2.  Adding RFC1918 reverse mappings

   RFC1918 reverse mapping updates use the same mechanism as ULA reverse
   mapping updates.  The host must first determine which zone to update,
   as described earlier in Section 5.6.  Once the zone has been
   determined, the reverse mapping is updated as described in
   Section 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 link using RA, DHCPv4 or DHCPv6,
   it provides its own address.  The IPv4 address that it provides is a
   valid IPv4 address on the link to which the host is attached.  The
   IPv6 address it provides is an address in the homenet's ULA prefix
   that is valid on the link to which the host is attached.

   When sending router advertisements, the homenet includes the 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
   the homenet is connected to more than one ISP, the prefixes for each
   ISP must be advertised in different RA options.  In this case, the
   prefix for the ULA should also be sent in a separate RA.

   If the configuration received from the ISP includes a Domain Name
   (DHCPv4) or Domain Search List (DHCPv4 or DHCPv6) option, the domain
   name provided is used to identify the PvD.  In the case of Domain
   Search List options, if there is more than one, the first one is
   used.  For the ULA prefix, the homenet domain is used to identify the
   PvD.

   In order to facilitate DNSSD bootstrapping, any 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 local domain name, as descried in [RFC6763]
   section 11.

<mglt>
>From this section the authoritative server, brokers are not provided by
the configuration. I suspect these information are provided via a
resolution. This is fine as long as all queries goes to the resolver.

I suspect we also need to provide some text as some host resolver are
not in the homenet.

</mglt>

9.  Globally Unique Names

   Homenets are not required to have globally unique names.  Homenets
   operating according to this specification do not publish names in
   such a way that they can be resolved by hosts that aren't on the
   homenet.  However, such names are useful for DNSSEC validation.

   There are three ways that homenets can get global names:

   1.  They can be manually configured by the user.  How this is done is
       out of scope for this document.

Lemon, et al.            Expires April 26, 2019                [Page 16]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   2.  They can publish a delegation with the ISP, using a 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 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 host, and is therefore not practical.  Validation
   for locally-served reverse zones for the ULA and RFC1918 addresses
   would likewise require a trust anchor to be installed on the host,
   and likewise are not practical.

   If DNSSEC validation is to be done for the homenet, the homenet must
   acquire a global name, and must be provided with a secure delegation.
   Secure delegations must also be provided from the homenet domain to
   each of the per-link subdomains.

   Each HNR on a homenet generates its own private/public key pair that
   can serve as a trust anchor.  These keys are shared using HNCP
   [RFC7788].  HNRs MUST NOT use pre-installed keys: each HNR MUST
   generate its own key.  The HNR responsible for authoritative
   Discovery Proxy service on a particular link signs the zone for that
   link; delegations from the homenet domain zone to each per-link
   subdomain zone include a DS record signed by the ZSK of the homenet
   zone.

<mglt>

As DNSSEC is hardly performed by the hosts themselves, we may also
enable DNSSEC with a trusted Resolver ,and a secure session to that
resolver. The model is a bit different. For home.arpa, I see still a
bootstrapping issue, but I am wondering if that could be solved somehow.

Maybe also some additional description of how running DNSSEC in the
homenet should be discussed.
</mglt>

10.1.  How trust is established

   Every HNR has its own public/private key pair.  A DS record for each
   such public key is published in the delegation for the homenet
   domain.  If stateless authoritative service for the homenet zone is
   being provided, then each HNR signs its own homenet zone.  The signed
   zone should be very stable, although the delegations may change when
   the network topology changes.  The HNR can therefore sign the zone
   using its private key whenever it changes.  Each HNR will have a copy
   of the zone signed with a different key, but since all of the ZSKs
   are present in the DS RRset at the delegation point, validation will
   succeed.

   If stateful authoritative service is being provided, the HNR that is
   acting as primary signs the zone, and all the secondaries serve

Lemon, et al.            Expires April 26, 2019                [Page 17]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   copies acquired using zone transfers.  If the HNR that is primary
   goes away, then a secondary becomes primary and signs the zone before
   beginning to provide service.  Again, since all of the HNR's public
   keys exist in the DS RRset at the delegation, the zone can be
   validated.

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 then an ISP connection
   becomes available, the HNR that is connected to the ISP determines
   whether HDeRP is available.  This is done by first determining the
   ISP domain.

   If the connection to the ISP is IPv4-only, this will be either the
   DHCPv4 Domain Name option or, if not present, the only domain name in
   the DHCPv4 Domain Name Search List option.  If the Domain Name Search
   List option contains more than one name, HDeRP is not supported by
   the ISP.

   If the connection to the ISP is dual-stack or IPv6-only, then the
   DHCPv6 Domain Search List option obtained through DHCPv6 Prefix
   Delegation is used.  If it is not present, or if it contains more
   than one domain name, HDeRP is not supported by the ISP.

   Once the ISP domain has been discovered, the HNR looks for an SRV
   record owned by the name _homenet-derp._tcp under the ISP domain.  If
   this is not present, HDeRP is not supported.  If the SRV record is
   present, then the HNR looks for A and AAAA records on the hostname
   provided in the HNR.  If present, these are used when attempting the
   update.

   The HNR then constructs a DNS update.  The DNS update creates a
   delegation for the zone home.arpa, with a DS record for each HNR on
   the homenet, containing that HNR's public key.  The HNR doing the
   update lists its key as the first key in the DS RRset.  The update is
   signed using SIG(0) with the private key of the HNR that is
   constructing it.  As with DNSSD SRP, the update includes an Update
   Lease EDNS(0) option, specifying a key lifetime of a week.

   The HNR then attempts to connect to the hostname provided in the SRV
   record, in a round-robin fashion across the set of IP addresses
   discovered during the A/AAAA lookup phase.  When it has successfully
   connected, it sends the DNS update.

   The HDeRP server validates the update by checking the SIG(0)
   signature of the update against the first key in the DS RRset.  If

Lemon, et al.            Expires April 26, 2019                [Page 18]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   the update is successfully validated, then the server generates a
   domain name and sends a reply back to the HNR on the same TCP
   connection, including the NOERROR (0) RCODE, and including in the
   query section the actual domain name that was generated.

   This domain name then becomes the homenet name.  Subsequent updates
   use the homenet name rather than 'home.arpa'.  It is not necessary
   that the same HNR do the update; if a different HNR does the update,
   it lists its public key first in the DS RRset, and signs the update
   using its private key.

   The HDeRP is responsible for removing the delegation if it is not
   refreshed for the length of its lifetime.  HNRs should attempt to
   refresh the delegation when half the lifetime has experienced, then
   again at 5/8ths, and again at 7/8ths of the lifetime.  If the ISP
   becomes unavailable, and a different ISP becomes available that
   supports HDeRP, the homenet should migrate to the new ISP.

12.  Using the Local Namespace While Away From Home

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

Lemon, et al.            Expires April 26, 2019                [Page 19]

Internet-Draft           Homenet Naming/SD Arch             October 2018

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.

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.

17.  IANA considerations

17.1.  Homenet Reverse Registration Protocol

   IANA is requested to add a new entry to the Service Names and Port
   Numbers registry for homenet-rrp with a transport type of tcp.  No
   port number is to be assigned.  The reference should be to this
   document, and the Assignee and Contact information should reference
   the authors of this document.  The Description should be as follows:

   Availability of Homenet Reverse Registration Protocol service for a
   given domain is advertised using an SRV record with an owner name of
   "_homenet-rrp._tcp.<domain>." in that domain, which gives the target
   host and port where Homenet Reverse Registration service is provided
   for the named domain.

17.2.  Homenet Delegation Registration Protocol

   IANA is requested to add a new entry to the Service Names and Port
   Numbers registry for homenet-derp with a transport type of tcp.  No
   port number is to be assigned.  The reference should be to this
   document, and the Assignee and Contact information should reference
   the authors of this document.  The Description should be as follows:

   Availability of Homenet Delegation Registration Protocol service for
   a given domain is advertised using an SRV record with an owner name
   of "_homenet-derp._tcp.<domain>." in that domain, which gives the

Lemon, et al.            Expires April 26, 2019                [Page 20]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   target host and port where Homenet Delegation Registration service is
   provided for the named domain.

17.3.  Unique Local Address Reserved Documentation Prefix

   IANA is requested to add an entry to the IPv6 Special-Purpose Address
   Registry for the prefix fc00:2001:db8::/48.  The Name shall be
   "Unique Local Address Documentation Prefix."  The reference RFC will
   be this document, once published.  The date will be the date the
   entry was added.  All other fields will be the same as for the
   Documentation prefix, 2001:db8::/32.

18.  References

18.1.  Normative References

   [I-D.ietf-dnsop-session-signal]
              Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
              Lemon, T., and T. Pusateri, "DNS Stateful Operations",
              draft-ietf-dnsop-session-signal-16 (work in progress),
              September 2018.

   [I-D.ietf-dnssd-hybrid]
              Cheshire, S., "Discovery Proxy for Multicast DNS-Based
              Service Discovery", draft-ietf-dnssd-hybrid-08 (work in
              progress), March 2018.

   [I-D.ietf-dnssd-push]
              Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              draft-ietf-dnssd-push-15 (work in progress), September
              2018.

   [I-D.ietf-intarea-provisioning-domains]
              Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
              Shao, "Discovering Provisioning Domain Names and Data",
              draft-ietf-intarea-provisioning-domains-03 (work in
              progress), October 2018.

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

   [localzones]
              Internet Assigned Numbers Authority, "Locally-Served DNS
              Zones", n.d., <https://www.iana.org/assignments/
              locally-served-dns-zones/locally-served-dns-zones.xhtml>.

Lemon, et al.            Expires April 26, 2019                [Page 21]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   [RFC1034]  Mockapetris, P., "Domain names - 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 - implementation and
              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 the 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 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>.

Lemon, et al.            Expires April 26, 2019                [Page 22]

Internet-Draft           Homenet Naming/SD Arch             October 2018

   [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: [email-masked]

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

   Email: [email-masked]

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

   Phone: +1 408 974 3207
   Email: [email-masked]

Lemon, et al.            Expires April 26, 2019                [Page 23]

On Tue, Oct 23, 2018 at 12:36 PM <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Home Networking WG of the IETF.
>
>         Title           : Homenet Naming and Service Discovery Architecture
>         Authors         : Ted Lemon
>                           Daniel Migault
>                           Stuart Cheshire
>         Filename        : draft-ietf-homenet-simple-naming-03.txt
>         Pages           : 23
>         Date            : 2018-10-23
>
> 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.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-simple-naming/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-03
> https://datatracker.ietf.org/doc/html/draft-ietf-homenet-simple-naming-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-simple-naming-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>