RFC1395 日本語訳

Network Working Group                                       J. Reynolds
Request for Comments: 1395                                          ISI
Obsoletes: 1084, 1048                                      January 1993
Updates: 951

コメントを求めるワーキンググループJ.レイノルズの要求をネットワークでつないでください: 1395ISIは以下を時代遅れにします。 1084、1048 1993年1月は以下をアップデートします。 951

                  BOOTP Vendor Information Extensions

BOOTP売り主情報拡張子

Status of this Memo

このMemoの状態

   This memo is a status report on the vendor information extensions
   used in the Bootstrap Protocol (BOOTP).  Distribution of this memo is
   unlimited.

このメモはBootstrapプロトコル(BOOTP)に使用される売り主情報拡張子に関する現状報告です。 このメモの分配は無制限です。

Introduction

序論

   This RFC is a slight revision and extension of RFC-1048 by Philip
   Prindeville, who should be credited with the original work in this
   memo.  This memo will be updated as additional tags are are defined.
   This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain
   Name, Tag 16 for Swap Server and Tag 17 for Root Path.

このRFCはフィリップPrindevilleによるRFC-1048のわずかな改正と拡大です。(オリジナルの仕事はこのメモでPrindevilleで称賛されるべきです)。 このメモは追加するとしてアップデートして、タグがあるということでしょう。定義されます。 この版はMerit Dump FileのためのTag14、Domain NameのためのTag15、Swap ServerのためのTag16、およびRoot PathのためのTag17を導入します。

   As workstations and personal computers proliferate on the Internet,
   the administrative complexity of maintaining a network is increased
   by an order of magnitude.  The assignment of local network resources
   to each client represents one such difficulty.  In most environments,
   delegating such responsibility to the user is not plausible and,
   indeed, the solution is to define the resources in uniform terms, and
   to automate their assignment.

ワークステーションとパーソナルコンピュータがインターネットで増殖するのに従って、ネットワークを維持する管理複雑さは1桁増強されます。 各クライアントへの企業内情報通信網リソースの課題はそのような困難の1つを表します。 本当に、ソリューションは、ほとんどの環境で、そのような責任をユーザへ代表として派遣するのがもっともらしくなく、一定の用語によるリソースを定義して、彼らの課題を自動化することです。

   The basic Bootstrap Protocol [RFC-951] dealt with the issue of
   assigning an internet address to a client, as well as a few other
   resources.  The protocol included provisions for vendor-defined
   resource information.

基本的なBootstrapプロトコル[RFC-951]はインターネットアドレスをクライアントに割り当てる問題に対処しました、他のいくつかのリソースと同様に。 プロトコルはベンダーによって定義されたリソース情報のための条項を含んでいました。

   This memo defines a (potentially) vendor-independent interpretation
   of this resource information.

このメモはこのリソース情報の(潜在的に)ベンダーから独立している解釈を定義します。

Overview of BOOTP

BOOTPの概要

   While the Reverse Address Resolution (RARP) Protocol [RFC-903] may be
   used to assign an IP address to a local network hardware address, it
   provides only part of the functionality needed.  Though this protocol
   can be used in conjunction with other supplemental protocols (the
   Resource Location Protocol [RFC-887], the Domain Name System [RFC-
   1034]), a more integrated solution may be desirable.

Reverse Address Resolution(RARP)プロトコル[RFC-903]はIPアドレスを企業内情報通信網ハードウェア・アドレスに割り当てるのに使用されるかもしれませんが、それは必要である機能性の一部だけを提供します。 他の補足のプロトコル(Resource Locationプロトコル[RFC-887]、ドメインネームシステム[RFC1034])に関連してこのプロトコルを使用できますが、より統合しているソリューションは望ましいかもしれません。

Reynolds                                                        [Page 1]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[1ページ]RFC1395BOOTP拡大1993年1月

   Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol that allows a
   booting host to configure itself dynamically, and more significantly,
   without user supervision.  It provides a means to assign a host its
   IP address, a file from which to download a boot program from some
   server, that server's address, and (if present) the address of an
   Internet gateway.

独力で進んでください。プロトコル(BOOTP)は穂ばらみホストがそれ自体をダイナミックに、そして、よりかなり構成できるIP UDP/ベースのプロトコルです、ユーザ指揮なしで。 それはIPアドレスをホストに割り当てる手段を提供します、インターネット・ゲートウェイの何らかのサーバ、そのサーバのアドレス、および(存在しているなら)アドレスから起動プログラムをダウンロードするファイル。

   One obvious advantage of this procedure is the centralized management
   of network addresses, which eliminates the need for per-host unique
   configuration files.  In an environment with several hundred hosts,
   maintaining local configuration information and operating system
   versions specific to each host might otherwise become chaotic.  By
   categorizing hosts into classes and maintaining configuration
   information and boot programs for each class, the complexity of this
   chore may be reduced in magnitude.

この手順の1つの明白な利点がネットワーク・アドレスが集中的管理です。(その集中的管理は1ホストあたりのユニークな構成ファイルの必要性を排除します)。 そうでなければ、数100人のホストがいる環境で、ローカルの設定情報とオペレーティングシステムバージョンを各ホストにとって特定に維持するのは混沌となるかもしれません。 各クラスのためにホストをクラスに分類して、設定情報と起動プログラムを維持することによって、この雑役の複雑さは大きさで減少するかもしれません。

BOOTP Vendor Information Format

BOOTP売り主情報形式

   The full description of the BOOTP request/reply packet format may be
   found in [RFC-951].  The rest of this document will concern itself
   with the last field of the packet, a 64 octet area reserved for
   vendor information, to be used in a hitherto unspecified fashion.  A
   generalized use of this area for giving information useful to a wide
   class of machines, operating systems, and configurations follows.  In
   situations where a single BOOTP server is to be used among
   heterogeneous clients in a single site, a generic class of data may
   be used.

BOOTP要求/回答パケット・フォーマットの余すところのない解説は[RFC-951]で見つけられるかもしれません。 このドキュメントの残りは、これまで不特定のファッションで使用されるためにパケットの最後の分野、売り主情報のために予約された64八重奏領域に携わるでしょう。 この領域の広いクラスのマシン、オペレーティングシステム、および構成の役に立つ知らせる一般化された使用は続きます。 ただ一つのBOOTPサーバがただ一つのサイトの異種のクライアントの中で使用されることである状況で、データのジェネリックのクラスは使用されるかもしれません。

   Vendor Information "Magic Cookie"

売り主情報「魔法クッキー」

      As suggested in [RFC-951], the first four bytes of this field have
      been assigned to the magic cookie, which identifies the mode in
      which the succeeding data is to be interpreted.  The value of the
      magic cookie is the 4 octet dotted decimal 99.130.83.99 (or
      hexadecimal number 63.82.53.63) in network byte order.

[RFC-951]に示されるように、この分野の最初の4バイトを魔法のクッキーに割り当ててあります。(それは、解釈される続くデータがことであるモードを特定します)。 魔法のクッキーの値が4八重奏ドット付き10進法99.130.83.99である、(16進数、63.82、.53、.63、)、ネットワークバイトオーダーで。

   Format of Individual Fields

個々の分野の形式

      The vendor information field has been implemented as a free
      format, with extendable tagged sub-fields.  These sub-fields are
      length tagged (with exceptions; see below), allowing clients not
      implementing certain types to correctly skip fields they cannot
      interpret.  Lengths are exclusive of the tag and length octets;
      all multi-byte quantities are in network byte-order.

ベンダー情報フィールドはフリー・フォーマットとして「広げ-可能」タグ付けをされたサブ分野で実装されました。 これらのサブ分野はあるタイプを実装しないクライアントが正しく、彼らが解釈できない分野をスキップするのを許容して、タグ付けをされた(例外で; 以下を見てください)長さです。 長さがタグと長さの八重奏を除いてあります。 ネットワークバイトオーダーにはすべてのマルチバイト量があります。

Reynolds                                                        [Page 2]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[2ページ]RFC1395BOOTP拡大1993年1月

      Fixed Length Data

