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.
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 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:
1. Dynamic allocation supported on secondary subnet numbers on
the LAN to which the server is attached.
2. 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.
RFC 2131
R. Droms, "Dynamic Host Configuration Protocol", 3/97. Supersedes RFC
1541 and RFC 1531. [Note that some of the references in this FAQ are to RFC
1541: I'll update them when I get a chance. -- Author]
RFC 1534
R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993.
RFC 2132
S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions",
3/97. Supersedes RFC 1533.
Some websites with copies of RFCs:
http://info.internet.isi.edu/1s/in-notes/rfc/
http://www.cis.ohio-state.edu/hypertext/information/rfc.html
http://www.pmg.lcs.mit.edu/rfc.html
16.What other sources of information are available?
See the dhcp-v4 mailing list mentioned above as well as its archives.
DHCP - Dynamic Host Configuration Protocol
http://www.eg.bucknell.edu/~droms/dhcp/
Problems and Solutions of DHCP: Experiences with DHCP
implementation and Operation
A. Tominaga, O. Nakamura, F. Teraoka, J.
Murai. http://info.isoc.org/HMP/PAPER/127/html/paper.html
DHCP Resources
Alan Dobkin. http://NWS.CC.Emory.Edu/WebStaff/Alan/Net-
Man/Computing/DHCP/
DHCP Reading Room
Eric Hall. http://www.ehsco.com/reading/dhcp.html
Internet Drafts
Internet drafts are works in progress intended to update the current RFCs or
specify additional functionality, and sometimes there is one or more draft
related to DHCP. All Internet Drafts are available from various sites: the US
East Cost site is ftp://ds.internic.net/internet-drafts/; a web site
is http://ds.internic.net/ds/dsintdrafts.html. The DHCP-related drafts currently
have filenames of the form "draft-ietf-dhc-SOMETHING". These DHCP-
related drafts are also stored at ftp://ftp.bucknell.edu/pub/dhcp/, and are
available through http://www.eg.bucknell.edu/~droms/dhcp/. I cannot be more
specific about the documents because they are by their nature temporary.
"DHCP Clients: Do They Really Work?"
Eric Hall. Network Computing, Vol. 7, No. 7, May 1, 1996, pp. 114-120.
Reviews DHCP-client-function of some popular Windows IP
stacks. http://www.ehsco.com/reading/19960515ncw2.html
"The Heaven And Hell Of DHCP Servers"
Eric Hall. Network Computing, Vol. 7, No. 8, May 15, 1996, pp. 118-121.
Reviews DHCP servers.http://www.ehsco.com/reading/19960515ncw1.html
17.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.
18.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.
19.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.
20.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:
1. 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.
2. Run both a DHCP and a BOOTP server. It would be good if I
could find out the gotcha's of such a setup.
3. Adapt your site's administration to one of the available
DHCP/BOOTP servers.
4. 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.
21.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.
22.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.
23.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.
24.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.
25.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
1. 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.
2. What freeware DHCP servers are available?
(This is not necessarily a complete list)
950415 Bootp server:
Bootp 2.4.3 (not DHCP, but with the "DHCP patches" mentioned
below, can handle DHCP requests)
ftp://ftp.mc.com/pub/bootp-2.4.3.tar.Z
950425 Bootp server version 2.4.3 with "samba" DHCP patches
(does manual allocation of IP addresses)
http://www.sghms.ac.uk/~mpreston/bootp_dhcp.tar.Z
(within http://www.sghms.ac.uk/~mpreston/tools.htm)
950706 "samba" DHCP patches for bootp server:
(does manual allocation of IP addresses)
ftp://nimbus.anu.edu.au:/pub/tridge/samba/contributed/DHCP.patch
(note: I've heard that the patched server will crash if it
receives
one particular optional packet, the DHCP Release packet)
950711 Patched bootp server supporting DHCP-based "automatic"
allocation:
(gives addresses dynamically, but never takes them away)
ftp://ftp.ntplx.net/pub/networking/bootp/bootp-DD2.4.3.tar.gz
951219 BOOTP server and patches for DHCP
ftp://africa.geomic.uni-oldenburg.de/pub/people/joey/dhcp/bootpd/
960112 OS/2 port of BOOTP server with patches for manual DHCP
support
ftp://ftp.leo.org/pub/comp/os/os2/tcpip/systools/bootpd-243-
dhcp.zip
960130 Rose-Hulman Institute of Technology "Mondo-DB" LAN
administration
project: modified DHCP server planned
http://www.rose-hulman.edu/~allard/Mondo-DB/index.html
950630 WIDE Project:
mailto:tomy@sfc.wide.ad.jp
WIDE Project
Keio Univ.
Japan
ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.2.1.tar.gz
Check Archie for dhcp-1.2.1 because lots of sites distribute it.
Beta version:
ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.3beta.tar.gz
960312 Carnegie Mellon University DHCP/BOOTP server (SunOS, dhcp-
3.3.7)
 ftp://ftp.net.cmu.edu/pub/dhcp/dhcp-3.3.7.tar.gz
961104 Princeton patches to CMU dhcpd 3.7.7.
http://www.princeton.edu/~irwin/dhcpd.html
971204 Internet Software Consortium (ISC) DHCP/BOOTP Server
http://www.isc.org/dhcp.html

3. What commercial DHCP servers are available?

(This is not necessarily a complete list)
951010 Wollongong: included in next release of PathWay for
OpenVMS which is in
beta
951219 Puzzle Systems: WEBserv (NLM(s) that do DHCP, BOOTP, HTTP,
and FTP)
mailto:info@puzzle.com
http://www.puzzle.com/
951220 Process Software: server for OpenVMS included in TCPware
for OpenVMS
http://www.process.com/
960130 Digital: RoamAbout Mobile IP Client/Server Network
Software V2.0
http://www.digital.com/info/Customer-
Update/940620001.txt.html
960312 Nevod Inc. Proxy IP/DHCP Server (PIP) Beta-1.0
http://www.nevod.com/pip/index.html
960327 Xedia: IP/Assist 1.0 feature for their switches includes
DHCP service.
http://www.xedia.com/
960420 Competitive Automation's JOIN (415-321-4006): SunOS4.x,
Solaris2.x,
Digital Unix 3.2, 4.x, HP-UX 9 & 10 DHCP/BOOTP servers.
http://www.join.com/
960514 SunSoft: Solstice SolarNet PC-Admin 1.5 includes a
DHCP/BOOTP server.
http://www.sun.com/solstice/Networking-products/PC-
Admin.html
960514 Microsoft: DHCP server included in Windows NT Server 3.51
http://www.microsoft.com/NTServer/
http://www.microsoft.com/BackOffice/techbriefs/tech1000.htm
ftp://ftp.microsoft.com/bussys/winnt/winnt-
docs/papers/tcpipimp.doc
960514 ON Technology: IPTrack 1.0 is a Novell Server-based
DHCP/BOOTP server (NLM)
http://www.on.com/on/onprods/iptrack.html/
960514 FTP Software: OnNet Server 2.0 (Services OnNet Product)
http://www.ftp.com/mkt_info/services.html
960531 Cisco: server in development.
http://www.cisco.com/
960620 Farallon: a DHCP server is built into its Netopia Internet
Router
http://www.farallon.com/
960716 Weird Solutions: BOOTP Server NT supports both BOOTP and
statically
allocated DHCP.
http://www.mhi.se/
960808 Novell: NetWare/IP 2.2 (free upgrade to NetWare servers)
 includes a DHCP/BOOTP server; unlike NetWare/IP 2.2
itself, this
server will run on NetWare 3.12.
ftp://ftp.novell.com/updates/unixconn/nwip22/nip22b.exe
http://netware.novell.com/discover/nwip/index.htm
960809 Silicon Graphics: 'proclaim' software for SGI
workstations; part
of IRIXpro.
http://www.sgi.com/Products/hardware/challenge/IRIXpro/IRI
Xpro.html
http://www.sgi.com/Products/hardware/challenge/IRIXpro/IRI
Xprospecs.html
960829 Isotro: NetID DHCP Server (BOOTP/DHCP server)
(No longer available from Isotro)
960912 Cisco: (announced) DHCP/BOOTP server for Solaris, HP-UX,
and
AIX, Windows NT (Alpha & Intel) included in Cisco's
DNS/DHCP
Manager V1.0 and Cisco's Server Suite 1000 V1.0
http://www.cisco.com/
960917 SunSoft: (future) DHCP/BOOTP server to be bundled with
Solaris 2.6
or as hte "Internet Server Supplement" to Solaris 2.5.1.
http://www.sun.com/
961118 Network TeleSystems: Shadow (PC-based) also does BOOTP
http://www.nts.com/NTS/shadow.html
961217 Hewlett-Packard: HP-UX 10.10 and subsequent versions
include a bootp
server with DHCP extensions.
970325 American Internet Corp: Net Registrar (for Windows NT and
Solaris)
http://www.american.com/
970403 Microsoft: BOOTP/DHCP server in NT 4.0 SP2.
http://www.microsoft.com/kb/articles/q161/5/71.htm
970415 VICOM: VICOM DHCP Server (runs on Macintosh/MacOS)
http://www.vicomtech.com/dhcp.main.html
970415 Sonic Systems: Sonic DHCP Internet Server runs on
Macintosh/MacOS,
also does BOOTP
http://www.sonicsys.com/dhcp.html
970805 Process Software: MultiNet 3.5 for OpenVMS includes
DHCP/BOOTP server.
http://www.process.com/multinet/
971217 Quadritek Systems, Inc.: QDHCP (NT or UNIX), also does
BOOTP
http://www.quadritek.com/products/qipdhcpserv.html
980518 Billiter Consultants: ipLease DHCP server (32bit Windows)
http://www.billiter.com/
980331 Deerfield Communications: DHCP server included in Wingate
Pro (2.1b) "proxy server"
http://www.wingate.net/
980603 IBM OS/400 Version 3 Release 7 and subsequent versions
includes
a DHCP/BOOTP server.
http://www.as400.ibm.com/
980611 Bay (Xylogics) Remote Annex (RA) and Remote Access
Concentrator
 (RAC) communication servers have proxy DHCP client since
release
13.2, December 1995.
http://www.baynetworks.com/
980612 IBM: DHCP server included in AIX 4.1.4 and beyond.
Includes
BOOTP service.
http://www.rs6000.ibm.com/
980612 IBM: TCP/IP Version 4.1 for OS/2 Warp includes DHCP, BOOTP
and
DDNS and java-based administration.
http://www.software.ibm.com/os/warp-server

4. What freeware DHCP clients are available?

(This is not necessarily a complete list)
960809 WIDE Project includes a client for BSD and SunOS systems:
mailto:tomy@sfc.wide.ad.jp
WIDE Project
Keio Univ.
Japan
ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.2.1.tar.gz
Check Archie for dhcp-1.2.1 because lots of sites
distribute it.
Beta version:
ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.3beta.tar.gz
960904 Linux bootp client: bootpc; DHCP being added over time.
ftp://ftp.damtp.cam.ac.uk/pub/linux/bootpc/
970415 dhcpcd (for Linux 1.2.xx, 1.3.xx, 2.0.x)
ftp://ftp.kobe-u.ac.jp/pub/PC-UNIX/Linux/network/dhcp/
version 0.4a:
ftp://ftp.kobe-u.ac.jp/pub/PC-
UNIX/Linux/network/dhcp/dhcpcd-0.4a.tar.gz
version 0.5:
ftp://ftp.kobe-u.ac.jp/pub/PC-
UNIX/Linux/network/dhcp/dhcpcd-0.5.tar.gz
version 0.5-p1:
ftp://ftp.kobe-u.ac.jp/pub/PC-
UNIX/Linux/network/dhcp/dhcpcd-0.5-p1.tar.gz
version 0.6:
ftp://ftp.kobe-u.ac.jp/pub/PC-
UNIX/Linux/network/dhcp/dhcpcd-0.6.tar.gz
971204 Internet Software Consortium (ISC) DHCP/BOOTP Server
Distribution includes a client. See ISC server in section
above
on "Freeware Servers".

5. Which vendors of client software currently support DHCP?

(This is not necessarily a complete list)
950417 Shiva: proxy client for remote users (in Lanrovers and
Netmodems)
950425 Hewlett-Packard
950502 NetManage: Chameleon 4.5
950630 Beame & Whiteside Software: resells Dirk Koeppen EDV-
Beratungs-GmbH's
TCP/IP BOOT-PROM
950705 Microsoft: MS-TCP/IP 3.11a & MS-TCP/IP 3.11b
950711 Microsoft: Windows NT 3.5
950711 Microsoft: Windows for Workgroups 3.11a
950711 Frontier Technologies(800-929-3054): in SuperTCP for
Windows
http:www.frontiertech.com
info@frontiertech.com
950712 Beame & Whiteside(800-720-7151): BW-Connect NFS for DOS &
Windows
950802 Wollongong: PathWay Access ver 3.2 (Windows)
http://www.twg.com/
950802 WRQ: Reflection Network Series products (version 5) for
Windows
http://www.wrq.com/
950814 Competitive Automation(415-321-4006): SunOS4.x, Solaris2.x
and
DECOSF3.x,4.x clients
950915 Stampede: included in Remote Office Gold
951113 Persoft(800-368-5283): TCP Addition and Portable TCP
http://www.persoft.com/
951207 Dirk Koeppen EDV-Beratungs-GmbH: TCP/IP DHCP Boot ROMs
(TCP/IP
BOOT-PROM) www.dunkel.de/dksoft
951220 Attachmate: IRMA TCP Suite Version 3.1
960130 Digital: RoamAbout Mobile IP Client/Server Network
Software V2.0
http://www.digital.com/info/Customer-
Update/940620001.txt.html
960209 FTP Software: included in OnNet 2.0 (Windows)
http://www.ftp.com/
960209 FTP Software: PC/TCP 4.0 (DOS)
http://www.ftp.com/
960312 Core Systems: Internet-Connect for Windows 95 Version 2.1
has DHCP
proxy client.
http://ns1.win.net/~core/Coresys/homepage.html
960313 Apple: Open Transport 1.1 included with System 7.5.3 &
runs on
68030, 68040, and PowerPC Macintoshes.
960314 Apple: Open Transport 1.1 shrink wrap version will be
offered.
960408 IBM: Client DHCP software for Windows 3.x.
960408 IBM: Client DHCP software for MS/PC-DOS.
960501 SunSoft: included in PC-NFS Pro 2.0 for Windows
960501 NetManage: included in ChameleonNFS 4.6
960503 FTP Software: included in OnNet32, Version 1.0 (Windows 95
and NT)
http://www.ftp.com/
960514 Novell: Client32 for DOS/Windows 3.1 (beta) will use
either DHCP
or BOOTP to get IP parameters.
960514 Novell: NetWare/IP for DOS, Windows 3.1, Windows 95, and
Windows NT uses DHCP to obtain IP parameters.
 960514 Novell: NetWare/IP servers can use DHCP to auto-configure
their
IP parameters.
960809 Silicon Graphics: included in IRIX since version 5.3.
http://www.sgi.com/Products/software/IRIX6.2/IRIX62DS.html
http://www.sgi.com/Products/hardware/challenge/IRIXpro/IRI
Xpro.html
960917 Sun: Solaris 2.6.
http://www.sun.com/
961118 Network TeleSystems TCP Pro 3.0 for Windows
http://www.nts.com/NTS/tcp_pro.html
970805 Cisco: DHCP & BOOTP for Windows 3.1 included in Cisco
TCP/IP
Suite 100 for Windows (formerly MultiNet for Windows) V2.0
For Windows 95, uses the native support.
http://www.cisco.com/
980331 Deerfield Communications: DHCP server included in Wingate
Pro (2.1b) "proxy server"
http://www.wingate.net/
980611 IBM: OS/2 WARP Version 4 (Merlin) has DHCP client
capability in the
basic package.
http://www.software.ibm.com/os/warp-client
980612 IBM's DOS/Windows LAN Services (for IBM PC-DOS, Microsoft
MS-DOS, and/or Microsoft Windows 3.x)
980612 IBM's line of NetworkStations are all DHCP clients (or
BOOTP)
http://www.as400.ibm.com/networkstation/
980612 IBM: AIX 4.1.4 client and server packages include a DHCP
client.
http://www.rs6000.ibm.com/

6. 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.
7. 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.
8. 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.
9. 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.
10.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 atftp://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.
11.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.
12.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
13.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)
14.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
15.Do any servers limit the MAC addresses that may roam?
 IBM's AIX and OS/2 WARP DHCP servers.
 ISC.
16.What analyzers decode DHCP?
  Release 5.0 of Network General Corporation's Sniffer software.
 I believe one of the free Unix implementations has included in its
distribution a program that captures and decodes BOOTP and
DHCP negotiations.
 Microsoft's SMS includes a protocol analyzer called "Network
Monitor" that decodes DHCP. All NT software includes a remote
agent for it.
 NetXRay, software that runs under Windows NT adn
95. http://ngcwebgate.ngc.com/product_info/netxray/netxray.html
 PacketView (LAN), SerialView (PPP and SLIP), and ISDNView
(PPP over ISDN) all are DOS programs that fully decode DHCP
packets.href="http://www.klos.com/
17.What administration tools administer DHCP configurations?
 Quadritek's QIP network administration product includes an
interface to Competitive Automation's JOIN DHCP server and
IBM's DHCP server and their own server.
18. 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.
19. 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.