Network Working Group M. Daniele
Request for Comments: 3419 Consultant
Category: Standards Track J. Schoenwaelder
TU Braunschweig
December 2002
Textual Conventions for Transport 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6.
この文書は、一般的に使用されるトランスポート層アドレス情報を表現するテキストの表記法を定義する管理情報ベース（MIB）モジュールを導入します。定義は、管理情報バージョン2（SMIv2）の構造によって導入TAddress /のTDomainペアの概念と互換性があり、IPv4とIPv6の上のインターネット・トランスポート・プロトコルをサポートしています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . 2
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Relationship to Other MIBs . . . . . . . . . . . . . . . . . 4
3.1.1 SNMPv2-TC (TAddress, TDomain) . . . . . . . . . . . . . . . 4
3.1.2 SNMPv2-TM . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
8. Intellectual Property Notice . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Several MIB modules need to represent transport-layer addresses in a generic way. Typical examples are MIBs for application protocols that can operate over several different transports or application management MIBs that need to model generic communication endpoints.
いくつかのMIBモジュールは、一般的な方法でトランスポート層アドレスを表現する必要があります。典型的な例は、一般的な通信エンドポイントをモデル化する必要があるいくつかの異なるトランスポートまたはアプリケーション管理のMIB上で動作できるアプリケーションプロトコルのためのMIBです。
The SMIv2 in STD 58, RFC 2579 [RFC2579] defines the textual conventions TDomain and TAddress to represent generic transport layer endpoints. A generic TAddress value is interpreted in a given transport domain which is identified by a TDomain value. The TDomain is an object identifier which allows MIB authors to extend the set of supported transport domains by providing suitable definitions in standardized or enterprise specific MIB modules.
STD 58のSMIv2、RFC 2579 [RFC2579]はテキストの表記法のTDomainとTAddress汎用トランスポート層エンドポイントを表すように定義します。ジェネリックTAddress値のTDomain値によって識別される所与の移送ドメインで解釈されます。 TDomainは、MIBの作成者は、標準化またはエンタープライズ特定のMIBモジュールに適切な定義を提供することによってサポートされているトランスポート・ドメインのセットを拡張することを可能にするオブジェクト識別子です。
An initial set of TDomain values and concrete TAddress formats has been standardized in STD 62, RFC 3417 [RFC3417]. These definitions are however mixed up with SNMP semantics. Furthermore, definitions for Internet transport protocols over IPv4 and IPv6 are missing.
TDomain値とコンクリートTAddressフォーマットの初期セットはSTD 62、RFC 3417 [RFC3417]に標準化されています。これらの定義は、しかし、SNMPセマンティクスと混同されています。さらに、IPv4およびIPv6経由のインターネットトランスポートプロトコルの定義が欠落しています。
The purpose of this memo is to introduce a set of well-known textual conventions to represent commonly used transport-layer addressing information which is compatible with the original TDomain and TAddress approach and which includes definitions for additional Internet transport protocols over IPv4 and IPv6. This memo also introduces a new textual convention which enumerates the well-known transport domains since such an enumeration provides in many cases sufficient flexibility and is more efficient compared to object identifiers.
このメモの目的は、IPv4とIPv6の上の追加のインターネットトランスポートプロトコルの定義を含む元のTDomainとTAddressアプローチと互換性があり、一般的に使用されるトランスポート層アドレス情報を表現するために、周知のテキスト表記の組を導入することです。このメモは、そのような列挙は、多くの場合に十分な柔軟性を提供し、オブジェクト識別子と比較してより効率的であるため、よく知られた輸送ドメインを列挙し、新しいテキストの表記法を導入します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "SHOULD"、 "SHOULD NOT" および本書でBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されるべきである、 "MAY"。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準の管理フレームワークを記述したドキュメントの詳細な概要については、RFC 3410 [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].
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBオブジェクトは、一般的に簡易ネットワーク管理プロトコル（SNMP）を介してアクセスされます。 MIBのオブジェクトは、管理情報（SMI）の構造で定義されたメカニズムを使用して定義されています。このメモは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]とSTD 58、RFC 2580 [RFC2580]に記載されているSMIv2のに準拠しているMIBモジュールを指定します。
This MIB module contains definitions for commonly used transport layer addressing information. In particular, it provides the following definitions:
このMIBモジュールは、一般的に使用されるトランスポート層は、情報に対処するための定義が含まれています。特に、以下の定義を提供します。
1. Textual conventions for generic transport addresses (TransportAddress) and generic transport domains (TransportDomain).
1.一般的なトランスポートアドレスためのテキストの表記法（TransportAddress）と、一般的な輸送ドメイン（TransportDomain）。
3. An enumeration of the well-known transport domains, called a transport address type (TransportAddressType).
3.周知輸送ドメインの列挙は、トランスポート・アドレス・タイプ（TransportAddressType）と呼ばれます。
4. A set of textual conventions for the address formats used by well-known transport domains. The DISPLAY-HINTs are aligned with the formats used in URIs [RFC2396], [RFC3291].
4.周知輸送ドメインで使用されるアドレス形式のテキスト規則のセット。 DISPLAY-ヒントはURIを[RFC2396]、[RFC3291]で使用されるフォーマットと整列しています。
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 [SCOPED]. 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 TransportAddressIPv4z and TransportAddressIPv6z are provided to support Internet transport addresses that include a zone index. In order to support arbitrary combinations of scoped Internet transport addresses, MIB authors SHOULD use a separate TransportDomain or TransportAddressType objects for each TransportAddress object.
よく知られた輸送ドメインをサポートするためのテキストの表記法は、インターネットアドレスをスコープ。インターネットアドレスの範囲は、アドレスがインターフェイスのインターフェイスまたはセットの一意の識別子として使用することができる内トポロジーのスパンです。スコープゾーン、または単にゾーンは、所与の範囲のトポロジーの具体接続領域です。範囲はトポロジカル領域[スコープ]の大きさであるのに対しゾーンは、トポロジカル領域の特定のインスタンスであることに留意されたいです。複数のゾーンを接続するデバイスでインターネットアドレスは一意である必要はありませんので、追加のゾーンインデックスは、インタフェースを選択するために、これらのデバイス上で必要とされています。テキストの表記法TransportAddressIPv4zとTransportAddressIPv6zはゾーンインデックスを含め、インターネット・トランスポート・アドレスをサポートするために提供されています。スコープインターネットトランスポート・アドレスの任意の組み合わせをサポートするために、MIBの作者は、各TransportAddressオブジェクトに対して別個TransportDomain又はTransportAddressTypeオブジェクトを使用すべきです。
There are two different ways how new transport domains and textual conventions for the address formats used by those new transport domains can be defined.
これらの新しいトランスポートドメインによって使用されるアドレスフォーマットのための新しいトランスポートドメインとテキストの表記法を定義することができますどのように二つの異なる方法があります。
1. The MIB module contained in this memo can be updated and new constants for the TransportDomain and the TransportAddressType enumeration can be assigned.
1.このメモに含まれているMIBモジュールを更新することができるとTransportDomainとTransportAddressType列挙のための新しい定数を割り当てることができます。
2. Other MIB modules may define additional transport domains and associated textual conventions. Such an extension can not update the TransportAddressType enumeration.
2.その他のMIBモジュールは、追加のトランスポート・ドメインと関連したテキストの表記法を定義することができます。このような拡張はTransportAddressType列挙を更新することはできません。
It is therefore a MIB designers choice whether he uses (a) a more compact TransportAddressType object with limited extensibility or (b) a more verbose TransportDomain object which allows arbitrary extensions in other MIB modules.
したがって、彼は限られた拡張性または（b）他のMIBモジュール内の任意の拡張を可能にする、より詳細なTransportDomainオブジェクトで（a）は、よりコンパクトなTransportAddressTypeオブジェクトを使用するかどうかMIBデザイナーの選択です。
The MIB module contained in this memo does NOT define the transport mappings of any particular protocol. Rather, it defines a set of common identifiers and textual conventions that are intended to be used within various transport mappings documents.
このメモに含まれるMIBモジュールは、任意の特定のプロトコルのトランスポートマッピングを定義していません。むしろ、それは、共通の識別子と、様々なトランスポートマッピングドキュメント内で使用されることが意図されているテキストの表記法のセットを定義します。
This section discusses how the definitions provided by the MIB module contained in this memo relate to definitions in other MIB modules.
このセクションでは、このメモに含まれるMIBモジュールによって提供される定義は、他のMIBモジュールの定義に関連する方法について説明します。
The SNMPv2-TC MIB module [RFC2579] defines the textual conventions TAddress and TDomain to represent generic transport addresses.
SNMPv2-TCのMIBモジュール[RFC 2579]は、一般的なトランスポートアドレスを表すためにテキストの表記法アドレスとドメインを定義します。
A TAddress is an octet string with a size between 1 and 255 octets. Experience has shown that there is sometimes a need to represent unknown transport addresses. The MIB module contained in this memo therefore introduces a new textual convention TransportAddress which is an octet string with a size between 0 and 255 octets and otherwise identical semantics. In other words, the sub-type TransportAddress (SIZE (1..255)) is identical with the TAddress defined in the SNMPv2-TC MIB module [RFC2579].
TAddressは、1と255オクテットの間の大きさのオクテット文字列です。経験は、未知のトランスポートアドレスを表現する必要が時々あることを示しています。このメモに含まれているMIBモジュールは、したがって、0と255オクテットと他の点では同一のセマンティクスの間でサイズがオクテット文字列で新しいテキストの表記法TransportAddressを紹介しています。換言すれば、サブタイプTransportAddress（SIZE（1 255））は、SNMPv2の-TC MIBモジュール[RFC2579]で定義さTAddressと同一です。
This MIB module also introduces a new textual convention TransportDomain which is compatible with the TDomain definition so that a complete set of definitions is contained in a single MIB module. New MIB modules SHOULD use the generic TransportDomain, TransportAddressType and TransportAddress definitions defined in this memo. Existing MIB modules may be updated to use the definitions provided in this memo by replacing TDomain with TransportDomain and TAddress with TransportAddress (SIZE (1..255)).
このMIBモジュールはまた、定義の完全なセットが単一のMIBモジュールに含まれるようにのTDomain定義と互換性のある新しいテキストの表記法TransportDomainを紹介しています。新しいMIBモジュールはこのメモで定義されている一般的なTransportDomain、TransportAddressTypeとTransportAddress定義を使用すべきです。既存のMIBモジュールはTransportAddress（SIZE（1 255））とTransportDomainとTAddressとのTDomain置き換えることによって、このメモで提供された定義を使用するように更新されてもよいです。
The transport domain values defined in the SNMPv2-TM MIB module [RFC3417] all contain "snmp" as the prefix in their name and are registered under `snmpDomains' (from RFC 2578 [RFC2578]). They were originally intended to describe SNMP transport domains only - but they were later also used for non-SNMP transport endpoints. These definitions are also incomplete since new transport address domains are needed to support (at least) SNMP over UDP over IPv6.
SNMPv2の-TM MIBモジュールで定義された輸送ドメイン値[RFC3417]のすべては、それらの名前に接頭辞として「SNMP」を含むと `snmpDomains'（RFC 2578から[RFC2578]）の下に登録されています。彼らはもともとのみSNMP輸送ドメインを記述するために意図されていた - しかし、彼らは後にも非SNMPトランスポートエンドポイントのために使用されました。新しいトランスポートアドレスのドメインがIPv6上でUDP上で（少なくとも）SNMPをサポートするために必要なので、これらの定義も不完全です。
The transport domain values defined in this memo are independent of the protocol running over the transport-layer and SHOULD be used for all transport endpoints not carrying SNMP traffic. Programs that interpret transport domain values should in addition accept the transport domain values defined in the SNMPv2-TM MIB module in order to provide interoperability with existing implementations that use the SNMP specific transport domain values.
このメモで定義された輸送ドメイン値はトランスポート層の上に実行されているプロトコルに依存しており、SNMPのトラフィックを伝送していないすべてのトランスポートエンドポイントには、使用されてください。輸送ドメイン値を解釈するプログラムは、ほかにSNMP特定のトランスポートドメイン値を使用する既存の実装との相互運用性を提供するためにはSNMPv2-TM MIBモジュールで定義された輸送ドメイン値を受け入れる必要があります。
Transport endpoints which carry SNMP traffic SHOULD continue to use the definitions from the SNMPv2-TM MIB module where applicable. They SHOULD use the transport domain values defined in this memo for SNMP transports not defined in the SNMPv2-TM MIB module, such as SNMP over UDP over IPv6. Programs that interpret transport domain values should in addition accept all the transport domain values defined in this memo in order to provide interoperability in cases where it is not possible or desirable to distinguish the protocols running over a transport endpoint.
SNMPトラフィックを運ぶトランスポートエンドポイントは、該当する場合はSNMPv2-TM MIBモジュールからの定義を使用し続けなければなりません。彼らは、IPv6上でUDP上でSNMPなどのSNMPv2-TM MIBモジュールで定義されていない搬送するSNMPのためにこのメモで定義された輸送ドメイン値を使用する必要があります。輸送ドメイン値を解釈するプログラムは、加えて、トランスポートエンドポイント上で実行されているプロトコルを識別することが可能か、望ましくない場合には、相互運用性を提供するために、このメモで定義されたすべてのトランスポートドメイン値を受け入れる必要があります。
The INET-ADDRESS-MIB MIB module [RFC3291] defines the textual conventions InetAddressType and InetAddress to represent Internet network layer endpoints. Some MIB modules use these textual conventions in conjunction with the InetPortNumber textual convention to represent Internet transport-layer endpoints. This approach is fine as long as a MIB models protocols or applications that are specific to the Internet suite of transport protocols. For protocols or applications that can potentially use other transport protocols, the use of the definitions contained in this memo is more appropriate.
INET-ADDRESS-MIB MIBモジュール[RFC3291]はテキストの表記法たInetAddressTypeとInetAddressがインターネットのネットワーク層エンドポイントを表すように定義します。一部のMIBモジュールは、インターネットトランスポート層のエンドポイントを表すためにInetPortNumberテキストの表記法と一緒にこれらのテキストの表記法を使用します。このアプローチは、限り、トランスポートプロトコルのインターネットスイートに固有のMIBモデルのプロトコルやアプリケーションなど細かいです。潜在的に他のトランスポートプロトコルを使用することができるプロトコルまたはアプリケーションのために、このメモに含まれる定義の使用がより適切です。
TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC;
SNMPv2-TC FROMのSNMPv2-SMIテキストの表記法からの輸入MODULE-IDENTITY、OBJECT-IDENTITY、MIB-2。
transportAddressMIB MODULE-IDENTITY LAST-UPDATED "200211010000Z" ORGANIZATION "IETF Operations and Management Area" CONTACT-INFO "Juergen Schoenwaelder (Editor) TU Braunschweig Bueltenweg 74/75 38106 Braunschweig, Germany
transportAddressMIBのMODULE-IDENTITY LAST-UPDATED "200211010000Z" ORGANIZATION "IETF操作と管理領域" CONTACT-INFO「ユルゲンSchoenwaelder（編集）TUブラウンシュバイクBueltenweg 75分の74 38106ブラウンシュヴァイク、ドイツ
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
Send comments to <mibs@ops.ietf.org>." DESCRIPTION "This MIB module provides commonly used transport address definitions.
<mibs@ops.ietf.org>。「DESCRIPTION」このMIBモジュールは、一般的に使用されるトランスポート・アドレスの定義を提供するコメントを送信。
Copyright (C) The Internet Society (2002). This version of
this MIB module is part of RFC 3419; see the RFC itself for
full legal notices."
-- Revision log
- リビジョンログ
REVISION "200211010000Z"
DESCRIPTION
"Initial version, published as RFC 3419."
::= { mib-2 100 }
transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 }
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
transportDomainUdpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 2 }
transportDomainUdpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 3 }
transportDomainUdpIpv6z OBJECT-IDENTITY STATUS current
transportDomainUdpIpv6z OBJECT-IDENTITYステータス現在
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 4 }
transportDomainTcpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 5 }
transportDomainTcpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 6 }
transportDomainTcpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 7 }
transportDomainTcpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 8 }
transportDomainSctpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 9 }
transportDomainSctpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 10 }
transportDomainSctpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 11 }
transportDomainSctpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 12 }
transportDomainLocal OBJECT-IDENTITY STATUS current DESCRIPTION "The Posix Local IPC transport domain. The corresponding transport address is of type TransportAddressLocal.
transportDomainLocal OBJECT-IDENTITYステータス現在の説明「PosixのローカルIPC輸送ドメイン。対応するトランスポートアドレスはタイプTransportAddressLocalです。
The Posix Local IPC transport domain incorporates the
well-known UNIX domain sockets."
::= { transportDomains 13 }
transportDomainUdpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 14 }
transportDomainTcpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 15 }
transportDomainSctpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 16 }
TransportDomain ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain.
Some possible values, such as transportDomainUdpIpv4, are
defined in this module. Other possible values can be
defined in other MIB modules."
SYNTAX OBJECT IDENTIFIER
-- -- The enumerated values of the textual convention below should -- be identical to the last sub-identifier of the OID registered -- for the same domain. --
- - 以下のテキストの表記法の列挙値がなければならない - 同じドメインの - OID登録の最後のサブ識別子と同一です。 -
TransportAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain. This is the
enumerated version of the transport domain registrations
in this MIB module. The enumerated values have the
following meaning:
unknown(0) unknown transport address type
udpIpv4(1) transportDomainUdpIpv4
udpIpv6(2) transportDomainUdpIpv6
udpIpv4z(3) transportDomainUdpIpv4z
udpIpv6z(4) transportDomainUdpIpv6z
tcpIpv4(5) transportDomainTcpIpv4
tcpIpv6(6) transportDomainTcpIpv6
tcpIpv4z(7) transportDomainTcpIpv4z tcpIpv6z(8) transportDomainTcpIpv6z
sctpIpv4(9) transportDomainSctpIpv4
sctpIpv6(10) transportDomainSctpIpv6
sctpIpv4z(11) transportDomainSctpIpv4z
sctpIpv6z(12) transportDomainSctpIpv6z
local(13) transportDomainLocal
udpDns(14) transportDomainUdpDns
tcpDns(15) transportDomainTcpDns
sctpDns(16) transportDomainSctpDns
This textual convention can be used to represent transport domains in situations where a syntax of TransportDomain is unwieldy (for example, when used as an index).
このテキストの表記法はTransportDomainの構文は、（例えば、インデックスとして使用）扱いにくい状況で輸送ドメインを表すために使用することができます。
The usage of this textual convention implies that additional transport domains can only be supported by updating this MIB module. This extensibility restriction does not apply for the TransportDomain textual convention which allows MIB authors to define additional transport domains independently in other MIB modules." SYNTAX INTEGER { unknown(0), udpIpv4(1), udpIpv6(2), udpIpv4z(3), udpIpv6z(4), tcpIpv4(5), tcpIpv6(6), tcpIpv4z(7), tcpIpv6z(8), sctpIpv4(9), sctpIpv6(10), sctpIpv4z(11), sctpIpv6z(12), local(13), udpDns(14), tcpDns(15), sctpDns(16) }
このテキストの表記法の使用は、追加の輸送ドメインは唯一このMIBモジュールを更新することでサポートできることを意味します。この拡張性の制限は、MIBの作成者は、他のMIBモジュールで独立に、追加の輸送ドメインを定義することができTransportDomainテキストの表記法には適用されません。」SYNTAX INTEGER {不明（0）、udpIpv4（1）、udpIpv6（2）、udpIpv4z（3）、 udpIpv6z（4）、tcpIpv4（5）、tcpIpv6（6）、tcpIpv4z（7）、tcpIpv6z（8）、ローカルsctpIpv4（9）、sctpIpv6（10）、sctpIpv4z（11）、sctpIpv6z（12）、（13）、 udpDns（14）、tcpDns（15）、sctpDns（16）}
TransportAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic transport address.
A TransportAddress value is always interpreted within the
context of a TransportAddressType or TransportDomain value.
Every usage of the TransportAddress textual convention MUST specify the TransportAddressType or TransportDomain object
which provides the context. Furthermore, MIB authors SHOULD
define a separate TransportAddressType or TransportDomain
object for each TransportAddress object. It is suggested that
the TransportAddressType or TransportDomain is logically
registered before the object(s) which use the
TransportAddress textual convention if they appear in the
same logical row.
The value of a TransportAddress object must always be consistent with the value of the associated TransportAddressType or TransportDomain object. Attempts to set a TransportAddress object to a value which is inconsistent with the associated TransportAddressType or TransportDomain must fail with an inconsistentValue error.
TransportAddressオブジェクトの値は常に関連TransportAddressType又はTransportDomainオブジェクトの値と一致しなければなりません。関連TransportAddressType又はTransportDomainと矛盾している値にTransportAddressオブジェクトを設定する試みはinconsistentValueエラーで失敗しなければなりません。
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (0..255))
このテキストの表記法は、インデックスオブジェクトの構文として使用される場合、この場合のSMIv2、STD 58で指定された128のサブ識別子の限界の問題があるかもしれない、OBJECT型の宣言は、に「SIZE」句を含まなければなりません潜在的なインスタンスサブ識別子の数を制限する。」構文オクテットSTRING（SIZE（0..255））
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (6))
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。それが使用される場合は、それはそれ自体で、またはペアとしてTransportAddressType又はTransportDomainと組み合わせて使用することができる。」構文オクテットSTRING（SIZE（6））
TransportAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address and a port number (as used for example by UDP,
TCP and SCTP):
TCPとSCTP）：
octets contents encoding 1-16 IPv6 address network-byte order 17-18 port number network-byte order
1-16 IPv6アドレスネットワークバイトオーダーに17-18ポート番号ネットワークバイト順を符号化するオクテット内容
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (18))
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。それが使用される場合は、それはそれ自体で、またはペアとしてTransportAddressType又はTransportDomainと組み合わせて使用することができる。」構文オクテットSTRING（SIZE（18））
TransportAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
9-10 port number network-byte order
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (10))
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。それが使用される場合は、それはそれ自体で、またはペアとしてTransportAddressType又はTransportDomainと組み合わせて使用することができる。」構文オクテットSTRING（SIZE（10））
TransportAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
21-22 port number network-byte order
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format.
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。
However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair." SYNTAX OCTET STRING (SIZE (22))
それが使用される場合は、それはそれ自体で、またはペアとしてTransportAddressType又はTransportDomainと組み合わせて使用することができる。」構文オクテットSTRING（SIZE（22））
TransportAddressLocal ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a POSIX Local IPC transport address:
octets contents encoding
all POSIX Local IPC address string
The Posix Local IPC transport domain subsumes UNIX domain sockets.
PosixのローカルIPC輸送ドメインは、UNIXドメインソケットを包摂します。
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair.
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。ただし、使用されれば、それは自分自身でまたはペアとしてTransportAddressTypeまたはTransportDomainと組み合わせて使用することができます。
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." REFERENCE "Protocol Independent Interfaces (IEEE POSIX 1003.1g)" SYNTAX OCTET STRING (SIZE (1..255))
このテキストの表記法は、インデックスオブジェクトの構文として使用される場合、この場合のSMIv2、STD 58で指定された128のサブ識別子の限界の問題があるかもしれない、OBJECT型の宣言は、に「SIZE」句を含まなければなりません潜在的なインスタンスサブ識別子の数を制限する。」基準 『プロトコル独立インタフェース（IEEE POSIXの1003.1グラム）』構文オクテットSTRING（SIZE（1 255））
TransportAddressDns ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a DNS domain name followed by a colon ':'
(ASCII character 0x3A) and a port number in ASCII.
The name SHOULD be fully qualified whenever possible.
Values of this textual convention are not directly useable as
transport-layer addressing information, and require runtime
resolution. As such, applications that write them must be
prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may have TransportAddressDns values must fully describe how (and when) such names are to be resolved to IP addresses and vice versa.
TransportAddressDns値を有していてもよいTransportAddressオブジェクトの記述節は完全にそのような名前は、その逆のIPアドレスに解決されるべき方法（および場合）について説明しなければなりません。
This textual convention SHOULD NOT be used directly in object definitions since it restricts addresses to a specific format. However, if it is used, it MAY be used either on its own or in conjunction with TransportAddressType or TransportDomain as a pair.
それは特定のフォーマットにアドレスを制限するため、このテキストの表記法はオブジェクト定義で直接使用してはなりません。ただし、使用されれば、それは自分自身でまたはペアとしてTransportAddressTypeまたはTransportDomainと組み合わせて使用することができます。
When this textual convention is used as a 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-TYPE declaration MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers." SYNTAX OCTET STRING (SIZE (1..255))
このテキストの表記法は、インデックスオブジェクトの構文として使用される場合、この場合のSMIv2、STD 58で指定された128のサブ識別子の限界の問題があるかもしれない、OBJECT型の宣言は、に「SIZE」句を含まなければなりません潜在的なインスタンスサブ識別子の数を制限する。」構文オクテットSTRING（SIZE（1 255））
END
終わり
This section shows some examples how transport addresses are encoded and rendered using some of the transport address definitions.
このセクションでは、トランスポート・アドレスは、符号化およびトランスポート・アドレスの定義の一部を使用してレンダリングする方法いくつかの例を示しています。
Description: Unspecified IPv4 address on port 80. Encoding (hex): 000000000050 Display: 0.0.0.0:80
説明：ポート80エンコード（16進）に指定されていないIPv4アドレス：000000000050ディスプレイ：0.0.0.0:80
Description: Global IPv4 address on port 80. Encoding (hex): 86A922010050 Display: 134.169.34.1:80
説明：ポート80エンコード（16進）にグローバルIPv4アドレス：86A922010050ディスプレイ：134.169.34.1:80
Description: Unspecified IPv6 address on port 80. Encoding (hex): 000000000000000000000000000000000050 Display: [0:0:0:0:0:0:0:0]:80
説明：ポート80エンコード（16進）に指定されていないIPv6アドレス：000000000000000000000000000000000050ディスプレイ：[0：0：0：0：0：0：0：0]：80
Description: Global IPv6 address on port 80. Encoding (hex): 108000000000000000080800200C417A0050 Display: [1080:0:0:0:8:800:200C:417A]:80
説明：ポート80エンコード（16進）にグローバルIPv6アドレス：108000000000000000080800200C417A0050ディスプレイ：[1080：0：0：0：8：800：200C：417A]：80
Description: Link-local IPv6 address with zone-index 42 on port 80. Encoding (hex): FE8000000000000000010000000002000000002A0050 Display: [FE80:0:0:0:1:0:0:200%42]:80
説明：ポート80エンコード（16進）のゾーンインデックス42とリンクローカルIPv6アドレス：FE8000000000000000010000000002000000002A0050ディスプレイ：[FE80：0：0：0：1：0：0：200％42]：80
Description: Posix Local IPC address (UNIX domain). Encoding (hex): 2F7661722F6167656E74782F6D6173746572 Display: /var/agentx/master
説明：POSIXローカルIPCアドレス（UNIXドメイン）。エンコード（16進数）：2F7661722F6167656E74782F6D6173746572ディスプレイ：の/ var /のAgentX /マスター
Description: Fully qualified domain name on port 80. Encoding (hex): 7777772E6578616D706C652E6E65743A3830 Display: www.example.net:80
説明：ポート80エンコーディングの完全修飾ドメイン名（16進数）：7777772E6578616D706C652E6E65743A3830ディスプレイ：www.example.net:80
The MIB module contained in this memo 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.
このメモに含まれているMIBモジュールは、任意の管理オブジェクトを定義していません。代わりに、管理オブジェクトを定義するために他のMIBモジュールによって使用することができるテキスト規則のセットを定義します。
Meaningful security considerations can only be written for MIB modules that define concrete management objects. This document has therefore no impact on the security of the Internet.
意味のあるセキュリティ上の考慮事項は、具体的な管理オブジェクトを定義するMIBモジュールのためにのみ書き込むことができます。従って、この文書は、インターネットのセキュリティには影響を与えません。
This document was produced by the Operations and Management Area "IPv6MIB" design team. The authors would like to thank Mark Ellison, Brian Haberman, Mike Heard, Glenn Mansfield Keeni, Erik Nordmark, Shawn A. Routhier, Bill Strahm, Dave Thaler and Bert Wijnen for their comments and suggestions.
この文書は、運用と管理エリア「IPv6MIB」デザインチームによって作成されました。作者は彼らのコメントと提案のためにマーク・エリソン、ブライアンハーバーマン、マイク・聞かれた、グレンマンスフィールドKeeni、エリックNordmarkと、ショーンA. Routhier、ビルStrahm、デーブターラーとバートWijnenに感謝したいと思います。
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 implementors 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専務に情報を扱ってください。
Normative References
引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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）の構造"、STD 58、RFC 2578、 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のためのテキストの表記法"、STD 58、RFC 2579、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のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "トランスポートマッピングのSNMP（Simple Network Management Protocol）について"、STD 62、RFC 3417、2002年12月。
Informative References
参考文献
[SCOPED] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A. and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress.
[スコープ]デアリング、S.、ハーバーマン、B.、神明、T.、Nordmarkと、E.、尾上、A.及びB. Zill、 "IPv6のスコープアドレスアーキテクチャ"、ProgressのWork。
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, August 1998.
[RFC2732] HindenとR.、大工、B.およびL. Masinter、RFC 2732、1998年8月 "リテラルIPv6のフォーマットは、URLの中のアドレス"。
[RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, December 2001.
[RFC3291]ダニエル、M.、ハーバーマン、B.、Routhier、S.およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 3291、2001年12月。
[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.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
Authors' Addresses
著者のアドレス
Mike Daniele Consultant 19 Pinewood Rd Hudson, NH 03051 USA
マイク・ダニエレ・コンサルタント19パインウッドRdのハドソン、NH 03051 USA
Phone: +1 603 883-6365 EMail: md@world.std.com
電話：+1 603 883-6365 Eメール：md@world.std.com
Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュバイクBültenweg75分の74 38106ブラウンシュヴァイク、ドイツ
Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de
電話：+49 531 391-3289 Eメール：schoenw@ibr.cs.tu-bs.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。