Questions

A. General
1. What is DHCP?
2. What is DHCP's purpose?
3. Who Created It? How Was It Created?
4. Can DHCP work with Appletalk or IPX?
5. How is it different than BOOTP or RARP?
6. How is it different than VLANs?
7. What protocol and port does DHCP use?
8. What is an IP address?
9. What is a MAC address?
10. What is a DHCP lease?
11. What is a Client ID?
12. Why shouldn't clients assign IP numbers without the use of a server?
13. Can DHCP support statically defined addresses?
14. How does DHCP and BOOTP handle other subnets?
15. Can a BOOTP client boot from a DHCP server?
16. Can a DHCP client boot from a BOOTP server?
17. Is a DHCP server "supposed to" be able to support a BOOTP client?
18. Is a DHCP client "supposed to" be able to use a BOOTP server?
19. Can a DHCP client or server make a DNS server update the client's DNS entry to
match the client's dynamically assigned address?
20. Can a DHCP server back up another DHCP server?
21. When will the server to server protocol be defined?
22. Is there a DHCP mailing list?
23. In a subnetted environment, how does the DHCP server discover what subnet a
request has come from?
24. If a single LAN has more than one subnet number, how can addresses be served
on subnets other than the primary one?
25. If a physical LAN has more than one logical subnet, how can different groups of
clients be allocated addresses on different subnets?
26. Where is DHCP defined?
27. What other sources of information are available?
28. Can DHCP support remote access?
29. Can a client have a home address and still float?
30. How can I relay DHCP if my router does not support it?
31. How do I migrate my site from BOOTP to DHCP?
32. Can you limit which MAC addresses are allowed to roam?
33. Is there an SNMP MIB for DHCP?
34. What is DHCP Spoofing?
35. How long should a lease be?
36. How can I control which clients get leases from my server?
37. How can I prevent unauthorized laptops from using a network that uses DHCP
for dynamic addressing?
38. What are the Gotcha's?
B. Info on Implementations
1. What features or restrictions can a DHCP server have?
2. What freeware DHCP servers are available?
3. What commercial DHCP servers are available?
 4. What freeware DHCP clients are available?
5. Which vendors of client software currently support DHCP?
6. What are the DHCP plans of major client-software vendors?
7. What Routers forward DHCP requests?
8. What Routers include DHCP servers?
9. What Routers use DHCP to configure their IP addresses?
10. What Servers forward DHCP requests?
11. Which implementations support or require the broadcast flag?
12. What servers support secondary subnet numbers?
13. What servers support RFC-based dynamic DNS update?
14. How can I run Windows 95 without a DHCP server?
15. Do any servers limit the MAC addresses that may roam?
16. What analyzers decode DHCP?
17. What administration tools administer DHCP configurations?
18. How do I make a client give up its lease?
19. What are the Gotcha's specific to various implementations?

Answers

A. General
1. What is DHCP?

DHCP stands for "Dynamic Host Configuration Protocol".

2. What is DHCP's purpose?

DHCP's purpose is to enable individual computers on an IP network to extract

their configurations from a server (the 'DHCP server') or servers, in particular,
servers that have no exact information about the individual computers until they
request the information. The overall purpose of this is to reduce the work
necessary to administer a large IP network. The most significant piece of
information distributed in this manner is the IP address.

3. Can DHCP work with AppleTalk or IPX?

No, it is too tied to IP. Furthermore, they don't need it since they have always
had automated mechanisms for assigning their own network addresses.

4. Who Created It? How Was It Created?

DHCP was created by the Dynamic Host Configuration Working Group of the
Internet Engineering Task Force (IETF; a volunteer organization which defines
protocols for use on the Internet). As such, it's definition is recorded in an
Internet RFC and the Internet Activities Board (IAB) is asserting its status as to
Internet Standardization. As of this writing (June 1998), DHCP is an Internet
Draft Standard Protocol and is Elective. BOOTP is an Internet Draft Standard
Protocol and is recommended. For more information on Internet standardization,
see RFC2300 (May 1998)

5. How is it different than BOOTP or RARP?

 DHCP is based on BOOTP and maintains some backward compatibility. The main
difference is that BOOTP was designed for manual pre-configuration of the host
information in a server database, while DHCP allows for dynamic allocation of
network addresses and configurations to newly attached hosts. Additionally,
DHCP allows for recovery and reallocation of network addresses through a
leasing mechanism.

RARP is a protocol used by Sun and other vendors that allows a computer to find
out its own IP number, which is one of the protocol parameters typically passed
to the client system by DHCP or BOOTP. RARP doesn't support other parameters
and using it, a server can only serve a single LAN. DHCP and BOOTP are
designed so they can be routed.

6. How is it different than VLANs?

