Network Working Group                                            J. Case
Request for Comments: 3410                           SNMP Research, Inc.
Obsoletes: 2570                                                 R. Mundy
Category: Informational                  Network Associates Laboratories
                                                              D. Partain
                                                              B. Stewart
                                                           December 2002
             Introduction and Applicability Statements for
                 Internet Standard Management Framework

Status of this Memo


This memo provides information for the Internet community. It does not specify an Internet-standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (C) The Internet Society (2002). All Rights Reserved.




The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).


The architecture is designed to be modular to allow the evolution of the Framework over time.


The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.

SNMPv1またはSNMPv2のの代わりに、SNMPv3を使用が強く推奨される理由を文書で説明しています。文書はまたのRFC 1157、1441、1901、1909年と1910年は歴史的な状況に移動して引退することをお勧めします。この文書はRFC 2570を廃止します。

Table of Contents


   1 Introduction .................................................    2
   2 The Internet Standard Management Framework ...................    3
   2.1 Basic Structure and Components .............................    4
   2.2 Architecture of the Internet Standard Management Framework .    4
   3 The SNMPv1 Management Framework ..............................    5
   3.1 The SNMPv1 Data Definition Language ........................    6
   3.2 Management Information .....................................    6
   3.3 Protocol Operations ........................................    7
   3.4 SNMPv1 Security and Administration .........................    7
   4 The SNMPv2 Management Framework ..............................    8
   5 The SNMPv3 Working Group .....................................    8
   6 SNMPv3 Framework Module Specifications .......................   10
   6.1 Data Definition Language ...................................   11
   6.2 MIB Modules ................................................   12
   6.3 Protocol Operations and Transport Mappings .................   13
   6.4 SNMPv3 Security and Administration .........................   13
   7 Document Summaries ...........................................   14
   7.1 Structure of Management Information ........................   14
   7.1.1 Base SMI Specification ...................................   15
   7.1.2 Textual Conventions ......................................   15
   7.1.3 Conformance Statements ...................................   16
   7.2 Protocol Operations ........................................   16
   7.3 Transport Mappings .........................................   16
   7.4 Protocol Instrumentation ...................................   17
   7.5 Architecture / Security and Administration .................   17
   7.6 Message Processing and Dispatch (MPD) ......................   17
   7.7 SNMP Applications ..........................................   18
   7.8 User-based Security Model (USM) ............................   18
   7.9 View-based Access Control (VACM) ...........................   19
   7.10 SNMPv3 Coexistence and Transition .........................   19
   8 Standardization Status .......................................   20
   8.1 SMIv1 Status ...............................................   20
   8.2 SNMPv1 and SNMPv2 Standardization Status ...................   21
   8.3 Working Group Recommendation ...............................   22
   9 Security Considerations ......................................   22
   10 References ..................................................   22
   11 Editor's Addresses ..........................................   26
   12 Full Copyright Statement ....................................   27
1. Introduction
1. はじめに

This document is an introduction to the third version of the Internet-Standard Management Framework, termed the SNMP version 3 Management Framework (SNMPv3) and has multiple purposes.


First, it describes the relationship between the SNMP version 3 (SNMPv3) specifications and the specifications of the SNMP version 1 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Framework, and the Community-based Administrative Framework for SNMPv2.


Second, it provides a roadmap to the multiple documents which contain the relevant specifications.


Third, this document provides a brief easy-to-read summary of the contents of each of the relevant specification documents.


This document is intentionally tutorial in nature and, as such, may occasionally be "guilty" of oversimplification. In the event of a conflict or contradiction between this document and the more detailed documents for which this document is a roadmap, the specifications in the more detailed documents shall prevail.


Further, the detailed documents attempt to maintain separation between the various component modules in order to specify well-defined interfaces between them. This roadmap document, however, takes a different approach and attempts to provide an integrated view of the various component modules in the interest of readability.


