[要約] RFC 5970は、ネットワークブートのためのDHCPv6オプションに関する仕様です。このRFCの目的は、IPv6ネットワーク上でのブートプロセスをサポートするために、DHCPv6オプションを定義することです。
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
ネットワークブートのDHCPV6オプション
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）の動的ホスト構成プロトコルは、ネットワーク上のノードに構成情報を渡すためのフレームワークを提供します。このドキュメントでは、ネットワークからノードを起動するために使用する必要がある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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
典型的なブートファイルは、たとえば、オペレーティングシステムカーネルまたはブートローダープログラムです。このようなファイルを実行できるようにするには、クライアントノードで実行されているファームウェアが次の2つの手順を実行する必要があります（図1を参照）：最初にブートファイルのダウンロードと実行に必要なすべての情報を取得します。次に、ブートファイルをダウンロードして実行します。
+------+
_______________________\| 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オプションで使用されるプロセッサアーキテクチャタイプの新しいIANAレジストリも紹介します（セクション3.3を参照）。
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オプションに準拠しています。Boot-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.
オクテットのブートファイルURLのオプションレン長。
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.
Boot-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カーネルのルートファイルシステム、または2段階のブートローダープログラムが構成ファイルをダウンロードできる場所を指定できます。
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).
オクターセットのブートファイルパラメーターのオプションレンの長さ（オプションコードとオプションレンフィールドのサイズは含まれません）。
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.
Bootファームウェアが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に対して定義されたクライアントシステムアーキテクチャタイプオプションのパリティを提供します。
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-Code 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.
オクテットの「アーキテクチャタイプ」フィールドのオプションレン長。ゼロより大きい偶数でなければなりません。詳細については、[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]を参照）、クライアントネットワークインターフェイス識別子オプションをDHCPサーバーに送信して、UNDIサポートのレベルに関する情報を提供する場合があります。
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-Code option_nii（62）。
option-len 3
オプションレン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.
これらのオプションは、タイプの勧誘、宣伝、要求、更新、rebind、情報request、および返信以外の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メッセージタイプのsolicit、request、regn、rebind、information-request、および再構成のオプションリクエストオプションに表示される場合があります。
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を使用することを推奨していることに注意してください（「TFTP」URL定義については[RFC3617]を参照）。
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.
ブートにインターネットSmall Computer System Interface（ISCSI）を使用する場合、[RFC4173]で定義されているように「ISCSI」URIが形成されます。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レジストリも紹介します。このレジストリの名前は「プロセッサアーキテクチャタイプ」です。レジストリエントリは、小数形式で記録された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]).
信頼されていないネットワークでは、Rogue 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：// username：password@servername/path/file」などのURLが含まれます。現在の時点では、暗号化されたDHCPV6メッセージを送信する可能性はないため、信頼されていないネットワークのURLで機密情報を使用しないことを強くお勧めします（[RFC3986]によると、URLでパスワードを使用しています）。
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）実装者がHTTPS [RFC2818]などのプロトコルを使用してHTTP内の輸送層セキュリティ（TLS）を使用して、スプーフィングを防ぐために、またはブートローダーソフトウェアがブートイメージとAに署名するメカニズムを実装することをお勧めします。設定可能な署名キー。後者は、悪意のある画像が提供された場合、検出および拒否できるように行われます。
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.
著者は、この文書につながった議論について、ルース・リー、ドン・ウェイ、キャスリン・ハンプトン、フィル・ドラ、リチャード・チャン、フィオナ・ジェンセンに感謝したいと思います。
The authors would also like to thank Ketan P. Pancholi, Alfred Hoenes, Gabriel Montenegro, and Ted Lemon for corrections and suggestions.
著者はまた、ケタン・P・パンチョリ、アルフレッド・ホーネス、ガブリエル・モンテネグロ、テッド・レモンに感謝します。
[PXE21] Johnston, M., "Preboot Execution Environment (PXE) Specification", September 1999, <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
[PXE21] Johnston、M。、「Preboot Execution Environment（PXE）仕様」、1999年9月、<http://www.pix.net/software/pxeboot/archive/pxesp.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、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] Sarkar、P.、Missimer、D。、およびC. Sapuntzakis、「インターネットSmall Computer System Interface（ISCSI）プロトコルを使用したブートストラップクライアント」、RFC 4173、2005年9月。
[RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)", RFC 4578, November 2006.
[RFC4578] Johnston、M。およびS. Venaas、「Intel Preboot実行環境（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 FORUM、 "Unified Extensibleファームウェアインターフェイス仕様、バージョン2.3"、2009年5月、<http://www.uefi.org/>。
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906, June 1984.
[RFC906] Finlayson、R。、「TFTPを使用したブートストラップ負荷」、RFC 906、1984年6月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]ソリンズ、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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. Lawrence、「HTTP/1.1内のTLSへのアップグレード」、RFC 2817、2000年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、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] Lear、E。、「些細なファイル転送プロトコル（TFTP）の均一なリソース識別子スキームと適用可能性ステートメント」、RFC 3617、2003年10月。
Authors' Addresses
著者のアドレス
Thomas H. Huth IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
Thomas H. Huth IBMドイツ研究開発GmbH Schoenaicher Strasse 220 Boeblingen 71032ドイツ
Phone: +49-7031-16-2183
EMail: thuth@de.ibm.com
Jens T. Freimann IBM Germany Research & Development GmbH Schoenaicher Strasse 220 Boeblingen 71032 Germany
Jens T. Freimann IBMドイツ研究開発GmbH Schoenaicher Strasse 220 Boeblingen 71032ドイツ
Phone: +49-7031-16-1122
EMail: jfrei@de.ibm.com
Vincent Zimmer Intel 2800 Center Drive DuPont WA 98327 USA
Vincent Zimmer Intel 2800センタードライブDupont WA 98327 USA
Phone: +1 253 371 5667
EMail: vincent.zimmer@intel.com
Dave Thaler Microsoft One Microsoft Way Redmond WA 98052 USA
Dave Thaler Microsoft One Microsoft Way Redmond WA 98052 USA
Phone: +1 425 703-8835
EMail: dthaler@microsoft.com