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

Reply via email to