DHCP stands for "Dynamic Host Configuration Protocol".
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.
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.
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)
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.
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, like BOOTP runs over UDP, utilizing ports 67 and 68.
An IP address (also called an IP number) is a number (typically written as four numbers separated by periods, i.e. 107.4.1.3 or 84.2.1.111) which uniquely identifies a computer that is making use of the Internet. It is 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.
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.
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.
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.
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.
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.
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".
Only if the DHCP server is specifically written to also handle BOOTP queries.
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.
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.
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.
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.
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.
The DHC WG of the IETF is actively investigating the issues in inter-server communication. The protocol should be defined "soon".
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/.
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.
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:
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.
In Internet RFCs.
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
See the dhcp-v4 mailing list mentioned above as well as its archives.
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.
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.
A server on a net(subnet) can relay DHCP or BOOTP for that net. Microsoft has software to make Windows NT do this.
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:
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.
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.
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.
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:
Some examples of lease-times that sites have used & their rationals:
There is no ideal answer: you have to give something up or do some extra work.
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.
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:
Other features which a DHCP server may or may not have:
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.
(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
(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/IRIXpro.html
http://www.sgi.com/Products/hardware/challenge/IRIXpro/IRIXprospecs.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
(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".
(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/IRIXpro.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/
(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.
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.
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.
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.
(These are not complete lists) The following servers can handle dynamic allocation on secondary subnet numbers:
The following can serve manually allocated addresses on secondary subnet numbers:
The following cannot support secondary subnet numbers:
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.
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:
A Document that addresses this question is the Windows 95tm Networking FAQ, http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
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.
In many cases, new releases have solved the problems that have been identified with various DHCP implementations.
File: Vdhcp.386 File Last Modified Date: 02/12/96 File Size: 27,985 bytes File Version Information: 4.00.951It 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