Internet Engineering Task Force R. Droms INTERNET-DRAFT Bucknell University June, 1992 Interoperation Between DHCP and BOOTP 1 Abstract The Dynamic Host Configuration Protocol (DHCP) provides a superset of the functions provided by the Bootstrap Protocol (BOOTP). Some DHCP participants may not be configured so as to be compatible. This document describes the interactions between DHCP and BOOTP network participants and mechanisms for accommodating incompatibilities between DHCP participants. 2 Status of this memo This draft document is a product of the IETF Dynamic Host Configuration Working Group; it will be submitted to the RFC editor as a standards document. Distribution of this memo is unlimited. Please respond with comments to the host-conf@sol.cs.bucknell.edu mailing list. This document will expire on January 1, 1993. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. INTERNET-DRAFT Interoperation Between DHCP and BOOTP June, 1992 3 Introduction 4 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) vendor extension is assumed to have been sent by a DHCP client. Messages without the DHCP Message Type vendor extension is 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. 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 DHCPOFFER vendor extension). 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. A BOOTP client will not be aware of the DHCP lease mechanism for network address assignment. A DHCP server assigns an infinite lease duration to for network 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. Use of the vendor extensions defined in DHCP is not restricted to DHCP clients and servers. Existing BOOTP clients and servers may choose to use the newly defined vendor extensions. The one restriction is that BOOTP clients MAY NOT use the 'DHCP client' vendor extension. Only clients using DHCP may use the 'DHCP client' vendor extension. 5 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 client 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. R. Droms [Page 2] INTERNET-DRAFT Interoperation Between DHCP and BOOTP June, 1992 6 Security Considerations This document does not address security issues. 7 Author's Address Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 (717) 524--1145 droms@bucknell.edu R. Droms [Page 3]