doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc1534.txt b/doc/rfc/rfc1534.txt
new file mode 100644
index 0000000..68549b8
--- /dev/null
+++ b/doc/rfc/rfc1534.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                           R. Droms
+Request for Comments: 1534                           Bucknell University
+Category: Standards Track                                   October 1993
+
+
+                 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
+
+   DHCP provides a superset of the functions provided by BOOTP. This
+   document describes the interactions between DHCP and BOOTP network
+   participants.
+
+1. Introduction
+
+   The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
+   for transmitting configuration parameters to hosts using the TCP/IP
+   protocol suite.  The format of DHCP messages is based on the format
+   of BOOTP messages, so that, in certain circumstances, DHCP and BOOTP
+   participants may exchange messages.  This document specifies the ways
+   in which DHCP and BOOTP 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 type 1 will be referred
+   to as a "DHCPDISCOVER" message.
+
+
+
+
+
+
+
+
+Droms                                                           [Page 1]
+
+RFC 1534         Interoperation Between DHCP and BOOTP      October 1993
+
+
+2. 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.
+
+   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.
+
+   Since BOOTP clients may not be prepared to receive automatic
+   addresses, the decision to allow a DHCP server to return automatic
+   addresses must 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.  Enabling of the feature must be the result of an active
+   decision by the system administrator.
+
+   If a DHCP server returns a automatic address, the BOOTP client will
+   not be aware of the DHCP lease mechanism for network address
+   assignment.  Thus the DHCP server must assign an infinite lease
+   duration to for automatic 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.
+
+   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.
+
+   DHCP servers MAY send any DHCP Options to a BOOTP client as allowed
+   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 automatic
+        addresses to BOOTP clients,
+
+      o MUST default this optional configuration to OFF,
+
+      o MUST abide by the BOOTP specification when interacting with
+        BOOTP clients, and
+
+      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.
+
+3. 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.
+
+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.
+
+
+
+
+
+
+
+
+Droms                                                           [Page 3]
+
+RFC 1534         Interoperation Between DHCP and BOOTP      October 1993
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                                                           [Page 4]
+
\ No newline at end of file