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