RFC 1449 Transport Mappings for SNMPv2 April 19931. IntroductionA network management system contains: several (potentially
many) nodes, each with a processing entity, termed an agent,
which has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines both authentication and
authorization policies.
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to their
management information.
The management protocol, version 2 of the Simple Network
Management Protocol [1], may be used over a variety of
protocol suites. It is the purpose of this document to define
how the SNMPv2 maps onto an initial set of transport domains.
Other mappings may be defined in the future.
Although several mappings are defined, the mapping onto UDP is
the preferred mapping. As such, to provide for the greatest
level of interoperability, systems which choose to deploy
other mappings should also provide for proxy service to the
UDP mapping.
1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard
Network Management Framework, as described in RFCs 1155, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2 framework
(SNMPv2).
Case, McCloghrie, Rose & Waldbusser [Page 2]

RFC 1449 Transport Mappings for SNMPv2 April 19933. SNMPv2 over UDP
This is the preferred transport mapping.
3.1. Serialization
Each instance of a message is serialized onto a single UDP[2]
datagram, using the algorithm specified in Section 8.
3.2. Well-known Values
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on UDP port 161. Further, it is suggested that
notification sinks be configured to listen on UDP port 162.
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
Case, McCloghrie, Rose & Waldbusser [Page 7]

RFC 1449 Transport Mappings for SNMPv2 April 19934. SNMPv2 over OSI
This is an optional transport mapping.
4.1. Serialization
Each instance of a message is serialized onto a single TSDU
[3,4] for the OSI Connectionless-mode Transport Service
(CLTS), using the algorithm specified in Section 8.
4.2. Well-known Values
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on transport selector "snmp-l" (which consists of six
ASCII characters), when using a CL-mode network service to
realize the CLTS. Further, it is suggested that notification
sinks be configured to listen on transport selector "snmpt-l"
(which consists of seven ASCII characters) when using a CL-
mode network service to realize the CLTS. Similarly, when
using a CO-mode network service to realize the CLTS, the
suggested transport selectors are "snmp-o" and "snmpt-o", for
agent and notification sink, respectively.
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
Case, McCloghrie, Rose & Waldbusser [Page 8]

