RFC1532 日本語訳
1532 Clarifications and Extensions for the Bootstrap Protocol. W.Wimer. October 1993. (Format: TXT=51545 bytes) (Obsoleted by RFC1542) (Updates RFC0951) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Wimer Request for Comments: 1532 Carnegie Mellon University Updates: 951 October 1993 Category: Standards Track
Wimerがコメントのために要求するワーキンググループW.をネットワークでつないでください: 1532のカーネギーメロン大学アップデート: 951 1993年10月のカテゴリ: 標準化過程
Clarifications and Extensions for the Bootstrap Protocol
明確化と拡大、プロトコルを独力で進んでください。
Status of this Memo
このMemoの状態
This RFC specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas.
BOOTPプロトコルのいくつかの局面がかなり緩く正式仕様書に基づき定義されました。 「「BOOTP中継エージェント」の振舞いに概説だけを提供した、(BOOTP小口運送業者が元々電話をした、」、) また、クライアント振舞い記述に、ある方法で苦しみました。 このメモは、これらの領域で仕様をはっきりさせて、強化するのを試みます。
In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.
さらに、正式仕様書が書かれて以来、新規発行は起こっています。 また、このメモは、これらのいくつかを扱うのを試みます。
Table of Contents
目次
1. Introduction................................................. 2 1.1 Requirements................................................ 2 1.2 Terminology................................................. 3 1.3 Data Transmission Order..................................... 4 2. General Issues............................................... 5 2.1 General BOOTP Processing.................................... 5 2.2 Definition of the 'flags' Field............................. 5 2.3 Bit Ordering of Hardware Addresses.......................... 7 2.4 BOOTP Over IEEE 802.5 Token Ring Networks................... 8 3. BOOTP Client Behavior........................................ 9 3.1 Client use of the 'flags' field............................. 9 3.1.1 The BROADCAST flag........................................ 9 3.1.2 The remainder of the 'flags' field........................ 9 3.2 Definition of the 'secs' field.............................. 9 3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10 3.4 Interpretation of the 'giaddr' field........................ 11 3.5 Vendor information "magic cookie"........................... 12 4. BOOTP Relay Agents........................................... 13
1. 序論… 2 1.1の要件… 2 1.2用語… 3 1.3 データ伝送オーダー… 4 2. 一般問題… 5 2.1 一般BOOTP処理… 5 2.2 '旗'分野の定義… 5 2.3にハードウェア・アドレスを注文しながら、噛み付きました… 7 IEEE802.5トークンリングネットワークの上の2.4BOOTP… 8 3. BOOTPクライアントの振舞い… 9 3.1 '旗'分野のクライアント使用… 9 3.1 .1 BROADCASTは弛みます… 9 3.1 .2 '旗'分野の残り… 9 3.2 'secs'分野の定義… 9 3.3 'ciaddr'と'yiaddr'分野の使用… 10 3.4 'giaddr'分野の解釈… 11 3.5 「魔法のクッキー」というベンダー情報… 12 4. BOOTPはエージェントをリレーします… 13
Wimer [Page 1] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[1ページ]RFC1532明確化と拡大
4.1 General BOOTP Processing for Relay Agents................... 13 4.1.1 BOOTREQUEST Messages...................................... 14 4.1.2 BOOTREPLY Messages........................................ 16 5. BOOTP Server Behavior........................................ 18 5.1 Reception of BOOTREQUEST Messages........................... 18 5.2 Use of the 'secs' field..................................... 19 5.3 Use of the 'ciaddr' field................................... 19 5.4 Strategy for Delivery of BOOTREPLY Messages................. 19 Acknowledgements................................................ 21 References...................................................... 21 Security Considerations......................................... 22 Author's Address................................................ 22
4.1 中継エージェントのための一般BOOTP処理… 13 4.1 .1 BOOTREQUESTメッセージ… 14 4.1 .2 BOOTREPLYメッセージ… 16 5. BOOTPサーバの振舞い… 18 5.1 BOOTREQUESTメッセージのレセプション… 18 5.2 'secs'分野の使用… 19 5.3 'ciaddr'分野の使用… 19 BOOTREPLYメッセージの配送のための5.4戦略… 19の承認… 21の参照箇所… 21 セキュリティ問題… 22作者のアドレス… 22
1. Introduction
1. 序論
The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which allows a booting host to configure itself dynamically and without user supervision. BOOTP provides a means to notify a host of its assigned IP address, the IP address of a boot server host, and the name of a file to be loaded into memory and executed [1]. Other configuration information such as the local subnet mask, the local time offset, the addresses of default routers, and the addresses of various Internet servers can also be communicated to a host using BOOTP [2].
Bootstrapプロトコル(BOOTP)は穂ばらみホストがダイナミックとユーザ指揮なしでそれ自体を構成できるIP UDP/ベースのプロトコルです。 BOOTPは割り当てられたIPアドレスのホスト、ブート・サーバーホストのIPアドレス、およびファイルの名前がメモリに積み込まれるように通知する手段を提供して、[1]を実行しました。 地方のサブネットマスクなどの他の設定情報、現地時間は相殺されました、デフォルトルータのアドレス、そして、また、BOOTP[2]を使用することで様々なインターネット・サーバのアドレスをホストに伝えることができます。
Unfortunately, the original BOOTP specification [1] left some issues of the protocol open to question. The exact behavior of BOOTP relay agents formerly called "BOOTP forwarding agents") was not clearly specified. Some parts of the overall protocol specification actually conflict, while other parts have been subject to misinterpretation, indicating that clarification is needed. This memo addresses these problems.
残念ながら、当初のBOOTP仕様[1]はプロトコルのいくつかの問題を疑問の余地があるままにしました。 以前「BOOTP小口運送業者」と呼ばれたBOOTP中継エージェントの正確な振舞い) 明確に指定されませんでした。 総合的なプロトコル仕様のいくつかの部分が実際に闘争します、他の部品は誤解を受けることがありますが、明確化が必要であることを示して。 このメモはこれらのその問題を訴えます。
Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network has been developed which presents a unique problem for BOOTP's particular message-transfer paradigm. This memo also suggests a solution for this problem.
BOOTPの導入以来、BOOTPの特別のメッセージ転送パラダイムのためにユニークな問題を提示するIEEE802.5Token Ring Networkは開発されています。 また、このメモはこの問題によってソリューションを示します。
NOTE: Unless otherwise specified in this document or a later document, the information and requirements specified througout this document also apply to extensions to BOOTP such as the Dynamic Host Configuration Protocol (DHCP) [3].
以下に注意してください。 別の方法でこのドキュメントか後のドキュメントで指定されない場合、情報と要件はDynamic Host Configuration Protocol(DHCP)[3]などのBOOTPにまたこのドキュメントが拡大に適用するthrougoutを指定しました。
1.1 Requirements
1.1 要件
In this memo, the words that are used to define the significance of particular requirements are capitalized. These words are:
このメモでは、特定の要件の意味を定義するのに使用される単語は大文字で書かれます。 これらの単語は以下の通りです。
Wimer [Page 2] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[2ページ]RFC1532明確化と拡大
o "MUST"
o "MUST"
This word or the adjective "REQUIRED" means that the item
is an absolute requirement of the specification.
「必要である」というこの単語か形容詞が、項目が仕様に関する絶対条件であることを意味します。
o "MUST NOT"
o 「必須NOT」
This phrase means that the item is an absolute prohibition
of the specification.
この句は、項目が仕様の絶対禁止であることを意味します。
o "SHOULD"
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a
different course.
この単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
o "SHOULD NOT"
o 「」であるべきです
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighed before
implementing any behavior described with this label.
この句は、このラベルで説明されたどんな振舞いも実装する前にいつ記載された振舞いが許容できるか、または役に立ちさえしますが、完全な含意が理解されるべきであるか、そして、この件が慎重に熟慮した特定の事情の正当な理由が存在するかもしれないことを意味します。
o "MAY"
o 「5月」
This word or the adjective "OPTIONAL" means that this item
is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or
because it enhances the product, for example; another
vendor may omit the same item.
「任意である」というこの単語か形容詞が、本当に、この項目が任意であることを意味します。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
1.2 Terminology
1.2 用語
This memo uses the following terms:
このメモは次の用語を使用します:
BOOTREQUEST
BOOTREQUEST
A BOOTREQUEST message is a BOOTP message sent from a BOOTP
client to a BOOTP server, requesting configuration information.
BOOTREQUESTメッセージは設定情報を要求して、BOOTPクライアントからBOOTPサーバに送られたBOOTPメッセージです。
BOOTREPLY
BOOTREPLY
A BOOTREPLY message is a BOOTP message sent from a BOOTP server
to a BOOTP client, providing configuration information.
BOOTREPLYメッセージは設定情報を提供して、BOOTPサーバからBOOTPクライアントに送られたBOOTPメッセージです。
Wimer [Page 3] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[3ページ]RFC1532明確化と拡大
Silently discard
静かに捨ててください。
This memo specifies several cases where a BOOTP entity is to
"silently discard" a received BOOTP message. This means that
the entity is to discard the message without further
processing, and that the entity will not send any ICMP error
message as a result. However, for diagnosis of problems, the
entity SHOULD provide the capability of logging the error,
including the contents of the silently-discarded message, and
SHOULD record the event in a statistics counter.
このメモは受信されたBOOTPメッセージを静かに捨てる」「BOOTP実体がことである数個のケースを指定します。 これは、実体がさらなる処理なしでメッセージを捨てることであり、実体がその結果どんなICMPエラーメッセージも送らないことを意味します。 しかしながら、問題の診断のために、実体SHOULDは静かに捨てられたメッセージのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
1.3 Data Transmission Order
1.3 データ伝送オーダー
The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.
本書では説明されたヘッダーとデータの伝達の注文を八重奏レベルに決議します。 ダイヤグラムが八重奏のグループを示しているときはいつも、それらの八重奏の送信の注文はそれらが英語で読まれる通常のオーダーです。 例えば、以下のダイヤグラムで、八重奏はオーダーで伝えられて、それらが番号付であるということです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-------------------------------+
| 3 | 4 |
+-------------------------------+
| 5 | 6 |
+-------------------------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | +-------------------------------+ | 3 | 4 | +-------------------------------+ | 5 | 6 | +-------------------------------+
Whenever an octet represents a numeric quantity, the leftmost bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal).
八重奏が数値量を表すときはいつも、ダイヤグラムによる一番左ビットは、高位か最上位ビットです。 すなわち、0とラベルされたビットは最も重要なビットです。 例えば、以下のダイヤグラムは値170の(小数)を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+---------------+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +---------------+
Similarly, whenever a multi-octet field represents a numeric quantity the leftmost bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.
同様に、マルチ八重奏分野が数値量を表すときはいつも、全体の分野の一番左ビットは最も重要なビットです。 マルチ八重奏量が伝えられるとき、最も重要な八重奏は最初に、伝えられます。
Wimer [Page 4] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[4ページ]RFC1532明確化と拡大
2. General Issues
2. 一般答弁
This section covers issues of general relevance to all BOOTP entities (clients, servers, and relay agents).
このセクションはすべてのBOOTP実体(クライアント、サーバ、および中継エージェント)に一般的な関連性の問題をカバーします。
2.1 General BOOTP Processing
2.1 一般BOOTP処理
The following consistency checks SHOULD be performed on BOOTP messages:
以下の一貫性はSHOULDをチェックします。BOOTPメッセージに実行されてください:
o The IP Total Length and UDP Length must be large enough to
contain the minimal BOOTP header of 300 octets (in the UDP
data field) specified in [1].
o IP Total LengthとUDP Lengthは[1]で指定された300の八重奏(UDPデータ・フィールドの)の最小量のBOOTPヘッダーを含むことができるくらい大きくなければなりません。
NOTE: Future extensions to the BOOTP protocol may increase the size of BOOTP messages. Therefore, BOOTP messages which, according to the IP Total Length and UDP Length fields, are larger than the minimum size specified by [1] MUST also be accepted.
以下に注意してください。 BOOTPプロトコルへの今後の拡大はBOOTPメッセージのサイズを増強するかもしれません。 したがって、また、IP Total LengthとUDP Length分野に従って最小規模が[1]で指定したより大きいBOOTPメッセージを受け入れなければなりません。
o The 'op' (opcode) field of the message must contain either the
code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).
o メッセージの'オプアート'(opcode)分野はBOOTREQUEST(1)のためのコードかBOOTREPLY(2)のためのコードのどちらかを含まなければなりません。
BOOTP messages not meeting these consistency checks MUST be silently discarded.
静かにこれらの一貫性チェックを満たさないBOOTPメッセージを捨てなければなりません。
2.2 Definition of the 'flags' Field
2.2 '旗'分野の定義
The standard BOOTP message format defined in [1] includes a two-octet field located between the 'secs' field and the 'ciaddr' field. This field is merely designated as "unused" and its contents left unspecified, although Section 7.1 of [1] does offer the following suggestion:
[1]で定義された標準のBOOTPメッセージ・フォーマットは'secs'分野と'ciaddr'分野の間に位置する2八重奏の分野を含んでいます。 この分野は単に「未使用」で任じられました、そして、コンテンツは不特定のままにされました、[1]のセクション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."
「初めてパケットをセットアップする前に、全体のパケットバッファをすべてのゼロまできれいにするのは、名案です」。 「これはそれらのデフォルト状態にすべての野原を置くでしょう。」
This memo hereby designates this two-octet field as the 'flags'
field.
このメモは'旗'分野としてこれによりこの2八重奏の分野を指定します。
This memo hereby defines the most significant bit of the 'flags'
field as the BROADCAST (B) flag. The semantics of this flag are
discussed in Sections 3.1.1 and 4.1.2 of this memo.
このメモはこれにより'旗'分野の最も重要なビットをBROADCAST(B)旗と定義します。 セクション3.1.1でこの旗の意味論について議論します、そして、4.1はこの.2のメモについて議論します。
The remaining bits of the 'flags' field are reserved for future
use. They MUST be set to zero by clients and ignored by servers
and relay agents.
'旗'分野の残っているビットは今後の使用のために予約されます。 それらをクライアントによってゼロに設定されて、サーバと中継エージェントは無視しなければなりません。
Wimer [Page 5] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[5ページ]RFC1532明確化と拡大
The 'flags' field, then, appears as follows:
次に、'旗'野原は以下の通りに見えます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-----------------------------+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| MBZ| +-+-----------------------------+
where:
どこ:
B BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2)
B BROADCAST旗(セクション3.1.1と4.1では、.2について議論します)
MBZ MUST BE ZERO (reserved for future use)
MBZはゼロであるに違いありません。(今後の使用のために、予約されます)
The format of a BOOTP message is shown below. The numbers in parentheses indicate the size of each field in octets.
BOOTPメッセージの書式は以下に示されます。 括弧の数は八重奏における、それぞれの分野のサイズを示します。
Wimer [Page 6] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[6ページ]RFC1532明確化と拡大
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | vend (64) | +---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプアート(1)| htype(1)| hlen(1)| ホップ(1)| +---------------+---------------+---------------+---------------+ | xid(4)| +-------------------------------+-------------------------------+ | secs(2)| 旗(2)| +-------------------------------+-------------------------------+ | ciaddr(4)| +---------------------------------------------------------------+ | yiaddr(4)| +---------------------------------------------------------------+ | siaddr(4)| +---------------------------------------------------------------+ | giaddr(4)| +---------------------------------------------------------------+ | | | chaddr(16)| | | | | +---------------------------------------------------------------+ | | | sname(64)| +---------------------------------------------------------------+ | | | ファイル(128)| +---------------------------------------------------------------+ | | | (64)を販売してください。| +---------------------------------------------------------------+
2.3 Bit Ordering of Hardware Addresses
2.3に、ハードウェア・アドレスを注文しながら、噛み付きました。
The bit ordering used for link-level hardware addresses in the protocol [4] on the client's link-level network (assuming ARP is defined for that network).
注文がリンク・レベルハードウェア・アドレスにクライアントのリンク・レベルネットワーク(ARPがそのネットワークのために定義されると仮定する)でプロトコル[4]に使用したビット。
The 'chaddr' field MUST be preserved as it was specified by the BOOTP client. A relay agent MUST NOT reverse the bit ordering of the two networks which use different bit orderings.
それがBOOTPクライアントによって指定されたとき、'chaddr'分野を保持しなければなりません。 中継エージェントは異なった噛み付いている受注業務を使用する2つのネットワークを注文するビットを逆にしてはいけません。
DISCUSSION:
議論:
One of the primary reasons the 'chaddr' field exists is to
enable BOOTP servers and relay agents to communicate directly
with clients without the use of broadcasts. In practice, the
contents of the the same way the normal ARP protocol would
'chaddr'分野が存在しているプライマリ理由の1つはBOOTPサーバと中継エージェントがクライアントと共に放送の使用なしで直接伝達するのを可能にすることです。 実際には、正常なARPが議定書を作る同じ方法のコンテンツはそうするでしょう。
Wimer [Page 7] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[7ページ]RFC1532明確化と拡大
have. Clearly, interoperability can only be achieved if a
consistent interpretation of the 'chaddr' field is used.
持っています。 明確に、'chaddr'分野の一貫した解釈が使用されている場合にだけ、相互運用性を達成できます。
As a practical example, this means that the bit ordering used
for the is the opposite of the bit ordering used by a BOOTP
client on a DIX ethernet network.
実例、噛み付いている注文が使用したこの手段、DIXイーサネットネットワークでBOOTPクライアントによって使用されたビットが注文される正反対はそうです。
2.4 BOOTP Over IEEE 802.5 Token Ring Networks
2.4 IEEE802.5トークンリングネットワークの上のBOOTP
Special consideration of the client/server and client/relay agent interactions must be given to IEEE 802.5 networks because of non- transparent bridging.
相互作用を与えなければならないクライアント/サーバとクライアント/中継エージェントの特別の配慮は非透明であるのでIEEE802.5にブリッジすることをネットワークでつなぎます。
The client SHOULD send its broadcast BOOTREQUEST with an All Routes Explorer RIF. This will enable servers/relay agents to cache the return route if they choose to do so. For those server/relay agents which cannot cache the return route (because they are stateless, for example), the BOOTREPLY message SHOULD be sent to the client's hardware address, as taken from the BOOTP message, with a Spanning Tree Rooted RIF. The actual bridge route will be recorded by the client and server/relay agent by normal ARP processing code.
クライアントSHOULDはAll RoutesエクスプローラーRIFと放送BOOTREQUESTを送ります。 彼らが、そうするのを選ぶと、これは、サーバ/中継エージェントが戻り経路をキャッシュするのを可能にするでしょう。 戻り経路(例えば、彼らが状態がないので)、BOOTREPLYメッセージSHOULDをキャッシュできないそれらのサーバ/中継エージェントには、クライアントのハードウェア・アドレスに送ってください、BOOTPメッセージから取るように、Spanning Tree Rooted RIFと共に。 実際のブリッジルートは正常なARP処理コードによってクライアントとサーバ/中継エージェントによって記録されるでしょう。
DISCUSSION:
議論:
In the simplest case, an unbridged, single ring network, the
broadcast behavior of the BOOTP protocol is identical to that
of Ethernet networks. However, a BOOTP client cannot know, a
priori, that an 802.5 network is not bridged. In fact, the
likelihood is that the server, or relay agent, will not know
either.
最も簡単なケース、非ブリッジしていて、ただ一つのリングネットワークでは、BOOTPプロトコルの放送の振舞いはイーサネットネットワークのものと同じです。 しかしながら、BOOTPクライアントは、802.5ネットワークがブリッジされないのを先験的に知ることができません。 事実上、見込みはサーバ、または中継エージェントが知らないということです。
Of the four possible scenerios, only two are interesting: where
the assumption is that the 802.5 network is not bridged and it
is, and the assumption that the network is bridged and it is
not. In the former case, the Routing Information Field (RIF)
will not be used; therefore, if the server/relay agent are on
another segment of the ring, the client cannot reach it. In
the latter case, the RIF field will be used, resulting in a few
extraneous bytes on the ring. It is obvious that an almost
immeasurable inefficiency is to be preferred over a complete
failure to communicate.
4の可能なsceneriosでは、2だけがおもしろいです: 仮定は802.5ネットワークがブリッジされないで、それがブリッジされるというどこのことですか、そして、ネットワークがブリッジされて、それがブリッジされないという仮定。 前の場合では、経路情報Field(RIF)は使用されないでしょう。 したがって、サーバ/中継エージェントがリングの別のセグメントにいるなら、クライアントはそれに達することができません。 後者の場合では、リングの異質な数バイトをもたらして、RIF分野は使用されるでしょう。 交信しない完全なことよりほとんど測り知れない非能率がことである好まれるのは明白です。
Given that the assumption is that RIF fields will be needed, it
is necesary to determine the optimum method for the client to
reach the server/relay agent, and the optimum method for the
response to be returned.
仮定がRIF分野が必要であるということであるなら、それはクライアントがサーバ/中継エージェントに連絡する最適なメソッド、および応答が返される最適なメソッドを決定するnecesaryです。
Wimer [Page 8] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[8ページ]RFC1532明確化と拡大
3. BOOTP Client Behavior
3. BOOTPクライアントの振舞い
This section clarifies various issues regarding BOOTP client behavior.
このセクションはBOOTPクライアントの振舞いに関する様々な問題をはっきりさせます。
3.1 Client use of the 'flags' field
3.1 '旗'分野のクライアント使用
3.1.1 The BROADCAST flag
3.1.1 BROADCAST旗
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY messages directly to a client using unicast delivery. The IP destination address (in the IP header) is set to the BOOTP 'yiaddr' address and the link-layer destination address is set to the BOOTP unable to receive such unicast IP datagrams until they know their own IP address (thus we have a "chicken and egg" issue). Often, however, they can receive broadcast IP datagrams (those with a valid IP broadcast address as the IP destination and the link-layer broadcast address as the link-layer destination).
通常、BOOTPサーバと中継エージェントは、ユニキャスト配送を使用することで直接クライアントへのメッセージをBOOTREPLYに提供するのを試みます。 受信者IPアドレス(IPヘッダーの)はBOOTP'yiaddr'アドレスに設定されます、そして、リンクレイヤ送付先アドレスは彼らがそれら自身のIPアドレスを知るまで(その結果、私たちには、「鶏肉と卵」問題があります)そのようなユニキャストIPデータグラムを受け取ることができないBOOTPに設定されます。 しかしながら、しばしば、彼らは放送IPデータグラムを受けることができます(IPの目的地とリンクレイヤがリンクレイヤの目的地としてアドレスを放送するとき、有効なIPがあるものはアドレスを放送します)。
If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client.
クライアントはこのカテゴリになって、それは新たに定義されたBROADCASTがそれが生成するBOOTREPLYメッセージの'旗'分野で旗を揚げさせるSHOULDセット(1への)です。 これは彼らが、彼らのBOOTREPLYメッセージをクライアントに放送するのを試みるべきであるというBOOTPサーバと中継エージェントへのヒントを提供するでしょう。
If a client does not have this limitation (i.e., it is perfectly able to receive unicast BOOTREPLY messages), it SHOULD NOT set the BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
クライアントにはこの制限がなくて(すなわち、それはユニキャストBOOTREPLYメッセージを完全に受け取ることができます)、それがBROADCASTが旗を揚げさせるSHOULD NOTセットである、(すなわち、それ、SHOULDはBROADCAST旗を0まで)きれいにします。
DISCUSSION:
議論:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
プロトコルへのこの追加は古いホスト導入のための回避策です。 そのような実装SHOULDは彼らがユニキャストBOOTREPLYメッセージを受け取ることができるように変更されていて、その結果、この回避策の使用を不要にしています。 一般に、このメカニズムの使用はお勧めできないです。
3.1.2 The remainder of the 'flags' field
3.1.2 '旗'分野の残り
The remaining bits of the 'flags' field are reserved for future use. A client MUST set these bits to zero in all BOOTREQUEST messages it generates. A client MUST ignore these bits in all BOOTREPLY messages it receives.
'旗'分野の残っているビットは今後の使用のために予約されます。 クライアントはそれが生成するすべてのBOOTREQUESTメッセージのゼロにこれらのビットを設定しなければなりません。 クライアントはそれが受け取るすべてのBOOTREPLYメッセージでこれらのビットを無視しなければなりません。
3.2 Definition of the 'secs' field
3.2 'secs'分野の定義
The 'secs' field of a BOOTREQUEST message SHOULD represent the elapsed time, in seconds, since the client sent its first BOOTREQUEST
SHOULDがクライアントが最初のBOOTREQUESTを送って以来の秒の経過時間に表すBOOTREQUESTメッセージの'secs'分野
Wimer [Page 9] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[9ページ]RFC1532明確化と拡大
message. Note that this implies that the 'secs' field of the first BOOTREQUEST message SHOULD be set to zero.
メッセージ。 これが、最初のBOOTREQUESTメッセージSHOULDの'secs'分野がゼロに設定されるのを含意することに注意してください。
Clients SHOULD NOT set the 'secs' field to a value which is constant for all BOOTREQUEST messages.
クライアントSHOULD NOTはすべてのBOOTREQUESTメッセージに、一定の値に'secs'分野を設定します。
DISCUSSION:
議論:
The original definition of the 'secs' field was vague. It was
not clear whether it represented the time since the first
BOOTREQUEST message was sent or some other time period such as
the time since the client machine was powered-up. This has
limited its usefulness as a policy control mechanism for BOOTP
servers and relay agents. Furthermore, certain client
implementations have been known to simply set this field to a
constant value or use incorrect byte-ordering. Incorrect
byte-ordering usually makes it appear as if a client has been
waiting much longer than it really has, so a relay agent will
relay the BOOTREQUEST sooner than desired (usually
immediately). These implementation errors have further
undermined the usefulness of the 'secs' field. These incorrect
implementations SHOULD be corrected.
'secs'分野のオリジナルの定義はあいまいでした。 それが最初のBOOTREQUESTメッセージを送って以来の時間かクライアントマシンが動力付きに上がる時から時間などのある他の期間を表したかどうかは、明確ではありませんでした。 これはBOOTPサーバと中継エージェントのための方針制御機構として有用性を制限しました。 その上、単にこの分野を恒常価値に設定するか、またはあるクライアント実装が不正確なバイト順を使用するのが知られています。 不正確なバイト順が通常まるでクライアントが本当にそうするよりはるかに長い間待っているかのように見えるようにするので、中継エージェントは望まれているより早さに(通常すぐに)、BOOTREQUESTをリレーするでしょう。 これらの実装誤りはさらに'secs'分野の有用性を弱体化させました。 これらの不正確な実装SHOULD、修正されてください。
3.3 Use of the 'ciaddr' and 'yiaddr' fields
3.3 'ciaddr'と'yiaddr'分野の使用
If a BOOTP client does not know what IP address it should be using, the client SHOULD set the 'ciaddr' field to 0.0.0.0. If the client has the ability to remember the last IP address it was assigned, or it has been preconfigured with an IP address via some alternate mechanism, the client MAY fill the 'ciaddr' field with that IP address. If the client does place a non-zero IP address in the datagrams addressed to that IP address and also answer ARP requests for that IP address (if ARP is used on that network).
使用、クライアントSHOULDが設定していて、BOOTPクライアントが、それはどんなIPアドレスがそうするべきであるかを知らないなら、'ciaddr'は.0に.0を0.0としてさばきます。 クライアントに最後のIPアドレスを思い出す能力があるなら、それが割り当てられたか、またはIPアドレスで何らかの代替のメカニズムで、クライアントがそのIPアドレスで'ciaddr'分野を満たすかもしれないのがあらかじめ設定されました。 クライアントが入賞するなら、データグラムの非ゼロIPアドレスはそのIPアドレスと答えARPにもそのIPアドレスを求める要求を扱いました(ARPがそのネットワークで使用されるなら)。
The BOOTP server is free to assign a different IP address (in the SHOULD adopt the IP address specified in 'yiaddr' and begin using it as soon as possible.
BOOTPサーバは無料で異なったIPアドレスを割り当てることができます。(SHOULDでは、'yiaddr'で指定されたIPアドレスを採用してください、そして、できるだけ早く、それを使用し始めてください。
DISCUSSION:
議論:
There are various interpretations about the purpose of the
'ciaddr' field and, unfortunately, no agreement on a single
correct interpretation. One interpretation is that if a client
is willing to accept whatever IP address the BOOTP server
assigns to it, the client should always place 0.0.0.0 in the
'ciaddr' field, regardless of whether it knows its previously-
assigned address. Conversely, if the client wishes to assert
that it must have a particular IP address (e.g., the IP address
'ciaddr'分野の目的と残念ながらただ一つの正しい解釈の協定がないのに関する様々な解釈があります。 1つの解釈がクライアントが、BOOTPサーバがそれに割り当てるどんなIPアドレスも受け入れても構わないと思っているなら、クライアントがいつも入賞するべきであるということである、0.0、.0、.0、以前に割り当てられたアドレスを知っているかどうかにかかわらず'ciaddr'分野で。 クライアントが、そうしなければならないと断言したいなら逆に、特定のIPアドレスを持ってください、(例えば、IPアドレス
Wimer [Page 10] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[10ページ]RFC1532明確化と拡大
was hand-configured by the host administrator and BOOTP is only
being used to obtain a boot file and/or information from the
'vend' field), the client will then fill the 'ciaddr' field
with the desired IP address and ignore the IP address assigned
by the BOOTP server as indicated in the 'yiaddr' field. An
alternate interpretation holds that the client always fills the
'ciaddr' field with its most recently-assigned IP address (if
known) even if that address may be incorrect. Such a client
will still accept and use the address assigned by the BOOTP
server as indicated in the 'yiaddr' field. The motivation for
this interpretation is to aid the server in identifying the
client and/or in delivering the BOOTREPLY to the client. Yet a
third (mis)interpretation allows the client to use client has
never used that address before or is not currently using that
address.
手でホストによって構成された管理者とBOOTPが'販売'分野からaブート・ファイル、そして/または、情報を得るのに使用されているだけであるということであった、)、クライアントは、次に、必要なIPアドレスで'ciaddr'分野を満たして、'yiaddr'分野にみられるようにBOOTPサーバによって割り当てられたIPアドレスを無視するでしょう。 代替の解釈は、そのアドレスが不正確であってもクライアントが最近最も割り当てられたIPアドレス(知られているなら)で'ciaddr'分野をいつも満たすと主張します。 それでも、そのようなクライアントは、'yiaddr'分野にみられるようにBOOTPサーバによって割り当てられたアドレスを、受け入れて、使用するでしょう。 この解釈に関する動機はクライアントを特定するBOOTREPLYをクライアントに提供する際にサーバを支援することです。 しかし、3分の1、(誤、)、解釈は、クライアントがそのアドレスを一度も使用したことがない使用にクライアントを許容するか、または現在、そのアドレスを使用していません。
The last interpretation is incorrect as it may prevent the
BOOTREPLY from reaching the client. The server will usually
unicast the reply to the address given in 'ciaddr' but the
client may not be listening on that address yet, or the client
may be connected to an incorrect subnet such that normal IP
routing (correctly) routes the reply to a different subnet.
BOOTREPLYがクライアントに届くのを防ぐかもしれないので、最後の解釈は不正確です。 サーバは通常'ciaddr'で与えられたアドレスに関する回答をユニキャストに望んでいますが、クライアントがそのアドレスでまだ聴いていないかもしれませんか、またはクライアントは、正常なIPルーティングが(正しく)異なったサブネットに回答を発送するように、不正確なサブネットに接続されるかもしれません。
The second interpretation also suffers from the "incorrect
subnet" problem.
また、2番目の解釈は「不正確なサブネット」問題に苦しみます。
The first interpretation seems to be the safest and most likely
to promote interoperability.
最初の解釈は最も安全であって、相互運用性を最も促進しそうなように思えます。
3.4 Interpretation of the 'giaddr' field
3.4 'giaddr'分野の解釈
The 'giaddr' field is rather poorly named. It exists to facilitate the transfer of BOOTREQUEST messages from a client, through BOOTP relay agents, to servers on different networks than the client. Similarly, it facilitates the delivery of BOOTREPLY messages from the servers, through BOOTP relay agents, back to the client. In no case does it represent a general IP router to be used by the client. A BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all BOOTREQUEST messages it generates.
'giaddr'分野はかなり不十分に命名されます。 それはクライアントからのBOOTREQUESTメッセージの転送を容易にするために存在しています、BOOTP中継エージェントを通して、クライアントより異なったネットワークのサーバに。 同様に、それはBOOTREPLYメッセージのBOOTP中継エージェントを通したサーバからクライアントまでの配送を容易にします。 クライアントによって使用されるように、それは一般的なIPルータを決して、表しません。 BOOTPクライアントが'giaddr'分野をゼロに設定しなければならない、(0.0 .0 .0) それが生成するすべてのBOOTREQUESTメッセージで。
A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY message to be the IP address of an IP router. A BOOTP client SHOULD completely ignore the contents of the 'giaddr' field in BOOTREPLY messages.
BOOTPクライアントはIPルータのIPアドレスであるBOOTREPLYメッセージの'giaddr'分野を解釈してはいけません。 BOOTPクライアントSHOULDはBOOTREPLYメッセージの'giaddr'分野のコンテンツを完全に無視します。
Wimer [Page 11] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[11ページ]RFC1532明確化と拡大
DISCUSSION:
議論:
The semantics of the 'giaddr' field were poorly defined.
Section 7.5 of [1] states:
'giaddr'分野の意味論は不十分に定義されました。 [1] 州のセクション7.5:
"If 'giaddr' (gateway address) is nonzero, then the packets
should be forwarded there first, in order to get to the
server."
「'giaddr'(ゲートウェイアドレス)が非零であるなら最初にパケットをそこに送るべきです、サーバを始めるために。」
In that sentence, "get to" refers to communication from the client to the server subsequent to the BOOTP exchange, such as a TFTP session. Unfortunately, the 'giaddr' field may contain the address of a BOOTP relay agent that is not itself an IP router (according to [1], Section 8, fifth paragraph), in which case, it will be useless as a first-hop for TFTP packets sent to the server (since, by definition, non-routers don't forward datagrams at the IP layer).
その文では、「始め」はクライアントからBOOTP交換へのその後のサーバまでコミュニケーションを示します、TFTPセッションのように。 残念ながら、'giaddr'分野はそれ自体でIPルータ(セクション8、[1]に従った第5パラグラフ)でないBOOTP中継エージェントのアドレスを含むかもしれません、その場合、TFTPパケットのための最初に、ホップがサーバに発信したので(非ルータが定義上IP層でデータグラムを進めないので)、それは役に立たなくなるでしょう。
Although now prohibited by Section 4.1.1 of this memo, the 'giaddr' field might contain a broadcast address according to Section 8, sixth paragraph of [1]. Not only would such an address be useless as a router address, it might also cause the client to ARP for the broadcast address (since, if the client didn't receive a subnet mask in the BOOTREPLY message, it would be unable to recognize a subnet broadcast address). This is clearly undesirable.
現在この.1のセクション4.1メモで禁止されますが、セクション8([1]の第6パラグラフ)によると、'giaddr'分野は放送演説を含むかもしれません。 また、そのようなアドレスが単にルータアドレスとして役に立たないだろうというのではなく、それは放送演説のためにARPにクライアントを引き起こすかもしれません(クライアントがBOOTREPLYメッセージにサブネットマスクを受け取らないなら、サブネット放送演説を認識できないので)。 これは明確に望ましくありません。
To reach a non-local server, clients can obtain a first-hop router address from the "Gateway" subfield of the "Vendor Information Extensions" [2] (if present), or via the ICMP router discovery protocol [5] or other similar mechanism.
非ローカルサーバに達するように、クライアントは「売り主情報拡張子」[2](存在しているなら)の「ゲートウェイ」部分体、ICMPルータ発見プロトコル[5]または他の同様のメカニズムで最初に、ホップルータアドレスを得ることができます。
3.5 Vendor information "magic cookie"
3.5 「魔法のクッキー」という売り主情報
It is RECOMMENDED that a BOOTP client always fill the first four octets of the 'vend' (vendor information) field of a BOOTREQUEST with a four-octet identifier called a "magic cookie." A BOOTP client SHOULD do this even if it has no special information to communicate to the BOOTP server using the 'vend' field. This aids the BOOTP server in determining what vendor information format it should use in its BOOTREPLY messages.
BOOTPクライアントがいつも4八重奏の識別子が「魔法のクッキー」と呼ばれているBOOTREQUESTの'販売(売り主情報)'分野の最初の4つの八重奏をいっぱいにするのは、RECOMMENDEDです。 それにBOOTPサーバに伝えるどんな特別な情報も'販売'分野を使用することでなくてもSHOULDがこれをするBOOTPクライアント。 それがBOOTREPLYメッセージでどんな売り主情報形式を使用するべきであるかを決定する際にこれはBOOTPサーバを支援します。
If a special vendor-specific magic cookie is not being used, a BOOTP client SHOULD use the dotted decimal value 99.130.83.99 as specified in [2]. In this case, if the client has no information to communicate to the server, the octet immediately following the magic cookie SHOULD be set to the "End" tag (255) and the remaining octets of the 'vend' field SHOULD be set to zero.
特別なベンダー特有の魔法のクッキーであるなら使用されないBOOTPクライアントSHOULD使用がドット付き10進法値である、99.130、.83、.99、[2]で指定されるように。 この場合、クライアントにサーバ、「終わり」までのセットがタグ(255)であったならすぐに魔法のクッキーSHOULDに続く八重奏、および'販売'分野SHOULDの残っている八重奏に伝えない情報が全くあるなら、ゼロに設定されてください。
Wimer [Page 12] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[12ページ]RFC1532明確化と拡大
DISCUSSION:
議論:
Sometimes different operating systems or networking packages
are run on the same machine at different times (or even at the
same time!). Since the hardware address placed in the 'chaddr'
field will likely be the same, BOOTREQUESTs from completely
different BOOTP clients on the same machine will likely be
difficult for a BOOTP server to differentiate. If the client
includes a magic cookie in its BOOTREQUESTs, the server will at
least know what format the client expects and can understand in
corresponding BOOTREPLY messages.
時々異なったオペレーティングシステムかネットワークパッケージがいろいろな時間(同時にさえ!)の同じマシンにおける走行です。 'chaddr'分野に置かれたハードウェア・アドレスがおそらく同じになるので、BOOTPサーバが差別化するのは、おそらく同じマシンの上の完全に異なったBOOTPクライアントからのBOOTREQUESTsが難しくなるでしょう。 クライアントがBOOTREQUESTsで魔法のクッキーを入れるなら、サーバは、クライアントがどんな形式を予想するかを少なくとも知って、対応するBOOTREPLYメッセージで理解されることができます。
4. BOOTP Relay Agents
4. BOOTP中継エージェント
In many cases, BOOTP clients and their associated BOOTP
server(s) do not reside on the same IP network or subnet. In
such cases, some kind of third-party agent is required to
transfer BOOTP messages between clients and servers. Such an
agent was originally referred to as a "BOOTP forwarding agent."
However, in order to avoid confusion with the IP forwarding
function of an IP router, the name "BOOTP relay agent" is
hereby adopted instead.
多くの場合、BOOTPクライアントと彼らの関連BOOTPサーバは同じIPネットワークかサブネットにありません。 そのような場合、ある種の第三者エージェントが、クライアントとサーバの間にBOOTPメッセージを移すのに必要です。 そのようなエージェントは元々、「BOOTP小口運送業者」と呼ばれました。 しかしながら、IPルータのIP推進機能への混乱を避けるために、名前「BOOTP中継エージェント」は代わりにこれにより採用されます。
DISCUSSION:
議論:
A BOOTP relay agent performs a task which is distinct from an
IP router's normal IP forwarding function. While a router
normally switches IP datagrams between networks more-or-less
transparently, a BOOTP relay agent may more properly be thought
to receive BOOTP messages as a final destination and then
generate new BOOTP messages as a result. It is incorrect for a
relay agent implementation to simply forward a BOOTP message
"straight through like a regular packet."
BOOTP中継エージェントはIPルータの正常なIP推進機能と異なったタスクを実行します。 通常、ルータが多少透過的にIPデータグラムをネットワークの間に切り換えている間、最終的な目的地としてBOOTPメッセージを受け取って、次に、BOOTP中継エージェントがその結果新しいBOOTPメッセージを生成すると、より適切に考えられるかもしれません。 中継エージェント実装が単に「まっすぐレギュラーのパケットのように」をBOOTPメッセージに送るのは、不正確です。
This relay-agent functionality is most conveniently located in
the routers which interconnect the clients and servers, but may
alternatively be located in a host which is directly connected
to the client subnet.
この中継エージェントの機能性は、クライアントとサーバとインタコネクトするルータで最も好都合なことに位置していますが、あるいはまた、直接クライアントサブネットに接続されるホストに位置するかもしれません。
Any Internet host or router which provides BOOTP relay-agent
capability MUST conform to the specifications in this memo.
BOOTP中継エージェントに能力を提供するどんなインターネット・ホストやルータもこのメモによる仕様に従わなければなりません。
4.1 General BOOTP Processing for Relay Agents
4.1 中継エージェントのための一般BOOTP処理
All locally delivered UDP messages whose UDP destination port number is BOOTPS (67) are considered for special processing by the host or router's logical BOOTP relay agent.
UDP目的地ポートナンバーがBOOTPS(67)であるすべての局所的に提供されたUDPメッセージが特別な処理のためにホストかルータの論理的なBOOTP中継エージェントによって考えられます。
Wimer [Page 13] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[13ページ]RFC1532明確化と拡大
In the case of a host, locally delivered datagrams are simply all datagrams normally received by that host, i.e., broadcast and multicast datagrams as well as unicast datagrams addressed to IP addresses of that host.
ホストの場合では、データグラムが局所的に提供されているのが、すべて、単に通常、すなわち、そのホスト、放送で受け取られたデータグラムであり、ユニキャストデータグラムと同様にマルチキャストデータグラムはそのホストのアドレスをIPに扱いました。
In the case of a router, locally delivered datagrams are broadcast and multicast datagrams as well as unicast datagrams addressed to IP addresses of that router. These are datagrams for which the router should be considered an end destination as opposed to an intermediate switching node. Thus a unicast datagram with an IP destination not matching any of the router's IP addresses is not considered for processing by the router's logical BOOTP relay agent.
ルータの場合では、局所的に提供されたデータグラムは放送されました、そして、ユニキャストデータグラムと同様にマルチキャストデータグラムはそのルータのアドレスをIPに扱いました。 これらは中間的切り換えノードと対照的にルータが端の目的地であると考えられるべきであるデータグラムです。 したがって、IPの目的地がルータのIPアドレスのいずれにも合っていないユニキャストデータグラムは処理のためにルータの論理的なBOOTP中継エージェントによって考えられません。
Hosts and routers are usually required to silently discard incoming datagrams containing illegal IP source addresses. This is generally known as "Martian address filtering." One of these illegal addresses is 0.0.0.0 (or actually anything on network 0). However, hosts or routers which support a BOOTP relay agent MUST accept for local delivery to the relay agent BOOTREQUEST messages whose IP source address is 0.0.0.0. BOOTREQUEST messages from legal IP source addresses MUST also be accepted.
通常、ホストとルータが、静かに不法なIPソースアドレスを含む受信データグラムを捨てるのに必要です。 一般に、これは「火星のアドレスフィルタリング」として知られています。 これらの不法なアドレスの1つはそうです。0.0 .0 .0 (実際にネットワーク0の何でも。) しかしながら、BOOTP中継エージェントをサポートするホストかルータが地方の配送のためにIPソースアドレスがある中継エージェントBOOTREQUESTメッセージに受け入れなければなりません。0.0 .0 .0。 また、法的なIPソースアドレスからのBOOTREQUESTメッセージを受け入れなければなりません。
A relay agent MUST silently discard any received UDP messages whose UDP destination port number is BOOTPC (68).
中継エージェントは静かに、UDP目的地ポートナンバーがBOOTPC(68)であるどんな受信されたUDPメッセージも捨てなければなりません。
DISCUSSION:
議論:
There should be no need for a relay agent to process messages
addressed to the BOOTPC port. Careful reading of the original
BOOTP specification [1] will show this. Nevertheless, some
relay agent implementations incorrectly relay such messages.
中継エージェントがBOOTPCポートに扱われたメッセージを処理する必要は全くあるべきではありません。 当初のBOOTP仕様[1]の熟読はこれを示すでしょう。 それにもかかわらず、いくつかの中継エージェント実装が不当にそのようなメッセージをリレーします。
The consistency checks specified in Section 2.1 SHOULD be performed by the relay agent. BOOTP messages not meeting these consistency checks MUST be silently discarded.
指定されて、一貫性をチェックします。セクション2.1SHOULDでは、中継エージェントによって実行されてください。 静かにこれらの一貫性チェックを満たさないBOOTPメッセージを捨てなければなりません。
4.1.1 BOOTREQUEST Messages
4.1.1 BOOTREQUESTメッセージ
Some configuration mechanism MUST exist to enable or disable the relaying of BOOTREQUEST messages. Relaying MUST be disabled by default.
何らかの構成メカニズムが、BOOTREQUESTメッセージのリレーを可能にするか、または無効にするために存在しなければなりません。 デフォルトでリレーを無効にしなければなりません。
When the BOOTP relay agent receives a BOOTREQUEST message, it MAY use the value of the 'secs' (seconds since client began booting) field of the request as a factor in deciding whether to relay the request. If such a policy mechanism is implemented, its threshold SHOULD be configurable.
BOOTP中継エージェントがBOOTREQUESTメッセージを受け取るとき、それは要求をリレーするかどうか決める要素として要求の'secs'(クライアントがブートし始めて以来の秒)分野の値を使用するかもしれません。 メカニズムはそのような方針であるなら実装されて、敷居はSHOULDです。構成可能であってください。
Wimer [Page 14] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[14ページ]RFC1532明確化と拡大
DISCUSSION:
議論:
To date, this feature of the BOOTP protocol has not necessarily
been shown to be useful. See Section 3.2 for a discussion.
これまで、BOOTPプロトコルのこの特徴は、役に立つように必ず示されるというわけではありませんでした。 議論に関してセクション3.2を見てください。
The relay agent MUST silently discard BOOTREQUEST messages whose provided to set this threshold to a smaller value if desired by the network manager. The default setting for a configurable threshold SHOULD be 4.
中継エージェントは静かにBOOTREQUESTを捨てなければなりません。ネットワークマネージャによって望まれているなら、より小さい値にこの敷居を設定するために提供していた状態でだれのものを通信させます。 構成可能な敷居にSHOULDを設定しながら、デフォルトとしてください。4になってください。
If the relay agent does decide to relay the request, it MUST examine
the 'giaddr' ("gateway" IP address) field. If this field is zero,
the relay agent MUST fill this field with the IP address of the
interface on which the request was received. If the interface has
more than one IP address logically associated with it, the relay
agent SHOULD choose one IP address associated with that interface and
use it consistently for all BOOTP messages it relays. If the
'giaddr' field contains some non-zero value, the 'giaddr' field MUST
NOT be modified. The relay agent MUST NOT, under any circumstances,
fill the 'giaddr' field with a broadcast address as is suggested in
[1] (Section 8, sixth paragraph).
中継エージェントが、要求をリレーすると決めるなら、それは'giaddr'(「ゲートウェイ」IPアドレス)分野を調べなければなりません。 この分野がゼロであるなら、中継エージェントは要求が受け取られたインタフェースのIPアドレスでこの分野を満たさなければなりません。 1つ以上のIPアドレスがインタフェースでそれに論理的に関連するようになるなら、中継エージェントSHOULDはそのインタフェースに関連している1つのIPアドレスを選んで、それがリレーするすべてのBOOTPメッセージに一貫してそれを使用します。 'giaddr'分野が何らかの非ゼロ価値を含んでいるなら、'giaddr'分野を変更してはいけません。 中継エージェントは[1](セクション8、第6パラグラフ)に示される放送演説で'giaddr'分野をどうあっても満たしてはいけません。
The value of the 'hops' field MUST be incremented.
'ホップ'分野の値を増加しなければなりません。
All other BOOTP fields MUST be preserved intact.
完全な状態で他のすべてのBOOTP分野を保持しなければなりません。
At this point, the request is relayed to its new destination (or destinations). This destination MUST be configurable. Further, this destination configuration SHOULD be independent of the destination configuration for any other so-called "broadcast forwarders" (e.g., for the UDP-based TFTP, DNS, Time, etc. protocols).
ここに、要求は新しい目的地(または、目的地)にリレーされます。 この目的地は構成可能であるに違いありません。 さらに、この目的地構成SHOULDはいかなる他のいわゆる「放送混載業者」のための目的地構成の如何にかかわらずこと(例えば、UDPベースのTFTP、DNS、Timeのためのなどプロトコル)です。
DISCUSSION:
議論:
The network manager may wish the relaying destination to be an
IP unicast, multicast, broadcast, or some combination. A
configurable list of destination IP addresses provides good
flexibility. More flexible configuration schemes are
encouraged. For example, it may be desirable to send to the
limited broadcast address (255.255.255.255) on specific
physical interfaces. However, if the BOOTREQUEST message was
received as a broadcast, the relay agent MUST NOT rebroadcast
the BOOTREQUEST on the physical interface from whence it came.
ネットワークマネージャは、リレーの目的地がIPユニキャスト、マルチキャスト、放送、または何らかの組み合わせである必要があるかもしれません。 送付先IPアドレスの構成可能なリストは良い柔軟性を提供します。 よりフレキシブルな構成体系は奨励されます。 例えば、限られた放送演説に発信するのが望ましいかもしれない、(255.255 .255 .255) 特定の物理インターフェースに関して。 中継エージェントが放送としてBOOTREQUESTメッセージを受け取ったなら起源から物理インターフェースのBOOTREQUESTをどのように再放送してはいけなくても、それは来ました。
A relay agent MUST use the same destination (or set of
destinations) for all BOOTREQUEST messages it relays from a
given client.
中継エージェントはそれが与えられたクライアントからリレーするすべてのBOOTREQUESTメッセージに、同じ目的地(または、目的地のセット)を使用しなければなりません。
Wimer [Page 15] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[15ページ]RFC1532明確化と拡大
DISCUSSION:
議論:
At least one known relay agent implementation uses a round-
robin scheme to provide load balancing across multiple BOOTP
servers. Each time it receives a new BOOTREQUEST message, it
relays the message to the next BOOTP server in a list of
servers. Thus, with this relay agent, multiple consecutive
BOOTREQUEST messages from a given client will be delivered to
different servers.
少なくとも1つの知られている中継エージェント実装が、複数のBOOTPサーバの向こう側にロードバランシングを提供するのに丸いコマドリ体系を使用します。 新しいBOOTREQUESTメッセージを受け取る各回、それはサーバのリストの次のBOOTPサーバにメッセージをリレーします。 したがって、この中継エージェントと共に、与えられたクライアントからの複数の連続したBOOTREQUESTメッセージが異なったサーバに提供されるでしょう。
Unfortunately, this well-intentioned scheme reacts badly with
DHCP [3] and perhaps other variations of the BOOTP protocol
which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY
messages between clients and servers. Therefore, all
BOOTREQUEST messages from a given client MUST be relayed to the
same destination (or set of destinations).
残念ながら、この善意の体系はひどくDHCP[3]と恐らくクライアントとサーバの間のBOOTREQUESTの複数の交換とBOOTREPLYメッセージによるBOOTPプロトコルの他の変化と反応します。 したがって、同じ目的地(または、目的地のセット)に与えられたクライアントからのすべてのBOOTREQUESTメッセージをリレーしなければなりません。
One way to meet this requirement while providing some load-
balancing benefit is to hash the client's link-layer address
(or some other reliable client-identifying information) and use
the resulting hash value to select the appropriate relay
destination (or set of destinations). The simplest solution,
of course, is to not use a load-balancing scheme and just relay
ALL received BOOTREQUEST messages to the same destination (or
set of destinations).
何らかの負荷を提供している間、この必要条件を満たすことにおける一方通行のバランスをとることの利益は、クライアントのリンクレイヤアドレス(または、ある他の信頼できるクライアント身元が分かる情報)を論じ尽くして、適切なリレーの目的地(または、目的地のセット)を選択するのに結果として起こるハッシュ値を使用することです。 最も簡単なソリューションは、もちろん負荷分散体系を使用して、ただ同じ目的地(または、目的地のセット)にすべての受信されたBOOTREQUESTメッセージをリレーするというわけではないことです。
When transmitting the request to its next destination, the
relay agent may set the IP Time-To-Live field to either the
default value for new datagrams originated by the relay agent,
or to the TTL of the original BOOTREQUEST decremented by (at
least) one.
次の目的地に要求を送るとき、中継エージェントは新しいデータグラムのためのデフォルト値が中継エージェントで溯源したどちらか、または、(少なくとも)の1つ減少するオリジナルのBOOTREQUESTのTTLにIP生きるTime分野を設定するかもしれません。
DISCUSSION:
議論:
As an extra precaution against BOOTREQUEST loops, it is
preferable to use the decremented TTL from the original
BOOTREQUEST. Unfortunately, this may be difficult to do in
some implementations.
BOOTREQUESTに対する付加的な注意が輪にされるとき、オリジナルのBOOTREQUESTから減少したTTLを使用するのは望ましいです。残念ながら、これはいくつかの実装でするのが難しいかもしれません。
If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum
is non-zero), the checksum must be recalculated before
transmitting the request.
BOOTREQUESTにUDPチェックサムがあるなら(すなわち、UDPチェックサムは非ゼロです)、要求を伝える前に、チェックサムについて再計算しなければなりません。
4.1.2 BOOTREPLY Messages
4.1.2 BOOTREPLYメッセージ
BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients. It is the responsibility of BOOTP servers to send BOOTREPLY messages directly to the relay agent identified in the BOOTREPLY messages it
BOOTP中継エージェントはBOOTPクライアントだけにBOOTREPLYメッセージをリレーします。 BOOTPサーバが直接中継エージェントへのメッセージをBOOTREPLYに送る責任がBOOTREPLYメッセージでそれを特定したということです。
Wimer [Page 16] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[16ページ]RFC1532明確化と拡大
receives are intended for BOOTP clients on its directly-connected networks.
受信、BOOTPクライアントのために、直接接続されたネットワークで意図します。
When a relay agent receives a BOOTREPLY message, it should examine the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and for the relay agent to deliver the BOOTREPLY message to the client.
中継エージェントがBOOTREPLYメッセージを受け取るとき、それは、BOOTP'giaddr'、'yiaddr'、'chaddr''htype'を調べて、BOOTREPLYメッセージをクライアントに提供する中継エージェントのために受け取るべきです。
The 'giaddr' field can be used to identify the logical interface from which the reply must be sent (i.e., the host or router interface connected to the same network as the BOOTP client). If the content of the 'giaddr' field does not match one of the relay agent's directly-connected logical interfaces, the BOOTREPLY messsage MUST be silently discarded.
回答を送らなければならない論理的なインタフェースを特定するのに'giaddr'分野を使用できます(すなわち、ホストかルータインタフェースがBOOTPクライアントと同じネットワークに接続しました)。 'giaddr'分野の内容が中継エージェントの直接接続された論理的なインタフェースの1つに合っていないなら、静かにBOOTREPLY messsageを捨てなければなりません。
The 'htype', 'hlen', and 'chaddr' fields supply the link-layer hardware type, hardware address length, and hardware address of the client as defined in the ARP protocol [4] and the Assigned Numbers document [6]. The 'yiaddr' field is the IP address of the client, as assigned by the BOOTP server.
'htype'、'hlen'、および'chaddr'分野はハードウェアタイプ、ハードウェア・アドレスの長さ、およびARPプロトコル[4]とAssigned民数記ドキュメント[6]で定義されるクライアントのハードウェア・アドレスをリンクレイヤに供給します。 'yiaddr'分野はBOOTPサーバによって割り当てられるようにクライアントのIPアドレスです。
The relay agent SHOULD examine the newly-defined BROADCAST flag (see Sections 2.2 and 3.1.1 for more information). If this flag is set to 1, the reply SHOULD be sent as an IP broadcast using the IP limited broadcast address 255.255.255.255 as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST flag is cleared (0), the reply SHOULD be sent as an IP unicast to the IP address specified by the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the reply MAY be sent as a broadcast, in which case it SHOULD be sent to the link-layer broadcast address using the IP limited broadcast address 255.255.255.255 as the IP destination address.
中継エージェントSHOULDは新たに定義されたBROADCAST旗を調べます(詳しい情報に関してセクション2.2と3.1.1を見てください)。 この旗が1、回答SHOULDに設定される、IPを使用するIP放送が放送演説を制限したので送ってください、255.255、.255、.255、受信者IPアドレスとリンクレイヤとして、リンクレイヤ送付先アドレスとしてのアドレスを放送してください。 BROADCAST旗がきれいにされる、(0)、回答SHOULD、'yiaddr'分野によって指定されたIPアドレスとリンクレイヤアドレスへのIPユニキャストが'chaddr'分野で指定したように、送ってください。 どれがそれをケースに入れるかでaがSHOULDを放送するときunicastingが可能です、回答を送るかもしれないということでないかどうか、IPの有限な放送演説を使用することでリンクレイヤ放送演説に送ってください、255.255、.255、.255、受信者IPアドレスとして。
DISCUSSION:
議論:
The addition of the BROADCAST flag to the protocol is a
workaround to help promote interoperability with certain client
implementations.
プロトコルへのBROADCAST旗の追加はあるクライアント実装で相互運用性を促進するのを助ける回避策です。
Note that since the 'flags' field was previously defined in [1]
simply as an "unused" field, it is possible that old client or
server implementations may accidentally and unknowingly set the
new BROADCAST flag. It is actually expected that such
implementations will be rare (most implementations seem to
zero-out this field), but interactions with such
implementations must nevertheless be considered. If an old
client or server does set the BROADCAST flag to 1 incorrectly,
conforming relay agents will generate broadcast BOOTREPLY
'旗'分野が以前に[1]で単に「未使用」の分野と定義されたのでその年取ったクライアントかサーバ実装が新しいBROADCAST旗を偶然と知らずに設定するのが、可能であることに注意してください。 そのような実装がまれであると(ほとんどの実装が無アウトにこの分野を思えます)実際に予想されますが、それにもかかわらず、そのような実装との相互作用を考えなければなりません。 年取ったクライアントかサーバが不当にBROADCAST旗を1に設定すると、中継エージェントを従わせると、放送BOOTREPLYは生成するでしょう。
Wimer [Page 17] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[17ページ]RFC1532明確化と拡大
messages to the corresponding client. The BOOTREPLY messages
should still properly reach the client, at the cost of one
(otherwise unnecessary) additional broadcast. This, however,
is no worse than a server or relay agent which always
broadcasts its BOOTREPLY messages.
対応するクライアントへのメッセージ。 BOOTREPLYメッセージは1つの(そうでなければ、不要)の追加放送の費用でまだ適切にクライアントに届いているべきです。 しかしながら、これはサーバか中継エージェントほど悪くはありません(いつもBOOTREPLYメッセージを放送します)。
Older client or server implementations which accidentally set
the BROADCAST flag SHOULD be corrected to properly comply with
this newer specification.
偶然BROADCASTを設定するより年取ったクライアントかサーバ実装がSHOULDに旗を揚げさせます。適切にこのより新しい仕様に従うために、修正されます。
All BOOTP fields MUST be preserved intact. The relay agent
MUST NOT modify any BOOTP field of the BOOTREPLY message when
relaying it to the client.
完全な状態ですべてのBOOTP分野を保持しなければなりません。 クライアントにそれをリレーするとき、中継エージェントはBOOTREPLYメッセージのどんなBOOTP分野も変更してはいけません。
The reply MUST have its UDP destination port set to BOOTPC
(68).
回答で、BOOTPC(68)にUDP仕向港を設定しなければなりません。
If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is
non-zero), the checksum must be recalculated before
transmitting the reply.
BOOTREPLYにUDPチェックサムがあるなら(すなわち、UDPチェックサムは非ゼロです)、回答を伝える前に、チェックサムについて再計算しなければなりません。
5. BOOTP Server Behavior
5. BOOTPサーバの振舞い
This section provides clarifications on the behavior of BOOTP servers.
このセクションはBOOTPサーバの働きのときに明確化を提供します。
5.1 Reception of BOOTREQUEST Messages
5.1 BOOTREQUESTメッセージのレセプション
All received UDP messages whose UDP destination port number is BOOTPS (67) are considered for processing by the BOOTP server.
UDP目的地ポートナンバーがBOOTPS(67)であるすべての受信されたUDPメッセージが処理のためにBOOTPサーバによって考えられます。
Hosts and routers are usually required to silently discard incoming datagrams containing illegal IP source addresses. This is generally known as "Martian address filtering." One of these illegal addresses is 0.0.0.0 (or actually anything on network 0). However, hosts or routers which support a BOOTP server MUST accept for local delivery to the server BOOTREQUEST messages whose IP source address is 0.0.0.0. BOOTREQUEST messages from legal IP source addresses MUST also be accepted.
通常、ホストとルータが、静かに不法なIPソースアドレスを含む受信データグラムを捨てるのに必要です。 一般に、これは「火星のアドレスフィルタリング」として知られています。 これらの不法なアドレスの1つはそうです。0.0 .0 .0 (実際にネットワーク0の何でも。) しかしながら、BOOTPサーバをサポートするホストかルータが地方の配送のためにIPソースアドレスがあるサーバBOOTREQUESTメッセージに受け入れなければなりません。0.0 .0 .0。 また、法的なIPソースアドレスからのBOOTREQUESTメッセージを受け入れなければなりません。
A BOOTP server MUST silently discard any received UDP messages whose UDP destination port number is BOOTPC (68).
BOOTPサーバは静かに、UDP目的地ポートナンバーがBOOTPC(68)であるどんな受信されたUDPメッセージも捨てなければなりません。
DISCUSSION:
議論:
There should be no need for a BOOTP server to process messages
addressed to the BOOTPC port. Careful reading of the original
BOOTP specification [1] will show this.
BOOTPサーバがBOOTPCポートに扱われたメッセージを処理する必要は全くあるべきではありません。 当初のBOOTP仕様[1]の熟読はこれを示すでしょう。
Wimer [Page 18] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[18ページ]RFC1532明確化と拡大
The consistency checks specified in Section 2.1 SHOULD be
performed by the BOOTP server. BOOTP messages not meeting
these consistency checks MUST be silently discarded.
一貫性はセクション2.1 SHOULDで指定されていた状態でチェックします。BOOTPサーバによって実行されてください。静かに一貫性がチェックするこれらに会わないBOOTPメッセージを捨てなければなりません。
5.2 Use of the 'secs' field
5.2 'secs'分野の使用
When the BOOTP server receives a BOOTREQUEST message, it MAY use the value of the 'secs' (seconds since client began booting) field of the request as a factor in deciding whether and/or how to reply to the request.
BOOTPサーバがBOOTREQUESTメッセージを受け取るとき、それは答えて要求に答える方法を決める要素として要求の'secs'(クライアントがブートし始めて以来の秒)分野の値を使用するかもしれません。
DISCUSSION:
議論:
To date, this feature of the BOOTP protocol has not necessarily
been shown to be useful. See Section 3.2 for a discussion.
これまで、BOOTPプロトコルのこの特徴は、役に立つように必ず示されるというわけではありませんでした。 議論に関してセクション3.2を見てください。
5.3 Use of the 'ciaddr' field
5.3 'ciaddr'分野の使用
There have been various client interpretations of the 'ciaddr' field for which Section 3.3 should be consulted. A BOOTP server SHOULD be prepared to deal with these varying interpretations. In general, the client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen' fields, and probably other information (perhaps in the 'file' and respond to a given client.
セクション3.3が相談されるべきである'ciaddr'分野の様々なクライアント解釈がありました。 BOOTPサーバSHOULD、解釈を変えながらこれらに対処するように用意してください。 一般に、クライアント。 そして、'ciaddr'、'chaddr'、'htype'、および'hlen'分野のコンテンツ、およびたぶん他の情報、(恐らく'ファイル'、与えられたクライアントに応じてください。
BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message SHOULD exactly match the contents of 'ciaddr' in the corresponding BOOTREQUEST message.
BOOTPサーバSHOULDはBOOTREPLYメッセージの'ciaddr'分野のコンテンツを保存します。 SHOULDがまさに対応するBOOTREQUESTメッセージで'ciaddr'のコンテンツに合っているというBOOTREPLYメッセージの'ciaddr'のコンテンツ。
DISCUSSION:
議論:
It has been suggested that a client may wish to use the contents of indeed intended for it.
クライアントが本当に、それのために意図していることのコンテンツを使用したがっているかもしれないことが提案されました。
5.4 Strategy for Delivery of BOOTREPLY Messages
5.4 BOOTREPLYメッセージの配送のための戦略
Once the BOOTP server has created an appropriate BOOTREPLY message, that BOOTREPLY message must be properly delivered to the client.
BOOTPサーバがいったん適切なBOOTREPLYメッセージを作成すると、適切にそのBOOTREPLYメッセージをクライアントに提供しなければなりません。
The server SHOULD first check the 'ciaddr' field. If the 'ciaddr' field is non-zero, the BOOTREPLY message SHOULD be sent as an IP unicast to the IP address identified in the 'ciaddr' field. The UDP destination port MUST be set to BOOTPC (68). However, the server MUST be aware of the problems identified in Section 3.3. The server MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr' field contains 0.0.0.0 (and thus continue with the rest of the delivery algorithm below).
サーバSHOULDは最初に、'ciaddr'分野をチェックします。 'ciaddr'であるなら、分野は非ゼロです、BOOTREPLYメッセージSHOULD。IPユニキャストとして、'ciaddr'分野で特定されたIPアドレスに送ってください。 BOOTPC(68)にUDP仕向港を設定しなければなりません。 しかしながら、サーバはセクション3.3で特定された問題を意識しているに違いありません。 サーバは、まるで'ciaddr'分野が0.0を含んでいるかのように'ciaddr'分野と行為を無視するのを選ぶかもしれません。.0 .0 (その結果、以下の配送アルゴリズムの残りを続行してください。)
Wimer [Page 19] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[19ページ]RFC1532明確化と拡大
The server SHOULD next check the 'giaddr' field. If this field is non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to the IP address identified in the 'giaddr' field. The UDP destination port MUST be set to BOOTPS (67). This action will deliver the BOOTREPLY message directly to the BOOTP relay agent closest to the client; the relay agent will then perform the final delivery to the client. If the BOOTP server has prior knowledge that a particular client cannot receive unicast BOOTREPLY messages (e.g., the network manager has explicitly configured the server with such knowledge), the server MAY set the newly-defined BROADCAST flag to indicate that relay agents SHOULD broadcast the BOOTREPLY message to the client. Otherwise, the server MUST preserve the state of the BROADCAST flag so that the relay agent can correctly act upon it.
次のサーバSHOULDは'giaddr'分野をチェックします。 この分野が非ゼロであるなら、IPアドレスへのIPユニキャストが'giaddr'分野で特定したようにサーバSHOULDはBOOTREPLYを送ります。 BOOTPS(67)にUDP仕向港を設定しなければなりません。 この動作はクライアントの最も近くで直接BOOTP中継エージェントにBOOTREPLYメッセージを提供するでしょう。 そして、中継エージェントは最終的な配送をクライアントに実行するでしょう。 BOOTPサーバに特定のクライアントがユニキャストBOOTREPLYメッセージを受け取ることができないという(例えば、ネットワークマネージャはそのような知識で明らかにサーバを構成しました)先の知識があるなら、サーバは、新たに定義されたBROADCAST旗に中継エージェントSHOULDがBOOTREPLYメッセージをクライアントに放送するのを示すように設定するかもしれません。 さもなければ、サーバは、中継エージェントが正しくそれに作用できるように、BROADCAST旗の状態を保持しなければなりません。
If the 'giaddr' field is set to 0.0.0.0, then the client resides on one of the same networks as the BOOTP server. The server SHOULD examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and 4.1.2 for more information). If this flag is set to 1 or the server has prior knowledge that the client is unable to receive unicast BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using the IP limited broadcast address 255.255.255.255 as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST flag is cleared (0), the reply SHOULD be sent as an IP unicast to the IP address specified by the field. If unicasting is not possible, the reply MAY be sent as a broadcast in which case it SHOULD be sent to the link- layer broadcast address using the IP limited broadcast address 255.255.255.255 as the IP destination address. In any case, the UDP destination port MUST be set to BOOTPC (68).
.0、次に、クライアントはBOOTPサーバと同じネットワークの1つに住んでいます。0.0へのセットが'giaddr'分野であるなら.0である、サーバSHOULDが新たに定義されたBROADCAST旗を調べる、(セクション2.2、3.1 .1と4.1を見てください、詳しい情報のための.2) 1かサーバにこの旗を設定するならIPを使用するIP放送が放送演説を制限したので、クライアントがユニキャストBOOTREPLYメッセージ、回答SHOULDを受け取ることができないという先の知識を送った、255.255、.255、.255、受信者IPアドレスとリンクレイヤとして、リンクレイヤ送付先アドレスとしてのアドレスを放送してください。 BROADCAST旗がきれいにされる、(0)、回答SHOULD、IPアドレスへのIPユニキャストが分野のそばで指定したように、送ってください。 unicastingが可能でないなら、回答が可能である、どれがそれをケースに入れるかでaがSHOULDを放送するので送って、IPの有限な放送演説を使用することでリンク層の放送アドレスに送ってください、255.255、.255、.255、受信者IPアドレスとして。 どのような場合でも、BOOTPC(68)にUDP仕向港を設定しなければなりません。
DISCUSSION:
議論:
The addition of the BROADCAST flag to the protocol is a
workaround to help promote interoperability with certain client
implementations.
プロトコルへのBROADCAST旗の追加はあるクライアント実装で相互運用性を促進するのを助ける回避策です。
The following table summarizes server delivery decisions for
BOOTREPLY messages based upon information in BOOTREQUEST
messages:
以下のテーブルはBOOTREQUESTメッセージの情報に基づくBOOTREPLYメッセージのためのサーバ配送決定をまとめます:
Wimer [Page 20] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[20ページ]RFC1532明確化と拡大
BOOTREQUEST fields BOOTREPLY values for UDP, IP, link-layer
+-----------------------+-----------------------------------------+
| 'ciaddr' 'giaddr' B | UDP dest IP destination link dest |
+-----------------------+-----------------------------------------+
| non-zero X X | BOOTPC (68) 'ciaddr' normal |
| 0.0.0.0 non-zero X | BOOTPS (67) 'giaddr' normal |
| 0.0.0.0 0.0.0.0 0 | BOOTPC (68) 'yiaddr' 'chaddr' |
| 0.0.0.0 0.0.0.0 1 | BOOTPC (68) 255.255.255.255 broadcast |
+-----------------------+-----------------------------------------+
BOOTREQUESTはUDP、IPのためにBOOTREPLY値をさばいて、リンクレイヤは+です。-----------------------+-----------------------------------------+ | 'ciaddr''giaddr'B| UDP dest IPの目的地リンクdest| +-----------------------+-----------------------------------------+ | 非ゼロX X| BOOTPC(68)'ciaddr'標準| | 0.0.0.0 非ゼロX| BOOTPS(67)'giaddr'標準| | 0.0.0.0 0.0.0.0 0 | BOOTPC(68)'yiaddr''chaddr'| | 0.0.0.0 0.0.0.0 1 | .255が放送するBOOTPC(68)255.255.255| +-----------------------+-----------------------------------------+
B = BROADCAST flag
B=BROADCAST旗
X = Don't care
X=は気にかけられません。
normal = determine from the given IP destination using normal
IP routing mechanisms and/or ARP as for any other
normal datagram
標準=はいかなる他の正常なデータグラムのようにも与えられたIPの目的地の使用の正常なIPからルーティングメカニズム、そして/または、ARPを決定します。
Acknowledgements
承認
The author would like to thank Gary Malkin for his contribution of the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve Deering for his observations on the problems associated with the 'giaddr' field.
作者は'giaddr'分野に関連している問題で彼の「IEEE802.5トークンリングネットワークの上のBOOTP」セクションの貢献のためのゲーリー・マルキン、および彼の観測のためのスティーブ・デアリングに感謝したがっています。
Ralph Droms and the many members of the IETF Dynamic Host Configuration and Router Requirements working groups provided ideas for this memo as well as encouragement to write it.
奨励と同様にこのメモがそれを書くように、ラルフDromsとIETF Dynamic Host ConfigurationとRouter Requirementsワーキンググループの多くのメンバーが考えを提供しました。
Philip Almquist and David Piscitello offered many helpful suggestions for improving the clarity, accuracy, and organization of this memo. These contributions are graciously acknowledged.
フィリップAlmquistとデヴィッドPiscitelloは、このメモの明快、精度、および組織を改良するために多くの役立つ提案を提供しました。 これらの貢献は丁重に承諾されます。
References
参照
[1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford University and Sun Microsystems, September 1985.
[1] 耕地、B.とJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とRFC951とスタンフォード大学とサン・マイクロシステムズ、1985年9月。
[2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
USC/Information Sciences Institute, August 1993. This RFC is
occasionally reissued with a new number. Please be sure to
consult the latest version.
[2] レイノルズ、J.、「BOOTP売り主情報拡張子」、USC/情報科学が1993年8月に設けるRFC1497。 このRFCは時折新しい数で再発行されます。 最新版に必ず相談してください。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
[3]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1531、Bucknell大学、1993年10月。
[4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
RFC 826, MIT, November 1982.
[4] プラマー、D.、「イーサネットアドレス解決プロトコル」、STD37、RFC826、MIT、1982年11月。
Wimer [Page 21] RFC 1532 Clarifications and Extensions for BOOTP October 1993
BOOTP1993年10月のためのWimer[21ページ]RFC1532明確化と拡大
[5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[5] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、ゼロックスPARC、1991年9月。
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July, 1992. This RFC is
periodically reissued with a new number. Please be sure to
consult the latest version.
[6] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。 このRFCは定期的に新しい数で再発行されます。 最新版に必ず相談してください。
Security Considerations
セキュリティ問題
There are many factors which make BOOTP in its current form quite insecure. BOOTP is built directly upon UDP and IP which are as yet inherently insecure themselves. Furthermore, BOOTP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. This makes it difficult to provide any form of reasonable authentication between servers and clients.
現在のフォームでのBOOTPをかなり不安定にする多くの要素があります。 BOOTPは直接本来まだ自分たちで不安定なUDPとIPに造られます。 その上、一般に、BOOTPがリモートな、そして/または、ディスクレスなホストのメインテナンスをより簡単にすることを意図します。 恐らく不可能でない間、パスワードかキーでそのようなホストを構成するのは、難しくて、不便であるかもしれません。 これで、どんな形式の合理的な認証もサーバとクライアントの間に提供するのは難しくなります。
Unauthorized BOOTP servers may easily be set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this "seed" mis-information is planted, an attacker can further compromise the affected systems.
権限のないBOOTPサーバは容易にセットアップされるかもしれません。 そのようなサーバは、次に、不正確であるように誤って潜在的に破壊的な情報をクライアントに送るか、またはIPアドレス、不正確なルーティング情報(パロディールータなどを含んでいる)、不正確なドメインネームサーバアドレス(パロディーネームサーバなどの)などをコピーできます。 明確に、この「種子」誤伝がいったん植わるようになると、攻撃者はさらに影響を受けるシステムに感染することができます。
Unauthorized BOOTP relay agents may present some of the same problems as unauthorized BOOTP servers.
権限のないBOOTP中継エージェントは権限のないBOOTPサーバと同じ問題のいくつかを提示するかもしれません。
Malicious BOOTP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.
悪意があるBOOTPクライアントは、正統のクライアントのふりをして、それらの正統のクライアントのために意図する情報を検索できました。 リソースの動的割当てが使用されているところでは、悪意があるクライアントはすべてのリソースのそれ自体に代金を請求することができました、その結果、正統のクライアントに対してリソースを否定します。
Author's Address
作者のアドレス
Walt Wimer Network Development Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3890
フォーブズ・Avenueピッツバーグ、ウォルトWimerネットワーク開発カーネギーメロン大学5000PA15213-3890
Phone: (412) 268-6252 EMail: Walter.Wimer@CMU.EDU
以下に電話をしてください。 (412) 268-6252 メールしてください: Walter.Wimer@CMU.EDU
Wimer [Page 22]
Wimer[22ページ]
一覧
スポンサーリンク
