Internet Engineering Task Force (IETF) T. Huth
Request for Comments: 5970 J. Freimann
Category: Standards Track IBM Germany R&D GmbH
ISSN: 2070-1721 V. Zimmer
Intel
D. Thaler
Microsoft
September 2010
DHCPv6 Options for Network Boot
Abstract
抽象
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network.
IPv6用動的ホスト構成プロトコル（DHCPv6の）は、ネットワーク上のノードに構成情報を渡すためのフレームワークを提供します。この文書では、ネットワークからノードを起動するために使用されるべきである（SHOULD）DHCPv6のための新しいオプションについて説明します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5970.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5970で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Options .........................................................3
3.1. Boot File Uniform Resource Locator (URL) Option ............3
3.2. Boot File Parameters Option ................................4
3.3. Client System Architecture Type Option .....................5
3.4. Client Network Interface Identifier Option .................6
4. Appearance of the Options .......................................7
5. Download Protocol Considerations ................................7
6. IANA Considerations .............................................7
7. Security Considerations .........................................8
8. Acknowledgements ................................................8
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References .....................................9
This document describes DHCPv6 options that SHOULD be used to provide configuration information for a node that must be booted using the network rather than from local storage.
この文書は、ローカルストレージからではなく、ネットワークを使用して起動する必要があり、ノードの構成情報を提供するために使用されるべきDHCPv6オプションを記述する。
Network booting is used, for example, in some environments where administrators have to maintain a large number of nodes. By serving all boot and configuration files from a central server, the effort required to maintain these nodes is greatly reduced.
ネットワークブートは、管理者が多数のノードを維持する必要がある環境では、例えば、使用されます。中央のサーバーからすべてのブートおよびコンフィギュレーションファイルを提供することにより、これらのノードを維持するために必要な労力が大幅に削減されます。
A typical boot file would be, for example, an operating system kernel or a boot-loader program. To be able to execute such a file, the firmware running on the client node must perform the following two steps (see Figure 1): First get all information that is required for downloading and executing the boot file. Second, download the boot file and execute it.
典型的なブートファイルは次のようになり、例えば、オペレーティングシステムのカーネルやブートローダプログラム。まず、ブートファイルをダウンロードし、実行するために必要とされるすべての情報を取得する：そのようなファイルを実行できるようにするには、クライアントノード上で実行されているファームウェアは、（図1を参照）、以下の2つの手順を実行する必要があります。第二に、ブートファイルをダウンロードして実行します。
+------+
_______________________\| DHCP |
/ 1 Get boot file info /|Server|
+------+ +------+
| Host |
+------+ +------+
\_______________________\| File |
2 Download boot file /|Server|
+------+
Figure 1: Network Boot Sequence
図1：ネットワークブートシーケンス
The information that is required for booting over the network MUST include at least the details about the server on which the boot files can be found, the protocol to be used for the download (for example, HTTP [RFC2616] or TFTP [RFC1350]), and the path and name of the boot file on the server. Additionally, the server and client MAY exchange information about the parameters that should be passed to the OS kernel or boot-loader program, respectively, or information about the supported boot environment.
ネットワークを介してブートするために必要とされる情報は、ブート・ファイルが見つかる可能なサーバ、ダウンロード（例えば、HTTP [RFC2616]またはTFTP [RFC1350]）に使用されるプロトコルに関する少なくとも詳細を含まなければなりませんサーバー上のブートファイルの、パスと名前。また、サーバとクライアントはそれぞれ、OSのカーネルやブートローダプログラムに渡されるパラメータ、またはサポートされているブート環境についての情報についての情報を交換することができます。
DHCPv6 allows client nodes to ask a DHCPv6 server for configuration parameters. This document provides new options that a client can request from the DHCPv6 server to satisfy its requirements for booting. It also introduces a new IANA registry for processor architecture types that are used by the OPTION_CLIENT_ARCH_TYPE option (see Section 3.3).
DHCPv6のクライアント・ノードは、設定パラメータのためのDHCPv6サーバに依頼することができます。この文書では、クライアントが起動用にその要件を満たすために、DHCPv6サーバから要求できる新しいオプションが用意されています。また、OPTION_CLIENT_ARCH_TYPEオプション（3.3節を参照）によって使用されているプロセッサアーキテクチャのタイプのための新しいIANAレジストリを紹介します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Terminology specific to IPv6 and DHCPv6 are used in the same way as is defined in the "Terminology" sections of [RFC3315].
IPv6とDHCPv6のに特定の用語は、[RFC3315]の「用語」セクションで定義されているのと同じ方法で使用されています。
Option formats comply with DHCPv6 options per [RFC3315] (Section 6). The boot-file-url option (see Section 3.1) is mandatory for booting, all other options are optional.
オプションのフォーマットは、[RFC3315]（セクション6）当たりのDHCPv6オプションに準拠します。ブート-file-urlには、オプション（3.1節を参照してください）他のすべてのオプションは任意です、ブートに必須です。
The server sends this option to inform the client about a URL to a boot file.
サーバーは、ブートファイルへのURLについてクライアントに通知するには、このオプションを送信します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. boot-file-url (variable length) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
フォーマットの説明：
option-code OPT_BOOTFILE_URL (59).
オプションコードOPT_BOOTFILE_URL（59）。
option-len Length of the boot-file-url in octets.
オクテット内のboot-file-URLのオプション-LEN長さ。
boot-file-url This string is the URL for the boot file. It MUST comply with STD 66 [RFC3986]. The string is not NUL-terminated.
ブート-file-urlには、この文字列は、ブートファイルのURLです。これは、STD 66 [RFC3986]に従わなければなりません。文字列はNUL終端されていません。
If the host in the URL is expressed using an IPv6 address rather than a domain name, the address in the URL then MUST be enclosed in "[" and "]" characters, conforming to [RFC3986]. Clients that have DNS implementations SHOULD support the use of domain names in the URL.
URLのホストがIPv6アドレスではなくドメイン名を使用して表現されている場合は、URL内のアドレスは、[RFC3986]に準拠した、「[」と「]」の文字で囲む必要があります。 DNSの実装を持っているクライアントは、URLのドメイン名の使用をサポートする必要があります。
This option is sent by the server to the client. It consists of multiple UTF-8 ([RFC3629]) strings. They are used to specify parameters for the boot file (similar to the command line arguments in most modern operating systems). For example, these parameters could be used to specify the root file system of the OS kernel, or the location from which a second-stage boot-loader program can download its configuration file.
このオプションは、サーバからクライアントに送信されます。これは、複数のUTF-8（[RFC3629]）文字列で構成されています。彼らは（ほとんどの現代のオペレーティングシステムでコマンドライン引数に似ている）ブートファイルのパラメータを指定するために使用されています。例えば、これらのパラメータは、OSカーネルのルートファイルシステム、または第二段階ブートローダプログラムは、そのコンフィギュレーションファイルをダウンロードできる場所を指定するために使用することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPT_BOOTFILE_PARAM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. <multiple Parameters> .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description:
フォーマットの説明：
option-code OPT_BOOTFILE_PARAM (60).
オプションコードOPT_BOOTFILE_PARAM（60）。
option-len Length of the Boot File Parameters option in octets (not including the size of the option-code and option-len fields).
ブートファイルのオプション-LEN長さ（オプション・コードおよびオプションのlenフィールドのサイズは含まない）オクテットにオプションパラメータ。
param-len 1...n This is a 16-bit integer that specifies the length of the following parameter in octets (not including the parameter-length field).
PARAM-LEN 1 ... Nこれは、（パラメータ長フィールドを含まない）オクテットで次のパラメータの長さを指定する16ビット整数です。
parameter 1...n These UTF-8 strings are parameters needed for booting, e.g., kernel parameters. The strings are not NUL-terminated.
パラメータ1 ... nはこれらのUTF-8文字列は、例えば、カーネルパラメータをブートするために必要なパラメータです。文字列はNUL終端されていません。
When the boot firmware executes the boot file that has been specified in the OPT_BOOTFILE_URL option, it MUST pass these parameters, if present, in the order that they appear in the OPT_BOOTFILE_PARAM option.
ブートファームウェアがOPT_BOOTFILE_URLオプションで指定されたブートファイルを実行すると存在する場合、それは彼らがOPT_BOOTFILE_PARAMオプションで表示される順序で、これらのパラメータを渡す必要があります。
This option provides parity with the Client System Architecture Type option defined for DHCPv4 in Section 2.1 of [RFC4578].
このオプションは、[RFC4578]のセクション2.1でのDHCPv4のために定義されたクライアント・システム・アーキテクチャTypeオプションでパリティを提供します。
The format of the option is:
オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENT_ARCH_TYPE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. architecture-types (variable length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_ARCH_TYPE (61).
オプションコードOPTION_CLIENT_ARCH_TYPE（61）。
option-len Length of the "architecture-types" field in octets. It MUST be an even number greater than zero. See Section 2.1 of [RFC4578] for details.
オクテットで、「建築・タイプ」フィールドのオプション-LEN長さ。それは、ゼロよりも大きい偶数でなければなりません。詳細については、[RFC4578]のセクション2.1を参照してください。
architecture-types A list of one or more architecture types, as specified in Section 2.1 of [RFC4578]. Each architecture type identifier in this list is a 16-bit value that describes the pre-boot runtime environment of the client machine. A list of valid values is maintained by the IANA (see Section 6).
アーキテクチャタイプ[RFC4578]のセクション2.1で指定されたように、1つのまたは複数のアーキテクチャ・タイプのリスト。このリストの各アーキテクチャタイプ識別子は、クライアントマシンの起動前のランタイム環境を記述する、16ビットの値です。有効な値のリストは、IANA（セクション6を参照）によって維持されています。
The client MAY use this option to send a list of supported architecture types to the server, so the server can decide which boot file should be provided to the client. If a client supports more than one pre-boot environment (for example, both 32-bit and 64-bit executables), the most preferred architecture type MUST be listed as first item, followed by the others with descending priority.
クライアントは、サーバーへのサポートアーキテクチャタイプのリストを送信するには、このオプションを使用することができるが、そのサーバがクライアントに提供されるべきブートファイル決めることができます。クライアントは、複数のプリブート環境をサポートしている場合（例えば、32ビットと64ビットの実行可能ファイルの両方）、最も好ましくアーキテクチャタイプは、最初の項目としてリスト下り優先度他人が続かなければなりません。
If the client used this option in the request, the server SHOULD include this option to inform the client about the pre-boot environments that are supported by the boot file. The list MUST only contain architecture types that have initially been queried by the client. The items MUST also be listed in order of descending priority.
クライアントが要求でこのオプションを使用した場合、サーバーは、ブートファイルでサポートされているプリブート環境についてクライアントに通知するには、このオプションを含むべきです。リストには、最初にクライアントから照会されているアーキテクチャの種類を含まなければなりません。アイテムはまた、優先順位の高い順にリストされなければなりません。
If the client supports the Universal Network Device Interface (UNDI) (see [PXE21] and [UEFI23]), it may send the Client Network Interface Identifier option to a DHCP server to provide information about its level of UNDI support.
クライアントはユニバーサルネットワークデバイスインターフェイス（UNDI）をサポートしている場合（[PXE21]を参照し、[UEFI23]）、それはUNDIサポートのそのレベルに関する情報を提供するために、DHCPサーバーへのクライアントネットワークインタフェース識別子オプションを送信することができます。
This option provides parity with the Client Network Interface Identifier option defined for DHCPv4 in Section 2.2 of [RFC4578].
このオプションは、[RFC4578]のセクション2.2でのDHCPv4のために定義されたクライアントのネットワークインタフェース識別子オプション付きのパリティを提供します。
The format of the option is:
オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NII | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Major | Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_NII (62).
オプションコードOPTION_NII（62）。
option-len 3
オプション-LEN 3
Type As specified in Section 2.2 of [RFC4578].
[RFC4578]のセクション2.2で指定されたタイプ。
Major As specified in Section 2.2 of [RFC4578].
[RFC4578]のセクション2.2で指定されるように主要。
Minor As specified in Section 2.2 of [RFC4578].
[RFC4578]のセクション2.2で指定されるようにマイナー。
The list of valid Type, Major, and Minor values is maintained in the Unified Extensible Firmware Interface specification [UEFI23].
有効なタイプ、メジャー、マイナー値のリストは、統一拡張ファームウェアインターフェイス仕様[UEFI23]に維持されます。
These options MUST NOT appear in DHCPv6 messages other than the types Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
これらのオプションは、タイプは、インフォメーション・リクエスト、および返信、勧誘広告、要求を、更新、再バインド以外のDHCPv6メッセージに現れてはいけません。
The option-codes of these options MAY appear in the Option Request option in the DHCPv6 message types Solicit, Request, Renew, Rebind, Information-Request, and Reconfigure.
これらのオプションのオプション・コードは、送信請求のDHCPv6メッセージタイプにオプション要求オプションに表示される要求、更新、再バインド、情報リクエスト、および再構成することができます。
The Boot File URL option does not place any constraints on the protocol used for downloading the boot file, other than that it MUST be possible to specify it in a URL. For the sake of administrative simplicity, we strongly recommend that, at a minimum, implementers of network boot loaders implement the well-known and established HyperText Transfer Protocol (HTTP) [RFC2616] for downloading. Please note that for IPv6, this supersedes [RFC906], which recommended using TFTP for downloading (see [RFC3617] for the 'tftp' URL definition).
URLで指定することも可能でなければならないことよりも、ブートファイルのURLオプションは、他のブートファイルを、ダウンロードするために使用されるプロトコル上の任意の制約を課すものではありません。行政簡単にするために、私たちは強く、最低でも、ネットワークブートローダーの実装は、ダウンロードするためのよく知られており、確立されたハイパーテキスト転送プロトコル（HTTP）[RFC2616]を実装する、ことをお勧めします。 IPv6のために、これは（「TFTP」URLの定義については、[RFC3617]を参照）[RFC906]、ダウンロードするためのTFTPを使用して、推奨され取って代わることに注意してください。
When using the Internet Small Computer System Interface (iSCSI) for booting, the 'iscsi' URI is formed as defined in [RFC4173]. The functionality attributed in RFC 4173 to a root path option is provided for IPv6 by the Boot File URL option instead.
ブートにインターネット小型コンピュータシステムインタフェース（iSCSIの）を使用する場合は、「iSCSIの」URIは、[RFC4173]で定義されるように形成されています。ルートパスオプションにRFC 4173に起因する機能は、代わりにブートファイルのURLオプションでのIPv6のために提供されます。
The following options have been assigned by the IANA from the option number space defined in Section 24 of the DHCPv6 RFC [RFC3315].
次のオプションは、DHCPv6のRFC [RFC3315]のセクション24で定義されたオプションの番号空間からIANAによって割り当てられています。
+-------------------------+-------+--------------+
| Option name | Value | Specified in |
+-------------------------+-------+--------------+
| OPT_BOOTFILE_URL | 59 | Section 3.1 |
| OPT_BOOTFILE_PARAM | 60 | Section 3.2 |
| OPTION_CLIENT_ARCH_TYPE | 61 | Section 3.3 |
| OPTION_NII | 62 | Section 3.4 |
+-------------------------+-------+--------------+
This document also introduces a new IANA registry for processor architecture types. The name of this registry is "Processor Architecture Types". Registry entries consist of a 16-bit integer recorded in decimal format and a descriptive name. The initial values of this registry can be found in [RFC4578], Section 2.1.
また、このドキュメントでは、プロセッサアーキテクチャのタイプのための新しいIANAレジストリを紹介します。このレジストリの名前は、「プロセッサ・アーキテクチャの種類」です。レジストリエントリ10進形式と記述名に記録された16ビットの整数から成ります。このレジストリの初期値は、[RFC4578]、2.1節に見出すことができます。
The assignment policy for values is through Expert Review (see [RFC5226]), and any requests for values must supply the descriptive name for the processor architecture type.
値の割り当てポリシーは、エキスパートレビュー（参照[RFC5226]）を介して行われ、および値のためのすべての要求は、プロセッサ・アーキテクチャ・タイプの記述名を供給しなければなりません。
In untrusted networks, a rogue DHCPv6 server could send the new DHCPv6 options described in this document. The booting clients could then be provided with a wrong URL so that either the boot fails or, even worse, the client boots the wrong operating system that has been provided by a malicious file server. To prevent this kind of attack, clients SHOULD use authentication of DHCPv6 messages (see Section 21 in [RFC3315]).
信頼できないネットワークでは、不正なDHCPv6サーバは、このドキュメントで説明する新しいDHCPv6オプションを送信することができます。ブートが失敗した場合や、悪質なファイルサーバによって提供されているにも悪いことに、クライアントブーツ間違ったオペレーティングシステムのいずれかとなるようブートクライアントは、間違ったURLを設けることができます。この種の攻撃を防ぐために、クライアントは、DHCPv6のメッセージ（[RFC3315]でセクション21を参照）の認証を使用する必要があります。
Note also that DHCPv6 messages are sent unencrypted by default. So the boot file URL options are sent unencrypted over the network, too. This can become a security risk since the URLs can contain sensitive information like user names and passwords (for example, a URL like "ftp://username:password@servername/path/file"). At the current point in time, there is no possibility to send encrypted DHCPv6 messages, so it is strongly RECOMMENDED not to use sensitive information in the URLs in untrusted networks (using passwords in URLs is deprecated anyway, according to [RFC3986]).
DHCPv6のメッセージは、デフォルトで暗号化されずに送信されていることにも注意してください。だから、ブートファイルのURLのオプションは、あまりにも、ネットワーク経由で暗号化されずに送信されます。 URLは、ユーザー名やパスワードなどの機密情報を含むことができますので、これはセキュリティ上のリスクになることができます（たとえば、「FTP：//ユーザー名：パスワード@サーバ名/パス/ファイル」のようなURL）。現時点では、そこに暗号化されたDHCPv6メッセージを送るべき可能性はありませんので、強く信頼できないネットワーク内のURLに機密情報を使用しないことをお勧めします（URLでパスワードを使用しては、[RFC3986]によると、とにかく推奨されません）。
Even if the DHCPv6 transaction is secured, this does not protect against attacks on the boot file download channel. Consequently, we recommend that either (a) implementers use protocols like HTTPS [RFC2818] or Transport Layer Security (TLS) within HTTP [RFC2817] to prevent spoofing or (b) the boot-loader software implement a mechanism for signing boot images and a configurable signing key. The latter is done so that if a malicious image is provided, it can be detected and rejected.
DHCPv6のトランザクションが確保されている場合でも、これはブートファイルのダウンロードチャネルへの攻撃を防ぐことはできません。したがって、我々は、（a）の実装は、なりすましを防止又は（b）のブートローダソフトウェアは、ブートイメージとAに署名するためのメカニズムを実装するためにHTTP [RFC2817]内HTTPSなどのプロトコル[RFC2818]またはTransport Layer Security（TLS）を使用することをお勧めします設定可能な署名鍵。悪質な画像が提供される場合、それを検出して排除することができるように後者が行われます。
The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton, Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led to this document.
著者は、この文書につながった議論のためのルースリー、ドン魏、キャスリン・ハンプトン、フィル・Dorah、リチャード・チャン、とフィオナジェンセンに感謝したいと思います。
The authors would also like to thank Ketan P. Pancholi, Alfred Hoenes, Gabriel Montenegro, and Ted Lemon for corrections and suggestions.
著者らはまた、訂正や提案をKetan P. Pancholi、アルフレッドHoenes、ガブリエルモンテネグロ、およびテッドレモンを感謝したいと思います。
[PXE21] Johnston, M., "Preboot Execution Environment (PXE) Specification", September 1999, <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
【PXE21]ジョンストン、M.、 "プレブート実行環境（PXE）仕様"、1999年9月、<http://www.pix.net/software/pxeboot/archive/pxespec.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4173] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[RFC4173]サルカール、P.、Missimer、D.、およびC. Sapuntzakis、RFC 4173、2005年9月 "インターネット小型コンピュータシステムインタフェース（iSCSIの）プロトコルを使用しているクライアントのブートストラップ"。
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578]ジョンストン、M.とS. Venaas、 "インテルプリブート実行環境（PXE）のための動的ホスト構成プロトコル（DHCP）オプション"、RFC 4578、2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[UEFI23] UEFI Forum, "Unified Extensible Firmware Interface Specification, Version 2.3", May 2009, <http://www.uefi.org/>.
[UEFI23] UEFIフォーラム、 "ユニファイド拡張ファームウェアインターフェイス仕様、バージョン2.3"、2009年5月、<http://www.uefi.org/>。
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, June 1984.
[RFC906]フィンレイソン、R.、 "TFTPを使用してブートストラップのロード"、RFC 906、1984年6月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350] Sollins、K.、 "TFTPプロトコル（改訂第2版）"、STD 33、RFC 1350、1992年7月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[RFC2817] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3617]リア、E.、RFC 3617、2003年10月 "簡易ファイル転送プロトコル（TFTP）のURI（Uniform Resource Identifier）スキームと適用性声明"。
Authors' Addresses
著者のアドレス
Thomas H. Huth IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
トーマスH.フートIBMドイツ研究開発社Schoenaicherシュトラーセ220ボーブリンゲン71032ドイツ
Phone: +49-7031-16-2183 EMail: thuth@de.ibm.com
電話：+ 49-7031-16-2183 Eメール：thuth@de.ibm.com
Jens T. Freimann IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
イェンス・T.フライマンIBMドイツ研究開発社Schoenaicherシュトラーセ220ボーブリンゲン71032ドイツ
Phone: +49-7031-16-1122 EMail: jfrei@de.ibm.com
電話：+ 49-7031-16-1122 Eメール：jfrei@de.ibm.com
Vincent Zimmer Intel 2800 Center Drive DuPont WA 98327 USA
ヴィンセントルームインテル2800・センター・ドライブデュポンWA 98327 USA
Phone: +1 253 371 5667 EMail: vincent.zimmer@intel.com
電話：+1 253 371 5667 Eメール：vincent.zimmer@intel.com
Dave Thaler Microsoft One Microsoft Way Redmond WA 98052 USA
デーブターラーマイクロソフトワンマイクロソフトウェイレドモンドWA 98052 USA
Phone: +1 425 703-8835 EMail: dthaler@microsoft.com
電話：+1 425 703-8835 Eメール：dthaler@microsoft.com