RFC951 日本語訳
0951 Bootstrap Protocol. W.J. Croft, J. Gilmore. September 1985. (Format: TXT=28354 bytes) (Updated by RFC1395, RFC1497, RFC1532, RFC1542) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Bill Croft (Stanford University)
Request for Comments: 951 John Gilmore (Sun Microsystems)
September 1985
コメントを求めるワーキンググループビルCroft(スタンフォード大学)要求をネットワークでつないでください: 951 ジョン・ギルモア(サン・マイクロシステムズ)1985年9月
BOOTSTRAP PROTOCOL (BOOTP)
プロトコルを独力で進んでください。(BOOTP)
1. Status of this Memo
1. このMemoの状態
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
2. Overview
2. 概要
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled 'address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol [9], since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP [3] or FTP [6].
このRFCはディスクレスクライアントマシンが、それ自身のIPアドレス、サーバー・ホストのアドレス、およびファイルの名前がメモリにロードされると発見できるプロトコル(BOOTP)を独力で進んで、実行されたIP/UDPについて説明します。 操作を独力で進んでください。TWO PHASESから成ると考えることができます。 このRFCは第1段階について説明します。(それは、'アドレス決断とbootfile選択'とラベルされるかもしれません)。 このアドレスとファイル名情報を得た後にコントロールが2番目のフェーズに通る、ファイル転送が起こるところに独力で進んでください。 ファイル転送はTFTPプロトコル[9]を通常使用するでしょう、両方のフェーズがクライアントの上のPROMにあることを意図するので。 しかしながら、また、BOOTPはSFTP[3]かFTP[6]などの他のプロトコルで働くことができました。
We suggest that the client's PROM software provide a way to do a complete bootstrap without 'user' interaction. This is the type of boot that would occur during an unattended power-up. A mechanism should be provided for the user to manually supply the necessary address and filename information to bypass the BOOTP protocol and enter the file transfer phase directly. If non-volatile storage is available, we suggest keeping default settings there and bypassing the BOOTP protocol unless these settings cause the file transfer phase to fail. If the cached information fails, the bootstrap should fall back to phase 1 and use BOOTP.
私たちは、クライアントのPROMソフトウェアが完全な状態でaをする方法を提供することを提案します。'ユーザ'相互作用なしで独力で進んでください。 これは無人のパワーアップすることの間に現れるブーツのタイプです。 ユーザがBOOTPプロトコルを迂回させて、直接ファイル転送フェーズに入れるために手動で必要なアドレスとファイル名情報を提供するように、メカニズムを提供するべきです。 非揮発性記憶装置が利用可能であるなら、私たちは、これらの設定がファイル転送フェーズに失敗されないなら、デフォルトがそこでの設定であることを保って、BOOTPプロトコルを迂回させることを提案します。 キャッシュされた情報が失敗するなら独力で進む、秋がフェーズ1と使用にBOOTPを支持するなら、独力で進んでください。
Here is a brief outline of the protocol:
ここに、プロトコルの簡潔なアウトラインがあります:
1. A single packet exchange is performed. Timeouts are used to
retransmit until a reply is received. The same packet field
layout is used in both directions. Fixed length fields of maximum
reasonable length are used to simplify structure definition and
parsing.
1. ただ一つのパケット交換は実行されます。 タイムアウトは、回答が受け取られているまで再送するのに使用されます。 同じパケット現場配置は両方の方向に使用されます。 最大の妥当な長さの固定長電界は、構造定義と構文解析を簡素化するのに使用されます。
2. An 'opcode' field exists with two values. The client
broadcasts a 'bootrequest' packet. The server then answers with a
'bootreply' packet. The bootrequest contains the client's
hardware address and its IP address, if known.
2. 'opcode'分野は2つの値で存在しています。 クライアントは'最もbootrequestな'パケットを放送します。 そして、サーバに'bootreply'パケットで答えます。 知られているなら、最もbootrequestであるのはクライアントのハードウェア・アドレスとそのIPアドレスを含んでいます。
Croft & Gilmore [Page 1]
耕地とギルモア[1ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
3. The request can optionally contain the name of the server the
client wishes to respond. This is so the client can force the
boot to occur from a specific host (e.g. if multiple versions of
the same bootfile exist or if the server is in a far distant
net/domain). The client does not have to deal with name / domain
services; instead this function is pushed off to the BOOTP server.
3. 要求は任意にクライアントが反応させたがっているサーバの名前を含むことができます。 これは、クライアントが特定のホストからブーツを強制的に現れさせることができる(例えば、同じbootfileの複数のバージョンが存在しているか、またはサーバがはるかに遠方のネット/ドメインにあるなら)ためにはそうです。 クライアントは名前/ドメインサービスに対処する必要はありません。 代わりに、この機能はBOOTPサーバに押し出されます。
4. The request can optionally contain the 'generic' filename to be
booted. For example 'unix' or 'ethertip'. When the server sends
the bootreply, it replaces this field with the fully qualified
path name of the appropriate boot file. In determining this name,
the server may consult his own database correlating the client's
address and filename request, with a particular boot file
customized for that client. If the bootrequest filename is a null
string, then the server returns a filename field indicating the
'default' file to be loaded for that client.
4. 要求は任意にブートされるべき'ジェネリック'ファイル名を含むことができます。 例えば、'unix'か'ethertip'。 サーバがbootreplyを送るとき、それはこの分野を適切なブート・ファイルの完全に適切なパス名に取り替えます。 この名前を決定する際に、サーバはクライアントのアドレスとファイル名が要求する彼自身のデータベース関連に相談するかもしれません、特定のブート・ファイルがそのクライアントのためにカスタム設計されている状態で。 最もbootrequestなファイル名がヌルストリングであるなら、サーバはそのクライアントのためにロードされるために'デフォルト'ファイルを示すファイル名野原を返します。
5. In the case of clients who do not know their IP addresses, the
server must also have a database relating hardware address to IP
address. This client IP address is then placed into a field in
the bootreply.
5. また、彼らのIPアドレスを知らないクライアントの場合では、サーバはIPアドレスにハードウェア・アドレスに関連するデータベースを持たなければなりません。 そして、このクライアントIPアドレスはbootreplyの分野に置かれます。
6. Certain network topologies (such as Stanford's) may be such
that a given physical cable does not have a TFTP server directly
attached to it (e.g. all the gateways and hosts on a certain cable
may be diskless). With the cooperation of neighboring gateways,
BOOTP can allow clients to boot off of servers several hops away,
through these gateways. See the section 'Booting Through
Gateways' below. This part of the protocol requires no special
action on the part of the client. Implementation is optional and
requires a small amount of additional code in gateways and
servers.
6. あるネットワークtopologies(スタンフォードなどの)がそのようなものであるかもしれないので、与えられた物理ケーブルは直接TFTPサーバをそれに取り付けません(例えば、あるケーブルの上のすべてのゲートウェイとホストがディスクレスであるかもしれません)。 隣接しているゲートウェイの協力で、BOOTPはクライアントにサーバからいくつかのホップを遠くにブートさせることができます、これらのゲートウェイを通して。 以下の'穂ばらみThrough Gateways'というセクションを見てください。 プロトコルのこの部分はクライアント側のどんな特別な動きも必要としません。 実装は、任意であり、ゲートウェイとサーバの少量の追加コードを必要とします。
3. Packet Format
3. パケット・フォーマット
All numbers shown are decimal, unless indicated otherwise. The BOOTP packet is enclosed in a standard IP [8] UDP [7] datagram. For simplicity it is assumed that the BOOTP packet is never fragmented. Any numeric fields shown are packed in 'standard network byte order', i.e. high order bits are sent first.
別の方法で示されない場合、示されたすべての数が10進です。 BOOTPパケットは標準のIP[8]UDP[7]データグラムに同封されます。 簡単さにおいて、BOOTPパケットが決して断片化されないと思われます。 '標準のネットワークバイトオーダー'で示されたどんな数字フィールドも梱包します、すなわち、最初に、高位のビットを送ります。
In the IP header of a bootrequest, the client fills in its own IP source address if known, otherwise zero. When the server address is unknown, the IP destination address will be the 'broadcast address' 255.255.255.255. This address means 'broadcast on the local cable, (I don't know my net number)' [4].
aのIPヘッダーでは、最もbootrequestに、クライアントは知られているならそれ自身のIPソースが扱うコネ、そうでなければゼロをいっぱいにします。 サーバアドレスが未知であるときに、受信者IPアドレスは'放送演説'255.255.255が.255であったなら未知になるでしょう。 このアドレスは、''地方のケーブル、(私はネットの番号を知りません)[4]で放送するように意味します。
Croft & Gilmore [Page 2]
耕地とギルモア[2ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
The UDP header contains source and destination port numbers. The BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) and 'BOOTP server' (67). The client sends requests using 'BOOTP server' as the destination port; this is usually a broadcast. The server sends replies using 'BOOTP client' as the destination port; depending on the kernel or driver facilities in the server, this may or may not be a broadcast (this is explained further in the section titled 'Chicken/Egg issues' below). The reason TWO reserved ports are used, is to avoid 'waking up' and scheduling the BOOTP server daemons, when a bootreply must be broadcast to a client. Since the server and other hosts won't be listening on the 'BOOTP client' port, any such incoming broadcasts will be filtered out at the kernel level. We could not simply allow the client to pick a 'random' port number for the UDP source port field; since the server reply may be broadcast, a randomly chosen port number could confuse other hosts that happened to be listening on that port.
UDPヘッダーはソースと目的地ポートナンバーを含んでいます。 BOOTPプロトコル用途twoはポートナンバー、'BOOTPクライアント'(68)、および'BOOTPサーバ'(67)を予約しました。 クライアントは仕向港として'BOOTPサーバ'を使用することで要求を送ります。 通常、これは放送です。 サーバは仕向港として'BOOTPクライアント'を使用することで回答を送ります。 サーバでカーネルかドライバー施設によって、これは放送であるかもしれません(これは以下で'鶏肉/卵の問題'と題をつけられたセクションで、より詳しく説明されます)。 理由TWO予約されたポートは使用されています、'目覚めること'を避けるためにあって、BOOTPサーバデーモンの計画をして、bootreplyをクライアントに放送しなければならないとき。 サーバと他のホストが'BOOTPクライアント'ポートの上で聴かないので、そのようなどんな入って来る放送もカーネルレベルで無視されるでしょう。 私たちはクライアントに'無作為'のポートナンバーをUDPソースポート分野に絶対に選ばせることができませんでした。 サーバ回答が放送されるかもしれないので、手当たりしだいに選ばれたポートナンバーはそのポートの上でたまたま聴いていた他のホストを混乱させるかもしれません。
The UDP length field is set to the length of the UDP plus BOOTP portions of the packet. The UDP checksum field can be set to zero by the client (or server) if desired, to avoid this extra overhead in a PROM implementation. In the 'Packet Processing' section below the phrase '[UDP checksum.]' is used whenever the checksum might be verified/computed.
UDP長さの分野はUDPの長さとパケットのBOOTP部分に設定されます。 PROM実装でこの付加的なオーバーヘッドを避けることが望まれているなら、クライアント(または、サーバ)はUDPチェックサム分野をゼロに設定できます。 句の下の'パケットProcessing'セクションでは、チェックサムが確かめられるか、または計算されるかもしれないときはいつも、'[UDPチェックサム]。'は使用されています。
FIELD BYTES DESCRIPTION
----- ----- -----------
分野バイト記述----- ----- -----------
op 1 packet op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
オプアートの1つのパケットのオペコード/メッセージタイプ。 1 = BOOTREQUEST、2はBOOTREPLYと等しいです。
htype 1 hardware address type,
see ARP section in "Assigned Numbers" RFC.
'1' = 10mb ethernet
htypeの1つのハードウェア・アドレスのタイプは「規定番号」RFCのARP部を見てください。 '1'=の10mbのイーサネット
hlen 1 hardware address length
(eg '6' for 10mb ethernet).
hlenの1つのハードウェア・アドレスの長さ(10mbのイーサネットのためのeg'6')。
hops 1 client sets to zero,
optionally used by gateways
in cross-gateway booting.
1人のクライアントがゲートウェイによって交差しているゲートウェイ穂ばらみに任意に使用されるゼロに設定するホップ。
xid 4 transaction ID, a random number,
used to match this boot request with the
responses it generates.
xid4トランザクションID(乱数)は以前はよくそれが生成する応答にこのブーツ要求に合っていました。
secs 2 filled in by client, seconds elapsed since
client started trying to boot.
その上試みられ始めたクライアント以来2がクライアント、秒までに記入したsecsは経過しました。
Croft & Gilmore [Page 3]
耕地とギルモア[3ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
-- 2 unused
-- 2、未使用
ciaddr 4 client IP address;
filled in by client in bootrequest if known.
ciaddr4クライアントIPアドレス。 知られているなら、最もbootrequestであるのはクライアントによって記入されます。
yiaddr 4 'your' (client) IP address;
filled by server if client doesn't
know its own address (ciaddr was 0).
'your'の(クライアント)IPが扱うyiaddr4。 サーバで、クライアントがそれ自身のアドレスを知らないなら(ciaddrは0でした)、いっぱいにされます。
siaddr 4 server IP address;
returned in bootreply by server.
siaddr4サーバIPアドレス。 bootreplyでは、サーバで、戻りました。
giaddr 4 gateway IP address,
used in optional cross-gateway booting.
任意の交差しているゲートウェイ穂ばらみに使用されるgiaddr4ゲートウェイIPアドレス。
chaddr 16 client hardware address,
filled in by client.
クライアントによって記入されたchaddr16クライアントハードウェア・アドレス。
sname 64 optional server host name,
null terminated string.
snameの64の任意のサーバー・ホスト名、ヌル終えられたストリング。
file 128 boot file name, null terminated string;
'generic' name or null in bootrequest,
fully qualified directory-path
name in bootreply.
128ブート・ファイル名、ヌル終えられたストリングをファイルしてください。 'ジェネリック'名かbootreplyの最もbootrequestと、完全に適切なディレクトリパス名のヌル。
vend 64 optional vendor-specific area,
e.g. could be hardware type/serial on request,
or 'capability' / remote file system handle
on reply. This info may be set aside for use
by a third phase bootstrap or kernel.
ハードウェアが回答での要求に応じてタイプ/連続の、または、'能力'/リモートなファイルシステムハンドルであったかもしれないなら例えば64の任意のベンダー特有の領域を販売してください。 このインフォメーションは使用のためにフェーズが独力で進む3分の1かカーネルによってかたわらに置かれるかもしれません。
4. Chicken / Egg Issues
4. 鶏肉/卵の問題
How can the server send an IP datagram to the client, if the client doesnt know its own IP address (yet)? Whenever a bootreply is being sent, the transmitting machine performs the following operations:
クライアントdoesntが(まだ)それ自身のIPアドレスを知っているなら、サーバはどうしたらIPデータグラムをクライアントに送ることができますか? bootreplyを送るときはいつも、伝えるマシンは以下の操作を実行します:
1. If the client knows its own IP address ('ciaddr' field is
nonzero), then the IP can be sent 'as normal', since the client
will respond to ARPs [5].
1. クライアントがそれ自身のIPアドレスを知っているなら('ciaddr'分野は非零です)、'標準'としてIPを送ることができます、クライアントがARPs[5]に応じるので。
2. If the client does not yet know its IP address (ciaddr zero),
then the client cannot respond to ARPs sent by the transmitter of
the bootreply. There are two options:
2. クライアントがまだ、IPアドレス(ciaddrゼロ)を知っていないなら、クライアントはbootreplyの送信機によって送られたARPsに応じることができません。 2つのオプションがあります:
a. If the transmitter has the necessary kernel or driver hooks
a。 送信機に必要なカーネルかドライバーフックがあるなら
Croft & Gilmore [Page 4]
耕地とギルモア[4ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
to 'manually' construct an ARP address cache entry, then it can
fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
course, this entry should have a timeout on it, just like any
other entry made by the normal ARP code itself. The
transmitter of the bootreply can then simply send the bootreply
to the client's IP address. UNIX (4.2 BSD) has this
capability.
そして、'手動'ARPアドレスキャッシュエントリーを組み立てるために、'chaddr'と'yiaddr'分野を使用することでそれはエントリーに記入できます。 もちろん、このエントリーはそれにタイムアウトを持つべきです、まさしく正常なARPコード自体によってされたいかなる他のエントリーのようにも。 そして、bootreplyの送信機は単にクライアントのIPアドレスにbootreplyを送ることができます。 UNIX(4.2BSD)には、この能力があります。
b. If the transmitter lacks these kernel hooks, it can simply
send the bootreply to the IP broadcast address on the
appropriate interface. This is only one additional broadcast
over the previous case.
b。 送信機がこれらのカーネルフックを欠いているなら、それは単に適切なインタフェースに関するIP放送演説にbootreplyを送ることができます。 これは先の事件の上の1つの追加放送にすぎません。
5. Client Use of ARP
5. ARPのクライアント使用
The client PROM must contain a simple implementation of ARP, e.g. the address cache could be just one entry in size. This will allow a second-phase-only boot (TFTP) to be performed when the client knows the IP addresses and bootfile name.
クライアントPROMはARPの簡単な実装を含まなければなりません、例えば、アドレスキャッシュがサイズがちょうど1つのエントリーであるかもしれません。 クライアントがIPアドレスとbootfile名を知っているとき、これで、2番目のフェーズだけブーツ(TFTP)は働くでしょう。
Any time the client is expecting to receive a TFTP or BOOTP reply, it should be prepared to answer an ARP request for its own IP to hardware address mapping (if known).
いつでも、クライアントは、TFTPかBOOTP回答を受け取ると予想していて、それ自身のIPを求めるARP要求にハードウェアアドレス・マッピングに答えるのは準備されているべきです(知られているなら)。
Since the bootreply will contain (in the hardware encapsulation) the hardware source address of the server/gateway, the client MAY be able to avoid sending an ARP request for the server/gateway IP address to be used in the following TFTP phase. However this should be treated only as a special case, since it is desirable to still allow a second-phase-only boot as described above.
bootreplyがサーバ/ゲートウェイのハードウェアソースアドレスを含むので(ハードウェアカプセル化で)、クライアントは、サーバ/ゲートウェイIPアドレスが以下のTFTPフェーズに使用されるというARP要求を送るのを避けることができるかもしれません。 しかしながら、これは特殊なものとしてだけ扱われるべきです、まだ2番目のフェーズだけブーツを許容しているのが上で説明されるように望ましいので。
6. Comparison to RARP
6. RARPとの比較
An earlier protocol, Reverse Address Resolution Protocol (RARP) [1] was proposed to allow a client to determine its IP address, given that it knew its hardware address. However RARP had the disadvantage that it was a hardware link level protocol (not IP/UDP based). This means that RARP could only be implemented on hosts containing special kernel or driver modifications to access these 'raw' packets. Since there are many network kernels existent now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications is a decided advantage.
以前のプロトコル、逆アドレス解決プロトコル(RARP)[1]はクライアントがIPアドレスを決定するのを許容するために提案されました、ハードウェア・アドレスを知っていたなら。 RARPにそれが不都合であったのがどのようにあったとしても、ハードウェアリンク・レベルは(基づかないどんなIP/UDPも)について議定書の中で述べます。 これは、これらの'生'のパケットにアクセスするために特別なカーネルかドライバー変更を含んでいて、ホストの上でRARPを実装することができただけであることを意味します。 現在各ソースが異なった組織によって維持されている状態で目下の多くのネットワークカーネルがあるので、カーネル変更を必要としないブーツプロトコルは明らかな利点です。
BOOTP provides this hardware to IP address lookup function, in addition to the other useful features described in the sections above.
BOOTPはIPアドレスルックアップ機能にこのハードウェアを提供します、上のセクションで説明された他の役に立つ特徴に加えて。
Croft & Gilmore [Page 5]
耕地とギルモア[5ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
7. Packet Processing
7. パケット処理
7.1. Client Transmission
7.1. クライアントトランスミッション
Before setting up the packet for the first time, it is a good idea
to clear the entire packet buffer to all zeros; this will place
all fields in their default state. The client then creates a
packet with the following fields.
初めてパケットをセットアップする前に、全体のパケットバッファをすべてのゼロまできれいにするのは、名案です。 これはそれらのデフォルト状態にすべての野原を置くでしょう。 そして、クライアントは以下の分野でパケットを作成します。
The IP destination address is set to 255.255.255.255. (the
broadcast address) or to the server's IP address (if known). The
IP source address and 'ciaddr' are set to the client's IP address
if known, else 0. The UDP header is set with the proper length;
source port = 'BOOTP client' port destination port = 'BOOTP
server' port.
受信者IPアドレスは.255に255.255に.255を設定することです。 (放送演説) または、サーバのIPアドレス(知られているなら)に。 IPソースアドレスと'ciaddr'は知られていてほかの0であるならクライアントのIPアドレスに設定されます。 UDPヘッダーは適切な長さで用意ができています。 ソースポート='BOOTPクライアント'ポート仕向港は'BOOTPサーバ'ポートと等しいです。
'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware
address type as assigned in the ARP section of the "Assigned
Numbers" RFC. 'hlen' is set to the length of the hardware address,
e.g. '6' for 10mb ethernet.
'オプアート'は'1'に設定されます、BOOTREQUEST。'htype'は「規定番号」RFCのARP部で割り当てられるようにハードウェア・アドレスタイプに設定されます。 'hlen'はハードウェア・アドレスの長さ、例えば、10mbのイーサネットのための'6'に設定されます。
'xid' is set to a 'random' transaction id. 'secs' is set to the
number of seconds that have elapsed since the client has started
booting. This will let the servers know how long a client has
been trying. As the number gets larger, certain servers may feel
more 'sympathetic' towards a client they don't normally service.
If a client lacks a suitable clock, it could construct a rough
estimate using a loop timer. Or it could choose to simply send
this field as always a fixed value, say 100 seconds.
'xid'は'無作為'のトランザクションイドに設定されます。 'secs'はクライアントがブートし始めて以来経過している秒数に設定されます。 これは、どれくらい長いクライアントが試みているかをサーバに知らせるでしょう。 数が得られるとき、より大きくて、あるサーバは通常、それらがサービスを提供しないクライアントに向かって、より'同情的である'と感じられるかもしれません。 クライアントが適当な時計を欠いているなら、それは、輪のタイマを使用することで概算を構成するかもしれません。 または、それは、いつも一定の価値として単にこの野原を送るのを選んで、100秒言うことができました。
If the client knows its IP address, 'ciaddr' (and the IP source
address) are set to this value. 'chaddr' is filled in with the
client's hardware address.
クライアントが知っているなら、IPアドレス、'ciaddr'(そして、IPソースアドレス)はこの値に設定されます。 'chaddr'はクライアントのハードウェア・アドレスで記入されます。
If the client wishes to restrict booting to a particular server
name, it may place a null-terminated string in 'sname'. The name
used should be any of the allowable names or nicknames of the
desired host.
クライアントが穂ばらみを特定のサーバー名に制限したいなら、それはヌルで終えられたストリングを'sname'に置くかもしれません。 使用という名前は、許容できる名前のいずれか必要なホストのあだ名であるべきです。
The client has several options for filling the 'file' name field.
If left null, the meaning is 'I want to boot the default file for
my machine'. A null file name can also mean 'I am only interested
in finding out client/server/gateway IP addresses, I dont care
about file names'.
クライアントには、'ファイル'名前欄をいっぱいにするためのいくつかのオプションがあります。 ヌルで残されるなら、意味は'私のマシンのためのデフォルトファイルをブートしたいと思います'です。 また、ヌルファイル名は、'クライアント/サーバ/ゲートウェイIPアドレスを見つけるだけでありたいと思い、私はファイル名に関するdont注意です'と意味できます。
The field can also be a 'generic' name such as 'unix' or
またはまた、分野が'unix'などの'ジェネリック'名であるかもしれない。
Croft & Gilmore [Page 6]
耕地とギルモア[6ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
'gateway'; this means 'boot the named program configured for my
machine'. Finally the field can be a fully directory qualified
path name.
'ゲートウェイ'。 これは、'私のマシンのために構成された命名されたプログラムをブートします'と意味します。 最終的に分野はディレクトリ完全に適切なパス名であるかもしれません。
The 'vend' field can be filled in by the client with
vendor-specific strings or structures. For example the machine
hardware type or serial number may be placed here. However the
operation of the BOOTP server should not DEPEND on this
information existing.
クライアントはベンダー特有のひもか構造で'販売'分野に記入できます。 例えばマシンハードウェアタイプか通し番号がここに置かれるかもしれません。 しかしながら、この情報のDEPENDが存在していて、BOOTPサーバの操作はそうするべきではありません。
If the 'vend' field is used, it is recommended that a 4 byte
'magic number' be the first item within 'vend'. This lets a
server determine what kind of information it is seeing in this
field. Numbers can be assigned by the usual 'magic number'
process --you pick one and it's magic. A different magic number
could be used for bootreply's than bootrequest's to allow the
client to take special action with the reply information.
'販売'分野が使用されているなら、4バイト'マジックナンバー'が'販売'の中の最初の項目であることはお勧めです。 これで、サーバは、それがこの分野にどういう情報が見えているかを決定します。 普通の'マジックナンバー'プロセスは数を割り当てることができます--あなたは1つを選びます、そして、それは魔法です。 bootreplyのものに最もbootrequestであるのと異なったマジックナンバーを使用できました。クライアントが回答情報がある特別な動きで取るのを許容することになっています。
[UDP checksum.]
[UDPチェックサム。]
7.2. Client Retransmission Strategy
7.2. クライアントRetransmission戦略
If no reply is received for a certain length of time, the client
should retransmit the request. The time interval must be chosen
carefully so as not to flood the network. Consider the case of a
cable containing 100 machines that are just coming up after a
power failure. Simply retransmitting the request every four
seconds will inundate the net.
ある長さの時間に回答を全く受け取らないなら、クライアントは要求を再送するべきです。 ネットワークをあふれさせないように慎重に時間間隔を選ばなければなりません。 停電の後にただ来る予定である100台のマシンを含むケーブルのケースを考えてください。 4秒毎に単に要求を再送すると、ネットは水浸しにされるでしょう。
As a possible strategy, you might consider backing off
exponentially, similar to the way ethernet backs off on a
collision. So for example if the first packet is at time 0:00,
the second would be at :04, then :08, then :16, then :32, then
:64. You should also randomize each time; this would be done
similar to the ethernet specification by starting with a mask and
'and'ing that with with a random number to get the first backoff.
On each succeeding backoff, the mask is increased in length by one
bit. This doubles the average delay on each backoff.
可能な戦略として、あなたは、指数関数的に引き返すと考えるかもしれません。イーサネットが衝突に引き返す方法と同様です。 それで、例えば、最初のパケットが0:00、秒がそうする時にあるなら、:04、次に、:08、次に、:16、:32、当時の当時の:64にいてください。 また、あなたは各回をランダマイズするべきです。 これがそうであるだろう、マスクと'and'ingからそれを始めるイーサネット仕様と同様の状態で、最初のbackoffを手に入れる乱数でします。 続く各backoffでは、マスクは1ビットによって長さで増強されます。 これは各backoffで平均した遅れを倍にします。
After the 'average' backoff reaches about 60 seconds, it should be
increased no further, but still randomized.
'平均した'backoffがおよそ60秒達した後に、それは、これ以上増強されませんが、まだランダマイズされているべきです。
Before each retransmission, the client should update the 'secs'
field. [UDP checksum.]
各「再-トランスミッション」の前では、クライアントは'secs'分野をアップデートするべきです。 [UDPチェックサム。]
Croft & Gilmore [Page 7]
耕地とギルモア[7ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
7.3. Server Receives BOOTREQUEST
7.3. サーバはBOOTREQUESTを受けます。
[UDP checksum.] If the UDP destination port does not match the
'BOOTP server' port, discard the packet.
[UDPチェックサム。] UDP仕向港が'BOOTPサーバ'ポートに合っていないなら、パケットを捨ててください。
If the server name field (sname) is null (no particular server
specified), or sname is specified and matches our name or
nickname, then continue with packet processing.
サーバ名前欄(sname)がヌルであるか(どんな特定のサーバも指定しませんでした)、snameが指定されて、私たちの名前かあだ名に合っているなら、パケット処理を続行してください。
If the sname field is specified, but does not match 'us', then
there are several options:
sname分野が指定されますが、'私たち'に合っていないなら、いくつかのオプションがあります:
1. You may choose to simply discard this packet.
1. あなたは、単にこのパケットを捨てるのを選ぶことができます。
2. If a name lookup on sname shows it to be on this same cable,
discard the packet.
2. snameの上の名前ルックアップが、この同じケーブルの上にそれがあるのを示すなら、パケットを捨ててください。
3. If sname is on a different net, you may choose to forward
the packet to that address. If so, check the 'giaddr' (gateway
address) field. If 'giaddr' is zero, fill it in with my
address or the address of a gateway that can be used to get to
that net. Then forward the packet.
3. snameが異なったネットにあるなら、あなたは、そのアドレスにパケットを送るのを選ぶことができます。 そうだとすれば、'giaddr'(ゲートウェイアドレス)分野をチェックしてください。 'giaddr'がゼロであるなら、中で私のアドレスかそのネットを始めるのに使用できるゲートウェイのアドレスでそれを満たしてください。 そして、パケットを進めてください。
If the client IP address (ciaddr) is zero, then the client does
not know its own IP address. Attempt to lookup the client
hardware address (chaddr, hlen, htype) in our database. If no
match is found, discard the packet. Otherwise we now have an IP
address for this client; fill it into the 'yiaddr' (your IP
address) field.
クライアントIPアドレス(ciaddr)がゼロであるなら、クライアントはそれ自身のIPアドレスを知りません。 私たちのデータベースのクライアントハードウェア・アドレス(chaddr、hlen、htype)をルックアップに試みてください。 マッチが全く見つけられないなら、パケットを捨ててください。 さもなければ、私たちには、現在、このクライアントのためのIPアドレスがあります。 'yiaddr'(あなたのIPアドレス)分野にそれをいっぱいにしてください。
We now check the boot file name field (file). The field will be
null if the client is not interested in filenames, or wants the
default bootfile. If the field is non-null, it is used as a
lookup key in a database, along with the client's IP address. If
there is a default file or generic file (possibly indexed by the
client address) or a fully-specified path name that matches, then
replace the 'file' field with the fully-specified path name of the
selected boot file. If the field is non-null and no match was
found, then the client is asking for a file we dont have; discard
the packet, perhaps some other BOOTP server will have it.
私たちは現在、ブート・ファイル名前欄(ファイル)をチェックします。 クライアントがファイル名に関心がないか、またはデフォルトbootfileが欲しいなら、分野はヌルになるでしょう。 分野が非ヌルであるなら、それはデータベースで主要なルックアップとして使用されます、クライアントのIPアドレスと共に。 デフォルトファイル、ジェネリックファイル(ことによるとクライアントアドレスによって索引をつけられる)または合っている完全に指定されたパス名があれば、'ファイル'分野を選択されたブート・ファイルの完全に指定されたパス名に取り替えてください。 分野が非ヌルであり、マッチが全く見つけられなかったなら、クライアントは私たちがdontに持っているファイルを求めています。 パケットを捨ててください、そして、恐らく、ある他のBOOTPサーバはそれを持つでしょう。
The 'vend' vendor-specific data field should now be checked and if
a recognized type of data is provided, client-specific actions
should be taken, and a response placed in the 'vend' data field of
the reply packet. For example, a workstation client could provide
認識されたタイプに関するデータを提供するなら、クライアント特有の動作は、'販売'のベンダー特有のデータ・フィールドが現在、チェックされるべきであり、取って回答パケットの'販売'データ・フィールドに置かれた応答であるべきです。 例えば、ワークステーションクライアントは提供できました。
Croft & Gilmore [Page 8]
耕地とギルモア[8ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
an authentication key and receive from the server a capability for
remote file access, or a set of configuration options, which can
be passed to the operating system that will shortly be booted in.
認証は、まもなく中で起動させられたオペレーティングシステムに合格できるリモートファイルアクセス、または1セットの設定オプションのためにサーバから能力を合わせて、受けます。
Place my (server) IP address in the 'siaddr' field. Set the 'op'
field to BOOTREPLY. The UDP destination port is set to 'BOOTP
client'. If the client address 'ciaddr' is nonzero, send the
packet there; else if the gateway address 'giaddr' is nonzero, set
the UDP destination port to 'BOOTP server' and send the packet to
'giaddr'; else the client is on one of our cables but it doesnt
know its own IP address yet --use a method described in the 'Egg'
section above to send it to the client. If 'Egg' is used and we
have multiple interfaces on this host, use the 'yiaddr' (your IP
address) field to figure out which net (cable/interface) to send
the packet to. [UDP checksum.]
私の(サーバ)IPアドレスを'siaddr'分野に置いてください。 'オプアート'分野をBOOTREPLYに設定してください。 UDP仕向港は'BOOTPクライアント'に設定されます。 クライアントアドレス'ciaddr'が非零であるなら、パケットをそこに送ってください。 ほかに、ゲートウェイアドレス'giaddr'が非零であるなら、'BOOTPサーバ'にUDP仕向港を設定してください、そして、'giaddr'にパケットを送ってください。 doesntに、まだそれ自身のIPアドレスを知っています--ほかに、クライアントは私たちのケーブルの1つにいますが、それをクライアントに送るためには上の'卵'セクションで説明されたメソッドを使用してください。 '卵'が使用されていて、私たちがこのホストの上に複数のインタフェースを持っているなら、'yiaddr'(あなたのIPアドレス)分野を使用して、どのネット(ケーブル/インタフェース)にパケットを送るか理解してください。 [UDPチェックサム。]
7.4. Server/Gateway Receives BOOTREPLY
7.4. サーバ/ゲートウェイはBOOTREPLYを受けます。
[UDP checksum.] If 'yiaddr' (your [the client's] IP address)
refers to one of our cables, use one of the 'Egg' methods above to
forward it to the client. Be sure to send it to the 'BOOTP
client' UDP destination port.
[UDPチェックサム。] 'yiaddr'(あなたの[クライアントのもの]IPアドレス)が私たちのケーブルの1つについて言及するなら、それをクライアントに送るためには上の'卵'メソッドの1つを使用してください。 'BOOTPクライアント'UDP仕向港にそれを必ず送ってください。
7.5. Client Reception
7.5. クライアントレセプション
Don't forget to process ARP requests for my own IP address (if I
know it). [UDP checksum.] The client should discard incoming
packets that: are not IP/UDPs addressed to the boot port; are not
BOOTREPLYs; do not match my IP address (if I know it) or my
hardware address; do not match my transaction id. Otherwise we
have received a successful reply. 'yiaddr' will contain my IP
address, if I didnt know it before. 'file' is the name of the
file name to TFTP 'read request'. The server address is in
'siaddr'. If 'giaddr' (gateway address) is nonzero, then the
packets should be forwarded there first, in order to get to the
server.
私自身のIPアドレスを求めるARP要求を処理するのを忘れないでください(私がそれを知っているなら)。 [UDPチェックサム。] クライアントが入って来るパケットを捨てるべきである、それ: ブーツポートに扱われなかったどんなIP/UDPsですも。 BOOTREPLYsではありません。 私のIPアドレス(私がそれを知っているなら)か私のハードウェア・アドレスを合わせないでください。 私のトランザクションイドを合わせないでください。 さもなければ、私たちはうまくいっている回答を受け取りました。 'yiaddr'は私のIPアドレスを含んで、didntは私であるなら以前、それを知っています。 'ファイル'はTFTP'読み出し要求'へのファイル名の名前です。 サーバアドレスが'siaddr'にあります。 'giaddr'(ゲートウェイアドレス)が非零であるなら、最初にパケットをそこに送るべきです、サーバを始めるために。
8. Booting Through Gateways
8. ゲートウェイを通した穂ばらみ
This part of the protocol is optional and requires some additional code in cooperating gateways and servers, but it allows cross-gateway booting. This is mainly useful when gateways are diskless machines. Gateways containing disks (e.g. a UNIX machine acting as a gateway), might as well run their own BOOTP/TFTP servers.
プロトコルのこの部分は、任意であり、協力関係を持っているゲートウェイとサーバの何らかの追加コードを必要としますが、それは交差しているゲートウェイ穂ばらみを許容します。 ゲートウェイがディスクレスマシンであるときに、これは主に役に立ちます。 ゲートウェイは、ディスク(例えばゲートウェイとして作動するUnixマシン)を含んでいて、それら自身のBOOTP/TFTPサーバを実行するほうがよいです。
Gateways listening to broadcast BOOTREQUESTs may decide to forward or rebroadcast these requests 'when appropriate'. For example, the
BOOTREQUESTsを放送するために聴かれるゲートウェイは、'適切である'ときに、これらの要求を進めるか、または再放送すると決めるかもしれません。 例えば
Croft & Gilmore [Page 9]
耕地とギルモア[9ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
gateway could have, as part of his configuration tables, a list of other networks or hosts to receive a copy of any broadcast BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea to simply globally rebroadcast the requests, since broadcast loops will almost certainly occur.
ゲートウェイには、彼の構成テーブルの一部としてどんな放送BOOTREQUESTsのコピーも受け取る他のネットワークかホストのリストがあるかもしれません。 'ホップ'分野は存在していますが、単に要求をグローバルに再放送するのは、劣った考えです、放送輪がほぼ確実に現れるので。
The forwarding could begin immediately, or wait until the 'secs' (seconds client has been trying) field passes a certain threshold.
'secs'(秒クライアントは試みている)分野が、ある敷居を渡すまで、推進は、すぐに始まるか、または待つことができました。
If a gateway does decide to forward the request, it should look at the 'giaddr' (gateway IP address) field. If zero, it should plug its own IP address (on the receiving cable) into this field. It may also use the 'hops' field to optionally control how far the packet is reforwarded. Hops should be incremented on each forwarding. For example, if hops passes '3', the packet should probably be discarded. [UDP checksum.]
ゲートウェイが、要求を転送すると決めるなら、それは'giaddr'(ゲートウェイIPアドレス)分野を見るべきです。 ゼロであるなら、それはそれ自身のIPアドレス(受信ケーブルの)をこの分野に差し込むべきです。 また、それは、パケットがどれくらい遠くに「再-進め」られるかを任意に制御するのに'ホップ'分野を使用するかもしれません。 ホップスは各推進のときに増加されるべきです。 例えば、ホップであるなら、パス'3'、パケットはたぶん捨てられるべきです。 [UDPチェックサム。]
Here we have recommended placing this special forwarding function in the gateways. But that does not have to be the case. As long as some 'BOOTP forwarding agent' exists on the net with the booting client, the agent can do the forwarding when appropriate. Thus this service may or may not be co-located with the gateway.
ここで、私たちは、この特別な推進機能をゲートウェイに置くことを勧めました。 しかし、それはそうである必要はありません。 適切であるときに、いくつかの'BOOTP小口運送業者'が穂ばらみクライアントと共にネットに存在している限り、エージェントは推進できます。 したがって、このサービスはゲートウェイで共同見つけられるかもしれません。
In the case of a forwarding agent not located in the gateway, the agent could save himself some work by plugging the broadcast address of the interface receiving the bootrequest into the 'giaddr' field. Thus the reply would get forwarded using normal gateways, not involving the forwarding agent. Of course the disadvantage here is that you lose the ability to use the 'Egg' non-broadcast method of sending the reply, causing extra overhead for every host on the client cable.
ゲートウェイに位置しない小口運送業者の場合では、エージェントは、いくらかの仕事を最もbootrequestに'giaddr'分野を迎え入れるインタフェースの放送演説をふさぐことによって、自分に節約させることができるでしょう。 したがって、小口運送業者にかかわるのではなく、正常なゲートウェイを使用することで回答を進めるでしょう。 もちろん、ここの不都合はあなたが回答を送る'卵'非放送メソッドを使用する能力を失うということです、クライアントケーブルの上のすべてのホストのために付加的なオーバーヘッドを引き起こして。
9. Sample BOOTP Server Database
9. サンプルBOOTPサーバデータベース
As a suggestion, we show a sample text file database that the BOOTP server program might use. The database has two sections, delimited by a line containing an percent in column 1. The first section contains a 'default directory' and mappings from generic names to directory/pathnames. The first generic name in this section is the 'default file' you get when the bootrequest contains a null 'file' string.
提案として、私たちはBOOTPサーバプログラムが使用するかもしれないサンプルテキストファイルデータベースを示しています。 データベースには、コラム1にパーセントを含む系列によって区切られた2つのセクションがあります。 最初のセクションは総称からディレクトリ/パス名までの'デフォルトディレクトリ'とマッピングを含みます。 このセクションにおける最初の総称はあなたが得る中でものである最もbootrequestである'デフォルトファイル'がヌル'ファイル'ストリングを含んでいるということです。
The second section maps hardware addresstype/address into an ipaddress. Optionally you can also overide the default generic name by supplying a ipaddress specific genericname. A 'suffix' item is also an option; if supplied, any generic names specified by the client will be accessed by first appending 'suffix' to the 'pathname'
第2セクションはハードウェアaddresstype/アドレスをipaddressに写像します。 また、任意に、あなたは、ipaddressの特定のgenericnameを供給することによって、デフォルト総称をoverideすることができます。 また、'接尾語'項目はオプションです。 供給すると、最初には、'接尾語'を'パス名'に追加しながら、クライアントによって指定されたどんな総称にもアクセスするでしょう。
Croft & Gilmore [Page 10]
耕地とギルモア[10ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
appropriate to that generic name. If that file is not found, then the plain 'pathname' will be tried. This 'suffix' option allows a whole set of custom generics to be setup without a lot of effort. Below is shown the general format; fields are delimited by one or more spaces or tabs; trailing empty fields may be omitted; blank lines and lines beginning with '#' are ignored.
その総称に適切です。 そのファイルが見つけられないと、明瞭な'パス名'は試みられるでしょう。 この'接尾語'オプションは、1つの全体集合のカスタム同種同効医薬品が多くの努力がなければセットアップであることを許容します。 一般形式は下に案内されます。 分野は1つ以上の空間かタブによって区切られます。 引きずっている何もない草原は省略されるかもしれません。 '#'で始まる空白行と線は無視されます。
# comment line
# 注釈行
homedirectory
genericname1 pathname1
genericname2 pathname2
...
homedirectory genericname1 pathname1 genericname2 pathname2…
% end of generic names, start of address mappings
総称の%終わり、アドレス・マッピングの始まり
hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
...
hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname接尾語hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname接尾語…
Here is a specific example. Note the 'hardwaretype' number is the same as that shown in the ARP section of the 'Assigned Numbers' RFC. The 'hardwaretype' and 'ipaddr' numbers are in decimal; 'hardwareaddr' is in hex.
ここに、特定の例があります。 'hardwaretype'番号が'割り当てられた民数記'RFCのARP部で示されたそれと同じであることに注意してください。 小数には'hardwaretype'と'ipaddr'番号があります。 十六進法には'hardwareaddr'があります。
# last updated by smith
# 鍛冶屋によってアップデートされます。
/usr/boot
vmunix vmunix
tip ethertip
watch /usr/diag/etherwatch
gate gate.
/usr/boot vmunix vmunixチップethertip腕時計/usr/diag/etherwatchゲートのゲート。
% end of generic names, start of address mappings
総称の%終わり、アドレス・マッピングの始まり
hamilton 1 02.60.8c.06.34.98 36.19.0.5
burr 1 02.60.8c.34.11.78 36.44.0.12
101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh
welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip
welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip
.64が外出を禁止するhamilton1 02.60.8c.06.34.98 36.19.0.5ばり1 02.60.8c.34.11.78 36.44.0.12 101ゲートウェイ1 02.60.8c.23.ab.35 36.44.0.32ゲート101mjh-ゲートウェイ1 02.60.8c.12.32.bc36.42.0は-tipaに支払いを回避している1 02.60.8c.22.65の.32 36.47.0.14チップ-tipbに支払いを回避している1 02.60.8c.12.15.c8 36.46.0.12チップをmjhします。
In the example above, if 'mjh-gateway' does a default boot, it will get the file '/usr/boot/gate.mjh'.
例では、'mjh-ゲートウェイ'がデフォルトブーツをするなら、上に、それは'/usr/boot/gate.mjh'というファイルを手に入れるでしょう。
Croft & Gilmore [Page 11]
耕地とギルモア[11ページ]
RFC 951 September 1985 Bootstrap Protocol
RFC951 1985年9月はプロトコルを独力で進みます。
10. Acknowledgements
10. 承認
Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP bootstraping [2] using RARP [1].
ロスフィンリースン(etアル)は、2の以前のRFCが[2] RARP[1]を使用することでTFTP bootstrapingについて議論するのを生産しました。
We would also like to acknowledge the previous work and comments of Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
また、クリスマスChiappa、ボブリヨン、ジェフ・ムガール人、マーク・ルイス、およびデヴィッド・プラマーの前の仕事とコメントを承諾したいと思います。
REFERENCES
参照
1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.
1. ロスフィンリースン、ティモシー・マン、ジェフリー・ムガール人、マーヴィンTheimer。 逆アドレス解決プロトコル。 RFC903、NIC、1984年6月。
2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,
June, 1984.
2. ロスフィンリースン。 TFTPを使用して、ローディングを独力で進んでください。 RFC906、NIC、1984年6月。
3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,
September, 1984.
3. Lottorをマークしてください。 簡単なファイル転送プロトコル。 RFC913、NIC、1984年9月。
4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,
October, 1984.
4. ジェフリー・ムガール人。 インターネットパケットを放送します。 RFC919、NIC、1984年10月。
5. David Plummer. An Ethernet Address Resolution Protocol. RFC
826, NIC, September, 1982.
5. デヴィッド・プラマー。 イーサネットは解決プロトコルを記述します。 RFC826、NIC、1982年9月。
6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.
6. ジョン・ポステル。 ファイル転送プロトコル。 RFC765、NIC、1980年6月。
7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.
7. ジョン・ポステル。 ユーザー・データグラム・プロトコル。 RFC768、NIC、1980年8月。
8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
8. ジョン・ポステル。 インターネットプロトコル。 RFC791、NIC、1981年9月。
9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,
June, 1981.
9. K。 R。 Sollins、クリスマスChiappa。 TFTPは議定書を作ります。 RFC783、NIC、1981年6月。
Croft & Gilmore [Page 12]
耕地とギルモア[12ページ]
一覧
スポンサーリンク
