Network Working Group                                         D. Hankins
Request for Comments: 5071                                           ISC
Category: Informational                                    December 2007
        
      Dynamic Host Configuration Protocol Options Used by 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
        
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、プレブート実行環境は、第一段目のネットワークブートストラップ剤です。 PXEは、[3]クエリがIPアドレスを取得するために、クライアントのホスト上のファームウェアのうち、ロード、およびDHCPを実行しています。

Once on the network, it loads a second-stage bootstrap agent as configured by DHCP header and option contents.

DHCPヘッダとオプションの内容によって構成されるように一度ネットワーク上には、第二段階ブートストラップエージェントをロードします。

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は、そのような第二段階ブートストラップ剤です。 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が使用中になるだろう、と、そうであっても、(S)PXELINUXダイジェストかもしれないものをオプション知る方法はありません知識を持ちません。そのクライアントにこのPXELINUXイメージを果たすローカルインストールはまた、彼らは[4] DHCPパラメータ要求リストに含まれていないにもかかわらず、これらのオプションを提供するために、彼らの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「MAGIC」 - 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の前に追加される値を設定します。

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]。このドキュメントのオプションコードの割り当ては、新しい範囲(128から223を含む)内のオプションコードの前に使用を文書化するためにRFC 3942の規定内で行われています。

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「の第一段階のブートローダー」 - 指定されたブートロードの順序は、次のような多くの段階を、持っているかもしれないがどこBIOSが起動し、この文書というPXE実行可能な、それは、この例では、唯一のPXEは、実行可能ファイルをロードするDOSブートディスク、 「第一段階のブートローダー」として説明 - 本質的に、これはDHCPが関与するでブートの最初の段階です。

o "second-stage bootloader" - This describes a program loaded by the first-stage bootloader at the behest of the DHCP server.

o「の第二段階ブートローダー」 - これは、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].

キーワード "MAY"、 "MUST"、 "MUST NOT"、 "SHOULD"、および "SHOULD NOT" 本書ではRFC 2119に記載されるように解釈されるべきである[2]。

3. MAGIC Option
3. MAGICオプション
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.

74:00:7eは、このオプションはPXEブートローダーに提供されている場合、値はオクテット文字列F1を一致させるためにPXELINUXによってチェックされます。これが一致した場合、以下に説明するように、その後、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ブートローダにつながるないだろう、ということを保証することを意図していました。

3.2. Packet Format
3.2. パケットフォーマット

The MAGIC Option format is as follows:

次のようにMAGICオプションの形式は次のとおりです。

              Code    Length     m1       m2       m3       m4
           +--------+--------+--------+--------+--------+--------+
           |   208  |    4   |  0xF1  |  0x00  |  0x74  |  0x7E  |
           +--------+--------+--------+--------+--------+--------+
        

The code for this option is 208. The length is always four.

このオプションのコードは長さが常に4である208です。

3.3. Applicability
3.3. 適用性

This option is absolutely inapplicable to any other purpose.

このオプションは、他の目的には絶対適用できません。

3.4. Response to
3.4. への反応

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経由でその名前のファイルをロードします。このファイルの内容は、ブートロード(メニュー選択などでユーザに提示するために、ブートイメージの名前、場所、ブート時のフラグ、テキストを指定して)、その次の段階で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エージェントは、いくつかのデフォルトの名前の設定ファイルのために(この前の段階にPXEによって決定される)TFTPサーバを検索します。

4.2. Packet Format
4.2. パケットフォーマット

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.

このオプションのためのコードはNVT-ASCII [1]印刷可能な文字列コンフィグファイル(c1..c(N))209です。それは、ゼロまたは他の値で終了していません。

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.

(よるDHCPオプションのために利用可能な限られたスペースにできない場合があります)、別の構成ファイルの使用ではなく、DHCPオプション内のすべての構成を含むを作る任意のブートローダー、PXEまたはそれ以外では、おそらくこのオプションを利用することができます。

