A very brief introduction to AppleTalk for people who know IP

[cheesestraws]

I wrote these bullet points for a forum member in PM and they encouraged me to post it as a thread here. Lots of people know IP fairly well, and a lot of that knowledge is transferrable to AppleTalk. Here's a very brisk guide to layers 2 and 3 in AppleTalk land.

First, "What is AppleTalk":

• AppleTalk is a protocol on the same level as IP. It is very like IP, in fact: it's a packet-oriented routable protocol. AppleTalk addresses are three bytes long. The first two are a network number, and the last one is a host number. You can only have 255 hosts on a single AppleTalk network, like an IP /24, but you can have multiple AppleTalk networks plugged into each other with a router in the middle, like IP.
  
  
• You basically never see AppleTalk addresses, though, except on A/UX and MacOS X, because all addressing is dynamic. When a computer comes onto a network, it remembers the address it had last time, and tries to use it again: if the address is free, it uses it, if it isn't, it changes and tries again. There's no DHCP-equivalent, computers on a network agree addressing between them.
  
  
• Much like in IP, software can open sockets to communicate with other computers. Sockets have a "socket number", which is what IP calls a port number. But again, you almost never see a socket number in the UI, because of NBP.
  
  
• NBP is the equivalent of DNS (or mDNS). When a client wants to find a server, it sends out a broadcast NBP lookup saying "give me all servers of this type". So, when you click on AppleShare in the Chooser, it broadcasts a lookup saying "Hello all AppleShare servers, please reply to this message." They do, and those go in the list in the Chooser.
  
  
• Unlike DNS, however, these responses include the socket number. So the NBP reply says "connect to computer 2.7 at socket 27". This means there don't need to be any fixed socket numbers aside from some very low-level ones, because the user always discovers services via NBP, which tells you the socket number.

Physical layers:

• Much like IP, AppleTalk can run over several different cabling systems. Ethernet is the most popular option these days. Note that this isn't "AppleTalk in IP over Ethernet", AppleTalk runs directly over Ethernet.
  
  
• LocalTalk is another option. LocalTalk is a bus network, where computers are daisychained through their serial ports. It uses RS485 as an electrical standard, and talks a protocol called SDLC over it, which was a very common way of building a low-cost network at the time.
  
  
• You can either bridge LocalTalk to Ethernet or route it. Bridging is kind of like what a WiFi AP does between WiFi and Ethernet: a computer on one side of the bridge sees a computer on the other as on the same network. Routing is like IP routing: two computers on two networks see each other as on different networks, but can send packets between them.
  
  
• Bridging is simpler, but has some wrinkles: routing is more flexible, but you have to configure it.

AppleTalk and IP:

• Usually, when a computer has both AppleTalk and IP enabled, they act as separate network stacks, like running IPv4 and IPv6 on a modern computer. They can either share a network interface or use different network interfaces: IP applications send IP packets, which turn into IP-typed ethernet frames, and AppleTalk applications send AppleTalk packets, which turn into AppleTalk-typed Ethernet frames.
  
  
• The problem comes when you have LocalTalk in the picture. LocalTalk, for highly technical and rather silly reasons, can't run IP directly over it. So, if you want to give LocalTalk-connected Macs IP connectivity, this has to be done by tunneling it over AppleTalk - kind of like each LocalTalk-connected Mac has its own ad-hoc VPN over AppleTalk. The system of running IP over AppleTalk is called MacIP.
  
  
• Obviously, you need the other end to this little VPN: you need something that has "real" IP connectivity to unwrap the packets from AppleTalk and send them on. This is called a MacIP gateway, and there are a number of options, including the macipgw appliance maintained by a forum member.

 

[chelseayr]

@cheesestraws interesting writeup thats for sure

and not to be too offtopic but regarding 'it changes and tries again' that sounds very alike to what I have heard of adb devices from somewhere several years ago? or to put it this way now: plug in two identical keyboards and at bootup the duplication (or however you may correctly call it) would be realized and a new device id is quietly issued for one of the keyboards

 

[cheesestraws]

Yup, similar idea: the idea is that the user never has to assign addresses explicitly. It's a bit different because in ADB you have a computer which is in charge of that process whereas in AppleTalk, no single computer is in charge. But the idea is very similar.

 

[stepleton]

Thanks for this introduction! How are network numbers chosen, and how does a computer joining an existing AppleTalk network learn what the network number is?

 

[cheesestraws]

How are network numbers chosen, and how does a computer joining an existing AppleTalk network learn what the network number is?

When an AppleTalk node starts up, it sends out a broadcast "hello, is there a router on this network? What am I plugged into?" kind of message. If there is a router, and if that router is a seed router (which means it's a router that's in charge of the configuration for that network), it replies with information about how the network is set up, including the network number. The node then uses the network number the router tells it to.

If there is no router, it just uses a default. This is 0 for LocalTalk: for Ethernet there's a range of network numbers assigned for a default (because on Ethernet, the 255 node thing was considered a bit of a limitation, so you can have multiple network numbers per physical link; this is called an extended network and is frankly a bit of a hack, but it does work pretty well).

The main thing you need to configure when setting up a router is network numbers.

 

[cheesestraws]

