INTERNET DRAFT EXPIRES APR 1998 INTERNET DRAFT
Network Working Group Bharat Madan, IBM
INTERNET DRAFT Sept. 1997
Category: Informational
The Boot Selection Menu Option for BOOTP/DHCP
<draft-rfced-info-madan-00.txt>
Status of This Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
1.0 Abstract
The BOOTP [1] or the Dynamic Host Configuration Protocol (DHCP) [2]
provide a framework for booting a host over a network from a remote
server. This document defines a new option which a BOOTP/DHCP client
may include in its BOOTP request or DHCPDISCOVER message. In their
replies, the recipient servers may include this option along with
the location/path information to a file ('boot.info') in the option
field. The client may use the contents of this file to select the
desired OS with which to boot along with the location/path of the
appropriate boot image file.
2.0 Introduction
BOOTP/DHCP Client and server may negotiate several possible options.
RFC 1533 [3] provides the current list of these options. With the
increasing popularity of NETWORK COMPUTERS, THIN CLIENTS and other
diskless hosts, it is relevant to give such clients the capability
of booting with a variety of OSs. The proposed option makes this
feasible, without disturbing the present functionality of BOOTP
or DCHP protocols.
3.0 Definitions
Madan draft-ietf-boot/dhcp-select-boot-00.txt [Page 1]
INTERNET DRAFT July 1997
Throughout this document, the words that are used to define the
significance of the particular requirements are capitalized. These
words are:
MUST
This word or the adjective "REQUIRED" means that the item is
an absolute requirement of this specification.
MUST NOT
This phrase means the item is an absolute prohibition of this
specification.
SHOULD
This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore
this item, but the full implications should be understood and
the case carefully weighed before choosing a different
course.
SHOULD NOT
This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighted before
implementing any behavior described with this label.
MAY
This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example, another vendor may omit
the same item.
This document also uses the following terms:
o "BOOTP/DHCP client"
BOOTP/DHCP client or "client" is an Internet host using
BOOTP or DHCP to obtain booting information and
configuration parameters such as a network address.
o "BOOTP/DHCP server"
A BOOTP or DHCP server of "server"is an Internet host
that returns booting information and
Madan draft-ietf-boot/dhcp-select-boot-00.txt [Page 2]
INTERNET DRAFT July 1997
configuration parameters to DHCP clients.
3.0 Boot selection menu option
The code for this option is TBD, and its minimum length is 2 bytes.
Code Len n-byte long ASCII string
+-------+-------+-------+-------+-------+-------+--
| TBD | n | | | | |
+-------+-------+-------+-------+-------+-------+--
4.0 BOOTP/DHCP client/server Behavior
A BOOTP/DHCP client broadcasts a REQUEST/DHCPDISCOVER datagram.
This datagram includes the new option in its option field:
Code Len
+-------+-------+
| TBD | 1 |
+-------+-------+
One or more servers will respond to this request. Servers MAY
include this option in their responses. If a response contains
this option, then the option part of this response data gram
SHOULD look like as shown below:
Code Len n-byte long ASCII string
+-------+-------+-------+-------+-------+-------+--
| TBD | n | | | | |
+-------+-------+-------+-------+-------+-------+--
The client SHOULD interpret the n-byte long ASCII string as follows:
'filename:OS1:OS2:...OSk'
where,':' is used as a parsing de-limilter and OS1, OS2,..., OSk
are the accepted names of the OSs that this server can offer.
It is however, not mendatory to include the list of OSs. The purpose
of this that it MAY be used by a DHCP client as an additional
criterion for making a decision about choosing a particular DHCP
server. On the server side, the file 'filename' MUST contain boot
menu information as explained in the next paragraph.
In case of the DHCP, client evaluates various responses offered
by the DHCP servers and selects a particular server. As explained
in the previous paragraph, this evaluation MAY now include an
additional criterion, viz. the list of OSs being offered. In case
of the BOOTP, there is deemed to be only one server. Therefore,
BOOTP clients MAY ignore the OSs list. A client SHOULD next retrieve
the file 'filename' using the TFTP. This file SHOULD contain tuples
of information. Each of these tuples SHOULD be of the type:
<OS name, boot file image name/location>
For simplifying the parsing of this file, these tuples SHOULD
appear on a separate lines.
After receiving this file, a client SHOULD display a
boot-manager like menu using the OS name field of these tuples.
Client SHOULD now make a choice within, say, 5-secs. Based on this
Madan draft-ietf-boot/dhcp-select-boot-00.txt [Page 3]
choice, the client MUST next retrieve the associated boot image
file using the TFTP. In case client user does not make a choice
within this time interval, client MAY behave as if this new option
does not exist.
5.0 Security Considerations
DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification [1].
6.0 References
[RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap
Protocol"
[RFC1541] R. Droms, "Dynamic Host Configuration Protocol"
[RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
extensions"
7.0 Acknowledgments
8.0 Author Information
Bharat B. Madan
IBM, Inc.
4205 S.Miami Blvd
Research Triangle Park, NC 27709
Phone: (919)254-5985
email: bmadan@vnet.ibm.com
INTERNET DRAFT EXPIRES APR 1998 INTERNET DRAFT