This document is a work product of the SNMPv3 Working Group of the Internet Engineering Task Force (IETF).


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 [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。

2. The Internet Standard Management Framework

The third version of the Internet Standard Management Framework (the SNMPv3 Framework) is derived from and builds upon both the original Internet-Standard Management Framework (SNMPv1) and the second Internet-Standard Management Framework (SNMPv2).


All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard Management SNMP Framework share the same basic structure and components. Furthermore, all versions of the specifications of the Internet Standard Management Framework follow the same architecture.


2.1. Basic Structure and Components
2.1. 基本構造とコンポーネント

An enterprise deploying the Internet Standard Management Framework contains four basic components:


* several (typically many) managed nodes, each with an SNMP entity which provides remote access to management instrumentation (traditionally called an agent);


* at least one SNMP entity with management applications (typically called a manager),


* a management protocol used to convey management information between the SNMP entities, and


* management information.


The management protocol is used to convey management information between SNMP entities such as managers and agents.


This basic structure is common to all versions of the Internet Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3.


2.2. Architecture of the Internet Standard Management Framework
2.2. インターネット標準管理フレームワークのアーキテクチャ

The specifications of the Internet Standard Management Framework are based on a modular architecture. This framework is more than just a protocol for moving data. It consists of:


* a data definition language,


* definitions of management information (the Management Information Base, or MIB),


* a protocol definition, and


* security and administration.


Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to SNMPv3, the definitions of each of these architectural components have become richer and more clearly defined, but the fundamental architecture has remained consistent.


One prime motivator for this modularity was to enable the ongoing evolution of the Framework, as is documented in RFC 1052 [2]. When originally envisioned, this capability was to be used to ease the transition from SNMP-based management of internets to management based on OSI protocols. To this end, the framework was architected with a protocol-independent data definition language and Management Information Base along with a MIB-independent protocol. This separation was designed to allow the SNMP-based protocol to be replaced without requiring the management information to be redefined or reinstrumented. History has shown that the selection of this architecture was the right decision for the wrong reason -- it turned out that this architecture has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition away from management based on the Simple Network Management Protocol.

このモジュール方式の一つプライム動機は、RFC 1052で文書化されたように、フレームワークの継続的な発展を可能にするためだった[2]。本来想定するとき、この機能は、OSIプロトコルに基づく管理へのインターネットのSNMPベースの管理からの移行を容易にするために使用されるようになりました。この目的を達成するために、フレームワークは、MIB-依存しないプロトコルと一緒に、プロトコルに依存しないデータ定義言語と管理情報ベースで設計されました。この分離は、SNMPベースのプロトコルは、再定義又は再インスする管理情報を必要とせずに交換することができるように設計しました。それは、このアーキテクチャがシンプルに基づいて、むしろ離れて経営からの移行を容易によりのSNMPv1からSNMPv2のへとSNMPv2からSNMPv3のへの移行を緩和していることが判明 - 歴史は、このアーキテクチャの選択は間違った理由のために正しい決断だったことを示していますネットワーク管理プロトコル。

The SNMPv3 Framework builds and extends these architectural principles by:


* building on these four basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and


* by using these same layering principles in the definition of new capabilities in the security and administration portion of the architecture.


Those who are familiar with the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework will find many familiar concepts in the architecture of the SNMPv3 Management Framework. However, in some cases, the terminology may be somewhat different.


3. The SNMPv1 Management Framework

The original Internet-Standard Network Management Framework (SNMPv1) is defined in the following documents:


* STD 16, RFC 1155 [3] which defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management.

* STD 16、RFC 1155 [3]管理情報(SMI)、管理の目的のためにオブジェクトを記述し、命名のために使用される機構の構造を定義します。

* STD 16, RFC 1212 [4] which defines a more concise description mechanism for describing and naming management information objects, but which is wholly consistent with the SMI.

* STD 16、RFC 1212 [4]管理情報オブジェクトを記述し、命名のためのより簡潔な記述メカニズムを定義するが、SMIと完全に一致しています。

* STD 15, RFC 1157 [5] which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects and event notification. Note this document also defines an initial set of event notifications.

* STD 15、RFC 1157 [5]簡易ネットワーク管理プロトコル(SNMP)、管理オブジェクトとイベント通知へのネットワークアクセスのために使用されるプロトコルを定義します。この文書はまた、イベント通知の初期セットを定義して注意してください。

Additionally, two documents are generally considered companions to these three:


* STD 17, RFC 1213 [6] which contains definitions for the base set of management information

* STD 17、RFC 1213 [6]、管理情報の基本セットの定義を含んでいます

* RFC 1215 [7] defines a concise description mechanism for defining event notifications, which are called traps in the SNMPv1 protocol. It also specifies the generic traps from RFC 1157 in the concise notation.

* RFC 1215 [7] SNMPv1プロトコルにトラップと呼ばれるイベント通知を定義するための簡潔な記述メカニズムを定義します。また、簡潔な表記でRFC 1157から汎用トラップを指定します。

These documents describe the four parts of the first version of the SNMP Framework.


3.1. The SNMPv1 Data Definition Language
3.1. SNMPv1のデータ定義言語

The first two and the last document, i.e., RFCs 1155, 1212, and 1215, describe the SNMPv1 data definition language and are often collectively referred to as "SMIv1". Note that due to the initial requirement that the SMI be protocol-independent, the first two SMI documents do not provide a means for defining event notifications (traps). Instead, the SNMP protocol document defines a few standardized event notifications (generic traps) and provides a means for additional event notifications to be defined. The last document specifies a straight-forward approach towards defining event notifications used with the SNMPv1 protocol. At the time that it was written, use of traps in the Internet-Standard network management framework was controversial. As such, RFC 1215 was put forward with the status of "Informational", which was never updated because it was believed that the second version of the SNMP Framework would replace the first version.

二つの第一及び最後のドキュメント、即ち、のRFC 1155、1212、1215、SNMPv1のデータ定義言語を記述し、しばしば集合的に「でSMIv1」と呼ばれます。 SMIは、プロトコルに依存しないことが最初の要求には、最初の2つのSMI文書がイベント通知(トラップ)を定義するための手段を提供しないことに注意してください。代わりに、SNMPプロトコル文書は、いくつかの標準化されたイベント通知(汎用トラップ)を定義し、定義するために追加のイベント通知のための手段を提供します。最後のドキュメントは、SNMPv1プロトコルで使用されるイベント通知の定義に向けた直接的なアプローチを指定します。それが書かれた時点で、インターネット標準ネットワーク管理フレームワークでのトラップの使用は物議ました。このようにして、RFC 1215には、それはSNMPフレームワークの第二のバージョンは、最初のバージョンを置き換えるだろうと信じられていたため、更新されなかった「情報」の状態、と提唱しました。

3.2. Management Information
3.2. 管理情報

The data definition language described in the first two documents was first used to define the now-historic MIB-I as specified in RFC 1066 [8], and was subsequently used to define MIB-II as specified in RFC 1213 [6].

最初の二つの文書に記載されたデータ定義言語は、最初の[8] RFC 1066で指定されるように、今、歴史的MIB-Iを定義するために使用し、続いて[6] RFC 1213に指定されているMIB-IIを定義するために使用しました。

Later, after the publication of MIB-II, a different approach to the management information definition was taken from the earlier approach of having a single committee staffed by generalists work on a single document to define the Internet-Standard MIB. Rather, many mini-MIB documents were produced in a parallel and distributed fashion by groups chartered to produce a specification for a focused portion of the Internet-Standard MIB and staffed by personnel with expertise in those particular areas ranging from various aspects of network management, to system management, and application management.


3.3. Protocol Operations
3.3. プロトコル動作

The third document, STD 15 [5], describes the SNMPv1 protocol operations performed by protocol data units (PDUs) on lists of variable bindings and describes the format of SNMPv1 messages. The operators defined by SNMPv1 are: get, get-next, get-response, set-request, and trap. Typical layering of SNMP on a connectionless transport service is also defined.

第三の文書は、STD 15 [5]は、変数バインディングのリストのプロトコルデータユニット(PDU)によって実行されるSNMPv1プロトコルの動作を説明し、SNMPv1のメッセージのフォーマットを記述する。 SNMPv1ので定義された事業者は、次のとおり取得するには、Get-次、取得 - 応答、設定要求、およびトラップ。コネクションレスのトランスポートサービス上のSNMPの典型的なレイヤーも定義されています。

3.4. SNMPv1 Security and Administration
3.4. SNMPv1のセキュリティと管理

STD 15 [5] also describes an approach to security and administration. Many of these concepts are carried forward and some, particularly security, are extended by the SNMPv3 Framework.

STD 15 [5]また、セキュリティと管理のアプローチを記載します。これらの概念の多くが引き継がれており、いくつかは、特にセキュリティ、SNMPv3のフレームワークによって拡張されています。

The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP messages between SNMP entities and distinguishes between application entities and protocol entities. In SNMPv3, these are renamed applications and engines, respectively.

SNMPv1フレームワークでは、SNMPエンティティ間のSNMPメッセージでのSNMPv1 PDUのカプセル化について説明し、アプリケーションエンティティとプロトコルエンティティが区別されます。 SNMPv3のでは、これらはそれぞれ、アプリケーションとエンジンが変更されます。

The SNMPv1 Framework also introduces the concept of an authentication service supporting one or more authentication schemes. In addition to authentication, SNMPv3 defines the additional security capability referred to as privacy. (Note: some literature from the security community would describe SNMPv3 security capabilities as providing data integrity, source authenticity, and confidentiality.) The modular nature of the SNMPv3 Framework permits both changes and additions to the security capabilities.

SNMPv1フレームワークでは、1つまたは複数の認証方式をサポートしている認証サービスの概念を導入しています。認証に加えて、SNMPv3は、プライバシーと呼ばれる追加のセキュリティ機能を定義します。 (注意:セキュリティコミュニティからいくつかの文献は、データの整合性、ソースの真正性、機密性を提供するものとしてSNMPv3セキュリティ機能について説明します。)のSNMPv3フレームワークのモジュラー性質は、セキュリティ機能の両方の変更や追加が可能になります。

Finally, the SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control. With this capability, SNMPv3 provides the means for controlling access to information on managed devices.

最後に、SNMPv1フレームワークでは、SNMP MIBビューと呼ばれる概念に基づいたアクセス制御を導入しています。 SNMPv3のフレームワークは、ビューベースのアクセス制御と呼ばれる基本的に同様の概念を指定します。この機能により、SNMPv3は、管理対象デバイス上の情報へのアクセスを制御するための手段を提供します。

However, while the SNMPv1 Framework anticipated the definition of multiple authentication schemes, it did not define any such schemes other than a trivial authentication scheme based on community strings. This was a known fundamental weakness in the SNMPv1 Framework but it was thought at that time that the definition of commercial grade security might be contentious in its design and difficult to get approved because "security" means many different things to different people. To that end, and because some users do not require strong authentication, the SNMPv1 architected an authentication service as a separate block to be defined "later" and the SNMPv3 Framework provides an architecture for use within that block as well as a definition for its subsystems.

SNMPv1フレームワークでは、複数の認証方式の定義を予想しながら、しかし、それはコミュニティストリングに基づいて、些細な認証方式以外の任意のそのようなスキームを定義していませんでした。これは、SNMPv1フレームワークで知られている根本的な弱点だったが、それは、「セキュリティ」は異なる人々に多くの異なるものを意味するので、商用グレードのセキュリティの定義は、承認を得るために、そのデザインで論争と難しいかもしれないその時に考えられていました。そのために、一部のユーザーは、強力な認証を必要としない、SNMPv1のは「後で」に定義されるように、別のブロックとして認証サービスをアーキテクチャおよびSNMPv3 Frameworkはそのブロック内で使用するためのアーキテクチャだけでなく、そのサブシステムの定義を提供しますので、 。

4. The SNMPv2 Management Framework
4. SNMPv2の管理フレームワーク

The SNMPv2 Management Framework is described in [8-13] and coexistence and transition issues relating to SNMPv1 and SNMPv2 are discussed in [15].


SNMPv2 provides several advantages over SNMPv1, including:


* expanded data types (e.g., 64 bit counter)


* improved efficiency and performance (get-bulk operator)


* confirmed event notification (inform operator)


* richer error handling (errors and exceptions)


* improved sets, especially row creation and deletion


* fine tuning of the data definition language


However, the SNMPv2 Framework, as described in these documents, is incomplete in that it does not meet the original design goals of the SNMPv2 project. The unmet goals included provision of security and administration delivering so-called "commercial grade" security with:


* authentication: origin identification, message integrity, and some aspects of replay protection;


* privacy: confidentiality;


* authorization and access control; and


* suitable remote configuration and administration capabilities for these features.


The SNMPv3 Management Framework, as described in this document and the companion documents, addresses these significant deficiencies.


5. The SNMPv3 Working Group
5. SNMPv3のワーキンググループ

This document, and its companion documents, were produced by the SNMPv3 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 Working Group was chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group was to produce the necessary set of documents that provide a single standard for the next generation of core SNMP functions. The single, most critical need in the next generation is a definition of security and administration that makes SNMP-based management transactions secure in a way which is useful for users who wish to use SNMPv3 to manage networks, the systems that make up those networks, and the applications which reside on those systems, including manager-to-agent, agent-to-manager, and manager-to-manager transactions.

このドキュメント、およびその仲間ドキュメントは、Internet Engineering Task Force(IETF)のSNMPv3のワーキンググループによって作成されました。 SNMPv3のワーキンググループは、SNMPの次の世代のための勧告を準備するためにチャーターされました。ワーキンググループの目標は、コアSNMP機能の次世代のための単一の標準を提供した文書の必要なセットを生成することでした。次の世代では、単一の、最も重要な必要性は、ネットワークを管理するためのSNMPv3を使用したいユーザーが、これらのネットワークを構成するシステムに有用な方法でセキュアなSNMPベースの管理の取引を行い、セキュリティと管理の定義ですそしてマネージャ・ツー・エージェント、エージェント - マネージャ、およびマネージャ・ツー・マネージャ取引を含むそれらのシステム上に常駐するアプリケーション。

In the several years prior to the chartering of the Working Group, there were a number of activities aimed at incorporating security and other improvements to SNMP. These efforts included:


* "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353),

1991-1992年頃* "SNMPセキュリティ"(RFC 1351 - RFC 1353)、

* "SMP" circa 1992-1993, and


* "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa 1993-1995 (RFC 1441 - RFC 1452).

(時々 "SNMPv2p" と呼ばれる)* "パーティー・ベースのSNMPv2" 1993年から1995年(RFC 1441 - RFC 1452)年頃。

Each of these efforts incorporated commercial grade, industrial strength security including authentication, privacy, authorization, view-based access control, and administration, including remote configuration.


These efforts fed the development of the SNMPv2 Management Framework as described in RFCs 1902 - 1908. However, the Framework described in those RFCs had no standards-based security and administrative framework of its own; rather, it was associated with multiple security and administrative frameworks, including:

; 1908しかし、これらのRFCに記述フレームワークは何の標準ベースのセキュリティと、独自の管理フレームワークを持っていた - RFCで説明したように、これらの取り組みは、1902年のSNMPv2管理フレームワークの開発を供給しましたむしろ、それを含めて、複数のセキュリティおよび管理フレームワークに関連していました。

* "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901 [16],

* "コミュニティベースのSNMPv2"(SNMPv2cの)RFC 1901年に記載されているように[16]、

* "SNMPv2u" as described in RFCs 1909 and 1910, and

*「SNMPv2u」のRFC 1909および1910で説明したように、そして

* "SNMPv2*."

* "SNMPv2の*。"

SNMPv2c had the most support within the IETF but had no security and administration whereas both SNMPv2u and SNMPv2* had security but lacked a consensus of support within the IETF.

SNMPv2cには、IETF内で最も支援があったが、SNMPv2uとSNMPv2 *の両方のセキュリティを持っていたが、IETF内で支援の合意を欠いていたのに対し、何のセキュリティと管理がありませんでした。

The SNMPv3 Working Group was chartered to produce a single set of specifications for the next generation of SNMP, based upon a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as was suggested by an advisory team which was formed to provide a single recommended approach for SNMP evolution.

シングルを提供するように形成された諮問チームによって提案されたとしてのSNMPv3ワーキンググループは、概念やSNMPv2uとSNMPv2 *の技術要素の収束に基づいて、SNMPの次の世代のための仕様の単一のセットを生成するためにチャーターされましたSNMPの進化のためのアプローチをお勧めします。

In so doing, the Working Group charter defined the following objectives:


* accommodate the wide range of operational environments with differing management demands;


* facilitate the need to transition from previous, multiple protocols to SNMPv3;

* SNMPv3の、前、複数のプロトコルからの移行の必要性を容易にします。

* facilitate the ease of setup and maintenance activities.


In the initial work of the SNMPv3 Working Group, the group focused on security and administration, including:


* authentication and privacy,


* authorization and view-based access control, and


* standards-based remote configuration of the above.


The SNMPv3 Working Group did not "reinvent the wheel", but reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those portions of the design that were outside the focused scope.

SNMPv3のワーキンググループは「車輪の再発明」ませんでしたが、集中範囲外であった設計の部分のために1908年を通じて1902 SNMPv2のドラフト標準の文書、すなわち、RFCを再利用します。

Rather, the primary contributors to the SNMPv3 Working Group, and the Working Group in general, devoted their considerable efforts to addressing the missing link -- security and administration -- and in the process made invaluable contributions to the state-of-the-art of management.

セキュリティと管理 - - むしろ、SNMPv3のワーキンググループへの主要な貢献者、および一般的なワーキンググループは、ミッシングリンクに対処する彼らの多大な努力を捧げ、その過程で最先端のに非常に貴重な貢献をしました経営の。

They produced a design based on a modular architecture with evolutionary capabilities with emphasis on layering. As a result, SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities.


In doing so, the Working Group achieved the goal of producing a single specification which has not only the endorsement of the IETF but also has security and administration.


6. SNMPv3 Framework Module Specifications
6. SNMPv3のフレームワークモジュール仕様

The specification of the SNMPv3 Management Framework is partitioned in a modular fashion among several documents. It is the intention of the SNMPv3 Working Group that, with proper care, any or all of the individual documents can be revised, upgraded, or replaced as requirements change, new understandings are obtained, and new technologies become available.


Whenever feasible, the initial document set which defines the SNMPv3 Management Framework leverages prior investments defining and implementing the SNMPv2 Management Framework by incorporating by reference each of the specifications of the SNMPv2 Management Framework.


The SNMPv3 Framework augments those specifications with specifications for security and administration for SNMPv3.


The documents which specify the SNMPv3 Management Framework follow the same architecture as those of the prior versions and can be organized for expository purposes into four main categories as follows:


* the data definition language,


* Management Information Base (MIB) modules,


* protocol operations, and


* security and administration.


The first three sets of documents are incorporated from SNMPv2. The documents in the fourth set are new to SNMPv3, but, as described previously, build on significant prior related works.


6.1. Data Definition Language
6.1. データ定義言語

The specifications of the data definition language include STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [17], and related specifications. These documents are updates of RFCs 1902 - 1904 [9-11] which have evolved independently from the other parts of the framework and were republished with minor editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted from Draft Standard to full Standard.

データ定義言語の仕様はSTD 58、[17]、及び関連する仕様RFC 2578、「経営情報バージョン2(SMIv2)の構造」を含みます。これらの文書は、RFCの更新である1902年から1904年フレームワークの他の部分から独立して進化したとSTD 58として軽微な編集上の変更で再発行された[9-11]のRFC 2578から2580 [17-19]ドラフト標準から昇格場合フル規格へ。

The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules. Related specifications include STD 58, RFCs 2579, 2580.

管理情報(SMIv2の)の構造は、基本データ型、オブジェクトモデル、およびMIBモジュールを書き込み、修正するための規則を定義します。関連の仕様はSTD 58、RFCの2579年、2580年が含まれます。

STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an initial set of shorthand abbreviations which are available for use within all MIB modules for the convenience of human readers and writers.

STD 58、RFC 2579、「SMIv2のためのテキストの表記法」[18]、ヒトリーダーとライターの便宜のために、すべてのMIBモジュール内で使用可能な速記の略語の最初のセットを定義します。

STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines the format for compliance statements which are used for describing requirements for agent implementations and capability statements which can be used to document the characteristics of particular implementations.

STD 58、RFC 2580、「SMIv2のための順応文」[19]は、特定の実装の特徴を文書化するために使用することができるエージェントの実装と機能文の要件を記述するために使用されるコンプライアンスステートメントの形式を定義します。

The term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.

用語のユーザーが、それは、少なくとも2つの異なる意味を持っているつもりので、用語「SMIv2のは」やや曖昧です。他の時にはこの曖昧さは不幸であるRFC 2578で定義されたデータ定義言語の一部のみを指すのに使用されるのに対し、2580 - 時々用語のRFC 2578の中で集合的に定義されたSTD 58の全体のデータ定義言語を指すのに使用されますしかし、実際には大きな問題はめったにありません。

6.2. MIB Modules
6.2. MIBモジュール

MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements specified in terms of appropriate object and event notification groups. As such, MIB modules define the management information maintained by the instrumentation in managed nodes, made remotely accessible by management agents, conveyed by the management protocol, and manipulated by management applications.


MIB modules are defined according to the rules defined in the documents which specify the data definition language, principally the SMI as supplemented by the related specifications.


There is a large and growing number of standards-track MIB modules, as defined in the periodically updated "Internet Official Protocol Standards" list [20]. As of this writing, there are more than 100 standards-track MIB modules with a total number of defined objects exceeding 10,000. In addition, there is an even larger and growing number of enterprise-specific MIB modules defined unilaterally by various vendors, research groups, consortia, and the like resulting in an unknown and virtually uncountable number of defined objects.


In general, management information defined in any MIB module, regardless of the version of the data definition language used, can be used with any version of the protocol. For example, MIB modules defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management Framework and can be conveyed by the protocols specified therein. Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be conveyed by it. However, there is one noteworthy exception: the Counter64 datatype which can be defined in a MIB module defined in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol engine. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but cannot be conveyed by an engine which exclusively supports SNMPv1.

一般に、任意のMIBモジュールで定義された管理情報は、関係なく使用されるデータ定義言語のバージョンのプロトコルのすべてのバージョンで使用することができます。例えば、SNMPv1のSMI(でSMIv1)の観点で定義されたMIBモジュールは、SNMPv3の管理フレームワークと互換性があり、その中に指定されたプロトコルによって搬送することができます。また、SNMPv2のSMI(SMIv2の)に関して定義されたMIBモジュールは、SNMPv1プロトコル操作と互換性があり、それによって搬送することができます。 SMIv2の形式で定義されたMIBモジュールで定義することができるが、SNMPv1プロトコルエンジンによって搬送することができないCounter64のデータ型:しかしながら、注目すべき例外があります。それはSNMPv2のか、SNMPv3エンジンによって搬送することができますが、排他的にSNMPv1のをサポートしてエンジンによって搬送することができません。

6.3. Protocol Operations and Transport Mappings
6.3. プロトコル操作とトランスポートマッピング

The specifications for the protocol operations and transport mappings of the SNMPv3 Framework are incorporated by reference to the two SNMPv2 Framework documents which have subsequently been updated.


The specification for protocol operations is found in STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21].

