RFC1608 日本語訳
1608 Representing IP Information in the X.500 Directory. T. Johannsen,G. Mansfield, M. Kosters, S. Sataluri. March 1994. (Format: TXT=40269 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Johannsen
Request for Comments: 1608 Dresden University
Category: Experimental G. Mansfield
AIC Systems Laboratory
M. Kosters
Network Solutions,Inc.
S. Sataluri
AT&T Bell Laboratories
March 1994
コメントを求めるワーキンググループT.ヨハンセンの要求をネットワークでつないでください: 1608年のドレスデン大学カテゴリ: 実験G.のシステム研究所M.Kostersネットワークマンスフィールドアイクソリューション、1994年の株式会社S.Sataluri AT&Tベル研究所の行進
Representing IP Information in the X.500 Directory
X.500ディレクトリにおけるIP情報を表します。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in the Directory by applying it to IP networks. This application of the Directory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore, Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations.
このドキュメントはX.500ディレクトリにIPネットワークとIP番号の情報を含むのに必要なオブジェクトについて説明します。 それは仕事[1] 一般的なフレームワークがディレクトリでIPネットワークにそれを適用することによってネットワークを代表するために提示されるところの「X.500ディレクトリでネットワークを図にします」を広げています。 ディレクトリのこのアプリケーションが当局を選任するIPネットワークの仕事をサポートすることを意図します、NICs、関連するネットワークに関するデータとしてIP番号に関するマッピングを探す他のアプリケーションと同様に。 その上、ネットワークと組織との彼らの関係に伴うディレクトリでAutonomous Systemsと関連するルーティング方針情報を表すことができます。
Johannsen, Mansfield, Kosters & Sataluri [Page 1] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[1ページ]RFC1608IP情報
Table of Contents
目次
1. Introduction 2
2. IP images of networks 3
2.1 IP network image 3
2.2 IP node image 5
2.3 IP network interface image 6
2.4 Autonomous Systems 7
3. Number assignment information 7
3.1 Delegated Block object 8
3.2 IP Group object 9
3.3 IP Reference object 10
3.4 AS Block object 10
3.5 AS Reference object 10
4. Directory tree 11
4.1 IP image objects 11
4.2 AS objects 11
4.3 Namespace objects 11
4.4 Relationship to organizational entries 13
5. Security Considerations 14
6. Authors' Addresses 15
References 16
Appendix: OID tables 17
1. 序論2 2。 ネットワーク3 2.1IPネットワークイメージ3 2.2IPノードイメージ5 2.3IPのIPイメージはインタフェースイメージ6 2.4Autonomous Systems7 3をネットワークでつなぎます。 数の課題情報7 3.1Delegated Blockオブジェクト8 3.2IP Groupオブジェクト9 3.3IP Referenceオブジェクト10 3.4AS Blockオブジェクト10 3.5AS Referenceが反対する、10、4 ディレクトリツリー11 4.1個のIPイメージオブジェクト11 4.2個のASオブジェクト11 4.3Namespaceが反対する、11、4.4Relationship、組織的なエントリー、13、5 セキュリティ問題14 6。 作者のアドレス15参照16盲腸: OIDテーブル17
1. Introduction
1. 序論
Information related to the Internet Network Infrastructure is created and stored by a number of different organizations, such as the Internet Assigned Numbers Authority (IANA), Internet Registry (IR), Network Information Centers (NICs), and the NSFNET Network Operations Center (NOC). This information is generally "mastered" (stored and maintained) by these organizations on a centralized basis, i.e., there is a single place to look for a definitive list of entries for these categories. This has worked well in the past but given the tremendous growth of the Internet and its number of users and networks, it is essential that a distributed schema be used.
インターネットNetwork Infrastructureに関連する情報は、多くの異なった組織によって作成されて、保存されます、インターネットAssigned民数記Authority(IANA)や、インターネットRegistry(IR)や、Network Informationセンターズ(NICs)や、NSFNETネットワーク運営センター(NOC)などのように。 一般に、この情報はこれらの組織によって集結ベースで「マスタリングされる」(保存されて、維持されます)、すなわち、これらのカテゴリのためのエントリーの決定的なリストを探す単一の場所があります。 分配された図式が使用されるのは、これが過去にうまくいきますが、インターネットの物凄い成長とそのユーザとネットワークの番号を与えたのが不可欠です。
The X.500 Directory offers the appropriate technology for implementing this distributed method of managing network infrastructure information.
X.500ディレクトリは、ネットワークインフラ情報を管理するこの分配されたメソッドを実装するために適正技術を提供します。
The following goals are addressed in this document:
以下の目標は本書では扱われます:
o Provision of IP specific images of network elements
o Mapping from Network Number to network, owner, provider etc.
o Support of delegation of IP address blocks
o Storage of high-level routing policies and AS information
o Support of "classless" network address formats
o ネットワークでつなぐNetwork Numberからのネットワーク要素o MappingのIPの特定のイメージの支給、所有者、IPあて先ブロックのハイレベルのルーティング方針のo Storageと「階級のない」ネットワークアドレス形式のAS情報o Supportの委譲のプロバイダーなどo Support
Johannsen, Mansfield, Kosters & Sataluri [Page 2] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[2ページ]RFC1608IP情報
o Provision of several organizational images of a network
o ネットワークのいくつかの組織的なイメージの支給
It may be noted that the document basically consists of two parts. In the first part, an IP specific extension of the general framework "Charting networks in the Directory" [1] is given. Objects defined by the application of this framework are related to IP numbers. An IP namespace is defined in the second part of this paper, referring to IP network elements defined at the beginning.
ドキュメントが2つの部品から基本的に成ることに注意されるかもしれません。 最初の部分では、一般的なフレームワークのIPの特定の拡大「ディレクトリでネットワークを図にします」[1]を与えます。 このフレームワークのアプリケーションで定義されたオブジェクトはIP番号に関連します。 IP名前空間はこの紙の第二部で定義されます、始めに定義されたIPネットワーク要素を示して。
2. IP images of networks
2. ネットワークのIPイメージ
As defined in [1], networks are modeled as a set of subnetworks and nodes, called network elements in the remainder. To obtain a particular view of a network element, images were introduced. Below, images of network elements for an IP specific view are defined. Please note that images contain references to underlying physical information about elements.
[1]で定義されるように、ネットワークは1セットのサブネットワークと残りにおけるネットワーク要素と呼ばれるノードとしてモデル化されます。 ネットワーク要素の特定の意見を得るために、イメージは紹介されました。 以下では、IPの特定の視点のためのネットワーク要素のイメージが定義されます。 イメージは要素の基本的な物理的な情報の参照を含んでいます。
In the remainder, ipStringSyntax is used as attribute type for all attributes that are to hold an IP number. Currently, there are two definitions for a syntax like this:
残りでは、ipStringSyntaxはすべての属性のためのIP番号を保持することになっている属性タイプとして使用されます。 現在、このような構文のための2つの定義があります:
o IpAddress as of [5]
o ip as of [6]
o [5]現在oがipするIpAddress[6]
It is suggested to use CaseIgnoreStringSyntax for implementations for the time being with the convention to use the ordinary IP syntax. Nevertheless, an OID has been reserved for ipStringSyntax (see Appendix).
それは、普通のIP構文を使用するのに当分の間実装のためのCaseIgnoreStringSyntaxをコンベンションと共に使用するために示されます。 それにもかかわらず、OIDはipStringSyntaxのために予約されました(Appendixを見てください)。
2.1 IP network image
2.1 IPネットワークイメージ
IP network image is one application of network images and therefore inherits the networkImageClass. This class is given below for reference only, its definition can be found in [1].
IPネットワークイメージは、ネットワークイメージの1つのアプリケーションであり、したがって、networkImageClassを引き継ぎます。 参照だけのためにこのクラスを以下に与えて、[1]で定義を見つけることができます。
networkImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
MAY CONTAIN
externalGateway :: distinguishedNameSyntax,
/* points to one or more nodes that act
as gateway for the protocol application
this image refers to */
ImageCommunicationObjectのnetworkImageオブジェクトクラスサブクラスはexternalGatewayを含むかもしれません:、: distinguishedNameSyntax、プロトコルアプリケーションのためにゲートウェイとしてこのイメージを機能させる1つ以上のノードへの/*ポイントは*/について言及します。
An IP network combines all network elements that have a common IP network number. Presently, IP network numbers fall into one of the classes A, B, or C. However, sub- and supernetworking is already done broadly, and classless networks numbers are expected to be assigned
IPネットワークは一般的なIPネットワーク・ナンバーを持っているすべてのネットワーク要素を結合します。 そして、現在IPネットワーク・ナンバーがクラスのA、B、またはC.Howeverの1つになる、サブ、「スーパー-ネットワーク」は割り当てられる数が予想される既に広くして、階級のないネットワークです。
Johannsen, Mansfield, Kosters & Sataluri [Page 3] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[3ページ]RFC1608IP情報
soon. [2] proposes to assign bitwise contiguous blocks of class-C- addresses to all networks with more than 255 nodes. The definition of IP network, therefore, is always related to common network number and network mask.
すぐ。 [2]は、提案します。案配は255以上のノードで隣接のブロックのクラスC-アドレスをすべてのネットワークにbitwiseします。 したがって、IPネットワークの定義はいつも一般的なネットワーク・ナンバーとネットワークマスクに関連します。
IP networks have a very close relationship to the Domain Name System. Several attributes are introduced to take care of these relations. Though we do not intend to abolish the existing DNS service, the schema defined here is able to provide the mapping IP number to domain name and vice versa.
IPネットワークには、ドメインネームシステムとの非常に親密な関係があります。 これらの関係の世話をするためにいくつかの属性を導入します。 私たちは既存のDNSサービスを撤廃しないつもりですが、ここで定義された図式は逆もまた同様にマッピングIP番号をドメイン名に提供できます。
An IP network image object as defined below is intended to provide technical and administrative data for one IP network. Attributes hold information that a NIC-WHOIS server would reveal for the network, and more.
以下で定義されるIPネットワークイメージオブジェクトが1つのIPネットワークのための技術的で管理のデータを提供することを意図します。 属性はNIC-WHOISサーバがネットワーク、およびその他で明らかにする情報を保持します。
ipNetworkImage OBJECT CLASS
SUBCLASS of NetworkImage
MUST CONTAIN
ipNetworkImageName :: CaseIgnoreString,
/* common name */
ipNwNumber :: IPStringSyntax,
/* the IP network number for
this (sub)network */
ipNwMask :: IPStringSyntax
/* mask that applies to ipNwNumber
in order to define classless
network number; also used for routing */
NetworkImageのipNetworkImageオブジェクトクラスサブクラスはipNetworkImageNameを含まなければなりません:、: CaseIgnoreString、/*コモン名前*/ipNwNumber:、: IPStringSyntax、IPがネットワークでつなぐ/*はこの(潜水艦)ネットワーク*/ipNwMaskのために以下に付番します: 階級のないネットワーク・ナンバーを定義するためにipNwNumberに申し込まれるIPStringSyntax/*マスク。 また、ルーティング*/のために、使用されます。
MAY CONTAIN
/* DNS related info ; e.g. - */
associatedDomain :: CaseIgnoreStringSyntax,
/* the domain name associated to this IP network;
As there is not always a 1:1 mapping between traditional
IP numbers and domain names, the name given here
should contain the "closest match".
1) (sub)network does not have a domain name
of its own, but is part of a bigger domain:
take name of that domain
2) network is divided into several domains,
therefore having more than one domain name:
list all of them.
Note: a reverse mapping of domain names to
networks/nodes can be achieved by a modified
implementation of RFC1279 */
inAddrServer :: DistinguishedNameSyntax,
/* refers to the ipNodeImageObject of the
inaddr Server that holds information about
MAY CONTAIN/*DNSはインフォメーションについて話しました。 例えば、--*/associatedDomain:、: CaseIgnoreStringSyntax、ドメイン名がこのIPネットワークに関連づけた/*。 伝統的なIP番号とドメイン名の間に1:1マッピングがいつもでないあるとき、ここの付与という名前は「最も近いマッチ」を含むべきです。 1) (潜水艦)ネットワークは、それ自身のドメイン名を持っていませんが、より大きいドメインの一部です: そのドメイン2) いくつかのドメインに分割されて、したがって1つ以上のドメイン名を持っているネットワークの名前を取ってください: それらを皆、記載してください。 以下に注意してください。 RFC1279*/inAddrServerの変更された実装はネットワーク/ノードへのドメイン名の逆のマッピングを達成できます:、: DistinguishedNameSyntax、/*は周囲に情報を保持するinaddr ServerのipNodeImageObjectについて言及します。
Johannsen, Mansfield, Kosters & Sataluri [Page 4] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[4ページ]RFC1608IP情報
this network */
/* routing policy; e.g. - */
asNumber :: integerStringSyntax,
/* number of Autonomous System this network belongs to */
acceptedUsagePolicy :: caseIgnoreStringSyntax,
/* semantics to be defined */
/* Any other - */
provider :: DistinguishedNameSyntax,
/* points to network provider */
onlineDate :: uTCTimeSyntax
/* date when network got connected to the Internet */
このネットワーク*//*ルーティング方針。 例えば、--*/asNumber:、: integerStringSyntax、これがネットワークでつなぐAutonomous Systemの/*数は*/acceptedUsagePolicyに属します:、: caseIgnoreStringSyntax、定義された*//*である/*意味論、いかなる他の--*/プロバイダー:、: DistinguishedNameSyntax、/*はネットワーク内の提供者*/onlineDateに以下を指します: ネットワークがインターネット*/に接続されたとき、uTCTimeSyntax/*はデートします。
2.2 IP node image
2.2 IPノードイメージ
If a node in the network is running the IP protocol, an ipNodeImageObject should be created for this node. This image is a subclass of nodeImageClass and holds IP specific information. The nodeImageClass is given below for reference only, its definition can be found in [1].
ネットワークにおけるノードがIPプロトコルを実行しているなら、ipNodeImageObjectはこのノードのために作成されるべきです。 このイメージは、nodeImageClassのサブクラスであり、IP特殊情報を保持します。 参照だけのためにnodeImageClassを以下に与えて、[1]で定義を見つけることができます。
nodeImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
/* no attributes common for all nodeImages have been
defined yet */
nodeImage OBJECT CLASS SUBCLASS、ImageCommunicationObject/*では、すべてのnodeImagesのためのどんな属性コモンも定義されるのにもかかわらずの、*/ではありません。
An ipNodeImage is used to obtain technical and administrative information on a host. The object is defined as follows:
ipNodeImageが得るのにおいて使用されている、技術的である、そして、ホストに関する管理情報。 オブジェクトは以下の通り定義されます:
ipNodeImage OBJECT CLASS
SUBCLASS of NodeImage
MUST CONTAIN
ipNodeName :: CaseIgnoreString
/* common name, it is advised to use
the hostname for this purpose */
MAY CONTAIN
protocol :: CaseIgnoreString,
/* name and version of IP protocol running */
domainName :: CaseIgnoreString,
/* the complete domain name of this node;
CNAMEs can be stored additionally to the
DNS A record name;
further relationships, like MX record entries,
should be taken care of by the domain name tree
according to RFC 1279 */
NodeImageのipNodeImageオブジェクトクラスサブクラスはipNodeNameを含まなければなりません:、: この目的*にホスト名を使用するようにアドバイスされます。CaseIgnoreString/*一般名、/MAY CONTAINは以下について議定書の中で述べます: CaseIgnoreString、/*名前、およびIPのバージョンは走り*/domainNameについて議定書の中で述べます:、: CaseIgnoreString、/*、このノードの完全なドメイン名。 さらに、DNS A記録名としてCNAMEsを保存できます。 MXがエントリーを記録するようにRFC1279*/に従って、さらなる関係はドメイン名木によって世話をされるべきです。
Johannsen, Mansfield, Kosters & Sataluri [Page 5] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[5ページ]RFC1608IP情報
2.3 IP network interface image
2.3 IPネットワーク・インターフェースイメージ
The most important IP related information of a node (its IP addresses) is registered with ipNetworkInterfaceImageObjects. This picture is accurate as a node can have several IP addresses, but at most one per interface. Furthermore, it shows clearly the relationship between interface and neighboring IP network.
ノード(IPアドレス)の最も重要なIP関連情報はipNetworkInterfaceImageObjectsに登録されます。 この画像はノードがいくつかのIPアドレスを持つことができますが、ほとんどの1インタフェースあたり1つにおいて正確です。 その上、それは明確にインタフェースと隣接しているIPネットワークとの関係を示しています。
IpNetworkInterfaceImage is a subclass of networkInterfaceImageClass. The networkInterfaceImageClass is given below for reference only, its definition can be found in [1]. Note that for ipNetworkInterfaceImage all references are drawn in the context of IP, i.e., networkInterfaceAddress becomes an IP address and connectedNetwork points to an ipNetworkImageObject.
IpNetworkInterfaceImageはnetworkInterfaceImageClassのサブクラスです。 参照だけのためにnetworkInterfaceImageClassを以下に与えて、[1]で定義を見つけることができます。 すなわち、networkInterfaceAddressはIPアドレスになります、そして、ipNetworkInterfaceImageに関して、すべての参照がIPの文脈で引き起こされることに注意してください、そして、connectedNetworkはipNetworkImageObjectを示します。
networkInterfaceImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
MAY CONTAIN
networkInterfaceAddress :: caseIgnoreStringSyntax,
/* this interface's address in the context the
image refers to, e.g. IP number, NSAP */
connectedNetwork :: distinguishedNameSyntax
/* pointer to networkImageObject that describes
the network this interface is attached to in terms
of the protocol or application the images
indicates */
ImageCommunicationObjectのnetworkInterfaceImageオブジェクトクラスサブクラスはnetworkInterfaceAddressを含むかもしれません:、: caseIgnoreStringSyntax、インタフェースのこのものが中でイメージが示す文脈を扱う/*、例えば、IP番号、NSAP*/connectedNetwork:、: これが連結するネットワークについて説明するnetworkImageObjectへのdistinguishedNameSyntax/*指針はプロトコルかアプリケーションで付いて、イメージが*/を示すということです。
Additionally, ipNetworkInterfaceImageObject has the following properties:
さらに、ipNetworkInterfaceImageObjectには、以下の特性があります:
ipNetworkInterfaceImage OBJECT CLASS
SUBCLASS of NetworkInterfaceImage
MUST CONTAIN
ipNetworkInterfaceName :: CaseIgnoreStringSyntax
/* It is suggested that the interface name
is derived from the name of the logical
device this interface represents for the
operating system, e.g. le0, COM1 */
MAY CONTAIN
ipNwMask :: IPStringSyntax
/* mask that applies to networkInterfaceAddress for
routing of packets to nodes on the connected
(broadcast) network;
Note: This is only a fraction
of the routing table information
for this interface, namely for one hop. */
NetworkInterfaceImageのipNetworkInterfaceImageオブジェクトクラスサブクラスはipNetworkInterfaceNameを含まなければなりません:、: CaseIgnoreStringSyntax/、*存在というこれが連結する論理的なデバイスの名前から導いているインタフェース名がオペレーティングシステム、例えば、le0、COM1*/5月のCONTAIN ipNwMaskのために以下を表すことが提案されます: ノードへのパケットのルーティングのために接続(放送)ネットワークでnetworkInterfaceAddressに申し込まれるIPStringSyntax/*マスク。 以下に注意してください。 これはすなわち、このインタフェースのための経路指定テーブル情報の部分、1つのホップのためだけのものです。 */
Johannsen, Mansfield, Kosters & Sataluri [Page 6] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[6ページ]RFC1608IP情報
2.4 Autonomous Systems
2.4 自律システム
Autonomous Systems (AS) are defined in asObject which is a subclass of imageCommunicationObject. It provides technical and administrative information of an AS. Furthermore, routing policies can be stored with the AS object. The definition of the AS object is aligned with the corresponding database object defined in [3].
自治のSystems(AS)はimageCommunicationObjectのサブクラスであるasObjectで定義されます。 それは技術的に提供されます。そして、ASに関する管理情報。 その上、ASオブジェクトでルーティング方針を保存できます。 ASオブジェクトの定義は[3]で定義される対応するデータベースオブジェクトに並べられます。
as OBJECT CLASS
SUBCLASS of ImageCommunicationObject
MUST CONTAIN
asNumber :: IntegerStringSyntax
オブジェクトのクラスとして、ImageCommunicationObjectのサブクラスはasNumberを含まなければなりません:、: IntegerStringSyntax
MAY CONTAIN
asName :: CaseIgnoreStringSyntax,
/* if there is a name different from AS */
asIn :: CaseIgnoreStringSyntax,
/* accepted routes from other AS */
/* for syntax and semantics refer [3] */
asOut :: CaseIgnoreStringSyntax,
/* generated routes announced to others */
/* for syntax and semantics refer [3] */
asDefault ::CaseIgnoreStringSyntax,
/* how default routing is handled */
/* for syntax and semantics refer [3] */
asGuardian :: DistinguishedNameSyntax, */
/* DN of guardian of this AS */
lastModifiedDate :: UTCtimeSyntax */
/* important as routes change frequently */
asNameを含むかもしれません:、: CaseIgnoreStringSyntax、*そこであるなら、/はAS*/asInと異なった名前です:、: CaseIgnoreStringSyntax、構文と意味論のためのもう一方AS*//*からの/*受け入れられたルートは[3] */asOutを参照します:、: CaseIgnoreStringSyntax、他のもの*//*に発表されたルートが構文のために生成された/*、および意味論は[3] */asDefaultを参照します:、:CaseIgnoreStringSyntax、デフォルトルーティングが構文と意味論のための扱われた*//*である/*は[3] */asGuardianを参照します:、: DistinguishedNameSyntax、このAS*/lastModifiedDateの保護者の*//*DN:、: ルートとして重要なUTCtimeSyntax*//*は頻繁に*/を変えます。
Note that routing policies for an Autonomous System are represented
by the {asIn, asOut} attributes of asObject. Due to performance
constraints of present X.500 technology, it will probably not be used
directly by routers for dynamic routing. However, it certainly can
be used in network management systems to determine the allowed paths
[i.e., in accordance with published policies] between two networks.
This will be useful in finding alternate paths, and evaluating the
connectivity of networks.
Autonomous Systemのためのルーティング方針があるというメモが表した、asIn、asOut、asObjectの属性。 現在のX.500技術の性能規制のため、それはダイナミックルーティングにたぶん直接ルータによって使用されないでしょう。 しかしながら、確かに、2つのネットワークの間で許容経路を決定すること[すなわち、広められた方針によると]にネットワーク管理システムでそれを使用できます。 これは代替パスを見つけて、ネットワークの接続性を評価する際に役に立ちます。
3. Number assignment information
3. 数の課題情報
In the following, Directory objects have been defined to represent IP and AS (Autonomous System) namespace in the Directory. Their purpose is to provide
以下では、ディレクトリオブジェクトは、ディレクトリにおけるIPとAS(自治のSystem)名前空間を表すために定義されました。 それらの目的は提供することです。
o mapping from IP number to IP network element (network or node)
o mapping from IP number to AS number and vice versa
o assignment and delegation information
o IP番号からIPまで逆もまた同様です、IP番号からAS番号とoまで課題を写像するネットワーク要素(ネットワークかノード)oと委譲情報を写像します。
Johannsen, Mansfield, Kosters & Sataluri [Page 7] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[7ページ]RFC1608IP情報
The need for a global, distributed database supporting the objectives arises mainly from distributed IP- and AS-number assignment.
目的が主に起こるグローバルな分散データベースサポートの必要性はIPとAS-数の課題を広げました。
Describing all IP numbers with one of the new objects delegatedBlock, ipGroup and ipReference leads to the desired information. AS number information is stored with the objects asBlock and asReference. Furthermore, all assigned numbers have some properties in common. Therefore, an objectclass assignedNumberClass is introduced. This class exports attributes to delegatedBlock, ipGroup, ipReference, asBlock, and asReference.
新しいオブジェクトのdelegatedBlock、ipGroup、およびipReferenceの1つと共にすべてのIP番号について説明するのは必要な情報に通じます。 AS数の情報はオブジェクトのasBlockとasReferenceと共に保存されます。 その上、すべての規定番号がいくつかの特性が共通です。 したがって、objectclass assignedNumberClassを導入します。 このクラスはdelegatedBlock、ipGroup、ipReference、asBlock、およびasReferenceに属性をエクスポートします。
AssignedNumberClass is defined as follows ("number" always refers to
IP number of delegatedBlock, network, host, and AS number, resp.):
AssignedNumberClassは以下の通り定義されます(「数」はいつもdelegatedBlock、ネットワーク、ホスト、およびAS番号、respのIP番号を示します。):
assignedNumberClass OBJECT CLASS
SUBCLASS of top
MAY CONTAIN
assBy :: DistinguishedNameSyntax,
/* refers to an organization or organizationalRole
that assigned the number to assTo (see below) */
assTo :: DistinguishedNameSyntax,
/* refers to organization or organizationalRole
that the number was assigned to. This does not
imply that assTo "owns" this number now. */
assDate :: uTCTimeSyntax,
/* date of assignment for this number */
nicHandle :: CaseIgnoreStringSyntax,
/* gives the unique ID for a description
related to this number.
format: "handle : nic-domain-name"
example: MAK21 : rs.internic.net */
relNwElement :: DistinguishedNameSyntax,
/* the network element related to this number
(network or node) */
最高5月のCONTAIN assByのassignedNumberClass OBJECT CLASS SUBCLASS:、: DistinguishedNameSyntax、/*はassTo(下を見る)*/assToに数を割り当てた組織かorganizationalRoleについて言及します:、: DistinguishedNameSyntax、/*は数が配属された組織かorganizationalRoleについて言及します。 これは、assToが現在この数を「所有していること」を含意しません。 */は以下をassDateします: uTCTimeSyntax、この数の*/nicHandleのための課題の/*日付:、: CaseIgnoreStringSyntax、/*はこの数に関連する記述のために固有のIDを与えます。以下をフォーマットしてください。 「以下を扱ってください」 「nic-ドメイン名」の例: MAK21: rs.internic.net*/relNwElement:、: DistinguishedNameSyntax、ネットワーク要素がこの数(ネットワークかノード)の*/に関係づけた/*
3.1 Delegated Block object
3.1 代表として派遣されたBlockは反対します。
This object provides information on a block of IP addresses delegated to some local-authority or service provider. Only contiguous blocks can be represented with the following schema. If an organization (say, a NIC) has been assigned several IP network numbers which do not form a contiguous block, it might want to use a different form of representing that fact (e.g., using imageNetworks). The delegatedBlock object holds lower and upper bounds of the block.
このオブジェクトは何らかの地方公共団体かサービスプロバイダーへ代表として派遣された1IPアドレスのブロックの情報を提供します。 以下の図式で隣接のブロックしか表すことができません。 隣接のブロックを形成しないいくつかのIPネットワーク・ナンバーが組織(たとえば、NIC)に配属されたなら、それはその事実を表す異なったフォームを使用したがっているかもしれません(例えば、imageNetworksを使用します)。 船倉が下げるdelegatedBlockオブジェクトとブロックの上限。
Note that the above does not make any assumption about the network masks being constrained by byte boundaries. We can thus represent subnetting within a "network (number)" that often happens within an
上記がネットワークに関する少しの仮定もバイト境界によって抑制されるマスクにしないことに注意してください。 その結果、私たちはそれがしばしば起こる「ネットワーク(数)」の中にサブネッティングを表すことができます。
Johannsen, Mansfield, Kosters & Sataluri [Page 8] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[8ページ]RFC1608IP情報
organization in the same framework.
同じフレームワークにおける組織。
This schema does lead to some granularity in the otherwise flat IP- number space. Further, the granularity is significant as it may be used to identify the administrator of the block - a service provider or a domain manager. E.g., it fits well into the schema of aggregating networks for routing purposes as has been proposed in [4].
この図式はそうでなければ、平坦なIP数のスペースにおける何らかの粒状につながります。 さらに、それがブロックの管理者を特定するのに使用されるかもしれないので、粒状は重要です--サービスプロバイダーかドメインマネージャ。 例えば、それは[4]で提案されたルーティング目的のためにネットワークに集める図式によく収まります。
The object delegatedBlock is of the form:
オブジェクトdelegatedBlockはフォームのものです:
delegatedBlock OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
delegatedBlockName :: caseIgnoreStringSyntax,
lowerBound :: IPStringSyntax,
/* smallest IP address belonging to the
block, e.g. 195.100.0.0 */
upperBound :: IPStringSyntax
/* highest IP address belonging to the
block, e.g. 195.103.255.255 */
AssignedNumberClassのdelegatedBlockオブジェクトクラスサブクラスはdelegatedBlockNameを含まなければなりません:、: caseIgnoreStringSyntax、lowerBound:、: IPStringSyntax、ブロックに属す/*最も小さいIPアドレス、例えば、195.100.0.0*/upperBound:、: IPStringSyntax/*最も高いIPは、ブロック、例えば、195.103に属すのが、.255.255*/であると扱います。
The attribute relNwElement (inherited from AssignedNumberClass) can point to a networkImage covering all networks within the block if this makes sense.
これが理解できるなら、属性relNwElement(AssignedNumberClassから、世襲する)はブロックの中にすべてのネットワークをカバーするnetworkImageを示すことができます。
3.2 IP Group object
3.2 IP Groupは反対します。
This object provides information for an IP network number. Its purpose is basically only to
このオブジェクトはIPネットワーク・ナンバーのための情報を提供します。 目的が基本的にそうである、唯一
o show that the number has been assigned, and
o provide a reference to the descriptive ipNetworkObject for
this network.
o ○ 数を割り当ててあるのを示してください、そして、描写的であるipNetworkObjectのこのネットワークの参照を前提としてください。
Regardless of the actual value of x, IP group objects may exist for IP numbers x.0.0.0, x.y.0.0 and x.y.z.0. This approach includes "classical" class-A, -B and -C network addresses as well as any kind of super- and subnetworking.
xの実価にかかわらず、IP群対象はIP番号x.0.0.0、x.y.0.0、およびx.y.z.0のために存在するかもしれません。 そして、このアプローチがいずれもと同様に「古典的な」クラスA、-B、および-Cネットワーク・アドレスをちょっと含んでいる、超、「副-ネットワーク」。
The IP group object is a subclass of assignedNumberClass. The attribute relNwElement points to an ipNetworkImage as defined above.
IP群対象はassignedNumberClassのサブクラスです。 属性relNwElementは上で定義されるようにipNetworkImageを示します。
ipGroup OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
ipGroupName :: IPStringSyntax,
/* IP number; x.0.0.0 or x.y.0.0 or x.y.z.0
AssignedNumberClassのipGroupオブジェクトクラスサブクラスはipGroupNameを含まなければなりません:、: IPStringSyntax、/*IP番号。 x.0.0.0、x.y.0.0またはx.y.z.0
Johannsen, Mansfield, Kosters & Sataluri [Page 9] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[9ページ]RFC1608IP情報
where x, y, z in 1..255 */
ipNwMask :: IPStringSyntax
/* mask that applies to all numbers
within the group; used to define
classless networking; */
どこ、x、y、1におけるz255*/ipNwMask:、: グループの中のすべての数に適用されるIPStringSyntax/*マスク。 以前はよく階級のないネットワークを定義していました。 */
3.3 IP Reference object
3.3 IP Referenceは反対します。
There is one IP reference object for each IP host address. The purpose of this object is to
それぞれのIPホスト・アドレスあたり1個のIP参照物体があります。 オブジェクトがあるこの目的
o tell that this IP number is already assigned to a node
o give a pointer to the related ipNodeImageObject
o 数が既に配属されるこのIPが関連するipNodeImageObjectへの指針をノードoに与えると言ってください。
The IP reference object is a subclass of assignedNumberClass. The attribute relNwElement points to an ipNodeImage.
IP参照物体はassignedNumberClassのサブクラスです。 属性relNwElementはipNodeImageを示します。
ipReference OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
ipReferenceName :: IPString
/* value is always IP address */
AssignedNumberClassのipReferenceオブジェクトクラスサブクラスはipReferenceNameを含まなければなりません:、: いつもIPString/*値はIPアドレス*/です。
3.4 AS block object
3.4ASブロックして、反対してください。
The AS block object is used to show delegation of blocks of AS numbers to regional registries. This is similar to delegatedBlock of ipNetwork numbers.
AS塊状物は、ブロックのAS番号の委譲を地方の登録に案内しているのに使用されます。 これはipNetwork番号のdelegatedBlockと同様です。
asBlock OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
asBlockName :: caseIgnoreStringSyntax,
asLowerBound :: integerStringSyntax,
asUpperBound :: integerStringSyntax
AssignedNumberClassのasBlockオブジェクトクラスサブクラスはasBlockNameを含まなければなりません:、: caseIgnoreStringSyntax、asLowerBound:、: integerStringSyntax、asUpperBound:、: integerStringSyntax
An AS block will comprise several consecutive AS numbers. Objects to describe these numbers may be stored in asObjects.
ASブロックはいくつかの連続したAS番号を包括するでしょう。 これらの数について説明するオブジェクトはasObjectsに保存されるかもしれません。
3.5 AS reference object
3.5 AS参照物体
An AS reference object is used to show that an Autonomous System number has been assigned (and thus can not be given to somebody else). Similar to ipGroup, asReference does not contain technical details about an autonomous system itself but rather points (with relNwElement) to a descriptive asObject.
AS参照物体は、Autonomous System番号を割り当ててあるのを(そして、その結果、他の誰かに与えることができません)示すのに使用されます。 ipGroupと同様です、asReferenceは自律システム自体に関する技術的詳細ではなく、むしろポイント(relNwElementと)を描写的であるasObjectに含んでいます。
Johannsen, Mansfield, Kosters & Sataluri [Page 10] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[10ページ]RFC1608IP情報
asReference OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
asNumber :: integerStringSyntax
AssignedNumberClassのasReferenceオブジェクトクラスサブクラスはasNumberを含まなければなりません:、: integerStringSyntax
4. Directory tree
4. ディレクトリツリー
root
|
+-------------+---------------+
| |
c= o=Internet
| |
+-----+------+ +------+-------+
| | | |
ipNw= as= dbl= asB=
| | |
ipNd= ipG= asRef=
| |
ipNwIf= ipRef=
根| +-------------+---------------+ | | c=oはインターネットと等しいです。| | +-----+------+ +------+-------+ | | | | =dbl= asB=としてのipNw=| | | ipNd= ipG= asRef=| | ipNwIf= ipRef=
Figure 1: Overall relationship of objects.
図1: オブジェクトの総合的な関係。
4.1 IP image objects
4.1 IPイメージオブジェクト
According to [1], IP image entries will be stored underneath the organization / organizationalUnit entry of the entity responsible for that network. The case that such an entry does not yet exist in the white-pages pilot is discussed in 4.4 below.
[1]によると、IPイメージエントリーはそのネットワークに原因となる実体の組織/organizationalUnitエントリーの下に保存されるでしょう。 そのようなエントリーがまだそうしていないケースは存在しています。ホワイトページでは、以下で4.4でパイロットについて議論します。
4.2 AS objects
4.2ASが反対します。
The technical and administrative description of an AS is basically maintained by NICs, network providers, or other special organizations. It is suggested that these organizations build a subtree for information on AS which they are responsible for.
ASの技術的で管理の記述はNICs、ネットワーク内の提供者、または他の特殊機関によって基本的に維持されます。 これらの組織が彼らが原因となるASの情報のために下位木を築き上げることが提案されます。
4.3 Namespace objects
4.3 名前空間オブジェクト
The new IP namespace objects build a single tree in the Directory. It is suggested that this tree will have a root of type organizationalUnit within @o=Internet@ou=Network Information.
新しいIP名前空間オブジェクトはディレクトリで単一の木を建てます。 この木が@o= Internet@ou の中のタイプorganizationalUnitの根がネットワーク情報との等しさにすることが提案されます。
objectClass= organizationalUnit
organizationalUnitName= IP networks
description= root of IP number tree
objectClass= organizationalUnit organizationalUnitName=IPはIP数の木の記述=根をネットワークでつなぎます。
Johannsen, Mansfield, Kosters & Sataluri [Page 11] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[11ページ]RFC1608IP情報
The tree is built under an administrative and an implementational view. Nowadays, network numbers usually are assigned to organizations by (national) Network Information Centers (NIC) which themselves have got a block of IP network numbers assigned from another authority (e.g., IR at top level). This concept of delegated blocks falling apart in smaller delegated blocks and IP network numbers is used to model the Directory tree. Thus, an ipGroup object is always subordinate of a delegated block object (namely the delegated block including this IP number). Network numbers that were directly assigned by a top-level authority, i.e., have not been object of a delegation to a local assigning authority, will all be at one level in the Directory. Already today, however, we find many delegations within the traditional class A-, B- and C-addresses. Such a delegation is represented by a delegated block object, having the assigned IP network numbers as subordinates. Also, part of the block can be further delegated to another authority, leading to another delegated block object within the parent delegated block's tree. Usually, subordinates of ipGroup objects are ipReferences, i.e., single IP addresses as assigned to nodes. To support subnetworking, it is also allowed to divide ipGroups into several subnetwork ipGroups, each representing an IP subnetwork. In such cases, subnetwork numbers are given as subordinates to the assigned IP network number. Network masks clarify what the subnetwork addresses are.
木は管理視点とimplementational視点の下で建てられます。 この頃は、通常、ネットワーク・ナンバーは別の権威(例えば、トップレベルにおけるIR)から1ブロックのIPネットワーク・ナンバーを自分たちで割り当てさせた(国家)のネットワーク情報センターズ(NIC)によって組織に配属されます。 よりわずかな代表として派遣されたブロックとIPネットワーク・ナンバーでバラバラに壊れる代表として派遣されたブロックのこの概念は、ディレクトリ木をモデル化するのに使用されます。 したがって、いつもipGroupオブジェクトは代表として派遣された塊状物(すなわち、このIP番号を含む代表として派遣されたブロック)の部下です。 すなわちトップレベル権威によって直接割り当てられたネットワーク・ナンバーはローカルの割り当て権威への委譲のオブジェクトでなく、ディレクトリにおける1つのレベルにすべてあるでしょう。 しかしながら、既に、今日、私たちは伝統的なクラスA、B、およびC-アドレスの中で多くの委譲を見つけます。 部下として割り当てられたIPネットワーク・ナンバーを持っていて、そのような委譲は代表として派遣された塊状物によって表されます。 また、さらにブロックの一部を別の権威へ代表として派遣することができて、親の中で別の代表として派遣された塊状物に通じるのはブロックの木を代表として派遣しました。 通常、ipGroupオブジェクトの部下はipReferences、すなわち、ノードに割り当てられるただ一つのIPアドレスです。 「副-ネットワーク」をサポートするために、また、それぞれIPサブネットワークを表して、それはipGroupsを数個サブネットワークipGroupsに分割できます。 そのような場合、割り当てられたIPの部下が数をネットワークでつなぐとき、サブネットワーク番号を与えます。 ネットワークマスクは、サブネットワークアドレスが何であるかをはっきりさせます。
ou=IP networks
|
+-------------------+-----------------------+
/ | \
dbl=150.0.0.0-150.100.0.0
|
+-------------------+-----------------------+
/ | \
ipG=150.80.0.0
|
+-------------------+-----------------------+
/ | \
ipG=150.80.240.0
|
+-------------------+-----------------------+
/ | \
ipRef=150.80.254.1 ipRef=150.80.254.2 ipRef=150.80.254.3
ouはIPネットワークと等しいです。| +-------------------+-----------------------+ / | dbl=150.0.0.0-150.100.0.0円| +-------------------+-----------------------+ / | ipG=150.80.0.0円| +-------------------+-----------------------+ / | ipG=150.80.240.0円| +-------------------+-----------------------+ / | ipRef=150.80.254.1ipRef=150.80.254.2ipRef=150.80.254.3円
Figure 2: Example population of IP namespace tree according
to delegation and subnetworking.
図2: 委譲と「副-ネットワーク」に従ったIP名前空間木の例の人口。
For some applications, the separation of ipImage (description of the network) and ipGroup (description of the namespace element) will bear
いくつかのアプリケーション、ipImage(ネットワークの記述)と(名前空間要素の記述)が持っているipGroupの分離のために
Johannsen, Mansfield, Kosters & Sataluri [Page 12] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[12ページ]RFC1608IP情報
disadvantages in the look-up procedure. In that case one might think of combining both object classes with the aim to provide one object describing administrative and technical data for an IP network.
ルックアップ手順における損失。 その場合、人は、IPネットワークのための管理的、そして、技術的なデータについて説明する1個のオブジェクトを提供するために両方のオブジェクトのクラスを目的に合併することを考えるかもしれません。
As Autonomous Systems are an additional namespace to the existing IP number space, they should go into a separate subtree. It is suggested that this is an organizationalUnit within @o=Internet@ou=Network Information.
Autonomous Systemsが既存のIP数のスペースへの追加名前空間であるので、彼らは別々の下位木を調べるべきです。 これがネットワーク@o= Internet@ou =情報の中のorganizationalUnitであると示唆されます。
objectClass= organizationalUnit
organizationalUnitName= AS numbers
description= root of Autonomous System number space
objectClass= organizationalUnit organizationalUnitName= AS数の記述はAutonomous System数のスペースの根と等しいです。
Similar to blocks of IP network numbers, blocks of AS numbers are sometimes delegated to another registry. This is expressed by asBlock objects. These objects come below the root of the AS number space. All AS numbers falling into such a block are stored as subordinates of the block. An AS block may have smaller AS blocks underneath if delegation is extended.
ブロックのIPネットワーク・ナンバーと同様であることで、ブロックのAS番号は時々別の登録に委任されます。 これはasBlockオブジェクトによって言い表されます。 これらのオブジェクトはAS数のスペースの根より下であるまで来ます。 そのようなブロックに落ちるすべてのAS番号がブロックの部下として保存されます。 委譲が拡張されているなら、ASブロックは下部によりわずかなASブロックを持っているかもしれません。
4.4 Relationship to organizational entries
4.4 組織的なエントリーとの関係
Organizational information (i.e., white-pages-like information about an organization, its departments and employees) occurs at several places in the network DIT - [org of IP-Number, org of AS-Number, org of Admin- contact, However, it will be basically mastered [administered, maintained] by the organization itself in the Directory Management Domain (DMD) over which the organization has the authority. This gives rise to some tricky problems - a typical example is that of a NIC which holds the AS, DNS, IP, ... subtrees of the DIT.
組織的な情報(すなわち、その組織、部、および従業員の白いページのような情報)は処々方々にネットワークDITで現れます--IP-数のorg、AS-数のorgはAdminをorgします。接触、However、それは基本的に管理されていた状態でマスタリングされるでしょう、組織が権威を持っているディレクトリManagement Domain(DMD)での組織自体によって維持されて; これはいくつかの微妙な問題をもたらします--典型的な例はASを持っているNICのものです、DNS、IP… DITの下位木。
A good strategy would avoid explicit duplication of information. By explicit duplication of information we understand information being duplicated outside the directory framework, e.g., by having several master entries for one and the same piece of information. The only way to avoid duplication would be to have relevant entries point to the pertinent organizational entry for organizational information. But since
優れた戦略は情報の明白な重複を避けるでしょう。 情報の明白な複製で、私たちは、情報がディレクトリフレームワークの外でコピーされるのを理解しています、例えば、全く同じ情報のためのいくつかのマスターエントリーを持っていることによって。 重複を避ける唯一の方法は関連エントリーに組織的な情報のための適切な組織的なエントリーを示させるだろうことです。 以来
o most organizations do not, as yet, have an entry in the DIT and
o the reliability of the access to an organizations DIT when
stored in a remote DSA cannot be taken for granted,
o ○ ほとんどの組織はまだDITにエントリーを持っていません、そして、リモートDSAに保存される場合、組織DITへのアクセスの信頼性は当然のことと思うことができません。
the following framework is adopted to accommodate the conflicting requirements /conditions.
以下のフレームワークは、競合する要求事項/状態を収容するために採用されます。
Johannsen, Mansfield, Kosters & Sataluri [Page 13] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[13ページ]RFC1608IP情報
o A copy of all the necessary organization-info is retained
at the NICs DSA. Since only the necessary info will be kept
the NIC will not be burdened to act as the repository of the
organizations DIT. These objects may be kept in a separate
subtree of affiliated-organizations [organizations
affiliated to the NIC]. Though the affiliated organizations node
does not really represent a locality, it is suggested to define
the node as objectClass locality. This does not break the
Directory schema when entries of organizations shall become
subordinate to the NICs organization's entry.
o すべての必要な組織インフォメーションのコピーはNICs DSAで保有されます。 必要なインフォメーションだけが保たれるとき、NICは、組織の倉庫としてDITを機能させるので、負われないでしょう。 これらのオブジェクトは系統機関[NICに所属する組織]の別々の下位木で保たれるかもしれません。 系統機関ノードは本当に場所を表しませんが、それは、objectClass場所とノードを定義するために示されます。 組織のエントリーがNICs組織のエントリーに下位になるものとするなら、これはディレクトリ図式を破りません。
o The problem of information duplication/consistency will arise when
organizational DITs/DSAs do come into existence. At that stage a
shadowing mechanism which will attempt to maintain the data
consistency may be resorted to. The X.500/ISO 9594(1993)
implementations are expected to provide appropriate shadowing
mechanisms along X.525.
o 組織的なDITs/DSAsが生まれると、情報の複製/一貫性の問題は起こるでしょう。 その段階では、データの一貫性を維持するのを試みるシャドウイングメカニズムは当てにされるかもしれません。 X.500/ISO9594(1993)実装がX.525に沿って適切なシャドウイングメカニズムを提供すると予想されます。
It may be noted that what is suggested is not a duplication of an entire white-pages-like structure at the NIC. It suggests an "affiliated organizations node". The entries under this node will be organization objects with a limited number of attributes, i.e., the attributes to hold the organization info necessary for the NIC: nothing more, nothing less. Operationally, and content wise the NIC DSA will hold exactly the amount of info that is desired by the NIC. When an organization sets up its DSA and when the organization informs the NIC about it, the NIC will set up the shadowing arrangement to obtain info on changes of interest [and forget about it].
示されることが複製でないことに注意されるかもしれない、全体、白、ページのようである、NICの構造。 それは「系統機関ノード」を示します。 このノードの下のエントリーはNICに必要であるとして組織インフォメーションを保持するためにすなわち、限られた数の属性、属性をもって組織物になるでしょう: それ以上何も、何でもないより少なくない。 操作上、内容NIC DSAがちょうどNICによって望まれているインフォメーションの量を保持するのが賢明です。 組織がDSAをセットアップして、組織がそれに関してNICに知らせるとき、NICは、興味がある変化に関するインフォメーションを得るためにシャドウイングアレンジメントをセットアップするでしょう[それを忘れてください]。
It may be emphasized that the entries under affiliated organizations are physical entities [replicated and refined from the Master entries, if and when they exist...] rather than alias entries. If a NIC dislikes the idea of users poring over the entries in the affiliated organizations - appropriate access control can be applied. Though duplication is unavoidable, the proposal attempts to make it transparent, by delegating the responsibility of maintaining the integrity to the Directory.
系統機関の下のエントリーが別名エントリーよりむしろ物理的実体[存在しているなら、Masterエントリーから模写されて、精製される]であると強調されるかもしれません。 --NICがユーザが系統機関におけるエントリーを詳細に調べるという考えが嫌であるなら適切なアクセス管理を適用できます。 複製は避けられないのですが、提案は、それを透明にするのを試みます、ディレクトリに保全する責任を代表として派遣することによって。
This issue is discussed in greater detail in a separate document [7].
別々のドキュメント[7]で詳細によりすばらしいこの問題について議論します。
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Johannsen, Mansfield, Kosters & Sataluri [Page 14] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[14ページ]RFC1608IP情報
6. Authors' Addresses
6. 作者のアドレス
Thomas Johannsen Dresden University of Technology Institute of Communication Technology D-01062 Dresden, GERMANY
コミュニケーションTechnology D-01062ドレスデン(ドイツ)の技術研究所のトーマスヨハンセンドレスデン大学
Phone: +49 351 463-4621 EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
以下に電話をしてください。 +49 351 463-4621 メールしてください: Thomas.Johannsen@ifn.et.tu-dresden.de
Glenn Mansfield AIC Systems Laboratory 6-6-3 Minami Yoshinari, Aoba-ku Sendai 989-32, JAPAN
グレン・マンスフィールド・アイクのSystems研究所6-6-3南Yoshinari、Aoba区仙台989-32(日本)
Phone: +81 22 279-3310 EMail: glenn@aic.co.jp
以下に電話をしてください。 +81 22 279-3310 メールしてください: glenn@aic.co.jp
Mark Kosters Network Solutions, Inc. 505 Huntmar Park Dr. Herndon, VA 22070
ハーンドン、マークKostersネットワークソリューションズ社505Huntmar Park博士ヴァージニア 22070
Phone: +1 703 742-4795 EMail: markk@internic.net
以下に電話をしてください。 +1 703 742-4795 メールしてください: markk@internic.net
Srinivas R. Sataluri AT&T Bell Laboratories Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030
Srinivas R.Sataluri AT&Tベル研究所部屋1C429、Crawfordsコーナー道路Holmdel、101ニュージャージー07733-3030
Phone: +1 908 949-7782 EMail: sri@qsun.att.com
以下に電話をしてください。 +1 908 949-7782 メールしてください: sri@qsun.att.com
Johannsen, Mansfield, Kosters & Sataluri [Page 15] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[15ページ]RFC1608IP情報
References
参照
[1] Mansfield, G., Johannsen, T., and M. Knopper, "Charting Networks
in the X.500 Directory", RFC 1609, AIC Systems Laboratory,
Dresden University, Merit Networks,Inc., March 1994.
[1] マンスフィールドとG.とヨハンセン、T.とM.Knopper、「X.500ディレクトリにおける図にするネットワーク」RFC1609、アイクシステム研究所(ドレスデン大学)はネットワークに値します、株式会社、1994年3月。
[2] Gerich, E., "Guidelines for Management of IP Address Space", RFC
1466, Merit, May 1993.
[2]Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1466)が1993年5月に値するE.。
[3] Bates, T., Jouanigot, J.-M., Karrenberg, D., Lothberg, P., and M.
Terpstra, "Representation of IP Routing Policies in the RIPE
Database", Document ripe-81, RIPE, February 1993.
[3] ベイツ、T.、Jouanigot、J.-M.、Karrenberg、D.、Lothberg、P.、およびM.テルプストラ、「熟しているデータベースにおける、IPルート設定方針の表現」、Documentの熟している81、RIPE(1993年2月)。
[4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: An
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
cisco, MERIT, OARnet, June 1992.
[4] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1338、BARRNet、コクチマス、MERIT、OARnet、6月1992日
[5] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, Performance Systems International, Hughes LAN Systems, May
1990.
[5]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155、国際パフォーマンスSystemsヒューズLAN Systems(1990年5月)
[6] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
RFC 1274, University College London, November 1991.
[6] RFC1274、ユニバーシティ・カレッジロンドン1991年11月のバーカー、P.、S.Kille、および「コサインとインターネットX.500図式」
[7] Mansfield, G., Johannsen, T., and J. Murai, J., "Deployment
Strategy for the Directory in the Internet", AIC Systems
Laboratory, Dresden University, Keio University, Work in
Progress, July 1993.
[7] マンスフィールドとG.とヨハンセン、T.とJ.村井、J.、「インターネットのディレクトリのための展開戦略」アイクシステム研究所(ドレスデン大学、慶応義塾大学)は進行中(1993年7月)で働いています。
Johannsen, Mansfield, Kosters & Sataluri [Page 16] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[16ページ]RFC1608IP情報
Appendix: OID tables
付録: OIDテーブル
This appendix lists object identifiers for object classes and attributes type defined in [1] and this document.
この付録は[1]とこのドキュメントで定義された物のクラスと属性タイプのために物の識別子をリストアップします。
OIDs are given in quipu-oidtable format to make it easy for people to include them into their pilots.
人々が彼らのパイロットに彼らを入れるのを簡単にするように結び縄文字-oidtable形式でOIDsを与えます。
IMPORT from oidtable.gen:
oidtable.genからのIMPORT:
iso: 1 identifiedOrganization: iso.3 dod: identifiedOrganization.6 internet: dod.1 experimental: internet.3 network-objects: experimental.53
iso: 1identifiedOrganization: iso.3dod: identifiedOrganization.6インターネット: dod.1実験的: インターネット.3ネットワーク物: 実験的な.53
-- localoidtable.gen
-- localoidtable.gen
id-nw-oc: network-objects.1 id-nw-at: network-objects.2 id-nw-as: network-objects.3 ipStringSyntax: ip-nw-as.1
イド-nw-oc: ネットワーク物の.1、イドがnwする、: ネットワーク物の.2、イドがnwする、: ネットワーク物の.3ipStringSyntax: ip-nw、-、.1
-- localoidtable.oc
-- localoidtable.oc
# general class definitions # Format is - # Object: OID: SubClassOf: MustHave: MayHave
# 一般的なクラス定義#Formatはそうです--、#Object: OID: SubClassOf: MustHave: MayHave
CommunicationObject: id-nw-oc.1 : top : \
: \
adminContact, technContact, description
CommunicationObject: イド-nw-oc.1: 先端: \ : \adminContact、technContact、記述
PhysicalCommunicationObject: id-nw-oc.2 : CommunicationObject : \
: \
owner, localityName, ICO
PhysicalCommunicationObject: イド-nw-oc.2: CommunicationObject: \ : \所有者(localityName)ICO
ImageCommunicationObject: id-nw-oc.3 : CommunicationObject : \
: \
imageType, imageOf
ImageCommunicationObject: イド-nw-oc.3: CommunicationObject: \ : \imageType、imageOf
# physical communication elements
# 物理的なコミュニケーション要素
network: id-nw-oc.4 : PhysicalCommunicationObject : \
networkName : \
以下をネットワークでつないでください。 イド-nw-oc.4: PhysicalCommunicationObject: \networkName: \
Johannsen, Mansfield, Kosters & Sataluri [Page 17] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[17ページ]RFC1608IP情報
externalGateway, nwType, media, speed, traffic, \
configurationDate, configurationHistory
externalGateway、nwType、メディア、速度、交通、\configurationDate、configurationHistory
node: id-nw-oc.5 : PhysicalCommunicationObject : \
nodeName : \
typeOfMachine, OS
ノード: イド-nw-oc.5: PhysicalCommunicationObject: \nodeName: \typeOfMachine、OS
networkInterface: id-nw-oc.6 : PhysicalCommunicationObject : \
networkInterfaceName : \
networkInterfaceAddress, connectedNetwork
networkInterface: イド-nw-oc.6: PhysicalCommunicationObject: \networkInterfaceName: \networkInterfaceAddress、connectedNetwork
# image communication elements
# イメージコミュニケーション要素
networkImage: id-nw-oc.7 : ImageCommunicationObject : \
: \
externalGateway, speed, traffic, charge
networkImage: イド-nw-oc.7: ImageCommunicationObject: \ : \externalGateway(速度、交通)は充電します。
nodeImage: id-nw-oc.8 : ImageCommunicationObject : \
:
nodeImage: イド-nw-oc.8: ImageCommunicationObject: \ :
networkInterfaceImage: id-nw-oc.9 : ImageCommunicationObject : \
: \
networkInterfaceAddress, connectedNetwork
networkInterfaceImage: イド-nw-oc.9: ImageCommunicationObject: \ : \networkInterfaceAddress、connectedNetwork
# IP image elements
# IPイメージ要素
ipNetworkImage: id-nw-oc.10 : networkImage : \
ipNetworkImageName, ipNwNumber, ipNwMask : \
associatedDomain, inAddrServer, asNumber, \
provider, onlineDate
ipNetworkImage: イド-nw-oc.10: networkImage: \ipNetworkImageName、ipNwNumber、ipNwMask: \associatedDomain、inAddrServer、asNumber、\プロバイダー、onlineDate
ipNodeImage: id-nw-oc.11 : nodeImage : \
ipNodeName : \
protocol, domainName
ipNodeImage: イド-nw-oc.11: nodeImage: \ipNodeName: \プロトコル、domainName
ipNetworkInterfaceImage: id-nw-oc.12 : networkInterfaceImage : \
ipNetworkInterfaceName : \
ipNwMask
ipNetworkInterfaceImage: イド-nw-oc.12: networkInterfaceImage: \ipNetworkInterfaceName: \ipNwMask
as: id-nw-oc.13 : ImageCommunicationObject : \
asNumber : \
asName, asIn, asOut, asDefault, asGuardian, \
lastModifiedDate
: イド-nw-oc.13: ImageCommunicationObject: \asNumber: \asName、asIn、asOut、asDefault、asGuardian、\lastModifiedDate
# number assignement objects
# 数のassignement物
assignedNumberClass: id-nw-oc.14 : top : \
: \
assignedNumberClass: イド-nw-oc.14: 先端: \ : \
Johannsen, Mansfield, Kosters & Sataluri [Page 18] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[18ページ]RFC1608IP情報
assBy, assTo, assDate, nicHandle, relNwElement, \
description
assBy、assTo、assDate、nicHandle、relNwElement、\記述
delegatedBlock: id-nw-oc.15 : AssignedNumberClass : \
delegatedBlockName, lowerBound, upperBound :
delegatedBlock: イド-nw-oc.15: AssignedNumberClass: \delegatedBlockName、lowerBound、upperBound:
ipGroup: id-nw-oc.16 : AssignedNumberClass : \
ipGroupName, ipNwMask :
ipGroup: イド-nw-oc.16: AssignedNumberClass: \ipGroupName、ipNwMask:
ipReference: id-nw-oc.17 : AssignedNumberClass : \
ipReferenceName :
ipReference: イド-nw-oc.17: AssignedNumberClass: \ipReferenceName:
asBlock: id-nw-oc.18 : AssignedNumberClass : \
asBlockName, asLowerBound, asUpperBound :
asBlock: イド-nw-oc.18: AssignedNumberClass: \asBlockName、asLowerBound、asUpperBound:
asReference: id-nw-oc.19 : AssignedNumberClass : \
asNumber :
asReference: イド-nw-oc.19: AssignedNumberClass: \asNumber:
-- localoidtable.at
-- localoidtable.at
adminContact: id-nw-at.1 :DN technContact: id-nw-at.2 :DN ICO: id-nw-at.3 :DN imageType: id-nw-at.4 :caseIgnoreString imageOf: id-nw-at.5 :DN networkName,nw: id-nw-at.6 :caseIgnoreString externalGateway: id-nw-at.7 :DN nwType: id-nw-at.8 :caseIgnoreString media: id-nw-at.9 :caseIgnoreString speed: id-nw-at.10 :numericString traffic: id-nw-at.11 :numericString configurationDate: id-nw-at.12 :utcTime configurationHistory: id-nw-at.13 :caseIgnoreString nodeName,nd: id-nw-at.14 :caseIgnoreString typeOfMachine: id-nw-at.15 :caseIgnoreString OS: id-nw-at.16 :caseIgnoreString networkInterfaceName,ni: id-nw-at.17 :caseIgnoreString networkInterfaceAddress: id-nw-at.18 :caseIgnoreString connectedNetwork: id-nw-at.19 :DN charge: id-nw-at.20 :numericString ipNetworkImageName,IPnw: id-nw-at.21 :caseIgnoreString ipNwNumber: id-nw-at.22 :caseIgnoreString ipNwMask: id-nw-at.23 :caseIgnoreString inAddrServer: id-nw-at.24 :DN asNumber,asN: id-nw-at.25 :integerString provider: id-nw-at.26 :DN
adminContact: イドがnwする、.1:DN technContact: イドがnwする、.2:DN ICO: イドがnwする、.3:DN imageType: イドがnwする、.4:caseIgnoreString imageOf: イドがnwする、.5 :DN networkName、nw: イドがnwする、.6:caseIgnoreString externalGateway: イドがnwする、.7:DN nwType: イドがnwする、.8 :caseIgnoreStringメディア: イドがnwする、.9 :caseIgnoreStringは疾走します: イドがnwする、.10 :numericString交通: イドがnwする、.11:numericString configurationDate: イドがnwする、.12:utcTime configurationHistory: イドがnwする、.13 :caseIgnoreString nodeName、第: イドがnwする、.14:caseIgnoreString typeOfMachine: イドがnwする、.15 :caseIgnoreString OS: イドがnwする、.16 :caseIgnoreString networkInterfaceName、Ni: イドがnwする、.17:caseIgnoreString networkInterfaceAddress: イドがnwする、.18:caseIgnoreString connectedNetwork: イドがnwする、.19 :DNは充電します: イドがnwする、.20 :numericString ipNetworkImageName、IPnw: イドがnwする、.21:caseIgnoreString ipNwNumber: イドがnwする、.22:caseIgnoreString ipNwMask: イドがnwする、.23:caseIgnoreString inAddrServer: イドがnwする、.24 :DN asNumber、asN: イドがnwする、.25:integerStringプロバイダー: イドがnwする、.26:DN
Johannsen, Mansfield, Kosters & Sataluri [Page 19] RFC 1608 IP Information in the X.500 Directory March 1994
X.500ディレクトリ行進1994年のヨハンセン、マンスフィールド、Kosters、およびSataluri[19ページ]RFC1608IP情報
onlineDate: id-nw-at.27 :utcTime ipNodeName,IPnd: id-nw-at.28 :caseIgnoreString protocol: id-nw-at.29 :caseIgnoreString domainName: id-nw-at.30 :caseIgnoreString ipNetworkInterfaceName,IPni: id-nw-at.31 :caseIgnoreString asName: id-nw-at.32 :caseIgnoreString asIn: id-nw-at.33 :caseIgnoreString asOut: id-nw-at.34 :caseIgnoreString asDefault: id-nw-at.35 :caseIgnoreString asGuardian: id-nw-at.36 :DN assBy: id-nw-at.37 :DN assTo: id-nw-at.38 :DN assDate: id-nw-at.39 :utcTime nicHandle: id-nw-at.40 :caseIgnoreString relNwElement: id-nw-at.41 :DN delegatedBlockName,dbl: id-nw-at.42 :caseIgnoreString lowerBound: id-nw-at.43 :caseIgnoreString upperBound: id-nw-at.44 :caseIgnoreString ipGroupName,IPgr: id-nw-at.45 :caseIgnoreString ipReferenceName,IPref: id-nw-at.46 :caseIgnoreString asBlockName,asBl: id-nw-at.47 :caseIgnoreString asLowerBound: id-nw-at.48 :integerString asUpperBound: id-nw-at.49 :integerString
onlineDate: イドがnwする、.27 :utcTime ipNodeName、IPnd: イドがnwする、.28 :caseIgnoreStringは議定書を作ります: イドがnwする、.29:caseIgnoreString domainName: イドがnwする、.30 :caseIgnoreString ipNetworkInterfaceName、IPni: イドがnwする、.31:caseIgnoreString asName: イドがnwする、.32:caseIgnoreString asIn: イドがnwする、.33:caseIgnoreString asOut: イドがnwする、.34:caseIgnoreString asDefault: イドがnwする、.35:caseIgnoreString asGuardian: イドがnwする、.36:DN assBy: イドがnwする、.37:DN assTo: イドがnwする、.38:DN assDate: イドがnwする、.39:utcTime nicHandle: イドがnwする、.40:caseIgnoreString relNwElement: イドがnwする、.41 :DN delegatedBlockName、dbl: イドがnwする、.42:caseIgnoreString lowerBound: イドがnwする、.43:caseIgnoreString upperBound: イドがnwする、.44 :caseIgnoreString ipGroupName、IPgr: イドがnwする、.45 :caseIgnoreString ipReferenceName、IPref: イドがnwする、.46 :caseIgnoreString asBlockName、asBl: イドがnwする、.47:caseIgnoreString asLowerBound: イドがnwする、.48:integerString asUpperBound: イドがnwする、.49:integerString
Johannsen, Mansfield, Kosters & Sataluri [Page 20]
ヨハンセン、マンスフィールド、Kosters、およびSataluri[20ページ]
一覧
スポンサーリンク
