BRACKENRIDGE@C.ISI.EDU (Billy) (11/09/87)
Someone asked about encapsulation of Appletalk packets in IP. My company, IPT sells software for Unix boxes which support Appletalk networks. The idea is that a Unix machine can more efficiently and cost effectively act as file, mail, and print server for an Appletalk network than a stand alone Macintosh. I would like to suggest that people looking at NFS as a remote file server protocol consider AFS. This is the remote file system pushed by Apple. It has the advantage that it was written after NFS and incorporates record locking into the lowest level protocols. If you intend to do multi user database work on a distributed file system AFS has some advantages over NFS. Currently we are using the Kinetics box to gateway between Appletalk nets and the Ethernet. Eventually we want to replace the Kinetics box with an AT motherboard that can talk to a number of Appletalk nets as well as Ethernets and various token nets. There are several interesting issues. I bring these up partly to plug our company and because I think they are worth talking about on this net and at the interoperability conference. One of the nicest features of Appletalk networks is that the user never needs to enter any configuration information. When a new Appletalk node comes on the net it calls a random number generator to make up an address. It then asks the other hosts on the net if it is OK to use the address. This works because one never has more than a dozen or so hosts on a single net. Internetworking is somewhat more complicated, but dedicated Macs take care of that. The Kinetics box is a small 68000 box with Ethernet and Appletalk interfaces. Most implementations download the Kinetics boxes from the Apple side of the net loading such information as the Kinetics Ethernet and IP addresses. Yes you heard it right! Kinetics boxes have no ROM Ethernet addresses. Kinetics has a manufacturer code but no individual serial numbers. We think your average Macintosh user shouldn't have to keep track of Ethernet and IP addresses. I would say the same about PCs speaking TCP/IP. If we solve the Macintosh problem we solve the PC problem. Our approach for AFS is to encapsulate the Appletalk packets in IP/UDP packets in the Kinetics box. This works fine except packets can be bigger than the maximum IP packet size. We don't want to deal with the IP fragmentation issue so we worked out a scheme for encoding the Appletalk header information into the IP header. Each Macintosh on the Appletalk side of the net is assigned an IP address. There is a table mapping IP addresses to Appletalk addresses in the Kinetics box. With this scheme we can keep our encapsulated Appletalk packets less than the maximum IP packet size. The overhead to the gateway isn't much given the slowness of Appletalk nets a 68000 or 8086 can easily keep up with Appletalk packet rates. We still haven't completely solved the problem of how do we auto config when a Kinetics box and Appletalk net connect to an IP network. The fact that the Kinetics box doesn't even know its Ethernet address makes this problem really interesting. Our ground rules also require that the Mac user need not know his IP address or the IP address of the Kinetics box. One generic Mac boot disk should be able to boot up any Appletalk network connected to any IP network. We can't use reverse ARP because not all Unix systems allow access to the Kernel or reverse ARP packets. Our server code must run at the user level. We are thinking about writing a configuration server that listens for UDP broadcast packets on a well known socket. I would like to bring up these topics at the TCP/IP Interoperability conference next month. If anybody has any bright ideas on encapsulation of Appletalk protocols in IP/UDP packets or on auto configuration of IP addresses for workstations, Id like to exchange ideas. Billy Brackenridge IPT Inc. 23801 Calabasas Road, Suite 2011 Calabasas, CA 91302 (818)347-7791 -------
ddp+@ANDREW.CMU.EDU.UUCP (11/10/87)
Billy, I wish everyone would just forget reverse arp. There is a MUCH better protocol which serves the same function and much more. It's called BOOTP, RFC950. It works on top of UDP and is even capable of working through IP gateways (although they require a "small" modification). Steve Waldbusser here at CMU is almost done with new proms for the Kinetics box which implement BOOTP and TFTP. Unfortunately, the prom also contains the ethernet address, so each box must have a different prom... Drew