draft-ietf-dhc-between-bootp-02.txt   rfc1534.txt 
Internet Engineering Task Force R. Droms Network Working Group R. Droms
INTERNET-DRAFT Bucknell University Request for Comments: 1534 Bucknell University
November, 1992 Category: Standards Track October 1993
Interoperation Between DHCP and BOOTP Interoperation Between DHCP and BOOTP
1 Abstract Status of this Memo
DHCP provides a superset of the functions provided by BOOTP. This document This RFC specifies an Internet standards track protocol for the
describes the interactions between DHCP and BOOTP network participants. 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.
2 Status of this memo Abstract
This draft document is a product of the IETF Dynamic Host Configuration DHCP provides a superset of the functions provided by BOOTP. This
Working Group; it will be submitted to the RFC editor as a standards document describes the interactions between DHCP and BOOTP network
document. Distribution of this memo is unlimited. Please respond with participants.
comments to the host-conf@sol.cs.bucknell.edu mailing list. This document
will expire on June 1, 1993.
This document is an Internet Draft. Internet Drafts are working documents 1. Introduction
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. The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
Internet Drafts may be updated, replaced, or obsoleted by other documents at for transmitting configuration parameters to hosts using the TCP/IP
any time. It is not appropriate to use Internet Drafts as reference protocol suite. The format of DHCP messages is based on the format
material or to cite them other than as a ``working draft'' or ``work in of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP
progress.'' Please check the 1id-abstracts.txt listing contained in the participants may exchange messages. This document specifies the ways
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, in which DHCP and BOOTP participants may interoperate.
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current
status of any Internet Draft.
3 Introduction 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".
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for Throughout this document, DHCP messages that include a 'DHCP message
transmitting configuration parameters to hosts using the TCP/IP protocl type' option will be referred to by the type of the message; e.g., a
suite. The format of DHCP messages is based on the format of BOOTP DHCP message with 'DHCP message type' option type 1 will be referred
messages, so that, in certain circumstances, DHCP and BOOTP particpants may to as a "DHCPDISCOVER" message.
exchange messages. This document specifies the ways in which DHCP and BOTP
participants may interoperate.
DHCP introduces a small change in terminology intended to clarify the 2. BOOTP clients and DHCP servers
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' The format of DHCP messages is defined to be compatible with the
option will be referred to by the type of the message; e.g., a DHCP message format of BOOTP messages, so that existing BOOTP clients can
with 'DHCP message type' option type1 will be referred to as a interoperate with DHCP servers. Any message received by a DHCP
``DHCPDISCOVER'' message. 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.
4 BOOTP clients and DHCP servers 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.
The format of DHCP messages is defined to be compatible with the format of Since BOOTP clients may not be prepared to receive automatic
BOOTP messages, so that existing BOOTP clients can interoperate with DHCP addresses, the decision to allow a DHCP server to return automatic
servers. Any message received by a DHCP server that includes a 'DHCP addresses must be under the control of the system administrator. If
message type' (51) option is assumed to have been sent by a DHCP client. a DHCP server supports supplying automatic addresses to BOOTP
Messages without the DHCP Message Type option are assumed to have been sent clients, this feature must be configurable, and the feature must
by a BOOTP client. Support of BOOTP clients by a DHCP server is optional at default off. Enabling of the feature must be the result of an active
the discretion of the local system administrator. If a DHCP server that is decision by the system administrator.
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 If a DHCP server returns a automatic address, the BOOTP client will
according to the BOOTP protocol. The server MUST formulate a BOOTP not be aware of the DHCP lease mechanism for network address
BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e., the server assignment. Thus the DHCP server must assign an infinite lease
MUST NOT include the 'DHCP message type' option and MUST NOT exceed the size duration to for automatic addresses assigned to BOOTP clients. Such
limit for BOOTREPLY messages). The server marks a binding for a BOOTP network addresses cannot be automatically reassigned by the server.
client as BOUND after sending the BOOTP BOOTREPLY, as a non-DHCP client will The local system administrator may choose to manually release network
not send a DHCPREQUEST message nor will that client expect a DHCPACK addresses assigned to BOOTP clients.
message.
A BOOTP client will not be aware of the DHCP lease mechanism for network A DHCP server that supports BOOTP clients MUST interact with BOOTP
address assignment. A DHCP server assigns an infinite lease duration to for clients according to the BOOTP protocol. The server MUST formulate a
network addresses assigned to BOOTP clients. Such network addresses cannot BOOTP BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e.,
be automatically reassigned by the server. The local system administrator the server MUST NOT include the 'DHCP message type' option and MUST
may choose to manually release network addresses assigned to BOOTP clients. 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 servers MAY send any DHCP Options to a BOOTP client as allowed
``DHCP Options and BOOTP Vendor Extensions'' internet Draft. by the "DHCP Options and BOOTP Vendor Extensions" RFC [2].
5 DHCP clients and BOOTP servers In summary, a DHCP server:
A DHCP client MAY use a reply from a BOOTP server if the configuration o MAY support BOOTP clients,
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.
6 Security Considerations o May return automatic addresses to BOOTP clients,
This document does not address security issues. o MUST provide a configuration switch if returning automatic
addresses to BOOTP clients,
7 Author's Address o MUST default this optional configuration to OFF,
Ralph Droms o MUST abide by the BOOTP specification when interacting with
Computer Science Department BOOTP clients, and
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
(717) 524-1145
droms@bucknell.edu 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.
8 Expiration date 3. DHCP clients and BOOTP servers
This document will expire on June 31, 1993. 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.
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
 End of changes. 26 change blocks. 
85 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/