idnits 2.17.1 draft-ietf-snmpv2-tm-ds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 101 has weird spacing: '... octets cont...' == Line 118 has weird spacing: '... octets cont...' == Line 159 has weird spacing: '... octets cont...' == Line 161 has weird spacing: '...address net...' -- 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 (November 1994) is 10752 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1243 (ref. '6') (Obsoleted by RFC 1742) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Transport Mappings for SNMPv2 November 1994 3 Transport Mappings for Version 2 of the 4 Simple Network Management Protocol (SNMPv2) 6 1 November 1994 8 Jeffrey D. Case 9 SNMP Research, Inc. 10 case@snmp.com 12 Keith McCloghrie 13 Cisco Systems, Inc. 14 kzm@cisco.com 16 Marshall T. Rose 17 Dover Beach Consulting, Inc. 18 mrose@dbc.mtview.ca.us 20 Steven Waldbusser 21 Carnegie Mellon University 22 waldbusser@cmu.edu 24 26 Status of this Memo 28 This document is an Internet-Draft. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, and 30 its working groups. Note that other groups may also distribute working 31 documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet- Drafts as reference material 36 or to cite them other than as ``work in progress.'' 38 To learn the current status of any Internet-Draft, please check the 39 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 40 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 41 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 43 1. Introduction 45 A management system contains: several (potentially many) nodes, each 46 with a processing entity, termed an agent, which has access to 47 management instrumentation; at least one management station; and, a 48 management protocol, used to convey management information between the 49 agents and management stations. Operations of the protocol are carried 50 out under an administrative framework which defines authentication, 51 authorization, access control, and privacy policies. 53 Management stations execute management applications which monitor and 54 control managed elements. Managed elements are devices such as hosts, 55 routers, terminal servers, etc., which are monitored and controlled via 56 access to their management information. 58 The management protocol, version 2 of the Simple Network Management 59 Protocol [1], may be used over a variety of protocol suites. It is the 60 purpose of this document to define how the SNMPv2 maps onto an initial 61 set of transport domains. Other mappings may be defined in the future. 63 Although several mappings are defined, the mapping onto UDP is the 64 preferred mapping. As such, to provide for the greatest level of 65 interoperability, systems which choose to deploy other mappings should 66 also provide for proxy service to the UDP mapping. 68 1.1. A Note on Terminology 70 For the purpose of exposition, the original Internet-standard Network 71 Management Framework, as described in RFCs 1155, 1157, and 1212, is 72 termed the SNMP version 1 framework (SNMPv1). The current framework is 73 termed the SNMP version 2 framework (SNMPv2). 75 1.2. Change Log 77 For the 1 November version: 79 - recast RFC 1449 into an Internet-Draft, 81 - fixed typos, 83 - clarified the description of the use of rfc1157Domain as the 84 transport domain of a proxy destination party. 86 2. Definitions 88 SNMPv2-TM DEFINITIONS ::= BEGIN 90 IMPORTS 91 snmpDomains, snmpProxys 92 FROM SNMPv2-SMI 93 TEXTUAL-CONVENTION 94 FROM SNMPv2-TC; 96 -- SNMPv2 over UDP 98 snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 } 99 -- for a SnmpUDPAddress of length 6: 100 -- 101 -- octets contents encoding 102 -- 1-4 IP-address network-byte order 103 -- 5-6 UDP-port network-byte order 104 -- 105 SnmpUDPAddress ::= TEXTUAL-CONVENTION 106 DISPLAY-HINT "1d.1d.1d.1d/2d" 107 STATUS current 108 DESCRIPTION 109 "Represents a UDP address." 110 SYNTAX OCTET STRING (SIZE (6)) 112 -- SNMPv2 over OSI 114 snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 } 115 snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 } 116 -- for a SnmpOSIAddress of length m: 117 -- 118 -- octets contents encoding 119 -- 1 length of NSAP "n" as an unsigned-integer 120 -- (either 0 or from 3 to 20) 121 -- 2..(n+1) NSAP concrete binary representation 122 -- (n+2)..m TSEL string of (up to 64) octets 123 -- 124 SnmpOSIAddress ::= TEXTUAL-CONVENTION 125 DISPLAY-HINT "*1x:/1x:" 126 STATUS current 127 DESCRIPTION 128 "Represents an OSI transport-address." 129 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 131 -- SNMPv2 over DDP 133 snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 } 134 -- for a SnmpNBPAddress of length m: 135 -- 136 -- octets contents encoding 137 -- 1 length of object "n" as an unsigned integer 138 -- 2..(n+1) object string of (up to 32) octets 139 -- n+2 length of type "p" as an unsigned integer 140 -- (n+3)..(n+2+p) type string of (up to 32) octets 141 -- n+3+p length of zone "q" as an unsigned integer 142 -- (n+4+p)..m zone string of (up to 32) octets 143 -- 144 -- for comparison purposes, strings are case-insensitive 145 -- 146 -- all strings may contain any octet other than 255 (hex ff) 147 -- 148 SnmpNBPAddress ::= TEXTUAL-CONVENTION 149 STATUS current 150 DESCRIPTION 151 "Represents an NBP name." 152 SYNTAX OCTET STRING (SIZE (3..99)) 154 -- SNMPv2 over IPX 156 snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 } 157 -- for a SnmpIPXAddress of length 12: 158 -- 159 -- octets contents encoding 160 -- 1-4 network-number network-byte order 161 -- 5-10 physical-address network-byte order 162 -- 11-12 socket-number network-byte order 163 -- 164 SnmpIPXAddress ::= TEXTUAL-CONVENTION 165 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 166 STATUS current 167 DESCRIPTION 168 "Represents an IPX address." 169 SYNTAX OCTET STRING (SIZE (12)) 171 -- for proxy to community-based SNMPv1 (RFC 1157) 173 rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } 175 -- uses SnmpUDPAddress 176 rfc1157Domain OBJECT IDENTIFIER ::= { rfc1157Proxy 1 } 178 -- the community-based noAuth 179 rfc1157noAuth OBJECT IDENTIFIER ::= { rfc1157Proxy 2 } 181 END 182 3. SNMPv2 over UDP 184 This is the preferred transport mapping. 186 3.1. Serialization 188 Each instance of a message is serialized (i.e., encoded according to the 189 convention of [1]) onto a single UDP[2] datagram, using the algorithm 190 specified in Section 8. 192 3.2. Well-known Values 194 Although the partyTable gives transport addressing information for an 195 SNMPv2 party, it is suggested that administrators configure their SNMPv2 196 entities acting in an agent role to listen on UDP port 161. Further, it 197 is suggested that notification sinks be configured to listen on UDP port 198 162. 200 The partyTable also lists the maximum message size which a SNMPv2 party 201 is willing to accept. This value must be at least 484 octets. 202 Implementation of larger values is encouraged whenever possible. 204 4. SNMPv2 over OSI 206 This is an optional transport mapping. 208 4.1. Serialization 210 Each instance of a message is serialized onto a single TSDU [3,4] for 211 the OSI Connectionless-mode Transport Service (CLTS), using the 212 algorithm specified in Section 8. 214 4.2. Well-known Values 216 Although the partyTable gives transport addressing information for an 217 SNMPv2 party, it is suggested that administrators configure their SNMPv2 218 entities acting in an agent role to listen on transport selector "snmp- 219 l" (which consists of six ASCII characters), when using a CL-mode 220 network service to realize the CLTS. Further, it is suggested that 221 notification sinks be configured to listen on transport selector 222 "snmpt-l" (which consists of seven ASCII characters, six letters and a 223 hyphen) when using a CL-mode network service to realize the CLTS. 224 Similarly, when using a CO-mode network service to realize the CLTS, the 225 suggested transport selectors are "snmp-o" and "snmpt-o", for agent and 226 notification sink, respectively. 228 The partyTable also lists the maximum message size which a SNMPv2 party 229 is willing to accept. This value must be at least 484 octets. 230 Implementation of larger values is encouraged whenever possible. 232 5. SNMPv2 over DDP 234 This is an optional transport mapping. 236 5.1. Serialization 238 Each instance of a message is serialized onto a single DDP datagram [5], 239 using the algorithm specified in Section 8. 241 5.2. Well-known Values 243 SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities 244 acting in an agent role listens on DDP socket number 8, whilst 245 notification sinks listen on DDP socket number 9. 247 Although the partyTable gives transport addressing information for an 248 SNMPv2 party, administrators must configure their SNMPv2 entities acting 249 in an agent role to use NBP type "SNMP Agent" (which consists of ten 250 ASCII characters), whilst notification sinks must be configured to use 251 NBP type "SNMP Trap Handler" (which consists of seventeen ASCII 252 characters). 254 The NBP name for agents and notification sinks should be stable - NBP 255 names should not change any more often than the IP address of a typical 256 TCP/IP node. It is suggested that the NBP name be stored in some form 257 of stable storage. 259 The partyTable also lists the maximum message size which a SNMPv2 party 260 is willing to accept. This value must be at least 484 octets. 261 Implementation of larger values is encouraged whenever possible. 263 5.3. Discussion of AppleTalk Addressing 265 The AppleTalk protocol suite has certain features not manifest in the 266 TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of 267 address assignment can cause problems for SNMPv2 entities that wish to 268 manage AppleTalk networks. TCP/IP nodes have an associated IP address 269 which distinguishes each from the other. In contrast, AppleTalk nodes 270 generally have no such characteristic. The network-level address, while 271 often relatively stable, can change at every reboot (or more 272 frequently). 274 Thus, when SNMPv2 is mapped over DDP, nodes are identified by a "name", 275 rather than by an "address". Hence, all AppleTalk nodes that implement 276 this mapping are required to respond to NBP lookups and confirms (e.g., 277 implement the NBP protocol stub), which guarantees that a mapping from 278 NBP name to DDP address will be possible. 280 In determining the SNMP identity to register for an SNMPv2 entity, it is 281 suggested that the SNMP identity be a name which is associated with 282 other network services offered by the machine. 284 NBP lookups, which are used to map NBP names into DDP addresses, can 285 cause large amounts of network traffic as well as consume CPU resources. 286 It is also the case that the ability to perform an NBP lookup is 287 sensitive to certain network disruptions (such as zone table 288 inconsistencies) which would not prevent direct AppleTalk communications 289 between two SNMPv2 entities. 291 Thus, it is recommended that NBP lookups be used infrequently, primarily 292 to create a cache of name-to-address mappings. These cached mappings 293 should then be used for any further SNMP traffic. It is recommended 294 that SNMPv2 entities acting in a manager role should maintain this cache 295 between reboots. This caching can help minimize network traffic, reduce 296 CPU load on the network, and allow for (some amount of) network trouble 297 shooting when the basic name-to-address translation mechanism is broken. 299 5.3.1. How to Acquire NBP names 301 An SNMPv2 entity acting in a manager role may have a pre-configured list 302 of names of "known" SNMPv2 entities acting in an agent role. Similarly, 303 an SNMPv2 entity acting in a manager role might interact with an 304 operator. Finally, an SNMPv2 entity acting in a manager role might 305 communicate with all SNMPv2 entities acting in an agent role in a set of 306 zones or networks. 308 5.3.2. When to Turn NBP names into DDP addresses 310 When an SNMPv2 entity uses a cache entry to address an SNMP packet, it 311 should attempt to confirm the validity mapping, if the mapping hasn't 312 been confirmed within the last T1 seconds. This cache entry lifetime, 313 T1, has a minimum, default value of 60 seconds, and should be 314 configurable. 316 An SNMPv2 entity acting in a manager role may decide to prime its cache 317 of names prior to actually communicating with another SNMPv2 entity. In 318 general, it is expected that such an entity may want to keep certain 319 mappings "more current" than other mappings, e.g., those nodes which 320 represent the network infrastructure (e.g., routers) may be deemed "more 321 important". 323 Note that an SNMPv2 entity acting in a manager role should not prime its 324 entire cache upon initialization - rather, it should attempt resolutions 325 over an extended period of time (perhaps in some pre-determined or 326 configured priority order). Each of these resolutions might, in fact, 327 be a wildcard lookup in a given zone. 329 An SNMPv2 entity acting in an agent role must never prime its cache. 330 Such an entity should do NBP lookups (or confirms) only when it needs to 331 send an SNMP trap. When generating a response, such an entity does not 332 need to confirm a cache entry. 334 5.3.3. How to Turn NBP names into DDP addresses 336 If the only piece of information available is the NBP name, then an NBP 337 lookup should be performed to turn that name into a DDP address. 338 However, if there is a piece of stale information, it can be used as a 339 hint to perform an NBP confirm (which sends a unicast to the network 340 address which is presumed to be the target of the name lookup) to see if 341 the stale information is, in fact, still valid. 343 An NBP name to DDP address mapping can also be confirmed implicitly 344 using only SNMP transactions. For example, an SNMPv2 entity acting in a 345 manager role issuing a retrieval operation could also retrieve the 346 relevant objects from the NBP group [6] for the SNMPv2 entity acting in 347 an agent role. This information can then be correlated with the source 348 DDP address of the response. 350 5.3.4. What if NBP is broken 352 Under some circumstances, there may be connectivity between two SNMPv2 353 entities, but the NBP mapping machinery may be broken, e.g., 355 o the NBP FwdReq (forward NBP lookup onto local attached network) 356 mechanism might be broken at a router on the other entity's 357 network; or, 359 o the NBP BrRq (NBP broadcast request) mechanism might be broken at a 360 router on the entity's own network; or, 362 o NBP might be broken on the other entity's node. 364 An SNMPv2 entity acting in a manager role which is dedicated to 365 AppleTalk management might choose to alleviate some of these failures by 366 directly implementing the router portion of NBP. For example, such an 367 entity might already know all the zones on the AppleTalk internet and 368 the networks on which each zone appears. Given an NBP lookup which 369 fails, the entity could send an NBP FwdReq to the network in which the 370 agent was last located. If that failed, the station could then send an 371 NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each 372 network number on that network. Of the above (single) failures, this 373 combined approach will solve the case where either the local router's 374 BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp 375 mechanism is broken. 377 6. SNMPv2 over IPX 379 This is an optional transport mapping. 381 6.1. Serialization 383 Each instance of a message is serialized onto a single IPX datagram [7], 384 using the algorithm specified in Section 8. 386 6.2. Well-known Values 388 SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange 389 Protocol). 391 Although the partyTable gives transport addressing information for an 392 SNMPv2 party, it is suggested that administrators configure their SNMPv2 393 entities acting in an agent role to listen on IPX socket 36879 (900f 394 hexadecimal). Further, it is suggested that notification sinks be 395 configured to listen on IPX socket 36880 (9010 hexadecimal) 397 The partyTable also lists the maximum message size which a SNMPv2 party 398 is willing to accept. This value must be at least 546 octets. 399 Implementation of larger values is encouraged whenever possible. 401 7. Proxy to SNMPv1 403 In order to provide proxy to community-based SNMP [8], some definitions 404 are necessary for both transport domains and authentication protocols. 406 7.1. Transport Domain: rfc1157Domain 408 The transport domain, rfc1157Domain, indicates the transport mapping for 409 community-based SNMP messages defined in RFC 1157. When a party's 410 transport domain (partyTDomain) is rfc1157Domain: 412 (1) the party's transport address (partyTAddress) shall be 6 octets 413 long, the initial 4 octets containing the IP-address in network- 414 byte order, and the last two octets containing the UDP port in 415 network-byte order; and, 417 (2) the party's authentication protocol (partyAuthProtocol) shall be 418 rfc1157noAuth. 420 When a proxy context specifies a proxy destination party which has 421 rfc1157Domain as its transport domain: 423 (1) the proxy source party (contextSrcPartyIndex) and proxied context 424 (contextProxyContext) components of the proxy context are 425 irrelevant; and, 427 (2) Section 3.1 of [9] specifies the behavior of the proxy agent. 429 7.2. Authentication Algorithm: rfc1157noAuth 431 A party's authentication protocol (partyAuthProtocol) specifies the 432 protocol and mechanism by which the party authenticates the integrity 433 and origin of the SNMPv1 or SNMPv2 PDUs it generates. When a party's 434 authentication protocol is rfc1157noAuth: 436 (1) the party's public authentication key (partyAuthPublic), clock 437 (partyAuthClock), and lifetime (partyAuthLifetime) are irrelevant; 438 and, 440 (2) the party's private authentication key (partyAuthPrivate) shall be 441 used as the 1157 community for the proxy destination, and shall be 442 at least one octet in length. (No maximum length is specified.) 444 Note that when setting the party's private authentication key, the 445 exclusive-OR semantics specified in [10] still apply. 447 8. Serialization using the Basic Encoding Rules 449 When the Basic Encoding Rules [11] are used for serialization: 451 (1) When encoding the length field, only the definite form is used; use 452 of the indefinite form encoding is prohibited. Note that when 453 using the definite-long form, it is permissible to use more than 454 the minimum number of length octets necessary to encode the length 455 field. 457 (2) When encoding the value field, the primitive form shall be used for 458 all simple types, i.e., INTEGER, OCTET STRING, OBJECT IDENTIFIER, 459 and BIT STRING (either IMPLICIT or explicit). The constructed form 460 of encoding shall be used only for structured types, i.e., a 461 SEQUENCE or an IMPLICIT SEQUENCE. 463 (3) When a BIT STRING is serialized, all named-bits are transferred 464 regardless of their truth-value. Further, if the number of named- 465 bits is not an integral multiple of eight, then the fewest number 466 of additional zero-valued bits are transferred so that an integral 467 multiple of eight bits is transferred. 469 These restrictions apply to all aspects of ASN.1 encoding, including the 470 message wrappers, protocol data units, and the data objects they 471 contain. 473 8.1. Usage Example 475 As an example of applying the Basic Encoding Rules, suppose one wanted 476 to encode an instance of the GetBulkRequest-PDU [1]: 478 [5] IMPLICIT SEQUENCE { 479 request-id 1414684022, 480 non-repeaters 1, 481 max-repetitions 2, 482 variable-bindings { 483 { name sysUpTime, 484 value { unspecified NULL } }, 485 { name ipNetToMediaPhysAddress, 486 value { unspecified NULL } }, 487 { name ipNetToMediaType, 488 value { unspecified NULL } } 489 } 490 } 492 Applying the BER, this would be encoded (in hexadecimal) as: 494 [5] IMPLICIT SEQUENCE a5 82 00 39 495 INTEGER 02 04 52 54 5d 76 496 INTEGER 02 01 01 497 INTEGER 02 01 02 498 SEQUENCE 30 2b 499 SEQUENCE 30 0b 500 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 501 NULL 05 00 502 SEQUENCE 30 0d 503 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 504 NULL 05 00 505 SEQUENCE 30 0d 506 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 507 NULL 05 00 509 Note that the initial SEQUENCE is not encoded using the minimum number 510 of length octets. (The first octet of the length, 82, indicates that 511 the length of the content is encoded in the next two octets.) 512 9. Acknowledgements 514 This document is a modified version of RFC 1449. 516 10. References 518 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 519 Operations for Version 2 of the Simple Network Management Protocol 520 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 521 Dover Beach Consulting, Inc., Carnegie Mellon University, November 522 1994. 524 [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 525 USC/Information Sciences Institute, August 1980. 527 [3] Information processing systems - Open Systems Interconnection - 528 Transport Service Definition, International Organization for 529 Standardization. International Standard 8072, (June, 1986). 531 [4] Information processing systems - Open Systems Interconnection - 532 Transport Service Definition - Addendum 1: Connectionless-mode 533 Transmission, International Organization for Standardization. 534 International Standard 8072/AD 1, (December, 1986). 536 [5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second 537 edition). Addison-Wesley, 1990. 539 [6] Waldbusser, S., "AppleTalk Management Information Base", RFC 1243, 540 Carnegie Mellon University, July 1991. 542 [7] Network System Technical Interface Overview. Novell, Inc, (June, 543 1989). 545 [8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network 546 Management Protocol", STD 15, RFC 1157, SNMP Research, Performance 547 Systems International, MIT Laboratory for Computer Science, May 548 1990. 550 [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 551 "Coexistence between Version 1 and Version 2 of the Internet- 552 standard Network Management Framework", Internet Draft, SNMP 553 Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., 554 Carnegie Mellon University, November 1994. 556 [10] McCloghrie, K., and Galvin, J., "Party MIB for Version 2 of the 557 Simple Network Management Protocol (SNMPv2)", Internet Draft, Cisco 558 Systems, Trusted Information Systems, November 1994. 560 [11] Information processing systems - Open Systems Interconnection - 561 Specification of Basic Encoding Rules for Abstract Syntax Notation 562 One (ASN.1), International Organization for Standardization. 563 International Standard 8825, (December, 1987). 565 11. Security Considerations 567 Security issues are not discussed in this memo. 569 12. Authors' Addresses 571 Jeffrey D. Case 572 SNMP Research, Inc. 573 3001 Kimberlin Heights Rd. 574 Knoxville, TN 37920-9716 575 US 577 Phone: +1 615 573 1434 578 Email: case@snmp.com 580 Keith McCloghrie 581 Cisco Systems, Inc. 582 170 West Tasman Drive, 583 San Jose CA 95134-1706. 585 Phone: +1 408 526 5260 586 Email: kzm@cisco.com 588 Marshall T. Rose 589 Dover Beach Consulting, Inc. 590 420 Whisman Court 591 Mountain View, CA 94043-2186 592 US 594 Phone: +1 415 968 1052 595 Email: mrose@dbc.mtview.ca.us 597 Steven Waldbusser 598 Carnegie Mellon University 599 5000 Forbes Ave 600 Pittsburgh, PA 15213 601 US 603 Phone: +1 412 268 6628 604 Email: waldbusser@cmu.edu 606 Table of Contents 608 1 Introduction .................................................... 2 609 1.1 A Note on Terminology ......................................... 2 610 1.2 Change Log .................................................... 2 611 2 Definitions ..................................................... 3 612 3 SNMPv2 over UDP ................................................. 7 613 3.1 Serialization ................................................. 7 614 3.2 Well-known Values ............................................. 7 615 4 SNMPv2 over OSI ................................................. 8 616 4.1 Serialization ................................................. 8 617 4.2 Well-known Values ............................................. 8 618 5 SNMPv2 over DDP ................................................. 9 619 5.1 Serialization ................................................. 9 620 5.2 Well-known Values ............................................. 9 621 5.3 Discussion of AppleTalk Addressing ............................ 9 622 5.3.1 How to Acquire NBP names .................................... 10 623 5.3.2 When to Turn NBP names into DDP addresses ................... 10 624 5.3.3 How to Turn NBP names into DDP addresses .................... 11 625 5.3.4 What if NBP is broken ....................................... 11 626 6 SNMPv2 over IPX ................................................. 13 627 6.1 Serialization ................................................. 13 628 6.2 Well-known Values ............................................. 13 629 7 Proxy to SNMPv1 ................................................. 14 630 7.1 Transport Domain: rfc1157Domain ............................... 14 631 7.2 Authentication Algorithm: rfc1157noAuth ....................... 14 632 8 Serialization using the Basic Encoding Rules .................... 16 633 8.1 Usage Example ................................................. 17 634 9 Acknowledgements ................................................ 18 635 10 References ..................................................... 18 636 11 Security Considerations ........................................ 20 637 12 Authors' Addresses ............................................. 20