SNMP over IPX (Obsoleted)

Network Working Group                                         R. Wormley
Request for Comments: 1298                                    S. Bostock
                                                            Novell, Inc.
                                                           February 1992


                             <span class="h1">SNMP over IPX</span>

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) [<a href="#ref-1" title=""A Simple Network Management Protocol (SNMP)"">1</a>] packets over the transport mechanism
   provided via the Internetwork Packet Exchange (IPX) protocol [<a href="#ref-2" title=""NetWare System Technical Interface Overview"">2</a>].

Editor's Note

   As stated below and in reference [<a href="#ref-5" title=""SNMP Communications Services,"">5</a>], it is strongly advised that for
   interoperability, SNMP be implemented over UDP/IP and not directly on
   media or other protocols (such as IPX).

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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) [<a href="#ref-3" title=""Internet Transport Protocols"">3</a>].  The socket address space authority is
   administered by Novell.

   The use of SNMP over the UDP transport [<a href="#ref-4" title=""User Datagram Protocol,"">4</a>] 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



<span class="grey">Wormley & Bostock                                               [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc1298">RFC 1298</a>                     SNMP over IPX                 February 1992</span>


   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 [<a href="#ref-5" title=""SNMP Communications Services,"">5</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Specification</span>

   SNMP packets will always set the Packet Type field in the IPX header
   to 4 (i.e., Packet Exchange Packet).

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>  Socket Assignments</span>

   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.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>  Maximum Packet Length</span>

   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.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>  The agent-addr Field for the Trap-PDU</span>

   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.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>  IPX Transport Address Representation</span>

   There are occasions when it is necessary to represent a transport
   service address in a MIB.  For instance, the SNMP party MIB [<a href="#ref-6" title=""Definitions of Managed Objects for Administration of SNMP Parties"">6</a>] 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.





<span class="grey">Wormley & Bostock                                               [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc1298">RFC 1298</a>                     SNMP over IPX                 February 1992</span>


 <a href="./rfc1298">RFC1298</a>-MIB DEFINITIONS ::= BEGIN

    IMPORTS
      enterprises         FROM <a href="./rfc1155">RFC1155</a>-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 [<a href="#ref-2" title=""NetWare System Technical Interface Overview"">2</a>], 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

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Document Procurement</span>

   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



<span class="grey">Wormley & Bostock                                               [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc1298">RFC 1298</a>                     SNMP over IPX                 February 1992</span>


       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

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  References</span>

   [<a id="ref-1">1</a>] Case J., Fedor M., Schoffstall M., and J. Davin, "A Simple
       Network Management Protocol (SNMP)", <a href="./rfc1157">RFC 1157</a>, SNMP Research,
       Performance Systems International, Performance Systems
       International, and MIT Laboratory for Computer Science, May 1990.

   [<a id="ref-2">2</a>] Novell, Inc., "NetWare System Technical Interface Overview", June
       1989.

   [<a id="ref-3">3</a>] Xerox System Integration Standard, "Internet Transport
       Protocols", XSIS 028112, Xerox Corporation, December 1981.

   [<a id="ref-4">4</a>] Postel, J., "User Datagram Protocol," <a href="./rfc768">RFC 768</a>, USC/Information
       Sciences Institute, 28 August 1980.

   [<a id="ref-5">5</a>] Kastenholz, F., "SNMP Communications Services," <a href="./rfc1270">RFC 1270</a>,
       Clearpoint Research Corporation, October 1991.

   [<a id="ref-6">6</a>] McCloghrie, K., Davin, J., and J. Galvin, "Definitions of Managed
       Objects for Administration of SNMP Parties", RFC in preparation.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   Security issues are not discussed in this memo.
















<span class="grey">Wormley & Bostock                                               [Page 4]</span>

<span id="page-5" ></span>
<span class="grey"><a href="./rfc1298">RFC 1298</a>                     SNMP over IPX                 February 1992</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Authors' Addresses</span>

   Raymond Brett Wormley
   Novell, Inc.
   2180 Fortune Drive
   Mail Stop F5-91-2
   San Jose, CA 95131

   Phone: 408 473 8208
   EMail: [email protected]


   Steve Bostock
   Novell, Inc.
   2180 Fortune Drive
   Mail Stop F5-91-2
   San Jose, CA 95131

   Phone: 408 473 8203
   EMail: [email protected]































Wormley & Bostock                                               [Page 5]