Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

DRAFT STANDARD
Errata Exist
Network Working Group                                           R. DromsRequest for Comments: 1534                           Bucknell UniversityCategory: Standards Track                                   October 1993Interoperation Between DHCP and BOOTPStatus 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 19932. 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 19936. Author's Address   Ralph Droms   Computer Science Department   323 Dana Engineering   Bucknell University   Lewisburg, PA 17837   Phone:(717) 524-1145   EMail: droms@bucknell.eduDroms                                                           [Page 4]

[8]ページ先頭

©2009-2025 Movatter.jp