RFC906 日本語訳

Network Working Group                                     Ross Finlayson
Request for Comments: 906                            Stanford University
                                                               June 1984

コメントを求めるワーキンググループロスフィンリースンRequestをネットワークでつないでください: 906 スタンフォード大学1984年6月

                      Bootstrap Loading using TFTP

TFTPを使用して、ローディングを独力で進んでください。

Status of this Memo

このMemoの状態

   It is often convenient to be able to bootstrap a computer system from
   a communications network.  This RFC proposes the use of the IP TFTP
   protocol for bootstrap loading in this case.

通信網からコンピュータ・システムを独力で進むことができるのはしばしば便利です。 このRFCがIP TFTPプロトコルの使用を提案する、この場合ローディングを独力で進んでください。

   This RFC specifies a proposed protocol for the ARPA Internet
   community, and requests discussion and suggestions for improvements.

このRFCはARPAインターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを改良に指定します。

Introduction

序論

   Many computer systems, such as diskless workstations, are
   bootstrapped by loading one or more code files across a network.
   Unfortunately, the protocol used to load these initial files has not
   been standardized - numerous methods have been employed by different
   computer manufacturers. This can make it difficult, for example, for
   an installation to support several different kinds of systems on a
   local-area network.  Each different booting mechanism that is used
   must be supported, for example by implementing a number of servers on
   one or more host machines.  This is in spite of the fact that these
   heterogeneous systems may be able to communicate freely (all using
   the same protocol) once they have been booted.

ディスクレスワークステーションなどの多くのコンピュータ・システムがネットワークの向こう側により多くのローディング1コードファイルによって独力で進まれます。 残念ながら、これらの初期のファイルをロードするのに使用されるプロトコルは標準化されていません--多数のメソッドは異なったコンピュータメーカーによって使われました。 これで、ローカル・エリア・ネットワークでいくつかの異種のシステムをサポートするのは例えばインストールに難しくなる場合があります。 それぞれの使用された異なった穂ばらみメカニズムをサポートしなければなりません、例えば、1個以上のホスト・マシンの上の多くのサーバを実装することによって。 これらの多相系が自由に交信できるかもしれないという(同じプロトコルをすべて使用して)事実にもかかわらず、いったん起動するようになると、これはあります。

   We propose that TFTP (Trivial File Transfer Protocol) [6] be used as
   a standard protocol for bootstrap loading.  This protocol is
   well-suited for our purpose, being based on the standard Internet
   Protocol (IP) [4].  It is easily implemented, both in the machines to
   be booted, and in bootstrap servers elsewhere on the net.  (In
   addition, many popular operating systems already support TFTP
   servers.)  The fact that TFTP is a rather slow protocol is not a
   serious concern, due to the fact that it need be used only for the
   primary bootstrap.  A secondary bootstrap could use a faster
   protocol.

私たちが、TFTP(トリビアル・ファイル転送プロトコル)[6]が標準プロトコルとして使用されるよう提案する、ローディングを独力で進んでください。 標準のインターネットプロトコル(IP)[4]に基づいて、このプロトコルは私たちの目的に十分合っています。 それはともにマシンで起動していると容易に実装されます、そして、ネットのほかの場所のサーバは中に独力で進みます。 (さらに、多くのポピュラーなオペレーティングシステムが既にTFTPにサーバをサポートします。) 予備選挙が単に独力で進んで、事実のためにTFTPがかなり遅いプロトコルであるという事実はそれが使用されなければならないという真剣な関心ではありません。 2番目が独力で進むAは、より速いプロトコルを使用できました。

   This RFC describes how system to be booted (called the "booter"
   below) would use TFTP to load a desired code file.  It also describes
   an existing implementation (in ROM) for Ethernet.

このRFCは起動している(以下に「フットボール選手」と呼ばれます)システムが必要なコードファイルをロードするのにどうTFTPを使用するだろうかを説明します。 また、それはイーサネットのために、既存の実装(ROMの)について説明します。

   Note that we are specifying only the network protocols that would be
   used by the booting system.  We do not attempt to mandate the method
   by which a user actually boots a system (such as the format of a
   command typed at the console).  In addition, our proposal does not

私たちが穂ばらみシステムによって使用されるネットワーク・プロトコルだけを指定していることに注意してください。 私たちは、ユーザが実際に、システム(コンソールでタイプされたコマンドの形式などの)をブートするメソッドを強制するのを試みません。 さらに、私たちの提案はそうしません。

Finlayson                                                       [Page 1]

フィンリースン[1ページ]

RFC 906                                                        June 1984

RFC906 1984年6月

   presuppose the use of any particular data-link level network
   architecture (although the example that we describe below uses
   Ethernet).

