doc: Add RFC documents

1 files changed, 2467 insertions, 0 deletions

diff --git a/doc/rfc/rfc2576.txt b/doc/rfc/rfc2576.txt
new file mode 100644
index 0000000..37c10c5
--- /dev/null
+++ b/doc/rfc/rfc2576.txt
@@ -0,0 +1,2467 @@
+
+
+
+
+
+
+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]
+   and RFC2089 [14].
+
+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].
+
+   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.
+
+      -  Mapping of notification parameters is documented in section 3.
+
+      -  Approaches to coexistence between entities which support the
+         various versions of SNMP in a multi-lingual network is
+         documented in 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], is
+         documented in 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 [2] which defines the Simple Network
+         Management Protocol (SNMPv1), the protocol used for network
+         access to managed objects.
+
+      -  STD 16, RFC 1155 [1] 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 [3] which defines a more concise description
+         mechanism, which is wholly consistent with the SMIv1.
+
+      -  RFC 1215 [4] 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 which defines Version 2 of the Structure of
+         Management Information (SMIv2) [7].
+
+      -  STD 58, RFC 2579 which defines common MIB "Textual Conventions"
+         [8].
+
+      -  STD 58, RFC 2580 which defines Conformance Statements and
+         requirements for defining agent and manager capabilities [9].
+
+      -  RFC 1905 which defines the Protocol Operations used in
+         processing [10].
+
+      -  RFC 1906 which defines the Transport Mappings used "on the
+         wire" [11].
+
+      -  RFC 1907 which defines the basic Management Information Base
+         for monitoring and controlling some basic common functions of
+         SNMP entities [12].
+
+   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 [6] 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 which defines an Architecture for Describing SNMP
+         Management Frameworks [16].
+
+      -  RFC 2572 which defines Message Processing and Dispatching [17].
+
+      -  RFC 2573 which defines various SNMP Applications [18].
+
+      -  RFC 2574 which defines the User-based Security Model (USM),
+         providing for both Authenticated and Private (encrypted) SNMP
+         messages [19].
+
+
+
+
+
+Frye, et al.                Standards Track                     [Page 4]
+
+RFC 2576           Coexistence between SNMP versions          March 2000
+
+
+      -  RFC 2575 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].
+
+   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], and the RowStatus and StorageType TEXTUAL-
+        CONVENTIONs are described in section 2 of RFC2579 [8].
+
+   (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], 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] 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].
+
+   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]:
+
+    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], 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 [12], 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 [12].
+
+      -  If the SNMPv2 snmpTrapOID parameter is not one of the standard
+         traps as defined in RFC1907 [12], 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], 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], 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] 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, "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, "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], 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
+
+   -  If a GetBulkRequest-PDU is received and must be forwarded using
+      the SNMPv1 message version, the proxy forwarder SHALL set the
+      non-repeaters and max-repetitions fields to 0, and SHALL set the
+      tag of the PDU to GetNextRequest-PDU.
+
+
+
+
+Frye, et al.                Standards Track                    [Page 21]
+
+RFC 2576           Coexistence between SNMP versions          March 2000
+
+
+   -  If a GetResponse-PDU is received whose error-status field has a
+      value of 'tooBig', the message will be forwarded using the SNMPv2c
+      or SNMPv3 message version, and the original request received by
+      the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL
+      remove the contents of the variable-bindings field before
+      forwarding the response.
+
+   -  If a GetResponse-PDU is received whose error-status field has a
+      value of 'tooBig,' and the message will be forwarded using the
+      SNMPv2c or SNMPv3 message version, and the original request
+      received by the proxy was a GetBulkRequest-PDU, the proxy
+      forwarder SHALL re-send the forwarded request (which would have
+      been altered to be a GetNextRequest-PDU) with all but the first
+      variable-binding removed.  The proxy forwarder SHALL only re-send
+      such a request a single time.  If the resulting GetResponse-PDU
+      also contains an error-status field with a value of 'tooBig,' then
+      the proxy forwarder SHALL remove the contents of the variable-
+      bindings field, and change the error-status field to 'noError'
+      before forwarding the response.  Note that if the original request
+      only contained a single variable-binding, the proxy may skip re-
+      sending the request and simply remove the variable-bindings and
+      change the error-status to 'noError.'
+
+   -  If a Trap-PDU is received, and will be forwarded using the SNMPv2c
+      or SNMPv3 message version, the proxy SHALL apply the translation
+      rules described in section 3, and SHALL forward the notification
+      as an SNMPv2-Trap-PDU.
+
+      Note that when an SNMPv1 agent generates a message containing a
+      Trap-PDU which is subsequently forwarded by one or more proxy
+      forwarders using SNMP versions other than SNMPv1, the community
+      string and agent-addr fields from the original message generated
+      by the SNMPv1 agent will be preserved through the use of the
+      snmpTrapAddress and snmpTrapCommunity nobjects.
+
+4.2.2.  Upstream Version Less Than Downstream Version
+
+   -  If a GetResponse-PDU is received in response to a GetRequest-PDU
+      (previously generated by the proxy) which contains variable-
+      bindings of type Counter64 or which contain an SNMPv2 exception
+      code, and the message would be forwarded using the SNMPv1 message
+      version, the proxy MUST generate an alternate response PDU
+      consisting of the request-id and variable bindings from the
+      original SNMPv1 request, containing a noSuchName error-status
+      value, and containing an error-index value indicating the position
+      of the variable-binding containing the Counter64 type or exception
+      code.
+
+
+
+
+Frye, et al.                Standards Track                    [Page 22]
+
+RFC 2576           Coexistence between SNMP versions          March 2000
+
+
+   -  If a GetResponse-PDU is received in response to a GetNextRequest-
+      PDU (previously generated by the proxy) which contains variable-
+      bindings that contain an SNMPv2 exception code, and the message
+      would be forwarded using the SNMPv1 message version, the proxy
+      MUST generate an alternate response PDU consisting of the
+      request-id and variable bindings from the original SNMPv1 request,
+      containing a noSuchName error-status value, and containing an
+      error-index value indicating the position of the variable-binding
+      containing the exception code.
+
+   -  If a GetResponse-PDU is received in response to a GetNextRequest-
+      PDU (previously generated by the proxy) which contains variable-
+      bindings of type Counter64, the proxy MUST re-send the entire
+      GetNextRequest-PDU, with the following modifications.  For any
+      variable bindings in the received GetResponse which contained
+      Counter64 types, the proxy substitutes the object names of these
+      variable bindings for the corresponding object names in the
+      previously-sent GetNextRequest.  The proxy MUST repeat this
+      process until no Counter64 objects are returned.  Note that an
+      implementation may attempt to optimize this process of skipping
+      Counter64 objects.  One approach to such an optimization would be
+      to replace the last sub-identifier of the object names of varbinds
+      containing a Counter64 type with 65535 if that sub-identifier is
+      less than 65535, or with 4294967295 if that sub-identifier is
+      greater than 65535.  This approach should skip multiple instances
+      of the same Counter64 object, while maintaining compatibility with
+      some broken agent implementations (which only use 16-bit integers
+      for sub-identifiers).
+
+      Deployment Hint:  The process of repeated GetNext requests used by
+      a proxy when Counter64 types are returned can be expensive.  When
+      deploying a proxy, this can be avoided by configuring the target
+      agents to which the proxy forwards requests in a manner such that
+      any objects of type Counter64 are in fact not-in-view for the
+      principal that the proxy is using when communicating with these
+      agents.
+
+   -  If a GetResponse-PDU is received which contains an SNMPv2 error-
+      status value of wrongValue, wrongEncoding, wrongType, wrongLength,
+      inconsistentValue, noAccess, notWritable, noCreation,
+      inconsistentName, resourceUnavailable, commitFailed, undoFailed,
+      or authorizationError, the error-status value is modified using
+      the mappings in section 4.3.
+
+   -  If an SNMPv2-Trap-PDU is received, and will be forwarded using the
+      SNMPv1 message version, the proxy SHALL apply the translation
+      rules described in section 3, and SHALL forward the notification
+
+
+
+
+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.
+
+   -  If an InformRequest-PDU is received, any configuration information
+      indicating that it would be forwarded using the SNMPv1 message
+      version SHALL be ignored.  An InformRequest-PDU can only be
+      forwarded using the SNMPv2c or SNMPv3 message version.  The
+      InformRequest-PDU may still be forwarded if there is other
+      configuration information indicating that it should be forwarded
+      using SNMPv2c or SNMPv3.
+
+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].  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], 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], 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 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], 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].  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."
+        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
+
+   -  Editorial changes to comply with current RFC requirements.
+
+   -  Added/updated copyright statements.
+
+   -  Added Intellectual Property section.
+
+   -  Replaced old introduction with complete new introduction/overview.
+
+   -  Added content for the Security Considerations Section.
+
+   -  Updated References to current documents.
+
+   -  Updated text to use current SNMP terminology.
+
+   -  Added coexistence for/with SNMPv3.
+
+   -  Added description for SNMPv1 and SNMPv2c Message Processing
+      Models and SNMPv1 and SNMPv2c Community-based Security
+      Models.
+
+   -  Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community
+      strings can be mapped into the SNMP Version Independent
+      paramaters which can then be used for access control using the
+      standard SNMPv3 View-based Access Control Model and the
+      snmpVacmMIB.
+
+   -  Added two MIB objects such that when an SNMPv1 notification
+      (trap) must be converted into an SNMPv2 notification we add
+      those two objects in order to preserve information about the
+      address and community of the originating SNMPv1 agent.
+
+   -  Included (and extended) from RFC2089 the SNMPv2 to SNMPv1
+      mapping within a multi-lingual SNMP Engine.
+
+   -  Use keywords from RFC 2119 to describe requirements for
+      compliance.
+
+   -  Changed/added some rules for converting a MIB module from
+      SMIv1 to SMIv2.
+
+   -  Extended and improved the description of Proxy Forwarder
+      behaviour when multiple SNMP versions are involved.
+
+
+
+
+
+
+
+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]
+