draft-ietf-dhc-dhcpv6-opt-netboot-09.txt   draft-ietf-dhc-dhcpv6-opt-netboot-10.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: December 8, 2010 Development GmbH Expires: January 27, 2011 Development GmbH
V. Zimmer V. Zimmer
Intel Intel
D. Thaler D. Thaler
Microsoft Microsoft
June 6, 2010 July 26, 2010
DHCPv6 option for network boot DHCPv6 options for network boot
draft-ietf-dhc-dhcpv6-opt-netboot-09 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 which 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
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 December 8, 2010. This Internet-Draft will expire on January 27, 2011.
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
skipping to change at page 6, line 44 skipping to change at page 6, line 44
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 this If the client used this option in the request, the server SHOULD
option to inform the client about the pre-boot environments which are include this option to inform the client about the pre-boot
supported by the boot file. The list MUST only contain architecture environments which are supported by the boot file. The list MUST
types which have initially been queried by the client. The items only contain architecture types which have initially been queried by
MUST also be listed in order of descending priority. the client. The items MUST also be listed in order of descending
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].
skipping to change at page 8, line 4 skipping to change at page 8, line 4
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 the 'tftp' URL definition). for downloading (see [RFC3617] for the 'tftp' URL definition).
When using iSCSI for booting, the 'iscsi' URI is formed as defined in When using iSCSI for booting, the 'iscsi' URI is formed as defined 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.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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 shall be 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 the boot either 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 which has
been provided by a malicious file server. To prevent this kind of been provided by a malicious file server. To prevent this kind of
attack, clients SHOULD use authentication of DHCPv6 messages (see attack, clients SHOULD use authentication of DHCPv6 messages (see
chapter 21. in [RFC3315]). chapter 21. 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
 End of changes. 7 change blocks. 
12 lines changed or deleted 13 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/