Network Working Group B. Wijnen Request for Comments: 2089 IBM Category: Informational D. Levi SNMP Research, Inc January 1997
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.
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).
2.0 Mapping SNMPv2 into SNMPv1
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status
2.2 Mapping SNMPv2 exceptions into SNMPv1
2.3 Mapping noSuchObject and noSuchInstance
2.4 Mapping endOfMibView
2.5 Mapping SNMPv2 SMI into SNMPv1
3.0 Processing SNMPv1 requests
3.1 Processing an SNMPv1 GET request
3.2 Processing an SNMPv1 GETNEXT request
3.3 Processing an outgoing SNMPv2 trap
6.0 Security Considerations
7.0 Authors' Addresses
Appendix A. Background Information
A.1 Mapping of error-status Values
A.2 SNMPv1 traps without Counter64 varBinds.
We now have the SNMPv1 protocol (RFC1157 ) as a full standard and the SNMPv2 protocol (RFC1905 ) 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.
These are the type of mappings that we need:
With the new SNMPv2 protocol (RFC1905 ) 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
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
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.
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.
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.
The SNMPv2 SMI (RFC1902 ) 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:
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.
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:
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) Set the error-status to noSuchName
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.
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.
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 .
value of snmpTrapOID.0 generic-trap =============================== ============ 220.127.116.11.18.104.22.168.5.1 (coldStart) 0 22.214.171.124.126.96.36.199.5.2 (warmStart) 1 188.8.131.52.184.108.40.206.5.3 (linkDown) 2 220.127.116.11.18.104.22.168.5.4 (linkUp) 3 22.214.171.124.126.96.36.199.5.5 (authenticationFailure) 4 188.8.131.52.184.108.40.206.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 .
In any event, the snmpTrapEnterprise.0 varBind (if present) is ignored in this case.
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)
 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.
 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.
 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.
 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.
Security considerations are not discussed in this memo.
IBM International Operations
1423 ND Uithoorn
SNMP Research, Inc
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
Here follows some reasoning as to why some choices were made.
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 .
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.
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: