Path: utzoo!attcan!uunet!lll-winken!lll-lcc!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!CSLI.STANFORD.EDU!croft From: croft@CSLI.STANFORD.EDU Newsgroups: comp.protocols.appletalk Subject: Re: Please explain this KIP behavior Message-ID:Date: 13 Jul 88 19:16:11 GMT References: <4137@ut-emx.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 Don, KIP doesnt really have any subnet assumptions built into it. That is why there is no subnet mask in the conf data. (It could use a subnet mask for routing purposes, instead of depending on proxy ARP, but that is another issue.) For your situation, it sounds like the 'H' line is the way to go, pointing to a UNIX host running the redirector (atalkrd). I dont understand why this didnt work for you. If you use any type of 'N' line, there WILL be storms of some sort because you say you have a mixture of 4.2 and 4.3 style hosts. The only way around this at present is the 'H' hack with a redirector pointing to the specific hosts running CAP (dont tell the redirector to broadcast). Another 'minor' point you have to worry about with an unsubnetted class B net: You can only reach 254 CAP hosts in one contiguous area of your entire class B allocation. For example, if you setup an H line pointing to 128.83.1.33 (emx.utexas.edu), then you can only reach with CAP, hosts numbered 128.83.1.1 thru 128.83.1.254. This is because the appletalk net/host number (16 and 8 bits respectively) maps rather simplemindedly into an IP net/host number (32 bits of IP number, with the lower 8 bits being the host number). It doesnt make any difference whether you use 'N' or 'H', you still only get 254 appletalk hosts per appletalk net number. As you surely know, this is a limitation of ethertalk as well.