Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucsbcsl!hydra!aks
From: aks@hydra.ucsb.edu ( )
Newsgroups: comp.protocols.appletalk
Subject: Re: KIP/K-Star
Summary: Complaint with KIP and K-Star
Keywords: IP SUBNET LOCALTALK KSTART KIP
Message-ID: <858@hub.ucsb.edu>
Date: 20 Sep 88 08:13:51 GMT
Expires: 31 Dec 88 08:00:00 GMT
Sender: news@hub.ucsb.edu
Reply-To: aks@hub.ucsb.edu (Alan Stebbens)
Organization: Center for Computational Sciences and Engineering 
Lines: 74

I would like to understand why (apparently both) KIP and K-Star do not
support the ability to treat the Localtalk network as an IP subnet AND
provide the directed, encapsulated IP feature?  It seems that you can
treat the Localtalk network as an IP subnet, while not having the
capability of encapsulating Localtalk packets and directing them to
another Kbox across a router, *or* you can treat the Localtalk network
as an extension of the SAME subnet on which the Kbox resides (with
either static or dynamic, serialized IP address assignment), while
obtaining encapsulated Localtalk packets.  Is this a correct assesment? 

Here's a grahic example of a small piece of our network:

		     Enet 254
	       ------------------------
		 | 		|
		[gw]           [gw]
		 |       	|
	         |           ---------
		 |              |
	         |	       [gw]
         ENet 24 |	ENet 88 |
	    --------	    ---------
		|		  |
	     [Kbox1]           [Kbox2]
		|		  |
	   ==========        ===========
	   |  |  |	      |   |   |
	 Mac Mac LW	     Mac Mac  LW

As you can see, Kbox1 and KBox2 are seperated by several gateways and
subnets; also, (it's not evident but) Enet 24 is very crowded -- we
don't want the Mac's in ATNet 26 to be part of ENet 24 -- our host
address are named, centrally administrated and statically allocated. 
Similarly, the Macs in ATNet 90 do not really need to be in ENet 88. 
Yet, if we want to make the two Zones "see" each other, we must run the
KIP or KStart software which doesn't allow the two modes to mix.  Or am
I wrong (I hope, I hope)? 

You see, if you are trying to fit one or more potentially large
Localtalk networks into some fairly well-occupied subnets, it is very
difficult to find blocks of sequential addresses to assign to each
Localtalk network.  Moreover, once you accomplish this, it becomes very
difficult to then later expand the Localtalk networks with more IP
addresses.  To me, the ideal would be to have each Localtalk network
treated as a subnet, with its own host address range, yet also very
desireable to be able to direct encapsulated Localtalk packets to
another Kbox. 

I realize there is a "klugey" way of accomplishing my goals: I can use ARP
subnetting, which is where a gateway (or host running "proxyarp") is
defined with multiple interface addresses, such that the same physical
media is carrying two subnets, thus logically separating the machines.  It
is true that I have done this with one of our Localtalk networks, in order
to "test" the KStar software, which we seem to have running sucessfully.
However, I do not find it at all desireable to continue this practice, nor
can I really recommend it to other campus departments as they may not have
gateways as configurable as ours, nor proxyarp, nor have the technical
expertise to keep it running happily.  I would really like to have both
features.

Does anyone else consider this to be a problem also?  Does anyone know if
there is a "fix" planned, or knows how one can be made?  I can hack the
code myself, if given a pointer.

Thanks for any sympathy or advice.

Alan Stebbens
Manager, CCSE
University of California, Santa Barbara
ARPA: aks@hub.ucsb.edu
UUCP: ucbvax!ucsbcsl!aks
805-961-3221

Alan Stebbens (aks@hub.ucsb.edu)