Difference between revisions of "RFC1298"
imported>Admin (Created page with " Network Working Group R. Wormley Request for Comments: 1298 S. Bostock ...") |
|||
Line 1: | Line 1: | ||
− | |||
Line 9: | Line 8: | ||
Novell, Inc. | Novell, Inc. | ||
February 1992 | February 1992 | ||
− | |||
SNMP over IPX | SNMP over IPX | ||
− | |||
Status of this Memo | Status of this Memo | ||
− | |||
This memo provides information for the Internet community. It does | This memo provides information for the Internet community. It does | ||
not specify an Internet standard. Distribution of this memo is | not specify an Internet standard. Distribution of this memo is | ||
unlimited. | unlimited. | ||
− | |||
Abstract | Abstract | ||
− | |||
This memo defines a convention for encapsulating Simple Network | This memo defines a convention for encapsulating Simple Network | ||
Management Protocol (SNMP) [1] packets over the transport mechanism | Management Protocol (SNMP) [1] packets over the transport mechanism | ||
provided via the Internetwork Packet Exchange (IPX) protocol [2]. | provided via the Internetwork Packet Exchange (IPX) protocol [2]. | ||
− | |||
Editor's Note | Editor's Note | ||
− | |||
As stated below and in reference [5], it is strongly advised that for | As stated below and in reference [5], it is strongly advised that for | ||
interoperability, SNMP be implemented over UDP/IP and not directly on | interoperability, SNMP be implemented over UDP/IP and not directly on | ||
media or other protocols (such as IPX). | media or other protocols (such as IPX). | ||
− | + | == Introduction == | |
− | == Introduction == | ||
− | |||
The SNMP protocol has been specified as the official network | The SNMP protocol has been specified as the official network | ||
management protocol of the Internet. Its widespread acceptance and | management protocol of the Internet. Its widespread acceptance and | ||
Line 38: | Line 28: | ||
community, is fostering synergetic growth to a variety of protocols | community, is fostering synergetic growth to a variety of protocols | ||
and platforms. | and platforms. | ||
− | |||
This memo addresses the use of SNMP over the IPX protocol, which has | This memo addresses the use of SNMP over the IPX protocol, which has | ||
become quite widespread principally due to the popularity of Novell | become quite widespread principally due to the popularity of Novell | ||
Line 44: | Line 33: | ||
connectionless, unacknowledged datagram service over a variety of | connectionless, unacknowledged datagram service over a variety of | ||
physical media and protocols. | physical media and protocols. | ||
− | |||
Although modifications have been made elsewhere in the NetWare | Although modifications have been made elsewhere in the NetWare | ||
protocol suite, IPX is identical to the Xerox Internet Datagram | protocol suite, IPX is identical to the Xerox Internet Datagram | ||
Protocol (IDP) [3]. The socket address space authority is | Protocol (IDP) [3]. The socket address space authority is | ||
administered by Novell. | administered by Novell. | ||
− | |||
The use of SNMP over the UDP transport [4] is today the common mode | The use of SNMP over the UDP transport [4] is today the common mode | ||
of operation in the Internet. This specification may be appropriate | of operation in the Internet. This specification may be appropriate | ||
for some environments in which UDP transport services are not | for some environments in which UDP transport services are not | ||
+ | |||
+ | |||
Line 63: | Line 52: | ||
Internet. Considerations relevant to choosing a transport for use | Internet. Considerations relevant to choosing a transport for use | ||
with SNMP are described in [5]. | with SNMP are described in [5]. | ||
− | + | == Specification == | |
− | == Specification == | ||
− | |||
SNMP packets will always set the Packet Type field in the IPX header | SNMP packets will always set the Packet Type field in the IPX header | ||
to 4 (i.e., Packet Exchange Packet). | to 4 (i.e., Packet Exchange Packet). | ||
− | + | === Socket Assignments === | |
− | |||
− | |||
SNMP protocol entities will receive GetRequest-PDU, GetNextRequest- | SNMP protocol entities will receive GetRequest-PDU, GetNextRequest- | ||
PDU, and SetRequest-PDU messages on socket 36879 (Destination Socket | PDU, and SetRequest-PDU messages on socket 36879 (Destination Socket | ||
field set to hexadecimal 900F), and Trap-PDU messages on socket 36880 | field set to hexadecimal 900F), and Trap-PDU messages on socket 36880 | ||
(Destination Socket field set to hexadecimal 9010). | (Destination Socket field set to hexadecimal 9010). | ||
− | |||
GetResponse-PDU messages will be addressed to the IPX address and | GetResponse-PDU messages will be addressed to the IPX address and | ||
socket from which the corresponding GetRequest-PDU, GetNextRequest- | socket from which the corresponding GetRequest-PDU, GetNextRequest- | ||
PDU, or SetRequest-PDU originated. | PDU, or SetRequest-PDU originated. | ||
− | + | === Maximum Packet Length === | |
− | |||
− | |||
Although SNMP does not require conformant implementations to accept | Although SNMP does not require conformant implementations to accept | ||
messages whose length exceed 484 bytes, it is recommended that | messages whose length exceed 484 bytes, it is recommended that | ||
Line 90: | Line 72: | ||
lengths if the maximum is known, which depends on the intermediate | lengths if the maximum is known, which depends on the intermediate | ||
routers and/or intermediate datalink layer protocols. | routers and/or intermediate datalink layer protocols. | ||
− | + | === The agent-addr Field for the Trap-PDU === | |
− | |||
− | |||
The agent-addr field in a Trap-PDU emitted by an SNMP agent should | 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 | contain the IpAddress 0.0.0.0. An SNMP manager may ascertain the | ||
source of the trap by querying the transport layer. | source of the trap by querying the transport layer. | ||
− | + | === IPX Transport Address Representation === | |
− | |||
− | |||
There are occasions when it is necessary to represent a transport | There are occasions when it is necessary to represent a transport | ||
service address in a MIB. For instance, the SNMP party MIB [6] uses | service address in a MIB. For instance, the SNMP party MIB [6] uses | ||
Line 104: | Line 82: | ||
and an OCTET STRING to represent an address within that domain. The | and an OCTET STRING to represent an address within that domain. The | ||
following definitions are provided for use in such a scheme. | following definitions are provided for use in such a scheme. | ||
+ | |||
+ | |||
Line 112: | Line 92: | ||
RFC1298-MIB DEFINITIONS ::= BEGIN | RFC1298-MIB DEFINITIONS ::= BEGIN | ||
− | |||
IMPORTS | IMPORTS | ||
enterprises FROM RFC1155-SMI; | enterprises FROM RFC1155-SMI; | ||
− | |||
novell OBJECT IDENTIFIER ::= { enterprises 23 } | novell OBJECT IDENTIFIER ::= { enterprises 23 } | ||
transportDomains OBJECT IDENTIFIER ::= { novell 7 } | transportDomains OBJECT IDENTIFIER ::= { novell 7 } | ||
− | |||
ipxTransportDomain OBJECT IDENTIFIER ::= { transportDomains 1 } | ipxTransportDomain OBJECT IDENTIFIER ::= { transportDomains 1 } | ||
− | |||
-- Authoritatively names the IPX Transport Domain | -- Authoritatively names the IPX Transport Domain | ||
− | |||
IpxTransportAddress ::= OCTET STRING (SIZE (12)) | IpxTransportAddress ::= OCTET STRING (SIZE (12)) | ||
− | |||
-- A textual convention denoting a transport service address in | -- A textual convention denoting a transport service address in | ||
-- the ipxTransportDomain. An IpxTransportAddress is 12 octets | -- the ipxTransportDomain. An IpxTransportAddress is 12 octets | ||
-- long and comprises 3 fields, each in network-byte (high-low) | -- long and comprises 3 fields, each in network-byte (high-low) | ||
-- order. | -- order. | ||
− | |||
-- The first field is 4 octets long and contains the network | -- The first field is 4 octets long and contains the network | ||
-- number. | -- number. | ||
− | |||
-- The next field is 6 octets long and contains the physical | -- The next field is 6 octets long and contains the physical | ||
-- address of the node. Since IPX can run over a variety of | -- address of the node. Since IPX can run over a variety of | ||
Line 140: | Line 112: | ||
-- the field and the most significant octets should be set | -- the field and the most significant octets should be set | ||
-- to zero. | -- to zero. | ||
− | |||
-- The last field is 2 octets long and contains the socket | -- The last field is 2 octets long and contains the socket | ||
-- number. | -- number. | ||
− | |||
END | END | ||
− | + | == Document Procurement == | |
− | == Document Procurement == | ||
− | |||
This section provides contact points for procurement of selected | This section provides contact points for procurement of selected | ||
documents. | documents. | ||
− | |||
A complete description of IPX may be secured at the following | A complete description of IPX may be secured at the following | ||
address: | address: | ||
− | |||
Novell, Inc. | Novell, Inc. | ||
122 East 1700 South | 122 East 1700 South | ||
Line 159: | Line 125: | ||
Provo, Utah 84601 USA | Provo, Utah 84601 USA | ||
800 526 5463 | 800 526 5463 | ||
+ | |||
+ | |||
Line 165: | Line 133: | ||
Novell Part # 883-000780-001 | Novell Part # 883-000780-001 | ||
− | |||
The specification for IDP (part of XNS) may be ordered from: | The specification for IDP (part of XNS) may be ordered from: | ||
− | |||
Xerox System Institute | Xerox System Institute | ||
475 Oakmead Parkway | 475 Oakmead Parkway | ||
Line 173: | Line 139: | ||
Attn: Fonda Pallone | Attn: Fonda Pallone | ||
(415) 813-7164 | (415) 813-7164 | ||
+ | == 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. | ||
+ | == Security Considerations == | ||
+ | Security issues are not discussed in this memo. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
Line 203: | Line 175: | ||
− | |||
+ | == Authors' Addresses == | ||
Raymond Brett Wormley | Raymond Brett Wormley | ||
Novell, Inc. | Novell, Inc. | ||
Line 210: | Line 182: | ||
Mail Stop F5-91-2 | Mail Stop F5-91-2 | ||
San Jose, CA 95131 | San Jose, CA 95131 | ||
− | |||
Phone: 408 473 8208 | Phone: 408 473 8208 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Steve Bostock | Steve Bostock | ||
Line 220: | Line 190: | ||
Mail Stop F5-91-2 | Mail Stop F5-91-2 | ||
San Jose, CA 95131 | San Jose, CA 95131 | ||
− | |||
Phone: 408 473 8203 | Phone: 408 473 8203 | ||
EMail: [email protected] | EMail: [email protected] |
Revision as of 01:01, 23 September 2020
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).
Contents
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].
Specification
SNMP packets will always set the Packet Type field in the IPX header to 4 (i.e., Packet Exchange Packet).
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.
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.
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.
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
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
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.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
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]