Subject: RE: Stateless DNS discovery draft

From: "Bound, Jim" <[email-masked]>
Date: Wed, 1 May 2002 19:07:52 -0400

Steve,

Good analysis but something about it don't sit well. My first response is that Routers are intermediary nodes and require configuration too so have all the properties that come with that flaw.  That flaw destroys any hope for the ideal view of stateless, except on the link.  I do agree I don't want my Stereo to go to an intermediary to find my speakers with IPv6.  But thats a link.  Some intermediary had to tell my Stereo where to send a copy of whats playing on my Stereo to my truck CD changer for a copy over 802.11 in the garage, cause in my domain the garage is on a different network Access Point.  And my domain required management to be set up the way I personally want it to be set up not the way the canned techno parts came to me via UPS.  I too personally want IPv6 to succeed and understand the stateless theme we all agreed to.  But I now question what we did here for "communications" to others, not the architecture.  Beginning with routers are intermediarys too. Possibl!
!
y we used stateless to broadly, and now that many are more educated about IPv6 the questions about the context is a valid discussion and part of the evolution of IPv6.  Though I wish it were not so and would not hold up parts we need in a rapidly deploying market for IPv6.

Regarding the future world of many devices I would argue will require co-habitation of the intermediary processes that are self contained in conjunction with the intermediarys that provide link and network information.  The reason is that with the exponential rate of devices IPv6 can provide and the networks, with that will come exponential uses and a complex mesh of attributes that will want to interoperate and work together.  That means management, so I see no real way around that problem it will happen when my Stereo wants to talk to my garage appliances.

My view of stateless was a reduced reliance on any permanent state information so the network could change from within the edge and the core easily or better than with IPv4 architecture.  I believe that is possible and ND proves that for me on the link. To integrate that principle with intermediarys is questionable I think, but if so then we need to agree on what defines an intermediary? The error check for speaker wires is a process that must be executed in the components and that is an intermediary all-be-it one you defined in your mail. I think you discussed it but maybe did not define it?  And the answer is yes DHCPv6 can be built as a contained process as the error check between my speakers and the stereo, simply because we used many of the principles inherent in IPv6 as we worked on the protocol.  But what it resides in will be an intermediary and even if its a router or hub or server that does routing or a router that does serving its an intermediary.  There is always a!
!
 middle guy can't get around them :---)

But my support for stateless back then was not the utopian view (not saying yours was at all either) because it makes (which you did bring out) high availability, failover, and fault-tolerance more possible.  But routers fail and if they go down any access past the link is dead.  Thats an intermediary problem?  Are we to ignore that in this abstraction because its a router?

To limit IPv6 evolution to using only routers for edge or core communications is not a wise view IMO, because we cannot assume the market will ever do the right thing from a scientific perspective.  Thats why we need WEB caches IMO too.  Not that they are a good idea, but because they are simply required to make stuff work.

But I do think using phase 1 and phase 2 of the dns-stateless spec is fine and hope we can do that or the vendors will just do it anyway, and as a vendor I support that completely.

thanks for the really good write up as always,
/jim

--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Wed, 1 May 2002 19:10:39 -0700

At 7:07 PM -0400 5/1/02, Bound, Jim wrote:
>Good analysis but something about it don't sit well. My first response is
>that Routers are intermediary nodes and require configuration too so have
>all the properties that come with that flaw.

Jim,

The pedantic answer is no, routers are not necessarily intermediaries
according to my definition of that term.  Intermediaries are entities
or sets of entities that a seeker sends *to* and/or receives *from*,
in order to acquire needed info about a target.  If those entities are
not on the same link as the sender, yes, you need routers to enable
that sending and/or receiving, but the routers themselves are not the
destination or source of the seeker-intermediary communication (unless
a router coincidentally happens to be the home of either seeker or
intermediary).

The more pragmatic answer is sure, routers are intermediaries.  If you
are going to allow seekers and targets to be on different links, you
necessarily rely on an intermediary of some sort.  The goal (for
robust plug-and-play) is simply to eliminate *unnecessary*
intermediaries, because each intermediary is a source of additional
potential failures.  For an Internet of more than one link, we
obviously need routers to enable communication; the question is
whether or not impose a requirement for *more* intermediaries that
those.

Note also that routers generally run protocols designed to maximize
fault tolerance, by allowing arbitrarily redundant topologies, by
not having single points-of-failure, and by ensuring that if a physical
path exists from A to B, then packets can be (best-efforts) delivered
from A to B.  That's generally not the case for autoconfiguration
servers.

>...my domain required management to be set up the way I personally
>want it to be set up not the way the canned techno parts came to me
>via UPS.

Fine, the IPv6 stateful autoconf option is there for those who want
to do that.  But my neighbor *does* want it to just work out-of-
the-UPS-box, and I want IPv6 to be reliably usable by all my neighbors,
not just the ones who are geeks.  (Well, here in Silicon Valley, it's
probably the case that all my neighbors are geeks, but you know what
I mean... :-)

Steve

---

From: Steve Deering <[email-masked]>
Date: Wed, 1 May 2002 19:25:22 -0700

At 7:07 PM -0400 5/1/02, Bound, Jim wrote:
>My first response is that Routers are intermediary nodes and require
>configuration too so have all the properties that come with that flaw.

One other thing: one of the reasons I've been pushing the multilink
subnet idea is to facilitate the development of plug-and-play routers
for unmanaged environments (by eliminating the need to configure
subnet prefixes on all router interfaces).

Steve

---

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

> a router coincidentally happens to be the home of either seeker or

But in comparing a router that forwards packets to a well-known
unicast/anycast/multicast address (a L3 intermediary?)
and a router with a DHCP relay (a L4+ intermediary) there
are significant similarities. The main differences seem to be:
 - a router failure in the first case can be repaired without
   telling the host application to try a different address, which may or may
   not be the case when using a L4+ intermediary.
 - there exists a routing protocol which is an efficient way to get the
   intermediaries to find the targets.

But because of routing transients when the set of targets change the L3
intermediaries will have stale information. Sure, the routing protocol
attempts to minimize that time period.

This observation leads me to believe (and I welcome discussion on this)
that whatever mechanisms is used for discovery, that if we want a high
level of availability, there is a need for an application layer failover 
mechanism.
This could be a combination of the discovery returning a list of IP addresses
to use, and the ability for the application to redo the discovery.
But solely relying on redoing the discovery will have more delay than
when there are multiple IP addresses known from the start.
Thus I wonder if the architecture here should take into account the need
for such a list of addresses to be provided.

  Erik