RFC4113 日本語訳
4113 Management Information Base for the User Datagram Protocol (UDP).B. Fenner, J. Flick. June 2005. (Format: TXT=40323 bytes) (Obsoletes RFC2454, RFC2013) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Fenner
Request for Comments: 4113 AT&T Labs - Research
Obsoletes: 2454, 2013 J. Flick
Category: Standards Track Hewlett-Packard Company
June 2005
コメントを求めるワーキンググループB.フェナーの要求をネットワークでつないでください: 4113のAT&T研究室--研究は以下を時代遅れにします。 2454、2013J.軽打カテゴリ: 標準化過程ヒューレット・パッカード会社2005年6月
Management Information Base for the User Datagram Protocol (UDP)
ユーザー・データグラム・プロトコルのための管理情報ベース(UDP)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはIPのバージョンの独立している方法でユーザー・データグラム・プロトコル(UDP)の実装に使用される管理オブジェクトについて説明します。 このメモはRFCs2013と2454を時代遅れにします。
Table of Contents
目次
1. The Internet-Standard Management Framework . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Relationship to Other MIBs . . . . . . . . . . . . . . . 3
2.1.1. Relationship to RFC1213-MIB . . . . . . . . . . 3
2.1.2. Relationship to the IPV6-UDP-MIB . . . . . . . . 3
2.1.3. Relationship to HOST-RESOURCES-MIB and
SYSAPPL-MIB. . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
1. インターネット標準の管理フレームワーク. . . . . . . . . . 2 2。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1。 他のMIBs. . . . . . . . . . . . . . . 3 2.1.1との関係。 RFC1213-MIB. . . . . . . . . . 3 2.1.2との関係。 IPV6-UDP-MIB. . . . . . . . 3 2.1.3との関係。 ホストリソースMIBとSYSAPPL-MIBとの関係。 . . . . . . . . . . . . . . . . . . 4 3. 定義. . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 5。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 15 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 17 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1。 引用規格. . . . . . . . . . . . . . . . . . 17 8.2。 有益な参照. . . . . . . . . . . . . . . . . 18
Fenner & Flick Standards [Page 1] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[1ページ]RFC4113UDP MIB2005年6月
1. The Internet-Standard Management Framework
1. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
2. Overview
2. 概要
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP), as defined in RFC 768 [RFC0768], in an IP version independent manner.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、ユーザー・データグラム・プロトコル(UDP)の実装に使用される管理オブジェクトについて説明します、RFC768[RFC0768]で定義されるように、IPのバージョンの独立している方法で。
The current UDP-MIB defined in this memo consists of one table and a group of scalars:
このメモで定義された現在のUDP-MIBは1個のテーブルとスカラのグループから成ります:
o The udp group of scalars reports parameters and statistics of a
UDP protocol engine. Two scalars, udpHCInDatagrams and
udpHCOutDatagrams, have been added to this group since the
publication of RFC 2013 [RFC2013] in order to provide high-
capacity counters for fast networks. Discontinuities in the
values of the counters in this group are indicated by
discontinuities in the value of the sysUpTime object, which is
defined in RFC 3418 [RFC3418].
o スカラのudpグループはUDPプロトコルエンジンのパラメタと統計を報告します。 RFC2013[RFC2013]の公表以来2つのスカラ(udpHCInDatagramsとudpHCOutDatagrams)が、高い容量カウンタを速いネットワークに提供するためにこのグループに追加されています。 このグループにおける、カウンタの値における不連続はRFC3418[RFC3418]で定義されるsysUpTimeオブジェクトの値における不連続によって示されます。
o The udpEndpointTable provides access to status information for all
UDP endpoints handled by a UDP protocol engine. The table
provides for strictly listening endpoints, as with the historical
udpTable, and also for "connected" UDP endpoints, which only
accept packets from a given remote system. It also reports
identification of the operating system level processes that handle
UDP connections. Addresses and ports of UDP endpoints in this
table are represented using the InetAddressType, InetAddress, and
InetPortNumber textual conventions defined in RFC 4001 [RFC4001].
o udpEndpointTableはUDPプロトコルエンジンによって扱われたすべてのUDP終点のための状態情報へのアクセスを提供します。 テーブルは厳密に聴いている終点に備えます、歴史的なudpTable、および「接続された」UDP終点によっても。(終点は与えられたリモートシステムからパケットを受け入れるだけです)。 また、それはUDP接続を扱うオペレーティングシステムレベルプロセスの識別を報告します。 このテーブルのUDP終点のアドレスとポートは、原文のコンベンションがRFC4001[RFC4001]で定義したInetAddressType、InetAddress、およびInetPortNumberを使用することで表されます。
Fenner & Flick Standards [Page 2] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[2ページ]RFC4113UDP MIB2005年6月
2.1. Relationship to Other MIBs
2.1. 他のMIBsとの関係
This section discusses the relationship of this UDP-MIB module to other MIB modules.
このセクションはこのUDP-MIBモジュールの関係について他のMIBモジュールに論じます。
2.1.1. Relationship to RFC1213-MIB
2.1.1. RFC1213-MIBとの関係
UDP related MIB objects were originally defined as part of the RFC1213-MIB, defined in RFC 1213 [RFC1213]. The UDP related objects of the RFC1213-MIB were later copied into a separate MIB module and published in RFC 2013 [RFC2013] in SMIv2 format.
UDPの関連するMIBオブジェクトは元々、RFC1213[RFC1213]で定義されたRFC1213-MIBの一部と定義されました。 RFC1213-MIBのUDPの関連するオブジェクトは、後で別々のMIBモジュールにコピーされて、RFC2013[RFC2013]でSMIv2形式で発行されました。
The previous versions of the UDP-MIB both defined the udpTable, which has been deprecated for basically two reasons:
UDP-MIBの旧バージョンはともに、udpTableを定義しました:(udpTableは基本的に2つの理由で推奨しないです)。
(1) The udpTable only supports IPv4.
(1) udpTableはIPv4をサポートするだけです。
The current approach in the IETF is to write IP version neutral
MIBs rather than have different definitions for various version
of IP. This reduces the amount of overhead when new objects are
introduced, since there is only one place to add them. Hence,
the approach taken in RFC 2454 [RFC2454] of having separate
tables is not continued.
IETFでの現在のアプローチはIPの様々なバージョンのための異なった定義を持っているよりむしろIPバージョン中立MIBsに書くことです。 新しいオブジェクトを導入するとき、それらを加える1つの場所しかないので、これはオーバーヘッドの量を減少させます。 したがって、別々のテーブルを持つRFC2454[RFC2454]で取られたアプローチは続けられていません。
(2) The udpTable does not permit describing "connected" UDP
endpoints.
(2) udpTableは、「接続された」UDP終点について説明するのを可能にしません。
It turns out that "connected" endpoints tend to have a different
behaviour and management access pattern from those of listening
endpoints. Adding remote endpoint information to the
udpEndpointTable thus allows for the addition of specific status
and statistic objects for "connected" endpoints and connections.
「接続された」終点が、聴取終点のものと異なったふるまいと管理アクセスパターンを持っている傾向があると判明します。 その結果、リモート終点情報をudpEndpointTableに加えると、特定の状態と統計値オブジェクトの追加は「接続された」終点と接続に関して考慮されます。
2.1.2. Relationship to the IPV6-UDP-MIB
2.1.2. IPV6-UDP-MIBとの関係
The IPV6-UDP-MIB, defined in RFC 2454 [RFC2454], has been moved to Historic because the approach of having separate IP version specific tables is not followed anymore. Implementation of RFC 2454 is thus not suggested anymore.
別々のIPバージョン特定のテーブルを持つアプローチがそれ以上続かれていないので、RFC2454[RFC2454]で定義されたIPV6-UDP-MIBはHistoricに動かされました。 RFC2454の実装はそれ以上このようにして示されません。
Note that because scoped addresses are now represented using the IPv4z and IPv6z address types, there is no longer a need to explicitly include the ifIndex in the index clause of the udpEndpointTable. This is a change from the use of ipv6UdpIfIndex in RFC 2454.
見られたアドレスが現在IPv4zとIPv6zアドレスタイプを使用することで表されるのでudpEndpointTableの指数約款に明らかにifIndexを含む必要がもうないことに注意してください。 これはRFC2454におけるipv6UdpIfIndexの使用からの変化です。
Fenner & Flick Standards [Page 3] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[3ページ]RFC4113UDP MIB2005年6月
2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB
2.1.3. ホストリソースMIBとSYSAPPL-MIBとの関係
The udpEndpointTable reports the identification of the operating system level process that handles a connection or a listening endpoint. The value is reported as an Unsigned32, which is expected to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the value is smaller than 2147483647) or the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. This allows management applications to identify the UDP connections that belong to an operating system level process, which has proven valuable in operational environments.
udpEndpointTableは接続か聴取終点を扱うオペレーティングシステムレベルプロセスの識別を報告します。 値はUnsigned32として報告されます。(Unsigned32はHOST-RESOURCES-MIB[RFC2790]のhrSWRunIndex(値が2147483647より小さいなら)かSYSAPPL-MIBのsysApplElmtRunIndex[RFC2287]と同じであると予想されます)。 これで、管理アプリケーションは運用環境で貴重であると判明したオペレーティングシステムレベルプロセスに属すUDP接続を特定できます。
3. Definitions
3. 定義
UDP-MIB DEFINITIONS ::= BEGIN
UDP-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64,
Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
InetAddress, InetAddressType,
InetPortNumber FROM INET-ADDRESS-MIB;
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Integer32、Counter32、Counter64、Unsigned32、IpAddress、mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF InetAddress、InetAddressType、InetPortNumber FROM INET-ADDRESS-MIB。
udpMIB MODULE-IDENTITY
LAST-UPDATED "200505200000Z" -- May 20, 2005
ORGANIZATION
"IETF IPv6 Working Group
http://www.ietf.org/html.charters/ipv6-charter.html"
CONTACT-INFO
"Bill Fenner (editor)
udpMIBモジュールアイデンティティは"200505200000Z"をアップデートしました--2005年5月20日組織「IETF IPv6作業部会 http://www.ietf.org/html.charters/ipv6-charter.html 」コンタクトインフォメーション「ビル・フェナー」(エディタ)
AT&T Labs -- Research
75 Willow Rd.
Menlo Park, CA 94025
AT&T研究室--研究75Willow通り メンローパーク、カリフォルニア 94025
Phone: +1 650 330-7893
Email: <fenner@research.att.com>
以下に電話をしてください。 +1 650 330-7893 メールしてください: <fenner@research.att.com>。
John Flick (editor)
ジョンFlick(エディタ)
Hewlett-Packard Company
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747
ヒューレット・パッカード会社8000山麓の丘Blvd. S5557ローズビル、M/カリフォルニア 95747
Phone: +1 916 785 4018
Email: <john.flick@hp.com>
以下に電話をしてください。 +1 4018年の916 785メール: <john.flick@hp.com>。
Send comments to <ipv6@ietf.org>"
「 to <ipv6@ietf.org をコメントに送ってください、gt;、」
Fenner & Flick Standards [Page 4] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[4ページ]RFC4113UDP MIB2005年6月
DESCRIPTION
"The MIB module for managing UDP implementations.
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4113;
see the RFC itself for full legal notices."
REVISION "200505200000Z" -- May 20, 2005
DESCRIPTION
"IP version neutral revision, incorporating the
following revisions:
記述、「UDP実装を管理するためのMIBモジュール。」 Copyright(C)インターネット協会(2005)。 このMIBモジュールのこのバージョンはRFC4113の一部です。 「完全な法定の通知に関してRFC自身を見てください。」 REVISION"200505200000Z"--、2005年5月20日記述、「IPのバージョンの中立改正、以下の改正を取り入れます:」
- Added udpHCInDatagrams and udpHCOutDatagrams in order
to provide high-capacity counters for fast networks.
- Added text to the descriptions of all counter objects
to indicate how discontinuities are detected.
- Deprecated the IPv4-specific udpTable and replaced it
with the version neutral udpEndpointTable. This
table includes support for connected UDP endpoints
and support for identification of the operating
system process associated with a UDP endpoint.
- Deprecated the udpGroup and replaced it with object
groups representing the current set of objects.
- Deprecated udpMIBCompliance and replaced it with
udpMIBCompliance2, which includes the compliance
information for the new object groups.
- 高容量カウンタを速いネットワークに提供するためにudpHCInDatagramsとudpHCOutDatagramsを加えました。 - 不連続がどう検出されるかを示すためにすべてのカウンタオブジェクトの記述にテキストを加えました。 - 推奨しなさ、IPv4特有のudpTableであって取り替えられる、それ、バージョンの中立udpEndpointTableと共に。 このテーブルは接続UDP終点のサポートとUDP終点に関連しているオペレーティングシステムプロセスの識別のサポートを含んでいます。 - そして、推奨しなさ、udpGroup、それを現在のセットのオブジェクトを表すオブジェクトグループに取り替えました。 - そして、推奨しないudpMIBCompliance、それをudpMIBCompliance2に取り替えました。(udpMIBCompliance2は新しいオブジェクトグループのための承諾情報を含んでいます)。
This version published as RFC 4113."
REVISION "199411010000Z" -- November 1, 1994
DESCRIPTION
"Initial SMIv2 version, published as RFC 2013."
REVISION "199103310000Z" -- March 31, 1991
DESCRIPTION
"The initial revision of this MIB module was part of
MIB-II, published as RFC 1213."
::= { mib-2 50 }
「RFC4113として発行されたこのバージョン。」 REVISION"199411010000Z"--「初期のSMIv2バージョンであって、RFC2013として発行された」1994年11月1日記述。 REVISION"199103310000Z"--、1991年3月31日記述、「このMIBモジュールの初期の改正はRFC1213として発行されたMIB-IIの一部でした」。 ::= mib-2 50
-- the UDP group
-- UDPグループ
udp OBJECT IDENTIFIER ::= { mib-2 7 }
udp OBJECT IDENTIFIER:、:= mib-2 7
udpInDatagrams OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP datagrams delivered to UDP
users.
「UDPデータグラムの総数はUDPユーザに提供した」udpInDatagrams OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Fenner & Flick Standards [Page 5] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[5ページ]RFC4113UDP MIB2005年6月
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 1 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp1
udpNoPorts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of received UDP datagrams for which
there was no application at the destination port.
udpNoPorts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「利用が全く仕向港になかった容認されたUDPデータグラムの総数。」
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 2 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp2
udpInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP datagrams that could not be
delivered for reasons other than the lack of an
application at the destination port.
udpInErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「アプリケーションの不足以外の理由で仕向港で提供できなかった容認されたUDPデータグラムの数。」
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 3 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp3
udpOutDatagrams OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP datagrams sent from this
entity.
「UDPデータグラムの総数はこの実体から送った」udpOutDatagrams OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 4 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp4
Fenner & Flick Standards [Page 6] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[6ページ]RFC4113UDP MIB2005年6月
udpHCInDatagrams OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP datagrams delivered to UDP
users, for devices that can receive more than 1
million UDP datagrams per second.
「UDPデータグラムの総数は1秒あたり100万個以上のUDPデータグラムを受けることができるデバイスのためにUDPユーザに提供した」udpHCInDatagrams OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 8 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp8
udpHCOutDatagrams OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP datagrams sent from this
entity, for devices that can transmit more than 1
million UDP datagrams per second.
「UDPデータグラムの総数は1秒あたり100万個以上のUDPデータグラムを送ることができるデバイスのためにこの実体から送った」udpHCOutDatagrams OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udp 9 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてsysUpTimeの値における不連続によって示される他の時に起こることができます。」 ::= udp9
--
-- { udp 6 } was defined as the ipv6UdpTable in RFC2454's
-- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is
-- obsoleted.
--
-- -- udp6はRFC2454のものでipv6UdpTableと定義されました--IPV6-UDP-MIB。 したがって、udp6はそうです--このRFCはRFC2454を時代遅れにして、時代遅れにされます。 --
-- The UDP "Endpoint" table.
-- UDP「終点」テーブル。
udpEndpointTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpEndpointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about this entity's UDP
endpoints on which a local application is currently
accepting or sending datagrams.
「局所塗布が現在、受け入れるか、またはデータグラムを送るこの実体のUDP終点の情報を含んでいて、Aはテーブルの上に置く」udpEndpointTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEndpointEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Fenner & Flick Standards [Page 7] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[7ページ]RFC4113UDP MIB2005年6月
The address type in this table represents the address
type used for the communication, irrespective of the
higher-layer abstraction. For example, an application
using IPv6 'sockets' to communicate via IPv4 between
::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use
InetAddressType ipv4(1).
このテーブルのアドレスタイプは、より高い層の抽象化の如何にかかわらずコミュニケーションに使用されるアドレスタイプの代理をします。 例えば、IPv4を通って以下の間に交信するのにIPv6'ソケット'を使用するアプリケーション:そして、ffff: 10.0 .0、.1、:、:ffff: 10.0 .0 .2はInetAddressType ipv4(1)を使用するでしょう。
Unlike the udpTable in RFC 2013, this table also allows
the representation of an application that completely
specifies both local and remote addresses and ports. A
listening application is represented in three possible
ways:
また、RFC2013のudpTableと異なって、このテーブルは地方の、そして、リモートなアドレスとポートの両方を完全に指定するアプリケーションの表現を許容します。 聴取アプリケーションは3つの可能な方法で表されます:
1) An application that is willing to accept both IPv4
and IPv6 datagrams is represented by a
udpEndpointLocalAddressType of unknown(0) and a
udpEndpointLocalAddress of ''h (a zero-length
octet-string).
1) IPv4とIPv6データグラムの両方を受け入れても構わないと思っているアプリケーションは未知(0)のudpEndpointLocalAddressTypeと「h(ゼロ・レングス八重奏ストリング)」のudpEndpointLocalAddressによって表されます。
2) An application that is willing to accept only IPv4
or only IPv6 datagrams is represented by a
udpEndpointLocalAddressType of the appropriate
address type and a udpEndpointLocalAddress of
'0.0.0.0' or '::' respectively.
2) 'IPv4だけかIPv6データグラムだけを受け入れるのが適切のa udpEndpointLocalAddressTypeによって表されることを望んでいるアプリケーションが、'0.0のタイプとudpEndpointLocalAddressが.0であると扱う、.0、'、'、:、:'それぞれ'。
3) An application that is listening for datagrams only
for a specific IP address but from any remote
system is represented by a
udpEndpointLocalAddressType of the appropriate
address type, with udpEndpointLocalAddress
specifying the local address.
3) 特定のIPのためだけにアドレスにもかかわらず、どんなリモートシステムからもデータグラムの聞こうとしているアプリケーションは適切なアドレスタイプのudpEndpointLocalAddressTypeによって表されます、udpEndpointLocalAddressがローカルアドレスを指定していて。
In all cases where the remote is a wildcard, the
udpEndpointRemoteAddressType is unknown(0), the
udpEndpointRemoteAddress is ''h (a zero-length
octet-string), and the udpEndpointRemotePort is 0.
h(ゼロ・レングス八重奏ストリング)、およびudpEndpointRemotePortはそうです。リモートことがワイルドカードである、udpEndpointRemoteAddressTypeが未知(0)であるすべての場合では、udpEndpointRemoteAddressがそうである、「0インチ。
If the operating system is demultiplexing UDP packets
by remote address and port, or if the application has
'connected' the socket specifying a default remote
address and port, the udpEndpointRemote* values should
be used to reflect this."
::= { udp 7 }
「オペレーティングシステムがリモートアドレスとポートのそばの逆多重化UDPパケットである、またはアプリケーションがリモートアドレスとポート、udpEndpointRemote*がこれを反映するのに使用されるべきであるのを評価するデフォルトを指定するソケットを'接続した'なら。」 ::= udp7
udpEndpointEntry OBJECT-TYPE
SYNTAX UdpEndpointEntry
MAX-ACCESS not-accessible
STATUS current
udpEndpointEntry OBJECT-TYPE SYNTAX UdpEndpointEntryのマックス-ACCESSのアクセスしやすくないSTATUS海流
Fenner & Flick Standards [Page 8] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[8ページ]RFC4113UDP MIB2005年6月
DESCRIPTION
"Information about a particular current UDP endpoint.
記述、「特定の現在のUDP終点に関する情報。」
Implementers need to be aware that if the total number
of elements (octets or sub-identifiers) in
udpEndpointLocalAddress and udpEndpointRemoteAddress
exceeds 111, then OIDs of column instances in this table
will have more than 128 sub-identifiers and cannot be
accessed using SNMPv1, SNMPv2c, or SNMPv3."
INDEX { udpEndpointLocalAddressType,
udpEndpointLocalAddress,
udpEndpointLocalPort,
udpEndpointRemoteAddressType,
udpEndpointRemoteAddress,
udpEndpointRemotePort,
udpEndpointInstance }
::= { udpEndpointTable 1 }
「Implementersは、udpEndpointLocalAddressとudpEndpointRemoteAddressの要素(八重奏かサブ識別子)の総数が111を超えているなら、このテーブルのコラムインスタンスのOIDsを128以上のサブ識別子を持って、SNMPv1、SNMPv2c、またはSNMPv3を使用することでアクセスできないのを意識している必要があります。」 udpEndpointLocalAddressType、udpEndpointLocalAddress、udpEndpointLocalPort、udpEndpointRemoteAddressType、udpEndpointRemoteAddress、udpEndpointRemotePort、udpEndpointInstanceに索引をつけてください:、:= udpEndpointTable1
UdpEndpointEntry ::= SEQUENCE {
udpEndpointLocalAddressType InetAddressType,
udpEndpointLocalAddress InetAddress,
udpEndpointLocalPort InetPortNumber,
udpEndpointRemoteAddressType InetAddressType,
udpEndpointRemoteAddress InetAddress,
udpEndpointRemotePort InetPortNumber,
udpEndpointInstance Unsigned32,
udpEndpointProcess Unsigned32
}
UdpEndpointEntry:、:= 系列udpEndpointLocalAddressType InetAddressType、udpEndpointLocalAddress InetAddress、udpEndpointLocalPort InetPortNumber、udpEndpointRemoteAddressType InetAddressType、udpEndpointRemoteAddress InetAddress、udpEndpointRemotePort InetPortNumber、udpEndpointInstance Unsigned32、udpEndpointProcess Unsigned32
udpEndpointLocalAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpEndpointLocalAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all local IP addresses are
accepted."
::= { udpEndpointEntry 1 }
udpEndpointLocalAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「udpEndpointLocalAddressのアドレスタイプ。」 「すべてのローカルアイピーアドレスのためのデータグラムを受け入れるなら、IPv4、IPv4z、IPv6、および唯一のIPv6zアドレスは予想されたか、または未知の(0)です。」 ::= udpEndpointEntry1
udpEndpointLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local IP address for this UDP endpoint.
「ローカルアイピーはこのUDP終点に扱う」udpEndpointLocalAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The value of this object can be represented in three
3でこのオブジェクトの値を表すことができます。
Fenner & Flick Standards [Page 9] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[9ページ]RFC4113UDP MIB2005年6月
possible ways, depending on the characteristics of the
listening application:
可能な道聴取アプリケーションの特性によって、
1. For an application that is willing to accept both
IPv4 and IPv6 datagrams, the value of this object
must be ''h (a zero-length octet-string), with
the value of the corresponding instance of the
udpEndpointLocalAddressType object being unknown(0).
1. IPv4とIPv6データグラムの両方を受け入れても構わないと思っているアプリケーションのために、このオブジェクトの値は「未知(0)であるudpEndpointLocalAddressTypeオブジェクトの対応するインスタンスの値のh(ゼロ・レングス八重奏ストリング)」でなければなりません。
2. For an application that is willing to accept only IPv4
or only IPv6 datagrams, the value of this object
must be '0.0.0.0' or '::', respectively, while the
corresponding instance of the
udpEndpointLocalAddressType object represents the
appropriate address type.
2. 'アプリケーションにおいて、それが、'0.0が.0であったに違いないならこのオブジェクトのIPv4だけかIPv6データグラム、値だけを受け入れても構わないと思っている、.0、'、'、:、:'udpEndpointLocalAddressTypeオブジェクトの対応するインスタンスが適切なアドレスを表している間、それぞれ、タイプしてください'。
3. For an application that is listening for data
destined only to a specific IP address, the value
of this object is the specific IP address for which
this node is receiving packets, with the
corresponding instance of the
udpEndpointLocalAddressType object representing the
appropriate address type.
3. アプリケーションのために、それは特定のIPアドレスだけに運命づけられたデータの聞こうとしていて、このオブジェクトの値はこのノードがパケットを受けている特定のIPアドレスです、udpEndpointLocalAddressTypeオブジェクトの対応するインスタンスが適切なアドレスタイプの代理をしていて。
As this object is used in the index for the
udpEndpointTable, implementors of this table should be
careful not to create entries that would result in OIDs
with more than 128 subidentifiers; else the information
cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
::= { udpEndpointEntry 2 }
このオブジェクトがudpEndpointTableにインデックスで使用されるので、このテーブルの作成者は128以上「副-識別子」でOIDsをもたらすエントリーを作成しないように慎重であるはずです。 「ほかに、SNMPv1、SNMPv2c、またはSNMPv3を使用することで情報にアクセスできません。」 ::= udpEndpointEntry2
udpEndpointLocalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local port number for this UDP endpoint."
::= { udpEndpointEntry 3 }
udpEndpointLocalPort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このUDP終点への地方のポートナンバー。」 ::= udpEndpointEntry3
udpEndpointRemoteAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpEndpointRemoteAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all remote IP addresses are
accepted. Also, note that some combinations of
udpEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「udpEndpointRemoteAddressのアドレスタイプ。」 すべてのリモートIPアドレスのためのデータグラムを受け入れるなら、IPv4、IPv4z、IPv6、および唯一のIPv6zアドレスは予想されたか、または未知の(0)です。 また、それにいくつか注意してください、組み合わせ
Fenner & Flick Standards [Page 10] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[10ページ]RFC4113UDP MIB2005年6月
udpEndpointLocalAdressType and
udpEndpointRemoteAddressType are not supported. In
particular, if the value of this object is not
unknown(0), it is expected to always refer to the
same IP version as udpEndpointLocalAddressType."
::= { udpEndpointEntry 4 }
udpEndpointLocalAdressTypeとudpEndpointRemoteAddressTypeはサポートされません。 「特に、このオブジェクトの値が未知(0)でないなら、いつもudpEndpointLocalAddressTypeと同じIPバージョンを示すと予想されます。」 ::= udpEndpointEntry4
udpEndpointRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote IP address for this UDP endpoint. If
datagrams from any remote system are to be accepted,
this value is ''h (a zero-length octet-string).
Otherwise, it has the type described by
udpEndpointRemoteAddressType and is the address of the
remote system from which datagrams are to be accepted
(or to which all datagrams will be sent).
「リモートIPはこのUDP終点に扱う」udpEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 どんなリモートシステムからのデータグラムも受け入れるつもりであるなら、この値は「h(ゼロ・レングス八重奏ストリング)」です。 さもなければ、それは、udpEndpointRemoteAddressTypeによって説明されたタイプがあって、データグラムが受け入れられることになっているリモートシステムの演説(または、すべてのデータグラムが送られる)です。
As this object is used in the index for the
udpEndpointTable, implementors of this table should be
careful not to create entries that would result in OIDs
with more than 128 subidentifiers; else the information
cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3."
::= { udpEndpointEntry 5 }
このオブジェクトがudpEndpointTableにインデックスで使用されるので、このテーブルの作成者は128以上「副-識別子」でOIDsをもたらすエントリーを作成しないように慎重であるはずです。 「ほかに、SNMPv1、SNMPv2c、またはSNMPv3を使用することで情報にアクセスできません。」 ::= udpEndpointEntry5
udpEndpointRemotePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote port number for this UDP endpoint. If
datagrams from any remote system are to be accepted,
this value is zero."
::= { udpEndpointEntry 6 }
udpEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumberのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このUDP終点へのリモートポートナンバー。」 「どんなリモートシステムからのデータグラムも受け入れるつもりであるなら、この値はゼロです。」 ::= udpEndpointEntry6
udpEndpointInstance OBJECT-TYPE
SYNTAX Unsigned32 (1..'ffffffff'h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The instance of this tuple. This object is used to
distinguish among multiple processes 'connected' to
the same UDP endpoint. For example, on a system
implementing the BSD sockets interface, this would be
used to support the SO_REUSEADDR and SO_REUSEPORT
socket options."
udpEndpointInstance OBJECT-TYPE SYNTAX Unsigned32、(1 'ffffffff'h) 「このインスタンスはtupleする」マックス-ACCESSのアクセスしやすくないSTATUS現在の記述'。 このオブジェクトは、同じUDP終点に'接続された'複数のプロセスの中で区別するのに使用されます。 「例えば、BSDソケットインタフェースを実装するシステムの上では、これはSO_REUSEADDRとSO_REUSEPORTがソケットオプションであるとサポートするのに使用されるでしょう。」
Fenner & Flick Standards [Page 11] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[11ページ]RFC4113UDP MIB2005年6月
::= { udpEndpointEntry 7 }
::= udpEndpointEntry7
udpEndpointProcess OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The system's process ID for the process associated with
this endpoint, or zero if there is no such process.
This value is expected to be the same as
HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB::
sysApplElmtRunIndex for some row in the appropriate
tables."
::= { udpEndpointEntry 8 }
「どれかそのようなプロセスがなければ、プロセスのためのシステムのプロセスIDはこの終点、またはゼロ終点に関連づけた」udpEndpointProcess OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 この値がHOST-RESOURCES-MIBと同じであると予想されます:、:hrSWRunIndexかSYSAPPL-MIB:、: 「いくつかのためのsysApplElmtRunIndexは適切なテーブルで船をこぎます。」 ::= udpEndpointEntry8
-- The deprecated UDP Listener table
-- 推奨しないUDP Listenerテーブル
-- The deprecated UDP listener table only contains information -- about this entity's IPv4 UDP end-points on which a local -- application is currently accepting datagrams. It does not -- provide more detailed connection information, or information -- about IPv6 endpoints.
-- 推奨しないUDPリスナーテーブルはどのaローカルの上でこの実体のIPv4 UDPエンドポイントの情報を含むだけであるか--アプリケーションは現在、データグラムを受け入れています。そうしません--より詳細な接続情報、またはIPv6終点の情報を提供してください。
udpTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"A table containing IPv4-specific UDP listener
information. It contains information about all local
IPv4 UDP end-points on which an application is
currently accepting datagrams. This table has been
deprecated in favor of the version neutral
udpEndpointTable."
::= { udp 5 }
アクセスしやすくない推奨しないudpTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEntryのマックス-ACCESS STATUS記述「Aテーブルの含んでいるIPv4特有のUDPリスナー情報。」 それはアプリケーションが現在データグラムを受け入れているすべての地方のIPv4 UDPエンドポイントの情報を含んでいます。「このテーブルはバージョンの中立udpEndpointTableを支持して推奨しないです。」 ::= udp5
udpEntry OBJECT-TYPE
SYNTAX UdpEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"Information about a particular current UDP listener."
INDEX { udpLocalAddress, udpLocalPort }
::= { udpTable 1 }
udpEntry OBJECT-TYPE SYNTAX UdpEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述、「特定の現在のUDPリスナーに関する情報。」 udpLocalAddress、udpLocalPortに索引をつけてください:、:= udpTable1
UdpEntry ::= SEQUENCE {
udpLocalAddress IpAddress,
udpLocalPort Integer32
UdpEntry:、:= 系列、udpLocalAddress IpAddress、udpLocalPort Integer32
Fenner & Flick Standards [Page 12] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[12ページ]RFC4113UDP MIB2005年6月
}
}
udpLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The local IP address for this UDP listener. In the
case of a UDP listener that is willing to accept
datagrams for any IP interface associated with the
node, the value 0.0.0.0 is used."
::= { udpEntry 1 }
「ローカルアイピーはこのUDPリスナーのために扱う」udpLocalAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述。 「UDPリスナーの場合では、それは、ノードに関連しているどんなIPインタフェースにもデータグラムを受け入れても構わないと思っています、値、0.0、.0、.0、使用されている、」 ::= udpEntry1
udpLocalPort OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The local port number for this UDP listener."
::= { udpEntry 2 }
udpLocalPort OBJECT-TYPE SYNTAX Integer32(0 .65535)のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「このUDPリスナーのための地方のポートナンバー。」 ::= udpEntry2
-- conformance information
-- 順応情報
udpMIBConformance OBJECT IDENTIFIER ::= { udpMIB 2 }
udpMIBCompliances OBJECT IDENTIFIER ::= { udpMIBConformance 1 }
udpMIBGroups OBJECT IDENTIFIER ::= { udpMIBConformance 2 }
udpMIBConformanceオブジェクト識別子:、:= udpMIB2udpMIBCompliancesオブジェクト識別子:、:= udpMIBConformance1udpMIBGroupsオブジェクト識別子:、:= udpMIBConformance2
-- compliance statements
-- 承諾声明
udpMIBCompliance2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems that implement
UDP.
udpMIBCompliance2 MODULE-COMPLIANCE STATUSの現在の記述、「UDPを実装するシステムのための承諾声明。」
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2, but
for which we have the following compliance
requirements, expressed in OBJECT clause form in this
description clause:
SMIv2の私たちがこの記述節のOBJECT節フォームで言い表された以下の承諾要件を持っている、OBJECT節の形に表すことができない多くのINDEXオブジェクトがあります:
-- OBJECT udpEndpointLocalAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(5) is not required.
-- OBJECT udpEndpointLocalAddress
-- OBJECT udpEndpointLocalAddressType--未知(0)、ipv4(1)--ipv6(2)、ipv4z(3)--ipv6z(4)(記述)がdns(5)のためにサポートするSYNTAX InetAddressTypeは必要ではありません。 -- オブジェクトudpEndpointLocalAddress
Fenner & Flick Standards [Page 13] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[13ページ]RFC4113UDP MIB2005年6月
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
-- OBJECT udpEndpointRemoteAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(5) is not required.
-- OBJECT udpEndpointRemoteAddress
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
"
MODULE -- this module
MANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup }
GROUP udpHCGroup
DESCRIPTION
"This group is mandatory for systems that
are capable of receiving or transmitting more than
1 million UDP datagrams per second. 1 million
datagrams per second will cause a Counter32 to
wrap in just over an hour."
::= { udpMIBCompliances 2 }
-- そして、SYNTAX InetAddress、(SIZE、(8|16|20、0|4|)、--記述--サポートが八重奏ゼロ・レングス--ストリングに必要であるだけである、見られて、「非-見」られる、--IPv4とIPv6アドレス。 -- OBJECT udpEndpointRemoteAddressType--未知(0)、ipv4(1)--ipv6(2)、ipv4z(3)--ipv6z(4)(記述)がdns(5)のためにサポートするSYNTAX InetAddressTypeは必要ではありません。 -- そして、OBJECT udpEndpointRemoteAddress--、SYNTAX InetAddress、(SIZE、(8|16|20、0|4|)、--記述--サポートが八重奏ゼロ・レングス--ストリングに必要であるだけである、見られて、「非-見」られる、--IPv4とIPv6アドレス。 「MODULE--、このモジュールMANDATORY-GROUPS、udpBaseGroup、udpEndpointGroup、GROUP udpHCGroup記述、「このグループは1秒あたり100万個以上のUDPデータグラムを受けるか、または送るできるシステムに義務的です」。 「1秒あたり100万個のデータグラムがちょうど1時間以上後に包装へのCounter32を引き起こすでしょう。」 ::= udpMIBCompliances2
udpMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for IPv4-only systems that
implement UDP. For IP version independence, this
compliance statement is deprecated in favor of
udpMIBCompliance2. However, agents are still
encouraged to implement these objects in order to
interoperate with the deployed base of managers."
MODULE -- this module
MANDATORY-GROUPS { udpGroup }
::= { udpMIBCompliances 1 }
udpMIBCompliance MODULE-COMPLIANCE STATUSの推奨しない記述、「UDPを実装するIPv4だけシステムのための承諾声明。」 IPバージョン独立において、この承諾声明はudpMIBCompliance2を支持して推奨しないです。 「しかしながら、エージェントがマネージャの配布しているベースで共同利用するためにこれらのオブジェクトを実装するようまだ奨励されています。」 MODULE--このモジュールMANDATORY-GROUPS udpGroup:、:= udpMIBCompliances1
-- units of conformance
-- ユニットの順応
udpGroup OBJECT-GROUP
OBJECTS { udpInDatagrams, udpNoPorts,
udpInErrors, udpOutDatagrams,
udpLocalAddress, udpLocalPort }
udpGroupオブジェクト群対象udpInDatagrams、udpNoPorts、udpInErrors、udpOutDatagrams、udpLocalAddress、udpLocalPort
Fenner & Flick Standards [Page 14] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[14ページ]RFC4113UDP MIB2005年6月
STATUS deprecated
DESCRIPTION
"The deprecated group of objects providing for
management of UDP over IPv4."
::= { udpMIBGroups 1 }
STATUSの推奨しない記述、「IPv4の上にUDPの管理に備えるオブジェクトの推奨しないグループ。」 ::= udpMIBGroups1
udpBaseGroup OBJECT-GROUP
OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors,
udpOutDatagrams }
STATUS current
DESCRIPTION
"The group of objects providing for counters of UDP
statistics."
::= { udpMIBGroups 2 }
udpBaseGroup OBJECT-GROUP OBJECTS、udpInDatagrams、udpNoPorts、udpInErrors、udpOutDatagrams、STATUSの現在の記述、「UDP統計のカウンタに備えるオブジェクトのグループ。」 ::= udpMIBGroups2
udpHCGroup OBJECT-GROUP
OBJECTS { udpHCInDatagrams, udpHCOutDatagrams }
STATUS current
DESCRIPTION
"The group of objects providing for counters of high
speed UDP implementations."
::= { udpMIBGroups 3 }
udpHCGroup OBJECT-GROUP OBJECTS、udpHCInDatagrams、udpHCOutDatagrams、STATUSの現在の記述、「高値のカウンタに備えるオブジェクトのグループはUDP実装を促進します」。 ::= udpMIBGroups3
udpEndpointGroup OBJECT-GROUP
OBJECTS { udpEndpointProcess }
STATUS current
DESCRIPTION
"The group of objects providing for the IP version
independent management of UDP 'endpoints'."
::= { udpMIBGroups 4 }
udpEndpointGroup OBJECT-GROUP OBJECTS udpEndpointProcess、STATUSの現在の記述、「UDP'終点'のIPのバージョンの独立している管理に備えるオブジェクトのグループ。」 ::= udpMIBGroups4
END
終わり
4. Acknowledgements
4. 承認
This document contains a modified subset of RFC 1213 and replaces RFCs 2013 and 2454. Acknowledgments are therefore due to the authors and editors of these documents for their excellent work.
このドキュメントは、RFC1213の変更された部分集合を含んでいて、RFCs2013と2454を取り替えます。 承認はしたがって、彼らの素晴らしい仕事のためのこれらのドキュメントの作者とエディタのためです。
5. Contributors
5. 貢献者
This document is an output of the IPv6 MIB revision team, and contributors to earlier versions of this document include:
このドキュメントはIPv6 MIB改正チームの出力です、そして、このドキュメントの以前のバージョンへの貢献者出力です。
Bill Fenner, AT&T Labs -- Research
Email: fenner@research.at.com
ビル・フェナー、AT&T研究室--メールを研究してください: fenner@research.at.com
Fenner & Flick Standards [Page 15] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[15ページ]RFC4113UDP MIB2005年6月
Brian Haberman
Email: brian@innovationslab.net
ブライアンハーバーマンEmail: brian@innovationslab.net
Shawn A. Routhier, Wind River
Email: sar@epilogue.com
ショーンA.Routhier、風の川のメール: sar@epilogue.com
Juergen Schoenwalder, TU Braunschweig
Email: schoenw@ibr.cs.tu-bs.de
ユルゲンSchoenwalder、TUブラウンシュバイクはメールされます: schoenw@ibr.cs.tu-bs.de
Dave Thaler, Microsoft
Email: dthaler@windows.microsoft.com
デーヴThaler、マイクロソフトメール: dthaler@windows.microsoft.com
Much of Keith McCloghrie's text from RFC1213/RFC2013 remains in this document, and the structure of the MIB is due to him.
RFC1213/RFC2013からのキースMcCloghrieのテキストの多くが本書では残っています、そして、MIBの構造は彼のためです。
Mike Daniele wrote the original IPv6 UDP MIB in RFC2454.
マイク・ダニエルはRFC2454にオリジナルのIPv6 UDP MIBに書きました。
Juergen Schoenwalder provided much of the text for section 2.
ユルゲンSchoenwalderはテキストの多くをセクション2に供給しました。
6. Security Considerations
6. セキュリティ問題
There are no management objects defined in this MIB that have a MAX- ACCESS clause of read-write and/or read-create. So, if this MIB is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
オブジェクトが読書して書くことのマックスACCESS節を持っているこのMIBで定義する、そして/または、読書して創設する管理が全くありません。 それで、このMIBが正しく実装されるなら、侵入者が変更できる危険が全くないか、またはダイレクトSNMP SET操作でこのMIBモジュールのあらゆる管理オブジェクトを作成してください。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
The indices of the udpEndpointTable and udpTable contain information on the listeners on an entity. In particular, the udpEndpointLocalPort and udpLocalPort objects in the indices can be used to identify what ports are open on the machine and what attacks are likely to succeed, without the attacker having to run a port scanner.
udpEndpointTableとudpTableのインデックスリストは実体のリスナーの情報を含んでいます。 特に、どんなポートがマシンで開いているか、そして、どんな攻撃が成功しそうであるかを特定するのにインデックスリストのudpEndpointLocalPortとudpLocalPortオブジェクトを使用できます、ポートスキャナを動かさなければならない攻撃者なしで。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
Fenner & Flick Standards [Page 16] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[16ページ]RFC4113UDP MIB2005年6月
It is recommended that the implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
作成者がSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、お勧めです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
その上、SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
7. IANA Considerations
7. IANA問題
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry:
MIBモジュールは本書ではSMI民数記登録に記録された以下のIANAによって割り当てられたOBJECT IDENTIFIER値を使用します:
+------------+-------------------------+
| Descriptor | OBJECT IDENTIFIER value |
+------------+-------------------------+
| udp | { mib-2 7} |
| udpMIB | { mib-2 50 } |
+------------+-------------------------+
+------------+-------------------------+ | 記述子| OBJECT IDENTIFIER値| +------------+-------------------------+ | udp| mib-2 7| | udpMIB| mib-2 50| +------------+-------------------------+
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2579] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3418] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」、STD62、RFC3418、2002年12月。
Fenner & Flick Standards [Page 17] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[17ページ]RFC4113UDP MIB2005年6月
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
8.2. Informative References
8.2. 有益な参照
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II",
STD 17, RFC 1213, March 1991.
[RFC1213]McCloghrieとK.とM.ローズ、「TCP/IPベースのインターネットのネットワークマネージメントのための管理情報ベース: MIB-II」、STD17、RFC1213、1991年3月。
[RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for
the User Datagram Protocol using SMIv2", RFC 2013,
November 1996.
[RFC2013] McCloghrie、K.、「1996年11月にSMIv2"、RFC2013を使用するユーザー・データグラム・プロトコルのためのSNMPv2管理情報ベース。」
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February
1998.
[RFC2287]KrupczakとC.とJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、RFC2287、1998年2月。
[RFC2454] Daniele, M., "IP Version 6 Management Information Base for
the User Datagram Protocol", RFC 2454, December 1998.
[RFC2454]ダニエル、M.、「ユーザー・データグラム・プロトコルのためのIPバージョン6管理情報ベース」、RFC2454、1998年12月。
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
2790, March 2000.
2000年の[RFC2790]WaldbusserとS.とP.グリロ、「ホストリソースMIB」(RFC2790)行進。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
Authors' Addresses
作者のアドレス
Bill Fenner AT&T Labs -- Research 75 Willow Rd Menlo Park, CA 94025 USA
ビルフェナーAT&T研究室--研究75はカリフォルニア94025第メンローパーク(米国)をウイロにかけます。
EMail: fenner@research.att.com
メール: fenner@research.att.com
John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 USA
ジョン軽打ヒューレット・パッカード会社8000山麓の丘Blvd. S5557カリフォルニア95747-5557M/ローズビル(米国)
EMail: john.flick@hp.com
メール: john.flick@hp.com
Fenner & Flick Standards [Page 18] RFC 4113 UDP MIB June 2005
フェナーと軽打規格[18ページ]RFC4113UDP MIB2005年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントは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機能のための基金は現在、インターネット協会によって提供されます。
Fenner & Flick Standards [Page 19]
フェナーと軽打規格[19ページ]
一覧
スポンサーリンク
