DHCP stands for ‘Dynamic Host Configuration Protocol’ and is a means for networked computers to get their TCP/IP networking settings from a central server. Importantly, DHCP assigns IP addresses and other TCP/IP configuration parameters automatically. DHCP is explained in more detail at RFC 1541. A good place to obtain the document is ds.internic.net, available via FTP, Gopher and HTTP

DHCP is an extension of BOOTP (Bootstrap Protocol), the previous IP allocation specification. So, existing BOOTP devices can communicate with DHCP servers and allow DHCP requests to cross routers running BOOTP forwarders. This level of backward compatibility makes it easy for administrators to upgrade their network devices from BOOTP to DHCP as needed, without having to replace all of the clients at once or having to upgrade all of the routers.

Several major advancements beyond the BOOTP specifications provide significant advantages. For example, DHCP supports the concept of a "lease" whereby a server can allocate an address to a client for a specific amount of time. If you have more devices than IP addresses, using shorter leases can help to keep you from running out of addresses. If you have more addresses than devices, you can utilize permanent leases or you can assign fixed addresses to specific devices similar to BOOTP's mechanism.

Also, DHCP incorporates a much more robust dialogue during lease negotiation. Since the addresses can be assigned to the devices on an ad-hoc basis, mechanisms need to be incorporated into the assignment procedure that allow for a broader range of options, as well as for a broader range of error handling conditions. BOOTP protocol only allowed for two types of messages (request and reply), while DHCP has seven possible message types that can be used during the address assignment sequence.

When a DHCP device attaches itself to the network for the first time, it broadcasts a DHCPDISCOVER packet. A DHCP server on the local segment will see the broadcast and return a DHCPOFFER packet that contains an IP address and other information. The servers may or may not conduct some sort of preliminary testing prior to offering the address, such as generating an ARP or an ICMP (Internet Control Message Protocol) echo to see if the address is already in use by another node somewhere. If your network does not have a DHCP server on every segment, you will need to configure your routers to provide BOOTP relay agents that forward the broadcasts to a predefined server on a remote segment.

The client may receive multiple DHCPOFFER packets from any number of servers, so it must choose between them, and broadcast a DHCPREQUEST packet that identifies the explicit server and lease offer that it likes the best. This decision may be based on which offer has the longest lease or which offer provides the most information that the specific client needs for optimal operation (more on this later). The non-chosen servers would notice the explicit DHCPREQUEST packet and go on about their business.

Assuming that the offer is still valid, the chosen server would return a DHCPACK that tells the client the lease is finalized. If the offer is no longer valid for some reason-perhaps due to a time-out or another client allocating the lease-then the selected server must respond with a DHCPNAK message. This would cause the client to send another DHCPDISCOVER packet, starting the process over again.

Once the client receives a DHCPACK, then all ownership and maintenance of the lease is the responsibility of the client. For example, a client may refuse an offer that is detailed in the DHCPACK message, and it is the client's responsibility to do so. Clients are supposed to test the addresses that have been offered to them by conducting ARP broadcasts. So if another node responds to the ARP, the client would assume that the offered address is in use. At this point, the client would reject the offer by sending a DHCPDECLINE message to the offering server, and would also send another DHCPDISCOVER packet, thereby starting the process yet again.

Once the client has the lease, it must be renewed prior to the lease expiration through another DHCPREQUEST message. If a client finishes using a lease prior to its expiration date, the client is supposed to send a DHCPRELEASE message to the server so that the lease can be made available to other nodes. If the server doesn't hear from the client by the end of the lease, it marks the lease as non-renewed, and makes it available for other clients to use.

Related Protocol

By using DHCP, dynamically configuring the host to the network is done by a simple handshake. In history, there are also many dynamic automatic configuration protocols. RARP (Reverse Address Resolution Protocol) and BOOTP can also provide the mechanism of automatic configuration. These protocols use simple interaction; the client requests and the server replies. RARP is executed on Ethernet, and converts the Ethernet address to an IP address. RARP handshake is mainly used in the diskless workstations. RARP uses an Ethernet frame directly; meanwhile BOOTP uses UDP (User Datagram Protocol). BOOTP returns IP addresses with the sub-net mask of a network, IP addresses of routers, etc. RARP and BOOTP have two defects. First, these protocols only support static allocation (conversion) of an IP address. RARP and BOOTP protocol do not solve the requirement of dynamic allocation. Secondly, these protocols can provide only few parameters.

