draft-ietf-dhc-dhcpv6-opt-netboot-05.txt   draft-ietf-dhc-dhcpv6-opt-netboot-06.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: February 11, 2010 Development GmbH Expires: April 29, 2010 Development GmbH
V. Zimmer V. Zimmer
Intel Intel
D. Thaler D. Thaler
Microsoft Microsoft
August 10, 2009 October 26, 2009
DHCPv6 option for network boot DHCPv6 option for network boot
draft-ietf-dhc-dhcpv6-opt-netboot-05 draft-ietf-dhc-dhcpv6-opt-netboot-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 February 11, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Boot File Uniform Resource Locator (URL) Option . . . . . 4 3.1. Boot File Uniform Resource Locator (URL) Option . . . . . 4
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 . . . . . . . . . . . . . . . . . . 8 4. Appearance of the options . . . . . . . . . . . . . . . . . . 7
5. Download protocol considerations . . . . . . . . . . . . . . . 8 5. Download protocol considerations . . . . . . . . . . . . . . . 7
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security considerations . . . . . . . . . . . . . . . . . . . 9 7. Security considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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 central server, the effort
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 US-ASCII string. It is used to convey an This option consists of an UTF-8 string. It is used to convey an URL
URL to a boot file. to a 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | bootfile-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 bootfile URL option in octets (not option-len Length of the Boot File URL option in octets (not
including the size of the option-code and option- including the size of the option-code and option-
len fields). len fields).
precedence A single unsigned octet indicating the order in boot-file-url This UTF-8 string is the URL for the boot file, as
which this URL should be processed, if more than defined in [RFC3986]. The string is not NUL-
one URL appears in the message.
bootfile-url This US-ASCII string is the URL for the boot file,
as defined in [RFC3986]. The string is not NUL-
terminated. terminated.
The node identifier in the URL must be reachable using IPv6. If the If the URL is expressed using an IPv6 address rather than a domain
URL is expressed using an IPv6 address rather than a domain name, the name, the address in the URL then MUST be enclosed in "[" and "]"
address in the URL then MUST be enclosed in "[" and "]" characters, characters, conforming to [RFC3986]. Clients that have DNS
conforming to [RFC3986]. Clients that have DNS implementations implementations should support the use of domain names in the URL.
should support the use of domain names in the URL.
Multiple occurrences of OPT_BOOTFILE_URL MAY be present in a single
DHCP message. Clients MUST process them according to the value of
the precedence field - the lowest precedence should be processed
first. If this fails, then the second-lowest should be used, and so
on.
Servers SHOULD NOT send two Bootfile URL options with the same
precedence. Clients receiving more than one OPT_BOOTFILE_URL option
with the same precedence SHOULD discard any extra such options. The
order in which the client processes options is not specified, and
therefore server implementations cannot assume that the client will
discard a particular such option.
The value of the precedence field MUST NOT be zero.
3.2. Boot File Parameters Option 3.2. Boot File Parameters Option
This option consists of multiple US-ASCII strings. They are used to This option consists of multiple UTF-8 strings. They are used to
specify parameters for the boot file (e.g. parameters for the kernel specify parameters for the boot file (similar to the command line
or boot loader program). arguments in most modern operating systems). For example, these
parameters 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 from.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | param-len 1 | parameter 1 | | param-len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter 1 .
. length) | . (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. <multiple Parameters> . . <multiple Parameters> .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| param-len n | parameter n | | param-len n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable length) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter n .
. | . (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format description: Format description:
option-code OPT_BOOTFILE_PARAM (TBD2). option-code OPT_BOOTFILE_PARAM (TBD2).
option-len Length of the bootfile 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).
precedence A one-octet quantity indicating the bootfile-url
option to which this set of parameters applies.
param-len 1...n This is a 16-bit integer which specifies the length param-len 1...n This is a 16-bit integer which 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).
parameters 1...n These US-ASCII 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.
The firmware MUST pass these parameters in the order they appear in The firmware MUST pass these parameters in the order they appear in
the OPT_BOOTFILE_PARAM option to the boot file which has been the OPT_BOOTFILE_PARAM option to the boot file which has been
specified in the OPT_BOOTFILE_URL option. specified in the OPT_BOOTFILE_URL option.
Multiple occurrences of OPT_BOOTFILE_PARAM MAY be present in a single
DHCP message. Clients MUST process them according to the value of
the precedence field:
o If the precedence field of the Bootfile Parameters option is zero,
the client SHOULD provide these parameters when it attempts to
execute any Bootfile it has loaded using any of the provided
Bootfile URL options.
o If the precedence field of the Bootfile Parameters option is
nonzero, the client SHOULD provide these parameters only when it
attempts to execute a Bootfile it loaded using a Bootfile URL
option with a precedence field that has the same value.
o In the event that the client receives both a Bootfile Parameters
option with a precedence field of zero and one with a precedence
field that matches a certain Bootfile URL option, the client MUST
use the Bootfile Parameters option whose predence matches the
precedence of the Bootfile URL 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 [RFC4578] section 2.1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 22 skipping to change at page 7, line 25
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 Bootfile 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 Bootfile, 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 (HTTP, see [RFC2616]) for downloading. hypertext transfer protocol (HTTP, see [RFC2616]) for downloading.
Please note that for IPv6, this supersedes [RFC906] which recommended Please note that for IPv6, this supersedes [RFC906] which recommended
to use TFTP for downloading (see [RFC3617] for TFTP URL definition). to use TFTP for downloading (see [RFC3617] for 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 [RFC4173]. The functionality attributed in RFC4173 to a root path in [RFC4173]. The functionality attributed in RFC4173 to a root path
option is provided for IPv6 by the bootfile 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 |
+-------------------------+-------+--------------+ +-------------------------+-------+--------------+
| OPT_BOOTFILE_URL | TBD1 | Section 3.1 | | OPT_BOOTFILE_URL | TBD1 | Section 3.1 |
skipping to change at page 9, line 35 skipping to change at page 8, line 37
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. information in the URLs in untrusted networks.
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 bootfile download channel. Consequently, we against attacks on the boot file download channel. Consequently, we
recommend that either a protocol like HTTPS (see [RFC2817] and recommend that either a protocol like HTTPS (see [RFC2817] and
[RFC2818]) be used to prevent spoofing, or that the boot loader [RFC2818]) be used to prevent spoofing, or that the boot loader
implementation implement a mechanism for signing boot images and a implementation implement a mechanism for signing boot images and a
configurable signing key in memory, so that if a malicious image is configurable signing key in memory, so that if a malicious image is
provided, it can be detected and rejected. 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
 End of changes. 20 change blocks. 
86 lines changed or deleted 46 lines changed or added

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