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 EngineeringLines: 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)