固定長データ

         The fixed length data are comprised of two formats.  Those that
         have no data consist of a single tag octet and are implicitly
         of one-octet length, while those that contain data consist of
         one tag octet, one length octet, and length octets of data.

固定長データは2つの形式から成ります。 データを含むものがデータの1つのタグ八重奏、ワンレン八重奏、および長さの八重奏から成る間のデータを全くただ一つのタグ八重奏から成らせないで、それとなくさせる1八重奏の長さのもの。

         Pad Field (Tag: 0, Data: None)

パッド分野(タグ: 0、データ: なにも)

            May be used to align subsequent fields to word boundaries
            required by the target machine (i.e., 32-bit quantities such
            as IP addresses on 32-bit boundaries).

ターゲットマシン(すなわち、32ビットの境界に関するIPアドレスなどの32ビットの量)によって必要とされた語境界にその後の分野を並べるのに使用されるかもしれません。

         Subnet Mask Field (Tag: 1, Data: 4 subnet mask bytes)

サブネットマスク分野(Data: タグ: 1、4サブネットマスクバイト)

            Specifies the net and local subnet mask as per the standard
            on subnetting [RFC-950].  For convenience, this field must
            precede the GATEWAY field (below), if present.

サブネッティング[RFC-950]の規格に従ってネットの、そして、地方のサブネットマスクを指定します。 便宜のために、存在しているなら、この分野はゲートウェイ分野(below)に先行しなければなりません。

         Time Offset Field (Tag: 2, Data: 4 time offset bytes)

時間オフセット分野(Data: タグ: 2、4時間オフセットバイト)

            Specifies the time offset of the local subnet in seconds
            from Coordinated Universal Time (UTC); signed 32-bit
            integer.

協定世界時(UTC)から秒の地方のサブネットの時間オフセットを指定します。 32ビットの整数であると署名されます。

         End Field (Tag: 255, Data: None)

端の分野(タグ: 255、データ: なにも)

            Specifies end of usable data in the vendor information area.
            The rest of this field should be filled with PAD zero)
            octets.

売り主情報領域で使用可能なデータの終わりを指定します。 この分野の残りはPADゼロ) 八重奏で満たされるべきです。

      Variable Length Data

可変長データ

         The variable length data has a single format; it consists of
         one tag octet, one length octet, and length octets of data.

可変長データには、ただ一つの形式があります。 それはデータの1つのタグ八重奏、ワンレン八重奏、および長さの八重奏から成ります。

         Gateway Field (Tag: 3, Data: N address bytes)

ゲートウェイ分野(Data: タグ: 3、Nアドレスのバイト)

            Specifies the IP addresses of N/4 gateways for this subnet.
            If one of many gateways is preferred, that should be first.

N/4門のIPアドレスをこのサブネットに指定します。 多くのゲートウェイの1つが好まれるなら、それは1番目であるべきです。

         Time Server Field (Tag: 4, Data: N address bytes)

時間サーバ分野(Data: タグ: 4、Nアドレスのバイト)

            Specifies the IP addresses of N/4 time servers [RFC-868].

N/4つの時間サーバ[RFC-868]のIPアドレスを指定します。

         IEN-116 Name Server Field (Tag: 5, Data: N address bytes)

IEN-116ネームサーバ分野(Data: タグ: 5、Nアドレスのバイト)

            Specifies the IP addresses of N/4 name servers [IEN-116].

N/4つのネームサーバ[IEN-116]のIPアドレスを指定します。

Reynolds                                                        [Page 3]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[3ページ]RFC1395BOOTP拡大1993年1月

         Domain Name Server Field (Tag: 6, Data: N address bytes)

ドメイン名サーバ分野(Data: タグ: 6、Nアドレスのバイト)

            Specifies the IP addresses of N/4 domain name servers RFC-
            1034].

N/4つのドメイン名サーバRFC1034年の]IPアドレスを指定します。

         Log Server Field (Tag: 7, Data: N address bytes)