DHCP and VLANs, 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
subnet 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 subnet. 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 subnets on a geographical basis, or on separate
networks. VLANs are generally aimed at allowing you to set up subnets
on some basis other than geographical, e.g. instead of putting everyone
in one office on the same subnet, putting each person on a subnet 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.
7. What protocol and port does DHCP use?

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

8. What is an IP address?

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 analogous to your
telephone number in that the telephone number is used by the telephone
network to direct calls to you. 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.

9. What is a MAC address?

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) which uniquely identifes a computer that has 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.

10. What is a DHCP lease?

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.

11. What is a Client ID?

What is termed the Client ID for the purposes of the DHCP protocol is whatever
is used by the protocol to identify the client computer. By default, DHCP
implementations typically employ the client's MAC address for this purpose, but
the DHCP protocol allows other options. Some DHCP implementations have a
setup option to specify the client ID you want. One alternative to the MAC
address is simply a character string of your choice. In any case, in order for
DHCP to function, you must be certain that no other client is using the client ID
you choose, and you must be sure the DHCP server will accept it.

12. Why shouldn't clients assign IP numbers without the use of a server?

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.

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.
 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.
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 subnet to another.
2. 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.

3. How does DHCP and BOOTP handle multiple subnets?

For the situations where there is more than one LAN, each with its own subnet
number, there are two ways. First of all, you can set up a seperate server on
each subnet. Secondly, a feature of some routers known as "BOOTP forwarding"
to forward DHCP or BOOTP requests to a server on another subnet 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 subnet 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".

4. Can a BOOTP client boot from a DHCP server?

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

5. Can a DHCP client boot from a BOOTP server?

Only if the DHCP client were 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.

6. Is a DHCP server "supposed to" be able to support a BOOTP client?

The RFC on such interoperability (1534) is clear: "In summary, a DHCP server:
... MAY support BOOTP clients," (section 2). The word "MAY" indicates such
support, however useful, is left as an option.

A source of confusion on this point is the following statement in section 1.5 of

RFC 1541: "DHCP must provide service to existing BOOTP clients." However, this
statement is one in a list of "general design goals for DHCP", i.e. what the
designers of the DHCP protocol set as their own goals. It is not in a list of
requirements for DHCP servers.

7. Is a DHCP client "supposed to" be able to use a BOOTP server?

 The RFC on such interoperability (1534) is clear: "A DHCP client MAY use a reply
from a BOOTP server if the configuration returned from the BOOTP server is
acceptable to the DHCP client." (section 3). The word "MAY" indicates such
support, however useful, is left as an option.

8. Can a DHCP client or server make a DNS server update the client's DNS entry to match the
client's dynamically assigned address?

RFCs 2136 and 2137 indicate a way in which DNS entries can be updated
dynamically. Using this requires a DNS server that supports this feature and a
DHCP server that makes use of it. The RFCs are very recent (as of 5/97) and
implementations are few. In the mean time, there are DNS and DHCP servers
that accomplish this through proprietary means.

9. Can a DHCP server back up another DHCP server?

You can have two or more servers handing out leases for different addresses. If
each has a dynamic pool accessible to the same clients, then even if one server
is down, one of those clients can lease an address from the other server.

However, without communication between the two servers to share their

information on current leases, when one server is down, any client with a lease
from it will not be able to renew their lease with the other server. Such
communication is the purpose of the "server to server protocol" (see next
question). It is possible that some server vendors have addressed this issue with
their own proprietary server-to-server communication.

10. When will the server to server protocol be defined?

The DHC WG of the IETF is actively investigating the issues in inter-server

communication. The protocol should be defined "soon".

11. Is there a DHCP mailing list?

There are several:

List Purpose
---- -------
dhcp-v4@bucknell.edu General discussion: a good list for
server administrators.
dhcp-bake@bucknell.edu DHCP bakeoffs
dhcp-impl@bucknell.edu Implementations
dhcp-serve@bucknell.edu Server to server protocol
dhcp-dns@bucknell.edu DNS-DHCP issues
dhcp-v6@bucknell.edu DHCP for IPv6

The lists are run by listserv@bucknell.edu which can be used to subscribe and
sign off. Archives for the dhcp-v4 list (which used to be called the host-conf list)
are stored at ftp://ftp.bucknell.edu/pub/dhcp/.

12. In a subnetted environment, how does the DHCP server discover what subnet 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 subnet 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, and
technically speaking, the latter phrase is correct.

13. If a single LAN has more than one subnet number, how can addresses be served on
subnets other than the primary one?

A single LAN might have more than one subnet number applicable to the same
set of ports (broadcast domain). Typically, one subnet is designated as primary,
the others as secondary. A site may find it necessary to support addresses on
more than one subnet 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 four
cases a server might have to handle:

Dynamic allocation supported on secondary subnet numbers on the LAN to

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

The other two cases are the same capabilities during manual allocation. It is
possible that a particular server-implementation can handle some of these cases,
but not all of them. See section below listing the capabilities of some servers.

