RFC 1534

Network Working Group 🎀

Request for Comments: 1534 ✨ Author: R. Droms, Bucknell University 💅 Category: Standards Track 🦋 Date: October 1993 🌸 This doc doesn't list any RFCs it obsoletes or updates. 🙈

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 🌈

Okay so, DHCP gives you a superset of everything BOOTP can do, and this doc is all about how DHCP and BOOTP people can talk to each other 🫶 It describes the interactions between DHCP and BOOTP network participants.

1. Introduction 💖

The Dynamic Host Configuration Protocol (DHCP) gives hosts a way to get configuration parameters over the TCP/IP protocol suite ✨ The format of DHCP messages is based on the format of BOOTP messages, so in certain circumstances, DHCP and BOOTP participants may exchange messages. This document specifies the ways in which DHCP and BOOTP participants may interoperate. 🎀

DHCP also made a tiny terminology glow-up to clarify one of the fields 💅 What was the "vendor extensions" field in BOOTP is now called the "options" field in DHCP. The tagged data items that lived inside the BOOTP "vendor extensions" field, which used to be called "vendor extensions" too, are now just called "options". This document refers to BOOTP vendor extensions and DHCP options uniformly as "options" 🦋

Throughout this document, DHCP messages that include a 'DHCP message type' option get referred to by the type of the message. For example, a DHCP message with 'DHCP message type' option type 1 is called a "DHCPDISCOVER" message 🍓

2. BOOTP clients and DHCP servers 🌸

The format of DHCP messages is defined to be compatible with the format of BOOTP messages, so existing BOOTP clients can interoperate with DHCP servers ✨ Any message a DHCP server receives that includes a 'DHCP message type' (51) option is assumed to have come from a DHCP client. Messages without the DHCP Message Type option are assumed to have come from a BOOTP client 🧚 Supporting BOOTP clients on a DHCP server is optional, at the discretion of the local system administrator. If a DHCP server that isn't configured to support BOOTP clients gets a BOOTREQUEST message from a BOOTP client, that server silently discards the BOOTREQUEST message 💀

If a DHCP server is set up to support BOOTP clients, it may be configured to supply static addresses, automatic addresses, or both. Static addresses were previously assigned by a system administrator and are stored in a database the DHCP server can access. Automatic addresses are picked by the DHCP server from its pool of unassigned addresses 🎀

BOOTP clients may not be ready to receive automatic addresses, so deciding whether a DHCP server can return automatic addresses has to 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. Turning it on has to be the result of an active decision by the system administrator 🙈

If a DHCP server returns an automatic address, the BOOTP client won't know about the DHCP lease mechanism for network address assignment. So the DHCP server must assign an infinite lease duration to automatic addresses given to BOOTP clients. Those network addresses can't 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, because a non-DHCP client won't 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]. 💜

In summary, a DHCP server:

• MAY support BOOTP clients,
• May return automatic addresses to BOOTP clients,
• MUST provide a configuration switch if returning automatic addresses to BOOTP clients,
• MUST default this optional configuration to OFF,
• MUST abide by the BOOTP specification when interacting with BOOTP clients, and
• 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 that comes back 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 over a reply from a BOOTP server, if it can 💖

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. 💀

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