idnits 2.17.1 draft-ietf-snmpv3-update-transmap-01.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 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 52 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC1906, but the abstract doesn't seem to directly say this. It does mention RFC1906 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 200 has weird spacing: '... octets cont...' == Line 230 has weird spacing: '... octets cont...' == Line 280 has weird spacing: '... octets cont...' == Line 282 has weird spacing: '...address net...' == Line 658 has weird spacing: '... The previo...' == (1 more instance...) -- 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 (23 January 2000) is 8859 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 310, but not defined -- Looks like a reference, but probably isn't: '5' on line 589 == Unused Reference: 'RFC-TM' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC2233' is defined on line 818, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS8072A' -- Possible downref: Non-RFC (?) normative reference: ref. 'APPLETALK' ** Downref: Normative reference to an Historic RFC: RFC 1742 -- Possible downref: Non-RFC (?) normative reference: ref. 'NOVELL' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TM' ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 12 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: -TM 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 23 January 2000 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 (2000). All Rights Reserved. 42 Abstract 44 This document is intended to obsolete RFC 1906, Transport Mappings 45 for Version 2 of the Simple Network Management Protocol (SNMPv2). It 46 defines the transport of SNMP messages over various protocols. 48 Table of Contents 50 1. Introduction ................................................ 3 51 2. Definitions ................................................. 4 52 3. SNMP over UDP ............................................... 7 53 3.1. Serialization ............................................. 7 54 3.2. Well-known Values ......................................... 8 55 4. SNMP over OSI ............................................... 8 56 4.1. Serialization ............................................. 8 57 4.2. Well-known Values ......................................... 8 58 5. SNMP over DDP ............................................... 8 59 5.1. Serialization ............................................. 8 60 5.2. Well-known Values ......................................... 9 61 5.3. Discussion of AppleTalk Addressing ........................ 9 62 5.3.1. How to Acquire NBP names ................................ 10 63 5.3.2. When to Turn NBP names into DDP addresses ............... 10 64 5.3.3. How to Turn NBP names into DDP addresses ................ 11 65 5.3.4. What if NBP is broken ................................... 11 66 6. SNMP over IPX ............................................... 12 67 6.1. Serialization ............................................. 12 68 6.2. Well-known Values ......................................... 12 69 7. Proxy to SNMPv1 ............................................. 12 70 8. Serialization using the Basic Encoding Rules ................ 12 71 8.1. Usage Example ............................................. 13 72 9. Notice on Intellectual Property ............................. 14 73 10. Acknowledgments ............................................ 14 74 11. Security Considerations .................................... 16 75 12. References ................................................. 16 76 13. Editor's Address ........................................... 18 77 14. Changes from RFC 1906 ...................................... 19 78 15. Issues ..................................................... 20 79 16. 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 2571 [RFC2571]. 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 2572 [RFC2572] and RFC 2574 104 [RFC2574]. 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 -PROTO [RFC-PROTO]. 112 - A set of fundamental applications described in RFC 2573 113 [RFC2573] and the view-based access control mechanism 114 described in RFC 2575 [RFC2575]. 116 A more detailed introduction to the SNMP Management Framework at 117 the time of this writing can be found in RFC 2570 [RFC2570]. 119 Managed objects are accessed via a virtual information store, 120 termed the Management Information Base or MIB. Objects in the 121 MIB are defined using the mechanisms defined in the SMI. 123 This document, Transport Mappings for the Simple Network 124 Management Protocol, defines how the management protocol [RFC- 125 PROTO] may be carried over a variety of protocol suites. It is 126 the purpose of this document to define how the SNMP maps onto an 127 initial set of transport domains. Other mappings may be defined 128 in the future. 130 Although several mappings are defined, the mapping onto UDP is 131 the preferred mapping. As such, to provide for the greatest 132 level of interoperability, systems which choose to deploy other 133 mappings should also provide for proxy service to the UDP 134 mapping. 136 2. Definitions 138 SNMPv2-TM DEFINITIONS ::= BEGIN 140 IMPORTS ! 141 MODULE-IDENTITY, OBJECT-IDENTITY, ! 142 snmpModules, snmpDomains, snmpProxys 143 FROM SNMPv2-SMI 144 TEXTUAL-CONVENTION 145 FROM SNMPv2-TC; 147 snmpv2tm MODULE-IDENTITY ! 148 LAST-UPDATED "200001231839Z" ! 149 ORGANIZATION "IETF SNMPv3 Working Group" ! 150 CONTACT-INFO ! 151 "WG-EMail: snmpv3@tis.com ! 152 Subscribe: majordomo@tis.com ! 153 In message body: subscribe snmpv3 ! 155 Chair: Russ Mundy ! 156 TIS Labs at Network Associates ! 157 postal: 3060 Washington Rd ! 158 Glenwood MD 21738 ! 159 USA ! 160 EMail: mundy@tislabs.com ! 161 phone: +1 301 854-6889 ! 163 Editor: Randy Presuhn ! 164 BMC Software, Inc. ! 165 postal: 2141 North First Street ! 166 San Jose, CA 95131 ! 167 USA ! 168 EMail: randy_presuhn@bmc.com ! 169 phone: +1 408 546-1006" ! 170 DESCRIPTION ! 171 "The MIB module for SNMP transport mappings." ! 172 REVISION "200001231839Z" ! 173 DESCRIPTION ! 174 "Clarifications, published as ! 175 " ! 177 REVISION "199601010000Z" ! 178 DESCRIPTION ! 179 "Clarifications, published as RFC 1906." ! 180 REVISION "199304010000Z" ! 181 DESCRIPTION ! 182 "The initial version, published as RFC 1449." ! 183 ::= { snmpModules ?? } -- to be assigned by IANA?? ! 185 -- SNMP over UDP over IPv4 187 snmpUDPDomain OBJECT-IDENTITY 188 STATUS current 189 DESCRIPTION 190 "The SNMP over UDP transport domain. The corresponding 191 transport address is of type SnmpUDPAddress." 192 ::= { snmpDomains 1 } 194 SnmpUDPAddress ::= TEXTUAL-CONVENTION 195 DISPLAY-HINT "1d.1d.1d.1d/2d" 196 STATUS current 197 DESCRIPTION 198 "Represents a UDP address: 200 octets contents encoding 201 1-4 IP-address network-byte order 202 5-6 UDP-port network-byte order 203 " 204 SYNTAX OCTET STRING (SIZE (6)) 206 -- SNMP over OSI 208 snmpCLNSDomain OBJECT-IDENTITY 209 STATUS current 210 DESCRIPTION 211 "The SNMP over CLNS transport domain. 212 The corresponding transport address is of type 213 SnmpOSIAddress." 214 ::= { snmpDomains 2 } 216 snmpCONSDomain OBJECT-IDENTITY 217 STATUS current 218 DESCRIPTION 219 "The SNMP over CONS transport domain. 220 The corresponding transport address is of type 221 SnmpOSIAddress." 222 ::= { snmpDomains 3 } 224 SnmpOSIAddress ::= TEXTUAL-CONVENTION 225 DISPLAY-HINT "*1x:/1x:" 226 STATUS current 227 DESCRIPTION 228 "Represents an OSI transport-address: 230 octets contents encoding 231 1 length of NSAP 'n' as an unsigned-integer 232 (either 0 or from 3 to 20) 233 2..(n+1) NSAP concrete binary representation 234 (n+2)..m TSEL string of (up to 64) octets 235 " 236 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 238 -- SNMP over DDP 240 snmpDDPDomain OBJECT-IDENTITY 241 STATUS current 242 DESCRIPTION 243 "The SNMP over DDP transport domain. The corresponding 244 transport address is of type SnmpNBPAddress." 245 ::= { snmpDomains 4 } 247 SnmpNBPAddress ::= TEXTUAL-CONVENTION 248 STATUS current 249 DESCRIPTION 250 "Represents an NBP name: 252 octets contents encoding 253 1 length of object 'n' as an unsigned integer 254 2..(n+1) object string of (up to 32) octets 255 n+2 length of type 'p' as an unsigned integer 256 (n+3)..(n+2+p) type string of (up to 32) octets 257 n+3+p length of zone 'q' as an unsigned integer 258 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 260 For comparison purposes, strings are 261 case-insensitive. All strings may contain any octet 262 other than 255 (hex ff)." 263 SYNTAX OCTET STRING (SIZE (3..99)) 265 -- SNMP over IPX 267 snmpIPXDomain OBJECT-IDENTITY 268 STATUS current 269 DESCRIPTION 270 "The SNMP over IPX transport domain. The corresponding 271 transport address is of type SnmpIPXAddress." 272 ::= { snmpDomains 5 } 274 SnmpIPXAddress ::= TEXTUAL-CONVENTION 275 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 276 STATUS current 277 DESCRIPTION 278 "Represents an IPX address: 280 octets contents encoding 281 1-4 network-number network-byte order 282 5-10 physical-address network-byte order 283 11-12 socket-number network-byte order 284 " 285 SYNTAX OCTET STRING (SIZE (12)) 287 -- for proxy to SNMPv1 (RFC 1157) 289 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 291 rfc1157Domain OBJECT-IDENTITY 292 STATUS current 293 DESCRIPTION 294 "The transport domain for SNMPv1 over UDP. 295 The corresponding transport address is of type 296 SnmpUDPAddress." 297 ::= { rfc1157Proxy 1 } 299 -- ::= { rfc1157Proxy 2 } this OID is obsolete 301 END 303 3. SNMP over UDP 305 This is the preferred transport mapping. 307 3.1. Serialization 309 Each instance of a message is serialized (i.e., encoded according to 310 the convention of [ASN1]) onto a single UDP [RFC768] 311 datagram, using the algorithm specified in Section 8. 313 3.2. Well-known Values 315 It is suggested that administrators configure their SNMP entities 316 supporting command responder applications to listen on UDP port 161. 317 Further, it is suggested that SNMP entities supporting notification 318 receiver applications be configured to listen on UDP port 162. 320 When an SNMP entity uses this transport mapping, it must be capable 321 of accepting messages up to and including 484 octets in size. It is ! 322 recommended that implementations be capable of accepting messages of ! 323 up to 1472 octets in size. Implementation of larger values is ! 324 encouraged whenever possible. 326 4. SNMP over OSI 328 This is an optional transport mapping. 330 4.1. Serialization 332 Each instance of a message is serialized onto a single TSDU [IS8072] 333 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 334 using the algorithm specified in Section 8. 336 4.2. Well-known Values 338 It is suggested that administrators configure their SNMP entities 339 supporting command responder applications to listen on transport 340 selector "snmp-l" (which consists of six ASCII characters), when 341 using a CL-mode network service to realize the CLTS. Further, it is 342 suggested that SNMP entities supporting notification receiver 343 applications be configured to listen on transport selector "snmpt-l" 344 (which consists of seven ASCII characters, six letters and a hyphen) 345 when using a CL-mode network service to realize the CLTS. Similarly, 346 when using a CO-mode network service to realize the CLTS, the 347 suggested transport selectors are "snmp-o" and "snmpt-o", for command 348 responders and notification receivers, respectively. 350 When an SNMP entity uses this transport mapping, it must be capable 351 of accepting messages that are at least 484 octets in size. 352 Implementation of larger values is encouraged whenever possible. 354 5. SNMP over DDP 356 This is an optional transport mapping. 358 5.1. Serialization 360 Each instance of a message is serialized onto a single DDP datagram 361 [APPLETALK], using the algorithm specified in Section 8. 363 5.2. Well-known Values 365 SNMP messages are sent using DDP protocol type 8. SNMP entities 366 supporting command responder applications listen on DDP socket number 367 8, while SNMP entities supporting notification receiver applications 368 listen on DDP socket number 9. 370 Administrators must configure their SNMP entities supporting command 371 responder applications to use NBP type "SNMP Agent" (which consists 372 of ten ASCII while those supporting notification receiver 373 applications must be configured to use NBP type "SNMP Trap Handler" 374 (which consists of seventeen ASCII characters). 376 The NBP name for SNMP entities supporting command responders and 377 notification receivers should be stable - NBP names should not change 378 any more often than the IP address of a typical TCP/IP node. It is 379 suggested that the NBP name be stored in some form of stable storage. 381 When an SNMP entity uses this transport mapping, it must be capable 382 of accepting messages that are at least 484 octets in size. 383 Implementation of larger values is encouraged whenever possible. 385 5.3. Discussion of AppleTalk Addressing 387 The AppleTalk protocol suite has certain features not manifest in the 388 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 389 address assignment can cause problems for SNMP entities that wish to 390 manage AppleTalk networks. TCP/IP nodes have an associated IP 391 address which distinguishes each from the other. In contrast, 392 AppleTalk nodes generally have no such characteristic. The network- 393 level address, while often relatively stable, can change at every 394 reboot (or more frequently). 396 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 397 rather than by an "address". Hence, all AppleTalk nodes that 398 implement this mapping are required to respond to NBP lookups and 399 confirms (e.g., implement the NBP protocol stub), which guarantees 400 that a mapping from NBP name to DDP address will be possible. 402 In determining the SNMP identity to register for an SNMP entity, it 403 is suggested that the SNMP identity be a name which is associated 404 with other network services offered by the machine. 406 NBP lookups, which are used to map NBP names into DDP addresses, can 407 cause large amounts of network traffic as well as consume CPU 408 resources. It is also the case that the ability to perform an NBP 409 lookup is sensitive to certain network disruptions (such as zone 410 table inconsistencies) which would not prevent direct AppleTalk 411 communications between two SNMP entities. 413 Thus, it is recommended that NBP lookups be used infrequently, 414 primarily to create a cache of name-to-address mappings. These 415 cached mappings should then be used for any further SNMP traffic. It 416 is recommended that SNMP entities supporting command generator 417 applications should maintain this cache between reboots. This 418 caching can help minimize network traffic, reduce CPU load on the 419 network, and allow for (some amount of) network trouble shooting when 420 the basic name-to-address translation mechanism is broken. 422 5.3.1. How to Acquire NBP names 424 An SNMP entity supporting command generator applications may have a 425 pre-configured list of names of "known" SNMP entities supporting 426 command responder applications. Similarly, an SNMP entity supporting 427 command generator or notification receiver applications might 428 interact with an operator. Finally, an SNMP entity supporting 429 command generator or notification receiver applications might 430 communicate with all SNMP entities supporting command responder or 431 notification originator applications in a set of zones or networks. 433 5.3.2. When to Turn NBP names into DDP addresses 435 When an SNMP entity uses a cache entry to address an SNMP packet, it 436 should attempt to confirm the validity mapping, if the mapping hasn't 437 been confirmed within the last T1 seconds. This cache entry 438 lifetime, T1, has a minimum, default value of 60 seconds, and should 439 be configurable. 441 An SNMP entity supporting a command generator application may decide 442 to prime its cache of names prior to actually communicating with 443 another SNMP entity. In general, it is expected that such an entity 444 may want to keep certain mappings "more current" than other mappings, 445 e.g., those nodes which represent the network infrastructure (e.g., 446 routers) may be deemed "more important". 448 Note that an SNMP entity supporting command generator applications 449 should not prime its entire cache upon initialization - rather, it 450 should attempt resolutions over an extended period of time (perhaps 451 in some pre- determined or configured priority order). Each of these 452 resolutions might, in fact, be a wildcard lookup in a given zone. 454 An SNMP entity supporting command responder applications must never 455 prime its cache. When generating a response, such an entity does not 456 need to confirm a cache entry. An SNMP entity supporting 457 notification originator applications should do NBP lookups (or 458 confirms) only when it needs to send an SNMP trap or inform. 460 5.3.3. How to Turn NBP names into DDP addresses 462 If the only piece of information available is the NBP name, then an 463 NBP lookup should be performed to turn that name into a DDP address. 464 However, if there is a piece of stale information, it can be used as 465 a hint to perform an NBP confirm (which sends a unicast to the 466 network address which is presumed to be the target of the name 467 lookup) to see if the stale information is, in fact, still valid. 469 An NBP name to DDP address mapping can also be confirmed implicitly 470 using only SNMP transactions. For example, an SNMP entity acting 471 supporting command generator applications issuing a retrieval 472 operation could also retrieve the relevant objects from the NBP group 473 [RFC1742] for the SNMP entity supporting the command responder 474 application. This information can then be correlated with the source 475 DDP address of the response. 477 5.3.4. What if NBP is broken 479 Under some circumstances, there may be connectivity between two SNMP 480 entities, but the NBP mapping machinery may be broken, e.g., 482 o the NBP FwdReq (forward NBP lookup onto local attached network) 483 mechanism might be broken at a router on the other entity's 484 network; or, 486 o the NBP BrRq (NBP broadcast request) mechanism might be broken 487 at a router on the entity's own network; or, 489 o NBP might be broken on the other entity's node. 491 An SNMP entity supporting command generator applications which is 492 dedicated to AppleTalk management might choose to alleviate some of 493 these failures by directly implementing the router portion of NBP. 494 For example, such an entity might already know all the zones on the 495 AppleTalk internet and the networks on which each zone appears. 496 Given an NBP lookup which fails, the entity could send an NBP FwdReq 497 to the network in which the SNMP entity supporting the command 498 responder or notification originator application was last located. 499 If that failed, the station could then send an NBP LkUp (NBP lookup 500 packet) as a directed (DDP) multicast to each network number on that 501 network. Of the above (single) failures, this combined approach will 502 solve the case where either the local router's BrRq-to-FwdReq 503 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 504 is broken. 506 6. SNMP over IPX 508 This is an optional transport mapping. 510 6.1. Serialization 512 Each instance of a message is serialized onto a single IPX datagram 513 [NOVELL], using the algorithm specified in Section 8. 515 6.2. Well-known Values 517 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 518 Protocol). 520 It is suggested that administrators configure their SNMP entities 521 supporting command responder applications to listen on IPX socket 522 36879 (900f hexadecimal). Further, it is suggested that those 523 supporting notification receiver applications be configured to listen 524 on IPX socket 36880 (9010 hexadecimal). 526 When an SNMP entity uses this transport mapping, it must be capable 527 of accepting messages that are at least 546 octets in size. 528 Implementation of larger values is encouraged whenever possible. 530 7. Proxy to SNMPv1 532 Historically, in order to support proxy to SNMPv1, as defined in 533 [RFC-COEX], it was deemed useful to define a transport domain, 534 rfc1157Domain, which indicates the transport mapping for SNMP 535 messages as defined in [RFC1157]. Subsequently, this transport 536 domain has proven useful in non-proxy situations. 538 8. Serialization using the Basic Encoding Rules 540 When the Basic Encoding Rules [BER] are used for serialization: 542 (1) When encoding the length field, only the definite form is used; 543 use of the indefinite form encoding is prohibited. Note that 544 when using the definite-long form, it is permissible to use more 545 than the minimum number of length octets necessary to encode the 546 length field. 548 (2) When encoding the value field, the primitive form shall be used 549 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 550 IDENTIFIER (either IMPLICIT or explicit). The constructed form 551 of encoding shall be used only for structured types, i.e., a 552 SEQUENCE or an IMPLICIT SEQUENCE. 554 (3) When encoding an object whose syntax is described using the BITS 555 construct, the value is encoded as an OCTET STRING, in which all 556 the named bits in (the definition of) the bitstring, commencing 557 with the first bit and proceeding to the last bit, are placed in 558 bits 8 to 1 of the first octet, followed by bits 8 to 1 of each 559 subsequent octet in turn, followed by as many bits as are needed 560 of the final subsequent octet, commencing with bit 8. Remaining 561 bits, if any, of the final octet are set to zero on generation 562 and ignored on receipt. 564 These restrictions apply to all aspects of ASN.1 encoding, including 565 the message wrappers, protocol data units, and the data objects they 566 contain. 568 8.1. Usage Example 570 As an example of applying the Basic Encoding Rules, suppose one 571 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: 573 [5] IMPLICIT SEQUENCE { 574 request-id 1414684022, 575 non-repeaters 1, 576 max-repetitions 2, 577 variable-bindings { 578 { name sysUpTime, 579 value { unspecified NULL } }, 580 { name ipNetToMediaPhysAddress, 581 value { unspecified NULL } }, 582 { name ipNetToMediaType, 583 value { unspecified NULL } } 584 } 585 } 587 Applying the BER, this would be encoded (in hexadecimal) as: 589 [5] IMPLICIT SEQUENCE a5 82 00 39 590 INTEGER 02 04 52 54 5d 76 591 INTEGER 02 01 01 592 INTEGER 02 01 02 593 SEQUENCE (OF) 30 2b 594 SEQUENCE 30 0b 595 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 596 NULL 05 00 597 SEQUENCE 30 0d 598 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 599 NULL 05 00 600 SEQUENCE 30 0d 601 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 602 NULL 05 00 604 Note that the initial SEQUENCE is not encoded using the minimum 605 number of length octets. (The first octet of the length, 82, 606 indicates that the length of the content is encoded in the next two 607 octets.) 609 9. Notice on Intellectual Property 611 The IETF takes no position regarding the validity or scope of any 612 intellectual property or other rights that might be claimed to 613 pertain to the implementation or use of the technology described in 614 this document or the extent to which any license under such rights 615 might or might not be available; neither does it represent that it 616 has made any effort to identify any such rights. Information on the 617 IETF's procedures with respect to rights in standards-track and 618 standards-related documentation can be found in BCP-11. Copies of 619 claims of rights made available for publication and any assurances of 620 licenses to be made available, or the result of an attempt made to 621 obtain a general license or permission for the use of such 622 proprietary rights by implementors or users of this specification can 623 be obtained from the IETF Secretariat. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights which may cover technology that may be required to practice 628 this standard. Please address the information to the IETF Executive 629 Director. 631 10. Acknowledgments 633 This document is the product of the SNMPv3 Working Group. Some 634 special thanks are in order to the following Working Group members: 636 Randy Bush 637 Jeffrey D. Case 638 Mike Daniele 639 Rob Frye 640 Lauren Heintz 641 Keith McCloghrie 642 Russ Mundy 643 David T. Perkins 644 Randy Presuhn 645 Aleksey Romanov 646 Juergen Schoenwaelder 647 Bert Wijnen 649 This version of the document, edited by Randy Presuhn, was initially 650 based on the work of a design team whose members were: 652 Jeffrey D. Case 653 Keith McCloghrie 654 David T. Perkins 655 Randy Presuhn 656 Juergen Schoenwaelder 658 The previous versions of this document, edited by Keith McCloghrie, 659 was the result of significant work by four major contributors: 661 Jeffrey D. Case 662 Keith McCloghrie 663 Marshall T. Rose 664 Steven Waldbusser 666 Additionally, the contributions of the SNMPv2 Working Group to the 667 previous versions are also acknowledged. In particular, a special 668 thanks is extended for the contributions of: 670 Alexander I. Alten 671 Dave Arneson 672 Uri Blumenthal 673 Doug Book 674 Kim Curran 675 Jim Galvin 676 Maria Greene 677 Iain Hanson 678 Dave Harrington 679 Nguyen Hien 680 Jeff Johnson 681 Michael Kornegay 682 Deirdre Kostick 683 David Levi 684 Daniel Mahoney 685 Bob Natale 686 Brian O'Keefe 687 Andrew Pearson 688 Dave Perkins 689 Randy Presuhn 690 Aleksey Romanov 691 Shawn Routhier 692 Jon Saperia 693 Juergen Schoenwaelder 694 Bob Stewart 695 Kaj Tesink 696 Glenn Waters 697 Bert Wijnen 699 11. Security Considerations 701 SNMPv1 by itself is not a secure environment. Even if the network ! 702 itself is secure (for example by using IPSec), even then, there is no ! 703 control as to who on the secure network is allowed to access and ! 704 GET/SET (read/change) the objects accessible through a command ! 705 responder application. ! 707 It is recommended that the implementors consider the security ! 708 features as provided by the SNMPv3 framework. Specifically, the use ! 709 of the User-based Security Model RFC 2574 [RFC2574] and the ! 710 View-based Access Control Model RFC 2575 [RFC2575] is recommended. ! 712 It is then a customer/user responsibility to ensure that the SNMP ! 713 entity giving access to a MIB is properly configured to give access ! 714 to the objects only to those principals (users) that have legitimate ! 715 rights to indeed GET or SET (change) them. ! 717 12. References 719 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 720 USC/Information Sciences Institute, August 1980. 722 [IS8072] Information processing systems - Open Systems 723 Interconnection - Transport Service Definition, 724 International Organization for Standardization. 725 International Standard 8072, June 1986. 727 [IS8072A] Information processing systems - Open Systems 728 Interconnection - Transport Service Definition - Addendum 729 1: Connectionless-mode Transmission, International 730 Organization for Standardization. International Standard 731 8072/AD 1, December 1986. 733 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 734 AppleTalk (second edition). Addison-Wesley, 1990. 736 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 737 Information Base II", RFC 1742, January 1995. 739 [NOVELL] Network System Technical Interface Overview. Novell, 740 Inc, June 1989. 742 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 743 "Coexistence between Version 1, Version 2, and Version 3 744 of the Internet-standard Network Management Framework", 745 , January, 2000. 747 [BER] Information processing systems - Open Systems 748 Interconnection - Specification of Basic Encoding Rules 749 for Abstract Syntax Notation One (ASN.1), International 750 Organization for Standardization. International Standard 751 8825, December 1987. 753 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 754 Architecture for Describing SNMP Management Frameworks", 755 RFC 2571, April 1999. 757 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 758 Identification of Management Information for TCP/IP-based 759 Internets", STD 16, RFC 1155, May 1990. 761 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 762 STD 16, RFC 1212, March 1991. 764 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 765 the SNMP", RFC 1215, March 1991. 767 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 768 Rose, M., and S. Waldbusser, "Structure of Management 769 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 770 1999. 772 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 773 Rose, M., and S. Waldbusser, "Textual Conventions for 774 SMIv2", STD 58, RFC 2579, April 1999. 776 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 777 Rose, M., and S. Waldbusser, "Conformance Statements for 778 SMIv2", STD 58, RFC 2580, April 1999. 780 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 781 "Simple Network Management Protocol", STD 15, RFC 1157, 782 May 1990. 784 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 785 "Introduction to Community-based SNMPv2", RFC 1901, 786 January 1996. 788 [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 789 Waldbusser, "Transport Mappings for the Simple Network 790 Management Protocol", 791 , January 2000. 793 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 794 "Message Processing and Dispatching for the Simple 795 Network Management Protocol (SNMP)", RFC 2572, April 796 1999. 798 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 799 (USM) for version 3 of the Simple Network Management 800 Protocol (SNMPv3)", RFC 2574, April 1999. 802 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 803 Waldbusser, "Protocol Operations for the Simple Network 804 Management Protocol", 805 , January 2000. 807 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 808 Applications", RFC 2573, April 1999. 810 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 811 Access Control Model (VACM) for the Simple Network 812 Management Protocol (SNMP)", RFC 2575, April 1999. 814 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 815 "Introduction to Version 3 of the Internet-standard 816 Network Management Framework", RFC 2570, April 1999. 818 [RFC2233] McCloghrie, K., and F. Kastenholz, "The Interfaces Group 819 MIB using SMIv2", RFC 2233, November 1997. 821 13. Editor's Address 823 Randy Presuhn 824 BMC Software, Inc. 825 2141 North First Street 826 San Jose, CA 95131 827 USA 829 Phone: +1 408 546-1006 830 EMail: randy_presuhn@bmc.com 832 14. Changes from RFC 1906 834 These are the changes from RFC 1906: 836 - Corrected typo in IPR statement; 838 - Updated copyright date; 840 - Updated with new editor's name and contact information; 842 - Cosmetic fixes to layout and typography; 844 - Changed title, headers and footers; 846 - Fixed typo in SnmpNBPAddress; 848 - Clarified that one of the BER SEQUENCEs in the example is 849 generated from the ASN.1 SEQUENCE OF construct; 851 - Updated acknowledgements section; 853 - Filled in the Security Considerations section; 855 - Replaced manager/agent terminology with terms from 856 architecture; 858 - Updated references section; 860 - Added MODULE-IDENTITY; 862 - Re-wrote introduction section using current boilerplate; 864 - Added recommendation for larger message size support; 866 - Added historical background on use of rfc1157Domain with 867 proxy; 869 15. Issues 871 This section is to be deleted when it is time to publish this 872 document as an RFC. The issue labels are the same as those used in 873 the on-line issues list at 874 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 876 1906-01 Done; title changed. 878 1906-02 Done; introduction clause replaced. 880 1906-03 882 1906-04 Done; resolution required no changes. 884 1906-05 Done; typo in SnmpNBPAddress fixed. 886 1906-06 888 1906-07 Done; use of manager/agent terminology replaced with 889 terms from architecture. 891 1906-08 Done; added recommendation for support of 1472 byte 892 messages. 894 1906-09 Done; resolution required no changes. 896 1906-10 Done; added historical background to material on proxy. 897 Note that some are unhappy with this text; a better 898 replacement would be most welcome. 900 1906-11 Done; resolution required no changes. 902 1906-12 Done; resolution required no changes. 904 1906-13 Done; resolution required no changes. 906 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 907 SEQUENCE OF. 909 1906-15 Done; security considerations text added. 911 1906-16 Done; references and acknowledgments updated. 913 1906-17 Done; IPR and copyright notices updated. 915 1906-18 Done; resolution required no changes. 917 1906-19 Done; MODULE-IDENTITY added. 919 16. Full Copyright Statement 921 Copyright (C) The Internet Society (2000). All Rights Reserved. 923 This document and translations of it may be copied and furnished to 924 others, and derivative works that comment on or otherwise explain it 925 or assist in its implementation may be prepared, copied, published 926 and distributed, in whole or in part, without restriction of any 927 kind, provided that the above copyright notice and this paragraph are 928 included on all such copies and derivative works. However, this 929 document itself may not be modified in any way, such as by removing 930 the copyright notice or references to the Internet Society or other 931 Internet organizations, except as needed for the purpose of 932 developing Internet standards in which case the procedures for 933 copyrights defined in the Internet Standards process must be 934 followed, or as required to translate it into languages other than 935 English. 937 The limited permissions granted above are perpetual and will not be 938 revoked by the Internet Society or its successors or assigns. 940 This document and the information contained herein is provided on an 941 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 942 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 943 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 944 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 945 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.