[homenet] Introduction to draft-ietf-homenet-simple-naming

[Ted Lemon <[e-mail]>]

The chairs requested that we have a discussion on this draft on the mailing
list.   I've been a bit slack in bringing it up, as you can tell from the
lack of any actual discussion.   So, I'm bringing it up.   I've copied the
abstract, introduction and requirements sections to the message below.
It's a pretty quick read.   Please read it and try to notice anything
that's missing, or that shouldn't be there, or that is just plain wrong.
If it looks fine, it would be great if you could just reply to say "it
looks fine."   If all goes well, we'll move on to the next section next
week.

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.

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

   The homenet naming architecture consists of two parts: the simple
   naming architecture, and the advanced naming architecture.  The
   advanced architecture provides approximate parity of features with a
   managed network, including the ability to publish services on the
   internet.  The simple architecture provides a minimal set of features
   required to enable seamless service discovery on a multi-link home
   network, but does not attempt to provide feature parity with a
   managed LAN.

   This document begins by presenting a motivational list of
   requirements and considerations, which should give the reader a clear
   idea of the scope of the problem being solved.  It then explains how
   each requirement is addressed, and provides references for relevant
   standards documents describing the details of the implementation.
   Some requirements are not satisfied by the simple architecture; these
   are discussed in this document, but explained in more detail in the
   Advanced Homenet Naming Architecture document, which is to follow.

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 a
      forward and one or two reverse domains that are applicable to that
      network

   o  Resolution: a full-service caching DNS resolver

   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

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

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

   A homenet does not have an operator, so functions that would normally
   be performed by the operator have to happen automatically.  This has
   implications for trust establishment--since there is no operator
   controlling what services are published locally, some other mechanism
   is required for basic trust establishment.  Additionally, whereas in
   a managed LAN with multiple links to the Internet, the network
   operator can configure the network so that multihoming is handled
   seamlessly, in a homenet, multihoming must be handled using multiple
   provisioning domains [RFC7556].

2.2.  Homenet-specific considerations

   A naming architecture for homenets therefore adds the following
   considerations:

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