どんなデータ・リンクの特定のレベルネットワークアーキテクチャの使用も予想してください(私たちが以下で説明する例はイーサネットを使用しますが)。

Network Protocols used by the Booting System

Booting Systemによって使用されたネットワークプロトコル

   To load a file, the booter sends a standard TFTP read request (RRQ)
   packet, containing the name of the file to be loaded.  The file name
   should not assume any operating system dependent naming conventions
   (file names containing only alphanumeric characters should suffice).
   Thereafter, the system receives TFTP DATA packets, and sends TFTP ACK
   and/or ERROR packets, in accordance with the TFTP specification [6].

ファイルをロードするために、フットボール選手は標準のTFTP読み出し要求(RRQ)パケットを送ります、ロードされるべきファイルの名前を含んでいて。 ファイル名は、どんなオペレーティングシステムも依存する命名規則であると仮定するべきではありません(英数字だけを含むファイル名は十分であるべきです)。 その後、システムは、TFTP DATAパケットを受けて、TFTP ACK、そして/または、ERRORにパケットを送ります、TFTP仕様[6]通りに。

   TFTP is implemented using the User Datagram Protocol (UDP) [5], which
   is in turn implemented using IP.  Thus, the booter must be able to
   receive IP datagrams containing up to 524 octets (excluding the IP
   header), since TFTP DATA packets can be up to 516 octets long, and
   UDP headers are 8 octets long.  The booting machine is not required
   to respond to incoming TFTP read or write requests.

TFTPは、ユーザー・データグラム・プロトコル(UDP)[5](IPを使用することで順番に実装される)を使用することで実装されます。 したがって、フットボール選手は最大524の八重奏(IPヘッダーを除いた)を含むIPデータグラムを受け取ることができなければなりません、長い間TFTP DATAパケットが最大516の八重奏であるかもしれなく、長い間UDPヘッダーが8つの八重奏であるので。 穂ばらみマシンは、TFTPが読む入来に応じるか、または要求を書くのに必要ではありません。

   We allow for the use of two additional protocols.  These are ARP
   (Address Resolution Protocol) [3], and RARP (Reverse Address
   Resolution Protocol) [1]. The possible use of these protocols is
   described below.  The booter could also use other protocols (such as
   for name lookup), but they should be IP-based, and an internet
   standard.

私たちは2つの追加議定書の使用を考慮します。 これらは、ARP(アドレスResolutionプロトコル)[3]と、RARP(逆アドレス解決プロトコル)[1]です。 これらのプロトコルの活用可能性は以下で説明されます。 また、フットボール選手は他のプロトコル(名前ルックアップなどの)を使用するかもしれませんが、それらはIPベースであるべきであり、インターネットは標準です。

   The IP datagram containing the initial TFTP RRQ (and all other IP
   datagrams sent by the booter) must of course contain both a source
   internet address and a destination internet address in its IP header.
   It is frequently the case, however, that the booter does not
   initially know its own internet address, but only a lower-level (e.g.
   Ethernet) address.  The Reverse Address Resolution Protocol
   (RARP) [1] may be used by the booter to find its internet address
   (prior to sending the TFTP RRQ).  RARP was motivated by Plummer's
   Address Resolution Protocol (ARP) [3].  Unlike ARP, which is used to
   find the 'hardware' address corresponding to a known higher-level
   protocol (e.g. internet) address, RARP is used to determine a
   higher-level protocol address, given a known hardware address.  RARP
   uses the same packet format as ARP, and like ARP, can be used for a
   wide variety of data-link protocols.

初期のTFTP RRQ(そして、フットボール選手によって送られた他のすべてのIPデータグラム)を含むIPデータグラムはもちろんIPヘッダーにソースインターネットアドレスと送付先インターネットアドレスの両方を含まなければなりません。 しかしながら、頻繁にフットボール選手は初めは、それ自身のインターネットアドレスを知るのではなく、低レベル(例えば、イーサネット)アドレスだけを知るのが、事実です。 逆アドレス解決プロトコル(RARP)[1]はフットボール選手によって使用されて、インターネットがアドレス(TFTP RRQを送る前の)であることがわかるかもしれません。 RARPはプラマーのAddress Resolutionプロトコル(ARP)[3]によって動機づけられました。 ARPと異なって、RARPは上位レベル・プロトコルアドレスを決定するのに使用されます、知られているハードウェア・アドレスを考えて。ARPは、'ハードウェア'アドレスが知られている上位レベル・プロトコルに対応する(例えば、インターネット)アドレスであることがわかるのに使用されます。 RARPはARPと同じパケット・フォーマットを使用します、そして、ARPのように、さまざまなデータリンクプロトコルに使用できます。

   ARP may also be used.  If the destination internet address is known,
   then an ARP request containing this address may be broadcast, to find
   a corresponding hardware address to which to send the subsequent TFTP
   RRQ.  It may not matter if this request should fail, because the RRQ
   can also be broadcast (at the data-link level).  However, because
   such an ARP request packet also contains the sender's (that is, the

