💾 Archived View for gmi.noulin.net › rfc › rfc2089.gmi captured on 2024-08-25 at 03:34:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Obsoleted by:
Network Working Group B. Wijnen
Request for Comments: 2089 IBM
Category: Informational D. Levi
SNMP Research, Inc
January 1997
V2ToV1
Mapping SNMPv2 onto SNMPv1
within a bi-lingual SNMP agent
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The goal of this memo is to document a common way of mapping an
SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP
agent (one that supports both SNMPv1 and SNMPv2).
Table of Contents
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Mapping SNMPv2 into SNMPv1 . . . . . . . . . . . . . . . . 2
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status . . . 3
2.2 Mapping SNMPv2 exceptions into SNMPv1 . . . . . . . . . . 3
2.3 Mapping noSuchObject and noSuchInstance . . . . . . . . . 4
2.4 Mapping endOfMibView . . . . . . . . . . . . . . . . . . . 5
2.5 Mapping SNMPv2 SMI into SNMPv1 . . . . . . . . . . . . . . 5
3.0 Processing SNMPv1 requests . . . . . . . . . . . . . . . . 6
3.1 Processing an SNMPv1 GET request . . . . . . . . . . . . . 6
3.2 Processing an SNMPv1 GETNEXT request . . . . . . . . . . . 7
3.3 Processing an outgoing SNMPv2 trap . . . . . . . . . . . . 8
4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
5.0 References . . . . . . . . . . . . . . . . . . . . . . . . 10
6.0 Security Considerations . . . . . . . . . . . . . . . . . 10
7.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background Information . . . . . . . . . . . . . 12
A.1 Mapping of error-status Values . . . . . . . . . . . . . 12
A.2 SNMPv1 traps without Counter64 varBinds. . . . . . . . . 12
Wijnen & Levi Informational [Page 1]
RFC 2089 V2toV1 January 1997
1.0 Introduction
We now have the SNMPv1 protocol (RFC1157 [1]) as a full standard and
the SNMPv2 protocol (RFC1905 [1]) as a DRAFT standard. It can be
expected that many agent implementations will support both SNMPv1 and
SNMPv2 requests coming from SNMP management entities. In many cases
the underlying instrumentation will be implemented using the new
SNMPv2 SMI and SNMPv2 protocol. The SNMP engine then gets the task
to ensure that any SNMPv2 response data coming from such SNMPv2
compliant instrumentation gets converted to a proper SNMPv1 response
if the original request came in as an SNMPv1 request. The SNMP
engine should also deal with mapping SNMPv2 traps which are generated
by an application or by the SNMPv2 compliant instrumentation into
SNMPv1 traps if the agent has been configured to send traps to an
SNMPv1 manager.
It seems beneficial if all such agents do this mapping in the same
way. This document describes such a mapping based on discussions and
perceived consensus on the various mailing lists. The authors of
this document have also compared their own implementations of these
mappings. They had a few minor differences and decided to make their
implementation behave the same and document this mapping so others
can benefit from it.
We recommend that all agents implement this same mapping.
Note that the mapping described in this document should also be
followed by SNMP proxies that provide a mapping between SNMPv1
management applications and SNMPv2 agents.
2.0 Mapping SNMPv2 into SNMPv1
These are the type of mappings that we need:
o Mapping of the SNMPv2 error-status into SNMPv1 error-status
o Mapping of the SNMPv2 exceptions into SNMPv1 error-status
o Skipping object instances that have a non-SNMPv1 Syntax
(specifically Counter64)
o Mapping of SNMPv2 traps into SNMPv1 traps
Wijnen & Levi Informational [Page 2]
RFC 2089 V2toV1 January 1997
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status
With the new SNMPv2 protocol (RFC1905 [1]) we get a set of error-
status values that return the cause of an error in much more detail.
But an SNMPv1 manager does not understand such error-status values.
So, when the instrumentation code returns response data and uses an
SNMPv2 error-status to report on the success or failure of the
requested operation and if the original SNMP request is an SNMPv1
request, then we must map such an error-status into an SNMPv1 error-
status when composing the SNMP response PDU.
The SNMPv2 error status is mapped to an SNMPv1 error-status using
this table:
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
readOnly readOnly
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
2.2 Mapping SNMPv2 exceptions into SNMPv1
In SNMPv2 we have so called exception values. These will allow an
SNMPv2 response PDU to return as much management information as
possible, even if one or more of the requested variables do not
exist. SNMPv1 does not support exception values, and thus does not
return the value of management information when any error occurs.
When multiple variables do not exist, an SNMPv1 agent can return only
a single error and index of a single variable. The agent determines
by its implementation strategy which variable to identify as the
Wijnen & Levi Informational [Page 3]
RFC 2089 V2toV1 January 1997
cause of the error via the value of the error-index field. Thus, an
SNMPv1 manager may make no assumption on the validity of the other
variables in the request.
So, when an SNMPv1 request is received, we must check the varBinds
returned from SNMPv2 compliant instrumentation for exception values,
and convert these exception values into SNMPv1 error codes.
The type of exception we can get back and the action we must take
depends on the SNMP operation that is requested.
o For SNMP GET requests we can get back noSuchObject and
noSuchInstance.
o For SNMP GETNEXT requests we can get back endOfMibView.
o For SNMP SET requests we cannot get back any exceptions.
o For SNMP GETBULK requests we can get back endOfMibView, but
such a request should only come in as an SNMPv2 request, so we
do not have to worry about any mapping onto SNMPv1. If a
GETBULK comes in as an SNMPv1 request, it is treated as an
error and the packet is dropped.
2.3 Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2
compliant instrumentation indicates that the requested object
instance can not be returned. The SNMPv1 error code for this
condition is noSuchName, and so the error-status field of the
response PDU should be set to noSuchName. Also, the error-index
field is set to the index of the varBind for which an exception
occurred, and the varBind list from the original request is returned
with the response PDU.
Note that when the response contains multiple exceptions, that the
agent may pick any one to be returned.
Wijnen & Levi Informational [Page 4]
RFC 2089 V2toV1 January 1997
2.4 Mapping endOfMibView
When SNMPv2 compliant instrumentation returns a varBind containing an
endOfMibView exception in response to a GETNEXT request, it indicates
that there are no object instances available which lexicographically
follow the object in the request. In an SNMPv1 agent, this condition
normally results in a noSuchName error, and so the error-status field
of the response PDU should be set to noSuchName. Also, the error-
index field is set to the index of the varBind for which an exception
occurred, and the varBind list from the original request is returned
with the response PDU.
Note that when the response contains multiple exceptions, that the
agent may pick any one to be returned.
2.5 Mapping SNMPv2 SMI into SNMPv1
The SNMPv2 SMI (RFC1902 [2]) defines basically one new syntax that is
problematic for SNMPv1 managers. That is the syntax Counter64. All
the others can be handled by SNMPv1 managers.
The net impact on bi-lingual agents is that they should make sure
that they never return a varBind with a Counter64 value to an SNMPv1
manager.
The best accepted practice is to consider such object instances
implicitly excluded from the view. So:
o On an SNMPv1 GET request, we return an error-status of
noSuchName and the error-index is set to the varBind that
causes this error.
o On an SNMPv1 GETNEXT request, we skip the object instance and
fetch the next object instance that follows the one with a
syntax of Counter64.
o Any SET request that has a varBind with a Counter64 value must
have come from a SNMPv2 manager, and so it should not cause a
problem. If we do receive a Counter64 value in an SNMPv1 SET
packet, it should result in an ASN.1 parse error since
Counter64 is not valid in the SNMPv1 protocol. When an ASN.1
parse error occurs, the counter snmpInASNParseErrs is
incremented and no response is returned.
o The GETBULK is an SNMPv2 operation, so it should never come
from an SNMPv1 manager. If we do receive a GETBULK PDU from in
an SNMPv1 packet, then we consider it an invalid PDU-type and
we drop the packet.
Wijnen & Levi Informational [Page 5]
RFC 2089 V2toV1 January 1997
3.0 Processing SNMPv1 requests
This sections contains a step by step description of how to handle
SNMPv1 requests in an agent where the underlying instrumentation code
is SNMPv2 compliant.
3.1 Processing an SNMPv1 GET request
First, the request is converted into a call to the underlying
instrumentation. This is implementation specific.
When such instrumentation returns response data using SNMPv2 syntax
and error-status values, then:
1. If the error-status is anything other than noError,
a. The error status is translated to an SNMPv1 error-status
using the table from 2.1, "Mapping SNMPv2 error-status into
SNMPv1 error-status" on page 2
b. The error-index is set to the position (in the original
request) of the varBind that caused the error-status.
c. The varBindList of the response PDU is made exactly the
same as the varBindList that was received in the original
request.
2. If the error-status is noError, then find any varBind that
contains an SNMPv2 exception (noSuchObject or noSuchInstance)
or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64).
(Note that if there are more than one, the agent may choose any
such varBind.) If there are any such varBinds, then for the
one chosen:
a. Set the error-status to noSuchName
b. Set the error-index to the position (in the varBindList of
the original request) of the varBind that returned such an
SNMPv2 exception or syntax.
c. Make the varBindList of the response PDU exactly the same
as the varBindList that was received in the original
request.
Wijnen & Levi Informational [Page 6]
RFC 2089 V2toV1 January 1997
3. If there are no such varBinds, then:
a. Set the error-status to noError
b. Set the error-index to zero
c. Compose the varBindList of the response, using the data as
it is returned by the instrumentation code.
3.2 Processing an SNMPv1 GETNEXT request
First, the request is converted into a call to the underlying
instrumentation. This is implementation specific. There may be
repetitive calls to (possibly different pieces of) instrumentation
code to try to find the first object which lexicographically follows
each of the objects in the request. Again, this is implementation
specific.
When the instrumentation finally returns response data using SNMPv2
syntax and error-status values, then:
1. If the error-status is anything other than noError,
a. The error status is translated to an SNMPv1 error-status
using the table from 2.1, "Mapping SNMPv2 error-status into
SNMPv1 error-status" on page 2
b. The error-index is set to the position (in the original
request) of the varBind that caused the error-status.
c. The varBindList of the response PDU is made exactly the
same as the varBindList that was received in the original
request.
2. If the error-status is noError, then:
a. If there are any varBinds containing an SNMPv2 syntax of
Counter64, then consider these varBinds to be not in view
and repeat the call to the instrumentation code as often as
needed till a value other than Counter64 is returned.
b. Find any varBind that contains an SNMPv2 exception
endOfMibView. (Note that if there are more than one, the
agent may choose any such varBind.) If there are any such
varBinds, then for the one chosen:
1) Set the error-status to noSuchName
Wijnen & Levi Informational [Page 7]
RFC 2089 V2toV1 January 1997
2) Set the error-index to the position (in the varBindList
of the original request) of the varBind that returned
such an SNMPv2 exception.
3) Make the varBindList of the response PDU exactly the
same as the varBindList that was received in the
original request.
c. If there are no such varBinds, then:
1) Set the error-status to noError
2) Set the error-index to zero
3) Compose the varBindList of the response, using the data
as it is returned by the instrumentation code.
3.3 Processing an outgoing SNMPv2 TRAP
If SNMPv2 compliant instrumentation presents an SNMPv2 trap to the
SNMP engine and such a trap passes all regular checking and then is
to be sent to an SNMPv1 destination, then the following steps must be
followed to convert such a trap to an SNMPv1 trap. This is basically
the reverse of the SNMPv1 to SNMPv2 mapping as described in RFC1908
[3].
1. If any of the varBinds in the varBindList has an SNMPv2 syntax
of Counter64, then such varBinds are implicitly considered to
be not in view, and so they are removed from the varBindList to
be sent with the SNMPv1 trap.
2. The 3 special varBinds in the varBindList of an SNMPv2 trap
(sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER) and
optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER)) are
removed from the varBindList to be sent with the SNMPv1 trap.
These 2 (or 3) varBinds are used to decide how to set other
fields in the SNMPv1 trap PDU as follows:
a. The value of sysUpTime.0 is copied into the timestamp field
of the SNMPv1 trap.
Wijnen & Levi Informational [Page 8]
RFC 2089 V2toV1 January 1997
b. If the snmpTrapOID.0 value is one of the standard traps the
specific-trap field is set to zero and the generic trap
field is set according to this mapping:
value of snmpTrapOID.0 generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
The enterprise field is set to the value of
snmpTrapEnterprise.0 if this varBind is present, otherwise
it is set to the value snmpTraps as defined in RFC1907 [4].
c. If the snmpTrapOID.0 value is not one of the standard
traps, then the generic-trap field is set to 6 and the
specific-trap field is set to the last subid of the
snmpTrapOID.0 value.
o If the next to last subid of snmpTrapOID.0 is zero,
then the enterprise field is set to snmpTrapOID.0 value
and the last 2 subids are truncated from that value.
o If the next to last subid of snmpTrapOID.0 is not zero,
then the enterprise field is set to snmpTrapOID.0 value
and the last 1 subid is truncated from that value.
In any event, the snmpTrapEnterprise.0 varBind (if present)
is ignored in this case.
3. The agent-addr field is set with the appropriate address of the
the sending SNMP entity, which is the IP address of the sending
entity of the trap goes out over UDP; otherwise the agent-addr
field is set to address 0.0.0.0.
Wijnen & Levi Informational [Page 9]
RFC 2089 V2toV1 January 1997
4.0 Acknowledgements
The authors wish to thank the contributions of the SNMPv2 Working
Group in general. Special thanks for their detailed review and
comments goes to these individuals:
Mike Daniele (DEC)
Dave Harrington (Cabletron)
Brian O'Keefe (Hewlett Packard)
Keith McCloghrie (Cisco Systems)
Dave Perkins (independent)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (University of Twente)
5.0 References
[1] Jeffrey D. Case, Mark Fedor, Martin Lee Schoffstall and James
R. Davin, Simple Network Management Protocol (SNMP), SNMP
Research, Performance Systems International, MIT Laboratory
for Computer Science, RFC 1157, May 1990.
[2] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Structure of Managment Information for Version 2
of the Simple Network Management Protocol (SNMPv2), SNMP
Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1902, January 1996.
[3] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework, SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1908, January 1996.
[4] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1907, January 1996.
6.0 Security Considerations
Security considerations are not discussed in this memo.
Wijnen & Levi Informational [Page 10]
RFC 2089 V2toV1 January 1997
7.0 Authors' Addresses
Bert Wijnen
IBM International Operations
Watsonweg 2
1423 ND Uithoorn
The Netherlands
Phone: +31-079-322-8316
E-mail: wijnen@vnet.ibm.com
David Levi
SNMP Research, Inc
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
USA
Phone: +1-615-573-1434
E-mail: levi@snmp.com
Wijnen & Levi Informational [Page 11]
RFC 2089 V2toV1 January 1997
APPENDIX A. Background Information
Here follows some reasoning as to why some choices were made.
A.1 Mapping of error-status values
The mapping of SNMPv2 error-status values to SNMPv1 error-status
values is based on the common interpretation of how an SNMPv1 entity
should create an error-status value based on the elements of
procedure defined in RFC1157 [1].
There was a suggestion to map wrongEncoding into genErr, because it
could be caused by an ASN.1 parsing error. Such maybe true, but in
most cases when we detect the ASN.1 parsing error, we do not yet know
about the PDU data yet. Most people who responded to our queries
have implemented the mapping to a badValue. So we "agreed" on the
mapping to badValue.
A.2 SNMPv1 Traps without Counter64 varBinds.
RFC1448 says that if one of the objects in the varBindList is not
included in the view, then the trap is NOT sent. Current SNMPv2u and
SNMPv2* documents make the same statement. However, the "rough
consensus" is that it is better to send partial information than no
information at all. Besides:
o RFC1448 does not allow for a TRAP to be sent with the varBinds
that are not included in the view removed, so it is an all or
nothing decision.
o We do NOT include the Counter64 varBinds... so the "not in
view" varBinds are not sent to the trap destination.
o The Counter64 objects are "implicit" not in view. If any
objects are explicit not in view, then this is checked before
we do the conversion from an SNMPv2 trap to an SNMPv1 trap, and
so the trap is not sent at all.
Wijnen & Levi Informational [Page 12]