プロトコル操作のための仕様は、「簡易ネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2」[21]、STD 62、RFC 3416に見出されます。

The SNMPv3 Framework is designed to allow various portions of the architecture to evolve independently. For example, it might be possible for a new specification of protocol operations to be defined within the Framework to allow for additional protocol operations.


The specification of transport mappings is found in STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22].

トランスポートマッピングの仕様はSTD 62、RFC 3417で発見され、「簡易ネットワーク管理プロトコル(SNMP)のためのマッピングを輸送します」[22]。

6.4. SNMPv3 Security and Administration
6.4. SNMPv3のセキュリティと管理

The document series pertaining to SNMPv3 Security and Administration defined by the SNMPv3 Working Group consists of seven documents at this time:


RFC 3410, "Introduction and Applicability Statements for the Internet-Standard Management Framework", which is this document.

RFC 3410、この文書で、「インターネット標準の管理フレームワークのための序論と適用性声明」。

STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], describes the overall architecture with special emphasis on the architecture for security and administration.

STD 62、RFC 3411には、「簡易ネットワーク管理プロトコル(SNMP)管理フレームワークを記述するためのアーキテクチャは、」[23]は、セキュリティと管理のためのアーキテクチャ上の特別な重点を置いて、全体的なアーキテクチャについて説明します。

STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the possibility of multiple message processing models and the dispatcher portion that can be a part of an SNMP protocol engine.

STD 62、RFC 3412、「メッセージ処理と簡易ネットワーク管理プロトコル(SNMP)のためのディスパッチ」[24]は、複数のメッセージ処理モデルおよびSNMPプロトコルエンジンの一部とすることができるディスパッチャ部分の可能性を記載しています。

STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25], describes the five initial types of applications that can be associated with an SNMPv3 engine and their elements of procedure.

STD 62、RFC 3413、「簡易ネットワーク管理プロトコル(SNMP)アプリケーション」[25]は、5つの初期SNMPv3エンジンと関連付けることができるアプリケーションの種類や手続きの彼らの要素について説明します。

STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)" [26], describes the threats against which protection is provided, as well as the mechanisms, protocols, and supporting data used to provide SNMP message-level security with the user-based security model.

STD 62、RFC 3414、「簡易ネットワーク管理プロトコル(SNMPv3の)のバージョン3のためのユーザベースセキュリティモデル(USM)」[26]、保護が提供され、これに対して脅威だけでなく、メカニズム、プロトコルを記述し、ユーザベースのセキュリティモデルと、SNMPメッセージレベルのセキュリティを提供するために使用されるデータをサポートします。

STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.

STD 62、RFC 3415、「簡易ネットワーク管理プロトコル(SNMP)のためのビューベースアクセス制御モデル(VCAM)」[27]は、ビューベースのアクセス制御は、コマンド応答者と通知創始アプリケーション内で適用する方法について説明します。

RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework, and is in the process of being updated by a Work in Progress.

RFC 2576、「SNMPv3の共存と移行」[28]は、SNMPv3の管理フレームワーク、SNMPv2の管理フレームワーク、及びオリジナルのSNMPv1管理フレームワークとの間の共存を説明し、そして進行中の作業によって更新中です。

7. Document Summaries

The following sections provide brief summaries of each document with slightly more detail than is provided in the overviews above.


7.1. Structure of Management Information
7.1. 経営情報の構造

Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written in the SNMP data definition language, which evolved from an adapted subset of OSI's Abstract Syntax Notation One (ASN.1) [29] language. STD 58, RFCs 2578, 2579, 2580, collectively define the data definition language, specify the base data types for objects, specify a core set of short-hand specifications for data types called textual conventions, and specify a few administrative assignments of object identifier (OID) values.

