Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework (original) (raw)

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

Obsoleted by: 3584 PROPOSED STANDARD
Errata Exist

Network Working Group R. Frye Request for Comments: 2576 CoSine Communications Category: Standards Track D. Levi Nortel Networks S. Routhier Integrated Systems Inc. B. Wijnen Lucent Technologies March 2000

    Coexistence between Version 1, Version 2, and Version 3
     of the Internet-standard Network Management Framework

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document obsoletes RFC 1908 [[13](#ref-13 ""Coexistence between Version 1 and Version 2 of the Internet- standard Network Management Framework"")] and RFC2089 [[14](#ref-14 ""Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent"")].

Table Of Contents

1 Overview ..................................................... 2 1.1 SNMPv1 ..................................................... 3 1.2 SNMPv2 ..................................................... 4 1.3 SNMPv3 ..................................................... 4 1.4 SNMPv1 and SNMPv2 Access to MIB Data ....................... 5 2 SMI and Management Information Mappings ...................... 5 2.1 MIB Modules ................................................ 6 2.1.1 Object Definitions ....................................... 6 2.1.2 Trap and Notification Definitions ........................ 9 2.2 Compliance Statements ...................................... 9 2.3 Capabilities Statements .................................... 10

Frye, et al. Standards Track [Page 1]

RFC 2576 Coexistence between SNMP versions March 2000

3 Translating Notifications Parameters ......................... 10 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters ................................... 12 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters ................................... 13 4 Approaches to Coexistence in a Multi-lingual Network ......... 14 4.1 Multi-lingual implementations .............................. 15 4.1.1 Command Generator ........................................ 15 4.1.2 Command Responder ........................................ 15 4.1.2.1 Handling Counter64 ..................................... 16 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 16 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 17 4.1.2.2.2 Mapping endOfMibView ................................. 17 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 18 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 19 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 20 4.1.3 Notification Originator .................................. 20 4.1.4 Notification Receiver .................................... 21 4.2 Proxy Implementations ...................................... 21 4.2.1 Upstream Version Greater Than Downstream Version ......... 21 4.2.2 Upstream Version Less Than Downstream Version ............ 22 4.3 Error Status Mappings ...................................... 24 5 Message Processing Models and Security Models ................ 25 5.1 Mappings ................................................... 25 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security Model ..................................................... 26 5.2.1 Processing An Incoming Request ........................... 26 5.2.2 Generating An Outgoing Response .......................... 28 5.2.3 Generating An Outgoing Notification ...................... 28 5.3 The SNMP Community MIB Module .............................. 29 6 Intellectual Property ........................................ 39 7 Acknowledgments .............................................. 39 8 Security Considerations ...................................... 40 9 References ................................................... 40 10 Editor's Addresses .......................................... 42 A. Changes From RFC1908 ........................................ 43 Full Copyright Statement ....................................... 44

1. Overview

The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1).

Frye, et al. Standards Track [Page 2]

RFC 2576 Coexistence between SNMP versions March 2000

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [[15](#ref-15 ""Key words for use in RFCs to Indicate Requirement Levels"")].

There are four general aspects of coexistence described in this document. Each of these is described in a separate section:

  -  Conversion of MIB documents between SMIv1 and SMIv2 formats is
     documented in [section 2](#section-2).

  -  Mapping of notification parameters is documented in [section 3](#section-3).

  -  Approaches to coexistence between entities which support the
     various versions of SNMP in a multi-lingual network is
     documented in [section 4](#section-4).  This section addresses the processing
     of protocol operations in multi-lingual implementations, as
     well as behaviour of proxy implementations.

  -  The SNMPv1 Message Processing Model and Community-Based
     Security Model, which provides mechanisms for adapting SNMPv1
     into the View-Based Access Control Model (VACM) [[20](#ref-20 ""View-based Access Control Model for the Simple Network Management Protocol (SNMP)"")], is
     documented in [section 5](#section-5) (this section also addresses the
     SNMPv2c Message Processing Model and Community-Based Security
     Model).

1.1. SNMPv1

SNMPv1 is defined by these documents:

  -  STD 15, [RFC 1157](./rfc1157) [[2](#ref-2 ""Simple Network Management Protocol"")] which defines the Simple Network
     Management Protocol (SNMPv1), the protocol used for network
     access to managed objects.

  -  STD 16, [RFC 1155](./rfc1155) [[1](#ref-1 ""Structure and Identification of Management Information for TCP/IP-based internets"")] which defines the Structure of Management
     Information (SMIv1), the mechanisms used for describing and
     naming objects for the purpose of management.

  -  STD 16, [RFC 1212](./rfc1212) [[3](#ref-3 ""Concise MIB Definitions"")] which defines a more concise description
     mechanism, which is wholly consistent with the SMIv1.

  -  [RFC 1215](./rfc1215) [[4](#ref-4 ""A Convention for Defining Traps for use with the SNMP"")] which defines a convention for defining Traps for
     use with the SMIv1.

Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215.

Frye, et al. Standards Track [Page 3]

RFC 2576 Coexistence between SNMP versions March 2000

1.2. SNMPv2

SNMPv2 is defined by these documents:

  -  STD 58, [RFC 2578](./rfc2578) which defines Version 2 of the Structure of
     Management Information (SMIv2) [[7](#ref-7 ""Structure of Management Information Version 2 (SMIv2)"")].

  -  STD 58, [RFC 2579](./rfc2579) which defines common MIB "Textual Conventions"
     [[8](#ref-8 ""Textual Conventions for SMIv2"")].

  -  STD 58, [RFC 2580](./rfc2580) which defines Conformance Statements and
     requirements for defining agent and manager capabilities [[9](#ref-9 ""Conformance Statements for SMIv2"")].

  -  [RFC 1905](./rfc1905) which defines the Protocol Operations used in
     processing [[10](#ref-10 ""Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)"")].

  -  [RFC 1906](./rfc1906) which defines the Transport Mappings used "on the
     wire" [[11](#ref-11 ""Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)"")].

  -  [RFC 1907](./rfc1907) which defines the basic Management Information Base
     for monitoring and controlling some basic common functions of
     SNMP entities [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")].

Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).

The following document augments the definition of SNMPv2:

  -  [RFC 1901](./rfc1901) [[6](#ref-6 ""Introduction to Community-based SNMPv2"")] is an Experimental definition for using SNMPv2
     PDUs within a community-based message wrapper.  This is
     referred to throughout this document as SNMPv2c.

1.3. SNMPv3

SNMPv3 is defined by these documents:

  -  [RFC 2571](./rfc2571) which defines an Architecture for Describing SNMP
     Management Frameworks [[16](#ref-16 ""An Architecture for Describing SNMP Management Frameworks"")].

  -  [RFC 2572](./rfc2572) which defines Message Processing and Dispatching [[17](#ref-17 ""Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)"")].

  -  [RFC 2573](./rfc2573) which defines various SNMP Applications [[18](#ref-18 ""SNMP Applications"")].

  -  [RFC 2574](./rfc2574) which defines the User-based Security Model (USM),
     providing for both Authenticated and Private (encrypted) SNMP
     messages [[19](#ref-19 ""The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMP)"")].

Frye, et al. Standards Track [Page 4]

RFC 2576 Coexistence between SNMP versions March 2000

  -  [RFC 2575](./rfc2575) which defines the View-based Access Control Model
     (VACM), providing the ability to limit access to different MIB
     objects on a per-user basis [[20](#ref-20 ""View-based Access Control Model for the Simple Network Management Protocol (SNMP)"")].

SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and the SMIv2 definitions of 2578 through 2580 described above.

1.4. SNMPv1 and SNMPv2 Access to MIB Data

In several places, this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are:

  -  Error-status values generated.

  -  Generation of exception codes.

  -  Use of the Counter64 data type.

  -  The format of parameters provided when a notification is
     generated.

SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error).

SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors.

Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions.

2. SMI and Management Information Mappings

The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 (1988)

Frye, et al. Standards Track [Page 5]

RFC 2576 Coexistence between SNMP versions March 2000

[11] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1.

The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.

2.1. MIB Modules

MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for the MIB modules to conform to the SMIv2, the following changes SHALL be made:

2.1.1. Object Definitions

In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object SHALL be deprecated or obsoleted, otherwise deprecation is not required.

(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212.

(2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement.

(3) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object MUST have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified.

(4) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32.

(5) For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate.

(6) For all objects, the ACCESS clause MUST be replaced by a MAX- ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a

Frye, et al. Standards Track [Page 6]

RFC 2576 Coexistence between SNMP versions March 2000

    MAX-ACCESS clause of "read-create".  If the value of the ACCESS
    clause is "write-only", then the value of the MAX-ACCESS clause
    MUST be "read-write", and the DESCRIPTION clause SHALL note that
    reading this object will result in implementation-specific
    results.  Note that in SMIv1, the ACCESS clause specifies the
    minimal required access, while in SMIv2, the MAX-ACCESS clause
    specifies the maximum allowed access.  This should be considered
    when converting an ACCESS clause to a MAX-ACCESS clause.

(7) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects.

(8) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined.

(9) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined.

(10) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. This approach allows one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers.

(11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress).

(12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub- identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier.

(13) One or more OBJECT-GROUPS MUST be defined, and related objects SHOULD be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP.

Frye, et al. Standards Track [Page 7]

RFC 2576 Coexistence between SNMP versions March 2000

Other changes are desirable, but not necessary:

(1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC2578 [[7](#ref-7 ""Structure of Management Information Version 2 (SMIv2)"")], and the RowStatus and StorageType TEXTUAL- CONVENTIONs are described in section 2 of RFC2579 [[8](#ref-8 ""Textual Conventions for SMIv2"")].

(2) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper- bounds on its length), the bounds for the size of the object SHOULD be defined.

(3) All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention.

(4) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object.

(5) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.

Finally, to avoid common errors in SMIv1 MIB modules:

(1) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete".

(2) For any conceptual row object that is not contained immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete".

Frye, et al. Standards Track [Page 8]

RFC 2576 Coexistence between SNMP versions March 2000

2.1.2. Trap and Notification Definitions

If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro:

(1) The IMPORTS statement MUST NOT reference RFC-1215 [[4](#ref-4 ""A Convention for Defining Traps for use with the SNMP"")], and MUST reference SNMPv2-SMI instead.

(2) The ENTERPRISE clause MUST be removed.

(3) The VARIABLES clause MUST be renamed to the OBJECTS clause.

(4) A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current,' although 'deprecated' or 'obsolete' may be used as needed.

(5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub- identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document.

(6) A DESCRIPTION clause MUST be added, if not already present.

(7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP.

2.2. Compliance Statements

For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review.

Frye, et al. Standards Track [Page 9]

RFC 2576 Coexistence between SNMP versions March 2000

Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document.

2.3. Capabilities Statements

RFC1303 [[5](#ref-5 ""A Convention for Describing SNMP- based Agents"")] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules. Converting such a description for use with the SMIv2 requires these changes:

(1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE-CONFORMANCE.

(2) The STATUS clause SHOULD be added, with a value of 'current'.

(3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC2580 [[9](#ref-9 ""Conformance Statements for SMIv2"")].

In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDED. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.)

3. Translating Notifications Parameters

This section describes how parameters used for generating notifications are translated between the format used for SNMPv1 notification protocol operations and the format used for SNMPv2 notification protocol operations. The parameters used to generate a notification are called 'notification parameters'. The format of parameters used for SNMPv1 notification protocol operations is refered to in this document as 'SNMPv1 notification parameters'. The format of parameters used for SNMPv2 notification protocol operations is refered to in this document as 'SNMPv2 notification parameters'.

Frye, et al. Standards Track [Page 10]

RFC 2576 Coexistence between SNMP versions March 2000

The situations where notification parameters MUST be translated are:

  -  When an entity generates a set of notification parameters in a
     particular format, and the configuration of the entity
     indicates that the notification must be sent using an SNMP
     message version that requires the other format for notification
     parameters.

  -  When a proxy receives a notification that was sent using an
     SNMP message version that requires one format of notification
     parameters, and must forward the notification using an SNMP
     message version that requires the other format of notification
     parameters.

In addition, it MAY be desirable to translate notification parameters in a notification receiver application in order to present notifications to the end user in a consistent format.

Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform.

SNMPv1 notification parameters consist of:

  -  An enterprise parameter (OBJECT IDENTIFIER).

  -  An agent-addr parameter (NetworkAddress).

  -  A generic-trap parameter (INTEGER).

  -  A specific-trap parameter (INTEGER).

  -  A time-stamp parameter (TimeTicks).

  -  A list of variable-bindings (VarBindList).

SNMPv2 notification parameters consist of:

  -  A sysUpTime parameter (TimeTicks).  This appears in the first
     variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.

  -  An snmpTrapOID parameter (OBJECT IDENTIFIER).  This appears in
     the second variable-binding in an SNMPv2-Trap-PDU or
     InformRequest-PDU.

  -  A list of variable-bindings (VarBindList).  This refers to all
     but the first two variable-bindings in an SNMPv2-Trap-PDU or
     InformRequest-PDU.

Frye, et al. Standards Track [Page 11]

RFC 2576 Coexistence between SNMP versions March 2000

3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters

The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters:

(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter.

(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the SNMPv1 enterprise parameter and two additional sub- identifiers, '0', and the SNMPv1 specific-trap parameter.

(3) If the SNMPv1 generic-trap parameter is not ' enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC1907 [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")]:

generic-trap parameter   snmpTrapOID.0
======================   =============
0                        1.3.6.1.6.3.1.1.5.1 (coldStart)
1                        1.3.6.1.6.3.1.1.5.2 (warmStart)
2                        1.3.6.1.6.3.1.1.5.3 (linkDown)
3                        1.3.6.1.6.3.1.1.5.4 (linkUp)
4                        1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5                        1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)

(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable- bindings. In addition, if the translation is being performed by a proxy in order to forward a received trap, three additional variable-bindings will be appended, if these three additional variable-bindings do not already exist in the SNMPv1 variable- bindings. The name portion of the first additional variable binding SHALL contain snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-addr parameter. The name portion of the second additional variable binding SHALL contain snmpTrapCommunity.0, and the value SHALL contain the value of the community-string field from the received SNMPv1 message which contained the SNMPv1 Trap-PDU. The name portion of the third additional variable binding SHALL contain snmpTrapEnterprise.0 [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")], and the value SHALL be the SNMPv1 enterprise parameter.

Frye, et al. Standards Track [Page 12]

RFC 2576 Coexistence between SNMP versions March 2000

3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters

The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters:

(1) The SNMPv1 enterprise parameter SHALL be determined as follows:

  -  If the SNMPv2 snmpTrapOID parameter is one of the standard
     traps as defined in [RFC1907](./rfc1907) [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")], then the SNMPv1 enterprise
     parameter SHALL be set to the value of the variable-binding in
     the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
     if that variable-binding exists.  If it does not exist, the
     SNMPv1 enterprise parameter SHALL be set to the value '
     snmpTraps' as defined in [RFC1907](./rfc1907) [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")].

  -  If the SNMPv2 snmpTrapOID parameter is not one of the standard
     traps as defined in [RFC1907](./rfc1907) [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")], then the SNMPv1 enterprise
     parameter SHALL be determined from the SNMPv2 snmpTrapOID
     parameter as follows:

     -  If the next-to-last sub-identifier of the snmpTrapOID is
        zero, then the SNMPv1 enterprise SHALL be the SNMPv2
        snmpTrapOID with the last 2 sub-identifiers removed,
        otherwise

     -  If the next-to-last sub-identifier of the snmpTrapOID is
        non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
        snmpTrapOID with the last sub-identifier removed.

(2) The SNMPv1 agent-addr parameter SHALL be determined based on the situation in which the translation occurs.

  -  If the translation occurs within a notification originator
     application, and the notification is to be sent over IP, the
     SNMPv1 agent-addr parameter SHALL be set to the IP address of
     the SNMP entity in which the notification originator resides.
     If the notification is to be sent over some other transport,
     the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.

  -  If the translation occurs within a proxy application, the proxy
     must attempt to extract the original source of the notification
     from the variable-bindings.  If the SNMPv2 variable-bindings
     contains a variable binding whose name is snmpTrapAddress.0,
     the agent-addr parameter SHALL be set to the value of that
     variable binding.  Otherwise, the SNMPv1 agent-addr parameter
     SHALL be set to 0.0.0.0.

Frye, et al. Standards Track [Page 13]

RFC 2576 Coexistence between SNMP versions March 2000

(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC1907 [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")], the SNMPv1 generic-trap parameter SHALL be set as follows:

        snmpTrapOID.0 parameter               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

    Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.

(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC1907 [[12](#ref-12 ""Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)"")], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter.

(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter.

(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable- bindings. Note, however, that if the SNMPv2 variable-bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters cannot be performed. In this case, the notification cannot be encoded in an SNMPv1 packet (and so the notification cannot be sent using SNMPv1, see section 4.1.3 and section 4.2).

4. Approaches to Coexistence in a Multi-lingual Network

There are two basic approaches to coexistence in a multi-lingual network, multi-lingual implementations and proxy implementations. Multi-lingual implementations allow elements in a network to communicate with each other using an SNMP version which both elements support. This allows a multi-lingual implementation to communicate with any mono-lingual implementation, regardless of the SNMP version supported by the mono-lingual implementation.

Proxy implementations provide a mechanism for translating between SNMP versions using a third party network element. This allows network elements which support only a single, but different, SNMP version to communicate with each other. Proxy implementations are also useful for securing communications over an insecure link between two locally secure networks.

Frye, et al. Standards Track [Page 14]

RFC 2576 Coexistence between SNMP versions March 2000

4.1. Multi-lingual implementations

This approach requires an entity to support multiple SNMP message versions. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message versions. The behaviour of various types of SNMP applications which support multiple message versions is described in the following sections. This approach allows entities which support multiple SNMP message versions to coexist with and communicate with entities which support only a single SNMP message version.

4.1.1. Command Generator

A command generator must select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version.

In addition, a command generator MUST 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. This is done by simply changing the operation type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero.

4.1.2. Command Responder

A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. A command responder must:

  -  Deal correctly with SNMPv2 access to MIB data that returns a
     Counter64 value while processing an SNMPv1 message,

  -  Deal correctly with SNMPv2 access to MIB data that returns one
     of the three exception values while processing an SNMPv1
     message, and

  -  Map SNMPv2 error codes returned from SNMPv2 access to MIB data
     into SNMPv1 error codes when processing an SNMPv1 message.

Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. In the case of proxy forwarding, for backwards compatibility, SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message.

The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses some combination of SNMPv1 and SNMPv2 access to MIB data.

Frye, et al. Standards Track [Page 15]

RFC 2576 Coexistence between SNMP versions March 2000

4.1.2.1. Handling Counter64

The SMIv2 [[7](#ref-7 ""Structure of Management Information Version 2 (SMIv2)"")] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1.

The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version.

Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So:

  -  On receipt of an SNMPv1 GetRequest-PDU containing a variable
     binding whose name field points to an object instance of type
     Counter64, a GetResponsePDU SHALL be returned, with an error-
     status of noSuchName and the error-index set to the variable
     binding that caused this error.

  -  On an SNMPv1 GetNextRequest-PDU, any object instance which
     contains a syntax of Counter64 SHALL be skipped, and the next
     accessible object instance that does not have the syntax of
     Counter64 SHALL be retrieved. If no such object instance
     exists, then an error-status of noSuchName SHALL be returned,
     and the error-index SHALL be set to the variable binding that
     caused this error.

  -  Any SNMPv1 request which contains a variable binding with a
     Counter64 value is ill-formed, so the foregoing rules do not
     apply.  If that error is detected, a response SHALL NOT be
     returned, since it would contain a copy of the ill-formed
     variable binding.  Instead, the offending PDU SHALL be
     discarded and the counter snmpInASNParseErrs SHALL be
     incremented.

4.1.2.2. Mapping SNMPv2 Exceptions

SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and error-index value.

Frye, et al. Standards Track [Page 16]

RFC 2576 Coexistence between SNMP versions March 2000

When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes.

The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request.

  -  For a GetRequest, a noSuchObject or noSuchInstance exception
     may be returned.

  -  For a GetNextRequest, an endOfMibView exception may be
     returned.

  -  No exceptions will be returned for a SetRequest, and a
     GetBulkRequest should only be received in an SNMPv2c or SNMPv3
     message, so these request types may be ignored when mapping
     exceptions.

Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference.

4.1.2.2.1. Mapping noSuchObject and noSuchInstance

A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data 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 SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (there may be more than one and it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.

4.1.2.2.2. Mapping endOfMibView

When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, 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 SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (there may be more than one and it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.

Frye, et al. Standards Track [Page 17]

RFC 2576 Coexistence between SNMP versions March 2000

4.1.2.3. Processing An SNMPv1 GetRequest

When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.

When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then:

(1) If the error-status is anything other than noError,

  -  The error status SHALL be translated to an SNMPv1 error-status
     using the table in [section 4.3](#section-4.3), "Error Status Mappings".

  -  The error-index SHALL be set to the position (in the original
     request) of the variable binding that caused the error-status.

  -  The variable binding list of the response PDU SHALL be made
     exactly the same as the variable binding list that was received
     in the original request.

(2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and:

  -  The error-status SHALL be set to noSuchName,

  -  The error-index SHALL be set to the position (in the variable
     binding list of the original request) of the selected variable
     binding, and

  -  The variable binding list of the response PDU SHALL be exactly
     the same as the variable binding list that was received in the
     original request.

(3) If there are no such variable bindings, then:

  -  The error-status SHALL be set to noError,

  -  The error-index SHALL be set to zero, and

  -  The variable binding list of the response SHALL be composed
     from the data as it is returned by the access to MIB data.

Frye, et al. Standards Track [Page 18]

RFC 2576 Coexistence between SNMP versions March 2000

4.1.2.4. Processing An SNMPv1 GetNextRequest

When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when an SNMPv2 access to MIB data is called as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request.

First, if the access to MIB data returns an error-status of anything other than noError:

(1) The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.3, "Error Status Mappings".

(2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.

(3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.

Otherwise, if the access to MIB data returns an error-status of noError:

(1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error occurs.

(2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (there may be more than one, it is an implementation decision as to which is chosen):

  -  The error-status SHALL be set to noSuchName,

  -  The error-index SHALL be set to the position (in the variable
     binding list of the original request) of the variable binding
     that returned such an SNMPv2 exception, and

  -  The variable binding list of the response PDU SHALL be exactly
     the same as the variable binding list that was received in the
     original request.

(3) If there are no such variable bindings, then:

Frye, et al. Standards Track [Page 19]

RFC 2576 Coexistence between SNMP versions March 2000

  -  The error-status SHALL be set to noError,

  -  The error-index SHALL be set to zero, and

  -  The variable binding list of the response SHALL be composed
     from the data as it is returned by the access to MIB data.

4.1.2.5. Processing An SNMPv1 SetRequest

When processing an SNMPv1 SetRequest, the following procedures MUST be followed when calling SNMPv2 MIB access routines.

When such MIB access routines return response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then:

  -  The error status SHALL be translated to an SNMPv1 error-status
     using the table in [section 4.3](#section-4.3), "Error Status Mappings".

  -  The error-index SHALL be set to the position (in the original
     request) of the variable binding that caused the error-status.

  -  The variable binding list of the response PDU SHALL be made
     exactly the same as the variable binding list that was received
     in the original request.

4.1.3. Notification Originator

A notification originator must be able to translate between SNMPv1 notifications parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1.

When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- MIB, if the SNMP version used to generate the notification is SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether the value of snmpNotifyType is trap(1) or inform(2).

Frye, et al. Standards Track [Page 20]

RFC 2576 Coexistence between SNMP versions March 2000

Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in order to perform the access check specified in [[18](#ref-18 ""SNMP Applications"")], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated.

4.1.4. Notification Receiver

There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher level application to request whether notifications should be delivered to a higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would then translate notification parameters when required in order to present a notification using the desired set of parameters.

4.2. Proxy Implementations

A proxy implementation may be used to enable communication between entities which support different SNMP message versions. This is accomplished in a proxy forwarder application by performing translations on PDUs. These translations depend on the PDU type, the SNMP version of the packet containing a received PDU, and the SNMP version to be used to forward a received PDU. The following sections describe these translations. In all cases other than those described below, the proxy SHALL forward a received PDU without change, subject to size constraints as defined in section 5.3 (Community MIB) of this document. Note that in the following sections, the 'Upstream Version' refers to the version used between the command generator and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder, regardless of the PDU type or direction.

4.2.1. Upstream Version Greater Than Downstream Version

Frye, et al. Standards Track [Page 21]

RFC 2576 Coexistence between SNMP versions March 2000

4.2.2. Upstream Version Less Than Downstream Version

Frye, et al. Standards Track [Page 22]

RFC 2576 Coexistence between SNMP versions March 2000

Frye, et al. Standards Track [Page 23]

RFC 2576 Coexistence between SNMP versions March 2000

  as a Trap-PDU.  Note that if the translation fails due to the
  existence of a Counter64 data-type in the received SNMPv2-Trap-
  PDU, the trap cannot be forwarded using SNMPv1.

4.3. Error Status Mappings

The following tables shows the mappings of SNMPv1 error-status values into SNMPv2 error-status values, and the mappings of SNMPv2 error- status values into SNMPv1 error-status values.

            SNMPv1 error-status    SNMPv2 error-status
            ===================    ===================
            noError                noError
            tooBig                 tooBig
            noSuchName             noSuchName
            badValue               badValue
            genErr                 genErr


            SNMPv2 error-status    SNMPv1 error-status
            ===================    ===================
            noError                noError
            tooBig                 tooBig
            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

Frye, et al. Standards Track [Page 24]

RFC 2576 Coexistence between SNMP versions March 2000

Whenever the SNMPv2 error-status value of authorizationError is translated to an SNMPv1 error-status value of noSuchName, the value of snmpInBadCommunityUses MUST be incremented.

5. Message Processing Models and Security Models

In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the following models are defined in this document:

  -  The SNMPv1 Message Processing Model

  -  The SNMPv1 Community-Based Security Model

The following models are also described in this document:

  -  The SNMPv2c Message Processing Model

  -  The SNMPv2c Community-Based Security Model

     In most respects, the SNMPv1 Message Processing Model and the
     SNMPv2c Message Processing Model are identical, and so these
     are not discussed independently in this document.  Differences
     between the two models are described as required.

     Similarly, the SNMPv1 Community-Based Security Model and the
     SNMPv2c Community-Based Security Model are nearly identical,
     and so are not discussed independently.  Differences between
     these two models are also described as required.

5.1. Mappings

The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model require mappings between parameters used in SNMPv1 (and SNMPv2c) messages, and the version independent parameters used in the SNMP architecture [[16](#ref-16 ""An Architecture for Describing SNMP Management Frameworks"")]. The parameters which MUST be mapped consist of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and contextEngineID/contextName pair. A MIB module (the SNMP- COMMUNITY-MIB) is provided in this document in order to perform these mappings. This MIB provides mappings in both directions, that is, a community name may be mapped to a securityName, contextEngineID, and contextName, or the combination of securityName, contextEngineID, and contextName may be mapped to a community name.

Frye, et al. Standards Track [Page 25]

RFC 2576 Coexistence between SNMP versions March 2000

5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model

The SNMPv1 Message Processing Model handles processing of SNMPv1 messages. The processing of messages is handled generally in the same manner as described in RFC1157 [[2](#ref-2 ""Simple Network Management Protocol"")], with differences and clarifications as described in the following sections. The SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SNMPv2c is 1).

5.2.1. Processing An Incoming Request

In RFC1157 [[2](#ref-2 ""Simple Network Management Protocol"")], section 4.1, item (3) for an entity which receives a message, states that various parameters are passed to the 'desired authentication scheme.' The desired authentication scheme in this case is the SNMPv1 Community-Based Security Model, which will be called using the processIncomingMsg ASI. The parameters passed to this ASI are:

  -  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).

  -  The maxMessageSize, which should be the maximum size of a
     message that the receiving entity can generate (since there is
     no such value in the received message).

  -  The securityParameters, which consist of the community string
     and the message's source and destination transport domains and
     addresses.

  -  The securityModel, which will be 1 (or 2 for SNMPv2c).

  -  The securityLevel, which will be noAuthNoPriv.

  -  The wholeMsg and wholeMsgLength.

The Community-Based Security Model will attempt to select a row in the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:

  -  The community string is equal to the snmpCommunityName value.

  -  If the snmpCommunityTransportTag is an empty string, it is
     ignored for the purpose of matching.  If the
     snmpCommunityTransportTag is not an empty string, the
     transportDomain and transportAddress from which the message was
     received must match one of the entries in the
     snmpTargetAddrTable selected by the snmpCommunityTransportTag

Frye, et al. Standards Track [Page 26]

RFC 2576 Coexistence between SNMP versions March 2000

     value.  The snmpTargetAddrTMask object is used as described in
     [section 5.3](#section-5.3) when checking whether the transportDomain and
     transportAddress matches a entry in the snmpTargetAddrTable.

If no such entry can be found, an authentication failure occurs as described in RFC1157 [[2](#ref-2 ""Simple Network Management Protocol"")], and the snmpInBadCommunityNames counter is incremented.

The parameters returned from the Community-Based Security Model are:

  -  The securityEngineID, which will always be the local value of
     snmpEngineID.0.

  -  The securityName.

  -  The scopedPDU.  Note that this parameter will actually consist
     of three values, the contextSnmpEngineID, the contextName, and
     the PDU.  These must be separate values, since the first two do
     not actually appear in the message.

  -  The maxSizeResponseScopedPDU.

  -  The securityStateReference.

The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are:

  -  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).

  -  The securityModel, which will be 1 (or 2 for SNMPv2c).

  -  The securityName, which was returned from the call to
     processIncomingMsg.

  -  The securityLevel, which is noAuthNoPriv.

  -  The contextEngineID, which was returned as part of the
     ScopedPDU from the call to processIncomingMsg.

  -  The contextName, which was returned as part of the ScopedPDU
     from the call to processIncomingMsg.

  -  The pduVersion, which should indicate an SNMPv1 version PDU (if
     the message version was SNMPv2c, this would be an SNMPv2
     version PDU).

Frye, et al. Standards Track [Page 27]

RFC 2576 Coexistence between SNMP versions March 2000

  -  The PDU, which was returned as part of the ScopedPDU from the
     call to processIncomingMsg.

  -  The maxSizeResponseScopedPDU which was returned from the call
     to processIncomingMsg.

  -  The stateReference which was returned from the call to
     processIncomingMsg.

The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI.

5.2.2. Generating An Outgoing Response

There is no special processing required for generating an outgoing response. However, the community string used in an outgoing response must be the same as the community string from the original request. The original community string MUST be present in the stateReference information of the original request.

5.2.3. Generating An Outgoing Notification

In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:

  -  The securityName must be equal to the snmpCommunitySecurityName
     value.

  -  The contextEngineID must be equal to the
     snmpCommunityContextEngineID value.

  -  The contextName must be equal to the snmpCommunityContextName
     value.

  -  If the snmpCommunityTransportTag is an empty string, it is
     ignored for the purpose of matching.  If the
     snmpCommunityTransportTag is not an empty string, the

Frye, et al. Standards Track [Page 28]

RFC 2576 Coexistence between SNMP versions March 2000

     transportDomain and transportAddress must match one of the
     entries in the snmpTargetAddrTable selected by the
     snmpCommunityTransportTag value.

If no such entry can be found, the notification is not sent. Otherwise, the community string used in the outgoing notification will be the value of the snmpCommunityName column of the selected row.

5.3. The SNMP Community MIB Module

The SNMP-COMMUNITY-MIB contains objects for mapping between community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source address validation on incoming requests, and for selecting community strings based on target addresses for outgoing notifications. These two features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [[18](#ref-18 ""SNMP Applications"")]. In addition, the SNMP-COMMUNITY-MIB augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. These values are used only where explicitly stated. In cases where the snmpTargetAddrTable is used without mention of these augmenting values, the augmenting values should be ignored.

The mask value, snmpTargetAddrTMask, allows selected entries in the snmpTargetAddrTable to specify multiple addresses (rather than just a single address per entry). This would typically be used to specify a subnet in an snmpTargetAddrTable rather than just a single address. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. The value of an instance of snmpTargetAddrTMask must always be an OCTET STRING whose length is either zero or the same as that of the corresponding instance of snmpTargetAddrTAddress.

Note that the snmpTargetAddrTMask object is only used where explicitly stated. In particular, it is not used when generating notifications (i.e., when generating notifications, entries in the snmpTargetAddrTable only specify individual addresses).

When checking whether a transport address matches an entry in the snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- length OCTET STRING, the mask value is ignored, and the value of snmpTargetAddrTAddress must exactly match a transport address. Otherwise, each bit of each octet in the snmpTargetAddrTMask value corresponds to the same bit of the same octet in the

Frye, et al. Standards Track [Page 29]

RFC 2576 Coexistence between SNMP versions March 2000

snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding bits in the snmpTargetAddrTAddress value must match the bits in a transport address. If all such bits match, the transport address is matched by that snmpTargetAddrTable entry. Otherwise, the transport address is not matched.

The maximum message size value, snmpTargetAddrMMS, is used to determine the maximum message size acceptable to another SNMP entity when the value cannot be determined from the protocol.

SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN

IMPORTS IpAddress, MODULE-IDENTITY, OBJECT-TYPE, Integer32, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB SnmpTagValue, snmpTargetAddrEntry FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;

snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "200003060000Z" -- 6 Mar 2000, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3

              Chair:      Russ Mundy
                          TIS Labs at Network Associates
              Postal:     3060 Washington Rd
                          Glenwood MD 21738
                          USA
              Email:      mundy@tislabs.com
              Phone:      +1-301-854-6889

Frye, et al. Standards Track [Page 30]

RFC 2576 Coexistence between SNMP versions March 2000

              Co-editor:  Rob Frye
                          CoSine Communications
              Postal:     1200 Bridge Parkway
                          Redwood City, CA 94065
                          USA
              E-mail:     rfrye@cosinecom.com
              Phone:      +1 703 725 1130

              Co-editor:  David B. Levi
                          Nortel Networks
              Postal:     3505 Kesterwood Drive
                          Knoxville, TN 37918
              E-mail:     dlevi@nortelnetworks.com
              Phone:      +1 423 686 0432

              Co-editor:  Shawn A. Routhier
                          Integrated Systems Inc.
              Postal:     333 North Ave 4th Floor
                          Wakefield, MA 01880
              E-mail:     sar@epilogue.com
              Phone:      +1 781 245 0804

              Co-editor:  Bert Wijnen
                          Lucent Technologies
              Postal:     Schagen 33
                          3461 GL Linschoten
                          Netherlands
              Email:      bwijnen@lucent.com
              Phone:      +31-348-407-775
             "

    DESCRIPTION
        "This MIB module defines objects to help support coexistence
         between SNMPv1, SNMPv2c, and SNMPv3."
    REVISION "200003060000Z" -- 6 Mar 2000
    DESCRIPTION "This version published as [RFC 2576](./rfc2576)."
    REVISION "199905130000Z" -- 13 May 1999
    DESCRIPTION "The Initial Revision"
::= { snmpModules 18 }

-- Administrative assignments ****************************************

snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }

-- -- The snmpCommunityTable contains a database of community strings. -- This table provides mappings between community strings, and the

Frye, et al. Standards Track [Page 31]

RFC 2576 Coexistence between SNMP versions March 2000

-- parameters required for View-based Access Control.

snmpCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of community strings configured in the SNMP engine's Local Configuration Datastore (LCD)." ::= { snmpCommunityMIBObjects 1 }

snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular community string." INDEX { IMPLIED snmpCommunityIndex } ::= { snmpCommunityTable 1 }

SnmpCommunityEntry ::= SEQUENCE { snmpCommunityIndex SnmpAdminString, snmpCommunityName OCTET STRING, snmpCommunitySecurityName SnmpAdminString, snmpCommunityContextEngineID SnmpEngineID, snmpCommunityContextName SnmpAdminString, snmpCommunityTransportTag SnmpTagValue, snmpCommunityStorageType StorageType, snmpCommunityStatus RowStatus }

snmpCommunityIndex OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique index value of a row in this table." ::= { snmpCommunityEntry 1 }

snmpCommunityName OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The community string for which a row in this table represents a configuration." ::= { snmpCommunityEntry 2 }

Frye, et al. Standards Track [Page 32]

RFC 2576 Coexistence between SNMP versions March 2000

snmpCommunitySecurityName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(1..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "A human readable string representing the corresponding value of snmpCommunityName in a Security Model independent format." ::= { snmpCommunityEntry 3 }

snmpCommunityContextEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-create STATUS current DESCRIPTION "The contextEngineID indicating the location of the context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName.

     The default value is the snmpEngineID of the entity in
     which this object is instantiated."
::= { snmpCommunityEntry 4 }

snmpCommunityContextName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE(0..32)) MAX-ACCESS read-create STATUS current DESCRIPTION "The context in which management information is accessed when using the community string specified by the corresponding instance of snmpCommunityName." DEFVAL { ''H } -- the empty string ::= { snmpCommunityEntry 5 }

snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints from which a command responder application will accept management requests. If a management request containing this community is received on a transport endpoint other than the transport endpoints identified by this object, the request is deemed unauthentic.

     The transports identified by this object are specified

Frye, et al. Standards Track [Page 33]

RFC 2576 Coexistence between SNMP versions March 2000

     in the snmpTargetAddrTable.  Entries in that table
     whose snmpTargetAddrTagList contains this tag value
     are identified.

     If the value of this object has zero-length, transport
     endpoints are not checked when authenticating messages
     containing this community string."
DEFVAL      { ''H }   -- the empty string
::= { snmpCommunityEntry 6 }

snmpCommunityStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "The storage type for this conceptual row in the snmpCommunityTable. Conceptual rows having the value 'permanent' need not allow write-access to any columnar object in the row." ::= { snmpCommunityEntry 7 }

snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable.

     An entry in this table is not qualified for activation
     until instances of all corresponding columns have been
     initialized, either through default values, or through
     Set operations.  The snmpCommunityName and
     snmpCommunitySecurityName objects must be explicitly set.

     There is no restriction on setting columns in this table
     when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }

-- -- The snmpTargetAddrExtTable

snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and mms values associated with the

Frye, et al. Standards Track [Page 34]

RFC 2576 Coexistence between SNMP versions March 2000

     snmpTargetAddrTable.

     The snmpTargetAddrExtTable augments the
     snmpTargetAddrTable with a transport address mask value
     and a maximum message size value.  The transport address
     mask allows entries in the snmpTargetAddrTable to define
     a set of addresses instead of just a single address.
     The maximum message size value allows the maximum
     message size of another SNMP entity to be configured for
     use in SNMPv1 (and SNMPv2c) transactions, where the
     message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 }

snmpTargetAddrExtEntry OBJECT-TYPE SYNTAX SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular mask and mms value." AUGMENTS { snmpTargetAddrEntry } ::= { snmpTargetAddrExtTable 1 }

SnmpTargetAddrExtEntry ::= SEQUENCE { snmpTargetAddrTMask OCTET STRING, snmpTargetAddrMMS Integer32 }

snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask value associated with an entry in the snmpTargetAddrTable. The value of this object must have the same length as the corresponding instance of snmpTargetAddrTAddress, or must have length 0. An attempt to set it to any other value will result in an inconsistentValue error.

     The value of this object allows an entry in the
     snmpTargetAddrTable to specify multiple addresses.
     The mask value is used to select which bits of
     a transport address must match bits of the corresponding
     instance of snmpTargetAddrTAddress, in order for the
     transport address to match a particular entry in the
     snmpTargetAddrTable.  Bits which are 1 in the mask
     value indicate bits in the transport address which
     must match bits in the snmpTargetAddrTAddress value.

Frye, et al. Standards Track [Page 35]

RFC 2576 Coexistence between SNMP versions March 2000

     Bits which are 0 in the mask indicate bits in the
     transport address which need not match.  If the
     length of the mask is 0, the mask should be treated
     as if all its bits were 1 and its length were equal
     to the length of the corresponding value of
     snmpTargetAddrTable.

     This object may not be modified while the value of the
     corresponding instance of snmpTargetAddrRowStatus is
     active(1).  An attempt to set this object in this case
     will result in an inconsistentValue error."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }

snmpTargetAddrMMS OBJECT-TYPE SYNTAX Integer32 (0|484..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum message size value associated with an entry in the snmpTargetAddrTable." DEFVAL { 484 } ::= { snmpTargetAddrExtEntry 2 }

-- -- The snmpTrapAddress and snmpTrapCommunity objects are included -- in notifications that are forwarded by a proxy, which were -- originally received as SNMPv1 Trap messages.

snmpTrapAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the agent-addr field of a Trap PDU which is forwarded by a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the agent-addr field from the original Trap PDU as generated by an SNMPv1 agent." ::= { snmpCommunityMIBObjects 3 }

snmpTrapCommunity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION

Frye, et al. Standards Track [Page 36]

RFC 2576 Coexistence between SNMP versions March 2000

    "The value of the community string field of an SNMPv1
     message containing a Trap PDU which is forwarded by a
     a proxy forwarder application using an SNMP version
     other than SNMPv1.  The value of this object SHOULD
     contain the value of the community string field from
     the original SNMPv1 message containing a Trap PDU as
     generated by an SNMPv1 agent."
::= { snmpCommunityMIBObjects 4 }

-- Conformance Information *******************************************

snmpCommunityMIBCompliances OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 1 } snmpCommunityMIBGroups OBJECT IDENTIFIER ::= { snmpCommunityMIBConformance 2 }

-- Compliance statements

snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB."

MODULE       -- this module
    MANDATORY-GROUPS { snmpCommunityGroup }

    OBJECT           snmpCommunityName
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunitySecurityName
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunityContextEngineID
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunityContextName
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunityTransportTag
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunityStorageType

Frye, et al. Standards Track [Page 37]

RFC 2576 Coexistence between SNMP versions March 2000

    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

    OBJECT           snmpCommunityStatus
    MIN-ACCESS       read-only
    DESCRIPTION     "Write access is not required."

::= { snmpCommunityMIBCompliances 1 }

snmpProxyTrapForwardCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which contain a proxy forwarding application which is capable of forwarding SNMPv1 traps using SNMPv2c or SNMPv3." MODULE -- this module MANDATORY-GROUPS { snmpProxyTrapForwardGroup } ::= { snmpCommunityMIBCompliances 2 }

snmpCommunityGroup OBJECT-GROUP OBJECTS { snmpCommunityName, snmpCommunitySecurityName, snmpCommunityContextEngineID, snmpCommunityContextName, snmpCommunityTransportTag, snmpCommunityStorageType, snmpCommunityStatus, snmpTargetAddrTMask, snmpTargetAddrMMS } STATUS current DESCRIPTION "A collection of objects providing for configuration of community strings for SNMPv1 (and SNMPv2c) usage." ::= { snmpCommunityMIBGroups 1 }

snmpProxyTrapForwardGroup OBJECT-GROUP OBJECTS { snmpTrapAddress, snmpTrapCommunity } STATUS current DESCRIPTION "Objects which are used by proxy forwarding applications when translating traps between SNMP versions. These are used to preserve SNMPv1-specific information when

Frye, et al. Standards Track [Page 38]

RFC 2576 Coexistence between SNMP versions March 2000

     translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }

END

6. Intellectual Property

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

7. Acknowledgments

This document is the result of the efforts of the SNMPv3 Working Group. The design of the SNMP-COMMUNITY-MIB incorporates work done by the authors of SNMPv2*:

  Jeff Case (SNMP Research, Inc.)
  David Harrington (Cabletron Systems Inc.)
  David Levi (SNMP Research, Inc.)
  Brian O'Keefe (Hewlett Packard)
  Jon Saperia (IronBridge Networks, Inc.)
  Steve Waldbusser (International Network Services)

Frye, et al. Standards Track [Page 39]

RFC 2576 Coexistence between SNMP versions March 2000

8. Security Considerations

Although SNMPv1 and SNMPv2 do not provide any security, allowing community names to be mapped into securityName/contextName provides the ability to use view-based access control to limit the access of unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for network administrators to make use of this capability in order to avoid unauthorized access to MIB data that would otherwise be secure.

Further, the SNMP-COMMUNITY-MIB has the potential to expose community strings which provide access to more information than that which is available using the usual 'public' community string. For this reason, a security administrator may wish to limit accessibility to the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible when using the 'public' community string.

When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy. Careful configuration of proxies is required to address such situations. One approach to deal with such situations might be to use an encrypted tunnel.

9. References

[1] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.

[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.

[3] McCloghrie, K. and M. Rose, Editors, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.

[5] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP- based Agents", RFC 1303, February 1992.

[6] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.

Frye, et al. Standards Track [Page 40]

RFC 2576 Coexistence between SNMP versions March 2000

[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[10] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.

[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet- standard Network Management Framework", RFC 1908, January 1996.

[14] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent", RFC 2089, January 1997.

[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[16] Harrington, D. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, May 1999.

[17] Case, J., Harrington, D. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, May 1999.

[18] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, May 1999.

[19] Blumenthal, U. and Wijnen, B., "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMP)", RFC 2574, May 1999.

Frye, et al. Standards Track [Page 41]

RFC 2576 Coexistence between SNMP versions March 2000

[20] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, May 1999.

10. Editor's Addresses

Rob Frye CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065 U.S.A.

Phone: +1 703 725 1130 EMail: rfrye@cosinecom.com

David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.

Phone: +1 423 686 0432 EMail: dlevi@nortelnetworks.com

Shawn A. Routhier Integrated Systems Inc. 333 North Ave 4th Floor Wakefield MA 01880 U.S.A.

Phone: + 1 781 245 0804 EMail: sar@epilogue.com

Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands

Phone: +31 348 407-775 EMail: wijnen@lucent.com

Frye, et al. Standards Track [Page 42]

RFC 2576 Coexistence between SNMP versions March 2000

A. Changes From RFC1908

Frye, et al. Standards Track [Page 43]

RFC 2576 Coexistence between SNMP versions March 2000

Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

Frye, et al. Standards Track [Page 44]