tom@wcc.oz (Tom Evans) (10/10/90)
In article <9010022010.AA20602@fourcroy.chem.wayne.edu>, rvg@chem.wayne.edu (Rahul V. Garg) writes: > > A basic doubt while trying to install CAP with KFPS-4. > Does CAP use Appletalk Phase I protocols? > And should you try and use atalkad and the remote host option > to load the IP configuration? Yes. Sort of. Ummm. Notice how Phase 2 didn't seem to affect your LocalTalk-connected Macs at all? Thet's because it didn't. Phase 2 includes the concepts of "extended" and "non-extended" networks. An "extended" one is a network that can use the new features, notably the network-range and zone-list stuff. All EtherTalk Phase 2 networks are extended. Likewise TokenTalk. LocalTalk is non-extended and hasn't changed. As well, Phase 2 doesn't affect "hosts" on non-extended networks, although it does affect "routers", nomatter where they are. Routers need to run Phase 2, be they on extended or non-extended networks. Phase 2 does affect Macs on Ethernet as EtherTalk Phase 2 uses a different Ethernet packet format, as well as the requirement for the Macs to perform different network and zone functions. Note that since Phase 1 and Phase 2 EtherTalk are different protocols, it is possible to run them both on the same Ethernet, with one (or more) of the routers connecting to both of these different "networks", and routing packets between them. This is "compatability" or "upgrade" mode, and requires all extended networks to not use the extended functions. In the same manner, an IPTalk network is just another protocol with a unique AppleTalk network number on the SAME Ethernet cable as EtherTalk - Phase 1, 2 or both. It is best to think of them as separate networks, and especially to draw them as such. Consider your ethernet cable as a separable bundle of networks/protocols. The protocol used by CAP - "IPTalk" is used for two separate functions. Firstly, it is used to connect an "IPTalk-host", probably better called a "CAP-host" (i.e. a TCP/IP host running CAP) to an AppleTalk internet. Secondly, it may be used to transport (or "tunnel") AppleTalk packets through an IP network (including through IP routers) from one AppleTalk internet to another AppleTalk internet. If you are using the "hosting" function, and the CAP-host is on the same IP network as the IPTalk router (kbox or whatever), then you don't need atalkad/atalkatab - just hard-configure the box (and the CAP-host - the atalk.local file) correctly. If you are using the "transport" function, and this includes the case where the "hosting" function is being used, but the CAP-host is on a different IP network to the IPTalk router, then atalkad/atalkatab is essential - it contains the static routing information that tells the IPTalk router the correspondence between AppleTalk and IP networks. Thus an IPTalk network (containing a CAP-host and an IPTalk router) is a non-extended network, and should continue to operate with Phase 2. Atalkad/atalkatab isn't required in this case. If the CAP-host is on another IP network, then appropriate entries have to be made in atalkatab, atalkad has to be run and the IPTalk router has to be configured with the IP address of the atalkad-host. This should also continue to operate with Phase 2. It may be necessary to put a "K" entry in atalkatab, otherwise the IPTalk router may tend to keep asking atalkad for its entry. Atalkad's log file grows to megabytes when this happens. If IPTalk is being used to link AppleTalk networks, then we have a "routing" condition, and it will not work properly in a Phase 2 AppleTalk network. This is because there is no way to represent extended networks in atalkatab, there is no packet format defined for atalkad to use to communicate with the IPTalk routers, and more importantly, the IPTalk routers can't exchange routing information about extended networks. It is possible for it to partly work - only the non-extended networks will be "visible" and usable across the IPTalk link, but the details are "implementation dependent", meaning the routers may consider it to be an error condition and not work at all. There is an IETF working group looking at this, and new packet formats have been proposed. BTW the "Phasing" is "1" and "2", not "I" and "II". ======================== Tom Evans tom@wcc.oz.au Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179 wcc@cup.portal.com 2109 O'Toole Avenue, Suite J SAN JOSE CA 95131 - 1303 CALIFORNIA 1-408-954-8054 FAX 1-408-954-1832