DHCP FAQ

Author: John Wobus, jmwobus@syr.edu (corrections welcome)
Date: 10/24/96
This file: http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
Web page of other links on the subject of LANs: http://web.syr.edu/~jmwobus/lans/

Questions

General
Info on Implementations

Answers

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.
3. 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 (March 1996), DHCP is an Internet Proposed Standard Protocol and is Elective. BOOTP is an Internet Draft Standard Protocol and is Recommended. For more information on Internet standardization, see RFC1920 (March 1996).
4. 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.
5. Why shouldn't clients assign IP numbers without the use of a server?
  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.
  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.
6. 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.
7. Can a BOOTP client boot from a DHCP server?
  Only if the DHCP server is specifically written to also handle BOOTP queries.
8. 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.
9. 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.
10. 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.
  
  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.
11. Can a DHCP client update its DNS entry through DHCP?
  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).
12. 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.
13. 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".
14. 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/.
15. 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.
16. 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.
17. 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.
18. Where is DHCP defined?
  In Internet RFCs.
  
  RFC1541
  R. Droms, "Dynamic Host Configuration Protocol", 10/27/1993.
  RFC1534
  R. Droms, "Interoperation Between DHCP and BOOTP", 10/08/1993.
  RFC1533
  S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", 10/08/1993.
  Note that there was an earlier RFC that defined DHCP, RFC 1531, but it was quickly superseded by RFC 1541. A web site for RFCs is: http://ds.internic.net/ds/dspg1intdoc.html
19. 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.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/
  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.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://TechWeb.CMP.Com/techweb/nc/707/707work2.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://TechWeb.CMP.Com/techweb/nc/708/708work1.html
20. 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.
  
  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.
21. 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.
22. 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.
23. 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.
24. 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.
25. 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.
26. 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.
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.
  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:
 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.
 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
960910 Internet Software Consortium (ISC) DHCP/BOOTP Server
 ftp://ftp.fugue.com/pub/DHCPD-BETA-5.9.tar.gz
 http://www.isc.org/isc
961015 Princeton patch to dhcpd 3.7.7.
 http://www.princeton.edu/~irwin/src/CMU-dhcpd-3.3.7-PU-patch1.Z
```
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
951010 TGV: DHCP/BOOTP server will be included in Multinet for VMS v3.5.
       http://www.tgv.com/
951121 TGV(800-848-3440): MultiNet 3.5 for OpenVMS includes DHCP server.
       mailto:sales@tgv.com
       http://www.tgv.com/
951207 IBM: DHCP server included in AIX 4.1.4 server packages.
       Also includes custom DNS server that is "DHCP knowledgeable".
       http://www.ibmlink.ibm.com/(search for DHCP in SalesManual)
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/
960110 Quadritek Systems, Inc. (DHCP server included in next release)
       http://www.qtek.com/qsi-qip.html
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
960419 Hewlett-Packard: HP-UX 10.10 includes a bootp server with DHCP
       extensions.
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 IBM: DHCP/BOOTP server included in Warp Server 3.0 (OS/2).
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
960710 Sonic Systems: Sonic DHCP Internet Server runs on MacOS
       http://www.sonicsys.com/dhcp.html
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)
       http://www.isotro.com
960904 VICOM: VICOM DHCP Server (runs on MacOS)
       http://www.vicomtech.com
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/
961003 Network TeleSystems: Shadow (PC-based)
       http://www.nts.com/NTS/shadow.html
```
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:
       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.
       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.dampt.cam.ac.uk/pub/linux/bootpc/
960910 Internet Software Consortium (ISC) DHCP/BOOTP Server includes
       a minimal client that can be used for testing.  See ISC server
       in section above on "Freeware Servers".
961003 dhcpcd 0.4 (for Linux 1.2.xx, 1.3.xx, and 2.0.x)
       ftp://sunsite.unc.edu/pub/Linux/system/Network/daemons/dhcpcd-0.4.tar.gz
```
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
950725 IBM: a future release of AIX
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
951207 IBM: AIX 4.1.4 client and server packages include a DHCP client.
       http://www.ibmlink.ibm.com/(search for DHCP in SalesManual)
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 TGV: included in MultiNet for Windows V1.2
       http://www.tgv.com/
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.
960606 IBM: Clients built with OS/2 Warp Server code include DHCP
       client code.  Note that OS/2 Warp Connect supports BOOTP but not
       DHCP.
960715 IBM fixpak for OS/2 WARP (the WARP Connect Version) that includes
       a DHCP client: UN00067 (updates TCP/IP V3.0 and assumes fixpak
       WR08210 has been applied to update MPTS).
       ftp://service.boulder.ibm.com
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
960823 IBM future version of OS/2 (codenamed Merlin) will include
       DHCP in the basic package.
960917 Sun: Solaris 2.6.
       http://www.sun.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 Connect does not support it, but there is a patch (fixpak) for it (see above). Clients built with Warp Server code support 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). I don't know what version of their software first supported it, but I know that 10.0 does.
  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.
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 at ftp://ftp.novell.edu/updates/inet/mpr211/tcpn01.exe and on Netwire. Two other such NLMs (possibly old versions of the same) that are available online:
    - ftp://netlab2.usu.edu/misc/bootpfd.zip(unsupported Novell software, 1993)
    - ftp://netlab2.usu.edu/misc/bootp311.zip(unsupported Novell software, 1991)
  - Also for Novell servers, the DHCP server that comes with NetWare/IP 2.2 can be configured to be just a BOOTP/DHCP forwarding agent.
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.
  - What servers support secondary subnet numbers?
    (These are not a 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
    The following can serve manually allocated addresses on secondary subnet numbers:
    - IPTrack version 2.0
    - ISC
    - JOIN
    The following cannot support secondary subnet numbers:
    - Microsoft Windows NT 3.51 and 4.0 (through RC1)
  - 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://user.interactive.net/~perin/
    A Document that addresses this question is the Windows 95tm Networking FAQ, http://www-leland.stanford.edu/~llurch/win95netbugs/faq.html
  - Do any servers limit the MAC addresses that may roam?
    - IBM's AIX and OS/2 WARP DHCP servers.
  - 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.
  - What administration tools administer DHCP configurations?
    - Quadritek's QIP network administration product includes an interface to Competitive Automation's JOIN DHCP server.
  - 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.
    - 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.