RFC 1419

RFC 1419: SNMP over AppleTalk 🦋

okay bestie, this one is a classic 🌸 It's from March 1993, from the Network Working Group, written by G. Minshall (Novell, Inc.) and M. Ritter (Apple Computer, Inc.) 💜 It's an IAB standards track protocol, and its title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨ (the full status stuff is below, so don't skip it 🙈)

Status of this Memo 💅

This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Introduction ✨

okay so this memo is about how to run SNMP (the Simple Network Management Protocol, as specified in [1]) over AppleTalk protocols [2] instead of the usual Internet UDP/IP stack 🎀 it's perfect for network elements that have AppleTalk support but no TCP/IP support. ngl, it should be noted that if a network element supports multiple protocol stacks and UDP is available, UDP is the preferred network layer to use 💖

SNMP has been a total hit for managing Internet-capable network elements that support the stack at least through UDP, the connectionless Internet transport layer protocol 🧚 as originally designed, SNMP can run over any reasonable transport mechanism (not necessarily a transport protocol) that supports bi-directional flow and addressability. it's giving versatile 🦋

tons of non-Internet-capable network elements are out there in networks, and some of them have AppleTalk protocols. one way to manage these is to define a method of transmitting an SNMP message inside an AppleTalk protocol data unit 👑

this RFC is the product of the SNMP over a Multi-protocol Internet Working Group of the Internet Engineering Task Force (IETF) 🫶

---

1. Background 🌈

the AppleTalk version of UDP (and IP) is DDP (Datagram Delivery Protocol) 💅 the header of a DDP datagram includes (at least conceptually) source and destination network numbers, source and destination node numbers, and source and destination socket numbers. DDP datagrams also include a "protocol type" in the header field, which may be used to further demultiplex packets. the data portion of a DDP datagram may contain from zero to 586 octets.

AppleTalk's Name Binding Protocol (NBP) is a distributed name-to-address mapping protocol 🍓 NBP names are logically of the form object:type@zone. zone is determined, loosely, by the network the named entity lives on. type is the kind of entity being named. object is any string that makes object:type@zone unique in the AppleTalk internet, and it usually helps an end-user figure out which instance of a specific type of service they're accessing. NBP names are not case sensitive 🙈 each field (object, type, and zone) is limited to 32 octets, and the octets usually consist of human-readable ASCII characters. main character energy for readable names ✨

2. Specification 💖

SNMP REQUESTS encapsulated according to this standard will be sent to DDP socket number 8 💌 they will contain a DDP protocol type of 8. the data octets of the DDP datagram will be a standard SNMP message as defined in [1].

SNMP RESPONSES encapsulated according to this standard will be sent to the DDP socket number that originated the corresponding SNMP request 🦋 they will also contain a DDP protocol type of 8, and the data octets will be a standard SNMP message as defined in [1]. (Note: as stated in [1], section 4.1, the source address of a RESPONSE PDU will be the same as the destination address of the corresponding REQUEST PDU. 👀)

okay this part is important, so pay attention 🔥 a network element that can respond to SNMP REQUESTS over AppleTalk MUST advertise this capability via the AppleTalk Name Binding Protocol, using an NBP type of "SNMP Agent" (hex 53, 4E, 4D, 50, 20, 41, 67, 65, 6E, 74) 🎀

a network management station that can receive an SNMP TRAP MUST advertise this capability via the AppleTalk Name Binding Protocol, using an NBP type of "SNMP Trap Handler" (hex 53, 4E, 4D, 50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72) 🌸

SNMP TRAPS encapsulated according to this standard will be sent to DDP socket number 9 🧚 they will contain a DDP protocol type of 8, and the data octets will be a standard SNMP message as defined in [1]. the agent-addr field of the Trap-PDU MUST be filled with a NetworkAddress of all zeros (the unknown IP address). so to identify the trap sender, the name and value of the nbpObject and nbpZone corresponding to the nbpEntry with the nbpType equal to "SNMP Agent" SHOULD be included in the variable-bindings of any trap that is sent [3]. that's the whole vibe of identifying the sender 💅

the NBP name for both an agent and a trap handler SHOULD be stable. it SHOULD NOT change any more often than the IP address of a typical TCP/IP end system changes 🙈 it's suggested that the NBP name be stored in some form of stable storage (PRAM, local disk, etc.).

---

3. Discussion of AppleTalk Addressing 🦋

3.1 Introduction 🌈

AppleTalk has some features that you won't see in the standard TCP/IP suite 💅 its unique naming strategy and the dynamic nature of address assignment can cause problems for SNMP management stations that want to manage AppleTalk networks. as of this writing, TCP/IP end nodes have an associated IP address that tells each one apart from the others. AppleTalk end nodes, in general, have no such characteristic. the network level address, while often relatively stable, can change at every reboot (or more often) 😭

so a big thrust of this proposal is that a "name" (as opposed to an "address") for an end system be used as the identifying attribute 💖 that's the equivalent, for TCP/IP end nodes, of using the domain name. the mapping (DNS name, IP address) is more stable than the mapping (NBP name, DDP address), but the mapping (DNS name, IP address) is not REQUIRED to exist (e.g., hosts with no host name, only an IP address). in contrast, all AppleTalk nodes that implement this specification are REQUIRED to respond to NBP lookups and confirms (e.g., implement the NBP protocol stub), which guarantees that the mapping (NBP name, DDP address) will exist 🫶

when you're picking the SNMP name to register for an agent, it's suggested that the SNMP name be a name associated with other network services the machine offers 🍓 on a Macintosh system, for example, it's suggested that the system name (the "Macintosh Name" for System 7.0, which is used to advertise file sharing, program-to-program communication, and possibly other services) be used as the object field of the NBP name. that name has AppleTalk significance and is tightly bound to the network's concept of a given system's identity 👑

NBP lookups, which turn NBP names into DDP addresses, can cause large amounts of network traffic and also consume CPU resources 💀 the ability to do an NBP lookup is also sensitive to certain network disruptions (such as zone table inconsistencies, etc.), which would NOT stop direct AppleTalk communication between a management station and an agent. sus, right? 🙈

so it's recommended that NBP lookups be used infrequently, with the primary purpose being to create a cache of name-to-address mappings 🧚 those cached mappings should then be used for any further SNMP requests. it's also RECOMMENDED that SNMP management stations keep this cache between reboots. this caching helps minimise network traffic, reduces CPU load on the network, and allows for (some amount of) network troubleshooting when the basic name-to-address translation mechanism is broken 🌈

3.2 How To Acquire NBP names: 🎀

a management station MAY have a pre-configured list of names of agents to manage 💅 it MAY also allow for an interaction with an operator, in which a list of manageable agents is acquired (via NBP) and presented so the operator can choose which agents that management station should manage ✨ finally, a management station MAY manage all manageable agents in a set of zones or networks 🦋

an agent MUST be configured with the name of a specific management station or group of management stations before sending SNMP traps. without any such configured information, an agent is NOT to generate any SNMP traps 🙅‍♀️ in particular, an agent is NEVER to initiate a wildcard NBP lookup to find a management station to receive a trap. all NBP lookups generated by an agent MUST be fully specified. note, however, that this does not apply to a configuration utility that might be associated with such an agent 💖 such a utility MAY well allow a user to navigate around the network to select the management station or stations that should receive SNMP traps from the agent 🫶

3.3 When To Turn NBP Names Into Addresses: ⭐

when SNMP agents or management stations use a cache entry to address an SNMP packet, they SHOULD attempt to confirm the mapping if it hasn't been confirmed in T1 seconds 🌸 this cache entry lifetime, T1, has a minimum, default value of 60 seconds. this value SHOULD be configurable 💅

a management station MAY decide to prime its cache of names before actually sending any SNMP requests to a given agent 🧚 in general, it is expected that a management station MAY want to keep certain mappings "more current" than others. in particular, nodes that represent the network infrastructure (routers, etc.) MAY be deemed "more important" by the management station 👑

note, however, that a long-running management station starting up and reading a configuration file containing a number of NBP names SHOULD NOT try to prime its cache all at once 🙈 it SHOULD, instead, issue the resolutions over an extended period of time (perhaps in some pre-determined or configured priority order). each resolution might, in fact, be a wildcard lookup in a given zone 🍓

an agent SHOULD NEVER prime its cache 😤 it SHOULD do NBP lookups (or confirms) only when it needs to send an SNMP trap to a given management station. an agent does not need to confirm a cache entry to reply to a request ✨

that's the end of part one, bestie 🌈💖

3.4 How To Turn NBP Names Into Addresses: 🧚

Okay so, if the only thing you've got is the NBP name, you need to do an NBP lookup to turn that name into a DDP address. That's the move, bestie 💅

But if you've got a piece of stale info lying around, you can use it as a hint and do an NBP confirm 🔍. That's a unicast sent to the network address that's presumed to be the target of the name lookup, and it checks whether the stale info is still valid 🫶

Here's the lowkey genius part ✨: you can confirm an NBP name to DDP address mapping implicitly, using only SNMP transactions. If a management station is sending a get-request, it can slip an extra request into the same packet, asking for the nbpObject and nbpZone of the nbpEntry whose nbpType equals "SNMP Agent" [3]. Then the source DDP address from the reply can be used, along with the nbpObject and nbpZone that came back, to confirm the cache entry 🦋

That said, set-requests have a race condition 😬. An SNMP request can end up at the wrong agent. Why? Because the old node went down and a new node came up with the same DDP address. This is a problem, because the wrong agent might generate a response packet that the management station couldn't tell apart from a reply from the intended agent 💀

Once SNMP security is implemented, each packet is authenticated at the destination. At that point, the reply should implicitly confirm the validity of the cache entry used and prevent this race condition ✨

---

3.5 What if NBP is broken: 🙈

Under some circumstances, there may be connectivity between a management station and an agent, but the NBP machinery needed to turn an NBP name into a DDP address may be broken. Examples of failures that would cause this include:

• NBP FwdReq (forward NBP lookup onto locally attached network) broken at a router on the network containing the agent;
• NBP BrRq (NBP broadcast request) mechanism broken at a router on the network containing the management station (because of a zone table mis-configuration, for example); or
• NBP broken in the target node.

A management station that's dedicated to AppleTalk management might choose to alleviate some of these failures by implementing the router portion of NBP within the management station itself. For example, the management station might already know all the zones on the AppleTalk internet and the networks on which each zone appears. Given an NBP lookup that fails, the management station could send an NBP FwdReq to the network in which the agent was last located. If that failed, the station could then send an NBP LkUp (an NBP lookup packet) as a directed (DDP) multicast to each network number on that network. Of the above (single) failures, this combined approach will solve the case where either the local router's BrRq to NBP FwdReq mechanism is broken, or the remote router's NBP FwdReq to NBP LkUp mechanism is broken. Clever, right? 🧠

---

4. Acknowledgements ✨

Some of the boilerplate in this memo is copied from [4], [5], and [6]. The Apple-IP Working Group was instrumental in defining this document. Their support and work was greatly appreciated 🫶

---

5. References 📚

• [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
• [2] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk (Second Edition)", Addison-Wesley, 1990.
• [3] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, Carnegie Mellon University, August 1991.
• [4] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., University of Tennessee at Knoxville, February 1989.
• [5] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
• [6] Piscitello, D., "Guidelines for the Specification of Protocol Support of the SNMP", Work in Progress.

---

6. Security Considerations 🚨

Security issues are discussed in section 3.4. Seriously, bestie, section 3.4 is where the drama lives, so give it your full attention 😭

---

7. Authors' Addresses 🎀

Greg Minshall:

Greg Minshall
Novell, Inc.
1340 Treat Blvd, ste. 500
Walnut Creek, CA  94596

Phone: 510 947-0998
Fax:   510 947-1238
EMail:  minshall@wc.novell.com

Mike Ritter:

Mike Ritter
Apple Computer, Inc.
10500 North De Anza Boulevard, MS: 35-K
Cupertino, California 95014

Phone: 408 862-8088
Fax:   408 862-1159
EMail: MWRITTER@applelink.apple.com

And that's a wrap on RFC 1419, part 2! 🌈💖 You absolutely slayed it, bestie 👑