[要約] RFC 2667は、IPトンネルMIB（Management Information Base）に関する規格であり、IPトンネルの管理情報を提供するためのデータモデルを定義しています。このRFCの目的は、ネットワーク管理者がIPトンネルを効果的に監視および管理できるようにすることです。
Network Working Group D. Thaler
Request for Comments: 2667 Microsoft
Category: Standards Track August 1999
IP Tunnel 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.
このメモは、インターネットコミュニティでのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）を定義します。特に、それは、IPv4ネットワーク上の任意のタイプのトンネルを管理するために使用される管理オブジェクトについて説明します。拡張MIBは、プロトコル固有のオブジェクトを管理するために設計されてもよいです。同様に、拡張MIBは、セキュリティ固有のオブジェクトを管理するために設計されてもよいです。このMIBは、（IPv6ネットワークを含む）非IPv4ネットワーク経由のトンネルをサポートしていません。そのようなトンネルの管理は、他のMIBによってサポートされてもよいです。
Table of Contents
目次
1 Abstract ...................................................... 1
2 Introduction .................................................. 2
3 The SNMP Network Management Framework ......................... 2
4 Overview ...................................................... 3
4.1 Relationship to the Interfaces MIB .......................... 3
4.1.1 Layering Model ............................................ 3
4.1.2 ifRcvAddressTable ......................................... 4
4.1.3 ifEntry ................................................... 4
5 Definitions ................................................... 4
6 Security Considerations ...................................... 12
7 Acknowledgements ............................................. 12
8 Author's Address ............................................. 12
9 References ................................................... 13
10 Intellectual Property Notice ................................. 15
11 Full Copyright Statement ..................................... 16
Over the past several years, there have been a number of "tunneling" protocols specified by the IETF (see [28] for an early discussion of the model and examples). This document describes a Management Information Base (MIB) used for managing tunnels of any type over IPv4 networks, including GRE [16,17], IP-in-IP [18], Minimal Encapsulation [19], L2TP [20], PPTP [21], L2F [25], UDP (e.g., [26]), ATMP [22], and IPv6-in-IPv4 [27] tunnels.
過去数年にわたり、IETFによって指定された「トンネリング」プロトコルの数（モデルと例の早期の議論のための[28]を参照）がありました。この文書管理情報ベース（MIB）は、IPインIP、GRE [16,17]を含む、IPv4ネットワーク上の任意のタイプのトンネルを管理するための説明[18]、最小カプセル化[19]、L2TP [20]、PPTP [21]、L2F [25]、UDP（例えば、[26]）、ATMP [22]、およびIPv6型のIPv4 [27]トンネル。
Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects (e.g., IPSEC [24]), and traffic conditioner [29] objects. Finally, this MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.
拡張MIBは、プロトコル固有のオブジェクトを管理するために設計されてもよいです。同様に、拡張MIBは[29]オブジェクトセキュリティ固有のオブジェクト（例えば、IPSEC [24]）、およびトラフィックコンディショナを管理するために設計されてもよいです。最後に、このMIBは、（IPv6ネットワークを含む）非IPv4ネットワーク経由のトンネルをサポートしていません。そのようなトンネルの管理は、他のMIBによってサポートされてもよいです。
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5つの主要コンポーネントから構成されています。
o An overall architecture, described in RFC 2571 [1].
RFC 2571に記載され、全体的なアーキテクチャ、O [1]。
o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
管理の目的のためにオブジェクトとイベントを記述し、命名するためのメカニズムO。管理情報（SMI）のこのような構造の最初のバージョンはSTD 16、[2]でSMIv1と呼ばれ、STD 16、RFC 1155に記載され、RFC 1212 [3]及びRFC 1215 [4]。 SMIv2のと呼ばれる第二のバージョン、STD 58、RFC 2578に記載されている[5]、STD 58、RFC 2579 [6]およびSTD 58、RFC 2580 [7]。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
管理情報を転送するためのOメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、[8]のSNMPv1と呼ばれ、STD 15、RFC 1157に記載されています。インターネット標準トラックプロトコルでないSNMPメッセージプロトコルの第2のバージョンは、SNMPv2cのと呼ばれ、RFC 1901年に記載されている[9]およびRFC 1906 [10]。メッセージプロトコルの第三のバージョンのSNMPv3と呼ばれ、RFC 1906年に記載されている[10]、RFC 2572 [11]およびRFC 2574 [12]。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
管理情報にアクセスするためのOプロトコル操作。プロトコル操作と関連PDU形式の第一セットは、STD 15、RFC 1157に記載されている[8]。プロトコル操作と関連PDU形式の第2のセットは、RFC 1905 [13]に記載されています。
o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
O RFC 2573 [14]とビューベースアクセス制御メカニズムに記載の基本的なアプリケーションのセットは、RFC 2575 [15]に記載します。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されています。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 SMIv1に従うMIBは、適切な翻訳を介して製造することができます。得られた翻訳されたMIBには翻訳（Counter64のの使用）が可能ではないので、オブジェクトまたはイベントが省略されている場合を除いて、意味的に等価でなければなりません。 SMIv2のいくつかの機械読み取り可能な情報には、翻訳プロセスの間、SMIv1の原文の記述に変換されます。しかし、機械読み取り可能な情報のこの損失がMIBの意味論を変えると考えられません。
This MIB module contains two tables:
このMIBモジュールは、2つのテーブルが含まれています。
o the Tunnel Interface Table, containing information on the tunnels known to a router; and
トンネルインターフェイス表O、ルータに知られているトンネルの情報を含みます。そして
o the Tunnel 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もトンネルを動的に作成するために使用することができ、トンネル構成表は、現在のインターフェースインデックス値にエンドポイントアドレスからマッピングを提供します。
This section clarifies the relationship of this MIB to the Interfaces MIB [23]. 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 [23]には、このMIBの関係を明確にしています。相関関係のいくつかの領域は、以下のサブセクションで対処されています。実装者は、これらの領域の総合的目的を理解するために、インタフェースMIBドキュメントと呼ばれます。
Each logical interface (physical or virtual) has an ifEntry in the Interfaces MIB [23]. 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 addresses of the tunnels are configured. The basic model, therefore, looks something like this (for example):
（物理または仮想）各論理インタフェースは、インタフェースMIB [23]でのifEntryを有しています。トンネルは、各トンネルの論理インターフェイス（ifEntryの）を作成することによって処理されます。これらは、その後、トンネルのローカルIPv4アドレスが設定されているもののインターフェイスに、インターフェイスMIBのifStackテーブルを用いて、相関しています。基本モデルは、したがって、（例えば）次のようになります。
| | | | | |
+--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | |
| tunnel | | tunnel | | |
+--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to underlying
+--+ +---------+ +----------+ +--+ interfaces, to be provided
| Physical interface | by ifStack table
+--------------------------------+
The ifRcvAddressTable usage is defined in the MIBs defining the encapsulation below the network layer. For example, if IP-in-IP encapsulation is being used, the ifRcvAddressTable is defined by IP-in-IP.
ifRcvAddressTable使用は、ネットワーク層の下のカプセル化を定義するMIBで定義されています。 IP-in-IPカプセル化が使用されている場合、例えば、ifRcvAddressTableは、IPインIPによって定義されます。
IfEntries are defined in the MIBs 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-in-IPカプセル化[20]が使用されている場合、例えば、ifEntryのは、IPインIPによって定義されます。
The ifType of a tunnel should be set to "tunnel" (131). An entry in the IP Tunnel MIB will exist for every ifEntry with this ifType. An implementation of the IP Tunnel MIB 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トンネルMIBのエントリは、このifTypeが持つすべてのifEntryのために存在します。 IPトンネルMIBの実装はのifEntriesがtunnelConfigTableを介して作成されることを可能にします。トンネルを作成することもifTable内とtunnelIfTableにエントリを追加し、トンネルを削除すると、同様のifTableとtunnelIfTableのエントリを削除します。
The use of two different tables in this MIB 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 complicate row creation and/or cause interoperability problems (if each agent had special restrictions on ifIndex). Instead, a separate table is used which 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.
このMIBの2つの異なるテーブルを使用することは、重要な設計上の決定でした。伝統的に、ifIndex値はエージェントによって選択され、そして再起動して変更することが許可されています。 （各エージェントがifIndexのに特別な制限を持っていた場合）ifIndexによってインデックス付け、トンネルインタフェース表に直接、行の作成を許可、行作成を複雑かつ/または相互運用性の問題を引き起こします。代わりに、別のテーブルは、管理者が制御を有するその上のオブジェクトによって索引付けされている使用されています。すなわち、これらは、トンネルエンドポイントのアドレスとカプセル化プロトコルです。最後に、追加の管理者に選択されたIDは、同一のエンドポイント間の複数のトンネルを可能にするようL2Fなどのプロトコルをサポートするために、インデックスに使用されます。
TUNNEL-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, transmission, Integer32, IpAddress FROM SNMPv2-SMI RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndexOrZero FROM IF-MIB;
IF-MIBからのSNMPv2-CONFのifIndex、InterfaceIndexOrZeroのFROMのSNMPv2-TCのMODULE-COMPLIANCE FROMのSNMPv2-SMI RowStatus標準からの輸入MODULE-IDENTITY、OBJECT-TYPE、送信、Integer32の、IPアドレス、オブジェクト・グループ。
tunnelMIB MODULE-IDENTITY
LAST-UPDATED "9908241200Z" -- August 24, 1999
ORGANIZATION "IETF Interfaces MIB Working Group"
CONTACT-INFO
" Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: dthaler@dthaler.microsoft.com"
DESCRIPTION
"The MIB module for management of IP Tunnels, independent of
the specific encapsulation scheme in use."
REVISION "9908241200Z" -- August 24, 1999
DESCRIPTION
"Initial version, published as RFC 2667."
::= { transmission 131 }
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
-- the IP Tunnel MIB-Group -- -- a collection of objects providing information about -- IP Tunnels
- IPトンネルMIB-グループ - - についての情報を提供するオブジェクトの収集 - IPトンネル
tunnelIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on configured
tunnels."
::= { tunnel 1 }
tunnelIfEntry OBJECT-TYPE SYNTAX TunnelIfEntry
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 ::= SEQUENCE {
tunnelIfLocalAddress IpAddress,
tunnelIfRemoteAddress IpAddress,
tunnelIfEncapsMethod INTEGER,
tunnelIfHopLimit Integer32,
tunnelIfSecurity INTEGER,
tunnelIfTOS Integer32
}
tunnelIfLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
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."
::= { tunnelIfEntry 1 }
tunnelIfRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
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."
::= { tunnelIfEntry 2 }
tunnelIfEncapsMethod OBJECT-TYPE 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
tunnelIfEncapsMethodのOBJECT-TYPE SYNTAX INTEGER {他の（1）、 - 次のダイレクト（2）のいずれも - ない中間ヘッダGRE（3）、 - GREカプセル化最小（4）、 - 最小カプセル化L2TP（5） 、 - L2TPカプセル化PPTP（6）、 - PPTPカプセル化L2F（7）、 - L2Fカプセル化UDP（8）、 - UDPカプセル化ATMP（9） - ATMPカプセル
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel. The value
direct indicates that the packet is encapsulated directly
within a normal IPv4 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). 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."
::= { tunnelIfEntry 3 }
tunnelIfHopLimit OBJECT-TYPE
SYNTAX Integer32 (0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The TTL to use in the outer IP header. A value of 0
indicates that the value is copied from the payload's
header."
::= { tunnelIfEntry 4 }
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 for the security
protocol in use."
::= { tunnelIfEntry 5 }
tunnelIfTOS OBJECT-TYPE SYNTAX Integer32 (-2..63) MAX-ACCESS read-write
tunnelIfTOSのOBJECT-TYPE構文Integer32（-2..63）MAX-ACCESSの読み取りと書き込み
STATUS current
DESCRIPTION
"The method used to set the high 6 bits of the TOS 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. A value
between 0 and 63 inclusive indicates that the bit field is
set to the indicated value."
::= { tunnelIfEntry 6 }
tunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS current
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 destination address should have a
corresponding row in the tunnelConfigTable, regardless of
whether it was created via SNMP."
::= { tunnel 2 }
tunnelConfigEntry OBJECT-TYPE
SYNTAX TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information on a
particular configured tunnel."
INDEX { tunnelConfigLocalAddress,
tunnelConfigRemoteAddress,
tunnelConfigEncapsMethod,
tunnelConfigID }
::= { tunnelConfigTable 1 }
TunnelConfigEntry ::= SEQUENCE {
tunnelConfigLocalAddress IpAddress,
tunnelConfigRemoteAddress IpAddress,
tunnelConfigEncapsMethod INTEGER,
tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero,
tunnelConfigStatus RowStatus
}
tunnelConfigLocalAddress OBJECT-TYPE
tunnelConfigLocalAddressのOBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
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."
::= { tunnelConfigEntry 1 }
tunnelConfigRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel."
::= { tunnelConfigEntry 2 }
tunnelConfigEncapsMethod OBJECT-TYPE
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)
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelConfigEntry 3 }
tunnelConfigID 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 conflict with an existing row, such as choosing a random number."
tunnelConfigIDのOBJECT-TYPE構文Integer32（1 2147483647）MAX-ACCESSステータス現在の説明は「同じエンドポイントと、同一のカプセル化方式の複数のトンネルを区別するための識別子。カプセル化プロトコルのみにつき1つのトンネルを許可する場合（例えば、GREまたはIPインIPのような）エンドポイントアドレスのセットは、このオブジェクトの値は、複数の並列のトンネルを許す（例えばL2Fなど）カプセル化方法のための1である、マネージャはない任意のIDを選択する責任がありますそのような乱数を選択するなどの既存の行との競合。」
::= { tunnelConfigEntry 4 }
tunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
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."
::= { tunnelConfigEntry 5 }
tunnelConfigStatus 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.
tunnelConfigStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSはリード作成しますステータス現在の説明「新しいエントリが作成されるかもしれない、この行の状態、またはこの表から削除古いエントリを。エージェントは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.
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."
::= { tunnelConfigEntry 6 }
-- conformance information
- 適合情報
tunnelMIBConformance
OBJECT IDENTIFIER ::= { tunnelMIB 2 }
tunnelMIBCompliances
OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
-- compliance statements
- コンプライアンスステートメント
tunnelMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for the IP Tunnel MIB." MODULE -- this module MANDATORY-GROUPS { tunnelMIBBasicGroup }
tunnelMIBCompliance MODULE-COMPLIANCEステータス現在の説明「IPトンネルMIBのための準拠宣言。」 MODULE - このモジュールMANDATORY-GROUPS {tunnelMIBBasicGroup}
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT tunnelIfTOS MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT tunnelConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 1 }
-- units of conformance
- 適合の単位
tunnelMIBBasicGroup OBJECT-GROUP
OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress,
tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS,
tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
STATUS current
DESCRIPTION
"A collection of objects to support basic management of IP
Tunnels."
::= { tunnelMIBGroups 1 }
END
終わり
This MIB contains readable objects whose values provide information related to IP tunnel interfaces. There are also a number of objects that have a MAX-ACCESS clause of read-write and/or read-create, such as those which allow an administrator to dynamically configure tunnels.
このMIBは、その値がIPトンネルインターフェイスに関連する情報を提供可読オブジェクトが含まれています。読み書きのMAX-ACCESS句を持つオブジェクトの数もあり、および/またはリード作成し、そのような管理者が動的にトンネルを設定することを可能にするものとして。
While unauthorized access to the readable objects is relatively innocuous, unauthorized access to the write-able objects could cause a denial of service, or could cause unauthorized creation and/or manipulation of tunnels. Hence, the support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
読み込み可能なオブジェクトへの不正アクセスは比較的無害ですが、書き込み可能なオブジェクトへの不正アクセス、サービス拒否を引き起こす可能性があり、または不正の作成および/またはトンネルの操作を引き起こす可能性があります。したがって、適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。
SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec [24]), even then, there is no control as to who on the secure network is allowed to access and SET (change/create/delete) the objects in this MIB.
それ自体でSNMPv1のは、このような不安定な環境です。ネットワーク自体が安全であっても（IPSecを使用して、例えば[24]）、その後も、安全なネットワーク上でこのMIBにアクセスし、SET（変更/作成/削除）オブジェクトを許可する者のようなコントロールが全くありません。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended.
SNMPv3フレームワークで提供するように実装は、セキュリティ機能を検討することをお勧めします。具体的には、ユーザベースセキュリティモデルのRFC 2574 [12]とビューベースアクセス制御モデルRFC 2575 [15]の使用が推奨されます。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them.
このMIBへのアクセスを与えるSNMP実体が、適切にのみそれらにアクセスするための正当な権利を持っているそれらのプリンシパル（ユーザ）にそれらのオブジェクトへのアクセスを提供するように設定されていることを確実にするために、顧客/ユーザーの責任です。
This MIB module was updated based on feedback from the IETF's Interfaces MIB (IF-MIB) and Point-to-Point Protocol Extensions (PPPEXT) Working Groups.
このMIBモジュールは、IETFのインターフェイスMIB（IF-MIB）およびポイントツーポイントプロトコル拡張機能（PPPEXT）ワーキンググループからのフィードバックに基づいて更新されました。
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
デーブターラーマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
電話：+1 425 703 8835 Eメール：dthaler@microsoft.com
[1] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] Wijnenの、B.、ハリントン、D.とR. Presuhn、RFC 2571、1999年4月 "SNMP管理フレームワークを記述するためのアーキテクチャ"。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[2]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月を。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[3]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[4]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[6] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[7] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2580、1999年4月 "SMIv2のための順応文"。
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[8]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、1996年1月。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[11]ケース、J.、ハリントンD.、Presuhn R.とB. Wijnenの、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、RFC 2572、1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[12]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、RFC 2574、1999年4月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[13]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡単なネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[14]レビ、D.、マイヤー、P.およびB.スチュワート、 "SNMPv3のアプリケーション"、RFC 2573、1999年4月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[15] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、RFC 2575、1999年4月。
[16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.
[16]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 1701、1994年10月。
[17] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994.
[17]ハンクス、S.、李、T.、ファリナッチ、D.とP. Trainaの、 "IPv4ネットワーク上総称ルーティングカプセル化"、RFC 1702、1994年10月。
[18] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[18]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[19] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[19]パーキンス、C.、 "IP内の最小カプセル化"、RFC 2004、1996年10月。
[20] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[20] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ソーン、G、BのPalter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[21] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[21] Hamzeh、K.、ポール、G.、Verthein、W. Taarud、J.、リトル、W.およびG.ゾルン、 "ポイントツーポイントトンネリングプロトコル"、RFC 2637、1999年7月。
[22] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997.
[22] Hamzeh、K.、 "アセンドトンネル管理プロトコル - ATMP"、RFC 2107、1997年2月。
[23] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[23] McCloghrie、K.、およびF. Kastenholzと。 "インターフェイスグループMIBのSMIv2を使用する"、RFC 2233、1997年11月。
[24] R. Atkinson, "Security architecture for the internet protocol", RFC 2401, November 1998.
[24] R.アトキンソン、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 2401、1998年11月。
[25] Valencia, A., Littlewood, M. and T. Kolar. "Cisco Layer Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[25]バレンシア、A.、リトル、M.およびT.コーラール。 "シスコのレイヤ二フォワーディング（プロトコル） "L2F""、RFC 2341、1998年5月。
[26] D. Provan, "Tunneling IPX Traffic through IP Networks", RFC 1234, June 1991.
[26] D. Provan、 "IPネットワークを介したトンネリングIPXトラフィック"、RFC 1234、1991年6月。
[27] Gilligan, R. and E. Nordmark. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[27]ギリガン、R.およびE. Nordmarkと。 、RFC 1933、1996年4月の「IPv6ホストとルータのための変遷メカニズム」。
[28] Woodburn, R. and D. Mills, "A Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241, July 1991.
[28]ウッドバーン、R.とD.ミルズ、 "インターネットプロトコルカプセル化のためのスキーム：バージョン1"、RFC 1241、1991年7月。
[29] 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.
[29]ニコルズ、K.、ブレイク、S.、ベイカー、F.およびD.ブラック。 「IPv4とIPv6ヘッダーとの差別化サービス分野（DS分野）の定義」、RFC 2474、1998年12月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat."
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。」
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。