管理情報は、仮想インフォメーションストアに存在する、管理対象オブジェクトのコレクションとして表示され、管理情報ベース(MIB)と呼ばれます。関連するオブジェクトのコレクションは、MIBモジュールで定義されています。これらのモジュールは、OSIの抽象構文記法1(ASN.1)[29]言語の適合サブセットから進化したSNMPデータ定義言語で書かれています。 STD 58のRFC 2578、2579、2580は、集合的に、オブジェクトの基本データ・タイプを指定し、データ定義言語を定義するテキストの表記法と呼ばれるデータ・タイプの短手仕様のコアセットを指定し、オブジェクト識別子のいくつかの管理の割り当てを指定します(OID)値。

The SMI is divided into three parts: module definitions, object definitions, and notification definitions.


(1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the semantics of an information module.

情報モジュールを記述する場合、(1)モジュールの定義が使用されます。 ASN.1マクロMODULE-IDENTITYは、簡潔に情報モジュールの意味を伝えるために使用されます。

(2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax and semantics of a managed object.

管理オブジェクトを記述する場合(2)オブジェクトの定義が使用されます。 ASN.1マクロ、OBJECT-TYPEは、簡潔に、管理オブジェクトの構文とセマンティクスを伝えるために使用されます。

(3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to convey concisely the syntax and semantics of a notification.

管理情報の迷惑送信を記述する場合(3)通知定義が使用されます。 ASN.1マクロ、NOTIFICATION-TYPEは、簡潔に通知の構文とセマンティクスを伝えるために使用されます。

As noted earlier, the term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer to the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.

先に述べたように、用語のユーザは、少なくとも2つの異なる意味を持っていることを意図しているため、用語「SMIv2のは」やや曖昧です。他の時にはこの曖昧さは、RFC 2578で定義されたデータ定義言語の一部のみを指すのに使用されるのに対し、2580 - 時々用語のRFC 2578の中で集合的に定義されたSTD 58の全体のデータ定義言語を指すのに使用されます不幸しかし、実際にはほとんど重大な問題ではありません。

7.1.1. Base SMI Specification
7.1.1. ベースSMI仕様

STD 58, RFC 2578 specifies the base data types for the data definition language, which include: Integer32, enumerated integers, Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to several object identifiers. STD 58, RFC 2578 further defines the following constructs of the data definition language:

構文Integer32、列挙された整数、Unsigned32の、Gauge32、Counter32の、Counter64の、時間刻み、INTEGER、オクテット文字列、オブジェクト識別子、IPアドレス、不透明、およびBITSを:STD 58は、RFC 2578には、データ定義言語の基本データ型を、指定します。それはまた、いくつかのオブジェクト識別子に値を割り当てます。 STD 58、RFC 2578は、データ定義言語の次の構成を定義します。

* IMPORTS to allow the specification of items that are used in a MIB module, but defined in another MIB module.

* MIBモジュールで使用されるが、他のMIBモジュールで定義されているアイテムの指定を可能にするためにインポートします。

* MODULE-IDENTITY to specify for a MIB module a description and administrative information such as contact and revision history.

* MODULE-IDENTITYは、接触と改訂履歴としてMIBモジュールの説明および管理情報を指定します。

* OBJECT-IDENTITY and OID value assignments to specify an OID value.

* OBJECT-IDENTITYとOID値の割り当ては、OID値を指定します。

* OBJECT-TYPE to specify the data type, status, and the semantics of managed objects.

* OBJECT-TYPEは、データタイプ、ステータス、および管理対象オブジェクトのセマンティクスを指定します。

* SEQUENCE type assignment to list the columnar objects in a table.

* SEQUENCEタイプの割り当ては、テーブル内の円柱状のオブジェクトを一覧表示します。

* NOTIFICATION-TYPE construct to specify an event notification.

* NOTIFICATION-TYPEイベント通知を指定するには、構築します。

7.1.2. Textual Conventions
7.1.2. テキストの表記法

When designing a MIB module, it is often useful to specify, in a short-hand way, the semantics for a set of objects with similar behavior. This is done by defining a new data type using a base data type specified in the SMI. Each new type has a different name, and specifies a base type with more restrictive semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading a MIB module and potentially by "intelligent" management applications. It is the purpose of STD 58,

MIBモジュールを設計するとき、短い手のやり方で、同様の振る舞いを持つオブジェクトのセットのためのセマンティクスを指定することが有用であることが多いです。これは、SMIで指定された基本データ型を使用して、新しいデータ型を定義することによって行われます。それぞれの新しいタイプは、別の名前を持っており、より限定的なセマンティクスで基本型を指定します。これらの新たに定義されたタイプは、原文のコンベンションと呼ばれて、MIBモジュールを読んだ人間の便宜のために、潜在的に「インテリジェント」管理アプリケーションで使用されています。これは、STD 58の目的です、

RFC 2579, Textual Conventions for SMIv2 [18], to define the construct, TEXTUAL-CONVENTION, of the data definition language used to define such new types and to specify an initial set of textual conventions available to all MIB modules.

このような新しいタイプを定義し、すべてのMIBモジュールに利用可能なテキスト表記の最初のセットを指定するために使用されるデータ定義言語のテキストの表記法を、構築物を規定するRFC 2579、SMIv2のためのテキストの表記法[18]。

7.1.3. Conformance Statements
7.1.3. 適合性宣言

It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of STD 58, RFC 2580, Conformance Statements for SMIv2 [19], to define the constructs of the data definition language used for these purposes. There are two kinds of constructs:

それを達成実装の実際のレベルと共に、実装の許容される低境界を定義することが有用であり得ます。これは、これらの目的のために使用されるデータ定義言語の構文を定義するために、SMIv2の[19]のための適合性宣言、STD 58、RFC 2580の目的です。コンストラクトの2種類があります。

(1) Compliance statements are used when describing requirements for agents with respect to object and event notification definitions. The MODULE-COMPLIANCE construct is used to convey concisely such requirements.

(1)オブジェクトに対してエージェントイベント通知の定義の要件を記述する際にコンプライアンスステートメントが使用されています。 MODULEコンプライアンス構築物を、簡潔な要件を伝えるために使用されます。

(2) Capability statements are used when describing capabilities of agents with respect to object and event notification definitions. The AGENT-CAPABILITIES construct is used to convey concisely such capabilities.

オブジェクトとイベント通知定義に対する薬剤の能力を記述する場合(2)機能ステートメントが使用されます。 AGENT-CAPABILITIES構築物は、簡潔な能力を伝えるために使用されます。

Finally, collections of related objects and collections of related event notifications are grouped together to form a unit of conformance. The OBJECT-GROUP construct is used to convey concisely the objects in and the semantics of an object group. The NOTIFICATION-GROUP construct is used to convey concisely the event notifications in and the semantics of an event notification group.

最後に、関連するオブジェクトと関連するイベント通知のコレクションのコレクションは、適合性のユニットを形成するために一緒にグループ化されます。オブジェクト・グループの構築物は簡潔でオブジェクトとオブジェクトグループの意味論を伝えるために使用されます。 NOTIFICATION-GROUP構築物は、簡潔でイベント通知やイベント通知グループの意味を伝えるために使用されます。

7.2. Protocol Operations
7.2. プロトコル動作

The management protocol provides for the exchange of messages which convey management information between the agents and the management stations. The form of these messages is a message "wrapper" which encapsulates a Protocol Data Unit (PDU).


It is the purpose of STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21], to define the operations of the protocol with respect to the sending and receiving of the PDUs.

これは、送信とPDUの受信に対してプロトコルの動作を定義するために、「簡易ネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2」、[21] STD 62、RFC 3416の目的です。

7.3. Transport Mappings
7.3. 交通のマッピング

SNMP messages may be used over a variety of protocol suites. It is the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22], to define how SNMP messages

SNMPメッセージは、プロトコル・スイートのさまざま上で使用することができます。それはどのようにSNMPメッセージを定義するには、「簡易ネットワーク管理プロトコル(SNMP)のための輸送マッピング」、[22] STD 62、RFC 3417の目的です

map onto an initial set of transport domains. Other mappings may be defined in the future.


Although several mappings are defined, the mapping onto UDP is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for proxy service to the UDP mapping.


7.4. Protocol Instrumentation
7.4. プロトコル計装

It is the purpose of STD 62, RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)" [30], to define managed objects which describe the behavior of portions of an SNMP entity.

