Internet Draft SNMP over IPX August 1992 SNMP over IPX Tuesday August 11, 1992 Steve Bostock Novell, Inc. steveb@novell.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress" Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This draft document is being circulated for comment. If consensus is reached in the IETF's "SNMP over a Multi-protocol Internet" working group, it will be submitted to the RFC editor as a Proposed Standard protocol specification. If published as an RFC, this document will obsolete RFC 1298. Bostock Expires February 11, 1993 [Page 1] Internet Draft SNMP over IPX August 1992 2. Abstract This document defines a convention for encapsulating Simple Network Management Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. 3. Introduction The Simple Network Management Protocol (SNMP) as defined in [1] is now used as an integral part of the network management framework for TCP/IP-based internets. Together with its companion standards, which define the Structure of Management Information (SMI) [3,4], and the Management Information Base (MIB) [5], the SNMP has received widespread deployment in many operational networks running the Internet suite of protocols. The success of SNMP in the TCP/IP environment has led to its deployment in non TCP/IP-based internets. This specification describes the mapping of SNMP onto the Internetwork Packet Exchange (IPX) protocol [2] used in Novell NetWare environments. As noted in [6], the preferred mapping for SNMP is onto UDP [7]. As such, this specification is intended for use in environments where UDP transport is not available. No aspect of this specification should be construed as a suggestion that, in a heterogeneous transport environment, a managed agent should support more than one mapping. Conversely, management stations are strongly encouraged to support mappings of SNMP onto all popular transports. 4. Mapping SNMP onto IPX Mapping SNMP onto IPX is straight-forward since IPX provides a datagram service very similar to that provided by IP/UDP. Although modifications have been made elsewhere in the NetWare protocol suite, IPX is identical to the Xerox Internet Datagram Protocol (IDP) [8]. The socket address space authority is administered by Novell. SNMP packets will always set the Packet Type field in the IPX header to 4 (i.e., Packet Exchange Packet). Bostock Expires February 11, 1993 [Page 2] Internet Draft SNMP over IPX August 1992 4.1 Socket Assignments SNMP protocol entities will receive GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU messages on socket 36879 (Destination Socket field set to hexadecimal 900F), and Trap-PDU messages on socket 36880 (Destination Socket field set to hexadecimal 9010). GetResponse-PDU messages will be addressed to the IPX address and socket from which the corresponding GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU originated. 4.2 Traps When SNMP traps are sent over IPX, the agent-addr field in the Trap-PDU contains the IP-address "0.0.0.0". An SNMP manager may ascertain the source of the trap based on information provided by the transport service 4.3 Maximum Message Size Although SNMP does not require conformant implementations to accept messages whose length exceeds 484 bytes, it is recommended that implementations support a maximum SNMP message size of 546 bytes (the maximum size allowed under IPX). Furthermore, this limit is the maximum packet length guaranteed to traverse IPX routers which do not provide fragmentation. Implementors may choose to use longer packet lengths if the maximum is known, which depends on the intermediate routers and/or intermediate datalink layer protocols. 4.4 SNMP Party Information There are occasions when it is necessary to represent a transport service address in a MIB. For instance, the SNMP party MIB [9] uses an OBJECT IDENTIFIER to define the transport domain (IP, IPX, etc.) and an OCTET STRING to represent an address within that domain. The following definitions are provided for use in such a scheme. RFCyyyy-MIB DEFINITIONS ::= BEGIN IMPORTS experimental FROM RFC1155-SMI; Bostock Expires February 11, 1993 [Page 3] Internet Draft SNMP over IPX August 1992 snmpOverIpx OBJECT IDENTIFIER ::= { experimental xx } snmpOverIpxDomain OBJECT IDENTIFIER ::= { snmpOverIpx 1} -- For snmpOverIpxDomain, a TAddress is 12 octets long and -- comprises 3 fields, each in network-byte (high-low) order. -- The first field is 4 octets long and contains the network -- number. -- The next field is 6 octets long and contains the physical -- address of the node. Since IPX can run over a variety of -- subnet architectures, the physical node address may not -- require all 6 octets. As specified in [2], the physical -- node address will occupy the least significant portion of -- the field and the most significant octets should be set -- to zero. -- The last field is 2 octets long and contains the socket -- number. -- When devices are installed, they need to be configured -- with an initial set of SNMP parties. The configuration -- of SNMP parties requires (among other things) the -- assignment of several OBJECT IDENTIFIERs. Any local -- network administration can obtain the delegated authority -- necessary to assign its own OBJECT IDENTIFIERs. However, -- to cater for those administrations who have not obtained -- the necessary authority, this document allocates a branch -- of the naming tree for use with the following -- conventions. initialIPXPartyId OBJECT IDENTIFIER ::= { snmpOverIpx 2 } -- This prefix is used in an analogous fashion as -- -- initialPartyId -- -- as defined in [9]. For an SNMP protocol entity residing -- at IPX transport address 'N', the identities of its six -- initial parties are formed by appending 12 sub identifiers, -- one sub-identifier for each octet in the IPX transport -- address, to -- Bostock Expires February 11, 1993 [Page 4] Internet Draft SNMP over IPX August 1992 -- initialIPXPartyId -- END 5. Document Procurement This section provides contact points for procurement of selected documents. A complete description of IPX may be secured at the following address: Novell, Inc. 122 East 1700 South P. O. Box 5900 Provo, Utah 84601 USA 800 526 5463 Novell Part # 883-000780-001 The specification for IDP (part of XNS) may be ordered from: Xerox System Institute 475 Oakmead Parkway Sunnyvale, CA 94086 Attn.: Fonda Pallone (415) 813-7164 6. Acknowledgments This specification was derived from RFC 1298, based on discussions in the IETF's "SNMP over a Multiprotocol Internet" working group. Bostock Expires February 11, 1993 [Page 5] Internet Draft SNMP over IPX August 1992 7. References [1]Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple Network Management Protocol (SNMP)", RFC 1157, May 1990. [2]Novell, Inc., "NetWare System Technical Interface Overview", part number 883-000780-001, June 1989. [3]Rose M.T., McCloghrie K., "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, May 1991. [4]Rose M.T., McCloghrie K., "Concise MIB Definitions", RFC 1212, March 1991. [5]Rose M.T., McCloghrie K., "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1213, March 1991. [6]Kastenholz, F., "SNMP Communications Services", RFC 1270, October 1991. [7]Postel J.B., "User Datagram Protocol", RFC 768, August 1980. [8]Xerox System Integration Standard, "Internet Transport Protocols", XSIS 028112, Xerox Corporation, December 1981. [9]McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed Objects for Administration of SNMP Parties", RFC 1353, July 1992 8. Security Considerations Security issues are not discussed in this memo. Bostock Expires February 11, 1993 [Page 6] Internet Draft SNMP over IPX August 1992 9. Author's Address Steve Bostock Novell, Inc. 2180 Fortune Drive San Jose, CA 95131 Phone: 408 473 8203 Fax: 408 435 1706 Email: steveb@novell.com Bostock Expires February 11, 1993 [Page 7]