Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!THUMPER.BELLCORE.COM!tsuchiya
From: tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Can subnets be separated by another net?
Message-ID: <9007121540.AA03014@chiya.bellcore.com>
Date: 12 Jul 90 15:40:41 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 50

From Bob Stewart:
> 
> Seems to me that imbedding topological meaning in an address is not
> necessarily a good idea.  That implies that as I move my portable around the
> network (from hotel to hotel, or, worse yet, on a cross country trip with a
> mobile phone), its address has to change.  We have that problem now with SLIP
> connections.  A name service could track the change so you could always reach
> me by name, but the more I move the more I have to change the name mapping,
> and such mappings usually don't appreciate being changed very much.
> 
> *I*n *M*y *H*umble *O*pinion, hierarchical administration for initial address
> assignment works nicely, such as with Domain Name Service or Ethernet global
> addresses, but should really be independent of routing.  Of course, flat
> addresses don't offer any built-in efficiencies for finding the right
> neighborhood, like IP addresses do now...
> 
> Tradeoffs, tradeoffs, always tradeoffs.  Why can't there just be a right
> answer? 
> 

Yes, tradoffs.  In my latest work, I have proposed 1) hierarchical
addresses reflecting the topological hierarchy, and 2) institutionalizing
multiple addresses to reflect, for instance, those cases where a
system is connected into the network in multiple places.  This latter
thing means that when you go to directory service or DNS, you get back
MULTIPLE ADDRESSES.  You pick one for your TCP connection (or whatever)
based on policy.  In other words, each address essentially represents
a different path, which you choose by picking an address.  I even
think that the list of valid addresses should be conveyed to the
destination by a TCP option in the call setup, and the destination
can send back in the call accept the list, possibly pruned by its
policy choices.

Well, I'm getting ahead of myself.  Anyway, what I have found is,
from a system's perspective, shoving part of the routing problem
into DNS is a GOOD tradeoff.  In general, I think we have concentrated
too much on automatic routing, and not enough on automatic address
management.  Our architecture and protocols do not take advantage of
the significant degree of freedom afforded by letting addresses be
more flexible--having multiple of them, changing them during a
transport connection, stuff like that.

Anyway, as I have said, read my paper.  It covers a lot of stuff.
Also, plan on getting sick and tired of my new-found religious
perspective.  It's been a while since I've had a soapbox to shout
from.

PT

ps.  IMHO.  I like that.