これは、SNMPエンティティの部分の挙動を記述する管理オブジェクトを定義するために、STD 62の目的は、RFC 3418、「簡易ネットワーク管理プロトコル(SNMP)管理情報ベース(MIB)」[30]です。

7.5. Architecture / Security and Administration
7.5. アーキテクチャ/セキュリティと管理

It is the purpose of STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], to define an architecture for specifying Management Frameworks. While addressing general architectural issues, it focuses on aspects related to security and administration. It defines a number of terms used throughout the SNMPv3 Management Framework and, in so doing, clarifies and extends the naming of:

これは、管理フレームワークを指定するためのアーキテクチャを定義するために、[23]、「簡易ネットワーク管理プロトコル(SNMP)管理フレームワークを記述するためのアーキテクチャ」STD 62、RFC 3411の目的です。一般的なアーキテクチャの問題に対処するが、それはセキュリティと管理に関連する側面に焦点を当てています。これは、SNMPv3の管理フレームワーク全体で使用される用語の数を定義し、そうすることで、明確にし、の命名を拡張します。

* engines and applications,


* entities (service providers such as the engines in agents and managers),


* identities (service users), and


* management information, including support for multiple logical contexts.


The document contains a small MIB module which is implemented by all authoritative SNMPv3 protocol engines.


7.6. Message Processing and Dispatch (MPD)
7.6. メッセージの処理と派遣(MPD)

STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.

STD 62、RFC 3412、「メッセージ処理と簡単なネットワーク管理プロトコル(SNMP)のためにディスパッチ」[24]は、メッセージ処理を説明し、SNMPアーキテクチャ内でSNMPメッセージのために派遣します。これは、適切なSNMPメッセージ処理モデルにSNMPメッセージの潜在的に複数のバージョンをディスパッチするため、およびSNMPアプリケーションにPDUをディスパッチするための手順を定義します。 SNMPv3のメッセージ処理モデル - この文書は、一つのメッセージ処理モデルについて説明します。

An SNMPv3 protocol engine MUST support at least one Message Processing Model. An SNMPv3 protocol engine MAY support more than one, for example in a multi-lingual system which provides simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c. For example, such a tri-lingual system which provides simultaneous support for SNMPv1, SNMPv2c, and SNMPv3 supports three message processing models.

SNMPv3プロトコルエンジンは、少なくとも1つのメッセージ処理モデルをサポートしなければなりません。 SNMPv3プロトコルエンジンは、SNMPv3のとSNMPv1および/またはSNMPv2cの同時サポートを提供する多言語システムでは、例えば、1つ以上をサポートするかもしれません。例えば、SNMPv1、SNMPv2c、およびSNMPv3に対する同時サポートを提供トリ言語システムは、3つのメッセージ処理モデルをサポートします。

7.7. SNMP Applications
7.7. SNMPアプリケーション

It is the purpose of STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25] to describe the five types of applications which can be associated with an SNMP engine. They are: Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.

SNMPエンジンと関連付けることができる5種類のアプリケーションを記述するためにSTD 62の目的は、RFC 3413、「簡易ネットワーク管理プロトコル(SNMP)アプリケーション」[25]です。彼らは以下のとおりです。コマンドジェネレータ、コマンド応答者、通知のオリジネーター、通知レシーバー、およびプロキシフォワーダ。

The document also defines MIB modules for specifying targets of management operations (including notifications), for notification filtering, and for proxy forwarding.


7.8. User-based Security Model (USM)
7.8. ユーザベースセキュリティモデル(USM)

STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" [26] describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security.

「簡易ネットワーク管理プロトコル(SNMPv3の)のバージョン3のためのユーザベースセキュリティモデル(USM)」STD 62、RFC 3414、[26]はSNMPv3のユーザベースセキュリティモデルを記述する。これは、SNMPメッセージレベルのセキュリティを提供するための手順の要素を定義します。

The document describes the two primary and two secondary threats which are defended against by the User-based Security Model. They are: modification of information, masquerade, message stream modification, and disclosure.


The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data integrity:

USMは、MD5 [31]とセキュアハッシュアルゴリズム[33]データの整合性を提供するために計算を消化するための[32]などのキー付きハッシュアルゴリズムを利用します。

* to directly protect against data modification attacks,


* to indirectly provide data origin authentication, and


* to defend against masquerade attacks.


The USM uses loosely synchronized monotonically increasing time indicators to defend against certain message stream modification attacks. Automatic clock synchronization mechanisms based on the protocol are specified without dependence on third-party time sources and concomitant security considerations.


The USM uses the Data Encryption Standard (DES) [34] in the cipher block chaining mode (CBC) if disclosure protection is desired. Support for DES in the USM is optional, primarily because export and usage restrictions in many countries make it difficult to export and use products which include cryptographic technology.

開示保護が所望される場合USMは、暗号ブロック連鎖方式(CBC)にデータ暗号化規格(DES)[34]を使用します。 USMにおけるDESのサポートは、多くの国の輸出と使用制限は、それが困難な暗号化技術が含まれる製品を輸出して使用するように作る主な理由、オプションです。

The document also includes a MIB suitable for remotely monitoring and managing the configuration parameters for the USM, including key distribution and key management.


An entity may provide simultaneous support for multiple security models as well as multiple authentication and privacy protocols. All of the protocols used by the USM are based on pre-placed keys, i.e., private key mechanisms. The SNMPv3 architecture permits the use of symmetric and asymmetric mechanisms and protocols (asymmetric mechanisms are commonly called public key cryptography) but, as of this writing, there are no SNMPv3 security models on the IETF standards track that use public key cryptography.

エンティティは、複数のセキュリティモデルを同時にサポートだけでなく、複数の認証とプライバシープロトコルを提供することができます。 USMによって使用されるプロトコルの全ては、予め配置されたキー、すなわち秘密鍵のメカニズムに基づいています。 SNMPv3アーキテクチャは、これを書いているとして、公開鍵暗号を使用するIETF標準トラックにはSNMPv3セキュリティモデルが存在しない、対称および非対称のメカニズムとプロトコルの使用を許可する(非対称のメカニズムは、一般的に、公開鍵暗号方式と呼ばれている)が、。

Work is underway to specify how AES is to be used within the User-based Security Model (USM). This will be a separate document.


7.9. View-based Access Control (VACM)
7.9. ビューベースアクセス制御(VACM)

The purpose of STD 62, RFC 3415, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], is to describe the View-based Access Control Model for use in the SNMP architecture. The VACM can simultaneously be associated in a single engine implementation with multiple Message Processing Models and multiple Security Models.

STD 62の目的は、RFC 3415、「簡易ネットワーク管理プロトコル(SNMP)のためのビューベースアクセス制御モデル(VACM)」[27]は、SNMPアーキテクチャで使用するためにビューベースアクセス制御モデルを記述することです。 VACMは、同時に複数のメッセージ処理モデルと、複数のセキュリティモデルを備えた単一エンジンの実装に関連することができます。

It is architecturally possible to have multiple, different, Access Control Models active and present simultaneously in a single engine implementation, but this is expected to be *_very_* rare in practice and *_far_* less common than simultaneous support for multiple Message Processing Models and/or multiple Security Models.