Another protocol called NIP (Network Information Protocol) has the mechanism of dynamic allocation. It is based on the ``Polling/Defense'' mechanism. When the NIP client requests an IP address, NIP server returns a set of IP address that is available in the network. NIP client selects one IP address from the network, and checks its availability with ARP (Address Resolution Protocol). If ARP replies, NIP client will retry the selection phase. If there is no ARP reply to repeated ARP requests, NIP client reserves the IP address. NIP may cause IP duplication if the host does not reply to ARP request. In addition, there is another problem that a client may be allocated to a different address than before after reallocation.

Design of DHCP

DHCP is extension of BOOTP. DHCP uses client-server model and is constructed on UDP. DHCP has server and client model with relay agent same as BOOTP. It relays messages between the client and the server.

In DHCP all interactions are initiated by a client, and a server replies. This paper refers to this DHCP interaction model as Basic Model. DHCP has following implementation goals;

• DHCP should support dynamic allocation. DHCP is capable of leasing the address, DHCP server should be able to recycle the IP address when the lease period is expired.
• A network administrator should not configure each client, and user interaction of each client should not be required.
• DHCP should also support static allocation and an infinite lease.
• DHCP should coexist with BOOTP and normal host.
• DHCP should not require a server on each sub-net. Relay agent that is compatible with BOOTP can be used.

Only allocation model supported by BOOTP is static allocation. On the other hand, DHCP supports three models;

1. Dynamic allocation: Server chooses and allocates an IP address with finite lease.
2. Automatic or Reserved allocation: Server allocates an IP address with infinite lease.
3. Static allocation: Server allocates an IP address that has been chosen by the administrator.

DHCP server manages two databases to recognize the network status: Address Pool is the database that holds IP addresses and other network configuration parameters. Binding database keeps mapping between an Ethernet address and entry of Address Pool.

DHCP Message Format

DHCP uses the same packet format with BOOTP for its compatibility (Figure 1). DHCP server can respond to BOOTP client and vice versa.

Figure 1: DHCP Packet Format

Table 1 is a part of the description of fields in a DHCP message. BOOTP uses only two message types; BootRequest and BootReply. These values are also used in DHCP for compatibility. However, DHCP puts another value in the options field to distinguish more various messages. There are seven message types for DHCP (Table 2).

DHCP protocol flows are different with, getting a new address and getting the previously assigned address. Figure2 shows the first case:

1. DHCP client broadcasts a DhcpDiscover. The client may specify preference of a lease and/or an IP address.
2. DHCP server receiving the DhcpDiscover may return DhcpOffer or may not return (Many servers may receives the DhcpDiscover). If a server decides to respond, server puts an available address into yiaddr field and broadcasts the DhcpOffer. At this point, there is no agreement of an assignment between the server and the client.
3. Client gets one or more DhcpOffers and chooses one server from them. The client puts the IP address of the server into the Server identifier option of a DhcpRequest and broadcasts it to a server.
4. The server checks the Server identifier option. If it does not match with its own address, the server considers it as an implicit decline. The selected server sends the DhcpAck (if its address is available) or the DhcpNak (for example, the address is already assigned to another client).
5. The client that gets the DhcpAck starts using the IP address. If it gets DhcpNak, it restarts from step 1.
6. The client finds a problem with the assigned address of DhcpAck, it sends DhcpDecline to the server, and restarts from step 1.
7. The client can release the address before its lease expires by DhcpRelease. This process is not absolutely required.

The second case, the client requests previously assigned address, some steps are omitted;

1. A DHCP client broadcasts a DhcpRequest which Requested IP address option is the previously assigned address.
2. A DHCP server that has a binding of the address returns DhcpAck or DhcpNak.
3. The remaining are same as the first case.

Relay agent

The relay agent is for relaying packets between servers and clients. This makes server possible to handle the sub-net that has no server available. Which means that there is no need to setup a server per sub-net. The relay agent works as following;

