draft-ietf-snmpv3-update-transmap-00.txt   draft-ietf-snmpv3-update-transmap-01.txt 
INTERNET-DRAFT Editor of this version: INTERNET-DRAFT Editor of this version:
Will Obsolete: 1906 R. Presuhn Request for Comments: -TM R. Presuhn
BMC Software, Inc. STD: XXX BMC Software, Inc.
9 January 2000 Obsoletes: 1906 Authors of previous version:
Category: Standards Track J. Case
Authors of previous version:
SNMPv2 Working Group
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
23 January 2000
Transport Mappings for Transport Mappings for
the Simple Network Management Protocol the Simple Network Management Protocol
<draft-ietf-snmpv3-update-transmap-00.txt> <draft-ietf-snmpv3-update-transmap-01.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 31 skipping to change at page 2, line 31
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 ............................................. 12
8. Serialization using the Basic Encoding Rules ................ 12 8. Serialization using the Basic Encoding Rules ................ 12
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 ............................................ 14
11. Security Considerations .................................... 15 11. Security Considerations .................................... 16
12. References ................................................. 16 12. References ................................................. 16
13. Editor's Address ........................................... 18 13. Editor's Address ........................................... 18
14. Changes from RFC 1906 ...................................... 18 14. Changes from RFC 1906 ...................................... 19
15. Issues ..................................................... 19 15. Issues ..................................................... 20
16. Full Copyright Statement ................................... 20 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 2571 [RFC2571].
- 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 4, line 15 skipping to change at page 4, line 15
Although several mappings are defined, the mapping onto UDP is Although several mappings are defined, the mapping onto UDP is
the preferred mapping. As such, to provide for the greatest the preferred mapping. As such, to provide for the greatest
level of interoperability, systems which choose to deploy other level of interoperability, systems which choose to deploy other
mappings should also provide for proxy service to the UDP mappings should also provide for proxy service to the UDP
mapping. mapping.
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 "200001100422Z" LAST-UPDATED "200001231839Z" !
ORGANIZATION "IETF SNMPv3 Working Group" ORGANIZATION "IETF SNMPv3 Working Group" !
CONTACT-INFO CONTACT-INFO !
"WG-EMail: snmpv3@tis.com "WG-EMail: snmpv3@tis.com !
Subscribe: majordomo@tis.com Subscribe: majordomo@tis.com !
In message body: subscribe snmpv3 In message body: subscribe snmpv3 !
Chair: Russ Mundy Chair: Russ Mundy !
TIS Labs at Network Associates TIS Labs at Network Associates !
postal: 3060 Washington Rd postal: 3060 Washington Rd !
Glenwood MD 21738 Glenwood MD 21738 !
USA USA !
EMail: mundy@tislabs.com EMail: mundy@tislabs.com !
phone: +1 301 854-6889 phone: +1 301 854-6889 !
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 "200001100422Z" REVISION "200001231839Z" !
DESCRIPTION DESCRIPTION !
"Clarifications, published as RFC 0." "Clarifications, published as !
REVISION "199601010000Z" <draft-ietf-snmpv3-update-transmap-01.txt>" !
DESCRIPTION REVISION "199601010000Z" !
"Clarifications, published as RFC 1906." DESCRIPTION !
REVISION "199304010000Z" "Clarifications, published as RFC 1906." !
DESCRIPTION REVISION "199304010000Z" !
"The initial version, published as RFC 1449." DESCRIPTION !
::= { snmpModules ?? } -- to be assigned by IANA?? "The initial version, published as RFC 1449." !
::= { 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 transport domain. The corresponding "The SNMP over UDP transport domain. The corresponding
transport address is of type SnmpUDPAddress." transport address is of type SnmpUDPAddress."
::= { snmpDomains 1 } ::= { snmpDomains 1 }
skipping to change at page 8, line 13 skipping to change at page 8, line 13
datagram, using the algorithm specified in Section 8. 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 15, line 7 skipping to change at page 14, line 50
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
10. Acknowledgments 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
The previous versions of this document, edited by Keith McCloghrie, The previous versions of this document, edited by Keith McCloghrie,
was the result of significant work by four major contributors: was the result of significant work by four major contributors:
Jeffrey D. Case (SNMP Research, case@snmp.com) Jeffrey D. Case
Keith McCloghrie (Cisco Systems, kzm@cisco.com) Keith McCloghrie
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) Marshall T. Rose
Steven Waldbusser (International Network Services, stevew@uni.ins.com) Steven Waldbusser
In addition, the contributions of the SNMPv2 Working Group are Additionally, the contributions of the SNMPv2 Working Group to the
acknowledged. In particular, a special thanks is extended for the previous versions are also acknowledged. In particular, a special
contributions of: thanks is extended for the contributions of:
Alexander I. Alten (Novell) Alexander I. Alten
Dave Arneson (Cabletron) Dave Arneson
Uri Blumenthal (IBM) Uri Blumenthal
Doug Book (Chipcom) Doug Book
Kim Curran (Bell-Northern Research) Kim Curran
Jim Galvin (Trusted Information Systems) Jim Galvin
Maria Greene (Ascom Timeplex) Maria Greene
Iain Hanson (Digital) Iain Hanson
Dave Harrington (Cabletron) Dave Harrington
Nguyen Hien (IBM) Nguyen Hien
Jeff Johnson (Cisco Systems) Jeff Johnson
Michael Kornegay (Object Quest) Michael Kornegay
Deirdre Kostick (AT&T Bell Labs) Deirdre Kostick
David Levi (SNMP Research) David Levi
Daniel Mahoney (Cabletron) Daniel Mahoney
Russ Mundy (TIS Labs at Network Associates, Chair) Bob Natale
Bob Natale (ACE*COMM) Brian O'Keefe
Brian O'Keefe (Hewlett Packard) Andrew Pearson
Andrew Pearson (SNMP Research) Dave Perkins
Dave Perkins (Peer Networks) Randy Presuhn
Aleksey Romanov (Quality Quorum) Aleksey Romanov
Shawn Routhier (Epilogue) Shawn Routhier
Jon Saperia (BGS Systems) Jon Saperia
Juergen Schoenwaelder (TU Braunschweig) Juergen Schoenwaelder
Bob Stewart (Cisco Systems) Bob Stewart
Kaj Tesink (Bellcore) Kaj Tesink
Glenn Waters (Bell-Northern Research) Glenn Waters
Bert Wijnen (IBM) 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 2574 [RFC2574] and the !
View-based Access Control Model RFC 2575 [RFC2575] is recommended. View-based Access Control Model RFC 2575 [RFC2575] 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
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980. USC/Information Sciences Institute, August 1980.
[IS8072] Information processing systems - Open Systems [IS8072] Information processing systems - Open Systems
Interconnection - Transport Service Definition, Interconnection - Transport Service Definition,
International Organization for Standardization. International Organization for Standardization.
International Standard 8072, June 1986. International Standard 8072, June 1986.
skipping to change at page 16, line 47 skipping to change at page 17, line 19
[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.
[NOVELL] Network System Technical Interface Overview. Novell, [NOVELL] Network System Technical Interface Overview. Novell,
Inc, June 1989. Inc, June 1989.
[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-06.txt>, December 1999. <draft-ietf-snmpv3-coex-07.txt>, January, 2000.
[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
8825, December 1987. 8825, December 1987.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks", Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999. RFC 2571, April 1999.
skipping to change at page 17, line 42 skipping to change at page 18, line 14
SMIv2", STD 58, RFC 2580, April 1999. SMIv2", STD 58, RFC 2580, April 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157, "Simple Network Management Protocol", STD 15, RFC 1157,
May 1990. May 1990.
[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.
[RFC-TM] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, [RFC-TM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
K., Rose, M., and S. Waldbusser, "Transport Mappings for Waldbusser, "Transport Mappings for the Simple Network
the Simple Network Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-transmap-00.txt>, January 2000. <draft-ietf-snmpv3-update-transmap-01.txt>, January 2000.
[RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, [RFC2572] 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)", RFC 2572, April
1999. 1999.
[RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, April 1999. Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC-PROTO] Presuhn, R., SNMPv2 Working Group, Case, J., McCloghrie, [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
K., Rose, M., and S. Waldbusser, "Protocol Operations for Waldbusser, "Protocol Operations for the Simple Network
the Simple Network Management Protocol", Management Protocol",
<draft-ietf-snmpv3-update-proto-00.txt>, January 2000. <draft-ietf-snmpv3-update-proto-01.txt>, January 2000.
[RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999. Applications", RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999. Management Protocol (SNMP)", RFC 2575, April 1999.
[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
skipping to change at page 20, line 22 skipping to change at page 20, line 47
1906-12 Done; resolution required no changes. 1906-12 Done; resolution required no changes.
1906-13 Done; resolution required no changes. 1906-13 Done; resolution required no changes.
1906-14 Done; clarified that BER SEQUENCE comes from ASN.1 1906-14 Done; clarified that BER SEQUENCE comes from ASN.1
SEQUENCE OF. SEQUENCE OF.
1906-15 Done; security considerations text added. 1906-15 Done; security considerations text added.
1906-16 PARTIAL; references updated, acknowledgments need work. 1906-16 Done; references and acknowledgments updated.
1906-17 Done; IPR and copyright notices updated. 1906-17 Done; IPR and copyright notices updated.
1906-18 Done; resolution required no changes. 1906-18 Done; resolution required no changes.
1906-19 Done; MODULE-IDENTITY added. 1906-19 Done; MODULE-IDENTITY added.
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
 End of changes. 21 change blocks. 
108 lines changed or deleted 132 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/