単一エンジンの実装で同時にアクティブと存在する複数の、異なる、アクセス制御モデルを持っているアーキテクチャも可能であるが、これは実際には稀で、複数のメッセージ処理モデルを同時にサポートより* _far_ *あまり一般的_very_ *を*されることが期待されると/または複数のセキュリティモデル。

7.10. SNMPv3 Coexistence and Transition
7.10. SNMPv3の共存と移行

The purpose of RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework" [28], is to describe coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework. In particular, this document describes four aspects of coexistence:

RFC 2576の目的は、「バージョン1、バージョン2の間の共存、およびインターネット標準ネットワーク管理フレームワークのバージョン3」[28]は、SNMPv3の管理フレームワーク、SNMPv2の管理フレームワーク、及びオリジナルのSNMPv1との間の共存を説明することです管理フレームワーク。特に、このドキュメントは、共存の4つの側面について説明します。

* Conversion of MIB documents from SMIv1 to SMIv2 format


* Mapping of notification parameters


* Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network, in particular the processing of protocol operations in multi-lingual implementations, as well as behavior of proxy implementations


* The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c into the View-Based Access Control Model (VACM) [27]


8. Standardization Status

Readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to determine the standardization status of any document.

読者は、任意の文書の標準化の状態を判断するためには、「Internet Official Protocol Standards」リスト[20]の最新バージョンを相談してください。

However, the SNMPv3 Working Group explicitly requested that text be included in this document to amplify on the status of SMIv1, SNMPv1, and SNMPv2c.


8.1. SMIv1 Status
8.1. でSMIv1ステータス

SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to full Standard status in 1990 and has remained a Standard even after SMIv2 reached full Standard (see RFC 2026 [35] for more information about the Internet Standards Process). In many cases, a Standard is declared "Historic" when its replacement reaches full Standard. For example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached full Standard. Similarly, when SMIv2 reached full Standard, it might have been reasonable at that time to retire SMIv1 and declare it to be "Historic" but as the result of a conscious decision, STD 16, RFCs 1155 and 1212 continue to have the standardization status of full "Standard" but are not recommended. These documents were not declared "Historic" and remain on the standards track because they provide normative references for other documents on the standards track and cannot be declared "Historic" without rendering the documents which rely on them to also become "Historic". Consequently, STD 16 retains its standardization status but is not recommended because it has been superseded by the newer SMIv2 specifications which are identified somewhat later in this document.

でSMIv1は、STD 16、RFC 1155とRFC 1212に記載されているように、1990年に完全な標準状態に昇格し、SMIv2のがフル標準(インターネット標準化過程の詳細は、RFC 2026 [35]参照)に達した後でも、標準のままでいます。その交換が完全な標準に達したとき、多くの場合、標準では「歴史的」と宣言されます。 MIB-2 [6]フル標準に達したとき、例えば、MIB-1 [8]、 "歴史" と宣言しました。同様のSMIv2がフル標準に達したとき、それはでSMIv1を引退し、「歴史的」であることを、それを宣言するために、その時点で合理的であったかもしれないが、意識的な決断、STD 16の結果として、RFC 1155とRFC 1212は、標準化の状態を持ち続けます完全な「標準」が、推奨されていません。これらの文書は「歴史的」と宣言し、それらが標準トラック上の他の文書のための規範的な参照を提供し、また、「歴史的」になるためにそれらに依存しているドキュメントをレンダリングすることなく、「歴史的」と宣言することはできませんので、基準がトラック上に残っていませんでした。その結果、STD 16は、その標準化の状態を保持するが、それは、この文書でやや後に識別され、新しいSMIv2の仕様に取って代わられているのでお勧めしません。

On a pragmatic level, since about 1993 it has been wise for users of the data definition language to use SMIv2 for all new work because the realities of the marketplace have occasionally required the support of data definitions in both the SMIv1 and SMIv2 formats. While there are tools widely available at low cost or no cost to translate SMIv2 definitions to SMIv1 definitions, it is impractical to build automatic tools that automatically translate SMIv1 definitions to SMIv2 definitions. Consequently, if one works in primarily SMIv2, the cost of providing data definitions in both SMIv1 and SMIv2 formats is trivial. In contrast, if one works primarily in SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is significantly more expensive. The market requirements today for providing data definitions in SMIv1 format are greatly diminished when compared to those of 1993, and SMIv2 continues to be the strongly preferred format even though SMIv1 has not been declared "Historic". Indeed, the IETF currently requires that new MIB modules be written using SMIv2.

市場の現実が時折両方でSMIv1とSMIv2のフォーマットのデータ定義のサポートを必要としているので、実用的なレベルでは、およそ1993年以来、それはすべての新しい仕事のためのSMIv2を使用するには、データ定義言語のユーザーのための賢明されています。でSMIv1定義にSMIv2の定義を翻訳する低コストまたは無償で広く利用可能なツールがありますが、自動的にSMIv2の定義にでSMIv1定義を翻訳自動ツールを構築することは非現実的です。 1は主にSMIv2の中で動作するかどうかしたがって、両方でSMIv1とSMIv2のフォーマットでデータ定義を提供するコストは自明です。 1がでSMIv1とSMIv2の両方にデータ定義を提供し、主にでSMIv1フォーマットで動作するかどうかは対照的に、かなり高価です。 1993年のものと比較した場合、でSMIv1形式のデータ定義を提供するため、市場の要件今日は大幅に減少している、とSMIv2のはでSMIv1は「歴史的」と宣言されていないにもかかわらず、非常に好ましい形式であり続けています。確かに、IETFは現在、新しいMIBモジュールがSMIv2のを使用して書かれている必要があります。

8.2. SNMPv1 and SNMPv2 Standardization Status
8.2. SNMPv1とSNMPv2の標準化動向

Protocol operations via SNMPv1 and SNMPv2c message wrappers support only trivial authentication based on plain-text community strings and, as a result, are fundamentally insecure. When the SNMPv3 specifications for security and administration, which include strong security, reached full Standard status, the full Standard SNMPv1, formerly STD 15 [5], and the experimental SNMPv2c specifications described in RFC 1901 [16] were declared Historic due to their weaknesses with respect to security and to send a clear message that the third version of the Internet Standard Management Framework is the framework of choice. The Party-based SNMPv2 (SNMPv2p), SNMPv2u, and SNMPv2* were either declared Historic circa 1995 or were never on the standards track.

SNMPv1およびSNMPv2cのメッセージラッパーを介したプロトコル操作はプレーンテキストのコミュニティストリングに基づいてのみ些細な認証をサポートして、その結果として、基本的に安全ではありません。強力なセキュリティを含むセキュリティおよび管理のためのSNMPv3の仕様は、完全な標準状態に達したとき、完全な標準のSNMPv1、以前STD 15 [5]、およびRFC 1901年に記載された実験SNMPv2cの仕様[16]、それらの弱点に歴史的に宣言されましたセキュリティに関しては、インターネット標準管理フレームワークの3番目のバージョンは、選択したフレームワークである明確なメッセージを送信します。パーティー・ベースのSNMPv2(SNMPv2p)、SNMPv2u、およびSNMPv2 *は、いずれかであった歴史的な年頃1995を宣言したり標準化過程の上ことはありませんでした。

On a pragmatic level, it is expected that a number of vendors will continue to produce and users will continue to deploy and use multi-lingual implementations that support SNMPv1 and/or SNMPv2c as well as SNMPv3. It should be noted that the IETF standards process does not control actions of vendors or users who may choose to promote or deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of known short-comings. However, it is not expected that vendors will produce nor that users will deploy multi-lingual implementations that support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*.

実用レベルでは、多くのベンダーが生産し続け、ユーザーが展開およびSNMPv1および/またはSNMPv2cのと同様のSNMPv3をサポートする多言語の実装を使用し続けることが予想されます。 IETFの標準化プロセスは、既知の短欠点にもかかわらず、促進や、SNMPv1とSNMPv2cのよう歴史的なプロトコルを展開することもできますベンダーやユーザーの行動を制御しないことに留意すべきです。しかし、ベンダーが生成されることも、ユーザーが党ベースSNMPv2p(SNMPv2p)、SNMPv2u、またはSNMPv2の*をサポートする多言語の実装を展開することが期待されていません。