1. A DHCP client broadcasts a message.
2. A relay agent puts its IP address of a network interface from which it receives the message into the giaddr field of the message. The relay agent unicasts to a server.
3. The server sends back its reply to the relay agent (unicast). The reply includes same giaddr as the request sent by the client.
4. The relay agent broadcasts the reply from the interface which IP address appears in giaddr field.

DHCP and VLANs (Virtual Local Area Network) , which are very different in concept, are sometimes cited as different solutions to the same problem. While they have a goal in common (easing moves of networked computers), VLANs represent a more revolutionary change to a LAN than DHCP. A DHCP server and forwarding agents can allow you to set things up so that you can unplug a client computer from one network or sub-net and plug it into another and have it come alive immediately, it having been reconfigured automatically. In conjunction to Dynamic DNS, it could automatically be given its same name in its new place. VLAN-capable LAN equipment with dynamic VLAN assignment allows you to configure things so a client computer can be plugged into any port and have the same IP number (as well as name) and be on the same sub-net. The VLAN-capable network either has its own configuration that lists which MAC addresses are to belong to each VLAN, or it makes the determination from the source IP address of the IP packets that the client computer sends. Some differences in the two approaches:

• DHCP handles changes by reconfiguring the client while a VLAN-capable network handles it by reconfiguring the network port the client is moved to.
• DHCP dynamic reconfiguration requires a DHCP server, forwarding agent in each router, and DHCP capability in each client's TCP/IP support. The analogous capability in VLANs requires that all hubs throughout the network be VLAN-capable, supporting the same VLAN scheme. To this point VLAN support is proprietary with no vendor interoperability, but standards are being developed.
• DHCP can configure a new client computer for you while a VLAN-capable network can't.
• DHCP is generally aimed at giving "easy moves" capability to networks that are divided into sub-nets on a geographical basis, or on separate networks. VLANs are generally aimed at allowing you to set up sub-nets on some basis other than geographical, e.g. instead of putting everyone in one office on the same sub-net, putting each person on a sub-net that has access to the servers that that person requires.

There is an issue with trying to use DHCP (or BOOTP) and VLANs at the same time, in particular, with the scheme by which the VLAN-capable network determines the client's VLAN based upon the client computer's source IP address. Doing so assumes the client computer is already configured, which precludes the use of network to get the configuration information from a DHCP or BOOTP server.

DHCP, like BOOTP runs over UDP, utilizing ports 67 and 68.

An IP address (also called an IP number) is a number (typically written as four numbers separated by periods, i.e. 107.4.1.3 or 84.2.1.111) which uniquely identifies a computer that is making use of the Internet. It is similar to a telephone number. The phone number is used by the telephone network to direct calls to a phone location. The IP address is used by the Internet to direct data to your computer, e.g. the data your web browser retrieves and displays when you surf the net. One task of DHCP is to assist in the problem of getting a functional and unique IP number into the hands of the computers that make use of the Internet.

A MAC address (also called an Ethernet address or an IEEE MAC address) is a number (typically written as twelve hexadecimal digits, 0 through 9 and A through F, or as six hexadecimal numbers separated by periods or colons, i.e. 0080002012ef, 0:80:0:2:20:ef) that uniquely identifies a computer with an Ethernet interface. Unlike the IP number, it includes no indication of where your computer is located. In DHCP's typical use, the server uses a requesting computer's MAC address to uniquely identify it.

A DHCP lease is the amount of time that the DHCP server grants to the DHCP client permission to use a particular IP address. A typical server allows its administrator to set the lease time.

It is theoretically possible to develop software for client-machines that finds an unused address by picking them out of the blue and broadcasting a request of all the other client machines to see if they are using them. Appletalk is designed around this idea, and Apple's MacTCP can be configured to do this for IP. However, this method of IP address assignment has disadvantages.