14. If a physical LAN has more than one logical subnet, how can different groups of clients be
allocated addresses on different subnets?

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.

15. Where is DHCP defined?

In Internet RFCs.

16. Can DHCP support remote access?

PPP has its own non-DHCP way in which communications servers can hand
clients an IP address called IPCP (IP Control Protocol) but doesn't have the same
flexibility as DHCP or BOOTP in handing out other parameters. Such a
communications server may support the use of DHCP to acquire the IP addresses
it gives out. This is sometimes called doing DHCP by proxy for the client. I know
that Windows NT's remote access support does this.

A feature of DHCP under development (DHCPinform) is a method by which a

DHCP server can supply parameters to a client that already has an IP number.
 With this, a PPP client could get its IP number using IPCP, then get the rest of its
parameters using this feature of DHCP.

SLIP has no standard way in which a server can hand a client an IP address, but
many communications servers support non-standard ways of doing this that can
be utilized by scripts, etc. Thus, like communications servers supporting PPP,
such communications servers could also support the use of DHCP to acquire the
IP addressees to give out.

The DHCP protocol is capable of allocating an IP address to a device without an

IEEE-style MAC address, such as a computer attached through SLIP or PPP, but
to do so, it makes use of a feature which may or may not be supported by the
DHCP server: the ability of the server to use something other than the MAC
address to identify the client. Communications servers that acquire IP numbers
for their clients via DHCP run into the same roadblock in that they have just one
MAC address, but need to acquire more than one IP address. One way such a
communications server can get around this problem is through the use of a set
of unique pseudo-MAC addresses for the purposes of its communications with
the DHCP server. Another way (used by Shiva) is to use a different "client ID
type" for your hardware address. Client ID type 1 means you're using MAC
addresses. However, client ID type 0 means an ASCII string.

17. Can a client have a home address and still float?

There is nothing in the protocol to keep a client that already has a leased or
permanent IP number from getting a(nother) lease on a temporary basis on
another subnet (i.e., for that laptop which is almost always in one office, but
occasionally is plugged in in a conference room or class room). Thus it is left to
the server implementation to support such a feature. I've heard that Microsoft's
NT-based server can do it.

18. How can I relay DHCP if my router does not support it?

A server on a net(subnet) can relay DHCP or BOOTP for that net. Microsoft has
software to make Windows NT do this.

19. How do I migrate my site from BOOTP to DHCP?

I don't have an answer for this, but will offer a little discussion. The answer
depends a lot on what BOOTP server you are using and how you are maintaining
it. If you depend heavily on BOOTP server software to support your existing
clients, then the demand to support clients that support DHCP but not BOOTP
presents you with problems. In general, you are faced with the choice:

Find a server that is administered like your BOOTP server only that also
serves DHCP. For example, one popular BOOTP server, the CMU server, has
been patched so that it will answer DHCP queries.
Run both a DHCP and a BOOTP server. It would be good if I could find out
the gotcha's of such a setup.
Adapt your site's administration to one of the available DHCP/BOOTP
servers.
Handle the non-BOOTP clients specially, e.g. turn off DHCP and configure
them statically: not a good solution, but certainly one that can be done to
handle the first few non-BOOTP clients at your site.
20. Can you limit which MAC addresses are allowed to roam?
 Sites may choose to require central pre-configuration for all computers that will
be able to acquire a dynamic address. A DHCP server could be designed to
implement such a requirement, presumably as an option to the server
administrator. See section below on servers that implement this.

21. Is there an SNMP MIB for DHCP?

There is no standard MIB; creating one is on the list of possible activities of the
DHCP working group. It is possible that some servers implement private MIBs.

22. What is DHCP Spoofing?

Ascend Pipeline ISDN routers (which attach Ethernets to ISDN lines) incorporate
a feature that Ascend calls "DHCP spoofing" which is essentially a tiny server
implementation that hands an IP address to a connecting Windows 95 computer,
with the intention of giving it an IP number during its connection process.

23. How long should a lease be?

I've asked sites about this and have heard answers ranging from 15 minutes to a
year. Most administrators will say 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 propogate.

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 suggest a 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 work-day 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
suffice.

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

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 apparently Microsoft's default, thus 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 that students can keep their IP address over the summer hiatus. I believe
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.

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

There is no ideal answer: you have to give something up or do some extra work.

 You can put all your clients on a subnet of your own along with your own
DHCP server.
 You can use manual allocation.
 Perhaps you can find DHCP server software that allows you to list which
MAC addresses the server will accept. DHCP servers that support roaming
machines may be adapted to such use.
 You can use the user class option assuming your clients and server
support it: it will require you to configure each of your clients with a user
 class name. You still depend upon the other clients to respect your
wishes.
2. How can I prevent unauthorized laptops from using a network that uses DHCP for dynamic
addressing?

