RFC4087 日本語訳
4087 IP Tunnel MIB. D. Thaler. June 2005. (Format: TXT=53206 bytes) (Obsoletes RFC2667) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Thaler Request for Comments: 4087 Microsoft Obsoletes: 2667 June 2005 Category: Standards Track
ターレルがコメントのために要求するワーキンググループD.をネットワークでつないでください: 4087 マイクロソフトは以下を時代遅れにします。 2667 2005年6月のカテゴリ: 標準化過程
IP Tunnel MIB
IPトンネルMIB
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 Management Information Base (MIB) module 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 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects. This MIB module does not support tunnels over non-IP networks. Management of such tunnels may be supported by other MIB modules. This memo obsoletes RFC 2667.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のためのManagement Information基地(MIB)のモジュールを定義します。 特に、それはIPv4とIPv6ネットワークの上でどんなタイプのトンネルも管理するのに使用される管理オブジェクトについて説明します。 拡大MIBモジュールは、プロトコル特有のオブジェクトを管理するように設計されるかもしれません。 同様に、拡大MIBモジュールは、セキュリティ特有のオブジェクトを管理するように設計されるかもしれません。 このMIBモジュールは非IPネットワークの上でトンネルを支えません。 そのようなトンネルの管理は他のMIBモジュールでサポートされるかもしれません。 このメモはRFC2667を時代遅れにします。
1. Introduction
1. 序論
Over the past several years, there has been a number of "tunneling" protocols specified by the IETF (see [RFC1241] for an early discussion of the model and examples). This document describes a Management Information Base (MIB) module used for managing tunnels of any type over IPv4 and IPv6 networks, including Generic Routing Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661], Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding (L2F) [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel Management Protocol (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893] tunnels, among others.
過去数年間、IETFによって指定された多くの「トンネリング」プロトコルがあります(モデルと例の早めの議論に関して[RFC1241]を見てください)。 このドキュメントは特にGenericルート設定Encapsulation(GRE)[RFC1701、RFC1702]、IPにおけるIP[RFC2003]、Minimal Encapsulation[RFC2004]、Layer2Tunnelingプロトコル(L2TP)[RFC2661]、PointからポイントへのTunnelingプロトコル(PPTP)[RFC2637]、Layer2Forwarding(L2F)[RFC2341]、UDP(例えば、[RFC1234])、Ascend Tunnel Managementプロトコル(ATMP)[RFC2107]、およびIPv4のIPv6[RFC2893]トンネルを含むIPv4とIPv6ネットワークの上でどんなタイプのトンネルも管理するのに使用されるManagement Information基地(MIB)のモジュールを説明します。
Thaler Standards Track [Page 1] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[1ページ]。
Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extension MIB modules may be designed for managing security-specific objects (e.g., IPsec [RFC2401]), and traffic conditioner [RFC2474] objects.
拡大MIBモジュールは、プロトコル特有のオブジェクトを管理するように設計されるかもしれません。 同様に、拡大MIBモジュールは、セキュリティ特有のオブジェクト(例えば、IPsec[RFC2401])、およびトラフィックコンディショナー[RFC2474]オブジェクトを管理するように設計されるかもしれません。
2. The Internet-Standard Management Framework
2. インターネット標準の管理フレームワーク
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モジュールを指定します。
3. Overview
3. 概要
This MIB module contains two current tables and one deprecated table. The current tables are:
このMIBモジュールは2個の現在のテーブルと1個の推奨しないテーブルを含んでいます。 現在のテーブルは以下の通りです。
o the Tunnel Interface Table, containing information on the tunnels
known to a router; and
o ルータに知られているトンネルの情報を含むTunnel Interface Table。 そして
o the Tunnel Inet Config Table, which can be used for dynamic
creation of tunnels, and also provides a mapping from endpoint
addresses to the current interface index value.
o Tunnel Inet Config Table。(そのTunnel Inet Config Tableはトンネルのダイナミックな作成に使用できて、また、終点アドレスから現在のインタフェースインデックス価値までマッピングを提供します)。
The version of this MIB module that appeared in RFC 2667 contained the Tunnel Config Table, which mapped IPv4 endpoint addresses to interface indexes. It is now deprecated in favor of the Tunnel Inet Config Table.
RFC2667に現れたこのMIBモジュールのバージョンはTunnel Config Tableを含みました。(Tunnel Config Tableは、インデックスを連結するようにIPv4終点アドレスを写像しました)。 それは現在、Tunnel Inet Config Tableを支持して推奨しないです。
3.1. Relationship to the Interfaces MIB
3.1. インタフェースMIBとの関係
This section clarifies the relationship of this MIB module to the Interfaces MIB [RFC2863]. Several areas of correlation are addressed in the following subsections. The implementor is referred to the Interfaces MIB document in order to understand the general intent of these areas.
このセクションはこのMIBモジュールの関係をInterfaces MIB[RFC2863]にはっきりさせます。 相関関係のいくつかの領域が以下の小区分で扱われます。 作成者は、これらの領域の総合的目的を理解するためにInterfaces MIBドキュメントを参照されます。
Thaler Standards Track [Page 2] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[2ページ]。
3.1.1. Layering Model
3.1.1. レイヤリングモデル
Each logical interface (physical or virtual) has an ifEntry in the Interfaces MIB [RFC2863]. Tunnels are handled by creating a logical interface (ifEntry) for each tunnel. These are then correlated, using the ifStack table of the Interfaces MIB, to those interfaces on which the local IPv4 or IPv6 addresses of the tunnels are configured. The basic model, therefore, looks something like this (for example):
それぞれの論理的なインタフェース(物理的であるか仮想の)はInterfaces MIB[RFC2863]にifEntryを持っています。 トンネルは、論理的なインタフェース(ifEntry)を各トンネルに作成することによって、扱われます。 次に、これらは関連します、Interfaces MIBのifStackテーブルを使用して、トンネルの地方のIPv4かIPv6アドレスが構成されるそれらのインタフェースに。 したがって、基本型はこの(例えば)ように見えます:
| | | | | |
+--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | |
| tunnel | | tunnel | | |
+--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to underlying
+--+ +---------+ +----------+ +--+ interfaces, to be provided
| Physical interface | by ifStack table
+--------------------------------+
| | | | | | +--+ +---+ +--+ +---+ | | |IPにおけるIP| | GRE| | | | トンネル| | トンネル| | | +--+ +---+ +--+ +---+ | | | | | | | | <= +の基礎となることへの付属--+ +---------+ +----------+ +--+は、提供するために連結します。| 物理インターフェース| ifStackテーブル+で--------------------------------+
3.1.2. ifRcvAddressTable
3.1.2. ifRcvAddressTable
The ifRcvAddressTable usage can be defined in the MIB modules defining the encapsulation below the network layer, and holds the local IP addresses on which decapsulation will occur. For example, if IP-in-IP encapsulation is being used, the ifRcvAddressTable can be defined by IP-in-IP. If it is not specified, the default is that one entry will exist for the tunnel interface, where ifRcvAddressAddress contains the local IP address used for encapsulation/decapsulation (i.e., tunnelIfLocalInetAddress in the Tunnel Interface Table).
ネットワーク層の下でカプセル化を定義するMIBモジュールでifRcvAddressTable用法を定義できます、そして、ローカルアイピーがどの被膜剥離術で扱う船倉は現れるでしょう。 例えば、IPにおけるIPカプセル化が使用されているなら、IPにおけるIPはifRcvAddressTableを定義できます。 それが指定されないなら、デフォルトは1つのエントリーがトンネルのインタフェースに存在するということです。(そこでは、ifRcvAddressAddressがカプセル化/被膜剥離術(すなわち、Tunnel Interface TableのtunnelIfLocalInetAddress)に使用されるローカルアイピーアドレスを含みます)。
3.1.3. ifEntry
3.1.3. ifEntry
IfEntries are defined in the MIB modules defining the encapsulation below the network layer. For example, if IP-in-IP encapsulation [20] is being used, the ifEntry is defined by IP-in-IP.
IfEntriesはネットワーク層の下でカプセル化を定義するMIBモジュールで定義されます。 例えば、IPにおけるIPカプセル化[20]が使用されているなら、ifEntryはIPにおけるIPによって定義されます。
The ifType of a tunnel should be set to "tunnel" (131). An entry in the IP Tunnel MIB module will exist for every ifEntry with this ifType. An implementation of the IP Tunnel MIB module may allow ifEntries to be created via the tunnelConfigTable. Creating a tunnel will also add an entry in the ifTable and in the tunnelIfTable, and deleting a tunnel will likewise delete the entry in the ifTable and the tunnelIfTable.
トンネルのifTypeは「トンネル」(131)に用意ができるべきです。 IP Tunnel MIBモジュールにおけるエントリーはあらゆるifEntryのためにこのifTypeと共に存在するでしょう。 IP Tunnel MIBモジュールの実装は、ifEntriesがtunnelConfigTableを通して作成されるのを許容するかもしれません。 また、トンネルを作成すると、エントリーはifTableとtunnelIfTableで加えられるでしょう、そして、トンネルを削除すると、エントリーはifTableとtunnelIfTableで同様に削除されるでしょう。
The use of two different tables in this MIB module was an important design decision. Traditionally, ifIndex values are chosen by agents, and are permitted to change across restarts. Allowing row creation directly in the Tunnel Interface Table, indexed by ifIndex, would
このMIBモジュールにおける2個の異なったテーブルの使用は重要なデザイン決定でした。 ifIndex値は、伝統的に、エージェントによって選ばれていて、受入れられて、横切って変化するのが再開するということです。 直接ifIndexによって索引をつけられたTunnel Interface Tableに行作成を許容するのはそうするでしょう。
Thaler Standards Track [Page 3] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[3ページ]。
complicate row creation and/or cause interoperability problems (if each agent had special restrictions on ifIndex). Instead, a separate table is used that is indexed only by objects over which the manager has control. Namely, these are the addresses of the tunnel endpoints and the encapsulation protocol. Finally, an additional manager- chosen ID is used in the index to support protocols such as L2F which allow multiple tunnels between the same endpoints.
行作成、そして/または、原因相互運用性問題を複雑にしてください(各エージェントがifIndexに特別な制限を持っていたなら)。 代わりにマネージャがコントロールを持っているオブジェクトだけによって索引をつけられる使用される別々のテーブル。 すなわち、これらは、トンネル終点のアドレスとカプセル化プロトコルです。 最終的に、追加IDが選ばれたマネージャは、同じ終点の間の複数のトンネルを許容するL2Fなどのプロトコルをサポートするのにインデックスで使用されます。
4. Definitions
4. 定義
TUNNEL-MIB DEFINITIONS ::= BEGIN
トンネル-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, transmission,
Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578]
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、トランスミッション、Integer32、IpAddress FROM SNMPv2-SMI--[RFC2578]
RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579]
SNMPv2-TcからのRowStatus、StorageType--[RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
SNMPv2-CONFからのモジュールコンプライアンス、オブジェクトグループ--[RFC2580]
InetAddressType,
InetAddress FROM INET-ADDRESS-MIB -- [RFC4001]
INETアドレスMIBからのInetAddressType、InetAddress--[RFC4001]
IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595]
IPV6流れラベルMIBからのIPv6FlowLabelOrAny--[RFC3595]
ifIndex,
InterfaceIndexOrZero FROM IF-MIB -- [RFC2863]
ifIndex、InterfaceIndexOrZero、-、MIB、--[RFC2863]
IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE]
IANAifType-MIBからのIANAtunnelType。 -- [IFTYPE]
tunnelMIB MODULE-IDENTITY
LAST-UPDATED "200505160000Z" -- May 16, 2005
ORGANIZATION "IETF IP Version 6 (IPv6) Working Group"
CONTACT-INFO
" Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: dthaler@microsoft.com"
DESCRIPTION
"The MIB module for management of IP Tunnels,
independent of the specific encapsulation scheme in
use.
tunnelMIBモジュールアイデンティティは"200505160000Z"--インフォメーションに連絡している2005年5月16日組織「IETF IPバージョン6(IPv6)作業部会」「レッドモンド、ワシントン98052-6399が以下をメールするデーヴターレルマイクロソフト社1マイクロソフト方法」をアップデートしました。 " dthaler@microsoft.com "記述、「使用中である特定のカプセル化体系の如何にかかわらずIP Tunnelsの管理のためのMIBモジュール。」
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4087; see
the RFC itself for full legal notices."
Copyright(C)インターネット協会(2005)。 このMIBモジュールのこのバージョンはRFC4087の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
Thaler Standards Track [Page 4] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[4ページ]。
REVISION "200505160000Z" -- May 16, 2005
DESCRIPTION
"IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the
tunnelConfigTable, and the tunnelMIBBasicGroup.
REVISION"200505160000Z"--2005年5月16日に、記述は「tunnelIfLocalAddress、tunnelIfRemoteAddress、tunnelConfigTable、およびtunnelMIBBasicGroupを含んでいて、推奨しなIPv4-詳細が反対するします」。
Added IP version-agnostic objects that should be used
instead, including tunnelIfAddressType,
tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress,
the tunnelInetConfigTable, and the
tunnelIMIBInetGroup.
tunnelIfAddressType、tunnelIfLocalInetAddress、tunnelIfRemoteInetAddress、tunnelInetConfigTable、およびtunnelIMIBInetGroupを含んでいて、代わりに使用されるべきであるIPバージョン不可知論者オブジェクトを加えました。
The new tunnelIfLocalInetAddress and
tunnelIfRemoteInetAddress objects are read-write,
rather than read-only.
読書唯一であるというよりむしろ新しいtunnelIfLocalInetAddressとtunnelIfRemoteInetAddressオブジェクトは読書して書いています。
Updated DESCRIPTION clauses of existing version-
agnostic objects (e.g., tunnelIfTOS) that contained
IPv4-specific text to cover IPv6 as well.
また、IPv6をカバーするためにIPv4特有のテキストを含んだバージョンの既存の不可知論者オブジェクト(例えば、tunnelIfTOS)の記述節をアップデートしました。
Added tunnelIfFlowLabel for tunnels over IPv6.
IPv6の上のトンネルにtunnelIfFlowLabelを加えました。
The encapsulation method was previously an INTEGER
type, and is now an IANA-maintained textual
convention.
カプセル化メソッドは、以前にINTEGERがタイプするということであり、現在、IANAによって維持された原文のコンベンションです。
Published as RFC 4087."
REVISION "199908241200Z" -- August 24, 1999
DESCRIPTION
"Initial version, published as RFC 2667."
::= { transmission 131 }
「RFC4087として、発行されます」。 REVISION"199908241200Z"--「初期のバージョンであって、RFC2667として発行された」1999年8月24日記述。 ::= トランスミッション131
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnelMIBObjectsオブジェクト識別子:、:= tunnelMIB1
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
OBJECT IDENTIFIERにトンネルを堀ってください:、:= tunnelMIBObjects1
-- the IP Tunnel MIB-Group -- -- a collection of objects providing information about -- IP Tunnels
-- IP Tunnel MIB-グループ----周囲で情報を提供するオブジェクトの収集--IP Tunnels
tunnelIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels."
「構成されることの(概念的)のテーブル含有情報はトンネルを堀る」tunnelIfTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelIfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
Thaler Standards Track [Page 5] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[5ページ]。
::= { tunnel 1 }
::= トンネル1
tunnelIfEntry OBJECT-TYPE
SYNTAX TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel."
INDEX { ifIndex }
::= { tunnelIfTable 1 }
tunnelIfEntry OBJECT-TYPE SYNTAX TunnelIfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の構成されたトンネルの情報を含むエントリー(概念的な行)。」 ifIndexに索引をつけてください:、:= tunnelIfTable1
TunnelIfEntry ::= SEQUENCE {
tunnelIfLocalAddress IpAddress, -- deprecated
tunnelIfRemoteAddress IpAddress, -- deprecated
tunnelIfEncapsMethod IANAtunnelType,
tunnelIfHopLimit Integer32,
tunnelIfSecurity INTEGER,
tunnelIfTOS Integer32,
tunnelIfFlowLabel IPv6FlowLabelOrAny,
tunnelIfAddressType InetAddressType,
tunnelIfLocalInetAddress InetAddress,
tunnelIfRemoteInetAddress InetAddress,
tunnelIfEncapsLimit Integer32
}
TunnelIfEntry:、:= 系列tunnelIfLocalAddress IpAddress--推奨しないtunnelIfRemoteAddress IpAddress--推奨しないtunnelIfEncapsMethod IANAtunnelType、tunnelIfHopLimit Integer32、tunnelIfSecurity INTEGER、tunnelIfTOS Integer32、tunnelIfFlowLabel IPv6FlowLabelOrAny、tunnelIfAddressType InetAddressType、tunnelIfLocalInetAddress InetAddress、tunnelIfRemoteInetAddress InetAddress、tunnelIfEncapsLimit Integer32
tunnelIfLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header), or 0.0.0.0 if unknown or if the tunnel is
over IPv6.
tunnelIfLocalAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「トンネル(すなわち、外側のIPヘッダーで使用されるソースアドレス)、または0.0の地方の終点のアドレス、.0、.0、未知である、またはIPv6の上にトンネルがある、」
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfLocalInetAddress."
::= { tunnelIfEntry 1 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelIfLocalInetAddressを支持して推奨しないです。」 ::= tunnelIfEntry1
tunnelIfRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header), or 0.0.0.0 if unknown, or an IPv6 address, or
または、tunnelIfRemoteAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「トンネル(すなわち、外側のIPヘッダーで使用される送付先アドレス)、または0.0の遠く離れた終点のアドレス、.0 .0 未知、またはIPv6アドレスであるなら」
Thaler Standards Track [Page 6] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[6ページ]。
the tunnel is not a point-to-point link (e.g., if it
is a 6to4 tunnel).
トンネルはポイントツーポイント接続(例えば、それが6to4トンネルであるなら)ではありません。
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfRemoteInetAddress."
::= { tunnelIfEntry 2 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelIfRemoteInetAddressを支持して推奨しないです。」 ::= tunnelIfEntry2
tunnelIfEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelIfEntry 3 }
「カプセル化メソッドはトンネルのそばで使用した」tunnelIfEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= tunnelIfEntry3
tunnelIfHopLimit OBJECT-TYPE
SYNTAX Integer32 (0 | 1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IPv4 TTL or IPv6 Hop Limit to use in the outer IP
header. A value of 0 indicates that the value is
copied from the payload's header."
::= { tunnelIfEntry 4 }
tunnelIfHopLimit OBJECT-TYPE SYNTAX Integer32、(0|1 .255) マックス-ACCESSは「外側のIPヘッダーにおける使用へのIPv4 TTLかIPv6 Hop Limit」をSTATUSの現在の記述に読書して書きます。 「0の値は、値がペイロードのヘッダーからコピーされるのを示します。」 ::= tunnelIfEntry4
tunnelIfSecurity OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no security
ipsec(2), -- IPsec security
other(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The method used by the tunnel to secure the outer IP
header. The value ipsec indicates that IPsec is used
between the tunnel endpoints for authentication or
encryption or both. More specific security-related
information may be available in a MIB module for the
security protocol in use."
::= { tunnelIfEntry 5 }
tunnelIfSecurity OBJECT-TYPE SYNTAX INTEGER、なにも、(1)--セキュリティがないipsec(2)--IPsecセキュリティ他の(3)、「メソッドは外側のIPヘッダーを固定するのにトンネルのそばで使用した」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 値のipsecは、IPsecが認証、暗号化または両方にトンネル終点の間で使用されるのを示します。 「より特定のセキュリティ関連の情報はセキュリティプロトコルにMIBモジュールで使用中に利用可能であるかもしれません。」 ::= tunnelIfEntry5
tunnelIfTOS OBJECT-TYPE
SYNTAX Integer32 (-2..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the high 6 bits (the
tunnelIfTOS OBJECT-TYPE SYNTAX Integer32(-2 .63)マックス-ACCESSが現在の記述をSTATUSに読書して書く、「メソッドが以前は高値をよく6ビット設定していた、(」
Thaler Standards Track [Page 7] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[7ページ]。
differentiated services codepoint) of the IPv4 TOS or
IPv6 Traffic Class in the outer IP header. A value of
-1 indicates that the bits are copied from the
payload's header. A value of -2 indicates that a
traffic conditioner is invoked and more information
may be available in a traffic conditioner MIB module.
A value between 0 and 63 inclusive indicates that the
bit field is set to the indicated value.
差別化されたサービスcodepoint) 外側のIPヘッダーのIPv4 TOSかIPv6 Traffic Classについて。 -1の値は、ビットがペイロードのヘッダーからコピーされるのを示します。 -2の値はトラフィックコンディショナーが呼び出されて、詳しい情報がトラフィックコンディショナーMIBモジュールで利用可能であるかもしれないことを示します。 0と63の間で包括的な値は、噛み付いている分野が表示値に設定されるのを示します。
Note: instead of the name tunnelIfTOS, a better name
would have been tunnelIfDSCPMethod, but the existing
name appeared in RFC 2667 and existing objects cannot
be renamed."
::= { tunnelIfEntry 6 }
以下に注意してください。 「既存の名前はRFC2667に現れました、そして、tunnelIfTOSという名前の代わりにより良い名前はtunnelIfDSCPMethodだったでしょうが、既存のオブジェクトは改名できません。」 ::= tunnelIfEntry6
tunnelIfFlowLabel OBJECT-TYPE
SYNTAX IPv6FlowLabelOrAny
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the IPv6 Flow Label value.
This object need not be present in rows where
tunnelIfAddressType indicates the tunnel is not over
IPv6. A value of -1 indicates that a traffic
conditioner is invoked and more information may be
available in a traffic conditioner MIB. Any other
value indicates that the Flow Label field is set to
the indicated value."
::= { tunnelIfEntry 7 }
tunnelIfFlowLabel OBJECT-TYPE SYNTAX IPv6FlowLabelOrAnyマックス-ACCESSは「メソッドは以前はよくIPv6 Flow Label値を設定していたこと」をSTATUSの現在の記述に読書して書きます。 このオブジェクトは列をなしてtunnelIfAddressTypeがIPv6の上にトンネルがないのを示すところに存在している必要はありません。 -1の値はトラフィックコンディショナーが呼び出されて、詳しい情報がトラフィックコンディショナーMIBで利用可能であるかもしれないことを示します。 「いかなる他の値も、Flow Label分野が表示値に設定されるのを示します。」 ::= tunnelIfEntry7
tunnelIfAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The type of address in the corresponding
tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects."
::= { tunnelIfEntry 8 }
tunnelIfAddressType OBJECT-TYPE SYNTAX InetAddressTypeマックス-ACCESSは「対応するtunnelIfLocalInetAddressとtunnelIfRemoteInetAddressオブジェクトのアドレスのタイプ」をSTATUSの現在の記述に読書して書きます。 ::= tunnelIfEntry8
tunnelIfLocalInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header). If the address is unknown, the value is
tunnelIfLocalInetAddress OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「トンネル(すなわち、外側のIPヘッダーで使用されるソースアドレス)の地方の終点のアドレス」をSTATUSの現在の記述に読書して書きます。 アドレスが未知であるなら、値は未知です。
Thaler Standards Track [Page 8] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[8ページ]。
0.0.0.0 for IPv4 or :: for IPv6. The type of this
object is given by tunnelIfAddressType."
::= { tunnelIfEntry 9 }
または、0.0.0.0、IPv4、:、: IPv6のために。 「このオブジェクトのタイプはtunnelIfAddressTypeによって与えられています。」 ::= tunnelIfEntry9
tunnelIfRemoteInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header). If the address is unknown or the tunnel is
not a point-to-point link (e.g., if it is a 6to4
tunnel), the value is 0.0.0.0 for tunnels over IPv4 or
:: for tunnels over IPv6. The type of this object is
given by tunnelIfAddressType."
::= { tunnelIfEntry 10 }
tunnelIfRemoteInetAddress OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「トンネル(すなわち、外側のIPヘッダーで使用される送付先アドレス)の遠く離れた終点のアドレス」をSTATUSの現在の記述に読書して書きます。 または、アドレスが未知であるか、トンネルがポイントツーポイント接続(例えば、それが6to4トンネルであるなら)でないなら、値が0.0である、.0、IPv4の上のトンネルへの.0、:、: IPv6の上のトンネルに。 「このオブジェクトのタイプはtunnelIfAddressTypeによって与えられています。」 ::= tunnelIfEntry10
tunnelIfEncapsLimit OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of additional encapsulations
permitted for packets undergoing encapsulation at this
node. A value of -1 indicates that no limit is
present (except as a result of the packet size)."
REFERENCE "RFC 2473, section 4.1.1"
::= { tunnelIfEntry 11 }
tunnelIfEncapsLimit OBJECT-TYPE SYNTAX Integer32、(-1|0 . .255) マックス-ACCESSは「追加カプセル化の最大数はこのノードでカプセル化を受けるパケットのために可能にしたこと」をSTATUSの現在の記述に読書して書きます。 「-1の値は、どんな限界も存在していないのを(パケットサイズを除いた)示します。」 REFERENCE、「セクション4.1 RFC2473、0.1インチ:、:、」= tunnelIfEntry11
tunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed IPv4
destination address should have a corresponding row in
the tunnelConfigTable, regardless of whether it was
created via SNMP.
「構成されることの(概念的)のテーブル含有情報はトンネルを堀る」tunnelConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF TunnelConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述。 1セットのトンネル終点を関連ifIndex値に写像するのにこのテーブルを使用できます。 また、行作成にそれを使用できます。 それがSNMPを通して作成されたかどうかにかかわらず固定IPv4送付先アドレスがあるtunnelIfTableのあらゆる行がtunnelConfigTableに対応する行を持つべきであることに注意してください。
Since this table does not support IPv6, it is
deprecated in favor of tunnelInetConfigTable."
::= { tunnel 2 }
「このテーブルがIPv6をサポートしないので、それはtunnelInetConfigTableを支持して推奨しないです。」 ::= トンネル2
Thaler Standards Track [Page 9] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[9ページ]。
tunnelConfigEntry OBJECT-TYPE
SYNTAX TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel.
tunnelConfigEntry OBJECT-TYPE SYNTAX TunnelConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述、「特定の構成されたトンネルの情報を含むエントリー(概念的な行)。」
Since this entry does not support IPv6, it is
deprecated in favor of tunnelInetConfigEntry."
INDEX { tunnelConfigLocalAddress,
tunnelConfigRemoteAddress,
tunnelConfigEncapsMethod,
tunnelConfigID }
::= { tunnelConfigTable 1 }
「このエントリーがIPv6をサポートしないので、それはtunnelInetConfigEntryを支持して推奨しないです。」 tunnelConfigLocalAddress、tunnelConfigRemoteAddress、tunnelConfigEncapsMethod、tunnelConfigIDに索引をつけてください:、:= tunnelConfigTable1
TunnelConfigEntry ::= SEQUENCE {
tunnelConfigLocalAddress IpAddress,
tunnelConfigRemoteAddress IpAddress,
tunnelConfigEncapsMethod IANAtunnelType,
tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero,
tunnelConfigStatus RowStatus
}
TunnelConfigEntry:、:= 系列tunnelConfigLocalAddress IpAddress、tunnelConfigRemoteAddress IpAddress、tunnelConfigEncapsMethod IANAtunnelType、tunnelConfigID Integer32、tunnelConfigIfIndex InterfaceIndexOrZero、tunnelConfigStatus RowStatus
tunnelConfigLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 if the device is free to choose any of its
addresses at tunnel establishment time.
tunnelConfigLocalAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述、「トンネル、または0.0の地方の終点のアドレス、.0、.0がデバイスであるならトンネル設立時間に自由にアドレスのどれかを選ぶことができる、」
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigLocalAddress."
::= { tunnelConfigEntry 1 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigLocalAddressを支持して推奨しないです。」 ::= tunnelConfigEntry1
tunnelConfigRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel.
tunnelConfigRemoteAddress OBJECT-TYPE SYNTAX IpAddressのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述、「トンネルの遠く離れた終点のアドレス。」
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigRemoteAddress."
::= { tunnelConfigEntry 2 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigRemoteAddressを支持して推奨しないです。」 ::= tunnelConfigEntry2
Thaler Standards Track [Page 10] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[10ページ]。
tunnelConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The encapsulation method used by the tunnel.
「カプセル化メソッドはトンネルのそばで使用した」tunnelConfigEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelTypeのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述。
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigEncapsMethod."
::= { tunnelConfigEntry 3 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigEncapsMethodを支持して推奨しないです。」 ::= tunnelConfigEntry3
tunnelConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
conflict with an existing row, such as choosing a
random number.
「識別子は同じ終点で同じカプセル化メソッドの複数のトンネルを見分けるのに使用した」tunnelConfigID OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述。 カプセル化プロトコルが終点アドレス(GREやIPにおけるIPなどの)のセットあたり1つのトンネルしか許容しないなら、このオブジェクトの値は1です。 複数の平行なトンネルを許容するカプセル化メソッド(L2Fなどの)において、マネージャは既存の行と衝突しないどんなIDも選ぶのに責任があります、乱数を選ぶのなどように。
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigID."
::= { tunnelConfigEntry 4 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigIDを支持して推奨しないです。」 ::= tunnelConfigEntry4
tunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"If the value of tunnelConfigStatus for this row is
active, then this object contains the value of ifIndex
corresponding to the tunnel interface. A value of 0
is not legal in the active state, and means that the
interface index has not yet been assigned.
tunnelConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「この行のためのtunnelConfigStatusの値がアクティブであるなら、このオブジェクトはトンネルのインタフェースに対応するifIndexの値を含んでいます」。 0の値は、活動的な状態で法的でなく、インタフェースインデックスがまだ割り当てられていないことを意味します。
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigIfIndex."
::= { tunnelConfigEntry 5 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigIfIndexを支持して推奨しないです。」 ::= tunnelConfigEntry5
tunnelConfigStatus OBJECT-TYPE
SYNTAX RowStatus
tunnelConfigStatusオブジェクト・タイプ構文RowStatus
Thaler Standards Track [Page 11] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[11ページ]。
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
マックス-ACCESSは「新しいエントリーがどれであるかもしれないかによって作成されたこの行の状態か古いエントリーがこのテーブルから削除した」STATUSの推奨しない記述を読書して作成します。 他のどんな書き込み可能なオブジェクトもこのテーブルにないので、エージェントは、設定がこのオブジェクトであることをcreateAndWaitかnotInServiceに支える必要はありません、そして、この行がアクティブである間、列をなしてtunnelIfTableなどの対応するテーブルの書き込み可能なオブジェクトは変更されるかもしれません。
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelConfigID of 1, and
set tunnelConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelConfigID and
set tunnelConfigStatus to createAndGo. In the event
that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation.
管理局は、同じ終点がある複数の平行なトンネルを支えないカプセル化メソッドのためにこのテーブルの行を作成するために、単に1のtunnelConfigIDを使用して、createAndGoにtunnelConfigStatusを設定するはずです。 複数の平行なトンネルを許容するL2Fなどのカプセル化メソッドのために、管理局はtunnelConfigIDとして使用する擬似乱数とセットtunnelConfigStatusをcreateAndGoに選択するかもしれません。 このIDが既に使用中であり、集合演算に対応してinconsistentValueを返す場合、管理局は、単に新しい擬似乱数を選択して、操作を再試行するはずです。
Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
エージェントはこのテーブルの行を作成するのに実装依存する方法でインタフェースインデックスを割り当てるでしょう、そして、対応する行はifTableとtunnelIfTableに例示されるでしょう。 エージェントがインタフェースインデックスを割り当てるとすぐに、この行の状態はアクティブになるでしょう、インタフェースが操作上上がっているかどうかにかかわらず。
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable.
このテーブルの行を削除すると、ifTableとtunnelIfTableの対応する行は同様に削除されるでしょう。
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigStatus."
::= { tunnelConfigEntry 6 }
「このオブジェクトがIPv6をサポートしないので、それはtunnelInetConfigStatusを支持して推奨しないです。」 ::= tunnelConfigEntry6
tunnelInetConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
tunnelInetConfigTable OBJECT-TYPEのSYNTAX SEQUENCE OF TunnelInetConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述
Thaler Standards Track [Page 12] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[12ページ]。
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed
destination address should have a corresponding row in
the tunnelInetConfigTable, regardless of whether it
was created via SNMP."
::= { tunnel 3 }
「構成されたトンネルの情報を含む(概念的)のテーブル。」 1セットのトンネル終点を関連ifIndex値に写像するのにこのテーブルを使用できます。 また、行作成にそれを使用できます。 「それがSNMPを通して作成されたかどうかにかかわらず固定送付先アドレスがあるtunnelIfTableのあらゆる行がtunnelInetConfigTableに対応する行を持つべきであることに注意してください。」 ::= トンネル3
tunnelInetConfigEntry OBJECT-TYPE
SYNTAX TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel. Note that there is
a 128 subid maximum for object OIDs. Implementers
need to be aware that if the total number of octets in
tunnelInetConfigLocalAddress and
tunnelInetConfigRemoteAddress exceeds 110 then OIDs of
column instances in this table will have more than 128
sub-identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3. In practice this is not expected
to be a problem since IPv4 and IPv6 addresses will not
cause the limit to be reached, but if other types are
supported by an agent, care must be taken to ensure
that the sum of the lengths do not cause the limit to
be exceeded."
INDEX { tunnelInetConfigAddressType,
tunnelInetConfigLocalAddress,
tunnelInetConfigRemoteAddress,
tunnelInetConfigEncapsMethod,
tunnelInetConfigID }
::= { tunnelInetConfigTable 1 }
tunnelInetConfigEntry OBJECT-TYPE SYNTAX TunnelInetConfigEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の構成されたトンネルの情報を含むエントリー(概念的な行)。」 オブジェクトOIDsのための128subid最大があることに注意してください。 Implementersは、tunnelInetConfigLocalAddressとtunnelInetConfigRemoteAddressの八重奏の総数が110を超えているなら、このテーブルのコラムインスタンスのOIDsを128以上のサブ識別子を持って、SNMPv1、SNMPv2c、またはSNMPv3を使用することでアクセスできないのを意識している必要があります。 「達していますが、他のタイプがエージェントによってサポートされるなら、注意しなければならないということである限界がアドレスで確実にしないIPv4とIPv6以来の長さの合計がそうしない問題でないと予想されて、実際には、限界が超えられていることを引き起こしてください。」 tunnelInetConfigAddressType、tunnelInetConfigLocalAddress、tunnelInetConfigRemoteAddress、tunnelInetConfigEncapsMethod、tunnelInetConfigIDに索引をつけてください:、:= tunnelInetConfigTable1
TunnelInetConfigEntry ::= SEQUENCE {
tunnelInetConfigAddressType InetAddressType,
tunnelInetConfigLocalAddress InetAddress,
tunnelInetConfigRemoteAddress InetAddress,
tunnelInetConfigEncapsMethod IANAtunnelType,
tunnelInetConfigID Integer32,
tunnelInetConfigIfIndex InterfaceIndexOrZero,
tunnelInetConfigStatus RowStatus,
tunnelInetConfigStorageType StorageType
}
TunnelInetConfigEntry:、:= 系列tunnelInetConfigAddressType InetAddressType、tunnelInetConfigLocalAddress InetAddress、tunnelInetConfigRemoteAddress InetAddress、tunnelInetConfigEncapsMethod IANAtunnelType、tunnelInetConfigID Integer32、tunnelInetConfigIfIndex InterfaceIndexOrZero、tunnelInetConfigStatus RowStatus、tunnelInetConfigStorageType StorageType
tunnelInetConfigAddressType OBJECT-TYPE
tunnelInetConfigAddressTypeオブジェクト・タイプ
Thaler Standards Track [Page 13] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[13ページ]。
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type over which the tunnel encapsulates
packets."
::= { tunnelInetConfigEntry 1 }
「アドレスはトンネルがパケットをカプセルに入れるものの上でタイプする」SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= tunnelInetConfigEntry1
tunnelInetConfigLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 (for IPv4) or :: (for IPv6) if the device is
free to choose any of its addresses at tunnel
establishment time."
::= { tunnelInetConfigEntry 2 }
または、tunnelInetConfigLocalAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「トンネル、または0.0の地方の終点のアドレス、.0、.0(IPv4のための)、:、:、」 (IPv6のための) 「デバイスがトンネル設立時間に無料でアドレスのどれかを選ぶことができるなら。」 ::= tunnelInetConfigEntry2
tunnelInetConfigRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel."
::= { tunnelInetConfigEntry 3 }
tunnelInetConfigRemoteAddress OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「トンネルの遠く離れた終点のアドレス。」 ::= tunnelInetConfigEntry3
tunnelInetConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelInetConfigEntry 4 }
「カプセル化メソッドはトンネルのそばで使用した」tunnelInetConfigEncapsMethod OBJECT-TYPE SYNTAX IANAtunnelTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= tunnelInetConfigEntry4
tunnelInetConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
「識別子は同じ終点で同じカプセル化メソッドの複数のトンネルを見分けるのに使用した」tunnelInetConfigID OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 カプセル化プロトコルが終点アドレス(GREやIPにおけるIPなどの)のセットあたり1つのトンネルしか許容しないなら、このオブジェクトの値は1です。 複数の平行なトンネルを許容するカプセル化メソッド(L2Fなどの)において、マネージャはそうしないどんなIDも選ぶのに責任があります。
Thaler Standards Track [Page 14] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[14ページ]。
conflict with an existing row, such as choosing a
random number."
::= { tunnelInetConfigEntry 5 }
「乱数を選ぶことなどの既存の行と衝突してください。」 ::= tunnelInetConfigEntry5
tunnelInetConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the value of tunnelInetConfigStatus for this row
is active, then this object contains the value of
ifIndex corresponding to the tunnel interface. A
value of 0 is not legal in the active state, and means
that the interface index has not yet been assigned."
::= { tunnelInetConfigEntry 6 }
tunnelInetConfigIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この行のためのtunnelInetConfigStatusの値がアクティブであるなら、このオブジェクトはトンネルのインタフェースに対応するifIndexの値を含んでいます」。 「0の値は、活動的な状態で法的でなく、インタフェースインデックスがまだ割り当てられていないことを意味します。」 ::= tunnelInetConfigEntry6
tunnelInetConfigStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
tunnelInetConfigStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「新しいエントリーがどれであるかもしれないかによって作成されたこの行の状態か古いエントリーがこのテーブルから削除した」STATUSの現在の記述を読書して作成します。 他のどんな書き込み可能なオブジェクトもこのテーブルにないので、エージェントは、設定がこのオブジェクトであることをcreateAndWaitかnotInServiceに支える必要はありません、そして、この行がアクティブである間、列をなしてtunnelIfTableなどの対応するテーブルの書き込み可能なオブジェクトは変更されるかもしれません。
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelInetConfigID of 1,
and set tunnelInetConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelInetConfigID
and set tunnelInetConfigStatus to createAndGo. In the
event that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation.
管理局は、同じ終点がある複数の平行なトンネルを支えないカプセル化メソッドのためにこのテーブルの行を作成するために、単に1のtunnelInetConfigIDを使用して、createAndGoにtunnelInetConfigStatusを設定するはずです。 複数の平行なトンネルを許容するL2Fなどのカプセル化メソッドのために、管理局はtunnelInetConfigIDとして使用する擬似乱数とセットtunnelInetConfigStatusをcreateAndGoに選択するかもしれません。 このIDが既に使用中であり、集合演算に対応してinconsistentValueを返す場合、管理局は、単に新しい擬似乱数を選択して、操作を再試行するはずです。
Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
そしてエージェントがこのテーブルの行を作成するのに実装依存する方法でインタフェースインデックスを割り当てて、対応する行がifTableに例示される。
Thaler Standards Track [Page 15] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[15ページ]。
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
tunnelIfTable。 エージェントがインタフェースインデックスを割り当てるとすぐに、この行の状態はアクティブになるでしょう、インタフェースが操作上上がっているかどうかにかかわらず。
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable."
::= { tunnelInetConfigEntry 7 }
「このテーブルの行を削除すると、ifTableとtunnelIfTableの対応する行は同様に削除されるでしょう。」 ::= tunnelInetConfigEntry7
tunnelInetConfigStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this row. If the row is
permanent(4), no objects in the row need be writable."
::= { tunnelInetConfigEntry 8 }
tunnelInetConfigStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「このストレージタイプはこぐ」STATUSの現在の記述を読書して作成します。 「行が永久的な(4)であるなら、行でどんなオブジェクトも書き込み可能である必要はありません。」 ::= tunnelInetConfigEntry8
-- conformance information
-- 順応情報
tunnelMIBConformance
OBJECT IDENTIFIER ::= { tunnelMIB 2 }
tunnelMIBCompliances
OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
tunnelMIBConformanceオブジェクト識別子:、:= tunnelMIB2tunnelMIBCompliancesオブジェクト識別子:、:= tunnelMIBConformance1tunnelMIBGroupsオブジェクト識別子:、:= tunnelMIBConformance2
-- compliance statements
-- 承諾声明
tunnelMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The (deprecated) IPv4-only compliance statement for
the IP Tunnel MIB.
tunnelMIBCompliance MODULE-COMPLIANCE STATUSの推奨しない記述、「IP Tunnel MIBのための(推奨しない)のIPv4だけ承諾声明。」
This is deprecated in favor of
tunnelMIBInetFullCompliance and
tunnelMIBInetReadOnlyCompliance."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBBasicGroup }
「これはtunnelMIBInetFullComplianceとtunnelMIBInetReadOnlyComplianceを支持して推奨しないです。」 MODULE--このモジュールMANDATORY-GROUPStunnelMIBBasicGroup
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfHopLimit MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelIfTOS
MIN-ACCESS read-only
OBJECT tunnelIfTOS MIN-ACCESS書き込み禁止
Thaler Standards Track [Page 16] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[16ページ]。
DESCRIPTION
"Write access is not required."
記述、「書く、アクセスは必要でない、」
OBJECT tunnelConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 1 }
OBJECT tunnelConfigStatus MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 ::= tunnelMIBCompliances1
tunnelMIBInetFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The full compliance statement for the IP Tunnel MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
tunnelMIBInetFullCompliance MODULE-COMPLIANCE STATUSの現在の記述、「IP Tunnel MIBに、完全な承諾声明。」 MODULE--このモジュールMANDATORY-GROUPStunnelMIBInetGroup
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
::= { tunnelMIBCompliances 2 }
OBJECT tunnelIfAddressType SYNTAX InetAddressType、ipv4(1)、ipv6(2)、ipv4z(3)、ipv6z(4)、「IPv4、そして/または、IPv6アドレスであるとサポート実装が必要であるだけである」記述。 「実装は、それが実際にデバイスでサポートするアドレスをサポートする必要があるだけです。」 ::= tunnelMIBCompliances2
tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The read-only compliance statement for the IP Tunnel
MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE STATUSの現在の記述、「IP Tunnel MIBのための書き込み禁止承諾声明。」 MODULE--このモジュールMANDATORY-GROUPStunnelMIBInetGroup
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfHopLimit MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelIfTOS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelIfFlowLabel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfFlowLabel MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
Thaler Standards Track [Page 17] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[17ページ]。
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required.
OBJECT tunnelIfAddressType SYNTAX InetAddressType、ipv4(1)、ipv6(2)、ipv4z(3)、ipv6z(4)、MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
実装が、IPv4、そして/または、IPv6がアドレスであるとサポートするのに必要であるだけです。 「実装は、それが実際にデバイスでサポートするアドレスをサポートする必要があるだけです。」
OBJECT tunnelIfLocalInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfLocalInetAddress MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelIfRemoteInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfRemoteInetAddress MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelIfEncapsLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfEncapsLimit MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT tunnelInetConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only
status that needs to be supported."
OBJECT tunnelInetConfigStatus MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要ではありません、そして、アクティブであるのが、サポートされる必要がある唯一の状態である、」
OBJECT tunnelInetConfigStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 3 }
OBJECT tunnelInetConfigStorageType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」 ::= tunnelMIBCompliances3
-- units of conformance
-- ユニットの順応
tunnelMIBBasicGroup OBJECT-GROUP
OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress,
tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS,
tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects to support basic management
tunnelMIBBasicGroup OBJECT-GROUP OBJECTS、tunnelIfLocalAddress、tunnelIfRemoteAddress、tunnelIfEncapsMethod、tunnelIfHopLimit、tunnelIfTOS、tunnelIfSecurity、tunnelConfigIfIndex、tunnelConfigStatus、STATUSの推奨しない記述、「基本的な管理をサポートするオブジェクトの収集」
Thaler Standards Track [Page 18] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[18ページ]。
of IPv4 Tunnels. Since this group cannot support
IPv6, it is deprecated in favor of
tunnelMIBInetGroup."
::= { tunnelMIBGroups 1 }
IPv4Tunnelsについて。 「このグループがIPv6をサポートすることができないので、それはtunnelMIBInetGroupを支持して推奨しないです。」 ::= tunnelMIBGroups1
tunnelMIBInetGroup OBJECT-GROUP
OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, tunnelIfEncapsMethod,
tunnelIfEncapsLimit,
tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel,
tunnelIfSecurity, tunnelInetConfigIfIndex,
tunnelInetConfigStatus, tunnelInetConfigStorageType }
STATUS current
DESCRIPTION
"A collection of objects to support basic management
of IPv4 and IPv6 Tunnels."
::= { tunnelMIBGroups 2 }
tunnelMIBInetGroup OBJECT-GROUP OBJECTS、tunnelIfAddressType、tunnelIfLocalInetAddress、tunnelIfRemoteInetAddress、tunnelIfEncapsMethod、tunnelIfEncapsLimit、tunnelIfHopLimit、tunnelIfTOS、tunnelIfFlowLabel、tunnelIfSecurity、tunnelInetConfigIfIndex、tunnelInetConfigStatus、tunnelInetConfigStorageType、STATUSの現在の記述、「IPv4とIPv6Tunnelsの基本的な管理をサポートするオブジェクトの収集。」 ::= tunnelMIBGroups2
END
終わり
5. IANA Considerations
5. IANA問題
This document introduces a new IANA-maintained textual convention (TC) which has been added to the IANAifType-MIB [IFTYPE]. The initial version of this IANAtunnelType TC can be found in Appendix A. The current version of the textual convention can be accessed at http://www.iana.org/assignments/ianaiftype-mib
このドキュメントはIANAifType-MIB[IFTYPE]に加えられる新しいIANAによって維持された原文のコンベンション(TC)を導入します。 このIANAtunnelType TCの初期のバージョンはAppendix A.で見つけられて、 http://www.iana.org/assignments/ianaiftype-mib で原文のコンベンションの最新版にアクセスできるということであるかもしれません。
The assignment policy for IANAtunnelType values should always be identical to the policy for assigning IANAifType values.
IANAtunnelType値のための課題方針はいつも値をIANAifTypeに割り当てるための方針と同じであるべきです。
New types of tunnels over IPv4 or IPv6 should not be assigned IANAifType values. Instead, they should be assigned IANAtunnelType values and hence reuse the interface type tunnel(131). (Note this restriction does not apply to "tunnels" which are not over IPv4 or IPv6.)
IPv4かIPv6の上の新しいタイプのトンネルにIANAifType値を割り当てるべきではありません。 代わりに、彼らは、IANAtunnelType値が割り当てられて、したがって、インターフェース型トンネル(131)を再利用するべきです。 (この制限がIPv4かIPv6の上にない「トンネル」に適用されないことに注意してください。)
Previously, tunnel types that were not point-to-point tunnels were problematic in that they could not be properly expressed in the tunnel MIB, and hence were assigned IANAifType values. This document now corrects this problem, and as a result, IANA has deprecated the sixToFour(215) IANAifType value in favor of the sixToFour(11) IANAtunnelType value.
トンネルMIBで適切に言い表すことができないで、したがって、IANAifType値が割り当てられたので、以前、二地点間トンネルでなかったトンネルタイプは問題が多かったです。 このドキュメントは現在この問題を修正します、そして、その結果、IANAには、sixToFour(11) IANAtunnelType値を支持して推奨しないsixToFour(215) IANAifType値があります。
Thaler Standards Track [Page 19] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[19ページ]。
6. Security Considerations
6. セキュリティ問題
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
Unauthorized write access to any of the writable objects could cause unauthorized creation and/or manipulation of tunnels, resulting in a denial of service, or redirection of packets to an arbitrary destination.
権限のなさ、トンネルの権限のない作成、そして/または、操作を引き起こす場合があって、サービスのa否定、または任意の目的地へのパケットのリダイレクションをもたらしながら、書き込み可能なオブジェクトのどれかへのアクセスを書いてください。
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.
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。
Unauthorized read access to tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, tunnelIfLocalAddress, tunnelIfRemoteAddress, or any object in the tunnelConfigTable or tunnelInetConfigTable would reveal information about the tunnel topology.
tunnelConfigTableかtunnelInetConfigTableのtunnelIfLocalInetAddress、tunnelIfRemoteInetAddress、tunnelIfLocalAddress、tunnelIfRemoteAddress、またはどんなオブジェクトへの権限のない読書アクセスもトンネルトポロジーの情報を明らかにするでしょう。
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モジュールでだれに許容されているかに関してコントロールが全くありません。
It is RECOMMENDED that implementers 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).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Further, 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に与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
Thaler Standards Track [Page 20] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[20ページ]。
7. Changes Since RFC 2667
7. RFC2667以来の変化
IPv4-specific objects were deprecated, including tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable, and the tunnelMIBBasicGroup.
tunnelIfLocalAddress、tunnelIfRemoteAddress、tunnelConfigTable、およびtunnelMIBBasicGroupを含んでいて、IPv4特有のオブジェクトは推奨しなかったです。
Added IP version-agnostic objects that should be used instead, including tunnelIfAddressType, tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the tunnelIMIBInetGroup.
tunnelIfAddressType、tunnelIfLocalInetAddress、tunnelIfRemoteInetAddress、tunnelInetConfigTable、およびtunnelIMIBInetGroupを含んでいて、代わりに使用されるべきであるIPバージョン不可知論者オブジェクトを加えました。
The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress objects are read-write, rather than read-only.
読書唯一であるというよりむしろ新しいtunnelIfLocalInetAddressとtunnelIfRemoteInetAddressオブジェクトは読書して書いています。
Updated DESCRIPTION clauses of existing version-agnostic objects (e.g., tunnelIfTOS) that contained IPv4-specific text to cover IPv6 as well.
また、IPv6をカバーするためにIPv4特有のテキストを含んだ既存のバージョン不可知論者オブジェクト(例えば、tunnelIfTOS)の記述節をアップデートしました。
Added tunnelIfFlowLabel for tunnels over IPv6.
IPv6の上のトンネルにtunnelIfFlowLabelを加えました。
The encapsulation method was previously an INTEGER type, and is now an IANA-maintained textual convention.
カプセル化メソッドは、以前にINTEGERがタイプするということであり、現在、IANAによって維持された原文のコンベンションです。
8. Acknowledgements
8. 承認
This MIB module was updated based on feedback from the IETF's Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions (PPPEXT), and IPv6 Working Groups. Mike Heard and Ville Nuorvala also provided valuable MIB guidance on this version.
IETFのInterfaces MIBからのフィードバックに基づいてこのMIBモジュールをアップデートした、(-、MIB、)、PointからポイントへのプロトコルExtensions(PPPEXT)、およびIPv6 Working Groups。 また、マイクHeardとヴィルNuorvalaはこのバージョンで貴重なMIB指導を提供しました。
Thaler Standards Track [Page 21] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[21ページ]。
Appendix A: IANA Tunnel Type TC
付録A: IANAトンネルタイプTc
This appendix defines the initial content of the IANAtunnelType textual convention. The most up-to-date and current version is maintained in the IANAifType-MIB.
この付録はIANAtunnelTypeの原文のコンベンションの初期の内容を定義します。 最も最新の、そして、現在のバージョンはIANAifType-MIBで維持されます。
IANAtunnelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated
directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates
that a Minimal Forwarding Header (RFC 2004) is
inserted between the outer header and the payload
packet. The value UDP indicates that the payload
packet is encapsulated within a normal UDP packet
(e.g., RFC 1234).
IANAtunnelType:、:= 「カプセル化メソッドはトンネルのそばで使用した」TEXTUAL-CONVENTION STATUSの現在の記述。 値が指示する、パケットが中間的ヘッダーのない普通のIPヘッダー、および遠く離れたトンネル終点へのユニキャスト(例えば、RFC2003IPにおけるIPトンネル、またはRFC1933IPv4のIPv6トンネル)の直接中でカプセルに入れられるのを示します。 値、最小量、Minimal Forwarding Header(RFC2004)が外側のヘッダーとペイロードパケットの間に挿入されるのを示します。 値のUDPは、ペイロードパケットが正常なUDPパケット(例えば、RFC1234)の中でカプセルに入れられるのを示します。
The values sixToFour, sixOverFour, and isatap
indicates that an IPv6 packet is encapsulated directly
within an IPv4 header, with no intermediate header,
and unicast to the destination determined by the 6to4,
6over4, or ISATAP protocol.
値のsixToFour、sixOverFour、およびisatapは、IPv6パケットが中間的ヘッダーのないIPv4ヘッダー、および6to4で断固とした目的地へのユニキャストの直接中でカプセルに入れられるのを示します、6over4、または、ISATAPは議定書を作ります。
The remaining protocol-specific values indicate that a
header of the protocol of that name is inserted
between the outer header and the payload header.
残っているプロトコル特有の値は、その名前のプロトコルのヘッダーが外側のヘッダーとペイロードヘッダーの間に挿入されるのを示します。
The assignment policy for IANAtunnelType values is
identical to the policy for assigning IANAifType
values."
SYNTAX INTEGER {
other(1), -- none of the following
direct(2), -- no intermediate header
gre(3), -- GRE encapsulation
minimal(4), -- Minimal encapsulation
l2tp(5), -- L2TP encapsulation
pptp(6), -- PPTP encapsulation
l2f(7), -- L2F encapsulation
udp(8), -- UDP encapsulation
atmp(9), -- ATMP encapsulation
msdp(10), -- MSDP encapsulation
sixToFour(11), -- 6to4 encapsulation
sixOverFour(12), -- 6over4 encapsulation
isatap(13), -- ISATAP encapsulation
「IANAtunnelType値のための課題方針は値をIANAifTypeに割り当てるための方針と同じです。」 SYNTAX INTEGER、他の(1)、--以下のいずれも(2)--中間的ヘッダーgre(3)がありません--GREカプセル化最小量の(4)--最小量のカプセル化l2tp(5)--L2TPカプセル化pptp(6)--PPTPカプセル化l2f(7)--L2Fカプセル化udp(8)--UDPカプセル化atmp(9)--ATMPカプセル化msdp(10)--MSDPカプセル化sixToFour(11)--6to4カプセル化sixOverFour(12)--6over4カプセル化isatap(13)--ISATAPカプセル化を指示しない
Thaler Standards Track [Page 22] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[22ページ]。
teredo(14) -- Teredo encapsulation
}
船食虫、(14)--船食虫、カプセル化
Normative References
引用規格
[IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB",
http://www.iana.org/assignments/ianaiftype-mib.
[IFTYPE]インターネットは数の権威、"IANAifType-MIB" http://www.iana.org/assignments/ianaiftype-mib を割り当てました。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2473] コンタとA.とS.デアリング、「IPv6仕様によるジェネリックパケットトンネリング」、RFC2473、1998年12月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズ、M.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズ、M.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.、およびF.Kastenholz。 「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label",
RFC 3595, September 2003.
[RFC3595] Wijnen、B.、「IPv6流れラベルのための原文のコンベンション」、RFC3595、2003年9月。
[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。
Informative References
有益な参照
[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
RFC 1234, June 1991.
[RFC1234] Provan、D.、「IPネットワークを通したトンネリングIPXトラフィック」、RFC1234、1991年6月。
[RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet
Encapsulation Protocol: Version 1", RFC 1241, July 1991.
[RFC1241]Woodburn、研究開発工場、「インターネットカプセル化の計画は以下について議定書の中で述べます」。 バージョン1インチ、RFC1241、1991年7月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
1994年10月の[RFC1701]ハンクスとS.と李とT.とファリナッチ、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC1701。
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
1994年10月の[RFC1702]ハンクスとS.と李とT.とファリナッチ、D.とP.Traina、「IPv4ネットワークの上の一般的なルート設定Encapsulation」RFC1702。
Thaler Standards Track [Page 23] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[23ページ]。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2003] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2004] パーキンス、C.、「IPの中の最小量のカプセル化」、RFC2004、1996年10月。
[RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP",
RFC 2107, February 1997.
[RFC2107]Hamzeh、K.、「トンネル管理プロトコルを昇ってください--ATMP」、RFC2107、2月1997日
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer
Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2341] バレンシア、A.、リトルウッド、M.、およびT.コラール。 「コクチマス層Twoの推進(プロトコル)"L2F"」(RFC2341)は1998がそうするかもしれません。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black.
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.は黒くされます。 「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474、1998年12月。
[RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol",
RFC 2637, July 1999.
[RFC2637] Hamzeh、K.、祭服、G.、Verthein、W.Taarud、J.、少し、w.、およびG.ゾルン、「二地点間トンネリングプロトコル」、RFC2637(1999年7月)。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] ギリガン、R.、およびE.Nordmark。 「IPv6ホストとルータのための変遷メカニズム」、RFC2893、2000年8月。
[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月)。
Author's Address
作者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デーヴターレルマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Thaler Standards Track [Page 24] RFC 4087 IP Tunnel MIB June 2005
ターレル規格はIPトンネルMIB2005年6月にRFC4087を追跡します[24ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Thaler Standards Track [Page 25]
ターレル標準化過程[25ページ]
一覧
スポンサーリンク