1. A computer that needs a permanently assigned IP number might be turned off and lose its number to a machine coming up. This has problems both for finding services and for security.
2. A network might be temporarily divided into two non-communicating networks while a network component is not functioning. During this time, two different client-machines might end up claiming the same IP number. When the network comes back, they start malfunctioning.
3. If such dynamic assignment is to be confined to ranges of IP addresses, then the ranges are configured in each desktop machine rather than being centrally administered. This can lead both to hidden configuration errors and to difficulty in changing the range. Another problem with the use of such ranges is keeping it easy to move a computer from one sub-net to another.

Can DHCP support statically defined addresses?

Yes. At least there is nothing in the protocol to preclude this and one expects it to be a feature of any DHCP server. This is really a server matter and the client should work either way. The RFC refers to this as manual allocation.

How does DHCP and BOOTP handle multiple sub-nets?

For the situations where there is more than one LAN, each with its own sub-net number, there are two ways. First of all, you can set up a separate server on each sub-net. Secondly, a feature of some routers known as "BOOTP forwarding" to forward DHCP or BOOTP requests to a server on another sub-net and to forward the replies back to the client. The part of such a router (or server acting as a router) that does this is called a "BOOTP forwarding agent". Typically you have to enable it on the interface to the sub-net to be served and have to configure it with the IP address of the DHCP or BOOTP server. On a Cisco router, the address is known as the "UDP Helper Address".

Can a BOOTP client boot from a DHCP server?

Only if the DHCP server is specifically written to also handle BOOTP queries.

Can a DHCP client boot from a BOOTP server?

Only if the DHCP client was specifically written to make use of the answer from a BOOTP server. It would presumably treat a BOOTP reply as an unending lease on the IP address. In particular, the TCP/IP stack included with Windows 95 does not have this capability.

In a sub-netted environment, how does the DHCP server discover what sub-net a request has come from?

DHCP client messages are sent to off-net servers by DHCP relay agents, which are often a part of an IP router. The DHCP relay agent records the sub-net, from which the message was received, in the DHCP message header for use by the DHCP server.

Note: a DHCP relay agent is the same thing as a BOOTP relay agent

If a single LAN has more than one sub-net number, how can addresses be served on sub-nets other than the primary one?

A single LAN might have more than one sub-net number applicable to the same set of ports (broadcast domain). Typically, one sub-net is designated as primary, the others as secondary. A site may find it necessary to support addresses on more than one sub-net number associated with a single interface. DHCP's scheme for handling this is that the server has to be configured with the necessary information and has to support such configuration & allocation.

 

Here are two instances a server might have to handle:

1. Dynamic allocation supported on secondary sub-net numbers on the LAN to which the server is attached.
2. Dynamic allocation supported on secondary sub-net numbers on a LAN that is handled through a DHCP/BOOTP Relay. In this case, the DHCP/BOOTP Relay sends the server a gateway address associated with the primary sub-net and the server must know what to do with it.

If a physical LAN has more than one logical sub-net, how can different groups of clients be allocated addresses on different sub-nets?

One way to do this is to preconfigure each client with information about what group it belongs to. A DHCP feature designed for this is the user class option. To do this, the client software must allow the user class option to be preconfigured and the server software must support its use to control which pool a client's address is allocated from.

How long should a lease be?

Leasing can be 15 minutes to a year. It depends upon your goals, your site's usage patterns, and service arrangements for your DHCP server. A very relevant factor is that the client starts trying to renew the lease when it is halfway through: thus, for example, with a 4 day lease, the client which has lost access to its DHCP server has 2 days from when it first tries to renew the lease until the lease expires and the client must stop using the network.. During a 2-day outage, new users cannot get new leases, but no lease will expire for any computer turned on at the time that the outage commences.

Another factor is that the longer the lease the longer time it takes for client configuration changes controlled by DHCP to propagate.

Some relevant questions in deciding on a lease time:

Do you have more users than addresses?

If so, you want to keep the lease time short so people don't end up sitting on leases. Naturally, there are degrees. In this situation, I've heard examples cited of 15 minutes, 2 hours, and 2 days. Naturally, if you know you will have 20 users using 10 addresses in within a day, a 2-day lease is not practical.

Are you supporting mobile users?

If so, you may be in the situation of having more users than addresses on some particular IP number range. See above.

Do you have a typical or minimum amount of time that you are trying to support?

