この文書はRFC4001の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group M. Daniele
Request for Comments: 4001 SyAM Software, Inc.
Obsoletes: 3291 B. Haberman
Category: Standards Track Johns Hopkins University
S. Routhier
Wind River Systems, Inc.
J. Schoenwaelder
International University Bremen
February 2005
Textual Conventions for Internet Network Addresses
インターネットネットワークアドレスのための文字列表記法
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Abstract
概要
This MIB module defines textual conventions to represent commonly
used Internet network layer addressing information. The intent is
that these textual conventions will be imported and used in MIB
modules that would otherwise define their own representations.
このＭＩＢモジュールは一般に使われるインターネットネットワーク層
アドレス情報を表現するための文字列表記法を定義します。意図は、そ
れぞれのＭＩＢモジュールで表記を定義するのではなく、これらのテキ
スト表記がＭＩＢモジュールに読み込まれて使われることです。
Table of Contents
目次
1. Introduction
1. はじめに
2. The Internet-Standard Management Framework
2. インターネット標準管理フレームワーク
3. Definitions
3. 定義
4. Usage Hints
4. 使用法助言
4.1. Table Indexing
4.1. 表インデックス
4.2. Uniqueness of Addresses
4.2. アドレスのユニークさ
4.3. Multiple Addresses per Host
4.3. ホスト毎の多数のアドレス
4.4. Resolving DNS Names
4.4. ＤＮＳ名解決
5. Table Indexing Example
5. 表インデックス例
6. Security Considerations
6. セキュリティの考察
7. Acknowledgments
7. 謝辞
8. Changes from RFC 3291 to RFC 4001
8. ＲＦＣ３２９１からＲＦＣ４００１への変更
9. Changes from RFC 2851 to RFC 3291
9. ＲＦＣ２８５１からＲＦＣ３２９１への変更
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
10.2. Informative References
10.2. 有益な参考文献
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
Several standards-track MIB modules use the IpAddress SMIv2 base
type. This limits the applicability of these MIB modules to IP
Version 4 (IPv4), as the IpAddress SMIv2 base type can only contain
4-byte IPv4 addresses. The IpAddress SMIv2 base type has become
problematic with the introduction of IP Version 6 (IPv6) addresses
[RFC3513].
いくつかの標準化ＭＩＢモジュールがIpAddress SMIv2ベースタイプを使
います。IpAddress SMIv2ベースタイプが４バイトのＩＰｖ４アドレスを
含むだけなので、これらのＭＩＢモジュールの適用性はＩＰバージョン４
（ＩＰｖ４）に制限されます。IpAddress SMIv2ベースタイプはバージョ
ン６（ＩＰｖ６）アドレス[RFC3513]の導入で問題が多くなりました。
This document defines multiple textual conventions (TCs) as a means
to express generic Internet network layer addresses within MIB module
specifications. The solution is compatible with SMIv2 (STD 58) and
SMIv1 (STD 16). New MIB definitions that have to express network
layer Internet addresses SHOULD use the textual conventions defined
in this memo. New MIB modules SHOULD NOT use the SMIv2 IpAddress
base type anymore.
この文書は多数の文字列表記法（TC）をＭＩＢモジュール仕様書の中で
一般的なインターネットネットワーク層アドレスを表記する手段と定義
します。解決策はSMIv2（ＳＴＤ５８）とSMIv1（ＳＴＤ１６）と互換性
があります。ネットワーク層インターネットアドレスを表記しなければ
ならない新しいＭＩＢ定義がこの文書で定義された文字列表記法を使う
べきです(SHOULD)。新しいＭＩＢモジュールがこれ以上SMIv2 IpAddress
ベースタイプを使うべきではありません(SHOULD NOT)。
A generic Internet address consists of two objects: one whose syntax
is InetAddressType, and another whose syntax is InetAddress. The
value of the first object determines how the value of the second is
encoded. The InetAddress textual convention represents an opaque
Internet address value. The InetAddressType enumeration is used to
"cast" the InetAddress value into a concrete textual convention for
the address type. This usage of multiple textual conventions allows
expression of the display characteristics of each address type and
makes the set of defined Internet address types extensible.
一般的なインターネットアドレスが２つのオブジェクトから成り立ちま
す：１つは構文がInetAddressTypeであるもので、もう一つは構文が
InetAddressであるものです。最初のオブジェクトの値は第２の値をコー
ド化する方法を決定します。InetAddress文字列表記法は不透明なインター
ネットアドレス値を表します。InetAddressType列挙はアドレスタイプの
具体的な文字列表記法にInetAddress値を「変換する」ために使われます。
この多数の文字列表記法の使用法はそれぞれのアドレスタイプの表示の
特徴の表記を許し、そして定義されたインターネットアドレスタイプ集
合を拡大可能にします。
The textual conventions for well-known transport domains support
scoped Internet addresses. The scope of an Internet address is a
topological span within which the address may be used as a unique
identifier for an interface or set of interfaces. A scope zone (or,
simply, a zone) is a concrete connected region of topology of a given
scope. Note that a zone is a particular instance of a topological
region, whereas a scope is the size of a topological region
[RFC4007]. Since Internet addresses on devices that connect multiple
zones are not necessarily unique, an additional zone index is needed
on these devices to select an interface. The textual conventions
InetAddressIPv4z and InetAddressIPv6z are provided to support
Internet addresses that include a zone index. To support arbitrary
combinations of scoped Internet addresses, MIB authors SHOULD use a
separate InetAddressType object for each InetAddress object.
よく知られているトランスポートドメインのための文字列表記法は範囲
付きインターネットアドレスをサポートします。インターネットアドレ
スの範囲はアドレスがユニークな識別子としてインタフェースあるいは
インタフェース集合で使われるトポロジ的範囲です。範囲ゾーン（ある
いは、単純に、ゾーン）が所定の範囲のトポロジ的に接続されたゾーン
です。ゾーンがトポロジ的範囲の特定の実体であるのに対して、範囲が
トポロジ的ゾーンの大きさであることに注意してください[RFC4007]。多
数のゾーンを結ぶ装置上のインターネットアドレスが必ずしも一意では
ないので、追加のゾーンインデックスがこれらの装置上でインタフェー
スを選ぶのに必要とされます。文字列表記法InetAddressIPv4zと
InetAddressIPv6zはゾーンインデックスを含むインターネットアドレス
をサポートするために供給されます。範囲付きインターネットアドレス
の任意の組合せをサポートするために、ＭＩＢ著者がそれぞれの
InetAddressオブジェクトのために別のInetAddressTypeオブジェクトを
使うべきです(SHOULD)。
The textual conventions defined in this document can also be used to
represent generic Internet subnets and Internet address ranges. A
generic Internet subnet is represented by three objects: one whose
syntax is InetAddressType, a second one whose syntax is InetAddress,
and a third one whose syntax is InetAddressPrefixLength. The
InetAddressType value again determines the concrete format of the
InetAddress value, whereas the InetAddressPrefixLength identifies the
Internet network address prefix.
この文書で定義された文字列表記法は一般的なインターネットサブネッ
トとインターネットアドレス範囲を表すために同じく使うことができま
す。一般的なインターネットサブネットが３つのオブジェクトで表され
ます：１つ目は構文がInetAddressTypeであるもので、２つ目は構文が
InetAddressであるもので、３つ目は構文がInetAddressPrefixLengthで
あるものです。InetAddressType値はInetAddress値の具体的なフォーマッ
トを決定するのに対して、InetAddressPrefixLengthはインターネット
ネットワークアドレスプレフィックスを識別します。
A generic range of consecutive Internet addresses is represented by
three objects. The first one has the syntax InetAddressType, and the
remaining objects have the syntax InetAddress and specify the start
and end of the address range. Again, the InetAddressType value
determines the format of the InetAddress values.
連続したインターネットアドレスの一般的な範囲が３つのオブジェクトに
よって表されます。最初のはInetAddressTypeの構文で、残りのオブジェ
クトはInetAddressの構文で、アドレス範囲の開始と終了を指定します。
InetAddressType値はやはりInetAddress値のフォーマットを決定します。
The textual conventions defined in this document can be used to
define Internet addresses by using DNS domain names in addition to
IPv4 and IPv6 addresses. A MIB designer can write compliance
statements to express that only a subset of the possible address
types must be supported by a compliant implementation.
この文書で定義された文字列表記法はＩＰｖ４とＩＰｖ６アドレスのほか
にＤＮＳドメイン名を使うことでインターネットアドレスを定義するため
に使うことができます。ＭＩＢ設計者は準拠実装がただ可能なアドレスタ
イプの一部だけをサポートしならないと言うために適応宣言を書くことが
できます。
MIB developers who need to represent Internet addresses SHOULD use
these definitions whenever applicable, as opposed to defining their
own constructs. Even MIB modules that only need to represent IPv4 or
IPv6 addresses SHOULD use the InetAddressType/InetAddress textual
conventions defined in this memo.
インターネットアドレスを表記する必要があるＭＩＢ開発者が、適用可
能であれば、自身の概念を定義せずに、これらの定義を使うべきです
(SHOULD)。ただＩＰｖ４あるいはＩＰｖ６アドレスの表記だけが必要な
ＭＩＢモジュールでも、この文書で定義された
InetAddressType/InetAddress文字列表記法を使うべきです(SHOULD)。。
There are many widely deployed MIB modules that use IPv4 addresses
and that have to be revised to support IPv6. These MIB modules can
be categorized as follows:
ＩＰｖ４アドレスを使い、ＩＰｖ６をサポートするために修正されなけれ
ばならない多くの広く配置されたＭＩＢモジュールがあります。これらの
ＭＩＢモジュールは次のように分類できます：
1. MIB modules that define management information that is, in
principle, IP version neutral, but the MIB currently uses
addressing constructs specific to a certain IP version.
1. 原則として、ＩＰバージョンに独立である管理情報を定義するＭＩ
Ｂモジュールであるが、あるＩＰバージョンに固有なアドレス概念
を使う概念。
2. MIB modules that define management information that is specific
to a particular IP version (either IPv4 or IPv6) and that is very
unlikely to ever be applicable to another IP version.
2. 特定のＩＰバージョン（ＩＰｖ４あるいはＩＰｖ６）に固有な管理
情報を定義し、そして他のＩＰバージョンに適用できることが非常
にありそうもないＭＩＢモジュール。
MIB modules of the first type SHOULD provide object definitions
(e.g., tables) that work with all versions of IP. In particular,
when revising a MIB module that contains IPv4 specific tables, it is
suggested to define new tables using the textual conventions defined
in this memo that support all versions of IP. The status of the new
tables SHOULD be "current", whereas the status of the old IP version
specific tables SHOULD be changed to "deprecated". The other
approach, of having multiple similar tables for different IP
versions, is strongly discouraged.
最初のタイプのＭＩＢモジュールがすべてのＩＰのバージョンで働くオ
ブジェクト定義（例えば、テーブル）を供給するべきです(SHOULD)。特
に、ＩＰｖ４固有のテーブルを含んでいるＭＩＢモジュールを修正する
時、このメモで定義されたすべてのＩＰバージョンをサポートする文字
列表記法を使う新しいテーブルを定義することを提案します。古いＩＰ
バージョン固有のテーブルが「望ましくない」に変化し(SHOULD)、新し
いテーブルの状態が「最新」にされるべきです(SHOULD)。異なるＩＰ
バージョンのために多数の類似のテーブルを持つ他の方法は、強く反対
します。
MIB modules of the second type, which are inherently IP version
specific, do not need to be redefined. Note that even in this case,
any additions to these MIB modules or to new IP version specific MIB
modules SHOULD use the textual conventions defined in this memo.
本質的に特定のＩＰバージョンに固有の２番目のタイプのＭＩＢモジュー
ルは再定義される必要がありません。この場合でも、これらのＭＩＢモ
ジュールへの、あるいは新しいＩＰバージョン固有のＭＩＢモジュール
への追加は、このメモで定義された文字列表記法を使うべき(SHOULD)で
あることに注意してください。
MIB developers SHOULD NOT use the textual conventions defined in this
document to represent generic transport layer addresses. A special
set of textual conventions for this purpose is defined in RFC 3419
[RFC3419].
ＭＩＢ開発者が一般的なトランスポートレイヤアドレスを表すために、
この文書で定義される文字列表記法を使うべきではありません(SHOULD
NOT)。この目的のための文字列表記法の特別なセットがＲＦＣ３４１９
[RFC3419]で定義されます。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY",
in this document are to be interpreted as described in RFC 2119
[RFC2119].
この文書のキーワード"MUST"と"MUST NOT"と"SHOULD"と"SHOULD NOT"と
"MAY"はＲＦＣ２１１９[RFC2119]で記述されるように解釈されるはず
です。
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].
現在のインターネット標準管理フレームワークを記述する文書の詳細な
概観のために、どうかＲＦＣ３４１０[RFC3410]の７章を参照してくださ
い。
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].
管理されたオブジェクトが仮想情報記憶装置によってアクセスされて、
管理情報ベースあるいはＭＩＢと呼ばれます。ＭＩＢオブジェクトが一
般にシンプル・ネットワーク・マネジメント・プロトコル（ＳＮＭＰ）
を通してアクセスされます。ＭＩＢのオブジェクトは管理情報構造（Ｓ
ＭＩ）で定義されたメカニズムを使って定義されます。このメモは、Ｓ
ＴＤ５８、ＲＦＣ２５７８［RFC2587］とＳＴＤ５８、ＲＦＣ２５７９
［RFC2579］とＳＴＤ５８、ＲＦＣ２５８０［RFC2580］で記述された、
ＳＭＩｖ２に準拠したＭＩＢモジュールを指定します、。
3. Definitions
3. 定義
INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
inetAddressMIB MODULE-IDENTITY
LAST-UPDATED "200502040000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
International University Bremen
P.O. Box 750 561
28725 Bremen, Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de
Send comments to <ietfmibs@ops.ietf.org>."
DESCRIPTION
"This MIB module defines textual conventions for
representing Internet addresses. An Internet
address can be an IPv4 address, an IPv6 address,
or a DNS domain name. This module also defines
textual conventions for Internet port numbers,
autonomous system numbers, and the length of an
Internet address prefix.
このＭＩＢモジュールはインターネットアドレスを表す文字列表
記法を定義します。インターネットアドレスはＩＰｖ４アドレス、
ＩＰｖ６アドレス、あるいはＤＮＳドメイン名であり得ます。こ
のモジュールはインターネットポート番号と、自律システム番号
と、インターネットアドレスプレフィックスの長さの文字列表記
法も定義します。
Copyright (C) The Internet Society (2005). This version
of this MIB module is part of RFC 4001, see the RFC
itself for full legal notices."
著作権、インターネット学会（２００５）。このこのＭＩＢモジュー
ルのバージョンはＲＦＣ４００１の一部です、完全な法律上の表
記はRFC自身を見てください。
REVISION "200502040000Z"
DESCRIPTION
"Third version, published as RFC 4001. This revision
introduces the InetZoneIndex, InetScopeType, and
InetVersion textual conventions."
ＲＦＣ４００１として出版された第３版。この修正は
InetZoneIndexとInetScopeTypeとInetVersion文字列表記法を導入
します。
REVISION "200205090000Z"
DESCRIPTION
"Second version, published as RFC 3291. This
revision contains several clarifications and
introduces several new textual conventions:
InetAddressPrefixLength, InetPortNumber,
InetAutonomousSystemNumber, InetAddressIPv4z,
and InetAddressIPv6z."
ＲＦＣ３２９１として出版された第２版。この修正はいくつかの
明確化といくつかの新しい文字列表記法を含んでいます：
InetAddressPrefixLengthとInetPortNumberと
InetAutonomousSystemNumberとInetAddressIPv4zと
InetAddressIPv6zを導入します。
REVISION "200006080000Z"
DESCRIPTION
"Initial version, published as RFC 2851."
ＲＦＣ２８５１として出版された最初の版。
::= { mib-2 76 }
InetAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of Internet address.
インターネットアドレス種別を表す値。
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding
InetAddress object is a zero-length string.
It may also be used to indicate an IP address
that is not in one of the formats defined
below.
未知のアドレス種別。もし対応するInetAddressオブ
ジェクトの値が長さゼロの文字列であるなら、この値
が使われなくてはなりません(MUST)。これは下で定義
されたフォーマットのでないＩＰアドレスを示すため
にも使われるかもしれません。
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
InetAddressIPv4文字列表記規則で定義された
ＩＰｖ４アドレス。
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
InetAddressIPv6文字列表記規則で定義された
ＩＰｖ６アドレス。
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z
textual convention.
InetAddressIPv4z文字列表記規則で定義されたゾー
ンインデックスを含む世界的でないＩＰｖ４アドレス。
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z
textual convention.
InetAddressIPv6ｚ文字列表記規則で定義されたゾー
ンインデックスを含む世界的でないＩＰｖ６アドレス。
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
InetAddressDNS文字列表記規則で定義されたＤＮＳドメイン名
。
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.
それぞれの具体的なInetAddressType値の定義は、その
InetAddressTypeと共に使う文字列表記規則の定義を伴わなくては
なりません。
To support future extensions, the InetAddressType textual
convention SHOULD NOT be sub-typed in object type definitions.
It MAY be sub-typed in compliance statements in order to
require only a subset of these address types for a compliant
implementation.
将来拡張をサポートするために、InetAddressType文字列表記規則
はオブジェクト型定義の部分型でないべきです(SHOULD NOT)。こ
れらのアドレス種別の一部だけを必要とする準拠実装で、これは
適用宣言により部分型にされるかもしれません(MAY)。
Implementations must ensure that InetAddressType objects
and any dependent objects (e.g., InetAddress objects) are
consistent. An inconsistentValue error must be generated
if an attempt to change an InetAddressType object would,
for example, lead to an undefined InetAddress value. In
particular, InetAddressType/InetAddress pairs must be
changed together if the address type changes (e.g., from
ipv6(2) to ipv4(1))."
実装はInetAddressTypeオブジェクトと依存するオブジェクト（例
えば、 InetAddressオブジェクト）が整合する事を保障しなくて
はなりません。もし InetAddressTypeオブジェクトを変える試み
が、例えば、不確定なInetAddress 値を導くなら、
inconsistentValue エラーが生成されなくてはなりません。特に、
アドレスタイプ変更で、InetAddressType/ InetAddress対が一緒
に変えられなくてはなりません（例えば、ipv6(2)からipv4(1)へ）。
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
ipv4z(3),
ipv6z(4),
dns(16)
}
InetAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Internet address.
一般的なインターネットアドレスを意味します。
An InetAddress value is always interpreted within the context
of an InetAddressType value. Every usage of the InetAddress
textual convention is required to specify the InetAddressType
object that provides the context. It is suggested that the
InetAddressType object be logically registered before the
object(s) that use the InetAddress textual convention, if
they appear in the same logical row.
InetAddress値が常にInetAddressType値によって通訳されます。
すべてのInetAddress文字列表記の使用は、InetAddressTypeオブ
ジェクトを指定するように要求されます。InetAddressTypeオブ
ジェクトは、もし同じ論理的な行に現われるなら、InetAddress
文字列表記を使うオブジェクトの前に論理的に登録されること
が提案されます。
The value of an InetAddress object must always be
consistent with the value of the associated InetAddressType
object. Attempts to set an InetAddress object to a value
inconsistent with the associated InetAddressType
must fail with an inconsistentValue error.
InetAddressオブジェクトの値は常に関連づけられた
InetAddressTypeオブジェクトの値と整合しているに違いありま
せん。InetAddressオブジェクトを関連づけられた
InetAddressTypeと一致しない値に設定する試みは
inconsistentValueエラーで失敗しなくてはなりません。
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the object definition MUST include a 'SIZE' clause to
limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate."
この文字列表記がインデックスオブジェクトの構文として用いら
れる時、SMIv2、ＳＴＤ５８で指定された１２８のサブ識別子の限
界の問題があるかもしれません。この場合、オブジェクト定義は
インスタンス副識別子の数を制限するために「大きさ」条項を含
まなくてはなりません(MUST)；さもなければ適用制約が、適切な
概念行の記述項、あるいはもし適切な記述項がないなら、あるい
は周囲の文書で述べられなくてはなりません(MUST)。
SYNTAX OCTET STRING (SIZE (0..255))
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
ＩＰｖ４ネットワークアドレス表記：
Octets Contents Encoding
オクテット 中身 コーディング。
1-4 IPv4 address network-byte order
The corresponding InetAddressType value is ipv4(1).
対応するInetAddressType値はipv4(1)です。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
この文字列表記は、特定のフォーマットにアドレスを限定するから、
オブジェクト定義で直接使われるべきではありません(SHOULD NOT)。
しかしながら、もしこれが使われるなら、これはこれ自身あるいは
InetAddressTypeと関連して、１対として使われるかもしれません
(MAY)。
SYNTAX OCTET STRING (SIZE (4))
InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
STATUS current
DESCRIPTION
"Represents an IPv6 network address:
ＩＰｖ６ネットワークアドレスの表記：
Octets Contents Encoding
オクテット 内容 コーディング
1-16 IPv6 address network-byte order
The corresponding InetAddressType value is ipv6(2).
対応するInetAddressType値はipv6(2)です。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
この文字列表記は、特定のフォーマットにアドレスを限定するから、
オブジェクト定義で直接使われるべきではありません。しかしなが
ら、もしこれが使われるなら、これ自身あるいはInetAddressType
と関連して、１対として使われるかもしれません(MAY)。
SYNTAX OCTET STRING (SIZE (16))
InetAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv4 network address, together
with its zone index:
世界的でないＩＰｖ４ネットワークアドレスを、そのゾーンイン
デックスと共に、表します：
Octets Contents Encoding
オクテット 内容 コーディング
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
The corresponding InetAddressType value is ipv4z(3).
対応するInetAddressType値はipv4z(3)です。
The zone index (bytes 5-8) is used to disambiguate identical
address values on nodes that have interfaces attached to
different zones of the same scope. The zone index may contain
the special value 0, which refers to the default zone for each
scope.
ゾーンインデックス（バイト５-８）は同じ範囲の異なるゾーンのイン
タフェースを持つノード上で同一のアドレス値のあいまいさを排除す
るために使われます。ゾーンインデックスは特別な値０を含んでいる
かもしれず、そしてこれはそれぞれの範囲のデフォルトゾーンを参照
します。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
この文字列表記は、特定のフォーマットにアドレスを限定するから、
オブジェクト定義で直接使われるべきではありません。しかしなが
ら、もしこれが使われるなら、これ自身あるいはInetAddressType
と関連して、１対として使われるかもしれません(MAY)。
SYNTAX OCTET STRING (SIZE (8))
InetAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv6 network address, together
with its zone index:
世界的でないＩＰｖ６ネットワークアドレスを、そのゾーンイン
デックスと共に、表します：
Octets Contents Encoding
オクテット 内容 コーディング
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
The corresponding InetAddressType value is ipv6z(4).
対応するInetAddressType値はipv6z(4)です。
The zone index (bytes 17-20) is used to disambiguate
identical address values on nodes that have interfaces
attached to different zones of the same scope. The zone index
may contain the special value 0, which refers to the default
zone for each scope.
ゾーンインデックス（バイト１７-２０）は同じ範囲の異なるゾーンの
インタフェースを持つノード上で同一のアドレス値のあいまいさを排
除するために使われます。ゾーンインデックスは特別な値０を含んで
いるかもしれず、そしてこれはそれぞれの範囲のデフォルトゾーンを
参照します。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
この文字列表記は、特定のフォーマットにアドレスを限定するから、
オブジェクト定義で直接使われるべきではありません。しかしなが
ら、もしこれが使われるなら、これ自身あるいはInetAddressType
と関連して、１対として使われるかもしれません(MAY)。
SYNTAX OCTET STRING (SIZE (20))
InetAddressDNS ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents a DNS domain name. The name SHOULD be fully
qualified whenever possible.
ＤＮＳドメイン名を表します。名前は、可能である時はいつでも、完
全指定に限定されるべきです(SHOULD)。
The corresponding InetAddressType is dns(16).
対応するInetAddressType値はdns(16)です。
The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when)
these names are to be resolved to IP addresses.
InetAddressDNS値を持つかもしれないInetAddressオブジェクトの記述
項は、名前がどのように（いつ）ＩＰアドレスに変換されるか完全に
記述しなくてはなりません(MUST)。
The resolution of an InetAddressDNS value may require to
query multiple DNS records (e.g., A for IPv4 and AAAA for
IPv6). The order of the resolution process and which DNS
record takes precedence depends on the configuration of the
resolver.
InetAddressDNS値の解決は多数のＤＮＳレコードを問合せるかもしれ
ません（例えば、ＩＰｖ４のＡとＩＰｖ６のＡＡＡＡ）。解決処理の
順序とどのＤＮＳレコードが優先となるかは、リゾルバ設定に依存し
ます。
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
この文字列表記は、特定のフォーマットにアドレスを限定するから、
オブジェクト定義で直接使われるべきではありません。しかしなが
ら、もしこれが使われるなら、これ自身あるいはInetAddressType
と関連して、１対として使われるかもしれません(MAY)。
SYNTAX OCTET STRING (SIZE (1..255))
InetAddressPrefixLength ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Denotes the length of a generic Internet network address
prefix. A value of n corresponds to an IP address mask
that has n contiguous 1-bits from the most significant
bit (MSB), with all other bits set to 0.
一般的なインターネットネットワークアドレスプレフィックス長を意
味します。ｎの値はＩＰアドレスマスクに対応し、最上位ビット（MSB）
からのn個の連続する1のビットと、他は0のビットです。
An InetAddressPrefixLength value is always interpreted within
the context of an InetAddressType value. Every usage of the
InetAddressPrefixLength textual convention is required to
specify the InetAddressType object that provides the
context. It is suggested that the InetAddressType object be
logically registered before the object(s) that use the
InetAddressPrefixLength textual convention, if they appear
in the same logical row.
InetAddressPrefixLength値が常にInetAddressType値に依存して通訳
されます。すべてのInetAddressPrefixLength文字列表記の使用法は、
InetAddressTypeオブジェクトの指定を要求します。InetAddressType
オブジェクトは、もしそれらが同じ論理的な行に現われるなら、
InetAddressPrefixLength文字列表記を使うオブジェクトの前に論理的
に登録されることが提案されます。
InetAddressPrefixLength values larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
for the InetAddressType 'dns(16)' is 0.
特定のInetAddressTypeで指定されるＩＰアドレスの最大長さより大き
いInetAddressPrefixLength値は、InetAddressTypeに適用可能な最大
値として取り扱われます。最大値は、InetAddressTypeの'ipv4(1)'と
'ipv4z(3)'で３２で、InetAddressType'ipv6(2)'と'ipv6z(4)'で
１２８です。InetAddressTypeの'dns(16)'の最大値は０です。
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where the Internet network address prefix
is unknown or does not apply.
ゼロ値はオブジェクト固有で、そしてこの構文を使うオブジェクトで
記述の一部と定義されなくてはなりません。ゼロの使用法は、例えば、
インターネットネットワークアドレスプレフィックスが未知であるか、
あるいは適用されない状態を含むかもしれません。
The upper bound of the prefix length has been chosen to
be consistent with the maximum size of an InetAddress."
プレフィックス長の上限は、InetAddressの最大の大きさと整合するよ
うに選ばれました。
SYNTAX Unsigned32 (0..2040)
InetPortNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents a 16 bit port number of an Internet transport
layer protocol. Port numbers are assigned by IANA. A
current list of all assignments is available from
<http://www.iana.org/>.
インターネットトランスポート層プロトコルの１６ビットのポート番
号を表します。ポート番号がＩＡＮＡによって割り当てられます。す
べての割当の現在のリストが<http://www.iana.org/>で利用可能です。
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where a port number is unknown, or when the
value zero is used as a wildcard in a filter."
ゼロの値はオブジェクト固有であり、そしてこの構文を使うどんなオ
ブジェクトも記述の一部で定義しなくてはなりません。ゼロの使用例
はポート番号ゼロが未知、あるいはフィルタのワイルドカードとして
用いらる事です。
REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
SYNTAX Unsigned32 (0..65535)
InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents an autonomous system number that identifies an
Autonomous System (AS). An AS is a set of routers under a
single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS,
and using an exterior gateway protocol to route packets to
other ASes'. IANA maintains the AS number space and has
delegated large parts to the regional registries.
自律システム（AS）を識別する自律システム番号を表します。ASは単一
の技術的管理下のルータの集合で、ASの中でパケットの経路を決める
ために内部ゲートウェイプロトコルと共通の測定量を使い、そして他
のASにパケットの経路を決めるために外部ゲートウェイプロトコルを
使います。ＩＡＮＡはAS番号空間を維持し、そして地域の登記所に大
きい部分を委任しました。
Autonomous system numbers are currently limited to 16 bits
(0..65535). There is, however, work in progress to enlarge the
autonomous system number space to 32 bits. Therefore, this
textual convention uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space."
自律システム番号は現在１６ビットに限定されています（０〜
６５５３５）。しかしながら、３２ビットに自律システム番号空間を
大きくする実行中の仕事があります。それ故に、この文字列表記はよ
り大きい自律システム番号空間をサポートするための範囲制限無しの
Unsigned32値を使います。
REFERENCE "RFC 1771, RFC 1930"
SYNTAX Unsigned32
InetScopeType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a scope type. This textual convention can be used
in cases where a MIB has to represent different scope types
and there is no context information, such as an InetAddress
object, that implicitly defines the scope type.
範囲種別を表します。この文字列表記は、ＭＩＢが異なる範囲種別を
表さなければならないが、そして暗黙のうちに範囲種別をする、
InetAddressオブジェクトのような、周囲情報がない所で使うことが
できます。
Note that not all possible values have been assigned yet, but
they may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values
not yet assigned."
すべての可能な値が既に割り当てられたわけではないく、この仕様書
の将来の修正で割り当てられるかもしれないことに注意してください。
従ってアプリケーションがまだ割り当てられていない値を扱うことが
可能であるべきです。
REFERENCE "RFC 3513"
SYNTAX INTEGER {
-- reserved(0),
interfaceLocal(1),
linkLocal(2),
subnetLocal(3),
adminLocal(4),
siteLocal(5), -- site-local unicast addresses
-- have been deprecated by RFC 3879
-- サイトローカルユニキャストアドレ
-- スがＲＦＣ３８７９によって望まし
-- くななりました。
-- unassigned(6),
-- unassigned(7),
organizationLocal(8),
-- unassigned(9),
-- unassigned(10),
-- unassigned(11),
-- unassigned(12),
-- unassigned(13),
global(14)
-- reserved(15)
}
InetZoneIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A zone index identifies an instance of a zone of a
specific scope.
ゾーンインデックスが特定の範囲のゾーンの実体を識別します。
The zone index MUST disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index (ifIndex as defined in the
IF-MIB) of the interface on which the address is configured.
ゾーンインデックスは同一のアドレス値のあいまいさを排除しなくて
はなりません(MUST)。リンクローカルアドレスで、ゾーンインデック
スは典型的にアドレスが配置されるインタフェースのインタフェース
インデックス（IF-MIBで定義されたifIndex）であるでしょう。
The zone index may contain the special value 0, which refers
to the default zone. The default zone may be used in cases
where the valid zone index is not known (e.g., when a
management application has to write a link-local IPv6
address without knowing the interface index value). The
default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address
is known."
ゾーンインデックスは特別な値0を含むかもしれず、そしてこれはデ
フォルトゾーンを参照します。デフォルトゾーンは正当なゾーンイン
デックスが知られていない場合に使われるかもしれません（例えば、
管理アプリケーションがインタフェースインデックス値を知らないで
リンクローカルＩＰｖ６アドレスを書かなければならない時）。デ
フォルトゾーンはグローバルでないＩＰｖ６アドレスでゾーンイン
デックスが知られている場合に、簡略化のために用いられるべきでは
ありません(SHOULD NOT)。
REFERENCE "RFC4007"
SYNTAX Unsigned32
InetVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value representing a version of the IP protocol.
ＩＰプロトコルのバージョンを表している値。
unknown(0) An unknown or unspecified version of the IP
protocol.
ＩＰプロトコルバージョンが未知か特定されていない。
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ＲＦＣで７９１（ＳＴＤ５）を定義されたＩＰｖ４プロ
トコル。
ipv6(2) The IPv6 protocol as defined in RFC 2460.
ＲＦＣ２４６０で定義されたＩＰｖ６プロトコル。
Note that this textual convention SHOULD NOT be used to
distinguish different address types associated with IP
protocols. The InetAddressType has been designed for this
purpose."
この文字列表記がＩＰプロトコルと結び付けられた異なるアドレスタ
イプを区別するために使われるべきではないことに注意してくださ
い(SHOULC NOT)。InetAddressTypeはこの目的のために設計されました。
REFERENCE "RFC 791, RFC 2460"
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2)
}
END
4. Usage Hints
4. 使用法助言
The InetAddressType and InetAddress textual conventions have been
introduced to avoid over-constraining an object definition by the use
of the IpAddress SMI base type, which is IPv4 specific. An
InetAddressType/InetAddress pair can represent IP addresses in
various formats.
InetAddressTypeとInetAddress文字列表記法は、ＩＰｖ４固有のIpAddress
SMIベースタイプの使用によってオブジェクト定義を過度に制限するのを避け
るために導入されました。InetAddressType/InetAddress対が様々なフォー
マットでＩＰアドレスの表現をすることができます。
The InetAddressType and InetAddress objects SHOULD NOT be sub-typed
in object definitions. Sub-typing binds the MIB module to specific
address formats, which may cause serious problems if new address
formats need to be introduced. Note that it is possible to write
compliance statements indicating that only a subset of the defined
address types must be implemented to be compliant.
InetAddressTypeとInetAddressオブジェクトはオブジェクト定義でサブタイ
プにされるべきではありません(SHOULD NOT)。サブタイプが特定のアドレス
フォーマットにＭＩＢモジュールを束縛し、そしてこれは新しいアドレス
フォーマットが導入される必要がある場合に重大な問題を起こします。ただ
定義されたアドレスタイプの部分集合だけが準拠実装で実行されなくてはな
らないことを示す適用宣言を書くことが可能であることに注意してください。
Every usage of the InetAddress or InetAddressPrefixLength textual
conventions must specify which InetAddressType object provides the
context for the interpretation of the InetAddress or
InetAddressPrefixLength textual convention.
すべてのInetAddressあるいはInetAddressPrefixLength文字列表記法の使用
は、どのInetAddressTypeオブジェクトがInetAddressあるいは
InetAddressPrefixLength文字列表記の解釈を提供するか明示しなくてはな
りません。
It is suggested that the InetAddressType object is logically
registered before the object(s) that use(s) the InetAddress or
InetAddressPrefixLength textual convention. An InetAddressType
object is logically registered before an InetAddress or
InetAddressPrefixLength object if it appears before the InetAddress
or InetAddressPrefixLength object in the conceptual row (which
includes any index objects). This rule allows programs such as MIB
compilers to identify the InetAddressType of a given InetAddress or
InetAddressPrefixLength object by searching for the InetAddressType
object, which precedes an InetAddress or InetAddressPrefixLength
object.
InetAddressTypeオブジェクトは、InetAddressあるいは
InetAddressPrefixLength文字列表記を使うオブジェクトの前に論理的に登
録されることが提案されます。InetAddressTypeオブジェクトは、もしそれ
が（インデックスオブジェクトを含む）概念的な行でInetAddressあるいは
InetAddressPrefixLengthオブジェクトの前に現われるなら、InetAddress
あるいはInetAddressPrefixLengthオブジェクトの前に論理的に登録されま
す。この規則はＭＩＢコンパイラのようなプログラムにInetAddressTypeオ
ブジェクトを捜すことによって特定のInetAddressあるいは
InetAddressPrefixLengthオブジェクトのInetAddressTypeを識別すること
を許し、そしてこれはInetAddressあるいはInetAddressPrefixLengthオブ
ジェクトより先に起こります。
4.1. Table Indexing
4.1. 表インデックス
When a generic Internet address is used as an index, both the
InetAddressType and InetAddress objects MUST be used. The
InetAddressType object MUST be listed before the InetAddress object
in the INDEX clause.
一般的なインターネットアドレスがインデックスとして用いられる時、
InetAddressTypeとInetAddressオブジェクトの両方が使われなくてはなりま
せん(MUST)。InetAddressTypeオブジェクトはインデックス項でInetAddress
オブジェクトの前にリストアップされなくてはなりません(MUST)。
The IMPLIED keyword MUST NOT be used for an object of type
InetAddress in an INDEX clause. Instance sub-identifiers are then of
the form T.N.O1.O2...On, where T is the value of the InetAddressType
object, O1...On are the octets in the InetAddress object, and N is
the number of those octets.
IMPLIEDキーワードはインデックス項でInetAddressのオブジェクト種別のた
めに使われてはなりません(MUST NOT)。ＴがInetAddressTypeオブジェクト
の値で、O1〜Onが InetAddressオブジェクトのオクテットで、Nがそれらの
オクテット数とすると、副識別子の実体はT.N.O1.O2...On形式です。
There is a meaningful lexicographical ordering to tables indexed in
this fashion. Command generator applications may look up specific
addresses of known type and value, issue GetNext requests for
addresses of a single type, or issue GetNext requests for a specific
type and address prefix.
この形式で表のインデックスに有意義な論理順序があります。コマンド生成
アプリケーションが周知のタイプと値の特定のアドレスを調べて、ひとつの
タイプのアドレスのGetNext要求、あるいは特定のタイプとアドレスプレ
フィックスのGetNext要求を発行するかもしれません。
4.2. Uniqueness of Addresses
4.2. アドレスのユニークさ
IPv4 addresses were intended to be globally unique, current usage
notwithstanding. IPv6 addresses were architected to have different
scopes and hence uniqueness [RFC3513]. In particular, IPv6 "link-
local" unicast addresses are not guaranteed to be unique on any
particular node. In such cases, the duplicate addresses must be
configured on different interfaces. So the combination of an IPv6
address and a zone index is unique [RFC4007].
ＩＰｖ４アドレスが、現在の使用法にかかわらず、世界的規模でユニークで
あるように意図されました。ＩＰｖ６アドレスが異なる範囲とそれ故異なる
ユニークさを持つために設計されました[RFC3513]。特に、ＩＰｖ６「リンク
ローカル」ユニキャストアドレスがどんなノード上でもユニークであること
を保証されません。このような場合、重複アドレスは異なるインタフェース
上で配置できなくてはなりません。それでＩＰｖ６アドレスとゾーンインデッ
クスの組合せがユニークです[RFC4007]。
The InetAddressIPv6 textual convention has been defined to represent
global IPv6 addresses and non-global IPv6 addresses in cases where no
zone index is needed (e.g., on end hosts with a single interface).
The InetAddressIPv6z textual convention has been defined to represent
non-global IPv6 addresses in cases where a zone index is needed
(e.g., a router connecting multiple zones). Therefore, MIB designers
who use InetAddressType/InetAddress pairs do not need to define
additional objects in order to support non-global addresses on nodes
that connect multiple zones.
InetAddressIPv6文字列表記はグローバルＩＰｖ６アドレスとゾーンインデッ
クスが必要ない場合（例えば、エンドホスト上にひとつのインタフェース）
の非グローバルＩＰｖ６アドレスを表現するように定義されました。
InetAddressIPv6z文字列表記はゾーンインデックスが必要な場合（例えば、
多数のゾーンを結んでいるルータ）の非グローバルＩＰｖ６アドレスを表現
するように定義されました。それ故に、 InetAddressType/InetAddress対を
使うＭＩＢデザイナが多数のゾーンを結ぶノード上で非グローバルアドレス
をサポートするために追加のオブジェクトを定義する必要がありません。
The InetAddressIPv4z is intended for use in MIB modules (such as the
TCP-MIB) which report addresses in the address family used on the
wire, but where the entity instrumented obtains these addresses from
applications or administrators in a form that includes a zone index,
such as v4-mapped IPv6 addresses.
InetAddressIPv４zはワイヤ上のアドレスファミリを報告する、しかしＶ４マッ
プＩＰｖ６アドレスのような、ゾーンインデックスを含む形式でアプリケー
ションあるいは管理者からこれらのアドレスを得る、（ＴＣＰ−ＭＩＢのよ
うな）ＭＩＢモジュールでの使用を意図しました。
The size of the zone index has been chosen so that it is consistent
with (i) the numerical zone index, defined in [RFC4007], and (ii) the
sin6_scope_id field of the sockaddr_in6 structure, defined in RFC
2553 [RFC2553].
ゾーンインデックスの大きさは、(i)[RFC4007]で定義された数値ゾーンイン
デックスと、(ii)ＲＦＣ２５５３[RFC2553]で定義されたsockaddr_in6構造
体のsin6_scope_idフィールドと整合するように選択されなければなりませ
ん。
4.3. Multiple Addresses per Host
4.3. ホスト毎の多数のアドレス
A single host system may be configured with multiple addresses (IPv4
or IPv6), and possibly with multiple DNS names. Thus it is possible
for a single host system to be accessible by multiple
InetAddressType/InetAddress pairs.
一つのホストシステムが多数のアドレス（ＩＰｖ４あるいはＩＰｖ６）と、
そして多分多数のＤＮＳ名で構成を設定されるかもしれません。それで一つ
のホストシステムが多数のInetAddressType/InetAddress対によってアクセス
可能であることは可能です。
If this could be an implementation or usage issue, the DESCRIPTION
clause of the relevant objects must fully describe which address is
reported in a given InetAddressType/InetAddress pair.
もしこれが実装あるいは使用法上の問題であり得るなら、適切なオブジェク
トの記述項は完全にどのアドレスが所定の InetAddressType/InetAddress対
で報告されるか記述しなくてはなりません。
4.4. Resolving DNS Names
4.4. ＤＮＳ名解決
DNS names MUST be resolved to IP addresses when communication with
the named host is required. This raises a temporal aspect to
defining MIB objects whose value is a DNS name: When is the name
translated to an address?
名指されたホストと通信が必要とされる時、ＤＮＳ名がＩＰアドレスに変換
されなくてはなりません(MUST)。これは値がＤＮＳ名であるＭＩＢオブジェ
クトを定義することに対し時間の面を問題にします：いつ名前はアドレスに
翻訳されますか？
For example, consider an object defined to indicate a forwarding
destination, and whose value is a DNS name. When does the forwarding
entity resolve the DNS name? Each time forwarding occurs, or just
once when the object was instantiated?
例えば、オブジェクトが転送の宛先を示すために定義されると考えます、そ
してどの値がＤＮＳ名ですか。いつ転送エンティティーはＤＮＳ名を変換し
ますか？転送が起こるたびに、あるいはオブジェクトが実体化した時ですか？
The DESCRIPTION clause of these objects SHOULD precisely define how
and when any required name to address resolution is done.
これらのオブジェクトの記述項は正確にどのように、そしていつ、必要され
た名前が解決されるか定義するべきです(SHOULD)。
Similarly, the DESCRIPTION clause of these objects SHOULD precisely
define how and when a reverse lookup is being done, if an agent has
accessed instrumentation that knows about an IP address, and if the
MIB module or implementation requires it to map the IP address to a
DNS name.
同様に、もしエージェントがＩＰアドレスを知っている相手にアクセスした
ら、そしてもしＭＩＢモジュールあるいは実装がＩＰアドレスをＤＮＳ名に
変換するように要求されるなら、これらのオブジェクトの記述項は正確にど
のように、そしていつ逆検索がされるか定義するべきです(SHOULD)。
5. Table Indexing Example
5. 表インデックス例
This example shows a table listing communication peers that are
identified by either an IPv4 address, an IPv6 address, or a DNS name.
The table definition also prohibits entries with an empty address
(whose type would be "unknown"). The size of a DNS name is limited
to 64 characters in order to satisfy OID length constraints.
この例はＩＰｖ４アドレス、ＩＰｖ６アドレス、あるいはＤＮＳ名によって
識別される通信相手をリストアップする表を示します。表定義は（そのタイ
プが「未知である」である）空のアドレスを禁止します。ＤＮＳ名の大きさ
はOID長さ制約を満足させるために６４の文字に制限されます。
peerTable OBJECT-TYPE
SYNTAX SEQUENCE OF PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of communication peers."
通信相手リスト
::= { somewhere 1 }
peerEntry OBJECT-TYPE
SYNTAX PeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing information about a particular peer."
特定の相手の情報を含んでいる項目
INDEX { peerAddressType, peerAddress }
::= { peerTable 1 }
PeerEntry ::= SEQUENCE {
peerAddressType InetAddressType,
peerAddress InetAddress,
peerStatus INTEGER
}
peerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of Internet address by which the peer
is reachable."
相手に到達可能なインターネットアドレスの種別。
::= { peerEntry 1 }
peerAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..64))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet address for the peer. The type of this
address is determined by the value of the peerAddressType
object. Note that implementations must limit themselves
to a single entry in this table per reachable peer.
The peerAddress may not be empty due to the SIZE
restriction.
相手のインターネットアドレス。このアドレス種別はpeerAddressType
オブジェクトの値によって決定されます。実装がこの表で到達可能な
相手毎にひとつの項目に制限しなくてはならないことに注意してくだ
さい。peerAddressは大きさ制限のために空ではないかもしれません。
If a row is created administratively by an SNMP
operation and the address type value is dns(16), then
the agent stores the DNS name internally. A DNS name
lookup must be performed on the internally stored DNS
name whenever it is being used to contact the peer.
もし列がSNMPオペレーションによって管理的に作られ、そしてアドレ
スタイプ値がdns(16)であるなら、エージェントは内部にＤＮＳ名を保
存します。ＤＮＳ名前検索が、相手と連絡を取るために使われている
時はいつも、内部に保存されたＤＮＳ名に対して行われなくてはなり
ません。
If a row is created by the managed entity itself and
the address type value is dns(16), then the agent
stores the IP address internally. A DNS reverse lookup
must be performed on the internally stored IP address
whenever the value is retrieved via SNMP."
もし列が管理された項目自身によって作られ、そしてアドレスタイプ
値がdns(16)であるなら、エージェントは内部にＩＰアドレスを保存し
ます。値がSNMPによって検索される時は、ＤＮＳ逆検索が内部に保存
されたＩＰアドレス上に行われなくてはなりません。
::= { peerEntry 2 }
The following compliance statement specifies that compliant
implementations need only support IPv4/IPv6 addresses without zone
indices. Support for DNS names or IPv4/IPv6 addresses with zone
indices is not required.
次の適用宣言は準拠実装がゾーンインデックス無しでただＩＰｖ４／ＩＰｖ
６アドレスだけのサポートを必要とすることを明示します。ＤＮＳ名あるい
はゾーンインデックスを持っているＩＰｖ４／ＩＰｖ６アドレスに対するサ
ポートが必要とされません。
peerCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement of the peer MIB."
ピアＭＩＢの適用宣言。
MODULE -- this module
MANDATORY-GROUPS { peerGroup }
OBJECT peerAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2) }
DESCRIPTION
"An implementation is only required to support IPv4
and IPv6 addresses without zone indices."
実装がただゾーンインデックスなしでＩＰｖ４とＩＰｖ６アドレス
をサポートするように要求されるだけです。
::= { somewhere 2 }
Note that the SMIv2 does not permit inclusion of objects that are not
accessible in an object group (see section 3.1 in STD 58, RFC 2580
[RFC2580]). It is therefore not possible to refine the syntax of
auxiliary objects that are not accessible. It is suggested that the
refinement be expressed informally in the DESCRIPTION clause of the
MODULE-COMPLIANCE macro invocation.
ＳＭＩｖ２がオブジェクトグループでアクセス可能でないオブジェクトの包
含を認めないことに注意してください（ＳＴＤ５８、ＲＦＣ２５８０
[RFC2580]の３.１章を見てください）。アクセス可能でない補助オブジェク
トの構文を精製することはそれ故に可能ではありません。モジュール遵守マ
クロ実施の記述項で改善が非公式に表現されることは提案されます。
6. Security Considerations
6. セキュリティの考察
This module does not define any management objects. Instead, it
defines a set of textual conventions which may be used by other MIB
modules to define management objects.
このモジュールは管理オブジェクトを定義しません。その代わりに、これは
管理オブジェクトを定義するために他のＭＩＢモジュールによって使われる
かもしれない文字列表記法の集合を定義します。
Meaningful security considerations can only be written in the MIB
modules that define management objects. This document has therefore
no impact on the security of the Internet.
有意義なセキュリティの考察はただマネージメントオブジェクトを定義する
ＭＩＢモジュールでだけ書くことができます。この文書はインターネットの
セキュリティにそれ故に影響を持っていません。
7. Acknowledgments
7. 謝辞
This document was produced by the Operations and Management Area
"IPv6MIB" design team. For their comments and suggestions, the
authors would like to thank Fred Baker, Randy Bush, Richard Draves,
Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Mike Heard, Tim
Jenkins, Allison Mankin, Glenn Mansfield, Keith McCloghrie, Thomas
Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew
Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill.
この文書はオペレーションとマネージメントエリア「IPv6MIB」設計チームに
よって作り出されました。コメントと示唆に対して著者はFred BakerとRandy
BushとRichard DravesとMark EllisonとBill FennerとJun-ichiro Haginoと
Mike HeardとTim JenkinsとAllison MankinとGlenn MansfieldとKeith
McCloghrieとThomas NartenとErik NordmarkとPeder Chr. NorgaardとRandy
PresuhnとAndrew SmithとDave ThalerとKenneth WhiteとBert WijnenとBrian
Zillに感謝ます。
8. Changes from RFC 3291 to RFC 4001
8. ＲＦＣ３２９１からＲＦＣ４００１への変更
The following changes have been made relative to RFC 3291:
ＲＦＣ３２９１と比較して次の変更がされました：
o Added a range restriction to the InetAddressPrefixLength textual
convention.
o InetAddressPrefixLength文字列表記に範囲制限を加えました。
o Added new textual conventions InetZoneIndex, InetScopeType, and
InetVersion.
o 新しい文字列表記法 InetZoneIndexとInetScopeTypeとInetVersionを加え
ました。
o Added explicit "d" DISPLAY-HINTs for textual conventions that did
not have them.
o 文字列表記法のために明示的な「ｄ」表示助言を加えました。
o Updated boilerplate text and references.
o 決まり文句の文と参考文献を更新しました。
9. Changes from RFC 2851 to RFC 3291
9. ＲＦＣ２８５１からＲＦＣ３２９１への変更
The following changes have been made relative to RFC 2851:
次の変更がＲＦＣ２８５１と比較してされました：
o Added new textual conventions InetAddressPrefixLength,
InetPortNumber, and InetAutonomousSystemNumber.
o 新しい文字列表記法InetAddressPrefixLengthとInetPortNumberと
InetAutonomousSystemNumberを加えました。
o Rewrote the introduction to say clearly that, in general, one
should define MIB tables that work with all versions of IP. The
other approach of multiple tables for different IP versions is
strongly discouraged.
o 一般に、すべてのＩＰのバージョンで作動するＭＩＢテーブルを定義する
べきであると明らかに言うために、はじめにを書き直しました。異なる
ＩＰバージョンのために複数の表を作る方法は強く反対です。
o Added text to the InetAddressType and InetAddress descriptions
requiring that implementations must reject set operations with an
inconsistentValue error if they lead to inconsistencies.
o 実装が、もし矛盾が導かれるならinconsistentValueエラーで設定オペレー
ションを拒絶しなくてはならないことを要求するように、
InetAddressTypeとInetAddress記述に文章を追加。
o Removed the strict ordering constraints. Description clauses now
must explain which InetAddressType object provides the context for
an InetAddress or InetAddressPrefixLength object.
o 厳密な順序の制約を取り除きました。記述条項はどのInetAddressTypeオ
ブジェクトがInetAddressあるいはInetAddressPrefixLengthオブジェクト
に状況を提供するか説明しなくてはなりません。
o Aligned wordings with the IPv6 scoping architecture document.
o ＩＰｖ６範囲体系文書と言葉をそろえました。
o Split the InetAddressIPv6 textual convention into the two textual
conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced
a new textual convention InetAddressIPv4z. Added ipv4z(3) and
ipv6z(4) named numbers to the InetAddressType enumeration.
Motivations for this change: (i) to enable the introduction of a
textual conventions for non-global IPv4 addresses, (ii) alignment
with the textual conventions for transport addresses, (iii)
simpler compliance statements in cases where support for IPv6
addresses with zone indices is not required, and (iv) to simplify
implementations for host systems that will never have to report
zone indices.
o InetAddressIPv6文字列表記を２つの文字列表記（InetAddressIPv6と
InetAddressIPv6z）に分け、そして新しい文字列表記InetAddressIPv4zを
導入しました。InetAddressType列挙にipv4z(3)とipv6z(4)の名前番号を
加えました。これの動機が変化します：(i)世界的でないＩＰｖ４アドレ
スの文字列表記法の導入を可能にするために、(ii)トランスポートアドレ
スのために文字列表記法の割当、(iii)ゾーンインデックスが必要でない
ＩＰｖ６アドレスに対するサポートがある場合のより単純な適用宣言、そ
して、(iv)ゾーンインデックスを報告しなくてもよいホストシステムの実
装を単純化するために。
10. References
10. 参考文献
10.1. Normative References
10.1. 参照する参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
February 2005.
10.2. Informative References
10.2. 有益な参考文献
[RFC2553] Gilligan, R., Thomson, S., Bound, J., and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for
Transport Addresses", RFC 3419, December 2002.
Authors' Addresses
著者のアドレス
Michael Daniele
SyAM Software, Inc.
1 Chestnut St, Suite 3-I
Nashua, NH 03060
USA
Phone: +1 603 598-9575
EMail: michael.daniele@syamsoftware.com
Brian Haberman
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723-6099
USA
Phone: +1-443-778-1319
EMail: brian@innovationslab.net
Shawn A. Routhier
Wind River Systems, Inc.
500 Wind River Way
Alameda, CA 94501
USA
Phone: +1 510 749-2095
EMail: shawn.routhier@windriver.com
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2005).
著作権（Ｃ）インターネット学会（２００４）。
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そしてこ
の中に明らかにされる以外は著者がすべての権利を維持します。
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、全ての保証を拒否します。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC's procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＩＳＯＣのＩＳＯＣ文書の権利
に関する手続きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/iprにあるＩＥＴＦオンラインＩＰＲ
貯蔵庫で得られます。
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかietf-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。