summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1419.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1419.txt')
-rw-r--r--doc/rfc/rfc1419.txt395
1 files changed, 395 insertions, 0 deletions
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