summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1298.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1298.txt')
-rw-r--r--doc/rfc/rfc1298.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc1298.txt b/doc/rfc/rfc1298.txt
new file mode 100644
index 0000000..3c602e9
--- /dev/null
+++ b/doc/rfc/rfc1298.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group R. Wormley
+Request for Comments: 1298 S. Bostock
+ Novell, Inc.
+ February 1992
+
+
+ SNMP over IPX
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard. Distribution of this memo is
+ unlimited.
+
+Abstract
+
+ This memo 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].
+
+Editor's Note
+
+ As stated below and in reference [5], it is strongly advised that for
+ interoperability, SNMP be implemented over UDP/IP and not directly on
+ media or other protocols (such as IPX).
+
+1. Introduction
+
+ The SNMP protocol has been specified as the official network
+ management protocol of the Internet. Its widespread acceptance and
+ implementation by developers, both inside and outside the Internet
+ community, is fostering synergetic growth to a variety of protocols
+ and platforms.
+
+ This memo addresses the use of SNMP over the IPX protocol, which has
+ become quite widespread principally due to the popularity of Novell
+ NetWare. Roughly equivalent to UDP in function, IPX provides
+ connectionless, unacknowledged datagram service over a variety of
+ physical media and protocols.
+
+ Although modifications have been made elsewhere in the NetWare
+ protocol suite, IPX is identical to the Xerox Internet Datagram
+ Protocol (IDP) [3]. The socket address space authority is
+ administered by Novell.
+
+ The use of SNMP over the UDP transport [4] is today the common mode
+ of operation in the Internet. This specification may be appropriate
+ for some environments in which UDP transport services are not
+
+
+
+Wormley & Bostock [Page 1]
+
+RFC 1298 SNMP over IPX February 1992
+
+
+ available. SNMP implementors should be aware that the choice of
+ underlying transport may have a significant impact on the
+ interoperability and ubiquity of the management capability in the
+ Internet. Considerations relevant to choosing a transport for use
+ with SNMP are described in [5].
+
+2. Specification
+
+ SNMP packets will always set the Packet Type field in the IPX header
+ to 4 (i.e., Packet Exchange Packet).
+
+2.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.
+
+2.2 Maximum Packet Length
+
+ Although SNMP does not require conformant implementations to accept
+ messages whose length exceed 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.
+
+2.3 The agent-addr Field for the Trap-PDU
+
+ The agent-addr field in a Trap-PDU emitted by an SNMP agent should
+ contain the IpAddress 0.0.0.0. An SNMP manager may ascertain the
+ source of the trap by querying the transport layer.
+
+2.4 IPX Transport Address Representation
+
+ There are occasions when it is necessary to represent a transport
+ service address in a MIB. For instance, the SNMP party MIB [6] 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.
+
+
+
+
+
+Wormley & Bostock [Page 2]
+
+RFC 1298 SNMP over IPX February 1992
+
+
+ RFC1298-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ enterprises FROM RFC1155-SMI;
+
+ novell OBJECT IDENTIFIER ::= { enterprises 23 }
+ transportDomains OBJECT IDENTIFIER ::= { novell 7 }
+
+ ipxTransportDomain OBJECT IDENTIFIER ::= { transportDomains 1 }
+
+ -- Authoritatively names the IPX Transport Domain
+
+ IpxTransportAddress ::= OCTET STRING (SIZE (12))
+
+ -- A textual convention denoting a transport service address in
+ -- the ipxTransportDomain. An IpxTransportAddress 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.
+
+ END
+
+3. 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
+
+
+
+Wormley & Bostock [Page 3]
+
+RFC 1298 SNMP over IPX February 1992
+
+
+ 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
+
+4. References
+
+ [1] Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple
+ Network Management Protocol (SNMP)", RFC 1157, SNMP Research,
+ Performance Systems International, Performance Systems
+ International, and MIT Laboratory for Computer Science, May 1990.
+
+ [2] Novell, Inc., "NetWare System Technical Interface Overview", June
+ 1989.
+
+ [3] Xerox System Integration Standard, "Internet Transport
+ Protocols", XSIS 028112, Xerox Corporation, December 1981.
+
+ [4] Postel, J., "User Datagram Protocol," RFC 768, USC/Information
+ Sciences Institute, 28 August 1980.
+
+ [5] Kastenholz, F., "SNMP Communications Services," RFC 1270,
+ Clearpoint Research Corporation, October 1991.
+
+ [6] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
+ Objects for Administration of SNMP Parties", RFC in preparation.
+
+5. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wormley & Bostock [Page 4]
+
+RFC 1298 SNMP over IPX February 1992
+
+
+6. Authors' Addresses
+
+ Raymond Brett Wormley
+ Novell, Inc.
+ 2180 Fortune Drive
+ Mail Stop F5-91-2
+ San Jose, CA 95131
+
+ Phone: 408 473 8208
+ EMail: bwormley@novell.com
+
+
+ Steve Bostock
+ Novell, Inc.
+ 2180 Fortune Drive
+ Mail Stop F5-91-2
+ San Jose, CA 95131
+
+ Phone: 408 473 8203
+ EMail: steveb@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wormley & Bostock [Page 5]
+ \ No newline at end of file