If your typical user is on for an hour at minimum, that suggests an hour lease at minimum.

How many clients do you have and how fast are the communications lines over which the DHCP packets will be run?

The shorter the lease, the higher the server and network load. In general, a lease of at least 2 hours is long enough that the load of even thousands of clients is negligible. For shorter leases, there may be a point beyond which you will want to watch the load. Note that if you have a communication line down for a long enough time for the leases to expire, you might see an unusually high load it returns. If the lease-time is at least double the communication line outage, this is avoided.

How long would it take to bring back up the DHCP server, and to what extent can your users live without it?

If the lease time is at least double the server outage, then running clients who already have leases will not lose them. If you have a good idea of your longest likely server outage, you can avoid such problems. For example, if your server-coverage is likely to recover the server within three hours at any time that clients are using their addresses, then a six-hour lease will handle such an outage. If you might have a server go down on Friday right after work and may need all Monday's workday to fix it, then your maximum outage time is 3 days and a 6-day lease will handle it.

 

Do you have users who want to tell other users about their IP number?

If your users are setting up their own web servers and telling people how to get to them either by telling people the IP number or through a permanent DNS entry, then they are looking for an IP number that won't be changing. While some sites would manually allocate any address that people expected to remain stable, other sites want to use DHCP's ability to automate distribution of relatively permanent addresses. The relevant time is the maximum amount of time that you wish to allow the user to keep their machine turned off yet keep their address. For example, in a university, if students might have their computers turned off for as long as three weeks between semesters, and you wish them to keep their IP address, then a lease of six weeks or longer would work.

Some examples of lease-times that sites have used & their rationales:

15 minutes

To keep the maximum number of addresses free for distribution in cases where there will be more users than addresses.

6 hours

Long enough to allow the DHCP server to be fixed, e.g. 3 hours.

12 hours

If you need to take back an address, then you know that it will only take one night for the users' lease to expire.

3 days

This is Microsoft's default and many sites use it.

6 days

Long enough that a weekend server outage that gets fixed on Monday will not result in leases terminating.

4 months

Long enough so students can keep their IP address over the summer hiatus. This rational is workable if the summer hiatus is no more than 2 months.

One year

If a user has not used their address in six months, then they are likely to be gone. Allows administrator to recover those addresses after someone has moved on.

1. How can I control which clients get leases from my server?

• A user could make trouble by putting up an unofficial DHCP server. The immediate problem would be a server passing out numbers already belonging to some computer yielding the potential for two or more "innocent bystander" nodes ending up with the same IP number. Net result is problems using the nodes, possibly intermittent of one or the other is sometimes turned off.
• A lot of problems are possible if a renegade server manages to get a client to accept its lease offering, and feeds the client its own version of other booting parameters. One scenario is a client that loads its OS over the network via tftp being directed to a different file (possibly on a different server), thus allowing the perpetrator to take over the client. Given that boot parameters are often made to control many different things about the computers' operation and communication, many other scenarios are just as serious.

1. What are the DHCP plans of major client-software vendors?

Apple MacOS

MacTCP's successor, Open Transport, supports DHCP. Open Transport 1.1 ships with System 7.5 Update 2.0 (which updates MacOS to version 7.5.3, released March 11, 1996) and supports any 68030, 68040, or PowerPC Macintosh. A shrink wrap version of Open Transport is planned.

Microsoft Windows95

Will support DHCP, but does not support BOOTP. BOOTP support may be added.

Novell LAN Workplace for DOS

For supporting DOS/Windows 3.1, Client32 for DOS/Windows, as of June 1996, provides the TCP/IP stack functions and DHCP, BOOTP support. For Windows 95 and Windows NT, the native stack will be used so that DHCP is supported.

IBM OS/2

Warp Connect does not support it, but there is a patch (fixpak) for it . Clients built with Warp Server code support it.

2. What Routers forward DHCP requests?

(This is not necessarily a complete list).

