draft-ietf-snmpv3-update-transmap-07.txt   draft-ietf-snmpv3-update-transmap-08.txt 
skipping to change at page 1, line 14 skipping to change at page 1, line 15
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
3 October 2001 16 October 2001
Transport Mappings for Transport Mappings for
the Simple Network Management Protocol the Simple Network Management Protocol
<draft-ietf-snmpv3-update-transmap-07.txt> <draft-ietf-snmpv3-update-transmap-08.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 2, line 37 skipping to change at page 2, line 37
8. Serialization using the Basic Encoding Rules ................ 13 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 ............................................ 15 10. Acknowledgments ............................................ 15
11. IANA Considerations ........................................ 16 11. IANA Considerations ........................................ 16
12. Security Considerations .................................... 16 12. Security Considerations .................................... 16
13. References ................................................. 17 13. References ................................................. 17
14. Editor's Address ........................................... 19 14. Editor's Address ........................................... 19
15. Changes from RFC 1906 ...................................... 19 15. Changes from RFC 1906 ...................................... 19
16. Issues ..................................................... 20 16. Issues ..................................................... 20
17. Full Copyright Statement ................................... 21 17. Full Copyright Statement ................................... 22
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 -ARC [RFC-ARC]. - 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
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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-PRO] 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. At the time of this writing, work was in progress to define
an IPv6 mapping, described in [WIP-TADDR]. 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", ! The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this ! "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. ! 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 "200110040534Z" ! LAST-UPDATED "200110161727Z"
ORGANIZATION "IETF SNMPv3 Working Group" ! ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO ! CONTACT-INFO
"WG-EMail: snmpv3@lists.tislabs.com "WG-EMail: snmpv3@lists.tislabs.com
Subscribe: snmpv3-request@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy Co-Chair: Russ Mundy
NAI Labs, NAI Labs,
Network Associates, Inc. Network Associates, Inc.
postal: 3060 Washington Rd. postal: 3060 Washington Rd.
Glenwood, MD 21738 Glenwood, MD 21738
USA USA
EMail: mundy@tislabs.com EMail: mundy@tislabs.com
skipping to change at page 5, line 13 skipping to change at page 5, line 13
phone: +1 603 337-2614 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 "200110040534Z" REVISION "200110161727Z"
DESCRIPTION DESCRIPTION
"Clarifications, published as RFC -TMM." "Clarifications, published as RFC -TMM."
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
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 38 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 14, line 10 skipping to change at page 14, line 10
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-PRO]: 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 may 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 54 52 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
skipping to change at page 16, line 36 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. IANA Considerations 11. IANA Considerations
The SNMPv2-TM MIB module requires the allocation of a single object ! The SNMPv2-TM MIB module requires the allocation of a single object
identifier for its MODULE-IDENTITY. IANA should allocate this object ! identifier for its MODULE-IDENTITY. IANA should allocate this object
identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB ! identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB
module. ! module.
12. Security Considerations 12. 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 -USM [RFC-USM] and the ! of the User-based Security Model RFC -USM [RFC-USM] and the
View-based Access Control Model RFC -ACM [RFC-ACM] 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 !
entity giving access to a MIB is properly configured to give access ! It is then a customer/user responsibility to ensure that the SNMP
to the objects only to those principals (users) that have legitimate ! entity giving access to a MIB is properly configured to give access
rights to indeed GET or SET (change) them. ! to the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change) them.
13. References 13. 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 18, line 36 skipping to change at page 18, line 36
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-TMM] 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-07.txt>, October 2001. <draft-ietf-snmpv3-update-transmap-08.txt>, October 2001.
[RFC-PRO] 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-07.txt>, October 2001. <draft-ietf-snmpv3-update-proto-08.txt>, October 2001.
[RFC-ARC] 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",
<draft-ietf-snmpv3-arch-v2-01.txt>, October 2001. <draft-ietf-snmpv3-arch-v2-02.txt>, October 2001.
[RFC-MPD] 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)", Network Management Protocol (SNMP)",
<draft-ietf-snmpv3-mpd-v2-01.txt>, October 2001. <draft-ietf-snmpv3-mpd-v2-02.txt>, October 2001.
[RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", [RFC-APL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
<draft-ietf-snmpv3-appl-v3-01.txt>, October 2001. <draft-ietf-snmpv3-appl-v3-01.txt>, October 2001.
[RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model for Version 3 of the Simple Network Management Model for Version 3 of the Simple Network Management
Protocol (SNMPv3)", Protocol (SNMPv3)",
<draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt>, October <draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt>, October
2001. 2001.
[RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model for the Simple Network Management Access Control Model for the Simple Network Management
Protocol (SNMP)", <draft-ietf-snmpv3-vacm-v2-01.txt>, Protocol (SNMP)", <draft-ietf-snmpv3-vacm-v2-01.txt>,
October 2001. October 2001.
[RFC-COEX] 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",
<draft-ietf-snmpv3-coex-v2-01.txt>, October 2001. <draft-ietf-snmpv3-coex-v2-01.txt>, October 2001.
[WIP-TADDR] Daniele, M., and J. Schoenwaelder, "Textual Conventions
for Transport Addresses",
<draft-ops-taddress-mib-01.txt>, September, 2001.
14. Editor's Address 14. 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
EMail: randy_presuhn@bmc.com EMail: randy_presuhn@bmc.com
skipping to change at page 20, line 33 skipping to change at page 20, line 38
- 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; - Updated working group mailing list address;
- Added address of working group co-chair; - Added address of working group co-chair;
- Corrected error in BER example; - Corrected error in BER example;
Added IANA considerations section. Added IANA considerations section;
Added non-normative reference to work-in-progress on IPv6
mapping.
16. Issues 16. 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.
 End of changes. 26 change blocks. 
51 lines changed or deleted 61 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/