summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3417.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3417.txt')
-rw-r--r--doc/rfc/rfc3417.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc3417.txt b/doc/rfc/rfc3417.txt
new file mode 100644
index 0000000..ba4c529
--- /dev/null
+++ b/doc/rfc/rfc3417.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group Editor of this version:
+Request for Comments: 3417 R. Presuhn
+STD: 62 BMC Software, Inc.
+Obsoletes: 1906 Authors of previous version:
+Category: Standards Track J. Case
+ SNMP Research, Inc.
+ K. McCloghrie
+ Cisco Systems, Inc.
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ International Network Services
+ December 2002
+
+
+ Transport Mappings for
+ the Simple Network Management Protocol (SNMP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document defines the transport of Simple Network Management
+ Protocol (SNMP) messages over various protocols. This document
+ obsoletes RFC 1906.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 1]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. Definitions ................................................. 3
+ 3. SNMP over UDP over IPv4 ..................................... 7
+ 3.1. Serialization ............................................. 7
+ 3.2. Well-known Values ......................................... 7
+ 4. SNMP over OSI ............................................... 7
+ 4.1. Serialization ............................................. 7
+ 4.2. Well-known Values ......................................... 8
+ 5. SNMP over DDP ............................................... 8
+ 5.1. Serialization ............................................. 8
+ 5.2. Well-known Values ......................................... 8
+ 5.3. Discussion of AppleTalk Addressing ........................ 9
+ 5.3.1. How to Acquire NBP names ................................ 9
+ 5.3.2. When to Turn NBP names into DDP addresses ............... 10
+ 5.3.3. How to Turn NBP names into DDP addresses ................ 10
+ 5.3.4. What if NBP is broken ................................... 10
+ 6. SNMP over IPX ............................................... 11
+ 6.1. Serialization ............................................. 11
+ 6.2. Well-known Values ......................................... 11
+ 7. Proxy to SNMPv1 ............................................. 12
+ 8. Serialization using the Basic Encoding Rules ................ 12
+ 8.1. Usage Example ............................................. 13
+ 9. Notice on Intellectual Property ............................. 14
+ 10. Acknowledgments ............................................ 14
+ 11. IANA Considerations ........................................ 15
+ 12. Security Considerations .................................... 16
+ 13. References ................................................. 16
+ 13.1. Normative References ..................................... 16
+ 13.2. Informative References ................................... 17
+ 14. Changes from RFC 1906 ...................................... 18
+ 15. Editor's Address ........................................... 18
+ 16. Full Copyright Statement ................................... 19
+
+1. Introduction
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. MIB objects are generally
+ accessed through the Simple Network Management Protocol (SNMP).
+ Objects in the MIB are defined using the mechanisms defined in the
+ Structure of Management Information (SMI). This memo specifies a MIB
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 2]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ module that is compliant to the SMIv2, which is described in STD 58,
+ RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+ [RFC2580].
+
+ This document, Transport Mappings for the Simple Network Management
+ Protocol, defines how the management protocol [RFC3416] may be
+ carried over a variety of protocol suites. It is the purpose of this
+ document to define how the SNMP maps onto an initial set of transport
+ domains. At the time of this writing, work was in progress to define
+ an IPv6 mapping, described in [RFC3419]. Other mappings may be
+ defined in the future.
+
+ Although several mappings are defined, the mapping onto UDP over IPv4
+ is the preferred mapping for systems supporting IPv4. Systems
+ implementing IPv4 MUST implement the mapping onto UDP over IPv4. To
+ maximize interoperability, systems supporting other mappings SHOULD
+ also provide for access via the UDP over IPv4 mapping.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. Definitions
+
+ SNMPv2-TM DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-IDENTITY,
+ snmpModules, snmpDomains, snmpProxys
+ FROM SNMPv2-SMI
+ TEXTUAL-CONVENTION
+ FROM SNMPv2-TC;
+
+ snmpv2tm MODULE-IDENTITY
+ LAST-UPDATED "200210160000Z"
+ ORGANIZATION "IETF SNMPv3 Working Group"
+ CONTACT-INFO
+ "WG-EMail: snmpv3@lists.tislabs.com
+ Subscribe: snmpv3-request@lists.tislabs.com
+
+ Co-Chair: Russ Mundy
+ Network Associates Laboratories
+ postal: 15204 Omega Drive, Suite 300
+ Rockville, MD 20850-4601
+ USA
+ EMail: mundy@tislabs.com
+ phone: +1 301 947-7107
+
+
+
+Presuhn, et al. Standards Track [Page 3]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ Co-Chair: David Harrington
+ Enterasys Networks
+ postal: 35 Industrial Way
+ P. O. Box 5005
+ Rochester, NH 03866-5005
+ USA
+ EMail: dbh@enterasys.com
+ phone: +1 603 337-2614
+
+ Editor: Randy Presuhn
+ BMC Software, Inc.
+ postal: 2141 North First Street
+ San Jose, CA 95131
+ USA
+ EMail: randy_presuhn@bmc.com
+ phone: +1 408 546-1006"
+ DESCRIPTION
+ "The MIB module for SNMP transport mappings.
+
+ Copyright (C) The Internet Society (2002). This
+ version of this MIB module is part of RFC 3417;
+ see the RFC itself for full legal notices.
+ "
+ REVISION "200210160000Z"
+ DESCRIPTION
+ "Clarifications, published as RFC 3417."
+ REVISION "199601010000Z"
+ DESCRIPTION
+ "Clarifications, published as RFC 1906."
+ REVISION "199304010000Z"
+ DESCRIPTION
+ "The initial version, published as RFC 1449."
+ ::= { snmpModules 19 }
+
+ -- SNMP over UDP over IPv4
+
+ snmpUDPDomain OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The SNMP over UDP over IPv4 transport domain.
+ The corresponding transport address is of type
+ SnmpUDPAddress."
+ ::= { snmpDomains 1 }
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 4]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ SnmpUDPAddress ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "1d.1d.1d.1d/2d"
+ STATUS current
+ DESCRIPTION
+ "Represents a UDP over IPv4 address:
+
+ octets contents encoding
+ 1-4 IP-address network-byte order
+ 5-6 UDP-port network-byte order
+ "
+ SYNTAX OCTET STRING (SIZE (6))
+
+ -- SNMP over OSI
+
+ snmpCLNSDomain OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The SNMP over CLNS transport domain.
+ The corresponding transport address is of type
+ SnmpOSIAddress."
+ ::= { snmpDomains 2 }
+
+ snmpCONSDomain OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The SNMP over CONS transport domain.
+ The corresponding transport address is of type
+ SnmpOSIAddress."
+ ::= { snmpDomains 3 }
+
+ SnmpOSIAddress ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "*1x:/1x:"
+ STATUS current
+ DESCRIPTION
+ "Represents an OSI transport-address:
+
+ octets contents encoding
+ 1 length of NSAP 'n' as an unsigned-integer
+ (either 0 or from 3 to 20)
+ 2..(n+1) NSAP concrete binary representation
+ (n+2)..m TSEL string of (up to 64) octets
+ "
+ SYNTAX OCTET STRING (SIZE (1 | 4..85))
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 5]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ -- SNMP over DDP
+
+ snmpDDPDomain OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The SNMP over DDP transport domain. The corresponding
+ transport address is of type SnmpNBPAddress."
+ ::= { snmpDomains 4 }
+
+ SnmpNBPAddress ::= TEXTUAL-CONVENTION
+ STATUS current
+ DESCRIPTION
+ "Represents an NBP name:
+
+ octets contents encoding
+ 1 length of object 'n' as an unsigned integer
+ 2..(n+1) object string of (up to 32) octets
+ n+2 length of type 'p' as an unsigned integer
+ (n+3)..(n+2+p) type string of (up to 32) octets
+ n+3+p length of zone 'q' as an unsigned integer
+ (n+4+p)..(n+3+p+q) zone string of (up to 32) octets
+
+ For comparison purposes, strings are
+ case-insensitive. All strings may contain any octet
+ other than 255 (hex ff)."
+ SYNTAX OCTET STRING (SIZE (3..99))
+
+ -- SNMP over IPX
+
+ snmpIPXDomain OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The SNMP over IPX transport domain. The corresponding
+ transport address is of type SnmpIPXAddress."
+ ::= { snmpDomains 5 }
+
+ SnmpIPXAddress ::= TEXTUAL-CONVENTION
+ DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
+ STATUS current
+ DESCRIPTION
+ "Represents an IPX address:
+
+ octets contents encoding
+ 1-4 network-number network-byte order
+ 5-10 physical-address network-byte order
+ 11-12 socket-number network-byte order
+ "
+ SYNTAX OCTET STRING (SIZE (12))
+
+
+
+Presuhn, et al. Standards Track [Page 6]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ -- for proxy to SNMPv1 (RFC 1157)
+
+ rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
+
+ rfc1157Domain OBJECT-IDENTITY
+ STATUS deprecated
+ DESCRIPTION
+ "The transport domain for SNMPv1 over UDP over IPv4.
+ The corresponding transport address is of type
+ SnmpUDPAddress."
+ ::= { rfc1157Proxy 1 }
+
+ -- ::= { rfc1157Proxy 2 } this OID is obsolete
+
+ END
+
+3. SNMP over UDP over IPv4
+
+ This is the preferred transport mapping.
+
+3.1. Serialization
+
+ Each instance of a message is serialized (i.e., encoded according to
+ the convention of [BER]) onto a single UDP [RFC768] over IPv4
+ [RFC791] datagram, using the algorithm specified in Section 8.
+
+3.2. Well-known Values
+
+ It is suggested that administrators configure their SNMP entities
+ supporting command responder applications to listen on UDP port 161.
+ Further, it is suggested that SNMP entities supporting notification
+ receiver applications be configured to listen on UDP port 162.
+
+ When an SNMP entity uses this transport mapping, it must be capable
+ of accepting messages up to and including 484 octets in size. It is
+ recommended that implementations be capable of accepting messages of
+ up to 1472 octets in size. Implementation of larger values is
+ encouraged whenever possible.
+
+4. SNMP over OSI
+
+ This is an optional transport mapping.
+
+4.1. Serialization
+
+ Each instance of a message is serialized onto a single TSDU [IS8072]
+ [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS),
+ using the algorithm specified in Section 8.
+
+
+
+Presuhn, et al. Standards Track [Page 7]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+4.2. Well-known Values
+
+ It is suggested that administrators configure their SNMP entities
+ supporting command responder applications to listen on transport
+ selector "snmp-l" (which consists of six ASCII characters), when
+ using a CL-mode network service to realize the CLTS. Further, it is
+ suggested that SNMP entities supporting notification receiver
+ applications be configured to listen on transport selector "snmpt-l"
+ (which consists of seven ASCII characters, six letters and a hyphen)
+ when using a CL-mode network service to realize the CLTS. Similarly,
+ when using a CO-mode network service to realize the CLTS, the
+ suggested transport selectors are "snmp-o" and "snmpt-o", for command
+ responders and notification receivers, respectively.
+
+ When an SNMP entity uses this transport mapping, it must be capable
+ of accepting messages that are at least 484 octets in size.
+ Implementation of larger values is encouraged whenever possible.
+
+5. SNMP over DDP
+
+ This is an optional transport mapping.
+
+5.1. Serialization
+
+ Each instance of a message is serialized onto a single DDP datagram
+ [APPLETALK], using the algorithm specified in Section 8.
+
+5.2. Well-known Values
+
+ SNMP messages are sent using DDP protocol type 8. SNMP entities
+ supporting command responder applications listen on DDP socket number
+ 8, while SNMP entities supporting notification receiver applications
+ listen on DDP socket number 9.
+
+ Administrators must configure their SNMP entities supporting command
+ responder applications to use NBP type "SNMP Agent" (which consists
+ of ten ASCII characters) while those supporting notification receiver
+ applications must be configured to use NBP type "SNMP Trap Handler"
+ (which consists of seventeen ASCII characters).
+
+ The NBP name for SNMP entities supporting command responders and
+ notification receivers should be stable - NBP names should not change
+ any more often than the IP address of a typical TCP/IP node. It is
+ suggested that the NBP name be stored in some form of stable storage.
+
+ When an SNMP entity uses this transport mapping, it must be capable
+ of accepting messages that are at least 484 octets in size.
+ Implementation of larger values is encouraged whenever possible.
+
+
+
+Presuhn, et al. Standards Track [Page 8]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+5.3. Discussion of AppleTalk Addressing
+
+ The AppleTalk protocol suite has certain features not manifest in the
+ TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
+ address assignment can cause problems for SNMP entities that wish to
+ manage AppleTalk networks. TCP/IP nodes have an associated IP
+ address which distinguishes each from the other. In contrast,
+ AppleTalk nodes generally have no such characteristic. The network-
+ level address, while often relatively stable, can change at every
+ reboot (or more frequently).
+
+ Thus, when SNMP is mapped over DDP, nodes are identified by a "name",
+ rather than by an "address". Hence, all AppleTalk nodes that
+ implement this mapping are required to respond to NBP lookups and
+ confirms (e.g., implement the NBP protocol stub), which guarantees
+ that a mapping from NBP name to DDP address will be possible.
+
+ In determining the SNMP identity to register for an SNMP entity, it
+ is suggested that the SNMP identity be a name which is associated
+ with other network services offered by the machine.
+
+ NBP lookups, which are used to map NBP names into DDP addresses, can
+ cause large amounts of network traffic as well as consume CPU
+ resources. It is also the case that the ability to perform an NBP
+ lookup is sensitive to certain network disruptions (such as zone
+ table inconsistencies) which would not prevent direct AppleTalk
+ communications between two SNMP entities.
+
+ Thus, it is recommended that NBP lookups be used infrequently,
+ primarily to create a cache of name-to-address mappings. These
+ cached mappings should then be used for any further SNMP traffic. It
+ is recommended that SNMP entities supporting command generator
+ applications should maintain this cache between reboots. This
+ caching can help minimize network traffic, reduce CPU load on the
+ network, and allow for (some amount of) network trouble shooting when
+ the basic name-to-address translation mechanism is broken.
+
+5.3.1. How to Acquire NBP names
+
+ An SNMP entity supporting command generator applications may have a
+ pre-configured list of names of "known" SNMP entities supporting
+ command responder applications. Similarly, an SNMP entity supporting
+ command generator or notification receiver applications might
+ interact with an operator. Finally, an SNMP entity supporting
+ command generator or notification receiver applications might
+ communicate with all SNMP entities supporting command responder or
+ notification originator applications in a set of zones or networks.
+
+
+
+
+Presuhn, et al. Standards Track [Page 9]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+5.3.2. When to Turn NBP names into DDP addresses
+
+ When an SNMP entity uses a cache entry to address an SNMP packet, it
+ should attempt to confirm the validity mapping, if the mapping hasn't
+ been confirmed within the last T1 seconds. This cache entry
+ lifetime, T1, has a minimum, default value of 60 seconds, and should
+ be configurable.
+
+ An SNMP entity supporting a command generator application may decide
+ to prime its cache of names prior to actually communicating with
+ another SNMP entity. In general, it is expected that such an entity
+ may want to keep certain mappings "more current" than other mappings,
+ e.g., those nodes which represent the network infrastructure (e.g.,
+ routers) may be deemed "more important".
+
+ Note that an SNMP entity supporting command generator applications
+ should not prime its entire cache upon initialization - rather, it
+ should attempt resolutions over an extended period of time (perhaps
+ in some pre-determined or configured priority order). Each of these
+ resolutions might, in fact, be a wildcard lookup in a given zone.
+
+ An SNMP entity supporting command responder applications must never
+ prime its cache. When generating a response, such an entity does not
+ need to confirm a cache entry. An SNMP entity supporting
+ notification originator applications should do NBP lookups (or
+ confirms) only when it needs to send an SNMP trap or inform.
+
+5.3.3. How to Turn NBP names into DDP addresses
+
+ If the only piece of information available is the NBP name, then an
+ NBP lookup should be performed to turn that name into a DDP address.
+ However, if there is a piece of stale information, it can be used as
+ a hint to perform an NBP confirm (which sends a unicast to the
+ network address which is presumed to be the target of the name
+ lookup) to see if the stale information is, in fact, still valid.
+
+ An NBP name to DDP address mapping can also be confirmed implicitly
+ using only SNMP transactions. For example, an SNMP entity supporting
+ command generator applications issuing a retrieval operation could
+ also retrieve the relevant objects from the NBP group [RFC1742] for
+ the SNMP entity supporting the command responder application. This
+ information can then be correlated with the source DDP address of the
+ response.
+
+5.3.4. What if NBP is broken
+
+ Under some circumstances, there may be connectivity between two SNMP
+ entities, but the NBP mapping machinery may be broken, e.g.,
+
+
+
+Presuhn, et al. Standards Track [Page 10]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ o the NBP FwdReq (forward NBP lookup onto local attached network)
+ mechanism might be broken at a router on the other entity's
+ network; or,
+
+ o the NBP BrRq (NBP broadcast request) mechanism might be broken at
+ a router on the entity's own network; or,
+
+ o NBP might be broken on the other entity's node.
+
+ An SNMP entity supporting command generator applications which is
+ dedicated to AppleTalk management might choose to alleviate some of
+ these failures by directly implementing the router portion of NBP.
+ For example, such an entity might already know all the zones on the
+ AppleTalk internet and the networks on which each zone appears.
+ Given an NBP lookup which fails, the entity could send an NBP FwdReq
+ to the network in which the SNMP entity supporting the command
+ responder or notification originator application was last located.
+ If that failed, the station could then send an NBP LkUp (NBP lookup
+ packet) as a directed (DDP) multicast to each network number on that
+ network. Of the above (single) failures, this combined approach will
+ solve the case where either the local router's BrRq-to-FwdReq
+ mechanism is broken or the remote router's FwdReq-to-LkUp mechanism
+ is broken.
+
+6. SNMP over IPX
+
+ This is an optional transport mapping.
+
+6.1. Serialization
+
+ Each instance of a message is serialized onto a single IPX datagram
+ [NOVELL], using the algorithm specified in Section 8.
+
+6.2. Well-known Values
+
+ SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange
+ Protocol).
+
+ It is suggested that administrators configure their SNMP entities
+ supporting command responder applications to listen on IPX socket
+ 36879 (900f hexadecimal). Further, it is suggested that those
+ supporting notification receiver applications be configured to listen
+ on IPX socket 36880 (9010 hexadecimal).
+
+ When an SNMP entity uses this transport mapping, it must be capable
+ of accepting messages that are at least 546 octets in size.
+ Implementation of larger values is encouraged whenever possible.
+
+
+
+
+Presuhn, et al. Standards Track [Page 11]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+7. Proxy to SNMPv1
+
+ Historically, in order to support proxy to SNMPv1, as defined in
+ [RFC2576], it was deemed useful to define a transport domain,
+ rfc1157Domain, which indicates the transport mapping for SNMP
+ messages as defined in [RFC1157].
+
+8. Serialization using the Basic Encoding Rules
+
+ When the Basic Encoding Rules [BER] are used for serialization:
+
+ (1) When encoding the length field, only the definite form is used;
+ use of the indefinite form encoding is prohibited. Note that
+ when using the definite-long form, it is permissible to use
+ more than the minimum number of length octets necessary to
+ encode the length field.
+
+ (2) When encoding the value field, the primitive form shall be used
+ for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
+ IDENTIFIER (either IMPLICIT or explicit). The constructed form
+ of encoding shall be used only for structured types, i.e., a
+ SEQUENCE or an IMPLICIT SEQUENCE.
+
+ (3) When encoding an object whose syntax is described using the
+ BITS construct, the value is encoded as an OCTET STRING, in
+ which all the named bits in (the definition of) the bitstring,
+ commencing with the first bit and proceeding to the last bit,
+ are placed in bits 8 (high order bit) to 1 (low order bit) of
+ the first octet, followed by bits 8 to 1 of each subsequent
+ octet in turn, followed by as many bits as are needed of the
+ final subsequent octet, commencing with bit 8. Remaining bits,
+ if any, of the final octet are set to zero on generation and
+ ignored on receipt.
+
+ These restrictions apply to all aspects of ASN.1 encoding, including
+ the message wrappers, protocol data units, and the data objects they
+ contain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 12]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+8.1. Usage Example
+
+ As an example of applying the Basic Encoding Rules, suppose one
+ wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]:
+
+ [5] IMPLICIT SEQUENCE {
+ request-id 1414684022,
+ non-repeaters 1,
+ max-repetitions 2,
+ variable-bindings {
+ { name sysUpTime,
+ value { unSpecified NULL } },
+ { name ipNetToMediaPhysAddress,
+ value { unSpecified NULL } },
+ { name ipNetToMediaType,
+ value { unSpecified NULL } }
+ }
+ }
+
+ Applying the BER, this may be encoded (in hexadecimal) as:
+
+ [5] IMPLICIT SEQUENCE a5 82 00 39
+ INTEGER 02 04 54 52 5d 76
+ INTEGER 02 01 01
+ INTEGER 02 01 02
+ SEQUENCE (OF) 30 2b
+ SEQUENCE 30 0b
+ OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
+ NULL 05 00
+ SEQUENCE 30 0d
+ OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
+ NULL 05 00
+ SEQUENCE 30 0d
+ OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
+ NULL 05 00
+
+ Note that the initial SEQUENCE in this example was not encoded using
+ the minimum number of length octets. (The first octet of the length,
+ 82, indicates that the length of the content is encoded in the next
+ two octets.)
+
+
+
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 13]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+9. Notice on Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+10. Acknowledgments
+
+ This document is the product of the SNMPv3 Working Group. Some
+ special thanks are in order to the following Working Group members:
+
+ Randy Bush
+ Jeffrey D. Case
+ Mike Daniele
+ Rob Frye
+ Lauren Heintz
+ Keith McCloghrie
+ Russ Mundy
+ David T. Perkins
+ Randy Presuhn
+ Aleksey Romanov
+ Juergen Schoenwaelder
+ Bert Wijnen
+
+ This version of the document, edited by Randy Presuhn, was initially
+ based on the work of a design team whose members were:
+
+ Jeffrey D. Case
+ Keith McCloghrie
+ David T. Perkins
+ Randy Presuhn
+ Juergen Schoenwaelder
+
+
+
+Presuhn, et al. Standards Track [Page 14]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ The previous versions of this document, edited by Keith McCloghrie,
+ was the result of significant work by four major contributors:
+
+ Jeffrey D. Case
+ Keith McCloghrie
+ Marshall T. Rose
+ Steven Waldbusser
+
+ Additionally, the contributions of the SNMPv2 Working Group to the
+ previous versions are also acknowledged. In particular, a special
+ thanks is extended for the contributions of:
+
+ Alexander I. Alten
+ Dave Arneson
+ Uri Blumenthal
+ Doug Book
+ Kim Curran
+ Jim Galvin
+ Maria Greene
+ Iain Hanson
+ Dave Harrington
+ Nguyen Hien
+ Jeff Johnson
+ Michael Kornegay
+ Deirdre Kostick
+ David Levi
+ Daniel Mahoney
+ Bob Natale
+ Brian O'Keefe
+ Andrew Pearson
+ Dave Perkins
+ Randy Presuhn
+ Aleksey Romanov
+ Shawn Routhier
+ Jon Saperia
+ Juergen Schoenwaelder
+ Bob Stewart
+ Kaj Tesink
+ Glenn Waters
+ Bert Wijnen
+
+11. IANA Considerations
+
+ The SNMPv2-TM MIB module requires the allocation of a single object
+ identifier for its MODULE-IDENTITY. IANA has allocated this object
+ identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB
+ module.
+
+
+
+
+Presuhn, et al. Standards Track [Page 15]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+12. Security Considerations
+
+ SNMPv1 by itself is not a secure environment. Even if the network
+ itself is secure (for example by using IPSec), even then, there is no
+ control as to who on the secure network is allowed to access and
+ GET/SET (read/change) the objects accessible through a command
+ responder application.
+
+ It is recommended that the implementors consider the security
+ features as provided by the SNMPv3 framework. Specifically, the use
+ of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the
+ View-based Access Control Model STD 62, RFC 3415 [RFC3415] is
+ recommended.
+
+ It is then a customer/user responsibility to ensure that the SNMP
+ entity giving access to a MIB is properly configured to give access
+ to the objects only to those principals (users) that have legitimate
+ rights to indeed GET or SET (change) them.
+
+13. References
+
+13.1. Normative References
+
+ [BER] Information processing systems - Open Systems
+ Interconnection - Specification of Basic Encoding Rules
+ for Abstract Syntax Notation One (ASN.1), International
+ Organization for Standardization. International Standard
+ 8825, December 1987.
+
+ [IS8072] Information processing systems - Open Systems
+ Interconnection - Transport Service Definition,
+ International Organization for Standardization.
+ International Standard 8072, June 1986.
+
+ [IS8072A] Information processing systems - Open Systems
+ Interconnection - Transport Service Definition - Addendum
+ 1: Connectionless-mode Transmission, International
+ Organization for Standardization. International Standard
+ 8072/AD 1, December 1986.
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Presuhn, et al. Standards Track [Page 16]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+ 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Textual Conventions for
+ SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Conformance Statements for
+ SMIv2", STD 58, RFC 2580, April 1999.
+
+ [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
+ Model (USM) for Version 3 of the Simple Network
+ Management Protocol (SNMPv3)", STD 62, RFC 3414, December
+ 2002.
+
+ [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+ Access Control Model (VACM) for the Simple Network
+ Management Protocol (SNMP)", STD 62, RFC 3415, December
+ 2002.
+
+ [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
+ Waldbusser, "Version 2 of the Protocol Operations for the
+ Simple Network Management Protocol (SNMP)", STD 62, RFC
+ 3416, December 2002.
+
+13.2. Informative References
+
+ [APPLETALK] Sidhu, G., Andrews, R. and A. Oppenheimer, Inside
+ AppleTalk (second edition). Addison-Wesley, 1990.
+
+ [NOVELL] Network System Technical Interface Overview. Novell,
+ Inc., June 1989.
+
+ [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
+ "Simple Network Management Protocol", STD 15, RFC 1157,
+ May 1990.
+
+ [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management
+ Information Base II", RFC 1742, January 1995.
+
+ [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
+ "Coexistence between Version 1, Version 2, and Version 3
+ of the Internet-Standard Network Management Framework",
+ RFC 2576, March 2000.
+
+
+
+
+Presuhn, et al. Standards Track [Page 17]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+ [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
+ "Introduction and Applicability Statements for Internet-
+ Standard Management Framework", RFC 3410, December 2002.
+
+ [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions
+ for Transport Addresses", RFC 3419, November 2002.
+
+14. Changes from RFC 1906
+
+ This document differs from RFC 1906 only in editorial improvements.
+ The protocol is unchanged.
+
+15. Editor's Address
+
+ Randy Presuhn
+ BMC Software, Inc.
+ 2141 North First Street
+ San Jose, CA 95131
+ USA
+
+ Phone: +1 408 546-1006
+ EMail: randy_presuhn@bmc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 18]
+
+RFC 3417 Transport Mappings for SNMP December 2002
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Presuhn, et al. Standards Track [Page 19]
+