RFC2851 日本語訳
2851 Textual Conventions for Internet Network Addresses. M. Daniele,B. Haberman, S. Routhier, J. Schoenwaelder. June 2000. (Format: TXT=32587 bytes) (Obsoleted by RFC3291) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Daniele
Request for Comments: 2851 Compaq Computer Corporation
Category: Standards Track B. Haberman
Nortel Networks
S. Routhier
Wind River Systems, Inc.
J. Schoenwaelder
TU Braunschweig
June 2000
コメントを求めるワーキンググループM.ダニエル要求をネットワークでつないでください: 2851年のコンパックコンピュータ社のカテゴリ: 規格はS.Routhier風の水系Inc.J.Schoenwaelder TUブラウンシュバイク2000年6月にB.ハーバーマンノーテルネットワークを追跡します。
Textual Conventions for Internet Network Addresses
インターネットネットワーク・アドレスのための原文のコンベンション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations.
このMIBモジュールは、一般的に使用されたインターネット網層のアドレス指定情報を表すために原文のコンベンションを定義します。 意図はこれらの定義がそうでなければそれら自身の表現を定義するMIBsでインポートされて、使用されるということです。
This work is output from the Operations and Management Area "IPv6MIB" design team.
この仕事はOperationsとManagement Area"IPv6MIB"デザインチームからの出力です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The SNMP Management Framework . . . . . . . . . . . . . . . 3 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . 9 4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . 9 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . 9 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 SNMP管理フレームワーク. . . . . . . . . . . . . . . 3 3。 定義. . . . . . . . . . . . . . . . . . . . . . . . 4 4。 用法ヒント. . . . . . . . . . . . . . . . . . . . . . . . 8 4.1は複数のDNS名. . . . . . . . . . . . . . . . . . . . 9 5を決議するホスト. . . . . . . . . . . . . . 9 4.4あたりのアドレス. . . . . . . . . . . . . . . . . . 9 4.3InetAddressesのインデックス. . . . . . . . . . . . . . . . . . . . . . . 8 4.2のユニークさを見送ります。 インデックスの例. . . . . . . . . . . . . . . . . . . 10 6を見送ってください。 セキュリティ問題. . . . . . . . . . . . . . . . . . 12 7。 承認. . . . . . . . . . . . . . . . . . . . . . 12
Daniele, et al. Standards Track [Page 1] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[1ページ]。
8. Intellectual Property Notice . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
8. 知的所有権通知. . . . . . . . . . . . . . . . 12参照. . . . . . . . . . . . . . . . . . . . . . . . . 13作者のアドレス. . . . . . . . . . . . . . . . . . . . . 15の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 16
1. Introduction
1. 序論
Several standard-track MIB modules use the IpAddress SMIv2 base type. This limits the applicability of these MIB modules to IP Version 4 (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has become problematic with the introduction of IP Version 6 (IPv6) addresses [21].
いくつかの標準のトラックMIBモジュールがIpAddress SMIv2ベースタイプを使用します。 IpAddress SMIv2ベースタイプが4バイトのIPv4アドレスを含むことができるだけであるので、これはこれらのMIBモジュールの適用性をIPバージョン4(IPv4)に制限します。 IpAddress SMIv2ベースタイプはIPバージョン6(IPv6)アドレス[21]の導入で問題が多くなりました。
This document defines multiple textual conventions as a mechanism to express generic Internet network layer addresses within MIB module specifications. The solution is compatible with SMIv2 (STD 58) and SMIv1 (STD 16). New MIB definitions which need to express network layer Internet addresses SHOULD use the textual conventions defined in this memo. New MIBs SHOULD NOT use the SMIv2 IpAddress base type anymore.
このドキュメントは、MIBモジュール仕様の中にジェネリックインターネット網層のアドレスを表すために複数の原文のコンベンションをメカニズムと定義します。 ソリューションはSMIv2(STD58)とSMIv1(STD16)と互換性があります。 ネットワーク層インターネット・アドレスSHOULDを急送する必要がある新しいMIB定義がこのメモで定義された原文のコンベンションを使用します。 新しいMIBs SHOULDはそれ以上SMIv2 IpAddressベースタイプを使用しません。
A generic Internet address consists of two objects, one whose syntax is InetAddressType, and another whose syntax is InetAddress. The value of the first object determines how the value of the second object is encoded. The InetAddress textual convention represents an opaque Internet address value. The InetAddressType enumeration is used to "cast" the InetAddress value into a concrete textual convention for the address type. This usage of multiple textual conventions allows expression of the display characteristics of each address type and makes the set of defined Internet address types extensible.
ジェネリックインターネットアドレスは2個のオブジェクト、構文がInetAddressTypeであるもの、および構文がInetAddressである別のものから成ります。 最初のオブジェクトの値は、第二目的語の値がどのようにコード化されるかを決定します。 InetAddressの原文のコンベンションは不透明なインターネットアドレス値を表します。 InetAddressType列挙は、アドレスタイプのために具体的な原文のコンベンションにInetAddress値を「投げかけること」に使用されます。 複数の原文のコンベンションのこの使用法で、それぞれのアドレスタイプのディスプレイの特性の式を許容して、定義されたインターネット・アドレスタイプのセットは広げることができるようになります。
The textual conventions defined in this document can be used to define Internet addresses by using DNS domain names in addition to IPv4 and IPv6 addresses. A MIB designer can write compliance statements to express that only a subset of the possible address types must be supported by a compliant implementation.
IPv4とIPv6アドレスに加えてDNSドメイン名を使用することによってインターネット・アドレスを定義するのに本書では定義された原文のコンベンションは使用できます。 MIBデザイナーは表す可能なアドレスの部分集合だけが対応する実装でサポートしなければならないのをタイプする承諾声明を書くことができます。
MIB developers who need to represent Internet addresses SHOULD use these definitions whenever applicable, as opposed to defining their own constructs. Even MIBs that only need to represent IPv4 or IPv6 addresses SHOULD use the textual conventions defined in this memo.
適切であるときはいつも、インターネット・アドレスSHOULDを表す必要があるMIB開発者がこれらの定義を使用します、それら自身の構造物を定義することと対照的に。 IPv4かIPv6を表す必要があるだけであるMIBsさえ、SHOULD使用がこのメモで定義された原文のコンベンションであると扱います。
In order to make existing widely-deployed IPv4-only MIBs fit for IPv6, it might be a valid approach to define separate tables for different address types. This is a decision for the MIB designer. For example, the tcpConnTable of the TCP-MIB [18] was left intact
既存の広く配布しているIPv4だけMIBsをIPv6のために合わせるように、異なったアドレスタイプのために別々のテーブルを定義するのは、有効なアプローチであるかもしれません。 これはMIBデザイナーのための決定です。 例えば、TCP-MIB[18]のtcpConnTableは完全なままにされました。
Daniele, et al. Standards Track [Page 2] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[2ページ]。
and a new table was added for TCP connections over IPv6 in the IPV6- TCP-MIB [19]. Note that even in this case, the MIBs SHOULD use the textual conventions defined in this memo.
そして、新しいテーブルはTCP接続のためにIPV6- TCP-MIB[19]でIPv6の上で加えられました。 この場合さえMIBs SHOULDがこのメモで定義された原文のコンベンションを使用することに注意してください。
Note that MIB developers SHOULD NOT use the textual conventions defined in this document to represent transport layer addresses.
MIB開発者SHOULD NOTがトランスポート層アドレスを表すために本書では定義された原文のコンベンションを使用することに注意してください。
Instead the SMIv2 TAddress textual convention and associated definitions should be used for transport layer addresses.
代わりに、SMIv2 TAddressの原文のコンベンションと関連定義はトランスポート層アドレスに使用されるべきです。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」はRFC2119[1]で説明されるように本書では解釈されることになっているべきです。
2. The SNMP Management Framework
2. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [2].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The
second version, called SMIv2, is described in STD 58, RFC 2578
[6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [9]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC
1906 [11]. The third version of the message protocol is called
SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574
[13].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [9]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[14].
o A set of fundamental applications described in RFC 2573 [15] and
the view-based access control mechanism described in RFC 2575
[16].
o オブジェクトとイベントを管理の目的にちなんで説明して、命名するためにRFC2571[2] o Mechanismsで説明された総合的なアーキテクチャ。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[3]、STD16、RFC1212[4]、およびRFC1215[5]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[6]、STD58、RFC2579[7]、およびSTD58RFC2580[8] (経営情報を移すためのo Messageプロトコル)で説明されます。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[9]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[10]とRFC1906[11]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[11]RFC2572[12]とRFC2574[13] (経営情報にアクセスするためのoプロトコル操作)でSNMPv3と呼ばれて、説明されます。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[9]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[14]で説明されます。Aが設定した基礎的応用の○はRFCで2573[15]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[16]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17].
RFC2570[17]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
Daniele, et al. Standards Track [Page 3] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[3ページ]。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
3. Definitions
3. 定義
INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
INETアドレスMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
IMPORTS MODULE-IDENTITY、mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC。
inetAddressMIB MODULE-IDENTITY
LAST-UPDATED "200006080000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Mike Daniele
Compaq Computer Corporation
110 Spit Brook Rd
Nashua, NH 03062, USA
inetAddressMIBモジュールアイデンティティは「マイクダニエルコンパックコンピュータ社110はブルック・第ナッシュア、ニューハンプシャー 03062、米国に痰唾を吐いた」という"200006080000Z"組織「IETF操作と管理領域」コンタクトインフォメーションをアップデートしました。
Phone: +1 603 884-1423
EMail: daniele@zk3.dec.com
以下に電話をしてください。 +1 603 884-1423 メールしてください: daniele@zk3.dec.com
Brian Haberman
Nortel Networks
4039 Emperor Blvd., Suite 200
Durham, NC 27703, USA
ブライアンハーバーマンノーテルは4039年の皇帝Blvd.、ダラム、NC 27703、Suite200米国をネットワークでつなぎます。
Phone: +1 919 992-4439
EMail: haberman@nortelnetworks.com
以下に電話をしてください。 +1 919 992-4439 メールしてください: haberman@nortelnetworks.com
Shawn A. Routhier
Wind River Systems, Inc.
1 Tara Blvd, Suite 403
Nashua, NH 03062, USA
ショーンA.RouthierはInc.1太良Blvd、Suite403ナッシュア、水系ニューハンプシャー 03062、米国を巻き上げします。
Phone: +1 603 897-2000
EMail: sar@epilogue.com
以下に電話をしてください。 +1 603 897-2000 メールしてください: sar@epilogue.com
Daniele, et al. Standards Track [Page 4] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[4ページ]。
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig, Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBueltenweg74/75 38106ブラウンシュバイク(ドイツ)
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
以下に電話をしてください。 +49 531 391-3289 メールしてください: schoenw@ibr.cs.tu-bs.de
Send comments to mibs@ops.ietf.org."
「コメントを mibs@ops.ietf.org に送ってください。」
DESCRIPTION
"This MIB module defines textual conventions for
representing Internet addresses. An Internet
address can be an IPv4 address, an IPv6 address
or a DNS domain name."
「このMIBモジュールはインターネット・アドレスを表しながら、原文のコンベンションを定義する」記述。 「インターネット・アドレスは、IPv4アドレス、IPv6アドレスまたはDNSドメイン名であるかもしれません。」
REVISION "200006080000Z"
DESCRIPTION
"Initial version, published as RFC 2851."
::= { mib-2 76 }
「初期のバージョンであって、RFC2851として発行された」REVISION"200006080000Z"記述。 ::= mib-2 76
InetAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of Internet address.
InetAddressType:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「一種のインターネット・アドレスを表す値。」
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding
InetAddress object is a zero-length string.
It may also be used to indicate an IP address
which is not in one of the formats defined
below.
未知のアドレスがタイプする未知(0)。 対応するInetAddressオブジェクトの値がゼロ長ストリングであるならこの値を使用しなければなりません。 また、それは、以下で定義された書式の1つにはないIPアドレスを示すのに使用されるかもしれません。
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
InetAddressIPv4の原文のコンベンションによって定義されるようにIPv4が扱うipv4(1)。
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
InetAddressIPv6の原文のコンベンションによって定義されるようにIPv6が扱うipv6(2)。
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
InetAddressDNSの原文のコンベンションによって定義されるdns(16)A DNSドメイン名。
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.
原文のコンベンションの定義でそのInetAddressTypeとの使用のために具体的なInetAddressType価値の各定義に伴わなければなりません。
The InetAddressType textual convention SHOULD NOT be subtyped
in object type definitions to support future extensions. It
InetAddressTypeの原文のコンベンションSHOULD NOT、オブジェクト型定義では、今後の拡大をサポートするために、副タイプされます。 それ
Daniele, et al. Standards Track [Page 5] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[5ページ]。
MAY be subtyped in compliance statements in order to require
only a subset of these address types for a compliant
implementation."
SYNTAX INTEGER {
unknown(0),
ipv4(1), -- these named numbers are aligned
ipv6(2), -- with AddressFamilyNumbers from
dns(16) -- IANA-ADDRESS-FAMILY-NUMBERS-MIB
}
「対応する実装のためにこれらのアドレスタイプの部分集合だけを必要とするように承諾声明で副タイプされるかもしれません。」 構文整数未知(0)、ipv4(1)--数というこれらはdns(16)からのAddressFamilyNumbersと並べられたipv6(2)です--、IANA-ADDRESS-FAMILY民数記MIB
InetAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Internet address.
InetAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「ジェネリックインターネットアドレスを指示します」。
An InetAddress value is always interpreted within the
context of an InetAddressType value. The InetAddressType
object which defines the context must be registered
immediately before the object which uses the InetAddress
textual convention. In other words, the object identifiers
for the InetAddressType object and the InetAddress object
MUST have the same length and the last sub-identifier of
the InetAddressType object MUST be 1 less than the last
sub-identifier of the InetAddress object.
InetAddress値はInetAddressType価値の文脈の中でいつも解釈されます。 InetAddressの原文のコンベンションを使用するオブジェクトの直前文脈を定義するInetAddressTypeオブジェクトを登録しなければなりません。 言い換えれば、InetAddressTypeオブジェクトとInetAddressオブジェクトのためのオブジェクト識別子には、同じ長さがなければなりません、そして、InetAddressTypeオブジェクトに関する最後のサブ識別子はInetAddressオブジェクトに関する最後のサブ識別子よりそれほど1であるに違いありません。
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (0..255))
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 「この場合、OBJECT-TYPE宣言は潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。」 構文八重奏ストリング(サイズ(0 .255))
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
InetAddressIPv4:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d"STATUSの現在の記述、「IPv4ネットワーク・アドレスを表します:、」
octets contents encoding
1-4 IP address network-byte order
1-4 IPアドレスネットワークバイトオーダーをコード化する八重奏コンテンツ
The corresponding InetAddressType value is ipv4(1)."
SYNTAX OCTET STRING (SIZE (4))
「対応するInetAddressType値はipv4(1)です。」 構文八重奏ストリング(サイズ(4))
InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS current
DESCRIPTION
InetAddressIPv6:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「2x:2x:2x:2x:2x:2x:2x: 2x%4d」STATUSの現在の記述
Daniele, et al. Standards Track [Page 6] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[6ページ]。
"Represents an IPv6 network address:
「IPv6ネットワーク・アドレスを表します:、」
octets contents encoding
1-16 IPv6 address network-byte order
17-20 scope identifier network-byte order
1-16 IPv6アドレスネットワークバイトオーダー17-20範囲識別子ネットワークバイトオーダーをコード化する八重奏コンテンツ
The corresponding InetAddressType value is ipv6(2).
対応するInetAddressType値はipv6(2)です。
The scope identifier (bytes 17-20) MUST NOT be present
for global IPv6 addresses. For non-global IPv6 addresses
(e.g. link-local or site-local addresses), the scope
identifier MUST always be present. It contains a link
identifier for link-local and a site identifier for
site-local IPv6 addresses.
範囲識別子(バイト17-20)はグローバルなIPv6アドレスのために存在しているはずがありません。 非グローバルなIPv6アドレス(例えば、リンク地方の、または、サイトローカルのアドレス)のために、範囲識別子はいつも存在していなければなりません。 リンク地方であることでリンク識別子を含んでいて、サイト地方のIPv6のためのサイト識別子は扱います。
The scope identifier MUST disambiguate identical address
values. For link-local addresses, the scope identifier will
typically be the interface index (ifIndex as defined in the
IF-MIB, RFC 2233) of the interface on which the address is
configured.
範囲識別子は同じアドレス値のあいまいさを除かなければなりません。 リンクローカルのアドレスのために、範囲識別子が通常インタフェースインデックスになる、(中で定義されるifIndex、-、MIB、RFC2233) アドレスが構成されるインタフェースについて。
The scope identifier may contain the special value 0
which refers to the default scope. The default scope
may be used in cases where the valid scope identifier
is not known (e.g., a management application needs to
write a site-local InetAddressIPv6 address without
knowing the site identifier value). The default scope
SHOULD NOT be used as an easy way out in cases where
the scope identifier for a non-global IPv6 is known."
SYNTAX OCTET STRING (SIZE (16|20))
範囲識別子はデフォルト範囲について言及する特別な値0を含むかもしれません。 デフォルト範囲は有効な範囲識別子が知られていない(例えば、管理アプリケーションは、サイト識別子価値を知らないでサイトローカルのInetAddressIPv6アドレスを書く必要があります)場合に使用されるかもしれません。 「デフォルトは、SHOULD NOTが安易な解決法として非グローバルなIPv6のための範囲識別子が知られている場合に使用されるのを見ます。」 構文八重奏ストリング(サイズ(16|20))
InetAddressDNS ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents a DNS domain name. The name SHOULD be
fully qualified whenever possible.
InetAddressDNS:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"255a"STATUSの現在の記述は「DNSドメイン名を表します」。 存在という可能であるときはいつも、完全に資格があった名前SHOULD。
The corresponding InetAddressType is dns(16).
対応するInetAddressTypeはdns(16)です。
The DESCRIPTION clause of InetAddress objects that
may have InetAddressDNS values must fully describe
how (and when) such names are to be resolved to IP
addresses."
SYNTAX OCTET STRING (SIZE (1..255))
「InetAddressDNS値を持っているかもしれないInetAddressオブジェクトの記述節はIPアドレスに決議されるそのような(そして、いつ)名がことである方法を完全に説明しなければなりません。」 構文八重奏ストリング(サイズ(1 .255))
END
終わり
Daniele, et al. Standards Track [Page 7] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[7ページ]。
4. Usage Hints
4. 用法は暗示します。
One particular usage of InetAddressType/InetAddress pairs is to avoid over-constraining an object definition by the use of the IpAddress SMI base type. An InetAddressType/InetAddress pair allows to represent IP addresses in various formats.
InetAddressType/InetAddress組の1つの特定の使用法はIpAddress SMIベースタイプの使用でオブジェクト定義を抑制し過ぎるのを避けることです。 組が様々な形式でIPアドレスを表させるInetAddressType/InetAddress。
The InetAddressType and InetAddress objects SHOULD NOT be subtyped. Subtyping binds the MIB module to specific address formats, which may cause serious problems if new address formats need to be introduced. Note that it is possible to write compliance statements in order to express that only a subset of the defined address types must be implemented to be compliant.
InetAddressTypeとInetAddressオブジェクトSHOULD NOT、副タイプされます。 Subtypingは特定のアドレス形式にMIBモジュールを縛ります。(新しいアドレス形式が、導入される必要があるなら、アドレス形式は深刻な問題を引き起こすかもしれません)。 言いなりになると定義されたアドレスタイプの部分集合だけを実装しなければならないと言い表すために承諾声明を書くのが可能であることに注意してください。
Internet addresses MUST always be represented by a pair of InetAddressType/InetAddress objects. It is not allowed to "share" an InetAddressType between multiple InetAddress objects. Furthermore, the InetAddressType object must be registered immediately before the InetAddress object. In other words, the object identifiers for the InetAddressType object and the InetAddress object MUST have the same length and the last sub-identifier of the InetAddressType object MUST be 1 less than the last sub-identifier of the InetAddress object.
1組のInetAddressType/InetAddressオブジェクトでインターネット・アドレスをいつも表さなければなりません。 それが複数のInetAddressオブジェクトの間のInetAddressTypeを「共有すること」が許容されていません。 その上、InetAddressオブジェクトの直前InetAddressTypeオブジェクトを登録しなければなりません。 言い換えれば、InetAddressTypeオブジェクトとInetAddressオブジェクトのためのオブジェクト識別子には、同じ長さがなければなりません、そして、InetAddressTypeオブジェクトに関する最後のサブ識別子はInetAddressオブジェクトに関する最後のサブ識別子よりそれほど1であるに違いありません。
4.1 Table Indexing
4.1 テーブルインデックス
When a generic Internet address is used as an index, both the InetAddressType and InetAddress objects MUST be used. The InetAddressType object MUST come immediately before the InetAddress object in the INDEX clause. If multiple Internet addresses are used in the INDEX clause, then every Internet address must be represented by a pair of InetAddressType and InetAddress objects.
ジェネリックインターネットアドレスがインデックスとして使用されるとき、InetAddressTypeとInetAddressオブジェクトの両方を使用しなければなりません。 InetAddressTypeオブジェクトはInetAddressオブジェクトの直前INDEX節で来なければなりません。 複数のインターネット・アドレスがINDEX節で使用されるなら、1組のInetAddressTypeとInetAddressオブジェクトであらゆるインターネット・アドレスを表さなければなりません。
The IMPLIED keyword MUST NOT be used for an object of type InetAddress in an INDEX clause. Instance sub-identifiers are then of the form T.N.O1.O2...On, where T is the value of the InetAddressType object, O1...On are the octets in the InetAddress object, and N is the number of those octets.
INDEX節のタイプInetAddressのオブジェクトにIMPLIEDキーワードを使用してはいけません。 インスタンスサブ識別子はそして、フォームT. N. O1.O2のものです…TがInetAddressTypeオブジェクトの値であることのO1に関して…オンであるのが、InetAddressオブジェクトの八重奏であり、Nはそれらの八重奏の数です。
There is a meaningful lexicographical ordering to tables indexed in this fashion. Command generator applications may lookup specific addresses of known type and value, issue GetNext requests for addresses of a single type, or issue GetNext requests for a specific type and address prefix.
こんなやり方で索引をつけられたテーブルには重要な辞書編集の注文があります。 コマンドジェネレータアプリケーションは知られているタイプと価値のルックアップの特定のアドレス、単独のタイプのアドレスを求める問題GetNext要求、または特定のタイプとアドレス接頭語を求める問題GetNext要求がそうするかもしれません。
Daniele, et al. Standards Track [Page 8] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[8ページ]。
4.2 Uniqueness of Addresses
4.2 アドレスのユニークさ
IPv4 addresses were intended to be globally unique, current usage notwithstanding. IPv6 addresses were architected to have different scopes and hence uniqueness [21]. In particular, IPv6 "link-local" and "site-local" addresses are not guaranteed to be unique on any particular node. In such cases, the duplicate addresses must be configured on different interfaces. So the combination of an IPv6 address and an interface number is unique. The interface number may therefore be used as a scope identifier.
グローバルにユニークであって、用法にもかかわらず、IPv4アドレスが現在であることを意図しました。 IPv6アドレスは、異なった範囲としたがって、ユニークさ[21]を持つためにarchitectedされました。 特に、IPv6の「リンク地方」の、そして、「サイト地方」のアドレスは、どんな特定のノードでも特有になるように保証されません。 そのような場合、異なったインタフェースで写しアドレスを構成しなければなりません。 それで、IPv6アドレスとインタフェース番号の組み合わせはユニークです。 したがって、インタフェース番号は範囲識別子として使用されるかもしれません。
The InetAddressIPv6 textual convention has been defined to represent global and non-global IPv6 addresses. MIB designers who use InetAddressType/InetAddress pairs therefore do not need define additional objects in order to support link-local or site-local addresses.
InetAddressIPv6の原文のコンベンションは、グローバルで非グローバルなIPv6アドレスを表すために定義されました。 したがって組が必要としないInetAddressType/InetAddressを使用するMIBデザイナーは、リンク地方の、または、サイトローカルのアドレスをサポートするために追加オブジェクトを定義します。
The size of the scope identifier has been chosen so that it matches the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 2553 [22].
範囲識別子のサイズが選ばれたので、それはRFC2553[22]で定義されたsockaddr_in6構造のsin6_範囲_イド分野に合っています。
4.3 Multiple InetAddresses per Host
4.3 複数の1ホストあたりのInetAddresses
A single host system may be configured with multiple addresses (IPv4 or IPv6), and possibly with multiple DNS names. Thus it is possible for a single host system to be represented by multiple InetAddressType/InetAddress pairs.
ただ一つのホストシステムは複数のアドレス(IPv4かIPv6)、およびことによると複数のDNS名によって構成されるかもしれません。 したがって、ただ一つのホストシステムが複数のInetAddressType/InetAddress組によって表されるのは、可能です。
If this could be an implementation or usage issue, then the DESCRIPTION clause of the relevant objects MUST fully describe required behavior.
これが実装か用法問題であるかもしれないなら、関連オブジェクトの記述節は必要な振舞いについて完全に説明しなければなりません。
4.4 Resolving DNS Names
4.4 DNS名を決議すること。
DNS names must be resolved to IP addresses when communication with the named host is required. This raises a temporal aspect to defining MIB objects whose value is a DNS name: When is the name translated to an address?
命名されたホストとのコミュニケーションが必要であるときに、IPアドレスにDNS名を決議しなければなりません。 これは値がDNS名であるMIBオブジェクトを定義するのに時の局面を上げます: 名前はいつアドレスに翻訳されますか?
For example, consider an object defined to indicate a forwarding destination, and whose value is a DNS name. When does the forwarding entity resolve the DNS name? Each time forwarding occurs? Once, when the object was instantiated?
例えば、推進の目的地とだれの値がDNS名であるかを示すために定義されたオブジェクトを考えてください。 推進実体はいつDNS名を決議しますか? 推進が起こる各回? 一度、オブジェクトはいつ例示されましたか?
The DESCRIPTION clause of such objects SHOULD precisely define how and when any required name to address resolution is done.
SHOULDが、解決を扱うために何かがどのように、いつ名前を必要としたかを正確に定義するそのようなオブジェクトの記述節は完了しています。
Daniele, et al. Standards Track [Page 9] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[9ページ]。
Similarly, the DESCRIPTION clause of such objects SHOULD precisely define how and when a reverse lookup is being done if an agent has accessed instrumentation that knows about an IP address and the MIB or implementation requires to map the address to a name.
同様に、エージェントがそれがIPアドレスとMIBか実装に関して知っている計装にアクセスしたなら、SHOULDが正確に定義する逆のルックアップがあるどのように、時に行われるそのようなオブジェクトの記述節は名前へのアドレスを地図に必要とします。
5. Table Indexing Example
5. テーブルインデックスの例
This example shows a table listing communication peers that are identified by either an IPv4 address, an IPv6 address or a DNS name. The table definition also prohibits entries with an empty address (whose type would be "unknown"). The size of a DNS name is limited to 64 characters.
この例は、テーブルがIPv4アドレス、IPv6アドレスまたはDNSが命名するどちらかによって特定されるコミュニケーション同輩を記載するのを示します。 また、テーブル定義は空のアドレス(タイプは「未知である」)でエントリーを禁止します。 DNS名のサイズは64のキャラクタに制限されます。
peerTable OBJECT-TYPE
SYNTAX SEQUENCE OF PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of communication peers."
::= { somewhere 1 }
「Aはコミュニケーション同輩について記載する」peerTable OBJECT-TYPE SYNTAX SEQUENCE OF PeerEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= どこか、1
peerEntry OBJECT-TYPE
SYNTAX PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing information about a particular peer."
INDEX { peerAddressType, peerAddress }
::= { peerTable 1 }
peerEntry OBJECT-TYPE SYNTAX PeerEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の同輩の情報を含むエントリー。」 peerAddressType、peerAddressに索引をつけてください:、:= peerTable1
PeerEntry ::= SEQUENCE {
peerAddressType InetAddressType,
peerAddress InetAddress,
peerStatus INTEGER }
PeerEntry:、:= 系列peerAddressType InetAddressType、peerAddress InetAddress、peerStatus整数
peerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of Internet address by which the peer
is reachable."
::= { peerEntry 1 }
peerAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「同輩が届いているインターネット・アドレスのタイプ。」 ::= peerEntry1
peerAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..64))
MAX-ACCESS not-accessible
STATUS current
peerAddress OBJECT-TYPE SYNTAX InetAddress(SIZE(1 .64))のマックス-ACCESSのアクセスしやすくないSTATUS海流
Daniele, et al. Standards Track [Page 10] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[10ページ]。
DESCRIPTION
"The Internet address for the peer. Note that
implementations must limit themselves to a single
entry in this table per reachable peer.
記述「同輩のためのインターネット・アドレス。」 実装がこの届いている同輩あたりのテーブルで自分たちを単一のエントリーに制限しなければならないことに注意してください。
The peerAddress may not be empty due to the SIZE
restriction.
peerAddressはSIZE制限のために空でないかもしれません。
If a row is created administratively by an SNMP
operation and the address type value is dns(16), then
the agent stores the DNS name internally. A DNS name
lookup must be performed on the internally stored DNS
name whenever it is being used to contact the peer.
If a row is created by the managed entity itself and
the address type value is dns(16), then the agent
stores the IP address internally. A DNS reverse lookup
must be performed on the internally stored IP address
whenever the value is retrieved via SNMP."
::= { peerEntry 2 }
行がSNMP操作で行政上作成されて、アドレスタイプ価値がdns(16)であるなら、エージェントは内部的にDNS名を保存します。 それが同輩に連絡するのに使用されているときはいつも、内部的に保存されたDNS名にDNS名前ルックアップを実行しなければなりません。 行が管理された実体自体によって作成されて、アドレスタイプ価値がdns(16)であるなら、エージェントは内部的にIPアドレスを保存します。 「値がSNMPを通して検索されるときはいつも、内部的に保存されたIPアドレスにDNSの逆のルックアップを実行しなければなりません。」 ::= peerEntry2
The following compliance statement specifies that implementations need only support IPv4 addresses and globally unique IPv6 addresses to be compliant. Support for DNS names or scoped IPv6 addresses is not required.
以下の承諾声明は、実装が、サポートIPv4アドレスとグローバルにユニークなIPv6アドレスだけが対応である必要であると指定します。 DNS名か見られたIPv6アドレスのサポートは必要ではありません。
peerCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement the peer MIB."
peerCompliance MODULE-COMPLIANCE STATUSの現在の記述、「承諾声明、同輩MIB、」
MODULE -- this module
MANDATORY-GROUPS { peerGroup }
MODULE--このモジュールMANDATORY-GROUPSpeerGroup
OBJECT peerAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is only required to support IPv4
and IPv6 addresses."
OBJECT peerAddressType SYNTAX InetAddressType、ipv4(1)、ipv6(2)、「IPv4とIPv6アドレスであるとサポート実装が必要であるだけである」記述。
OBJECT peerAddress
SYNTAX InetAddress (SIZE(4|16))
DESCRIPTION
"An implementation is only required to support IPv4
and globally unique IPv6 addresses."
「IPv4とグローバルにユニークなIPv6アドレスであるとサポート実装が必要であるだけである」OBJECT peerAddress SYNTAX InetAddress(SIZE(4|16))記述。
::= { somewhere 2 }
::= どこか、2
Daniele, et al. Standards Track [Page 11] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[11ページ]。
Note that the SMIv2 does not permit inclusion of not-accessible objects in an object group (see section 3.1 in STD 58, RFC 2580 [8]). It is therefore not possible to formally refine the syntax of auxiliary objects which are not-accessible. In such a case, it is suggested to express the refinement informally in the DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation.
SMIv2がオブジェクトグループでアクセスしやすくないことの包含にオブジェクトを可能にしないことに注意してください。(STD58(RFC2580[8]))のセクション3.1を見てください。 したがって、正式にアクセスしやすくない補助のオブジェクトの構文を洗練するのは可能ではありません。 このような場合には、それは、MODULE-COMPLIANCEマクロ実施の記述節で気品を非公式に言い表すために示されます。
6. Security Considerations
6. セキュリティ問題
This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MIB modules to define management objects.
このモジュールはどんな管理オブジェクトも定義しません。 代わりに、それは管理オブジェクトを定義するのに他のMIBモジュールで使用されるかもしれない1セットの原文のコンベンションを定義します。
Meaningful security considerations can only be written in the modules that define management objects.
管理物を定義するモジュールで重要なセキュリティ問題を書くことができるだけです。
7. Acknowledgments
7. 承認
The authors would like to thank Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for their comments and suggestions.
作者はランディ・ブッシュに感謝したがっています、リチャードDraves、マーク・エリソン、ビル・フェナー、6月-ichiro Hagino、ティム・ジェンキンス、グレン・マンスフィールド、キースMcCloghrie、トーマスNarten、エリックNordmark、Peder Chr。 彼らのコメントと提案のためのNorgaard、ランディPresuhn、アンドリュー・スミス、デーヴThaler、ケネス・ホワイト、バートWijnen、およびブライアンZill。
8. Intellectual Property Notice
8. 知的所有権通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Daniele, et al. Standards Track [Page 12] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[12ページ]。
References
参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[2] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理枠組みについて説明するための構造」、RFC2571、1999年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ベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[5] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[5] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[6] 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.
[6]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[7]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[8]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[9] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[11] 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.
[11]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[12]ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[13] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
Daniele, et al. Standards Track [Page 13] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[13ページ]。
[14] 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.
[14] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
2573, April 1999.
[15] レビとD.とマイヤーとP.とB.スチュワート、「SNMPアプリケーション」、RFC2573、1999年4月。
[16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management
Protocol (SNMP)", RFC 2575, April 1999.
[16] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス管理モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[17] ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメント枠組みのバージョン3への序論」RFC2570(1999年4月)。
[18] McCloghrie, K., "SNMPv2 Management Information Base for the
Transmission Control Protocol using SMIv2", RFC 2012, November
1996.
[18]McCloghrie、K.、「1996年11月にSMIv2"、RFC2012を使用する通信制御プロトコルのためのSNMPv2管理情報ベース。」
[19] Daniele, M., "IP Version 6 Management Information Base for the
Transmission Control Protocol", RFC 2452, December 1998.
[19] ダニエル、M.、「通信制御プロトコルのためのIPバージョン6管理情報ベース」、RFC2452、1998年12月。
[20] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[20] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[21] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[21]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[22] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[22] ギリガンとR.とトムソンとS.とバウンドとJ.とW.スティーブンス、「IPv6"、RFC2553、1999年3月のための基本的なソケットインタフェース拡大。」
Daniele, et al. Standards Track [Page 14] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[14ページ]。
Authors' Addresses
作者のアドレス
Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062 USA
マイクダニエルコンパックコンピュータ社110はブルック・ニューハンプシャー03062第ナッシュア(米国)に痰唾を吐きました。
Phone: +1 603 884-1423 EMail: daniele@zk3.dec.com
以下に電話をしてください。 +1 603 884-1423 メールしてください: daniele@zk3.dec.com
Brian Haberman Nortel Networks 4039 Emperor Blvd., Suite 200 Durham, NC 27703 USA
ブライアンハーバーマンノーテルは4039年の皇帝Blvd.、Suite200ダラム、NC27703米国をネットワークでつなぎます。
Phone: +1 919 992-4439 EMail: haberman@nortelnetworks.com
以下に電話をしてください。 +1 919 992-4439 メールしてください: haberman@nortelnetworks.com
Shawn A. Routhier Wind River Systems, Inc. 1 Tara Blvd, Suite 403 Nashua, NH 03062 USA
ショーンA.Routhier風の水系Inc.1太良Blvd、Suite403ナッシュア(ニューハンプシャー)03062米国
Phone: +1 603 897-2000 EMail: sar@epilogue.com
以下に電話をしてください。 +1 603 897-2000 メールしてください: sar@epilogue.com
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBueltenweg74/75 38106ブラウンシュバイクドイツ
Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de
以下に電話をしてください。 +49 531 391-3289 メールしてください: schoenw@ibr.cs.tu-bs.de
Daniele, et al. Standards Track [Page 15] RFC 2851 TCs for Internet Network Addresses June 2000
ダニエル、他 規格は2000年6月にインターネットネットワーク・アドレスのためにRFC2851TCsを追跡します[15ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daniele, et al. Standards Track [Page 16]
ダニエル、他 標準化過程[16ページ]
一覧
スポンサーリンク
