Summary

  • RFC 1419 carried ordinary SNMP messages over AppleTalk for network elements without TCP/IP. It kept SNMP's PDU semantics but replaced the UDP/IP transport address with a DDP network, node and socket tuple.
  • Because AppleTalk addresses could change at reboot, the RFC treated a stable NBP service name as the durable reference and recommended caches that survived management-station restarts. Those caches also kept a direct management path usable when NBP discovery broke.
  • The resilience had a hard boundary. A stale address could be reassigned to another node, and an SNMP SET response might then look as if it came from the intended agent. Name, mapping, reachability, authentication, authority and device effect remained separate evidence.

One management protocol, a different road underneath

RFC 1419 appeared in March 1993 for equipment that spoke AppleTalk but not TCP/IP. Its proposition was narrow: a standard SNMP message could ride inside an AppleTalk Datagram Delivery Protocol packet. If the element supported several stacks and UDP was available, the RFC still preferred UDP. AppleTalk was an additional path for installed equipment, not a mandate to normalize every network onto it.

That choice was possible because SNMP had kept its message model relatively independent of the road beneath it. RFC 1157 described each SNMP message as a self-contained datagram and said other transport services could be used if their transport addresses were defined accordingly. The PDU still meant GetRequest, GetNextRequest, GetResponse, SetRequest or Trap. AppleTalk supplied a different envelope and addressing grammar.

DDP combined source and destination network numbers, node numbers and socket numbers, plus a protocol type. Its data area could carry up to 586 octets. Under RFC 1419, an SNMP request went to DDP socket 8 with protocol type 8. A response returned to the socket that originated the request, also with type 8. The response's source address corresponded to the request's destination, preserving the request-response binding expected by SNMP.

Traps used another well-known socket, 9, but the same protocol type. This was not mere port trivia. Requests, responses and unsolicited reports had different direction and state. Receiving a packet at the right socket proved that a datagram reached an endpoint participating in the mapping. It did not prove which durable machine or operator stood behind that endpoint.

AppleTalk made the name more durable than the address

The difficult part was not putting BER-encoded SNMP bytes inside DDP. It was deciding what the manager meant by “that agent” after an address changed.

AppleTalk's Name Binding Protocol mapped a name of the logical form object:type@zone to a DDP address. The fields were case-insensitive, usually human-readable and limited to 32 octets each. An RFC 1419 agent advertised the type SNMP Agent; a management station able to receive traps advertised SNMP Trap Handler.

The object portion was supposed to connect the SNMP service to the network's existing conception of the machine. On a Macintosh, the RFC suggested the System 7 Macintosh Name already used by other services. The document called this name tightly bound to the network's concept of system identity. That was useful continuity language, not cryptographic authentication. The same RFC later explained why the distinction mattered.

An AppleTalk network address could change on every reboot, or even more often. The NBP name, by contrast, was expected not to change more frequently than a typical TCP/IP host's address and was to be kept in stable storage. Durable intent therefore attached to the name: this is the service I want to manage. Delivery still required a current mapping: this is the DDP tuple that presently reaches it.

That separation resembles DNS and an IP address, but RFC 1419 was careful about the difference. Every node implementing the mapping had to answer NBP lookups and confirmations, so a name-to-address mapping existed by contract. Existence did not make each answer timeless or authentic. A manager still needed to remember when and how the mapping had been confirmed.

A cache became part of the management system

NBP lookups could consume network bandwidth and CPU. They were also sensitive to failures that did not break ordinary DDP communication: inconsistent zone tables, a damaged broadcast-to-forwarding path in a router, or broken NBP machinery in the target node. A manager could lose the ability to ask where an agent lived while retaining the ability to send packets to its last known address.

RFC 1419 responded by making lookup a relatively infrequent cache-filling operation. Management stations were advised to preserve name-to-address mappings between reboots and use them for subsequent SNMP traffic. The cache reduced repeated discovery work, but its more interesting function was operational independence. When the discovery layer failed, yesterday's mapping could keep enough of the data path alive to investigate the failure.

