RFC1931 日本語訳
1931 Dynamic RARP Extensions for Automatic Network AddressAcquisition. D. Brownell. April 1996. (Format: TXT=27544 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Brownell Request For Comments: 1931 Sun Microsystems, Inc. Category: Informational April 1996
コメントを求めるワーキンググループD.ブラウネル要求をネットワークでつないでください: 1931年のサン・マイクロシステムズ・インクカテゴリ: 情報の1996年4月
Dynamic RARP Extensions for
Automatic Network Address Acquisition
自動ネットワーク・アドレス獲得のためのダイナミックなRARP拡張子
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not define an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も定義しません。 このメモの分配は無制限です。
1. Introduction
1. 序論
This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D- RARP). The role of DRARP, and to some extent the configuration protocol used in conjunction with it, has subsequently been addressed by the DHCP protocol [9]. This memo is being published now to document this protocol for the record.
このメモは拡大について逆アドレス解決プロトコルに説明します。(RARP[2])と呼ばれたDynamic RARP(D RARPであると断言されたDRARP)。 DRARPの役割、およびある程度それに関連して使用される構成プロトコルは次に、DHCPプロトコル[9]によって扱われました。 このメモは、現在、公式にこのプロトコルを記録するために発表されています。
DRARP is used to acquire (or allocate) a protocol level address given the fixed hardware address for a host. Its clients are systems being installed or reconfigured, and its servers are integrated with other network administration services. The protocol, along with adjunct protocols as briefly described here, supports several common styles of "Intranet" administration including networks which choose not to support the simplified installation and reconfiguration features enabled by DRARP.
DRARPが取得するのにおいて使用されている、(割り当て、)、ホストのための固定ハードウェア的なアドレスを考えて、プロトコルはアドレスを平らにします。 クライアントはインストールされるか、または再構成されるシステムです、そして、サーバは他のネットワーク管理サービスについて統合しています。 プロトコルはここで簡潔に説明されているとしての付属物プロトコルと共に簡易型のインストールと再構成がDRARPによって可能にされた特徴であるとサポートしないのを選ぶネットワークを含むいくつかの一般的なスタイルの「イントラネット」管理をサポートします。
The rest of this introductory section summarizes the system design of which the DRARP protocol was a key part. The second section presents the DRARP protocol, and the third section discusses requirements noted for an "Address Authority" managing addresses in conjunction with one or more cooperating DRARP servers.
この紹介しているセクションの残りはDRARPプロトコルが主要な部分であったシステム設計をまとめます。 第2セクションはDRARPプロトコルを提示します、そして、第3セクションは1かさらに協力関係を持っているDRARPサーバに関連して「アドレス権威」でアドレスを管理しながら有名である要件について論じます。
1.1 Automatic System Installation
1.1 オートマティック・システムインストール
Dynamic RARP was used by certain Sun Microsystems platforms beginning in 1988. (These platforms are no longer sold by Sun.) In conjunction with other administrative protocols, as summarized in the next subsection, it was part of a simplified network and domain administration framework for SunOS 4.0. Accordingly, there was a product requirement to extend (rather than replace) the RARP/TFTP two phase booting model [3], in order to leverage the existing system infrastructure. This is in contrast to the subsequent DHCP [9] work,
ダイナミックなRARPは1988年に始まるある一定のサン・マイクロシステムズプラットホームによって使用されました。 (これらのプラットホームはもう日曜日までに販売されません) 他の管理プロトコルに関連して、次の小区分でまとめられるように、それはSunOS4.0のための簡易型のネットワークとドメイン管理フレームワークの一部でした。 それに従って、広がるという製品要件があった、(むしろ、取り替え、)、既存のシステムインフラストラクチャを利用するRARP/TFTP二相穂ばらみモデル[3]。 これはその後のDHCP[9]仕事と対照的になっています。
Brownell Informational [Page 1] RFC 1931 Dynamic RARP April 1996
ダイナミックな[1ページ]RFC1931RARP1996年4月の情報のブラウネル
which extended BOOTP.
BOOTPを広げました。
The "hands-off" installation of all kinds of systems (including diskless workstations, and servers) was required, as supported by LocalTalk networks [8]. However, Internet administrative models are not set up to allow that: there is no way to set up a completely functional IP network by just plugging machines into a cable and powering them up. That procedure doesn't have a way to input the network number (and class) that must be used, or to bootstrap the host naming system. An approach based on administered servers was needed for IP-based "Intranet" systems, even though that unfortunately called for networks to be initially set up by knowledgeable staff before any "hands-off" installations could be performed.
すべての種類のシステム(ディスクレスワークステーション、およびサーバを含んでいる)の「下に手」インストールが必要でした、LocalTalkネットワーク[8]によってサポートされるように。 しかしながら、インターネット管理モデルは、以下のことを許容するためにセットアップされません。 ただケーブルにマシンのプラグを差し込んで、それらを動かすことによって上がっている完全に機能的なIPネットワークを設立する方法が全くありません。 その手順に、使用しなければならないネットワーク・ナンバー(そして、クラス)を入力するか、またはホスト命名システムを独力で進む方法がありません。 管理されたサーバに基づくアプローチがIPベースの「イントラネット」システムに必要でした、どんな「下に手」インストールも実行できる前にそれは、残念ながらネットワークが初めは博識なスタッフによって設立されるように求めましたが。
1.2 System Overview
1.2 システム概要
DRARP was used by systems in the first phase of joining a network, to
acquire a network address without personal intervention by a network
administrator. Once a system was given a network address, it would
perform whatever network operations it desired, subject to a site's
access control policies. During system installation, those network
operations involved a (re)configuration protocol ("Plug'n'Play", or
PNP). Diskless sytems used TFTP to download code which could speak
the PNP protocol.
DRARPはネットワーク管理者による個人的な介入なしでネットワーク・アドレスを習得するためにネットワークに加わる第1段階におけるシステムによって使用されました。 いったんネットワーク・アドレスをシステムに与えると、それはサイトのアクセス制御方針を条件として望んでいたどんなネットワーク操作も実行するでしょうに。 システムインストールの間、それらのネットワーク操作が(re)構成プロトコルにかかわった、(「Plug'n'は」 PNPをプレーします)' ディスクレスsytemsは、PNPプロトコルを話すことができたコードをダウンロードするのにTFTPを使用しました。
The PNP protocol would register the names of newly installed hosts in the naming service, using the address which was acquired using DRARP. These names could be chosen by users installing the system, but could also be assigned automatically. Diskless systems used the PNP protocol to assign booting resources (e.g. filesystem space) on servers. All systems were assigned public and private keys, also initial (quasi-secret) "root" passwords, so that they could use what was then the strongest available ONC RPC authentication system.
PNPプロトコルは名前付けサービスで新たにインストールされたホストの名前を登録するでしょう、DRARPを使用することで習得されたアドレスを使用して。 これらの名前をシステムをインストールしているユーザが選ぶことができましたが、また、自動的に割り当てることができました。 ディスクレスシステムは、穂ばらみリソース(例えば、ファイルシステムスペース)をサーバに割り当てるのにPNPプロトコルを使用しました。 公衆と秘密鍵、また、初期(準秘密の)の「根」パスワードはすべてのシステムに選任されました、次に最も強い利用可能なONC RPC認証システムであったことを使用できるように。
Servers for DRARP and for the configuration protocol (as well as
other administrative tools) needed to consult an authoritative
database of which Internet addresses which were allocated to which
hosts (as identified by hardware addresses). This "address
authority" role was implemented using a name service (NIS) and an
RPC-based centralized IP address allocation protocol ("IPalloc").
Address allocation could be performed only by authorized users,
including network administrators and DRARP servers.
DRARPと構成プロトコル(他の管理ツールと同様に)のためのサーバは、どのホストに割り当てられたどのインターネット・アドレスの正式のデータベースに相談する必要がありました(ハードウェア的にアドレスを特定するので)。 この「アドレス権威」の役割は名前サービス(NIS)を利用して、RPCベースの集結されたIPアドレス配分プロトコルであると実装されました("IPalloc")。 単にネットワーク管理者とDRARPサーバを含む認定ユーザはアドレス配分を実行できました。
Most systems used DRARP and PNP each time they started, to automatically reconfigure applicable system and network policies. For example, network addresses and numbers were changed using these protocols; host names changed less often. The naming service (NIS)
ほとんどのシステムが自動的に適切なシステムとネットワーク方針を再構成するために始まったたびにDRARPとPNPを使用しました。 例えば、これらのプロトコルを使用することでネットワーク・アドレスと数を変えました。 ホスト名は、よりしばしば変化しました。 名前付けサービス(ニーシ)
Brownell Informational [Page 2] RFC 1931 Dynamic RARP April 1996
ダイナミックな[2ページ]RFC1931RARP1996年4月の情報のブラウネル
held most information, such as the locations of printers and users' home directories.
プリンタとユーザのホームディレクトリの位置などのほとんどの情報を保持しました。
2. Dynamic RARP Extensions
2. ダイナミックなRARP拡張子
Dynamic RARP (DRARP) service is provided by any of a small active set of cooperating server systems on a network segment (network or subnetwork). Those servers are contacted through link level procedures, normally a packet broadcast. One or more servers may respond to a given request. It was intended that network segments will be administered together in domains [5] consisting of one or more network segments. Domains sharing a network segment need to share information about network addresses, both hardware level and protocol level, so an address authority (see section 3) can avoid reallocating protocol addresses which are already allocated or in use.
小さい活動的なセットの協力関係を持っているサーバシステムのいずれもネットワークセグメント(ネットワークかサブネットワーク)でダイナミックなRARP(DRARP)サービスを提供します。 リンク・レベル手順、通常パケット放送でそれらのサーバは連絡されます。 1つ以上のサーバが与えられた要求に応じるかもしれません。 ネットワークセグメントが[5] 1つ以上のネットワークセグメントから成りながらドメインで一緒に管理されることを意図しました。 ネットワークセグメントを共有するドメインが、ネットワーク・アドレスの情報、ハードウェアレベルとプロトコルレベルの両方を共有する必要があるので、アドレス権威(セクション3を見る)は、既に割り当てたか、または使用中のプロトコルアドレスを再割当てするのを避けることができます。
Dynamic RARP benefits from link layer addresses which are scoped more widely than just the local network segment. It takes advantage of such scoping to detect hosts which move between network segments. Such scoping is provided by IEEE 802 48-bit addresses [7], but not by all other kinds of network address. Without such a widely scoped ID, the case of systems roaming between networks can't be detected by Dynamic RARP.
ダイナミックなRARPはまさしく企業内情報通信網セグメントより広く見られるリンクレイヤアドレスの利益を得ます。 それは、ホストを検出するのにそのような見ることを利用します(ネットワークセグメントの間で移行します)。 そのような見ることをIEEE802 48ビットのアドレス[7]で提供しますが、他のすべての種類のネットワーク・アドレスは提供するというわけではありません。 そのような広く見られたIDがなければ、Dynamic RARPはシステムがネットワークの間を移動するケースを検出できません。
2.1 Mixing RARP and DRARP Servers
2.1 RARPとDRARPサーバを混合すること。
DRARP is an extension to RARP, so that all Dynamic RARP servers are also RARP servers. However, DRARP provides a more manageable service model than RARP does: while RARP allows multiple servers to respond to RARP requests, it does not expect all those servers to be able to respond, or to respond identically. A given RARP server can not be relied upon to know whether a given link level address can be mapped into a protocol address, and some other RARP server may have a different answer.
DRARPがRARPへの拡大であるので、また、すべてのDynamic RARPサーバがRARPサーバです。 しかしながら、DRARPはRARPがそうするより処理しやすいサービスモデルを提供します: RARPがRARP要求に複数のサーバを応じさせている間、それは、それらのすべてのサーバが応じるか、または同様に応じることができると予想しません。 与えられたリンク・レベルアドレスをプロトコルアドレスに写像できるかどうかを知るために与えられたRARPサーバを当てにすることができません、そして、ある他のRARPサーバには、異なった答えがあるかもしれません。
Dynamic RARP addresses this problem by requiring that all Dynamic RARP servers on a network segment must communicate with the same address authority. That address authority controls name and address bindings, records bindings between host identifiers and addresses, makes decisions about how to allocate addresses, and keeps records about addresses in use.
ネットワークセグメントに関するすべてのDynamic RARPサーバが同じアドレス権威で交信しなければならないのを必要とすることによって、ダイナミックなRARPはこのその問題を訴えます。 ホスト識別子とアドレスの間のそのアドレス典拠コントロール名とアドレス結合、記録結合は、どうアドレスを割り当てるかに関して決定をして、使用中のアドレスに関して記録をつけます。
This means that in effect there may be a number of independent RARP services offered along with a single DRARP service. DRARP service may well be offered through multiple servers, and the persistent address bindings it serves will be accessible as from a set of coordinated RARP servers.
これは、事実上、ただ一つのDRARPサービスと共に提供された多くの独立しているRARPサービスがあるかもしれないことを意味します。 たぶん複数のサーバを通してDRARPサービスを提供するでしょう、そして、1セットの連携RARPサーバ付けで、それが役立つ永続的なアドレス結合はアクセスしやすくなるでしょう。
Brownell Informational [Page 3] RFC 1931 Dynamic RARP April 1996
ダイナミックな[3ページ]RFC1931RARP1996年4月の情報のブラウネル
Not all networks want to support dynamic address allocation services. Even those that do support it will need control over implementation of the address authority. So DRARP servers need policy controls such as "restricting" them from assigning addresses (applied to an entire network segment) as well as disabling use of DRARP entirely. (One may need to disable servers that would otherwise allocate new addresses, in order to enable ones which can speak to the "correct" address authority. Standards do not exist for protocols and security options used to talk to address authorities.)
すべてのネットワークが、ダイナミックなアドレスが配分サービスであるとサポートしたがっているというわけではありません。 それをサポートする人さえアドレス権威の実装のコントロールを必要とするでしょう。 それで、DRARPサーバはそれらのアドレス(全体のネットワークセグメントに適用される)を割り当てて、DRARPの使用を完全に無効にするので「制限」などであることなどの方針コントロールを必要とします。 (そうでなければ新しいアドレスを割り当てるサーバを損傷する必要があるかもしれません、「正しい」アドレス権威に話すことができるものを可能にするために。 規格はプロトコルのために存在していません、そして、セキュリティオプションは、当局に演説するために以前はよく話していました。)
2.2 Packet Format
2.2 パケット・フォーマット
The packet format is identical to RARP and is encapsulated using RARP frames, with the same Ethernet/SNAP type field. [1, 2, 6]. That is, a DRARP packet looks like a RARP packet, but it uses opcodes which are ignored by RARP servers; DRARP servers must also support RARP requests, and hence ARP requests [1].
パケット・フォーマットは、同じイーサネット/SNAPタイプ分野があるRARPフレームを使用することでRARPと同じであり、カプセル化されます。 [1, 2, 6]. すなわち、DRARPパケットはRARPパケットに似ていますが、RARPサーバによって無視されるopcodesを使用します。 また、DRARPサーバは、RARP要求をサポートして、したがって、ARP要求[1]をサポートしなければなりません。
2.2.1 RARP Packets
2.2.1 RARPパケット
The two RARP opcodes are described here, in order to clarify the overall presentation. The name "REVARP", used in the opcode descriptions, is a synonym for "RARP".
2RARP opcodesが、総合的なプレゼンテーションをはっきりさせるためにここで説明されます。 "REVARP"というopcode記述に使用される名前は"RARP"のための同義語です。
REVARP_REQUEST (3)
REVARP_REQUEST packets are sent to RARP servers as a request to
map the target hardware address (tha) into the corresponding
target protocol address (tpa), sending the response to the
source hardware address (sha) as encoded in the packet. The
source hardware address will usually be the same as the target
hardware address, that of the system sending the packet. RARP
servers will consult their name and address databases, and
return a REVARP_REPLY packet if they can perform the reverse
address resolution as requested.
対応する目標プロトコルアドレス(tpa)に目標ハードウェア・アドレス(tha)を写像するという要求としてREVARP_REQUEST(3)REVARP_REQUESTパケットをRARPサーバに送ります、パケットでコード化されるようにソースハードウェア・アドレス(sha)に応答を送って。 通常、ソースハードウェア・アドレスは目標ハードウェアアドレスと同じになるでしょう、システムのものがパケットを送って。 要求された通り逆のアドレス解決を実行できると、RARPサーバは、それらの名前とアドレスデータベースに相談して、REVARP_REPLYパケットを返すでしょう。
REVARP_REPLY (4)
This packet is sent by RARP servers in response to
REVARP_REQUEST packets. The target protocol address (tpa) is
filled in as requested, and the source hardware and protocol
addresses (sha, spa) correspond to the RARP server. The target
hardware address (tha) is from the corresponding REVARP_REQUEST
packet, and the packet is sent to the source hardware address
(sha) from that packet.
このパケットがRARPサーバによってREVARP_REQUESTパケットに対応して送られるREVARP_REPLY(4)。 目標プロトコルアドレス(tpa)は要求された通り記入されます、そして、ソースハードウェアとプロトコルアドレス(sha、鉱泉)はRARPサーバに一致しています。目標ハードウェア・アドレス(tha)は対応するREVARP_REQUESTパケットから来ています、そして、パケットをそのパケットからソースハードウェア・アドレス(sha)に送ります。
This packet is also sent by Dynamic RARP servers in response to
DRARP_REQUEST packets, if the protocol address returned was not
a temporary one, but was instead what it would have returned
given an otherwise identical REVARP_REQUEST packet.
また、DRARP_REQUESTパケットに対応してDynamic RARPサーバでこのパケットを送ります、アドレスが返したプロトコルが一時的なものではありませんでしたが、代わりにそうでなければ、同じREVARP_REQUESTパケットを考えて、それが返したものであったなら。
Brownell Informational [Page 4] RFC 1931 Dynamic RARP April 1996
ダイナミックな[4ページ]RFC1931RARP1996年4月の情報のブラウネル
2.2.2 Dynamic RARP Packets
2.2.2 ダイナミックなRARPパケット
There are three opcodes defined for DRARP, in addition to the
two already defined for RARP:
2に加えたDRARPのためにRARPのために既に定義されていた状態で定義された3opcodesがあります:
DRARP_REQUEST (5)
DRARP_REQUEST packets have the same format as REVARP_REQUEST
packets, except for the operation code. The semantics are simi-
lar, except that in cases where a REVARP_REQUEST would produce
no REVARP_REPLY (no persistent address mapping is stored in an
addressing database) a DRARP_REQUEST will normally return a tem-
porary address allocation in a DRARP_REPLY packet. A
DRARP_ERROR packet may also be returned; a Dynamic RARP server
will always provide a response, unlike a REVARP server.
DRARP_REQUEST(5)DRARP_REQUESTパケットには、命令コード以外のREVARP_REQUESTパケットと同じ形式があります。 意味論はsimi- larです、REVARP_REQUESTがREVARP_REPLYを全く生産しない(どんな永続的なアドレス・マッピングもアドレシングデータベースに保存されません)場合では、通常、DRARP_REQUESTがDRARP_REPLYパケットでtem- poraryアドレス配分を返すのを除いて。 また、DRARP_ERRORパケットを返すかもしれません。 Dynamic RARPサーバはいつもREVARPサーバと異なった応答を提供するでしょう。
DRARP_REPLY (6)
DRARP_REPLY packets have the same format, opcode excepted, as
REVARP_REPLY packets. The interpretation of the fields is the
same.
DRARP_REPLY(6)DRARP_REPLYパケットには、同じ形式、REVARP_REPLYパケットとして除外されているopcodeがあります。 分野の解釈は同じです。
There are semantic differences between the two packet types.
First, the protocol address bindings returned in DRARP_REPLY
packets are temporary ones, which will be recycled after some
period (e.g. an hour). Those bindings returned in REVARP_REPLY
packets are "persistent" addresses which typically change much
more slowly. Second, it is explicitly a protocol error for
DRARP_REPLY packets to be sent which differ except in the sender
address fields. Also, DRARP_REPLY packets are generated only in
response to DRARP_REQUEST packets.
2つのパケットタイプの間には、意味違いがあります。 まず最初に、DRARP_REPLYパケットで返されたプロトコルアドレス結合は一時的なものです。(そのものはいつかの期間(例えば、1時間)の後に再生されるでしょう)。 REVARP_REPLYパケットで返されたそれらの結合ははるかにゆっくり通常変化する「永続的な」アドレスです。 2番目に、明らかに、送られる送付者を除いて、異なるDRARP_REPLYパケットのためのプロトコル誤りが分野を扱うということです。 また、DRARP_REPLYパケットは単にDRARP_REQUESTパケットに対応して生成されます。
These temporary addresses may be reallocated to another system
after some time period. A configuration protocol is normally
used to ensure that reallocation does not occur.
これらの仮の住所はいつかの期間の後に別のシステムに再割当てされるかもしれません。 通常、構成プロトコルは、再配分が起こらないのを保証するのに使用されます。
DRARP_ERROR (7)
DRARP_ERROR packets may also be sent in response to
DRARP_REQUESTs. The format is identical to REVARP_REPLY, except
for the opcode and that the target protocol address (tpa) field
is replaced by an error code field. The error code field must
be at least one byte long, and the first byte is used to encode
an error status describing why no target protocol address (tpa)
is being returned. The status values are:
また、DRARP_REQUESTsに対応してDRARP_ERROR(7)DRARP_ERRORパケットを送るかもしれません。 形式はopcode以外のREVARP_REPLYと同じです、そして、目標プロトコルが、(tpa)が分野であると扱うのをエラーコード分野に取り替えます。 エラーコード分野は長さ少なくとも1バイトでなければなりません、そして、最初のバイトは、目標プロトコルアドレス(tpa)が全くなぜ返されていないかを説明するエラー状況をコード化するのに使用されます。 状態値は以下の通りです。
DRARPERR_RESTRICTED (1)
This network does not support dynamic address allocation.
The response is definitive; the network is controlled so
that no other DRARP_REPLY (for this hardware address) is
legal until the network policy on dynamic address
このネットワークがするDRARPERR_RESTRICTED(1)は、ダイナミックなアドレスが配分であるとサポートしません。 応答は決定的です。 ネットワークが制御されているので、他のどんなDRARP_REPLY(このハードウェア・アドレスのための)もダイナミックなアドレスに関するネットワーク方針まで法的ではありません。
Brownell Informational [Page 5] RFC 1931 Dynamic RARP April 1996
ダイナミックな[5ページ]RFC1931RARP1996年4月の情報のブラウネル
allocation is changed, or until the client is otherwise
assigned a persistent address binding. A REVARP_REQUEST
might yield a REVARP_REPLY, however; non-cooperating RARP
servers could be the very reason that dynamic address allo-
cation was disabled.
配分は、変えるか、または別の方法でクライアントまで永続的なアドレス結合を割り当てます。 しかしながら、REVARP_REQUESTはREVARP_REPLYをもたらすかもしれません。 非協力RARPサーバはダイナミックなアドレス異陽イオンが無効にされたまさしくその理由であるかもしれません。
DRARPERR_NOADDRESSES (2)
This network supports dynamic address allocation, but all
available protocol addresses in the local segment are in
use, so none can be allocated now.
このネットワークが動力をサポートするDRARPERR_NOADDRESSES(2)が配分を扱いますが、地方のセグメントのすべての利用可能なプロトコルアドレスが使用中であるので、現在、なにも割り当てることができません。
DRARPERR_SERVERDOWN (3)
The service providing access to the address authority is
temporarily unavailable. May also be returned if an
address allocation was required and the required response
took a "long time" to generate; this distinguishes the case
of a network that didn't support DRARP from the case of one
that does, but is slow.
サービス提供がアドレス権威にアクセスするDRARPERR_SERVERDOWN(3)は一時入手できません。 また、アドレス配分が必要であり、必要な応答が生成する「長い時間」取ったなら、返すかもしれません。 これはそれがすることに関するケースからDRARPをサポートしていませんが、遅いネットワークに関するケースを区別します。
DRARPERR_MOVED (4)
Analogous to the DRARPERR_RESTRICTED status in that no
address was dynamically allocated. This provides the addi-
tional status that this client was recognized by the
administration software for the domain as being on a dif-
ferent network segment than expected; users will be able to
remedy the problem by connecting the system to the correct
network segment.
中のアドレスが全くダイナミックに割り当てられなかったDRARPERR_RESTRICTED状態への類似のDRARPERR_MOVED(4)。 これは予想よりdif- ferentネットワークセグメントにあるとドメインのための管理ソフトウェアによって認識されていた状態でこのクライアントがいたaddi- tional状態を提供します。 ユーザは、正しいネットワークセグメントにシステムを接続することによって、問題を改善できるでしょう。
DRARPERR_FAILURE (5)
For some reason, no address could be returned. No defined
status code known to the server explained the reason.
或るものが推論するDRARPERR_FAILURE(5)For、アドレスを全く返すことができませんでした。 サーバに知られない定義されたステータスコードで、全く理由がわかりました。
More opcodes for the Address Resolution Protocol (ARP) family could be defined in the future, so unrecognized opcodes (and error codes) should be ignored rather than treated as errors.
将来Address Resolutionプロトコル(ARP)ファミリーのための、より多くのopcodesを定義できました、非常に認識されていないので、opcodes(そして、エラーコード)は誤りとして扱われるよりむしろ無視されるべきです。
2.3 Protocol Exchanges
2.3 プロトコル交換
This section describes typical protocol exchanges using RARP and Dynamic RARP, and common fault modes of each exchange.
このセクションはRARPとDynamic RARPを使用する典型的なプロトコル交換、およびそれぞれの交換の一般的な欠点モードを説明します。
2.3.1. RARP Address Lookup
2.3.1. RARPアドレスルックアップ
To determine a previously published ("persistent") protocol address
for itself or another system, a system may issue a REVARP_REQUEST
packet. If a REVARP_REPLY packet arrives in response, then the
target protocol address listed there should be used.
それ自体のための以前に発行された(「永続的な」)プロトコルアドレスか別のシステムを決定するために、システムはREVARP_REQUESTパケットを発行するかもしれません。 REVARP_REPLYパケットが応答に到達するなら、そこに記載された目標プロトコルアドレスは使用されるべきです。
Brownell Informational [Page 6] RFC 1931 Dynamic RARP April 1996
ダイナミックな[6ページ]RFC1931RARP1996年4月の情報のブラウネル
If no REVARP_REPLY response packet arrives within some time interval, a number of errors may have occurred. The simplest one is that the request or reply packet may never have arrived: most RARP client implementations retransmit requests to partially account for this error. There is no clear point at which to stop retransmitting a request, so many implementations apply an exponential backoff to the retransmit interval, to reduce what is typically broadcast traffic.
REVARP_REPLY応答パケットが全くいくつかの時間間隔以内に到着しないなら、エラー回数は起こったかもしれません。 最も簡単なものは要求か回答パケットが一度も到着したことがないかもしれないということです: ほとんどのRARPクライアント実装がこの誤りを部分的に説明するという要求を再送します。 ポイントが要求を再送するのを止めるために、とても多くの実装が指数のbackoffをどれに適用するかではっきりとある、間隔を再送してください、そして、通常放送されることを減少させるために、取引してください。
Otherwise there are many different errors which all have the same failure mode, including: the system might not have a published protocol address; it might be on the wrong network segment, so its published address is invalid; the RARP servers which can supply the published address may be unavailable; it might even be on a network without any RARP servers at all.
そうでなければ、である:同じ故障モードを持っている多くの異なった誤りがすべて、あります。 システムには、発行されたプロトコルアドレスがないかもしれません。 それが間違ったネットワークセグメントにあるかもしれないので、発行されたアドレスは無効です。 発行されたアドレスを供給できるRARPサーバは入手できないかもしれません。 それはネットワークに全く少しもRARPサーバなしでありさえするかもしれません。
2.3.2 Dynamic RARP Address Lookup
2.3.2 ダイナミックなRARPアドレスルックアップ
Dynamic RARP may be used to determine previously published protocol addresses by clients who issue DRARP_REQUEST packets. If the client has a published protocol address on the network segment on which the DRARP_REQUEST packet was issued, it is returned in a REVARP_REPLY packet.
ダイナミックなRARPは、DRARP_REQUESTにパケットを発行するクライアントによる以前に発行されたプロトコルアドレスを決定するのに使用されるかもしれません。 クライアントにDRARP_REQUESTパケットが発行されたネットワークセグメントに関する発行されたプロトコルアドレスがあるなら、REVARP_REPLYパケットでそれを返します。
If the client has a published protocol address only on some other network segment, then two basic responses are possible. In the case where dynamic address reallocation is enabled, a temporary protocol address may be allocated and returned in a DRARP_REPLY packet. Otherwise if dynamic address reallocation is disabled, a DRARP_ERROR packet is returned with the status DRARPERR_MOVED. Detection of host movement can be provided only with link level addresses that are unique over the catenet, such as are provided with IEEE 802 48 bit addresses. Without such uniqueness guarantees, this case looks like a request for a new address as described in the next section.
クライアントにある他のネットワークセグメントだけに関する発行されたプロトコルアドレスがあるなら、2つの基本的な応答が可能です。 ダイナミックなアドレス再配分が可能にされる場合では、DRARP_REPLYパケットで一時的なプロトコルアドレスを割り当てて、返すかもしれません。 さもなければ、ダイナミックなアドレス再配分は障害があるなら、状態DRARPERR_MOVEDと共にDRARP_ERRORパケットを返します。 IEEE802 48のビット・アドレスを提供するようなcatenetに関してユニークなリンク・レベルアドレスだけにホスト運動の検出を提供できます。 そのようなユニークさの保証がなければ、本件は次のセクションで説明されるように新しいアドレスを求める要求に似ています。
2.3.3 Dynamic RARP Address Allocation
2.3.3 ダイナミックなRARPアドレス配分
Dynamic RARP clients who issue DRARP_REQUEST packets may acquire newly allocated protocol addresses. If the client has no published protocol address, there are three responses:
問題DRARP_REQUESTパケットが新たに取得するかもしれないダイナミックなRARPクライアントはプロトコルアドレスを割り当てました。 クライアントに発行されたプロトコルアドレスが全くないなら、3つの応答があります:
(a) When dynamic address allocation is enabled, a temporary protocol
address is allocated and returned in a DRARP_REPLY packet.
(a) ダイナミックなアドレス配分を可能にするとき、DRARP_REPLYパケットで一時的なプロトコルアドレスを割り当てて、返します。
(b) Errors or delays in the allocation process (with dynamic address
allocation enabled) are reported in DRARP_ERROR packets with
error codes such as DRARPERR_SERVERDOWN, DRARPERR_NOADDRESSES,
DRARPERR_MOVED, or even DRARPERR_FAILURE.
(b) 割当過程(ダイナミックなアドレス配分が可能にされている)の誤りか遅れがDRARP_ERRORパケットでDRARPERR_SERVERDOWN、DRARPERR_NOADDRESSES、DRARPERR_MOVED、またはDRARPERR_FAILUREなどさえのエラーコードで報告されます。
Brownell Informational [Page 7] RFC 1931 Dynamic RARP April 1996
ダイナミックな[7ページ]RFC1931RARP1996年4月の情報のブラウネル
(c) When dynamic address allocation is disabled (or "restricted"), a
DRARP_ERROR packet with status DRARPERR_RESTRICTED is returned.
(c) ダイナミックなアドレス配分は障害があるとき(または、「制限される」)、状態DRARPERR_RESTRICTEDがあるDRARP_ERRORパケットを返します。
DRARP_REQUESTS are normally retransmitted until an address is
returned, using backoff-style algorithms to minimize needless
network traffic. When DRARP_ERROR responses are received, they
should be reported to the user. For example, knowing that the
server is busy could indicate it's time for a cup of Java, but
if the network is restricted then it might be time to contact a
network administrator for help instead.
不必要なネットワークトラフィックを最小にするのにbackoff-スタイルアルゴリズムを使用して、通常、DRARP_REQUESTSはアドレスを返すまで再送されます。 DRARP_ERROR応答が受け取られているとき、それらはユーザに報告されるべきです。 例えば、サーバが忙しいのを知っているのが1カップのJavaのための時間であることを示すかもしれませんが、ネットワークが制限されるなら、助けのために代わりにもうネットワーク管理者に連絡するべき時間であるかもしれません。
2.3.4 Discovering Other DRARP Servers
2.3.4 他のDRARPサーバを発見すること。
The existence of a DRARP server can be discovered by the fact
that it puts its addressing information in all DRARP_REPLY
packets that it sends. DRARP servers can listen for such
packets, as well as announcing themselves by sending such a
packet to themselves.
送るすべてのDRARP_REPLYパケットにアドレス指定情報を入れるという事実でDRARPサーバの存在を発見できます。 DRARPサーバはそのようなパケットを自分たちに送ることによって自分たちを発表することと同様にそのようなパケットの聞こうとすることができます。
It can be important to discover other DRARP servers. Users make
mistakes, and can inappropriately set up DRARP servers that do
not coordinate their address allocation with that done by the
other DRARP servers on their network segment. That causes
significant administrative problems, which can all but be
eliminated by DRARP servers which politely announce themselves,
and when they detect an apparently spurious server, report this
fact before entering a "restricted" mode to avoid creating any
problems themselves.
他のDRARPサーバを発見するのは重要である場合があります。 ユーザは、誤りをして、不適当にそれらのネットワークセグメントで他のDRARPサーバでそれをしていて彼らのアドレス配分を調整しないDRARPサーバをセットアップできます。 それは重要な管理上の問題を引き起こして、レポートはどんな問題自体も生じさせるのを避けるために「制限された」モードを入れる前のこの事実です。(すべて礼儀正しく自分たちを発表するDRARPサーバによって排除されて、彼らが明らかに偽りのサーバを検出するとき、管理上の問題はそうすることができます)。
As no further server-to-server protocol is defined here, some
out-of-band mechanism, such as communication through the address
authority, must be used to help determine which servers are in
fact spurious.
サーバからサーバへのさらなるプロトコルが全くここで定義されないとき、事実上、どのサーバが偽りであるかを決定するのを助けるのにアドレス権威を通したコミュニケーションなどのバンドで出ている何らかのメカニズムを使用しなければなりません。
2.4 Network Setup Concerns
2.4 ネットワークセットアップ関心
Some internetwork environments connect multiple network segments
using link level bridges or routers. In such environments, a
given broadcast accessible "local" area network will have two
problems worth noting.
いくつかのインターネットワーク環境が、リンク・レベルブリッジかルータを使用することで複数のネットワークセグメントを接続します。 そのような環境、アクセスしやすい「地方」の領域ネットワークがそうする与えられた放送では、注意する価値がある2つの問題を持ってください。
First, it will extend over several cable segments, and be
subject to partitioning faults. Assigning one DRARP server to
each segment (perhaps on systems acting as routers or bridges,
to serve multiple segments) can reduce the cost of such faults.
Assigning more than one such server can help reduce the cost of
failure to any single network segment; these cooperate in the
assignment of addresses through the address authority.
まず最初に、それは、いくつかのケーブルセグメントに達して、仕切りの欠点を被りやすくなるでしょう。 各セグメント(恐らく複数のセグメントに役立つようにルータかブリッジとして作動するシステムの上の)への割り当て1DRARPサーバはそのような欠点のコストを削減できます。 そのようなサーバの1つ以上を割り当てるのは、どんなただ一つのネットワークセグメントにも失敗のコストを削減するのを助けることができます。 これらはアドレス権威を通したアドレスの課題に協力します。
Brownell Informational [Page 8] RFC 1931 Dynamic RARP April 1996
ダイナミックな[8ページ]RFC1931RARP1996年4月の情報のブラウネル
Second, those networks are sometimes shared by organizations
which don't cooperate much on the management of protocol
addresses, or perhaps aren't even collocated. A DRARP server
might need help from link level bridges/routers in order to
ensure that local clients are tied to local servers (rather
than, for example, to servers across the country where they are
prone to availability problems). Or the server might need to
run in "restricted" mode so that a network administrator
manually assigns address and other resources to each system.
それらのネットワークは、2番目に、時々プロトコルアドレスの管理とあまり協力しない組織によって共有されるか、または恐らくありません。並べさえしました。 DRARPサーバが地元のクライアントがローカルサーバにつながれるのを確実にするためにリンク・レベルブリッジ/ルータから助けを必要とするかもしれない、(むしろ、例えばそれらは有用性問題の傾向がある国中のサーバ、) または、サーバが、「制限された」モードに立候補する必要があるかもしれないので、ネットワーク管理者は手動でアドレスと他のリソースを各システムに割り当てます。
3. The Address Authority
3. アドレス権威
While not part of the DRARP protocol, the Address Authority used
by the DRARP servers on a network segment is critical to
providing the address allocation functionality. It manages the
data needed to implement such service, which is required not
just for dynamic address allocation tools. This section is
provided to record one set of requirements for such an
authority, ignoring implementation isssues such as whether
protocol support for replication or partitioning is needed.
DRARPプロトコルの一部でない間、ネットワークセグメントでDRARPサーバによって使用されるAddress Authorityはアドレス配分の機能性を提供するのに重要です。 それはダイナミックでないアドレス配分ツールだけに必要であるそのようなサービスを実装するのに必要であるデータを管理します。 そのような権威のための1セットの要件を記録するためにこのセクションを提供します、模写か仕切りのプロトコルサポートが必要などであるかどうかなどの実装isssuesを無視して。
3.1 Basic Requirements
3.1 基本の要件
For each network segment under its control, an Address Authority
maintains at least:
Address Authorityが、それぞれがコントロールの下でセグメントをネットワークでつなぐと主張する、少なくとも:
- persistent bindings between hardware and protocol addresses
(for at least those hosts which are DRARP clients);
- ハードウェアとプロトコルアドレス(少なくともDRARPクライアントであるそれらのホストのための)の間の永続的な結合。
- temporary bindings between such addresses;
- そのようなアドレスの間の仮製本。
- protocol addresses available for temporary bindings;
- 仮製本に利用可能なアドレスについて議定書の中で述べてください。
The Address Authority is also responsible for presenting and managing those bindings. DRARP clients need it to support:
また、Address Authorityもそれらの結合を提示して、管理するのに責任があります。 DRARPクライアントは、以下をサポートするためにそれを必要とします。
- creating temporary bindings initially,
- 初めは仮製本を作成します。
- looking up bindings (the distinction between temporary and
persistent bindings is not usually significant here),
- 結合(通常、一時的で永続的な結合の区別はここで重要でない)を見上げます。
- deleting temporary or persistent bindings on request,
- 要求に応じて一時的であるか永続的な結合を削除します。
- purging them automatically by noticing that a binding is
now persistent or that the temporary address is available
for reuse.
- 結合が現在、永続的であるか、または仮の住所が再利用に利用可能であるのに気付くことによって、自動的にそれらを掃除します。
Brownell Informational [Page 9] RFC 1931 Dynamic RARP April 1996
ダイナミックな[9ページ]RFC1931RARP1996年4月の情報のブラウネル
Those clients will frequently make concurrent requests, and should be required to pass some kind of authorization check before they create or change any bindings. They may also need to know about other clients, in order to determine (for example) if a given DRARP server is spurious.
それらのクライアントは、頻繁に同時要求をして、どんな結合も作成するか、または変える前にある種の許可検査を通過しなければならないべきです。 また、彼らは、他のクライアントに関して知る必要があるかもしれません、与えられたDRARPサーバが偽りであるかどうか決定する(例えば)ために。
3.2 Multiple Authorities and Segments
3.2 複数の当局とセグメント
Note there is only a single address authority on a given network segment. It may be desirable to partition that authority, though that complicates implementation and administration of the authority substantially.
ただ一つのアドレス権威しか与えられたネットワークセグメントにないことに注意してください。 それは実質的に権威の実装と管理を複雑にしますが、その権威を仕切るのは望ましいかもしれません。
If detection of systems moving between network segments is to be provided, then the authorities for those two network segments must either be the same or (equivalently) must communicate with one another. Also, as noted earlier, hardware addresses must be scoped widely enough that the two segments do not assign the same link level address to different hosts.
ネットワークセグメントの間で移行するシステムの検出が提供することであるなら、それらの2つのネットワークセグメントのための当局は、同じでなければならないか、または(同等に)お互いにコミュニケートしなければなりません。 また、より早く注意されるように、2つのセグメントが同じリンク・レベルアドレスを異なったホストに割り当てないほど広くハードウェア・アドレスを見なければなりません。
3.3 Quality of Service
3.3 サービスの質
The records of temporary address bindings must be persistent for at least long enough to install a system and propagate its records through the site's administrative databases, even in the case of server or network faults. A timeout mechanism could be used to ensure that the limited address space was not used up too quickly. The initial implementation found that an hour's worth of caching, before deleting temporary bindings, was sufficient.
仮の住所結合の記録は少なくともサイトの管理データベースを通してシステムをインストールして、記録を伝播するくらいの長い間、永続的であるに違いありません、サーバかネットワーク障害の場合でさえ。 限られたアドレス空間がすばやく使いきられ過ぎたというわけではないのを保証するのにタイムアウトメカニズムを使用できました。 初期の実装によって、仮製本を削除する前に1時間のキャッシュの価値が十分であったのがわかりました。
Experience has shown that many networks have addresses in use which are not listed in their name services (or other administrative databases). On such networks, the Address Authority should have a way to learn when an address which it thinks is available for allocation is instead being actively used. Probing the network for "the truth" before handing out what turns out to be a duplicate IP address is a worthwhile. Both ARPing for the address and ICMP echo request have been used for this.
経験は、多くのネットワークには彼らの名前サービス(または、他の管理データベース)で記載されていない使用中のアドレスがあるのを示しました。 そのようなネットワークでは、Address Authorityはそれが配分に利用可能であると思うアドレスがいつ代わりに活発に使用されているかを学ぶ方法を持っているはずです。 写しIPアドレスになるように出ている回転がものであることを与える前の「真実」aにおいて、価値があるネットワークを調べます。 アドレスのためのARPingとICMPエコー要求の両方がこれに使用されました。
4. Security Considerations
4. セキュリティ問題
Security concerns are not addressed in this memo. They are recognized as significant, but they also interact with site-specific network administration policies. Those policies need to be addressed at higher levels before ramifications at this level can be understood.
安全上の配慮はこのメモで扱われません。 それらは重要であるとして認識されますが、また、彼らはサイト特有のネットワーク管理方針と対話します。 それらの方針は、このレベルにおける分岐を理解できる前に、より高いレベルで扱われる必要があります。
Brownell Informational [Page 10] RFC 1931 Dynamic RARP April 1996
ダイナミックな[10ページ]RFC1931RARP1996年4月の情報のブラウネル
5. References
5. 参照
[1] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, MIT, November 1982.
[1] プラマー、D.、「イーサネットアドレス解決プロトコル」、STD37、RFC826、MIT、1982年11月。
[2] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", STD 38, RFC 903, Stanford, June
1984.
[2] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」STD38、RFC903、スタンフォード(1984年6月)。
[3] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
Stanford, June 1984.
[3] フィンリースン、R.、「TFTPを使用して、ローディングを独力で進んでください」、RFC906、スタンフォード、1984年6月。
[4] Postel, J., "Multi-LAN Address Resolution", RFC 925,
USC/Information Sciences Institute, October 1984.
[4] ポステル、J.、「マルチLANアドレス解決」、RFC925、科学が1984年10月に設けるUSC/情報。
[5] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[5]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[6] Postel, J., and J. Reynolds, "A Standard for the Transmission of
IP Datagrams over IEEE802 Networks", STD 43, RFC 1042,
USC/Information Sciences Institute, February 1988.
[6] ポステル、J.、およびJ.レイノルズ、「IEEE802ネットワークの上のIPデータグラムの送信の規格」、STD43、RFC1042(科学が1988年2月に設けるUSC/情報)。
[7] IEEE; "IEEE Standards for Local Area Networks: Logical Link
Control" (IEEE 802.2); IEEE, New York, NY; 1985.
[7]IEEE。 「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」(IEEE802.2)。 IEEE、ニューヨークニューヨーク。 1985.
[8] United States Patent No. 4,689,786; "Local Area Network with
Self Assigned Address Method"; Issued August 25, 1987;
Inventors: Sidhu, et al.; Assignee: Apple Computer, Inc.
[8] 合衆国はNo.4,689,786の特許をとります。 「自己がいるローカル・エリア・ネットワークはアドレスメソッドを割り当てました」。 1987年8月25日に、発行されます。 発明者: Sidhu、他。 【譲受人】 アップル・コンピューターInc.
[9] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
Bucknell University, October 1993.
[9]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1541、Bucknell大学、1993年10月。
[10] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification, Version 2", RFC 1831, Sun Microsystems, August
1995.
[10]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様、バージョン2インチ、RFC1831、サン・マイクロシステムズ、1995年8月。
Author's Address:
作者のアドレス:
David Brownell SunSoft, Inc 2550 Garcia Way, MS 19-215 Mountain View, CA 94043
マウンテンビュー、MS19-215カリフォルニア デヴィッドブラウネルSunSoft、Inc2550ガルシアWay、94043
Phone: +1-415-336-1615 EMail: dbrownell@sun.com
以下に電話をしてください。 +1-415-336-1615 メールしてください: dbrownell@sun.com
Brownell Informational [Page 11]
ブラウネルInformationalです。[11ページ]
一覧
スポンサーリンク