4.4. Response to
4.4. への反応

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.

設定ファイルのオプションは、それがパラメータ要求リストに表示された場合、DHCPサーバによって供給されなければならないが、サーバ管理者は、それが後に(例えば、サーバが第二を提供するように構成されているため、クライアントに有用であろうと信じている場合も供給されなければなりません彼らはそれを利用します知っている-stageブートイメージ、)。何値がそれのために構成されていない場合、このオプションは、供給されてはいけません、またはゼロ長さの値が設定されている場合。

The DHCP client MUST only cache this option in a location the second-stage bootloader may access.

DHCPクライアントは二段目のブートローダがアクセスできる場所に、このオプションをキャッシュしなければなりません。

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オプションとフィールドと協調して、TFTP経由でロードされ、さらに第二段階ローダ固有の設定パラメータのために読み込まれるファイル名として、このオプションの値を使用しなければなりません。そのようなファイルの形式と内容は、第二段目のブートローダに対して特異的であり、そのようなものとして、この文書の範囲外です。

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パス接頭辞を持っているだろうが、異なるファイル名を有することがよくある(例:ホストのブートローダーイメージや設定ファイルは、そのメディアアクセス由来ディレクトリ構造に保つことができますコントロール(MAC)アドレス)。プレフィックスと、おそらくホスト固有のファイルの場所:これら二つのものがDHCPサーバーの設定で個別に設定することができるように、結果的に、それは、TFTPパス接頭辞の設定オプションを提供するために価値があると考えられました。

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ファイルのパスは、同様に処理されている - このオプションの内容を付加します。

5.2. Packet Format
5.2. パケットフォーマット

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.

このオプションのためのコードは、パス接頭辞は、NVT-ASCII印刷可能な文字列で210です。それは、ゼロまたは他の値で終了していません。

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.

これが表す「ショートカット」は価値があるが、それがプロトコルワイヤ上に現れる必要があるかどうかは疑問です。

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ブートファイル名オプション(#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
5.4. への反応

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.

パス接頭辞オプションは、それがパラメータ要求リストに表示された場合、DHCPサーバによって供給されなければならないが、サーバ管理者は、それが後に(例えば、サーバが第二を提供するように構成されているため、クライアントに有用であろうと信じている場合も供給されなければなりません彼らはそれを利用します知っている-stageブートイメージ)。何値がそれのために構成されていない場合、このオプションは、供給されてはいけません、またはゼロ長さの値が設定されている場合。

The DHCP client MUST only cache this option in a location where the second-stage bootloader may access it.

DHCPクライアントは二段目のブートローダがそれにアクセスすることが可能な場所に、このオプションをキャッシュしなければなりません。

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.

二段目のブートローダーは、TFTPを介した結果の値、またはデフォルトの「設定ファイル検索パス」を、得る前のConfigFileオプションの内容に、もしあれば、このオプションの値を付加しなければならない存在しない場合に第二段階のブートローダーを反復設定ファイルオプションの。それがロードされた後、クライアントは、そのファイル内の他の設定ディレクティブに価値を付加してもよい(MAY)。明示的にそのオプションやフィールドを記述した文書に記載がない限り、クライアントは、他のDHCPオプションの内容やフィールドに、このオプションの値を付加してはなりません。

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.

300秒が経過した後に実行さPXELINUX、その後、何らかの理由で、ブートストラップを継続するために、そのTFTPサーバに到達することができないはずです、クライアントは、デフォルトでは、自分自身を再起動します。これは、環境に応じて、完全長すぎる、短すぎる、または不適切な行為かもしれません。

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:

次のように再起動し時間オプションの形式は次のとおりです。

              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.

このオプションのコードは長さが常に4である211です。リブート時間は、ネットワークバイト順に、32ビット(4バイト)の整数です。

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.

任意の十分に複雑なネットワーク環境内のすべてのネットワークブートストラッププログラムは、おそらくその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サーバから別の作業設定パラメータを取得することがあります。

6.4. Response to
6.4. への反応

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.

再起動の時間オプションは、それがパラメータ要求リストに表示された場合、DHCPサーバによって供給されなければならないが、サーバ管理者は、それが後に(例えば、サーバが第二を提供するように構成されているため、クライアントに有用であろうと信じている場合も供給されなければなりません彼らはそれを利用します知っている-stageブートイメージ)。値がそれのために設定されていない場合のオプションは提供されてはならない、またはそれは、長さゼロの値が含まれている場合。

The DHCP client MUST only cache this option in a location the second-stage bootloader may access.

DHCPクライアントは二段目のブートローダがアクセスできる場所に、このオプションをキャッシュしなければなりません。

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).