The RFC did not say “cache forever.” If a mapping had not been confirmed in T1 seconds, an agent or station using it should try to confirm it. The minimum default for T1 was 60 seconds, and the value was configurable. Infrastructure nodes such as routers could be kept fresher than less important entries. A long-running station reading many names at startup was not to resolve everything at once; it could spread lookups over time and follow a configured priority.

These details placed future decisions at the operator edge. The common layer supplied a confirmation interval, not one universal refresh schedule. The manager knew which nodes mattered, what startup load the network could absorb and how much staleness a particular operation could tolerate.

Trap discovery stopped before it became a broadcast search for authority

RFC 1419 treated trap destinations more strictly than manager discovery. An agent had to be configured with the name of a particular management station or set of stations before sending traps. Without that configuration, it sent no traps. It was never to issue a wildcard NBP lookup merely to find someone willing to receive them.

This rule prevented an unsolicited event channel from inventing its own recipient set. A configuration utility could let a human browse the network and choose stations, but the agent's running behavior used that prior selection. Discovery showed candidates; configuration established the destination.

The agent also was not to prime all of its mappings in advance. It looked up or confirmed a management station when a trap needed to be sent. Replies to requests were different again: an agent did not need to confirm a cache entry before responding because the originating DDP socket was already present in the request envelope.

These were three distinct relationships—manage this agent, send events to this station, answer this request—and RFC 1419 did not collapse them into one “known device” flag.

The zero address inside a trap admitted what the carrier did not know

SNMPv1's Trap-PDU included an agent-addr field shaped as an Internet network address. An AppleTalk-only agent did not possess the relevant IP address, so RFC 1419 required all zeros. The carrier did not manufacture an IP identity simply to fill the inherited field.

Instead, the trap was expected to include the nbpObject and nbpZone values for the SNMP Agent registration. RFC 1243 defined those as distinct objects alongside nbpType and nbpState. The outer DDP source, the zero IP-shaped field and the variable bindings each told a different part of the story.

The zero was positive evidence of a boundary: this field cannot name the sender in this transport domain. The NBP bindings supplied a name claim that the management station could compare with its cache. Neither converted the trap into proof that the event occurred, that the source was authorized or that an operator acted on it.

A read could help confirm; a write exposed the race

When a manager possessed a possibly stale DDP address, it could use that address as a hint for a unicast NBP confirmation. It could also fold confirmation into an ordinary SNMP read: request the destination's NBP object and zone, then compare those returned values and the response's DDP source with the intended cache entry.

That method gathered several observations in one exchange. It still did not eliminate every ambiguity. RFC 1419 singled out SET because the cost of being wrong was higher and the act itself could race the check.

Suppose the old node went down and a new node acquired the same DDP address. A SetRequest sent through the stale cache could reach the new agent. That agent might generate a syntactically valid response whose source matched the destination used by the request. The management station, the RFC said, might be unable to distinguish that reply from one sent by the intended agent.

The document looked to future SNMP security: authenticate each packet at the destination so the response would implicitly confirm the cache entry and prevent this race. The future tense is crucial. RFC 1419 did not claim that a stable name, an address, a community string or a matching response already supplied strong endpoint identity.

RFC 1157 defined communities, MIB views and access policies, but its Security Considerations section simply said security issues were not discussed. A transport mapping could preserve these administrative concepts without repairing their security limits.

Broken discovery did not require surrendering the direct path

The RFC also described a local fallback for a dedicated AppleTalk management station. If the ordinary NBP path failed, the station might implement the router portion of NBP itself. Knowing the zones and their networks, it could forward a request toward the agent's last network and, if needed, issue a directed DDP multicast to the relevant network numbers.

The scope was bounded. The text said this combined approach could solve specified single failures in local or remote router NBP handling. It did not promise recovery from partition, wrong configuration at every layer or a missing agent. More importantly, it left the choice with the management station. The common protocol described enough structure for a local operator to build a diagnostic route without making every AppleTalk node carry the same recovery machinery.

The historical lesson is not that persistent caches are always safe. It is that a resilient control system can preserve a last-known path while retaining the evidence that makes the path defeasible. Name, address, last confirmation, response source, returned registration fields and request type all matter. If the system keeps only “agent reachable,” it destroys the distinctions needed to decide whether a read is informative or a write is reckless.