draft-ietf-snmpv2-tm-ds-04.txt   rfc1906.txt 
Internet Draft Transport Mappings for SNMPv2 September 1995 Network Working Group SNMPv2 Working Group
Request for Comments: 1906 J. Case
Obsoletes: 1449 SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
Transport Mappings for Version 2 of the Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2) Simple Network Management Protocol (SNMPv2)
25 September 1995 | Status of this Memo
draft-ietf-snmpv2-tm-ds-04.txt |
Keith McCloghrie
Editor +
Cisco Systems, Inc.
kzm@cisco.com
Status of this Memo -
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, and Internet community, and requests discussion and suggestions for
its working groups. Note that other groups may also distribute working improvements. Please refer to the current edition of the "Internet
documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months Table of Contents
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the 1. Introduction ................................................ 2
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 1.1 A Note on Terminology ...................................... 2
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 2. Definitions ................................................. 3
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 3. SNMPv2 over UDP ............................................. 5
3.1 Serialization .............................................. 5
3.2 Well-known Values .......................................... 5
4. SNMPv2 over OSI ............................................. 6
4.1 Serialization .............................................. 6
4.2 Well-known Values .......................................... 6
5. SNMPv2 over DDP ............................................. 6
5.1 Serialization .............................................. 6
5.2 Well-known Values .......................................... 6
5.3 Discussion of AppleTalk Addressing ......................... 7
5.3.1 How to Acquire NBP names ................................. 8
5.3.2 When to Turn NBP names into DDP addresses ................ 8
5.3.3 How to Turn NBP names into DDP addresses ................. 8
5.3.4 What if NBP is broken .................................... 9
6. SNMPv2 over IPX ............................................. 9
6.1 Serialization .............................................. 9
6.2 Well-known Values .......................................... 9
7. Proxy to SNMPv1 ............................................. 10
8. Serialization using the Basic Encoding Rules ................ 10
8.1 Usage Example .............................................. 11
9. Security Considerations ..................................... 11
10. Editor's Address ........................................... 12
11. Acknowledgements ........................................... 12
12. References ................................................. 13
1. Introduction 1. Introduction
A management system contains: several (potentially many) nodes, each A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a management instrumentation; at least one management station; and, a
management protocol, used to convey management information between the management protocol, used to convey management information between
agents and management stations. Operations of the protocol are carried the agents and management stations. Operations of the protocol are
out under an administrative framework which defines authentication, carried out under an administrative framework which defines
authorization, access control, and privacy policies. authentication, authorization, access control, and privacy policies.
Management stations execute management applications which monitor and Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as hosts, control managed elements. Managed elements are devices such as
routers, terminal servers, etc., which are monitored and controlled via hosts, routers, terminal servers, etc., which are monitored and
access to their management information. controlled via access to their management information.
The management protocol, version 2 of the Simple Network Management The management protocol, version 2 of the Simple Network Management
Protocol [1], may be used over a variety of protocol suites. It is the Protocol [1], may be used over a variety of protocol suites. It is
purpose of this document to define how the SNMPv2 maps onto an initial the purpose of this document to define how the SNMPv2 maps onto an
set of transport domains. Other mappings may be defined in the future. initial set of transport domains. Other mappings may be defined in
the future.
Although several mappings are defined, the mapping onto UDP is the Although several mappings are defined, the mapping onto UDP is the
preferred mapping. As such, to provide for the greatest level of preferred mapping. As such, to provide for the greatest level of
interoperability, systems which choose to deploy other mappings should interoperability, systems which choose to deploy other mappings
also provide for proxy service to the UDP mapping. should also provide for proxy service to the UDP mapping.
1.1. A Note on Terminology 1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
termed the SNMP version 1 framework (SNMPv1). The current framework is | 15), and 1212 (STD 16), is termed the SNMP version 1 framework
termed the SNMP version 2 framework (SNMPv2), as described in [11]. | (SNMPv1). The current framework is termed the SNMP version 2
framework (SNMPv2).
2. Definitions 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
OBJECT-IDENTITY, snmpDomains, snmpProxys OBJECT-IDENTITY, snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
skipping to change at page 7, line 4 skipping to change at page 5, line 34
rfc1157Domain OBJECT-IDENTITY rfc1157Domain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The transport domain for SNMPv1 over UDP. The "The transport domain for SNMPv1 over UDP. The
corresponding transport address is of type SnmpUDPAddress." corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 } ::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete -- ::= { rfc1157Proxy 2 } this OID is obsolete
END END
3. SNMPv2 over UDP 3. SNMPv2 over UDP
This is the preferred transport mapping. This is the preferred transport mapping.
3.1. Serialization 3.1. Serialization
Each instance of a message is serialized (i.e., encoded according to the Each instance of a message is serialized (i.e., encoded according to
convention of [1]) onto a single UDP[2] datagram, using the algorithm the convention of [1]) onto a single UDP[2] datagram, using the
specified in Section 8. algorithm specified in Section 8.
3.2. Well-known Values 3.2. Well-known Values
It is suggested that administrators configure their SNMPv2 entities It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on UDP port 161. Further, it is 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 suggested that notification sinks be configured to listen on UDP port
162. 162.
When an SNMPv2 entity uses this transport mapping, it must be capable of When an SNMPv2 entity uses this transport mapping, it must be capable
accepting messages that are at least 484 octets in size. Implementation of accepting messages that are at least 484 octets in size.
of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
4. SNMPv2 over OSI 4. SNMPv2 over OSI
This is an optional transport mapping. This is an optional transport mapping.
4.1. Serialization 4.1. Serialization
Each instance of a message is serialized onto a single TSDU [3,4] for Each instance of a message is serialized onto a single TSDU [3,4] for
the OSI Connectionless-mode Transport Service (CLTS), using the the OSI Connectionless-mode Transport Service (CLTS), using the
algorithm specified in Section 8. algorithm specified in Section 8.
4.2. Well-known Values 4.2. Well-known Values
It is suggested that administrators configure their SNMPv2 entities It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on transport selector "snmp-l" (which acting in an agent role to listen on transport selector "snmp-l"
consists of six ASCII characters), when using a CL-mode network service (which consists of six ASCII characters), when using a CL-mode
to realize the CLTS. Further, it is suggested that notification sinks network service to realize the CLTS. Further, it is suggested that
be configured to listen on transport selector "snmpt-l" (which consists notification sinks be configured to listen on transport selector
of seven ASCII characters, six letters and a hyphen) when using a CL- "snmpt-l" (which consists of seven ASCII characters, six letters and
mode network service to realize the CLTS. Similarly, when using a CO- a hyphen) when using a CL-mode network service to realize the CLTS.
mode network service to realize the CLTS, the suggested transport Similarly, when using a CO-mode network service to realize the CLTS,
selectors are "snmp-o" and "snmpt-o", for agent and notification sink, the suggested transport selectors are "snmp-o" and "snmpt-o", for
respectively. agent and notification sink, respectively.
When an SNMPv2 entity uses this transport mapping, it must be capable of When an SNMPv2 entity uses this transport mapping, it must be capable
accepting messages that are at least 484 octets in size. Implementation of accepting messages that are at least 484 octets in size.
of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
5. SNMPv2 over DDP 5. SNMPv2 over DDP
This is an optional transport mapping. This is an optional transport mapping.
5.1. Serialization 5.1. Serialization
Each instance of a message is serialized onto a single DDP datagram [5], Each instance of a message is serialized onto a single DDP datagram
using the algorithm specified in Section 8. [5], using the algorithm specified in Section 8.
5.2. Well-known Values 5.2. Well-known Values
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities
acting in an agent role listens on DDP socket number 8, whilst acting in an agent role listens on DDP socket number 8, whilst
notification sinks listen on DDP socket number 9. notification sinks listen on DDP socket number 9.
Administrators must configure their SNMPv2 entities acting in an agent Administrators must configure their SNMPv2 entities acting in an
role to use NBP type "SNMP Agent" (which consists of ten ASCII agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
characters), whilst notification sinks must be configured to use NBP characters), whilst notification sinks must be configured to use NBP
type "SNMP Trap Handler" (which consists of seventeen ASCII characters). type "SNMP Trap Handler" (which consists of seventeen ASCII
characters).
The NBP name for agents and notification sinks should be stable - NBP 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 names should not change any more often than the IP address of a
TCP/IP node. It is suggested that the NBP name be stored in some form typical TCP/IP node. It is suggested that the NBP name be stored in
of stable storage. some form of stable storage.
When an SNMPv2 entity uses this transport mapping, it must be capable of When an SNMPv2 entity uses this transport mapping, it must be capable
accepting messages that are at least 484 octets in size. Implementation of accepting messages that are at least 484 octets in size.
of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
5.3. Discussion of AppleTalk Addressing 5.3. Discussion of AppleTalk Addressing
The AppleTalk protocol suite has certain features not manifest in the The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish to address assignment can cause problems for SNMPv2 entities that wish
manage AppleTalk networks. TCP/IP nodes have an associated IP address to manage AppleTalk networks. TCP/IP nodes have an associated IP
which distinguishes each from the other. In contrast, AppleTalk nodes address which distinguishes each from the other. In contrast,
generally have no such characteristic. The network-level address, while AppleTalk nodes generally have no such characteristic. The network-
often relatively stable, can change at every reboot (or more level address, while often relatively stable, can change at every
frequently). reboot (or more frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified by a "name", Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
rather than by an "address". Hence, all AppleTalk nodes that implement "name", rather than by an "address". Hence, all AppleTalk nodes that
this mapping are required to respond to NBP lookups and confirms (e.g., implement this mapping are required to respond to NBP lookups and
implement the NBP protocol stub), which guarantees that a mapping from confirms (e.g., implement the NBP protocol stub), which guarantees
NBP name to DDP address will be possible. 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 In determining the SNMP identity to register for an SNMPv2 entity, it
suggested that the SNMP identity be a name which is associated with is suggested that the SNMP identity be a name which is associated
other network services offered by the machine. with other network services offered by the machine.
NBP lookups, which are used to map NBP names into DDP addresses, can 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. cause large amounts of network traffic as well as consume CPU
It is also the case that the ability to perform an NBP lookup is resources. It is also the case that the ability to perform an NBP
sensitive to certain network disruptions (such as zone table lookup is sensitive to certain network disruptions (such as zone
inconsistencies) which would not prevent direct AppleTalk communications table inconsistencies) which would not prevent direct AppleTalk
between two SNMPv2 entities. communications between two SNMPv2 entities.
Thus, it is recommended that NBP lookups be used infrequently, primarily Thus, it is recommended that NBP lookups be used infrequently,
to create a cache of name-to-address mappings. These cached mappings primarily to create a cache of name-to-address mappings. These
should then be used for any further SNMP traffic. It is recommended cached mappings should then be used for any further SNMP traffic. It
that SNMPv2 entities acting in a manager role should maintain this cache is recommended that SNMPv2 entities acting in a manager role should
between reboots. This caching can help minimize network traffic, reduce maintain this cache between reboots. This caching can help minimize
CPU load on the network, and allow for (some amount of) network trouble network traffic, reduce CPU load on the network, and allow for (some
shooting when the basic name-to-address translation mechanism is broken. amount of) network trouble shooting when the basic name-to-address
translation mechanism is broken.
5.3.1. How to Acquire NBP names 5.3.1. How to Acquire NBP names
An SNMPv2 entity acting in a manager role may have a pre-configured list An SNMPv2 entity acting in a manager role may have a pre-configured
of names of "known" SNMPv2 entities acting in an agent role. Similarly, list of names of "known" SNMPv2 entities acting in an agent role.
an SNMPv2 entity acting in a manager role might interact with an Similarly, an SNMPv2 entity acting in a manager role might interact
operator. Finally, an SNMPv2 entity acting in a manager role might with an operator. Finally, an SNMPv2 entity acting in a manager role
communicate with all SNMPv2 entities acting in an agent role in a set of might communicate with all SNMPv2 entities acting in an agent role in
zones or networks. a set of zones or networks.
5.3.2. When to Turn NBP names into DDP addresses 5.3.2. When to Turn NBP names into DDP addresses
When an SNMPv2 entity uses a cache entry to address an SNMP packet, it When an SNMPv2 entity uses a cache entry to address an SNMP packet,
should attempt to confirm the validity mapping, if the mapping hasn't it should attempt to confirm the validity mapping, if the mapping
been confirmed within the last T1 seconds. This cache entry lifetime, hasn't been confirmed within the last T1 seconds. This cache entry
T1, has a minimum, default value of 60 seconds, and should be lifetime, T1, has a minimum, default value of 60 seconds, and should
configurable. be configurable.
An SNMPv2 entity acting in a manager role may decide to prime its cache An SNMPv2 entity acting in a manager role may decide to prime its
of names prior to actually communicating with another SNMPv2 entity. In cache of names prior to actually communicating with another SNMPv2
general, it is expected that such an entity may want to keep certain entity. In general, it is expected that such an entity may want to
mappings "more current" than other mappings, e.g., those nodes which keep certain mappings "more current" than other mappings, e.g., those
represent the network infrastructure (e.g., routers) may be deemed "more nodes which represent the network infrastructure (e.g., routers) may
important". be deemed "more important".
Note that an SNMPv2 entity acting in a manager role should not prime its Note that an SNMPv2 entity acting in a manager role should not prime
entire cache upon initialization - rather, it should attempt resolutions its entire cache upon initialization - rather, it should attempt
over an extended period of time (perhaps in some pre-determined or resolutions over an extended period of time (perhaps in some pre-
configured priority order). Each of these resolutions might, in fact, determined or configured priority order). Each of these resolutions
be a wildcard lookup in a given zone. might, in fact, be a wildcard lookup in a given zone.
An SNMPv2 entity acting in an agent role must never prime its cache. 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 Such an entity should do NBP lookups (or confirms) only when it needs
send an SNMP trap. When generating a response, such an entity does not to send an SNMP trap. When generating a response, such an entity
need to confirm a cache entry. does not need to confirm a cache entry.
5.3.3. How to Turn NBP names into DDP addresses 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 If the only piece of information available is the NBP name, then an
lookup should be performed to turn that name into a DDP address. 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 However, if there is a piece of stale information, it can be used as
hint to perform an NBP confirm (which sends a unicast to the network a hint to perform an NBP confirm (which sends a unicast to the
address which is presumed to be the target of the name lookup) to see if network address which is presumed to be the target of the name
the stale information is, in fact, still valid. lookup) to see if the stale information is, in fact, still valid.
An NBP name to DDP address mapping can also be confirmed implicitly An NBP name to DDP address mapping can also be confirmed implicitly
using only SNMP transactions. For example, an SNMPv2 entity acting in a using only SNMP transactions. For example, an SNMPv2 entity acting
manager role issuing a retrieval operation could also retrieve the in a manager role issuing a retrieval operation could also retrieve
relevant objects from the NBP group [6] for the SNMPv2 entity acting in the relevant objects from the NBP group [6] for the SNMPv2 entity
an agent role. This information can then be correlated with the source acting in an agent role. This information can then be correlated
DDP address of the response. with the source DDP address of the response.
5.3.4. What if NBP is broken 5.3.4. What if NBP is broken
Under some circumstances, there may be connectivity between two SNMPv2 Under some circumstances, there may be connectivity between two
entities, but the NBP mapping machinery may be broken, e.g., SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,
o the NBP FwdReq (forward NBP lookup onto local attached network) o the NBP FwdReq (forward NBP lookup onto local attached network)
mechanism might be broken at a router on the other entity's mechanism might be broken at a router on the other entity's
network; or, network; or,
o the NBP BrRq (NBP broadcast request) mechanism might be broken at a o the NBP BrRq (NBP broadcast request) mechanism might be broken
router on the entity's own network; or, at a router on the entity's own network; or,
o NBP might be broken on the other entity's node. o NBP might be broken on the other entity's node.
An SNMPv2 entity acting in a manager role which is dedicated to An SNMPv2 entity acting in a manager role which is dedicated to
AppleTalk management might choose to alleviate some of these failures by AppleTalk management might choose to alleviate some of these failures
directly implementing the router portion of NBP. For example, such an by directly implementing the router portion of NBP. For example,
entity might already know all the zones on the AppleTalk internet and such an entity might already know all the zones on the AppleTalk
the networks on which each zone appears. Given an NBP lookup which internet and the networks on which each zone appears. Given an NBP
fails, the entity could send an NBP FwdReq to the network in which the lookup which fails, the entity could send an NBP FwdReq to the
agent was last located. If that failed, the station could then send an network in which the agent was last located. If that failed, the
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each station could then send an NBP LkUp (NBP lookup packet) as a directed
network number on that network. Of the above (single) failures, this (DDP) multicast to each network number on that network. Of the above
combined approach will solve the case where either the local router's (single) failures, this combined approach will solve the case where
BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp either the local router's BrRq-to-FwdReq mechanism is broken or the
mechanism is broken. remote router's FwdReq-to-LkUp mechanism is broken.
6. SNMPv2 over IPX 6. SNMPv2 over IPX
This is an optional transport mapping. This is an optional transport mapping.
6.1. Serialization 6.1. Serialization
Each instance of a message is serialized onto a single IPX datagram [7], Each instance of a message is serialized onto a single IPX datagram
using the algorithm specified in Section 8. [7], using the algorithm specified in Section 8.
6.2. Well-known Values 6.2. Well-known Values
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
Protocol). Exchange Protocol).
It is suggested that administrators configure their SNMPv2 entities It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on IPX socket 36879 (900f acting in an agent role to listen on IPX socket 36879 (900f
hexadecimal). Further, it is suggested that notification sinks be hexadecimal). Further, it is suggested that notification sinks be
configured to listen on IPX socket 36880 (9010 hexadecimal) configured to listen on IPX socket 36880 (9010 hexadecimal)
When an SNMPv2 entity uses this transport mapping, it must be capable of When an SNMPv2 entity uses this transport mapping, it must be capable
accepting messages that are at least 546 octets in size. Implementation of accepting messages that are at least 546 octets in size.
of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
7. Proxy to SNMPv1 7. Proxy to SNMPv1
In order to provide proxy to SNMPv1 [8], it may be useful to define a In order to provide proxy to SNMPv1 [8], it may be useful to define a
transport domain, rfc1157Domain, which indicates the transport mapping transport domain, rfc1157Domain, which indicates the transport
for SNMP messages as defined in RFC 1157. Section 3.1 of [9] specifies mapping for SNMP messages as defined in RFC 1157. Section 3.1 of [9]
the behavior of the proxy agent. specifies the behavior of the proxy agent.
8. Serialization using the Basic Encoding Rules 8. Serialization using the Basic Encoding Rules
When the Basic Encoding Rules [10] are used for serialization: When the Basic Encoding Rules [10] are used for serialization:
(1) When encoding the length field, only the definite form is used; use (1) When encoding the length field, only the definite form is used; use
of the indefinite form encoding is prohibited. Note that when of the indefinite form encoding is prohibited. Note that when
using the definite-long form, it is permissible to use more than using the definite-long form, it is permissible to use more than
the minimum number of length octets necessary to encode the length the minimum number of length octets necessary to encode the length
field. field.
(2) When encoding the value field, the primitive form shall be used for (2) When encoding the value field, the primitive form shall be used for
all simple types, i.e., INTEGER, OCTET STRING, and OBJECT all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
IDENTIFIER (either IMPLICIT or explicit). The constructed form of IDENTIFIER (either IMPLICIT or explicit). The constructed form of
encoding shall be used only for structured types, i.e., a SEQUENCE encoding shall be used only for structured types, i.e., a SEQUENCE
or an IMPLICIT SEQUENCE. or an IMPLICIT SEQUENCE.
(3) When encoding an object whose syntax is described using the BITS (3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to the last bit, are placed in with the first bit and proceeding to the last bit, are placed in
bits 8 to 1 of the first octet, followed by bits 8 to 1 of each bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
subsequent octet in turn, followed by as many bits as are needed of subsequent octet in turn, followed by as many bits as are needed of
the final subsequent octet, commencing with bit 8. Remaining bits, the final subsequent octet, commencing with bit 8. Remaining bits,
if any, of the final octet are set to zero on generation and if any, of the final octet are set to zero on generation and
ignored on receipt. ignored on receipt.
These restrictions apply to all aspects of ASN.1 encoding, including the These restrictions apply to all aspects of ASN.1 encoding, including
message wrappers, protocol data units, and the data objects they the message wrappers, protocol data units, and the data objects they
contain. contain.
8.1. Usage Example 8.1. Usage Example
As an example of applying the Basic Encoding Rules, suppose one wanted As an example of applying the Basic Encoding Rules, suppose one
to encode an instance of the GetBulkRequest-PDU [1]: wanted to encode an instance of the GetBulkRequest-PDU [1]:
[5] IMPLICIT SEQUENCE { [5] IMPLICIT SEQUENCE {
request-id 1414684022, request-id 1414684022,
non-repeaters 1, non-repeaters 1,
max-repetitions 2, max-repetitions 2,
variable-bindings { variable-bindings {
{ name sysUpTime, { name sysUpTime,
value { unspecified NULL } }, value { unspecified NULL } },
{ name ipNetToMediaPhysAddress, { name ipNetToMediaPhysAddress,
value { unspecified NULL } }, value { unspecified NULL } },
skipping to change at page 16, line 41 skipping to change at page 11, line 41
SEQUENCE 30 0b SEQUENCE 30 0b
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00 NULL 05 00
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00 NULL 05 00
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00 NULL 05 00
Note that the initial SEQUENCE is not encoded using the minimum number Note that the initial SEQUENCE is not encoded using the minimum
of length octets. (The first octet of the length, 82, indicates that number of length octets. (The first octet of the length, 82,
the length of the content is encoded in the next two octets.) indicates that the length of the content is encoded in the next two
9. Acknowledgements octets.)
This document is the result of significant work by the four major 9. Security Considerations
contributors:
Jeffrey Case (SNMP Research, case@snmp.com) Security issues are not discussed in this memo.
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Steven Waldbusser (International Network Services, stevew@uni.ins.com)
In addition, the contributions of the SNMPv2 Working Group are 10. Editor's Address
acknowledged. In particular, a special thanks is extended for the
contributions of: Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
EMail: kzm@cisco.com
11. Acknowledgements
This document is the result of significant work by the four major
contributors:
Jeffrey D. Case (SNMP Research, case@snmp.com)
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Steven Waldbusser (International Network Services, stevew@uni.ins.com)
In addition, the contributions of the SNMPv2 Working Group are
acknowledged. In particular, a special thanks is extended for the
contributions of:
Alexander I. Alten (Novell) Alexander I. Alten (Novell)
Dave Arneson (Cabletron) Dave Arneson (Cabletron)
Uri Blumenthal (IBM) Uri Blumenthal (IBM)
Doug Book (Chipcom) Doug Book (Chipcom)
Kim Curran (Bell-Northern Research) Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems) Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex) Maria Greene (Ascom Timeplex)
Iain Hanson (Digital) Iain Hanson (Digital)
Dave Harrington (Cabletron) Dave Harrington (Cabletron)
skipping to change at page 18, line 5 skipping to change at page 13, line 9
Dave Perkins (Peer Networks) Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks) Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum) Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue) Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems) Jon Saperia (BGS Systems)
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore) Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research) Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM) Bert Wijnen (IBM)
10. References 12. References
[1] McCloghrie, K., Editor, | [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
"Protocol Operations for Version 2 of the Simple Network Management S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980. USC/Information Sciences Institute, August 1980.
[3] Information processing systems - Open Systems Interconnection - [3] Information processing systems - Open Systems Interconnection -
Transport Service Definition, International Organization for Transport Service Definition, International Organization for
Standardization. International Standard 8072, (June, 1986). Standardization. International Standard 8072, (June, 1986).
[4] Information processing systems - Open Systems Interconnection - [4] Information processing systems - Open Systems Interconnection -
Transport Service Definition - Addendum 1: Connectionless-mode Transport Service Definition - Addendum 1: Connectionless-mode
skipping to change at page 18, line 32 skipping to change at page 13, line 36
[5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second [5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
edition). Addison-Wesley, 1990. edition). Addison-Wesley, 1990.
[6] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, [6] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
Carnegie Mellon University, July 1991. Carnegie Mellon University, July 1991.
[7] Network System Technical Interface Overview. Novell, Inc, (June, [7] Network System Technical Interface Overview. Novell, Inc, (June,
1989). 1989).
[8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May Systems International, MIT Laboratory for Computer Science, May
1990. 1990.
[9] McCloghrie, K., Editor, | [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
"Coexistence between Version 1 and Version 2 of the Internet- S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
standard Network Management Framework", Internet Draft, Cisco | Internet-standard Network Management Framework", RFC 1908,
Systems, September 1995. | January 1996.
[10] Information processing systems - Open Systems Interconnection - [10] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1), International Organization for Standardization. One (ASN.1), International Organization for Standardization.
International Standard 8825, December 1987. International Standard 8825, December 1987.
[11] McCloghrie, K., Editor, "Introduction to Version 2 of the +
Internet-standard Network Management Framework", Internet Draft, +
Cisco Systems, September 1995. +
11. Security Considerations
Security issues are not discussed in this memo.
12. Editor's Address
Keith McCloghrie -
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
Email: kzm@cisco.com
Table of Contents -
1 Introduction .................................................... 2
1.1 A Note on Terminology ......................................... 2
2 Definitions ..................................................... 3
3 SNMPv2 over UDP ................................................. 7
3.1 Serialization ................................................. 7
3.2 Well-known Values ............................................. 7
4 SNMPv2 over OSI ................................................. 8
4.1 Serialization ................................................. 8
4.2 Well-known Values ............................................. 8
5 SNMPv2 over DDP ................................................. 9
5.1 Serialization ................................................. 9
5.2 Well-known Values ............................................. 9
5.3 Discussion of AppleTalk Addressing ............................ 9
5.3.1 How to Acquire NBP names .................................... 10
5.3.2 When to Turn NBP names into DDP addresses ................... 10
5.3.3 How to Turn NBP names into DDP addresses .................... 11
5.3.4 What if NBP is broken ....................................... 11
6 SNMPv2 over IPX ................................................. 13
6.1 Serialization ................................................. 13
6.2 Well-known Values ............................................. 13
7 Proxy to SNMPv1 ................................................. 14
8 Serialization using the Basic Encoding Rules .................... 15
8.1 Usage Example ................................................. 16
9 Acknowledgements ................................................ 17
10 References ..................................................... 18
11 Security Considerations ........................................ 19
12 Editor's Address ............................................... 19
 End of changes. 61 change blocks. 
237 lines changed or deleted 281 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/