zben@ni.umd.edu (Ben Cranston) (03/16/91)
Is there any "gotcha" that make an "AppleTalk Bridge" unfeasable? I'm talking about a gut-level bridge that just forwards DDP packets from a LocalTalk network on one side to an EtherTalk network on the other side. For example, it would have to sense "Enq" packets on the LocalTalk side and rebroadcast them as AARP type 3 packets on the EtherTalk side, and convert AARP replies (type 2) into "Ack" packets on the LocalTalk side, etc. (Actually you probably want to answer Enq with Ack yourself if the node in question is in your ARP cache as belonging to the EtherTalk side). After a little reading in Inside AppleTalk I've identified two possible problem areas: 1. The LocalTalk side is going to still be doing that 1-127 for clients and 129-254 for servers stuff, there is no equivalent on the EtherTalk side. 2. Phase 2 EtherTalk is not defined for LocalTalk. I'm particularly worried about old implementations like LaserWriters. They are going to start up as being on network zero, while the EtherTalk spec requires them to initially register on a temporary network number (FF00-FFFE). Why not build a router? To avoid having to deal with configuration issues like setting "seed" network numbers for the two subnetworks.