This would have to be done using a mechanism other than DHCP. DHCP does not
prevent other clients from using the addresses it is set to hand out nor can it
distinguish between a computer's permanent MAC address and one set by the
computer's user. DHCP can impose no restrictions on what IP address can use a
particular port nor control the IP address used by any client.

3. What are the Gotcha's?

 A malicious 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.

Note that BOOTP has the same vulnerabilities.

 The "broadcast flag": DHCP includes a way in which client

implementations unable to receive a packet with a specific IP address can
ask the server or relay agent to use the broadcast IP address in the
replies (a "flag" set by the client in the requests). The definition of DHCP
states that implementations "should" honor this flag, but it doesn't say
they "must". Some Microsoft TCP/IP implementations used this flag,
which meant in practical terms, relay agents and servers had to
implement it. A number of BOOTP-relay-agent implementations (e.g. in
routers) handled DHCP just fine except for the need for this feature, thus
they announced new versions stated to handle DHCP.
 Some of the virtual LAN schemes, i.e., those that use the packet's IP
number to decide which "virtual LAN" a client-computer is on for the
purposes of TCP/IP, don't work when using DHCP to dynamically assign
addresses. DHCP servers and relay agents use their knowledge of what
LAN the client-station is on to select the subnet number for the client-
station's new IP address whereas such switches use the subnet number
sent by the client-station to decide which (virtual) LAN to put the station
on.
 Routers are sometimes configured so that one LAN on one port has
multiple network (or subnet) numbers. When the router is relaying
requests from such a LAN to the DHCP server, it must pass along as IP
number that is associated with one of the network (or subnet) numbers.
The only way the DHCP server can allocate addresses on one of the LAN's
other network (or subnet) numbers is if the DHCP server is specifically
written to have a feature to handle such cases, and it has a configuration
describing the situation.
  The knowledge that a particular IP number is associated with a particular
node is often used for various functions. Examples are: for security
purposes, for network management, and even for identifying resources.
Furthermore, if the DNS's names are going to identify IP numbers, the
numbers, the IP numbers have to be stable. Dynamic configuration of the
IP numbers undercuts such methods. For this reason, some sites try to
keep the continued use of dynamically allocatable IP numbers to a
minimum.
 With two or more servers serving a LAN, clients that are moved around
(e.g. mobile clients) can end up with redundant leases. Consider a home
site with two DHCP servers, a remote site with DHCP services, and a
mobile client. The client first connects to the home site and receives an
address from one of the two serves. He/she then travels to the remote
site (without releasing the lease at the home site) and attempts to use
the acquired address. It is of course NAK'ed and the client receives an
address appropriate for the remote site. The client then returns home and
tries to use the address from the remote site. It is NAK'ed but now the
client broadcasts a DHCPDISCOVER to get a address. The server that
holds the previous lease will offer the address back to the client but there
is no guarantee that the client will accept that address; consequently, it is
possible for the client to acquire an address on the other server and
therefore have two leases within the site. The problem can be solved by
using only one server per subnet/site and can be mitigated by short lease
lengths. But in a very mobile environment, it is possible for these
transient clients to consume more than their fair share of addresses.
 If departments, offices, or individuals run DHCP servers with their own
small address pools on LANs shared by other departments, offices, or
individuals, they can find that their addresses are being used by anyone
on the LAN that happens to set their IP configuration to use DHCP.
 An easy mistake to make in setting up a DHCP server is to fail to set all
the necessary global parameters. This can result in some functions
working while others are not, or functions working when the client is set
up manually, but failing to work when set to use DHCP.
 Long leases can be disadvantageous in cases where you need to change a