また、ARPは使用されるかもしれません。 送付先インターネットアドレスが知られているなら、このアドレスを含むARP要求は、その後のTFTP RRQを送る対応するハードウェア・アドレスを見つけるために放送されるかもしれません。 この要求がまた、RRQを放送できるので(データ・リンクレベルで)失敗するべきであるかどうかは重要でないかもしれません。 また、しかしながら、ARPリクエスト・パケットは、あれほどので、送付者のものを含んでいます。(それはそうです。

Finlayson                                                       [Page 2]

フィンリースン[2ページ]

RFC 906                                                        June 1984

RFC906 1984年6月

   booter's) internet and hardware addresses, this information is made
   available to the rest of the local subnet, and could be useful for
   routing, for instance.

フットボール選手のもの) インターネットとハードウェアアドレス、この情報は、地方のサブネットの残りに利用可能に作られていて、例えば、ルーティングの役に立つかもしれません。

   If a single destination internet address is not known, then a special
   'broadcast' internet address could be used as the destination address
   in the TFTP RRQ, so that it will be received by all 'local' internet
   hosts.  (At this time, however, no standard for internet broadcasting
   has been officially adopted. [**])

ただ一つの送付先インターネットアドレスが知られていないなら、特別な'放送'インターネットアドレスはTFTP RRQの送付先アドレスとして使用されるかもしれません、それがすべての'地方'のインターネットホストによって受け取られるように。 (しかしながら、このとき、インターネット放送の規格は全く公式に採用されません。 [**])

An Example Implementation

例の実装

   The author has implemented TFTP booting as specified above.  The
   resulting code resides in ROM.  (This implementation is for a
   Motorola 68000 based workstation, booting over an Ethernet.)  A user
   wishing to boot such a machine types a file name, and (optionally)
   the internet address of the workstation, and/or the internet address
   of a server machine from which the file is to be loaded.  The
   bootstrap code proceeds as follows:

作者は、上で指定されるとしてTFTPが穂ばらみであると実装しました。 結果として起こるコードはROMにあります。 (この実装はモトローラの68000のベースのワークステーション、イーサネットの上の穂ばらみのためのものです。) そのようなマシンをブートしたがっているユーザはファイル名と、ワークステーションの(任意に)インターネットアドレス、そして/または、ロードされているファイルがことであるサーバマシンのインターネットアドレスをタイプします。 以下のコード売り上げを独力で進んでください:

      (1) The workstation's Ethernet address is found (by querying the
      Ethernet interface).

(1) ワークステーションのイーサネット・アドレスは見つけられます(イーサネットインタフェースについて質問することによって)。

      (2) If the internet address of the workstation was not given, then
      a RARP request is broadcast, in order to find it.  If this request
      fails (that is, times out), then the bootstrap fails.

(2) ワークステーションのインターネットアドレスが与えられなかったなら、RARP要求は放送されます、それを見つけるために。 次に、この要求が失敗する、(すなわち、回が外にある状態で)やり損ないを独力で進んでください。

      (3) If the internet address of a server host was given, then
      broadcast an ARP request to try to find a corresponding Ethernet
      address.  If this fails, or if a server internet address was not
      given, then the Ethernet broadcast address is used.

(3) サーバー・ホストのインターネットアドレスを与えたなら、対応するイーサネット・アドレスを見つけようとするというARP要求を放送してください。 これが失敗したか、またはサーバインターネットアドレスが与えられなかったなら、イーサネット放送演説は使用されています。

      (4) If the internet address of a server host was not given, then
      we use a special internet address that represents a broadcast on
      the "local subnet", as described in [2].  (This is not an internet
      standard.)

(4) サーバー・ホストのインターネットアドレスが与えられなかったなら、私たちは「地方のサブネット」に放送を表す特別なインターネットアドレスを使用します、[2]で説明されるように。 (これはインターネット規格ではありません。)

      (5) A TFTP RRQ for the requested file is sent to the Ethernet
      address found in step (3).  The source internet address is that
      found in step (2), and the destination internet address is that
      found in step (4).

