RFC 1298

SNMP over IPX 🎀

• RFC: 1298
• Authors: R. Wormley and S. Bostock, both at Novell, Inc. (full names in the Authors' Addresses section)
• Category: Informational. It provides information for the Internet community and does not specify an Internet standard.
• Date: February 1992
• Obsoletes / Updates: Neither is listed in this document.

---

Status of This Memo 📜

okay so this memo is information only for the Internet community. It is not a standard, and it's open for distribution with no limits 💖

Abstract 🦋

this memo sets up a way to wrap up Simple Network Management Protocol (SNMP) [1] packets so they can ride over the transport that the Internetwork Packet Exchange (IPX) protocol [2] gives you ✨

Editor's Note 🫶

as mentioned below and in reference [5], the editors strongly suggest that for interoperability, SNMP gets implemented over UDP/IP and not directly on media or other protocols (such as IPX) 🙈

1. Introduction ✨

so SNMP is the official network management protocol of the Internet, and it's honestly everywhere now. Developers both inside and outside the Internet community have adopted it, and it's giving synergy with all kinds of protocols and platforms 🌈

this memo is about running SNMP over IPX, which got super popular mostly because of Novell NetWare 💅 IPX works kind of like UDP in what it does. It gives you connectionless, unacknowledged datagram service across a bunch of different physical media and protocols.

IPX has been changed in some places across the NetWare protocol suite, but it's still identical to the Xerox Internet Datagram Protocol (IDP) [3]. Novell is the one that administers the socket address space authority, so that's their lane 👑

Running SNMP over UDP [4] is the common setup on the Internet right now. This specification might be a good fit for environments where UDP transport services aren't available. SNMP implementors should be aware that picking the underlying transport can seriously affect how interoperable and widespread the management capability is across the Internet. Considerations for choosing a transport for SNMP are described in [5] 🧚

2. Specification 🌸

SNMP packets will always set the Packet Type field in the IPX header to 4 (that's the 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). Trap-PDU messages go to socket 36880 (Destination Socket field set to hexadecimal 9010) 🎀

GetResponse-PDU messages get addressed to the IPX address and socket that the matching GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU came from. Reply to the sender, bestie 💌

2.2. Maximum Packet Length 📏

ngl this one is a little plot twist. SNMP doesn't require conformant implementations to accept messages whose length exceed 484 bytes. That said, it is recommended that implementations support a maximum SNMP message size of 546 bytes, which is the max size allowed under IPX. This limit is also the maximum packet length that's guaranteed to get through IPX routers that don't do fragmentation 🚀

implementors can go longer if they know the maximum. That depends on the intermediate routers and/or intermediate datalink layer protocols, so check what's in the middle first 🫶

2.3. The agent-addr Field for the Trap-PDU 🧚‍♀️

the agent-addr field in a Trap-PDU sent by an SNMP agent should contain the IpAddress 0.0.0.0. If an SNMP manager wants to figure out where the trap came from, it can ask the transport layer 💖

2.4. IPX Transport Address Representation 💎

sometimes you need to represent a transport service address inside a MIB, and that's where this comes in. The SNMP party MIB [6] uses an OBJECT IDENTIFIER to name the transport domain (IP, IPX, etc.) and an OCTET STRING to hold the address inside that domain. The definitions below are here for exactly that kind of 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 has the contact info for getting your hands on certain documents 💅

the full IPX description comes from Novell:

Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001

the IDP spec (part of XNS) is available 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. Yes, really. Handle with care 🙈

6. Authors' Addresses 💌

these are the two authors, both at Novell, Inc.:

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