As per Relevance of the word automatic, we have this rfc below:
Network Working Group R.
Request for Comments: 1534 Bucknell
Category: Standards Track October 1993
Interoperation Between DHCP and
Status of this
This RFC specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
DHCP provides a superset of the functions provided by BOOTP.
document describes the interactions between DHCP and BOOTP
participants
1.
The Dynamic Host Configuration Protocol (DHCP) provides a
for transmitting configuration parameters to hosts using the TCP/
protocol suite. The format of DHCP messages is based on the
of BOOTP messages, so that, in certain circumstances, DHCP and
participants may exchange messages. This document specifies the
in which DHCP and BOOTP participants may interoperate
DHCP introduces a small change in terminology intended to clarify
meaning of one of the fields. What was the "vendor extensions"
in BOOTP has been re-named the "options" field in DHCP. Similarly
the tagged data items that were used inside the BOOTP "
extensions" field, which were formerly referred to as "
extensions", are now termed simply "options". This document
refer to BOOTP vendor extensions and DHCP options uniformly
"options".
Throughout this document, DHCP messages that include a 'DHCP
type' option will be referred to by the type of the message; e.g.,
DHCP message with 'DHCP message type' option type 1 will be
to as a "DHCPDISCOVER" message
Droms [Page 1]
RFC 1534 Interoperation Between DHCP and BOOTP October 1993
2. BOOTP clients and DHCP
The format of DHCP messages is defined to be compatible with
format of BOOTP messages, so that existing BOOTP clients
interoperate with DHCP servers. Any message received by a
server that includes a 'DHCP message type' (51) option is assumed
have been sent by a DHCP client. Messages without the DHCP
Type option are assumed to have been sent by a BOOTP client.
of BOOTP clients by a DHCP server is optional at the discretion
the local system administrator. If a DHCP server that is
configured to support BOOTP clients receives a BOOTREQUEST
from a BOOTP client, that server silently discards the
message
If a DHCP server is configured to support BOOTP clients, it may
configured to supply static addresses, automatic addresses or both
Static addresses are those that have been previously assigned by
system administrator and are stored in a database available to
DHCP server. Automatic addresses are those selected by the
server from its pool of unassigned addresses
Since BOOTP clients may not be prepared to receive
addresses, the decision to allow a DHCP server to return
addresses must be under the control of the system administrator.
a DHCP server supports supplying automatic addresses to
clients, this feature must be configurable, and the feature
default off. Enabling of the feature must be the result of an
decision by the system administrator
If a DHCP server returns a automatic address, the BOOTP client
not be aware of the DHCP lease mechanism for network
assignment. Thus the DHCP server must assign an infinite
duration to for automatic addresses assigned to BOOTP clients.
network addresses cannot be automatically reassigned by the server
The local system administrator may choose to manually release
addresses assigned to BOOTP clients
A DHCP server that supports BOOTP clients MUST interact with
clients according to the BOOTP protocol. The server MUST formulate
BOOTP BOOTREPLY message rather than a DHCP DHCPOFFER message (i.e.,
the server MUST NOT include the 'DHCP message type' option and
NOT exceed the size limit for BOOTREPLY messages). The server
a binding for a BOOTP client as BOUND after sending the
BOOTREPLY, as a non-DHCP client will not send a DHCPREQUEST
nor will that client expect a DHCPACK message
DHCP servers MAY send any DHCP Options to a BOOTP client as
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
addresses to BOOTP clients
o MUST default this optional configuration to OFF
o MUST abide by the BOOTP specification when interacting
BOOTP clients,
o MAY send DHCP options (those options defined in the DHCP
document but not in the BOOTP vendor extensions documents)
a BOOTP client
3. DHCP clients and BOOTP
A DHCP client MAY use a reply from a BOOTP server if
configuration returned from the BOOTP server is acceptable to
DHCP client. A DHCP client MUST assume that an IP address
in a message from a BOOTP server has an infinite lease. A
client SHOULD choose to use a reply from a DHCP server in
to a reply from a BOOTP server
4.
[1] Wimer, W., "Clarifications and Extensions for the
Protocol", RFC 1532, Carnegie Mellon University, October 1993.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP
Extensions", RFC 1533, Lachman Technology, Inc.,
University, October 1993.
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1531,
Bucknell University, October 1993.
5. Security
Security issues are not discussed in this memo
Droms [Page 3]
RFC 1534 Interoperation Between DHCP and BOOTP October 1993
6. Author's
Ralph
Computer Science
323 Dana
Bucknell
Lewisburg, PA 17837
Phone:(717) 524-1145
EMail: droms@bucknell.
Droms [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