RFC 1449 Transport Mappings for SNMPv2 April 19935. SNMPv2 over DDP
This is an optional transport mapping.
5.1. Serialization
Each instance of a message is serialized onto a single DDP
datagram [5], using the algorithm specified in Section 8.
5.2. Well-known Values
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2
entities acting in an agent role listens on DDP socket number
8, whilst notification sinks listen on DDP socket number 9.
Although the partyTable gives transport addressing information
for an SNMPv2 party, administrators must configure their
SNMPv2 entities acting in an agent role to use NBP type "SNMP
Agent" (which consists of ten ASCII characters), whilst
notification sinks must be configured to use NBP type "SNMP
Trap Handler" (which consists of seventeen ASCII characters).
The NBP name for agents and notification sinks should be
stable - NBP names should not change any more often than the
IP address of a typical TCP/IP node. It is suggested that the
NBP name be stored in some form of stable storage.
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 484 octets. Implementation of larger values is
encouraged whenever possible.
5.3. Discussion of AppleTalk Addressing
The AppleTalk protocol suite has certain features not manifest
in the TCP/IP suite. AppleTalk's naming strategy and the
dynamic nature of address assignment can cause problems for
SNMPv2 entities that wish to manage AppleTalk networks.
TCP/IP nodes have an associated IP address which distinguishes
each from the other. In contrast, AppleTalk nodes generally
have no such characteristic. The network-level address, while
often relatively stable, can change at every reboot (or more
Case, McCloghrie, Rose & Waldbusser [Page 9]

RFC 1449 Transport Mappings for SNMPv2 April 1993
frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified by
a "name", rather than by an "address". Hence, all AppleTalk
nodes that implement this mapping are required to respond to
NBP lookups and confirms (e.g., implement the NBP protocol
stub), which guarantees that a mapping from NBP name to DDP
address will be possible.
In determining the SNMP identity to register for an SNMPv2
entity, it is suggested that the SNMP identity be a name which
is associated with other network services offered by the
machine.
NBP lookups, which are used to map NBP names into DDP
addresses, can cause large amounts of network traffic as well
as consume CPU resources. It is also the case that the
ability to perform an NBP lookup is sensitive to certain
network disruptions (such as zone table inconsistencies) which
would not prevent direct AppleTalk communications between two
SNMPv2 entities.
Thus, it is recommended that NBP lookups be used infrequently,
primarily to create a cache of name-to-address mappings.
These cached mappings should then be used for any further SNMP
traffic. It is recommended that SNMPv2 entities acting in a
manager role should maintain this cache between reboots. This
caching can help minimize network traffic, reduce CPU load on
the network, and allow for (some amount of) network trouble
shooting when the basic name-to-address translation mechanism
is broken.
5.3.1. How to Acquire NBP names
An SNMPv2 entity acting in a manager role may have a pre-
configured list of names of "known" SNMPv2 entities acting in
an agent role. Similarly, an SNMPv2 entity acting in a
manager role might interact with an operator. Finally, an
SNMPv2 entity acting in a manager role might communicate with
all SNMPv2 entities acting in an agent role in a set of zones
or networks.
Case, McCloghrie, Rose & Waldbusser [Page 10]

RFC 1449 Transport Mappings for SNMPv2 April 19935.3.2. When to Turn NBP names into DDP addresses
When an SNMPv2 entity uses a cache entry to address an SNMP
packet, it should attempt to confirm the validity mapping, if
the mapping hasn't been confirmed within the last T1 seconds.
This cache entry lifetime, T1, has a minimum, default value of
60 seconds, and should be configurable.
An SNMPv2 entity acting in a manager role may decide to prime
its cache of names prior to actually communicating with
another SNMPv2 entity. In general, it is expected that such
an entity may want to keep certain mappings "more current"
than other mappings, e.g., those nodes which represent the
network infrastructure (e.g., routers) may be deemed "more
important".
Note that an SNMPv2 entity acting in a manager role should not
prime its entire cache upon initialization - rather, it should
attempt resolutions over an extended period of time (perhaps
in some pre-determined or configured priority order). Each of
these resolutions might, in fact, be a wildcard lookup in a
given zone.
An SNMPv2 entity acting in an agent role must never prime its
cache. Such an entity should do NBP lookups (or confirms)
only when it needs to send an SNMP trap. When generating a
response, such an entity does not need to confirm a cache
entry.
5.3.3. How to Turn NBP names into DDP addresses
If the only piece of information available is the NBP name,
then an NBP lookup should be performed to turn that name into
a DDP address. However, if there is a piece of stale
information, it can be used as a hint to perform an NBP
confirm (which sends a unicast to the network address which is
presumed to be the target of the name lookup) to see if the
stale information is, in fact, still valid.
An NBP name to DDP address mapping can also be confirmed
implicitly using only SNMP transactions. For example, an
SNMPv2 entity acting in a manager role issuing a retrieval
operation could also retrieve the relevant objects from the
NBP group [6] for the SNMPv2 entity acting in an agent role.
Case, McCloghrie, Rose & Waldbusser [Page 11]

RFC 1449 Transport Mappings for SNMPv2 April 1993
This information can then be correlated with the source DDP
address of the response.
5.3.4. What if NBP is broken
Under some circumstances, there may be connectivity between
two SNMPv2 entities, but the NBP mapping machinery may be
broken, e.g.,
o the NBP FwdReq (forward NBP lookup onto local attached
network) mechanism might be broken at a router on the
other entity's network; or,
o the NBP BrRq (NBP broadcast request) mechanism might be
broken at a router on the entity's own network; or,
o NBP might be broken on the other entity's node.
An SNMPv2 entity acting in a manager role which is dedicated
to AppleTalk management might choose to alleviate some of
these failures by directly implementing the router portion of
NBP. For example, such an entity might already know all the
zones on the AppleTalk internet and the networks on which each
zone appears. Given an NBP lookup which fails, the entity
could send an NBP FwdReq to the network in which the agent was
last located. If that failed, the station could then send an
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to
each network number on that network. Of the above (single)
failures, this combined approach will solve the case where
either the local router's BrRq-to-FwdReq mechanism is broken
or the remote router's FwdReq-to-LkUp mechanism is broken.
Case, McCloghrie, Rose & Waldbusser [Page 12]

RFC 1449 Transport Mappings for SNMPv2 April 19936. SNMPv2 over IPX
This is an optional transport mapping.
6.1. Serialization
Each instance of a message is serialized onto a single IPX
datagram [7], using the algorithm specified in Section 8.
6.2. Well-known Values
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
Exchange Packet).
Although the partyTable gives transport addressing information
for an SNMPv2 party, it is suggested that administrators
configure their SNMPv2 entities acting in an agent role to
listen on IPX socket 36879 (900f hexadecimal). Further, it is
suggested that notification sinks be configured to listen on
IPX socket 36880 (9010 hexadecimal)
The partyTable also lists the maximum message size which a
SNMPv2 party is willing to accept. This value must be at
least 546 octets. Implementation of larger values is
encouraged whenever possible.
Case, McCloghrie, Rose & Waldbusser [Page 13]