このオプションの値がゼロでないならば、第二段階のブートローダーはタイムアウトをスケジュールする必要があります:このオプションの値に等しい秒数が経過した後に、二段目のブートローダが最終的に戻って実行パスを返す、システムを再起動する必要があります第一段階のブートローダー。実行スレッドがホストオペレーティングシステムに渡された後、それはシステムを再起動してはならない(この時点で、このタイムアウトを効果的に回避されます)。

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.

このオプションの値がゼロであれば、第二段階ブートローダーは、すべてのそのようなタイムアウトをスケジュールしてはいけません。それを見つけ、任意の第二段階のブートローダーは、オペレータの介入を待つために、ネットワークから自分自身を切断する必要があり、そのホスト・オペレーティング・システムを取得しようとする過度のタイムアウトが発生しましたが、無期限にホストオペレーティングシステムを取得しようとし続けることができます。

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.

指示されたように、この仕様に準拠するには、クライアントとサーバは、パス接頭辞、および再起動の時間オプションを設定ファイルを実装しなければなりません。

The MAGIC option MAY NOT be implemented, as it has been deprecated.

それは廃止されましたようMAGICオプションは、実装されない場合があります。

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クライアントは、彼らが正しい、権威DHCPサーバから設定情報を受信して​​いることを確認することができますように、現在のところ、PXEの実装は、[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の使用はまた、暗号署名のいずれかの形式を欠い - ので、攻撃「中間者」は、クライアントシステム上で実行されている攻撃者のコードにつながる可能性があります。これは暗号化されたチャネルではないので、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サーバによって与えられていることにより、クライアントシステムのネットワークリソースへの不適切なアクセスを得るためにそのIDを取り、攻撃者を可能にすることができるクライアントの一意の識別情報として、イーサネットMACアドレスの使用は、することがターゲットシステムは、(それがターゲットであるかのように起動します)。

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.

近くの攻撃者は、DHCPサーバによりサービス拒否(DoS攻撃)を達成するために、疑いを持たないクライアントのマスに1秒の「再起動時」オプションの値を養うかもしれませんが、その後再びそれは同じように簡単に不正秒でこれらのクライアントを供給することができます単にパケットの洪水を送信-stageブートローダ。

This document in and by itself provides no security, nor does it impact existing DCHP security as described in RFC 2131 [3].

それ自体によって、この文書には、セキュリティを提供しない、またRFC 2131に記載されているように、既存のDHCPセキュリティに影響を与えない[3]。

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オプションコード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を移動しました。

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.レイノルズ、 "テルネットプロトコル仕様"、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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]アレクサンダー、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]、BCP 43、RFC 2939、2000年9月Droms、R.、 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。

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版)"、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]フォルツ、B.、RFC 3942、2004年11月 "動的ホスト構成プロトコルバージョン4(DHCPv4の)オプションを再分類"。

Author's Address

著者のアドレス

David W. Hankins Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 US

デビッドW.ハンキンズインターネットシステムコンソーシアム株式会社950憲章通りカリフォルニア州レッドウッドシティー94063米国

Phone: +1 650 423 1307 EMail: David_Hankins@isc.org

電話:+1 650 423 1307 Eメール:David_Hankins@isc.org

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2007).

著作権(C)IETFトラスト(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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。