RFC 3419 - Textual Conventions for Transport Addresses 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3419
タイトル : RFC 3419 - 輸送アドレスのテキストコンベンション
翻訳編集 : 自動生成

[要約] RFC 3419は、トランスポートアドレスのテキスト表現に関する規定を提供するものであり、ネットワーク通信におけるアドレスの一貫性と相互運用性を確保することを目的としています。

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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

1. Introduction

1. はじめに

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で動作できるアプリケーションプロトコルのMIBSです。

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は、標準化されたまたはエンタープライズ固有の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値とコンクリートのタドレス形式の初期セットは、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.

このメモの目的は、元のTdomainおよびTaddressアプローチと互換性があり、IPv4およびIPv6を介した追加のインターネット輸送プロトコルの定義を含む、一般的に使用される輸送層アドレス指定情報を表すために、よく知られているテキスト慣習のセットを導入することです。このメモは、多くの場合、十分な柔軟性を提供し、オブジェクト識別子と比較してより効率的であるため、よく知られている輸送ドメインを列挙する新しいテキスト条約も紹介します。

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].

このドキュメントの「必須」、「必要はない」、「そうはない」、「すべきではない」、「そうすべきではない」は、BCP 14、RFC 2119 [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].

現在のインターネット標準管理フレームワークを説明するドキュメントの詳細な概要については、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モジュールを指定します。

3. Overview

3. 概要

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）のテキスト規則。

2. Object identifier registrations for well-known transport domains.

2. よく知られている輸送ドメインのオブジェクト識別子登録。

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. よく知られている輸送ドメインで使用されるアドレス形式のテキストコンベンションのセット。ディスプレイヒントは、URIS [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.

これらの新しい輸送ドメインが使用するアドレス形式の新しい輸送ドメインとテキストコンベンションを定義する方法は2つあります。

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.

したがって、（a）限られた拡張性を備えたよりコンパクトなTransportAddressTypeオブジェクトを使用するか、（b）他のMIBモジュールの任意の拡張を可能にするより冗長な輸送ドメインオブジェクトを使用するかどうかは、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モジュールは、特定のプロトコルの輸送マッピングを定義しません。むしろ、さまざまな輸送マッピングドキュメント内で使用することを目的とした共通の識別子とテキストの慣習のセットを定義します。

3.1 Relationship to Other MIBs

3.1 他の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モジュールの定義にどのように関連しているかについて説明します。

3.1.1 SNMPv2-TC (TAddress, TDomain)

3.1.1 snmpv2-tc（taddress、tdomain）

The SNMPv2-TC MIB module [RFC2579] defines the textual conventions TAddress and TDomain to represent generic transport addresses.

SNMPV2-TC MIBモジュール[RFC2579]は、一般的な輸送アドレスを表すためにTADDRESSとTDOMAINをテキストの規則と定義します。

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].

タドレスは、サイズが1〜255オクテットのオクテットの弦です。経験は、不明な輸送住所を表す必要があることがあることを示しています。したがって、このメモに含まれるMIBモジュールは、0〜255オクテットと同一のセマンティクスのサイズのオクテット文字列である新しいテキスト条約のTransportAddressを紹介します。言い換えれば、サブタイプのTransportAddress（サイズ（1..255））は、SNMPV2-TC MIBモジュール[RFC2579]で定義されているTadressと同一です。

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モジュールは、Tromain定義と互換性のある新しいテキストコンベンションTransportDomainも導入して、1つのMIBモジュールに完全な定義セットが含まれるようにします。新しいMIBモジュールは、このメモで定義されている一般的なTransportDomain、TransportAddressType、およびTransportAddressの定義を使用する必要があります。既存のMIBモジュールを更新して、TDomainをTransportDomainに置き換え、TaddressをTransportAddress（サイズ（1..255））に置き換えることにより、このメモで提供される定義を使用することができます。

3.1.2 SNMPv2-TM

3.1.2 SNMPV2-TM

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など、SNMP2-TM MIBモジュールでは定義されていないSNMPトランスポートのこのメモで定義されているトランスポートドメイン値を使用する必要があります。輸送ドメイン値を解釈するプログラムは、トランスポートエンドポイントを介して実行されるプロトコルを区別することが不可能または望ましくない場合に相互運用性を提供するために、このメモで定義されたすべての輸送ドメイン値を受け入れる必要があります。

