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.