DHCPv4 has been around for about 20 years. It was originally specified in RFC 1531, “Dynamic Host Configuration Protocol”, October 1993, and RFC 1533 “DHCP Options and BOOTP Vendor Extensions”, October 1993. RFC 1531 was replaced almost immediately with RFC 1541, “Dynamic Host Configuration Protocol”, October 1993 (to correct some errors).
RFC 1541 was replaced with RFC 2131, “Dynamic Host Configuration Protocol”, March 1997. RFC 1533 was replaced with RFC 2132 “DHCP Options and BOOTP Vendor Extensions”, March 1997. These last two are the current versions, although there have been several updates to both.
All of these RFCs were written by Ralph Droms (with additional authors in some cases), the “father of DHCP”. His book “The DHCP Handbook, 2nd Edition” (2002) is the standard reference work on DHCPv4.
Actually, DHCPv4 is based on an even older protocol, BOOTP. This was originally specified in RFC 951, “Bootstrap Protocol”, September 1985.
DHCPv4 supports automatic configuration of TCP/IP for IPv4 from a centralized server. Almost every device that runs TCP/IP includes a DHCPv4 client.
DHCPv4 uses broadcast heavily (every configuration involves four separate broadcast transmissions). It also has no security of any kind. It is trivial to deploy a “rogue” DHCPv4 server in a subnet (this often happens even by accident). If such a server is present, nodes may obtain bogus network configuration that won’t work. It is possible to deploy a pair of DHCPv4 servers for redundancy, but you must configure non-overlapping pools in the two servers.
DHCPv4 is accessible only over IPv4. It does not support access over IPv6. DHCPv4 cannot manage IPv6 addresses or information of any kind. A completely new protocol and server implementation was required for DHCPv6.
The DHCPv4 server provides stateless information to nodes, including the IPv4 addresses of DNS, the DNS subnet default domain name, DNS search strings, the subnet default gateway and the “subnet mask” (e.g. 255.255.0.0). All nodes in a subnet get the same stateless information, and the server does not need to keep track of who it provided the information to (hence “stateless”).
The DHCPv4 server also provide “stateful” information to nodes, in the form of a managed IPv4 address. Each node that requests configuration gets one unique address from a pool of IPv4 addresses that it manages. It must keep track of which addresses have been assigned from the pool, so that it doesn’t assign the same address to two nodes (hence “stateful”).
The managed address pools can contain public or private (RFC 1918) IPv4 addresses. Most organizations no longer have enough public addresses to manage with DHCPv4. ISPs may provide one public IPv4 address to home routers via an ISP based DHCPv4 server (for the WAN interface and “hide mode” external address for NAT44). Many ISP modem/routers include a DHCPv4 server, which almost always manages private addresses.
Over the years, many additional options for DHCPv4 have been added. These even include the ability to configure IP phones with SIP.
DHCPv4 makes address assignments with a specified lease (characterized by a starting and ending date and time). It is up to the node to renew a lease before it expires. If the lease expires without renewal, the node will remove the assigned address, and the server may assign the address to another node. The lease duration is configured on the server, and can last from only a few minutes, to years. If a large number of people are sharing a small pool of addresses, short leases are common. If there are plenty of addresses, long leases are better.
TCP/IP Configuration Using DHCPv4
When you configure an IPv4 compliant node for TCP/IP, most platforms allow you to choose one of three approaches:
1. Specify all network configuration manually (IPv4 node address, subnet mask, default gateway, and IPv4 addresses of DNS).
2. Obtain all network configuration from DHCPv4 (IPv4 node address, subnet mask, default gateway, and IPv4 addresses of DNS).
3. Obtain all network configuration from DHCPv4 except for the IPv4 addresses of DNS, which are specified manually.
It is not possible to specify the node address, subnet mask and default gateway manually while still obtaining the IPv4 addresses of DNS from DHCPv4.
If a node tries to configure an address via DHCPv4 and there is not DHCPv4 server available, it used to fail with no address assigned. Recent nodes will fall back to an APIPA link-local address from netblock 169.254/16.
DHCPv4 Relay Agent
DHCPv4 clients use broadcast to discover a DHCPv4 server. Since usually they have no node address (or other network configuration) prior to trying to obtain one from DHCPv4, there is a “chicken and egg” problem – how do you connect to a server if you don’t already have an address? Use of broadcast solves that problem, and incidentally means you don’t have to configure the address of the DHCPv4 server in each client node. The client node sends a broadcast packet and the DHCPv4 server sees it and responds to it with another broadcast. Actually a total of four broadcasts are involved in most DHCPv4 requests (see packet captures below).
However, broadcast packets will not cross any routers. They work only within the sending node’s subnet. They are “link-local”. So what if you want to manage all of the IPv4 addresses for a multi-subnet network from one DHCPv4 server? There is something called a DHCPv4 relay agent that can be deployed in each subnet. It receives the broadcast from the client, and relays it to the real DHCPv4 server (in another subnet) over unicast UDP. The real server handles the request, and returns the results to the relay agent over unicast UDP, which then returns the result to the requesting node via broadcast. The relay agent must be configured with the IPv4 address of the real DHCPv4 server. The relay agent is “stateless”. All of the state is maintained in the real DHCPv4 server. From the viewpoint of a DHCPv4 client, there is no difference in talking to a local DHCPv4 server and a DHCPv4 relay agent.
DHCPv4 Server Configuration
Usually routers and firewalls have both a DHCPv4 server and a DHCPv4 relay agent included. You enable one or the other, but not both. If you enable the relay agent, you must have a real DHCPv4 server running somewhere for it to relay requests to, and you must configure the address of that real server in the relay agent. If you enable a DHCPv4 server anywhere (one in each subnet, or one central one with relay agents), there are several things you must configure:
- a pool of IPv4 addresses, e.g. 172.20.2.1 to 172.20.2.254
- lease period
- the subnet mask, e.g. 255.255.0.0 (or alternatively, the prefix length, e.g. 16)
- the IPv4 addresses of DNS (e.g. 172.20.0.13, 172.20.0.14)
- the IPv4 address of the default gateway (e.g. 172.20.0.1)
You can also configure address reservations, by MAC address. Any time a node with a MAC address from an address reservation asks for an IPv4 address, they will be given the address from the reservation. For example, reserve 172.20.2.1 for MAC address 50-46-5d-6b-7a-54. Some DHCPv4 servers have the ability to elevate a current address lease to a reservation. Making an address reservation usually automatically removes the reserved IP address from the pool.
There may be other items you can configure in a DHCPv4 server, but those are the basic items. Be sure that none of the addresses in the configured pool are currently manually assigned to any node, or you will get an address conflict when one of those is assigned to another node by DHCPv4. You can usually remove a few addresses (or ranges of addresses) from the pool (e.g. pool is 172.20.1.1 to 172.20.1.127, except for 172.20.1.10 and 172.20.1.11).
Address Pool: 172.20.1.1 – 172.20.1.127
Option 003 Router = 172.20.0.1 (default gateway)
Option 006 DNS servers = 172.20.0.13, 172.20.0.12
Option 015 DNS Domain Name = hughesnet.local
Lease Duration = 0 days, 8 hours, 0 mintues
Address Node name Lease Expiration
172.20.1.9 fred.hughesnet.local 7/24/2013 8:27:16 PM
172.20.1.5 joe.hughesnet.local 7/24/2013 7:55:58 PM
172.20.1.4 sue.hughesnet.local 7/24/2013 8:27:13 PM
In this case, there is actually a second DHCPv4 server on the subnet, configured exactly the same way, except for the pool, which is 172.20.1.128 – 172.20.1.254. When a node asks for DHCPv6 configuration, both servers respond to the broadcast with an offer (which is also broadcast). The client receives both offers, chooses one of them and accepts it with another broadcast. The server that made the offer that was actually reserves the offered address and returns the official configuration to the client, at which point the client actually sets the configuration. The other server returns the address from its offer to its pool.
There are two DHCPv4 servers in this subnet (both running on Windows Server 2008 R2). Both have the following options:
Default Gateway: 172.20.0.1
DNS Servers: 172.20.0.13, 172.20.0.12
DNS Domain Name: hughesnet.local
Lease Duration: 0 days, 8 hours, 0 minutes
Server ws3.hughesnet.local (at 172.20.0.13)
The address pool is:
172.20.1.128 – 172.20.1.254
Server ws4.hughesnet.local (at 172.20.0.14)
The address pool is:
172.20.1.1 – 172.20.1.127
There are four packets exchanged in each DHCPv4 transaction (Discover, Offer, Request and Ack). In this case, there are actually two DHCP Offers (one from the DHCPv4 server on ws3.hughesnet.local and one from the DHCPv4 server on ws4.hughesnet.local), so a total of five packet captures are shown.
The source address for messages from a client is 0.0.0.0 (the unspecified address). The destination address for all messages from a client is 255.255.255.255 (the broadcast address). The client sends and receives on port 68 (bootpc).
The source address for messages from a server is its IPv4 address. The destination address for all messages from a server is 255.255.255.255 (the broadcast address).The server sends and receives on port 67 (bootps).
In this case, the node previously has the address 172.20.1.6, and asks to keep it. There is no guarantee that this will be honored (that address might have been given to someone else, if the client let the lease expire). In this case, the lease hasn’t expired, and that address is still available (from the server on 172.20.0.14), so the client gets its wish.
The client node requests TCP/IP configuration by sending a DHCP Discover message.
The DHCPv4 server on 172.20.0.14 sends a DHCP Offer message, saying “Would you like address 172.20.1.6?”
The DHCPv4 server on 172.20.0.13 sends a DHCP Offer message, saying “Would you like address 172.20.1.129?”
The client accepts the offer for address 172.20.1.6, and responds with a DHCP Request message saying “OK, I choose the offer from 172.20.0.14.” This is specified as the DHCP Server Identifier.
On seeing the DHCP Request message, the DHCPv4 server on 172.20.0.13 says “OK, no problem”, returns address 172.20.1.129 to its pool, and goes back to sleep. The DHCPv4 server on 172.20.0.14 reserves address 172.20.1.6 for this client node, and sends a DHCP Ack message with the official TCP/IP configuration information. If you check the DHCPv4 server on 172.20.0.14, it will now show the address 172.20.1.6 assigned to node lawrence-pc, with an expiration date and time of 7/24/2013, 9:26:31 PM (8 hours from this transaction).
On receiving the DHCP Ack message, the client node actually configures TCP/IP with the configuration information in that message.
Note that all messages were sent via UDP broadcast. Every node in the subnet is interrupted by each broadcast, and has to check if it applies to them. All nodes except for the client and the DHCPv4 servers say “not for me” and discard the messages. DHCPv4 is very “noisy”.