ログサーバ分野(Data: タグ: 7、Nアドレスのバイト)

            Specifies the IP addresses of N/4 MIT-LCS UDP log server
            [LOGGING].

N/4MIT-LCS UDPログサーバ[LOGGING]のIPアドレスを指定します。

         Cookie/Quote Server Field (Tag: 8, Data: N address bytes)

クッキー/引用文のサーバ分野(Data: タグ: 8、Nアドレスのバイト)

            Specifies the IP addresses of N/4 Quote of the Day servers
            [RFC-865].

デーサーバ[RFC-865]のN/4QuoteのIPアドレスを指定します。

         LPR Server Field (Tag: 9, Data: N address bytes)

LPRサーバ分野(Data: タグ: 9、Nアドレスのバイト)

            Specifies the IP addresses of N/4 Berkeley 4BSD printer
            servers [LPD].

N/4つのバークレー4BSDプリンタサーバ[LPD]のIPアドレスを指定します。

         Impress Server Field (Tag: 10, Data: N address bytes)

押印サーバ分野(Data: タグ: 10、Nアドレスのバイト)

            Specifies the IP addresses of N/4 Impress network image
            servers [IMAGEN].

N/4つのImpressネットワークイメージサーバ[IMAGEN]のIPアドレスを指定します。

         RLP Server Field (Tag: 11, Data: N address bytes)

RLPサーバ分野(Data: タグ: 11、Nアドレスのバイト)

            Specifies the IP addresses of N/4 Resource Location Protocol
            (RLP) servers [RFC-887].

N/4Resource Locationプロトコル(RLP)サーバ[RFC-887]のIPアドレスを指定します。

         Hostname (Tag: 12, Data: N bytes of hostname)

ホスト名(Data: タグ: 12、Nバイトのホスト名)

            Specifies the name of the client. The name may or may not
            domain qualified: this is a site-specific issue.

クライアントの名前を指定します。 名前はそうするかもしれません。ドメインは資格を得ました: これはサイト特有の問題です。

         Boot File Size (Tag: 13, Data: 2)

ブート・ファイルサイズ(データ: タグ: 13、2)

            A two octet value (in network order) specifying the number
            of 512 octet blocks in the default boot file.  Informs BOOTP
            client how large the BOOTP file image is.

512八重奏の数を指定する2八重奏価値(ネットワークオーダーにおける)はデフォルトブート・ファイルの輪郭を描きます。 BOOTPファイルイメージがどれくらい大きいかをBOOTPクライアントに知らせます。

         Merit Dump File (Tag: 14, Data: N bytes of filename)

長所ダンプファイル(Data: タグ: 14、Nバイトのファイル名)

            Name of a file to dump core of this client to.

このクライアントのコアをどさっと落とすファイルの名前。

Reynolds                                                        [Page 4]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[4ページ]RFC1395BOOTP拡大1993年1月

         Domain Name  (Tag: 15, Data: N bytes of domain name)

ドメイン名(Data: タグ: 15、Nバイトのドメイン名)

            Specifies the domain name of the client for Domain Name
            Server (DNS) resolution [RFC-1034].

Domain Name Server(DNS)解決[RFC-1034]にクライアントのドメイン名を指定します。

         Swap Server (Tag: 16, Data: 4 address bytes)

サーバを交換してください。(Data: タグ: 16、4アドレスのバイト)

            An IP address to hold the IP address of a swap server.

スワッピングサーバのIPアドレスを保持するIPアドレス。

         Root Path  (Tag: 17, Data: N bytes of path name)

根の経路(Data: タグ: 17、Nバイトのパス名)

            A string to specify a pathname to mount as a root disk.

ルートディスクとして上がるようにパス名を指定する五弦。

         Reserved Fields (Tag: 128-254, Data: N bytes of undefined
         content)

予約された分野(Data: タグ: 128-254、Nバイトの未定義の内容)

            Specifies additional site-specific information, to be
            interpreted on an implementation-specific basis.  This
            should follow all data with the preceding generic tags 0-
            127).