RFC 1449 Transport Mappings for SNMPv2 April 19937. Proxy to SNMPv1
In order to provide proxy to community-based SNMP [8], some
definitions are necessary for both transport domains and
authentication protocols.
7.1. Transport Domain: rfc1157Domain
The transport domain, rfc1157Domain, indicates the transport
mapping for community-based SNMP messages defined in RFC 1157.
When a party's transport domain (partyTDomain) is
rfc1157Domain:
(1) the party's transport address (partyTAddress) shall be 6
octets long, the initial 4 octets containing the IP-
address in network-byte order, and the last two octets
containing the UDP port in network-byte order; and,
(2) the party's authentication protocol (partyAuthProtocol)
shall be rfc1157noAuth.
When a proxy relationship identifies a proxy destination party
which has rfc1157Domain as its transport domain:
(1) the proxy source party (contextSrcPartyIndex) and proxy
context (contextProxyContext) components of the proxy
relationship are irrelevant; and,
(2) Section 3.1 of [9] specifies the behavior of the proxy
agent.
7.2. Authentication Algorithm: rfc1157noAuthA party's authentication protocol (partyAuthProtocol)
specifies the protocol and mechanism by which the party
authenticates the integrity and origin of the SNMPv1 or SNMPv2
PDUs it generates. When a party's authentication protocol is
rfc1157noAuth:
(1) the party's public authentication key (partyAuthPublic),
clock (partyAuthClock), and lifetime (partyAuthLifetime)
are irrelevant; and,
Case, McCloghrie, Rose & Waldbusser [Page 14]

RFC 1449 Transport Mappings for SNMPv2 April 1993
(2) the party's private authentication key
(partySecretsAuthPrivate) shall be used as the 1157
community for the proxy destination, and shall be at
least one octet in length. (No maximum length is
specified.)
Note that when setting the party's private authentication key,
the exclusive-OR semantics specified in [10] still apply.
Case, McCloghrie, Rose & Waldbusser [Page 15]

RFC 1449 Transport Mappings for SNMPv2 April 19938. Serialization using the Basic Encoding Rules
When the Basic Encoding Rules [11] are used for serialization:
(1) When encoding the length field, only the definite form is
used; use of the indefinite form encoding is prohibited.
Note that when using the definite-long form, it is
permissible to use more than the minimum number of length
octets necessary to encode the length field.
(2) When encoding the value field, the primitive form shall
be used for all simple types, i.e., INTEGER, OCTET
STRING, OBJECT IDENTIFIER, and BIT STRING (either
IMPLICIT or explicit). The constructed form of encoding
shall be used only for structured types, i.e., a SEQUENCE
or an IMPLICIT SEQUENCE.
(3) When a BIT STRING is serialized, all named-bits are
transferred regardless of their truth-value. Further, if
the number of named-bits is not an integral multiple of
eight, then the fewest number of additional zero-valued
bits are transferred so that an integral multiple of
eight bits is transferred.
These restrictions apply to all aspects of ASN.1 encoding,
including the message wrappers, protocol data units, and the
data objects they contain.
Case, McCloghrie, Rose & Waldbusser [Page 16]