RFC 2089 V2toV1 January 1997 1.0 Introduction We now have the SNMPv1 protocol (RFC 1157 [1]) as a full standard and the SNMPv2 protocol (RFC 1905 [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