RFC3796 日本語訳
3796 Survey of IPv4 Addresses in Currently Deployed IETF Operations &Management Area Standards Track and Experimental Documents. P.Nesser, II, A. Bergstrom, Ed.. June 2004. (Format: TXT=78400 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Nesser, II
Request for Comments: 3796 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
ワーキンググループP.Nesser、コメントを求めるII要求をネットワークでつないでください: 3796年のNesser&Nesserコンサルティングカテゴリ: エド情報のA.ベルイストローム、エーストフォールユニバーシティ・カレッジ2004年6月
Survey of IPv4 Addresses in Currently Deployed IETF
Operations & Management Area Standards Track and Experimental Documents
IPv4の調査は、現在配布しているIETFで操作と管理領域が標準化過程と実験ドキュメントであると扱います。
Status of this Memo
この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).
Copyright(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 Operationsであると配布された現在のIPv4アドレスのすべての用法を記録しようとします、そして、Management Areaは規格を受け入れました。 首尾よくすべてのIPv4インターネットからすべてのIPv6インターネットに移行するために、多くの中間の段階を取るでしょう。 これらのステップの1つはIPv4の依存を持っている現在のプロトコルの発展です。 これらのプロトコル(そして、それらの実装)がネットワーク・アドレス独立者であることが再設計されることが望まれていますが、それに失敗するのは二元的にIPv4とIPv6を少なくともサポートするでしょう。 このために、すべてのStandards(完全、Draft、およびProposed)、およびExperimental RFCsは調査されるでしょう、そして、どんな依存も記録されるでしょう。
Nesser II & Bergstrom Informational [Page 1] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[1ページ]情報のRFC3796IPv4
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 組織を記録してください。 . . . . . . . . . . . . . . . . . . . . 2 3. 完全な規格. . . . . . . . . . . . . . . . . . . . . . . . 3 4。 規格を作成してください。 . . . . . . . . . . . . . . . . . . . . . . . 5 5. 提案された標準. . . . . . . . . . . . . . . . . . . . . . 9 6。 実験的なRFCs。 . . . . . . . . . . . . . . . . . . . . . . 34 7. 結果. . . . . . . . . . . . . . . . . . . . . . 36 7.1の概要。 規格。 . . . . . . . . . . . . . . . . . . . . . . . 36 7.2. 規格を作成してください。 . . . . . . . . . . . . . . . . . . . . 36 7.3. 提案された標準. . . . . . . . . . . . . . . . . . . 37 7.4。 実験的なRFCs。 . . . . . . . . . . . . . . . . . . . 40 8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 40 9. 承認. . . . . . . . . . . . . . . . . . . . . . . 40 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.1。 引用規格。 . . . . . . . . . . . . . . . . . . 40 10.2. 有益な参照. . . . . . . . . . . . . . . . . 41 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 42 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 43
1. Introduction
1. 序論
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).
このドキュメントはIPv4アドレスのすべての用法をIETF規格に記録することを目指す1セットの一部です。 処理しやすいフォームに情報を持つ取り組みでは、現在のIETF領域(アプリケーション、インターネット、Operations&Management、ルート設定、Security、Sub-IP、およびTransport)に一致している7通のドキュメントがそれに細かく分けられました。
For a full introduction, please see the introduction [1].
完全な序論に関しては、序論[1]を見てください。
2. Document Organization
2. ドキュメント組織
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はFull、Draft、Proposed Standards、およびExperimental RFCsの生の分析について説明します。 各RFCは自分の番になって、RFC1をきっかけに議論して、(around) RFC3100と共に終わっています。 各RFCのためのコメントは現実に「生です」。 真空ですなわち各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はセクション3、4、5、および6に提示されたデータの分析です。 結果のすべてが全体で考えられて、後のRFCsで解決された問題が関連されているのが、ここにそれがあります。
Nesser II & Bergstrom Informational [Page 2] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[2ページ]情報のRFC3796IPv4
3. Full Standards
3. 完全な規格
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネットStandards(最も一般的に単に「規格」と呼ばれる)は広く履行されて、インターネット中で使用される完全に熟しているプロトコル仕様です。
3.1. RFC 1155 Structure of Management Information
3.1. 経営情報のRFC1155構造
Section 3.2.3.2. IpAddress defines the following:
セクション3.2 .3 .2。 IpAddressは以下を定義します:
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 STRINGとして表されます。
There are several instances of the use of this definition in the rest of the document.
ドキュメントの残りにおけるこの定義の使用のいくつかのインスタンスがあります。
3.2. RFC 1212 Concise MIB definitions
3.2. RFC1212Concise MIB定義
In section 4.1.6 IpAddress is defined as:
セクション4.1.6では、IpAddressは以下と定義されます。
(6) IpAddress-valued: 4 sub-identifiers, in the familiar
a.b.c.d notation.
(6)はIpAddress評価しました: 4 身近なa.b.c.d記法でサブ識別子です。
3.3. RFC 1213 Management Information Base
3.3. RFC1213管理情報ベース
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グループです。
3.4. RFC 2578 Structure of Management Information Version 2 (SMIv2)
3.4. 経営情報バージョン2のRFC2578構造(SMIv2)
Section 7.1.5 defines the IpAddress data type:
セクション7.1 .5 IpAddressデータ型を定義します:
The IpAddress type represents a 32-bit internet address. It is
represented as an OCTET STRING of length 4, in network byte-order.
IpAddressタイプは32ビットのインターネットアドレスを表します。 それはネットワークバイトオーダーにおける長さ4のOCTET STRINGとして表されます。
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.
IpAddressタイプが歴史的な理由のためのタグ付けをされたタイプであることに注意してください。 ネットワーク・アドレスは、TEXTUAL-CONVENTIONマクロの実施を使用することで表されるべきです。
Note the deprecated status of this type; see RFC 3291 for details on the replacement TEXTUAL-CONVENTION definitions.
このタイプの推奨しない状態に注意してください。 交換TEXTUAL-CONVENTION定義に関する詳細に関してRFC3291を見てください。
3.5. RFC 2579 Textual Conventions for SMIv2
3.5. SMIv2のためのRFC2579の原文のコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 3] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[3ページ]情報のRFC3796IPv4
3.6. RFC 2580 Conformance Statements for SMIv2
3.6. SMIv2のためのRFC2580順応声明
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.7. RFC 2819 Remote Network Monitoring Management Information Base
3.7. RFC2819のリモートネットワーク監視管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.8. RFC 3411 An Architecture for Describing SNMP Management Frameworks
3.8. SNMP管理フレームワークについて説明するための1アーキテクチャあたりRFC3411
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.9. RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
3.9. RFC3412メッセージ処理と簡単なネットワーク管理プロトコルのために急いでいること。(SNMP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.10. RFC 3413 SNMP Applications
3.10. RFC3413SNMPアプリケーション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.11. RFC 3414 User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3)
3.11. Simple Network Managementプロトコルのバージョン3のためのRFC3414のUserベースのSecurity Model(USM)(SNMPv3)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.12. RFC 3415 View-based Access Control Model (VACM) for the Simple
Network Management Protocol (SNMP)
3.12. 簡単なネットワーク管理プロトコルのためのRFC3415の視点ベースのアクセス制御モデル(VACM)(SNMP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.13. RFC 3416 Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMP)
3.13. 簡単なネットワーク管理プロトコルのバージョン2のためのRFC3416プロトコル操作(SNMP)
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 MIB2からのデータがIPv4アドレスを含む.1(Table TraversalのAnother Example)がともに使用するTable Traversal、およびセクション4.2.3のExampleは反対します。 これらの例の部での彼らの使用以外に、この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 4] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[4ページ]情報のRFC3796IPv4
3.14. RFC 3417 Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMP)
3.14. 簡単なネットワーク管理プロトコルのバージョン2のためのRFC3417輸送マッピング(SNMP)
Section 2 Definitions contains the following definition:
セクション2 Definitionsは以下の定義を含んでいます:
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
SnmpUDPAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d/2d"STATUSの現在の記述、「UDPアドレスを表します:、」
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-6UDP-ポートネットワークバイトオーダー「構文八重奏ストリング」をコード化する八重奏コンテンツ(サイズ(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(Usage Example)はIPv4がそれの用途を扱う例を含みますが、それには、仕様の操作における意味が全くありません。
3.15. RFC 3418 Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMP)
3.15. 簡単なネットワーク管理プロトコルのバージョン2のためのRFC3418管理情報ベース(SNMP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4. Draft Standards
4. 草稿規格
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.
草稿StandardsはIETFに終わりから二番目の標準のレベルを表します。 複数の、そして、独立していて、共同利用できる実装があるときだけ、プロトコルは草稿規格を実現できます。 草稿Standardsは通常、かなり熟して広く使用されています。
4.1. RFC 1493 Definitions of Managed Objects for Bridges
4.1. ブリッジのための管理オブジェクトのRFC1493定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.2. RFC 1559 DECnet Phase IV MIB Extensions
4.2. RFC1559DECnetフェーズIV MIB拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 5] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[5ページ]情報のRFC3796IPv4
4.3. RFC 1657 Definitions of Managed Objects for the Fourth
Version of the Border Gateway Protocol (BGP-4) using SMIv2
4.3. SMIv2を使用するボーダ・ゲイトウェイ・プロトコル(BGP-4)の第4バージョンのための管理オブジェクトのRFC1657定義
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はこのRFCでBGP4のベースのルーティングシステムのオブジェクトとの取引を定義して、したがって、MIB2で定義されたIpAddressの32ビットの値によって制限される多くのオブジェクトを含んでいます。 明確に、このMIBの値はIPv4アドレスに制限されます。 アップデートは全く必要ではありません、BGP4+がIPv6アドレスとルートの管理を許すように、新しいMIBは定義されるべきですが。
4.4. RFC 1658 Definitions of Managed Objects for Character Stream
Devices using SMIv2
4.4. SMIv2を使用するキャラクターストリームデバイスのための管理オブジェクトのRFC1658定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.5. RFC 1659 Definitions of Managed Objects for RS-232-like Hardware
Devices using SMIv2
4.5. SMIv2を使用するRS-232のようなハードウェアデバイスのための管理オブジェクトのRFC1659定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.6. RFC 1660 Definitions of Managed Objects for Parallel-printer-like
Hardware Devices using SMIv2
4.6. SMIv2を使用する平行なプリンタのようなハードウェアデバイスのための管理オブジェクトのRFC1660定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.7. RFC 1694 Definitions of Managed Objects for SMDS Interfaces using
SMIv2
4.7. SMIv2を使用するSMDSインタフェースへの管理オブジェクトのRFC1694定義
This MIB module definition defines the following subtree:
このMIBモジュール定義は以下の下位木を定義します:
ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }
ipOverSMDSオブジェクト識別子:、:= smdsApplications1
-- 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.
-- このグループにおけるオブジェクトが書き込み禁止ですが--、それらがされるかもしれないエージェントの裁量がそうにそれを読書して書く--管理局、適切に認可されると--、関連するアドレス指定情報を変えてください--、論理的なIPサブネットワークの構成が実装した、オンである、--SMDSの先端であるかもしれない。
-- 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)であるとサポートするのに必要であり、Group AddressesとARPで知らせます。Logical IPサブネットワークで使用されて、扱います。 -- 1つのSMDSアドレスが複数のIPに関連しているかもしれません--アドレス。 1SNIが複数のLISsに関連しているかもしれません。
ipOverSMDSTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpOverSMDSEntry
MAX-ACCESS not-accessible
アクセスしやすくないipOverSMDSTable OBJECT-TYPE SYNTAX SEQUENCE OF IpOverSMDSEntryマックス-ACCESS
Nesser II & Bergstrom Informational [Page 6] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[6ページ]情報のRFC3796IPv4
STATUS current
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ipOverSMDS 1 }
「この実体のIPに関連しているアドレス指定情報のテーブルは扱う」STATUSの現在の記述。 ::= ipOverSMDS1
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 }
「この実体のIPの1つに関するアドレス指定情報は扱う」ipOverSMDSEntry OBJECT-TYPE SYNTAX IpOverSMDSEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ipOverSMDSIndex、ipOverSMDSAddressに索引をつけてください:、:= ipOverSMDSTable1
IpOverSMDSEntry ::=
SEQUENCE {
ipOverSMDSIndex IfIndex,
ipOverSMDSAddress IpAddress,
ipOverSMDSHA SMDSAddress,
ipOverSMDSLISGA SMDSAddress,
ipOverSMDSARPReq SMDSAddress
}
IpOverSMDSEntry:、:= 系列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 }
ipOverSMDSIndex OBJECT-TYPE SYNTAX IfIndexのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このオブジェクトの値はこのエントリーが経営情報を含むインタフェースを特定します」。 " ::= ipOverSMDSEntry1
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 }
「IPはこのエントリーのアドレス指定情報が関係させるものに扱う」ipOverSMDSAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ipOverSMDSEntry2
ipOverSMDSHA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
ipOverSMDSHA OBJECT-TYPE SYNTAX SMDSAddressマックス-ACCESS書き込み禁止STATUS海流
Nesser II & Bergstrom Informational [Page 7] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[7ページ]情報のRFC3796IPv4
DESCRIPTION
"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }
「ステーションはSMDS IndividualはIPに演説する」記述。 ::= ipOverSMDSEntry3
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 }
ipOverSMDSLISGA OBJECT-TYPE SYNTAX SMDSAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「Logical IP Subnetwork(LIS)のすべてのメンバーのSMDS Subscriber-ネットワークInterfaces(SNIs)を特定するために構成されたSMDS Group AddressはSMDSをサポートするネットワークに接続しました」。 ::= ipOverSMDSEntry4
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 }
「SMDSはARP Requestsが送られることになっている(個人かグループ)を扱う」ipOverSMDSARPReq OBJECT-TYPE SYNTAX SMDSAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ipOverSMDSEntry5
Although these object definitions are intended for IPv4 addresses, a similar MIB can be defined for IPv6 addressing.
これらのオブジェクト定義はIPv4アドレスのために意図しますが、IPv6アドレシングのために同様のMIBを定義できます。
4.8. RFC 1724 RIP Version 2 MIB Extension
4.8. RFC1724はバージョン2MIB拡張子を裂きます。
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が必要です。
4.9. RFC 1748 IEEE 802.5 MIB using SMIv2
4.9. SMIv2を使用するRFC1748IEEE802.5MIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.10. RFC 1850 OSPF Version 2 Management Information Base
4.10. RFC1850OSPFバージョン2管理情報ベース
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の新しいバージョンをサポートするのに必要です。
Nesser II & Bergstrom Informational [Page 8] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[8ページ]情報のRFC3796IPv4
4.11. RFC 2115 Management Information Base for Frame Relay DTEs
Using SMIv2
4.11. SMIv2を使用するフレームリレーDTEsのためのRFC2115管理情報ベース
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アドレスがどうFrame Relay DLCIsに写像されるかもしれないかに関するいくつかの例があります。 それらの例以外に、この仕様に基づくIPv4の依存が全くありません。
4.12. RFC 2790 Host Resources MIB
4.12. RFC2790ホストリソースMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.13. RFC 2863 The Interfaces Group MIB
4.13. RFC2863インタフェースはMIBを分類します。
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の依存が全くありません。 自己診断を実行するインタフェースに関して1つのオブジェクト定義における何らかの議論がありますが、オブジェクト自体はIPバージョン独立者です。
4.14. RFC 3592 Definitions of Managed Objects for the Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
4.14. 同期式光通信網/同期デジタルハイアラーキのための管理オブジェクトのRFC3592定義(Sonet/SDH)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.15. RFC 3593 Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals
4.15. 15分の間隔に基づくパフォーマンス歴史を使用するMIBモジュールのためのRFC3593の原文のコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5. Proposed Standards
5. 提案された標準
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.
提案されたStandardsは紹介している平らなドキュメントです。 ただ一つの実装さえのための要件が全くありません。 多くの場合、ProposedはIETF標準化過程で実装されるか、または決して進められません。 したがって、それらはインターネットコミュニティに提示されるしばしばただ提案された考えです。 時々、欠点は暴露されるか、彼らが問題への多くの競争している解決の1つです。これらの後の場合では、この議論の目的に役立たないように議論は全く提示されません。
5.1. RFC 1239 Reassignment of experimental MIBs to standard MIBs
5.1. 標準のMIBsへの実験的なMIBsのRFC1239Reassignment
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.2. RFC 1269 Definitions of Managed Objects for the Border
Gateway Protocol: Version 3
5.2. 境界ゲートウェイへの管理オブジェクトのRFC1269定義は議定書を作ります: バージョン3
The use of BGP3 has been deprecated and is not discussed.
BGP3の使用について、推奨しなく、議論しません。
Nesser II & Bergstrom Informational [Page 9] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[9ページ]情報のRFC3796IPv4
5.3. RFC 1285 FDDI Management Information Base
5.3. RFC1285FDDI管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.4. RFC 1381 SNMP MIB Extension for X.25 LAPB
5.4. X.25 LAPBのためのRFC1381SNMP MIB拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.5. RFC 1382 SNMP MIB Extension for the X.25 Packet Layer
5.5. X.25パケット層のためのRFC1382SNMP MIB拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.6. RFC 1414 Identification MIB
5.6. RFC1414識別MIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.7. RFC 1418 SNMP over OSI
5.7. OSIの上のRFC1418SNMP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.8. RFC 1419 SNMP over AppleTalk
5.8. AppleTalkの上のRFC1419SNMP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.9. RFC 1420 SNMP over IPX
5.9. IPXの上のRFC1420SNMP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.10. RFC 1461 SNMP MIB extension for Multiprotocol Interconnect
over X.25
5.10. X.25の上のMultiprotocol InterconnectのためのRFC1461SNMP MIB拡張子
The following objects are defined in Section 4, Definitions:
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
「最後のEncapsulatedは対応するX.121がアドレスであることがわかるために失敗されて、mioxPleEnAddrToX121LkupFlrsが増加されるように引き起こされたそれを扱う」mioxPleLastFailedEnAddr OBJECT-TYPE SYNTAX OCTET STRING(SIZE(2 .128))のACCESSの書き込み禁止のSTATUSの義務的な記述。 このオブジェクトの最初の八重奏はカプセル化タイプを含んでいて、残っている八重奏は失敗したそのタイプのアドレスを含んでいます。 したがって、IPアドレスのために、長さは5つの八重奏になるでしょう、そして、最初の八重奏は204(十六進法CC)を含むでしょう、そして、最後の4つの八重奏がIPを含むでしょう。
Nesser II & Bergstrom Informational [Page 10] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[10ページ]情報のRFC3796IPv4
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 }
アドレス。 「最初のバイトは即座のカプセル化のための、128(80人に魔法をかける)でしょう、そして、八重奏ストリングの残りには、即座のヘッダーがあるでしょう。」 ::= mioxPleEntry4
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 SYNTAX OCTET STRING(SIZE(0 .128))ACCESSは「このテーブル項目で写像されたリモートホストのEncapsulationアドレス」をSTATUSの義務的な記述に読書して書きます。 ゼロの長さは、使用に、リモート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 }
このオブジェクトの最初の八重奏はカプセル化タイプを含んでいて、残っている八重奏はそのタイプのアドレスを含んでいます。 したがって、IPアドレスのために、長さは5つの八重奏になるでしょう、そして、最初の八重奏は204(十六進法CC)を含むでしょう、そして、最後の4つの八重奏がIPアドレスを含むでしょう。 「最初のバイトは即座のカプセル化のための、128(80人に魔法をかける)でしょう、そして、八重奏ストリングの残りには、即座のヘッダーがあるでしょう。」 DEFVAL、「h、:、:、」= mioxPeerEntry7
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 SYNTAX INTEGER(0 .256)ACCESSは「カプセル化タイプの値」をSTATUSの義務的な記述に読書して書きます。 IPカプセル化のために、これには、204(十六進法CC)の値があるでしょう。 パケットであるとカプセル化されたSNAPに関しては、これには、128の値があるでしょう(80人に魔法をかけてください)。 CLNP、ISO8473年のために、これには、129の値があるでしょう(81人に魔法をかけてください)。 ES-ES、ISO9542年のために、これには、130の値があるでしょう(82人に魔法をかけてください)。 197(十六進法C5)の値はBlacker X.25カプセル化を特定します。 値、0 Nullカプセル化を特定します。
This value can only be written when the
mioxPeerStatus object with the same
mioxPeerStatusが同じくらいで反対するときだけ、この値を書くことができます。
Nesser II & Bergstrom Informational [Page 11] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[11ページ]情報のRFC3796IPv4
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 }
mioxPeerIndexには、underCreationの値があります。 256の値にこのオブジェクトを設定すると、エントリーは削除されます。 「それらのmioxPeerEncIndex値がエントリーを削除する、同じmioxPeerIndexとmioxPeerEncTableの他のすべてのエントリー、および次に、mioxPeerEncIndexが、より高い削除されたエントリーですべて1つ減少するとき。」 ::= mioxPeerEncEntry2
Updated values of the first byte of these objects can be defined to support IPv6 addresses.
IPv6にアドレスをサポートするためにこれらのオブジェクトの最初のバイトのアップデートされた値を定義できます。
5.11. RFC 1471 The Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol
5.11. 二地点間プロトコルのリンク制御プロトコルのための管理オブジェクトのRFC1471定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.12. RFC 1472 The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol
5.12. 二地点間プロトコルのセキュリティプロトコルのための管理オブジェクトのRFC1472定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.13. RFC 1473 The Definitions of Managed Objects for the IP Network
Control Protocol of the Point-to-Point Protocol
5.13. IPのための管理オブジェクトの定義がネットワークでつなぐRFC1473は二地点間プロトコルのプロトコルを制御します。
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. RFC 1474 The Definitions of Managed Objects for the Bridge
Network Control Protocol of the Point-to-Point Protocol
5.14. ブリッジのための管理オブジェクトの定義がネットワークでつなぐRFC1474は二地点間プロトコルのプロトコルを制御します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.15. RFC 1512 FDDI Management Information Base
5.15. RFC1512FDDI管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.16. RFC 1513 Token Ring Extensions to the Remote Network
Monitoring MIB
5.16. リモートネットワーク監視MIBへのRFC1513トークンリング拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.17. RFC 1525 Definitions of Managed Objects for Source Routing
Bridges
5.17. ソースルート設定ブリッジのための管理オブジェクトのRFC1525定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 12] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[12ページ]情報のRFC3796IPv4
5.18. RFC 1628 UPS Management Information Base
5.18. RFC1628は管理情報ベースを上げます。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.19. RFC 1666 Definitions of Managed Objects for SNA NAUs using SMIv2
5.19. SMIv2を使用するSNA NAUsのための管理オブジェクトのRFC1666定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.20. RFC 1696 Modem Management Information Base (MIB) using SMIv2
5.20. SMIv2を使用するRFC1696モデム管理情報ベース(MIB)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.21. RFC 1697 Relational Database Management System (RDBMS)
Management Information Base (MIB) using SMIv2
5.21. SMIv2を使用するRFC1697リレーショナルデータベース管理システム(RDBMS)管理情報ベース(MIB)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.22. RFC 1742 AppleTalk Management Information Base II
5.22. RFC1742AppleTalk管理情報ベースII
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
}
KipEntry:、:= 系列kipNetStart ATNetworkNumber、kipNetEnd ATNetworkNumber、kipNextHop IpAddress、kipHopCount整数、kipBCastAddr IpAddress、kipCore整数、kipType整数、kipState整数、kipShare整数、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 }
kipNextHop OBJECT-TYPE SYNTAX IpAddress ACCESSは「このエントリーの送信先ネットワークへのルートによる次のホップのIPアドレス」をSTATUSの義務的な記述に読書して書きます。 ::= kipEntry3
kipBCastAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESSは義務的な記述をSTATUSに読書して書きます。
Nesser II & Bergstrom Informational [Page 13] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[13ページ]情報のRFC3796IPv4
"The form of the IP address used to broadcast on this
network."
::= { kipEntry 5 }
「IPアドレスの書式は以前はこのネットワークでよく放送されていました。」 ::= kipEntry5
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 }
「ルーティングエントリーがどれであったかからAAプロトコルで学習されて、IPは扱う」kipFrom OBJECT-TYPE SYNTAX IpAddress ACCESSの書き込み禁止のSTATUSの義務的な記述。 「このエントリーがAAプロトコルで作成されないなら、IPアドレス0.0.0.0を含んでいるでしょうに。」 ::= kipEntry10
5.23. RFC 1747 Definitions of Managed Objects for SNA Data Link
Control (SDLC) using SMIv2
5.23. SMIv2を使用するSNAデータリンク制御(SDLC)のための管理オブジェクトのRFC1747定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.24. RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2
5.24. SMIv2を使用しているRFC1749IEEE802.5駅のソースルート設定MIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.25. RFC 1759 Printer MIB
5.25. RFC1759プリンタMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.26. RFC 2006 The Definitions of Managed Objects for IP Mobility
Support using SMIv2
5.26. SMIv2を使用するIPの移動性のための管理オブジェクトの定義がサポートするRFC2006
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 Mobilityのための新しいMIBが必要であると述べられています。
5.27. RFC 2011 SNMPv2 Management Information Base for the Internet
Protocol using SMIv2
5.27. SMIv2を使用するインターネットプロトコルのためのRFC2011SNMPv2管理情報ベース
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をサポートするために定義される必要があります。
Nesser II & Bergstrom Informational [Page 14] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[14ページ]情報のRFC3796IPv4
5.28. RFC 2012 SNMPv2 Management Information Base for the
Transmission Control Protocol using SMIv2
5.28. SMIv2を使用する通信制御プロトコルのためのRFC2012SNMPv2管理情報ベース
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だけをサポートします。 これらの3つのモジュールがIPv4の32ビットのインターネットアドレスを表すために長さ4のOCTET STRINGと定義されたIpAddressタイプを使用します。 (SNMPv2に関してRFC1902、SMIを見てください。) 彼らは、新しい128ビットのIPv6インターネットがアドレスであるとサポートしません。
5.29. RFC 2013 SNMPv2 Management Information Base for the User
Datagram Protocol using SMIv2
5.29. SMIv2を使用するユーザー・データグラム・プロトコルのためのRFC2013SNMPv2管理情報ベース
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だけをサポートします。 これらの3つのモジュールがIPv4の32ビットのインターネットアドレスを表すために長さ4のOCTET STRINGと定義されたIpAddressタイプを使用します。 (SNMPv2に関してRFC1902、SMIを見てください。) 彼らは、新しい128ビットのIPv6インターネットがアドレスであるとサポートしません。
5.30. RFC 2020 IEEE 802.12 Interface MIB
5.30. RFC2020IEEE802.12インタフェースMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.31. RFC 2021 Remote Network Monitoring Management Information Base
Version 2 using SMIv2
5.31. SMIv2を使用するRFC2021のリモートネットワーク監視管理情報ベースバージョン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 SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the
index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
Nesser II & Bergstrom Informational [Page 15] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[15ページ]情報のRFC3796IPv4
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= addressMapEntry2
nlHostAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network address for this nlHostEntry.
「ネットワークはこのnlHostEntryのために扱う」nlHostAddress OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlHostEntry2
nlMatrixSDSourceAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network source address for this nlMatrixSDEntry.
「ネットワークソースはこのnlMatrixSDEntryのために扱う」nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixSDEntry2
nlMatrixSDDestAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network destination address for this
nlMatrixSDEntry.
「ネットワークの目的地はこのnlMatrixSDEntryのために扱う」nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Nesser II & Bergstrom Informational [Page 16] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[16ページ]情報のRFC3796IPv4
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixSDEntry3
nlMatrixDSSourceAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network source address for this nlMatrixDSEntry.
「ネットワークソースはこのnlMatrixDSEntryのために扱う」nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixDSEntry2
nlMatrixDSDestAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The network destination address for this
nlMatrixDSEntry.
「ネットワークの目的地はこのnlMatrixDSEntryのために扱う」nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRINGのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the protocolDirLocalIndex component of the index.
これは八重奏ストリングとしてインデックスのprotocolDirLocalIndexの部品によって特定される特定の意味論と長さで表されます。
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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixDSEntry3
nlMatrixTopNSourceAddress OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-only
nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRINGマックス-ACCESS書き込み禁止
Nesser II & Bergstrom Informational [Page 17] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[17ページ]情報のRFC3796IPv4
STATUS current
DESCRIPTION
"The network layer address of the source host in this
conversation.
「ソースのネットワーク層アドレスはこの会話で接待する」STATUSの現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the associated nlMatrixTopNProtocolDirLocalIndex.
これは八重奏ストリングとして関連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 }
「例えば、protocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixTopNEntry3
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 SYNTAX OCTET STRINGのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the associated nlMatrixTopNProtocolDirLocalIndex.
これは八重奏ストリングとして関連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 }
「例えば、nlMatrixTopNProtocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= nlMatrixTopNEntry4
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 SYNTAX OCTET STRINGのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 これは八重奏ストリングとして関連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."
「例えば、alMatrixTopNProtocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」
Nesser II & Bergstrom Informational [Page 18] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[18ページ]情報のRFC3796IPv4
::= { alMatrixTopNEntry 3 }
::= alMatrixTopNEntry3
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 SYNTAX OCTET STRINGのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
This is represented as an octet string with
specific semantics and length as identified
by the associated alMatrixTopNProtocolDirLocalIndex.
これは八重奏ストリングとして関連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 }
「例えば、alMatrixTopNProtocolDirLocalIndexがipのカプセル化を示すなら、このオブジェクトはipアドレスの4つの八重奏があとに続いた4の長さの八重奏としてネットワークバイトオーダーでコード化されます。」 ::= alMatrixTopNEntry4
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 }
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。trapDestProtocol OBJECT-TYPE SYNTAX INTEGER、ip(1)、ipx(2)、「この罠を送るプロトコル。」 ::= trapDestEntry3
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 SYNTAX OCTET STRINGマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このエントリーを代表して罠を送るアドレス。」
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
関連trapDestProtocolオブジェクトがip(1)と等しいなら、このオブジェクトのコード化は[RFC1906]のsnmpUDPAddressの原文のコンベンションと同じです: -- 長さ6のSnmpUDPAddressのために: -- -- 5-6 UDP-ポートネットワークバイトオーダーをコード化する(1-4 IP-アドレスネットワークバイトオーダー)八重奏コンテンツ
If the associated trapDestProtocol object is equal to ipx(2),
関連trapDestProtocolが反対するなら、ipx(2)には同輩がいます。
Nesser II & Bergstrom Informational [Page 19] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[19ページ]情報のRFC3796IPv4
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
このオブジェクトのコード化は[RFC1906]のsnmpIPXAddressの原文のコンベンションと同じです: -- 長さ12のSnmpIPXAddressのために: -- -- 5-10 物理アドレスネットワークバイトオーダーをコード化する(1-4 ネットワーク・ナンバーネットワークバイトオーダー)八重奏コンテンツ--11-12 ソケット番号ネットワークバイトオーダー
This object may not be modified if the associated
trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 }
「関連trapDestStatusオブジェクトがアクティブな(1)と等しいなら、このオブジェクトは変更されないかもしれません。」 ::= trapDestEntry4
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アドレスだけを参照します。 しかしながら、OCTET STRINGのSYNTAXを使用するので、彼らはIPv6アドレスのためにきめ細かに働くべきです。 trapDestProtocolの値を認知してください。A新しい、(すなわち、ipv6(3)のSYNTAX追加で、この仕様はIPv6に機能的になるべきです。
5.32. RFC 2024 Definitions of Managed Objects for Data Link Switching
using SMIv2
5.32. SMIv2を使用することで切り替わるデータ・リンクへの管理オブジェクトのRFC2024定義
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))
TAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「輸送サービスアドレスを指示します」。 「dlswTCPDomainに関して、ネットワークバイトオーダーにおけるIP-アドレスを含んでいて、長い間、TAddressは4つの八重奏です。」 構文八重奏ストリング(サイズ(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))
-- TCP dlswTCPDomainオブジェクト識別子の上のDLSw:、:= 長さ4のIPアドレスのためのdlswDomains1: -- -- コード化--1-4 IP-アドレスネットワークバイトオーダー--八重奏コンテンツDlswTCPAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d"STATUSの現在の記述は「トランスポート・プロトコルとしてTCPを使用するDLSwのIPアドレスを表します」。 構文八重奏ストリング(サイズ(4))
Nesser II & Bergstrom Informational [Page 20] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[20ページ]情報のRFC3796IPv4
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のSYNTAXを使用する多くのオブジェクト定義があります。 TAddressのためのSYNTAXはおもしろく、最大256のキャラクタのOCTETストリングです。 それは容易にIPv6アドレスのための同様のハイブリッド形式を収容するかもしれません。
A new OID to enhance functionality for DlswTCPAddress could be added to support IPv6 addresses.
IPv6にアドレスをサポートするためにDlswTCPAddressのための機能性を高める新しいOIDを加えることができました。
5.33. RFC 2051 Definitions of Managed Objects for APPC using SMIv2
5.33. SMIv2を使用するAPPCのための管理オブジェクトのRFC2051定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.34. RFC 2096 IP Forwarding Table MIB
5.34. RFC2096IP推進テーブルMIB
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. RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater
Devices using SMIv2 802
5.35. SMIv2 802を使用するIEEE802.3リピータデバイスのための管理オブジェクトのRFC2108定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.36. RFC 2127 ISDN Management Information Base using SMIv2
5.36. SMIv2を使用するRFC2127ISDN管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.37. RFC 2128 Dial Control Management Information Base using
SMIv2
5.37. SMIv2を使用するRFC2128ダイヤルコントロール管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.38. RFC 2206 RSVP Management Information Base using SMIv2
5.38. SMIv2を使用するRFC2206RSVP管理情報ベース
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. RFC 2213 Integrated Services Management Information
Base using SMIv2
5.39. SMIv2を使用する2213年のRFCの統合サービス管理情報ベース
This MIB is IPv6 aware and therefore there are no IPv4 dependencies in this specification.
このMIBはIPv6意識しています、そして、したがって、この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 21] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[21ページ]情報のRFC3796IPv4
5.40. RFC 2214 Integrated Services Management Information
Base Guaranteed Service Extensions using SMIv2
5.40. 統合サービス拡大がSMIv2を使用することで保証された2214年のRFCサービス管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.41. RFC 2232 Definitions of Managed Objects for DLUR using SMIv2
5.41. SMIv2を使用するDLURのための管理オブジェクトのRFC2232定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.42. RFC 2238 Definitions of Managed Objects for HPR using SMIv2
5.42. SMIv2を使用するHPRのための管理オブジェクトのRFC2238定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.43. RFC 2266 Definitions of Managed Objects for IEEE 802.12
Repeater Devices
5.43. IEEE802.12リピータデバイスのための管理オブジェクトのRFC2266定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.44. RFC 2287 Definitions of System-Level Managed Objects for
Applications
5.44. アプリケーションのためのシステムレベル管理オブジェクトのRFC2287定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.45. RFC 2320 Definitions of Managed Objects for Classical IP
and ARP Over ATM Using SMIv2 (IPOA-MIB)
5.45. SMIv2を使用する気圧での古典的なIPとARPのための管理オブジェクトのRFC2320定義(IPOA-MIB)
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. RFC 2417 Definitions of Managed Objects for Multicast
over UNI 3.0/3.1 based ATM Networks
5.46. UNI3.0/3.1の上のMulticastのためのManaged ObjectsのRFC2417DefinitionsはATM Networksを基礎づけました。
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. RFC 2452 IP Version 6 Management Information Base for the
Transmission Control Protocol
5.47. 通信制御プロトコルのためのRFC2452IPバージョン6管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐ、時代遅れにされたIPv6 MIBになるようにaを記録して、この議論で考えられません。
5.48. RFC 2454 IP Version 6 Management Information Base for
the User Datagram Protocol
5.48. ユーザー・データグラム・プロトコルのためのRFC2454IPバージョン6管理情報ベース
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐ、時代遅れにされたIPv6 MIBになるようにaを記録して、この議論で考えられません。
Nesser II & Bergstrom Informational [Page 22] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[22ページ]情報のRFC3796IPv4
5.49. RFC 2455 Definitions of Managed Objects for APPN
5.49. APPNのための管理オブジェクトのRFC2455定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.50. RFC 2456 Definitions of Managed Objects for APPN TRAPS
5.50. APPN罠のための管理オブジェクトのRFC2456定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.51. RFC 2457 Definitions of Managed Objects for Extended Border
Node
5.51. 敷衍された境界ノードのための管理オブジェクトのRFC2457定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.52. RFC 2465 Management Information Base for IP Version 6:
Textual Conventions and General Group
5.52. IPバージョン6のためのRFC2465管理情報ベース: 原文のコンベンションと一般グループ
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐ、時代遅れにされたIPv6 MIBになるようにaを記録して、この議論で考えられません。
5.53. RFC 2466 Management Information Base for IP Version 6:
ICMPv6 Group
5.53. IPバージョン6のためのRFC2466管理情報ベース: ICMPv6グループ
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCはすぐ、時代遅れにされたIPv6 MIBになるようにaを記録して、この議論で考えられません。
5.54. RFC 2494 Definitions of Managed Objects for the DS0
and DS0 Bundle Interface Type
5.54. DS0とDS0バンドルインターフェース型のための管理オブジェクトのRFC2494定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.55. RFC 2495 Definitions of Managed Objects for the DS1, E1,
DS2 and E2 Interface Types
5.55. DS1、1ユーロ、DS2、および2ユーロのインターフェース型のための管理オブジェクトのRFC2495定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.56. RFC 2496 Definitions of Managed Object for the DS3/E3
Interface Type
5.56. 3DS3/Eのインターフェース型のための管理オブジェクトのRFC2496定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.57. RFC 2512 Accounting Information for ATM Networks
5.57. 気圧ネットワークのためのRFC2512課金情報
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 23] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[23ページ]情報のRFC3796IPv4
5.58. RFC 2513 Managed Objects for Controlling the Collection
and Storage of Accounting Information for
Connection-Oriented Networks
5.58. 接続指向のネットワークのために課金情報の収集とストレージを制御するためのRFC2513管理オブジェクト
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.59. RFC 2514 Definitions of Textual Conventions and
OBJECT-IDENTITIES for ATM Management
5.59. 気圧管理のための原文のコンベンションとオブジェクトアイデンティティのRFC2514定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.60. RFC 2515 Definitions of Managed Objects for ATM Management
5.60. 気圧管理のための管理オブジェクトのRFC2515定義
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
}
AtmInterfaceConfEntry:、:= 系列{ atmInterfaceMaxVpcs整数、atmInterfaceMaxVccs整数、atmInterfaceConfVpcs整数、atmInterfaceConfVccs整数、atmInterfaceMaxActiveVpiBits整数、atmInterfaceMaxActiveVciBits整数、atmInterfaceIlmiVpi AtmVpIdentifier、atmInterfaceIlmiVci AtmVcIdentifier; atmInterfaceAddressType整数、atmInterfaceAdminAddress AtmAddr、atmInterfaceMyNeighborIpAddress IpAddress、atmInterfaceMyNeighborIfName DisplayString、atmInterfaceCurrentMaxVpiBits整数、atmInterfaceCurrentMaxVciBits整数、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 }
atmInterfaceMyNeighborIpAddress OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSは「隣人システムのIPアドレスがNetwork Management駅がメッセージをSNMPに送ることができるこのインタフェースの遠い端まで接続しました、IPデータグラムがUDPポート161に発信したので、そのシステムの操作に関してネットワークマネージメント情報にアクセスするために」STATUSの現在の記述に読書して書きます。 「このオブジェクトの値が異なった方法で得られるかもしれないことに例えば、手動の構成か、隣人システムとのILMI相互作用を通して注意してください。」 ::= atmInterfaceConfEntry11
Nesser II & Bergstrom Informational [Page 24] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[24ページ]情報のRFC3796IPv4
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 }
atmInterfaceConfGroup2 OBJECT-GROUP OBJECTS、atmInterfaceMaxVpcs、atmInterfaceMaxVccs、atmInterfaceConfVpcs、atmInterfaceConfVccs、atmInterfaceMaxActiveVpiBits、atmInterfaceMaxActiveVciBits、atmInterfaceIlmiVpi、atmInterfaceIlmiVci、atmInterfaceMyNeighborIpAddress、atmInterfaceMyNeighborIfName、atmInterfaceCurrentMaxVpiBits、atmInterfaceCurrentMaxVciBits、atmInterfaceSubscrAddress、「オブジェクトがATMに関する設定情報を提供する収集は連結する」STATUSの現在の記述。 ::= atmMIBGroups10
Clearly a subsequent revision of this MIB module should define equivalent IPv6 objects.
明確に、このMIBモジュールのその後の改正は同等なIPv6オブジェクトを定義するべきです。
5.61. RFC 2561 Base Definitions of Managed Objects for TN3270E
Using SMIv2
5.61. SMIv2を使用するTN3270Eのための管理オブジェクトのRFC2561基地の定義
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. RFC 2562 Definitions of Protocol and Managed Objects for
TN3270E Response Time Collection Using SMIv2
5.62. SMIv2を使用するTN3270E応答時間収集のためのプロトコルと管理オブジェクトのRFC2562定義
This MIB module inherits IP version-independence by virtue of importing the appropriate definitions from RFC 2561.
RFC2561から適切な定義をインポートすることによってこのMIBモジュールはIPバージョン独立を引き継ぎます。
5.63. RFC 2564 Application Management MIB
5.63. RFC2564アプリケーション管理MIB
The following textual convention is defined:
以下の原文のコンベンションは定義されます:
ApplTAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
ApplTAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述は「輸送サービスアドレスを指示します」。
For snmpUDPDomain, an ApplTAddress is 6 octets long,
snmpUDPDomainに関しては、長い間、ApplTAddressは6つの八重奏です。
Nesser II & Bergstrom Informational [Page 25] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[25ページ]情報のRFC3796IPv4
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))
ネットワークバイトオーダーにおけるIP-アドレスを含む初期の4つの八重奏とネットワークバイトオーダーにUDPポートを含む最後の2。 「snmpUDPDomainに関する詳細のために'Simple Network Managementプロトコル(SNMPv2)のバージョン2のための輸送Mappings'に相談してください。」 構文八重奏ストリング(サイズ(0 .255))
A new TC should be defined to handle IPv6 addresses.
新しいTCは、IPv6アドレスを扱うために定義されるべきです。
5.64. RFC 2584 Definitions of Managed Objects for APPN/HPR in
IP Networks
5.64. IPネットワークにおけるAPPN/HPRのための管理オブジェクトのRFC2584定義
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をサポートしないでしょう。
5.65. RFC 2594 Definitions of Managed Objects for WWW Services
5.65. WWWサービスのための管理オブジェクトのRFC2594定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.66. RFC 2605 Directory Server Monitoring MIB
5.66. RFC2605のディレクトリのサーバのモニターしているMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.67. RFC 2613 Remote Network Monitoring MIB Extensions for
Switched Networks Version 1.0
5.67. 1.0に交換網バージョンのためのMIB拡張子をモニターするRFC2613のリモートネットワーク
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.68. RFC 2618 RADIUS Authentication Client MIB
5.68. RFC2618半径認証クライアントMIB
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,
RadiusAuthServerEntry:、:= 系列、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
Nesser II & Bergstrom Informational [Page 26] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[26ページ]情報のRFC3796IPv4
radiusAuthClientPacketsDropped 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 }
「RADIUS認証サーバのIPアドレスはこのテーブル項目で言及した」radiusAuthServerAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= radiusAuthServerEntry2
There needs to be an update to allow an IPv6 based object for this value.
この値のためのIPv6のベースのオブジェクトを許容するアップデートがあるのが必要です。
5.69. RFC 2619 RADIUS Authentication Server MIB
5.69. RFC2619半径認証サーバMIB
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
}
RadiusAuthClientEntry:、:= 系列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 }
「RADIUS認証クライアントのNAS IPアドレスはこのテーブル項目で言及した」radiusAuthClientAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= radiusAuthClientEntry2
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、推奨しなく、IPv4とIPv6の両方にアドレスをサポートするものに取り替えられる必要があります。
Nesser II & Bergstrom Informational [Page 27] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[27ページ]情報のRFC3796IPv4
5.70. RFC 2622 Routing Policy Specification Language (RPSL)
5.70. RFC2622ルート設定方針仕様言語(RPSL)
The only objects in the version of RPSL that deal with IP addresses are defined as:
RPSLのバージョンにおけるIPアドレスに対処する唯一のオブジェクトが以下と定義されます。
<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.
「>An IPv4が扱う<ipv4-アドレスは0〜255までの範囲のキャラクタドットによって切り離された4つの整数の系列として表される」、」 例えば、128.9 .128 .5 有効なIPv4アドレスを表します。 このドキュメントの残りでは、私たちはIPv4アドレスをIPアドレスと呼ぶかもしれません。
<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アドレスがキャラクタスラッシュを」 /に続けたので、>Anが接頭語を扱う<アドレス接頭語は表されること」が続きました。 ↓これは有効なアドレス接頭語です: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; そして、以下のアドレス接頭語は無効です: 0/0、0か128.9以来の128.9/16は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アドレスと接頭語のための追加オブジェクトは、定義される必要があります。
5.71. RFC 2662 Definitions of Managed Objects for the ADSL Lines
5.71. ADSL線のための管理オブジェクトのRFC2662定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.72. RFC 2667 IP Tunnel MIB
5.72. RFC2667IPトンネルMIB
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.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のためのManagement Information基地(MIB)を定義します。 特に、それはIPv4ネットワークの上でどんなタイプのトンネルも管理するのに使用される管理オブジェクトについて説明します。 拡大MIBsは、プロトコル特有のオブジェクトを管理するように設計されるかもしれません。 同様に、拡大MIBsは、セキュリティ特有のオブジェクトを管理するように設計されるかもしれません。 このMIBは非IPv4ネットワークの上でトンネルを支えません(IPv6ネットワークを含んでいて)。 そのようなトンネルの管理は他のMIBsによってサポートされるかもしれません。
A similar MIB for tunneling over IPv6 should be defined.
IPv6の上でトンネルを堀るための同様のMIBは定義されるべきです。
Nesser II & Bergstrom Informational [Page 28] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[28ページ]情報のRFC3796IPv4
5.73. RFC 2669 DOCSIS Cable Device MIB Cable Device Management
Information Base for DOCSIS compliant Cable Modems and
Cable Modem Termination Systems
5.73. DOCSISの言いなりになっているCable ModemsとCable Modem Termination SystemsのためのRFC2669DOCSIS Cable Device MIB Cable Device Management Information基地
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.
DOCSIS1.0規格は、Cable ModemsがSNMPv1を実装して、IPv4顧客トラフィックを処理するのを必要とするだけです。 このMIBでのデザイン選択はそれらの要件を反映します。 DOCSIS規格の将来のバージョンがまた、SNMPv3とIPv6に支持を要すると予想されます。
5.74. RFC 2670 Radio Frequency (RF) Interface Management Information
Base for MCNS/DOCSIS compliant RF interfaces
5.74. MCNS/DOCSIS対応することのRFインタフェースへのRFC2670Radio Frequency(RF)インタフェースManagement Information基地
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
}
DocsIfCmtsCmStatusEntry:、:= 系列{ docsIfCmtsCmStatusIndex Integer32、docsIfCmtsCmStatusMacAddress MacAddress、docsIfCmtsCmStatusIpAddress IpAddress、docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero、docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero、docsIfCmtsCmStatusRxPower TenthdBmV、docsIfCmtsCmStatusTimingOffset Unsigned32; docsIfCmtsCmStatusEqualizationData八重奏ストリング、docsIfCmtsCmStatusValue整数、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 }
「Cable ModemはIPはこれを扱う」docsIfCmtsCmStatusIpAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 Cable ModemがIPアドレスを全く割り当てさせないか、またはIPアドレスが未知であるなら、このオブジェクトは.0に0.0の値に.0を返します。 「Cable Modemに複数のIPアドレスがあるなら、このオブジェクトはCableインタフェースに関連しているIPアドレスを返します。」 ::= docsIfCmtsCmStatusEntry3
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、推奨しなく、IPv4とIPv6の両方にアドレスをサポートするものに取り替えられる必要があります。
Nesser II & Bergstrom Informational [Page 29] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[29ページ]情報のRFC3796IPv4
5.75. RFC 2674 Definitions of Managed Objects for Bridges with
Traffic Classes, Multicast Filtering and Virtual LAN
Extensions
5.75. トラフィックのクラス、マルチキャストフィルタリング、およびバーチャルLAN拡大とのブリッジのための管理オブジェクトのRFC2674定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.76. RFC 2677 Definitions of Managed Objects for the NBMA Next
Hop Resolution Protocol (NHRP)
5.76. 次のNBMAのための管理オブジェクトのRFC2677定義は解決プロトコルを飛び越します。(NHRP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.77. RFC 2720 Traffic Flow Measurement: Meter MIB
5.77. RFC2720トラフィック流量測定: メーターMIB
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.78. RFC 2725 Routing Policy System Security
5.78. RFC2725ルート設定方針システムセキュリティ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.79. RFC 2726 PGP Authentication for RIPE Database Updates
5.79. 熟しているデータベース更新のためのRFC2726PGP認証
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.80. RFC 2737 Entity MIB (Version 2)
5.80. RFC2737実体MIB(バージョン2)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.81. RFC 2741 Agent Extensibility (AgentX) Protocol Version 1
5.81. RFC2741エージェント伸展性(AgentX)プロトコルバージョン1
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. RFC 2742 Definitions of Managed Objects for Extensible SNMP
Agents
5.82. 広げることができるSNMPエージェントのための管理オブジェクトのRFC2742定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.83. RFC 2748 The COPS (Common Open Policy Service) Protocol
5.83. RFC2748巡査(一般的なオープンポリシーサービス)は議定書を作ります。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.84. RFC 2749 COPS usage for RSVP
5.84. RSVPのためのRFC2749COPS用法
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.85. RFC 2769 Routing Policy System Replication
5.85. RFC2769ルート設定方針システム模写
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 30] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[30ページ]情報のRFC3796IPv4
5.86. RFC 2787 Definitions of Managed Objects for the Virtual
Router Redundancy Protocol
5.86. 仮想のルータ冗長プロトコルのための管理オブジェクトのRFC2787定義
As stated in the Overview section:
Overview部で述べられているように:
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はIPアドレスのためのIPv4に特定のSYNTAXを使用します。 したがって、このMIBは変化がIPv6環境で共同利用しなければならないでしょう。
5.87. RFC 2788 Network Services Monitoring MIB
5.87. MIBをモニターするRFC2788ネットワーク・サービス
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.88. RFC 2789 Mail Monitoring MIB
5.88. RFC2789はモニターしているMIBに郵送します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.89. RFC 2837 Definitions of Managed Objects for the Fabric Element
in Fibre Channel Standard
5.89. 繊維チャンネル規格におけるファブリック要素のための管理オブジェクトのRFC2837定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.90. RFC 2856 Textual Conventions for Additional High Capacity
Data Types
5.90. 追加高容量データ型のためのRFC2856の原文のコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.91. RFC 2864 The Inverted Stack Table Extension to the Interfaces
Group MIB
5.91. インタフェースグループMIBへのRFC2864の逆さのスタックテーブル拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.92. RFC 2895 Remote Network Monitoring MIB Protocol Identifier
Reference
5.92. RFC2895のリモートネットワーク監視MIBプロトコル識別子参照
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.93. RFC 2925 Definitions of Managed Objects for Remote
Ping, Traceroute, and Lookup Operations
5.93. リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトのRFC2925定義
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
マックス-ACCESSが読書して作成するpingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32(0 .65507)UNITS「八重奏」
Nesser II & Bergstrom Informational [Page 31] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[31ページ]情報のRFC3796IPv4
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 }
STATUSの現在の記述は「八重奏におけるピング操作で伝えられるためにデータ部のサイズを指定します」。 通常、ピング要求はIPパケットにコード化されたICMPメッセージです。 IPパケットには、65535の八重奏の最大サイズがあります。 「ICMPかUDPヘッダーのサイズ(両方の8つの八重奏)とIPヘッダーのサイズ(20の八重奏)を引き算すると、65507の八重奏の最大サイズはもたらされます。」 DEFVAL0:、:= pingCtlEntry5
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 }
マックス-ACCESSが読書して作成するtraceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32(0 .65507)UNITS「八重奏」STATUSの現在の記述は「八重奏における、トレースルート要求のデータ部のサイズを指定します」。 トレースルート要求は、UDPデータグラムをIPパケットにコード化することによって、本質的には伝えられます。 「したがって、UDPヘッダーのサイズ(8つの八重奏)とIPヘッダーのサイズ(20の八重奏)を引き算すると、最大65507の八重奏がもたらされます。」 DEFVAL0:、:= traceRouteCtlEntry6
The DESCRIPTION clauses need to be updated to remove the IPv4 dependencies.
記述節は、IPv4の依存を取り除くためにアップデートする必要があります。
5.94. RFC 2932 IPv4 Multicast Routing MIB
5.94. RFC2932IPv4マルチキャストルート設定MIB
This specification is only defined for IPv4 and a similar MIB must be defined for IPv6.
この仕様はIPv4のために定義されるだけです、そして、IPv6のために同様のMIBを定義しなければなりません。
5.95. RFC 2933 Internet Group Management Protocol MIB
5.95. RFC2933インターネット集団経営プロトコルMIB
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などのように。
Nesser II & Bergstrom Informational [Page 32] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[32ページ]情報のRFC3796IPv4
5.96. RFC 2940 Definitions of Managed Objects for Common
Open Policy Service (COPS) Protocol Clients
5.96. 一般的なオープンポリシーサービス(巡査)プロトコルクライアントのための管理オブジェクトのRFC2940定義
This MIB is both IPv4 and IPv6 aware and needs no changes.
このMIBはIPv4とIPv6ともに意識していて、変化を全く必要としません。
5.97. RFC 2954 Definitions of Managed Objects for Frame
Relay Service
5.97. フレームリレーサービスのための管理オブジェクトのRFC2954定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.98. RFC 2955 Definitions of Managed Objects for Monitoring
and Controlling the Frame Relay/ATM PVC Service
Interworking Function
5.98. フレームリレー/気圧PVCサービス織り込む機能をモニターして、制御するための管理オブジェクトのRFC2955定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.99. RFC 2959 Real-Time Transport Protocol Management Information Base
5.99. RFC2959のリアルタイムのトランスポート・プロトコル管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.100. RFC 2981 Event MIB
5.100. RFC2981イベントMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.101. RFC 2982 Distributed Management Expression MIB
5.101. RFC2982分散管理式MIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.102. RFC 3014 Notification Log MIB
5.102. RFC3014通知ログMIB
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.103. RFC 3019 IP Version 6 Management Information Base for
The Multicast Listener Discovery Protocol
5.103. マルチキャストリスナー発見プロトコルのためのRFC3019IPバージョン6管理情報ベース
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
5.104. RFC 3020 Definitions of Managed Objects for Monitoring
and Controlling the UNI/NNI Multilink Frame Relay Function
5.104. UNI/NNIマルチリンクフレームリレー機能をモニターして、制御するための管理オブジェクトのRFC3020定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.105. RFC 3055 Management Information Base for the PINT Services
Architecture
5.105. パイントサービスアーキテクチャのためのRFC3055管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 33] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[33ページ]情報のRFC3796IPv4
5.106. RFC 3060 Policy Core Information Model -- Version 1
Specification (CIM)
5.106. RFC3060方針コア情報モデル--バージョン1仕様(シム)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.107. RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)
5.107. RFC3084は方針の食糧を供給する用法を獲得します。(PRを獲得します)です。
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.
この仕様は、RFC2748に建てて、IPv4とIPv6のできる両方です。 仕様はセクション4.3でサンプルフィルタを定義します。(それは、「それのipv4"」を持っています)。
5.108. RFC 3165 Definitions of Managed Objects for the Delegation of
Management Scripts
5.108. 管理スクリプトの委譲のための管理オブジェクトのRFC3165定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.109. RFC 3231 Definitions of Managed Objects for Scheduling
Management Operations
5.109. スケジューリング管理操作のための管理オブジェクトのRFC3231定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.110. RFC 3291 Textual Conventions for Internet Network Addresses
5.110. インターネットネットワーク・アドレスのためのRFC3291の原文のコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.111. RFC 3635 Definitions of Managed Objects for the
Ethernet-like Interface Types
5.111. イーサネットのようなインターフェース型のための管理オブジェクトのRFC3635定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.112. RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs)
5.112. IEEE802.3中型の付属ユニット管理オブジェクトのRFC3636定義(MAUs)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6. Experimental RFCs
6. 実験的なRFCs
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.
実験的なRFCsはインターネットにwidescale実装か用法を持っていないプロトコルを通常定義します。 しばしばそれらは限られたアリーナで自然か中古の正当です。 それらは、潜在的相互運用性かある他の潜在的役に立つシナリオを許容するためにインターネットコミュニティに記録されます。 いくつかの場合では、それらは主流のソリューションへの代替手段として承認された問題に提示されます。
6.1. RFC 1187 Bulk Table Retrieval with the SNMP
6.1. SNMPとのRFC1187の大量のテーブル検索
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 34] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[34ページ]情報のRFC3796IPv4
6.2. RFC 1224 Techniques for managing asynchronously generated
alerts
6.2. 管理するためのRFC1224Techniquesは警戒を非同期に生成しました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.3. RFC 1238 CLNS MIB for use with Connectionless Network Protocol
(ISO 8473) and End System to Intermediate System (ISO 9542)
6.3. Connectionless Networkプロトコル(ISO8473)との使用のためのRFC1238CLNS MIBとIntermediate SystemへのEnd System(ISO9542)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.4. RFC 1592 Simple Network Management Protocol Distributed Protocol
Interface Version 2.0
6.4. RFC1592の簡単なネットワーク管理プロトコル分配されたプロトコルインタフェースバージョン2.0
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.5. RFC 1792 TCP/IPX Connection Mib Specification
6.5. RFC1792TCP/IPX接続Mib仕様
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.6. RFC 2724 RTFM: New Attributes for Traffic Flow Measurement
6.6. RFC2724RTFM: トラフィック流量測定のための新しい属性
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.7. RFC 2758 Definitions of Managed Objects for Service Level
Agreements Performance Monitoring
6.7. サービス・レベル・アグリーメントパフォーマンスモニターのための管理オブジェクトのRFC2758定義
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.8. RFC 2786 Diffie-Helman USM Key Management Information Base and
Textual Convention
6.8. RFC2786のディフィー-ヘルマンのUSMの主要なManagement Information Baseと原文のコンベンション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.9. RFC 2903 Generic AAA Architecture
6.9. RFC2903ジェネリックAAAアーキテクチャ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.10. RFC 2934 Protocol Independent Multicast MIB for IPv4
6.10. IPv4のためのRFC2934のプロトコルの独立しているマルチキャストMIB
This document is specific to IPv4.
このドキュメントはIPv4に特定です。
6.11. RFC 3179 Script MIB Extensibility Protocol Version 1.1
6.11. RFC3179スクリプトMIB伸展性プロトコルバージョン1.1
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Nesser II & Bergstrom Informational [Page 35] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[35ページ]情報のRFC3796IPv4
7. Summary of Results
7. 結果の概要
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
RFCsの初期の調査では、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%
規格: 15%か40.00%のうちの6は規格を作成します: 15%か26.67%のうちの4は規格を提案しました: 112のうちの26か23.21%の実験的なRFCs: 0 11%か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.
彼らが時代遅れの、そして、未使用のプロトコルを記録するので、多くが動作を全く必要としません、他のものは適切なワーキンググループによって活発にアップデートされているドキュメントプロトコルですが特定されたものでは。 さらに、それらをアップデートしないなら、アップデートするべきですが、どんな操作上の影響も引き起こさない規格の多くのインスタンスがあります。 残っているインスタンスは以下に記録されます。
7.1. Standards
7.1. 規格
7.1.1. STD 16, Structure of Management Information (RFCs 1155 and 1212)
7.1.1. STD16、経営情報の構造(RFCs1155と1212)
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.
RFC1155とRFC1212(情報のドキュメントRFC1215に伴う)はSMIv1を定義します。 これらのドキュメントはSMIv2を定義するRFCs2578、2579、および2580年までに取って代わられました。 SMIv1がもう新しいIETF MIBモジュールの基礎として使用されていないので、このインターネットStandardで特定された制限は少しの動作も必要としません。
7.1.2. STD 17 Simple Network Management Protocol (RFC 1213)
7.1.2. STD17の簡単なネットワーク管理プロトコル(RFC1213)
The limitations identified have been addressed, because RFC 1213 has been split into multiple modules which are all IPv6 capable.
RFC1213がすべてできるIPv6である複数のモジュールに分割されたので、特定された制限は扱われました。
7.2. Draft Standards
7.2. 草稿規格
7.2.1. BGP4 MIB (RFC 1657)
7.2.1. BGP4 MIB(RFC1657)
This problem is currently being addressed by the Inter Domain Routing (IDR) WG [2].
この問題は現在、Inter Domainルート設定(IDR)WG[2]によって扱われています。
7.2.2. SMDS MIB (RFC 1694)
7.2.2. SMDS MIB(RFC1694)
See Internet Area standards. Once a specification for IPv6 over SMDS is created a new MIB must be defined.
インターネットArea規格を見てください。 SMDSの上のIPv6のための仕様がいったん作成されると、新しいMIBを定義しなければなりません。
7.2.3. RIPv2 MIB (RFC 1724)
7.2.3. RIPv2 MIB(RFC1724)
There is no updated MIB module to cover the problems outlined. A new MIB module should be defined.
問題が概説したカバーへのアップデートされたMIBモジュールが全くありません。 新しいMIBモジュールは定義されるべきです。
Nesser II & Bergstrom Informational [Page 36] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[36ページ]情報のRFC3796IPv4
7.2.4. OSPFv2 MIB (RFC 1850)
7.2.4. OSPFv2 MIB(RFC1850)
This problem is currently being addressed by the OSPF WG [3].
この問題は現在、OSPF WG[3]によって扱われています。
7.2.5. Transport MIB (RFC 1906)
7.2.5. 輸送MIB(RFC1906)
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.
RFC1906はRFC3417によって時代遅れにされました、SNMPのためのTransport Mappings、そして、この仕様の制限がそのRFCによって扱われました。(RFCはIPのバージョンから独立している方法で輸送ドメインを指定するのに使用できるTCsを定義します)。 RFC3419は、IPv6サポートが必要であって、すべてのSNMP特有であるというわけではない新しいアプリケーションのためのものであるときに、それらのTCsがSnmpUDPAddressに代わって使用されることを勧めます。
7.3. Proposed Standards
7.3. 提案された標準
7.3.1. MIB for Multiprotocol Interconnect over X.25 (RFC 1461)
7.3.1. MultiprotocolのためのMIBはX.25の上で内部連絡します。(RFC1461)
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モジュールは、それを収容するためにアップデートする必要があるでしょう。
7.3.2. PPP IPCP MIB (RFC 1473)
7.3.2. ppp IPCP MIB(RFC1473)
There is no updated MIB to cover the problems outlined. A new MIB should be defined.
問題が概説したカバーへのMIBをアップデートしません。 新しいMIBは定義されるべきです。
7.3.3. Appletalk MIB (RFC 1742)
7.3.3. Appletalk MIB(RFC1742)
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 (RFC 2006)
7.3.4. SMIv2を使用するIP移動性サポートのための管理オブジェクトの定義(RFC2006)
The problems are being resolved by the MIP6 WG [4].
問題はMIP6 WG[4]によって解決されています。
7.3.5. SMIv2 IP MIB (RFC 2011)
7.3.5. SMIv2IP MIB(RFC2011)
This issue is being resolved by the IPv6 WG [5].
この問題はIPv6 WG[5]によって解決されています。
7.3.6. SNMPv2 TCP MIB (RFC 2012)
7.3.6. SNMPv2 TCP MIB(RFC2012)
This issue is being resolved by the IPv6 WG [6].
この問題はIPv6 WG[6]によって解決されています。
Nesser II & Bergstrom Informational [Page 37] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[37ページ]情報のRFC3796IPv4
7.3.7. SNMPv2 UDP MIB (RFC 2013)
7.3.7. SNMPv2 UDP MIB(RFC2013)
This issue is being resolved by the IPv6 WG [7].
この問題はIPv6 WG[7]によって解決されています。
7.3.8. RMON-II MIB (RFC 2021)
7.3.8. RMON-II MIB(RFC2021)
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の注意にもたらされました。 現在、RFC2021をアップデートするために、進行中[8]には仕事がありますが、特定されたその問題を訴えません。 そのドキュメントの将来のバージョンには解決があると予想されます。
7.3.9. DataLink Switching using SMIv2 MIB (RFC 2024)
7.3.9. SMIv2 MIBを使用するデータリンクの切り換え(RFC2024)
The problems have not been addressed and an updated MIB should be defined.
問題は扱われていません、そして、アップデートされたMIBは定義されるべきです。
7.3.10. IP Forwarding Table MIB (RFC 2096)
7.3.10. IP推進テーブルMIB(RFC2096)
This issue is being worked on by the IPv6 WG [9].
IPv6 WG[9]によってこの問題に働かれています。
7.3.11. Classical IP & ARP over ATM MIB (RFC 2320)
7.3.11. 気圧MIBの上の古典的なIPとARP(RFC2320)
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(RFC2225)の上のClassical IPとARPの最新版はIPv6をサポートしません。 IPv6サポートを加えるためにそのプロトコル仕様をアップデートすると、IPv6アドレスを表す新しいMIBオブジェクトは、このMIBモジュールに追加される必要があるでしょう。
7.3.12. Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417)
7.3.12. UNI3.0/3.1気圧MIBの上のマルチキャスト(RFC2417)
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.
UNI3.0/3.1ATM(RFC2022)の上のMulticastの最新版はIPv6をサポートしません。 IPv6サポートを加えるためにそのプロトコル仕様をアップデートすると、IPv6アドレスを表す新しいMIBオブジェクトは、このMIBモジュールに追加される必要があるでしょう。
7.3.13. ATM MIB (RFC 2515)
7.3.13. 気圧MIB(RFC2515)
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は、現在、RFC2515のための実装レポートを集めていて、この仕様を進めるか、改訂するか、または回収するかを考えています。 特定された問題はWGの注意にもたらされました。
7.3.14. TN3270 MIB (RFC 2562)
7.3.14. TN3270 MIB(RFC2562)
The problems identified are not being addressed and a new MIB module may need to be defined.
特定された問題は扱われていません、そして、新しいMIBモジュールは定義される必要があるかもしれません。
Nesser II & Bergstrom Informational [Page 38] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[38ページ]情報のRFC3796IPv4
7.3.15. Application MIB (RFC 2564)
7.3.15. アプリケーションMIB(RFC2564)
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モジュールは定義される必要があるかもしれません。 1つの可能なソリューションはRFC3419TCsを使用することであるかもしれません。
7.3.16. Definitions of Managed Objects for APPN/HPR in IP Networks
(RFC 2584)
7.3.16. IPネットワークにおけるAPPN/HPRのための管理オブジェクトの定義(RFC2584)
The problems identified are not addressed and a new MIB may be defined.
特定された問題は扱われません、そして、新しいMIBは定義されるかもしれません。
7.3.17. RADIUS MIB (RFC 2618)
7.3.17. 半径MIB(RFC2618)
The problems have not been addressed and a new MIB should be defined.
問題は扱われていません、そして、新しいMIBは定義されるべきです。
7.3.18. RADIUS Authentication Server MIB (RFC 2619)
7.3.18. 半径認証サーバMIB(RFC2619)
The problems have not been addressed and a new MIB should be defined.
問題は扱われていません、そして、新しいMIBは定義されるべきです。
7.3.19. RPSL (RFC 2622)
7.3.19. RPSL(RFC2622)
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]はこの問題を解決するために拡大を定義します、そして、それは公表のために考えられています。
7.3.20. IPv4 Tunnel MIB (RFC 2667)
7.3.20. IPv4トンネルMIB(RFC2667)
The issue is being resolved.
問題は解決されています。
7.3.21. DOCSIS MIB (RFC 2669)
7.3.21. DOCSIS MIB(RFC2669)
This problem is currently being addressed by the IPCDN WG.
この問題は現在、IPCDN WGによって扱われています。
7.3.22. RF MIB For DOCSIS (RFC 2670)
7.3.22. DOCSISのためのrf MIB(RFC2670)
This problem is currently being addressed by the IPCDN WG [11].
この問題は現在、IPCDN WG[11]によって扱われています。
7.3.23. VRRP MIB (RFC 2787)
7.3.23. VRRP MIB(RFC2787)
The problems have not been addressed and a new MIB may need to be defined.
問題は扱われていません、そして、新しいMIBは定義される必要があるかもしれません。
7.3.24. MIB For Traceroute, Pings and Lookups (RFC 2925)
7.3.24. トレースルート、ピング、およびルックアップのためのMIB(RFC2925)
The problems have not been addressed and a new MIB may need to be defined.
問題は扱われていません、そして、新しいMIBは定義される必要があるかもしれません。
Nesser II & Bergstrom Informational [Page 39] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[39ページ]情報のRFC3796IPv4
7.3.25. IPv4 Multicast Routing MIB (RFC 2932)
7.3.25. IPv4マルチキャストルート設定MIB(RFC2932)
The problems have not been addressed a new MIB must be defined.
問題は扱われて、新しいMIBを定義しなければならないということではありません。
7.3.26. IGMP MIB (RFC 2933)
7.3.26. IGMP MIB(RFC2933)
This problem is currently being addressed by the MAGMA WG [12].
この問題は現在、MAGMA WG[12]によって扱われています。
7.4. Experimental RFCs
7.4. 実験的なRFCs
7.4.1. Protocol Independent Multicast MIB for IPv4 (RFC 2934)
7.4.1. IPv4のためのプロトコルの独立しているマルチキャストMIB(RFC2934)
The problems have not been addressed and a new MIB may need to be defined.
問題は扱われていません、そして、新しいMIBは定義される必要があるかもしれません。
8. Security Considerations
8. セキュリティ問題
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは仕様のIPv6-準備を調べます。 これには、本来、セキュリティ問題がありません。
9. Acknowledgements
9. 承認
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.
作者は研究における、インターネット協会のサポートとこのドキュメントの生産を承諾したがっています。 ウェンディーM.Nesser、さらに、作者(フィリップJ.Nesser II)はすべての方法で彼のパートナーに感謝したがっています。
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、ブライアンCarpenter、バートWijnen、および特にC.M.Heardに感謝したがっています。
10. References
10. 参照
10.1. Normative Reference
10.1. 引用規格
[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.ベルイストローム、エディタ、「IPv4の調査への紹介は現在配布しているIETFで規格を扱います」、RFC3789、2004年6月。
Nesser II & Bergstrom Informational [Page 40] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[40ページ]情報のRFC3796IPv4
10.2. Informative References
10.2. 有益な参照
[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] エディターズ、「ボーダ・ゲイトウェイ・プロトコル(BGP-4)の第4バージョンのための管理オブジェクトの定義」というハース、J.、およびS.野兎は進行中(2004年4月)で働いています。
[3] Joyal, D. and V. Manral, "Management Information Base for
OSPFv3", Work in Progress, April 2004.
[3]Joyal、D.、およびManralに対する「OSPFv3"のための管理情報ベース、処理中の作業、2004年4月。」
[4] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "The Mobile
IPv6 MIB", Work in Progress, February 2004.
[4] 「モバイルIPv6 MIB」というKeeni、G.、小出、K.、Nagami、K.、およびS.Gundavelliは進歩、2004年2月に働いています。
[5] Routhier, S., Editor, "Management Information Base for the
Internet Protocol (IP)", Work in Progress, April 2004.
[5] S.、エディタ、「インターネットプロトコル(IP)のための管理情報ベース」というRouthierは進歩、2004年4月に働いています。
[6] Raghunarayan, R., Editor, "Management Information Base for the
Transmission Control Protocol (TCP)", Work in Progress, February
2004.
[6] R.、エディタ、「通信制御プロトコル(TCP)のための管理情報ベース」というRaghunarayanは進歩、2004年2月に働いています。
[7] Fenner, B. and J. Flick, "Management Information Base for the
User Datagram Protocol (UDP)", Work in Progress, April 2004.
[7] 「ユーザー・データグラム・プロトコル(UDP)のための管理情報ベース」というフェナー、B.、およびJ.軽打は進歩、2004年4月に働いています。
[8] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 Using SMIv2", Work in Progress,
February 2004.
[8]Waldbusser、S.、「2004年2月にSMIv2"、進行中の仕事を使用するリモートネットワーク監視管理情報ベースバージョン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.
Progress(2004年4月)の[10]BlunkとL.とダマとJ.とParentとF.とA.Robachevsky、「世代のルート設定Policy Specification Language次(RPSLng)」Work。
[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.Cardona、Editor、「ラジオFrequency(RF)はDOCSIS2.0対応することのRFインタフェースにManagement Information基地を連結します」、ProgressのWork、2004年4月。
[12] Chesterfield, J., Editor, "Multicast Group Membership Discovery
MIB", Work in Progress, February 2004.
[12] チェスターフィールド、J.、エディタ、「マルチキャストグループ会員資格発見MIB」が進歩、2004年2月に働いています。
Nesser II & Bergstrom Informational [Page 41] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[41ページ]情報のRFC3796IPv4
11. Authors' Addresses
11. 作者のアドレス
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第100Ave Ne、#5202カークランド、98034
Phone: +1 425 481 4303 Fax: +1 425 48 EMail: phil@nesser.com
以下に電話をしてください。 +1 425 481、4303Fax: +1 425 48 メール: 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
Nesser II & Bergstrom Informational [Page 42] RFC 3796 IPv4 in the IETF Operations & Management Area June 2004
IETF操作と管理領域2004年6月のNesser IIとベルイストローム[42ページ]情報のRFC3796IPv4
12. Full Copyright Statement
12. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Nesser II & Bergstrom Informational [Page 43]
Nesser IIとベルイストロームInformationalです。[43ページ]
一覧
スポンサーリンク
