draft-ietf-dhc-dhcpv6-opt-netboot-10.txt   rfc5970.txt 
DHC T. Huth Internet Engineering Task Force (IETF) T. Huth
Internet-Draft J. Freimann Request for Comments: 5970 J. Freimann
Intended status: Standards Track IBM Germany Research & Category: Standards Track IBM Germany R&D GmbH
Expires: January 27, 2011 Development GmbH ISSN: 2070-1721 V. Zimmer
V. Zimmer
Intel Intel
D. Thaler D. Thaler
Microsoft Microsoft
July 26, 2010 September 2010
DHCPv6 options for network boot DHCPv6 Options for Network Boot
draft-ietf-dhc-dhcpv6-opt-netboot-10
Abstract Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a
framework for passing configuration information to nodes on a framework for passing configuration information to nodes on a
network. This document describes new options for DHCPv6 which SHOULD network. This document describes new options for DHCPv6 that SHOULD
be used for booting a node from the network. be used for booting a node from the network.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on January 27, 2011. 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.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions .....................................................3
3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Options .........................................................3
3.1. Boot File Uniform Resource Locator (URL) Option . . . . . 4 3.1. Boot File Uniform Resource Locator (URL) Option ............3
3.2. Boot File Parameters Option . . . . . . . . . . . . . . . 5 3.2. Boot File Parameters Option ................................4
3.3. Client System Architecture Type Option . . . . . . . . . . 6 3.3. Client System Architecture Type Option .....................5
3.4. Client Network Interface Identifier Option . . . . . . . . 7 3.4. Client Network Interface Identifier Option .................6
4. Appearance of the options . . . . . . . . . . . . . . . . . . 7 4. Appearance of the Options .......................................7
5. Download protocol considerations . . . . . . . . . . . . . . . 7 5. Download Protocol Considerations ................................7
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations .............................................7
7. Security considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations .........................................8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements ................................................8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References ......................................................9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References .......................................9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References .....................................9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This draft describes DHCPv6 options that SHOULD be used to provide This document describes DHCPv6 options that SHOULD be used to provide
configuration information for a node that must be booted using the configuration information for a node that must be booted using the
network, rather than from local storage. network rather than from local storage.
Network booting is used, for example, in some environments where Network booting is used, for example, in some environments where
administrators have to maintain a large number of nodes. By serving administrators have to maintain a large number of nodes. By serving
all boot and configuration files from a central server, the effort all boot and configuration files from a central server, the effort
required to maintain these nodes is greatly reduced. required to maintain these nodes is greatly reduced.
A typical boot file would be, for example, an operating system kernel 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 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 firmware running on the client node must perform the following two
steps (see Figure 1): First get all information which is required for steps (see Figure 1): First get all information that is required for
downloading and executing the boot file. Second, download the boot downloading and executing the boot file. Second, download the boot
file and execute it. file and execute it.
+------+ +------+
_______________________\| DHCP | _______________________\| DHCP |
/ 1 Get boot file info /|Server| / 1 Get boot file info /|Server|
+------+ +------+ +------+ +------+
| Host | | Host |
+------+ +------+ +------+ +------+
\_______________________\| File | \_______________________\| File |
2 Download boot file /|Server| 2 Download boot file /|Server|
+------+ +------+
Figure 1: Network Boot Sequence Figure 1: Network Boot Sequence
The information which is required for booting over the network MUST The information that is required for booting over the network MUST
include at least the details about the server on which the boot files 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 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 HTTP [RFC2616] or TFTP [RFC1350]), and the path and name of the boot
file on the server. Additionally, the server and client MAY exchange file on the server. Additionally, the server and client MAY exchange
information about the parameters which should be passed to the OS information about the parameters that should be passed to the OS
kernel or boot loader program respectively, or information about the kernel or boot-loader program, respectively, or information about the
supported boot environment. supported boot environment.
DHCPv6 allows client nodes to ask a DHCPv6 server for configuration DHCPv6 allows client nodes to ask a DHCPv6 server for configuration
parameters. This document provides new options which a client can parameters. This document provides new options that a client can
request from the DHCPv6 server to satisfy its requirements for request from the DHCPv6 server to satisfy its requirements for
booting. It also introduces a new IANA registry for processor booting. It also introduces a new IANA registry for processor
architecture types which are used by the OPTION_CLIENT_ARCH_TYPE architecture types that are used by the OPTION_CLIENT_ARCH_TYPE
option (see Section 3.3). option (see Section 3.3).
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Terminology specific to IPv6 and DHCPv6 are used in the same way as Terminology specific to IPv6 and DHCPv6 are used in the same way as
defined in the "Terminology" sections of [RFC3315]. is defined in the "Terminology" sections of [RFC3315].
3. Options 3. Options
Option formats comply with DHCPv6 options per [RFC3315] (section 6). Option formats comply with DHCPv6 options per [RFC3315] (Section 6).
The boot-file-url option (see Section 3.1) is mandatory for booting, The boot-file-url option (see Section 3.1) is mandatory for booting,
all other options are optional. all other options are optional.
3.1. Boot File Uniform Resource Locator (URL) Option 3.1. Boot File Uniform Resource Locator (URL) Option
The server sends this option to inform the client about an URL to a The server sends this option to inform the client about a URL to a
boot file. boot file.
0 1 2 3 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 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 | | OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. boot-file-url (variable length) . . boot-file-url (variable length) .
| | | |
skipping to change at page 4, line 34 skipping to change at page 4, line 4
0 1 2 3 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 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 | | OPT_BOOTFILE_URL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. boot-file-url (variable length) . . boot-file-url (variable length) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description: Format description:
option-code OPT_BOOTFILE_URL (TBD1). option-code OPT_BOOTFILE_URL (59).
option-len Length of the boot-file-url in octets. option-len Length of the boot-file-url in octets.
boot-file-url This string is the URL for the boot file. It MUST boot-file-url This string is the URL for the boot file. It MUST
comply with STD 66 [RFC3986]. The string is not comply with STD 66 [RFC3986]. The string is not
NUL-terminated. NUL-terminated.
If the host in the URL is expressed using an IPv6 address rather than 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 "[" a domain name, the address in the URL then MUST be enclosed in "["
and "]" characters, conforming to [RFC3986]. Clients that have DNS and "]" characters, conforming to [RFC3986]. Clients that have DNS
implementations SHOULD support the use of domain names in the URL. implementations SHOULD support the use of domain names in the URL.
3.2. Boot File Parameters Option 3.2. Boot File Parameters Option
This option is sent by the server to the client. It consists of This option is sent by the server to the client. It consists of
multiple UTF-8 ([RFC3629]) strings. They are used to specify multiple UTF-8 ([RFC3629]) strings. They are used to specify
parameters for the boot file (similar to the command line arguments parameters for the boot file (similar to the command line arguments
in most modern operating systems). For example, these parameters in most modern operating systems). For example, these parameters
could be used to specify the root file system of the OS kernel, or could be used to specify the root file system of the OS kernel, or
where a second stage boot loader can download its configuration file the location from which a second-stage boot-loader program can
from. download its configuration file.
0 1 2 3 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 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 | | OPT_BOOTFILE_PARAM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len 1 | | | param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. (variable length) | . (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 32 skipping to change at page 5, line 4
. (variable length) | . (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. <multiple Parameters> . . <multiple Parameters> .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | | | param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. (variable length) | . (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description: Format description:
option-code OPT_BOOTFILE_PARAM (TBD2). option-code OPT_BOOTFILE_PARAM (60).
option-len Length of the Boot File Parameters option in octets option-len Length of the Boot File Parameters option in octets
(not including the size of the option-code and (not including the size of the option-code and
option-len fields). option-len fields).
param-len 1...n This is a 16-bit integer which specifies the length param-len 1...n This is a 16-bit integer that specifies the length
of the following parameter in octets (not including of the following parameter in octets (not including
the parameter-length field). the parameter-length field).
parameter 1...n These UTF-8 strings are parameters needed for parameter 1...n These UTF-8 strings are parameters needed for
booting, e.g. kernel parameters. The strings are booting, e.g., kernel parameters. The strings are
not NUL-terminated. not NUL-terminated.
When the boot firmware executes the boot file which has been When the boot firmware executes the boot file that has been specified
specified in the OPT_BOOTFILE_URL option, it MUST pass these in the OPT_BOOTFILE_URL option, it MUST pass these parameters, if
parameters, if present, in the order that they appear in the present, in the order that they appear in the OPT_BOOTFILE_PARAM
OPT_BOOTFILE_PARAM option. option.
3.3. Client System Architecture Type Option 3.3. Client System Architecture Type Option
This option provides parity with the Client System Architecture Type This option provides parity with the Client System Architecture Type
Option defined for DHCPv4 in section 2.1 of [RFC4578]. option defined for DHCPv4 in Section 2.1 of [RFC4578].
The format of the option is: The format of the option is:
0 1 2 3 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 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 | | OPTION_CLIENT_ARCH_TYPE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. architecture-types (variable length) . . architecture-types (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_ARCH_TYPE (TBD3). option-code OPTION_CLIENT_ARCH_TYPE (61).
option-len Length of the "architecture-types" field in option-len Length of the "architecture-types" field in
octets. It MUST be an even number greater than octets. It MUST be an even number greater than
zero. See section 2.1 of [RFC4578] for details. zero. See Section 2.1 of [RFC4578] for details.
architecture-types A list of one or more architecture types, as architecture-types A list of one or more architecture types, as
specified in section 2.1 of [RFC4578]. Each specified in Section 2.1 of [RFC4578]. Each
architecture type identifier in this list is a architecture type identifier in this list is a
16-bit value which describes the pre-boot runtime 16-bit value that describes the pre-boot runtime
environment of the client machine. A list of environment of the client machine. A list of
valid values is maintained by the IANA (see valid values is maintained by the IANA (see
Section 6). Section 6).
The client MAY use this option to send a list of supported The client MAY use this option to send a list of supported
architecture types to the server, so the server can decide which boot architecture types to the server, so the server can decide which boot
file should be provided to the client. If a client supports more 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 than one pre-boot environment (for example, both 32-bit and 64-bit
executables), the most preferred architecture type MUST be listed as executables), the most preferred architecture type MUST be listed as
first item, followed by the others with descending priority. first item, followed by the others with descending priority.
If the client used this option in the request, the server SHOULD If the client used this option in the request, the server SHOULD
include this option to inform the client about the pre-boot include this option to inform the client about the pre-boot
environments which are supported by the boot file. The list MUST environments that are supported by the boot file. The list MUST only
only contain architecture types which have initially been queried by contain architecture types that have initially been queried by the
the client. The items MUST also be listed in order of descending client. The items MUST also be listed in order of descending
priority. priority.
3.4. Client Network Interface Identifier Option 3.4. Client Network Interface Identifier Option
If the client supports the Universal Network Device Interface (UNDI) If the client supports the Universal Network Device Interface (UNDI)
(see [PXE21] and [UEFI23]), it may send the Client Network Interface (see [PXE21] and [UEFI23]), it may send the Client Network Interface
Identifier option to a DHCP server to provide information about its Identifier option to a DHCP server to provide information about its
level of UNDI support. level of UNDI support.
This option provides parity with the Client Network Interface This option provides parity with the Client Network Interface
Identifier Option defined for DHCPv4 in section 2.2 of [RFC4578]. Identifier option defined for DHCPv4 in Section 2.2 of [RFC4578].
The format of the option is: The format of the option is:
0 1 2 3 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 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 | | OPTION_NII | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Major | Minor | | Type | Major | Minor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_NII (TBD4). option-code OPTION_NII (62).
option-len 3 option-len 3
Type As specified in section 2.2 of [RFC4578]. Type As specified in Section 2.2 of [RFC4578].
Major As specified in section 2.2 of [RFC4578]. Major As specified in Section 2.2 of [RFC4578].
Minor As specified in section 2.2 of [RFC4578]. Minor As specified in Section 2.2 of [RFC4578].
The list of valid Type, Major and Minor values is maintained in the The list of valid Type, Major, and Minor values is maintained in the
Unified Extensible Firmware Interface specification [UEFI23]. Unified Extensible Firmware Interface specification [UEFI23].
4. Appearance of the options 4. Appearance of the Options
These options MUST NOT appear in DHCPv6 messages other than the types These options MUST NOT appear in DHCPv6 messages other than the types
Solicit, Advertise, Request, Renew, Rebind, Information-Request and Solicit, Advertise, Request, Renew, Rebind, Information-Request, and
Reply. Reply.
The option-codes of these options MAY appear in the Option Request The option-codes of these options MAY appear in the Option Request
Option in the DHCPv6 message types Solicit, Request, Renew, Rebind, option in the DHCPv6 message types Solicit, Request, Renew, Rebind,
Information-Request and Reconfigure. Information-Request, and Reconfigure.
5. Download protocol considerations 5. Download Protocol Considerations
The Boot File URL option does not place any constraints on the The Boot File URL option does not place any constraints on the
protocol used for downloading the boot file, other than that it MUST 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 be possible to specify it in a URL. For the sake of administrative
simplicity, we strongly recommend that, at a mininum, implementors of simplicity, we strongly recommend that, at a minimum, implementers of
network boot loaders implement the well-known and established network boot loaders implement the well-known and established
hypertext transfer protocol [RFC2616] for downloading. Please note HyperText Transfer Protocol (HTTP) [RFC2616] for downloading. Please
that for IPv6, this supersedes [RFC906] which recommended to use TFTP note that for IPv6, this supersedes [RFC906], which recommended using
for downloading (see [RFC3617] for the 'tftp' URL definition). TFTP for downloading (see [RFC3617] for the 'tftp' URL definition).
When using iSCSI for booting, the 'iscsi' URI is formed as defined in When using the Internet Small Computer System Interface (iSCSI) for
[RFC4173]. The functionality attributed in RFC4173 to a root path booting, the 'iscsi' URI is formed as defined in [RFC4173]. The
option is provided for IPv6 by the Boot File URL option instead. functionality attributed in RFC 4173 to a root path option is
provided for IPv6 by the Boot File URL option instead.
6. IANA considerations 6. IANA Considerations
The following options need to be assigned by the IANA from the option The following options have been assigned by the IANA from the option
number space defined in the chapter 24 of the DHCPv6 RFC [RFC3315]. number space defined in Section 24 of the DHCPv6 RFC [RFC3315].
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
| Option name | Value | Specified in | | Option name | Value | Specified in |
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
| OPT_BOOTFILE_URL | TBD1 | Section 3.1 | | OPT_BOOTFILE_URL | 59 | Section 3.1 |
| OPT_BOOTFILE_PARAM | TBD2 | Section 3.2 | | OPT_BOOTFILE_PARAM | 60 | Section 3.2 |
| OPTION_CLIENT_ARCH_TYPE | TBD3 | Section 3.3 | | OPTION_CLIENT_ARCH_TYPE | 61 | Section 3.3 |
| OPTION_NII | TBD4 | Section 3.4 | | OPTION_NII | 62 | Section 3.4 |
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
This document also introduces a new IANA registry for processor This document also introduces a new IANA registry for processor
architecture types. The name of this registry shall be "Processor architecture types. The name of this registry is "Processor
Architecture Type". Registry entries consist of a 16-bit integer Architecture Types". Registry entries consist of a 16-bit integer
recorded in decimal format, and a descriptive name. The initial recorded in decimal format and a descriptive name. The initial
values of this registry can be found in [RFC4578] section 2.1. values of this registry can be found in [RFC4578], Section 2.1.
The assignment policy for values shall be Expert Review (see The assignment policy for values is through Expert Review (see
[RFC5226]), and any requests for values must supply the descriptive [RFC5226]), and any requests for values must supply the descriptive
name for the processor architecture type. name for the processor architecture type.
7. Security considerations 7. Security Considerations
In untrusted networks, a rogue DHCPv6 server could send the new In untrusted networks, a rogue DHCPv6 server could send the new
DHCPv6 options described in this document. The booting clients could DHCPv6 options described in this document. The booting clients could
then be provided with a wrong URL so that either the boot fails, or then be provided with a wrong URL so that either the boot fails or,
even worse, the client boots the wrong operating system which has even worse, the client boots the wrong operating system that has been
been provided by a malicious file server. To prevent this kind of provided by a malicious file server. To prevent this kind of attack,
attack, clients SHOULD use authentication of DHCPv6 messages (see clients SHOULD use authentication of DHCPv6 messages (see Section 21
chapter 21. in [RFC3315]). in [RFC3315]).
Note also that DHCPv6 messages are sent unencrypted by default. So Note also that DHCPv6 messages are sent unencrypted by default. So
the boot file URL options are sent unencrypted over the network, too. the boot file URL options are sent unencrypted over the network, too.
This can become a security risk since the URLs can contain sensitive This can become a security risk since the URLs can contain sensitive
information like user names and passwords (for example a URL like information like user names and passwords (for example, a URL like
"ftp://username:password@servername/path/file"). At the current "ftp://username:password@servername/path/file"). At the current
point in time, there is no possibility to send encrypted DHCPv6 point in time, there is no possibility to send encrypted DHCPv6
messages, so it is strongly RECOMMENDED not to use sensitive messages, so it is strongly RECOMMENDED not to use sensitive
information in the URLs in untrusted networks (using passwords in information in the URLs in untrusted networks (using passwords in
URLs is deprecated anyway according to [RFC3986]). URLs is deprecated anyway, according to [RFC3986]).
Even if the DHCPv6 transaction is secured, this does not protect Even if the DHCPv6 transaction is secured, this does not protect
against attacks on the boot file download channel. Consequently, we against attacks on the boot file download channel. Consequently, we
recommend that either protocols like HTTPS [RFC2818] or TLS within recommend that either (a) implementers use protocols like HTTPS
HTTP [RFC2817] are used to prevent spoofing, or that the boot loader [RFC2818] or Transport Layer Security (TLS) within HTTP [RFC2817] to
software implements a mechanism for signing boot images and a prevent spoofing or (b) the boot-loader software implement a
configurable signing key in memory, so that if a malicious image is mechanism for signing boot images and a configurable signing key.
provided, it can be detected and rejected. The latter is done so that if a malicious image is provided, it can
be detected and rejected.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton, The authors would like to thank Ruth Li, Dong Wei, Kathryn Hampton,
Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led Phil Dorah, Richard Chan, and Fiona Jensen for discussions that led
to this document. to this document.
The authors would also like to thank Ketan P. Pancholi, Alfred The authors would also like to thank Ketan P. Pancholi, Alfred
Hoenes, Gabriel Montenegro and Ted Lemon for corrections and Hoenes, Gabriel Montenegro, and Ted Lemon for corrections and
suggestions. suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[PXE21] Johnston, M., "Preboot Execution Environment (PXE) [PXE21] Johnston, M., "Preboot Execution Environment (PXE)
Specification", September 1999, Specification", September 1999,
<http://www.pix.net/software/pxeboot/archive/pxespec.pdf>. <http://www.pix.net/software/pxeboot/archive/pxespec.pdf>.
skipping to change at page 10, line 28 skipping to change at page 9, line 46
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[UEFI23] UEFI Forum, "Unified Extensible Firmware Interface [UEFI23] UEFI Forum, "Unified Extensible Firmware Interface
Specification, Version 2.3", May 2009, Specification, Version 2.3", May 2009,
<http://www.uefi.org/>. <http://www.uefi.org/>.
9.2. Informative References 9.2. Informative References
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
June 1984.
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992. RFC 1350, July 1992.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer Applicability Statement for the Trivial File Transfer
Protocol (TFTP)", RFC 3617, October 2003. Protocol (TFTP)", RFC 3617, October 2003.
[RFC906] Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
June 1984.
Authors' Addresses Authors' Addresses
Thomas H. Huth Thomas H. Huth
IBM Germany Research & Development GmbH IBM Germany Research & Development GmbH
Schoenaicher Strasse 220 Schoenaicher Strasse 220
Boeblingen 71032 Boeblingen 71032
Germany Germany
Phone: +49-7031-16-2183 Phone: +49-7031-16-2183
Email: thuth@de.ibm.com EMail: thuth@de.ibm.com
Jens T. Freimann Jens T. Freimann
IBM Germany Research & Development GmbH IBM Germany Research & Development GmbH
Schoenaicher Strasse 220 Schoenaicher Strasse 220
Boeblingen 71032 Boeblingen 71032
Germany Germany
Phone: +49-7031-16-1122 Phone: +49-7031-16-1122
Email: jfrei@de.ibm.com EMail: jfrei@de.ibm.com
Vincent Zimmer Vincent Zimmer
Intel Intel
2800 Center Drive 2800 Center Drive
DuPont WA 98327 DuPont WA 98327
USA USA
Phone: +1 253 371 5667 Phone: +1 253 371 5667
Email: vincent.zimmer@intel.com EMail: vincent.zimmer@intel.com
Dave Thaler Dave Thaler
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond WA 98052 Redmond WA 98052
USA USA
Phone: +1 425 703-8835 Phone: +1 425 703-8835
Email: dthaler@microsoft.com EMail: dthaler@microsoft.com
 End of changes. 67 change blocks. 
130 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/