(5) ステップ(3)で見つけられたイーサネット・アドレスに要求されたファイルのためのTFTP RRQを送ります。 ソースインターネットアドレスは見つけられて、ステップ(4)で見つけられたそれがステップ(2)、および送付先インターネットアドレスに、いるということです。

   Note that because several TFTP servers may, in general, reply to the
   RRQ, we do not abort if a TFTP ERROR packet is received, because this
   does not preclude the possibility of some other server replying later
   with the first data packet of the requested file.  When the first
   valid TFTP DATA packet is received in response to the RRQ, the source
   internet and Ethernet addresses of this packet are used as the

TFTP ERRORパケットが受け取られているならいくつかのTFTPサーバが一般にRRQに答えるかもしれないので私たちが中止にならないことに注意してください、これがある他のサーバが後で要求されたファイルの最初のデータ・パケットで返答する可能性を排除しないので。 このパケットのソースのいつRRQに対応して最初の有効なTFTP DATAパケットを受け取るか、そして、インターネットとイーサネット・アドレスは使用されます。

Finlayson                                                       [Page 3]

フィンリースン[3ページ]

RFC 906                                                        June 1984

RFC906 1984年6月

   destination addresses in subsequent TFTP ACK packets.  Should another
   server later respond with a DATA packet, an ERROR packet is sent back
   in response.

目的地はその後のTFTP ACKでパケットを扱います。 別のサーバが後でDATAパケットで反応するなら、ERRORパケットは応答で返送されます。

   An implementation of TFTP booting can take up a lot of space if care
   is not taken.  This can be a significant problem if the code is to
   fit in a limited amount of ROM.  However, the implementation
   described above consists of less than 4K bytes of code (not counting
   the Ethernet device driver).

注意しないなら、TFTP穂ばらみの実装は多くのスペースを取ることができます。 コードがROMの数量限定をうまくはめ込むことであるなら、これは重大な問題であるかもしれません。 しかしながら、上で説明された実装は4K未満のバイトのコードから成ります(イーサネットデバイスドライバを数えないで)。

Acknowledgements

承認

   The ideas presented here are the result of discussions with several
   other people, in particular Jeff Mogul.

ここに提示された考えは特定のジェフ・ムガール人の数人の他の人々との議論の結果です。

References

参照

   [1]  Finlayson, R.,  Mann, T.,  Mogul, J.  & Theimer, M.,  "A Reverse
        Address Resolution Protocol", RFC 903  Stanford University,
        June 1984.

[1] フィンリースン、R.、マン、T.、ムガール人、J.、およびTheimer、M.、「逆は解決プロトコルを扱います」、RFC。903スタンフォード大学(1984年6月)。

   [2]  Mogul, J., "Internet Broadcasting",  Proposed RFC, January 1984.

[2] J.、「インターネット放送」というムガール人はRFC、1984年1月を提案しました。

   [3]  Plummer, D., "An Ethernet Address Resolution Protocol",
        RFC 826,  MIT-LCS, November 1982.

[3] プラマー、D.、「イーサネットアドレス解決プロトコル」、RFC826、MIT-LCS、1982年11月。

   [4]  Postel, J., ed., "Internet Protocol - DARPA Internet Program
        Protocol Specification", RFC 791, USC/Information Sciences
        Institute, September 1981.

[4] ポステル、J.、教育、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、USC/情報Sciences Institute、9月1981日

   [5]  Postel, J., "User Datagram Protocol", RFC 768 USC/Information
        Sciences Institute, August 1980.

[5] ポステル、J.、「ユーザー・データグラム・プロトコル」とRFC768USC/情報科学は、1980年8月に設けます。

   [6]  Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT/LCS,
        June 1981.

[6]Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、MIT/LCS、1981年6月。

   [**]  Editor's Note:  While there is no standard for an Internet wide
        broadcast or multicast address, it is strongly recommended that
        the "all ones" local part of the Internet address be used to
        indicate a broadcast in a particular network.  That is, in class
        A network 1 the broadcast address would be 1.255.255.255, in
        class B network 128.1 the broadcast address would be
        128.1.255.255, and in class C network 192.1.1 the broadcast
        address would be 192.1.1.255.

[**] 編集者注: 「すべてのもの」ローカルは離れています。インターネットの広い放送かマルチキャストアドレスの規格が全くない間、それが強くそれに推薦される、インターネット・アドレスに、使用されて、特定のネットワークで放送を示してください。 放送演説はそうでしょう。すなわち、放送が扱う1が分類するクラスAネットワークでは、.255、コネが1.255が.255であったなら128.1が.255であったなら放送が扱う128.1が分類するBネットワークを分類する、クラスCがネットワークでつなぐ.255、およびコネ、192.1、.1、192.1 .1 .255。

Finlayson                                                       [Page 4]

フィンリースン[4ページ]