home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-madan-00.txt < prev    next >
Text File  |  1997-10-10  |  8KB  |  244 lines

  1.  
  2. INTERNET DRAFT        EXPIRES APR 1998        INTERNET DRAFT
  3.  
  4. Network Working Group                                   Bharat Madan, IBM
  5. INTERNET DRAFT                                                 Sept. 1997
  6. Category: Informational
  7.  
  8.  
  9.  
  10.               The Boot Selection Menu Option for BOOTP/DHCP
  11.                     <draft-rfced-info-madan-00.txt>
  12.  
  13. Status of This Memo
  14.  
  15. This document is an Internet-Draft.  Internet-Drafts are working
  16. documents of the Internet Engineering Task Force (IETF), its
  17. areas, and its working groups.  Note that other groups may also
  18. distribute working documents as Internet-Drafts.
  19.  
  20. Internet-Drafts are draft documents valid for a maximum of six
  21. months and may be updated, replaced, or obsoleted by other
  22. documents at any time.  It is inappropriate to use Internet-
  23. Drafts as reference material or to cite them other than as
  24. "work in progress."
  25.  
  26. To learn the current status of any Internet-Draft, please check
  27. the "1id-abstracts.txt" listing contained in the Internet-
  28. Drafts Shadow Directories on ftp.is.co.za (Africa),
  29. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  30. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  31.  
  32. Distribution of this document is unlimited.
  33.  
  34. 1.0  Abstract
  35.  
  36.    The BOOTP [1] or the Dynamic Host Configuration Protocol (DHCP) [2]
  37.    provide a framework for booting a host over a network from a remote
  38.    server. This document defines a new option which a BOOTP/DHCP client
  39.    may include in its BOOTP request or DHCPDISCOVER message. In their
  40.    replies, the  recipient servers may include this option  along with
  41.    the location/path information to a file ('boot.info') in the option
  42.    field. The client may use the contents of this file to select the
  43.    desired  OS  with which to boot along with the location/path of the
  44.    appropriate boot image file.
  45.  
  46. 2.0 Introduction
  47.  
  48.    BOOTP/DHCP Client and server may negotiate several possible options.
  49.    RFC 1533 [3] provides the current list of these options. With the
  50.    increasing popularity of NETWORK COMPUTERS, THIN CLIENTS and other
  51.    diskless hosts, it is relevant to give such clients the capability
  52.    of booting with a variety of OSs. The proposed option makes this
  53.    feasible, without disturbing the present functionality of BOOTP
  54.    or DCHP protocols.
  55.  
  56.  
  57. 3.0  Definitions
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Madan          draft-ietf-boot/dhcp-select-boot-00.txt              [Page 1]
  64.  
  65.  
  66.  
  67.  
  68.  
  69. INTERNET DRAFT                                                 July 1997
  70.  
  71.  
  72.    Throughout this document, the words that are used to define the
  73.    significance of the particular requirements are capitalized.  These
  74.    words are:
  75.  
  76.       MUST
  77.  
  78.            This word or the adjective "REQUIRED" means that the item is
  79.            an absolute requirement of this specification.
  80.  
  81.       MUST NOT
  82.  
  83.            This phrase means the item is an absolute prohibition of this
  84.            specification.
  85.  
  86.       SHOULD
  87.  
  88.            This word or the adjective "RECOMMENDED" means that there may
  89.            exist valid reasons in particular circumstances to ignore
  90.            this item, but the full implications should be understood and
  91.            the case carefully weighed before choosing a different
  92.            course.
  93.  
  94.       SHOULD NOT
  95.  
  96.            This phrase means that there may exist valid reasons in
  97.            particular circumstances when the listed behavior is
  98.            acceptable or even useful, but the full implications should
  99.            be understood and the case carefully weighted before
  100.            implementing any behavior described with this label.
  101.  
  102.       MAY
  103.  
  104.            This word or the adjective "OPTIONAL" means that this item is
  105.            truly optional.  One vendor may choose to include the item
  106.            because a particular marketplace requires it or because it
  107.            enhances the product, for example, another vendor may omit
  108.            the same item.
  109.  
  110.    This document also uses the following terms:
  111.  
  112.  
  113.       o "BOOTP/DHCP client"
  114.  
  115.            BOOTP/DHCP client or "client" is an Internet host using
  116.            BOOTP or DHCP to obtain booting information and
  117.            configuration parameters such as a network address.
  118.  
  119.       o "BOOTP/DHCP server"
  120.  
  121.            A BOOTP or DHCP server of "server"is an Internet host
  122.            that returns booting information and
  123.  
  124.  
  125.  
  126. Madan          draft-ietf-boot/dhcp-select-boot-00.txt              [Page 2]
  127.  
  128.  
  129.  
  130.  
  131.  
  132. INTERNET DRAFT                                                 July 1997
  133.  
  134.  
  135.            configuration parameters to DHCP clients.
  136.  
  137.  
  138. 3.0  Boot selection menu option
  139.  
  140.    The code for this option is TBD, and its minimum length is 2 bytes.
  141.  
  142.              Code     Len      n-byte long ASCII string
  143.            +-------+-------+-------+-------+-------+-------+--
  144.            |  TBD  |   n   |       |       |       |       |
  145.            +-------+-------+-------+-------+-------+-------+--
  146.  
  147.  
  148. 4.0  BOOTP/DHCP client/server Behavior
  149.  
  150.     A BOOTP/DHCP client broadcasts a REQUEST/DHCPDISCOVER datagram.
  151.     This datagram includes the new option in its option field:
  152.  
  153.              Code     Len
  154.            +-------+-------+
  155.            |  TBD  |   1   |
  156.            +-------+-------+
  157.  
  158.     One or more servers will respond to this request. Servers MAY
  159.     include this option in their responses. If a response contains
  160.     this option, then the option part of this response data gram
  161.     SHOULD look like as shown below:
  162.  
  163.              Code     Len      n-byte long ASCII string
  164.            +-------+-------+-------+-------+-------+-------+--
  165.            |  TBD  |   n   |       |       |       |       |
  166.            +-------+-------+-------+-------+-------+-------+--
  167.  
  168.     The client SHOULD interpret the n-byte long ASCII string as follows:
  169.  
  170.               'filename:OS1:OS2:...OSk'
  171.  
  172.     where,':' is used as a parsing de-limilter and OS1, OS2,..., OSk
  173.     are the accepted names of the OSs that this server can offer.
  174.     It is however, not mendatory to include the list of OSs. The purpose
  175.     of this that it MAY be used by a DHCP client as an additional
  176.     criterion for making a decision about choosing a particular DHCP
  177.     server. On the server side, the file 'filename' MUST contain boot
  178.     menu information as explained in the next paragraph.
  179.  
  180.          In case of the DHCP, client evaluates various responses offered
  181.     by the DHCP servers and selects a particular server. As explained
  182.     in the previous paragraph, this evaluation MAY now include an
  183.     additional criterion, viz. the list of OSs being offered. In case
  184.     of the BOOTP, there is deemed to be only one server. Therefore,
  185.     BOOTP clients MAY ignore the OSs list. A client SHOULD next retrieve
  186.     the file 'filename' using the TFTP. This file SHOULD contain tuples
  187.     of information. Each of these tuples SHOULD be of the type:
  188.  
  189.                    <OS name, boot file image name/location>
  190.  
  191.     For simplifying the parsing of this file, these tuples SHOULD
  192.     appear on a separate lines.
  193.  
  194.          After receiving this file, a client SHOULD display a
  195.     boot-manager like menu using the OS name field of these tuples.
  196.     Client SHOULD now make a choice within, say, 5-secs. Based on this
  197.  
  198.  
  199.  
  200. Madan          draft-ietf-boot/dhcp-select-boot-00.txt              [Page 3]
  201.  
  202.  
  203.     choice, the client MUST next retrieve the associated boot image
  204.     file using the TFTP. In case client user does not make a choice
  205.     within this time interval, client MAY behave as if this new option
  206.     does not exist.
  207.  
  208.  
  209. 5.0  Security Considerations
  210.  
  211.    DHCP currently provides no authentication or security mechanisms.
  212.    Potential exposures to attack are discussed in section 7 of the DHCP
  213.    protocol specification [1].
  214.  
  215.  
  216.  
  217. 6.0  References
  218.  
  219.    [RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap
  220.              Protocol"
  221.  
  222.    [RFC1541] R. Droms, "Dynamic Host Configuration Protocol"
  223.  
  224.    [RFC1533] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
  225.              extensions"
  226.  
  227.  
  228. 7.0  Acknowledgments
  229.  
  230.  
  231.  
  232. 8.0  Author Information
  233.  
  234. Bharat B. Madan
  235. IBM, Inc.
  236. 4205 S.Miami Blvd
  237. Research Triangle Park, NC 27709
  238. Phone: (919)254-5985
  239. email: bmadan@vnet.ibm.com
  240.  
  241. INTERNET DRAFT        EXPIRES APR 1998        INTERNET DRAFT
  242.  
  243.  
  244.