Indeed, as described above, one of the SNMPv3 specifications for security and administration, RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Management Framework [28], addresses these issues.

上述のように実際に、バージョン1、バージョン2、及びインターネット標準管理フレームワーク[28]のバージョン3との間のセキュリティと管理、RFC 2576、共存のためのSNMPv3仕様の1つは、これらの問題に対処します。

Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to insure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization's security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly equivalent from a security point of view. For example, it is probably unwise to allow SNMPv1 or SNMPv2c a greater level of access than is provided to unauthenticated SNMPv3 users, e.g., it does not make sense to guard the front door with armed guards, trained attack dogs, moats and drawbridges while providing unfettered access through an open back door.


The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited capabilities for administering the SNMPv1 and SNMPv2c protocols. For example, there are no objects defined to view and configure communities or destinations for notifications (traps and informs). The result has been vendor defined mechanisms for administration that range from proprietary format configuration files that cannot be viewed or configured via SNMP to enterprise specific object definitions. The SNMPv3 framework provides a rich standards-based approach to administration which, by design, can be used for the SNMPv1 and SNMPv2c protocols. Thus, to foster interoperability of administration of SNMPv1 and SNMPv2c protocols in multi-lingual systems, the mechanisms and objects specified in [25], [27], and [28] should be used to supplement or replace the equivalent proprietary mechanisms.

SNMPv1のフレームワーク、SNMPv2のフレームワーク、およびSNMPv2cは、SNMPv1とSNMPv2cプロトコルを管理するための限られた能力を持っていました。たとえば、表示および通知(トラップおよび情報)のためのコミュニティや目的地を設定するために定義されたオブジェクトがありません。結果は、ベンダー企業、特定のオブジェクト定義にSNMPを介して表示したり設定することができない独自の形式のコンフィギュレーションファイルの範囲で投与するためのメカニズムが定義されています。 SNMPv3フレームワークは、設計により、SNMPv1とSNMPv2cのプロトコルのために使用することができる管理に豊富な標準ベースのアプローチを提供します。したがって、多言語システムでのSNMPv1およびSNMPv2cプロトコルの投与の相互運用性を促進するために、機構およびオブジェクト[25]で指定された、[27]及び[28]補完または同等の独自のメカニズムを置換するために使用されるべきです。

8.3. Working Group Recommendation
8.3. 作業部会の勧告

Based on the explanations above, the SNMPv3 Working Group recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as Historical documents.


9. Security Considerations

As this document is primarily a roadmap document, it introduces no new security considerations. The reader is referred to the relevant sections of each of the referenced documents for information about security considerations.


10. References
10.1. Normative References
10.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

10.2. Informative References
10.2. 参考文献

[2] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.

[2]サーフ、V.、 "インターネットネットワークマネージメント規格の開発のためのIABの提言"、RFC 1052、1988年4月。

[3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.

[3]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990月。

[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.

[4]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。

[5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.

[5]ケース、J.、ヒョードル、M.、Schoffstall、M.およびデーヴィン、J.、 "簡易ネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。

[6] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.

[6] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース:MIB-II"、STD 17、RFC 1213、1991年3月。

[7] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.

[7]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。

[8] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, March 1990.

[8] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース"、RFC 1156、1990年3月を。

[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.

[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造"、RFC 1902、1996年1月。

[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[10]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1903、1996年1月 "簡易ネットワーク管理プロトコル(SNMPv2)のバージョン2のためのテキストの表記法"。

[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.

[11]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1904、1996年1月 "簡易ネットワーク管理プロトコル(SNMPv2)のバージョン2のための順応文"。

[12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[12]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作(SNMPv2の)"、RFC 1905、1996年1月。

[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[13]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル(SNMPv2)のバージョン2のためのトランスポートマッピング"、1996年1月。

[14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.

[14]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2の)"、RFC 1907、1996年1月。

[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-Standard Network Management Framework", RFC 2576, January 1996.

[15]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "バージョン1およびインターネット標準ネットワーク管理フレームワークのバージョン2の間の共存"、RFC 2576、1996年1月。

[16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.

[16]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。

[17] 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.

[17] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2(SMIv2)の構造"、STD 58、RFC 2578、 1999年4月。

[18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[18] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。

[19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[19] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。

[20] "Official Internet Protocol Standards", also STD0001.

[20] "公式のインターネットプロトコル標準"、もSTD0001。

[21] 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.

[21] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡易ネットワーク管理プロトコル(SNMP)のためのプロトコル操作のバージョン2"、STD 62、RFC 3416 、2002年12月。

[22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.

[22] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "トランスポートマッピングのSNMP(Simple Network Management Protocol)について"、STD 62、RFC 3417、2002年12月。

[23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.

[23]ハリントン、D.、PresuhnとR.とB. Wijnen、 "簡易ネットワーク管理プロトコル(SNMP)管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。

[24] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.

[24]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル(SNMP)のための派遣"、STD 62、RFC 3412、2002年12月。

[25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.

[25]レビ、D.、マイヤー、P.とB.スチュワート、 "簡易ネットワーク管理プロトコル(SNMP)アプリケーション"、STD 62、RFC 3413、2002年12月。

[26] Blumenthal, U. and B. Wijnen, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

、STD 62、RFC 3414、2002年12月[26]ブルーメンソール、U.とB. Wijnenの、 "簡易ネットワーク管理プロトコル(SNMPv3の)のバージョン3のためのユーザベースセキュリティモデル(USM)"。

[27] 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.

[27] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "ビューベースアクセス制御モデル(VACM)簡易ネットワーク管理プロトコル(SNMP)のために"、STD 62、RFC 3415、2002年12月。

[28] 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.

[28]フライ、R.、レヴィ、D.、Routhier、S.およびB. Wijnenの、 "バージョン1、バージョン2、およびインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、RFC 2576、2000年3月。

[29] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).

[29]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1(ASN.1)、国際標準化機構の仕様。国際標準8824、(12月、1987)。

[30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.

、STD 62、RFC 3418 "簡易ネットワーク管理プロトコル(SNMP)管理情報ベース(MIB)" [30] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 、2002年12月。

[31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.

[31]リベスト、R.、 "メッセージダイジェストアルゴリズムMD5"、RFC 1321、1992年4月。

[32] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) (ASCII) (Postscript)

[32]セキュア・ハッシュ・アルゴリズム。 NIST FIPS 180-1、(1995年4月)ポストスクリプト)

[33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[33] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC:メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。

[34] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988).

[34]データ暗号化規格、アメリカ国立標準技術研究所。連邦情報処理標準(FIPS)出版46-1。 FIPS出版46、(;再確認1988年1月、1月、1977年)よりも優先されます。

[35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October, 1996.

[35]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。

11. Editors' Addresses

Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA

ジェフリーケースSNMPリサーチ社3001キンバリンハイツロードノックスビル、テネシー州37920から9716 USA

Phone: +1 865 573 1434 EMail:

電話:+1 865 573 1434 Eメール

Russ Mundy Network Associates Laboratories 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA

ラスマンディネットワークアソシエイツ研究所15204オメガドライブ、スイート300ロックビル、MD 20850から4601 USA

Phone: +1 301 947 7107 EMail:

電話:+1 301 947 7107 Eメール

David Partain Ericsson P.O. Box 1248 SE-581 12 Linkoping Sweden

デビッドパーテインエリクソン私書箱ボックス1248 SE-581 12リンシェーピングスウェーデン

Phone: +46 13 28 41 44 EMail:

電話:+46 13 28 41 44 Eメール

Bob Stewart Retired


12. 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.






Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。