draft-ietf-snmpv3-update-transmap-05.txt   draft-ietf-snmpv3-update-transmap-06.txt 
INTERNET-DRAFT Editor of this version: INTERNET-DRAFT Editor of this version:
Request for Comments: -TM R. Presuhn Request for Comments: -TMM R. Presuhn
STD: XXX BMC Software, Inc. STD: XXX BMC Software, Inc.
Obsoletes: 1906 Authors of previous version: Obsoletes: 1906 Authors of previous version:
Category: Standards Track J. Case Category: Standards Track J. Case
SNMP Research, Inc. SNMP Research, Inc.
K. McCloghrie K. McCloghrie
Cisco Systems, Inc. Cisco Systems, Inc.
M. Rose M. Rose
Dover Beach Consulting, Inc. Dover Beach Consulting, Inc.
S. Waldbusser S. Waldbusser
International Network Services International Network Services
9 August 2000
Transport Mappings for Transport Mappings for
the Simple Network Management Protocol the Simple Network Management Protocol
<draft-ietf-snmpv3-update-transmap-05.txt> <draft-ietf-snmpv3-update-transmap-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 41 skipping to change at page 1, line 39
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document defines the transport of SNMP messages over various This document defines the transport of SNMP messages over various
protocols. This document obsoletes RFC 1906. protocols. This document obsoletes RFC 1906.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Definitions ................................................. 4 2. Definitions ................................................. 4
3. SNMP over UDP over IPv4 ..................................... 7 3. SNMP over UDP over IPv4 ..................................... 8
3.1. Serialization ............................................. 7 3.1. Serialization ............................................. 8
3.2. Well-known Values ......................................... 8 3.2. Well-known Values ......................................... 8
4. SNMP over OSI ............................................... 8 4. SNMP over OSI ............................................... 8
4.1. Serialization ............................................. 8 4.1. Serialization ............................................. 8
4.2. Well-known Values ......................................... 8 4.2. Well-known Values ......................................... 9
5. SNMP over DDP ............................................... 8 5. SNMP over DDP ............................................... 9
5.1. Serialization ............................................. 8 5.1. Serialization ............................................. 9
5.2. Well-known Values ......................................... 9 5.2. Well-known Values ......................................... 9
5.3. Discussion of AppleTalk Addressing ........................ 9 5.3. Discussion of AppleTalk Addressing ........................ 10
5.3.1. How to Acquire NBP names ................................ 10 5.3.1. How to Acquire NBP names ................................ 10
5.3.2. When to Turn NBP names into DDP addresses ............... 10 5.3.2. When to Turn NBP names into DDP addresses ............... 11
5.3.3. How to Turn NBP names into DDP addresses ................ 11 5.3.3. How to Turn NBP names into DDP addresses ................ 11
5.3.4. What if NBP is broken ................................... 11 5.3.4. What if NBP is broken ................................... 11
6. SNMP over IPX ............................................... 12 6. SNMP over IPX ............................................... 12
6.1. Serialization ............................................. 12 6.1. Serialization ............................................. 12
6.2. Well-known Values ......................................... 12 6.2. Well-known Values ......................................... 12
7. Proxy to SNMPv1 ............................................. 12 7. Proxy to SNMPv1 ............................................. 13
8. Serialization using the Basic Encoding Rules ................ 12 8. Serialization using the Basic Encoding Rules ................ 13
8.1. Usage Example ............................................. 13 8.1. Usage Example ............................................. 13
9. Notice on Intellectual Property ............................. 14 9. Notice on Intellectual Property ............................. 14
10. Acknowledgments ............................................ 14 10. Acknowledgments ............................................ 15
11. Security Considerations .................................... 16 11. Security Considerations .................................... 16
12. References ................................................. 16 12. References ................................................. 17
13. Editor's Address ........................................... 18 13. Editor's Address ........................................... 19
14. Changes from RFC 1906 ...................................... 19 14. Changes from RFC 1906 ...................................... 19
15. Issues ..................................................... 20 15. Issues ..................................................... 20
16. Full Copyright Statement ................................... 21 16. Full Copyright Statement ................................... 21
1. Introduction 1. Introduction
The SNMP Management Framework at the time of this writing consists of The SNMP Management Framework at the time of this writing consists of
five major components: five major components:
- An overall architecture, described in RFC 2571 [RFC2571]. - An overall architecture, described in RFC -ARC [RFC-ARC].
- Mechanisms for describing and naming objects and events for - Mechanisms for describing and naming objects and events for
the purpose of management. The first version of this the purpose of management. The first version of this
Structure of Management Information (SMI) is called SMIv1 Structure of Management Information (SMI) is called SMIv1
and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC
1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version,
called SMIv2, is described in STD 58, RFC 2578 [RFC2578], called SMIv2, is described in STD 58, RFC 2578 [RFC2578],
STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- Message protocols for transferring management information. - Message protocols for transferring management information.
The first version of the SNMP message protocol is called The first version of the SNMP message protocol is called
SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A
second version of the SNMP message protocol, which is not second version of the SNMP message protocol, which is not
an Internet standards track protocol, is called SNMPv2c and an Internet standards track protocol, is called SNMPv2c and
is described in RFC 1901 [RFC1901] and this document. The is described in RFC 1901 [RFC1901] and this document. The
third version of the message protocol is called SNMPv3 and third version of the message protocol is called SNMPv3 and
described in this document, RFC 2572 [RFC2572] and RFC 2574 described in this document, RFC -MPD [RFC-MPD] and RFC -USM
[RFC2574]. [RFC-USM].
- Protocol operations for accessing management information. - Protocol operations for accessing management information.
The first set of protocol operations and associated PDU The first set of protocol operations and associated PDU
formats is described in STD 15, RFC 1157 [RFC1157]. A formats is described in STD 15, RFC 1157 [RFC1157]. A
second set of protocol operations and associated PDU second set of protocol operations and associated PDU
formats is described RFC -PROTO [RFC-PROTO]. formats is described RFC -PRO [RFC-PRO].
- A set of fundamental applications described in RFC 2573 - A set of fundamental applications described in RFC -APL
[RFC2573] and the view-based access control mechanism [RFC-APL] and the view-based access control mechanism
described in RFC 2575 [RFC2575]. described in RFC -ACM [RFC-ACM].
A more detailed introduction to the SNMP Management Framework at the A more detailed introduction to the SNMP Management Framework at the
time of this writing can be found in RFC 2570 [RFC2570]. time of this writing can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI. defined using the mechanisms defined in the SMI.
This document, Transport Mappings for the Simple Network Management This document, Transport Mappings for the Simple Network Management
Protocol, defines how the management protocol [RFC-PROTO] may be Protocol, defines how the management protocol [RFC-PRO] may be
carried over a variety of protocol suites. It is the purpose of this 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 document to define how the SNMP maps onto an initial set of transport
domains. Other mappings may be defined in the future. domains. Other mappings may be defined in the future.
Although several mappings are defined, the mapping onto UDP over IPv4 Although several mappings are defined, the mapping onto UDP over IPv4 !
is the preferred mapping for systems supporting IPv4. Systems is the preferred mapping for systems supporting IPv4. Systems !
implementing IPv4 MUST implement the mapping onto UDP over IPv4. To implementing IPv4 MUST implement the mapping onto UDP over IPv4. To !
maximize interoperability, systems supporting other mappings SHOULD maximize interoperability, systems supporting other mappings SHOULD !
also provide for access via the UDP over IPv4 mapping. 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 RFC 2119 [RFC2119]. !
2. Definitions 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS !
MODULE-IDENTITY, OBJECT-IDENTITY, MODULE-IDENTITY, OBJECT-IDENTITY, !
snmpModules, snmpDomains, snmpProxys snmpModules, snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
snmpv2tm MODULE-IDENTITY snmpv2tm MODULE-IDENTITY !
LAST-UPDATED "200008091958Z" LAST-UPDATED "200107021829Z" !
ORGANIZATION "IETF SNMPv3 Working Group" ORGANIZATION "IETF SNMPv3 Working Group" !
CONTACT-INFO CONTACT-INFO !
"WG-EMail: snmpv3@tis.com "WG-EMail: snmpv3@lists.tislabs.com
Subscribe: majordomo@tis.com Subscribe: snmpv3-request@lists.tislabs.com
In message body: subscribe snmpv3
Chair: Russ Mundy Co-Chair: Russ Mundy
TIS Labs at Network Associates NAI Labs,
postal: 3060 Washington Rd Network Associates, Inc.
Glenwood MD 21738 postal: 3060 Washington Rd.
Glenwood, MD 21738
USA USA
EMail: mundy@tislabs.com EMail: mundy@tislabs.com
phone: +1 301 854-6889 phone: +1 301 854-6889
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 Editor: Randy Presuhn
BMC Software, Inc. BMC Software, Inc.
postal: 2141 North First Street postal: 2141 North First Street
San Jose, CA 95131 San Jose, CA 95131
USA USA
EMail: randy_presuhn@bmc.com EMail: randy_presuhn@bmc.com
phone: +1 408 546-1006" phone: +1 408 546-1006"
DESCRIPTION DESCRIPTION
"The MIB module for SNMP transport mappings." "The MIB module for SNMP transport mappings."
REVISION "200008091958Z" REVISION "200107021829Z"
DESCRIPTION DESCRIPTION
"Clarifications, published as "Clarifications, published as RFC -TMM."
<draft-ietf-snmpv3-update-transmap-05.txt>"
REVISION "199601010000Z" REVISION "199601010000Z"
DESCRIPTION DESCRIPTION
"Clarifications, published as RFC 1906." "Clarifications, published as RFC 1906."
REVISION "199304010000Z" REVISION "199304010000Z"
DESCRIPTION DESCRIPTION
"The initial version, published as RFC 1449." "The initial version, published as RFC 1449."
::= { snmpModules ?? } -- to be assigned by IANA?? ::= { snmpModules ?? } -- to be assigned by IANA??
-- SNMP over UDP over IPv4 -- SNMP over UDP over IPv4
snmpUDPDomain OBJECT-IDENTITY snmpUDPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over UDP over IPv4 transport domain. "The SNMP over UDP over IPv4 transport domain. !
The corresponding transport address is of type The corresponding transport address is of type
SnmpUDPAddress." SnmpUDPAddress."
::= { snmpDomains 1 } ::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d" DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents a UDP over IPv4 address: "Represents a UDP over IPv4 address: !
octets contents encoding octets contents encoding
1-4 IP-address network-byte order 1-4 IP-address network-byte order
5-6 UDP-port network-byte order 5-6 UDP-port network-byte order
" "
SYNTAX OCTET STRING (SIZE (6)) SYNTAX OCTET STRING (SIZE (6))
-- SNMP over OSI -- SNMP over OSI
snmpCLNSDomain OBJECT-IDENTITY snmpCLNSDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMP over CLNS transport domain. "The SNMP over CLNS transport domain.
The corresponding transport address is of type The corresponding transport address is of type
SnmpOSIAddress." SnmpOSIAddress."
::= { snmpDomains 2 } ::= { snmpDomains 2 }
snmpCONSDomain OBJECT-IDENTITY snmpCONSDomain OBJECT-IDENTITY
STATUS current STATUS current
skipping to change at page 7, line 25 skipping to change at page 8, line 4
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an IPX address: "Represents an IPX address:
octets contents encoding octets contents encoding
1-4 network-number network-byte order 1-4 network-number network-byte order
5-10 physical-address network-byte order 5-10 physical-address network-byte order
11-12 socket-number network-byte order 11-12 socket-number network-byte order
" "
SYNTAX OCTET STRING (SIZE (12)) SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157) -- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY rfc1157Domain OBJECT-IDENTITY
STATUS deprecated STATUS deprecated !
DESCRIPTION DESCRIPTION
"The transport domain for SNMPv1 over UDP over IPv4. "The transport domain for SNMPv1 over UDP over IPv4. !
The corresponding transport address is of type The corresponding transport address is of type
SnmpUDPAddress." SnmpUDPAddress."
::= { rfc1157Proxy 1 } ::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete -- ::= { rfc1157Proxy 2 } this OID is obsolete
END END
3. SNMP over UDP over IPv4 3. SNMP over UDP over IPv4
skipping to change at page 8, line 13 skipping to change at page 8, line 38
[RFC791] datagram, using the algorithm specified in Section 8. [RFC791] datagram, using the algorithm specified in Section 8.
3.2. Well-known Values 3.2. Well-known Values
It is suggested that administrators configure their SNMP entities It is suggested that administrators configure their SNMP entities
supporting command responder applications to listen on UDP port 161. supporting command responder applications to listen on UDP port 161.
Further, it is suggested that SNMP entities supporting notification Further, it is suggested that SNMP entities supporting notification
receiver applications be configured to listen on UDP port 162. receiver applications be configured to listen on UDP port 162.
When an SNMP entity uses this transport mapping, it must be capable 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 of accepting messages up to and including 484 octets in size. It is !
recommended that implementations be capable of accepting messages of recommended that implementations be capable of accepting messages of !
up to 1472 octets in size. Implementation of larger values is up to 1472 octets in size. Implementation of larger values is !
encouraged whenever possible. encouraged whenever possible.
4. SNMP over OSI 4. SNMP over OSI
This is an optional transport mapping. This is an optional transport mapping.
4.1. Serialization 4.1. Serialization
Each instance of a message is serialized onto a single TSDU [IS8072] Each instance of a message is serialized onto a single TSDU [IS8072]
[IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS),
skipping to change at page 9, line 19 skipping to change at page 9, line 41
5.2. Well-known Values 5.2. Well-known Values
SNMP messages are sent using DDP protocol type 8. SNMP entities SNMP messages are sent using DDP protocol type 8. SNMP entities
supporting command responder applications listen on DDP socket number supporting command responder applications listen on DDP socket number
8, while SNMP entities supporting notification receiver applications 8, while SNMP entities supporting notification receiver applications
listen on DDP socket number 9. listen on DDP socket number 9.
Administrators must configure their SNMP entities supporting command Administrators must configure their SNMP entities supporting command
responder applications to use NBP type "SNMP Agent" (which consists responder applications to use NBP type "SNMP Agent" (which consists
of ten ASCII while those supporting notification receiver of ten ASCII characters) while those supporting notification receiver
applications must be configured to use NBP type "SNMP Trap Handler" applications must be configured to use NBP type "SNMP Trap Handler"
(which consists of seventeen ASCII characters). (which consists of seventeen ASCII characters).
The NBP name for SNMP entities supporting command responders and The NBP name for SNMP entities supporting command responders and
notification receivers should be stable - NBP names should not change 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 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. 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 When an SNMP entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size. of accepting messages that are at least 484 octets in size.
skipping to change at page 12, line 35 skipping to change at page 13, line 8
supporting notification receiver applications be configured to listen supporting notification receiver applications be configured to listen
on IPX socket 36880 (9010 hexadecimal). on IPX socket 36880 (9010 hexadecimal).
When an SNMP entity uses this transport mapping, it must be capable When an SNMP entity uses this transport mapping, it must be capable
of accepting messages that are at least 546 octets in size. of accepting messages that are at least 546 octets in size.
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
7. Proxy to SNMPv1 7. Proxy to SNMPv1
Historically, in order to support proxy to SNMPv1, as defined in Historically, in order to support proxy to SNMPv1, as defined in
[RFC2576], it was deemed useful to define a transport domain, [RFC-COEX], it was deemed useful to define a transport domain,
rfc1157Domain, which indicates the transport mapping for SNMP rfc1157Domain, which indicates the transport mapping for SNMP
messages as defined in [RFC1157]. messages as defined in [RFC1157].
8. Serialization using the Basic Encoding Rules 8. Serialization using the Basic Encoding Rules
When the Basic Encoding Rules [BER] are used for serialization: When the Basic Encoding Rules [BER] are used for serialization:
(1) When encoding the length field, only the definite form is used; (1) When encoding the length field, only the definite form is used;
use of the indefinite form encoding is prohibited. Note that use of the indefinite form encoding is prohibited. Note that
when using the definite-long form, it is permissible to use more when using the definite-long form, it is permissible to use more
skipping to change at page 13, line 25 skipping to change at page 13, line 46
final octet are set to zero on generation and ignored on final octet are set to zero on generation and ignored on
receipt. receipt.
These restrictions apply to all aspects of ASN.1 encoding, including These restrictions apply to all aspects of ASN.1 encoding, including
the message wrappers, protocol data units, and the data objects they the message wrappers, protocol data units, and the data objects they
contain. contain.
8.1. Usage Example 8.1. Usage Example
As an example of applying the Basic Encoding Rules, suppose one As an example of applying the Basic Encoding Rules, suppose one
wanted to encode an instance of the GetBulkRequest-PDU [RFC-PROTO]: wanted to encode an instance of the GetBulkRequest-PDU [RFC-PRO]:
[5] IMPLICIT SEQUENCE { [5] IMPLICIT SEQUENCE {
request-id 1414684022, request-id 1414684022,
non-repeaters 1, non-repeaters 1,
max-repetitions 2, max-repetitions 2,
variable-bindings { variable-bindings {
{ name sysUpTime, { name sysUpTime, !
value { unspecified NULL } }, value { unSpecified NULL } },
{ name ipNetToMediaPhysAddress, { name ipNetToMediaPhysAddress, !
value { unspecified NULL } }, value { unSpecified NULL } },
{ name ipNetToMediaType, { name ipNetToMediaType, !
value { unspecified NULL } } value { unSpecified NULL } }
} }
} }
Applying the BER, this would be encoded (in hexadecimal) as:
Applying the BER, this may be encoded (in hexadecimal) as:
[5] IMPLICIT SEQUENCE a5 82 00 39 [5] IMPLICIT SEQUENCE a5 82 00 39
INTEGER 02 04 52 54 5d 76 INTEGER 02 04 54 52 5d 76
INTEGER 02 01 01 INTEGER 02 01 01
INTEGER 02 01 02 INTEGER 02 01 02
SEQUENCE (OF) 30 2b SEQUENCE (OF) 30 2b
SEQUENCE 30 0b SEQUENCE 30 0b
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00 NULL 05 00
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00 NULL 05 00
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00 NULL 05 00
Note that the initial SEQUENCE is not encoded using the minimum Note that the initial SEQUENCE in this example was not encoded using
number of length octets. (The first octet of the length, 82, the minimum number of length octets. (The first octet of the length,
indicates that the length of the content is encoded in the next two 82, indicates that the length of the content is encoded in the next
octets.) two octets.)
9. Notice on Intellectual Property 9. Notice on Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at page 16, line 23 skipping to change at page 16, line 36
Shawn Routhier Shawn Routhier
Jon Saperia Jon Saperia
Juergen Schoenwaelder Juergen Schoenwaelder
Bob Stewart Bob Stewart
Kaj Tesink Kaj Tesink
Glenn Waters Glenn Waters
Bert Wijnen Bert Wijnen
11. Security Considerations 11. Security Considerations
SNMPv1 by itself is not a secure environment. Even if the network 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 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 control as to who on the secure network is allowed to access and !
GET/SET (read/change) the objects accessible through a command GET/SET (read/change) the objects accessible through a command !
responder application. responder application. !
It is recommended that the implementors consider the security It is recommended that the implementors consider the security !
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use !
of the User-based Security Model RFC 2574 [RFC2574] and the of the User-based Security Model RFC -USM [RFC-USM] and the !
View-based Access Control Model RFC 2575 [RFC2575] is recommended. View-based Access Control Model RFC -ACM [RFC-ACM] is recommended. !
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP !
entity giving access to a MIB is properly configured to give access entity giving access to a MIB is properly configured to give access !
to the objects only to those principals (users) that have legitimate to the objects only to those principals (users) that have legitimate !
rights to indeed GET or SET (change) them. rights to indeed GET or SET (change) them. !
12. References 12. References
[APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside [APPLETALK] Sidhu, G., Andrews, R., and A. Oppenheimer, Inside
AppleTalk (second edition). Addison-Wesley, 1990. AppleTalk (second edition). Addison-Wesley, 1990.
[BER] Information processing systems - Open Systems [BER] Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1), International for Abstract Syntax Notation One (ASN.1), International
Organization for Standardization. International Standard Organization for Standardization. International Standard
skipping to change at page 17, line 46 skipping to change at page 18, line 9
[RFC1215] Rose, M., "A Convention for Defining Traps for use with [RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991. the SNMP", RFC 1215, March 1991.
[RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management [RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management
Information Base II", RFC 1742, January 1995. Information Base II", RFC 1742, January 1995.
[RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, "Introduction to Community-based SNMPv2", RFC 1901,
January 1996. January 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard "Introduction to Version 3 of the Internet-standard
Network Management Framework", RFC 2570, April 1999. Network Management Framework", RFC 2570, April 1999.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC-ARC] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks", Architecture for describing SNMP Management Frameworks",
RFC 2571, April 1999. <draft-ietf-snmpv3-arch-v2-01.txt>, July 2001.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, [RFC-MPD] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple "Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, April Network Management Protocol (SNMP)",
1999. <draft-ietf-snmpv3-mpd-v2-01.txt>, July 2001.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 [RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
Applications", RFC 2573, April 1999. <draft-ietf-snmpv3-appl-v3-01.txt>, July 2001.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security
(USM) for version 3 of the Simple Network Management Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999. Protocol (SNMPv3)",
<draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt>, July 2001.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model for the Simple Network Management
Management Protocol (SNMP)", RFC 2575, April 1999. Protocol (SNMP)", <draft-ietf-snmpv3-vacm-04.txt>,
February 1999. <draft-ietf-snmpv3-vacm-v2-01.txt>, July
2001.
[RFC2576] Frye, R., Levi, D., Routhier, S., and B. Wijnen, [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 "Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework", of the Internet-standard Network Management Framework",
RFC 2576, March, 2000. <draft-ietf-snmpv3-coex-v2-01.txt>, July 2001.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999. 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999. SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for the Simple Network Waldbusser, "Transport Mappings for the Simple Network
Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-transmap-05.txt>, August 2000. <draft-ietf-snmpv3-update-transmap-06.txt>, July 2001.
[RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. [RFC-PRO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network Waldbusser, "Protocol Operations for the Simple Network
Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-proto-05.txt>, August 2000. <draft-ietf-snmpv3-update-proto-06.txt>, July 2001.
13. Editor's Address 13. Editor's Address
Randy Presuhn Randy Presuhn
BMC Software, Inc. BMC Software, Inc.
2141 North First Street 2141 North First Street
San Jose, CA 95131 San Jose, CA 95131
USA USA
Phone: +1 408 546-1006 Phone: +1 408 546-1006
skipping to change at page 19, line 51 skipping to change at page 20, line 16
- Updated references section; - Updated references section;
- Added MODULE-IDENTITY; - Added MODULE-IDENTITY;
- Re-wrote introduction section using current boilerplate; - Re-wrote introduction section using current boilerplate;
- Added recommendation for larger message size support; - Added recommendation for larger message size support;
- Added historical background on use of rfc1157Domain with - Added historical background on use of rfc1157Domain with
proxy and changed status to "deprecated". proxy and changed status to "deprecated";
- Added an abstract. - Added an abstract;
- Strengthened conformance requirement for support of the UDP - Strengthened conformance requirement for support of the UDP
over IPv4 mapping. over IPv4 mapping;
- Updated working group mailing list address;
- Added address of working group co-chair;
- Corrected error in BER example.
15. Issues 15. Issues
This section is to be deleted when it is time to publish this This section is to be deleted when it is time to publish this
document as an RFC. The issue labels are the same as those used in document as an RFC. The issue labels are the same as those used in
the on-line issues list at the on-line issues list at
ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html ftp://amethyst.bmc.com/pub/snmpv3/Update567/rfc1906/index.html
1906-01 Done; title changed. 1906-01 Done; title changed.
skipping to change at page 21, line 20 skipping to change at page 21, line 40
mandatory for systems which support IPv4. mandatory for systems which support IPv4.
1906-21 Done; resolution was to make no change. 1906-21 Done; resolution was to make no change.
1906-22 Done; resolution was to make no change. 1906-22 Done; resolution was to make no change.
1906-23 Done; added abstract. 1906-23 Done; added abstract.
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 57 change blocks. 
107 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/