HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:07:36 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 14 Aug 1998 13:03:00 GMT ETag: "361fc4-1fac-35d43584" Accept-Ranges: bytes Content-Length: 8108 Connection: close Content-Type: text/plain 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 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: 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