3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress)

3.1.3 inet-address-mib（inetaddresstype、inetAddress）

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 Module [RFC3291]は、インターネットネットワークレイヤーのエンドポイントを表すために、テキストの慣習とイノタドレスを定義します。一部のMIBモジュールは、これらのテキスト規則を使用して、InetportNumberのテキスト条約と併用して、インターネット輸送層のエンドポイントを表しています。このアプローチは、インターネットスイートの輸送プロトコルに固有のMIBモデルプロトコルまたはアプリケーションである限り、問題ありません。他のトランスポートプロトコルを潜在的に使用できるプロトコルまたはアプリケーションの場合、このメモに含まれる定義の使用がより適切です。

4. Definitions

4. 定義

TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN

IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC;

snmpv2-tcからのsnmpv2-smiテキストコンベンションからのモジュール同一性、オブジェクトアイデンティティ、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 Phone: +49 531 391-3289 EMail: schoenw@ibr.cs.tu-bs.de

TransportAddressmibモジュールのアイデンティティ最終的な「200211010000Z」組織「IETFオペレーションおよび管理エリア」コンタクトINFO "Juergen Schoenwaelder（編集者）Tu Braunschweig Bueltenweg 74/75 38106 Braunschweig、ドイツの電話：49 531 391-3289電子メール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>にコメントを送信します。 "説明"この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
    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オブジェクトアイデンティティステータス現在の説明 "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

TransportDomainUdPipv4などのいくつかの可能な値は、このモジュールで定義されています。他の可能な値は、他のMIBモジュールで定義できます。 "構文オブジェクト識別子

--
-- The enumerated values of the textual convention below should
-- be identical to the last sub-identifier of the OID registered
-- for the same domain.
--

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

不明（0）不明な輸送アドレスタイプudpipv4（1）Transportdomainudpipv4 udpipv6（2）TransportdomainudPipv6 Udpipv4z（3）TransportdomainudPipv4Z Udpipv6Z（4）TransportDomainudPipv6Z TCPIPV4（5）TransportDomingDdominaintdCPV4 TCPIPV6（6）輸送Dome ）TransportDomaintCPIPV4Z TCPIPV6Z（8）TransportDomaintCPIPV6Z SCTPIPV4（9）TransportDomainsCtpipv4 SCTPIPV6（10）TransportDomainsCTPIPV6 SCTPIPVZ（11）TransportDomainsCTPIPV4Z SCTPIPV6Z（12）TransportDomainsCTPIPV6Z Local（13）TransportDomainLocal UDPDNS（14）輸送中国輸送中国の輸送中国輸送（15）輸送中国の輸送（15） ns

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).

このテキスト条約は、輸送ドメインの構文が扱いにくい状況で輸送ドメインを表すために使用できます（たとえば、インデックスとして使用する場合）。

         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)
                }

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.

TransportAddress値は、常にTransportAddressTypeまたはTransportDomain値のコンテキスト内で解釈されます。TransportAddressテキスト条約のすべての使用法は、コンテキストを提供するTransportAddressTypeまたはTransportDomainオブジェクトを指定する必要があります。さらに、MIBの著者は、各TransportAddressオブジェクトの個別のTransportAddressTypeまたはTransportDomainオブジェクトを定義する必要があります。TransportAddressTypeまたはTransportDomainは、同じ論理行に表示されている場合、TransportAddressテキスト慣習を使用するオブジェクトの前に論理的に登録されることが示唆されています。

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オブジェクトの値と常に一致する必要があります。TransportAddressオブジェクトを、関連する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 (0..255))

このテキスト条約がインデックスオブジェクトの構文として使用される場合、SMIV2、STD 58で指定された128のサブ識別子の制限に問題がある場合があります。この場合、オブジェクトタイプの宣言には「サイズ」句を含める必要があります。潜在的なインスタンスサブ識別子の数を制限します。 "構文オクテット文字列（サイズ（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

1-4 IPv4アドレスネットワークバイトオーダー5-6ポート番号ネットワークバイトオーダーをエンコードするオクテットの内容

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と組み合わせてペアとして使用できます。

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):

octets contents encoding 1-16 IPv6 address network-byte order 17-18 port number network-byte order

1-16 IPv6アドレスネットワークバイトオーダー17-18ポート番号ネットワークバイトオーダーをエンコードするオクテットの内容