実装特有のベースで解釈されるために追加サイト特殊情報を指定します。 これが前のジェネリックタグ0- 127ですべてのデータに従うべきである、)

Extensions

拡大

   Additional generic data fields may be registered by contacting:

追加ジェネリックデータ・フィールドは、以下に連絡することによって、示されるかもしれません。

          Internet Assigned Numbers Authority (IANA)
          Information Sciences Institute
          University of Southern California
          4676 Admiralty Way
          Marina del Rey, California  90292-6695

南カリフォルニア4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695のインターネットAssigned民数記Authority(IANA)情報Sciences Institute大学

          or by email as: iana@isi.edu

または、以下としてのメールで iana@isi.edu

   Implementation specific use of undefined generic types (those in the
   range 18-127) may conflict with other implementations, and
   registration is required.

未定義のジェネリックタイプ(範囲18-127のそれら)の実装特定的用法は他の実装と衝突するかもしれません、そして、登録が必要です。

   When selecting information to put into the vendor specific area, care
   should be taken to not exceed the 64 byte length restriction.
   Nonessential information (such as host name and quote of the day
   server) may be excluded, which may later be located with a more
   appropriate service protocol, such as RLP or the WKS resource-type of
   the domain name system.  Indeed, even RLP servers may be discovered
   using a broadcast request to locate a local RLP server.

ベンダーの特定の領域を入れるために情報を選択するとき、64バイトの長さの制限を超えないように注意するべきです。 不要不急な情報(ホスト名や今日の名言サーバなどの)は除かれるかもしれません、RLPやドメイン名システムのWKSリソースタイプのように。(情報は後でより適切なサービスプロトコルで見つけられるかもしれません)。 本当に、RLPサーバさえローカルのRLPサーバの場所を見つけるという放送要求を使用していると発見されるかもしれません。

Reynolds                                                        [Page 5]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[5ページ]RFC1395BOOTP拡大1993年1月

Comparison to Alternative Approaches

代替的アプローチとの比較

   Extending BOOTP to provide more configuration information than the
   minimum required by boot PROMs may not be necessary.  Rather than
   having each module in a host (e.g., the time module, the print
   spooler, the domain name resolver) broadcast to the BOOTP server to
   obtain the addresses of required servers, it would be better for each
   of them to multicast directly to the particular server group of
   interest, possibly using "expanding ring" multicasts.

ブーツPROMによって必要とされた最小限より多くの設定情報を提供するためにBOOTPを広げるのは必要でないかもしれません。 むしろ、それぞれのそれらには、それは必要なサーバのアドレスを得るためにホスト(例えば、時間モジュール、プリントスプーラ、ドメイン名レゾルバ)放送における各モジュールをBOOTPサーバに持っているより直接興味深い特定のサーバグループへのマルチキャストに良いでしょう、ことによると「拡張リング」マルチキャストを使用して。

   The multicast approach has the following advantages over the BOOTP
   approach:

マルチキャストアプローチには、BOOTPアプローチより以下の利点があります:

    - It eliminates dependency on a third party (the BOOTP server) that
    may be temporarily unavailable or whose database may be incorrect or
    incomplete.  Multicasting directly to the desired services will
    locate those servers that are currently available, and only those.

- それはデータベースが一時入手できないかもしれないか、不正確であるかまたは不完全であるかもしれない第三者(BOOTPサーバ)の上で依存を根絶します。 直接必要なサービスへのマルチキャスティングはそれらの現在利用可能なサーバ、およびそれらだけの場所を見つけるでしょう。

    - It reduces the administrative chore of keeping the (probably
    replicated) BOOTP database up-to-date and consistent.  This is
    especially important in an environment with a growing number of
    services and an evolving population of servers.

- それは(たぶん模写されています)のBOOTPデータベースを最新で一貫しているように保つ管理雑役を減少させます。 増加している数のサービスとサーバの発展している人口のために、これは環境で特に重要です。

    - In some cases, it reduces the amount of packet traffic and/or the
    delay required to get the desired information.  For example, the
    current time can be obtained by a single multicast to a time server
    group which evokes replies from those time servers that are
    currently up.  The BOOTP approach would require a broadcast to the
    BOOTP server, a reply from the BOOTP server, one or more unicasts to
    time servers (perhaps waiting for long timeouts if the initially
    chosen server(s) are down), and finally a reply from a server.

