aboutsummaryrefslogtreecommitdiff
path: root/contrib/isc-dhcp/doc
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/isc-dhcp/doc')
-rw-r--r--contrib/isc-dhcp/doc/rfc2131.txt2523
-rw-r--r--contrib/isc-dhcp/doc/rfc2132.txt1907
-rw-r--r--contrib/isc-dhcp/doc/rfc951.txt684
3 files changed, 5114 insertions, 0 deletions
diff --git a/contrib/isc-dhcp/doc/rfc2131.txt b/contrib/isc-dhcp/doc/rfc2131.txt
new file mode 100644
index 000000000000..f45d9b864a24
--- /dev/null
+++ b/contrib/isc-dhcp/doc/rfc2131.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Network Working Group R. Droms
+Request for Comments: 2131 Bucknell University
+Obsoletes: 1541 March 1997
+Category: Standards Track
+
+ Dynamic Host Configuration Protocol
+
+Status of this memo
+
+ This document 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" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Dynamic Host Configuration Protocol (DHCP) provides a framework
+ for passing configuration information to hosts on a TCPIP network.
+ DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
+ capability of automatic allocation of reusable network addresses and
+ additional configuration options [19]. DHCP captures the behavior of
+ BOOTP relay agents [7, 21], and DHCP participants can interoperate
+ with BOOTP participants [9].
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
+ 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
+ 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
+ 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
+ 3.1 Client-server interaction - allocating a network address. . . 13
+ 3.2 Client-server interaction - reusing a previously allocated
+ network address . . . . . . . . . . . . . . . . . . . . . . . 17
+ 3.3 Interpretation and representation of time values. . . . . . . 20
+ 3.4 Obtaining parameters with externally configured network
+ address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
+ 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
+ 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
+ 4. Specification of the DHCP client-server protocol. . . . . . . 22
+
+
+
+Droms Standards Track [Page 1]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
+ 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
+ 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
+ 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
+ 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
+ A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
+List of Figures
+ 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
+ 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
+ 3. Timeline diagram of messages exchanged between DHCP client and
+ servers when allocating a new network address. . . . . . . . . 15
+ 4. Timeline diagram of messages exchanged between DHCP client and
+ servers when reusing a previously allocated network address. . 18
+ 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
+List of Tables
+ 1. Description of fields in a DHCP message. . . . . . . . . . . . 10
+ 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
+ 4. Client messages from various states. . . . . . . . . . . . . . 33
+ 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
+
+1. Introduction
+
+ The Dynamic Host Configuration Protocol (DHCP) provides configuration
+ parameters to Internet hosts. DHCP consists of two components: a
+ protocol for delivering host-specific configuration parameters from a
+ DHCP server to a host and a mechanism for allocation of network
+ addresses to hosts.
+
+ DHCP is built on a client-server model, where designated DHCP server
+ hosts allocate network addresses and deliver configuration parameters
+ to dynamically configured hosts. Throughout the remainder of this
+ document, the term "server" refers to a host providing initialization
+ parameters through DHCP, and the term "client" refers to a host
+ requesting initialization parameters from a DHCP server.
+
+ A host should not act as a DHCP server unless explicitly configured
+ to do so by a system administrator. The diversity of hardware and
+ protocol implementations in the Internet would preclude reliable
+ operation if random hosts were allowed to respond to DHCP requests.
+ For example, IP requires the setting of many parameters within the
+ protocol implementation software. Because IP can be used on many
+ dissimilar kinds of network hardware, values for those parameters
+ cannot be guessed or assumed to have correct defaults. Also,
+ distributed address allocation schemes depend on a polling/defense
+
+
+
+Droms Standards Track [Page 2]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ mechanism for discovery of addresses that are already in use. IP
+ hosts may not always be able to defend their network addresses, so
+ that such a distributed address allocation scheme cannot be
+ guaranteed to avoid allocation of duplicate network addresses.
+
+ DHCP supports three mechanisms for IP address allocation. In
+ "automatic allocation", DHCP assigns a permanent IP address to a
+ client. In "dynamic allocation", DHCP assigns an IP address to a
+ client for a limited period of time (or until the client explicitly
+ relinquishes the address). In "manual allocation", a client's IP
+ address is assigned by the network administrator, and DHCP is used
+ simply to convey the assigned address to the client. A particular
+ network will use one or more of these mechanisms, depending on the
+ policies of the network administrator.
+
+ Dynamic allocation is the only one of the three mechanisms that
+ allows automatic reuse of an address that is no longer needed by the
+ client to which it was assigned. Thus, dynamic allocation is
+ particularly useful for assigning an address to a client that will be
+ connected to the network only temporarily or for sharing a limited
+ pool of IP addresses among a group of clients that do not need
+ permanent IP addresses. Dynamic allocation may also be a good choice
+ for assigning an IP address to a new client being permanently
+ connected to a network where IP addresses are sufficiently scarce
+ that it is important to reclaim them when old clients are retired.
+ Manual allocation allows DHCP to be used to eliminate the error-prone
+ process of manually configuring hosts with IP addresses in
+ environments where (for whatever reasons) it is desirable to manage
+ IP address assignment outside of the DHCP mechanisms.
+
+ The format of DHCP messages is based on the format of BOOTP messages,
+ to capture the BOOTP relay agent behavior described as part of the
+ BOOTP specification [7, 21] and to allow interoperability of existing
+ BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
+ the necessity of having a DHCP server on each physical network
+ segment.
+
+1.1 Changes to RFC 1541
+
+ This document updates the DHCP protocol specification that appears in
+ RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
+ section 3.4, 4.3 and 4.4 for details. The classing mechanism for
+ identifying DHCP clients to DHCP servers has been extended to include
+ "vendor" classes as defined in sections 4.2 and 4.3. The minimum
+ lease time restriction has been removed. Finally, many editorial
+ changes have been made to clarify the text as a result of experience
+ gained in DHCP interoperability tests.
+
+
+
+
+Droms Standards Track [Page 3]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+1.2 Related Work
+
+ There are several Internet protocols and related mechanisms that
+ address some parts of the dynamic host configuration problem. The
+ Reverse Address Resolution Protocol (RARP) [10] (through the
+ extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
+ addresses the problem of network address discovery, and includes an
+ automatic IP address assignment mechanism. The Trivial File Transfer
+ Protocol (TFTP) [20] provides for transport of a boot image from a
+ boot server. The Internet Control Message Protocol (ICMP) [16]
+ provides for informing hosts of additional routers via "ICMP
+ redirect" messages. ICMP also can provide subnet mask information
+ through the "ICMP mask request" message and other information through
+ the (obsolete) "ICMP information request" message. Hosts can locate
+ routers through the ICMP router discovery mechanism [8].
+
+ BOOTP is a transport mechanism for a collection of configuration
+ information. BOOTP is also extensible, and official extensions [17]
+ have been defined for several configuration parameters. Morgan has
+ proposed extensions to BOOTP for dynamic IP address assignment [15].
+ The Network Information Protocol (NIP), used by the Athena project at
+ MIT, is a distributed mechanism for dynamic IP address assignment
+ [19]. The Resource Location Protocol RLP [1] provides for location
+ of higher level services. Sun Microsystems diskless workstations use
+ a boot procedure that employs RARP, TFTP and an RPC mechanism called
+ "bootparams" to deliver configuration information and operating
+ system code to diskless hosts. (Sun Microsystems, Sun Workstation
+ and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
+ networks also use DRARP and an auto-installation mechanism to
+ automate the configuration of new hosts in an existing network.
+
+ In other related work, the path minimum transmission unit (MTU)
+ discovery algorithm can determine the MTU of an arbitrary internet
+ path [14]. The Address Resolution Protocol (ARP) has been proposed
+ as a transport protocol for resource location and selection [6].
+ Finally, the Host Requirements RFCs [3, 4] mention specific
+ requirements for host reconfiguration and suggest a scenario for
+ initial configuration of diskless hosts.
+
+1.3 Problem definition and issues
+
+ DHCP is designed to supply DHCP clients with the configuration
+ parameters defined in the Host Requirements RFCs. After obtaining
+ parameters via DHCP, a DHCP client should be able to exchange packets
+ with any other host in the Internet. The TCP/IP stack parameters
+ supplied by DHCP are listed in Appendix A.
+
+
+
+
+
+Droms Standards Track [Page 4]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Not all of these parameters are required for a newly initialized
+ client. A client and server may negotiate for the transmission of
+ only those parameters required by the client or specific to a
+ particular subnet.
+
+ DHCP allows but does not require the configuration of client
+ parameters not directly related to the IP protocol. DHCP also does
+ not address registration of newly configured clients with the Domain
+ Name System (DNS) [12, 13].
+
+ DHCP is not intended for use in configuring routers.
+
+1.4 Requirements
+
+ Throughout this document, the words that are used to define the
+ significance of particular requirements are capitalized. These words
+ are:
+
+ o "MUST"
+
+ This word or the adjective "REQUIRED" means that the
+ item is an absolute requirement of this specification.
+
+ o "MUST NOT"
+
+ This phrase means that the item is an absolute prohibition
+ of this specification.
+
+ o "SHOULD"
+
+ This word or the adjective "RECOMMENDED" means that there
+ may exist valid reasons in particular circumstances to ignore
+ this item, but the full implications should be understood and
+ the case carefully weighed before choosing a different course.
+
+ o "SHOULD NOT"
+
+ This phrase means that there may exist valid reasons in
+ particular circumstances when the listed behavior is acceptable
+ or even useful, but the full implications should be understood
+ and the case carefully weighed before implementing any behavior
+ described with this label.
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 5]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ o "MAY"
+
+ This word or the adjective "OPTIONAL" means that this item is
+ truly optional. One vendor may choose to include the item
+ because a particular marketplace requires it or because it
+ enhances the product, for example; another vendor may omit the
+ same item.
+
+1.5 Terminology
+
+ This document uses the following terms:
+
+ o "DHCP client"
+
+ A DHCP client is an Internet host using DHCP to obtain
+ configuration parameters such as a network address.
+
+ o "DHCP server"
+
+ A DHCP server is an Internet host that returns configuration
+ parameters to DHCP clients.
+
+ o "BOOTP relay agent"
+
+ A BOOTP relay agent or relay agent is an Internet host or router
+ that passes DHCP messages between DHCP clients and DHCP servers.
+ DHCP is designed to use the same relay agent behavior as specified
+ in the BOOTP protocol specification.
+
+ o "binding"
+
+ A binding is a collection of configuration parameters, including
+ at least an IP address, associated with or "bound to" a DHCP
+ client. Bindings are managed by DHCP servers.
+
+1.6 Design goals
+
+ The following list gives general design goals for DHCP.
+
+ o DHCP should be a mechanism rather than a policy. DHCP must
+ allow local system administrators control over configuration
+ parameters where desired; e.g., local system administrators
+ should be able to enforce local policies concerning allocation
+ and access to local resources where desired.
+
+
+
+
+
+
+
+Droms Standards Track [Page 6]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ o Clients should require no manual configuration. Each client
+ should be able to discover appropriate local configuration
+ parameters without user intervention and incorporate those
+ parameters into its own configuration.
+
+ o Networks should require no manual configuration for individual
+ clients. Under normal circumstances, the network manager
+ should not have to enter any per-client configuration
+ parameters.
+
+ o DHCP should not require a server on each subnet. To allow for
+ scale and economy, DHCP must work across routers or through the
+ intervention of BOOTP relay agents.
+
+ o A DHCP client must be prepared to receive multiple responses
+ to a request for configuration parameters. Some installations
+ may include multiple, overlapping DHCP servers to enhance
+ reliability and increase performance.
+
+ o DHCP must coexist with statically configured, non-participating
+ hosts and with existing network protocol implementations.
+
+ o DHCP must interoperate with the BOOTP relay agent behavior as
+ described by RFC 951 and by RFC 1542 [21].
+
+ o DHCP must provide service to existing BOOTP clients.
+
+ The following list gives design goals specific to the transmission of
+ the network layer parameters. DHCP must:
+
+ o Guarantee that any specific network address will not be in
+ use by more than one DHCP client at a time,
+
+ o Retain DHCP client configuration across DHCP client reboot. A
+ DHCP client should, whenever possible, be assigned the same
+ configuration parameters (e.g., network address) in response
+ to each request,
+
+ o Retain DHCP client configuration across server reboots, and,
+ whenever possible, a DHCP client should be assigned the same
+ configuration parameters despite restarts of the DHCP mechanism,
+
+ o Allow automated assignment of configuration parameters to new
+ clients to avoid hand configuration for new clients,
+
+ o Support fixed or permanent allocation of configuration
+ parameters to specific clients.
+
+
+
+
+Droms Standards Track [Page 7]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+2. Protocol Summary
+
+ From the client's point of view, DHCP is an extension of the BOOTP
+ mechanism. This behavior allows existing BOOTP clients to
+ interoperate with DHCP servers without requiring any change to the
+ clients' initialization software. RFC 1542 [2] details the
+ interactions between BOOTP and DHCP clients and servers [9]. There
+ are some new, optional transactions that optimize the interaction
+ between DHCP clients and servers that are described in sections 3 and
+ 4.
+
+ Figure 1 gives the format of a DHCP message and table 1 describes
+ each of the fields in the DHCP message. The numbers in parentheses
+ indicate the size of each field in octets. The names for the fields
+ given in the figure will be used throughout this document to refer to
+ the fields in DHCP messages.
+
+ There are two primary differences between DHCP and BOOTP. First,
+ DHCP defines mechanisms through which clients can be assigned a
+ network address for a finite lease, allowing for serial reassignment
+ of network addresses to different clients. Second, DHCP provides the
+ mechanism for a client to acquire all of the IP configuration
+ parameters that it needs in order to operate.
+
+ 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 8]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | op (1) | htype (1) | hlen (1) | hops (1) |
+ +---------------+---------------+---------------+---------------+
+ | xid (4) |
+ +-------------------------------+-------------------------------+
+ | secs (2) | flags (2) |
+ +-------------------------------+-------------------------------+
+ | ciaddr (4) |
+ +---------------------------------------------------------------+
+ | yiaddr (4) |
+ +---------------------------------------------------------------+
+ | siaddr (4) |
+ +---------------------------------------------------------------+
+ | giaddr (4) |
+ +---------------------------------------------------------------+
+ | |
+ | chaddr (16) |
+ | |
+ | |
+ +---------------------------------------------------------------+
+ | |
+ | sname (64) |
+ +---------------------------------------------------------------+
+ | |
+ | file (128) |
+ +---------------------------------------------------------------+
+ | |
+ | options (variable) |
+ +---------------------------------------------------------------+
+
+ Figure 1: Format of a DHCP message
+
+ DHCP defines a new 'client identifier' option that is used to pass an
+ explicit client identifier to a DHCP server. This change eliminates
+ the overloading of the 'chaddr' field in BOOTP messages, where
+ 'chaddr' is used both as a hardware address for transmission of BOOTP
+ reply messages and as a client identifier. The 'client identifier'
+ is an opaque key, not to be interpreted by the server; for example,
+ the 'client identifier' may contain a hardware address, identical to
+ the contents of the 'chaddr' field, or it may contain another type of
+ identifier, such as a DNS name. The 'client identifier' chosen by a
+ DHCP client MUST be unique to that client within the subnet to which
+ the client is attached. If the client uses a 'client identifier' in
+ one message, it MUST use that same identifier in all subsequent
+ messages, to ensure that all servers correctly identify the client.
+
+
+
+
+Droms Standards Track [Page 9]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ DHCP clarifies the interpretation of the 'siaddr' field as the
+ address of the server to use in the next step of the client's
+ bootstrap process. A DHCP server may return its own address in the
+ 'siaddr' field, if the server is prepared to supply the next
+ bootstrap service (e.g., delivery of an operating system executable
+ image). A DHCP server always returns its own address in the 'server
+ identifier' option.
+
+ FIELD OCTETS DESCRIPTION
+ ----- ------ -----------
+
+ op 1 Message op code / message type.
+ 1 = BOOTREQUEST, 2 = BOOTREPLY
+ htype 1 Hardware address type, see ARP section in "Assigned
+ Numbers" RFC; e.g., '1' = 10mb ethernet.
+ hlen 1 Hardware address length (e.g. '6' for 10mb
+ ethernet).
+ hops 1 Client sets to zero, optionally used by relay agents
+ when booting via a relay agent.
+ xid 4 Transaction ID, a random number chosen by the
+ client, used by the client and server to associate
+ messages and responses between a client and a
+ server.
+ secs 2 Filled in by client, seconds elapsed since client
+ began address acquisition or renewal process.
+ flags 2 Flags (see figure 2).
+ ciaddr 4 Client IP address; only filled in if client is in
+ BOUND, RENEW or REBINDING state and can respond
+ to ARP requests.
+ yiaddr 4 'your' (client) IP address.
+ siaddr 4 IP address of next server to use in bootstrap;
+ returned in DHCPOFFER, DHCPACK by server.
+ giaddr 4 Relay agent IP address, used in booting via a
+ relay agent.
+ chaddr 16 Client hardware address.
+ sname 64 Optional server host name, null terminated string.
+ file 128 Boot file name, null terminated string; "generic"
+ name or null in DHCPDISCOVER, fully qualified
+ directory-path name in DHCPOFFER.
+ options var Optional parameters field. See the options
+ documents for a list of defined options.
+
+ Table 1: Description of fields in a DHCP message
+
+ The 'options' field is now variable length. A DHCP client must be
+ prepared to receive DHCP messages with an 'options' field of at least
+ length 312 octets. This requirement implies that a DHCP client must
+ be prepared to receive a message of up to 576 octets, the minimum IP
+
+
+
+Droms Standards Track [Page 10]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ datagram size an IP host must be prepared to accept [3]. DHCP
+ clients may negotiate the use of larger DHCP messages through the
+ 'maximum DHCP message size' option. The options field may be further
+ extended into the 'file' and 'sname' fields.
+
+ In the case of a client using DHCP for initial configuration (before
+ the client's TCP/IP software has been completely configured), DHCP
+ requires creative use of the client's TCP/IP software and liberal
+ interpretation of RFC 1122. The TCP/IP software SHOULD accept and
+ forward to the IP layer any IP packets delivered to the client's
+ hardware address before the IP address is configured; DHCP servers
+ and BOOTP relay agents may not be able to deliver DHCP messages to
+ clients that cannot accept hardware unicast datagrams before the
+ TCP/IP software is configured.
+
+ To work around some clients that cannot accept IP unicast datagrams
+ before the TCP/IP software is configured as discussed in the previous
+ paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
+ defined as the BROADCAST (B) flag. The semantics of this flag are
+ discussed in section 4.1 of this document. The remaining bits of the
+ flags field are reserved for future use. They MUST be set to zero by
+ clients and ignored by servers and relay agents. Figure 2 gives the
+ format of the 'flags' field.
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |B| MBZ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ B: BROADCAST flag
+
+ MBZ: MUST BE ZERO (reserved for future use)
+
+ Figure 2: Format of the 'flags' field
+
+2.1 Configuration parameters repository
+
+ The first service provided by DHCP is to provide persistent storage
+ of network parameters for network clients. The model of DHCP
+ persistent storage is that the DHCP service stores a key-value entry
+ for each client, where the key is some unique identifier (for
+ example, an IP subnet number and a unique identifier within the
+ subnet) and the value contains the configuration parameters for the
+ client.
+
+ For example, the key might be the pair (IP-subnet-number, hardware-
+ address) (note that the "hardware-address" should be typed by the
+
+
+
+Droms Standards Track [Page 11]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ type of hardware to accommodate possible duplication of hardware
+ addresses resulting from bit-ordering problems in a mixed-media,
+ bridged network) allowing for serial or concurrent reuse of a
+ hardware address on different subnets, and for hardware addresses
+ that may not be globally unique. Alternately, the key might be the
+ pair (IP-subnet-number, hostname), allowing the server to assign
+ parameters intelligently to a DHCP client that has been moved to a
+ different subnet or has changed hardware addresses (perhaps because
+ the network interface failed and was replaced). The protocol defines
+ that the key will be (IP-subnet-number, hardware-address) unless the
+ client explicitly supplies an identifier using the 'client
+ identifier' option. A client can query the DHCP service to
+ retrieve its configuration parameters. The client interface to the
+ configuration parameters repository consists of protocol messages to
+ request configuration parameters and responses from the server
+ carrying the configuration parameters.
+
+2.2 Dynamic allocation of network addresses
+
+ The second service provided by DHCP is the allocation of temporary or
+ permanent network (IP) addresses to clients. The basic mechanism for
+ the dynamic allocation of network addresses is simple: a client
+ requests the use of an address for some period of time. The
+ allocation mechanism (the collection of DHCP servers) guarantees not
+ to reallocate that address within the requested time and attempts to
+ return the same network address each time the client requests an
+ address. In this document, the period over which a network address
+ is allocated to a client is referred to as a "lease" [11]. The
+ client may extend its lease with subsequent requests. The client may
+ issue a message to release the address back to the server when the
+ client no longer needs the address. The client may ask for a
+ permanent assignment by asking for an infinite lease. Even when
+ assigning "permanent" addresses, a server may choose to give out
+ lengthy but non-infinite leases to allow detection of the fact that
+ the client has been retired.
+
+ In some environments it will be necessary to reassign network
+ addresses due to exhaustion of available addresses. In such
+ environments, the allocation mechanism will reuse addresses whose
+ lease has expired. The server should use whatever information is
+ available in the configuration information repository to choose an
+ address to reuse. For example, the server may choose the least
+ recently assigned address. As a consistency check, the allocating
+ server SHOULD probe the reused address before allocating the address,
+ e.g., with an ICMP echo request, and the client SHOULD probe the
+ newly received address, e.g., with ARP.
+
+
+
+
+
+Droms Standards Track [Page 12]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+3. The Client-Server Protocol
+
+ DHCP uses the BOOTP message format defined in RFC 951 and given in
+ table 1 and figure 1. The 'op' field of each DHCP message sent from
+ a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
+ 'op' field of each DHCP message sent from a server to a client.
+
+ The first four octets of the 'options' field of the DHCP message
+ contain the (decimal) values 99, 130, 83 and 99, respectively (this
+ is the same magic cookie as is defined in RFC 1497 [17]). The
+ remainder of the 'options' field consists of a list of tagged
+ parameters that are called "options". All of the "vendor extensions"
+ listed in RFC 1497 are also DHCP options. RFC 1533 gives the
+ complete set of options defined for use with DHCP.
+
+ Several options have been defined so far. One particular option -
+ the "DHCP message type" option - must be included in every DHCP
+ message. This option defines the "type" of the DHCP message.
+ Additional options may be allowed, required, or not allowed,
+ depending on the DHCP message type.
+
+ 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.
+
+3.1 Client-server interaction - allocating a network address
+
+ The following summary of the protocol exchanges between clients and
+ servers refers to the DHCP messages described in table 2. The
+ timeline diagram in figure 3 shows the timing relationships in a
+ typical client-server interaction. If the client already knows its
+ address, some steps may be omitted; this abbreviated interaction is
+ described in section 3.2.
+
+ 1. The client broadcasts a DHCPDISCOVER message on its local physical
+ subnet. The DHCPDISCOVER message MAY include options that suggest
+ values for the network address and lease duration. BOOTP relay
+ agents may pass the message on to DHCP servers not on the same
+ physical subnet.
+
+ 2. Each server may respond with a DHCPOFFER message that includes an
+ available network address in the 'yiaddr' field (and other
+ configuration parameters in DHCP options). Servers need not
+ reserve the offered network address, although the protocol will
+ work more efficiently if the server avoids allocating the offered
+ network address to another client. When allocating a new address,
+ servers SHOULD check that the offered network address is not
+
+
+
+Droms Standards Track [Page 13]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ already in use; e.g., the server may probe the offered address
+ with an ICMP Echo Request. Servers SHOULD be implemented so that
+ network administrators MAY choose to disable probes of newly
+ allocated addresses. The server transmits the DHCPOFFER message
+ to the client, using the BOOTP relay agent if necessary.
+
+ Message Use
+ ------- ---
+
+ DHCPDISCOVER - Client broadcast to locate available servers.
+
+ DHCPOFFER - Server to client in response to DHCPDISCOVER with
+ offer of configuration parameters.
+
+ DHCPREQUEST - Client message to servers either (a) requesting
+ offered parameters from one server and implicitly
+ declining offers from all others, (b) confirming
+ correctness of previously allocated address after,
+ e.g., system reboot, or (c) extending the lease on a
+ particular network address.
+
+ DHCPACK - Server to client with configuration parameters,
+ including committed network address.
+
+ DHCPNAK - Server to client indicating client's notion of network
+ address is incorrect (e.g., client has moved to new
+ subnet) or client's lease as expired
+
+ DHCPDECLINE - Client to server indicating network address is already
+ in use.
+
+ DHCPRELEASE - Client to server relinquishing network address and
+ cancelling remaining lease.
+
+ DHCPINFORM - Client to server, asking only for local configuration
+ parameters; client already has externally configured
+ network address.
+
+ Table 2: DHCP messages
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 14]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Server Client Server
+ (not selected) (selected)
+
+ v v v
+ | | |
+ | Begins initialization |
+ | | |
+ | _____________/|\____________ |
+ |/DHCPDISCOVER | DHCPDISCOVER \|
+ | | |
+ Determines | Determines
+ configuration | configuration
+ | | |
+ |\ | ____________/ |
+ | \________ | /DHCPOFFER |
+ | DHCPOFFER\ |/ |
+ | \ | |
+ | Collects replies |
+ | \| |
+ | Selects configuration |
+ | | |
+ | _____________/|\____________ |
+ |/ DHCPREQUEST | DHCPREQUEST\ |
+ | | |
+ | | Commits configuration
+ | | |
+ | | _____________/|
+ | |/ DHCPACK |
+ | | |
+ | Initialization complete |
+ | | |
+ . . .
+ . . .
+ | | |
+ | Graceful shutdown |
+ | | |
+ | |\ ____________ |
+ | | DHCPRELEASE \|
+ | | |
+ | | Discards lease
+ | | |
+ v v v
+ Figure 3: Timeline diagram of messages exchanged between DHCP
+ client and servers when allocating a new network address
+
+
+
+
+
+
+
+Droms Standards Track [Page 15]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ 3. The client receives one or more DHCPOFFER messages from one or more
+ servers. The client may choose to wait for multiple responses.
+ The client chooses one server from which to request configuration
+ parameters, based on the configuration parameters offered in the
+ DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
+ that MUST include the 'server identifier' option to indicate which
+ server it has selected, and that MAY include other options
+ specifying desired configuration values. The 'requested IP
+ address' option MUST be set to the value of 'yiaddr' in the
+ DHCPOFFER message from the server. This DHCPREQUEST message is
+ broadcast and relayed through DHCP/BOOTP relay agents. To help
+ ensure that any BOOTP relay agents forward the DHCPREQUEST message
+ to the same set of DHCP servers that received the original
+ DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
+ value in the DHCP message header's 'secs' field and be sent to the
+ same IP broadcast address as the original DHCPDISCOVER message.
+ The client times out and retransmits the DHCPDISCOVER message if
+ the client receives no DHCPOFFER messages.
+
+ 4. The servers receive the DHCPREQUEST broadcast from the client.
+ Those servers not selected by the DHCPREQUEST message use the
+ message as notification that the client has declined that server's
+ offer. The server selected in the DHCPREQUEST message commits the
+ binding for the client to persistent storage and responds with a
+ DHCPACK message containing the configuration parameters for the
+ requesting client. The combination of 'client identifier' or
+ 'chaddr' and assigned network address constitute a unique
+ identifier for the client's lease and are used by both the client
+ and server to identify a lease referred to in any DHCP messages.
+ Any configuration parameters in the DHCPACK message SHOULD NOT
+ conflict with those in the earlier DHCPOFFER message to which the
+ client is responding. The server SHOULD NOT check the offered
+ network address at this point. The 'yiaddr' field in the DHCPACK
+ messages is filled in with the selected network address.
+
+ If the selected server is unable to satisfy the DHCPREQUEST message
+ (e.g., the requested network address has been allocated), the
+ server SHOULD respond with a DHCPNAK message.
+
+ A server MAY choose to mark addresses offered to clients in
+ DHCPOFFER messages as unavailable. The server SHOULD mark an
+ address offered to a client in a DHCPOFFER message as available if
+ the server receives no DHCPREQUEST message from that client.
+
+ 5. The client receives the DHCPACK message with configuration
+ parameters. The client SHOULD perform a final check on the
+ parameters (e.g., ARP for allocated network address), and notes the
+ duration of the lease specified in the DHCPACK message. At this
+
+
+
+Droms Standards Track [Page 16]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ point, the client is configured. If the client detects that the
+ address is already in use (e.g., through the use of ARP), the
+ client MUST send a DHCPDECLINE message to the server and restarts
+ the configuration process. The client SHOULD wait a minimum of ten
+ seconds before restarting the configuration process to avoid
+ excessive network traffic in case of looping.
+
+ If the client receives a DHCPNAK message, the client restarts the
+ configuration process.
+
+ The client times out and retransmits the DHCPREQUEST message if the
+ client receives neither a DHCPACK or a DHCPNAK message. The client
+ retransmits the DHCPREQUEST according to the retransmission
+ algorithm in section 4.1. The client should choose to retransmit
+ the DHCPREQUEST enough times to give adequate probability of
+ contacting the server without causing the client (and the user of
+ that client) to wait overly long before giving up; e.g., a client
+ retransmitting as described in section 4.1 might retransmit the
+ DHCPREQUEST message four times, for a total delay of 60 seconds,
+ before restarting the initialization procedure. If the client
+ receives neither a DHCPACK or a DHCPNAK message after employing the
+ retransmission algorithm, the client reverts to INIT state and
+ restarts the initialization process. The client SHOULD notify the
+ user that the initialization process has failed and is restarting.
+
+ 6. The client may choose to relinquish its lease on a network address
+ by sending a DHCPRELEASE message to the server. The client
+ identifies the lease to be released with its 'client identifier',
+ or 'chaddr' and network address in the DHCPRELEASE message. If the
+ client used a 'client identifier' when it obtained the lease, it
+ MUST use the same 'client identifier' in the DHCPRELEASE message.
+
+3.2 Client-server interaction - reusing a previously allocated network
+ address
+
+ If a client remembers and wishes to reuse a previously allocated
+ network address, a client may choose to omit some of the steps
+ described in the previous section. The timeline diagram in figure 4
+ shows the timing relationships in a typical client-server interaction
+ for a client reusing a previously allocated network address.
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 17]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ 1. The client broadcasts a DHCPREQUEST message on its local subnet.
+ The message includes the client's network address in the
+ 'requested IP address' option. As the client has not received its
+ network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
+ relay agents pass the message on to DHCP servers not on the same
+ subnet. If the client used a 'client identifier' to obtain its
+ address, the client MUST use the same 'client identifier' in the
+ DHCPREQUEST message.
+
+ 2. Servers with knowledge of the client's configuration parameters
+ respond with a DHCPACK message to the client. Servers SHOULD NOT
+ check that the client's network address is already in use; the
+ client may respond to ICMP Echo Request messages at this point.
+
+ Server Client Server
+
+ v v v
+ | | |
+ | Begins |
+ | initialization |
+ | | |
+ | /|\ |
+ | _________ __/ | \__________ |
+ | /DHCPREQU EST | DHCPREQUEST\ |
+ |/ | \|
+ | | |
+ Locates | Locates
+ configuration | configuration
+ | | |
+ |\ | /|
+ | \ | ___________/ |
+ | \ | / DHCPACK |
+ | \ _______ |/ |
+ | DHCPACK\ | |
+ | Initialization |
+ | complete |
+ | \| |
+ | | |
+ | (Subsequent |
+ | DHCPACKS |
+ | ignored) |
+ | | |
+ | | |
+ v v v
+
+ Figure 4: Timeline diagram of messages exchanged between DHCP
+ client and servers when reusing a previously allocated
+ network address
+
+
+
+Droms Standards Track [Page 18]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ If the client's request is invalid (e.g., the client has moved
+ to a new subnet), servers SHOULD respond with a DHCPNAK message to
+ the client. Servers SHOULD NOT respond if their information is not
+ guaranteed to be accurate. For example, a server that identifies a
+ request for an expired binding that is owned by another server SHOULD
+ NOT respond with a DHCPNAK unless the servers are using an explicit
+ mechanism to maintain coherency among the servers.
+
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
+ the same subnet as the server. The server MUST
+ broadcast the DHCPNAK message to the 0xffffffff broadcast address
+ because the client may not have a correct network address or subnet
+ mask, and the client may not be answering ARP requests.
+ Otherwise, the server MUST send the DHCPNAK message to the IP
+ address of the BOOTP relay agent, as recorded in 'giaddr'. The
+ relay agent will, in turn, forward the message directly to the
+ client's hardware address, so that the DHCPNAK can be delivered even
+ if the client has moved to a new network.
+
+ 3. The client receives the DHCPACK message with configuration
+ parameters. The client performs a final check on the parameters
+ (as in section 3.1), and notes the duration of the lease specified
+ in the DHCPACK message. The specific lease is implicitly identified
+ by the 'client identifier' or 'chaddr' and the network address. At
+ this point, the client is configured.
+
+ If the client detects that the IP address in the DHCPACK message
+ is already in use, the client MUST send a DHCPDECLINE message to the
+ server and restarts the configuration process by requesting a
+ new network address. This action corresponds to the client
+ moving to the INIT state in the DHCP state diagram, which is
+ described in section 4.4.
+
+ If the client receives a DHCPNAK message, it cannot reuse its
+ remembered network address. It must instead request a new
+ address by restarting the configuration process, this time
+ using the (non-abbreviated) procedure described in section
+ 3.1. This action also corresponds to the client moving to
+ the INIT state in the DHCP state diagram.
+
+ The client times out and retransmits the DHCPREQUEST message if
+ the client receives neither a DHCPACK nor a DHCPNAK message. The
+ client retransmits the DHCPREQUEST according to the retransmission
+ algorithm in section 4.1. The client should choose to retransmit
+ the DHCPREQUEST enough times to give adequate probability of
+ contacting the server without causing the client (and the user of
+ that client) to wait overly long before giving up; e.g., a client
+ retransmitting as described in section 4.1 might retransmit the
+
+
+
+Droms Standards Track [Page 19]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ DHCPREQUEST message four times, for a total delay of 60 seconds,
+ before restarting the initialization procedure. If the client
+ receives neither a DHCPACK or a DHCPNAK message after employing
+ the retransmission algorithm, the client MAY choose to use the
+ previously allocated network address and configuration parameters
+ for the remainder of the unexpired lease. This corresponds to
+ moving to BOUND state in the client state transition diagram shown
+ in figure 5.
+
+ 4. The client may choose to relinquish its lease on a network
+ address by sending a DHCPRELEASE message to the server. The
+ client identifies the lease to be released with its
+ 'client identifier', or 'chaddr' and network address in the
+ DHCPRELEASE message.
+
+ Note that in this case, where the client retains its network
+ address locally, the client will not normally relinquish its
+ lease during a graceful shutdown. Only in the case where the
+ client explicitly needs to relinquish its lease, e.g., the client
+ is about to be moved to a different subnet, will the client send
+ a DHCPRELEASE message.
+
+3.3 Interpretation and representation of time values
+
+ A client acquires a lease for a network address for a fixed period of
+ time (which may be infinite). Throughout the protocol, times are to
+ be represented in units of seconds. The time value of 0xffffffff is
+ reserved to represent "infinity".
+
+ As clients and servers may not have synchronized clocks, times are
+ represented in DHCP messages as relative times, to be interpreted
+ with respect to the client's local clock. Representing relative
+ times in units of seconds in an unsigned 32 bit word gives a range of
+ relative times from 0 to approximately 100 years, which is sufficient
+ for the relative times to be measured using DHCP.
+
+ The algorithm for lease duration interpretation given in the previous
+ paragraph assumes that client and server clocks are stable relative
+ to each other. If there is drift between the two clocks, the server
+ may consider the lease expired before the client does. To
+ compensate, the server may return a shorter lease duration to the
+ client than the server commits to its local database of client
+ information.
+
+3.4 Obtaining parameters with externally configured network address
+
+ If a client has obtained a network address through some other means
+ (e.g., manual configuration), it may use a DHCPINFORM request message
+
+
+
+Droms Standards Track [Page 20]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ to obtain other local configuration parameters. Servers receiving a
+ DHCPINFORM message construct a DHCPACK message with any local
+ configuration parameters appropriate for the client without:
+ allocating a new address, checking for an existing binding, filling
+ in 'yiaddr' or including lease time parameters. The servers SHOULD
+ unicast the DHCPACK reply to the address given in the 'ciaddr' field
+ of the DHCPINFORM message.
+
+ The server SHOULD check the network address in a DHCPINFORM message
+ for consistency, but MUST NOT check for an existing lease. The
+ server forms a DHCPACK message containing the configuration
+ parameters for the requesting client and sends the DHCPACK message
+ directly to the client.
+
+3.5 Client parameters in DHCP
+
+ Not all clients require initialization of all parameters listed in
+ Appendix A. Two techniques are used to reduce the number of
+ parameters transmitted from the server to the client. First, most of
+ the parameters have defaults defined in the Host Requirements RFCs;
+ if the client receives no parameters from the server that override
+ the defaults, a client uses those default values. Second, in its
+ initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
+ server with a list of specific parameters the client is interested
+ in. If the client includes a list of parameters in a DHCPDISCOVER
+ message, it MUST include that list in any subsequent DHCPREQUEST
+ messages.
+
+ The client SHOULD include the 'maximum DHCP message size' option to
+ let the server know how large the server may make its DHCP messages.
+ The parameters returned to a client may still exceed the space
+ allocated to options in a DHCP message. In this case, two additional
+ options flags (which must appear in the 'options' field of the
+ message) indicate that the 'file' and 'sname' fields are to be used
+ for options.
+
+ The client can inform the server which configuration parameters the
+ client is interested in by including the 'parameter request list'
+ option. The data portion of this option explicitly lists the options
+ requested by tag number.
+
+ In addition, the client may suggest values for the network address
+ and lease time in the DHCPDISCOVER message. The client may include
+ the 'requested IP address' option to suggest that a particular IP
+ address be assigned, and may include the 'IP address lease time'
+ option to suggest the lease time it would like. Other options
+ representing "hints" at configuration parameters are allowed in a
+ DHCPDISCOVER or DHCPREQUEST message. However, additional options may
+
+
+
+Droms Standards Track [Page 21]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ be ignored by servers, and multiple servers may, therefore, not
+ return identical values for some options. The 'requested IP address'
+ option is to be filled in only in a DHCPREQUEST message when the
+ client is verifying network parameters obtained previously. The
+ client fills in the 'ciaddr' field only when correctly configured
+ with an IP address in BOUND, RENEWING or REBINDING state.
+
+ If a server receives a DHCPREQUEST message with an invalid 'requested
+ IP address', the server SHOULD respond to the client with a DHCPNAK
+ message and may choose to report the problem to the system
+ administrator. The server may include an error message in the
+ 'message' option.
+
+3.6 Use of DHCP in clients with multiple interfaces
+
+ A client with multiple network interfaces must use DHCP through each
+ interface independently to obtain configuration information
+ parameters for those separate interfaces.
+
+3.7 When clients should use DHCP
+
+ A client SHOULD use DHCP to reacquire or verify its IP address and
+ network parameters whenever the local network parameters may have
+ changed; e.g., at system boot time or after a disconnection from the
+ local network, as the local network configuration may change without
+ the client's or user's knowledge.
+
+ If a client has knowledge of a previous network address and is unable
+ to contact a local DHCP server, the client may continue to use the
+ previous network address until the lease for that address expires.
+ If the lease expires before the client can contact a DHCP server, the
+ client must immediately discontinue use of the previous network
+ address and may inform local users of the problem.
+
+4. Specification of the DHCP client-server protocol
+
+ In this section, we assume that a DHCP server has a block of network
+ addresses from which it can satisfy requests for new addresses. Each
+ server also maintains a database of allocated addresses and leases in
+ local permanent storage.
+
+4.1 Constructing and sending DHCP messages
+
+ DHCP clients and servers both construct DHCP messages by filling in
+ fields in the fixed format section of the message and appending
+ tagged data items in the variable length option area. The options
+ area includes first a four-octet 'magic cookie' (which was described
+ in section 3), followed by the options. The last option must always
+
+
+
+Droms Standards Track [Page 22]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ be the 'end' option.
+
+ DHCP uses UDP as its transport protocol. DHCP messages from a client
+ to a server are sent to the 'DHCP server' port (67), and DHCP
+ messages from a server to a client are sent to the 'DHCP client' port
+ (68). A server with multiple network address (e.g., a multi-homed
+ host) MAY use any of its network addresses in outgoing DHCP messages.
+
+ The 'server identifier' field is used both to identify a DHCP server
+ in a DHCP message and as a destination address from clients to
+ servers. A server with multiple network addresses MUST be prepared
+ to to accept any of its network addresses as identifying that server
+ in a DHCP message. To accommodate potentially incomplete network
+ connectivity, a server MUST choose an address as a 'server
+ identifier' that, to the best of the server's knowledge, is reachable
+ from the client. For example, if the DHCP server and the DHCP client
+ are connected to the same subnet (i.e., the 'giaddr' field in the
+ message from the client is zero), the server SHOULD select the IP
+ address the server is using for communication on that subnet as the
+ 'server identifier'. If the server is using multiple IP addresses on
+ that subnet, any such address may be used. If the server has
+ received a message through a DHCP relay agent, the server SHOULD
+ choose an address from the interface on which the message was
+ recieved as the 'server identifier' (unless the server has other,
+ better information on which to make its choice). DHCP clients MUST
+ use the IP address provided in the 'server identifier' option for any
+ unicast requests to the DHCP server.
+
+ DHCP messages broadcast by a client prior to that client obtaining
+ its IP address must have the source address field in the IP header
+ set to 0.
+
+ If the 'giaddr' field in a DHCP message from a client is non-zero,
+ the server sends any return messages to the 'DHCP server' port on the
+ BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
+ field is zero and the 'ciaddr' field is nonzero, then the server
+ unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
+ If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
+ set, then the server broadcasts DHCPOFFER and DHCPACK messages to
+ 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
+ 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
+ messages to the client's hardware address and 'yiaddr' address. In
+ all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
+ messages to 0xffffffff.
+
+ If the options in a DHCP message extend into the 'sname' and 'file'
+ fields, the 'option overload' option MUST appear in the 'options'
+ field, with value 1, 2 or 3, as specified in RFC 1533. If the
+
+
+
+Droms Standards Track [Page 23]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ 'option overload' option is present in the 'options' field, the
+ options in the 'options' field MUST be terminated by an 'end' option,
+ and MAY contain one or more 'pad' options to fill the options field.
+ The options in the 'sname' and 'file' fields (if in use as indicated
+ by the 'options overload' option) MUST begin with the first octet of
+ the field, MUST be terminated by an 'end' option, and MUST be
+ followed by 'pad' options to fill the remainder of the field. Any
+ individual option in the 'options', 'sname' and 'file' fields MUST be
+ entirely contained in that field. The options in the 'options' field
+ MUST be interpreted first, so that any 'option overload' options may
+ be interpreted. The 'file' field MUST be interpreted next (if the
+ 'option overload' option indicates that the 'file' field contains
+ DHCP options), followed by the 'sname' field.
+
+ The values to be passed in an 'option' tag may be too long to fit in
+ the 255 octets available to a single option (e.g., a list of routers
+ in a 'router' option [21]). Options may appear only once, unless
+ otherwise specified in the options document. The client concatenates
+ the values of multiple instances of the same option into a single
+ parameter list for configuration.
+
+ DHCP clients are responsible for all message retransmission. The
+ client MUST adopt a retransmission strategy that incorporates a
+ randomized exponential backoff algorithm to determine the delay
+ between retransmissions. The delay between retransmissions SHOULD be
+ chosen to allow sufficient time for replies from the server to be
+ delivered based on the characteristics of the internetwork between
+ the client and the server. For example, in a 10Mb/sec Ethernet
+ internetwork, the delay before the first retransmission SHOULD be 4
+ seconds randomized by the value of a uniform random number chosen
+ from the range -1 to +1. Clients with clocks that provide resolution
+ granularity of less than one second may choose a non-integer
+ randomization value. The delay before the next retransmission SHOULD
+ be 8 seconds randomized by the value of a uniform number chosen from
+ the range -1 to +1. The retransmission delay SHOULD be doubled with
+ subsequent retransmissions up to a maximum of 64 seconds. The client
+ MAY provide an indication of retransmission attempts to the user as
+ an indication of the progress of the configuration process.
+
+ The 'xid' field is used by the client to match incoming DHCP messages
+ with pending requests. A DHCP client MUST choose 'xid's in such a
+ way as to minimize the chance of using an 'xid' identical to one used
+ by another client. For example, a client may choose a different,
+ random initial 'xid' each time the client is rebooted, and
+ subsequently use sequential 'xid's until the next reboot. Selecting
+ a new 'xid' for each retransmission is an implementation decision. A
+ client may choose to reuse the same 'xid' or select a new 'xid' for
+ each retransmitted message.
+
+
+
+Droms Standards Track [Page 24]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Normally, DHCP servers and BOOTP relay agents attempt to deliver
+ DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
+ uicast delivery. The IP destination address (in the IP header) is
+ set to the DHCP 'yiaddr' address and the link-layer destination
+ address is set to the DHCP 'chaddr' address. Unfortunately, some
+ client implementations are unable to receive such unicast IP
+ datagrams until the implementation has been configured with a valid
+ IP address (leading to a deadlock in which the client's IP address
+ cannot be delivered until the client has been configured with an IP
+ address).
+
+ A client that cannot receive unicast IP datagrams until its protocol
+ software has been configured with an IP address SHOULD set the
+ BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
+ DHCPREQUEST messages that client sends. The BROADCAST bit will
+ provide a hint to the DHCP server and BOOTP relay agent to broadcast
+ any messages to the client on the client's subnet. A client that can
+ receive unicast IP datagrams before its protocol software has been
+ configured SHOULD clear the BROADCAST bit to 0. The BOOTP
+ clarifications document discusses the ramifications of the use of the
+ BROADCAST bit [21].
+
+ A server or relay agent sending or relaying a DHCP message directly
+ to a DHCP client (i.e., not to a relay agent specified in the
+ 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
+ field. If this bit is set to 1, the DHCP message SHOULD be sent as
+ an IP broadcast using an IP broadcast address (preferably 0xffffffff)
+ as the IP destination address and the link-layer broadcast address as
+ the link-layer destination address. If the BROADCAST bit is cleared
+ to 0, the message SHOULD be sent as an IP unicast to the IP address
+ specified in the 'yiaddr' field and the link-layer address specified
+ in the 'chaddr' field. If unicasting is not possible, the message
+ MAY be sent as an IP broadcast using an IP broadcast address
+ (preferably 0xffffffff) as the IP destination address and the link-
+ layer broadcast address as the link-layer destination address.
+
+4.2 DHCP server administrative controls
+
+ DHCP servers are not required to respond to every DHCPDISCOVER and
+ DHCPREQUEST message they receive. For example, a network
+ administrator, to retain stringent control over the clients attached
+ to the network, may choose to configure DHCP servers to respond only
+ to clients that have been previously registered through some external
+ mechanism. The DHCP specification describes only the interactions
+ between clients and servers when the clients and servers choose to
+ interact; it is beyond the scope of the DHCP specification to
+ describe all of the administrative controls that system
+ administrators might want to use. Specific DHCP server
+
+
+
+Droms Standards Track [Page 25]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ implementations may incorporate any controls or policies desired by a
+ network administrator.
+
+ In some environments, a DHCP server will have to consider the values
+ of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
+ messages when determining the correct parameters for a particular
+ client.
+
+ A DHCP server needs to use some unique identifier to associate a
+ client with its lease. The client MAY choose to explicitly provide
+ the identifier through the 'client identifier' option. If the client
+ supplies a 'client identifier', the client MUST use the same 'client
+ identifier' in all subsequent messages, and the server MUST use that
+ identifier to identify the client. If the client does not provide a
+ 'client identifier' option, the server MUST use the contents of the
+ 'chaddr' field to identify the client. It is crucial for a DHCP
+ client to use an identifier unique within the subnet to which the
+ client is attached in the 'client identifier' option. Use of
+ 'chaddr' as the client's unique identifier may cause unexpected
+ results, as that identifier may be associated with a hardware
+ interface that could be moved to a new client. Some sites may choose
+ to use a manufacturer's serial number as the 'client identifier', to
+ avoid unexpected changes in a clients network address due to transfer
+ of hardware interfaces among computers. Sites may also choose to use
+ a DNS name as the 'client identifier', causing address leases to be
+ associated with the DNS name rather than a specific hardware box.
+
+ DHCP clients are free to use any strategy in selecting a DHCP server
+ among those from which the client receives a DHCPOFFER message. The
+ client implementation of DHCP SHOULD provide a mechanism for the user
+ to select directly the 'vendor class identifier' values.
+
+4.3 DHCP server behavior
+
+ A DHCP server processes incoming DHCP messages from a client based on
+ the current state of the binding for that client. A DHCP server can
+ receive the following messages from a client:
+
+ o DHCPDISCOVER
+
+ o DHCPREQUEST
+
+ o DHCPDECLINE
+
+ o DHCPRELEASE
+
+ o DHCPINFORM
+
+
+
+
+Droms Standards Track [Page 26]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Table 3 gives the use of the fields and options in a DHCP message by
+ a server. The remainder of this section describes the action of the
+ DHCP server for each possible incoming message.
+
+4.3.1 DHCPDISCOVER message
+
+ When a server receives a DHCPDISCOVER message from a client, the
+ server chooses a network address for the requesting client. If no
+ address is available, the server may choose to report the problem to
+ the system administrator. If an address is available, the new address
+ SHOULD be chosen as follows:
+
+ o The client's current address as recorded in the client's current
+ binding, ELSE
+
+ o The client's previous address as recorded in the client's (now
+ expired or released) binding, if that address is in the server's
+ pool of available addresses and not already allocated, ELSE
+
+ o The address requested in the 'Requested IP Address' option, if that
+ address is valid and not already allocated, ELSE
+
+ o A new address allocated from the server's pool of available
+ addresses; the address is selected based on the subnet from which
+ the message was received (if 'giaddr' is 0) or on the address of
+ the relay agent that forwarded the message ('giaddr' when not 0).
+
+ As described in section 4.2, a server MAY, for administrative
+ reasons, assign an address other than the one requested, or may
+ refuse to allocate an address to a particular client even though free
+ addresses are available.
+
+ Note that, in some network architectures (e.g., internets with more
+ than one IP subnet assigned to a physical network segment), it may be
+ the case that the DHCP client should be assigned an address from a
+ different subnet than the address recorded in 'giaddr'. Thus, DHCP
+ does not require that the client be assigned as address from the
+ subnet in 'giaddr'. A server is free to choose some other subnet,
+ and it is beyond the scope of the DHCP specification to describe ways
+ in which the assigned IP address might be chosen.
+
+ While not required for correct operation of DHCP, the server SHOULD
+ NOT reuse the selected network address before the client responds to
+ the server's DHCPOFFER message. The server may choose to record the
+ address as offered to the client.
+
+ The server must also choose an expiration time for the lease, as
+ follows:
+
+
+
+Droms Standards Track [Page 27]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ o IF the client has not requested a specific lease in the
+ DHCPDISCOVER message and the client already has an assigned network
+ address, the server returns the lease expiration time previously
+ assigned to that address (note that the client must explicitly
+ request a specific lease to extend the expiration time on a
+ previously assigned address), ELSE
+
+ o IF the client has not requested a specific lease in the
+ DHCPDISCOVER message and the client does not have an assigned
+ network address, the server assigns a locally configured default
+ lease time, ELSE
+
+ o IF the client has requested a specific lease in the DHCPDISCOVER
+ message (regardless of whether the client has an assigned network
+ address), the server may choose either to return the requested
+ lease (if the lease is acceptable to local policy) or select
+ another lease.
+
+Field DHCPOFFER DHCPACK DHCPNAK
+----- --------- ------- -------
+'op' BOOTREPLY BOOTREPLY BOOTREPLY
+'htype' (From "Assigned Numbers" RFC)
+'hlen' (Hardware address length in octets)
+'hops' 0 0 0
+'xid' 'xid' from client 'xid' from client 'xid' from client
+ DHCPDISCOVER DHCPREQUEST DHCPREQUEST
+ message message message
+'secs' 0 0 0
+'ciaddr' 0 'ciaddr' from 0
+ DHCPREQUEST or 0
+'yiaddr' IP address offered IP address 0
+ to client assigned to client
+'siaddr' IP address of next IP address of next 0
+ bootstrap server bootstrap server
+'flags' 'flags' from 'flags' from 'flags' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
+ client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
+ message message message
+'sname' Server host name Server host name (unused)
+ or options or options
+'file' Client boot file Client boot file (unused)
+ name or options name or options
+'options' options options
+
+
+
+Droms Standards Track [Page 28]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Option DHCPOFFER DHCPACK DHCPNAK
+------ --------- ------- -------
+Requested IP address MUST NOT MUST NOT MUST NOT
+IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
+ MUST NOT (DHCPINFORM)
+Use 'file'/'sname' fields MAY MAY MUST NOT
+DHCP message type DHCPOFFER DHCPACK DHCPNAK
+Parameter request list MUST NOT MUST NOT MUST NOT
+Message SHOULD SHOULD SHOULD
+Client identifier MUST NOT MUST NOT MAY
+Vendor class identifier MAY MAY MAY
+Server identifier MUST MUST MUST
+Maximum message size MUST NOT MUST NOT MUST NOT
+All others MAY MAY MUST NOT
+
+ Table 3: Fields and options used by DHCP servers
+
+ Once the network address and lease have been determined, the server
+ constructs a DHCPOFFER message with the offered configuration
+ parameters. It is important for all DHCP servers to return the same
+ parameters (with the possible exception of a newly allocated network
+ address) to ensure predictable client behavior regardless of which
+ server the client selects. The configuration parameters MUST be
+ selected by applying the following rules in the order given below.
+ The network administrator is responsible for configuring multiple
+ DHCP servers to ensure uniform responses from those servers. The
+ server MUST return to the client:
+
+ o The client's network address, as determined by the rules given
+ earlier in this section,
+
+ o The expiration time for the client's lease, as determined by the
+ rules given earlier in this section,
+
+ o Parameters requested by the client, according to the following
+ rules:
+
+ -- IF the server has been explicitly configured with a default
+ value for the parameter, the server MUST include that value
+ in an appropriate option in the 'option' field, ELSE
+
+ -- IF the server recognizes the parameter as a parameter
+ defined in the Host Requirements Document, the server MUST
+ include the default value for that parameter as given in the
+ Host Requirements Document in an appropriate option in the
+ 'option' field, ELSE
+
+ -- The server MUST NOT return a value for that parameter,
+
+
+
+Droms Standards Track [Page 29]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ The server MUST supply as many of the requested parameters as
+ possible and MUST omit any parameters it cannot provide. The
+ server MUST include each requested parameter only once unless
+ explicitly allowed in the DHCP Options and BOOTP Vendor
+ Extensions document.
+
+ o Any parameters from the existing binding that differ from the Host
+ Requirements Document defaults,
+
+ o Any parameters specific to this client (as identified by
+ the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
+ or DHCPREQUEST message), e.g., as configured by the network
+ administrator,
+
+ o Any parameters specific to this client's class (as identified
+ by the contents of the 'vendor class identifier'
+ option in the DHCPDISCOVER or DHCPREQUEST message),
+ e.g., as configured by the network administrator; the parameters
+ MUST be identified by an exact match between the client's vendor
+ class identifiers and the client's classes identified in the
+ server,
+
+ o Parameters with non-default values on the client's subnet.
+
+ The server MAY choose to return the 'vendor class identifier' used to
+ determine the parameters in the DHCPOFFER message to assist the
+ client in selecting which DHCPOFFER to accept. The server inserts
+ the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
+ the DHCPOFFER message and sends the DHCPOFFER message to the
+ requesting client.
+
+4.3.2 DHCPREQUEST message
+
+ A DHCPREQUEST message may come from a client responding to a
+ DHCPOFFER message from a server, from a client verifying a previously
+ allocated IP address or from a client extending the lease on a
+ network address. If the DHCPREQUEST message contains a 'server
+ identifier' option, the message is in response to a DHCPOFFER
+ message. Otherwise, the message is a request to verify or extend an
+ existing lease. If the client uses a 'client identifier' in a
+ DHCPREQUEST message, it MUST use that same 'client identifier' in all
+ subsequent messages. If the client included a list of requested
+ parameters in a DHCPDISCOVER message, it MUST include that list in
+ all subsequent messages.
+
+
+
+
+
+
+
+Droms Standards Track [Page 30]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Any configuration parameters in the DHCPACK message SHOULD NOT
+ conflict with those in the earlier DHCPOFFER message to which the
+ client is responding. The client SHOULD use the parameters in the
+ DHCPACK message for configuration.
+
+ Clients send DHCPREQUEST messages as follows:
+
+ o DHCPREQUEST generated during SELECTING state:
+
+ Client inserts the address of the selected server in 'server
+ identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
+ filled in with the yiaddr value from the chosen DHCPOFFER.
+
+ Note that the client may choose to collect several DHCPOFFER
+ messages and select the "best" offer. The client indicates its
+ selection by identifying the offering server in the DHCPREQUEST
+ message. If the client receives no acceptable offers, the client
+ may choose to try another DHCPDISCOVER message. Therefore, the
+ servers may not receive a specific DHCPREQUEST from which they can
+ decide whether or not the client has accepted the offer. Because
+ the servers have not committed any network address assignments on
+ the basis of a DHCPOFFER, servers are free to reuse offered
+ network addresses in response to subsequent requests. As an
+ implementation detail, servers SHOULD NOT reuse offered addresses
+ and may use an implementation-specific timeout mechanism to decide
+ when to reuse an offered address.
+
+ o DHCPREQUEST generated during INIT-REBOOT state:
+
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST be filled in with client's notion of its previously
+ assigned address. 'ciaddr' MUST be zero. The client is seeking to
+ verify a previously allocated, cached configuration. Server SHOULD
+ send a DHCPNAK message to the client if the 'requested IP address'
+ is incorrect, or is on the wrong network.
+
+ Determining whether a client in the INIT-REBOOT state is on the
+ correct network is done by examining the contents of 'giaddr', the
+ 'requested IP address' option, and a database lookup. If the DHCP
+ server detects that the client is on the wrong net (i.e., the
+ result of applying the local subnet mask or remote subnet mask (if
+ 'giaddr' is not zero) to 'requested IP address' option value
+ doesn't match reality), then the server SHOULD send a DHCPNAK
+ message to the client.
+
+
+
+
+
+
+
+Droms Standards Track [Page 31]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ If the network is correct, then the DHCP server should check if
+ the client's notion of its IP address is correct. If not, then the
+ server SHOULD send a DHCPNAK message to the client. If the DHCP
+ server has no record of this client, then it MUST remain silent,
+ and MAY output a warning to the network administrator. This
+ behavior is necessary for peaceful coexistence of non-
+ communicating DHCP servers on the same wire.
+
+ If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
+ the same subnet as the server. The server MUST broadcast the
+ DHCPNAK message to the 0xffffffff broadcast address because the
+ client may not have a correct network address or subnet mask, and
+ the client may not be answering ARP requests.
+
+ If 'giaddr' is set in the DHCPREQUEST message, the client is on a
+ different subnet. The server MUST set the broadcast bit in the
+ DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
+ client, because the client may not have a correct network address
+ or subnet mask, and the client may not be answering ARP requests.
+
+ o DHCPREQUEST generated during RENEWING state:
+
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST NOT be filled in, 'ciaddr' MUST be filled in with
+ client's IP address. In this situation, the client is completely
+ configured, and is trying to extend its lease. This message will
+ be unicast, so no relay agents will be involved in its
+ transmission. Because 'giaddr' is therefore not filled in, the
+ DHCP server will trust the value in 'ciaddr', and use it when
+ replying to the client.
+
+ A client MAY choose to renew or extend its lease prior to T1. The
+ server may choose not to extend the lease (as a policy decision by
+ the network administrator), but should return a DHCPACK message
+ regardless.
+
+ o DHCPREQUEST generated during REBINDING state:
+
+ 'server identifier' MUST NOT be filled in, 'requested IP address'
+ option MUST NOT be filled in, 'ciaddr' MUST be filled in with
+ client's IP address. In this situation, the client is completely
+ configured, and is trying to extend its lease. This message MUST
+ be broadcast to the 0xffffffff IP broadcast address. The DHCP
+ server SHOULD check 'ciaddr' for correctness before replying to
+ the DHCPREQUEST.
+
+
+
+
+
+
+Droms Standards Track [Page 32]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ The DHCPREQUEST from a REBINDING client is intended to accommodate
+ sites that have multiple DHCP servers and a mechanism for
+ maintaining consistency among leases managed by multiple servers.
+ A DHCP server MAY extend a client's lease only if it has local
+ administrative authority to do so.
+
+4.3.3 DHCPDECLINE message
+
+ If the server receives a DHCPDECLINE message, the client has
+ discovered through some other means that the suggested network
+ address is already in use. The server MUST mark the network address
+ as not available and SHOULD notify the local system administrator of
+ a possible configuration problem.
+
+4.3.4 DHCPRELEASE message
+
+ Upon receipt of a DHCPRELEASE message, the server marks the network
+ address as not allocated. The server SHOULD retain a record of the
+ client's initialization parameters for possible reuse in response to
+ subsequent requests from the client.
+
+4.3.5 DHCPINFORM message
+
+ The server responds to a DHCPINFORM message by sending a DHCPACK
+ message directly to the address given in the 'ciaddr' field of the
+ DHCPINFORM message. The server MUST NOT send a lease expiration time
+ to the client and SHOULD NOT fill in 'yiaddr'. The server includes
+ other parameters in the DHCPACK message as defined in section 4.3.1.
+
+4.3.6 Client messages
+
+ Table 4 details the differences between messages from clients in
+ various states.
+
+ ---------------------------------------------------------------------
+ | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
+ ---------------------------------------------------------------------
+ |broad/unicast |broadcast |broadcast |unicast |broadcast |
+ |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
+ |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
+ |ciaddr |zero |zero |IP address |IP address|
+ ---------------------------------------------------------------------
+
+ Table 4: Client messages from different states
+
+
+
+
+
+
+
+Droms Standards Track [Page 33]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+4.4 DHCP client behavior
+
+ Figure 5 gives a state-transition diagram for a DHCP client. A
+ client can receive the following messages from a server:
+
+ o DHCPOFFER
+
+ o DHCPACK
+
+ o DHCPNAK
+
+ The DHCPINFORM message is not shown in figure 5. A client simply
+ sends the DHCPINFORM and waits for DHCPACK messages. Once the client
+ has selected its parameters, it has completed the configuration
+ process.
+
+ Table 5 gives the use of the fields and options in a DHCP message by
+ a client. The remainder of this section describes the action of the
+ DHCP client for each possible incoming message. The description in
+ the following section corresponds to the full configuration procedure
+ previously described in section 3.1, and the text in the subsequent
+ section corresponds to the abbreviated configuration procedure
+ described in section 3.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 34]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ -------- -------
+| | +-------------------------->| |<-------------------+
+| INIT- | | +-------------------->| INIT | |
+| REBOOT |DHCPNAK/ +---------->| |<---+ |
+| |Restart| | ------- | |
+ -------- | DHCPNAK/ | | |
+ | Discard offer | -/Send DHCPDISCOVER |
+-/Send DHCPREQUEST | | |
+ | | | DHCPACK v | |
+ ----------- | (not accept.)/ ----------- | |
+| | | Send DHCPDECLINE | | |
+| REBOOTING | | | | SELECTING |<----+ |
+| | | / | | |DHCPOFFER/ |
+ ----------- | / ----------- | |Collect |
+ | | / | | | replies |
+DHCPACK/ | / +----------------+ +-------+ |
+Record lease, set| | v Select offer/ |
+timers T1, T2 ------------ send DHCPREQUEST | |
+ | +----->| | DHCPNAK, Lease expired/ |
+ | | | REQUESTING | Halt network |
+ DHCPOFFER/ | | | |
+ Discard ------------ | |
+ | | | | ----------- |
+ | +--------+ DHCPACK/ | | |
+ | Record lease, set -----| REBINDING | |
+ | timers T1, T2 / | | |
+ | | DHCPACK/ ----------- |
+ | v Record lease, set ^ |
+ +----------------> ------- /timers T1,T2 | |
+ +----->| |<---+ | |
+ | | BOUND |<---+ | |
+ DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
+ DHCPNAK/Discard ------- | Broadcast Halt network
+ | | | | DHCPREQUEST |
+ +-------+ | DHCPACK/ | |
+ T1 expires/ Record lease, set | |
+ Send DHCPREQUEST timers T1, T2 | |
+ to leasing server | | |
+ | ---------- | |
+ | | |------------+ |
+ +->| RENEWING | |
+ | |----------------------------+
+ ----------
+ Figure 5: State-transition diagram for DHCP clients
+
+
+
+
+
+
+
+Droms Standards Track [Page 35]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+4.4.1 Initialization and allocation of network address
+
+ The client begins in INIT state and forms a DHCPDISCOVER message.
+ The client SHOULD wait a random time between one and ten seconds to
+ desynchronize the use of DHCP at startup. The client sets 'ciaddr'
+ to 0x00000000. The client MAY request specific parameters by
+ including the 'parameter request list' option. The client MAY
+ suggest a network address and/or lease time by including the
+ 'requested IP address' and 'IP address lease time' options. The
+ client MUST include its hardware address in the 'chaddr' field, if
+ necessary for delivery of DHCP reply messages. The client MAY
+ include a different unique identifier in the 'client identifier'
+ option, as discussed in section 4.2. If the client included a list
+ of requested parameters in a DHCPDISCOVER message, it MUST include
+ that list in all subsequent messages.
+
+ The client generates and records a random transaction identifier and
+ inserts that identifier into the 'xid' field. The client records its
+ own local time for later use in computing the lease expiration. The
+ client then broadcasts the DHCPDISCOVER on the local hardware
+ broadcast address to the 0xffffffff IP broadcast address and 'DHCP
+ server' UDP port.
+
+ If the 'xid' of an arriving DHCPOFFER message does not match the
+ 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
+ must be silently discarded. Any arriving DHCPACK messages must be
+ silently discarded.
+
+ The client collects DHCPOFFER messages over a period of time, selects
+ one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
+ messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
+ from the previously used server) and extracts the server address from
+ the 'server identifier' option in the DHCPOFFER message. The time
+ over which the client collects messages and the mechanism used to
+ select one DHCPOFFER are implementation dependent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 36]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPINFORM DHCPRELEASE
+----- ------------ ----------- -----------
+'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
+'htype' (From "Assigned Numbers" RFC)
+'hlen' (Hardware address length in octets)
+'hops' 0 0 0
+'xid' selected by client 'xid' from server selected by
+ DHCPOFFER message client
+'secs' 0 or seconds since 0 or seconds since 0
+ DHCP process started DHCP process started
+'flags' Set 'BROADCAST' Set 'BROADCAST' 0
+ flag if client flag if client
+ requires broadcast requires broadcast
+ reply reply
+'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
+ client's network address client's network
+ network address (BOUND/RENEW/REBIND) address
+ (DHCPINFORM) (DHCPRELEASE)
+'yiaddr' 0 0 0
+'siaddr' 0 0 0
+'giaddr' 0 0 0
+'chaddr' client's hardware client's hardware client's hardware
+ address address address
+'sname' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ unused unused
+'file' options, if options, if (unused)
+ indicated in indicated in
+ 'sname/file' 'sname/file'
+ option; otherwise option; otherwise
+ unused unused
+'options' options options (unused)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 37]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
+ DHCPINFORM DHCPRELEASE
+------ ------------ ----------- -----------
+Requested IP address MAY MUST (in MUST
+ (DISCOVER) SELECTING or (DHCPDECLINE),
+ MUST NOT INIT-REBOOT) MUST NOT
+ (INFORM) MUST NOT (in (DHCPRELEASE)
+ BOUND or
+ RENEWING)
+IP address lease time MAY MAY MUST NOT
+ (DISCOVER)
+ MUST NOT
+ (INFORM)
+Use 'file'/'sname' fields MAY MAY MAY
+DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
+ DHCPINFORM DHCPRELEASE
+Client identifier MAY MAY MAY
+Vendor class identifier MAY MAY MUST NOT
+Server identifier MUST NOT MUST (after MUST
+ SELECTING)
+ MUST NOT (after
+ INIT-REBOOT,
+ BOUND, RENEWING
+ or REBINDING)
+Parameter request list MAY MAY MUST NOT
+Maximum message size MAY MAY MUST NOT
+Message SHOULD NOT SHOULD NOT SHOULD
+Site-specific MAY MAY MUST NOT
+All others MAY MAY MUST NOT
+
+ Table 5: Fields and options used by DHCP clients
+
+ If the parameters are acceptable, the client records the address of
+ the server that supplied the parameters from the 'server identifier'
+ field and sends that address in the 'server identifier' field of a
+ DHCPREQUEST broadcast message. Once the DHCPACK message from the
+ server arrives, the client is initialized and moves to BOUND state.
+ The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
+ message. The client records the lease expiration time as the sum of
+ the time at which the original request was sent and the duration of
+ the lease from the DHCPACK message. The client SHOULD perform a
+ check on the suggested address to ensure that the address is not
+ already in use. For example, if the client is on a network that
+ supports ARP, the client may issue an ARP request for the suggested
+ request. When broadcasting an ARP request for the suggested address,
+ the client must fill in its own hardware address as the sender's
+ hardware address, and 0 as the sender's IP address, to avoid
+ confusing ARP caches in other hosts on the same subnet. If the
+
+
+
+Droms Standards Track [Page 38]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ network address appears to be in use, the client MUST send a
+ DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
+ reply to announce the client's new IP address and clear any outdated
+ ARP cache entries in hosts on the client's subnet.
+
+4.4.2 Initialization with known network address
+
+ The client begins in INIT-REBOOT state and sends a DHCPREQUEST
+ message. The client MUST insert its known network address as a
+ 'requested IP address' option in the DHCPREQUEST message. The client
+ may request specific configuration parameters by including the
+ 'parameter request list' option. The client generates and records a
+ random transaction identifier and inserts that identifier into the
+ 'xid' field. The client records its own local time for later use in
+ computing the lease expiration. The client MUST NOT include a
+ 'server identifier' in the DHCPREQUEST message. The client then
+ broadcasts the DHCPREQUEST on the local hardware broadcast address to
+ the 'DHCP server' UDP port.
+
+ Once a DHCPACK message with an 'xid' field matching that in the
+ client's DHCPREQUEST message arrives from any server, the client is
+ initialized and moves to BOUND state. The client records the lease
+ expiration time as the sum of the time at which the DHCPREQUEST
+ message was sent and the duration of the lease from the DHCPACK
+ message.
+
+4.4.3 Initialization with an externally assigned network address
+
+ The client sends a DHCPINFORM message. The client may request
+ specific configuration parameters by including the 'parameter request
+ list' option. The client generates and records a random transaction
+ identifier and inserts that identifier into the 'xid' field. The
+ client places its own network address in the 'ciaddr' field. The
+ client SHOULD NOT request lease time parameters.
+
+ The client then unicasts the DHCPINFORM to the DHCP server if it
+ knows the server's address, otherwise it broadcasts the message to
+ the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
+ directed to the 'DHCP server' UDP port.
+
+ Once a DHCPACK message with an 'xid' field matching that in the
+ client's DHCPINFORM message arrives from any server, the client is
+ initialized.
+
+ If the client does not receive a DHCPACK within a reasonable period
+ of time (60 seconds or 4 tries if using timeout suggested in section
+ 4.1), then it SHOULD display a message informing the user of the
+ problem, and then SHOULD begin network processing using suitable
+
+
+
+Droms Standards Track [Page 39]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ defaults as per Appendix A.
+
+4.4.4 Use of broadcast and unicast
+
+ The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
+ messages, unless the client knows the address of a DHCP server. The
+ client unicasts DHCPRELEASE messages to the server. Because the
+ client is declining the use of the IP address supplied by the server,
+ the client broadcasts DHCPDECLINE messages.
+
+ When the DHCP client knows the address of a DHCP server, in either
+ INIT or REBOOTING state, the client may use that address in the
+ DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
+ The client may also use unicast to send DHCPINFORM messages to a
+ known DHCP server. If the client receives no response to DHCP
+ messages sent to the IP address of a known DHCP server, the DHCP
+ client reverts to using the IP broadcast address.
+
+4.4.5 Reacquisition and expiration
+
+ The client maintains two times, T1 and T2, that specify the times at
+ which the client tries to extend its lease on its network address.
+ T1 is the time at which the client enters the RENEWING state and
+ attempts to contact the server that originally issued the client's
+ network address. T2 is the time at which the client enters the
+ REBINDING state and attempts to contact any server. T1 MUST be
+ earlier than T2, which, in turn, MUST be earlier than the time at
+ which the client's lease will expire.
+
+ To avoid the need for synchronized clocks, T1 and T2 are expressed in
+ options as relative times [2].
+
+ At time T1 the client moves to RENEWING state and sends (via unicast)
+ a DHCPREQUEST message to the server to extend its lease. The client
+ sets the 'ciaddr' field in the DHCPREQUEST to its current network
+ address. The client records the local time at which the DHCPREQUEST
+ message is sent for computation of the lease expiration time. The
+ client MUST NOT include a 'server identifier' in the DHCPREQUEST
+ message.
+
+ Any DHCPACK messages that arrive with an 'xid' that does not match
+ the 'xid' of the client's DHCPREQUEST message are silently discarded.
+ When the client receives a DHCPACK from the server, the client
+ computes the lease expiration time as the sum of the time at which
+ the client sent the DHCPREQUEST message and the duration of the lease
+ in the DHCPACK message. The client has successfully reacquired its
+ network address, returns to BOUND state and may continue network
+ processing.
+
+
+
+Droms Standards Track [Page 40]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ If no DHCPACK arrives before time T2, the client moves to REBINDING
+ state and sends (via broadcast) a DHCPREQUEST message to extend its
+ lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
+ current network address. The client MUST NOT include a 'server
+ identifier' in the DHCPREQUEST message.
+
+ Times T1 and T2 are configurable by the server through options. T1
+ defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
+ duration_of_lease). Times T1 and T2 SHOULD be chosen with some
+ random "fuzz" around a fixed value, to avoid synchronization of
+ client reacquisition.
+
+ A client MAY choose to renew or extend its lease prior to T1. The
+ server MAY choose to extend the client's lease according to policy
+ set by the network administrator. The server SHOULD return T1 and
+ T2, and their values SHOULD be adjusted from their original values to
+ take account of the time remaining on the lease.
+
+ In both RENEWING and REBINDING states, if the client receives no
+ response to its DHCPREQUEST message, the client SHOULD wait one-half
+ of the remaining time until T2 (in RENEWING state) and one-half of
+ the remaining lease time (in REBINDING state), down to a minimum of
+ 60 seconds, before retransmitting the DHCPREQUEST message.
+
+ If the lease expires before the client receives a DHCPACK, the client
+ moves to INIT state, MUST immediately stop any other network
+ processing and requests network initialization parameters as if the
+ client were uninitialized. If the client then receives a DHCPACK
+ allocating that client its previous network address, the client
+ SHOULD continue network processing. If the client is given a new
+ network address, it MUST NOT continue using the previous network
+ address and SHOULD notify the local users of the problem.
+
+4.4.6 DHCPRELEASE
+
+ If the client no longer requires use of its assigned network address
+ (e.g., the client is gracefully shut down), the client sends a
+ DHCPRELEASE message to the server. Note that the correct operation
+ of DHCP does not depend on the transmission of DHCPRELEASE messages.
+
+
+
+
+
+
+
+
+
+
+
+
+Droms Standards Track [Page 41]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+5. Acknowledgments
+
+ The author thanks the many (and too numerous to mention!) members of
+ the DHC WG for their tireless and ongoing efforts in the development
+ of DHCP and this document.
+
+ The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
+ Mendonca in organizing DHCP interoperability testing sessions are
+ gratefully acknowledged.
+
+ The development of this document was supported in part by grants from
+ the Corporation for National Research Initiatives (CNRI), Bucknell
+ University and Sun Microsystems.
+
+6. References
+
+ [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
+ 1983.
+
+ [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
+ University, October 1993.
+
+ [3] Braden, R., Editor, "Requirements for Internet Hosts --
+ Communication Layers", STD 3, RFC 1122, USC/Information Sciences
+ Institute, October 1989.
+
+ [4] Braden, R., Editor, "Requirements for Internet Hosts --
+ Application and Support, STD 3, RFC 1123, USC/Information
+ Sciences Institute, October 1989.
+
+ [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
+ (DRARP)", Work in Progress.
+
+ [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
+ Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
+ Communications Review), 20(4):50--59, 1990.
+
+ [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
+ Stanford and SUN Microsystems, September 1985.
+
+ [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
+ PARC, September 1991.
+
+ [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
+ Bucknell University, October 1993.
+
+
+
+
+
+Droms Standards Track [Page 42]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
+ Address Resolution Protocol", RFC 903, Stanford, June 1984.
+
+ [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
+ Mechanism for Distributed File Cache Consistency", In Proc. of
+ the Twelfth ACM Symposium on Operating Systems Design, 1989.
+
+ [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+ 13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [13] Mockapetris, P., "Domain Names -- Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+ [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
+ November 1990.
+
+ [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
+ Hosts", Work in Progress.
+
+ [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
+ USC/Information Sciences Institute, September 1981.
+
+ [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
+ USC/Information Sciences Institute, August 1993.
+
+ [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ USC/Information Sciences Institute, October 1994.
+
+ [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
+ Assignment of IP Addresses for use on an Ethernet. (Available
+ from the Athena Project, MIT), 1989.
+
+ [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
+ June 1981.
+
+ [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
+ Protocol", RFC 1542, Carnegie Mellon University, October 1993.
+
+7. Security Considerations
+
+ DHCP is built directly on UDP and IP which are as yet inherently
+ insecure. Furthermore, DHCP is generally intended to make
+ maintenance of remote and/or diskless hosts easier. While perhaps
+ not impossible, configuring such hosts with passwords or keys may be
+ difficult and inconvenient. Therefore, DHCP in its current form is
+ quite insecure.
+
+
+
+
+Droms Standards Track [Page 43]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+ Unauthorized DHCP servers may be easily set up. Such servers can
+ then send false and potentially disruptive information to clients
+ such as incorrect or duplicate IP addresses, incorrect routing
+ information (including spoof routers, etc.), incorrect domain
+ nameserver addresses (such as spoof nameservers), and so on.
+ Clearly, once this seed information is in place, an attacker can
+ further compromise affected systems.
+
+ Malicious DHCP clients could masquerade as legitimate clients and
+ retrieve information intended for those legitimate clients. Where
+ dynamic allocation of resources is used, a malicious client could
+ claim all resources for itself, thereby denying resources to
+ legitimate clients.
+
+8. 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 Standards Track [Page 44]
+
+RFC 2131 Dynamic Host Configuration Protocol March 1997
+
+
+A. Host Configuration Parameters
+
+ IP-layer_parameters,_per_host:_
+
+ Be a router on/off HRC 3.1
+ Non-local source routing on/off HRC 3.3.5
+ Policy filters for
+ non-local source routing (list) HRC 3.3.5
+ Maximum reassembly size integer HRC 3.3.2
+ Default TTL integer HRC 3.2.1.7
+ PMTU aging timeout integer MTU 6.6
+ MTU plateau table (list) MTU 7
+ IP-layer_parameters,_per_interface:_
+ IP address (address) HRC 3.3.1.6
+ Subnet mask (address mask) HRC 3.3.1.6
+ MTU integer HRC 3.3.3
+ All-subnets-MTU on/off HRC 3.3.3
+ Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
+ Perform mask discovery on/off HRC 3.2.2.9
+ Be a mask supplier on/off HRC 3.2.2.9
+ Perform router discovery on/off RD 5.1
+ Router solicitation address (address) RD 5.1
+ Default routers, list of:
+ router address (address) HRC 3.3.1.6
+ preference level integer HRC 3.3.1.6
+ Static routes, list of:
+ destination (host/subnet/net) HRC 3.3.1.2
+ destination mask (address mask) HRC 3.3.1.2
+ type-of-service integer HRC 3.3.1.2
+ first-hop router (address) HRC 3.3.1.2
+ ignore redirects on/off HRC 3.3.1.2
+ PMTU integer MTU 6.6
+ perform PMTU discovery on/off MTU 6.6
+
+ Link-layer_parameters,_per_interface:_
+ Trailers on/off HRC 2.3.1
+ ARP cache timeout integer HRC 2.3.2.1
+ Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
+
+ TCP_parameters,_per_host:_
+ TTL integer HRC 4.2.2.19
+ Keep-alive interval integer HRC 4.2.3.6
+ Keep-alive data size 0/1 HRC 4.2.3.6
+
+Key:
+
+ MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
+ RD = Router Discovery (RFC 1256, Proposed Standard)
+
+
+
+Droms Standards Track [Page 45]
+
diff --git a/contrib/isc-dhcp/doc/rfc2132.txt b/contrib/isc-dhcp/doc/rfc2132.txt
new file mode 100644
index 000000000000..e9c4f4b30ac0
--- /dev/null
+++ b/contrib/isc-dhcp/doc/rfc2132.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group S. Alexander
+Request for Comments: 2132 Silicon Graphics, Inc.
+Obsoletes: 1533 R. Droms
+Category: Standards Track Bucknell University
+ March 1997
+
+ DHCP Options and BOOTP Vendor Extensions
+
+Status of this memo
+
+ This document 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" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ The Dynamic Host Configuration Protocol (DHCP) [1] provides a
+ framework for passing configuration information to hosts on a TCP/IP
+ network. Configuration parameters and other control information are
+ carried in tagged data items that are stored in the 'options' field
+ of the DHCP message. The data items themselves are also called
+ "options."
+
+ This document specifies the current set of DHCP options. Future
+ options will be specified in separate RFCs. The current list of
+ valid options is also available in ftp://ftp.isi.edu/in-
+ notes/iana/assignments [22].
+
+ All of the vendor information extensions defined in RFC 1497 [2] may
+ be used as DHCP options. The definitions given in RFC 1497 are
+ included in this document, which supersedes RFC 1497. All of the
+ DHCP options defined in this document, except for those specific to
+ DHCP as defined in section 9, may be used as BOOTP vendor information
+ extensions.
+
+Table of Contents
+
+ 1. Introduction .............................................. 2
+ 2. BOOTP Extension/DHCP Option Field Format .................. 4
+ 3. RFC 1497 Vendor Extensions ................................ 5
+ 4. IP Layer Parameters per Host .............................. 11
+ 5. IP Layer Parameters per Interface ........................ 13
+ 6. Link Layer Parameters per Interface ....................... 16
+ 7. TCP Parameters ............................................ 17
+ 8. Application and Service Parameters ........................ 18
+ 9. DHCP Extensions ........................................... 25
+
+
+
+Alexander & Droms Standards Track [Page 1]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ 10. Defining new extensions ................................... 31
+ 11. Acknowledgements .......................................... 31
+ 12. References ................................................ 32
+ 13. Security Considerations ................................... 33
+ 14. Authors' Addresses ........................................ 34
+
+1. Introduction
+
+ This document specifies options for use with both the Dynamic Host
+ Configuration Protocol and the Bootstrap Protocol.
+
+ The full description of DHCP packet formats may be found in the DHCP
+ specification document [1], and the full description of BOOTP packet
+ formats may be found in the BOOTP specification document [3]. This
+ document defines the format of information in the last field of DHCP
+ packets ('options') and of BOOTP packets ('vend'). The remainder of
+ this section defines a generalized use of this area for giving
+ information useful to a wide class of machines, operating systems and
+ configurations. Sites with a single DHCP or BOOTP server that is
+ shared among heterogeneous clients may choose to define other, site-
+ specific formats for the use of the 'options' field.
+
+ Section 2 of this memo describes the formats of DHCP options and
+ BOOTP vendor extensions. Section 3 describes options defined in
+ previous documents for use with BOOTP (all may also be used with
+ DHCP). Sections 4-8 define new options intended for use with both
+ DHCP and BOOTP. Section 9 defines options used only in DHCP.
+
+ References further describing most of the options defined in sections
+ 2-6 can be found in section 12. The use of the options defined in
+ section 9 is described in the DHCP specification [1].
+
+ Information on registering new options is contained in section 10.
+
+ This document updates the definition of DHCP/BOOTP options that
+ appears in RFC1533. The classing mechanism has been extended to
+ include vendor classes as described in section 8.4 and 9.13. The new
+ procedure for defining new DHCP/BOOTP options in described in section
+ 10. Several new options, including NIS+ domain and servers, Mobile
+ IP home agent, SMTP server, TFTP server and Bootfile server, have
+ been added. Text giving definitions used throughout the document has
+ been added in section 1.1. Text emphasizing the need for uniqueness
+ of client-identifiers has been added to section 9.14.
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 2]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+1.1 Requirements
+
+ Throughout this document, the words that are used to define the
+ significance of particular requirements are capitalized. These words
+ are:
+
+ o "MUST"
+
+ This word or the adjective "REQUIRED" means that the item is an
+ absolute requirement of this specification.
+
+ o "MUST NOT"
+
+ This phrase means that the item is an absolute prohibition of
+ this specification.
+
+ o "SHOULD"
+
+ This word or the adjective "RECOMMENDED" means that there may
+ exist valid reasons in particular circumstances to ignore this
+ item, but the full implications should be understood and the case
+ carefully weighed before choosing a different course.
+
+ o "SHOULD NOT"
+
+ This phrase means that there may exist valid reasons in
+ particular circumstances when the listed behavior is acceptable
+ or even useful, but the full implications should be understood
+ and the case carefully weighed before implementing any behavior
+ described with this label.
+
+ o "MAY"
+
+ This word or the adjective "OPTIONAL" means that this item is
+ truly optional. One vendor may choose to include the item
+ because a particular marketplace requires it or because it
+ enhances the product, for example; another vendor may omit the
+ same item.
+
+1.2 Terminology
+
+ This document uses the following terms:
+
+ o "DHCP client"
+
+ A DHCP client or "client" is an Internet host using DHCP to
+ obtain configuration parameters such as a network address.
+
+
+
+
+Alexander & Droms Standards Track [Page 3]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ o "DHCP server"
+
+ A DHCP server of "server"is an Internet host that returns
+ configuration parameters to DHCP clients.
+
+ o "binding"
+
+ A binding is a collection of configuration parameters, including
+ at least an IP address, associated with or "bound to" a DHCP
+ client. Bindings are managed by DHCP servers.
+
+2. BOOTP Extension/DHCP Option Field Format
+
+
+ DHCP options have the same format as the BOOTP 'vendor extensions'
+ defined in RFC 1497 [2]. Options may be fixed length or variable
+ length. All options begin with a tag octet, which uniquely
+ identifies the option. Fixed-length options without data consist of
+ only a tag octet. Only options 0 and 255 are fixed length. All
+ other options are variable-length with a length octet following the
+ tag octet. The value of the length octet does not include the two
+ octets specifying the tag and length. The length octet is followed
+ by "length" octets of data. Options containing NVT ASCII data SHOULD
+ NOT include a trailing NULL; however, the receiver of such options
+ MUST be prepared to delete trailing nulls if they exist. The
+ receiver MUST NOT require that a trailing null be included in the
+ data. In the case of some variable-length options the length field
+ is a constant but must still be specified.
+
+ Any options defined subsequent to this document MUST contain a length
+ octet even if the length is fixed or zero.
+
+ All multi-octet quantities are in network byte-order.
+
+ When used with BOOTP, the first four octets of the vendor information
+ field have been assigned to the "magic cookie" (as suggested in RFC
+ 951). This field identifies the mode in which the succeeding data is
+ to be interpreted. The value of the magic cookie is the 4 octet
+ dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
+ network byte order.
+
+ All of the "vendor extensions" defined in RFC 1497 are also DHCP
+ options.
+
+ Option codes 128 to 254 (decimal) are reserved for site-specific
+ options.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 4]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Except for the options in section 9, all options may be used with
+ either DHCP or BOOTP.
+
+ Many of these options have their default values specified in other
+ documents. In particular, RFC 1122 [4] specifies default values for
+ most IP and TCP configuration parameters.
+
+ Many options supply one or more 32-bit IP address. Use of IP
+ addresses rather than fully-qualified Domain Names (FQDNs) may make
+ future renumbering of IP hosts more difficult. Use of these
+ addresses is discouraged at sites that may require renumbering.
+
+3. RFC 1497 Vendor Extensions
+
+ This section lists the vendor extensions as defined in RFC 1497.
+ They are defined here for completeness.
+
+3.1. Pad Option
+
+ The pad option can be used to cause subsequent fields to align on
+ word boundaries.
+
+ The code for the pad option is 0, and its length is 1 octet.
+
+ Code
+ +-----+
+ | 0 |
+ +-----+
+
+3.2. End Option
+
+ The end option marks the end of valid information in the vendor
+ field. Subsequent octets should be filled with pad options.
+
+ The code for the end option is 255, and its length is 1 octet.
+
+ Code
+ +-----+
+ | 255 |
+ +-----+
+
+3.3. Subnet Mask
+
+ The subnet mask option specifies the client's subnet mask as per RFC
+ 950 [5].
+
+ If both the subnet mask and the router option are specified in a DHCP
+ reply, the subnet mask option MUST be first.
+
+
+
+Alexander & Droms Standards Track [Page 5]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for the subnet mask option is 1, and its length is 4 octets.
+
+ Code Len Subnet Mask
+ +-----+-----+-----+-----+-----+-----+
+ | 1 | 4 | m1 | m2 | m3 | m4 |
+ +-----+-----+-----+-----+-----+-----+
+
+3.4. Time Offset
+
+ The time offset field specifies the offset of the client's subnet in
+ seconds from Coordinated Universal Time (UTC). The offset is
+ expressed as a two's complement 32-bit integer. A positive offset
+ indicates a location east of the zero meridian and a negative offset
+ indicates a location west of the zero meridian.
+
+ The code for the time offset option is 2, and its length is 4 octets.
+
+ Code Len Time Offset
+ +-----+-----+-----+-----+-----+-----+
+ | 2 | 4 | n1 | n2 | n3 | n4 |
+ +-----+-----+-----+-----+-----+-----+
+
+3.5. Router Option
+
+ The router option specifies a list of IP addresses for routers on the
+ client's subnet. Routers SHOULD be listed in order of preference.
+
+ The code for the router option is 3. The minimum length for the
+ router option is 4 octets, and the length MUST always be a multiple
+ of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.6. Time Server Option
+
+ The time server option specifies a list of RFC 868 [6] time servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for the time server option is 4. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 6]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.7. Name Server Option
+
+ The name server option specifies a list of IEN 116 [7] name servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for the name server option is 5. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.8. Domain Name Server Option
+
+ The domain name server option specifies a list of Domain Name System
+ (STD 13, RFC 1035 [8]) name servers available to the client. Servers
+ SHOULD be listed in order of preference.
+
+ The code for the domain name server option is 6. The minimum length
+ for this option is 4 octets, and the length MUST always be a multiple
+ of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.9. Log Server Option
+
+ The log server option specifies a list of MIT-LCS UDP log servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for the log server option is 7. The minimum length for this
+ option is 4 octets, and the length MUST always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+
+Alexander & Droms Standards Track [Page 7]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+3.10. Cookie Server Option
+
+ The cookie server option specifies a list of RFC 865 [9] cookie
+ servers available to the client. Servers SHOULD be listed in order
+ of preference.
+
+ The code for the log server option is 8. The minimum length for this
+ option is 4 octets, and the length MUST always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.11. LPR Server Option
+
+ The LPR server option specifies a list of RFC 1179 [10] line printer
+ servers available to the client. Servers SHOULD be listed in order
+ of preference.
+
+ The code for the LPR server option is 9. The minimum length for this
+ option is 4 octets, and the length MUST always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.12. Impress Server Option
+
+ The Impress server option specifies a list of Imagen Impress servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for the Impress server option is 10. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.13. Resource Location Server Option
+
+ This option specifies a list of RFC 887 [11] Resource Location
+ servers available to the client. Servers SHOULD be listed in order
+ of preference.
+
+
+
+Alexander & Droms Standards Track [Page 8]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 11. The minimum length for this option
+ is 4 octets, and the length MUST always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.14. Host Name Option
+
+ This option specifies the name of the client. The name may or may
+ not be qualified with the local domain name (see section 3.17 for the
+ preferred way to retrieve the domain name). See RFC 1035 for
+ character set restrictions.
+
+ The code for this option is 12, and its minimum length is 1.
+
+ Code Len Host Name
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+3.15. Boot File Size Option
+
+ This option specifies the length in 512-octet blocks of the default
+ boot image for the client. The file length is specified as an
+ unsigned 16-bit integer.
+
+ The code for this option is 13, and its length is 2.
+
+ Code Len File Size
+ +-----+-----+-----+-----+
+ | 13 | 2 | l1 | l2 |
+ +-----+-----+-----+-----+
+
+3.16. Merit Dump File
+
+ This option specifies the path-name of a file to which the client's
+ core image should be dumped in the event the client crashes. The
+ path is formatted as a character string consisting of characters from
+ the NVT ASCII character set.
+
+ The code for this option is 14. Its minimum length is 1.
+
+ Code Len Dump File Pathname
+ +-----+-----+-----+-----+-----+-----+---
+ | 14 | n | n1 | n2 | n3 | n4 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+
+
+Alexander & Droms Standards Track [Page 9]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+3.17. Domain Name
+
+ This option specifies the domain name that client should use when
+ resolving hostnames via the Domain Name System.
+
+ The code for this option is 15. Its minimum length is 1.
+
+ Code Len Domain Name
+ +-----+-----+-----+-----+-----+-----+--
+ | 15 | n | d1 | d2 | d3 | d4 | ...
+ +-----+-----+-----+-----+-----+-----+--
+
+3.18. Swap Server
+
+ This specifies the IP address of the client's swap server.
+
+ The code for this option is 16 and its length is 4.
+
+ Code Len Swap Server Address
+ +-----+-----+-----+-----+-----+-----+
+ | 16 | n | a1 | a2 | a3 | a4 |
+ +-----+-----+-----+-----+-----+-----+
+
+3.19. Root Path
+
+ This option specifies the path-name that contains the client's root
+ disk. The path is formatted as a character string consisting of
+ characters from the NVT ASCII character set.
+
+ The code for this option is 17. Its minimum length is 1.
+
+ Code Len Root Disk Pathname
+ +-----+-----+-----+-----+-----+-----+---
+ | 17 | n | n1 | n2 | n3 | n4 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+3.20. Extensions Path
+
+ A string to specify a file, retrievable via TFTP, which contains
+ information which can be interpreted in the same way as the 64-octet
+ vendor-extension field within the BOOTP response, with the following
+ exceptions:
+
+ - the length of the file is unconstrained;
+ - all references to Tag 18 (i.e., instances of the
+ BOOTP Extensions Path field) within the file are
+ ignored.
+
+
+
+
+Alexander & Droms Standards Track [Page 10]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 18. Its minimum length is 1.
+
+ Code Len Extensions Pathname
+ +-----+-----+-----+-----+-----+-----+---
+ | 18 | n | n1 | n2 | n3 | n4 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+4. IP Layer Parameters per Host
+
+ This section details the options that affect the operation of the IP
+ layer on a per-host basis.
+
+4.1. IP Forwarding Enable/Disable Option
+
+ This option specifies whether the client should configure its IP
+ layer for packet forwarding. A value of 0 means disable IP
+ forwarding, and a value of 1 means enable IP forwarding.
+
+ The code for this option is 19, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 19 | 1 | 0/1 |
+ +-----+-----+-----+
+
+4.2. Non-Local Source Routing Enable/Disable Option
+
+ This option specifies whether the client should configure its IP
+ layer to allow forwarding of datagrams with non-local source routes
+ (see Section 3.3.5 of [4] for a discussion of this topic). A value
+ of 0 means disallow forwarding of such datagrams, and a value of 1
+ means allow forwarding.
+
+ The code for this option is 20, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 20 | 1 | 0/1 |
+ +-----+-----+-----+
+
+4.3. Policy Filter Option
+
+ This option specifies policy filters for non-local source routing.
+ The filters consist of a list of IP addresses and masks which specify
+ destination/mask pairs with which to filter incoming source routes.
+
+ Any source routed datagram whose next-hop address does not match one
+ of the filters should be discarded by the client.
+
+
+
+Alexander & Droms Standards Track [Page 11]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ See [4] for further information.
+
+ The code for this option is 21. The minimum length of this option is
+ 8, and the length MUST be a multiple of 8.
+
+ Code Len Address 1 Mask 1
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ Address 2 Mask 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+ | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+4.4. Maximum Datagram Reassembly Size
+
+ This option specifies the maximum size datagram that the client
+ should be prepared to reassemble. The size is specified as a 16-bit
+ unsigned integer. The minimum value legal value is 576.
+
+ The code for this option is 22, and its length is 2.
+
+ Code Len Size
+ +-----+-----+-----+-----+
+ | 22 | 2 | s1 | s2 |
+ +-----+-----+-----+-----+
+
+4.5. Default IP Time-to-live
+
+ This option specifies the default time-to-live that the client should
+ use on outgoing datagrams. The TTL is specified as an octet with a
+ value between 1 and 255.
+
+ The code for this option is 23, and its length is 1.
+
+ Code Len TTL
+ +-----+-----+-----+
+ | 23 | 1 | ttl |
+ +-----+-----+-----+
+
+4.6. Path MTU Aging Timeout Option
+
+ This option specifies the timeout (in seconds) to use when aging Path
+ MTU values discovered by the mechanism defined in RFC 1191 [12]. The
+ timeout is specified as a 32-bit unsigned integer.
+
+ The code for this option is 24, and its length is 4.
+
+
+
+
+Alexander & Droms Standards Track [Page 12]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Timeout
+ +-----+-----+-----+-----+-----+-----+
+ | 24 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+4.7. Path MTU Plateau Table Option
+
+ This option specifies a table of MTU sizes to use when performing
+ Path MTU Discovery as defined in RFC 1191. The table is formatted as
+ a list of 16-bit unsigned integers, ordered from smallest to largest.
+ The minimum MTU value cannot be smaller than 68.
+
+ The code for this option is 25. Its minimum length is 2, and the
+ length MUST be a multiple of 2.
+
+ Code Len Size 1 Size 2
+ +-----+-----+-----+-----+-----+-----+---
+ | 25 | n | s1 | s2 | s1 | s2 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+5. IP Layer Parameters per Interface
+
+ This section details the options that affect the operation of the IP
+ layer on a per-interface basis. It is expected that a client can
+ issue multiple requests, one per interface, in order to configure
+ interfaces with their specific parameters.
+
+5.1. Interface MTU Option
+
+ This option specifies the MTU to use on this interface. The MTU is
+ specified as a 16-bit unsigned integer. The minimum legal value for
+ the MTU is 68.
+
+ The code for this option is 26, and its length is 2.
+
+ Code Len MTU
+ +-----+-----+-----+-----+
+ | 26 | 2 | m1 | m2 |
+ +-----+-----+-----+-----+
+
+5.2. All Subnets are Local Option
+
+ This option specifies whether or not the client may assume that all
+ subnets of the IP network to which the client is connected use the
+ same MTU as the subnet of that network to which the client is
+ directly connected. A value of 1 indicates that all subnets share
+ the same MTU. A value of 0 means that the client should assume that
+ some subnets of the directly connected network may have smaller MTUs.
+
+
+
+Alexander & Droms Standards Track [Page 13]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 27, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 27 | 1 | 0/1 |
+ +-----+-----+-----+
+
+5.3. Broadcast Address Option
+
+ This option specifies the broadcast address in use on the client's
+ subnet. Legal values for broadcast addresses are specified in
+ section 3.2.1.3 of [4].
+
+ The code for this option is 28, and its length is 4.
+
+ Code Len Broadcast Address
+ +-----+-----+-----+-----+-----+-----+
+ | 28 | 4 | b1 | b2 | b3 | b4 |
+ +-----+-----+-----+-----+-----+-----+
+
+5.4. Perform Mask Discovery Option
+
+ This option specifies whether or not the client should perform subnet
+ mask discovery using ICMP. A value of 0 indicates that the client
+ should not perform mask discovery. A value of 1 means that the
+ client should perform mask discovery.
+
+ The code for this option is 29, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 29 | 1 | 0/1 |
+ +-----+-----+-----+
+
+5.5. Mask Supplier Option
+
+ This option specifies whether or not the client should respond to
+ subnet mask requests using ICMP. A value of 0 indicates that the
+ client should not respond. A value of 1 means that the client should
+ respond.
+
+ The code for this option is 30, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 30 | 1 | 0/1 |
+ +-----+-----+-----+
+
+
+
+
+Alexander & Droms Standards Track [Page 14]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+5.6. Perform Router Discovery Option
+
+ This option specifies whether or not the client should solicit
+ routers using the Router Discovery mechanism defined in RFC 1256
+ [13]. A value of 0 indicates that the client should not perform
+ router discovery. A value of 1 means that the client should perform
+ router discovery.
+
+ The code for this option is 31, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 31 | 1 | 0/1 |
+ +-----+-----+-----+
+
+5.7. Router Solicitation Address Option
+
+ This option specifies the address to which the client should transmit
+ router solicitation requests.
+
+ The code for this option is 32, and its length is 4.
+
+ Code Len Address
+ +-----+-----+-----+-----+-----+-----+
+ | 32 | 4 | a1 | a2 | a3 | a4 |
+ +-----+-----+-----+-----+-----+-----+
+
+5.8. Static Route Option
+
+ This option specifies a list of static routes that the client should
+ install in its routing cache. If multiple routes to the same
+ destination are specified, they are listed in descending order of
+ priority.
+
+ The routes consist of a list of IP address pairs. The first address
+ is the destination address, and the second address is the router for
+ the destination.
+
+ The default route (0.0.0.0) is an illegal destination for a static
+ route. See section 3.5 for information about the router option.
+
+ The code for this option is 33. The minimum length of this option is
+ 8, and the length MUST be a multiple of 8.
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 15]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Destination 1 Router 1
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ Destination 2 Router 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+ | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+6. Link Layer Parameters per Interface
+
+ This section lists the options that affect the operation of the data
+ link layer on a per-interface basis.
+
+6.1. Trailer Encapsulation Option
+
+ This option specifies whether or not the client should negotiate the
+ use of trailers (RFC 893 [14]) when using the ARP protocol. A value
+ of 0 indicates that the client should not attempt to use trailers. A
+ value of 1 means that the client should attempt to use trailers.
+
+ The code for this option is 34, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 34 | 1 | 0/1 |
+ +-----+-----+-----+
+
+6.2. ARP Cache Timeout Option
+
+ This option specifies the timeout in seconds for ARP cache entries.
+ The time is specified as a 32-bit unsigned integer.
+
+ The code for this option is 35, and its length is 4.
+
+ Code Len Time
+ +-----+-----+-----+-----+-----+-----+
+ | 35 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+6.3. Ethernet Encapsulation Option
+
+ This option specifies whether or not the client should use Ethernet
+ Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation
+ if the interface is an Ethernet. A value of 0 indicates that the
+ client should use RFC 894 encapsulation. A value of 1 means that the
+ client should use RFC 1042 encapsulation.
+
+
+
+
+Alexander & Droms Standards Track [Page 16]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 36, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 36 | 1 | 0/1 |
+ +-----+-----+-----+
+
+7. TCP Parameters
+
+ This section lists the options that affect the operation of the TCP
+ layer on a per-interface basis.
+
+7.1. TCP Default TTL Option
+
+ This option specifies the default TTL that the client should use when
+ sending TCP segments. The value is represented as an 8-bit unsigned
+ integer. The minimum value is 1.
+
+ The code for this option is 37, and its length is 1.
+
+ Code Len TTL
+ +-----+-----+-----+
+ | 37 | 1 | n |
+ +-----+-----+-----+
+
+7.2. TCP Keepalive Interval Option
+
+ This option specifies the interval (in seconds) that the client TCP
+ should wait before sending a keepalive message on a TCP connection.
+ The time is specified as a 32-bit unsigned integer. A value of zero
+ indicates that the client should not generate keepalive messages on
+ connections unless specifically requested by an application.
+
+ The code for this option is 38, and its length is 4.
+
+ Code Len Time
+ +-----+-----+-----+-----+-----+-----+
+ | 38 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+7.3. TCP Keepalive Garbage Option
+
+ This option specifies the whether or not the client should send TCP
+ keepalive messages with a octet of garbage for compatibility with
+ older implementations. A value of 0 indicates that a garbage octet
+ should not be sent. A value of 1 indicates that a garbage octet
+ should be sent.
+
+
+
+
+Alexander & Droms Standards Track [Page 17]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 39, and its length is 1.
+
+ Code Len Value
+ +-----+-----+-----+
+ | 39 | 1 | 0/1 |
+ +-----+-----+-----+
+
+8. Application and Service Parameters
+
+ This section details some miscellaneous options used to configure
+ miscellaneous applications and services.
+
+8.1. Network Information Service Domain Option
+
+ This option specifies the name of the client's NIS [17] domain. The
+ domain is formatted as a character string consisting of characters
+ from the NVT ASCII character set.
+
+ The code for this option is 40. Its minimum length is 1.
+
+ Code Len NIS Domain Name
+ +-----+-----+-----+-----+-----+-----+---
+ | 40 | n | n1 | n2 | n3 | n4 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+8.2. Network Information Servers Option
+
+ This option specifies a list of IP addresses indicating NIS servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for this option is 41. Its minimum length is 4, and the
+ length MUST be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.3. Network Time Protocol Servers Option
+
+ This option specifies a list of IP addresses indicating NTP [18]
+ servers available to the client. Servers SHOULD be listed in order
+ of preference.
+
+ The code for this option is 42. Its minimum length is 4, and the
+ length MUST be a multiple of 4.
+
+
+
+
+Alexander & Droms Standards Track [Page 18]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.4. Vendor Specific Information
+
+ This option is used by clients and servers to exchange vendor-
+ specific information. The information is an opaque object of n
+ octets, presumably interpreted by vendor-specific code on the clients
+ and servers. The definition of this information is vendor specific.
+ The vendor is indicated in the vendor class identifier option.
+ Servers not equipped to interpret the vendor-specific information
+ sent by a client MUST ignore it (although it may be reported).
+ Clients which do not receive desired vendor-specific information
+ SHOULD make an attempt to operate without it, although they may do so
+ (and announce they are doing so) in a degraded mode.
+
+ If a vendor potentially encodes more than one item of information in
+ this option, then the vendor SHOULD encode the option using
+ "Encapsulated vendor-specific options" as described below:
+
+ The Encapsulated vendor-specific options field SHOULD be encoded as a
+ sequence of code/length/value fields of identical syntax to the DHCP
+ options field with the following exceptions:
+
+ 1) There SHOULD NOT be a "magic cookie" field in the encapsulated
+ vendor-specific extensions field.
+
+ 2) Codes other than 0 or 255 MAY be redefined by the vendor within
+ the encapsulated vendor-specific extensions field, but SHOULD
+ conform to the tag-length-value syntax defined in section 2.
+
+ 3) Code 255 (END), if present, signifies the end of the
+ encapsulated vendor extensions, not the end of the vendor
+ extensions field. If no code 255 is present, then the end of
+ the enclosing vendor-specific information field is taken as the
+ end of the encapsulated vendor-specific extensions field.
+
+ The code for this option is 43 and its minimum length is 1.
+
+ Code Len Vendor-specific information
+ +-----+-----+-----+-----+---
+ | 43 | n | i1 | i2 | ...
+ +-----+-----+-----+-----+---
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 19]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ When encapsulated vendor-specific extensions are used, the
+ information bytes 1-n have the following format:
+
+ Code Len Data item Code Len Data item Code
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+
+8.5. NetBIOS over TCP/IP Name Server Option
+
+ The NetBIOS name server (NBNS) option specifies a list of RFC
+ 1001/1002 [19] [20] NBNS name servers listed in order of preference.
+
+ The code for this option is 44. The minimum length of the option is
+ 4 octets, and the length must always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
+ | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
+
+8.6. NetBIOS over TCP/IP Datagram Distribution Server Option
+
+ The NetBIOS datagram distribution server (NBDD) option specifies a
+ list of RFC 1001/1002 NBDD servers listed in order of preference. The
+ code for this option is 45. The minimum length of the option is 4
+ octets, and the length must always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
+ | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
+
+8.7. NetBIOS over TCP/IP Node Type Option
+
+ The NetBIOS node type option allows NetBIOS over TCP/IP clients which
+ are configurable to be configured as described in RFC 1001/1002. The
+ value is specified as a single octet which identifies the client type
+ as follows:
+
+ Value Node Type
+ ----- ---------
+ 0x1 B-node
+ 0x2 P-node
+ 0x4 M-node
+ 0x8 H-node
+
+
+
+
+
+Alexander & Droms Standards Track [Page 20]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ In the above chart, the notation '0x' indicates a number in base-16
+ (hexadecimal).
+
+ The code for this option is 46. The length of this option is always
+ 1.
+
+ Code Len Node Type
+ +-----+-----+-----------+
+ | 46 | 1 | see above |
+ +-----+-----+-----------+
+
+8.8. NetBIOS over TCP/IP Scope Option
+
+ The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
+ parameter for the client as specified in RFC 1001/1002. See [19],
+ [20], and [8] for character-set restrictions.
+
+ The code for this option is 47. The minimum length of this option is
+ 1.
+
+ Code Len NetBIOS Scope
+ +-----+-----+-----+-----+-----+-----+----
+ | 47 | n | s1 | s2 | s3 | s4 | ...
+ +-----+-----+-----+-----+-----+-----+----
+
+8.9. X Window System Font Server Option
+
+ This option specifies a list of X Window System [21] Font servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for this option is 48. The minimum length of this option is
+ 4 octets, and the length MUST be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+ | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+8.10. X Window System Display Manager Option
+
+ This option specifies a list of IP addresses of systems that are
+ running the X Window System Display Manager and are available to the
+ client.
+
+ Addresses SHOULD be listed in order of preference.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 21]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for the this option is 49. The minimum length of this option
+ is 4, and the length MUST be a multiple of 4.
+
+ Code Len Address 1 Address 2
+
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+ | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+---
+
+8.11. Network Information Service+ Domain Option
+
+ This option specifies the name of the client's NIS+ [17] domain. The
+ domain is formatted as a character string consisting of characters
+ from the NVT ASCII character set.
+
+ The code for this option is 64. Its minimum length is 1.
+
+ Code Len NIS Client Domain Name
+ +-----+-----+-----+-----+-----+-----+---
+ | 64 | n | n1 | n2 | n3 | n4 | ...
+ +-----+-----+-----+-----+-----+-----+---
+
+8.12. Network Information Service+ Servers Option
+
+ This option specifies a list of IP addresses indicating NIS+ servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+ The code for this option is 65. Its minimum length is 4, and the
+ length MUST be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.13. Mobile IP Home Agent option
+
+ This option specifies a list of IP addresses indicating mobile IP
+ home agents available to the client. Agents SHOULD be listed in
+ order of preference.
+
+ The code for this option is 68. Its minimum length is 0 (indicating
+ no home agents are available) and the length MUST be a multiple of 4.
+ It is expected that the usual length will be four octets, containing
+ a single home agent's address.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 22]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Home Agent Addresses (zero or more)
+ +-----+-----+-----+-----+-----+-----+--
+ | 68 | n | a1 | a2 | a3 | a4 | ...
+ +-----+-----+-----+-----+-----+-----+--
+
+8.14. Simple Mail Transport Protocol (SMTP) Server Option
+
+ The SMTP server option specifies a list of SMTP servers available to
+ the client. Servers SHOULD be listed in order of preference.
+
+ The code for the SMTP server option is 69. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.15. Post Office Protocol (POP3) Server Option
+
+ The POP3 server option specifies a list of POP3 available to the
+ client. Servers SHOULD be listed in order of preference.
+
+ The code for the POP3 server option is 70. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.16. Network News Transport Protocol (NNTP) Server Option
+
+ The NNTP server option specifies a list of NNTP available to the
+ client. Servers SHOULD be listed in order of preference.
+
+ The code for the NNTP server option is 71. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+
+
+
+
+Alexander & Droms Standards Track [Page 23]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+8.17. Default World Wide Web (WWW) Server Option
+
+ The WWW server option specifies a list of WWW available to the
+ client. Servers SHOULD be listed in order of preference.
+
+ The code for the WWW server option is 72. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.18. Default Finger Server Option
+
+ The Finger server option specifies a list of Finger available to the
+ client. Servers SHOULD be listed in order of preference.
+
+ The code for the Finger server option is 73. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.19. Default Internet Relay Chat (IRC) Server Option
+
+ The IRC server option specifies a list of IRC available to the
+ client. Servers SHOULD be listed in order of preference.
+
+ The code for the IRC server option is 74. The minimum length for
+ this option is 4 octets, and the length MUST always be a multiple of
+ 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.20. StreetTalk Server Option
+
+ The StreetTalk server option specifies a list of StreetTalk servers
+ available to the client. Servers SHOULD be listed in order of
+ preference.
+
+
+
+
+Alexander & Droms Standards Track [Page 24]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for the StreetTalk server option is 75. The minimum length
+ for this option is 4 octets, and the length MUST always be a multiple
+ of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+8.21. StreetTalk Directory Assistance (STDA) Server Option
+
+ The StreetTalk Directory Assistance (STDA) server option specifies a
+ list of STDA servers available to the client. Servers SHOULD be
+ listed in order of preference.
+
+ The code for the StreetTalk Directory Assistance server option is 76.
+ The minimum length for this option is 4 octets, and the length MUST
+ always be a multiple of 4.
+
+ Code Len Address 1 Address 2
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+ | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+ +-----+-----+-----+-----+-----+-----+-----+-----+--
+
+9. DHCP Extensions
+
+ This section details the options that are specific to DHCP.
+
+9.1. Requested IP Address
+
+ This option is used in a client request (DHCPDISCOVER) to allow the
+ client to request that a particular IP address be assigned.
+
+ The code for this option is 50, and its length is 4.
+
+ Code Len Address
+ +-----+-----+-----+-----+-----+-----+
+ | 50 | 4 | a1 | a2 | a3 | a4 |
+ +-----+-----+-----+-----+-----+-----+
+
+9.2. IP Address Lease Time
+
+ This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
+ to allow the client to request a lease time for the IP address. In a
+ server reply (DHCPOFFER), a DHCP server uses this option to specify
+ the lease time it is willing to offer.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 25]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The time is in units of seconds, and is specified as a 32-bit
+ unsigned integer.
+
+ The code for this option is 51, and its length is 4.
+
+ Code Len Lease Time
+ +-----+-----+-----+-----+-----+-----+
+ | 51 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+9.3. Option Overload
+
+ This option is used to indicate that the DHCP 'sname' or 'file'
+ fields are being overloaded by using them to carry DHCP options. A
+ DHCP server inserts this option if the returned parameters will
+ exceed the usual space allotted for options.
+
+ If this option is present, the client interprets the specified
+ additional fields after it concludes interpretation of the standard
+ option fields.
+
+ The code for this option is 52, and its length is 1. Legal values
+ for this option are:
+
+ Value Meaning
+ ----- --------
+ 1 the 'file' field is used to hold options
+ 2 the 'sname' field is used to hold options
+ 3 both fields are used to hold options
+
+ Code Len Value
+ +-----+-----+-----+
+ | 52 | 1 |1/2/3|
+ +-----+-----+-----+
+
+9.4 TFTP server name
+
+ This option is used to identify a TFTP server when the 'sname' field
+ in the DHCP header has been used for DHCP options.
+
+ The code for this option is 66, and its minimum length is 1.
+
+ Code Len TFTP server
+ +-----+-----+-----+-----+-----+---
+ | 66 | n | c1 | c2 | c3 | ...
+ +-----+-----+-----+-----+-----+---
+
+
+
+
+
+Alexander & Droms Standards Track [Page 26]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+9.5 Bootfile name
+
+ This option is used to identify a bootfile when the 'file' field in
+ the DHCP header has been used for DHCP options.
+
+ The code for this option is 67, and its minimum length is 1.
+
+ Code Len Bootfile name
+ +-----+-----+-----+-----+-----+---
+ | 67 | n | c1 | c2 | c3 | ...
+ +-----+-----+-----+-----+-----+---
+
+9.6. DHCP Message Type
+
+ This option is used to convey the type of the DHCP message. The code
+ for this option is 53, and its length is 1. Legal values for this
+ option are:
+
+ Value Message Type
+ ----- ------------
+ 1 DHCPDISCOVER
+ 2 DHCPOFFER
+ 3 DHCPREQUEST
+ 4 DHCPDECLINE
+ 5 DHCPACK
+ 6 DHCPNAK
+ 7 DHCPRELEASE
+ 8 DHCPINFORM
+
+ Code Len Type
+ +-----+-----+-----+
+ | 53 | 1 | 1-9 |
+ +-----+-----+-----+
+
+9.7. Server Identifier
+
+ This option is used in DHCPOFFER and DHCPREQUEST messages, and may
+ optionally be included in the DHCPACK and DHCPNAK messages. DHCP
+ servers include this option in the DHCPOFFER in order to allow the
+ client to distinguish between lease offers. DHCP clients use the
+ contents of the 'server identifier' field as the destination address
+ for any DHCP messages unicast to the DHCP server. DHCP clients also
+ indicate which of several lease offers is being accepted by including
+ this option in a DHCPREQUEST message.
+
+ The identifier is the IP address of the selected server.
+
+ The code for this option is 54, and its length is 4.
+
+
+
+Alexander & Droms Standards Track [Page 27]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ Code Len Address
+ +-----+-----+-----+-----+-----+-----+
+ | 54 | 4 | a1 | a2 | a3 | a4 |
+ +-----+-----+-----+-----+-----+-----+
+
+9.8. Parameter Request List
+
+ This option is used by a DHCP client to request values for specified
+ configuration parameters. The list of requested parameters is
+ specified as n octets, where each octet is a valid DHCP option code
+ as defined in this document.
+
+ The client MAY list the options in order of preference. The DHCP
+ server is not required to return the options in the requested order,
+ but MUST try to insert the requested options in the order requested
+ by the client.
+
+ The code for this option is 55. Its minimum length is 1.
+
+ Code Len Option Codes
+ +-----+-----+-----+-----+---
+ | 55 | n | c1 | c2 | ...
+ +-----+-----+-----+-----+---
+
+9.9. Message
+
+ This option is used by a DHCP server to provide an error message to a
+ DHCP client in a DHCPNAK message in the event of a failure. A client
+ may use this option in a DHCPDECLINE message to indicate the why the
+ client declined the offered parameters. The message consists of n
+ octets of NVT ASCII text, which the client may display on an
+ available output device.
+
+ The code for this option is 56 and its minimum length is 1.
+
+ Code Len Text
+ +-----+-----+-----+-----+---
+ | 56 | n | c1 | c2 | ...
+ +-----+-----+-----+-----+---
+
+9.10. Maximum DHCP Message Size
+
+ This option specifies the maximum length DHCP message that it is
+ willing to accept. The length is specified as an unsigned 16-bit
+ integer. A client may use the maximum DHCP message size option in
+ DHCPDISCOVER or DHCPREQUEST messages, but should not use the option
+ in DHCPDECLINE messages.
+
+
+
+
+Alexander & Droms Standards Track [Page 28]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The code for this option is 57, and its length is 2. The minimum
+ legal value is 576 octets.
+
+ Code Len Length
+ +-----+-----+-----+-----+
+ | 57 | 2 | l1 | l2 |
+ +-----+-----+-----+-----+
+
+9.11. Renewal (T1) Time Value
+
+ This option specifies the time interval from address assignment until
+ the client transitions to the RENEWING state.
+
+ The value is in units of seconds, and is specified as a 32-bit
+ unsigned integer.
+
+ The code for this option is 58, and its length is 4.
+
+ Code Len T1 Interval
+ +-----+-----+-----+-----+-----+-----+
+ | 58 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+9.12. Rebinding (T2) Time Value
+
+ This option specifies the time interval from address assignment until
+ the client transitions to the REBINDING state.
+
+ The value is in units of seconds, and is specified as a 32-bit
+ unsigned integer.
+
+ The code for this option is 59, and its length is 4.
+
+ Code Len T2 Interval
+ +-----+-----+-----+-----+-----+-----+
+ | 59 | 4 | t1 | t2 | t3 | t4 |
+ +-----+-----+-----+-----+-----+-----+
+
+9.13. Vendor class identifier
+
+ This option is used by DHCP clients to optionally identify the vendor
+ type and configuration of a DHCP client. The information is a string
+ of n octets, interpreted by servers. Vendors may choose to define
+ specific vendor class identifiers to convey particular configuration
+ or other identification information about a client. For example, the
+ identifier may encode the client's hardware configuration. Servers
+ not equipped to interpret the class-specific information sent by a
+ client MUST ignore it (although it may be reported). Servers that
+
+
+
+Alexander & Droms Standards Track [Page 29]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ respond SHOULD only use option 43 to return the vendor-specific
+ information to the client.
+
+ The code for this option is 60, and its minimum length is 1.
+
+ Code Len Vendor class Identifier
+ +-----+-----+-----+-----+---
+ | 60 | n | i1 | i2 | ...
+ +-----+-----+-----+-----+---
+
+9.14. Client-identifier
+
+ This option is used by DHCP clients to specify their unique
+ identifier. DHCP servers use this value to index their database of
+ address bindings. This value is expected to be unique for all
+ clients in an administrative domain.
+
+ Identifiers SHOULD be treated as opaque objects by DHCP servers.
+
+ The client identifier MAY consist of type-value pairs similar to the
+ 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
+ of a hardware type and hardware address. In this case the type field
+ SHOULD be one of the ARP hardware types defined in STD2 [22]. A
+ hardware type of 0 (zero) should be used when the value field
+ contains an identifier other than a hardware address (e.g. a fully
+ qualified domain name).
+
+ For correct identification of clients, each client's client-
+ identifier MUST be unique among the client-identifiers used on the
+ subnet to which the client is attached. Vendors and system
+ administrators are responsible for choosing client-identifiers that
+ meet this requirement for uniqueness.
+
+ The code for this option is 61, and its minimum length is 2.
+
+ Code Len Type Client-Identifier
+ +-----+-----+-----+-----+-----+---
+ | 61 | n | t1 | i1 | i2 | ...
+ +-----+-----+-----+-----+-----+---
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 30]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+10. Defining new extensions
+
+ The author of a new DHCP option will follow these steps to obtain
+ acceptance of the option as a part of the DHCP Internet Standard:
+
+ 1. The author devises the new option.
+ 2. The author requests a number for the new option from IANA by
+ contacting:
+ Internet Assigned Numbers Authority (IANA)
+ USC/Information Sciences Institute
+ 4676 Admiralty Way
+ Marina del Rey, California 90292-6695
+
+ or by email as: iana@iana.org
+
+ 3. The author documents the new option, using the newly obtained
+ option number, as an Internet Draft.
+ 4. The author submits the Internet Draft for review through the IETF
+ standards process as defined in "Internet Official Protocol
+ Standards" (STD 1). The new option will be submitted for eventual
+ acceptance as an Internet Standard.
+ 5. The new option progresses through the IETF standards process; the
+ new option will be reviewed by the Dynamic Host Configuration
+ Working Group (if that group still exists), or as an Internet
+ Draft not submitted by an IETF working group.
+ 6. If the new option fails to gain acceptance as an Internet
+ Standard, the assigned option number will be returned to IANA for
+ reassignment.
+
+ This procedure for defining new extensions will ensure that:
+
+ * allocation of new option numbers is coordinated from a single
+ authority,
+ * new options are reviewed for technical correctness and
+ appropriateness, and
+ * documentation for new options is complete and published.
+
+11. Acknowledgements
+
+ The author thanks the many (and too numerous to mention!) members of
+ the DHC WG for their tireless and ongoing efforts in the development
+ of DHCP and this document.
+
+ The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
+ Mendonca in organizing DHCP interoperability testing sessions are
+ gratefully acknowledged.
+
+
+
+
+
+Alexander & Droms Standards Track [Page 31]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ The development of this document was supported in part by grants from
+ the Corporation for National Research Initiatives (CNRI), Bucknell
+ University and Sun Microsystems.
+
+12. References
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ Bucknell University, March 1997.
+
+ [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
+ USC/Information Sciences Institute, August 1993.
+
+ [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
+ Stanford University and Sun Microsystems, September 1985.
+
+ [4] Braden, R., Editor, "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, USC/Information Sciences
+ Institute, October 1989.
+
+ [5] Mogul, J., and J. Postel, "Internet Standard Subnetting
+ Procedure", STD 5, RFC 950, USC/Information Sciences Institute,
+ August 1985.
+
+ [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC
+ 868, USC/Information Sciences Institute, SRI, May 1983.
+
+ [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences
+ Institute, August 1979.
+
+ [8] Mockapetris, P., "Domain Names - Implementation and
+ Specification", STD 13, RFC 1035, USC/Information Sciences
+ Institute, November 1987.
+
+ [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
+ USC/Information Sciences Institute, May 1983.
+
+ [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
+ Wollongong Group, August 1990.
+
+ [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
+ December 1983.
+
+ [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+ DECWRL, Stanford University, November 1990.
+
+ [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
+ Xerox PARC, September 1991.
+
+
+
+
+Alexander & Droms Standards Track [Page 32]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+ [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893,
+ U. C. Berkeley, April 1984.
+
+ [15] Hornig, C., "Standard for the Transmission of IP Datagrams over
+ Ethernet Networks", RFC 894, Symbolics, April 1984.
+
+ [16] Postel, J. and J. Reynolds, "Standard for the Transmission of
+ IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information
+ Sciences Institute, February 1988.
+
+ [17] Sun Microsystems, "System and Network Administration", March
+ 1990.
+
+ [18] Mills, D., "Internet Time Synchronization: The Network Time
+ Protocol", RFC 1305, UDEL, March 1992.
+
+ [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
+ on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001,
+ March 1987.
+
+ [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
+ on a TCP/UDP transport: Detailed Specifications", STD 19, RFC
+ 1002, March 1987.
+
+ [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198,
+ MIT Laboratory for Computer Science, January 1991.
+
+ [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+ USC/Information Sciences Institute, July 1992.
+
+13. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 33]
+
+RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
+
+
+14. Authors' Addresses
+
+ Steve Alexander
+ Silicon Graphics, Inc.
+ 2011 N. Shoreline Boulevard
+ Mailstop 510
+ Mountain View, CA 94043-1389
+
+ Phone: (415) 933-6172
+ EMail: sca@engr.sgi.com
+
+
+ Ralph Droms
+ Bucknell University
+ Lewisburg, PA 17837
+
+ Phone: (717) 524-1145
+ EMail: droms@bucknell.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Alexander & Droms Standards Track [Page 34]
+
diff --git a/contrib/isc-dhcp/doc/rfc951.txt b/contrib/isc-dhcp/doc/rfc951.txt
new file mode 100644
index 000000000000..86cd69e63c54
--- /dev/null
+++ b/contrib/isc-dhcp/doc/rfc951.txt
@@ -0,0 +1,684 @@
+
+
+Network Working Group Bill Croft (Stanford University)
+Request for Comments: 951 John Gilmore (Sun Microsystems)
+ September 1985
+
+ BOOTSTRAP PROTOCOL (BOOTP)
+
+
+1. Status of this Memo
+
+ This RFC suggests a proposed protocol for the ARPA-Internet
+ community, and requests discussion and suggestions for improvements.
+ Distribution of this memo is unlimited.
+
+2. Overview
+
+ This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
+ a diskless client machine to discover its own IP address, the address
+ of a server host, and the name of a file to be loaded into memory and
+ executed. The bootstrap operation can be thought of as consisting of
+ TWO PHASES. This RFC describes the first phase, which could be
+ labeled 'address determination and bootfile selection'. After this
+ address and filename information is obtained, control passes to the
+ second phase of the bootstrap where a file transfer occurs. The file
+ transfer will typically use the TFTP protocol [9], since it is
+ intended that both phases reside in PROM on the client. However
+ BOOTP could also work with other protocols such as SFTP [3] or
+ FTP [6].
+
+ We suggest that the client's PROM software provide a way to do a
+ complete bootstrap without 'user' interaction. This is the type of
+ boot that would occur during an unattended power-up. A mechanism
+ should be provided for the user to manually supply the necessary
+ address and filename information to bypass the BOOTP protocol and
+ enter the file transfer phase directly. If non-volatile storage is
+ available, we suggest keeping default settings there and bypassing
+ the BOOTP protocol unless these settings cause the file transfer
+ phase to fail. If the cached information fails, the bootstrap should
+ fall back to phase 1 and use BOOTP.
+
+ Here is a brief outline of the protocol:
+
+ 1. A single packet exchange is performed. Timeouts are used to
+ retransmit until a reply is received. The same packet field
+ layout is used in both directions. Fixed length fields of maximum
+ reasonable length are used to simplify structure definition and
+ parsing.
+
+ 2. An 'opcode' field exists with two values. The client
+ broadcasts a 'bootrequest' packet. The server then answers with a
+ 'bootreply' packet. The bootrequest contains the client's
+ hardware address and its IP address, if known.
+
+
+Croft & Gilmore [Page 1]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 3. The request can optionally contain the name of the server the
+ client wishes to respond. This is so the client can force the
+ boot to occur from a specific host (e.g. if multiple versions of
+ the same bootfile exist or if the server is in a far distant
+ net/domain). The client does not have to deal with name / domain
+ services; instead this function is pushed off to the BOOTP server.
+
+ 4. The request can optionally contain the 'generic' filename to be
+ booted. For example 'unix' or 'ethertip'. When the server sends
+ the bootreply, it replaces this field with the fully qualified
+ path name of the appropriate boot file. In determining this name,
+ the server may consult his own database correlating the client's
+ address and filename request, with a particular boot file
+ customized for that client. If the bootrequest filename is a null
+ string, then the server returns a filename field indicating the
+ 'default' file to be loaded for that client.
+
+ 5. In the case of clients who do not know their IP addresses, the
+ server must also have a database relating hardware address to IP
+ address. This client IP address is then placed into a field in
+ the bootreply.
+
+ 6. Certain network topologies (such as Stanford's) may be such
+ that a given physical cable does not have a TFTP server directly
+ attached to it (e.g. all the gateways and hosts on a certain cable
+ may be diskless). With the cooperation of neighboring gateways,
+ BOOTP can allow clients to boot off of servers several hops away,
+ through these gateways. See the section 'Booting Through
+ Gateways' below. This part of the protocol requires no special
+ action on the part of the client. Implementation is optional and
+ requires a small amount of additional code in gateways and
+ servers.
+
+3. Packet Format
+
+ All numbers shown are decimal, unless indicated otherwise. The BOOTP
+ packet is enclosed in a standard IP [8] UDP [7] datagram. For
+ simplicity it is assumed that the BOOTP packet is never fragmented.
+ Any numeric fields shown are packed in 'standard network byte order',
+ i.e. high order bits are sent first.
+
+ In the IP header of a bootrequest, the client fills in its own IP
+ source address if known, otherwise zero. When the server address is
+ unknown, the IP destination address will be the 'broadcast address'
+ 255.255.255.255. This address means 'broadcast on the local cable,
+ (I don't know my net number)' [4].
+
+
+
+Croft & Gilmore [Page 2]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ The UDP header contains source and destination port numbers. The
+ BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
+ and 'BOOTP server' (67). The client sends requests using 'BOOTP
+ server' as the destination port; this is usually a broadcast. The
+ server sends replies using 'BOOTP client' as the destination port;
+ depending on the kernel or driver facilities in the server, this may
+ or may not be a broadcast (this is explained further in the section
+ titled 'Chicken/Egg issues' below). The reason TWO reserved ports
+ are used, is to avoid 'waking up' and scheduling the BOOTP server
+ daemons, when a bootreply must be broadcast to a client. Since the
+ server and other hosts won't be listening on the 'BOOTP client' port,
+ any such incoming broadcasts will be filtered out at the kernel
+ level. We could not simply allow the client to pick a 'random' port
+ number for the UDP source port field; since the server reply may be
+ broadcast, a randomly chosen port number could confuse other hosts
+ that happened to be listening on that port.
+
+ The UDP length field is set to the length of the UDP plus BOOTP
+ portions of the packet. The UDP checksum field can be set to zero by
+ the client (or server) if desired, to avoid this extra overhead in a
+ PROM implementation. In the 'Packet Processing' section below the
+ phrase '[UDP checksum.]' is used whenever the checksum might be
+ verified/computed.
+
+ FIELD BYTES DESCRIPTION
+ ----- ----- -----------
+
+ op 1 packet op code / message type.
+ 1 = BOOTREQUEST, 2 = BOOTREPLY
+
+ htype 1 hardware address type,
+ see ARP section in "Assigned Numbers" RFC.
+ '1' = 10mb ethernet
+
+ hlen 1 hardware address length
+ (eg '6' for 10mb ethernet).
+
+ hops 1 client sets to zero,
+ optionally used by gateways
+ in cross-gateway booting.
+
+ xid 4 transaction ID, a random number,
+ used to match this boot request with the
+ responses it generates.
+
+ secs 2 filled in by client, seconds elapsed since
+ client started trying to boot.
+
+
+Croft & Gilmore [Page 3]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ -- 2 unused
+
+ ciaddr 4 client IP address;
+ filled in by client in bootrequest if known.
+
+ yiaddr 4 'your' (client) IP address;
+ filled by server if client doesn't
+ know its own address (ciaddr was 0).
+
+ siaddr 4 server IP address;
+ returned in bootreply by server.
+
+ giaddr 4 gateway IP address,
+ used in optional cross-gateway booting.
+
+ chaddr 16 client hardware address,
+ filled in by client.
+
+ sname 64 optional server host name,
+ null terminated string.
+
+ file 128 boot file name, null terminated string;
+ 'generic' name or null in bootrequest,
+ fully qualified directory-path
+ name in bootreply.
+
+ vend 64 optional vendor-specific area,
+ e.g. could be hardware type/serial on request,
+ or 'capability' / remote file system handle
+ on reply. This info may be set aside for use
+ by a third phase bootstrap or kernel.
+
+4. Chicken / Egg Issues
+
+ How can the server send an IP datagram to the client, if the client
+ doesnt know its own IP address (yet)? Whenever a bootreply is being
+ sent, the transmitting machine performs the following operations:
+
+ 1. If the client knows its own IP address ('ciaddr' field is
+ nonzero), then the IP can be sent 'as normal', since the client
+ will respond to ARPs [5].
+
+ 2. If the client does not yet know its IP address (ciaddr zero),
+ then the client cannot respond to ARPs sent by the transmitter of
+ the bootreply. There are two options:
+
+ a. If the transmitter has the necessary kernel or driver hooks
+
+
+Croft & Gilmore [Page 4]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ to 'manually' construct an ARP address cache entry, then it can
+ fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
+ course, this entry should have a timeout on it, just like any
+ other entry made by the normal ARP code itself. The
+ transmitter of the bootreply can then simply send the bootreply
+ to the client's IP address. UNIX (4.2 BSD) has this
+ capability.
+
+ b. If the transmitter lacks these kernel hooks, it can simply
+ send the bootreply to the IP broadcast address on the
+ appropriate interface. This is only one additional broadcast
+ over the previous case.
+
+5. Client Use of ARP
+
+ The client PROM must contain a simple implementation of ARP, e.g. the
+ address cache could be just one entry in size. This will allow a
+ second-phase-only boot (TFTP) to be performed when the client knows
+ the IP addresses and bootfile name.
+
+ Any time the client is expecting to receive a TFTP or BOOTP reply, it
+ should be prepared to answer an ARP request for its own IP to
+ hardware address mapping (if known).
+
+ Since the bootreply will contain (in the hardware encapsulation) the
+ hardware source address of the server/gateway, the client MAY be able
+ to avoid sending an ARP request for the server/gateway IP address to
+ be used in the following TFTP phase. However this should be treated
+ only as a special case, since it is desirable to still allow a
+ second-phase-only boot as described above.
+
+6. Comparison to RARP
+
+ An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
+ was proposed to allow a client to determine its IP address, given
+ that it knew its hardware address. However RARP had the disadvantage
+ that it was a hardware link level protocol (not IP/UDP based). This
+ means that RARP could only be implemented on hosts containing special
+ kernel or driver modifications to access these 'raw' packets. Since
+ there are many network kernels existent now, with each source
+ maintained by different organizations, a boot protocol that does not
+ require kernel modifications is a decided advantage.
+
+ BOOTP provides this hardware to IP address lookup function, in
+ addition to the other useful features described in the sections
+ above.
+
+
+
+Croft & Gilmore [Page 5]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+7. Packet Processing
+
+ 7.1. Client Transmission
+
+ Before setting up the packet for the first time, it is a good idea
+ to clear the entire packet buffer to all zeros; this will place
+ all fields in their default state. The client then creates a
+ packet with the following fields.
+
+ The IP destination address is set to 255.255.255.255. (the
+ broadcast address) or to the server's IP address (if known). The
+ IP source address and 'ciaddr' are set to the client's IP address
+ if known, else 0. The UDP header is set with the proper length;
+ source port = 'BOOTP client' port destination port = 'BOOTP
+ server' port.
+
+ 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware
+ address type as assigned in the ARP section of the "Assigned
+ Numbers" RFC. 'hlen' is set to the length of the hardware address,
+ e.g. '6' for 10mb ethernet.
+
+ 'xid' is set to a 'random' transaction id. 'secs' is set to the
+ number of seconds that have elapsed since the client has started
+ booting. This will let the servers know how long a client has
+ been trying. As the number gets larger, certain servers may feel
+ more 'sympathetic' towards a client they don't normally service.
+ If a client lacks a suitable clock, it could construct a rough
+ estimate using a loop timer. Or it could choose to simply send
+ this field as always a fixed value, say 100 seconds.
+
+ If the client knows its IP address, 'ciaddr' (and the IP source
+ address) are set to this value. 'chaddr' is filled in with the
+ client's hardware address.
+
+ If the client wishes to restrict booting to a particular server
+ name, it may place a null-terminated string in 'sname'. The name
+ used should be any of the allowable names or nicknames of the
+ desired host.
+
+ The client has several options for filling the 'file' name field.
+ If left null, the meaning is 'I want to boot the default file for
+ my machine'. A null file name can also mean 'I am only interested
+ in finding out client/server/gateway IP addresses, I dont care
+ about file names'.
+
+ The field can also be a 'generic' name such as 'unix' or
+
+
+
+Croft & Gilmore [Page 6]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 'gateway'; this means 'boot the named program configured for my
+ machine'. Finally the field can be a fully directory qualified
+ path name.
+
+ The 'vend' field can be filled in by the client with
+ vendor-specific strings or structures. For example the machine
+ hardware type or serial number may be placed here. However the
+ operation of the BOOTP server should not DEPEND on this
+ information existing.
+
+ If the 'vend' field is used, it is recommended that a 4 byte
+ 'magic number' be the first item within 'vend'. This lets a
+ server determine what kind of information it is seeing in this
+ field. Numbers can be assigned by the usual 'magic number'
+ process --you pick one and it's magic. A different magic number
+ could be used for bootreply's than bootrequest's to allow the
+ client to take special action with the reply information.
+
+ [UDP checksum.]
+
+ 7.2. Client Retransmission Strategy
+
+ If no reply is received for a certain length of time, the client
+ should retransmit the request. The time interval must be chosen
+ carefully so as not to flood the network. Consider the case of a
+ cable containing 100 machines that are just coming up after a
+ power failure. Simply retransmitting the request every four
+ seconds will inundate the net.
+
+ As a possible strategy, you might consider backing off
+ exponentially, similar to the way ethernet backs off on a
+ collision. So for example if the first packet is at time 0:00,
+ the second would be at :04, then :08, then :16, then :32, then
+ :64. You should also randomize each time; this would be done
+ similar to the ethernet specification by starting with a mask and
+ 'and'ing that with with a random number to get the first backoff.
+ On each succeeding backoff, the mask is increased in length by one
+ bit. This doubles the average delay on each backoff.
+
+ After the 'average' backoff reaches about 60 seconds, it should be
+ increased no further, but still randomized.
+
+ Before each retransmission, the client should update the 'secs'
+ field. [UDP checksum.]
+
+
+
+
+
+Croft & Gilmore [Page 7]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ 7.3. Server Receives BOOTREQUEST
+
+ [UDP checksum.] If the UDP destination port does not match the
+ 'BOOTP server' port, discard the packet.
+
+ If the server name field (sname) is null (no particular server
+ specified), or sname is specified and matches our name or
+ nickname, then continue with packet processing.
+
+ If the sname field is specified, but does not match 'us', then
+ there are several options:
+
+ 1. You may choose to simply discard this packet.
+
+ 2. If a name lookup on sname shows it to be on this same cable,
+ discard the packet.
+
+ 3. If sname is on a different net, you may choose to forward
+ the packet to that address. If so, check the 'giaddr' (gateway
+ address) field. If 'giaddr' is zero, fill it in with my
+ address or the address of a gateway that can be used to get to
+ that net. Then forward the packet.
+
+ If the client IP address (ciaddr) is zero, then the client does
+ not know its own IP address. Attempt to lookup the client
+ hardware address (chaddr, hlen, htype) in our database. If no
+ match is found, discard the packet. Otherwise we now have an IP
+ address for this client; fill it into the 'yiaddr' (your IP
+ address) field.
+
+ We now check the boot file name field (file). The field will be
+ null if the client is not interested in filenames, or wants the
+ default bootfile. If the field is non-null, it is used as a
+ lookup key in a database, along with the client's IP address. If
+ there is a default file or generic file (possibly indexed by the
+ client address) or a fully-specified path name that matches, then
+ replace the 'file' field with the fully-specified path name of the
+ selected boot file. If the field is non-null and no match was
+ found, then the client is asking for a file we dont have; discard
+ the packet, perhaps some other BOOTP server will have it.
+
+ The 'vend' vendor-specific data field should now be checked and if
+ a recognized type of data is provided, client-specific actions
+ should be taken, and a response placed in the 'vend' data field of
+ the reply packet. For example, a workstation client could provide
+
+
+
+
+Croft & Gilmore [Page 8]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ an authentication key and receive from the server a capability for
+ remote file access, or a set of configuration options, which can
+ be passed to the operating system that will shortly be booted in.
+
+ Place my (server) IP address in the 'siaddr' field. Set the 'op'
+ field to BOOTREPLY. The UDP destination port is set to 'BOOTP
+ client'. If the client address 'ciaddr' is nonzero, send the
+ packet there; else if the gateway address 'giaddr' is nonzero, set
+ the UDP destination port to 'BOOTP server' and send the packet to
+ 'giaddr'; else the client is on one of our cables but it doesnt
+ know its own IP address yet --use a method described in the 'Egg'
+ section above to send it to the client. If 'Egg' is used and we
+ have multiple interfaces on this host, use the 'yiaddr' (your IP
+ address) field to figure out which net (cable/interface) to send
+ the packet to. [UDP checksum.]
+
+ 7.4. Server/Gateway Receives BOOTREPLY
+
+ [UDP checksum.] If 'yiaddr' (your [the client's] IP address)
+ refers to one of our cables, use one of the 'Egg' methods above to
+ forward it to the client. Be sure to send it to the 'BOOTP
+ client' UDP destination port.
+
+ 7.5. Client Reception
+
+ Don't forget to process ARP requests for my own IP address (if I
+ know it). [UDP checksum.] The client should discard incoming
+ packets that: are not IP/UDPs addressed to the boot port; are not
+ BOOTREPLYs; do not match my IP address (if I know it) or my
+ hardware address; do not match my transaction id. Otherwise we
+ have received a successful reply. 'yiaddr' will contain my IP
+ address, if I didnt know it before. 'file' is the name of the
+ file name to TFTP 'read request'. The server address is in
+ 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the
+ packets should be forwarded there first, in order to get to the
+ server.
+
+8. Booting Through Gateways
+
+ This part of the protocol is optional and requires some additional
+ code in cooperating gateways and servers, but it allows cross-gateway
+ booting. This is mainly useful when gateways are diskless machines.
+ Gateways containing disks (e.g. a UNIX machine acting as a gateway),
+ might as well run their own BOOTP/TFTP servers.
+
+ Gateways listening to broadcast BOOTREQUESTs may decide to forward or
+ rebroadcast these requests 'when appropriate'. For example, the
+
+
+Croft & Gilmore [Page 9]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ gateway could have, as part of his configuration tables, a list of
+ other networks or hosts to receive a copy of any broadcast
+ BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea
+ to simply globally rebroadcast the requests, since broadcast loops
+ will almost certainly occur.
+
+ The forwarding could begin immediately, or wait until the 'secs'
+ (seconds client has been trying) field passes a certain threshold.
+
+ If a gateway does decide to forward the request, it should look at
+ the 'giaddr' (gateway IP address) field. If zero, it should plug its
+ own IP address (on the receiving cable) into this field. It may also
+ use the 'hops' field to optionally control how far the packet is
+ reforwarded. Hops should be incremented on each forwarding. For
+ example, if hops passes '3', the packet should probably be discarded.
+ [UDP checksum.]
+
+ Here we have recommended placing this special forwarding function in
+ the gateways. But that does not have to be the case. As long as
+ some 'BOOTP forwarding agent' exists on the net with the booting
+ client, the agent can do the forwarding when appropriate. Thus this
+ service may or may not be co-located with the gateway.
+
+ In the case of a forwarding agent not located in the gateway, the
+ agent could save himself some work by plugging the broadcast address
+ of the interface receiving the bootrequest into the 'giaddr' field.
+ Thus the reply would get forwarded using normal gateways, not
+ involving the forwarding agent. Of course the disadvantage here is
+ that you lose the ability to use the 'Egg' non-broadcast method of
+ sending the reply, causing extra overhead for every host on the
+ client cable.
+
+9. Sample BOOTP Server Database
+
+ As a suggestion, we show a sample text file database that the BOOTP
+ server program might use. The database has two sections, delimited
+ by a line containing an percent in column 1. The first section
+ contains a 'default directory' and mappings from generic names to
+ directory/pathnames. The first generic name in this section is the
+ 'default file' you get when the bootrequest contains a null 'file'
+ string.
+
+ The second section maps hardware addresstype/address into an
+ ipaddress. Optionally you can also overide the default generic name
+ by supplying a ipaddress specific genericname. A 'suffix' item is
+ also an option; if supplied, any generic names specified by the
+ client will be accessed by first appending 'suffix' to the 'pathname'
+
+
+Croft & Gilmore [Page 10]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+ appropriate to that generic name. If that file is not found, then
+ the plain 'pathname' will be tried. This 'suffix' option allows a
+ whole set of custom generics to be setup without a lot of effort.
+ Below is shown the general format; fields are delimited by one or
+ more spaces or tabs; trailing empty fields may be omitted; blank
+ lines and lines beginning with '#' are ignored.
+
+ # comment line
+
+ homedirectory
+ genericname1 pathname1
+ genericname2 pathname2
+ ...
+
+ % end of generic names, start of address mappings
+
+ hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
+ hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
+ ...
+
+ Here is a specific example. Note the 'hardwaretype' number is the
+ same as that shown in the ARP section of the 'Assigned Numbers' RFC.
+ The 'hardwaretype' and 'ipaddr' numbers are in decimal;
+ 'hardwareaddr' is in hex.
+
+ # last updated by smith
+
+ /usr/boot
+ vmunix vmunix
+ tip ethertip
+ watch /usr/diag/etherwatch
+ gate gate.
+
+ % end of generic names, start of address mappings
+
+ hamilton 1 02.60.8c.06.34.98 36.19.0.5
+ burr 1 02.60.8c.34.11.78 36.44.0.12
+ 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
+ mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh
+ welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip
+ welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip
+
+ In the example above, if 'mjh-gateway' does a default boot, it will
+ get the file '/usr/boot/gate.mjh'.
+
+
+
+
+
+Croft & Gilmore [Page 11]
+
+
+
+RFC 951 September 1985
+Bootstrap Protocol
+
+
+10. Acknowledgements
+
+ Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
+ bootstraping [2] using RARP [1].
+
+ We would also like to acknowledge the previous work and comments of
+ Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
+
+REFERENCES
+
+ 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A
+ Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.
+
+ 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,
+ June, 1984.
+
+ 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,
+ September, 1984.
+
+ 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,
+ October, 1984.
+
+ 5. David Plummer. An Ethernet Address Resolution Protocol. RFC
+ 826, NIC, September, 1982.
+
+ 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.
+
+ 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.
+
+ 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
+
+ 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,
+ June, 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Croft & Gilmore [Page 12]
+