From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1419.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc1419.txt (limited to 'doc/rfc/rfc1419.txt') diff --git a/doc/rfc/rfc1419.txt b/doc/rfc/rfc1419.txt new file mode 100644 index 0000000..6f21f35 --- /dev/null +++ b/doc/rfc/rfc1419.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group G. Minshall +Request for Comments: 1419 Novell, Inc. + M. Ritter + Apple Computer, Inc. + March 1993 + + + SNMP over AppleTalk + +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 + + This memo describes the method by which the Simple Network Management + Protocol (SNMP) as specified in [1] can be used over AppleTalk + protocols [2] instead of the Internet UDP/IP protocol stack. This + specification is useful for network elements which have AppleTalk + support but lack TCP/IP support. It should be noted that if a + network element supports multiple protocol stacks, and UDP is + available, it is the preferred network layer to use. + + SNMP has been successful in managing Internet capable network + elements which support the protocol stack at least through UDP, the + connectionless Internet transport layer protocol. As originally + designed, SNMP is capable of running over any reasonable transport + mechanism (not necessarily a transport protocol) that supports bi- + directional flow and addressability. + + Many non-Internet capable network elements are present in networks. + Some of these elements are equipped with the AppleTalk protocols. + One method of using SNMP to manage these elements 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 equivalent of UDP (and IP) is DDP (Datagram Delivery + Protocol). The header field of a DDP datagram includes (at least + conceptually) source and destination network numbers, source and + + + +Minshall & Ritter [Page 1] + +RFC 1419 SNMP over AppleTalk March 1993 + + + destination node numbers, and source and destination socket numbers. + Additionally, DDP datagrams 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", where "zone" is determined, loosely, by the + network on which the named entity resides; "type" is the kind of + entity being named; and "object" is any string which causes + "object:type@zone" to be unique in the AppleTalk internet. + Generally, "object" also helps an end-user determine which instance + of a specific type of service is being accessed. NBP names are not + case sensitive. Each field of the NBP name ("object", "type", and + "zone") is limited to 32 octets. The octets usually consist of + human-readable ascii characters. + +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 which originated the corresponding SNMP + request; 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]. (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.) + + A network element which is capable of responding 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 which is capable of receiving 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. The + data octets of the DDP datagram 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). Thus, to + identify the trap sender, the name and value of the nbpObject and + + + +Minshall & Ritter [Page 2] + +RFC 1419 SNMP over AppleTalk March 1993 + + + 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]. + + 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 is 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 + + The AppleTalk protocol suite has certain features not manifest 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 wish to manage AppleTalk networks. TCP/IP end nodes, + as of this writing, have an associated IP address which distinguishes + each from the other. AppleTalk end nodes, in general, have no such + characteristic. The network level address, while often relatively + stable, can change at every reboot (or more frequently). + + Thus, a thrust of this proposal is that a "name" (as opposed to an + "address") for an end system be used as the identifying attribute. + This is the equivalent, when dealing with TCP/IP end nodes, of using + the domain name. While the mapping (DNS name, IP address) is more + stable than the mapping (NBP name, DDP address), 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. + + In determining the SNMP name to register for an agent, it is + suggested that the SNMP name be a name which is associated with other + network services offered by the machine. On a Macintosh system, for + example, it is 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. This name has AppleTalk + significance, and is tightly bound to the network's concept of a + given system's identity. + + NBP lookups, which are used to turn NBP names into DDP addresses, can + cause large amounts of network traffic as well as consume CPU + resources. It is also the case that the ability to perform an NBP + lookup is sensitive to certain network disruptions (such as zone + table inconsistencies, etc.) which would not prevent direct AppleTalk + + + +Minshall & Ritter [Page 3] + +RFC 1419 SNMP over AppleTalk March 1993 + + + communications between a management station and an agent. + + Thus, it is recommended that NBP lookups be used infrequently with + the primary purpose being to create a cache of name-to-address + mappings. These cached mappings should then be used for any further + SNMP requests. It is recommended that SNMP management stations + maintain this cache between reboots. This caching can help minimize + network traffic, reduce CPU load on the network, and allow for (some + amount of) network trouble shooting 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. A management station may allow for an interaction + with an operator in which a list of manageable agents is acquired + (via NBP) and presented for the operator to choose which agents + should be managed by that management station. 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. + In the absence of 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 a management station or stations to 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 prior to + actually sending any SNMP requests to any given agent. In general, + it is expected that a management station may want to keep certain + mappings "more current" than other mappings. In particular, those + nodes which represent the network infrastructure (routers, etc.) may + be deemed "more important" by the management station. + + + + +Minshall & Ritter [Page 4] + +RFC 1419 SNMP over AppleTalk March 1993 + + + Note, however, that a long-running management station starting up and + reading a configuration file containing a number of NBP names should + not attempt 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. + +3.4 How To Turn NBP Names Into Addresses: + + If the only piece of information available is the NBP name, then an + NBP lookup should be performed to turn that name into a DDP address. + + However, if there is a piece of stale information, it can be used as + a hint to perform an NBP confirm (which sends a unicast to the + network address which is presumed to be the target of the name + lookup) to see if the stale information is, in fact, still valid. + + An NBP name to DDP address mapping can also be confirmed implicitly + using only SNMP transactions. If a management station is sending a + get-request, it can add a request, in the same packet, for the + destination's nbpObject and nbpZone corresponding to the nbpEntry + with the nbpType equal to "SNMP Agent" [3]. The source DDP address + can be gleaned from the reply and used with the nbpObject and nbpZone + returned to confirm the cache entry. + + The above notwithstanding, for set-requests, there is a race + condition that can occur where an SNMP request may go to the wrong + agent (because the old node went down and a new node came up with the + same DDP address.) This is problematic becase the wrong agent might + generate a response packet that the management station could not + distinguish from a reply from the intended agent. In the future, + when SNMP security is implemented, each packet is authenticated at + the destination, and 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 required to + turn an NBP name into a DDP address may be broken. Examples of + failures which 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) + + + +Minshall & Ritter [Page 5] + +RFC 1419 SNMP over AppleTalk March 1993 + + + mechanism broken at a router on the network containing the managment + station (because of a zone table mis-configuration, for example); or + NBP broken in the target node. + + A management station which is 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 which 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. + +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. + + + + + +Minshall & Ritter [Page 6] + +RFC 1419 SNMP over AppleTalk March 1993 + + +6. Security Considerations + + Security issues are discussed in section 3.4. + +7. Authors' Addresses + + 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 + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Minshall & Ritter [Page 7] + \ No newline at end of file -- cgit v1.2.3