- いくつかの場合、パケットトラフィックの量を減少させます、そして、遅れが必要な情報を得るのが必要です。 例えば、ただ一つのマルチキャストはそれらの現在上がっている時間サーバから回答を喚起する時間サーバグループに現在の時間を得ることができます。 BOOTPアプローチはBOOTPサーバ、BOOTPサーバからの回答、時間サーバ(恐らく、初めは選ばれたサーバが下がっているなら、長いタイムアウトを待っている)への1つ以上のユニキャスト、およびサーバからの最終的に回答に放送を必要とするでしょう。

   One apparent advantage of the proposed BOOTP extensions is that they
   provide a uniform way to locate servers.  However, the multicast
   approach could also be implemented in a consistent way across
   multiple services.  The V System naming protocol is a good example of
   this; character string pathnames are used to name any number of
   resources (i.e., not just files) and a standard subroutine library
   looks after multicasting to locate the resources, caching the
   discovered locations, and detecting stale cache data.

提案されたBOOTP拡張子の1つの見かけの利点はサーバの場所を見つける一定の方法を提供するということです。 しかしながら、また、複数のサービスの向こう側に一貫した方法でマルチキャストアプローチを実装することができました。 V System命名プロトコルはこの好例です。 文字列パス名はいろいろなリソース(すなわち、ただ、ファイルしない)を命名するのに使用されます、そして、標準のサブルーチンライブラリはリソースの場所を見つけるようにマルチキャスティングの世話をします、発見された位置をキャッシュして、聞き古したキャッシュデータを検出して。

   Another apparent advantage of the BOOTP approach is that it allows an
   administrator to easily control which hosts use which servers.  The
   multicast approach favors more distributed control over resource
   allocation, where each server decides which hosts it will serve,
   using whatever level of authentication is appropriate for the
   particular service.  For example, time servers usually don't care who
   they serve (i.e., administrative control via the BOOTP database is

BOOTPアプローチの別の見かけの利点は管理者が、それからどのホストがどのサーバを使用するかを容易に制御できるということです。 マルチキャストアプローチは資源配分の上の、より多くの分散制御を支持して、特定のサービスに、各サーバが、どこで認証のどういったレベルを使用して、それがどのホストに役立つかを決めるかは、適切です。 例えば、通常、時間サーバが、それらがだれに役立つかを気にかけない、(すなわち、BOOTPデータベースを通した運営管理コントロールはそうです。

Reynolds                                                        [Page 6]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[6ページ]RFC1395BOOTP拡大1993年1月

   unnecessary), whereas file servers usually require strong
   authentication (i.e., administrative control via the BOOTP database
   is insufficient).

不要である、)、ファイルサーバーは通常強い認証を必要としますが(すなわち、BOOTPデータベースを通した運営管理コントロールは不十分です)。

   The main drawback of the multicast approach, of course, is that IP
   multicasting is not widely implemented, and there is a need to locate
   existing services which do not understand IP multicasts.

マルチキャストアプローチの主な欠点はもちろんIPマルチキャスティングが広く実装されないで、IPマルチキャストを理解していない既存のサービスの場所を見つける必要があるということです。

   The BOOTP approach may be most efficient in the case that all the
   information needed by the client host is returned by a single BOOTP
   reply and each program module simply reads the information it needs
   from a local table filled in by the BOOTP reply.

ただ一つのBOOTP回答でクライアントホストによって必要とされたすべての情報を返して、各プログラムモジュールが単にそれがBOOTP回答で記入された地方のテーブルから必要とする情報を読んで、BOOTPアプローチは最も効率的であるかもしれません。

Acknowledgments

承認

   The following people provided helpful comments on the first edition
   of this memo: Drew Perkins, of Carnagie Mellon University, Bill
   Croft, of Stanford University, and co-author of BOOTP, and Steve
   Deering, also of Stanford University, for contributing the
   "Comparison to Alternative Approaches" section.

