SNMP over IPX
How to carry SNMP network management messages over Novell NetWare's IPX transport.
Bostock, S., "SNMP over IPX", RFC 1420, DOI 10.17487/RFC1420, March 1993, <https://www.rfc-editor.org/info/rfc1420>.
@misc{rfc1420,
series = {Request for Comments},
number = 1420,
howpublished = {RFC 1420},
publisher = {RFC Editor},
doi = {10.17487/RFC1420},
url = {https://www.rfc-editor.org/info/rfc1420},
author = {S. Bostock},
title = {{SNMP over IPX}},
pagetotal = 4,
year = 1993,
month = mar,
} RFC text
Contents
Network Working Group S. Bostock
Request for Comments: 1420 Novell, Inc.
Obsoletes: 1298 March 1993
SNMP over IPX
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.
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].
1. 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.
2. 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).
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 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
2.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.
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
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. Acknowledgments
This specification was derived from RFC 1298, based on discussions in
the IETF's "SNMP over a Multiprotocol Internet" Working Group.
5. References
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[2] Novell, Inc., "NetWare System Technical Interface Overview", part
number 883-000780-001, June 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
[4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[5] Rose M., and K. McCloghrie, Editors, "Management Information Base
for Network Management of TCP/IP-based Internets", STD 17, RFC
1213, Hughes LAN Systems, Inc., Performance Systems
International, March 1991.
[6] Kastenholz, F., "SNMP Communications Services", RFC 1270,
Clearpoint Research Corporation, October 1991.
[7] Postel J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[8] Xerox System Integration Standard, "Internet Transport
Protocols", XSIS 028112, Xerox Corporation, December 1981.
6. Security Considerations
Security issues are not discussed in this memo.
7. 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
AI ELI5
On this page
§1Why Map SNMP onto IPX
The Simple Network Management Protocol (SNMP) is an integral part of the network management framework for TCP/IP-based internets. Its success led to use in networks that do not run TCP/IP. This RFC maps SNMP onto the Internetwork Packet Exchange (IPX) protocol used in Novell NetWare environments.
The preferred mapping for SNMP is onto UDP, so this specification is for environments where UDP is not available. It does not suggest that an agent in a mixed environment support more than one mapping, but management stations are strongly encouraged to support mappings onto all popular transports.
Normally the questions travel in one kind of envelope. This note is for places that only have another kind of envelope.
§2Packet Type and Sockets
Mapping is straightforward because IPX provides a datagram service very similar to IP/UDP. SNMP packets always set the Packet Type field in the IPX header to 4 (Packet Exchange Packet).
SNMP entities receive GetRequest-PDU, GetNextRequest-PDU and SetRequest-PDU messages on socket 36879 (hexadecimal 900F), and Trap-PDU messages on socket 36880 (hexadecimal 9010). A GetResponse-PDU goes back to the IPX address and socket the request came from.
Questions go to one numbered mailbox and alarm messages go to another. Answers go back to whoever asked.
| Socket | Hex | Messages received |
|---|---|---|
| 36879 | 900F | GetRequest-PDU, GetNextRequest-PDU, SetRequest-PDU |
| 36880 | 9010 | Trap-PDU |
§3Traps and Message Size
When a trap is sent over IPX, the agent-addr field in the Trap-PDU holds the IP address 0.0.0.0, and a manager can learn the source of the trap from the transport service.
SNMP does not require implementations to accept messages longer than 484 bytes, but this RFC recommends supporting a maximum SNMP message size of 546 bytes, the maximum allowed under IPX and the limit guaranteed to cross IPX routers that do not fragment. Implementors may use longer packets if the maximum is known.
Alarm messages do not have an IP address to put in the sender box, so a placeholder goes there. Messages should fit in a packet of about 546 bytes so routers do not break them.
§4Security
The RFC's security section is one sentence: security issues are not discussed in this memo. Readers who need protection should not assume this document provides any.
The note does not say anything about keeping messages safe.