DHCP [RFC2131] is a popular client/server protocol used to assign configuration information to hosts (and, less frequently, to routers). DHCP is very widely used, in both enterprises and home networks. Even the most basic home router devices support embedded DHCP servers. DHCP clients are incorporated into all common client operating systems and a large number of embedded devices such as net- work printers and VoIP phones. Such devices usually use DHCP to acquire their IP address, subnet mask, router IP address, and DNS server IP address. Information pertaining to other services (e.g., SIP servers used with VoIP) may also be conveyed using DHCP. DHCP was originally conceived for use with IPv4, so references to it or its relationship with IP in this chapter will refer to IPv4 unless otherwise specified. IPv6 can also use a version of DHCP called DHCPv6 [RFC3315], which we discuss in Section 6.2.5, but IPv6 also supports its own automatic processes to
ptg999 Section 6.2 Dynamic Host Configuration Protocol (DHCP) 235
determine configuration information. In a hybrid configuration, IPv6 automatic configuration can be combined with the use of DHCPv6.
The design of DHCP is based on an earlier protocol called the Internet Boot- strap Protocol (BOOTP) [RFC0951][RFC1542], which is now effectively obsolete.
BOOTP provides limited configuration information to clients and does not have a mechanism to support changing that information after it has been provided.
DHCP extends the BOOTP model with the concept of leases [GC89] and can pro- vide all information required for a host to operate. Leases allow clients to use the configuration information for an agreed-upon amount of time. A client may request to renew the lease and continue operations, subject to agreement from the DHCP server. BOOTP and DHCP are backward-compatible in the sense that BOOTP-only clients can make use of DHCP servers and DHCP clients can make use of BOOTP-only servers. BOOTP, and therefore DHCP as well, is carried using UDP/IP (see Chapter 10). Clients use port 68 and servers use port 67.
DHCP comprises two major parts: address management and delivery of configuration data. Address management handles the dynamic allocation of IP addresses and provides address leases to clients. Configuration data delivery includes the DHCP protocol’s message formats and state machines. A DHCP server can be configured to provide three levels of address allocation: automatic allocation, dynamic allocation, and manual allocation. The differences among the three have to do with whether the addresses assigned are based on the identity of the client and whether such addresses are subject to being revoked or changed.
The most commonly used method is dynamic allocation, whereby a client is given a revocable IP address from a pool (usually a predefined range) of addresses con- figured at the server. In automatic allocation, the same method is used but the address is never revoked. In manual allocation, the DHCP protocol is used to con- vey the address, but the address is fixed for the requesting client (i.e., it is not part of an allocatable pool maintained by the server). In this last mode, DHCP acts like BOOTP. We shall focus on dynamic allocation, as it is the most interesting and common case.
6.2.1 Address Pools and Leases
In dynamic allocation, a DHCP client requests the allocation of an IP address.
The server responds with one address selected from a pool of available addresses.
Typically, the pool is a contiguous range of IP addresses allocated specifically for DHCP’s use. The address given to the client is allocated for only a specific amount of time, called the lease duration. The client is permitted to use the IP address until the lease expires, although it may request extension of the lease as required. In most situations, clients are able to renew leases they wish to extend.
The lease duration is an important configuration parameter of a DHCP server.
Lease durations can range from a few minutes to days or more (“infinite” is pos- sible but not recommended for anything but simple networks). Determining the best value to use for leases is a trade-off between the number of expected clients,
ptg999 the size of the address pool, and the desire for the stability of addresses. Longer
lease durations tend to deplete the available address pool faster but provide greater stability in addresses and somewhat reduced network overhead (because there are fewer requests to renew leases). Shorter leases tend to keep the pool available for other clients, with a consequent potential decrease in stability and increase in network traffic load. Common defaults include 12 to 24 hours, depending on the particular DHCP server being used. Microsoft, for example, recommends 8 days for small networks and 16 to 24 days for larger networks. Clients begin trying to renew leases after half of the lease duration has passed.
When making a DHCP request, a client is able to provide information to the server. This information can include the name of the client, its requested lease duration, a copy of the address it is already using or last used, and other parame- ters. When the server receives such a request, it can make use of whatever informa- tion the client has provided (including the requesting MAC address) in addition to other exogenous information (e.g., the time of day, the interface on which the request was received) to determine what address and configuration information to provide in response. In providing a lease to a client, a server stores the lease information in persistent memory, typically in nonvolatile memory or on disk. If the DHCP server restarts and all goes well, leases are maintained intact.
6.2.2 DHCP and BOOTP Message Format
DHCP extends BOOTP, DHCP’s predecessor. Compatibility is maintained between the protocols by defining the DHCP message format as an extension to BOOTP’s in such a way that BOOTP clients can be served by DHCP servers, and BOOTP relay agents (see Section 6.2.6) can be used to support DHCP use, even on networks where DHCP servers do not reside. The message format includes a fixed-length initial portion and a variable-length tail portion (see Figure 6-1).
The message format of Figure 6-1 is defined by BOOTP and DHCP in several RFCs ([RFC0951][RFC1542][RFC2131]). The Op (Operation) field identifies the mes- sage as either a request (1) or a reply (2). The HW Type (htype) field is assigned based on values used with ARP (see Chapter 4) and defined in the corresponding IANA ARP parameters page [IARP], with the value 1 (Ethernet) being very com- mon. The HW Len (hlen) field gives the number of bytes used to hold the hardware (MAC) address and is commonly 6 for Ethernet-like networks. The Hops field is used to store the number of relays through which the message has traveled. The sender of the message sets this value to 0, and it is incremented at each relay.
The Transaction ID is a (random) number chosen by the client and copied into responses by the server. It is used to match replies with requests.
The Secs field is set by the client with the number of seconds that have elapsed since the first attempt to establish or renew an address. The Flags field currently contains only a single defined bit called the broadcast flag. Clients may set this bit in requests if they are unable or unwilling to process incoming unicast IP data- grams but can process incoming broadcast datagrams (e.g., because they do not
ptg999 Section 6.2 Dynamic Host Configuration Protocol (DHCP) 237
yet have an IP address). Setting the bit informs the server and relays that broad- cast addressing should be used for replies.
Note
There has been some difficulty in Windows environments regarding the use of the broadcast flag. Windows XP and Windows 7 DHCP clients do not set the flag, but Windows Vista clients do. Some DHCP servers in use do not process the flag properly, leading to apparent difficulties in supporting Vista clients, even though the Vista implementation is RFC-compliant. See [MKB928233] for more information.
The next four fields are various IP addresses. The Client IP Address (ciaddr) field includes a current IP address of the requestor, if known, and is 0 otherwise.
The “Your” IP Address (yiaddr) field is filled in by a server when providing an
2S5HT5HSO\
ELWV
+:7\SH KW\SHELWV
+:/HQ KOHQELWV
+RSV ELWV 7UDQVDFWLRQ,'[LGELWV
6HFVELWV )ODJVELWV
&OLHQW,3$GGUHVVFLDGGUELWVLINQRZQ
³<RXU´,3DGGUHVV\LDGGUELWV 1H[W6HUYHU,3$GGUHVVVLDGGUELWV
*DWHZD\5HOD\,3$GGUHVVJLDGGUELWV
&OLHQW+DUGZDUH$GGUHVVFKDGGUELWV
6HUYHU1DPHVQDPHE\WHV
%RRW)LOH1DPHILOHE\WHV
2SWLRQVYHQGYDULDEOH
%
=HUR
%URDGFDVW)ODJ
)L[HG6L]H
)ODJVELWV
%22732SWLRQ ,QGLFDWHV'+&30HVVDJH
2SWLRQ2YHUORDG$UHD
$OWHUQDWLYH$UHDWR+ROG2SWLRQV
Figure 6-1 The BOOTP message format, including field names from [RFC0951], [RFC1542], and [RFC2131].
The BOOTP message format is used to hold DHCP messages by appropriate assignment of options.
In this way, BOOTP relay agents can process DHCP messages, and BOOTP clients can use DHCP servers. The Server Name and Boot File Name fields can be used to carry DHCP options if necessary.
ptg999 address to a requesting client. The Next Server IP Address (siaddr) field gives the IP
address of the next server to use for the client’s bootstrap process (e.g., if the client needs to download an operating system image that may be accomplished from a server other than the DHCP server). The Gateway (or Relay) IP Address (giaddr) field is filled in by a DHCP or BOOTP relay with its address when forwarding DHCP (BOOTP) messages. The Client Hardware Address (chaddr) field holds a unique identifier of the client and can be used in various ways by the server, including arranging for the same IP address to be given each time a particular client makes an address request. This field has traditionally held the client’s MAC address, which has been used as an identifier. Nowadays, the Client Identifier, an option described in Sections 6.2.3 and 6.2.4, is preferred for this use.
The remaining fields include the Server Name (sname) and Boot File Name (file) fields. These fields are not always filled in, but if they are, they contain 64 or 128 bytes, respectively, of ASCII characters indicating the name of the server or path to the boot file. Such strings are null-terminated, as in the C programming language.
They can also be used instead to hold DHCP options if space is tight (see Section 6.2.3). The final field, originally known as the Vendor Extensions field in BOOTP and fixed in length, is now known as the Options field and is variable in length. As we shall see, options are used extensively with DHCP and are required to distin- guish DHCP messages from legacy BOOTP messages.
6.2.3 DHCP and BOOTP Options
Given that DHCP extends BOOTP, any fields needed by DHCP that were not pres- ent when BOOTP was designed are carried as options. Options take a standard format beginning with an 8-bit tag indicating the option type. For some options, a fixed number of bytes following the tag contain the option value. All others consist of the tag followed by 1 byte containing the length of the option value (not including the tag or length), followed by a variable number of bytes containing the option value itself.
A large number of options are available with DHCP, some of which are also supported by BOOTP. The current list is given by the BOOTP/DHCP parameters page [IBDP]. The first 77 options, including the most common ones, are speci- fied in [RFC2132]. Common options include Pad (0), Subnet Mask (1), Router Address (3), Domain Name Server (6), Domain Name (15), Requested IP Address (50), Address Lease Time (51), DHCP Message Type (53), Server Identifier (54), Parameter Request List (55), DHCP Error Message (56), Lease Renewal Time (58), Lease Rebinding Time (59), Client Identifier (61), Domain Search List (119), and End (255).
The DHCP Message Type option (53) is a 1-byte-long option that is always used with DHCP messages and has the following possible values: DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPDECLINE (4), DHCPACK (5), DHCPNAK (6), DHCPRELEASE (7), DHCPINFORM (8), DHCPFORCERENEW (9) [RFC3203], DHCPLEASEQUERY (10), DHCPLEASEUNASSIGNED (11),
ptg999 Section 6.2 Dynamic Host Configuration Protocol (DHCP) 239
DHCPLEASEUNKNOWN (12), and DHCPLEASEACTIVE (13). The last four val- ues are defined by [RFC4388].
Options may be carried in the Options field of a DHCP message, as well as in the Server Name and Boot File Name fields mentioned previously. When options are carried in either of these latter two places, called option overloading, a special Over- load option (52) is included to indicate which fields have been appropriated for holding options. For options whose lengths exceed 255 bytes, a special long options mechanism has been defined [RFC3396]. In essence, if the same option is repeated multiple times in the same message, the contents are concatenated in the order in which they appear in the message, and the result is processed as a single option. If a long option also uses option overloading, the order of processing is last to first:
Options field, Boot File Name field, and then Server Name field.
Options tend to either provide relatively simple configuration information or be used in supporting some other agreement protocol. For example, [RFC2132]
specifies options for most of the traditional configuration information a TCP/IP node requires (addressing information, server addresses, Boolean assignments of configuration information such as enabling IP forwarding, initial TTL values).
Subsequent specifications describe simple configuration information for NetWare [RFC2241][RFC2242], user classes [RFC3004], FQDN [RFC4702], Internet Storage Name Service server (iSNS, used in storage networks) [RFC4174], Broadcast and Multicast Service controller (BCMCS, used with 3G cellular networks) [RFC4280], time zone [RFC4833], autoconfiguration [RFC2563], subnet selection [RFC3011], name service selection (see Chapter 11) [RFC2937], and servers for the Protocol for Carrying Authentication for Network Access (PANA) (see Chapter 18) [RFC5192].
Those options defined for use in support of other protocols and functions are described later, starting with Section 6.2.7.
6.2.4 DHCP Protocol Operation
DHCP messages are essentially BOOTP messages with a special set of options.
When a new client attaches to a network, it first discovers what DHCP servers are available and what addresses they are offering. It then decides which server to use and which address it desires and requests it from the offering server (while informing all the servers of its choice). Unless the server has given away the address in the meantime, it responds by acknowledging the address allocation to the requesting client. The time sequence of events between a typical client and server is depicted in Figure 6-2.
Requesting clients set the BOOTP Op field to BOOTREQUEST and the first 4 bytes of the Options field to the decimal values 99, 130, 83, and 99, respectively (the magic cookie value from [RFC2132]). Messages from client to server are sent as UDP/IP datagrams containing a BOOTP BOOTREQUEST operation and an appro- priate DHCP message type (usually DHCPDISCOVER or DHCPREQUEST). Such messages are sent from address 0.0.0.0 (port 68) to the limited broadcast address 255.255.255.255 (port 67). Messages traveling in the other direction (from server to
ptg999
client) are sent from the IP address of the server and port 67 to the IP local broad- cast address and port 68 (see Chapter 10 for details on UDP).
In a typical exchange, a client first broadcasts a DHCPDISCOVER message. Each server receiving the request, either directly or through a relay, may respond with a DHCPOFFER message, including an offered IP address in the “Your” IP Address field. Other configuration options (e.g., IP address of DNS server, subnet mask) are often included. The offer message includes the lease time (T), which provides the upper bound on the amount of time the address can be used if it is not renewed. The message also contains the renewal time (T1), which is the amount of time before the client should attempt to renew its lease with the server from which it acquired its lease, and the rebinding time (T2), which bounds the time in which it should attempt to renew its address with any DHCP server. By default, T1 = (T/2) and T2 = (7T/8).
After receiving one or more DHCPOFFER messages from one or more servers, the client determines which offer it will accept and broadcasts a DHCPREQUEST message including the Server Identifier option. The Requested IP Address option is set to the address received in the selected DHCPOFFER message. Multiple servers may receive the broadcast DHCPREQUEST message, but only the server identified within the DHCPREQUEST message acts by committing the address binding to
',6 &29(5
QXOOFLDGGUEURDGFDVW[LGSDUDPVUHTXHVW
2))(5
EURDGFDVWVLDGGU[LG\LDGGURSWLRQV
$&.
EURDGFDVW[LG\LDGGURSWLRQV 5( 48(67 EURDGFDVWVLDGGUFLDGGU[LGRSWLRQV
&OLHQW 6 HOHFWHG
6 HUYHU
'HWHUPLQHV
&RQILJXUDWLRQ
2WKHU6 HUYHUV0D\2))( 5
&ROOHFWV5HSOLHV 6 HOHFWV 6 HUYHU&RQILJXUDWLRQ
6 HOHFWHG6 HUYHU&RPPLWV
&RQILJXUDWLRQ 2WKHU6 HUYHUV'R1RW
&RQILJXUHG
&KHFNHJ$53$&'IRU&RQIOLFW '( &/,1(
,I&RQIOLFW 9HULI\LQJ
5HFRPPHQGHG
&OLHQW6 WDUWV 0D\8VH=HUR,3
6 RXUFH$GGUHVV
Figure 6-2 A typical DHCP exchange. A client discovers a set of servers and addresses they are offering using broadcast messages, requests the address it desires, and receives an acknowledgment from the selected server. The transaction ID (xid) allows requests and responses to be matched up, and the server ID (an option) indicates which server is pro- viding and committing the provided address binding with the client. If the client already knows the address it desires, the protocol can be simplified to include use of only the REQUEST and ACK messages.
ptg999 Section 6.2 Dynamic Host Configuration Protocol (DHCP) 241
persistent storage; the others clear any state regarding the request. After handling the binding, the selected server responds with a DHCPACK message, indicating to the client that the address binding can now be used. In the case where the server cannot allocate the address contained in the DHCPREQUEST message (e.g., it has been allocated in some other way or is not available), the server responds with a DHCPNAK message.
Once the client receives the DHCPACK message and other associated configu- ration information, it may probe the network to ensure that the address provided is not in use (e.g., by sending an ARP request for the address to perform ACD, described in Chapter 4). Should the client determine that the address is already in use, the client ceases using the address and sends a DHCPDECLINE message to the server to indicate that the address cannot be used. After a recommended 10s delay, the client is able to retry. If a client elects to relinquish its address before its lease expires, it sends a DHCPRELEASE message.
In circumstances where a client already has an IP address and wishes only to renew its lease, the initial DHCPDISCOVER/DHCPOFFER messages can be skipped. Instead, the protocol begins with the client requesting the address it is currently using with a DHCPREQUEST message. At this point, the protocol works as already described: the server will likely grant the request (with a DHC- PACK) or deny the request by issuing a DHCPNAK. Another circumstance arises when a client already has an address, does not need to renew it, but requires other (non-address) configuration information. In this case, it can use a DHCPINFORM message in place of a DHCPREQUEST message to indicate its use of an existing address and desire to obtain additional information. Such messages elicit a DHC- PACK message from the server, which includes the requested additional configu- ration information.
6.2.4.1 Example
To see DHCP in action, we now inspect the packets exchanged when a Microsoft Vista laptop attaches to a wireless LAN supported by a Linux-based DHCP server (Windows 7 systems are nearly identical). The client was recently associated with a different wireless network, using a different IP prefix, and is now being connected to the new network. Because it remembers the address it had from the previous net- work, the client first tries to continue using that address using a DHCPREQUEST message (see Figure 6-3).
Note
There is now an agreed-upon procedure for detecting network attachment (DNA), specified in [RFC4436] for IPv4 and [RFC6059] for IPv6. These specifications do not contain new protocols but instead suggest how unicast ARP (for IPv4) and a combination of unicast and multicast Neighbor Solicitation/Router Discovery messages (for IPv6; see Chapter 8) can be used to reduce the latency of acquir- ing configuration information when a host switches network links. As these speci- fications are relatively new (especially for IPv6), not all systems implement them.