configuration parameter or withdraw an address from use. The length of
the lease can mean the difference between having to go to every affected
client and rebooting it, or merely waiting a certain amount of time for the
leases to be renewed. (Note: one workaround is to fool with the client
computer's clock).

B. Info on Implementations

4. What features or restrictions can a DHCP server have?

While the DHCP server protocol is designed to support dynamic management of

IP addresses, there is nothing to stop someone from implementing a server that
uses the DHCP protocol, but does not provide that kind of support. In particular,
the maintainer of a BOOTP server-implementation might find it helpful to
enhance their BOOTP server to allow DHCP clients that cannot speak "BOOTP" to
retrieve statically defined addresses via DHCP. The following terminology has
become common to describe three kinds of IP address allocation/management.
These are independent "features": a particular server can offer or not offer any
of them:
  Manual allocation: the server's administrator creates a configuration for
the server that includes the MAC address and IP address of each DHCP
client that will be able to get an address: functionally equivalent to
BOOTP though the protocol is incompatible.
 Automatic allocation: the server's administrator creates a configuration
for the server that includes only IP addresses, which it gives out to
clients. An IP address, once associated with a MAC address, is
permanently associated with it until the server's administrator intervenes.
 Dynamic allocation: like automatic allocation except that the server will
track leases and give IP addresses whose lease has expired to other
DHCP clients.

Other features which a DHCP server may or may not have:

 Support for BOOTP clients.

 Support for the broadcast bit.
 Administrator-settable lease times.
 Administrator-settable lease times on manually allocated addresses.
 Ability to limit what MAC addresses will be served with dynamic
addresses.
 Allows administrator to configure additional DHCP option-types.
 Interaction with a DNS server. Note that there are a number of
interactions that one might support and that a standard set & method is
in the works.
 Interaction with some other type of name server, e.g. NIS.
 Allows manual allocation of two or more alternative IP numbers to a
single MAC address, whose use depends upon the gateway address
through which the request is relayed.
 Ability to define the pool/pools of addresses that can be allocated
dynamically. This is pretty obvious, though someone might have a server
that forces the pool to be a whole subnet or network. Ideally, the server
does not force such a pool to consist of contiguous IP addresses.
 Ability to associate two or more dynamic address pools on separate IP
networks (or subnets) with a single gateway address. This is the basic
support for "secondary nets", e.g. a router that is acting as a BOOTP
relay for an interface which has addresses for more than one IP network
or subnet.
 Ability to configure groups of clients based upon client-supplied user
and/or vendor class. Note: this is a feature that might be used to assign
different client-groups on the same physical LAN to different logical
subnets.
 Administrator-settable T1/T2 lengths.
 Interaction with another DHCP server. Note that there are a number of
interactions that one might support and that a standard set & method is
in the works.
 Use of PING (ICMP Echo Request) to check an address prior to
dynamically allocating it.
 Server grace period on lease times.
 Ability to force client(s) to get a new address rather than renew.

Following are some features related not to the functions that the server is
capable of carrying out, but to the way that it is administered.

 Ability to import files listing manually allocated addresses (as opposed to

a system which requires you to type the entire configuration into its own
 input utility). Even better is the ability to make the server do this via a
command that can be used in a script, rdist, rsh, etc.
 Graphical administration.
 Central administration of multiple servers.
 Ability to import data in the format of legacy configurations, e.g.
/etc/bootptab as used by the CMU BOOTP daemon.
 Ability to make changes while the server is running and leases are being
tracked, i.e. add or take away addressees from a pool, modify
parameters.
 Ability to make global modifications to parameters, i.e., that apply to all
entries; or ability to make modifications to groups of ports or pools.
 Maintenance of a lease audit trail, i.e. a log of the leases granted.

5. 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
supports it and does not support BOOTP. I heard a rumor that BOOTP support will be
added.
Novell LAN Workplace for DOS
For supporting DOS/Windows 3.1, Client32 for DOS/Windows, due in June 1996, will
provide the TCP/IP stack functions and will support DHCP and BOOTP. For Windows 95
and Windows NT, the native stack will be used so that DHCP is supported.
IBM OS/2 Warp
supports it.

6. 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.

7. 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
an 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.
8. 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.

9. 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.com/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.
 Warp Server Version 4.
10. Which implementations support or require the broadcast flag?

The broadcast flag is an optional element of DHCP, but a client which sets it
works only with a server or relay that supports it.

 Clients

Microsoft Windows NT
DHCP client support added with version 3.5 sets the broadcast flag. Version 3.51 and
later no longer set it. The exception is in the remote access support: it sets the flag
when it uses DHCP to acquire addresses to hand out to its PPP clients.
tcp/ip-32 for Microsoft Windows for Workgroups (WFW)
Version 3.11a sets it, but version 3.11B doesn't.
Microsoft Windows 95
Does not set the broadcast flag.

11. What servers support secondary subnet numbers?

(These are not complete lists) The following servers can handle dynamic
allocation on secondary subnet numbers:

 IPTrack version 2.0

 ISC
 JOIN
  SGI's DHCP Server under IRIX 6.2
 Cisco (previously TGV)
 NetID
 Microsoft Windows NT 4.0 (since service pack 2)
 Sonic
 QDHCP
 ipLease
 IBM Warp Server Version 4
 IBM AIX

The following can serve manually allocated addresses on secondary subnet

numbers:

 IPTrack version 2.0

 ISC
 JOIN
 QDHCP

The following cannot support secondary subnet numbers:

 Microsoft Windows NT 3.51 and 4.0 (through RC1)

 WIDE
 Sonic DHCP Server
12. What servers support RFC-based dynamic DNS update?

The following DHCP servers include the ability to make use of the RFC
2136/2137 DNS feature to make dynamic updates to the DNS. To make use of
this ability, you need a DNS server that supports this feature. A likely use is to
create temporary DNS records that associate a fully qualified DNS name derived
from the client's netbios name with the client's leased IP number. Another use
might be to associate DNS names with MAC addresses. These products might
support one or both of these uses.

 American Internet Corp Net Registrar

 QDHCP
 IBM's Warp Server (version 4 and after)
 IBM's AIX server (version 4.1 and after)
13. How can I run Windows 95 without a DHCP server?

Not really a DHCP question, but it has been asked a lot, particularly by sites for
which changing from BOOTP represents a lot of work. Some choices:

 Use no server at all for the Windows 95 clients: set the addresses in each
client's setup.
 Install a non-Microsoft TCP/IP stack for Windows 95 that supports BOOTP.
 Switch from your current BOOTP server to one that supports both BOOTP
and DHCP.
 The 'billgPC' program uses BOOTP (instead of DHCP) to configure
Windows 95's native IP stack: http://www.panix.com/~perin/ (note: it
also works with Windows NT).

