RFC1534 Interoperation Between DHCP and BOOTP

1534 Interoperation Between DHCP and BOOTP. R. Droms. October 1993. (Format: TXT=6966 bytes) (Status: DRAFT STANDARD)

日本語訳
RFC一覧

参照

Network Working Group                                           R. Droms
Request for Comments: 1534                           Bucknell University
Category: Standards Track                                   October 1993


                 Interoperation Between DHCP and BOOTP

Status of this Memo

   This RFC specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Abstract

   DHCP provides a superset of the functions provided by BOOTP. This
   document describes the interactions between DHCP and BOOTP network
   participants.

1. Introduction

   The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
   for transmitting configuration parameters to hosts using the TCP/IP
   protocol suite.  The format of DHCP messages is based on the format
   of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP
   participants may exchange messages.  This document specifies the ways
   in which DHCP and BOOTP participants may interoperate.

   DHCP introduces a small change in terminology intended to clarify the
   meaning of one of the fields.  What was the "vendor extensions" field
   in BOOTP has been re-named the "options" field in DHCP.  Similarly,
   the tagged data items that were used inside the BOOTP "vendor
   extensions" field, which were formerly referred to as "vendor
   extensions", are now termed simply "options".  This document will
   refer to BOOTP vendor extensions and DHCP options uniformly as
   "options".

   Throughout this document, DHCP messages that include a 'DHCP message
   type' option will be referred to by the type of the message; e.g., a
   DHCP message with 'DHCP message type' option type 1 will be referred
   to as a "DHCPDISCOVER" message.








Droms                                                           [Page 1]

RFC 1534         Interoperation Between DHCP and BOOTP      October 1993


2. BOOTP clients and DHCP servers

   The format of DHCP messages is defined to be compatible with the
   format of BOOTP messages, so that existing BOOTP clients can
   interoperate with DHCP servers.  Any message received by a DHCP
   server that includes a 'DHCP message type' (51) option is assumed to
   have been sent by a DHCP client.  Messages without the DHCP Message
   Type option are assumed to have been sent by a BOOTP client.  Support
   of BOOTP clients by a DHCP server is optional at the discretion of
   the local system administrator.  If a DHCP server that is not
   configured to support BOOTP clients receives a BOOTREQUEST message
   from a BOOTP client, that server silently discards the BOOTREQUEST
   message.

   If a DHCP server is configured to support BOOTP clients, it may be
   configured to supply static addresses, automatic addresses or both.
   Static addresses are those that have been previously assigned by a
   system administrator and are stored in a database available to the
   DHCP server.  Automatic addresses are those selected by the DHCP
   server from its pool of unassigned addresses.

   Since BOOTP clients may not be prepared to receive automatic
   addresses, the decision to allow a DHCP server to return automatic
   addresses must be under the control of the system administrator.  If
   a DHCP server supports supplying automatic addresses to BOOTP
   clients, this feature must be configurable, and the feature must
   default off.  Enabling of the feature must be the result of an active
   decision by the system administrator.

   If a DHCP server returns a automatic address, the BOOTP client will
   not be aware of the DHCP lease mechanism for network address
   assignment.  Thus the DHCP server must assign an infinite lease
   duration to for automatic addresses assigned to BOOTP clients.  Such
   network addresses cannot be automatically reassigned by the server.
   The local system administrator may choose to manually release network
   addresses assigned to BOOTP clients.

   A DHCP server that supports BOOTP clients MUST interact with BOOTP
   clients according to the BOOTP protocol.  The server MUST formulate a
   BOOTP BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e.,
   the server MUST NOT include the 'DHCP message type' option and MUST
   NOT exceed the size limit for BOOTREPLY messages).  The server marks
   a binding for a BOOTP client as BOUND after sending the BOOTP
   BOOTREPLY, as a non-DHCP client will not send a DHCPREQUEST message
   nor will that client expect a DHCPACK message.

   DHCP servers MAY send any DHCP Options to a BOOTP client as allowed
   by the "DHCP Options and BOOTP Vendor Extensions" RFC [2].



Droms                                                           [Page 2]

RFC 1534         Interoperation Between DHCP and BOOTP      October 1993


   In summary, a DHCP server:

      o MAY support BOOTP clients,

      o May return automatic addresses to BOOTP clients,

      o MUST provide a configuration switch if returning automatic
        addresses to BOOTP clients,

      o MUST default this optional configuration to OFF,

      o MUST abide by the BOOTP specification when interacting with
        BOOTP clients, and

      o MAY send DHCP options (those options defined in the DHCP options
        document but not in the BOOTP vendor extensions documents) to
        a BOOTP client.

3. DHCP clients and BOOTP servers

   A DHCP client MAY use a reply from a BOOTP server if the
   configuration returned from the BOOTP server is acceptable to the
   DHCP client.  A DHCP client MUST assume that an IP address returned
   in a message from a BOOTP server has an infinite lease.  A DHCP
   client SHOULD choose to use a reply from a DHCP server in preference
   to a reply from a BOOTP server.

4. References

   [1] Wimer, W., "Clarifications and Extensions for the Bootstrap
       Protocol", RFC 1532, Carnegie Mellon University, October 1993.

   [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
       University, October 1993.

   [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
       Bucknell University, October 1993.


5. Security Considerations

   Security issues are not discussed in this memo.








Droms                                                           [Page 3]

RFC 1534         Interoperation Between DHCP and BOOTP      October 1993


6. Author's Address

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

   Phone:(717) 524-1145
   EMail: droms@bucknell.edu









































一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

横画面に固定する、縦画面に固定する(表示モードの固定)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る