SNMP over IPX
Carrying SNMP messages on Novell IPX networks.
Wormley, R. and S. Bostock, "SNMP over IPX", RFC 1298, DOI 10.17487/RFC1298, February 1992, <https://www.rfc-editor.org/info/rfc1298>.
@misc{rfc1298,
series = {Request for Comments},
number = 1298,
howpublished = {RFC 1298},
publisher = {RFC Editor},
doi = {10.17487/RFC1298},
url = {https://www.rfc-editor.org/info/rfc1298},
author = {R. Wormley and S. Bostock},
title = {{SNMP over IPX}},
pagetotal = 5,
year = 1992,
month = feb,
} RFC text
Contents
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
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.
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
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.
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
AI ELI5
On this page
§1The Problem
In the early 1990s, Novell NetWare was widely deployed in local area networks, yet it did not support the Internet Protocol. IPX (Internetwork Packet Exchange), Novell's connectionless datagram protocol, was roughly equivalent to UDP in function. Organizations running NetWare networks needed a way to manage devices on those networks using SNMP, the standard network management protocol.
This RFC specifies how to carry SNMP messages directly over IPX, allowing management stations to monitor SNMP agents on IPX networks. The specification assigns IPX socket addresses for SNMP operations, similar to how UDP port numbers are used in the Internet.
Novell networks didn't have UDP, but they had IPX, which does the same job. This shows how to send SNMP management commands through IPX.
§2Socket Assignments and Packet Types
SNMP agents listen on IPX socket 36879 (hexadecimal 900F) for GetRequest-PDU, GetNextRequest-PDU, and SetRequest-PDU messages. They listen on socket 36880 (hexadecimal 9010) for Trap-PDU messages sent by other agents.
GetResponse-PDU messages are addressed back to the socket and IPX address from which the original request came. All SNMP packets set the IPX packet type field to 4 (Packet Exchange Packet), indicating a standard IPX datagram. The SNMP message itself is encoded identically to UDP-based SNMP; only the transport layer changes.
SNMP uses mailboxes called sockets: 36879 for commands, 36880 for alerts. The replies go back to whoever sent the command.
§3Message Size and Compatibility
IPX supports a maximum datagram length of 546 bytes, which imposes a limit on SNMP message size. Although the SNMP specification itself allows messages to be as short as 484 bytes, this RFC recommends that implementations support the full 546-byte IPX limit. This maximum is also the packet size guaranteed to traverse IPX routers without fragmentation.
The agent-addr field in Trap-PDU messages emitted by SNMP agents running over IPX should contain 0.0.0.0. The management station can determine the source of the trap by querying the IPX transport layer directly. This is necessary because IPX addresses differ from IP addresses and there is no standard way to embed an IPX address in the agent-addr field.
IPX messages can be at most 546 bytes, so SNMP messages are limited to that size. When an agent sends an alert, it can't put its IPX address in the standard place, so the manager has to ask IPX where it came from.