Internet Engineering Task Force                                     R. Droms
INTERNET-DRAFT                                           Bucknell University
                                                              November, 1992


                   Interoperation Between DHCP and BOOTP




1 Abstract


DHCP provides a superset of the functions provided by BOOTP. This document
describes the interactions between DHCP and BOOTP network 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 June 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.


3 Introduction


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


INTERNET-DRAFT      Interoperation Between DHCP and BOOTP     November, 1992

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 type1 will be referred to as a
``DHCPDISCOVER'' message.


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

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.

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.

DHCP servers MAY send any DHCP Options to a BOOTP client as allowed by the
``DHCP Options and BOOTP Vendor Extensions'' internet Draft.







R. Droms                                                            [Page 2]


INTERNET-DRAFT      Interoperation Between DHCP and BOOTP     November, 1992

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


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



8 Expiration date


This document will expire on June 31, 1993.



















R. Droms                                                            [Page 3]