A Document that addresses this question is the Windows 95tm Networking FAQ,
http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
14. Do any servers limit the MAC addresses that may roam?
 IBM's AIX and OS/2 WARP DHCP servers.
 ISC.
15. What analyzers decode DHCP?
 Release 5.0 of Network General Corporation's Sniffer software.
16. How do I make a client give up its lease?

This is a general question, but the answer is of necessity specific to the client-
implementation. Naturally, one way to avoid the problem is to keep leases short
enough that you are not obliged to do this.

 One method mentioned is to temporarily change the clock on the client.

 For a Win95 client, the winipcfg.exe program can do it.
17. What are the Gotcha's specific to various implementations?

In many cases, new releases have solved the problems that have been identified
with various DHCP implementations.

 An extra server feature is required to handle the allocation of addresses

on the secondary IP addresses associated with a router port. You may
find out after the fact that you have such secondary addresses
 There have been servers that are inflexible as to the list of configuration
parameters they were able to serve. If your client requires certain
parameters, you could find such a server unusable.
 I hate to cast wide suspicions, but I've heard occasional word on client
DHCP implementations that do not implement the entire protocol. Doing
so requires that the software module be able to wake up again after a
specified period of time and "renew the lease", i.e., ask to continue using
the IP number. This is at least one feature of DHCP that is very hard to
implement in some simpler systems.
 A specific complaint about Microsoft's Windows 95 dhcp client: it times
out its requests much more quickly than the times specified by RFC1541
section 4.1. Among the circumstances that can turn this into a practical
problem are the latencies due to relay agents and a server's use of ICMP
echo to doublecheck the address. While it works with Microsoft's own NT-
based server, the problem prevents interoperation with some other DHCP
servers under some conditions. Microsoft is rumored to have developed
an updater named VDHCPUPD.EXE to patch this problem, once available
through the following patch:
 File: Vdhcp.386
 File Last Modified Date: 02/12/96
 File Size: 27,985 bytes
 File Version Information: 4.00.951

It consists of 2 files, vdhcpupd.exe and vdhcpupd.txt. I've since been told

that a newer version is 4.00.954. I've also been told that the exe file is
on the net at http://www.halcyon.com/cerelli/software/vdhcpupd.exe

 There are a number of issues regarding the patched bootp servers. These
have been reported to re DD2.4.3:
 'When run from inetd, I had problems with "Could not bind port"
and DHCP request failure. I don't know why, and the problem went
away when bootpd is run as a daemon.'
 'Unless you set "dl" to some value in the bootptab file, the DHCP
lease time, renewal time and prebinding time will be rubbish,
 which will cause occasional renewal problems.' One symptom you
might see is Microsoft DHCP implementations using 5-minute
leases, which is their default. Other implementations may not run
at all.
 Early Microsoft DHCP client implementations required the broadcast bit.
Current ones do not.
 I have heard a vague complaints about the Microsoft implementations of
DHCP: that it does not follow the standards. I could use details.
 Early Apple Open Transport implementations did not always fill out
packets to BOOTP's 300-byte minimum, thus BOOTP forwarding agents
that follow the BOOTP RFC and discard such packets end up discarding
such DHCP packets, causing some of the functions to fail. Open Transport
1.1 fixes this.
 Pre 1.1 versions of Open Transport experienced interoperability problems
with the Microsoft NT DHCP server.
 The very first announced release of Carnegie Mellon's server, dhcp-3.3.6,
circa March 1996 has shown signs of needing to be shaken out to be
more easily compiled outside of its development environment.
 Windows NT server v3.51 allows the administrator to specify addresses
within its assignment range to be excluded, but does not always exclude
them.
 Report: Novell's NetwareIP 2.2 server refuses to hand out dynamic bootp
assignments to hosts mentioned in the local /etc/hosts file, even if
configured to do so.
 I've heard a report that some combinations of versions of Unix & the ISC
server will transmit packets to the subnet broadcast address rather than
the default broadcast address (255.255.255.255), which impedes
interoperability with some clients.
 Windows 95 DHCP client answers pings from an IP address even after the
the client's lease has expired. Thus a server that uses ping to check to
see that an IP number is unused before reassigning it may find that it is
still in use.
 Windows 95 DHCP client cannot handle a lease renewal offered by a