I should probably add a note about Zones here. People seem to get confused about them a bit, and the key to them is that they are intended for humans, not for machines. A Zone is really just a label that can be attached to an endpoint. It's not semantically tied to network topology (although you need to tell routers about them), it's tied to administrative convenience.

So, for example, you could have a zone for "everything on the third floor of this building", regardless of whether those things were on Ethernet or LocalTalk. Then, when a node on the third floor wants to search for, say, printers, it will by default look for printers in the same zone, which in this case means it's less likely a user will have to climb stairs.

You can think of these as something like a DNS search domain in IP-land, but more powerful and general. For example, you can do zone-wide broadcasts, which will reach every node in that zone regardless of topology—routers will forward the broadcasts to networks which have nodes in that zone on.

(Confusingly, this is how MacIP does its equivalent of ARP, mapping IP addresses to AppleTalk addresses: the AppleTalk address is found by means of a zone-wide NBP lookup, like for any other AppleTalk service. This means that MacIP is zone-scoped, not network-scoped. This makes sense when you're actually using it but if you think about it too much it might give you a headache. It does me. I recommend not thinking about it too hard.)

 

[NJRoadfan]

To make things more confusing, there are different ways to "interact" between TCP/IP and AppleTalk networks.

• MacIP as already mentioned allows AppleTalk only clients (primarily LocalTalk) to access TCP/IP network resources via a gateway.
• IP Talk aka KIP was an early protocol that allowed TCP/IP only clients to access AppleTalk resources. This required a bridge like a Shiva Fastpath and mapped a dedicated TCP/UDP port to each AppleTalk service (NBP, AFP, etc). This was used by the Columbia AppleTalk Package, which ran on UNIX platforms that did not any AppleTalk network support in the early days.
• AppleTalk tunneling via TCP/IP was also popular. Once again this was available in dedicated routers like the Shiva Fastpath and Cayman GatorBox. This allowed interlinking of AppleTalk networks over the Internet... basically what we would now call a VPN, but for AppleTalk. Both Cayman and Shiva used differing protocols, so you had to use matching hardware on both sides (some 3rd parties supported one or the other). Apple had their own protocol called "Apple Update-based Routing Protocol" supported by their Internet Router software. Shiva called their protocol "TunnelTalk" or "Dr. Pepper". Cayman's was called SEDI (Simple Encapsulation of DDP in IP). There were attempts to standardize this in 1993 but by then AppleTalk was dying and it went nowhere. See MacWorld April 1994 page 165 for more.

 

[Tashtari]

@cheesestraws Thanks for sharing this, it was useful to read. TashTalk notwithstanding, networking is not my long suit and most things about AppleTalk above LocalTalk are mysterious to me.

It makes me wonder how complicated an undertaking it would be to make a router in a PIC16F1788 with one Ethernet port (driven by the ENC28J60) and one LocalTalk port (driven by TashTalk), the former using the SPI interface and the latter using the UART. The neatness of that association attracts me, but I wonder whether implementing the logic would be more than I can handle...

 

[robin-fo]

An AppleTalk router needs *a lot* of RAM to store the routing table and the zone information table. You probably also want dynamic memory allocation (especially useful for ATP which is required by ZIP), except if you can live with a single pending request at a time.

You could try building a bridge instead of a router, but then you basically have the same as the AirTalk, except having native AppleTalk over wired Ethernet instead of using UDP.

 

[Tashtari]

An AppleTalk router needs *a lot* of RAM to store the routing table and the zone information table.

Yeah, that's me out, then. =)

Suppose I could use an external SRAM, depending on what "a lot" is, though...

 

[robin-fo]

I hope to let my own AppleTalk router stack run on an STM32 target one day, but I didn‘t do any experiments towards this yet… The RAM issues probably apply there also, but I could try to store at least the tables on an SPI EEPROM as they seldom change (at least they would in a 1990‘s office envirnonment ).

 

[cheesestraws]

Yes: this feels like more of an ESP32 or STM32 sized problem to me rather than a PIC sized one, mostly because of memory.

That said, @tashtari, I've learned not to make definite statements about what can or cannot be done on a PIC near you ;-).

 

[Tashtari]

In case anyone's watching this thread and not already aware, I did eventually make a router... just not in a PIC. =D See the TashRouter thread and GitHub page.

(Having now done it in Python on an RPi, I doubt I could have managed it on a PIC.)

 

[ArmorAlley]

Thanks very much for this.

 

[zefrenchtoon]

What about EtherTalk ?
Was it the somewhat commercial name for AppleTalk over Ethernet or something else ?

 

[cheesestraws]

Was it the somewhat commercial name for AppleTalk over Ethernet or something else ?

Yup, that's exactly what it was.

 

[NJRoadfan]

There was also TokenTalk and FDDITalk too.

 

[zefrenchtoon]

Yup, that's exactly what it was.

Thanks for confirmation

There was also TokenTalk and FDDITalk too.

I remember TokenTalk but never see FDDITalk

 

[cheesestraws]

I remember TokenTalk but never see FDDITalk

There was also IRTalk for short range infra-red, IIRC.

Apple's habit of using 'Talk' as a general purpose marketing term muddies the technical waters something fierce here, though.