idnits 2.17.1 draft-ietf-snmpv3-coex-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([13], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The abstract seems to indicate that this document obsoletes RFC1908, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 477 has weird spacing: '...rameter snmp...' == Line 1019 has weird spacing: '...ailable gen...' == Line 1872 has weird spacing: '...for the purpo...' == Line 1902 has weird spacing: '...ameters to S...' == Line 1904 has weird spacing: '...ameters to S...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 May 1999) is 9100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1303 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '6') ** Obsolete normative reference: RFC 1905 (ref. '10') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '12') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '13') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2089 (ref. '14') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 2571 (ref. '16') (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (ref. '17') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (ref. '18') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (ref. '19') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (ref. '20') (Obsoleted by RFC 3415) Summary: 22 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Coexistence between SNMP versions 21 May 1999 4 INTERNET-DRAFT Rob Frye 5 MCI WorldCom 6 David B. Levi 7 Nortel Networks 8 Shawn A. Routhier 9 Integrated Systems Inc. 10 Bert Wijnen 11 IBM T.J. Watson Research 12 21 May 1999 14 Coexistence between Version 1, Version 2, and Version 3 15 of the Internet-standard Network Management Framework 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright Notice 39 Copyright (C) The Internet Society (1999). All Rights Reserved. 41 Abstract 43 The purpose of this document is to describe coexistence between 44 version 3 of the Internet-standard Network Management Framework, 45 (SNMPv3), version 2 of the Internet-standard Network Management 46 Framework (SNMPv2), and the original Internet-standard Network 47 Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] 48 and RFC2089 [14]. 50 Table Of Contents 52 1. Overview 54 The purpose of this document is to describe coexistence between 55 version 3 of the Internet-standard Network Management Framework, 56 termed the SNMP version 3 framework (SNMPv3), version 2 of the 57 Internet-standard Network Management Framework, termed the SNMP 58 version 2 framework (SNMPv2), and the original Internet-standard 59 Network Management Framework (SNMPv1). 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC2119 [15]. 65 There are four general aspects of coexistence described in this 66 document. Each of these is described in a separate section: 68 - Conversion of MIB documents between SMIv1 and SMIv2 formats is 69 documented in section 2. 71 - Mapping of notification parameters is documented in section 3. 73 - Approaches to coexistence between entities which support the 74 various versions of SNMP in a multi-lingual network is 75 documented in section 4. This section addresses the 76 processing of protocol operations in multi-lingual 77 implementations, as well as behaviour of proxy 78 implementations. 80 - The SNMPv1 Message Processing Model and Community-Based 81 Security Model, which provides mechanisms for adapting SNMPv1 82 into the View-Based Access Control Model (VACM) [20], is 83 documented in section 5 (this section also addresses the 84 SNMPv2c Message Processing Model and Community-Based Security 85 Model). 87 1.1. SNMPv1 89 SNMPv1 is defined by these documents: 91 - STD 15, RFC 1157 [2] which defines the Simple Network 92 Management Protocol (SNMPv1), the protocol used for network 93 access to managed objects. 95 - STD 16, RFC 1155 [1] which defines the Structure of Management 96 Information (SMIv1), the mechanisms used for describing and 97 naming objects for the purpose of management. 99 - STD 16, RFC 1212 [3] which defines a more concise description 100 mechanism, which is wholly consistent with the SMIv1. 102 - RFC 1215 [4] which defines a convention for defining Traps for 103 use with the SMIv1. 105 Note that throughout this document, the term 'SMIv1' is used. This 106 term generally refers to the information presented in RFC 1155, RFC 107 1212, and RFC 1215. 109 1.2. SNMPv2 111 SNMPv2 is defined by these documents: 113 - STD 58, RFC 2578 which defines Version 2 of the Structure of 114 Management Information (SMIv2) [7]. 116 - STD 58, RFC 2579 which defines common MIB "Textual 117 Conventions" [8]. 119 - STD 58, RFC 2580 which defines Conformance Statements and 120 requirements for defining agent and manager capabilities [9]. 122 - RFC 1905 which defines the Protocol Operations used in 123 processing [10]. 125 - RFC 1906 which defines the Transport Mappings used "on the 126 wire" [11]. 128 - RFC 1907 which defines the basic Management Information Base 129 upon which other MIBs can be built [12]. 131 Note that SMIv2 as used throughout this document refers to the first 132 three documents listed above (RFCs 2578, 2579, and 2580). 134 The following document augments the definition of SNMPv2: 136 - RFC 1901 [6] is an Experimental definition for using SNMPv2 137 PDUs within a community-based message wrapper. This is 138 referred to throughout this document as SNMPv2c. 140 1.3. SNMPv3 142 SNMPv3 is defined by these documents: 144 - RFC 2571 which defines an Architecture for Describing SNMP 145 Management Frameworks [16]. 147 - RFC 2572 which defines Message Processing and Dispatching 148 [17]. 150 - RFC 2573 which defines various SNMP Applications [18]. 152 - RFC 2574 which defines the User-based Security Model (USM), 153 providing for both Authenticated and Private (encrypted) SNMP 154 messages [19]. 156 - RFC 2575 which defines the View-based Access Control Model 157 (VACM), providing the ability to limit access to different MIB 158 objects on a per-user basis [20]. 160 SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 and 161 the SMIv2 definitions of 2578 through 2580 described above. 163 1.4. SNMPv1 and SNMPv2 MIB Instrumentation 165 In several places, this document refers to 'SNMPv1 MIB 166 Instrumentation' and 'SNMPv2 MIB Instrumentation'. These terms refer 167 to the part of an SNMP agent which actually implements MIB objects, 168 and which actually initiates generation of notifications. 169 Differences between the two types of MIB instrumentation are: 171 - Error-status values generated. 173 - Generation of exception codes. 175 - Use of the Counter64 data type. 177 - The format of parameters provided when a notification is 178 generated. 180 SNMPv1 MIB instrumentation may generate SNMPv1 error-status values, 181 will never generate exception codes nor use the Counter64 data type, 182 and will provide SNMPv1 format parameters for generating 183 notifications. Note also that SNMPv1 MIB instrumentation will 184 actually never generate a readOnly error (a noSuchName error would 185 always occur in the situation where one would expect a readOnly 186 error). 188 SNMPv2 MIB instrumentation may generate SNMPv2 error-status values, 189 may generate exception codes, may use the Counter64 data type, and 190 will provide SNMPv2 format parameters for generating notifications. 191 Note that SNMPv2 MIB instrumentation will never generate readOnly, 192 noSuchName, or badValue errors. 194 Note that a particular multi-lingual implementation may choose to 195 implement all MIB instrumentation as SNMPv2 MIB instrumentation. 197 2. SMI and Management Information Mappings 199 The SMIv2 approach towards describing collections of managed objects 200 is nearly a proper superset of the approach defined in the SMIv1. 201 For example, both approaches use an adapted subset of ASN.1 (1988) 202 [11] as the basis for a formal descriptive notation. Indeed, one 203 might note that the SMIv2 approach largely codifies the existing 204 practice for defining MIB modules, based on extensive experience with 205 the SMIv1. 207 The following sections consider the three areas: MIB modules, 208 compliance statements, and capabilities statements. 210 2.1. MIB Modules 212 MIB modules defined using the SMIv1 may continue to be used with 213 protocol versions which use SNMPv2 PDUs. However, for the MIB 214 modules to conform to the SMIv2, the following changes SHALL be made: 216 2.1.1. Object Definitions 218 In general, conversion of a MIB module does not require the 219 deprecation of the objects contained therein. If the semantics of an 220 object truly changes, the object SHALL be deprecated, otherwise 221 deprecation is not required. 223 (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of 224 RFC1155-SMI and RFC-1212. 226 (2) The MODULE-IDENTITY macro MUST be invoked immediately after any 227 IMPORTs statement. 229 (3) For any object with an integer-valued SYNTAX clause, in which the 230 corresponding INTEGER does not have a range restriction (i.e., the 231 INTEGER has neither a defined set of named-number enumerations nor 232 an assignment of lower- and upper-bounds on its value), the object 233 MUST have the value of its SYNTAX clause changed to Integer32. 235 (4) For any object with a SYNTAX clause value of Counter, the object 236 MUST have the value of its SYNTAX clause changed to Counter32. 238 (5) For any object with a SYNTAX clause value of Gauge, the object MUST 239 have the value of its SYNTAX clause changed to Gauge32. 241 (6) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS 242 clause. The value of the MAX-ACCESS clause SHALL be the same as 243 that of the ACCESS clause unless some other value makes "protocol 244 sense" as the maximal level of access for the object. In 245 particular, object types for which instances can be explicitly 246 created by a protocol set operation, SHALL have a MAX-ACCESS clause 247 of "read-create". If the value of the ACCESS clause is "write- 248 only", then the value of the MAX-ACCESS clause MUST be "read- 249 write", and the DESCRIPTION clause SHALL note that reading this 250 object will result in implementation-specific results. 252 (7) For all objects, if the value of the STATUS clause is "mandatory" 253 or "optional", the value MUST be replaced with "current", 254 "deprecated", or "obsolete" depending on the current usage of such 255 objects. 257 (8) For any object not containing a DESCRIPTION clause, the object MUST 258 have a DESCRIPTION clause defined. 260 (9) For any object corresponding to a conceptual row which does not 261 have an INDEX clause, the object MUST have either an INDEX clause 262 or an AUGMENTS clause defined. 264 (10) If any INDEX clause contains a reference to an object with a syntax 265 of NetworkAddress, then a new object MUST be created and placed in 266 this INDEX clause immediately preceding the object whose syntax is 267 NetworkAddress. This new object MUST have a syntax of INTEGER, it 268 MUST be not-accessible, and its value MUST always be 1. 270 (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be 271 changed to IpAddress. 273 (12) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER 274 value which is expressed as a collection of sub-identifiers, the 275 value MUST be changed to reference a single ASN.1 identifier. This 276 may require defining a series of new objects in order to define the 277 single ASN.1 identifier. 279 Other changes are desirable, but not necessary: 281 (1) Creation and deletion of conceptual rows is inconsistent using the 282 SMIv1. The SMIv2 corrects this. As such, if the MIB module 283 undergoes review early in its lifetime, and it contains conceptual 284 tables which allow creation and deletion of conceptual rows, then 285 the objects relating to those tables MAY be deprecated and replaced 286 with objects defined using the new approach. The new approach can 287 be found in section 7 of RFC2578 [7], and the RowStatus and 288 StorageType TEXTUAL-CONVENTIONs are described in section 2 of 289 RFC2579 [8]. 291 (2) For any object with a string-valued SYNTAX clause, in which the 292 corresponding OCTET STRING does not have a size restriction (i.e., 293 the OCTET STRING has no assignment of lower- and upper-bounds on 294 its length), the bounds for the size of the object SHOULD be 295 defined. 297 (3) All textual conventions informally defined in the MIB module SHOULD 298 be redefined using the TEXTUAL-CONVENTION macro. Such a change 299 would not necessitate deprecating objects previously defined using 300 an informal textual convention. 302 (4) For any object which represents a measurement in some kind of 303 units, a UNITS clause SHOULD be added to the definition of that 304 object. 306 (5) For any conceptual row which is an extension of another conceptual 307 row, i.e., for which subordinate columnar objects both exist and 308 are identified via the same semantics as the other conceptual row, 309 an AUGMENTS clause SHOULD be used in place of the INDEX clause for 310 the object corresponding to the conceptual row which is an 311 extension. 313 Finally, to avoid common errors in SMIv1 MIB modules: 315 (1) For any non-columnar object that is instanced as if it were 316 immediately subordinate to a conceptual row, the value of the 317 STATUS clause of that object MUST be changed to "obsolete". 319 (2) For any conceptual row object that is not contained immediately 320 subordinate to a conceptual table, the value of the STATUS clause 321 of that object (and all subordinate objects) MUST be changed to 322 "obsolete". 324 2.1.2. Trap and Notification Definitions 326 If a MIB module is changed to conform to the SMIv2, then each 327 occurrence of the TRAP-TYPE macro MUST be changed to a corresponding 328 invocation of the NOTIFICATION-TYPE macro: 330 (1) The IMPORTS statement MUST NOT reference RFC-1215 [4], and MUST 331 reference SNMPv2-SMI instead. 333 (2) The ENTERPRISE clause MUST be removed. 335 (3) The VARIABLES clause MUST be renamed to the OBJECTS clause. 337 (4) The STATUS clause MUST be added, with a value of 'current'. 339 (5) The value of an invocation of the NOTIFICATION-TYPE macro is an 340 OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. 341 Specifically, if the value of the ENTERPRISE clause is not 'snmp' 342 then the value of the invocation SHALL be the value of the 343 ENTERPRISE clause extended with two sub-identifiers, the first of 344 which has the value 0, and the second has the value of the 345 invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause 346 is 'snmp', then the value of the invocation of the NOTIFICATION- 347 TYPE macro SHALL be mapped in the same manner as described in 348 section 3.1 in this document. 350 (6) The DESCRIPTION clause MUST be added, if not already present. 352 (7) One or more NOTIFICATION-GROUPs SHOULD be defined, and related 353 notifications SHOULD be collected into those groups. 355 2.2. Compliance Statements 357 For those information modules which are "standards track", a 358 corresponding invocation of the MODULE-COMPLIANCE macro and related 359 OBJECT-GROUP macros MUST be included within the information module 360 (or in a companion information module), and any commentary text in 361 the information module which relates to compliance SHOULD be removed. 362 Typically this editing can occur when the information module 363 undergoes review. 365 Note that it is always good practice to add compliance statements to 366 a MIB document, even if the document is not on the standards track. 368 2.3. Capabilities Statements 370 RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's 371 capabilities with respect to one or more MIB modules. Converting 372 such a description for use with the SMIv2 requires these changes: 374 (1) The macro name AGENT-CAPABILITIES SHOULD be used instead of MODULE- 375 CONFORMANCE. 377 (2) The STATUS clause SHOULD be added, with a value of 'current'. 379 (3) All occurrences of the CREATION-REQUIRES clause SHOULD either be 380 omitted if appropriate, or be changed such that the semantics are 381 consistent with RFC2580 [9]. 383 In order to ease coexistence, object groups defined in an SMIv1 384 compliant MIB module may be referenced by the INCLUDES clause of an 385 invocation of the AGENT-CAPABILITIES macro: upon encountering a 386 reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB 387 module, all leaf objects which are subordinate to the subtree and 388 have a STATUS clause value of mandatory are deemed to be INCLUDEd. 389 (Note that this method is ambiguous when different revisions of an 390 SMIv1 MIB have different sets of mandatory objects under the same 391 subtree; in such cases, the only solution is to rewrite the MIB using 392 the SMIv2 in order to define the object groups unambiguously.) 394 3. Translating Notifications Parameters 396 This section describes how parameters used for generating 397 notifications are translated between the format used for SNMPv1 398 notification protocol operations and the format used for SNMPv2 399 notification protocol operations. The parameters used to generate a 400 notification are called 'notification parameters'. The format of 401 parameters used for SNMPv1 notification protocol operations is 402 refered to in this document as 'SNMPv1 notification parameters.' The 403 format of parameters used for SNMPv2 notification protocol operations 404 is refered to in this document as 'SNMPv2 notification parameters.' 406 The SMI version used to define a notification will usually determine 407 which type of notification parameters are provided by MIB 408 instrumentation when a notification is generated. 410 The situations where notification parameters MUST be translated are: 412 - When MIB instrumentation in an entity generates a set of 413 notification parameters in a particular format, and the 414 configuration of the entity indicates that the notification 415 must be sent using an SNMP message version that requires the 416 other format for notification parameters. 418 - When a proxy receives a notification that was sent using an 419 SNMP message version that requires one format of notification 420 parameters, and must forward the notification using an SNMP 421 message version that requires the other format of notification 422 parameters. 424 In addition, it MAY be desirable to translate notification parameters 425 in a notification receiver application in order to present 426 notifications to the end user in a consistent format. 428 Note that for the purposes of this section, the set of notification 429 parameters is independent of whether the notification is to be sent 430 as a trap or an inform. 432 SNMPv1 notification parameters consist of: 434 - An enterprise parameter (OBJECT IDENTIFIER). 436 - An agent-addr parameter (NetworkAddress). 438 - A generic-trap parameter (INTEGER). 440 - A specific-trap parameter (INTEGER). 442 - A time-stamp parameter (TimeTicks). 444 - A list of variable-bindings (VarBindList). 446 SNMPv2 notification parameters consist of: 448 - A sysUpTime parameter (TimeTicks). This appears in the first 449 variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU. 451 - An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in 452 the second variable-binding in an SNMPv2-Trap-PDU or 453 InformRequest-PDU. 455 - A list of variable-bindings (VarBindList). This refers to all 456 but the first two variable-bindings in an SNMPv2-Trap-PDU or 457 InformRequest-PDU. 459 3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification 460 Parameters 462 The following procedure describes how to translate SNMPv1 463 notification parameters into SNMPv2 notification parameters: 465 (1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the 466 SNMPv1 time-stamp parameter. 468 (2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', 469 the SNMPv2 snmpTrapOID parameter SHALL be the concatentation of the 470 SNMPv1 enterprise parameter and two additional sub-identifiers, 471 '0', and the SNMPv1 specific-trap parameter. 473 (3) If the SNMPv1 generic-trap parameter is not 474 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be 475 the corresponding trap as defined in section 2 of RFC1907 [12]: 477 generic-trap parameter snmpTrapOID.0 478 ====================== ============= 479 0 1.3.6.1.6.3.1.1.5.1 (coldStart) 480 1 1.3.6.1.6.3.1.1.5.2 (warmStart) 481 2 1.3.6.1.6.3.1.1.5.3 (linkDown) 482 3 1.3.6.1.6.3.1.1.5.4 (linkUp) 483 4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 484 5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 486 (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. 487 In addition, if the translation is being performed by a proxy in 488 order to forward a received trap, three additional variable- 489 bindings will be appended, if these three additional variable- 490 bindings do not already exist in the SNMPv1 variable-bindings. The 491 name portion of the first additional variable binding SHALL contain 492 snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent- 493 addr parameter. The name portion of the second additional variable 494 binding SHALL contain snmpTrapCommunity.0, and the value SHALL 495 contain the value of the community-string field from the received 496 SNMPv1 message which contained the SNMPv1 Trap-PDU. The name 497 portion of the third additional variable binding SHALL contain 498 snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1 499 enterprise parameter. 501 3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification 502 Parameters 504 The following procedure describes how to translate SNMPv2 505 notification parameters into SNMPv1 notification parameters: 507 (1) The SNMPv1 enterprise parameter SHALL be determined as follows: 509 - If the SNMPv2 snmpTrapOID parameter is one of the standard 510 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 511 parameter SHALL be set to the value of the variable-binding in 512 the SNMPv2 variable-bindings whose name is 513 snmpTrapEnterprise.0 if that variable-binding exists. If it 514 does not exist, the SNMPv1 enterprise parameter SHALL be set 515 to the value 'snmpTraps' as defined in RFC1907 [12]. 517 - If the SNMPv2 snmpTrapOID parameter is not one of the standard 518 traps as defined in RFC1907 [12], then the SNMPv1 enterprise 519 parameter SHALL be set to the SNMPv2 snmpTrapOID parameter as 520 follows: 522 - If the next-to-last sub-identifier of the snmpTrapOID is 523 zero, then the SMIv1 enterprise SHALL be the SMIv2 524 snmpTrapOID with the last 2 sub-identifiers removed, 525 otherwise 527 - If the next-to-last sub-identifier of the snmpTrapOID is 528 non-zero, then the SMIv1 enterprise SHALL be the SMIv2 529 snmpTrapOID with the last sub-identifier removed. 531 (2) The SNMPv1 agent-addr parameter SHALL be determined based on the 532 situation in which the translation occurs. 534 - If the translation occurs within a notification originator 535 application, and the notification is to be sent over IP, the 536 SNMPv1 agent-addr parameter SHALL be set to the IP address of 537 the SNMP entity in which the notification originator resides. 538 If the notification is to be sent over some other transport, 539 the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0. 541 - If the translation occurs within a proxy application, the 542 proxy must attempt to extract the original source of the 543 notification from the variable-bindings. If the SNMPv2 544 variable-bindings contains a variable binding whose name is 545 snmpTrapAddress.0, the agent-addr parameter SHALL be set to 546 the value of that variable binding. Otherwise, the SNMPv1 547 agent-addr parameter SHALL be set to 0.0.0.0. 549 (3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 550 defined in RFC1907 [12], the SNMPv1 generic-trap parameter SHALL be 551 set as follows: 553 snmpTrapOID.0 parameter generic-trap 554 =============================== ============ 555 1.3.6.1.6.3.1.1.5.1 (coldStart) 0 556 1.3.6.1.6.3.1.1.5.2 (warmStart) 1 557 1.3.6.1.6.3.1.1.5.3 (linkDown) 2 558 1.3.6.1.6.3.1.1.5.4 (linkUp) 3 559 1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4 560 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5 562 Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6. 564 (4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as 565 defined in RFC1907 [12], the SNMPv1 specific-trap parameter SHALL 566 be set to zero. Otherwise, the SNMPv1 specific-trap parameter 567 SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID 568 parameter. 570 (5) The SNMPv1 time-stamp parameter SHALL be taken directly from the 571 SNMPv2 sysUpTime parameter. 573 (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings. 574 Note, however, that if the SNMPv2 variable-bindings contain any 575 objects whose type is Counter64, the translation to SNMPv1 576 notification parameters cannot be performed. In this case, the 577 notification cannot be encoded in an SNMPv1 packet (and so the 578 notification cannot be sent using SNMPv1, see section 4.1.3 and 579 section 4.2). 581 4. Approaches to Coexistence in a Multi-lingual Network 583 There are two basic approaches to coexistence in a multi-lingual 584 network, multi-lingual implementations and proxy implementations. 585 Multi-lingual implementations allow elements in a network to 586 communicate with each other using an SNMP version which both elements 587 support. This allows a multi-lingual implementation to communicate 588 with any mono-lingual implementation, regardless of the SNMP version 589 supported by the mono-lingual implementation. 591 Proxy implementations provide a mechanism for translating between 592 SNMP versions using a third party network element. This allows 593 network elements which support only a single, but different, SNMP 594 version to communicate with each other. Proxy implementations are 595 also useful for securing communications over an insecure link between 596 two locally secure networks. 598 4.1. Multi-lingual implementations 600 This approach requires an entity to support multiple SNMP message 601 versions. Typically this means supporting SNMPv1, SNMPv2c, and 602 SNMPv3 message versions. The behaviour of various types of SNMP 603 applications which support multiple message versions is described in 604 the following sections. This approach allows entities which support 605 multiple SNMP message versions to coexist with and communicate with 606 entities which support only a single SNMP message version. 608 4.1.1. Command Generator 610 A command generator must select an appropriate message version when 611 sending requests to another entity. One way to achieve this is to 612 consult a local database to select the appropriate message version. 614 In addition, a command generator should 'downgrade' GetBulk requests 615 to GetNext requests when selecting SNMPv1 as the message version for 616 an outgoing request. This is done by simply changing the operation 617 type to GetNext, ignoring any non-repeaters and max-repetitions 618 values, and setting error-status and error-index to zero. 620 4.1.2. Command Responder 622 A command responder must be able to deal with MIB instrumentation 623 that is written using both the SNMPv1 and SNMPv2. There are three 624 aspects to dealing with this. A command responder must: 626 - Deal correctly with SNMPv2 MIB instrumentation that returns a 627 Counter64 value while processing an SNMPv1 message, 629 - Deal correctly with SNMPv2 MIB instrumentation that returns 630 one of the three exception values while processing an SNMPv1 631 message, and 633 - Map SNMPv2 error codes returned from SNMPv2 MIB 634 instrumentation into SNMPv1 error codes when processing an 635 SNMPv1 message. 637 Note that SNMPv1 error codes can be used without any change when 638 processing SNMPv2c or SNMPv3 messages. 640 The following sections describe the behaviour of a command responder 641 application which supports multiple SNMP message versions, and which 642 has access to some combination of SNMPv1 and SNMPv2 MIB 643 instrumentation. 645 4.1.2.1. Handling Counter64 647 The SMIv2 [7] defines one new syntax that is incompatible with SMIv1. 648 This syntax is Counter64. All other syntaxes defined by SMIv2 are 649 compatible with SMIv1. 651 The impact on multi-lingual command responders is that they MUST NOT 652 ever return a variable binding containing a Counter64 value in a 653 response to a request that was received using the SNMPv1 message 654 version. 656 Multi-lingual command responders SHALL take the approach that object 657 instances whose type is Counter64 are implicitly excluded from view 658 when processing an SNMPv1 message. So: 660 - On an SNMPv1 GET request, an error-status of noSuchName SHALL 661 be returned, and the error-index SHALL be set to the variable 662 binding that caused this error. 664 - On an SNMPv1 GetNext request, any object instance which 665 contains a syntax of Counter64 shall be skipped, and the next 666 object instance that follows the one with a syntax of 667 Counter64 SHALL be fetched. This step may need to be repeated 668 several times in order to find an object whose syntax is not 669 Counter64. 671 - Any SET request that has a variable binding with a Counter64 672 value must have come from a SNMPv2 manager, and so it should 673 not cause a problem. However, if an object with SYNTAX of 674 Counter64 is received in an SNMPv1 SET packet, it SHALL result 675 in an ASN.1 parse error since Counter64 is not valid in the 676 SNMPv1 protocol. When an ASN.1 parse error occurs, the counter 677 snmpInASNParseErrs SHALL be incremented and no response is 678 returned. 680 4.1.2.2. Mapping SNMPv2 Exceptions 682 SNMPv2 provides a feature called exceptions, which allow an SNMPv2 683 Response PDU to return as much management information as possible, 684 even when an error occurs. However, SNMPv1 does not support 685 exceptions, and so an SNMPv1 Response PDU cannot return any 686 management information, and can only return an error-status and 687 error-index value. 689 When an SNMPv1 request is received, a command responder MUST check 690 any variable bindings returned from SNMPv2 MIB instrumentation for 691 exception values, and convert these exception values into SNMPv1 692 error codes. 694 The type of exception that can be returned from MIB instrumentation 695 and the action taken depends on the type of SNMP request. 697 - For a GetRequest, a noSuchObject or noSuchInstance exception 698 may be returned. 700 - For a GetNextRequest, an endOfMibView exception may be 701 returned. 703 - No exceptions will be returned for a SetRequest, and a 704 GetBulkRequest should only be received in an SNMPv2c or SNMPv3 705 message, so these request types may be ignored when mapping 706 exceptions. 708 Note that when a response contains multiple exceptions, it is an 709 implementation choice as to which variable binding the error-index 710 should reference. 712 4.1.2.2.1. Mapping noSuchObject and noSuchInstance 714 A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB 715 instrumentation indicates that the requested object instance can not 716 be returned. The SNMPv1 error code for this condition is noSuchName, 717 and so the error-status field of the response PDU SHALL be set to 718 noSuchName. Also, the error-index field SHALL be set to the index of 719 the variable binding for which an exception occurred, and the 720 variable binding list from the original request SHALL be returned 721 with the response PDU. 723 4.1.2.2.2. Mapping endOfMibView 725 When SNMPv2 MIB instrumentation returns a variable binding containing 726 an endOfMibView exception, it indicates that there are no object 727 instances available which lexicographically follow the object in the 728 request. In an SNMPv1 agent, this condition normally results in a 729 noSuchName error, and so the error-status field of the response PDU 730 SHALL be set to noSuchName. Also, the error-index field SHALL be set 731 to the index of the variable binding for which an exception occurred, 732 and the variable binding list from the original request SHALL be 733 returned with the response PDU. 735 4.1.2.3. Processing An SNMPv1 GetRequest 737 When processing an SNMPv1 GetRequest, the following procedures MUST 738 be followed when calling SNMPv2 MIB instrumentation. 740 When such MIB instrumentation returns response data using SNMPv2 741 syntax and error-status values, then: 743 (1) If the error-status is anything other than noError, 745 - The error status SHALL be translated to an SNMPv1 error-status 746 using the table in section 4.3, "Error Status Mappings". 748 - The error-index SHALL be set to the position (in the original 749 request) of the variable binding that caused the error-status. 751 - The variable binding list of the response PDU SHALL be made 752 exactly the same as the variable binding list that was 753 received in the original request. 755 (2) If the error-status is noError, the variable bindings SHALL be 756 checked for any SNMPv2 exception (noSuchObject or noSuchInstance) 757 or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If 758 there are any such variable bindings, one of those variable 759 bindings SHALL be selected (it is an implementation choice as to 760 which is selected), and: 762 - The error-status SHALL be set to noSuchName, 764 - The error-index SHALL be set to the position (in the variable 765 binding list of the original request) of the selected variable 766 binding, and 768 - The variable binding list of the response PDU SHALL be exactly 769 the same as the variable binding list that was received in the 770 original request. 772 (3) If there are no such variable bindings, then: 774 - The error-status SHALL be set to noError, 776 - The error-index SHALL be set to zero, and 778 - The variable binding list of the response SHALL be composed 779 from the data as it is returned by the MIB instrumentation. 781 4.1.2.4. Processing An SNMPv1 GetNextRequest 783 When processing an SNMPv1 GetNextRequest, the following procedures 784 MUST be followed when SNMPv2 MIB instrumentation is called as part of 785 processing the request. There may be repetitive calls to (possibly 786 different pieces of) MIB instrumentation to try to find the first 787 object which lexicographically follows each of the objects in the 788 request. This is implementation specific. These procedures are 789 followed only for data returned from SNMPv2 MIB instrumentation. 790 Data returned from SNMPv1 MIB instrumentation may be treated in the 791 normal manner for an SNMPv1 request. 793 First, if the MIB instrumentation returns an error-status of anything 794 other than noError: 796 (1) The error status SHALL be translated to an SNMPv1 error-status 797 using the table in section 4.3, "Error Status Mappings". 799 (2) The error-index SHALL be set to the position (in the original 800 request) of the variable binding that caused the error-status. 802 (3) The variable binding list of the response PDU SHALL be exactly the 803 same as the variable binding list that was received in the original 804 request. 806 Otherwise, if the MIB instrumentation returns an error-status of 807 noError: 809 (1) Any variable bindings containing an SNMPv2 syntax of Counter64 810 SHALL be considered to be not in view, and the MIB instrumentation 811 SHALL be called as often as is required until either a value other 812 than Counter64 is returned, or an error occurs. 814 (2) If there is any variable binding that contains an SNMPv2 exception 815 endOfMibView (there may be more than one, it is an implementation 816 decision as to which is chosen): 818 - The error-status SHALL be set to noSuchName, 820 - The error-index SHALL be set to the position (in the variable 821 binding list of the original request) of the variable binding 822 that returned such an SNMPv2 exception, and 824 - The variable binding list of the response PDU SHALL be exactly 825 the same as the variable binding list that was received in the 826 original request. 828 (3) If there are no such variable bindings, then: 830 - The error-status SHALL be set to noError, 832 - The error-index SHALL be set to zero, and 834 - The variable binding list of the response SHALL be composed 835 from the data as it is returned by the MIB instrumentation. 837 4.1.3. Notification Originator 839 A notification originator must be able to translate between SNMPv1 840 notifications parameters and SNMPv2 notification parameters in order 841 to send a notification using a particular SNMP message version. If 842 MIB instrumentation presents a notification using SNMPv1 notification 843 parameters, and configuration information specifies that 844 notifications be sent using SNMPv2c or SNMPv3, the notification 845 parameters must be translated to SNMPv2 notification parameters. 846 Likewise, if MIB instrumentation presents a notification using SNMPv2 847 notification parameters, and configuration information specifies that 848 notifications be sent using SNMPv1, the notification parameters must 849 be translated to SNMPv1 notification parameters. In this case, if 850 the notification cannot be translated (due to the presence of a 851 Counter64 type), it will not be sent using SNMPv1. 853 When a notification originator generates a notification, using 854 parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- 855 MIB, if the SNMP version used to generate the notification is SNMPv1, 856 the PDU type used will always be a TrapPDU, regardless of whether the 857 value of snmpNotifyType is trap(1) or inform(2). 859 Note also that access control and notification filtering are 860 performed in the usual manner for notifications, regardless of the 861 SNMP message version to be used when sending a notification. The 862 parameters for performing access control are found in the usual 863 manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP- 864 NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in 865 order to perform the access check specified in [18], section 3.3, 866 bullet (3), the notification originator may need to generate a value 867 for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of 868 this document. If the SNMPv1 notification parameters being used were 869 previously translated from a set of SNMPv2 notification parameters, 870 this value may already be known, in which case it need not be 871 generated. 873 4.1.4. Notification Receiver 875 There are no special requirements of a notification receiver. 876 However, an implementation may find it useful to allow a higher level 877 application to request whether notifications should be delivered to a 878 higher level application using SNMPv1 notification parameter or 879 SNMPv2 notification parameters. The notification receiver would then 880 translate notification parameters when required in order to present a 881 notification using the desired set of parameters. 883 4.2. Proxy Implementations 885 A proxy implementation may be used to enable communication between 886 entities which support different SNMP message versions. This is 887 accomplished in a proxy forwarder application by performing 888 translations on a PDU in the following situations: 890 - If a GetBulkRequest-PDU is received and must be forwarded 891 using the SNMPv1 message version, the proxy forwarder SHALL 892 set the non-repeaters and max-repetitions fields to 0, and 893 SHALL set the tag of the PDU to GetNextRequest-PDU. 895 - If a GetResponse-PDU is received whose error-status field has 896 a value of 'tooBig', and the message will be forwarded using 897 the SNMPv2c or SNMPv3 message version, the proxy forwarder 898 SHALL remove the contents of the variable-bindings field 899 before forwarding the response. 901 - If a GetResponse-PDU is received in response to a GetRequest- 902 PDU (previously generated by the proxy) which contains 903 variable-bindings of type Counter64 or which contain an SNMPv2 904 exception code, and the message would be forwarded using the 905 SNMPv1 message version, the proxy MUST generate an alternate 906 response PDU consisting of the request-id and variable 907 bindings from the original SNMPv1 request, containing a 908 noSuchName error-status value, and containing an error-index 909 value indicating the position of the variable-binding 910 containing the Counter64 type or exception code. 912 - If a GetResponse-PDU is received in response to a 913 GetNextRequest-PDU (previously generated by the proxy) which 914 contains variable-bindings that contain an SNMPv2 exception 915 code, and the message would be forwarded using the SNMPv1 916 message version, the proxy MUST generate an alternate response 917 PDU consisting of the request-id and variable bindings from 918 the original SNMPv1 request, containing a noSuchName error- 919 status value, and containing an error-index value indicating 920 the position of the variable-binding containing the exception 921 code. 923 - If a GetResponse-PDU is received in response to a 924 GetNextRequest-PDU (previously generated by the proxy) which 925 contains variable-bindings of type Counter64, the proxy MUST 926 re-send the entire GetNextRequest-PDU, with the following 927 modifications. For any variable bindings in the received 928 GetResponse which contained Counter64 types, the proxy 929 substitutes the object names of these variable bindings for 930 the corresponding object names in the previously-sent 931 GetNextRequest. The proxy MUST repeat this process until no 932 Counter64 objects are returned. Note that an implementation 933 may attempt to optimize this process of skipping Counter64 934 objects. One approach to such an optimization would be to 935 replace the last sub-identifier of the object names of 936 varbinds containing a Counter64 type with 65535 if that sub- 937 identifier is less than 65535, or with 4294967295 if that 938 sub-identifier is greater than 65535. This approach should 939 skip multiple instances of the same Counter64 object, while 940 maintaining compatibility with some broken agent 941 implementations (which only use 16-bit integers for sub- 942 identifiers). 944 - If a GetResponse-PDU is received which contains an SNMPv2 945 error-status value of wrongValue, wrongEncoding, wrongType, 946 wrongLength, inconsistentValue, noAccess, notWritable, 947 noCreation, inconsistentName, resourceUnavailable, 948 commitFailed, undoFailed, or authorizationError, the error- 949 status value is modified using the mappings in section 4.3. 951 - If a Trap-PDU is received, and will be forwarded using the 952 SNMPv2c or SNMPv3 message version, the proxy SHALL apply the 953 translation rules described in section 3, and SHALL forward 954 the notification as an SNMPv2-Trap-PDU. 956 - If an SNMPv2-Trap-PDU is received, and will be forwarded using 957 the SNMPv1 message version, the proxy SHALL apply the 958 translation rules described in section 3, and SHALL forward 959 the notification as a Trap-PDU. Note that if the translation 960 fails dues to the existence of a Counter64 data-type in the 961 received SNMPv2-Trap-PDU, the trap cannot be forwarded using 962 SNMPv1. 964 - If an InformRequest-PDU is received, any configuration 965 information indicating that it would be forwarded using the 966 SNMPv1 message version SHALL be ignored. An InformRequest-PDU 967 can only be forwarded using the SNMPv2c or SNMPv3 message 968 version. The InformRequest-PDU may still be forwarded if 969 there is other configuration information indicating that it 970 should be forwarded using SNMPv2c or SNMPv3. 972 - In all other cases, the proxy SHALL forward a received PDU 973 without change. 975 Note that when an SNMPv1 agent generates a message containing a 976 Trap-PDU which is subsequently forwarded by one or more proxy 977 forwarders using SNMP versions other than SNMPv1, the community 978 string and agent-addr fields from the original message generated by 979 the SNMPv1 agent will be preserved through the use of the 980 snmpTrapAddress and snmpTrapCommunity objects. 982 4.2.1. Deployment Hint 984 The process of repeated GetNext requests used by a proxy when 985 Counter64 types are returned can be expensive. When deploying a 986 proxy, this can be avoided by configuring the target agents to which 987 the proxy forwards requests in a manner such that any objects of type 988 Counter64 are in fact not-in-view for the principal that the proxy is 989 using when communicating with these agents. 991 4.3. Error Status Mappings 993 The following tables shows the mappings of SNMPv1 error-status values 994 into SNMPv2 error-status values, and the mappings of SNMPv2 error- 995 status values into SNMPv1 error-status values. 997 SNMPv1 error-status SNMPv2 error-status 998 =================== =================== 999 noError noError 1000 tooBig tooBig 1001 noSuchName noSuchName 1002 badValue badValue 1003 genErr genErr 1005 SNMPv2 error-status SNMPv1 error-status 1006 =================== =================== 1007 noError noError 1008 tooBig tooBig 1009 genErr genErr 1010 wrongValue badValue 1011 wrongEncoding badValue 1012 wrongType badValue 1013 wrongLength badValue 1014 inconsistentValue badValue 1015 noAccess noSuchName 1016 notWritable noSuchName 1017 noCreation noSuchName 1018 inconsistentName noSuchName 1019 resourceUnavailable genErr 1020 commitFailed genErr 1021 undoFailed genErr 1022 authorizationError noSuchName 1024 5. Message Processing Models and Security Models 1026 In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, 1027 the following models are defined in this document: 1029 - The SNMPv1 Message Processing Model 1031 - The SNMPv1 Community-Based Security Model 1033 The following models are also described in this document: 1035 - The SNMPv2c Message Processing Model 1037 - The SNMPv2c Community-Based Security Model 1039 In most respects, the SNMPv1 Message Processing Model and the 1040 SNMPv2c Message Processing Model are identical, and so these 1041 are not discussed independently in this document. Differences 1042 between the two models are described as required. 1044 Similarly, the SNMPv1 Community-Based Security Model and the 1045 SNMPv2c Community-Based Security Model are nearly identical, 1046 and so are not discussed independently. Differences between 1047 these two models are also described as required. 1049 5.1. Mappings 1051 The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model 1052 require mappings between parameters used in SNMPv1 (and SNMPv2c) 1053 messages, and the version independent parameters used in the SNMP 1054 architecture [16]. The parameters which MUST be mapped consist of the 1055 SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and 1056 contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) 1057 is provided in this document in order to perform these mappings. This 1058 MIB provides mappings in both directions, that is, a community name may 1059 be mapped to a securityName, contextEngineID, and contextName, or the 1060 combination of securityName, contextEngineID, and contextName may be 1061 mapped to a community name. 1063 5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model 1065 The SNMPv1 Message Processing Model handles processing of SNMPv1 1066 messages. The processing of messages is handled generally in the 1067 same manner as described in RFC1157 [2], with differences and 1068 clarifications as described in the following sections. The 1069 SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for 1070 SNMPv2c is 1). 1072 5.2.1. Processing An Incoming Request 1074 In RFC1157 [2], section 4.1, item (3) for an entity which receives a 1075 message, states that various parameters are passed to the 'desired 1076 authentication scheme.' The desired authentication scheme in this 1077 case is the SNMPv1 Community-Based Security Model, which will be 1078 called using the processIncomingMsg ASI. The parameters passed to 1079 this ASI are: 1081 - The messageProcessingModel, which will be 0 (or 1 for 1082 SNMPv2c). 1084 - The maxMessageSize, which should be the maximum size of a 1085 message that the receiving entity can generate (since there is 1086 no such value in the received message). 1088 - The securityParameters, which consist of the community string 1089 and the message's source and destination transport domains and 1090 addresses. 1092 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1094 - The securityLevel, which will be noAuthNoPriv. 1096 - The wholeMsg and wholeMsgLength. 1098 The Community-Based Security Model will attempt to select a row in 1099 the snmpCommunityTable. This is done by performing a search through 1100 the snmpCommunityTable in lexicographic order. The first entry for 1101 which the following matching criteria are satisfied will be selected: 1103 - The community string is equal to the snmpCommunityName value. 1105 - If the snmpCommunityTransportTag is an empty string, it is 1106 ignored for the purpose of matching. If the 1107 snmpCommunityTransportTag is not an empty string, the 1108 transportDomain and transportAddress from which the message 1109 was received must match one of the entries in the 1110 snmpTargetAddrTable selected by the snmpCommunityTransportTag 1111 value. 1113 If no such entry can be found, an authentication failure occurs as 1114 described in RFC1157 [2]. 1116 The parameters returned from the Community-Based Security Model are: 1118 - The securityEngineID, which will always be the local value of 1119 snmpEngineID.0. 1121 - The securityName. 1123 - The scopedPDU. Note that this parameter will actually consist 1124 of three values, the contextSnmpEngineID, the contextName, and 1125 the PDU. These must be separate values, since the first two 1126 do not actually appear in the message. 1128 - The maxSizeResponseScopedPDU. 1130 - The securityStateReference. 1132 The appropriate SNMP application will then be called (depending on 1133 the value of the contextEngineID and the request type in the PDU) 1134 using the processPdu ASI. The parameters passed to this ASI are: 1136 - The messageProcessingModel, which will be 0 (or 1 for 1137 SNMPv2c). 1139 - The securityModel, which will be 1 (or 2 for SNMPv2c). 1141 - The securityName, which was returned from the call to 1142 processIncomingMsg. 1144 - The securityLevel, which is noAuthNoPriv. 1146 - The contextEngineID, which was returned as part of the 1147 ScopedPDU from the call to processIncomingMsg. 1149 - The contextName, which was returned as part of the ScopedPDU 1150 from the call to processIncomingMsg. 1152 - The pduVersion, which should indicate an SNMPv1 version PDU 1153 (if the message version was SNMPv2c, this would be an SNMPv2 1154 version PDU). 1156 - The PDU, which was returned as part of the ScopedPDU from the 1157 call to processIncomingMsg. 1159 - The maxSizeResponseScopedPDU which was returned from the call 1160 to processIncomingMsg. 1162 - The stateReference which was returned from the call to 1163 processIncomingMsg. 1165 The SNMP application should process the request as described 1166 previously in this document. Note that access control is applied by 1167 an SNMPv3 command responder application as usual. The parameters as 1168 passed to the processPdu ASI will be used in calls to the 1169 isAccessAllowed ASI. 1171 5.2.2. Generating An Outgoing Response 1173 There is no special processing required for generating an outgoing 1174 response. However, the community string used in an outgoing response 1175 must be the same as the community string from the original request. 1176 The original community string MUST be present in the stateReference 1177 information of the original request. 1179 5.2.3. Generating An Outgoing Notification 1181 In a multi-lingual SNMP entity, the parameters used for generating 1182 notifications will be obtained by examining the SNMP-TARGET-MIB and 1183 SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 1184 Message Processing Model using the sendPdu ASI. The SNMPv1 Message 1185 Processing Model will attempt to locate an appropriate community 1186 string in the snmpCommunityTable based on the parameters passed to 1187 the sendPdu ASI. This is done by performing a search through the 1188 snmpCommunityTable in lexicographic order. The first entry for which 1189 the following matching criteria are satisfied will be selected: 1191 - The securityName must be equal to the 1192 snmpCommunitySecurityName value. 1194 - The contextEngineID must be equal to the 1195 snmpCommunityContextEngineID value. 1197 - The contextName must be equal to the snmpCommunityContextName 1198 value. 1200 - If the snmpCommunityTransportTag is an empty string, it is 1201 ignored for the purpose of matching. If the 1202 snmpCommunityTransportTag is not an empty string, the 1203 transportDomain and transportAddress must match one of the 1204 entries in the snmpTargetAddrTable selected by the 1205 snmpCommunityTransportTag value. 1207 If no such entry can be found, the notification is not sent. 1208 Otherwise, the community string used in the outgoing notification 1209 will be the value of the snmpCommunityName column of the selected 1210 row. 1212 5.3. The SNMP Community MIB Module 1214 The SNMP-COMMUNITY-MIB contains objects for mapping between community 1215 strings and version-independent SNMP message parameters. In 1216 addition, this MIB provides a mechanism for performing source address 1217 validation on incoming requests, and for selecting community strings 1218 based on target addresses for outgoing notifications. These two 1219 features are accomplished by providing a tag in the 1220 snmpCommunityTable which selects sets of entries in the 1221 snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB 1222 augments the snmpTargetAddrTable with a transport address mask value 1223 and a maximum message size value. These values are used only where 1224 explicitly stated. In cases where the snmpTargetAddrTable is used 1225 without mention of these augmenting values, the augmenting values 1226 should be ignored. 1228 The mask value, snmpTargetAddrTMask, allows selected entries in the 1229 snmpTargetAddrTable to specify multiple addresses (rather than just a 1230 single address per entry). This would typically be used to specify a 1231 subnet in an snmpTargetAddrTable rather than just a single address. 1232 The mask value is used to select which bits of a transport address 1233 must match bits of the corresponding instance of 1234 snmpTargetAddrTAddress, in order for the transport address to match a 1235 particular entry in the snmpTargetAddrTable. The value of an 1236 instance of snmpTargetAddrTMask must always be an OCTET STRING whose 1237 length is either zero or the same as that of the corresponding 1238 instance of snmpTargetAddrTAddress. 1240 When checking whether a transport address matches an entry in the 1241 snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- 1242 length OCTET STRING, the mask value is ignored, and the value of 1243 snmpTargetAddrTAddress must exactly match a transport address. 1244 Otherwise, each bit of each octet in the snmpTargetAddrTMask value 1245 corresponds to the same bit of the same octet in the 1246 snmpTargetAddrTAddress value. For bits that are set in the 1247 snmpTargetAddrTMask value (i.e. bits equal to 1), the corresponding 1248 bits in the snmpTargetAddrTAddress value must match the bits in a 1249 transport address. If all such bits match, the transport address is 1250 matched by that snmpTargetAddrTable entry. Otherwise, the transport 1251 address is not matched. 1253 The maximum message size value, snmpTargetAddrMMS, is used to 1254 determine the maximum message size acceptable to another SNMP entity 1255 when the value cannot be determined from the protocol. 1257 SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN 1259 IMPORTS 1260 IpAddress, 1261 MODULE-IDENTITY, 1262 OBJECT-TYPE, 1263 Integer32, 1264 snmpModules 1265 FROM SNMPv2-SMI 1266 RowStatus, 1267 StorageType 1268 FROM SNMPv2-TC 1269 SnmpAdminString, 1270 snmpEngineID 1271 FROM SNMP-FRAMEWORK-MIB 1272 SnmpTagValue, 1273 snmpTargetAddrEntry 1274 FROM SNMP-TARGET-MIB 1275 MODULE-COMPLIANCE, 1276 OBJECT-GROUP 1277 FROM SNMPv2-CONF; 1279 snmpCommunityMIB MODULE-IDENTITY 1280 LAST-UPDATED "199905130000Z" -- 13 May 1999, midnight 1281 ORGANIZATION "SNMPv3 Working Group" 1282 CONTACT-INFO "WG-email: snmpv3@lists@tislabs.com.com 1283 Subscribe: majordomo@lists@tislabs.com.com 1284 In msg body: subscribe snmpv3 1286 Chair: Russ Mundy 1287 TIS Labs at Network Associates 1288 Postal: 3060 Washington Rd 1289 Glenwood MD 21738 1290 USA 1291 Email: mundy@tislabs.com 1292 Phone: +1-301-854-6889 1294 Co-editor: Rob Frye 1295 MCI WorldCom 1297 Postal: 2100 Reston Parkway, Suite 600 1298 Reston, VA 20191 1299 USA 1300 E-mail: Rob.Frye@wcom.com 1301 Phone: +1 703 715 7225 1303 Co-editor: David B. Levi 1304 Nortel Networks 1305 Postal: 3505 Kesterwood Drive 1306 Knoxville, TN 37918 1307 E-mail: dlevi@nortelnetworks.com 1308 Phone: +1 423 686 0432 1310 Co-editor: Shawn A. Routhier 1311 Integrated Systems Inc. 1312 Postal: 333 North Ave 4th Floor 1313 Wakefield, MA 01880 1314 E-mail: sar@epilogue.com 1315 Phone: +1 781 245 0804 1317 Co-editor: Bert Wijnen 1318 IBM T. J. Watson Research 1319 Postal: Schagen 33 1320 3461 GL Linschoten 1321 Netherlands 1322 Email: wijnen@vnet.ibm.com 1323 Phone: +31-348-432-794 1324 " 1326 DESCRIPTION 1327 "This MIB module defines objects to help support coexistence 1328 between SNMPv1, SNMPv2c, and SNMPv3." 1329 REVISION "199905130000Z" -- 13 May 1999 (same as LAST-UPDATED) 1330 DESCRIPTION "The Initial Revision" 1331 ::= { snmpModules 18 } 1333 -- Administrative assignments **************************************** 1335 snmpCommunityMIBObjects OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 } 1336 snmpCommunityMIBConformance OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 } 1338 -- 1339 -- The snmpCommunityTable contains a database of community strings. 1340 -- This table provides mappings between community strings, and the 1341 -- parameters required for View-based Access Control. 1342 -- 1343 snmpCommunityTable OBJECT-TYPE 1344 SYNTAX SEQUENCE OF SnmpCommunityEntry 1345 MAX-ACCESS not-accessible 1346 STATUS current 1347 DESCRIPTION 1348 "The table of community strings configured in the SNMP 1349 engine's Local Configuration Datastore (LCD)." 1350 ::= { snmpCommunityMIBObjects 1 } 1352 snmpCommunityEntry OBJECT-TYPE 1353 SYNTAX SnmpCommunityEntry 1354 MAX-ACCESS not-accessible 1355 STATUS current 1356 DESCRIPTION 1357 "Information about a particular community string." 1358 INDEX { IMPLIED snmpCommunityIndex } 1359 ::= { snmpCommunityTable 1 } 1361 SnmpCommunityEntry ::= SEQUENCE { 1362 snmpCommunityIndex SnmpAdminString, 1363 snmpCommunityName OCTET STRING, 1364 snmpCommunitySecurityName SnmpAdminString, 1365 snmpCommunityContextEngineID SnmpEngineID, 1366 snmpCommunityContextName SnmpAdminString, 1367 snmpCommunityTransportTag SnmpTagValue, 1368 snmpCommunityStorageType StorageType, 1369 snmpCommunityStatus RowStatus 1370 } 1372 snmpCommunityIndex OBJECT-TYPE 1373 SYNTAX SnmpAdminString (SIZE(1..32)) 1374 MAX-ACCESS not-accessible 1375 STATUS current 1376 DESCRIPTION 1377 "The unique index value of a row in this table." 1378 ::= { snmpCommunityEntry 1 } 1380 snmpCommunityName OBJECT-TYPE 1381 SYNTAX OCTET STRING (SIZE(1..64)) 1382 MAX-ACCESS read-create 1383 STATUS current 1384 DESCRIPTION 1385 "The community string for which a row in this table 1386 represents a configuration." 1387 ::= { snmpCommunityEntry 2 } 1389 snmpCommunitySecurityName OBJECT-TYPE 1390 SYNTAX SnmpAdminString 1391 MAX-ACCESS read-create 1392 STATUS current 1393 DESCRIPTION 1394 "A human readable string representing the corresponding 1395 value of snmpCommunityName in a Security Model 1396 independent format." 1397 ::= { snmpCommunityEntry 3 } 1399 snmpCommunityContextEngineID OBJECT-TYPE 1400 SYNTAX SnmpEngineID 1401 MAX-ACCESS read-create 1402 STATUS current 1403 DESCRIPTION 1404 "The contextEngineID indicating the location of the 1405 context in which management information is accessed 1406 when using the community string specified by the 1407 corresponding instance of snmpCommunityName. 1409 The default value is the snmpEngineID of the entity in 1410 which this object is instantiated." 1411 ::= { snmpCommunityEntry 4 } 1413 snmpCommunityContextName OBJECT-TYPE 1414 SYNTAX SnmpAdminString (SIZE(0..32)) 1415 MAX-ACCESS read-create 1416 STATUS current 1417 DESCRIPTION 1418 "The context in which management information is accessed 1419 when using the community string specified by the corresponding 1420 instance of snmpCommunityName." 1421 DEFVAL { ''H } -- the empty string 1422 ::= { snmpCommunityEntry 5 } 1424 snmpCommunityTransportTag OBJECT-TYPE 1425 SYNTAX SnmpTagValue 1426 MAX-ACCESS read-create 1427 STATUS current 1428 DESCRIPTION 1429 "This object specifies a set of transport endpoints 1430 from which a command responder application will accept 1431 management requests. If a management request containing 1432 this community is received on a transport endpoint other 1433 than the transport endpoints identified by this object, 1434 the request is deemed unauthentic. 1436 The transports identified by this object are specified 1437 in the snmpTargetAddrTable. Entries in that table 1438 whose snmpTargetAddrTagList contains this tag value 1439 are identified. 1441 If the value of this object has zero-length, transport 1442 endpoints are not checked when authenticating messages 1443 containing this community string." 1444 DEFVAL { ''H } -- the empty string 1445 ::= { snmpCommunityEntry 6 } 1447 snmpCommunityStorageType OBJECT-TYPE 1448 SYNTAX StorageType 1449 MAX-ACCESS read-create 1450 STATUS current 1451 DESCRIPTION 1452 "The storage type for this conceptual row in the 1453 snmpCommunityTable. Conceptual rows having the value 1454 'permanent' need not allow write-access to any 1455 columnar object in the row." 1456 ::= { snmpCommunityEntry 7 } 1458 snmpCommunityStatus OBJECT-TYPE 1459 SYNTAX RowStatus 1460 MAX-ACCESS read-create 1461 STATUS current 1462 DESCRIPTION 1463 "The status of this conceptual row in the snmpCommunityTable. 1465 An entry in this table is not qualified for activation 1466 until instances of all corresponding columns have been 1467 initialized, either through default values, or through 1468 Set operations. The snmpCommunityName and 1469 snmpCommunitySecurityName objects must be explicitly set. 1471 There is no restriction on setting columns in this table 1472 when the value of snmpCommunityStatus is active(1)." 1473 ::= { snmpCommunityEntry 8 } 1475 -- 1476 -- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with 1477 -- a transport address mask value and a maximum message size value. 1478 -- The transport address mask allows entries in the 1479 -- snmpTargetAddrTable to define a set of addresses instead of just 1480 -- a single address. The maximum message size value allows the 1481 -- maximum message size of another SNMP entity to be configured 1482 -- for use in SNMPv1 (and SNMPv2c) transactions, where the message 1483 -- format does not specify a maximum message size. 1485 -- 1487 snmpTargetAddrExtTable OBJECT-TYPE 1488 SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry 1489 MAX-ACCESS not-accessible 1490 STATUS current 1491 DESCRIPTION 1492 "The table of mask and mms values associated with the 1493 snmpTargetAddrTable." 1494 ::= { snmpCommunityMIBObjects 2 } 1496 snmpTargetAddrExtEntry OBJECT-TYPE 1497 SYNTAX SnmpTargetAddrExtEntry 1498 MAX-ACCESS not-accessible 1499 STATUS current 1500 DESCRIPTION 1501 "Information about a particular mask and mms value." 1502 AUGMENTS { snmpTargetAddrEntry } 1503 ::= { snmpTargetAddrExtTable 1 } 1505 SnmpTargetAddrExtEntry ::= SEQUENCE { 1506 snmpTargetAddrTMask OCTET STRING, 1507 snmpTargetAddrMMS Integer32 1508 } 1510 snmpTargetAddrTMask OBJECT-TYPE 1511 SYNTAX OCTET STRING (SIZE (0..255)) 1512 MAX-ACCESS read-create 1513 STATUS current 1514 DESCRIPTION 1515 "The mask value associated with an entry in the 1516 snmpTargetAddrTable. The value of this object must 1517 have the same length as the corresponding instance of 1518 snmpTargetAddrTAddress, or must have length 0. An 1519 attempt to set it to any other value will result in 1520 an inconsistentValue error. 1522 The value of this object allows an entry in the 1523 snmpTargetAddrTable to specify multiple addresses. 1524 The mask value is used to select which bits of 1525 a transport address must match bits of the corresponding 1526 instance of snmpTargetAddrTAddress, in order for the 1527 transport address to match a particular entry in the 1528 snmpTargetAddrTable. Bits which are 1 in the mask 1529 value indicate bits in the transport address which 1530 must match bits in the snmpTargetAddrTAddress value. 1531 Bits which are 0 in the mask indicate bits in the 1532 transport address which need not match. If the 1533 length of the mask is 0, the mask should be treated 1534 as if all its bits were 1 and its length were equal 1535 to the length of the corresponding value of 1536 snmpTargetAddrTable." 1537 DEFVAL { ''H } 1538 ::= { snmpTargetAddrExtEntry 1 } 1540 snmpTargetAddrMMS OBJECT-TYPE 1541 SYNTAX Integer32 (0|484..65535) 1542 MAX-ACCESS read-create 1543 STATUS current 1544 DESCRIPTION 1545 "The maximum message size value associated with an entry 1546 in the snmpTargetAddrTable. The default value of 1472 1547 is the maximum size of the data portion of a UDP packet 1548 carried in an ethernet frame (i.e. the maximum size of 1549 an SNMP packet using UDP)." 1550 DEFVAL { 1472 } 1551 ::= { snmpTargetAddrExtEntry 2 } 1553 -- 1554 -- The snmpTrapAddress and snmpTrapCommunity objects are included 1555 -- in notifications that are forwarded by a proxy, which were 1556 -- originally received as SNMPv1 Trap messages. 1557 -- 1559 snmpTrapAddress OBJECT-TYPE 1560 SYNTAX IpAddress 1561 MAX-ACCESS accessible-for-notify 1562 STATUS current 1563 DESCRIPTION 1564 "The value of the agent-addr field of a Trap PDU which 1565 is forwarded by a proxy forwarder application using 1566 an SNMP version other than SNMPv1. The value of this 1567 object SHOULD contain the value of the agent-addr field 1568 from the original Trap PDU as generated by an SNMPv1 1569 agent." 1570 ::= { snmpCommunityMIBObjects 3 } 1572 snmpTrapCommunity OBJECT-TYPE 1573 SYNTAX OCTET STRING 1574 MAX-ACCESS accessible-for-notify 1575 STATUS current 1576 DESCRIPTION 1577 "The value of the community string field of an SNMPv1 1578 message containing a Trap PDU which is forwarded by a 1579 a proxy forwarder application using an SNMP version 1580 other than SNMPv1. The value of this object SHOULD 1581 contain the value of the community string field from 1582 the original SNMPv1 message containing a Trap PDU as 1583 generated by an SNMPv1 agent." 1584 ::= { snmpCommunityMIBObjects 4 } 1586 -- Conformance Information ******************************************* 1588 snmpCommunityMIBCompliances OBJECT IDENTIFIER 1589 ::= { snmpCommunityMIBConformance 1 } 1590 snmpCommunityMIBGroups OBJECT IDENTIFIER 1591 ::= { snmpCommunityMIBConformance 2 } 1593 -- Compliance statements 1595 snmpCommunityMIBCompliance MODULE-COMPLIANCE 1596 STATUS current 1597 DESCRIPTION 1598 "The compliance statement for SNMP engines which 1599 implement the SNMP-COMMUNITY-MIB." 1601 MODULE -- this module 1602 MANDATORY-GROUPS { snmpCommunityGroup } 1604 OBJECT snmpCommunityName 1605 MIN-ACCESS read-only 1606 DESCRIPTION "Write access is not required." 1608 OBJECT snmpCommunitySecurityName 1609 MIN-ACCESS read-only 1610 DESCRIPTION "Write access is not required." 1612 OBJECT snmpCommunityContextEngineID 1613 MIN-ACCESS read-only 1614 DESCRIPTION "Write access is not required." 1616 OBJECT snmpCommunityContextName 1617 MIN-ACCESS read-only 1618 DESCRIPTION "Write access is not required." 1620 OBJECT snmpCommunityTransportTag 1621 MIN-ACCESS read-only 1622 DESCRIPTION "Write access is not required." 1624 OBJECT snmpCommunityStorageType 1625 MIN-ACCESS read-only 1626 DESCRIPTION "Write access is not required." 1628 OBJECT snmpCommunityStatus 1629 MIN-ACCESS read-only 1630 DESCRIPTION "Write access is not required." 1632 ::= { snmpCommunityMIBCompliances 1 } 1634 snmpProxyTrapForwardCompliance MODULE-COMPLIANCE 1635 STATUS current 1636 DESCRIPTION 1637 "The compliance statement for SNMP engines which 1638 contain a proxy forwarding application which is 1639 capable of forwarding SNMPv1 traps using SNMPv2c 1640 or SNMPv3." 1641 MODULE -- this module 1642 MANDATORY-GROUPS { snmpProxyTrapForwardGroup } 1643 ::= { snmpCommunityMIBCompliances 2 } 1645 snmpCommunityGroup OBJECT-GROUP 1646 OBJECTS { 1647 snmpCommunityName, 1648 snmpCommunitySecurityName, 1649 snmpCommunityContextEngineID, 1650 snmpCommunityContextName, 1651 snmpCommunityTransportTag, 1652 snmpCommunityStorageType, 1653 snmpCommunityStatus, 1654 snmpTargetAddrTMask, 1655 snmpTargetAddrMMS 1656 } 1657 STATUS current 1658 DESCRIPTION 1659 "A collection of objects providing for configuration 1660 of community strings for SNMPv1 (and SNMPv2c) usage." 1661 ::= { snmpCommunityMIBGroups 1 } 1663 snmpProxyTrapForwardGroup OBJECT-GROUP 1664 OBJECTS { 1665 snmpTrapAddress, 1666 snmpTrapCommunity 1667 } 1668 STATUS current 1669 DESCRIPTION 1670 "Objects which are used by proxy forwarding applications 1671 when translating traps between SNMP versions. These are 1672 used to preserve SNMPv1-specific information when 1673 translating to SNMPv2c or SNMPv3." 1674 ::= { snmpCommunityMIBGroups 3 } 1676 END 1678 6. Intellectual Property 1680 The IETF takes no position regarding the validity or scope of any 1681 intellectual property or other rights that might be claimed to 1682 pertain to the implementation or use of the technology described in 1683 this document or the extent to which any license under such rights 1684 might or might not be available; neither does it represent that it 1685 has made any effort to identify any such rights. Information on the 1686 IETF's procedures with respect to rights in standards-track and 1687 standards-related documentation can be found in BCP-11. Copies of 1688 claims of rights made available for publication and any assurances of 1689 licenses to be made available, or the result of an attempt made to 1690 obtain a general license or permission for the use of such 1691 proprietary rights by implementors or users of this specification can 1692 be obtained from the IETF Secretariat. 1694 The IETF invites any interested party to bring to its attention any 1695 copyrights, patents or patent applications, or other proprietary 1696 rights which may cover technology that may be required to practice 1697 this standard. Please address the information to the IETF Executive 1698 Director. 1700 7. Acknowledgments 1702 This document is the result of the efforts of the SNMPv3 Working 1703 Group. The design of the SNMP-COMMUNITY-MIB incorporates work done 1704 by the authors of SNMPv2*: 1706 Jeff Case (SNMP Research, Inc.) 1707 David Harrington (Cabletron Systems Inc.) 1708 David Levi (SNMP Research, Inc.) 1709 Brian O'Keefe (Hewlett Packard) 1710 Jon Saperia (IronBridge Networks, Inc.) 1711 Steve Waldbusser (International Network Services) 1713 8. Security Considerations 1715 Although SNMPv1 and SNMPv2 do not provide any security, allowing 1716 community names to be mapped into securityName/contextName provides 1717 the ability to use view-based access control to limit the access of 1718 unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for 1719 network administrators to make use of this capability in order to 1720 avoid unauthorized access to MIB data that would otherwise be secure. 1722 Further, the SNMP-COMMUNITY-MIB has the potential to expose community 1723 strings which provide access to more information than that which is 1724 available using the usual 'public' community string. For this 1725 reason, a security administrator may wish to limit accessibility to 1726 the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible 1727 when using the 'public' community string. 1729 When a proxy implementation translates messages between SNMPv1 (or 1730 SNMPv2c) and SNMPv3, there may be a loss of security. For example, 1731 an SNMPv3 message received using authentication and privacy which is 1732 subsequently forwarded using SNMPv1 will lose the security benefits 1733 of using authentication and privacy. Careful configuration of 1734 proxies is required to address such situations. One approach to deal 1735 with such situations might be to use an encrypted tunnel. 1737 9. References 1739 [1] Rose, M. and K. McCloghrie, "Structure and Identification of 1740 Management Information for TCP/IP-based internets"", STD16, RFC 1741 1155, May 1990. 1743 [2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1744 Management Protocol", STD15, RFC 1157, SNMP Research, Performance 1745 Systems International, Performance Systems International, MIT 1746 Laboratory for Computer Science, May 1990. 1748 [3] McCloghrie, K., and M. Rose, Editors, "Concise MIB Definitions", 1749 STD 16, RFC 1212, Hughes LAN Systems, Performance Systems 1750 International, March 1991. 1752 [4] Rose, M. T., "A Convention for Defining Traps for use with the 1753 SNMP", RFC 1215, March 1991. 1755 [5] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP- 1756 based Agents", RFC 1303, Hughes LAN Systems, Dover Beach 1757 Consulting, Inc., February 1992. 1759 [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1760 Waldbusser, "Introduction to Community-based SNMPv2", RFC1901, SNMP 1761 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1762 International Network Services, January 1996. 1764 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1765 and S. Waldbusser, "Structure of Management Information Version 2 1766 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 1767 Braunschweig, SNMP Research, First Virtual Holdings, International 1768 Network Services, April 1999. 1770 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1771 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 1772 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 1773 Virtual Holdings, International Network Services, April 1999. 1775 [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1776 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 1777 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 1778 First Virtual Holdings, International Network Services, April 1999. 1780 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1781 Waldbusser, "Protocol Operations for Version 2 of the Simple 1782 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 1783 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 1784 Network Services, January 1996. 1786 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport 1787 Mappings for Version 2 of the Simple Network Management Protocol 1788 (SNMPv2)", RFC 1906, January 1996. 1790 [12] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1791 Waldbusser, "Management Information Base for Version 2 of the 1792 Simple Network Management Protocol (SNMPv2)", RFC1907, SNMP 1793 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1794 International Network Services, January 1996. 1796 [13] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 1797 Waldbusser, "Coexistence between Version 1 and Version 2 of the 1798 Internet-standard Network Management Framework", RFC1908, SNMP 1799 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1800 International Network Services, January 1996. 1802 [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- 1803 lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January 1804 1997. 1806 [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1807 Levels", BCP 14, RFC 2119, March 1997. 1809 [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An 1810 Architecture for Describing SNMP Management Frameworks", RFC 2571, 1811 May 1999. 1813 [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., 1814 "Message Processing and Dispatching for the Simple Network 1815 Management Protocol (SNMP)", RFC 2572, May 1999. 1817 [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP 1818 Applications", RFC2573, May 1999. 1820 [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- 1821 Based Security Model for Version 3 of the Simple Network Management 1822 Protocol (SNMP)", RFC 2574, May 1999. 1824 [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., 1825 "View-based Access Control Model for the Simple Network Management 1826 Protocol (SNMP)", RFC 2575, May 1999. 1828 10. Editor's Address 1830 Rob Frye 1831 MCI WorldCom 1832 2100 Reston Parkway, Suite 600 1833 Reston, VA 20191 1834 U.S.A. 1835 Phone: +1 703 715 7225 1836 EMail: Rob.Frye@wcom.com 1838 David B. Levi 1839 Nortel Networks 1840 3505 Kesterwood Drive 1841 Knoxville, TN 37918 1842 U.S.A. 1843 Phone: +1 423 686 0432 1844 EMail: dlevi@nortelnetworks.com 1846 Shawn A. Routhier 1847 Integrated Systems Inc. 1848 333 North Ave 4th Floor 1849 Wakefield MA 01880 1850 U.S.A. 1851 Phone: + 1 781 245 0804 1852 EMail: sar@epilogue.com 1854 Bert Wijnen 1855 IBM T. J. Watson Research 1856 Schagen 33 1857 3461 GL Linschoten 1858 Netherlands 1859 Phone: +31 348 432 794 1860 EMail: wijnen@vnet.ibm.com 1862 A. Full Copyright Statement 1864 This document and translations of it may be copied and furnished to 1865 others, and derivative works that comment on or otherwise explain it 1866 or assist in its implementation may be prepared, copied, published 1867 and distributed, in whole or in part, without restriction of any 1868 kind, provided that the above copyright notice and this paragraph are 1869 included on all such copies and derivative works. However, this 1870 document itself may not be modified in any way, such as by removing 1871 the copyright notice or references to the Internet Society or other 1872 Internet organizations, except as needed for the purpose of 1873 developing Internet standards in which case the procedures for 1874 copyrights defined in the Internet Standards process must be 1875 followed, or as required to translate it into languages other than 1876 English. 1878 The limited permissions granted above are perpetual and will not be 1879 revoked by the Internet Society or its successors or assigns. 1881 This document and the information contained herein is provided on an 1882 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1883 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1884 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1885 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1886 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1888 Table of Contents 1890 1 Overview ..................................................... 4 1891 1.1 SNMPv1 ..................................................... 4 1892 1.2 SNMPv2 ..................................................... 5 1893 1.3 SNMPv3 ..................................................... 6 1894 1.4 SNMPv1 and SNMPv2 MIB Instrumentation ...................... 6 1895 2 SMI and Management Information Mappings ...................... 8 1896 2.1 MIB Modules ................................................ 8 1897 2.1.1 Object Definitions ....................................... 8 1898 2.1.2 Trap and Notification Definitions ........................ 10 1899 2.2 Compliance Statements ...................................... 11 1900 2.3 Capabilities Statements .................................... 11 1901 3 Translating Notifications Parameters ......................... 13 1902 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 1903 Notification Parameters ................................... 14 1904 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 1905 Notification Parameters ................................... 15 1906 4 Approaches to Coexistence in a Multi-lingual Network ......... 18 1907 4.1 Multi-lingual implementations .............................. 18 1908 4.1.1 Command Generator ........................................ 18 1909 4.1.2 Command Responder ........................................ 19 1910 4.1.2.1 Handling Counter64 ..................................... 19 1911 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 1912 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21 1913 4.1.2.2.2 Mapping endOfMibView ................................. 21 1914 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 1915 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 1916 4.1.3 Notification Originator .................................. 23 1917 4.1.4 Notification Receiver .................................... 24 1918 4.2 Proxy Implementations ...................................... 25 1919 4.2.1 Deployment Hint .......................................... 27 1920 4.3 Error Status Mappings ...................................... 27 1921 5 Message Processing Models and Security Models ................ 29 1922 5.1 Mappings ................................................... 29 1923 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 1924 Model ..................................................... 29 1925 5.2.1 Processing An Incoming Request ........................... 30 1926 5.2.2 Generating An Outgoing Response .......................... 32 1927 5.2.3 Generating An Outgoing Notification ...................... 32 1928 5.3 The SNMP Community MIB Module .............................. 33 1929 6 Intellectual Property ........................................ 44 1930 7 Acknowledgments .............................................. 45 1931 8 Security Considerations ...................................... 46 1932 9 References ................................................... 47 1933 10 Editor's Address ............................................ 49 1934 A. Full Copyright Statement .................................... 50