different server.
 Some clients have no way to configure a class option, which can be a
showstopper if you need to use the class option to help decide what pool
of addresses the client uses.
 I've heard reports that Windows 95, or at least some versions will use an
address after the lease has expired under some circumstances, even
when renewal requests have been turned down. With properly behaving
clients, an IP administrator can safely make the following statement: "As
long as all the clients are set to get their addresses through DHCP, I can
tell which addresses are not being used by the clients simply by checking
the server to see which IP addresses have no outstanding leases." The
reports suggest that Windows 95 implementations won't allow this
statement to be assumed.
Contents

• 1 Introduction
• 2 Overview
• 3 Extent of DHCP usage
• 4 IP address allocation
• 5 DHCP and firewalls
o 5.1 Example in ipfw firewall
o 5.2 Example in Cisco IOS Extended ACL
• 6 Technical details
o 6.1 DHCP discovery
o 6.2 DHCP offers
o 6.3 DHCP requests
o 6.4 DHCP acknowledgement
o 6.5 DHCP selection
o 6.6 DHCP information
o 6.7 DHCP releasing
o 6.8 Client configuration parameters
• 7 See also

• 8 External links

[edit] Introduction

DHCP is a protocol used by networked computers (clients) to obtain unique IP addresses, and
other parameters such as default router, subnet mask, and IP addresses for DNS servers from
a DHCP server. This protocol is used when computers are added to a network because these
settings are necessary for the host to participate in the network. This setting is periodically
refreshed (it expires, meaning the client must obtain another assignment) with typical intervals
ranging from one hour to several months, and can, if desired, be set to infinite (never expire).
The length of time the address is available to the device it was assigned to is called a lease,
and is determined by the server.

The DHCP server ensures that all IP addresses are unique, that is, no IP address is assigned to
a second client while the first client's assignment is valid (its lease has not expired). Thus IP
address pool management is done by the server and not by a human network administrator.

DHCP emerged as a standard protocol in October 1993. As of 2006, RFC 2131 provides the
latest ([dated March 1997]) DHCP definition. DHCP functionally became a successor to the
older BOOTP protocol, whose leases were given for infinite time and did not support options.
Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP.

The latest non-standard of the protocol, describing DHCPv6 (DHCP in an IPv6 environment),
appeared in July 2003 as RFC 3315.

[edit] Overview

The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses,
subnet masks, default routers, and other IP parameters. The assignment usually occurs when
the DHCP configured machine boots up or regains connectivity to the network. The DHCP client
sends out a query requesting a response from a DHCP server on the locally attached network.
The query is typically initiated immediately after booting up and before the client initiates any
IP based communication with other hosts. The DHCP server then replies to the client with its
assigned IP address, subnet mask, DNS server and default gateway information.

The assignment of the IP address usually expires after a predetermined period of time, at
which point the DHCP client and server renegotiate a new IP address from the server's
predefined pool of addresses. Configuring firewall rules to accommodate access from machines
who receive their IP addresses via DHCP is therefore more difficult because the remote IP
address will vary from time to time. Administrators must usually allow access to the entire
remote DHCP subnet for a particular TCP/UDP port.

Most home routers and firewalls are configured in the factory to be DHCP servers for a home
network. An alternative to a home router is to use a computer as a DHCP server. ISPs generally
use DHCP to assign clients individual IP addresses.

DHCP is a broadcast-based protocol. As with other types of broadcast traffic, it does not cross
a router unless specifically configured to do so. Users who desire this capability must configure
their routers to pass DHCP traffic across UDP ports 67 and 68.

[edit] Extent of DHCP usage

Most cable internet providers use DHCP to allocate IP addresses.

In the UK many broad-band ISP networks use DHCP, but xDSL providers make extensive use of
"infinite lease", which amounts to assigning semi-static IPs.

In addition, many routers and other gateway devices provide DHCP support for networks
running many computers being assigned private IP addresses.

Office networks also use DHCP, in particular when workers make extensive use of laptops
which link directly to the in-house network only occasionally .

Network routers and often multilayer switches employ a DHCP relay agent, which relays DHCP
"Discover" broadcasts from a LAN which does not include a DHCP server to a network which
does have one. These devices may be sometimes configured to append information about port
from which DHCP request originates (also known as option 82). One example of such a relay
agent is the UDP Helper Address command employed by Cisco routers.

[edit] IP address allocation

Depending on implementation, the DHCP server has three methods of allocating IP-addresses:

• manual allocation, where the DHCP server performs the allocation based on a table with
MAC address - IP address pairs manually filled by the server administrator. Only
requesting clients with a MAC address listed in this table get the IP address according to
the table.
• automatic allocation, where the DHCP server permanently assigns to a requesting client
a free IP-address from a range given by the administrator.
• dynamic allocation, the only method which provides dynamic re-use of IP addresses. A
network administrator assigns a range of IP addresses to DHCP, and each client
computer on the LAN has its TCP/IP software configured to request an IP address from
the DHCP server when that client computer's network interface card starts up. The
request-and-grant process uses a lease concept with a controllable time period. This
eases the network installation procedure on the client computer side considerably.
This decision remains transparent to clients.

Some DHCP server implementations can update the DNS name associated with the client hosts
to reflect the new IP address. They make use of the DNS update protocol established with RFC
2136.

[edit] DHCP and firewalls

Firewalls usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server
protocol describes several cases when packets must have the source address of 0x00000000
or the destination address of 0xffffffff. Anti-spoofing policy rules and tight inclusive firewalls
often stop such packets. Multi-homed DHCP servers require special consideration and further
complicate configuration.

To allow DHCP, network administrators need to allow several types of packets through the
server-side firewall. All DHCP packets travel as UDP datagrams; all client-sent packets have
source port 68 and destination port 67; all server-sent packets have source port 67 and
destination port 68. For example, a server-side firewall should allow the following types of
packets:

• Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip

• Incoming packets from any address to 255.255.255.255
• Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255

where dhcp-ip represents any address configured on a DHCP server host and dhcp-pool stands
for the pool from which a DHCP server assigns addresses to clients

[edit] Example in ipfw firewall

To give an idea of how a configuration would look in production, the following rules for a
server-side ipfirewall to allow DHCP traffic through. Dhcpd operates on interface rl0 and
assigns addresses from 192.168.0.0/24 :

pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0

pass udp from any 68 to 255.255.255.255 67 in recv rl0
pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0

[edit] Example in Cisco IOS Extended ACL

The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is
applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.

10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps

20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps
30 permit udp any eq bootpc host 255.255.255.255 eq bootps

[edit] Technical details

DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and
68/udp for the client side.

DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer,
IP lease selection, and IP lease acknowledgement.
[edit] DHCP discovery

The client broadcasts on the local physical subnet to find available servers. Network
administrators can configure a local router to forward DHCP packets to a DHCP server on a
different subnet. This client-implementation creates a UDP packet with the broadcast
destination of 255.255.255.255 or subnet broadcast address and also requests its last-known
IP address (in the example below, 192.168.1.100) although the server may ignore this optional
parameter....

[edit] DHCP offers

When a DHCP server receives an IP lease request from a client, it extends an IP lease offer.
This is done by reserving an IP address for the client and broadcasting a DHCPOFFER message
across the network. This message contains the client's MAC address, followed by the IP
address that the server is offering, the subnet mask, the lease duration, and the IP address of
the DHCP server making the offer.

The server determines the configuration, based on the client's hardware address as specified in
the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.

[edit] DHCP requests

Whenever a computer comes on line, it checks to see if it currently has an IP address leased. If
it does not, it requests a lease from a DHCP server. Because the client computer does not know
the address of a DHCP server, it uses 0.0.0.0 as its own IP address and 255.255.255.255 as
the destination address. Doing so allows the client to broadcast a DHCPDISCOVER message
across the network. Such a message consists of the client computer's Media Access Control
(MAC) address (the hardware address built into the network card) and its NetBIOS name.

The client selects a configuration out of the DHCP "Offer" packets it has received and
broadcasts it on the local subnet. Again, this client requests the 192.168.1.100 address that
the server specified. In case the client has received multiple offers it specifies the server from
which it has accepted the offer.

[edit] DHCP acknowledgement

When the DHCP server receives the DHCPREQUEST message from the client, it initiates the
final phase of the configuration process. This acknowledgement phase involves sending a
DHCPACK packet to the client. This packet includes the lease duration and any other
configuration information that the client might have requested. At this point, the TCP/IP
configuration process is complete.

The server acknowledges the request and sends the acknowledgement to the client. The
system as a whole expects the client to configure its network interface with the supplied
options.

[edit] DHCP selection

When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has
accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP
address of the server that made the offer. When the other DHCP servers receive this message,
they withdraw any offers that they might have made to the client. They then return the
address that they had reserved for the client back to the pool of valid addresses that they can
offer to another computer. Any number of DHCP servers can respond to an IP lease request,
but the client can only accept one offer per network interface card.
[edit] DHCP information

The client sends a request to the DHCP server: either to request more information than the
server sent with the original DHCPACK; or to repeat data for a particular application - for
example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do
not cause the DHCP server to refresh the IP expiry time in its database.

[edit] DHCP releasing

The client sends a request to the DHCP server to release the DHCP and the client unconfigures
its IP address. As clients usually do not know when users may unplug them from the network,
the protocol does not define the sending of DHCP Release as mandatory.

[edit] Client configuration parameters

A DHCP server can provide optional configuration parameters to the client. RFC 2132 defines
the available DHCP options, which are summarized here.