[要約] RFC 5071は、PXELINUXで使用されるDHCPオプションに関する情報を提供する。目的は、ネットワークブートプロトコルの実装者に対して、PXELINUXの動作をサポートするための適切なDHCPオプションの使用方法を示すことである。
Network Working Group D. Hankins
Request for Comments: 5071 ISC
Category: Informational December 2007
Dynamic Host Configuration Protocol Options Used by PXELINUX
pxelinuxが使用する動的ホスト構成プロトコルオプション
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オプションコードのPxelinuxによる使用について説明します。
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
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は、1段階のネットワークブートストラップエージェントです。PXEはクライアントホストのファームウェアからロードされ、DHCP [3]クエリを実行してIPアドレスを取得します。
Once on the network, it loads a second-stage bootstrap agent as configured by DHCP header and option contents.
ネットワークに着くと、DHCPヘッダーとオプションコンテンツで構成されているように、2段階のブートストラップエージェントをロードします。
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.
最も頻繁に、これは、些細なファイル転送プロトコル（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パラメーターリクエストリストに載っていない場合でも、これらのオプションを提供するようにDHCPサーバーを構成する必要があります[4]。
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 「Magic」-208-存在とコンテンツがPxelinuxブートローダーに検証されているオプションは、209-211に記載されているオプションが目的のためです。
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に加えられる値を構成します。
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.
歴史的に、208-211の番号付けされたこれらのオプションコードは「サイトローカル」と指定されていましたが、RFC3942 [8]の公開後、新しい標準DHCPオプションとして割り当てに利用可能になりました。
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オプションコード割り当てガイドライン[5]で言及されていないため、珍しいことです。このドキュメントのオプションコード割り当ては、新しい範囲内でオプションコードを事前に使用することを文書化するためのRFC 3942の規定内で行われます（128-223包括的）。
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 「ファーストステージブートローダー」 - 特定のブートロード順序には、BIOSがDOSブートディスクをブートし、PXE実行可能ファイルをロードするなど、多くの段階がある場合がありますが、この例では、このドキュメントが説明している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サーバーの要請で1段階のブートローダーによってロードされたプログラムを説明しています。
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].
このドキュメントの「may」、「must」、「must」、「must」、 "nut"、 "not" not "は、RFC 2119 [2]に記載されているように解釈されるべきキーワードは解釈されます。
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によってチェックされ、Octet String 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.
この措置は、「サイトローカル」オプションスペースが中央当局から割り当てられていないため、Pxelinuxブートローダーが別の目的のために意図されたオプションを不適切に消化することをもたらさないことを保証することを目的としています。
The MAGIC Option format is as follows:
魔法のオプション形式は次のとおりです。
Code Length m1 m2 m3 m4
+--------+--------+--------+--------+--------+--------+
| 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E |
+--------+--------+--------+--------+--------+--------+
The code for this option is 208. The length is always four.
このオプションのコードは208です。長さは常に4です。
This option is absolutely inapplicable to any other purpose.
このオプションは、他の目的には絶対に適用できません。
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.
別の目的でこのオプションコードを利用することは合理的ですが、レガシーユーザーベースでの潜在的な衝突を回避したいという願望を考えると、後でこれを行うことをお勧めします。
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を介してその名前のファイルをロードします。このファイルの内容は、ブートロードの次の段階で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によって決定されます）を検索します。
The Configuration File Option format is as follows:
構成ファイルオプション形式は次のとおりです。
Code Length Config-file...
+--------+--------+--------+--------+--------+--------+
| 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-file（c1..c（n））はNVT-ascii [1]印刷可能な文字列です。ゼロまたはその他の値によって終了しません。
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.
DHCPオプション内にすべての構成を含めるのではなく、個別の構成ファイルを使用するブートローダー（PXEまたはその他）は、このオプションを使用する可能性がある場合があります。
The code 209 will be adopted for this purpose.
この目的のためにコード209が採用されます。
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ファイルオプションは、パラメーターリクエストリストに表示される場合は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.
2段階のブートローダーは、他のDHCPオプションおよびフィールドと協調して、このオプションの値をファイル名として使用してTFTPを介して読み取り、さらに2段階荷重装置固有の構成パラメーターを読み取る必要があります。このようなファイルのフォーマットとコンテンツは、2段階のブートローダーに固有のものであり、そのため、このドキュメントの範囲外です。
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パスプレフィックスがあるが、異なるファイル名があることがよくあります（たとえば、ホストのブートローダー画像と構成ファイルは、メディアアクセスから派生したディレクトリ構造に保持される場合があります。コントロール（MAC）アドレス）。したがって、TFTPパスプレフィックス構成オプションを配信する価値があると見なされたため、これらの2つのことをDHCPサーバー構成：プレフィックスとホスト固有のファイルの位置で個別に構成できます。
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.
TFTPサーバーからpxelinuxが要求する実際のファイル名は、この値を上記の構成ファイルオプションに準備することにより派生します。この構成ファイルがロードされ、処理中にその中に指定されたTFTPファイルパスも同様に処理されます - このオプションの内容を準備します。
The Path Prefix Option format is as follows:
パスプレフィックスオプション形式は次のとおりです。
Code Length Path-Prefix...
+--------+--------+--------+--------+--------+--------+
| 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です。パスプレフィックスは、NVT-ASCII印刷可能な文字列です。ゼロまたはその他の値によって終了することはありません。
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.
これが表す「ショートカット」は価値がありますが、それがプロトコルワイヤーで現れる必要があるかどうかは疑わしいです。
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.
ただし、ファイル名ヘッダーの内容またはDHCPブートファイル名オプション（＃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ロードされた構成ファイルのコンテンツの圧縮は説得力のある要因ではありませんが、これらの値を使用した不自然な構成も存在する可能性があります。設定されたパスプレフィックスは実際には異なる画像をロードします。この種の使用が本当に必要であるかどうかは証明されていません。
The code 210 will be adopted for this purpose.
この目的のためにコード210が採用されます。
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プレフィックスオプションは、パラメーターリクエストリストに表示される場合は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を介して結果の値を取得する前に、このオプションの値がconfigFileオプションのコンテンツまたはデフォルトの「configファイル検索パス」を取得する前に、configfileオプションのコンテンツにプリケントする必要があります。構成ファイルオプションの。クライアントは、ロードされたら、そのファイル内の他の構成ディレクティブに値を事前に予備することができます。クライアントは、そのオプションまたはフィールドを説明するドキュメントに明示的に記載されていない限り、このオプションの値を他のDHCPオプションのコンテンツまたはフィールドに準備してはなりません。
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クライアントがリースを放棄すると仮定することは安全ではありません。
The Reboot Time Option format is as follows:
再起動時間オプション形式は次のとおりです。
Code Length
+--------+--------+--------+--------+--------+--------+
| 211 | 4 | Reboot Time |
+--------+--------+--------+--------+--------+--------+
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です。再起動時間は、ネットワークバイトの順序で32ビット（4バイト）整数です。
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.
十分に複雑なネットワーキング環境のネットワークブートストラッププログラムは、PXE由来のDHCPで移動することにより、ネットワーク上の不正なクライアントによってIPアドレスが盗まれたため、そのような同様の条件に入る可能性があります。リースはもはや有効ではなく、同様の手段があります。
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サーバーから異なる動作構成パラメーターを取得できます。
The code 211 will be adopted for this purpose.
この目的のためにコード211が採用されます。
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.
再起動時間オプションは、パラメーターリクエストリストに表示される場合は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段階のブートローダーは、オペレーターの介入を待つためにネットワークから切断されるはずですが、ホストオペレーティングシステムを無期限に取得しようとし続ける可能性があります。
To conform to this specification, clients and servers MUST implement the Configuration File, Path Prefix, and Reboot Time options as directed.
この仕様に準拠するには、クライアントとサーバーが構成ファイル、パスプレフィックス、および指示に従って時間オプションを再起動する必要があります。
The MAGIC option MAY NOT be implemented, as it has been deprecated.
魔法のオプションは、非推奨されているため、実装されない場合があります。
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クライアントが正しい権威あるDHCPサーバーから構成情報を受信していることを確認できるように、認証メカニズム[7]を実装することが知られていないPXE実装は知られていない。
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の使用には、あらゆる形態の暗号化署名もありません。したがって、「中央の」攻撃は、クライアントシステムで攻撃者のコードが実行される可能性があります。これは暗号化されたチャネルではないため、TFTPロードされたデータのいずれかも公開される場合があります（ /etc /passwdまたは同様の情報を含む「ラムディスク」画像の読み込みなど）。
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).
クライアントの一意のIDとしてイーサネットMACアドレスを使用することで、そのアイデンティティを引き受ける攻撃者が、DHCPサーバーによって「キー」が必要なものを提供することにより、クライアントシステムのネットワークリソースへの不適切なアクセスを得ることができる場合があります。ターゲットシステム（ターゲットであるかのように起動するため）。
Great care should be taken to secure PXE and PXELINUX installations, such as by using IP firewalls, to reduce or eliminate these concerns.
IPファイアウォールを使用して、これらの懸念を軽減または排除するなど、PXEおよびPXELINUXのインストールを確保するために細心の注意を払う必要があります。
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.
近くの攻撃者は、疑いを持たないクライアントのマスに1秒の「再起動時間」オプション値を提供し、DHCPサーバーにサービス拒否（DOS）を実現する可能性がありますが、再びこれらのクライアントにRogueの2番目の2番目に簡単に提供するかもしれません - 単にパケットの洪水を送信するステージブートローダー。
This document in and by itself provides no security, nor does it impact existing DCHP security as described in RFC 2131 [3].
このドキュメントは、それ自体でセキュリティを提供しません。また、RFC 2131 [3]に記載されているように、既存のDCHPセキュリティに影響を与えません。
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オプションコード208を「暫定的に割り当てられた」から「割り当て」に移動し、このドキュメントを参照しました。IANAは、この同じオプションコード、208を非推奨とマークしました。
2. Moved DHCPv4 Option code 209 from 'Tentatively Assigned' to 'Assigned', referencing this document.
2. DHCPV4オプションコード209を「暫定的に割り当てられた」から「割り当て」に移動し、このドキュメントを参照しました。
3. Moved DHCPv4 Option code 210 from 'Tentatively Assigned' to 'Assigned', referencing this document.
3. DHCPV4オプションコード210を「暫定的に割り当てられた」から「割り当て」に移動し、このドキュメントを参照しました。
4. Moved DHCPv4 Option code 211 from 'Tentatively Assigned' to 'Assigned', referencing this document.
4. DHCPV4オプションコード211を「暫定的に割り当てられた」から「割り当て」に移動し、このドキュメントを参照しました。
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.
これらのオプションは、H。PeterAnvinによってPxelinuxプロジェクト向けに設計および実装され、彼はこのドキュメントの作成に尽力しました。Shane Kerrは、このドキュメントを改善したフィードバックも提供しています。
[1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[1] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、STD 8、RFC 854、1983年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、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ガイドライン」、BCP 43、RFC 2939、2000年9月。
[6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[6] Sollins、K。、「TFTPプロトコル（改訂2）」、STD 33、RFC 1350、1992年7月。
[7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[7] Droms、R。およびW. Arbaugh、「DHCPメッセージの認証」、RFC 3118、2001年6月。
[8] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[8] Volz、B。、「動的ホスト構成プロトコルバージョン4（DHCPV4）オプションの再分類」、RFC 3942、2004年11月。
Author's Address
著者の連絡先
David W. Hankins Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US
David W. Hankins Internet Systems Consortium、Inc。950 Charter Street Redwood City、CA 94063 US
Phone: +1 650 423 1307
EMail: David_Hankins@isc.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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への情報をお問い合わせください。