以下の人々はこのメモの初版で役に立つコメントを提供しました: Carnagieメロン大学、スタンフォード大学、およびBOOTPの共著者のビルCroft、およびスティーブ・デアリング、「代替的アプローチとの比較」セクションを寄付するためのスタンフォード大学についてもドリュー・パーキンス。

References

参照

   [RFC-951]   Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)",
               Stanford and SUN Microsystems, September 1985.

[RFC-951] 耕地、B.とJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とスタンフォードと太陽マイクロシステムズ、1985年9月。

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

[RFC-903]フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」RFC903、スタンフォード、1984年6月。

   [RFC-887]   Accetta, M., "Resource Location Protocol", RFC 887, CMU,
               December 1983.

[RFC-887] Accetta、M.、「リソース位置のプロトコル」、RFC887、米カーネギーメロン大学、1983年12月。

   [RFC-1034]  Mockapetris, P., "Domain Names - Concepts and
               Facilities", STD 13, RFC 1034, USC/Information Sciences
               Institute, November 1987.

[RFC-1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日

   [RFC-950]   Mogul, J., and J. Postel, "Internet Standard Subnetting
               Procedure", STD 5, RFC 950, USC/Information Sciences
               Institute, August 1985.

[RFC-950] ムガール人、J.とJ.ポステル、「インターネットの標準のサブネッティング手順」、STD5、RFC950、科学が1985年8月に設けるUSC/情報。

   [RFC-868]   Postel, J., "Time Protocol", STD 26, RFC 868,
               USC/Information Sciences Institute, May 1983.

[RFC-868]ポステル(J.、「時間プロトコル」、STD26、RFC868、科学が設けるUSC/情報)は1983がそうするかもしれません。

   [IEN-116]   Postel, J., "Internet Name Server", USC/Information
               Sciences Institute, August 1979.

[IEN-116] ポステル、J.、「インターネットネームサーバ」とUSC/情報科学は、1979年8月に設けます。

Reynolds                                                        [Page 7]

RFC 1395                    BOOTP Extensions                January 1993

レイノルズ[7ページ]RFC1395BOOTP拡大1993年1月

   [LOGGING]   Clark, D., "Logging and Status Protocol", Massachusetts
               Institute of Technology Laboratory for Computer Science,
               Cambridge, Massachusetts, 1981.

[登録します] クラーク、D.、「伐採と状態は議定書を作る」マサチューセッツ工科大学コンピュータ科学研究所、ケンブリッジ(マサチューセッツ)1981。

   [RFC-865]   Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
               USC/Information Sciences Institute, May 1983.

[RFC-865]ポステル(J.、「今日の名言プロトコル」、STD23、RFC865、科学が設けるUSC/情報)は1983がそうするかもしれません。

   [LPD]       Campbell, R., "4.2BSD Line Printer Spooler Manual", UNIX
               Programmer's Manual, Vol II,  University of California at
               Berkeley, Computer Science Division, July 1983.

[LPD]キャンベル、R.、「4.2BSDはプリンタスプーラマニュアルを裏打ちします」、UNIXプログラマのマニュアル、Vol II、カリフォルニア大学バークレイ校、コンピュータ学術課、1983年7月。

   [IMAGEN]    "Image Server XT Programmer's Guide", Imagen Corporation,
               Santa Clara, California, August 1986.

[IMAGEN]「イメージサーバXTプログラマーズガイド」、Imagen社、サンタクララ(カリフォルニア)1986年8月。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address:

作者のアドレス:

   Joyce K. Reynolds
   Information Sciences Institute
   University of Southern California
   4676 Admiralty Way
   Marina del Rey, CA 90292

ジョイスK.レイノルズ情報Sciences Institute南カリフォルニア大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292

   Phone:  (310) 822-1511

以下に電話をしてください。 (310) 822-1511

   EMail: jkrey@isi.edu

メール: jkrey@isi.edu

Reynolds                                                        [Page 8]

レイノルズ[8ページ]