idnits 2.17.1 draft-ietf-snmpv3-update-transmap-07.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 41 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 210 has weird spacing: '... octets cont...' == Line 239 has weird spacing: '... octets cont...' == Line 289 has weird spacing: '... octets cont...' == Line 291 has weird spacing: '...address net...' == Line 666 has weird spacing: '... The previo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (3 October 2001) is 8235 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) == Missing Reference: 'ASN1' is mentioned on line 319, but not defined -- Looks like a reference, but probably isn't: '5' on line 597 == Unused Reference: 'RFC-TMM' is defined on line 803, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'APPLETALK' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072A' -- Possible downref: Non-RFC (?) normative reference: ref. 'NOVELL' ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1742 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PRO' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ARC' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APL' ** Obsolete normative reference: RFC 2574 (ref. 'RFC-USM') (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor of this version: 2 Request for Comments: -TMM R. Presuhn 3 STD: XXX BMC Software, Inc. 4 Obsoletes: 1906 Authors of previous version: 5 Category: Standards Track J. Case 6 SNMP Research, Inc. 7 K. McCloghrie 8 Cisco Systems, Inc. 9 M. Rose 10 Dover Beach Consulting, Inc. 11 S. Waldbusser 12 International Network Services 13 3 October 2001 15 Transport Mappings for 16 the Simple Network Management Protocol 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 This document defines the transport of SNMP messages over various 45 protocols. This document obsoletes RFC 1906. 47 Table of Contents 49 1. Introduction ................................................ 3 50 2. Definitions ................................................. 4 51 3. SNMP over UDP over IPv4 ..................................... 8 52 3.1. Serialization ............................................. 8 53 3.2. Well-known Values ......................................... 8 54 4. SNMP over OSI ............................................... 8 55 4.1. Serialization ............................................. 8 56 4.2. Well-known Values ......................................... 9 57 5. SNMP over DDP ............................................... 9 58 5.1. Serialization ............................................. 9 59 5.2. Well-known Values ......................................... 9 60 5.3. Discussion of AppleTalk Addressing ........................ 10 61 5.3.1. How to Acquire NBP names ................................ 10 62 5.3.2. When to Turn NBP names into DDP addresses ............... 11 63 5.3.3. How to Turn NBP names into DDP addresses ................ 11 64 5.3.4. What if NBP is broken ................................... 11 65 6. SNMP over IPX ............................................... 12 66 6.1. Serialization ............................................. 12 67 6.2. Well-known Values ......................................... 12 68 7. Proxy to SNMPv1 ............................................. 13 69 8. Serialization using the Basic Encoding Rules ................ 13 70 8.1. Usage Example ............................................. 13 71 9. Notice on Intellectual Property ............................. 14 72 10. Acknowledgments ............................................ 15 73 11. IANA Considerations ........................................ 16 74 12. Security Considerations .................................... 16 75 13. References ................................................. 17 76 14. Editor's Address ........................................... 19 77 15. Changes from RFC 1906 ...................................... 19 78 16. Issues ..................................................... 20 79 17. Full Copyright Statement ................................... 21 81 1. Introduction 83 The SNMP Management Framework at the time of this writing consists of 84 five major components: 86 - An overall architecture, described in RFC -ARC [RFC-ARC]. 88 - Mechanisms for describing and naming objects and events for 89 the purpose of management. The first version of this 90 Structure of Management Information (SMI) is called SMIv1 91 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 92 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 93 called SMIv2, is described in STD 58, RFC 2578 [RFC2578], 94 STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 96 - Message protocols for transferring management information. 97 The first version of the SNMP message protocol is called 98 SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A 99 second version of the SNMP message protocol, which is not 100 an Internet standards track protocol, is called SNMPv2c and 101 is described in RFC 1901 [RFC1901] and this document. The 102 third version of the message protocol is called SNMPv3 and 103 described in this document, RFC -MPD [RFC-MPD] and RFC -USM 104 [RFC-USM]. 106 - Protocol operations for accessing management information. 107 The first set of protocol operations and associated PDU 108 formats is described in STD 15, RFC 1157 [RFC1157]. A 109 second set of protocol operations and associated PDU 110 formats is described RFC -PRO [RFC-PRO]. 112 - A set of fundamental applications described in RFC -APL 113 [RFC-APL] and the view-based access control mechanism 114 described in RFC -ACM [RFC-ACM]. 116 A more detailed introduction to the SNMP Management Framework at the 117 time of this writing can be found in RFC 2570 [RFC2570]. 119 Managed objects are accessed via a virtual information store, termed 120 the Management Information Base or MIB. Objects in the MIB are 121 defined using the mechanisms defined in the SMI. 123 This document, Transport Mappings for the Simple Network Management 124 Protocol, defines how the management protocol [RFC-PRO] may be 125 carried over a variety of protocol suites. It is the purpose of this 126 document to define how the SNMP maps onto an initial set of transport 127 domains. Other mappings may be defined in the future. 129 Although several mappings are defined, the mapping onto UDP over IPv4 ! 130 is the preferred mapping for systems supporting IPv4. Systems ! 131 implementing IPv4 MUST implement the mapping onto UDP over IPv4. To ! 132 maximize interoperability, systems supporting other mappings SHOULD ! 133 also provide for access via the UDP over IPv4 mapping. ! 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", ! 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this ! 137 document are to be interpreted as described in RFC 2119 [RFC2119]. ! 139 2. Definitions 141 SNMPv2-TM DEFINITIONS ::= BEGIN 143 IMPORTS ! 144 MODULE-IDENTITY, OBJECT-IDENTITY, ! 145 snmpModules, snmpDomains, snmpProxys 146 FROM SNMPv2-SMI 147 TEXTUAL-CONVENTION 148 FROM SNMPv2-TC; 150 snmpv2tm MODULE-IDENTITY ! 151 LAST-UPDATED "200110040534Z" ! 152 ORGANIZATION "IETF SNMPv3 Working Group" ! 153 CONTACT-INFO ! 154 "WG-EMail: snmpv3@lists.tislabs.com 155 Subscribe: snmpv3-request@lists.tislabs.com 157 Co-Chair: Russ Mundy 158 NAI Labs, 159 Network Associates, Inc. 160 postal: 3060 Washington Rd. 161 Glenwood, MD 21738 162 USA 163 EMail: mundy@tislabs.com 164 phone: +1 301 854-6889 166 Co-Chair: David Harrington 167 Enterasys Networks 168 postal: 35 Industrial Way 169 P. O. Box 5005 170 Rochester, NH 03866-5005 171 USA 172 EMail: dbh@enterasys.com 173 phone: +1 603 337-2614 174 Editor: Randy Presuhn 175 BMC Software, Inc. 176 postal: 2141 North First Street 177 San Jose, CA 95131 178 USA 179 EMail: randy_presuhn@bmc.com 180 phone: +1 408 546-1006" 181 DESCRIPTION 182 "The MIB module for SNMP transport mappings." 183 REVISION "200110040534Z" 184 DESCRIPTION 185 "Clarifications, published as RFC -TMM." 186 REVISION "199601010000Z" 187 DESCRIPTION 188 "Clarifications, published as RFC 1906." 189 REVISION "199304010000Z" 190 DESCRIPTION 191 "The initial version, published as RFC 1449." 192 ::= { snmpModules ?? } -- to be assigned by IANA?? 194 -- SNMP over UDP over IPv4 196 snmpUDPDomain OBJECT-IDENTITY 197 STATUS current 198 DESCRIPTION 199 "The SNMP over UDP over IPv4 transport domain. ! 200 The corresponding transport address is of type 201 SnmpUDPAddress." 202 ::= { snmpDomains 1 } 204 SnmpUDPAddress ::= TEXTUAL-CONVENTION 205 DISPLAY-HINT "1d.1d.1d.1d/2d" 206 STATUS current 207 DESCRIPTION 208 "Represents a UDP over IPv4 address: ! 210 octets contents encoding 211 1-4 IP-address network-byte order 212 5-6 UDP-port network-byte order 213 " 214 SYNTAX OCTET STRING (SIZE (6)) 216 -- SNMP over OSI 217 snmpCLNSDomain OBJECT-IDENTITY 218 STATUS current 219 DESCRIPTION 220 "The SNMP over CLNS transport domain. 221 The corresponding transport address is of type 222 SnmpOSIAddress." 223 ::= { snmpDomains 2 } 225 snmpCONSDomain OBJECT-IDENTITY 226 STATUS current 227 DESCRIPTION 228 "The SNMP over CONS transport domain. 229 The corresponding transport address is of type 230 SnmpOSIAddress." 231 ::= { snmpDomains 3 } 233 SnmpOSIAddress ::= TEXTUAL-CONVENTION 234 DISPLAY-HINT "*1x:/1x:" 235 STATUS current 236 DESCRIPTION 237 "Represents an OSI transport-address: 239 octets contents encoding 240 1 length of NSAP 'n' as an unsigned-integer 241 (either 0 or from 3 to 20) 242 2..(n+1) NSAP concrete binary representation 243 (n+2)..m TSEL string of (up to 64) octets 244 " 245 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 247 -- SNMP over DDP 249 snmpDDPDomain OBJECT-IDENTITY 250 STATUS current 251 DESCRIPTION 252 "The SNMP over DDP transport domain. The corresponding 253 transport address is of type SnmpNBPAddress." 254 ::= { snmpDomains 4 } 256 SnmpNBPAddress ::= TEXTUAL-CONVENTION 257 STATUS current 258 DESCRIPTION 259 "Represents an NBP name: 261 octets contents encoding 262 1 length of object 'n' as an unsigned integer 263 2..(n+1) object string of (up to 32) octets 264 n+2 length of type 'p' as an unsigned integer 265 (n+3)..(n+2+p) type string of (up to 32) octets 266 n+3+p length of zone 'q' as an unsigned integer 267 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 269 For comparison purposes, strings are 270 case-insensitive. All strings may contain any octet 271 other than 255 (hex ff)." 272 SYNTAX OCTET STRING (SIZE (3..99)) 274 -- SNMP over IPX 276 snmpIPXDomain OBJECT-IDENTITY 277 STATUS current 278 DESCRIPTION 279 "The SNMP over IPX transport domain. The corresponding 280 transport address is of type SnmpIPXAddress." 281 ::= { snmpDomains 5 } 283 SnmpIPXAddress ::= TEXTUAL-CONVENTION 284 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 285 STATUS current 286 DESCRIPTION 287 "Represents an IPX address: 289 octets contents encoding 290 1-4 network-number network-byte order 291 5-10 physical-address network-byte order 292 11-12 socket-number network-byte order 293 " 294 SYNTAX OCTET STRING (SIZE (12)) 296 -- for proxy to SNMPv1 (RFC 1157) 298 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 300 rfc1157Domain OBJECT-IDENTITY 301 STATUS deprecated ! 302 DESCRIPTION 303 "The transport domain for SNMPv1 over UDP over IPv4. ! 304 The corresponding transport address is of type 305 SnmpUDPAddress." 306 ::= { rfc1157Proxy 1 } 308 -- ::= { rfc1157Proxy 2 } this OID is obsolete 310 END 312 3. SNMP over UDP over IPv4 314 This is the preferred transport mapping. 316 3.1. Serialization 318 Each instance of a message is serialized (i.e., encoded according to 319 the convention of [ASN1]) onto a single UDP [RFC768] over IPv4 320 [RFC791] datagram, using the algorithm specified in Section 8. 322 3.2. Well-known Values 324 It is suggested that administrators configure their SNMP entities 325 supporting command responder applications to listen on UDP port 161. 326 Further, it is suggested that SNMP entities supporting notification 327 receiver applications be configured to listen on UDP port 162. 329 When an SNMP entity uses this transport mapping, it must be capable 330 of accepting messages up to and including 484 octets in size. It is ! 331 recommended that implementations be capable of accepting messages of ! 332 up to 1472 octets in size. Implementation of larger values is ! 333 encouraged whenever possible. 335 4. SNMP over OSI 337 This is an optional transport mapping. 339 4.1. Serialization 341 Each instance of a message is serialized onto a single TSDU [IS8072] 342 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 343 using the algorithm specified in Section 8. 345 4.2. Well-known Values 347 It is suggested that administrators configure their SNMP entities 348 supporting command responder applications to listen on transport 349 selector "snmp-l" (which consists of six ASCII characters), when 350 using a CL-mode network service to realize the CLTS. Further, it is 351 suggested that SNMP entities supporting notification receiver 352 applications be configured to listen on transport selector "snmpt-l" 353 (which consists of seven ASCII characters, six letters and a hyphen) 354 when using a CL-mode network service to realize the CLTS. Similarly, 355 when using a CO-mode network service to realize the CLTS, the 356 suggested transport selectors are "snmp-o" and "snmpt-o", for command 357 responders and notification receivers, respectively. 359 When an SNMP entity uses this transport mapping, it must be capable 360 of accepting messages that are at least 484 octets in size. 361 Implementation of larger values is encouraged whenever possible. 363 5. SNMP over DDP 365 This is an optional transport mapping. 367 5.1. Serialization 369 Each instance of a message is serialized onto a single DDP datagram 370 [APPLETALK], using the algorithm specified in Section 8. 372 5.2. Well-known Values 374 SNMP messages are sent using DDP protocol type 8. SNMP entities 375 supporting command responder applications listen on DDP socket number 376 8, while SNMP entities supporting notification receiver applications 377 listen on DDP socket number 9. 379 Administrators must configure their SNMP entities supporting command 380 responder applications to use NBP type "SNMP Agent" (which consists 381 of ten ASCII characters) while those supporting notification receiver 382 applications must be configured to use NBP type "SNMP Trap Handler" 383 (which consists of seventeen ASCII characters). 385 The NBP name for SNMP entities supporting command responders and 386 notification receivers should be stable - NBP names should not change 387 any more often than the IP address of a typical TCP/IP node. It is 388 suggested that the NBP name be stored in some form of stable storage. 390 When an SNMP entity uses this transport mapping, it must be capable 391 of accepting messages that are at least 484 octets in size. 392 Implementation of larger values is encouraged whenever possible. 394 5.3. Discussion of AppleTalk Addressing 396 The AppleTalk protocol suite has certain features not manifest in the 397 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 398 address assignment can cause problems for SNMP entities that wish to 399 manage AppleTalk networks. TCP/IP nodes have an associated IP 400 address which distinguishes each from the other. In contrast, 401 AppleTalk nodes generally have no such characteristic. The network- 402 level address, while often relatively stable, can change at every 403 reboot (or more frequently). 405 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 406 rather than by an "address". Hence, all AppleTalk nodes that 407 implement this mapping are required to respond to NBP lookups and 408 confirms (e.g., implement the NBP protocol stub), which guarantees 409 that a mapping from NBP name to DDP address will be possible. 411 In determining the SNMP identity to register for an SNMP entity, it 412 is suggested that the SNMP identity be a name which is associated 413 with other network services offered by the machine. 415 NBP lookups, which are used to map NBP names into DDP addresses, can 416 cause large amounts of network traffic as well as consume CPU 417 resources. It is also the case that the ability to perform an NBP 418 lookup is sensitive to certain network disruptions (such as zone 419 table inconsistencies) which would not prevent direct AppleTalk 420 communications between two SNMP entities. 422 Thus, it is recommended that NBP lookups be used infrequently, 423 primarily to create a cache of name-to-address mappings. These 424 cached mappings should then be used for any further SNMP traffic. It 425 is recommended that SNMP entities supporting command generator 426 applications should maintain this cache between reboots. This 427 caching can help minimize network traffic, reduce CPU load on the 428 network, and allow for (some amount of) network trouble shooting when 429 the basic name-to-address translation mechanism is broken. 431 5.3.1. How to Acquire NBP names 433 An SNMP entity supporting command generator applications may have a 434 pre-configured list of names of "known" SNMP entities supporting 435 command responder applications. Similarly, an SNMP entity supporting 436 command generator or notification receiver applications might 437 interact with an operator. Finally, an SNMP entity supporting 438 command generator or notification receiver applications might 439 communicate with all SNMP entities supporting command responder or 440 notification originator applications in a set of zones or networks. 442 5.3.2. When to Turn NBP names into DDP addresses 444 When an SNMP entity uses a cache entry to address an SNMP packet, it 445 should attempt to confirm the validity mapping, if the mapping hasn't 446 been confirmed within the last T1 seconds. This cache entry 447 lifetime, T1, has a minimum, default value of 60 seconds, and should 448 be configurable. 450 An SNMP entity supporting a command generator application may decide 451 to prime its cache of names prior to actually communicating with 452 another SNMP entity. In general, it is expected that such an entity 453 may want to keep certain mappings "more current" than other mappings, 454 e.g., those nodes which represent the network infrastructure (e.g., 455 routers) may be deemed "more important". 457 Note that an SNMP entity supporting command generator applications 458 should not prime its entire cache upon initialization - rather, it 459 should attempt resolutions over an extended period of time (perhaps 460 in some pre- determined or configured priority order). Each of these 461 resolutions might, in fact, be a wildcard lookup in a given zone. 463 An SNMP entity supporting command responder applications must never 464 prime its cache. When generating a response, such an entity does not 465 need to confirm a cache entry. An SNMP entity supporting 466 notification originator applications should do NBP lookups (or 467 confirms) only when it needs to send an SNMP trap or inform. 469 5.3.3. How to Turn NBP names into DDP addresses 471 If the only piece of information available is the NBP name, then an 472 NBP lookup should be performed to turn that name into a DDP address. 473 However, if there is a piece of stale information, it can be used as 474 a hint to perform an NBP confirm (which sends a unicast to the 475 network address which is presumed to be the target of the name 476 lookup) to see if the stale information is, in fact, still valid. 478 An NBP name to DDP address mapping can also be confirmed implicitly 479 using only SNMP transactions. For example, an SNMP entity supporting 480 command generator applications issuing a retrieval operation could 481 also retrieve the relevant objects from the NBP group [RFC1742] for 482 the SNMP entity supporting the command responder application. This 483 information can then be correlated with the source DDP address of the 484 response. 486 5.3.4. What if NBP is broken 488 Under some circumstances, there may be connectivity between two SNMP 489 entities, but the NBP mapping machinery may be broken, e.g., 490 o the NBP FwdReq (forward NBP lookup onto local attached network) 491 mechanism might be broken at a router on the other entity's 492 network; or, 494 o the NBP BrRq (NBP broadcast request) mechanism might be broken 495 at a router on the entity's own network; or, 497 o NBP might be broken on the other entity's node. 499 An SNMP entity supporting command generator applications which is 500 dedicated to AppleTalk management might choose to alleviate some of 501 these failures by directly implementing the router portion of NBP. 502 For example, such an entity might already know all the zones on the 503 AppleTalk internet and the networks on which each zone appears. 504 Given an NBP lookup which fails, the entity could send an NBP FwdReq 505 to the network in which the SNMP entity supporting the command 506 responder or notification originator application was last located. 507 If that failed, the station could then send an NBP LkUp (NBP lookup 508 packet) as a directed (DDP) multicast to each network number on that 509 network. Of the above (single) failures, this combined approach will 510 solve the case where either the local router's BrRq-to-FwdReq 511 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 512 is broken. 514 6. SNMP over IPX 516 This is an optional transport mapping. 518 6.1. Serialization 520 Each instance of a message is serialized onto a single IPX datagram 521 [NOVELL], using the algorithm specified in Section 8. 523 6.2. Well-known Values 525 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 526 Protocol). 528 It is suggested that administrators configure their SNMP entities 529 supporting command responder applications to listen on IPX socket 530 36879 (900f hexadecimal). Further, it is suggested that those 531 supporting notification receiver applications be configured to listen 532 on IPX socket 36880 (9010 hexadecimal). 534 When an SNMP entity uses this transport mapping, it must be capable 535 of accepting messages that are at least 546 octets in size. 536 Implementation of larger values is encouraged whenever possible. 538 7. Proxy to SNMPv1 540 Historically, in order to support proxy to SNMPv1, as defined in 541 [RFC-COEX], it was deemed useful to define a transport domain, 542 rfc1157Domain, which indicates the transport mapping for SNMP 543 messages as defined in [RFC1157]. 545 8. Serialization using the Basic Encoding Rules 547 When the Basic Encoding Rules [BER] are used for serialization: 549 (1) When encoding the length field, only the definite form is used; 550 use of the indefinite form encoding is prohibited. Note that 551 when using the definite-long form, it is permissible to use more 552 than the minimum number of length octets necessary to encode the 553 length field. 555 (2) When encoding the value field, the primitive form shall be used 556 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 557 IDENTIFIER (either IMPLICIT or explicit). The constructed form 558 of encoding shall be used only for structured types, i.e., a 559 SEQUENCE or an IMPLICIT SEQUENCE. 561 (3) When encoding an object whose syntax is described using the BITS 562 construct, the value is encoded as an OCTET STRING, in which all 563 the named bits in (the definition of) the bitstring, commencing 564 with the first bit and proceeding to the last bit, are placed in 565 bits 8 (high order bit) to 1 (low order bit) of the first octet, 566 followed by bits 8 to 1 of each subsequent octet in turn, 567 followed by as many bits as are needed of the final subsequent 568 octet, commencing with bit 8. Remaining bits, if any, of the 569 final octet are set to zero on generation and ignored on 570 receipt. 572 These restrictions apply to all aspects of ASN.1 encoding, including 573 the message wrappers, protocol data units, and the data objects they 574 contain. 576 8.1. Usage Example 578 As an example of applying the Basic Encoding Rules, suppose one 579 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PRO]: 581 [5] IMPLICIT SEQUENCE { 582 request-id 1414684022, 583 non-repeaters 1, 584 max-repetitions 2, 585 variable-bindings { 586 { name sysUpTime, ! 587 value { unSpecified NULL } }, 588 { name ipNetToMediaPhysAddress, ! 589 value { unSpecified NULL } }, 590 { name ipNetToMediaType, ! 591 value { unSpecified NULL } } 592 } 593 } 595 Applying the BER, this may be encoded (in hexadecimal) as: 597 [5] IMPLICIT SEQUENCE a5 82 00 39 598 INTEGER 02 04 54 52 5d 76 599 INTEGER 02 01 01 600 INTEGER 02 01 02 601 SEQUENCE (OF) 30 2b 602 SEQUENCE 30 0b 603 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 604 NULL 05 00 605 SEQUENCE 30 0d 606 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 607 NULL 05 00 608 SEQUENCE 30 0d 609 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 610 NULL 05 00 612 Note that the initial SEQUENCE in this example was not encoded using 613 the minimum number of length octets. (The first octet of the length, 614 82, indicates that the length of the content is encoded in the next 615 two octets.) 617 9. Notice on Intellectual Property 619 The IETF takes no position regarding the validity or scope of any 620 intellectual property or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; neither does it represent that it 624 has made any effort to identify any such rights. Information on the 625 IETF's procedures with respect to rights in standards-track and 626 standards-related documentation can be found in BCP-11. Copies of 627 claims of rights made available for publication and any assurances of 628 licenses to be made available, or the result of an attempt made to 629 obtain a general license or permission for the use of such 630 proprietary rights by implementors or users of this specification can 631 be obtained from the IETF Secretariat. 633 The IETF invites any interested party to bring to its attention any 634 copyrights, patents or patent applications, or other proprietary 635 rights which may cover technology that may be required to practice 636 this standard. Please address the information to the IETF Executive 637 Director. 639 10. Acknowledgments 641 This document is the product of the SNMPv3 Working Group. Some 642 special thanks are in order to the following Working Group members: 644 Randy Bush 645 Jeffrey D. Case 646 Mike Daniele 647 Rob Frye 648 Lauren Heintz 649 Keith McCloghrie 650 Russ Mundy 651 David T. Perkins 652 Randy Presuhn 653 Aleksey Romanov 654 Juergen Schoenwaelder 655 Bert Wijnen 657 This version of the document, edited by Randy Presuhn, was initially 658 based on the work of a design team whose members were: 660 Jeffrey D. Case 661 Keith McCloghrie 662 David T. Perkins 663 Randy Presuhn 664 Juergen Schoenwaelder 666 The previous versions of this document, edited by Keith McCloghrie, 667 was the result of significant work by four major contributors: 669 Jeffrey D. Case 670 Keith McCloghrie 671 Marshall T. Rose 672 Steven Waldbusser 674 Additionally, the contributions of the SNMPv2 Working Group to the 675 previous versions are also acknowledged. In particular, a special 676 thanks is extended for the contributions of: 678 Alexander I. Alten 679 Dave Arneson 680 Uri Blumenthal 681 Doug Book 682 Kim Curran 683 Jim Galvin 684 Maria Greene 685 Iain Hanson 686 Dave Harrington 687 Nguyen Hien 688 Jeff Johnson 689 Michael Kornegay 690 Deirdre Kostick 691 David Levi 692 Daniel Mahoney 693 Bob Natale 694 Brian O'Keefe 695 Andrew Pearson 696 Dave Perkins 697 Randy Presuhn 698 Aleksey Romanov 699 Shawn Routhier 700 Jon Saperia 701 Juergen Schoenwaelder 702 Bob Stewart 703 Kaj Tesink 704 Glenn Waters 705 Bert Wijnen 707 11. IANA Considerations 709 The SNMPv2-TM MIB module requires the allocation of a single object ! 710 identifier for its MODULE-IDENTITY. IANA should allocate this object ! 711 identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB ! 712 module. ! 714 12. Security Considerations 716 SNMPv1 by itself is not a secure environment. Even if the network ! 717 itself is secure (for example by using IPSec), even then, there is no ! 718 control as to who on the secure network is allowed to access and ! 719 GET/SET (read/change) the objects accessible through a command ! 720 responder application. ! 722 It is recommended that the implementors consider the security ! 723 features as provided by the SNMPv3 framework. Specifically, the use ! 724 of the User-based Security Model RFC -USM [RFC-USM] and the ! 725 View-based Access Control Model RFC -ACM [RFC-ACM] is recommended. ! 726 It is then a customer/user responsibility to ensure that the SNMP ! 727 entity giving access to a MIB is properly configured to give access ! 728 to the objects only to those principals (users) that have legitimate ! 729 rights to indeed GET or SET (change) them. ! 731 13. References 733 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 734 AppleTalk (second edition). Addison-Wesley, 1990. 736 [BER] Information processing systems - Open Systems 737 Interconnection - Specification of Basic Encoding Rules 738 for Abstract Syntax Notation One (ASN.1), International 739 Organization for Standardization. International Standard 740 8825, December 1987. 742 [IS8072] Information processing systems - Open Systems 743 Interconnection - Transport Service Definition, 744 International Organization for Standardization. 745 International Standard 8072, June 1986. 747 [IS8072A] Information processing systems - Open Systems 748 Interconnection - Transport Service Definition - Addendum 749 1: Connectionless-mode Transmission, International 750 Organization for Standardization. International Standard 751 8072/AD 1, December 1986. 753 [NOVELL] Network System Technical Interface Overview. Novell, 754 Inc, June 1989. 756 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 757 August 1980. 759 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 760 September 1981. 762 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 763 Identification of Management Information for TCP/IP-based 764 Internets", STD 16, RFC 1155, May 1990. 766 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 767 "Simple Network Management Protocol", STD 15, RFC 1157, 768 May 1990. 770 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 771 STD 16, RFC 1212, March 1991. 773 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 774 the SNMP", RFC 1215, March 1991. 776 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 777 Information Base II", RFC 1742, January 1995. 779 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 780 "Introduction to Community-based SNMPv2", RFC 1901, 781 January 1996. 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 787 "Introduction to Version 3 of the Internet-standard 788 Network Management Framework", RFC 2570, April 1999. 790 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 791 Rose, M., and S. Waldbusser, "Structure of Management 792 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 793 1999. 795 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 796 Rose, M., and S. Waldbusser, "Textual Conventions for 797 SMIv2", STD 58, RFC 2579, April 1999. 799 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 800 Rose, M., and S. Waldbusser, "Conformance Statements for 801 SMIv2", STD 58, RFC 2580, April 1999. 803 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 804 Waldbusser, "Transport Mappings for the Simple Network 805 Management Protocol", 806 , October 2001. 808 [RFC-PRO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 809 Waldbusser, "Protocol Operations for the Simple Network 810 Management Protocol", 811 , October 2001. 813 [RFC-ARC] Harrington, D., Presuhn, R. and B. Wijnen, "An 814 Architecture for describing SNMP Management Frameworks", 815 , October 2001. 817 [RFC-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, 818 "Message Processing and Dispatching for the Simple 819 Network Management Protocol (SNMP)", 820 , October 2001. 822 [RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", 823 , October 2001. 825 [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 826 Model for Version 3 of the Simple Network Management 827 Protocol (SNMPv3)", 828 , October 829 2001. 831 [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 832 Access Control Model for the Simple Network Management 833 Protocol (SNMP)", , 834 October 2001. 836 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 837 "Coexistence between Version 1, Version 2, and Version 3 838 of the Internet-standard Network Management Framework", 839 , October 2001. 841 14. Editor's Address 843 Randy Presuhn 844 BMC Software, Inc. 845 2141 North First Street 846 San Jose, CA 95131 847 USA 849 Phone: +1 408 546-1006 850 EMail: randy_presuhn@bmc.com 852 15. Changes from RFC 1906 854 These are the changes from RFC 1906: 856 - Corrected typo in IPR statement; 858 - Updated copyright date; 860 - Updated with new editor's name and contact information; 862 - Cosmetic fixes to layout and typography; 864 - Changed title, headers and footers; 866 - Fixed typo in SnmpNBPAddress; 868 - Clarified that one of the BER SEQUENCEs in the example is 869 generated from the ASN.1 SEQUENCE OF construct; 871 - Updated acknowledgements section; 873 - Filled in the Security Considerations section; 875 - Replaced manager/agent terminology with terms from 876 architecture; 878 - Updated references section; 880 - Added MODULE-IDENTITY; 882 - Re-wrote introduction section using current boilerplate; 884 - Added recommendation for larger message size support; 886 - Added historical background on use of rfc1157Domain with 887 proxy and changed status to "deprecated"; 889 - Added an abstract; 891 - Strengthened conformance requirement for support of the UDP 892 over IPv4 mapping; 894 - Updated working group mailing list address; 896 - Added address of working group co-chair; 898 - Corrected error in BER example; 900 Added IANA considerations section. 902 16. Issues 904 This section is to be deleted when it is time to publish this 905 document as an RFC. The issue labels are the same as those used in 906 the on-line issues list at 907 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 909 1906-01 Done; title changed. 911 1906-02 Done; introduction clause replaced. 913 1906-03 Done; no action taken. 915 1906-04 Done; resolution required no changes. 917 1906-05 Done; typo in SnmpNBPAddress fixed. 919 1906-06 See issue 1906-10. 921 1906-07 Done; use of manager/agent terminology replaced with 922 terms from architecture. 924 1906-08 Done; added recommendation for support of 1472 byte 925 messages. 927 1906-09 Done; resolution required no changes. 929 1906-10 Done; resolved by deprecating the definition. 931 1906-11 Done; resolution required no changes. 933 1906-12 Done; resolution required no changes. 935 1906-13 Done; resolution required no changes. 937 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 938 SEQUENCE OF. 940 1906-15 Done; security considerations text added. 942 1906-16 Done; references and acknowledgments updated. 944 1906-17 Done; IPR and copyright notices updated. 946 1906-18 Done; resolution required no changes. 948 1906-19 Done; MODULE-IDENTITY added. 950 1906-20 Done; resolution was to the mapping onto UDP over IPv4 951 mandatory for systems which support IPv4. 953 1906-21 Done; resolution was to make no change. 955 1906-22 Done; resolution was to make no change. 957 1906-23 Done; added abstract. 959 17. Full Copyright Statement 961 Copyright (C) The Internet Society (2001). All Rights Reserved. 963 This document and translations of it may be copied and furnished to 964 others, and derivative works that comment on or otherwise explain it 965 or assist in its implementation may be prepared, copied, published 966 and distributed, in whole or in part, without restriction of any 967 kind, provided that the above copyright notice and this paragraph are 968 included on all such copies and derivative works. However, this 969 document itself may not be modified in any way, such as by removing 970 the copyright notice or references to the Internet Society or other 971 Internet organizations, except as needed for the purpose of 972 developing Internet standards in which case the procedures for 973 copyrights defined in the Internet Standards process must be 974 followed, or as required to translate it into languages other than 975 English. 977 The limited permissions granted above are perpetual and will not be 978 revoked by the Internet Society or its successors or assigns. 980 This document and the information contained herein is provided on an 981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.