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.
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.
It is theoretically possible for client-machines to find addresses to use by picking an address 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.
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 presumeably 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.
No. There has been some discussion about adding this ability to DHCP.
(Note: as far as I can tell, the DNS needs no protocol update since the server already tells the clients how long they can use the information they receive; what is really needed is a DNS server that can make fuller use of this feature and that cooperates with a DHCP server, perhaps through the use of some new "DHCP-server-to-DNS-server" protocol).
This is the purpose of the "server to server protocol" (see next question). I know of no other way that you can keep a "hot" spare server in synch with your production server. However, it is possible that some server vendors have addressed this issue with their own features.
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 ---- ------- host-conf@sol.eg.bucknell.edu General discussion dhcp-bake@bucknell.edu DHCP bakeoffs dhcp-impl@bucknell.edu Implementations dhcp-serve@bucknell.edu Server to server protocolAdmin requests for the host-conf list should go to host-conf-request@sol.eg.bucknell.edu; admin requests for the other lists should go to listserv@bucknell.edu. Archives for 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 the latter phrase is more commonly used.
In Internet RFCs.
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.
I am not currently aware of any way in which DHCP can support client-computers served solely by PPP or SLIP. Such a computer doesn't have the IEEE-style MAC address that DHCP requires to act as its key to determining which client-computer is which within the same subnet. 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 occiasionally 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 and Windows NT is an example of a server with that capability.
(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 static allocation of IP addresses) http://www.sghms.ac.uk/~mpreston/bootp_dhcp.tar.Z (within http://www.sghms.ac.uk/~mpreston/tools.htm") 950630 WIDE Project: Akihiro Tominaga (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. 950706 "samba" DHCP patches for bootp server: (does static 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
(This is not necessarily a complete list)
950425 Silicon Graphics
950613 NetWare/IP 2.1 will NOT support DHCP but support for enhanced
bootp will be provided. I'm guessing this means DHCP-format
packets, but no address leasing.
950714 FTP Software (Services OnNet Product)
http://www.ftp.com/mkt_info/services.html
950714 Sun (SolarNet)
http://www.sun.com/cgi-bin/show?sunsoft/Products/Networking-products/products/pcadmin.html
950714 Microsoft Windows NT
http://www.microsoft.com/NTServer/
http://www.microsoft.com/BackOffice/techbriefs/tech1000.htm
950714 Hewlett Packard HP-UX
950802 Process Software: server for OpenVMS
http://www.process.com/
950828 Novell: I heard a rumor that they will deliver a server by the
end of 1995.
950906 IBM: included in Warp Server which is in beta
951010 Wollongong: included in next release of PathWay for OpenVMS which is in
beta
951010 TGV: DHCP/BOOTP server will be included in Multinet for VMS v3.5.
951101 Competitive Automation's JOIN (415-321-4006): SunOS4.x,
Solaris2.x and DECOSF3.x,4.x DHCP/BOOTP servers; HP-UX planned.
http://www.join.com/
951106 ON Technology: Novell Server-based DHCP/BOOTP server (NLM)
http://www.on.com/
951121 TGV(800-848-3440): MultiNet 3.5 for OpenVMS includes DHCP server.
mailto:sales@tgv.com
(This is not necessarily a complete list)
950417 Shiva: proxy client for remote users (in Lanrovers and Netmodems)
950421 Microsoft: Windows for Workgroups
950425 Sun
950425 Silicon Graphics
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
950725 IBM: a future release of AIX
950728 Sun: PCNFS for Windows
950801 FTP Software: for DOS and Windows (included in PC/TCP OnNet and
PC/TCP networking software; note: the DOS client utilizes DHCP
queries/responses to get an IP address, but does not track its
lease and renew when it should; however, the Windows client is
true DHCP. FTP has stated that the DHCP client the upcoming
OnNet 2.0 and PC/TCP 4.0 releases will perform lease renewal
properly).
http://www.ftp.com/
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
950906 IBM: included in Warp Server which is in beta
950915 Stampede: included in Remote Office Gold
951005 Apple: "Open Transport" included with PowerPC PCI Macintoshes.
951010 TGV: will be included in MultiNet for Windows V1.2
951011 Dirk Koeppen EDV-Beratungs-GmbH: TCP/IP DHCP Boot ROMs (TCP/IP
BOOT-PROM) www.dunkel.de/desoft
951113 Persoft(800-368-5283): TCP Addition and Portable TCP
http://www.persoft.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).
DHCP requires disk storage (or some other form of reliable non-volatile storage), making the task of DHCP service compatible with servers but incompatible with dedicated routers. There are a number of server types that can be configured to both route and serve DHCP, but no dedicated routers.
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.
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: