RFC5071 日本語訳
5071 Dynamic Host Configuration Protocol Options Used by PXELINUX. D.Hankins. December 2007. (Format: TXT=26777 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Hankins Request for Comments: 5071 ISC Category: Informational December 2007
コメントを求めるワーキンググループD.ハンキンズの要求をネットワークでつないでください: 5071年のISCカテゴリ: 情報の2007年12月
Dynamic Host Configuration Protocol Options Used by PXELINUX
PXELINUXによって使用されたDynamic Host Configuration Protocolオプション
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211.
このドキュメントは208-211からのいくつかのDHCP Option Codes付番のPXELINUXによる使用について説明します。
Hankins Informational [Page 1] RFC 5071 PXELINUX Options December 2007
[1ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 5
4. Configuration File Option . . . . . . . . . . . . . . . . . . 5
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 6
4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6
5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 8
5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8
6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 10
6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10
7. Specification Conformance . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 魔法のオプション. . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1。 記述. . . . . . . . . . . . . . . . . . . . . . . 4 3.2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . 5 3.3。 適用性. . . . . . . . . . . . . . . . . . . . . . 5 3.4。 RFC3942.5 4への応答。 構成ファイルオプション. . . . . . . . . . . . . . . . . . 5 4.1。 記述. . . . . . . . . . . . . . . . . . . . . . . 5 4.2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . 6 4.3。 適用性. . . . . . . . . . . . . . . . . . . . . . 6 4.4。 RFC3942.64.5への応答。 クライアントとサーバのふるまい. . . . . . . . . . . . . . . 6 5。 経路接頭語オプション. . . . . . . . . . . . . . . . . . . . . . 7 5.1。 記述. . . . . . . . . . . . . . . . . . . . . . . 7 5.2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . 7 5.3。 適用性. . . . . . . . . . . . . . . . . . . . . . 7 5.4。 RFC3942.85.5への応答。 クライアントとサーバのふるまい. . . . . . . . . . . . . . . 8 6。 時間オプション. . . . . . . . . . . . . . . . . . . . . . 9 6.1をリブートしてください。 記述. . . . . . . . . . . . . . . . . . . . . . . 9 6.2。 パケット・フォーマット. . . . . . . . . . . . . . . . . . . . . . 9 6.3。 適用性. . . . . . . . . . . . . . . . . . . . . . 10 6.4。 RFC3942.106.5への応答。 クライアントとサーバのふるまい. . . . . . . . . . . . . . . 10 7。 仕様順応. . . . . . . . . . . . . . . . . . 11 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 11 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 12 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 12
Hankins Informational [Page 2] RFC 5071 PXELINUX Options December 2007
[2ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
1. Introduction
1. 序論
PXE, the Preboot eXecution Environment, is a first-stage network bootstrap agent. PXE is loaded out of firmware on the client host, and performs DHCP [3] queries to obtain an IP address.
PXE(Preboot eXecution Environment)による第一段階ネットワークがエージェントを独力で進むということです。 PXEは、クライアントホストに関するファームウェアからロードされて、IPアドレスを得るためにDHCP[3]質問を実行します。
Once on the network, it loads a second-stage bootstrap agent as configured by DHCP header and option contents.
ネットワークでは、一度、それは2番目のステージがDHCPヘッダーによって構成されて、エージェントを独力で進んで、コンテンツをゆだねるaをロードします。
PXELINUX is one such second-stage bootstrap agent. Once PXE has passed execution to it, PXELINUX seeks its configuration from a cache of DHCP options supplied to the PXE first-stage agent, and then takes action based upon those options.
PXELINUXはそのようなステージの2番目の1つにエージェントを独力で進むことです。 一度、PXEが実行をそれに通過したことがあって、PXELINUXはPXE第一段階のエージェントに提供されたDHCPオプションのキャッシュから構成を求めて、次に、それらのオプションに基づく行動を取ります。
Most frequently, this implies loading via Trivial File Transfer Protocol (TFTP) [6] one or more images that are decompressed into memory, then executed to pass execution to the final Host Operating System.
最も頻繁に、これはメモリに減圧されて、次に最終的なHost Operating Systemに実行を通過するために実行されるより多くのトリビアル・ファイル転送プロトコル(TFTP)[6]1イメージでローディングを含意します。
PXELINUX uses DHCP options 208-211 to govern parts of this bootstrap process, but these options are not requested by the PXE DHCP client at the time it acquires its lease. At that time, the PXE bootloader has no knowledge that PXELINUX is going to be in use, and even so, would have no way to know what option(s) PXELINUX might digest. Local installations that serve this PXELINUX image to its clients must also configure their DHCP servers to provide these options even though they are not on the DHCP Parameter Request List [4].
この部品を治めるPXELINUX用途DHCPオプション208-211はプロセスを独力で進みますが、リースを取得するとき、これらのオプションはPXE DHCPクライアントによって要求されません。 その時、PXEブートローダーには、PXELINUXが使用中になって、たとえそうだとしても、PXELINUXがどんなオプションを読みこなすかもしれないかを知る方法を全く持っていないだろうという知識が全くありません。 また、このPXELINUXイメージをクライアントにサービスする現地搬入は、それらがDHCP Parameter Request List[4]にありませんが、これらのオプションを提供するために彼らのDHCPサーバを構成しなければなりません。
These options are:
これらのオプションは以下の通りです。
o "MAGIC" - 208 - An option whose presence and content verifies to
the PXELINUX bootloader that the options numbered 209-211 are for
the purpose as described herein.
o 「マジック」--208--存在と内容が209-211に付番されたオプションがここに説明されるように目的のためのものであることをPXELINUXブートローダーに確かめるオプション。
o "ConfigFile" - 209 - Configures the path/filename component of the
configuration file's location, which this bootloader should use to
configure itself.
o "ConfigFile"(209)は構成ファイルの位置の経路/ファイル名コンポーネントを構成します。(このブートローダーは、それ自体を構成するのに位置を使用するべきです)。
o "PathPrefix" - 210 - Configures a value to be prepended to the
ConfigFile to discern the directory location of the file.
o "PathPrefix"(210)は、ファイルのディレクトリ位置について明察するためにConfigFileにprependedされるように値を構成します。
o "RebootTime" - 211 - Configures a timeout after which the
bootstrap program will reboot the system (most likely returning it
to PXE).
o "RebootTime"(211)はローディング・プログラムがシステムをリブートするタイムアウトを構成します(たぶんそれをPXEに返して)。
Historically, these option codes numbering from 208-211 were designated 'Site Local', but after publication of RFC3942 [8], they were made available for allocation as new standard DHCP options.
歴史的に、'サイトLocal'に208-211から付番するこれらのオプションコードを指定しましたが、RFC3942[8]の公表の後に、それらを新しい標準のDHCPオプションとして配分に利用可能にしました。
Hankins Informational [Page 3] RFC 5071 PXELINUX Options December 2007
[3ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
This document marks these codes as assigned.
このドキュメントは割り当てられるようにこれらのコードをマークします。
This direct assignment of option code values in the option definitions below is unusual as it is not mentioned in DHCP Option Code assignment guidelines [5]. This document's Option Code assignments are done within RFC 3942's provisions for documenting prior use of option codes within the new range (128-223 inclusive).
それがDHCP Option Code課題ガイドライン[5]で言及されないように以下でのオプション定義における、オプションコード値のこのダイレクト課題は珍しいです。 新しい範囲の中に(128-223 包括的)でオプションコードの先の使用を記録するためのRFC3942の条項の中でこのドキュメントのOption Code課題をします。
2. Terminology
2. 用語
o "first-stage bootloader" - Although a given bootloading order may
have many stages, such as where a BIOS boots a DOS Boot Disk,
which then loads a PXE executable, it is, in this example, only
the PXE executable that this document describes as the "first-
stage bootloader" -- in essence, this is the first stage of
booting at which DHCP is involved.
o 「第一段階ブートローダー」--与えられたbootloadingオーダーには、BIOSが実行可能なPXEがその時ロードするDOS Boot Diskをブートするところなどの多くのステージがあるかもしれませんが、この例では、唯一のそれはこのドキュメントが「最初のステージブートローダー」を記述する実行可能なPXEです--本質では、これはDHCPがかかわる穂ばらみの第一段階です。
o "second-stage bootloader" - This describes a program loaded by the
first-stage bootloader at the behest of the DHCP server.
o 「2番目のステージブートローダー」--これはDHCPサーバの命令のときに第一段階ブートローダーによってロードされたプログラムについて説明します。
o "bootloader" and "network bootstrap agent" - These are synonyms,
excepting that "bootloader" is intentionally vague in that its
next form of bootstrapping may not in fact involve network
resources.
o 「ブートローダー」と「ネットワークはエージェントを独力で進みます」--これらが同義語である、次のフォームのブートストラップ法が事実上ネットワーク資源を伴わないかもしれないので、その「ブートローダー」を除くのは故意にあいまいです。
The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in RFC 2119 [2].
そして、キーワード「5月」、“MUST"、「必須NOT」、“SHOULD"、「」 これが記録するコネはRFC2119[2]で説明されるように解釈されないべきであることですか?
3. MAGIC Option
3. 魔法のオプション
3.1. Description
3.1. 記述
If this option is provided to the PXE bootloader, then the value is checked by PXELINUX to match the octet string f1:00:74:7e. If this matches, then PXELINUX bootloaders will also consume options 209-211, as described below. Otherwise, they are ignored.
このオプションをPXEブートローダーに提供するなら、PXELINUXは八重奏ストリングf1を合わせるために値をチェックします: 00:74:7e。 また、これが合っていると、PXELINUXブートローダーは以下で説明されるようにオプション209-211を消費するでしょう。 さもなければ、それらは無視されます。
This measure was intended to ensure that, as the 'Site Local' option space is not allocated from a central authority, no conflict would result in a PXELINUX bootloader improperly digesting options intended for another purpose.
この測定が、'サイトLocal'オプションスペースが主要な権威から割り当てられないのに従ってどんな闘争も不適切に別の目的のために意図するオプションを読みこなすPXELINUXブートローダーをもたらさないのを保証することを意図しました。
Hankins Informational [Page 4] RFC 5071 PXELINUX Options December 2007
[4ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
3.2. Packet Format
3.2. パケット・フォーマット
The MAGIC Option format is as follows:
マジックOption形式は以下の通りです:
Code Length m1 m2 m3 m4
+--------+--------+--------+--------+--------+--------+
| 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E |
+--------+--------+--------+--------+--------+--------+
コードLength m1 m2 m3 m4+--------+--------+--------+--------+--------+--------+ | 208 | 4 | 0xF1| 0×00| 0×74| 0x7E| +--------+--------+--------+--------+--------+--------+
The code for this option is 208. The length is always four.
このオプションのためのコードは208です。 いつも長さは4です。
3.3. Applicability
3.3. 適用性
This option is absolutely inapplicable to any other purpose.
このオプションはいかなる他の目的にも絶対に不適当です。
3.4. Response to RFC 3942
3.4. RFC3942への応答
The option code 208 will be adopted for this purpose and immediately deprecated. Future standards action may return this option to an available status should it be necessary.
オプションコード208は、すぐに、この目的のために採用されていて推奨しなくなるでしょう。 それが必要であるなら動作が利用可能な状態へのこのオプションを返すかもしれない将来の規格。
A collision of the use of this option is harmless (at least from PXELINUX' point of view) by design: if it does not match the aforementioned magic value, the PXELINUX bootloader will take no special action.
'このオプションの使用の衝突は故意に無害です(少なくともPXELINUX'観点からの): 前述の魔法の値を合わせないと、PXELINUXブートローダーはどんな特別な行動も取らないでしょう。
The PXELINUX project will deprecate the use of this option; future versions of the software will not evaluate its contents.
PXELINUXプロジェクトはこのオプションの使用を非難するでしょう。 ソフトウェアの将来のバージョンはコンテンツを評価しないでしょう。
It is reasonable to utilize this option code for another purpose, but it is recommended to do this at a later time, given the desire to avoid potential collisions in legacy user bases.
別の目的にこのオプションコードを利用するのが妥当ですが、後でこれをするのはお勧めです、レガシーユーザベースの中で潜在的衝突を避ける願望を考えて。
4. Configuration File Option
4. 構成ファイルオプション
4.1. Description
4.1. 記述
Once the PXELINUX executable has been entered from the PXE bootloader, it evaluates this option and loads a file of that name via TFTP. The contents of this file serve to configure PXELINUX in its next stage of bootloading (specifying boot image names, locations, boot-time flags, text to present the user in menu selections, etc).
実行可能なPXELINUXがPXEブートローダーからいったん入られると、それは、TFTPを通してこのオプションを評価して、その名前のファイルをロードします。 このファイルの中身は、次のステージのbootloadingでPXELINUXを構成するのに役立ちます(ブーツイメージ名、位置、ブート時間旗、メニュー選択でユーザを紹介するテキストなどを指定して)。
In the absence of this option, the PXELINUX agent will search the TFTP server (as determined by PXE prior to this stage) for a config file of several default names.
このオプションがないとき、PXELINUXエージェントはいくつかのデフォルト名のコンフィグファイルのために、TFTPサーバ(この段階の前でPXEによって決定されるように)を捜すでしょう。
Hankins Informational [Page 5] RFC 5071 PXELINUX Options December 2007
[5ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
4.2. Packet Format
4.2. パケット・フォーマット
The Configuration File Option format is as follows:
Configuration File Option形式は以下の通りです:
Code Length Config-file...
+--------+--------+--------+--------+--------+--------+
| 209 | n | c1 | c2 | ... | c(n) |
+--------+--------+--------+--------+--------+--------+
長さのコンフィグファイルをコード化してください… +--------+--------+--------+--------+--------+--------+ | 209 | n| c1| c2| ... | c(n)| +--------+--------+--------+--------+--------+--------+
The code for this option is 209. The Config-file (c1..c(n)) is an NVT-ASCII [1] printable string; it is not terminated by a zero or any other value.
このオプションのためのコードは209です。 Configファイルしてください。(c1..c(n))はNVT-ASCIIの[1]の印刷可能なストリングです。 それはゼロかいかなる他の値によっても終えられません。
4.3. Applicability
4.3. 適用性
Any bootloader, PXE or otherwise, that makes use of a separate configuration file rather than containing all configurations within DHCP options (which may be impossible due to the limited space available for DHCP options) may conceivably make use of this option.
どんなブートローダーかPXEかそうでなければ、それもDHCPオプション(DHCPオプションに利用可能な限られたスペースのために不可能であるかもしれない)の中の構成が多分利用するかもしれないすべてを含むよりむしろ別々の構成ファイルの使用をこのオプションにします。
4.4. Response to RFC 3942
4.4. RFC3942への応答
The code 209 will be adopted for this purpose.
コード209はこのために採用されるでしょう。
4.5. Client and Server Behaviour
4.5. クライアントとサーバのふるまい
The Config File Option MUST be supplied by the DHCP server if it appears on the Parameter Request List, but MUST also be supplied if the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second- stage boot image, which they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if a value of zero length has been configured.
Config File OptionをParameter Request Listに現れるならDHCPサーバから供給しなければなりませんが、また、サーバアドミニストレータが、それが後でクライアントの役に立つと(サーバが彼らがそれを利用するのを知っている2番目のステージブーツイメージを提供するために構成されるのでそのような)信じていたなら、供給しなければなりません。 それのために値を全く構成していないか、またはゼロ・レングスの値を構成したなら、オプションを供給してはいけません。
The DHCP client MUST only cache this option in a location the second- stage bootloader may access.
DHCPクライアントが2番目のステージブートローダーがそうする位置でこのオプションをキャッシュするだけでよい、アクセサリー
The second-stage bootloader MUST, in concert with other DHCP options and fields, use this option's value as a filename to be loaded via TFTP and read for further second-stage-loader-specific configuration parameters. The format and content of such a file is specific to the second-stage bootloader, and as such, is out of scope of this document.
他のDHCPオプションと分野と協力して、2番目のステージブートローダーは、TFTPを通してロードされて、さらなる2番目のステージ荷物を積む人詳細設定パラメータをめざして勉強するのにファイル名としてこのオプションの値を使用しなければなりません。 2番目のステージブートローダー、そのようなものがこのドキュメントの範囲から特定であるようにそのようなファイルの形式と中身は特定です。
Hankins Informational [Page 6] RFC 5071 PXELINUX Options December 2007
[6ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
5. Path Prefix Option
5. 経路接頭語オプション
5.1. Description
5.1. 記述
In PXELINUX' case, it is often the case that several different environments would have the same TFTP path prefix, but would have different filenames (for example: hosts' bootloader images and config files may be kept in a directory structure derived from their Media Access Control (MAC) address). Consequently, it was deemed worthwhile to deliver a TFTP path prefix configuration option, so that these two things could be configured separately in a DHCP Server configuration: the prefix and the possibly host-specific file location.
'PXELINUX'ケース、いくつかの異なった環境には、しばしば、同じTFTP経路接頭語を持っているでしょうが、異なったファイル名(: 例えば'のブートローダーイメージとコンフィグファイルが保たれるかもしれないディレクトリ構造がそれらのメディアAccess Control(MAC)アドレスから引き出したホスト)があるでしょう。 その結果、それはTFTP経路接頭語設定オプションを提供するために価値があると考えられました、別々にDHCP Server構成でこれらの2つのものを構成できるように: 接頭語とことによるとホスト特有のファイルの位置。
The actual filename that PXELINUX requests from its TFTP server is derived by prepending this value to the Config File Option above. Once this config file is loaded and during processing, any TFTP file paths specified within it are similarly processed -- prepending the contents of this option.
PXELINUXがTFTPサーバから要求する実際のファイル名は、上のConfig File Optionにこの値をprependingすることによって、引き出されます。 一度、このコンフィグファイルはロードされています、そして、処理の間、このオプションのコンテンツをprependingして、それの中で指定されたどんなTFTPファイル経路も同様に処理されます。
5.2. Packet Format
5.2. パケット・フォーマット
The Path Prefix Option format is as follows:
Path Prefix Option形式は以下の通りです:
Code Length Path-Prefix...
+--------+--------+--------+--------+--------+--------+
| 210 | n | p1 | p2 | ... | p(n) |
+--------+--------+--------+--------+--------+--------+
長さの経路接頭語をコード化してください… +--------+--------+--------+--------+--------+--------+ | 210 | n| p1| p2| ... | p(n)| +--------+--------+--------+--------+--------+--------+
The code for this option is 210. The Path Prefix is an NVT-ASCII printable string; it is not terminated by zero or any other value.
このオプションのためのコードは210です。 Path PrefixはNVT-ASCIIの印刷可能なストリングです。 それはゼロかいかなる他の値によっても終えられません。
5.3. Applicability
5.3. 適用性
This option came into existence because server administrators found it useful to configure the prefix and suffix of the config file path separately. A group of different PXE booting clients may use the same path prefix, but different filenames, or vice versa.
サーバアドミニストレータが、別々にコンフィグファイル経路の接頭語と接尾語を構成するのが役に立つのがわかったので、このオプションは生まれました。 異なったPXE穂ばらみクライアントのグループは同じ経路接頭語の、しかし、異なったファイル名を使用するかもしれませんか、逆もまた同様です。
The 'shortcut' this represents is worthwhile, but it is questionable whether that needs to manifest itself on the protocol wire.
これが表す'近道'価値がありますが、それが、プロトコルワイヤの上に現れる必要があるかどうかが、疑わしいです。
Hankins Informational [Page 7] RFC 5071 PXELINUX Options December 2007
[7ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
It only becomes interesting from a protocol standpoint if other options are adopted that prefix this value as well -- performing a kind of string compression is highly beneficial to the limited available DHCP option space.
別の選択肢が採用される場合にだけ、また、この値を前に置いてください--一種のストリング圧縮を実行するのが限られた利用可能なDHCPオプションスペースに非常に有益であることはプロトコル見地からおもしろくなります。
But it's clearly inapplicable to any current use of, e.g., the FILENAME header contents or the DHCP Boot File Name option (#67). Use of these fields is encoded on firmware of thousands of devices that can't or are not likely to be upgraded. Altering any behaviour here is likely to cause severe compatibility problems.
しかし、それが明確にどんな現在の使用にも不適当である、例えば、FILENAMEヘッダーコンテンツかDHCP Boot File Nameオプション(#67)。 これらの分野の使用は、そうすることができない何千台ものデバイスに関するファームウェアでコード化されそうにはありませんし、アップグレードされそうにはありません。 ここでどんなふるまいも変更するのは厳しい互換性の問題を引き起こしそうです。
Although compression of the TFTP-loaded configuration file contents is not a compelling factor, contrived configurations using these values may also exist: where each of a large variety of different clients load the same configuration file, with the same contents, but due to a differently configured path prefix actually load different images. Whether this sort of use is truly needed remains unproven.
TFTP満載の構成ファイルコンテンツの圧縮は無視できない要素ではありませんが、また、これらの値を使用する人為的な構成は存在するかもしれません: さまざまな異なったクライアント各人が同じコンテンツで同じ構成ファイルをロードしますが、異なって構成された経路接頭語のためロードするところでは、実際に異なったイメージをロードしてください。 本当に、この種類の使用が必要であるかどうかが立証されないままで残っています。
5.4. Response to RFC 3942
5.4. RFC3942への応答
The code 210 will be adopted for this purpose.
コード210はこのために採用されるでしょう。
5.5. Client and Server Behaviour
5.5. クライアントとサーバのふるまい
The Path Prefix option MUST be supplied by the DHCP server if it appears on the Parameter Request List, but MUST also be supplied if the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second- stage boot image that they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if a value of zero length has been configured.
Path PrefixオプションをParameter Request Listに現れるならDHCPサーバから供給しなければなりませんが、また、サーバアドミニストレータが、それが後でクライアントの役に立つと信じていたなら、供給しなければなりません(サーバが2番目のステージブーツイメージにそれを提供するために構成されるので彼らが知っているようにそのようなものはそれを利用するでしょう)。 それのために値を全く構成していないか、またはゼロ・レングスの値を構成したなら、オプションを供給してはいけません。
The DHCP client MUST only cache this option in a location where the second-stage bootloader may access it.
DHCPクライアントは2番目のステージブートローダーがそれにアクセスするかもしれない位置でこのオプションをキャッシュするだけでよいです。
The second-stage bootloader MUST prepend this option's value, if any, to the contents of the ConfigFile option prior to obtaining the resulting value via TFTP, or the default 'Config File Search Path', which the second-stage bootloader iterates in the absence of a Config File Option. The client MAY prepend the value to other configuration directives within that file once it has been loaded. The client MUST NOT prepend this option's value to any other DHCP option contents or field, unless explicitly stated in a document describing that option or field.
2番目のステージブートローダーはどんなでもある、TFTPを通して結果として起こる値を得るか、またはConfig File Optionが不在のとき2番目のステージブートローダーが繰り返すデフォルト'コンフィグFile検索Path'を得る前のConfigFileオプションのコンテンツへのオプションのこのものが評価するprependがそうしなければなりません。 クライアントはそれがいったんロードされるとそれの中の他の構成指示への値がファイルするprependがそうするかもしれません。 クライアントはいかなる他のDHCPオプションコンテンツか分野にもこのオプションの値をprependしてはいけません、そのオプションか分野について説明するドキュメントに明らかに述べられない場合。
Hankins Informational [Page 8] RFC 5071 PXELINUX Options December 2007
[8ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
6. Reboot Time Option
6. 時間オプションをリブートしてください。
6.1. Description
6.1. 記述
Should PXELINUX be executed, and then for some reason, be unable to reach its TFTP server to continue bootstrapping, the client will, by default, reboot itself after 300 seconds have passed. This may be too long, too short, or inappropriate behaviour entirely, depending on the environment.
PXELINUXが実行される、およびそして、何らかの理由であるはずであるなら、独力で進み続けるためにTFTPサーバに達することができません、300秒が経過した後にクライアントがデフォルトでそれ自体をリブートするということになってください。 環境によって、これは完全に長過ぎるか、短過ぎるか、不適当なふるまいであるかもしれません。
By configuring a non-zero value in this option, admins can inform PXELINUX of which specific timeout is desired. The client will reboot itself if it fails to achieve its configured network resources within the specified number of seconds.
このオプションにおける非ゼロ値を構成することによって、アドミンは特定のタイムアウトが望まれているPXELINUXに知らせることができます。 指定された秒数の中で構成されたネットワーク資源を達成しないと、クライアントはそれ自体をリブートするでしょう。
This reboot will run through the system's normal boot-time execution path, most likely leading it back to PXE and therefore PXELINUX. So, in the general case, this is akin to returning the client to the DHCP INIT state.
このリブートはシステムの正常なブート時間実行経路を貫くでしょう、たぶんPXEとしたがって、PXELINUXにそれを返して。 それで、一般的な場合では、これはDHCP INIT状態にクライアントを返すのと同系です。
By configuring zero, the feature is disabled, and instead the client chooses to remove itself from the network and wait indefinitely for operator intervention.
ゼロを構成することによって、特徴は障害があって、クライアントは、代わりに、ネットワークから立ち退いて、オペレータ介入が無期限に待つのを選びます。
It should be stressed that this is in no way related to configuring a lease time. The perceived transition to INIT state is due to client running state -- reinitializing itself -- not due to lease timer activity. That is, it is not safe to assume that a PXELINUX client will abandon its lease when this timer expires.
これがリース時間を構成すると決して関連しないと強調されるべきです。 INIT状態への知覚された変遷はタイマ活動を賃貸するのにおいて当然でないクライアント実行状態(再初期化自体)のためです。 すなわち、このタイマが期限が切れるとPXELINUXクライアントがリースを捨てると仮定するのは安全ではありません。
6.2. Packet Format
6.2. パケット・フォーマット
The Reboot Time Option format is as follows:
Reboot Time Option形式は以下の通りです:
Code Length
+--------+--------+--------+--------+--------+--------+
| 211 | 4 | Reboot Time |
+--------+--------+--------+--------+--------+--------+
コードの長さ+--------+--------+--------+--------+--------+--------+ | 211 | 4 | リブート時間| +--------+--------+--------+--------+--------+--------+
The code for this option is 211. The length is always four. The Reboot Time is a 32-bit (4 byte) integer in network byte order.
このオプションのためのコードは211です。 いつも長さは4です。 Reboot Timeはネットワークバイトオーダーで32ビット(4バイト)の整数です。
Hankins Informational [Page 9] RFC 5071 PXELINUX Options December 2007
[9ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
6.3. Applicability
6.3. 適用性
Any network bootstrap program in any sufficiently complex networking environment could conceivably enter into such a similar condition, either due to having its IP address stolen out from under it by a rogue client on the network, by being moved between networks where its PXE-derived DHCP lease is no longer valid, or any similar means.
どんな十分複雑なネットワーク環境でもどんなネットワークローディング・プログラムも多分そのような類縁疾患に入ることができました、IPアドレスがネットワークの間でそれの下でネットワークの凶暴なクライアント、動かされるのによるPXEによって派生させられたDHCPリースがもうどこで有効でないか、そして、どんな同様の手段からの外にも盗どちらかにされるため。
It seems desirable for any network bootstrap agent to implement an ultimate timeout for it to start over.
どんなネットワークもそれがやり直す究極のタイムアウトを実装するためにエージェントを独力で進むので、それは望ましく思えます。
The client may, for example, get different working configuration parameters from a different DHCP server upon restarting.
例えば、クライアントは異なったDHCPサーバと異なった働く設定パラメータを再開に得るかもしれません。
6.4. Response to RFC 3942
6.4. RFC3942への応答
The code 211 will be adopted for this purpose.
コード211はこのために採用されるでしょう。
6.5. Client and Server Behaviour
6.5. クライアントとサーバのふるまい
The Reboot Time Option MUST be supplied by the DHCP server if it appears on the Parameter Request List, but MUST also be supplied if the server administrator believed it would later be useful to the client (such as because the server is configured to offer a second- stage boot image that they know will make use of it). The option MUST NOT be supplied if no value has been configured for it, or if it contains a value of zero length.
Reboot Time OptionをParameter Request Listに現れるならDHCPサーバから供給しなければなりませんが、また、サーバアドミニストレータが、それが後でクライアントの役に立つと信じていたなら、供給しなければなりません(サーバが2番目のステージブーツイメージにそれを提供するために構成されるので彼らが知っているようにそのようなものはそれを利用するでしょう)。 値が全くそれのために構成されていないか、またはゼロ・レングスの値を含んでいるなら、オプションを供給してはいけません。
The DHCP client MUST only cache this option in a location the second- stage bootloader may access.
DHCPクライアントが2番目のステージブートローダーがそうする位置でこのオプションをキャッシュするだけでよい、アクセサリー
If the value of this option is nonzero, the second-stage bootloader MUST schedule a timeout: after a number of seconds equal to this option's value have passed, the second-stage bootloader MUST reboot the system, ultimately returning the path of execution back to the first-stage bootloader. It MUST NOT reboot the system once the thread of execution has been passed to the host operating system (at which point, this timeout is effectively obviated).
このオプションの値が非零であるなら、2番目のステージブートローダーはタイムアウトの計画をしなければなりません: このオプションの値と等しい何秒も経過した後に、2番目のステージブートローダーはシステムをリブートしなければなりません、結局実行の経路を第一段階ブートローダーに返して戻して。 実行のスレッドがいったんホスト・オペレーティング・システムに通過されると(どのポイントで、事実上、このタイムアウトを取り除くか)、それはシステムをリブートしてはいけません。
If the value of this option is zero, the second-stage bootloader MUST NOT schedule such a timeout at all. Any second-stage bootloader that finds it has encountered excessive timeouts attempting to obtain its host operating system SHOULD disconnect itself from the network to wait for operator intervention, but MAY continue to attempt to acquire the host operating system indefinitely.
このオプションの値がゼロであるなら、2番目のステージブートローダーは全くそのようなタイムアウトの計画をしてはいけません。 それを見つけるどんな2番目のステージブートローダーも、ネットワークから待ちまでホスト・オペレーティング・システムSHOULD分離自体をオペレータ介入に得るのを試みる過度のタイムアウトに遭遇しましたが、ホスト・オペレーティング・システムを無期限に入手するのを試み続けるかもしれません。
Hankins Informational [Page 10] RFC 5071 PXELINUX Options December 2007
[10ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
7. Specification Conformance
7. 仕様順応
To conform to this specification, clients and servers MUST implement the Configuration File, Path Prefix, and Reboot Time options as directed.
この仕様、クライアント、およびサーバに従うのは指示されるとしてConfiguration File、Path Prefix、およびReboot Timeにオプションを実装しなければなりません。
The MAGIC option MAY NOT be implemented, as it has been deprecated.
それが推奨しないときに、マジックオプションは実装されないかもしれません。
8. Security Considerations
8. セキュリティ問題
PXE and PXELINUX allow any entity acting as a DHCP server to execute arbitrary code upon a system. At present, no PXE implementation is known to implement authentication mechanisms [7] so that PXE clients can be sure they are receiving configuration information from the correct, authoritative DHCP server.
PXEとPXELINUXはDHCPサーバとして機能するどんな実体にもシステムの勝手な規準を実行させます。 現在のところ、PXE実装が、全くPXEクライアントが彼らが正しくて、正式のDHCPサーバから設定情報を受け取っているのを確信するように認証機構が[7]であると実装するのが知られません。
The use of TFTP by PXE and PXELINUX also lacks any form of cryptographic signature -- so a 'Man in the Middle' attack may lead to an attacker's code being executed on the client system. Since this is not an encrypted channel, any of the TFTP loaded data may also be exposed (such as in loading a "RAMDISK" image, which contains /etc/passwd or similar information).
また、PXEとPXELINUXによるTFTPの使用はどんな形式の暗号の署名も欠いています--したがって、'Middleの男性'攻撃はクライアントシステムの上で実行される攻撃者のコードにつながるかもしれません。 これが暗号化されたチャンネルでないことで、またロードされたデータが暴露されるかもしれないTFTP(/etc/passwdか同様の情報を含む"RAMDISK"イメージをロードなどなどの)のいずれでもあります。
The use of the Ethernet MAC Address as the client's unique identity may allow an attacker who takes on that identity to gain inappropriate access to a client system's network resources by being given by the DHCP server whatever 'keys' are required, in fact, to be the target system (to boot up as though it were the target).
クライアントのユニークなアイデンティティとしてのイーサネットマックーアドレスの使用で、そのアイデンティティを呈する攻撃者は事実上、目標システム(まるでそれが目標であるかのように起動する)になるのに必要であるいかなる'キー'もDHCPサーバで与えるのによるクライアントシステムのネットワーク資源への不適当なアクセスに獲得できるかもしれません。
Great care should be taken to secure PXE and PXELINUX installations, such as by using IP firewalls, to reduce or eliminate these concerns.
PXEとPXELINUXがインストールであると機密保護するために高度の注意を取るべきです、これらの関心を減少するか、または排除するのにIPファイアウォールを使用するのなどように。
A nearby attacker might feed a "Reboot Time" option value of 1 second to a mass of unsuspecting clients, to effect a Denial Of Service (DoS) upon the DHCP server, but then again it may just as easily supply these clients with rogue second-stage bootloaders that simply transmit a flood of packets.
近い攻撃者はDHCPサーバでDenial Of Service(DoS)に作用するように1の「リブート時間」オプション価値を疑わないクライアントの集団に2番目であるのに食べさせるかもしれませんが、一方、それはただ同じくらい容易に単にパケットの洪水を伝える凶暴な2番目のステージブートローダーをこれらのクライアントに提供するかもしれません。
This document in and by itself provides no security, nor does it impact existing DCHP security as described in RFC 2131 [3].
それ自体とそれ自体でこのドキュメントはセキュリティを全く提供しません、そして、それはRFC2131[3]で説明されるように既存のDCHPセキュリティに影響を与えません。
9. IANA Considerations
9. IANA問題
IANA has done the following:
IANAは以下をしました:
1. Moved DHCPv4 Option code 208 from 'Tentatively Assigned' to
'Assigned', referencing this document. IANA has marked this same
option code, 208, as Deprecated.
1. 動くDHCPv4 Optionが'試験的に208をコード化する、Assigned、''割り当てられたこと'にこのドキュメントに参照をつける。 IANAはDeprecatedとしてこの同じオプションコード、208をマークしました。
Hankins Informational [Page 11] RFC 5071 PXELINUX Options December 2007
[11ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
2. Moved DHCPv4 Option code 209 from 'Tentatively Assigned' to
'Assigned', referencing this document.
2. 動くDHCPv4 Optionが'試験的に209をコード化する、Assigned、''割り当てられたこと'にこのドキュメントに参照をつける。
3. Moved DHCPv4 Option code 210 from 'Tentatively Assigned' to
'Assigned', referencing this document.
3. 動くDHCPv4 Optionが'試験的に210をコード化する、Assigned、''割り当てられたこと'にこのドキュメントに参照をつける。
4. Moved DHCPv4 Option code 211 from 'Tentatively Assigned' to
'Assigned', referencing this document.
4. 動くDHCPv4 Optionが'試験的に211をコード化する、Assigned、''割り当てられたこと'にこのドキュメントに参照をつける。
10. Acknowledgements
10. 承認
These options were designed and implemented for the PXELINUX project by H. Peter Anvin, and he was instrumental in producing this document. Shane Kerr has also provided feedback that has improved this document.
これらのオプションは、PXELINUXプロジェクトのためにH.ピーターAnvinによって設計されて、実装されました、そして、彼はこのドキュメントを製作する際に手段になっていました。 また、シェーン・カーはこのドキュメントを改良したフィードバックを提供しました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, May 1983.
[1] ポステルとJ.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[4] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[5] Droms, R., "Procedures and IANA Guidelines for Definition of New
DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[5] Droms、R.、「新しいDHCPオプションの定義のための手順とIANAガイドラインとメッセージはタイプします」、BCP43、RFC2939、2000年9月。
11.2. Informative References
11.2. 有益な参照
[6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
July 1992.
[6]Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。
[7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[7]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[8] Volz, B., "Reclassifying Dynamic Host Configuration Protocol
version 4 (DHCPv4) Options", RFC 3942, November 2004.
[8] フォルツ、B.、「Dynamic Host Configuration Protocolバージョン4(DHCPv4)オプションに分類し直します」、RFC3942、2004年11月。
Hankins Informational [Page 12] RFC 5071 PXELINUX Options December 2007
[12ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
Author's Address
作者のアドレス
David W. Hankins Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
デヴィッドW.ハンキンズインターネットSystems共同体Inc.950憲章通りカリフォルニア94063レッドウッドシティー(米国)
Phone: +1 650 423 1307 EMail: David_Hankins@isc.org
以下に電話をしてください。 +1 1307年の650 423メール: David_Hankins@isc.org
Hankins Informational [Page 13] RFC 5071 PXELINUX Options December 2007
[13ページ]RFC5071PXELINUXオプション2007年12月の情報のハンキンズ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Hankins Informational [Page 14]
ハンキンズInformationalです。[14ページ]
一覧
スポンサーリンク
