idnits 2.17.1 draft-ietf-snmpv3-update-transmap-02.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. -- 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 201 has weird spacing: '... octets cont...' == Line 231 has weird spacing: '... octets cont...' == Line 281 has weird spacing: '... octets cont...' == Line 283 has weird spacing: '...address net...' == Line 361 has weird spacing: '... Each insta...' == (2 more instances...) -- 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 April 2000) is 8788 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 311, but not defined -- Looks like a reference, but probably isn't: '5' on line 590 == Unused Reference: 'RFC-TM' is defined on line 812, 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) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2576 (Obsoleted by RFC 3584) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 11 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 3 April 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 over IPv4 ..................................... 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 over 131 IPv4 is the preferred mapping. As such, to provide for the 132 greatest level of interoperability, systems which choose to 133 deploy other mappings should also provide for proxy service to 134 the UDP over IPv4 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 "200004032350Z" 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 "200004032350Z" 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 over IPv4 transport domain. 191 The corresponding transport address is of type 192 SnmpUDPAddress." 193 ::= { snmpDomains 1 } 195 SnmpUDPAddress ::= TEXTUAL-CONVENTION 196 DISPLAY-HINT "1d.1d.1d.1d/2d" 197 STATUS current 198 DESCRIPTION 199 "Represents a UDP over IPv4 address: 201 octets contents encoding 202 1-4 IP-address network-byte order 203 5-6 UDP-port network-byte order 204 " 205 SYNTAX OCTET STRING (SIZE (6)) 207 -- SNMP over OSI 209 snmpCLNSDomain OBJECT-IDENTITY 210 STATUS current 211 DESCRIPTION 212 "The SNMP over CLNS transport domain. 213 The corresponding transport address is of type 214 SnmpOSIAddress." 215 ::= { snmpDomains 2 } 217 snmpCONSDomain OBJECT-IDENTITY 218 STATUS current 219 DESCRIPTION 220 "The SNMP over CONS transport domain. 221 The corresponding transport address is of type 222 SnmpOSIAddress." 223 ::= { snmpDomains 3 } 225 SnmpOSIAddress ::= TEXTUAL-CONVENTION 226 DISPLAY-HINT "*1x:/1x:" 227 STATUS current 228 DESCRIPTION 229 "Represents an OSI transport-address: 231 octets contents encoding 232 1 length of NSAP 'n' as an unsigned-integer 233 (either 0 or from 3 to 20) 234 2..(n+1) NSAP concrete binary representation 235 (n+2)..m TSEL string of (up to 64) octets 236 " 237 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 239 -- SNMP over DDP 241 snmpDDPDomain OBJECT-IDENTITY 242 STATUS current 243 DESCRIPTION 244 "The SNMP over DDP transport domain. The corresponding 245 transport address is of type SnmpNBPAddress." 246 ::= { snmpDomains 4 } 248 SnmpNBPAddress ::= TEXTUAL-CONVENTION 249 STATUS current 250 DESCRIPTION 251 "Represents an NBP name: 253 octets contents encoding 254 1 length of object 'n' as an unsigned integer 255 2..(n+1) object string of (up to 32) octets 256 n+2 length of type 'p' as an unsigned integer 257 (n+3)..(n+2+p) type string of (up to 32) octets 258 n+3+p length of zone 'q' as an unsigned integer 259 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 261 For comparison purposes, strings are 262 case-insensitive. All strings may contain any octet 263 other than 255 (hex ff)." 264 SYNTAX OCTET STRING (SIZE (3..99)) 266 -- SNMP over IPX 268 snmpIPXDomain OBJECT-IDENTITY 269 STATUS current 270 DESCRIPTION 271 "The SNMP over IPX transport domain. The corresponding 272 transport address is of type SnmpIPXAddress." 273 ::= { snmpDomains 5 } 275 SnmpIPXAddress ::= TEXTUAL-CONVENTION 276 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 277 STATUS current 278 DESCRIPTION 279 "Represents an IPX address: 281 octets contents encoding 282 1-4 network-number network-byte order 283 5-10 physical-address network-byte order 284 11-12 socket-number network-byte order 285 " 286 SYNTAX OCTET STRING (SIZE (12)) 288 -- for proxy to SNMPv1 (RFC 1157) 290 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 292 rfc1157Domain OBJECT-IDENTITY 293 STATUS current 294 DESCRIPTION 295 "The transport domain for SNMPv1 over UDP over IPv4. 296 The corresponding transport address is of type 297 SnmpUDPAddress." 298 ::= { rfc1157Proxy 1 } 300 -- ::= { rfc1157Proxy 2 } this OID is obsolete 302 END 304 3. SNMP over UDP over IPv4 306 This is the preferred transport mapping. 308 3.1. Serialization 310 Each instance of a message is serialized (i.e., encoded according to 311 the convention of [ASN1]) onto a single UDP [RFC768] over IPv4 312 [RFC791] datagram, using the algorithm specified in Section 8. 314 3.2. Well-known Values 316 It is suggested that administrators configure their SNMP entities 317 supporting command responder applications to listen on UDP port 161. 318 Further, it is suggested that SNMP entities supporting notification 319 receiver applications be configured to listen on UDP port 162. 321 When an SNMP entity uses this transport mapping, it must be capable 322 of accepting messages up to and including 484 octets in size. It is 323 recommended that implementations be capable of accepting messages of 324 up to 1472 octets in size. Implementation of larger values is 325 encouraged whenever possible. 327 4. SNMP over OSI 329 This is an optional transport mapping. 331 4.1. Serialization 333 Each instance of a message is serialized onto a single TSDU [IS8072] 334 [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), 335 using the algorithm specified in Section 8. 337 4.2. Well-known Values 339 It is suggested that administrators configure their SNMP entities 340 supporting command responder applications to listen on transport 341 selector "snmp-l" (which consists of six ASCII characters), when 342 using a CL-mode network service to realize the CLTS. Further, it is 343 suggested that SNMP entities supporting notification receiver 344 applications be configured to listen on transport selector "snmpt-l" 345 (which consists of seven ASCII characters, six letters and a hyphen) 346 when using a CL-mode network service to realize the CLTS. Similarly, 347 when using a CO-mode network service to realize the CLTS, the 348 suggested transport selectors are "snmp-o" and "snmpt-o", for command 349 responders and notification receivers, respectively. 351 When an SNMP entity uses this transport mapping, it must be capable 352 of accepting messages that are at least 484 octets in size. 353 Implementation of larger values is encouraged whenever possible. 355 5. SNMP over DDP 357 This is an optional transport mapping. 359 5.1. Serialization 361 Each instance of a message is serialized onto a single DDP datagram 362 [APPLETALK], using the algorithm specified in Section 8. 364 5.2. Well-known Values 366 SNMP messages are sent using DDP protocol type 8. SNMP entities 367 supporting command responder applications listen on DDP socket number 368 8, while SNMP entities supporting notification receiver applications 369 listen on DDP socket number 9. 371 Administrators must configure their SNMP entities supporting command 372 responder applications to use NBP type "SNMP Agent" (which consists 373 of ten ASCII while those supporting notification receiver 374 applications must be configured to use NBP type "SNMP Trap Handler" 375 (which consists of seventeen ASCII characters). 377 The NBP name for SNMP entities supporting command responders and 378 notification receivers should be stable - NBP names should not change 379 any more often than the IP address of a typical TCP/IP node. It is 380 suggested that the NBP name be stored in some form of stable storage. 382 When an SNMP entity uses this transport mapping, it must be capable 383 of accepting messages that are at least 484 octets in size. 384 Implementation of larger values is encouraged whenever possible. 386 5.3. Discussion of AppleTalk Addressing 388 The AppleTalk protocol suite has certain features not manifest in the 389 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 390 address assignment can cause problems for SNMP entities that wish to 391 manage AppleTalk networks. TCP/IP nodes have an associated IP 392 address which distinguishes each from the other. In contrast, 393 AppleTalk nodes generally have no such characteristic. The network- 394 level address, while often relatively stable, can change at every 395 reboot (or more frequently). 397 Thus, when SNMP is mapped over DDP, nodes are identified by a "name", 398 rather than by an "address". Hence, all AppleTalk nodes that 399 implement this mapping are required to respond to NBP lookups and 400 confirms (e.g., implement the NBP protocol stub), which guarantees 401 that a mapping from NBP name to DDP address will be possible. 403 In determining the SNMP identity to register for an SNMP entity, it 404 is suggested that the SNMP identity be a name which is associated 405 with other network services offered by the machine. 407 NBP lookups, which are used to map NBP names into DDP addresses, can 408 cause large amounts of network traffic as well as consume CPU 409 resources. It is also the case that the ability to perform an NBP 410 lookup is sensitive to certain network disruptions (such as zone 411 table inconsistencies) which would not prevent direct AppleTalk 412 communications between two SNMP entities. 414 Thus, it is recommended that NBP lookups be used infrequently, 415 primarily to create a cache of name-to-address mappings. These 416 cached mappings should then be used for any further SNMP traffic. It 417 is recommended that SNMP entities supporting command generator 418 applications should maintain this cache between reboots. This 419 caching can help minimize network traffic, reduce CPU load on the 420 network, and allow for (some amount of) network trouble shooting when 421 the basic name-to-address translation mechanism is broken. 423 5.3.1. How to Acquire NBP names 425 An SNMP entity supporting command generator applications may have a 426 pre-configured list of names of "known" SNMP entities supporting 427 command responder applications. Similarly, an SNMP entity supporting 428 command generator or notification receiver applications might 429 interact with an operator. Finally, an SNMP entity supporting 430 command generator or notification receiver applications might 431 communicate with all SNMP entities supporting command responder or 432 notification originator applications in a set of zones or networks. 434 5.3.2. When to Turn NBP names into DDP addresses 436 When an SNMP entity uses a cache entry to address an SNMP packet, it 437 should attempt to confirm the validity mapping, if the mapping hasn't 438 been confirmed within the last T1 seconds. This cache entry 439 lifetime, T1, has a minimum, default value of 60 seconds, and should 440 be configurable. 442 An SNMP entity supporting a command generator application may decide 443 to prime its cache of names prior to actually communicating with 444 another SNMP entity. In general, it is expected that such an entity 445 may want to keep certain mappings "more current" than other mappings, 446 e.g., those nodes which represent the network infrastructure (e.g., 447 routers) may be deemed "more important". 449 Note that an SNMP entity supporting command generator applications 450 should not prime its entire cache upon initialization - rather, it 451 should attempt resolutions over an extended period of time (perhaps 452 in some pre- determined or configured priority order). Each of these 453 resolutions might, in fact, be a wildcard lookup in a given zone. 455 An SNMP entity supporting command responder applications must never 456 prime its cache. When generating a response, such an entity does not 457 need to confirm a cache entry. An SNMP entity supporting 458 notification originator applications should do NBP lookups (or 459 confirms) only when it needs to send an SNMP trap or inform. 461 5.3.3. How to Turn NBP names into DDP addresses 463 If the only piece of information available is the NBP name, then an 464 NBP lookup should be performed to turn that name into a DDP address. 465 However, if there is a piece of stale information, it can be used as 466 a hint to perform an NBP confirm (which sends a unicast to the 467 network address which is presumed to be the target of the name 468 lookup) to see if the stale information is, in fact, still valid. 470 An NBP name to DDP address mapping can also be confirmed implicitly 471 using only SNMP transactions. For example, an SNMP entity acting 472 supporting command generator applications issuing a retrieval 473 operation could also retrieve the relevant objects from the NBP group 474 [RFC1742] for the SNMP entity supporting the command responder 475 application. This information can then be correlated with the source 476 DDP address of the response. 478 5.3.4. What if NBP is broken 480 Under some circumstances, there may be connectivity between two SNMP 481 entities, but the NBP mapping machinery may be broken, e.g., 483 o the NBP FwdReq (forward NBP lookup onto local attached network) 484 mechanism might be broken at a router on the other entity's 485 network; or, 487 o the NBP BrRq (NBP broadcast request) mechanism might be broken 488 at a router on the entity's own network; or, 490 o NBP might be broken on the other entity's node. 492 An SNMP entity supporting command generator applications which is 493 dedicated to AppleTalk management might choose to alleviate some of 494 these failures by directly implementing the router portion of NBP. 495 For example, such an entity might already know all the zones on the 496 AppleTalk internet and the networks on which each zone appears. 497 Given an NBP lookup which fails, the entity could send an NBP FwdReq 498 to the network in which the SNMP entity supporting the command 499 responder or notification originator application was last located. 500 If that failed, the station could then send an NBP LkUp (NBP lookup 501 packet) as a directed (DDP) multicast to each network number on that 502 network. Of the above (single) failures, this combined approach will 503 solve the case where either the local router's BrRq-to-FwdReq 504 mechanism is broken or the remote router's FwdReq-to-LkUp mechanism 505 is broken. 507 6. SNMP over IPX 509 This is an optional transport mapping. 511 6.1. Serialization 513 Each instance of a message is serialized onto a single IPX datagram 514 [NOVELL], using the algorithm specified in Section 8. 516 6.2. Well-known Values 518 SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange 519 Protocol). 521 It is suggested that administrators configure their SNMP entities 522 supporting command responder applications to listen on IPX socket 523 36879 (900f hexadecimal). Further, it is suggested that those 524 supporting notification receiver applications be configured to listen 525 on IPX socket 36880 (9010 hexadecimal). 527 When an SNMP entity uses this transport mapping, it must be capable 528 of accepting messages that are at least 546 octets in size. 529 Implementation of larger values is encouraged whenever possible. 531 7. Proxy to SNMPv1 533 Historically, in order to support proxy to SNMPv1, as defined in 534 [RFC2576], it was deemed useful to define a transport domain, 535 rfc1157Domain, which indicates the transport mapping for SNMP 536 messages as defined in [RFC1157]. Subsequently, this transport 537 domain has proven useful in non-proxy situations. 539 8. Serialization using the Basic Encoding Rules 541 When the Basic Encoding Rules [BER] are used for serialization: 543 (1) When encoding the length field, only the definite form is used; 544 use of the indefinite form encoding is prohibited. Note that 545 when using the definite-long form, it is permissible to use more 546 than the minimum number of length octets necessary to encode the 547 length field. 549 (2) When encoding the value field, the primitive form shall be used 550 for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT 551 IDENTIFIER (either IMPLICIT or explicit). The constructed form 552 of encoding shall be used only for structured types, i.e., a 553 SEQUENCE or an IMPLICIT SEQUENCE. 555 (3) When encoding an object whose syntax is described using the BITS 556 construct, the value is encoded as an OCTET STRING, in which all 557 the named bits in (the definition of) the bitstring, commencing 558 with the first bit and proceeding to the last bit, are placed in 559 bits 8 to 1 of the first octet, followed by bits 8 to 1 of each 560 subsequent octet in turn, followed by as many bits as are needed 561 of the final subsequent octet, commencing with bit 8. Remaining 562 bits, if any, of the final octet are set to zero on generation 563 and ignored on receipt. 565 These restrictions apply to all aspects of ASN.1 encoding, including 566 the message wrappers, protocol data units, and the data objects they 567 contain. 569 8.1. Usage Example 571 As an example of applying the Basic Encoding Rules, suppose one 572 wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: 574 [5] IMPLICIT SEQUENCE { 575 request-id 1414684022, 576 non-repeaters 1, 577 max-repetitions 2, 578 variable-bindings { 579 { name sysUpTime, 580 value { unspecified NULL } }, 581 { name ipNetToMediaPhysAddress, 582 value { unspecified NULL } }, 583 { name ipNetToMediaType, 584 value { unspecified NULL } } 585 } 586 } 588 Applying the BER, this would be encoded (in hexadecimal) as: 590 [5] IMPLICIT SEQUENCE a5 82 00 39 591 INTEGER 02 04 52 54 5d 76 592 INTEGER 02 01 01 593 INTEGER 02 01 02 594 SEQUENCE (OF) 30 2b 595 SEQUENCE 30 0b 596 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 597 NULL 05 00 598 SEQUENCE 30 0d 599 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 600 NULL 05 00 601 SEQUENCE 30 0d 602 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 603 NULL 05 00 605 Note that the initial SEQUENCE is not encoded using the minimum 606 number of length octets. (The first octet of the length, 82, 607 indicates that the length of the content is encoded in the next two 608 octets.) 610 9. Notice on Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 intellectual property or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; neither does it represent that it 617 has made any effort to identify any such rights. Information on the 618 IETF's procedures with respect to rights in standards-track and 619 standards-related documentation can be found in BCP-11. Copies of 620 claims of rights made available for publication and any assurances of 621 licenses to be made available, or the result of an attempt made to 622 obtain a general license or permission for the use of such 623 proprietary rights by implementors or users of this specification can 624 be obtained from the IETF Secretariat. 626 The IETF invites any interested party to bring to its attention any 627 copyrights, patents or patent applications, or other proprietary 628 rights which may cover technology that may be required to practice 629 this standard. Please address the information to the IETF Executive 630 Director. 632 10. Acknowledgments 634 This document is the product of the SNMPv3 Working Group. Some 635 special thanks are in order to the following Working Group members: 637 Randy Bush 638 Jeffrey D. Case 639 Mike Daniele 640 Rob Frye 641 Lauren Heintz 642 Keith McCloghrie 643 Russ Mundy 644 David T. Perkins 645 Randy Presuhn 646 Aleksey Romanov 647 Juergen Schoenwaelder 648 Bert Wijnen 650 This version of the document, edited by Randy Presuhn, was initially 651 based on the work of a design team whose members were: 653 Jeffrey D. Case 654 Keith McCloghrie 655 David T. Perkins 656 Randy Presuhn 657 Juergen Schoenwaelder 659 The previous versions of this document, edited by Keith McCloghrie, 660 was the result of significant work by four major contributors: 662 Jeffrey D. Case 663 Keith McCloghrie 664 Marshall T. Rose 665 Steven Waldbusser 667 Additionally, the contributions of the SNMPv2 Working Group to the 668 previous versions are also acknowledged. In particular, a special 669 thanks is extended for the contributions of: 671 Alexander I. Alten 672 Dave Arneson 673 Uri Blumenthal 674 Doug Book 675 Kim Curran 676 Jim Galvin 677 Maria Greene 678 Iain Hanson 679 Dave Harrington 680 Nguyen Hien 681 Jeff Johnson 682 Michael Kornegay 683 Deirdre Kostick 684 David Levi 685 Daniel Mahoney 686 Bob Natale 687 Brian O'Keefe 688 Andrew Pearson 689 Dave Perkins 690 Randy Presuhn 691 Aleksey Romanov 692 Shawn Routhier 693 Jon Saperia 694 Juergen Schoenwaelder 695 Bob Stewart 696 Kaj Tesink 697 Glenn Waters 698 Bert Wijnen 700 11. Security Considerations 702 SNMPv1 by itself is not a secure environment. Even if the network 703 itself is secure (for example by using IPSec), even then, there is no 704 control as to who on the secure network is allowed to access and 705 GET/SET (read/change) the objects accessible through a command 706 responder application. 708 It is recommended that the implementors consider the security 709 features as provided by the SNMPv3 framework. Specifically, the use 710 of the User-based Security Model RFC 2574 [RFC2574] and the 711 View-based Access Control Model RFC 2575 [RFC2575] is recommended. 713 It is then a customer/user responsibility to ensure that the SNMP 714 entity giving access to a MIB is properly configured to give access 715 to the objects only to those principals (users) that have legitimate 716 rights to indeed GET or SET (change) them. 718 12. References 720 [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside 721 AppleTalk (second edition). Addison-Wesley, 1990. 723 [BER] Information processing systems - Open Systems 724 Interconnection - Specification of Basic Encoding Rules 725 for Abstract Syntax Notation One (ASN.1), International 726 Organization for Standardization. International Standard 727 8825, December 1987. 729 [IS8072] Information processing systems - Open Systems 730 Interconnection - Transport Service Definition, 731 International Organization for Standardization. 732 International Standard 8072, June 1986. 734 [IS8072A] Information processing systems - Open Systems 735 Interconnection - Transport Service Definition - Addendum 736 1: Connectionless-mode Transmission, International 737 Organization for Standardization. International Standard 738 8072/AD 1, December 1986. 740 [NOVELL] Network System Technical Interface Overview. Novell, 741 Inc, June 1989. 743 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 744 August 1980. 746 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 747 September 1981. 749 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 750 Identification of Management Information for TCP/IP-based 751 Internets", STD 16, RFC 1155, May 1990. 753 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 754 "Simple Network Management Protocol", STD 15, RFC 1157, 755 May 1990. 757 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 758 STD 16, RFC 1212, March 1991. 760 [RFC1215] Rose, M., "A Convention for Defining Traps for use with 761 the SNMP", RFC 1215, March 1991. 763 [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management 764 Information Base II", RFC 1742, January 1995. 766 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 767 "Introduction to Community-based SNMPv2", RFC 1901, 768 January 1996. 770 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 771 "Introduction to Version 3 of the Internet-standard 772 Network Management Framework", RFC 2570, April 1999. 774 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 775 Architecture for Describing SNMP Management Frameworks", 776 RFC 2571, April 1999. 778 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 779 "Message Processing and Dispatching for the Simple 780 Network Management Protocol (SNMP)", RFC 2572, April 781 1999. 783 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 784 Applications", RFC 2573, April 1999. 786 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 787 (USM) for version 3 of the Simple Network Management 788 Protocol (SNMPv3)", RFC 2574, April 1999. 790 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 791 Access Control Model (VACM) for the Simple Network 792 Management Protocol (SNMP)", RFC 2575, April 1999. 794 [RFC2576] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 795 "Coexistence between Version 1, Version 2, and Version 3 796 of the Internet-standard Network Management Framework", 797 RFC 2576, March, 2000. 799 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 800 Rose, M., and S. Waldbusser, "Structure of Management 801 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 802 1999. 804 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 805 Rose, M., and S. Waldbusser, "Textual Conventions for 806 SMIv2", STD 58, RFC 2579, April 1999. 808 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 809 Rose, M., and S. Waldbusser, "Conformance Statements for 810 SMIv2", STD 58, RFC 2580, April 1999. 812 [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 813 Waldbusser, "Transport Mappings for the Simple Network 814 Management Protocol", 815 , April 2000. 817 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 818 Waldbusser, "Protocol Operations for the Simple Network 819 Management Protocol", 820 , April 2000. 822 13. Editor's Address 824 Randy Presuhn 825 BMC Software, Inc. 826 2141 North First Street 827 San Jose, CA 95131 828 USA 830 Phone: +1 408 546-1006 831 EMail: randy_presuhn@bmc.com 833 14. Changes from RFC 1906 835 These are the changes from RFC 1906: 837 - Corrected typo in IPR statement; 839 - Updated copyright date; 841 - Updated with new editor's name and contact information; 843 - Cosmetic fixes to layout and typography; 845 - Changed title, headers and footers; 847 - Fixed typo in SnmpNBPAddress; 849 - Clarified that one of the BER SEQUENCEs in the example is 850 generated from the ASN.1 SEQUENCE OF construct; 852 - Updated acknowledgements section; 854 - Filled in the Security Considerations section; 856 - Replaced manager/agent terminology with terms from 857 architecture; 859 - Updated references section; 861 - Added MODULE-IDENTITY; 863 - Re-wrote introduction section using current boilerplate; 865 - Added recommendation for larger message size support; 867 - Added historical background on use of rfc1157Domain with 868 proxy; 870 15. Issues 872 This section is to be deleted when it is time to publish this 873 document as an RFC. The issue labels are the same as those used in 874 the on-line issues list at 875 ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html 877 1906-01 Done; title changed. 879 1906-02 Done; introduction clause replaced. 881 1906-03 883 1906-04 Done; resolution required no changes. 885 1906-05 Done; typo in SnmpNBPAddress fixed. 887 1906-06 889 1906-07 Done; use of manager/agent terminology replaced with 890 terms from architecture. 892 1906-08 Done; added recommendation for support of 1472 byte 893 messages. 895 1906-09 Done; resolution required no changes. 897 1906-10 Done; added historical background to material on proxy. 898 Note that some are unhappy with this text; a better 899 replacement would be most welcome. 901 1906-11 Done; resolution required no changes. 903 1906-12 Done; resolution required no changes. 905 1906-13 Done; resolution required no changes. 907 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 908 SEQUENCE OF. 910 1906-15 Done; security considerations text added. 912 1906-16 Done; references and acknowledgments updated. 914 1906-17 Done; IPR and copyright notices updated. 916 1906-18 Done; resolution required no changes. 918 1906-19 Done; MODULE-IDENTITY added. 920 16. Full Copyright Statement 922 Copyright (C) The Internet Society (2000). All Rights Reserved. 924 This document and translations of it may be copied and furnished to 925 others, and derivative works that comment on or otherwise explain it 926 or assist in its implementation may be prepared, copied, published 927 and distributed, in whole or in part, without restriction of any 928 kind, provided that the above copyright notice and this paragraph are 929 included on all such copies and derivative works. However, this 930 document itself may not be modified in any way, such as by removing 931 the copyright notice or references to the Internet Society or other 932 Internet organizations, except as needed for the purpose of 933 developing Internet standards in which case the procedures for 934 copyrights defined in the Internet Standards process must be 935 followed, or as required to translate it into languages other than 936 English. 938 The limited permissions granted above are perpetual and will not be 939 revoked by the Internet Society or its successors or assigns. 941 This document and the information contained herein is provided on an 942 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 943 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 944 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 945 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 946 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.