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.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