このテキスト条約は、アドレスを特定の形式に制限するため、オブジェクト定義で直接使用すべきではありません。ただし、使用する場合は、単独で、またはPairとしてTransportAddressTypeまたはTransportDomainと組み合わせて使用できます。

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

1-4 IPv4アドレスネットワークバイトオーダー5-8ゾーンインデックスネットワークバイトオーダー9-10ポート番号ネットワークバイトオーダーをエンコードするオクテットの内容

このテキスト条約は、アドレスを特定の形式に制限するため、オブジェクト定義で直接使用すべきではありません。ただし、使用する場合は、単独で、またはTransportAddressTypeまたはTransportDomainと組み合わせてペアとして使用できます。

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

1-16 IPv6アドレスネットワークバイトオーダー17-20ゾーンインデックスネットワークバイトオーダー21-22ポート番号ネットワークバイトオーダー17-20ゾーンバイトオーダーをエンコードするオクテットの内容

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と組み合わせてペアとして使用できます。

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

すべてのPOSIXローカルIPCアドレス文字列をコードするオクテットの内容

The Posix Local IPC transport domain subsumes UNIX domain sockets.

POSIXローカルIPCトランスポートドメインは、UNIXドメインソケットを包含します。

このテキスト条約は、アドレスを特定の形式に制限するため、オブジェクト定義で直接使用すべきではありません。ただし、使用する場合は、単独で、またはTransportAddressTypeまたはTransportDomainと組み合わせて使用することができます。

このテキスト条約がインデックスオブジェクトの構文として使用される場合、SMIV2、STD 58で指定された128のサブ識別子の制限に問題がある場合があります。この場合、オブジェクトタイプの宣言には「サイズ」句を含める必要があります。潜在的なインスタンスサブ識別子の数を制限します。

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アドレスに解決する方法（およびいつ）を完全に説明する必要があります。

END

終わり

5. Examples

5. 例

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の不特定のIPv4アドレス。エンコード（hex）：000000000050ディスプレイ：0.0.0.0:80

Description: Global IPv4 address on port 80. Encoding (hex): 86A922010050 Display: 134.169.34.1:80

説明：ポート80のグローバルIPv4アドレス。エンコーディング（hex）：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

Description:      Global IPv6 address on port 80.
Encoding (hex):   108000000000000000080800200C417A0050
Display:          [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

Description:      Posix Local IPC address (UNIX domain).
Encoding (hex):   2F7661722F6167656E74782F6D6173746572
Display:          /var/agentx/master
Description:      Fully qualified domain name on port 80.
Encoding (hex):   7777772E6578616D706C652E6E65743A3830
Display:          www.example.net:80

6. Security Considerations

6. セキュリティに関する考慮事項

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モジュールに対してのみ作成できます。したがって、このドキュメントは、インターネットのセキュリティに影響を与えません。

7. Acknowledgments

7. 謝辞

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」設計チームによって作成されました。著者は、マーク・エリソン、ブライアン・ハーバーマン、マイク・ハード、グレン・マンスフィールド・ケーニ、エリック・ノードマーク、ショーン・A・ラウチエ、ビル・ストラーム、デイブ・ターラー、バート・ウィジネンのコメントと提案に感謝したいと思います。

8. Intellectual Property Notice

8. 知的財産通知

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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。and 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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMP）の輸送マッピング」、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.

[Scoped] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E.、Onoe、A。and B. Zill、「IPv6スコープアドレスアーキテクチャ」、進行中の作業。

[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFC2396] Berners-Lee、T.、Fielding、R。and L. Masinter、「Uniform Resource Identiers（URI）：Generic Syntax」、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.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1998年8月。

[RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, December 2001.

[RFC3291] Daniele、M.、Haberman、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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。

Authors' Addresses

著者のアドレス

Mike Daniele Consultant 19 Pinewood Rd Hudson, NH 03051 USA

マイク・ダニエルコンサルタント19パインウッドRDハドソン、ニューハンプシャー03051 USA

   Phone: +1 603 883-6365
   EMail: md@world.std.com

Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany

Juergen Schoenwaelder Tu Braunschweig Bueltenweg 74/75 38106 Braunschweigドイツ

   Phone: +49 531 391-3289
   EMail: schoenw@ibr.cs.tu-bs.de

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。