Subject: Re: Stateless DNS discovery draft

From: Steve Deering <[email-masked]>
Date: Wed, 1 May 2002 13:38:09 -0700

Here's another attempt to clarify the "stateless"/"serverless"/
"third-party-serverless" issue.  I'm not sure this will be any more
successful than previous attempts, but it's worth a try.  Please
excuse the pedantic tone and the excruciating level of boring detail;
a couple of folks have asked for exactly that.  Note that I am
speaking only as a working group member with a substantial personal
interest in the success of IPv6, rather than making any "official
pronouncements" as working group co-chair.

In this first part, I try to avoid using the terms stateless, server-
less, server, configuration, auto-configuration, and DHCP, because all
of those are ambiguous, evidently.  I'm also initially not talking
about DNS discovery/configuration specifically, but rather the generic
discovery/configuration problem.

Before a network entity can use the services of, or communicate with,
another network entity or set of entities, it often must obtain certain
information about that entity or set of entities, for example its
network address(es) and other parameters/properties of its service
or application.  To avoid further use of such tortured locution, let
me adopt the following terms, which I hope are sufficiently un-burdened
with overloaded semantics:

	- "seeker" is the entity that needs to acquire the information.

	- "target" is the entity or set of entities with whom the
	  seeker wishes to communicate, or that offers the service
	  the seeker wishes to use.

	- "needed info" is the information about the target needed by
	  the seeker, in order to communicate with, or use the services
	  of, the target.

There is a wide variety of possible techniques that seekers could use to
obtain the needed info, for example:

	manual-config: 
	    the seeker could be manually configured with the needed info.

	query-to-well-known-target-addr:
	    the seeker could send a query message to a well-known (i.e.,
	    compiled-in, constant) address to which the target (and
	    possibly others) listens, requesting the needed info from
	    the target.  The well-known address might be unicast,
	    anycast, multicast, or broadcast, and of global or non-
	    global scope.

	multicast-advert-from-target:
	    the target could send periodic "advertisement" messages to
	    a well-known broadcast or multicast address, to which the
	    seeker listens to learn the needed info.

	unicast-push-from-target:
	    the target could send an unsolicited unicast message to
	    the seeker, "pushing" the needed info to the seeker.

	query-to-intermediary:
	    the seeker could send a message to a third-party entity or
	    set of entities -- an "intermediary" -- requesting the
	    needed info.

	multicast-advert-from-intermediary:
	    an intermediary could send periodic "advertisement" messages
	    to a well-known broadcast or multicast address, to which
	    the seeker listens to learn the needed info about the target.

	unicast-push-from-intermediary:
	    an intermediary could send an unsolicited unicast message to
	    the seeker, "pushing" the needed info to the seeker.

	run-app-over-well-known-target-addr:
	    for some targets, for which the only needed info is a network
	    address, it may (if certain other conditions are also met)
	    be possible to simply make that address be a well-known one,
	    effectively reducing the needed info to the null set.  The
	    seeker would simply send its service requests or other
	    target-specific communication to that well-known address.

I'm sure this isn't a complete list; if I left out a known technique,
please let me know.

