[要約] RFC 3796は、IETFのOperations & Management Areaの標準トラックおよび実験的なドキュメントにおけるIPv4アドレスの調査に関するものです。このRFCの目的は、現在のIETFドキュメントにおけるIPv4アドレスの使用状況を把握し、将来のIPv4アドレスの管理に関する情報を提供することです。
Network Working Group P. Nesser, II
Request for Comments: 3796 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents
現在展開されているIETFオペレーションおよび管理エリア標準の追跡および実験文書におけるIPv4アドレスの調査
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented.
このドキュメントでは、現在展開されているIETFオペレーションおよび管理領域に受け入れられている標準でIPv4アドレスのすべての使用を記録しようとしています。すべてのIPv4インターネットからすべてのIPv6インターネットに正常に移行するために、多くの暫定ステップが実行されます。これらの手順の1つは、IPv4依存関係を持つ現在のプロトコルの進化です。これらのプロトコル（およびその実装）がネットワークアドレスが依存しないように再設計されることが期待されていますが、少なくとも二重にIPv4とIPv6をサポートすることに失敗します。この目的のために、すべての標準（フル、ドラフト、提案）、および実験的なRFCが調査され、依存関係が文書化されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 9
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . . 36
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . . 37
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . . 40
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative Reference. . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . 41
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 43
This document is part of a set aiming to record all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Operations & Management, Routing, Security, Sub-IP and Transport).
このドキュメントは、IETF標準でIPv4アドレスのすべての使用を記録することを目的としたセットの一部です。情報を管理可能な形式で入手するために、現在のIETF領域（アプリケーション、インターネット、運用と管理、ルーティング、セキュリティ、サブIP、トランスポート）に準拠した7つのドキュメントに分割されています。
For a full introduction, please see the introduction [1].
完全な紹介については、紹介[1]を参照してください。
The document is organized as described below:
ドキュメントは、以下で説明するように整理されています。
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed.
セクション3、4、5、および6は、それぞれ、完全、ドラフト、および提案された標準、および実験的RFCの生の分析について説明します。各RFCは、RFC 1から始まり、RFC 3100で終了するターンで説明されています。各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に示されているデータの分析です。ここでは、すべての結果が全体として考慮され、後のRFCで解決された問題は相関しています。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネット標準（最も一般的には「標準」と呼ばれる）は、インターネット全体で広く実装および使用されている完全に成熟したプロトコル仕様です。
Section 3.2.3.2. IpAddress defines the following:
セクション3.2.3.2。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のオクテット文字列として表されます。
There are several instances of the use of this definition in the rest of the document.
文書の残りの部分には、この定義の使用に関するいくつかのインスタンスがあります。
In section 4.1.6 IpAddress is defined as:
セクション4.1.6では、iPaddressは次のように定義されています。
(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d notation.
(6) iPaddress-Valued：馴染みのあるA.B.C.D表記の4つのサブIDENTIFIER。
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.
このドキュメントは、ここに列挙するためのこのドキュメントのインスタンスがあまりにも多くあります。影響を受ける特定のオブジェクトグループは、IPグループ、ICMPグループ、TCPグループ、UDPグループ、およびEGPグループです。
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のオクテット文字列として表されます。
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タイプは、歴史的な理由でタグ付きタイプであることに注意してください。ネットワークアドレスは、テキストコンベンションマクロの呼び出しを使用して表現する必要があります。
Note the deprecated status of this type; see RFC 3291 for details on the replacement TEXTUAL-CONVENTION definitions.
このタイプの非推奨ステータスに注意してください。交換テキストコンベンションの定義の詳細については、RFC 3291を参照してください。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
3.9. RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
3.9. RFC 3412シンプルなネットワーク管理プロトコル（SNMP）のメッセージ処理とディスパッチ
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Section 4.2.2.1., Example of Table Traversal, and Section 4.2.3.1., Another Example of Table Traversal, both use objects from MIB2 whose data contains IPv4 addresses. Other than their use in these example sections, there are no IPv4 dependencies in this specification.
セクション4.2.2.1。、テーブルトラバーサルの例、およびセクション4.2.3.1。、テーブルトラバーサルのもう1つの例では、どちらもデータがIPv4アドレスを含むMIB2のオブジェクトを使用します。これらの例セクションでの使用以外に、この仕様にはIPv4依存関係はありません。
Section 2 Definitions contains the following definition:
セクション2の定義には、次の定義が含まれています。
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6))
1-4 IP-Address Network -Byte Order 5-6 UDP-PORT Network-Byte Order "Syntax Octet String（サイズ（6））をコードするオクテットの内容
Section 8.1, Usage Example, also contains examples which uses IPv4 address, but it has no significance in the operation of the specification.
セクション8.1、使用例には、IPv4アドレスを使用する例も含まれていますが、仕様の操作には重要ではありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
ドラフト標準は、IETFの最後から2番目の標準レベルを表しています。プロトコルは、複数の独立した相互運用可能な実装がある場合にのみ、ドラフト標準を達成できます。ドラフト基準は通常、非常に成熟しており、広く使用されています。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
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.
このRFCで定義されているMIBは、BGP4ベースのルーティングシステムのオブジェクトを扱うため、MIB2で定義されたiPaddress 32ビット値によって制限される多くのオブジェクトが含まれています。明らかに、このMIBの値はIPv4アドレスに限定されています。更新は必要ありませんが、IPv6アドレスとルートの管理を可能にするために、BGP4の新しいMIBを定義する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This MIB module definition defines the following subtree:
このMIBモジュール定義は、次のサブツリーを定義します。
ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }
-- Although the objects in this group are read-only, at the
-- agent's discretion they may be made read-write so that the
-- management station, when appropriately authorized, may
-- change the addressing information related to the
-- configuration of a logical IP subnetwork implemented on
-- top of SMDS.
-- 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.
ipOverSMDSTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpOverSMDSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of addressing information relevant to
this entity's IP addresses."
::= { ipOverSMDS 1 }
ipOverSMDSEntry OBJECT-TYPE
SYNTAX IpOverSMDSEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The addressing information for one of this
entity's IP addresses."
INDEX { ipOverSMDSIndex, ipOverSMDSAddress }
::= { ipOverSMDSTable 1 }
IpOverSMDSEntry ::=
SEQUENCE {
ipOverSMDSIndex IfIndex,
ipOverSMDSAddress IpAddress,
ipOverSMDSHA SMDSAddress,
ipOverSMDSLISGA SMDSAddress,
ipOverSMDSARPReq SMDSAddress
}
ipOverSMDSIndex OBJECT-TYPE
SYNTAX IfIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object identifies the
interface for which this entry contains management
information. "
::= { ipOverSMDSEntry 1 }
ipOverSMDSAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address to which this entry's addressing
information pertains."
::= { ipOverSMDSEntry 2 }
ipOverSMDSHA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS Individual address of the IP station."
::= { ipOverSMDSEntry 3 }
ipOverSMDSLISGA OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS Group Address that has been configured
to identify the SMDS Subscriber-Network Interfaces
(SNIs) of all members of the Logical IP Subnetwork
(LIS) connected to the network supporting SMDS."
::= { ipOverSMDSEntry 4 }
ipOverSMDSARPReq OBJECT-TYPE
SYNTAX SMDSAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The SMDS address (individual or group) to which
ARP Requests are to be sent."
::= { ipOverSMDSEntry 5 }
Although these object definitions are intended for IPv4 addresses, a similar MIB can be defined for IPv6 addressing.
これらのオブジェクト定義はIPv4アドレスを対象としていますが、IPv6アドレス指定に対して同様のMIBを定義できます。
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.
予想どおり、このRFCはIPv4のみのルーティングプロトコルのMIBモジュールを定義するため、IPv4依存関係で満たされています。RIPNGの新しいMIBが必要です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This MIB defines managed objects for OSPFv2 which is a protocol used to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 addresses, a new MIB is required to support a new version of OSPF that is IPv6 aware.
このMIBは、IPv4ルーティング情報を交換するために使用されるプロトコルであるOSPFV2の管理されたオブジェクトを定義します。OSPFv2はIPv4アドレスに限定されているため、IPv6認識の新しいバージョンのOSPFをサポートするには、新しいMIBが必要です。
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アドレスをどのようにマッピングしてリレーDLCISをフレーム化するかについてのいくつかの例があります。これらの例を除いて、この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification. There is some discussion in one object definition about an interface performing a self test, but the object itself is IP version independent.
この仕様にはIPv4依存関係はありません。セルフテストを実行するインターフェイスについての1つのオブジェクト定義でいくつかの議論がありますが、オブジェクト自体はIPバージョンに依存しません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases, Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
提案された標準は、入門レベルの文書です。単一の実装にも要件はありません。多くの場合、提案されていることは、IETF標準プロセスで実装または進行することはありません。したがって、それらは多くの場合、インターネットコミュニティに提示される提案されたアイデアです。欠陥が暴露されることもあれば、問題に対する多くの競合する解決策の1つです。これらの後のケースでは、この議論の目的に役立たないため、議論は提示されません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
The use of BGP3 has been deprecated and is not discussed.
BGP3の使用は非推奨であり、議論されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
The following objects are defined in Section 4, Definitions:
次のオブジェクトは、セクション4の定義で定義されています。
mioxPleLastFailedEnAddr OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2..128))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The last Encapsulated address that failed
to find a corresponding X.121 address and
caused mioxPleEnAddrToX121LkupFlrs to be
incremented. The first octet of this object
contains the encapsulation type, the
remaining octets contain the address of that
type that failed. Thus for an IP address,
the length will be five octets, the first
octet will contain 204 (hex CC), and the
last four octets will contain the IP
address. For a snap encapsulation, the
first byte would be 128 (hex 80) and the
rest of the octet string would have the snap
header."
::= { mioxPleEntry 4 }
mioxPeerEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The Encapsulation address of the remote host mapped by this table entry. A length of zero indicates the remote IP address is unknown or unspecified for use as a PLE default.
mioxpeerenaddr object-type構文octet string（size（0..128））アクセス読み取りワイトステータス必須説明 "このテーブルエントリによってマッピングされたリモートホストのカプセル化アドレス。ゼロの長さは、リモートIPアドレスが不明または不明であることを示しますPLEデフォルトとして使用するため。
The first octet of this object contains the
encapsulation type, the remaining octets
contain an address of that type. Thus for
an IP address, the length will be five
octets, the first octet will contain 204
(hex CC), and the last four octets will
contain the IP address. For a snap
encapsulation, the first byte would be 128
(hex 80) and the rest of the octet string
would have the snap header."
DEFVAL { ''h }
::= { mioxPeerEntry 7 }
mioxPeerEncType OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the encapsulation type. For IP encapsulation this will have a value of 204 (hex CC). For SNAP encapsulated packets, this will have a value of 128 (hex 80). For CLNP, ISO 8473, this will have a value of 129 (hex 81). For ES-ES, ISO 9542, this will have a value of 130 (hex 82). A value of 197 (hex C5) identifies the Blacker X.25 encapsulation. A value of 0, identifies the Null encapsulation.
mioxpeerEnctypeオブジェクトタイプの構文整数（0..256）アクセスアクセス読み取りワイトステータス必須説明 "カプセル化タイプの値。IPカプセル化の場合、これは204（hex cc）の値を持ちます。128（六角80）の値。CLNP、ISO 8473の場合、これには129（六角81）の値があります。ES-ES、ISO 9542の場合、これは130（hex 82）の値を持ちます。197（HEX C5）は、Blacker X.25のカプセル化を識別します。
This value can only be written when the
mioxPeerStatus object with the same
mioxPeerIndex has a value of underCreation.
Setting this object to a value of 256
deletes the entry. When deleting an entry,
all other entries in the mioxPeerEncTable
with the same mioxPeerIndex and with an
mioxPeerEncIndex higher then the deleted
entry, will all have their mioxPeerEncIndex
values decremented by one."
::= { mioxPeerEncEntry 2 }
Updated values of the first byte of these objects can be defined to support IPv6 addresses.
これらのオブジェクトの最初のバイトの更新された値は、IPv6アドレスをサポートするために定義できます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
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でターゲットにされています。PPPを介してIPv6をサポートするために、新しいMIBモジュールを定義する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
The following objects are defined:
次のオブジェクトが定義されています。
KipEntry ::= SEQUENCE {
kipNetStart ATNetworkNumber,
kipNetEnd ATNetworkNumber,
kipNextHop IpAddress,
kipHopCount INTEGER,
kipBCastAddr IpAddress,
kipCore INTEGER,
kipType INTEGER,
kipState INTEGER,
kipShare INTEGER,
kipFrom IpAddress
}
kipNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IP address of the next hop in the route to this
entry's destination network."
::= { kipEntry 3 }
kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION
kipbcastaddr object-type構文ipaddressアクセス読み取りワイトステータス必須説明
"The form of the IP address used to broadcast on this
network."
::= { kipEntry 5 }
kipFrom OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The IP address from which the routing entry was
learned via the AA protocol. If this entry was not
created via the AA protocol, it should contain IP
address 0.0.0.0."
::= { kipEntry 10 }
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This document defines a MIB for the Mobile IPv4. Without enumeration, let it be stated that a new MIB for IPv6 Mobility is required.
このドキュメントでは、モバイルIPv4のMIBを定義しています。列挙なしでは、IPv6モビリティの新しいMIBが必要であると述べてください。
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をサポートするために、新しいオブジェクトを定義する必要があります。
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のオクテット文字列として定義されたiPaddressタイプを使用します。（RFC 1902、SMI for Snmpv2を参照してください。）新しい128ビットIPv6インターネットアドレスをサポートしていません。
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のオクテット文字列として定義されたiPaddressタイプを使用します。（RFC 1902、SMI for Snmpv2を参照してください。）新しい128ビットIPv6インターネットアドレスをサポートしていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
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オブジェクトタイプの構文octet string max-accessアクセス不可能なステータス現在の説明 "この関係のネットワークアドレス。
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."
::= { addressMapEntry 2 }
nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this nlHostEntry.
nlhostaddressオブジェクトタイプ構文octet string max-accessアクセス不可能なステータス現在の説明 "このnlhostentryのネットワークアドレス。
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 }
nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixSDEntry.
nlmatrixsdsourceaddress object-type syntax octet string max-accessアクセス不可能なステータス現在の説明 "このnlmatrixsdentryのネットワークソースアドレス。
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 }
nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixSDEntry.
nlmatrixsddestaddress object-type syntax octet string max-accessアクセス不可能なステータス現在の説明 "このnlmatrixsdentryのネットワーク宛先アドレス。
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 }
nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixDSEntry.
nlmatrixdssourceaddress object-type syntax octet string max-access accessable nocessable current current current "このnlmatrixdsentryのネットワークソースアドレス。
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 }
nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixDSEntry.
nlmatrixdsDestAddress Object-Type Syntax Octet String Max-Access Not-Accessable Current Current説明 "このnlmatrixdsentryのネットワーク宛先アドレス。
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 }
nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation.
nlmatrixtopnsourceaddress object-type syntax octet string max-access読み取り専用ステータス現在の説明 "この会話におけるソースホストのネットワークレイヤーアドレス。
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 }
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 max-access読み取り専用ステータス現在の説明 "この会話における宛先ホストのネットワークレイヤーアドレス。
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 }
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 Max-Access読み取り専用ステータス現在
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のカプセル化を示している場合、このオブジェクトは4の長さのオクテットとしてエンコードされ、その後、ネットワークバイトの順序でIPアドレスの4オクテットが続きます。」
::= { alMatrixTopNEntry 3 }
alMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation.
almatrixtopndestaddressオブジェクトタイプ構文octet string max-access読み取り専用ステータス現在の説明 "この会話における宛先ホストのネットワークレイヤーアドレス。
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 }
trapDestProtocol OBJECT-TYPE
SYNTAX INTEGER {
ip(1),
ipx(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The protocol with which to send this trap."
::= { trapDestEntry 3 }
trapDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The address to send traps on behalf of this entry.
trapdestaddress object-type構文octet string max-access read-createステータス現在の説明 "このエントリに代わってトラップを送信するアドレス。
If the associated trapDestProtocol object is equal to ip(1),
the encoding of this object is the same as the snmpUDPAddress
textual convention in [RFC1906]:
-- for a SnmpUDPAddress of length 6:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
-- 5-6 UDP-port network-byte order
If the associated trapDestProtocol object is equal to ipx(2),
the encoding of this object is the same as the snmpIPXAddress
textual convention in [RFC1906]:
-- for a SnmpIPXAddress of length 12:
--
-- octets contents encoding
-- 1-4 network-number network-byte order
-- 5-10 physical-address network-byte order
-- 11-12 socket-number network-byte order
This object may not be modified if the associated
trapDestStatus object is equal to active(1)."
::= { trapDestEntry 4 }
All of the object definitions above (except trapDestProtocol) mention only IPv4 addresses. However, since they use a SYNTAX of OCTET STRING, they should work fine for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e., SYNTAX addition of ipv6(3) should make this specification functional for IPv6.
上記のすべてのオブジェクト定義（trapdestprotocolを除く）は、IPv4アドレスのみに言及しています。ただし、Octet Stringの構文を使用するため、IPv6アドレスの場合は正常に動作するはずです。TrapdestProtocolの新しい正当な価値（つまり、IPv6（3）の構文添加は、この仕様をIPv6に対して機能的にする必要があります。
The following textual conventions are defined:
次のテキストの規則が定義されています。
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For dlswTCPDomain, a TAddress is 4 octets long,
containing the IP-address in network-byte order."
SYNTAX OCTET STRING (SIZE (0..255))
-- DLSw over TCP
dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 }
-- for an IP address of length 4:
--
-- octets contents encoding
-- 1-4 IP-address network-byte order
--
DlswTCPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents the IP address of a DLSw which uses
TCP as a transport protocol."
SYNTAX OCTET STRING (SIZE (4))
Additionally there are many object definitions that use a SYNTAX of TAddress within the document. Interestingly the SYNTAX for TAddress is an OCTET string of up to 256 characters. It could easily accommodate a similar hybrid format for IPv6 addresses.
さらに、ドキュメント内にTaddressの構文を使用する多くのオブジェクト定義があります。興味深いことに、Taddressの構文は、最大256文字のオクテット文字列です。IPv6アドレスの同様のハイブリッド形式に簡単に対応できます。
A new OID to enhance functionality for DlswTCPAddress could be added to support IPv6 addresses.
DLSWTCPADDRESSの機能を強化する新しいOIDを追加して、IPv6アドレスをサポートできます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
The MIB module's main conceptual table ipCidrRouteTable uses IPv4 addresses as index objects and is therefore incapable of representing an IPv6 forwarding information base. A new conceptual table needs to be defined to support IPv6 addresses.
MIBモジュールの主な概念テーブルIPCIDRROTETABALTは、IPv4アドレスをインデックスオブジェクトとして使用するため、IPv6転送情報ベースを表すことができません。IPv6アドレスをサポートするために、新しい概念テーブルを定義する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
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依存関係はありません。
This MIB is IPv6 aware and therefore there are no IPv4 dependencies in this specification.
このMIBはIPv6認識であるため、この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
このMIBは、IPv4に完全に依存しています。同じ機能を提供するには、IPv6の新しいMIBが必要です。
This MIB is wholly dependent on IPv4. A new MIB for IPv6 is required to provide the same functionality.
このMIBは、IPv4に完全に依存しています。同じ機能を提供するには、IPv6の新しいMIBが必要です。
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCは、間もなく廃止されたIPv6 MIBを文書化し、この議論では考慮されていません。
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCは、間もなく廃止されたIPv6 MIBを文書化し、この議論では考慮されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCは、間もなく廃止されたIPv6 MIBを文書化し、この議論では考慮されていません。
This RFC documents a soon to be obsoleted IPv6 MIB and is not considered in this discussion.
このRFCは、間もなく廃止されたIPv6 MIBを文書化し、この議論では考慮されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.58. RFC 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
5.58. RFC 2513接続指向ネットワークの会計情報の収集とストレージを制御するための管理オブジェクト
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This MIB defines the following objects:
このMIBは次のオブジェクトを定義します。
AtmInterfaceConfEntry ::= SEQUENCE {
atmInterfaceMaxVpcs INTEGER,
atmInterfaceMaxVccs INTEGER,
atmInterfaceConfVpcs INTEGER,
atmInterfaceConfVccs INTEGER,
atmInterfaceMaxActiveVpiBits INTEGER,
atmInterfaceMaxActiveVciBits INTEGER,
atmInterfaceIlmiVpi AtmVpIdentifier,
atmInterfaceIlmiVci AtmVcIdentifier,
atmInterfaceAddressType INTEGER,
atmInterfaceAdminAddress AtmAddr,
atmInterfaceMyNeighborIpAddress IpAddress,
atmInterfaceMyNeighborIfName DisplayString,
atmInterfaceCurrentMaxVpiBits INTEGER,
atmInterfaceCurrentMaxVciBits INTEGER,
atmInterfaceSubscrAddress AtmAddr
}
atmInterfaceMyNeighborIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IP address of the neighbor system connected to
the far end of this interface, to which a Network
Management Station can send SNMP messages, as IP
datagrams sent to UDP port 161, in order to access
network management information concerning the
operation of that system. Note that the value
of this object may be obtained in different ways,
e.g., by manual configuration, or through ILMI
interaction with the neighbor system."
::= { atmInterfaceConfEntry 11 }
atmInterfaceConfGroup2 OBJECT-GROUP
OBJECTS {
atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
atmInterfaceConfVpcs, atmInterfaceConfVccs,
atmInterfaceMaxActiveVpiBits,
atmInterfaceMaxActiveVciBits,
atmInterfaceIlmiVpi,
atmInterfaceIlmiVci,
atmInterfaceMyNeighborIpAddress,
atmInterfaceMyNeighborIfName,
atmInterfaceCurrentMaxVpiBits,
atmInterfaceCurrentMaxVciBits,
atmInterfaceSubscrAddress }
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information about an ATM interface."
::= { atmMIBGroups 10 }
Clearly a subsequent revision of this MIB module should define equivalent IPv6 objects.
明らかに、このMIBモジュールのその後の改訂は、同等のIPv6オブジェクトを定義する必要があります。
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の両方の認識です。
This MIB module inherits IP version-independence by virtue of importing the appropriate definitions from RFC 2561.
このMIBモジュールは、RFC 2561から適切な定義をインポートすることにより、IPバージョンに依存します。
The following textual convention is defined:
次のテキスト条約が定義されています。
ApplTAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
For snmpUDPDomain, an ApplTAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult 'Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)' for further information on snmpUDPDomain." SYNTAX OCTET STRING (SIZE (0..255))
snmpudpdomainの場合、Appltaddressの長さは6オクターで、最初の4オクテットはネットワークバイトの順序でIPアドレスを含み、最後の2はUDPポートをネットワークバイト順に含みます。SNMPUDPDOMAINの詳細については、「シンプルネットワーク管理プロトコル（SNMPV2）のバージョン2のトランスポートマッピング」を参照してください。
A new TC should be defined to handle IPv6 addresses.
IPv6アドレスを処理するために、新しいTCを定義する必要があります。
Many of the object definitions described in this document assume the use of the IPv4 only TOS header bits. It is therefore IPv4-only in nature and will not support IPv6.
このドキュメントで説明されているオブジェクト定義の多くは、IPv4のみのTOSヘッダービットの使用を想定しています。したがって、本質的にIPv4のみであり、IPv6はサポートしません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This RFC defines the following objects:
このRFCは次のオブジェクトを定義します。
RadiusAuthServerEntry ::= SEQUENCE {
radiusAuthServerIndex Integer32,
radiusAuthServerAddress IpAddress,
radiusAuthClientServerPortNumber Integer32,
radiusAuthClientRoundTripTime TimeTicks,
radiusAuthClientAccessRequests Counter32,
radiusAuthClientAccessRetransmissions Counter32,
radiusAuthClientAccessAccepts Counter32,
radiusAuthClientAccessRejects Counter32,
radiusAuthClientAccessChallenges Counter32,
radiusAuthClientMalformedAccessResponses Counter32,
radiusAuthClientBadAuthenticators Counter32,
radiusAuthClientPendingRequests Gauge32,
radiusAuthClientTimeouts Counter32,
radiusAuthClientUnknownTypes Counter32,
radiusAuthClientPacketsDropped Counter32
}
radiusAuthServerAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The IP address of the RADIUS authentication server
referred to in this table entry."
::= { radiusAuthServerEntry 2 }
There needs to be an update to allow an IPv6 based object for this value.
この値にIPv6ベースのオブジェクトを許可するための更新が必要です。
This MIB defines the followings objects:
このMIBは、次のオブジェクトを定義します。
RadiusAuthClientEntry ::= SEQUENCE {
radiusAuthClientIndex Integer32,
radiusAuthClientAddress IpAddress,
radiusAuthClientID SnmpAdminString,
radiusAuthServAccessRequests Counter32,
radiusAuthServDupAccessRequests Counter32,
radiusAuthServAccessAccepts Counter32,
radiusAuthServAccessRejects Counter32,
radiusAuthServAccessChallenges Counter32,
radiusAuthServMalformedAccessRequests Counter32,
radiusAuthServBadAuthenticators Counter32,
radiusAuthServPacketsDropped Counter32,
radiusAuthServUnknownTypes Counter32
}
radiusAuthClientAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The NAS-IP-Address of the RADIUS authentication client
referred to in this table entry."
::= { radiusAuthClientEntry 2 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、IPv4アドレスとIPv6アドレスの両方をサポートするオブジェクトに廃止され、置き換える必要があります。
The only objects in the version of RPSL that deal with IP addresses are defined as:
IPアドレスを扱うRPSLのバージョンの唯一のオブジェクトは、次のように定義されます。
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
<IPv4-Address> IPv4アドレスは、文字DOTで分離された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.
<Address-Prefix>アドレスプレフィックスは、IPv4アドレスとして表され、その後の文字スラッシュ "/"に続いて0から32の範囲の整数が続きます。/16、0.0.0.0/0;また、次のアドレスのプレフィックスは無効です：0/0、128.9/16は0または128.9が4つの整数を含む文字列ではないためです。
There seems to be an awareness of IPv6 because of the terminology but it is not specifically defined. Therefore additional objects for IPv6 addresses and prefixes need to be defined.
用語のためにIPv6の認識があるようですが、それは具体的には定義されていません。したがって、IPv6アドレスとプレフィックスの追加オブジェクトを定義する必要があります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
The Abstract of this document says:
このドキュメントの要約には次のように書かれています。
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.
このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用する管理情報ベース（MIB）を定義します。特に、IPv4ネットワークを介したあらゆるタイプのトンネルの管理に使用される管理されたオブジェクトについて説明します。拡張MIBSは、プロトコル固有のオブジェクトを管理するために設計できます。同様に、拡張MIBは、セキュリティ固有のオブジェクトを管理するために設計されている場合があります。このMIBは、非IPV4ネットワーク（IPv6ネットワークを含む）上のトンネルをサポートしていません。そのようなトンネルの管理は、他のMIBによってサポートされる場合があります。
A similar MIB for tunneling over IPv6 should be defined.
IPv6を介したトンネリング用の同様のMIBを定義する必要があります。
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. RFC 2669 DOCSISケーブルデバイスMIBケーブルデバイス管理情報DOCSISコンプライアンスケーブルモデムとケーブルモデム終了システム
This document states:
このドキュメントは次のように述べています。
Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements. Future versions of the DOCSIS standard are expected to require support for SNMPv3 and IPv6 as well.
DOCSIS 1.0標準では、SNMPV1を実装し、IPv4の顧客トラフィックを処理するためのケーブルモデムのみが必要であることに注意してください。このMIBの設計の選択は、これらの要件を反映しています。DOCSIS標準の将来のバージョンは、SNMPV3とIPv6のサポートも必要とされると予想されます。
This MIB defines the following objects:
このMIBは次のオブジェクトを定義します。
DocsIfCmtsCmStatusEntry ::= SEQUENCE {
docsIfCmtsCmStatusIndex Integer32,
docsIfCmtsCmStatusMacAddress MacAddress,
docsIfCmtsCmStatusIpAddress IpAddress,
docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero,
docsIfCmtsCmStatusRxPower TenthdBmV,
docsIfCmtsCmStatusTimingOffset Unsigned32,
docsIfCmtsCmStatusEqualizationData OCTET STRING,
docsIfCmtsCmStatusValue INTEGER,
docsIfCmtsCmStatusUnerroreds Counter32,
docsIfCmtsCmStatusCorrecteds Counter32,
docsIfCmtsCmStatusUncorrectables Counter32,
docsIfCmtsCmStatusSignalNoise TenthdB,
docsIfCmtsCmStatusMicroreflections Integer32
}
docsIfCmtsCmStatusIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"IP address of this Cable Modem. If the Cable Modem has no
IP address assigned, or the IP address is unknown, this
object returns a value of 0.0.0.0. If the Cable Modem has
multiple IP addresses, this object returns the IP address
associated with the Cable interface."
::= { docsIfCmtsCmStatusEntry 3 }
This object needs to be deprecated and replaced by one that supports both IPv4 and IPv6 addresses.
このオブジェクトは、IPv4アドレスとIPv6アドレスの両方をサポートするオブジェクトに廃止され、置き換える必要があります。
5.75. RFC 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions
5.75. RFC 2674トラフィッククラス、マルチキャストフィルタリング、仮想LAN拡張機能を備えたブリッジ用の管理されたオブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Although the examples in the document are for IPv4 transport only, there is no IPv4 dependency in the AgentX protocol itself.
ドキュメントの例はIPv4トランスポートのみですが、AgentXプロトコル自体にIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
As stated in the Overview section:
概要セクションに記載されているように：
Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment.
VRRPプロトコルはIPv4ルーターのみで使用することを目的としているため、このMIBはIPv4に固有のIPアドレスに構文を使用します。したがって、このMIBがIPv6環境で相互運用するには変更が必要になります。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
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
STATUS current
DESCRIPTION
"Specifies the size of the data portion to be
transmitted in a ping operation in octets. A ping
request is usually an ICMP message encoded
into an IP packet. An IP packet has a maximum size
of 65535 octets. Subtracting the size of the ICMP
or UDP header (both 8 octets) and the size of the IP
header (20 octets) yields a maximum size of 65507
octets."
DEFVAL { 0 }
::= { pingCtlEntry 5 }
traceRouteCtlDataSize OBJECT-TYPE
SYNTAX Unsigned32 (0..65507)
UNITS "octets"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the data portion of a traceroute
request in octets. A traceroute request is essentially
transmitted by encoding a UDP datagram into a
IP packet. So subtracting the size of a UDP header
(8 octets) and the size of a IP header (20 octets)
yields a maximum of 65507 octets."
DEFVAL { 0 }
::= { traceRouteCtlEntry 6 }
The DESCRIPTION clauses need to be updated to remove the IPv4 dependencies.
IPv4依存関係を削除するには、説明条項を更新する必要があります。
This specification is only defined for IPv4 and a similar MIB must be defined for IPv6.
この仕様はIPv4に対してのみ定義され、同様のMIBをIPv6で定義する必要があります。
As stated in this document:
このドキュメントで述べたように：
Since IGMP is specific to IPv4, this MIB does not support management of equivalent functionality for other address families, such as IPv6.
IGMPはIPv4に固有であるため、このMIBはIPv6などの他のアドレスファミリの同等の機能の管理をサポートしていません。
This MIB is both IPv4 and IPv6 aware and needs no changes.
このMIBはIPv4とIPv6の両方を認識しており、変更は必要ありません。
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. RFC 2955フレームリレー/ATM PVCサービスインターワーキング機能を監視および制御するための管理されたオブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.100. RFC 2981 Event MIB
5.100。RFC 2981イベントMIB
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.101. RFC 2982 Distributed Management Expression MIB
5.101。RFC 2982分散管理式MIB
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.102. RFC 3014 Notification Log MIB
5.102。RFC 3014通知ログ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。RFC 3019 IPバージョン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。RFC 3020 UNI/NNIマルチリンクフレームリレー機能を監視および制御するための管理されたオブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.105. RFC 3055 Management Information Base for the PINT Services Architecture
5.105。RFC 3055パイントサービスアーキテクチャ用の管理情報ベース
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.106. RFC 3060 Policy Core Information Model -- Version 1 Specification (CIM)
5.106。RFC 3060ポリシーコア情報モデル - バージョン1仕様（CIM）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.107. RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)
5.107。RFC 3084 PolicyプロビジョニングのためのCOPSの使用（COPS-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.
この仕様はRFC 2748に基づいており、IPv4とIPv6の両方が可能です。仕様では、セクション4.3のサンプルフィルターを定義します。セクション4.3には「IPv4」があります。
5.108. RFC 3165 Definitions of Managed Objects for the Delegation of Management Scripts
5.108。RFC 3165管理スクリプトの委任のための管理されたオブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.109. RFC 3231 Definitions of Managed Objects for Scheduling Management Operations
5.109。RFC 3231管理操作のスケジューリングのための管理されたオブジェクトの定義
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
5.110. RFC 3291 Textual Conventions for Internet Network Addresses
5.110。RFC 3291インターネットネットワークアドレスのテキストコンベンション
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。RFC 3635イーサネットのようなインターフェイスタイプの管理されたオブジェクトの定義
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。RFC 3636 IEEE 802.3の媒体アタッチメントユニットの管理されたオブジェクトの定義（MAUS）
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases, they are presented as alternatives to the mainstream solution to an acknowledged problem.
通常、実験的なRFCは、インターネット上での幅広い実装や使用法を持たないプロトコルを定義します。それらはしばしば本質的に礼儀正しさであるか、限られた分野で使用されています。それらは、潜在的な相互運用性またはその他の潜在的な有用なシナリオを可能にするために、インターネットコミュニティに文書化されています。いくつかのケースでは、それらは、認められた問題の主流の解決策の代替として提示されます。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
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. RFC 1238 CLNS MIB ConnectionLess Network Protocol（ISO 8473）およびEnd Systemから中間システム（ISO 9542）で使用する
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様はIPv4とIPv6の両方であり、変更は必要ありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
This document is specific to IPv4.
このドキュメントはIPv4に固有です。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4依存関係はありません。
In the initial survey of RFCs, 36 positives were identified out of a total of 153, broken down as follows:
RFCの最初の調査では、合計153の36の陽性が特定され、次のように分類されました。
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または23.21％の実験RFCS：11または0.00％のうち0
Of those identified, many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that should be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below.
特定されたもののうち、多くは時代遅れで未使用のプロトコルを文書化するため、アクションは必要ありませんが、他のものは適切なワーキンググループによって積極的に更新されているドキュメントプロトコルです。さらに、更新する必要があるが、更新されていない場合は運用上の影響を引き起こさない標準の多くのインスタンスがあります。残りのインスタンスは以下に文書化されています。
RFC 1155 and RFC 1212 (along with the informational document RFC 1215) define SMIv1. These documents have been superseded by RFCs 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer being used as the basis for new IETF MIB modules, the limitations identified in this Internet Standard do not require any action.
RFC 1155およびRFC 1212（情報ドキュメントRFC 1215とともに）SMIV1を定義します。これらのドキュメントは、SMIV2を定義するRFCS 2578、2579、および2580に取って代わられています。SMIV1は新しいIETF MIBモジュールの基礎として使用されなくなったため、このインターネット標準で特定された制限はアクションを必要としません。
The limitations identified have been addressed, because RFC 1213 has been split into multiple modules which are all IPv6 capable.
RFC 1213がすべてIPv6対応の複数のモジュールに分割されているため、特定された制限に対処されています。
This problem is currently being addressed by the Inter Domain Routing (IDR) WG [2].
この問題は現在、Inter Domainルーティング（IDR）WG [2]によって対処されています。
See Internet Area standards. Once a specification for IPv6 over SMDS is created a new MIB must be defined.
インターネットエリアの標準を参照してください。SMD上のIPv6の仕様が作成されると、新しいMIBを定義する必要があります。
There is no updated MIB module to cover the problems outlined. A new MIB module should be defined.
概説されている問題をカバーするための更新されたMIBモジュールはありません。新しいMIBモジュールを定義する必要があります。
This problem is currently being addressed by the OSPF WG [3].
この問題は現在、OSPF WG [3]によって対処されています。
RFC 1906 has been obsoleted by RFC 3417, Transport Mappings for SNMP, and the limitations of this specification have been addressed by that RFC, which defines TCs that can be used to specify transport domains in an IP version-independent way. RFC 3419 recommends that those TCs be used in place of SnmpUDPAddress when IPv6 support is required and for all new applications that are not SNMP-specific.
RFC 1906は、SNMPの輸送マッピングRFC 3417によって廃止されており、この仕様の制限は、IPバージョンに依存しない方法で輸送ドメインを指定するために使用できるTCを定義するRFCによって対処されています。RFC 3419は、IPv6サポートが必要な場合、およびSNMP固有ではないすべての新しいアプリケーションに対して、これらのTCをSNMPudPaddressの代わりに使用することを推奨しています。
This problem has not been addressed. If a user requirement for IPv6 over X.25 develops (which is thought to be unlikely) then this MIB module will need to be updated in order to accommodate it.
この問題は対処されていません。X.25を超えるIPv6のユーザー要件が開発されている場合（これはありそうもないと考えられています）、このMIBモジュールに対応するために更新する必要があります。
There is no updated MIB to cover the problems outlined. A new MIB should be defined.
概説されている問題をカバーするための更新されたMIBはありません。新しいMIBを定義する必要があります。
This problem has not been addressed. If a user requirement for IPv6 over Appletalk develops (which is thought to be unlikely) then this MIB module will need to be updated (or a new MIB module will need to be created) in order to accommodate it.
この問題は対処されていません。AppleTalkを介したIPv6のユーザー要件が開発されている場合（これはありそうもないと考えられています）、このMIBモジュールを更新する必要があります（または新しいMIBモジュールを作成する必要があります）。
The problems are being resolved by the MIP6 WG [4].
問題はMIP6 WG [4]によって解決されています。
This issue is being resolved by the IPv6 WG [5].
この問題は、IPv6 WG [5]によって解決されています。
This issue is being resolved by the IPv6 WG [6].
この問題は、IPv6 WG [6]によって解決されています。
This issue is being resolved by the IPv6 WG [7].
この問題は、IPv6 WG [7]によって解決されています。
This issue has been brought to the attention of the RMONMIB WG. Currently, there is a work in progress [8] to update RFC 2021, but it does not address the problems that have been identified; it is expected that there will be a resolution in a future version of that document.
この問題は、rmonmib wgの注意を喚起しています。現在、RFC 2021を更新する作業[8]がありますが、特定された問題に対処していません。そのドキュメントの将来のバージョンに解決策があると予想されます。
The problems have not been addressed and an updated MIB should be defined.
問題は対処されておらず、更新されたMIBを定義する必要があります。
This issue is being worked on by the IPv6 WG [9].
この問題は、IPv6 WG [9]によって取り組んでいます。
The current version of Classical IP and ARP over ATM (RFC 2225) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
Classical IPおよびARP Over ATM（RFC 2225）の現在のバージョンは、IPv6をサポートしていません。IPv6サポートを追加するためにそのプロトコル仕様が更新された場合、IPv6アドレスを表す新しいMIBオブジェクトをこのMIBモジュールに追加する必要があります。
The current version of Multicast over UNI 3.0/3.1 ATM (RFC 2022) does not support IPv6. If and when that protocol specification is updated to add IPv6 support, then new MIB objects to represent IPv6 addresses will need to be added to this MIB module.
UNI 3.0/3.1 ATM（RFC 2022）上のマルチキャストの現在のバージョンは、IPv6をサポートしていません。IPv6サポートを追加するためにそのプロトコル仕様が更新された場合、IPv6アドレスを表す新しいMIBオブジェクトをこのMIBモジュールに追加する必要があります。
The AToM MIB WG is currently collecting implementation reports for RFC 2515 and is considering whether to advance, revise, or retire this specification. The problems identified have been brought to the attention of the WG.
Atom MIB WGは現在、RFC 2515の実装レポートを収集しており、この仕様を前進、修正、または廃止するかどうかを検討しています。特定された問題は、WGの注意を喚起しています。
The problems identified are not being addressed and a new MIB module may need to be defined.
特定された問題は対処されておらず、新しいMIBモジュールを定義する必要がある場合があります。
The problems identified are not being addressed and a new MIB module may need to be defined. One possible solution might be to use the RFC 3419 TCs.
特定された問題は対処されておらず、新しいMIBモジュールを定義する必要がある場合があります。考えられる解決策の1つは、RFC 3419 TCSを使用することです。
7.3.16. Definitions of Managed Objects for APPN/HPR in IP Networks (RFC 2584)
7.3.16. IPネットワークのAPPN/HPRのマネージドオブジェクトの定義（RFC 2584）
The problems identified are not addressed and a new MIB may be defined.
特定された問題は対処されておらず、新しいMIBが定義される場合があります。
The problems have not been addressed and a new MIB should be defined.
問題は対処されておらず、新しいMIBを定義する必要があります。
The problems have not been addressed and a new MIB should be defined.
問題は対処されておらず、新しいMIBを定義する必要があります。
Additional objects must be defined for IPv6 addresses and prefixes.
IPv6アドレスとプレフィックスには、追加のオブジェクトを定義する必要があります。
[10] defines extensions to solve this issue, and it is being considered for publication.
[10] この問題を解決するための拡張機能を定義し、公開とみなされています。
The issue is being resolved.
問題は解決されています。
This problem is currently being addressed by the IPCDN WG.
この問題は現在、IPCDN WGによって対処されています。
This problem is currently being addressed by the IPCDN WG [11].
この問題は現在、IPCDN WG [11]によって対処されています。
The problems have not been addressed and a new MIB may need to be defined.
問題は対処されておらず、新しいMIBを定義する必要がある場合があります。
The problems have not been addressed and a new MIB may need to be defined.
問題は対処されておらず、新しいMIBを定義する必要がある場合があります。
The problems have not been addressed a new MIB must be defined.
問題は対処されていません。新しいMIBを定義する必要があります。
This problem is currently being addressed by the MAGMA WG [12].
この問題は現在、マグマWG [12]によって対処されています。
The problems have not been addressed and a new MIB may need to be defined.
問題は対処されておらず、新しいMIBを定義する必要がある場合があります。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモでは、仕様のIPv6対応を調べます。これにはセキュリティ上の考慮事項はありません。
The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thank his partner in all ways, Wendy M. Nesser.
著者は、この文書の研究と制作におけるインターネット社会の支援を認めたいと考えています。さらに、著者のフィリップ・J・ネッサーIIは、あらゆる点で彼のパートナー、ウェンディ・M・ネッサーに感謝したいと思います。
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.
編集者のアンドレアス・バーグストロムは、このドキュメントの編集に関するコメントの指導とコメントのコレクションについて、Pekka Savolaに感謝したいと思います。彼はさらに、Juergen Schoenwaelder、Brian Carpenter、Bert Wijnen、特にC. M.がこの文書の多くのポイントに関するフィードバックを聞いたことに感謝したいと思います。
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser、II、P。およびA. Bergstrom、編集者、「現在展開されているIETF標準におけるIPv4アドレスの調査の紹介」、RFC 3789、2004年6月。
[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] Haas、J。およびS. Hares、編集者、「Border Gateway Protocol（BGP-4）の4番目のバージョンの管理されたオブジェクトの定義」、2004年4月、進行中の作業。
[3] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, April 2004.
[3] Joyal、D。およびV. Manral、「OSPFV3の管理情報ベース」、2004年4月、進行中の作業。
[4] Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "The Mobile IPv6 MIB", Work in Progress, February 2004.
[4] Keeni、G.、Koide、K.、Nagami、K。、およびS. Gundavelli、「The Mobile IPv6 MIB」、2004年2月、進行中の作業。
[5] Routhier, S., Editor, "Management Information Base for the Internet Protocol (IP)", Work in Progress, April 2004.
[5] Routhier、S.、編集者、「インターネットプロトコル（IP）の管理情報ベース」、2004年4月、進行中の作業。
[6] Raghunarayan, R., Editor, "Management Information Base for the Transmission Control Protocol (TCP)", Work in Progress, February 2004.
[6] Raghunarayan、R.、編集者、「送信制御プロトコル（TCP）の管理情報ベース」、2004年2月、作業中。
[7] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", Work in Progress, April 2004.
[7] Fenner、B。およびJ. Flick、「ユーザーデータグラムプロトコル（UDP）の管理情報ベース」、2004年4月、進行中の作業。
[8] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 Using SMIv2", Work in Progress, February 2004.
[8] Waldbusser、S。、「リモートネットワーク監視管理情報ベースバージョン2を使用したバージョン2」、2004年2月、進行中の作業。
[9] Haberman, B., "IP Forwarding Table MIB", Work in Progress, February 2004.
[9] ハーバーマン、B。、「IP転送テーブルMIB」、2004年2月、進行中の作業。
[10] Blunk, L., Damas, J., Parent, F. and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", Work in Progress, April 2004.
[10] Blunk、L.、Damas、J.、Parent、F。and A. Robachevsky、「ルーティングポリシー仕様言語次世代（RPSLNG）」、2004年4月、進行中の作業。
[11] Raftus, D. and E. Cardona, Editor, "Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces", Work in Progress, April 2004.
[11] Raftus、D。およびE. Cardona、編集者、「DOCSIS 2.0準拠のRFインターフェイスの無線周波数（RF）インターフェイス管理情報ベース」、2004年4月、進行中の作業。
[12] Chesterfield, J., Editor, "Multicast Group Membership Discovery MIB", Work in Progress, February 2004.
[12] Chesterfield、J.、編集者、「マルチキャストグループメンバーシップディスカバリーMIB」、2004年2月、進行中の作業。
Please contact the authors with any questions, comments or suggestions at:
質問、コメント、または提案については、著者に連絡してください。
Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034
フィリップJ.ネッサーIIプリンシパルネッサー＆ネッサーコンサルティング13501 100th Ave NE、＃5202 Kirkland、WA 98034
Phone: +1 425 481 4303
Fax: +1 425 48
EMail: phil@nesser.com
Andreas Bergstrom (Editor) Ostfold University College Rute 503 Buer N-1766 Halden Norway
Andreas Bergstrom（編集者）Ostfold University College Rute 503 Buer N-1766 Halden Norway
EMail: andreas.bergstrom@hiof.no
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。