home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit 2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Rfc / RFC1534.TXT < prev    next >
Encoding:
Text File  |  1999-11-04  |  6.8 KB  |  228 lines
  1. Network Working Group                                           R. Droms
  2. Request for Comments: 1534                           Bucknell University
  3. Category: Standards Track                                   October 1993
  4.  
  5.  
  6.                  Interoperation Between DHCP and BOOTP
  7.  
  8. Status of this Memo
  9.  
  10.    This RFC specifies an Internet standards track protocol for the
  11.    Internet community, and requests discussion and suggestions for
  12.    improvements.  Please refer to the current edition of the "Internet
  13.    Official Protocol Standards" for the standardization state and status
  14.    of this protocol.  Distribution of this memo is unlimited.
  15.  
  16. Abstract
  17.  
  18.    DHCP provides a superset of the functions provided by BOOTP. This
  19.    document describes the interactions between DHCP and BOOTP network
  20.    participants.
  21.  
  22. 1. Introduction
  23.  
  24.    The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
  25.    for transmitting configuration parameters to hosts using the TCP/IP
  26.    protocol suite.  The format of DHCP messages is based on the format
  27.    of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP
  28.    participants may exchange messages.  This document specifies the ways
  29.    in which DHCP and BOOTP participants may interoperate.
  30.  
  31.    DHCP introduces a small change in terminology intended to clarify the
  32.    meaning of one of the fields.  What was the "vendor extensions" field
  33.    in BOOTP has been re-named the "options" field in DHCP.  Similarly,
  34.    the tagged data items that were used inside the BOOTP "vendor
  35.    extensions" field, which were formerly referred to as "vendor
  36.    extensions", are now termed simply "options".  This document will
  37.    refer to BOOTP vendor extensions and DHCP options uniformly as
  38.    "options".
  39.  
  40.    Throughout this document, DHCP messages that include a 'DHCP message
  41.    type' option will be referred to by the type of the message; e.g., a
  42.    DHCP message with 'DHCP message type' option type 1 will be referred
  43.    to as a "DHCPDISCOVER" message.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Droms                                                           [Page 1]
  53.  
  54.  
  55. RFC 1534         Interoperation Between DHCP and BOOTP      October 1993
  56.  
  57.  
  58. 2. BOOTP clients and DHCP servers
  59.  
  60.    The format of DHCP messages is defined to be compatible with the
  61.    format of BOOTP messages, so that existing BOOTP clients can
  62.    interoperate with DHCP servers.  Any message received by a DHCP
  63.    server that includes a 'DHCP message type' (51) option is assumed to
  64.    have been sent by a DHCP client.  Messages without the DHCP Message
  65.    Type option are assumed to have been sent by a BOOTP client.  Support
  66.    of BOOTP clients by a DHCP server is optional at the discretion of
  67.    the local system administrator.  If a DHCP server that is not
  68.    configured to support BOOTP clients receives a BOOTREQUEST message
  69.    from a BOOTP client, that server silently discards the BOOTREQUEST
  70.    message.
  71.  
  72.    If a DHCP server is configured to support BOOTP clients, it may be
  73.    configured to supply static addresses, automatic addresses or both.
  74.    Static addresses are those that have been previously assigned by a
  75.    system administrator and are stored in a database available to the
  76.    DHCP server.  Automatic addresses are those selected by the DHCP
  77.    server from its pool of unassigned addresses.
  78.  
  79.    Since BOOTP clients may not be prepared to receive automatic
  80.    addresses, the decision to allow a DHCP server to return automatic
  81.    addresses must be under the control of the system administrator.  If
  82.    a DHCP server supports supplying automatic addresses to BOOTP
  83.    clients, this feature must be configurable, and the feature must
  84.    default off.  Enabling of the feature must be the result of an active
  85.    decision by the system administrator.
  86.  
  87.    If a DHCP server returns a automatic address, the BOOTP client will
  88.    not be aware of the DHCP lease mechanism for network address
  89.    assignment.  Thus the DHCP server must assign an infinite lease
  90.    duration to for automatic addresses assigned to BOOTP clients.  Such
  91.    network addresses cannot be automatically reassigned by the server.
  92.    The local system administrator may choose to manually release network
  93.    addresses assigned to BOOTP clients.
  94.  
  95.    A DHCP server that supports BOOTP clients MUST interact with BOOTP
  96.    clients according to the BOOTP protocol.  The server MUST formulate a
  97.    BOOTP BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e.,
  98.    the server MUST NOT include the 'DHCP message type' option and MUST
  99.    NOT exceed the size limit for BOOTREPLY messages).  The server marks
  100.    a binding for a BOOTP client as BOUND after sending the BOOTP
  101.    BOOTREPLY, as a non-DHCP client will not send a DHCPREQUEST message
  102.    nor will that client expect a DHCPACK message.
  103.  
  104.    DHCP servers MAY send any DHCP Options to a BOOTP client as allowed
  105.    by the "DHCP Options and BOOTP Vendor Extensions" RFC [2].
  106.  
  107.  
  108.  
  109. Droms                                                           [Page 2]
  110.  
  111.  
  112. RFC 1534         Interoperation Between DHCP and BOOTP      October 1993
  113.  
  114.  
  115.    In summary, a DHCP server:
  116.  
  117.       o MAY support BOOTP clients,
  118.  
  119.       o May return automatic addresses to BOOTP clients,
  120.  
  121.       o MUST provide a configuration switch if returning automatic
  122.         addresses to BOOTP clients,
  123.  
  124.       o MUST default this optional configuration to OFF,
  125.  
  126.       o MUST abide by the BOOTP specification when interacting with
  127.         BOOTP clients, and
  128.  
  129.       o MAY send DHCP options (those options defined in the DHCP options
  130.         document but not in the BOOTP vendor extensions documents) to
  131.         a BOOTP client.
  132.  
  133. 3. DHCP clients and BOOTP servers
  134.  
  135.    A DHCP client MAY use a reply from a BOOTP server if the
  136.    configuration returned from the BOOTP server is acceptable to the
  137.    DHCP client.  A DHCP client MUST assume that an IP address returned
  138.    in a message from a BOOTP server has an infinite lease.  A DHCP
  139.    client SHOULD choose to use a reply from a DHCP server in preference
  140.    to a reply from a BOOTP server.
  141.  
  142. 4. References
  143.  
  144.    [1] Wimer, W., "Clarifications and Extensions for the Bootstrap
  145.        Protocol", RFC 1532, Carnegie Mellon University, October 1993.
  146.  
  147.    [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
  148.        Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
  149.        University, October 1993.
  150.  
  151.    [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
  152.        Bucknell University, October 1993.
  153.  
  154.  
  155. 5. Security Considerations
  156.  
  157.    Security issues are not discussed in this memo.
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Droms                                                           [Page 3]
  167.  
  168.  
  169. RFC 1534         Interoperation Between DHCP and BOOTP      October 1993
  170.  
  171.  
  172. 6. Author's Address
  173.  
  174.    Ralph Droms
  175.    Computer Science Department
  176.    323 Dana Engineering
  177.    Bucknell University
  178.    Lewisburg, PA 17837
  179.  
  180.    Phone:(717) 524-1145
  181.    EMail: droms@bucknell.edu
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Droms                                                           [Page 4]
  224.  
  225.  
  226.  
  227.  
  228.