<begin digression>

    Note that more than one technique may be employed for a given target.
    For example, in IPv6 Neighbor Discovery, a host learns the "needed
    info" to use the IP forwarding service of routers both by query-to-
    well-known-target-addr, i.e., sending router solicitations to the
    link-local, all-routers multicast address, and by multicast-advert-
    from-target, i.e., listening for router advertisements on the
    link-local, all-nodes multicast address.

    For the techniques that employ intermediaries, there arises the
    question:

	Q1: How does the intermediary obtain the needed info about the
	    target, in order to provide it to seekers?

    For query-to-intermediary, there's also the question:

	Q2: How does the seeker obtain the needed info to communicate
	    with the intermediary itself?

    For unicast-push-from-target and unicast-push-from-intermediary,
    there's the question:

	Q3: How does the target or intermediary obtain the needed info
	    to send an unsolicited "push" message to the seeker, e.g.,
	    the seeker's address?

    The answer to all those questions is: one or more choices from the
    same set of techniques listed above.  For example, in "classic" IPv4
    DHCP or BOOTP usage -- which are examples of using query-to-
    intermediary for getting needed info about a target to a seeker --
    the answers to questions Q1 and Q2 are:

	A1: the intermediary (DHCP or BOOTP server) uses manual-config
	    or query-to-intermediary or unicast-push-from-intermediary,
	    i.e., it gets the needed info from a human or another
	    intermediary, such as a "provisioning" system.

	A2: the seeker (DHCP or BOOTP client) uses run-app-over-well-
	    known-target-addr, i.e., it communicates with a DHCP or BOOT
	    server at a well-known address: the IPv4 all-ones broadcast
	    address. (A special-purpose forwarding service, in the form
	    of DHCP or BOOTP relays, enables that communication to reach
	    beyond a single link; I could further recurse here and talk
	    about how the relays get *their* needed info, but I won't).

<end of digression>

I hope and expect that IPv6 will be used in many "unmanaged" environments,
e.g., homes, small offices, vehicles, "body networks", etc., where there
is no network management or operations staff.  I also hope and expect
that IPv6 will be held to a higher standard of fault tolerance than IPv4
has been to-date, as more of our day-to-day support infrastructure
becomes dependent on IP communication, e.g., among kitchen appliances,
entertainment systems, medical devices, and so on.  Furthermore, many of
the environments in which I expect IPv6 to be used will be highly
volatile, topologically, due to ever increasing node and network mobility,
environmental challenges, lack of professional network management, and
just the sheer number of devices and communication links.  In such
unmanaged, volatile, but heavily IP-dependent environments, discovery/
configuration techniques that depend on intermediaries can have a number
of serious drawbacks, compared to alternatives:

    (1) If an intermediary is not co-resident with (i.e., on the same
	node as) the target for which it is providing needed info, a
	failure of the node holding the intermediary, or of the path
	from a seeker to the intermediary, can prevent the seeker from
	communicating with the target, even though the target and a
	path to the target are up and running.  If my home stereo
	system uses IPv6 to communicate with its speakers, I don't want
	failure of a separate "configuration server box" to prevent me
	from using my stereo (or force me to manually configure my
	stereo with the IPv6 addresses of the speakers), if that can
	be avoided.

	Note that even a co-resident intermediary can fail independently
	of the target, a hazard that can be reduced or eliminated by
	building the intermediary into the target process itself, at
	which point it is no longer an intermediary.  However, a careful
	implementation of a co-resident intermediary service that, for
	example, uses a watchdog timer to restart an intermediary process
	if it fails, would probably suffice, if complete elimination
	of the intermediary is not possible for some reason.

    (2) If the way an intermediary obtains the needed info to hand
	out to seekers is via manual configuration, or via other
	intermediaries that are themselves manually configured, that
	creates the hazard that the configured info may be out-of-synch
	with reality.  When that happens, the intermediary might tell a
	seeker to use a target that is no longer up, is no longer
	reachable, or no longer exists, or it might fail to tell a
	seeker the needed info to use a valid target that does exist
	and is up and reachable.   Or another way to look at it is that
	manually-configured intermediaries impose a network management
	burden of having to update the intermediary before a new
	target can be used.  If someone buys a new gadget for their
	home network -- say, an IP barometer -- the less manual
	configuration they have to do to be able to use it, the
	better -- preferably none.

	The inconsistencies that can arise in manually-configured
	intermediaries due to temporary failures of target nodes or
	paths to target nodes, or due to decommissioned targets,
	are less onerous, in that if the target service is
	available at more than one node, and if the intermediary
	supplied the needed info for all such nodes, the seeker
	itself can find a working and reachable instance of the
	target if there is one, simply by trying them all.  However,
	that may well come at the cost of greater timeout delays and
	more network traffic than alternatives that don't entail the
	use of intermediaries.

	(And for intermediaries that do *not* obtain their needed info
	via manual configuration, but rather dynamically obtain it
	directly from the targets, e.g., using techniques like
	query-to-well-known-target-addr or multicast-advert-from-
	target, one must ask why not just have the seekers use
	those same techniques, and eliminate the unnecessary
	middlemen?)

    (3) If only a single intermediary is used to supply needed info
	to seekers of different kinds or instances of targets, and
	those different targets may reside on different nodes, it
	is not possible to make the single intermediary co-resident
	with all of them, thus causing the problem identified in
	point (1) above for at least some targets.

    (4) If in response to point (3) you then say, "OK, let's fix that
	by replicating the multi-target intermediary on all targets,"
	you now have the problem of providing each replica with a copy
	of the same needed-info "database" (assuming any replica is
	allowed and required to provide the the needed info for any
	target), but if you do that replication of the database
	manually, you have now exacerbated the problem identified in
	point (2) above.  And if the replicas each learn all the data
	automatically by polling or listening to the targets, again the
	question arises: why not just have the seekers do the polling
	or listening themselves?

Now, with *all* that preamble, I think I can finally more precisely state
what properties some of us (or, at least, I) are asking for, when we
say we want a "stateless", or "serverless", or "third-party serverless"
solution that IPv6 seekers can use for obtaining needed info about
IPv6 targets:

    We would like a solution that does not *require* the use of
    intermediaries that:

	- are non-co-resident with targets, or

	- are manually configured, or

	- employ only a single intermediary to provide needed-info about
	  multiple kinds or instances of targets, or

	- employ replicated intermediaries, any one of which is required
	  to provide the same needed-info about the same multiple kinds
	  or instances of targets.

I don't believe we are asking for the impossible, because there are a
number of solutions that don't have those properties, such as query-to-
well-known-target-addr or multicast-advert-from-target.  In this note,
I don't want to argue the relative importance of those properties vs.
other desirable properties, but am just trying to clarify what is being
referred to by the shorthand "stateless" or "serverless".

That this has sometimes been expressed imprecisely as "we don't want to
depend on DHCP" is due to that fact that DHCP, *in the way it is widely
and commonly used and understood*, is the most obvious example of --
and the obvious candidate for -- a solution that entails intermediaries
that are non-co-resident with targets, that are manually configured (or
indirectly manually configured via other intermediaries), and that
either employ a single intermediary or multiple replicated
intermediaries to provide needed info about multiple kinds or instances
of targets.

Clearly, it is possible to use DHCP-formatted messages in one of the
techniques that do not use intermediaries, and the IPv6 DNS Discovery
design team considered that as one of the many candidate solutions.
However, it is not clear to me that that's what is being proposed by
Ralph, Rob, and others who are advocating the sole use of DHCP for IPv6
DNS Discovery.  If their proposal is to:

	- run a DHCP responder built into, or co-resident with, each
	  target instance,

	- that does not have to be manually configured with information
	  about other kinds or instances of targets,

	- that responds only on behalf of its corresponding target
	  instance, and

	- that works properly if more than one such responder (for
	  different kinds of targets) reside in the same node (e.g.,
	  a seeker won't reject more than one DHCP reply from the same
	  node, thinking it's a duplicate or something),

then great, that satisfies the desirable properties listed above (as could
a number of other possible solutions, such as SLP or a pair of new ICMP
messages).  One minor issue that I did not see addressed by the DHCP-only
advocates is whether their solution would continue to use a single
well-known address for seeking info for all types of targets, or whether
different well-known addresses could be used for different target types
(e.g., one well-known multicast or anycast address for NTP config,
another one for DNS config, another for cookie-of-the-day config, etc.)
Allowing different query addresses for different services avoids
disturbing more target nodes with query traffic than necessary, which
would be important if it is going to be used in environments with
many different types of targets and very many seekers.

Though IPv6 will be used in many unmanaged environments, it will also be
used in many managed environments as well (one hopes), in which it may
be required or desired to support more complex or controlled
configuration of nodes than the simple plug-and-play/zeroconf/
"automatically find and use a nearby instance of target X" approach
supported by the automatic configuration techniques that do not depend
on intermediaries.  That's why we included support in IPv6 (specifically
in the neighbor discovery protocol) to direct nodes to a "stateful"
configuration service (read, intermediary), when that's desired by
network managers.  The configuration philosophy/goal embedded in the
IPv6 design (as I understand it, and as I have conveyed to many others
over the years of teaching tutorials about IPv6, and as I assumed was
also understood by everyone else who was involved in fleshing out that
design -- an assumption that I'm distressed to now learn is not valid) is:

	- By default, out of the box, IPv6 hosts (and someday maybe IPv6
	  routers, as well) are "plug-and-play", i.e., use robust,
	  as-close-to-zeroconf-as-possible methods of learning the
	  information they need to serve their purpose(s) on the network.
	  (For IP-layer info, this is accomplished by so-called stateless
	  address autoconf and other parts of the IPv6 neighbor discovery
	  protocol.)

	- For environments where network management wants to override
	  the default plug-and-play behavior, there is a mechanism for
	  the network manager to interpose an intermediary in the
	  configuration process.  (This is accomplished by having the
	  two bits in the router advertisement messages that tell hosts
	  to use use a "stateful" configuration service for getting
	  their own addresses and other needed info, respectively.)

	- For cases where neither the default plug-and-play behavior nor
	  the intermediary-provided service yields the desired result,
	  their is a mechanism for a node administrator to override both
	  (i.e., manual configuration of the node itself).

I think we should declare that DHCP is the protocol to use to invoke
the services of the "stateful" configuration service.  At the time the
"use-stateful" bits were defined, we thought it was conceivable that
DHCP might be superceded by a newer intermediary-based configuration
service, but that hasn't happened, and in any case, we clearly can't
use any intermediary until we define what protocol to use to talk to
that intermediary, and DHCP is the obvious choice.

As to what technique to use for robust plug-and-play autoconfiguration,
intermediary-free-DHCP would be one candidate, as would SLP, ICMP
extensions, etc.  For those targets that can satisfy the conditions
required to use the run-app-over-well-known-target-addr technique
(i.e., only needed info is an address, any replica of the target will
do, no more than one packet needed in each direction to invoke the
service), that might be the best choice, because it eliminates
unnecessary code in those target's implementations and reduces the
number of packet exchanges required to use the target.

Which brings me at last to *DNS* Discovery.  I believe that DNS servers,
as targets, satisfy the requirements needed to use the run-app-over-
well-known-target-addr, and that indeed is the current "phase 1"
proposal from the DNS Discovery design team.  This is not "inventing
yet another configuration/discovery protocol", it is doing without any
configuration/discovery protocol at all, because the needed config info
has been reduced to the null set.  (Or another view is that it is
taking advantage of the "discovery protocol" that is built into every
IP routing protocol.)

I think the "phase 2" info (default domain name, search list ) is not
information "about the target" -- which has been the subject of this essay
-- but rather information specific to the seeker, as has been pointed out
by others on this list.  For many hosts, especially in unmanaged
environments, that info is not needed at all, or is part of the
"personalization" that users normally do with their own devices (PC,
laptop, cell phone, whatever).  In a corporate environment in which
uniform search lists are desired for some reason, those environments can
use the O bit in router advertisements to tell hosts to use intermediary-
based DHCP, and get it that way.

If you've read this far, you must be a real glutton for punishment, so
may be disappointed to know that I'm going to stop now, rather than
spiralling even deeper by observing that DNS servers are themselves
intermediaries, which it would be nice to avoid dependence on.  That'll
have to be a topic for another day.

Steve
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 May 2002 16:16:41 +0200 (CEST)

Steve,

I think this is a very good writeup, but it's missing
the security considerations section :-)/2

Thinking for 5 minutes about intermediaries vs. not and security
it isn't obvious to me that one is better than the other.
A few points:
 - A solution with an intermediary requires on the order of N + M trust
   relationships for N clients and M services. A solution without requires
   N * M. Are there fundamental differences in how to do key management in
   the two cases?
 - An intermediary would imply putting all the security eggs in one basket.

I think it is important to think about this some more. While the devices
in a single home can rely on physical security combined with firewalls
I think the fact that folks are talking about DNS discovery as 
reaching from the home networks into the ISP means that we need to
take security a bit more seriously in this space.

  Erik