Path: utzoo!mnetor!uunet!husc6!hao!gatech!mcnc!decvax!ucbvax!GATEWAY.MITRE.ORG!tsuchiya
From: tsuchiya@GATEWAY.MITRE.ORG (Paul Tsuchiya)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: More than one IP (sub)network on one ethernet cable
Message-ID: <8712221618.AA13714@gateway.mitre.org>
Date: 22 Dec 87 16:18:40 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 38

Maybe I am about to say something that is obvious and that everybody
already knows, but here goes............

The purpose of subnetting (as I understand it) is to allow gateways
and separated (sub)networks to exist in what appears to be a single network
outside, therefore making routing decisions outside of the network
to not be concerned with is going on inside the network.  This does
not, however, mean that one can change the topology inside their
network without expecting some IP addresses to change, just as one
would not expect to move their host from MITRE to SRI with getting
a new IP address.

The problem is that the name-domain function apparently does not
allow other hosts to dynamically rediscover that some host has
a new IP address.  I don't know is this is an implementation problem
or a design problem, although I assume the former.

If I might indulge in a little self-promotion, the algorithms I
have been working on, which are collectively called Landmark
Routing, cause gateways to self-configure automatically, assign
addresses to gateways, and bind host "names" to those addresses in
an efficient and dynamic fashion (at least they do if my design
is correct.  We have no implementation to date, although we are
now embarking on simulation).  What this means is that hosts are
assign permanent IP addresses that NEVER change even if the host
moves, and that the Landmark Routing function automatically handles
all (landmark) address assignments.  Then assignment of IP addresses
is then purely an administrative consideration, and not a topological
one.  If this is of interest to folks, please let me know so that
I can focus my work appropriately and work towards a testbed.  I
plan some RFCs on this topic later in 1988.


_________________________________________________________________
Paul F. Tsuchiya		The MITRE Corp.
tsuchiya@gateway.mitre.org	7525 Colshire Dr.
703-883-7352			McLean, VA 22102 USA
_________________________________________________________________