Note that in general, these routers probably already had BOOTP forwarding, but lacked the support for the BOOTP broadcast flag (see "broadcast flag" under What are the Gotcha's? above). It is likely that many other routers also support BOOTP forwarding.

Cisco

(from Cisco FAQ) Routers running GSYS version 9.21(4) and 10.0(3) as well as later releases.

Wellfleet/Bay

(from Wellfleet FAQ) DHCP is supported by enabling BOOTP support (with transmission and/or reception as needed). Starting with version 9.00 of their routing software BayRs.

3Com Netbuilder

Version 7.2 software can support DHCP relaying through the use of its generic UDP Helper service. Version 8.0 and later officially supports DHCP.

Xyplex

Version 5.5 of their routing software supports DHCP.

ALANTEC

The switches' "router" function has have been handling BOOTP forwarding since around 1993. Support for the broadcast flag introduced in a maintenance release of 2.5 of their software and is in version 2.6 and later.

IBM 2210

I've confirmed that Version 1 Release 2 has a BOOTP relay agent. I haven't found out anything about support for the broadcast flag.

ACC

Version 7.2 (about 1994) and later support DHCP relaying.

Proteon/Digital

I'm not sure what is the first version that has this support.

Novell MPR

The same as for their server.

IBM 6611

Supports BOOTP forwarding.

3. What Routers include DHCP servers?

DHCP requires disk storage (or some other form of reliable non-volatile storage), making the task of DHCP service more compatible with servers than with dedicated routers. The large-scale routers (i.e., those of Cisco, Bay, Fore) don't and will probably never will have a DHCP server function. But there are a number of types of servers that can be configured to route and serve DHCP. This includes Novell servers and computers running Unix. There are also units designed to handle two or more aspects of your Internet connection, e.g. routing between a LAN and a leased line as well as doing other functions to allow computers on the LAN to reach the Internet (or corporate intranet as the case may be). One example is Farallon's Netopia Internet Router mentioned above under commercial servers.

4. What Routers use DHCP to configure their IP addresses?

The DHCP RFC specifically says that DHCP is not intended for use in configuring routers. The reason is that in maintaining and troubleshooting routers, it is important to know its exact configuration rather than leaving that to be automatically done, and also that you do not want your router's operation to depend upon the working of yet another server. It may be possible to configure some types of more general-purpose computers or servers to get their addresses from DHCP and to act as routers. Also, there are remote access servers, often which are usually not true routers, which use DHCP to acquire addresses to hand out to their clients.

5. What Servers forward DHCP requests?

• Windows NT's 3.51 Service Pack 3 (and 4) includes a BOOTP (& DHCP) relay agent as part of "Multi Protocol Router". 3.51).
• For Novell servers, there are NLMs that forward BOOTP requests, thus DHCP requests. The "BOOTPFWD NLM" is included in NetWare 4.1. You can get this support in NetWare 3.11 and 3.12 also by applying the TCPN01.EXE patch which is located at ftp://ftp.novell.edu/updates/inet/mpr211/tcpn01.exe and on Netwire. Two other such NLMs (possibly old versions of the same) that are available online:
• ftp://netlab2.usu.edu/misc/bootpfd.zip(unsupported Novell software, 1993)
• ftp://netlab2.usu.edu/misc/bootp311.zip(unsupported Novell software, 1991)
• Also for Novell servers, the DHCP server that comes with NetWare/IP 2.2 can be configured to be just a BOOTP/DHCP forwarding agent.
• AIX, through its dhcprd daemon.

1. How do I make a client give up its lease?

File: Vdhcp.386
File Last Modified Date: 02/12/96
File Size: 27,985 bytes
File Version Information: 4.00.951

 

References:

 

Author John Wobus, jmwobus@syr.edu (corrections welcome) Date 6/12/1998

http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html

http://techweb.cmp.com/nc/708/708work1.html

http://info.isoc.org/HMP/PAPER/127/html/paper.html

 

Akihiro Tominaga (tomy@sfc.wide.ad.jp)
Osamu Nakamura (osamu@wide.ad.jp)
Fumio Teraoka (tera@csl.sony.co.jp)
Jun Murai (jun@wide.ad.jp)

 

http://www.bucknell.edu/~droms/dhcp/index.html

 

The DHCP FAQ

Last Modified 9/6/95
Joe Germuska
j-germuska@nwu.edu
ACNS, Northwestern University