draft-ietf-dhc-dhcpv6-opt-netboot-07.txt   draft-ietf-dhc-dhcpv6-opt-netboot-08.txt 
DHC T. Huth DHC T. Huth
Internet-Draft J. Freimann Internet-Draft J. Freimann
Intended status: Standards Track IBM Germany Research & Intended status: Standards Track IBM Germany Research &
Expires: June 22, 2010 Development GmbH Expires: July 8, 2010 Development GmbH
V. Zimmer V. Zimmer
Intel Intel
D. Thaler D. Thaler
Microsoft Microsoft
December 19, 2009 January 4, 2010
DHCPv6 option for network boot DHCPv6 option for network boot
draft-ietf-dhc-dhcpv6-opt-netboot-07 draft-ietf-dhc-dhcpv6-opt-netboot-08
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 are network. This document describes new options for DHCPv6 which are
required for booting a node from the network. required for booting a node from the network.
Status of this Memo Status of this Memo
skipping to change at page 1, line 44 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2010. This Internet-Draft will expire on July 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This draft describes DHCPv6 options that can be used to provide This draft describes DHCPv6 options that can 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 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 (BIOS) running on the client node must perform the following firmware (BIOS) running on the client node must perform the following
two steps (see Figure 1): First get all information which is required two steps (see Figure 1): First get all information which is required
for downloading and executing the boot file. Second, download the for downloading and executing the boot file. Second, download the
boot file and execute it. boot file and execute it.
+------+ +------+
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 RFC 3315 [RFC3315]. defined in the "Terminology" sections of RFC 3315 [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).
3.1. Boot File Uniform Resource Locator (URL) Option 3.1. Boot File Uniform Resource Locator (URL) Option
This option consists of an UTF-8 string. It is sent by the server to The server sends this option to inform the client about an URL to a
inform the client about an 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) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description: Format description:
option-code OPT_BOOTFILE_URL (TBD1). option-code OPT_BOOTFILE_URL (TBD1).
option-len Length of the Boot File URL option in octets (not option-len Length of the boot-file-url in octets.
including the size of the option-code and option-
len fields).
boot-file-url This UTF-8 string is the URL for the boot file, as boot-file-url This string is the URL for the boot file. It MUST
defined in [RFC3986]. The string is not NUL- comply with STD 66 [RFC3986]. The string is not
terminated. NUL-terminated.
If the URL is expressed using an IPv6 address rather than a domain If the URL is expressed using an IPv6 address rather than a domain
name, the address in the URL then MUST be enclosed in "[" and "]" name, the address in the URL then MUST be enclosed in "[" and "]"
characters, conforming to [RFC3986]. Clients that have DNS 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 strings. They are used to specify parameters for the multiple UTF-8 strings. They are used to specify parameters for the
skipping to change at page 5, line 50 skipping to change at page 5, line 48
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 which has been
specified in the OPT_BOOTFILE_URL option, it MUST pass these specified in the OPT_BOOTFILE_URL option, it MUST pass these
parameters in the order that they appear in the OPT_BOOTFILE_PARAM parameters in the order that they appear in the 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 [RFC4578] section 2.1. 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 (TBD3).
option-len Length of the "processor architecture type" field option-len Length of the "architecture-types" field in
in octets (not including the option-code and octets. It MUST be an even number greater than
option-len fields). It MUST be an even number zero. See section 2.1 of [RFC4578] for details.
greater than zero. See [RFC4578] section 2.1 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 [RFC4578] section 2.1. 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 which 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 can use this option to send a list of supported The client can 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 clients supports more file should be provided to the client. If a client supports more
than one pre-boot environments (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.
The server can use this option to inform the client about the pre- The server can use this option to inform the client about the pre-
boot environments which are supported by the boot file. The list boot environments which are supported by the boot file. The list
MUST only contain architecture types which have initially been MUST only contain architecture types which have initially been
queried by the client. The items MUST also be listed in order of queried by the client. The items MUST also be listed in order of
descending priority. descending priority.
3.4. Client Network Interface Identifier Option 3.4. Client Network Interface Identifier Option
The Client Network Interface Identifier option is sent by a DHCP If the client supports the Universal Network Device Interface (UNDI)
client to a DHCP server to provide information about its level of (see [PXE21] and [UEFI23]), it may send the Client Network Interface
Universal Network Device Interface (UNDI) support (see also [PXE21] Identifier option to a DHCP server to provide information about its
and [UEFI23]). 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 [RFC4578] section 2.2. 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 (TBD4).
option-len 3 option-len 3
Type As specified in [RFC4578] section 2.2. Type As specified in section 2.2 of [RFC4578].
Major As specified in [RFC4578] section 2.2. Major As specified in section 2.2 of [RFC4578].
Minor As specified in [RFC4578] section 2.2. 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
UEFI 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 mininum, implementors 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 [RFC2616] for downloading. Please note
that for IPv6, this supersedes [RFC906] which recommended to use TFTP that for IPv6, this supersedes [RFC906] which recommended to use TFTP
for downloading (see [RFC3617] for TFTP URL definition). for downloading (see [RFC3617] for the 'tftp' URL definition).
When using iSCSI for booting, the "iscsi:"-URI is formed as defined When using iSCSI for booting, the 'iscsi' URI is formed as defined in
in [RFC4173]. The functionality attributed in RFC4173 to a root path [RFC4173]. The functionality attributed in RFC4173 to a root path
option is provided for IPv6 by the Boot File URL option instead. 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 need to be assigned by the IANA from the option
number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315]. number space defined in the chapter 22 of the DHCPv6 RFC [RFC3315].
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
| Option name | Value | Specified in | | Option name | Value | Specified in |
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
 End of changes. 22 change blocks. 
37 lines changed or deleted 33 lines changed or added

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