Network Working Group P. Nesser, II
Request for Comments: 3796 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents
IPv4の調査は、現在展開IETF操作と管理領域標準化過程と実験ドキュメント内のアドレス
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.
この文書では、現在展開IETF操作と管理領域でIPv4アドレスのすべての使用を記録しようとする基準を受け入れました。正常にすべてのIPv6インターネットにすべてのIPv4インターネットから移行するために、多くの中間ステップが取られます。これらのステップの一つは、IPv4の依存関係を持っている現在のプロトコルの進化です。これらのプロトコル（およびその実装は）独立したネットワークアドレスに再設計されることが期待され、それに失敗すると、少なくとも二重IPv4およびIPv6をサポートします。このためには、すべての標準（フル、ドラフト、および提案された）だけでなく、実験的RFCは、調査され、すべての依存関係が記載されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 9
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 36
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 37
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative Reference. . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 43
This document is part of a set aiming to record all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Operations & Management, Routing, Security, Sub-IP and Transport).
この文書は、IETF標準でIPv4アドレスのすべての使用状況を記録することを目指しセットの一部です。管理しやすい形式で情報を持っているための努力では、現在IETFエリア（アプリケーション、インターネット、運用と管理、ルーティング、セキュリティ、サブIPとトランスポート）に準拠した7つの文書に分割されています。
For a full introduction, please see the introduction [1].
完全な概要については、導入[1]を参照してください。
The document is organized as described below:
後述のように文書が構成されています。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
セクション3、4、5、及び6はそれぞれフル、ドラフト、及び提案された標準、および実験RFCの生の分析を記載します。各RFCは、各RFCのコメントは、自然の中で「生」であり、RFC 1から始まり、（周り）RFC 3100で終わるその順番で説明されています。これは、各RFCは、問題はすでに修正されているかどうかを確認するために「先読み」していない議論真空や問題点や問題に議論されています。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
セクション7は、結果のすべてが全体としてみなされ、それ以降のRFCsで解決された問題が相関していることをここであり、セクション3に提示されたデータの分析である4、5、および6。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
（最も一般的に、単に「基準」という。）のフルインターネット規格は広く実装し、インターネット全体で使用されている完全に成熟したプロトコル仕様です。
Section 3.2.3.2. IpAddress defines the following:
セクション3.2.3.2。 IPアドレスは次のように定義しています。
This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order.
このアプリケーション全体のタイプは、32ビットのインターネットアドレスを表します。これは、ネットワークバイト順で長さ4のOCTET文字列として表されます。
There are several instances of the use of this definition in the rest of the document.
文書の残りの部分では、この定義の使用のいくつかのインスタンスがあります。
In section 4.1.6 IpAddress is defined as:
セクション4.1.6にIPアドレスを次のように定義されます。
(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d notation.
（6）IPアドレス値：馴染みA.B.C.D表記の4つのサブ識別子を、。
There are far too many instances of IPv4 addresses is this document to enumerate here. The particular object groups that are affected are the IP group, the ICMP group, the TCP group, the UDP group, and the EGP group.
IPv4アドレスのあまりにも多くの場合は、ここに列挙するには、この文書ではあります。影響を受けている特定のオブジェクトグループは、IPグループ、ICMPグループ、TCPグループ、UDPグループ、およびEGP基です。
Section 7.1.5 defines the IpAddress data type:
7.1.5項では、IPアドレスのデータ型を定義します。
The IpAddress type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order.
IPアドレスのタイプは32ビットのインターネットアドレスを表します。これは、ネットワークバイト順で長さ4のOCTET文字列として表されます。
Note that the IpAddress type is a tagged type for historical reasons. Network addresses should be represented using an invocation of the TEXTUAL-CONVENTION macro.
IPアドレスのタイプは歴史的な理由のためにタグ付けされたタイプであることに留意されたいです。ネットワークアドレスは、TEXTUAL-CONVENTIONマクロの呼び出しを使用して表現する必要があります。
Note the deprecated status of this type; see RFC 3291 for details on the replacement TEXTUAL-CONVENTION definitions.
このタイプの非推奨の状況に注意してください。代替テキストの表記法の定義の詳細については、RFC 3291を参照してください。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
3.9. Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
3.9. 簡易ネットワーク管理プロトコル（SNMP）のためのメッセージ処理と派遣
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
3.11. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
3.11. 簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
3.12. View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
3.12. 簡易ネットワーク管理プロトコル（SNMP）のためのビューベースアクセス制御モデル（VACM）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
3.13. Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMP)
3.13. 簡易ネットワーク管理プロトコル（SNMP）のバージョン2のためのプロトコル動作
Section 4.2.2.1., Example of Table Traversal, and Section 4.2.3.1., Another Example of Table Traversal, both use objects from MIB2 whose data contains IPv4 addresses. Other than their use in these example sections, there are no IPv4 dependencies in this specification.
セクション4.2.2.1、表トラバーサルの例、およびセクション4.2.3.1、表トラバーサルの別の例として、データのIPv4アドレスを含むMIB2両方から利用オブジェクト。これらの例のセクションでの使用以外に、この仕様にはIPv4の依存関係はありません。
3.14. Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMP)
3.14. 簡易ネットワーク管理プロトコル（SNMP）のバージョン2のための輸送マッピング
Section 2 Definitions contains the following definition:
第2節の定義は、次の定義が含まれています。
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6))
1-4 IPアドレスネットワークバイトオーダー5-6 UDPポートのネットワークバイトオーダー "構文オクテットSTRING（SIZE（6））を符号化するオクテット内容
Section 8.1, Usage Example, also contains examples which uses IPv4 address, but it has no significance in the operation of the specification.
セクション8.1、使用例は、また、IPv4アドレスを使用する例が含まれ、それは仕様の動作には意味を持ちません。
3.15. Management Information Base for Version 2 of the Simple Network Management Protocol (SNMP)
3.15. 簡易ネットワーク管理プロトコル（SNMP）のバージョン2のための管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
ドラフト規格は、IETFにおける最後から二番目の標準レベルを表します。プロトコルは、複数の独立した、相互運用可能な実装がある場合にドラフト標準を達成することができます。ドラフト規格は通常、非常に成熟し、広く使用されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.3. Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2
4.3. SMIv2のを使用して、ボーダーゲートウェイプロトコルのバージョン4（BGP-4）のための管理対象オブジェクトの定義
The MIB defined in this RFC deals with objects in a BGP4 based routing system and therefore contain many objects that are limited by the IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB are limited to IPv4 addresses. No update is needed, although a new MIB should be defined for BGP4+ to allow management of IPv6 addresses and routes.
MIBは、BGP4ベースのルーティングシステム内のオブジェクトを、このRFCディールで定義され、従って、MIB2で定義されたIPアドレスの32ビットの値によって制限され、多くのオブジェクトを含みます。明らかに、このMIBの値は、IPv4アドレスに制限されています。新しいMIBは、IPv6アドレスとルートの管理を可能にするために、BGP4 +のために定義されなければならないが、何の更新は、必要ありません。
4.4. Definitions of Managed Objects for Character Stream Devices using SMIv2
4.4. SMIv2のを使用して文字ストリームデバイスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.5. Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2
4.5. SMIv2のを使用してRS-232のようなハードウェアデバイスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.6. Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2
4.6. SMIv2のを使用してパラレル・プリンタなどのハードウェアデバイスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.7. Definitions of Managed Objects for SMDS Interfaces using SMIv2
4.7. SMIv2のを使用してSMDSインタフェースのための管理対象オブジェクトの定義
This MIB module definition defines the following subtree:
このMIBモジュールの定義は、以下のサブツリーを定義します。
ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }
-- Although the objects in this group are read-only, at the -- agent's discretion they may be made read-write so that the -- management station, when appropriately authorized, may -- change the addressing information related to the -- configuration of a logical IP subnetwork implemented on -- top of SMDS.
このグループのオブジェクトは読み取り専用であるが、時 - 管理ステーション、適切に許可するとき、できる - - に関連するアドレス情報を変更する - そのようにエージェントの裁量それらは読み書きを行うことができます - SMDSの上 - 上に実装された論理IPサブネットワークの設定。
-- This table is necessary to support RFC1209 (IP-over-SMDS) -- and gives information on the Group Addresses and ARP -- Addresses used in the Logical IP subnetwork. -- One SMDS address may be associated with multiple IP -- addresses. One SNI may be associated with multiple LISs.
- この表はRFC1209（IP-オーバー-SMDS）をサポートする必要がある - とグループアドレスとARPの情報を提供します - 論理IPサブネットワークで使用されるアドレス。 - アドレス - ワンSMDSアドレスは、複数のIPに関連付けすることができます。一SNIは、複数のLISに関連付けることができます。
ipOverSMDSTable OBJECT-TYPE SYNTAX SEQUENCE OF IpOverSMDSEntry MAX-ACCESS not-accessible
IpOverSMDSEntryアクセス不可能なMAX-ACCESS OF ipOverSMDSTable OBJECT-TYPE構文配列
STATUS current
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ipOverSMDS 1 }
ipOverSMDSEntry OBJECT-TYPE
SYNTAX IpOverSMDSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The addressing information for one of this
entity's IP addresses."
INDEX { ipOverSMDSIndex, ipOverSMDSAddress }
::= { ipOverSMDSTable 1 }
IpOverSMDSEntry ::=
SEQUENCE {
ipOverSMDSIndex IfIndex,
ipOverSMDSAddress IpAddress,
ipOverSMDSHA SMDSAddress,
ipOverSMDSLISGA SMDSAddress,
ipOverSMDSARPReq SMDSAddress
}
ipOverSMDSIndex OBJECT-TYPE
SYNTAX IfIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains management
information. "
::= { ipOverSMDSEntry 1 }
ipOverSMDSAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address to which this entry's addressing
information pertains."
::= { ipOverSMDSEntry 2 }
ipOverSMDSHA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current
ipOverSMDSHAのOBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-onlyステータス電流
DESCRIPTION
"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }
ipOverSMDSLISGA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS Group Address that has been configured
to identify the SMDS Subscriber-Network Interfaces
(SNIs) of all members of the Logical IP Subnetwork
(LIS) connected to the network supporting SMDS."
::= { ipOverSMDSEntry 4 }
ipOverSMDSARPReq OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS address (individual or group) to which
ARP Requests are to be sent."
::= { ipOverSMDSEntry 5 }
Although these object definitions are intended for IPv4 addresses, a similar MIB can be defined for IPv6 addressing.
これらのオブジェクト定義は、IPv4アドレスのために意図されているが、同様のMIBは、IPv6アドレスのために定義することができます。
As expected, this RFC is filled with IPv4 dependencies since it defines a MIB module for an IPv4-only routing protocol. A new MIB for RIPng is required.
予想通り、それはIPv4専用ルーティングプロトコルのMIBモジュールを定義するため、このRFCは、IPv4の依存関係が満たされています。 RIPngのための新しいMIBが必要です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This MIB defines managed objects for OSPFv2 which is a protocol used to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 addresses, a new MIB is required to support a new version of OSPF that is IPv6 aware.
このMIBは、ルーティング情報のIPv4を交換するために使用されるプロトコルであるOSPFv2のための管理オブジェクトを定義します。 OSPFv2には、IPv4アドレスに制限されているので、新しいMIBは、IPv6が認識しているOSPFの新しいバージョンをサポートするために必要です。
4.11. Management Information Base for Frame Relay DTEs Using SMIv2
4.11. SMIv2を使用したフレームリレーのDTEのための管理情報ベース
This specification has several examples of how IPv4 addresses might be mapped to Frame Relay DLCIs. Other than those examples there are no IPv4 dependencies in this specification.
この仕様は、IPv4アドレスは、リレーのDLCIをフレームにマッピングされるかもしれない方法の例をいくつか持っています。その他これらの例よりも、この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification. There is some discussion in one object definition about an interface performing a self test, but the object itself is IP version independent.
この仕様にはIPv4の依存関係はありません。そこセルフテストを実行するインタフェースに関する一つのオブジェクト定義内のいくつかの議論があるが、オブジェクト自体は、IPバージョン独立しています。
4.14. Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
4.14. 同期光ネットワーク/同期デジタル階層（SONET / SDH）のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
4.15. Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
4.15. 15分間隔に基づいて、パフォーマンス履歴を使用してMIBモジュールのためのテキストの表記法
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases, Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
提案された標準は、入門レベルの文書です。でも、単一の実装のための要件はありません。多くの場合、実装されることはありません提案やIETF標準化プロセスに進みました。したがって、これらは、多くの場合、インターネットコミュニティに提示されているだけで、提案のアイデアです。時には欠陥が露出したり、彼らが問題に多くの競合ソリューションの一つですされています。この後の例では、何の議論は、それがこの議論の目的を果たすないだろうと提示されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.2. Definitions of Managed Objects for the Border Gateway Protocol: Version 3
5.2. ボーダーゲートウェイプロトコルのための管理対象オブジェクトの定義：バージョン3
The use of BGP3 has been deprecated and is not discussed.
BGP3の使用が推奨されていませんし、議論されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.10. SNMP MIB extension for Multiprotocol Interconnect over X.25
5.10. X.25上のマルチプロトコルの相互接続のためのSNMP MIB拡張
The following objects are defined in Section 4, Definitions:
次のオブジェクトは第4節、定義で定義されています。
mioxPleLastFailedEnAddr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2..128))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The last Encapsulated address that failed
to find a corresponding X.121 address and
caused mioxPleEnAddrToX121LkupFlrs to be
incremented. The first octet of this object
contains the encapsulation type, the
remaining octets contain the address of that
type that failed. Thus for an IP address,
the length will be five octets, the first
octet will contain 204 (hex CC), and the
last four octets will contain the IP address. For a snap encapsulation, the
first byte would be 128 (hex 80) and the
rest of the octet string would have the snap
header."
::= { mioxPleEntry 4 }
mioxPeerEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The Encapsulation address of the remote host mapped by this table entry. A length of zero indicates the remote IP address is unknown or unspecified for use as a PLE default.
mioxPeerEnAddr OBJECT-TYPE構文オクテットSTRING（SIZE（0 128））ACCESS読み取りと書き込みステータス必須説明「このテーブルエントリによってマップされたリモートホストのカプセル化アドレス。ゼロの長さは、リモートIPアドレスが不明又は不特定であることを示しPLEデフォルトとして使用するため。
The first octet of this object contains the
encapsulation type, the remaining octets
contain an address of that type. Thus for
an IP address, the length will be five
octets, the first octet will contain 204
(hex CC), and the last four octets will
contain the IP address. For a snap
encapsulation, the first byte would be 128
(hex 80) and the rest of the octet string
would have the snap header."
DEFVAL { ''h }
::= { mioxPeerEntry 7 }
mioxPeerEncType OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the encapsulation type. For IP encapsulation this will have a value of 204 (hex CC). For SNAP encapsulated packets, this will have a value of 128 (hex 80). For CLNP, ISO 8473, this will have a value of 129 (hex 81). For ES-ES, ISO 9542, this will have a value of 130 (hex 82). A value of 197 (hex C5) identifies the Blacker X.25 encapsulation. A value of 0, identifies the Null encapsulation.
mioxPeerEncType OBJECT-TYPE構文INTEGER（0 256）ACCESS読み取りと書き込みステータス必須説明「カプセル化タイプの値。IPカプセル化の場合、これは204（六角CC）の値を有することになる。SNAPパケットをカプセル化するため、これはあります128（16進数80）の値。CLNP、ISO 8473の場合、これは129（16進数81）の値を有することになる。ES-ES、ISO 9542の場合、これは130（16進数82）の値を有するであろう。の値197（六角C5）は、ブラッカーX.25カプセル化を識別する。0の値は、ヌルカプセル化を識別する。
This value can only be written when the
mioxPeerStatus object with the same mioxPeerIndex has a value of underCreation.
Setting this object to a value of 256
deletes the entry. When deleting an entry,
all other entries in the mioxPeerEncTable
with the same mioxPeerIndex and with an
mioxPeerEncIndex higher then the deleted
entry, will all have their mioxPeerEncIndex
values decremented by one."
::= { mioxPeerEncEntry 2 }
Updated values of the first byte of these objects can be defined to support IPv6 addresses.
これらのオブジェクトの最初のバイトの更新された値は、IPv6アドレスをサポートするために定義することができます。
5.11. The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol
5.11. ポイントツーポイントプロトコルのリンク制御プロトコルのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.12. The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol
5.12. ポイントツーポイントプロトコルのセキュリティプロトコルのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.13. The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol
5.13. ポイントツーポイントプロトコルのIPネットワーク制御プロトコルのための管理対象オブジェクトの定義
This MIB module is targeted specifically at IPv4 over PPP. A new MIB module would need to be defined to support IPv6 over PPP.
このMIBモジュールは、PPP上でのIPv4で特異的に標的化されます。新しいMIBモジュールは、PPP上でIPv6をサポートするために定義する必要があります。
5.14. The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol
5.14. ポイントツーポイントプロトコルのブリッジネットワーク制御プロトコルのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.16. Token Ring Extensions to the Remote Network Monitoring MIB
5.16. リモートネットワーク監視MIBへのトークンリング拡張機能
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.17. Definitions of Managed Objects for Source Routing Bridges
5.17. ソースルーティングブリッジのための管理オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.21. Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2
5.21. リレーショナル・データベース管理システム（RDBMS）の管理情報ベース（MIB）のSMIv2を使用して
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The following objects are defined:
次のオブジェクトが定義されています。
KipEntry ::= SEQUENCE {
kipNetStart ATNetworkNumber,
kipNetEnd ATNetworkNumber,
kipNextHop IpAddress,
kipHopCount INTEGER,
kipBCastAddr IpAddress,
kipCore INTEGER,
kipType INTEGER,
kipState INTEGER,
kipShare INTEGER,
kipFrom IpAddress
}
kipNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IP address of the next hop in the route to this
entry's destination network."
::= { kipEntry 3 }
kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION
kipBCastAddrのOBJECT-TYPE構文IPアドレスアクセス読み取りと書き込みステータス必須説明
"The form of the IP address used to broadcast on this
network."
::= { kipEntry 5 }
kipFrom OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The IP address from which the routing entry was
learned via the AA protocol. If this entry was not
created via the AA protocol, it should contain IP
address 0.0.0.0."
::= { kipEntry 10 }
5.23. Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2
5.23. SMIv2のを使用してSNAデータリンク制御のための管理対象オブジェクトの定義（SDLC）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.26. The Definitions of Managed Objects for IP Mobility Support using SMIv2
5.26. SMIv2のを使用してIPモビリティサポートのための管理対象オブジェクトの定義
This document defines a MIB for the Mobile IPv4. Without enumeration, let it be stated that a new MIB for IPv6 Mobility is required.
この文書では、モバイルIPv4のためのMIBを定義します。列挙しないと、IPv6のモビリティのための新しいMIBが必要であると言うことができます。
5.27. SNMPv2 Management Information Base for the Internet Protocol using SMIv2
5.27. SMIv2のを使用してインターネットプロトコルのためのSNMPv2管理情報ベース
Approximately 1/3 of the objects defined in this document are IPv4- dependent. New objects need to be defined to support IPv6.
約1/3このドキュメントで定義されたオブジェクトのはIPv4-依存しています。新しいオブジェクトは、IPv6をサポートするために定義する必要があります。
5.28. SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2
5.28. 伝送制御プロトコルのためのSNMPv2管理情報ベースのSMIv2を使用して
A number of object definitions in this MIB assumes IPv4 addresses, as is noted in the note reproduced below:
ノートは以下に再現に注目されるように、このMIBのオブジェクト定義の数は、IPv4アドレスを前提としています。
IESG Note:
IESG注：
The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses.
IP、UDP、およびTCP MIBモジュールは、現在、IPv4のみをサポートしています。これら三つのモジュールは、IPv4の32ビットのインターネットアドレスを表すために長さ4のOCTET STRINGとして定義されるIPアドレスタイプを使用します。 （、SNMPv2のためのSMIをRFC 1902を参照してください。）彼らは、新しい128ビットのIPv6インターネットアドレスをサポートしていません。
5.29. SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2
5.29. SMIv2のを使用してユーザーデータグラムプロトコルのためのSNMPv2管理情報ベース
A number of object definitions in this MIB assumes IPv4 addresses, as is noted in the note reproduced below:
ノートは以下に再現に注目されるように、このMIBのオブジェクト定義の数は、IPv4アドレスを前提としています。
IESG Note:
IESG注：
The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses.
IP、UDP、およびTCP MIBモジュールは、現在、IPv4のみをサポートしています。これら三つのモジュールは、IPv4の32ビットのインターネットアドレスを表すために長さ4のOCTET STRINGとして定義されるIPアドレスタイプを使用します。 （、SNMPv2のためのSMIをRFC 1902を参照してください。）彼らは、新しい128ビットのIPv6インターネットアドレスをサポートしていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.31. Remote Network Monitoring Management Information Base Version 2 using SMIv2
5.31. SMIv2のを使用してリモートネットワーク監視管理情報ベースバージョン2
The following objects are defined:
次のオブジェクトが定義されています。
addressMapNetworkAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this relation.
addressMapNetworkAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「この関係のネットワークアドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the
index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { addressMapEntry 2 }
nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this nlHostEntry.
nlHostAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「このnlHostEntryのネットワークアドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlHostEntry 2 }
nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixSDEntry.
nlMatrixSDSourceAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「このnlMatrixSDEntryのネットワーク送信元アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 2 }
nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixSDEntry.
nlMatrixSDDestAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「このnlMatrixSDEntryのネットワーク宛先アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixSDEntry 3 }
nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixDSEntry.
nlMatrixDSSourceAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「このnlMatrixDSEntryのネットワーク送信元アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 2 }
nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixDSEntry.
nlMatrixDSDestAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESSステータス現在の説明は「このnlMatrixDSEntryのネットワーク宛先アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixDSEntry 3 }
nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only
nlMatrixTopNSourceAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESS読み取り専用
STATUS current
DESCRIPTION
"The network layer address of the source host in this
conversation.
This is represented as an octet string with
specific semantics and length as identified
by the associated nlMatrixTopNProtocolDirLocalIndex.
For example, if the protocolDirLocalIndex indicates an
encapsulation of ip, this object is encoded as a length
octet of 4, followed by the 4 octets of the ip address,
in network byte order."
::= { nlMatrixTopNEntry 3 }
nlMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation.
nlMatrixTopNDestAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESS read-onlyステータス現在の説明「この会話の宛先ホストのネットワーク層アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the associated nlMatrixTopNProtocolDirLocalIndex.
For example, if the nlMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { nlMatrixTopNEntry 4 }
alMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex.
alMatrixTopNSourceAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESS read-only説明「この会話で送信元ホストのネットワーク層アドレスが、これは、関連alMatrixTopNProtocolDirLocalIndexによって識別されるように特定の意味論および長さとオクテット文字列として表されます。
For example, if the alMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the
ip address, in network byte order."
::= { alMatrixTopNEntry 3 }
alMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation.
alMatrixTopNDestAddress OBJECT-TYPE構文オクテット文字列MAX-ACCESS read-onlyステータス現在の説明「この会話の宛先ホストのネットワーク層アドレス。
This is represented as an octet string with
specific semantics and length as identified
by the associated alMatrixTopNProtocolDirLocalIndex.
For example, if the alMatrixTopNProtocolDirLocalIndex
indicates an encapsulation of ip, this object is encoded as a
length octet of 4, followed by the 4 octets of the ip
address, in network byte order."
::= { alMatrixTopNEntry 4 }
trapDestProtocol OBJECT-TYPE
SYNTAX INTEGER {
ip(1),
ipx(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The protocol with which to send this trap."
::= { trapDestEntry 3 }
trapDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The address to send traps on behalf of this entry.
trapDestAddressのOBJECT-TYPE構文オクテット文字列MAX-ACCESSはリード作成しますステータス現在の説明は「このエントリに代わってトラップを送信するアドレス。
If the associated trapDestProtocol object is equal to ip(1),
the encoding of this object is the same as the snmpUDPAddress
textual convention in [RFC1906]:
-- for a SnmpUDPAddress of length 6:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order
If the associated trapDestProtocol object is equal to ipx(2), the encoding of this object is the same as the snmpIPXAddress textual convention in [RFC1906]: -- for a SnmpIPXAddress of length 12: -- -- octets contents encoding -- 1-4 network-number network-byte order -- 5-10 physical-address network-byte order -- 11-12 socket-number network-byte order
関連trapDestProtocolオブジェクトは、IPXに等しい場合（2）、このオブジェクトの符号化は[RFC1906]でsnmpIPXAddressテキストの表記法と同じである： - 長さ12のSnmpIPXAddressため： - - オクテット内容符号化 - 1 -4ネットワーク番号ネットワークバイト順 - 5-10物理アドレスネットワークバイト順 - 11-12ソケット番号ネットワークバイト順
This object may not be modified if the associated
trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 }
All of the object definitions above (except trapDestProtocol) mention only IPv4 addresses. However, since they use a SYNTAX of OCTET STRING, they should work fine for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e., SYNTAX addition of ipv6(3) should make this specification functional for IPv6.
（trapDestProtocol除く）上記オブジェクト定義のすべてがIPv4アドレスのみを言及します。彼らはオクテット文字列の構文を使用するので、しかし、彼らは、IPv6アドレスのために正常に動作する必要があります。 trapDestProtocolの新しい正規値（すなわち、IPv6のシンタックスの添加は、（3）IPv6のための本明細書に機能させるべきです。
5.32. Definitions of Managed Objects for Data Link Switching using SMIv2
5.32. データリンクのSMIv2を使用して切り替えのための管理対象オブジェクトの定義
The following textual conventions are defined:
次のテキストの表記法が定義されています。
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order."
SYNTAX OCTET STRING (SIZE (0..255))
-- DLSw over TCP
dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 }
-- for an IP address of length 4:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
--
DlswTCPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents the IP address of a DLSw which uses
TCP as a transport protocol."
SYNTAX OCTET STRING (SIZE (4))
Additionally there are many object definitions that use a SYNTAX of TAddress within the document. Interestingly the SYNTAX for TAddress is an OCTET string of up to 256 characters. It could easily accommodate a similar hybrid format for IPv6 addresses.
また、文書内TAddressの構文を使用する多くのオブジェクト定義があります。興味深いことにTAddressの構文は、最大256文字のオクテット文字列です。これは、簡単にIPv6アドレスのための同様のハイブリッドフォーマットを収容できます。
A new OID to enhance functionality for DlswTCPAddress could be added to support IPv6 addresses.
DlswTCPAddressための機能を強化するため、新たなOIDは、IPv6アドレスをサポートするために追加することができます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The MIB module's main conceptual table ipCidrRouteTable uses IPv4 addresses as index objects and is therefore incapable of representing an IPv6 forwarding information base. A new conceptual table needs to be defined to support IPv6 addresses.
MIBモジュールの主要概念テーブルはipCidrRouteTableインデックスオブジェクトとしてIPv4アドレスを使用するため、IPv6の転送情報ベースを表すことができません。新しい概念の表は、IPv6アドレスをサポートするために定義する必要があります。
5.35. Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 802
5.35. SMIv2の802を使用したIEEE 802.3リピータデバイスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.37. Dial Control Management Information Base using SMIv2
5.37. SMIv2のを使用して制御管理情報ベースをダイヤル
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
All of the relevant object definitions in this MIB have options for both IPv4 and IPv6. There are no IPv4 dependencies in this specification.
このMIB内の関連するオブジェクト定義のすべては、IPv4とIPv6の両方のオプションを持っています。この仕様にはIPv4の依存関係はありません。
5.39. Integrated Services Management Information Base using SMIv2
5.39. SMIv2のを使用してサービス統合型管理情報ベース
This MIB is IPv6 aware and therefore there are no IPv4 dependencies in this specification.
このMIBは、IPv6認識しているため、この仕様にはIPv4の依存関係はありません。
5.40. Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
5.40. SMIv2のを使用してサービス統合型管理情報ベース保証サービス拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.43. Definitions of Managed Objects for IEEE 802.12 Repeater Devices
5.43. IEEE 802.12リピータデバイスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.44. Definitions of System-Level Managed Objects for Applications
5.44. システムレベルの定義は、アプリケーションのオブジェクトを管理します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.45. Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)
5.45. SMIv2の（IPOA-MIB）を使用して、古典的なIPとARPオーバーATMのための管理対象オブジェクトの定義
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
このMIBは、IPv4に完全に依存しています。 IPv6のための新しいMIBは、同じ機能を提供するために必要とされます。
5.46. Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
5.46. UNI 3.0 / 3.1ベースのATMネットワーク経由のマルチキャストのための管理対象オブジェクトの定義
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
このMIBは、IPv4に完全に依存しています。 IPv6のための新しいMIBは、同じ機能を提供するために必要とされます。
5.47. IP Version 6 Management Information Base for the Transmission Control Protocol
5.47. 伝送制御プロトコルのためのIPバージョン6管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐに廃止するのIPv6 MIBを文書化し、この議論では考慮されていません。
5.48. IP Version 6 Management Information Base for the User Datagram Protocol
5.48. ユーザーデータグラムプロトコルのためのIPバージョン6管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐに廃止するのIPv6 MIBを文書化し、この議論では考慮されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.51. Definitions of Managed Objects for Extended Border Node
5.51. 拡張ボーダーノードのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.52. Management Information Base for IP Version 6: Textual Conventions and General Group
5.52. テキストの表記法と一般的なグループ：IPバージョン6のための管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐに廃止するのIPv6 MIBを文書化し、この議論では考慮されていません。
5.53. Management Information Base for IP Version 6: ICMPv6 Group
5.53. ICMPv6のグループ：IPバージョン6のための管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐに廃止するのIPv6 MIBを文書化し、この議論では考慮されていません。
5.54. Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type
5.54. DS0とDS0バンドルインターフェイスタイプのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.55. Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types
5.55. DS1、E1、DS2およびE2インターフェイスのタイプのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.56. Definitions of Managed Object for the DS3/E3 Interface Type
5.56. DS3 / E3インターフェイスの種類のための管理オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.58. Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
5.58. コネクション指向ネットワークのための会計情報の収集と保管を制御するための管理対象オブジェクト
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.59. Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management
5.59. ATMの管理のためのテキストの表記法およびOBJECT-アイデンティティの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This MIB defines the following objects:
このMIBは、次のオブジェクトが定義されています。
AtmInterfaceConfEntry ::= SEQUENCE {
atmInterfaceMaxVpcs INTEGER,
atmInterfaceMaxVccs INTEGER,
atmInterfaceConfVpcs INTEGER,
atmInterfaceConfVccs INTEGER,
atmInterfaceMaxActiveVpiBits INTEGER,
atmInterfaceMaxActiveVciBits INTEGER,
atmInterfaceIlmiVpi AtmVpIdentifier,
atmInterfaceIlmiVci AtmVcIdentifier,
atmInterfaceAddressType INTEGER,
atmInterfaceAdminAddress AtmAddr,
atmInterfaceMyNeighborIpAddress IpAddress,
atmInterfaceMyNeighborIfName DisplayString,
atmInterfaceCurrentMaxVpiBits INTEGER,
atmInterfaceCurrentMaxVciBits INTEGER,
atmInterfaceSubscrAddress AtmAddr
}
atmInterfaceMyNeighborIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of the neighbor system connected to
the far end of this interface, to which a Network
Management Station can send SNMP messages, as IP
datagrams sent to UDP port 161, in order to access
network management information concerning the
operation of that system. Note that the value
of this object may be obtained in different ways,
e.g., by manual configuration, or through ILMI
interaction with the neighbor system."
::= { atmInterfaceConfEntry 11 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
Clearly a subsequent revision of this MIB module should define equivalent IPv6 objects.
明らかに、このMIBモジュールのその後の改訂は、同等のIPv6オブジェクトを定義すべきです。
5.61. Base Definitions of Managed Objects for TN3270E Using SMIv2
5.61. SMIv2を使用するTN3270Eのための管理オブジェクトの基本定義
The document states:
ドキュメントの状態：
The MIB defined by this memo supports use of both IPv4 and IPv6 addressing.
このメモで定義されたMIBはIPv4とIPv6アドレスの両方の使用をサポートしています。
This specification is both IPv4 and IPv6 aware.
この仕様は、IPv4とIPv6の両方が認識しています。
5.62. Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2
5.62. SMIv2を使用するTN3270E応答時間の収集のためのプロトコルおよび管理オブジェクトの定義
This MIB module inherits IP version-independence by virtue of importing the appropriate definitions from RFC 2561.
このMIBモジュールはRFC 2561からの適切な定義をインポートのおかげでIPバージョン - 独立性を継承します。
The following textual convention is defined:
以下のテキストの表記法が定義されています。
ApplTAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For snmpUDPDomain, an ApplTAddress is 6 octets long, the initial 4 octets containing the IP-address in
network-byte order and the last 2 containing the UDP
port in network-byte order. Consult 'Transport Mappings
for Version 2 of the Simple Network Management Protocol
(SNMPv2)' for further information on snmpUDPDomain."
SYNTAX OCTET STRING (SIZE (0..255))
A new TC should be defined to handle IPv6 addresses.
新しいTCは、IPv6アドレスを処理するために定義する必要があります。
5.64. Definitions of Managed Objects for APPN/HPR in IP Networks
5.64. IPネットワークにおけるAPPN / HPRのための管理対象オブジェクトの定義
Many of the object definitions described in this document assume the use of the IPv4 only TOS header bits. It is therefore IPv4-only in nature and will not support IPv6.
この文書に記述されたオブジェクト定義の多くは、IPv4のみTOSヘッダービットを使用することを前提としています。これは、IPv4のみの自然の中でそのためであるとIPv6をサポートしていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.67. Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0
5.67. スイッチングネットワークのバージョン1.0用のリモートネットワーク監視MIB拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This RFC defines the following objects:
このRFCは、次のオブジェクトが定義されています。
RadiusAuthServerEntry ::= SEQUENCE {
radiusAuthServerIndex Integer32,
radiusAuthServerAddress IpAddress,
radiusAuthClientServerPortNumber Integer32,
radiusAuthClientRoundTripTime TimeTicks,
radiusAuthClientAccessRequests Counter32,
radiusAuthClientAccessRetransmissions Counter32,
radiusAuthClientAccessAccepts Counter32,
radiusAuthClientAccessRejects Counter32,
radiusAuthClientAccessChallenges Counter32,
radiusAuthClientMalformedAccessResponses Counter32,
radiusAuthClientBadAuthenticators Counter32,
radiusAuthClientPendingRequests Gauge32,
radiusAuthClientTimeouts Counter32,
radiusAuthClientUnknownTypes Counter32, radiusAuthClientPacketsDropped Counter32
}
radiusAuthServerAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the RADIUS authentication server
referred to in this table entry."
::= { radiusAuthServerEntry 2 }
There needs to be an update to allow an IPv6 based object for this value.
この値のIPv6ベースのオブジェクトを許可するように更新が必要です。
This MIB defines the followings objects:
このMIBは、以下のオブジェクトを定義します。
RadiusAuthClientEntry ::= SEQUENCE {
radiusAuthClientIndex Integer32,
radiusAuthClientAddress IpAddress,
radiusAuthClientID SnmpAdminString,
radiusAuthServAccessRequests Counter32,
radiusAuthServDupAccessRequests Counter32,
radiusAuthServAccessAccepts Counter32,
radiusAuthServAccessRejects Counter32,
radiusAuthServAccessChallenges Counter32,
radiusAuthServMalformedAccessRequests Counter32,
radiusAuthServBadAuthenticators Counter32,
radiusAuthServPacketsDropped Counter32,
radiusAuthServUnknownTypes Counter32
}
radiusAuthClientAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NAS-IP-Address of the RADIUS authentication client
referred to in this table entry."
::= { radiusAuthClientEntry 2 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、IPv4アドレスとIPv6アドレスの両方をサポートするものでは非推奨と交換する必要があります。
The only objects in the version of RPSL that deal with IP addresses are defined as:
IPアドレスを扱うRPSLのバージョンでのみオブジェクトは、次のように定義されています。
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
<IPv4のアドレス> IPv4アドレスは、文字ドットで区切られた0から255の範囲の4つの整数のシーケンスとして表されます「」。例えば、128.9.128.5は有効なIPv4アドレスを表します。このドキュメントの残りの部分では、我々は、IPアドレスとしてIPv4アドレスを参照してもよいです。
<address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers.
<アドレスプレフィックス>アドレスプレフィックスが0から32の範囲は次の整数に続くキャラクタ、スラッシュ「/」に続いてIPv4アドレスとして表される有効なアドレスプレフィックスである：128.9.128.5/32、128.9.0.0 / 16、0.0.0.0/0。そして、次のアドレスのプレフィックスが無効です：0/0、128.9 / 0から16または128.9の4つの整数を含む文字列ではありません。
There seems to be an awareness of IPv6 because of the terminology but it is not specifically defined. Therefore additional objects for IPv6 addresses and prefixes need to be defined.
そこなぜなら用語のIPv6のへの認識のようですが、それを具体的に定義されていません。したがって、IPv6アドレスとプレフィックスのための追加オブジェクトを定義する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
The Abstract of this document says:
この文書の要旨は言います：
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.
このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）を定義します。特に、それは、IPv4ネットワーク上の任意のタイプのトンネルを管理するために使用される管理オブジェクトについて説明します。拡張MIBは、プロトコル固有のオブジェクトを管理するために設計されてもよいです。同様に、拡張MIBは、セキュリティ固有のオブジェクトを管理するために設計されてもよいです。このMIBは、（IPv6ネットワークを含む）非IPv4ネットワーク経由のトンネルをサポートしていません。そのようなトンネルの管理は、他のMIBによってサポートされてもよいです。
A similar MIB for tunneling over IPv6 should be defined.
IPv6経由のトンネルのための同様のMIBを定義する必要があります。
5.73. DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems
5.73. DOCSISケーブルデバイスMIBケーブルデバイスDOCSIS準拠のケーブルモデムやケーブルモデム終端システムのための管理情報ベース
This document states:
このドキュメントの状態：
Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements. Future versions of the DOCSIS standard are expected to require support for SNMPv3 and IPv6 as well.
DOCSIS 1.0規格は、SNMPv1のみを実装するとIPv4の顧客のトラフィックを処理するために、ケーブルモデムが必要であることに注意してください。このMIBのデザイン選択はそれらの要件を反映しています。 DOCSIS規格の将来のバージョンは、同様のSNMPv3とIPv6のサポートを必要とすると予想されています。
5.74. Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces
5.74. 無線周波数（RF）MCNS / DOCSIS準拠RFインターフェイスのインターフェイスの管理情報ベース
This MIB defines the following objects:
このMIBは、次のオブジェクトが定義されています。
DocsIfCmtsCmStatusEntry ::= SEQUENCE {
docsIfCmtsCmStatusIndex Integer32,
docsIfCmtsCmStatusMacAddress MacAddress,
docsIfCmtsCmStatusIpAddress IpAddress,
docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusRxPower TenthdBmV,
docsIfCmtsCmStatusTimingOffset Unsigned32,
docsIfCmtsCmStatusEqualizationData OCTET STRING,
docsIfCmtsCmStatusValue INTEGER,
docsIfCmtsCmStatusUnerroreds Counter32,
docsIfCmtsCmStatusCorrecteds Counter32,
docsIfCmtsCmStatusUncorrectables Counter32,
docsIfCmtsCmStatusSignalNoise TenthdB,
docsIfCmtsCmStatusMicroreflections Integer32
}
docsIfCmtsCmStatusIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of this Cable Modem. If the Cable Modem has no
IP address assigned, or the IP address is unknown, this
object returns a value of 0.0.0.0. If the Cable Modem has
multiple IP addresses, this object returns the IP address
associated with the Cable interface."
::= { docsIfCmtsCmStatusEntry 3 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、IPv4アドレスとIPv6アドレスの両方をサポートするものでは非推奨と交換する必要があります。
5.75. Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions
5.75. トラフィッククラス、マルチキャストフィルタリングおよび仮想LAN拡張機能を持つブリッジのための管理オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.76. Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
5.76. NBMAネクストホップ解決プロトコル（NHRP）のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Although the examples in the document are for IPv4 transport only, there is no IPv4 dependency in the AgentX protocol itself.
ドキュメントの例は、IPv4のみの輸送のためのものであるが、AgentXプロトコル自体にはIPv4の依存性は存在しません。
5.82. Definitions of Managed Objects for Extensible SNMP Agents
5.82. 拡張可能SNMPエージェントのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.86. Definitions of Managed Objects for the Virtual Router Redundancy Protocol
5.86. 仮想ルータ冗長プロトコルのための管理対象オブジェクトの定義
As stated in the Overview section:
概要のセクションで述べたように：
Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment.
VRRPプロトコルはIPv4のみルータで使用するために意図されているので、このMIBは、IPv4に固有のIPアドレスの構文を使用します。このMIBは、IPv6環境で相互運用するためにこのように、変更が必要となります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.89. Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
5.89. ファイバチャネル標準におけるファブリック要素のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.90. Textual Conventions for Additional High Capacity Data Types
5.90. 追加の大容量のデータ型のテキストの表記法
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.91. The Inverted Stack Table Extension to the Interfaces Group MIB
5.91. インタフェースグループMIBへの逆積層テーブル拡張
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.92. Remote Network Monitoring MIB Protocol Identifier Reference
5.92. リモートネットワーク監視MIBプロトコル識別子リファレンス
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
5.93. Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
5.93. リモートピング、トレースルート、およびルックアップ操作のための管理対象オブジェクトの定義
This MIB mostly is IPv4 and IPv6 aware. There are a few assumptions that are problems, though. In the following object definitions:
このMIBは、主に、IPv4とIPv6を認識しています。問題のあるいくつかの仮定は、しかし、があります。以下のオブジェクト定義には：
pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create
pingCtlDataSizeのOBJECT-TYPE構文Unsigned32（0..65507）UNITS "オクテット" MAX-ACCESSはリード作成
STATUS current
DESCRIPTION
"Specifies the size of the data portion to be
transmitted in a ping operation in octets. A ping
request is usually an ICMP message encoded
into an IP packet. An IP packet has a maximum size
of 65535 octets. Subtracting the size of the ICMP
or UDP header (both 8 octets) and the size of the IP
header (20 octets) yields a maximum size of 65507
octets."
DEFVAL { 0 }
::= { pingCtlEntry 5 }
traceRouteCtlDataSize OBJECT-TYPE
SYNTAX Unsigned32 (0..65507)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the data portion of a traceroute
request in octets. A traceroute request is essentially
transmitted by encoding a UDP datagram into a
IP packet. So subtracting the size of a UDP header
(8 octets) and the size of a IP header (20 octets)
yields a maximum of 65507 octets."
DEFVAL { 0 }
::= { traceRouteCtlEntry 6 }
The DESCRIPTION clauses need to be updated to remove the IPv4 dependencies.
記述節は、IPv4の依存関係を削除するために更新する必要があります。
This specification is only defined for IPv4 and a similar MIB must be defined for IPv6.
この仕様は、IPv4のみのために定義されており、同様のMIBは、IPv6のために定義されなければなりません。
As stated in this document:
この文書に記載されているように：
Since IGMP is specific to IPv4, this MIB does not support management of equivalent functionality for other address families, such as IPv6.
IGMPは、IPv4に固有なので、このMIBは、IPv6など他のアドレスファミリーのための同等の機能の管理をサポートしていません。
5.96. Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
5.96. 一般的なオープンポリシーサービスのための管理対象オブジェクトの定義（COPS）プロトコルクライアント
This MIB is both IPv4 and IPv6 aware and needs no changes.
このMIBは、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
5.97. Definitions of Managed Objects for Frame Relay Service
5.97. フレームリレーサービスのための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.98. Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
5.98. フレームリレー/ ATM PVCサービスインターワーキング機能を監視制御のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.103. IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol
5.103。マルチキャストリスナ発見プロトコルのためのIPバージョン6管理情報ベース
This is an IPv6 related document and is not discussed in this document.
これは、IPv6関連の文書であり、この文書で説明されていません。
5.104. Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
5.104。 UNI / NNIマルチリンクフレームリレー機能を監視制御のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.105. Management Information Base for the PINT Services Architecture
5.105。 PINTサービスアーキテクチャのための管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.106. Policy Core Information Model -- Version 1 Specification (CIM)
5.106。方針コア情報モデル - バージョン1仕様（CIM）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification builds on RFC 2748, and is both IPv4 and IPv6 capable. The specification defines a sample filter in section 4.3, which has "ipv4" in it.
この仕様は、RFC 2748に基づいて構築し、IPv4とIPv6の両方が可能です。明細書は、その中に「IPv4の」を有するセクション4.3のサンプルフィルタを定義します。
5.108. Definitions of Managed Objects for the Delegation of Management Scripts
5.108。管理スクリプトの委任のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.109. Definitions of Managed Objects for Scheduling Management Operations
5.109。スケジュール管理操作のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.111. Definitions of Managed Objects for the Ethernet-like Interface Types
5.111。イーサネットのようなインターフェース型のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.112. Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
5.112。 IEEE 802.3媒体接続ユニット（MAUに）のための管理対象オブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases, they are presented as alternatives to the mainstream solution to an acknowledged problem.
実験的RFCは、通常、インターネット上のwidescale実装や用法を持っていないプロトコルを定義します。彼らは多くの場合、自然の中で妥当または制限された競技場で使用されています。彼らは、潜在的な相互運用性またはいくつかの他の潜在的に有用なシナリオを可能にするためにインターネットコミュニティに文書化されています。いくつかのケースでは、彼らは認め問題の主流の解決策の代替として提示されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.2. Techniques for managing asynchronously generated alerts
6.2. 非同期に生成されたアラートを管理するためのテクニック
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.3. CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)
6.3. 中間システムへのコネクションレスネットワークプロトコル（ISO 8473）およびエンドシステムで使用するためのCLNS MIB（ISO 9542）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.4. Simple Network Management Protocol Distributed Protocol Interface Version 2.0
6.4. 簡易ネットワーク管理プロトコルは、プロトコル・インタフェースのバージョン2.0を分散します
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
6.7. Definitions of Managed Objects for Service Level Agreements Performance Monitoring
6.7. サービスレベル契約のパフォーマンス監視のための管理対象オブジェクトの定義
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
6.8. Diffie-Helman USM Key Management Information Base and Textual Convention
6.8. ディフィー・ヘルマンUSMキー管理情報ベースおよびテキストの表記法
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This document is specific to IPv4.
この文書では、IPv4に固有のものです。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
RFCの最初の調査では、36個の陽性は、以下のように分解、153の合計のうち、同定されました。
Standards: 6 out of 15 or 40.00%
Draft Standards: 4 out of 15 or 26.67%
Proposed Standards: 26 out of 112 or 23.21%
Experimental RFCs: 0 out of 11 or 0.00%
Of those identified, many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that should be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below.
彼らは時代遅れと未使用のプロトコルを文書化するため、他の人が積極的に適切なワーキンググループによって更新されている文書・プロトコルをしている間、特定されたもののうち、多くは、何のアクションを必要としません。また、更新する必要がありますが、それらが更新されていない場合はすべての業務への影響を起こさない水準の多くのインスタンスがあります。残りのインスタンスは、以下の文書化されています。
RFC 1155 and RFC 1212 (along with the informational document RFC 1215) define SMIv1. These documents have been superseded by RFCs 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer being used as the basis for new IETF MIB modules, the limitations identified in this Internet Standard do not require any action.
RFC 1155およびRFC 1212は、（情報のドキュメントRFC 1215と一緒に）でSMIv1を定義します。これらのドキュメントはSMIv2のを定義するRFC 2578、2579、および2580に取って代わられています。でSMIv1は、もはや新しいIETF MIBモジュールのための基礎として使用されているので、このインターネット標準で特定さ制限は任意のアクションを必要としません。
The limitations identified have been addressed, because RFC 1213 has been split into multiple modules which are all IPv6 capable.
RFC 1213は、すべてのIPv6対応している複数のモジュールに分割されているので、識別の制限は、対処されています。
This problem is currently being addressed by the Inter Domain Routing (IDR) WG [2].
この問題は、現在、インタードメインルーティング（IDR）WGによって対処されている[2]。
See Internet Area standards. Once a specification for IPv6 over SMDS is created a new MIB must be defined.
インターネットエリアの基準を参照してください。 SMDSの上にIPv6の仕様が作成されると、新しいMIBを定義する必要があります。
There is no updated MIB module to cover the problems outlined. A new MIB module should be defined.
概説した問題をカバーするために何の更新MIBモジュールはありません。新しいMIBモジュールを定義する必要があります。
This problem is currently being addressed by the OSPF WG [3].
この問題は、現在OSPF WGによって対処されている[3]。
RFC 1906 has been obsoleted by RFC 3417, Transport Mappings for SNMP, and the limitations of this specification have been addressed by that RFC, which defines TCs that can be used to specify transport domains in an IP version-independent way. RFC 3419 recommends that those TCs be used in place of SnmpUDPAddress when IPv6 support is required and for all new applications that are not SNMP-specific.
RFC 1906、RFC 3417によって廃止された、トランスポートSNMPのマッピング、および本明細書の制限は、IPバージョンに依存しない方法で輸送ドメインを指定するために使用することができるのTCを定義するRFCによって対処されてきました。 RFC 3419には、IPv6のサポートが必要とSNMP固有ではないすべての新しいアプリケーションのためにされている場合、それらのTCSはSnmpUDPAddressの代わりに使用することをお勧めします。
This problem has not been addressed. If a user requirement for IPv6 over X.25 develops (which is thought to be unlikely) then this MIB module will need to be updated in order to accommodate it.
この問題は解決されていません。 X.25経由のIPv6のためのユーザーの要件は（そうであると考えられている）の開発の場合、このMIBモジュールは、それに対応するために更新する必要があります。
There is no updated MIB to cover the problems outlined. A new MIB should be defined.
概説した問題をカバーするために何の更新MIBはありません。新しいMIBを定義する必要があります。
This problem has not been addressed. If a user requirement for IPv6 over Appletalk develops (which is thought to be unlikely) then this MIB module will need to be updated (or a new MIB module will need to be created) in order to accommodate it.
この問題は解決されていません。 AppleTalk経由のIPv6のためのユーザーの要件は（そうであると考えられている）の開発の場合、このMIBモジュールを更新する必要があります（または新しいMIBモジュールを作成する必要があります）、それに対応するために。
7.3.4. The Definitions of Managed Objects for IP Mobility Support using SMIv2 ()
7.3.4. SMIv2のを使用してIPモビリティサポートのための管理対象オブジェクトの定義（）
The problems are being resolved by the MIP6 WG [4].
問題は、MIP6 WGによって解決されている[4]。
This issue is being resolved by the IPv6 WG [5].
この問題は、IPv6 WGによって解決されている[5]。
This issue is being resolved by the IPv6 WG [6].
この問題は、IPv6 WGによって解決されている[6]。
This issue is being resolved by the IPv6 WG [7].
この問題は、IPv6 WGによって解決されている[7]。
This issue has been brought to the attention of the RMONMIB WG. Currently, there is a work in progress [8] to update RFC 2021, but it does not address the problems that have been identified; it is expected that there will be a resolution in a future version of that document.
この問題はRMONMIB WGの注意に持って来られました。現在、そこに進行中の作業は、[8] RFC 2021を更新することですが、それは確認されている問題に対処しません。その文書の将来のバージョンで解決が期待されます。
The problems have not been addressed and an updated MIB should be defined.
問題が解決されておらず、更新MIBを定義する必要があります。
This issue is being worked on by the IPv6 WG [9].
この問題は、IPv6 WG [9]で作業中です。
The current version of Classical IP and ARP over ATM (RFC 2225) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
ATMを介したClassical IPとARPの現在のバージョン（RFC 2225）は、IPv6をサポートしていません。そのプロトコル仕様は、IPv6のサポートを追加するために更新されたとき場合は、IPv6アドレスを表現するための新しいMIBオブジェクトがこのMIBモジュールに追加する必要があります。
The current version of Multicast over UNI 3.0/3.1 ATM (RFC 2022) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
UNI 3.0 / 3.1 ATM上のマルチキャストの現在のバージョン（RFC 2022）は、IPv6をサポートしていません。そのプロトコル仕様は、IPv6のサポートを追加するために更新されたとき場合は、IPv6アドレスを表現するための新しいMIBオブジェクトがこのMIBモジュールに追加する必要があります。
The AToM MIB WG is currently collecting implementation reports for RFC 2515 and is considering whether to advance, revise, or retire this specification. The problems identified have been brought to the attention of the WG.
AToMのMIB WGは現在、RFC 2515の実装報告を収集していると、進め修正、またはこの仕様を引退するかどうかを検討しています。特定された問題は、WGの注目されてきました。
The problems identified are not being addressed and a new MIB module may need to be defined.
特定された問題は対処されていないと、新しいMIBモジュールを定義する必要があります。
The problems identified are not being addressed and a new MIB module may need to be defined. One possible solution might be to use the RFC 3419 TCs.
特定された問題は対処されていないと、新しいMIBモジュールを定義する必要があります。一つの可能な解決策は、RFCに3419件のTCを使用するかもしれません。
7.3.16. Definitions of Managed Objects for APPN/HPR in IP Networks (RFC 2584)
7.3.16. IPネットワークでAPPN / HPRのための管理オブジェクトの定義（RFC 2584）
The problems identified are not addressed and a new MIB may be defined.
特定された問題は対処されていないと、新しいMIBを定義することができます。
The problems have not been addressed and a new MIB should be defined.
問題が解決されておらず、新しいMIBを定義する必要があります。
The problems have not been addressed and a new MIB should be defined.
問題が解決されておらず、新しいMIBを定義する必要があります。
Additional objects must be defined for IPv6 addresses and prefixes.
さらなる目的は、IPv6アドレスとプレフィックスを定義する必要があります。
[10] defines extensions to solve this issue, and it is being considered for publication.
[10]この問題を解決するために拡張機能を定義し、そしてそれは公表のために検討されています。
The issue is being resolved.
問題が解決されています。
This problem is currently being addressed by the IPCDN WG.
この問題は、現在IPCDN WGによって対処されています。
This problem is currently being addressed by the IPCDN WG [11].
この問題は、現在IPCDN WG [11]によって対処されています。
The problems have not been addressed and a new MIB may need to be defined.
問題が解決されておらず、新しいMIBを定義する必要があるかもしれません。
The problems have not been addressed and a new MIB may need to be defined.
問題が解決されておらず、新しいMIBを定義する必要があるかもしれません。
The problems have not been addressed a new MIB must be defined.
問題は、新しいMIBを定義する必要があります対処されていませんでした。
This problem is currently being addressed by the MAGMA WG [12].
この問題は、現在MAGMA WG [12]によって対処されています。
The problems have not been addressed and a new MIB may need to be defined.
問題が解決されておらず、新しいMIBを定義する必要があるかもしれません。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは、仕様のIPv6対応の準備を調べます。これは、それ自体ではセキュリティ上の配慮を持っていません。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thank his partner in all ways, Wendy M. Nesser.
著者は、この文書の研究と生産におけるインターネット協会の支援を承認したいと思います。さらに著者、フィリップJ. Nesser IIは、すべての方法で彼のパートナー、ウェンディM. Nesserに感謝したいと思います。
The editor, Andreas Bergstrom, would like to thank Pekka Savola for his guidance and collection of comments for the editing of this document. He would further like to thank Juergen Schoenwaelder, Brian Carpenter, Bert Wijnen and especially C. M. Heard for feedback on many points of this document.
編集者、アンドレアスベルイストロームは、この文書の編集のコメントの彼の指導とコレクションのためペッカSavolaに感謝したいと思います。彼はさらに、この文書の多くのポイントにフィードバックするためにユルゲンSchoenwaelder、ブライアン・カーペンター、バートWijnen、特にC. M.聞いたに感謝したいと思います。
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser、II、P.およびA.ベルイストローム、エディタを、RFC 3789、2004年6月 "のIPv4の調査の概要は、現在展開IETF標準のアドレス"。
[2] Haas, J. and S. Hares, Editors, "Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)", Work in Progress, April 2004.
[2]ハース、J.とS.ノウサギ、編集者、「ボーダーゲートウェイプロトコル（BGP-4）第4バージョンのための管理オブジェクトの定義」、進歩、2004年4月に作業。
[3] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, April 2004.
[3] Joyal、D.およびV. Manral、 "OSPFv3のための管理情報ベース"、進歩、2004年4月に作業。
[4] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "The Mobile IPv6 MIB", Work in Progress, February 2004.
[4] Keeni、G.、小出、K.、永見、K.およびS. Gundavelli、 "モバイルIPv6 MIB"、進歩、2004年2月に働いています。
[5] Routhier, S., Editor, "Management Information Base for the Internet Protocol (IP)", Work in Progress, April 2004.
[5] Routhier、S.、エディタ、 "インターネットプロトコル（IP）のための管理情報ベース"、進歩、2004年4月に作業。
[6] Raghunarayan, R., Editor, "Management Information Base for the Transmission Control Protocol (TCP)", Work in Progress, February 2004.
[6]、進歩、2004年2月に作業Raghunarayan、R.、エディタ、 "伝送制御プロトコル（TCP）のための管理情報ベース"。
[7] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", Work in Progress, April 2004.
[7]フェナー、B.とJ.フリック、進歩、2004年4月に、ワーク "はUDP（User Datagram Protocol）のための管理情報ベース"。
[8] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 Using SMIv2", Work in Progress, February 2004.
[8] Waldbusser、S.、 "リモートネットワーク監視管理情報ベースバージョン2のSMIv2を使用する"、進歩、2004年2月に作業。
[9] Haberman, B., "IP Forwarding Table MIB", Work in Progress, February 2004.
[9]ハーバーマン、B.、 "IP転送テーブルMIB"、進歩、2004年2月に作業を。
[10] Blunk, L., Damas, J., Parent, F. and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", Work in Progress, April 2004.
[10]ブルンク、L.、ダマ、J.、親、F.及びA. Robachevsky、 "ルーティングポリシー仕様言語次世代（RPSLng）"、進歩、2004年4月に働いています。
[11] Raftus, D. and E. Cardona, Editor, "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", Work in Progress, April 2004.
[11] Raftus、D.およびE.カルドナ、エディタ、 "DOCSIS 2.0準拠RFインターフェイスの無線周波数（RF）インターフェースの管理情報ベース" は進歩、2004年4月に働いています。
[12] Chesterfield, J., Editor, "Multicast Group Membership Discovery MIB", Work in Progress, February 2004.
[12]チェスターフィールド、J.、エディタ、 "マルチキャストグループメンバーシップディスカバリーMIB"、進歩、2004年2月に作業。
Please contact the authors with any questions, comments or suggestions at:
でご質問、コメントや提案を作者に連絡してください：
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ. Nesser II校長Nesser＆Nesserコンサルティング13501第百アヴェNE、＃5202カークランド、WA 98034
Phone: +1 425 481 4303 Fax: +1 425 48 EMail: phil@nesser.com
電話：+1 425 481 4303ファックス：+1 425 48 Eメール：phil@nesser.com
Andreas Bergstrom (Editor) Ostfold University College Rute 503 Buer N-1766 Halden Norway
アンドレアスベルイストローム（編集）エースト大学ルートアーチ503 N-1766ハルデンノルウェー
EMail: andreas.bergstrom@hiof.no
メールアドレス：andreas.bergstrom@hiof.no
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。