summaryrefslogtreecommitdiff
path: root/cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt
diff options
context:
space:
mode:
Diffstat (limited to 'cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt')
-rw-r--r--cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt1067
1 files changed, 0 insertions, 1067 deletions
diff --git a/cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt b/cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt
deleted file mode 100644
index ba4c52934a..0000000000
--- a/cleopatre/application/spidnetsnmp/doc/rfc/snmpV3/rfc3417.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-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]
-