DHCP Complete

What is DHCP?
DHCP (Dynamic Host Configuration Protocol) is a protocol that lets network administrators manage centrally and automate the assignment of IP (Internet Protocol) configurations on a computer network. When using the Internet's set of protocols (TCP/IP), in order for a computer system to communicate to another computer system it needs a unique IP address. Without DHCP, the IP address must be entered manually at each computer system. DHCP lets a network administrator supervise and distribute IP addresses from a central point. The purpose of DHCP is to provide the automatic (dynamic) allocation of IP client configurations for a specific time period (lease period) and to eliminate the work necessary to administer a large IP network.

Who created DHCP?
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. Its definition is recorded in an Internet RFC (standard) and the Internet Activities Board (IAB) is asserting its status as to Internet Standardization.

Why is DHCP important?
When connected to a network, every computer must be assigned a unique address. However, when adding a machine to a network, the assignment and configuration of network (IP) addresses has required human action. The computer user had to request an address and then the administrator would manually configure the machine. Mistakes in the configuration process are easy for novices to make, and can cause difficulties for both the administrator making the error as well as neighbors on the network. Also, when mobile computer users travel between sites, they have had to relive this process for each different site from which they connected to a network. In order to simplify the process of adding machines to a network and assigning unique IP addresses manually, there is a need to automate the task. The introduction of DHCP alleviated the problems associated with manually assigning TCP/IP client addresses. Network administrators have quickly appreciated the importance, flexibility and ease-of-use offered in DHCP.

How does DHCP work?
When a client needs to start up TCP/IP operations, it broadcasts a request for address information. The DHCP server receives the request, assigns a new address for a specific time period (called a lease period) and sends it to the client together with the other required configuration information. This information is acknowledged by the client, and used to set up its configuration. The DHCP server will not re allocate the address during the lease period and will attempt to return the same address every time the client requests an address. The client may extend its lease with subsequent requests, and may send a message to the server before the lease expires telling it that it no longer needs the address so it can be released and assigned to another client on the network.

What advantages does DHCP have over manual configuration methods?
The use of DHCP is highly recommended and there are a number of obvious reasons why you should use it. As mentioned before, there are two ways you can configure client addresses on a computer network, either manually or automatically. Manual configuration requires the careful input of a unique IP address, subnet mask, default router address and a Domain Name Server address. In an ideal world, manually assigning client addresses should be relatively straight forward and error free. Unfortunately we do not live in an ideal world so computers are frequently moved and new systems get added to a network. Also if a major network resource, such as a router (which interconnects networks) changes network addresses, this could mean changing EVERY system's configuration. For a network administrator this process can be time consuming, tedious and error prone. Problems can occur when manually setting up your client machines, so if you have the option to set-up your client machines automatically, please do, as it will save you time and a lot of headaches. DHCP has several major advantages over manual configurations. Each computer gets its configuration from a "pool" of available numbers automatically for a specific time period (called a leasing period), meaning no wasted numbers. When a computer has finished with the address, it is released for another computer to use. Configuration information can be administered from a single point. Major network resource changes ( e.g. a router changing address), requires only the DHCP server be updated with the new information, rather than every system.

Can DHCP provide support for mobile users?
Yes. The benefits of dynamic addressing are especially helpful in mobile computing environments where users frequently change locations. Mobile users simply plug-in their laptop to the network, and receive their required configuration automatically. When moving to a different network using a DHCP server, then the configuration will be supplied by that network's server. No manual reconfiguration is required at all.

Are DHCP servers easy to set-up and administer?
DHCP Servers offer completely centralized management of all TCP/IP client configurations, including IP address, gateway address and DNS address. DHCP servers are easy to administer and can be set-up in just a few minutes. Client addresses are assigned automatically unlike static set-up which requires the manual input of client addresses which can be a time consuming and tedious task.

Are there any limitations that I should be aware of?
Some machines on your network need to be at fixed addresses, for example servers and routers. The DHCP server you choose should be capable of assigning pre-allocated addresses to these specific machines. You need to be able to assign a machine to run the DHCP server continually as it must be available at all times when clients need IP access. To avoid conflicts between addresses assigned by the DHCP server and those assigned manually, users should be discouraged, or preferably prevented, from reconfiguring their own IP addresses. Some older operating systems do not support DHCP. If you have such systems you may be able to upgrade them. If this is not possible they may support the older BOOTP protocol, and a DHCP server can be chosen that will support this option. For peace of mind, it is a good idea to decide what is important to you, which of the available DHCP servers is best suited to meet your specific requirements and always get a second opinion.

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.

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. Apple talk is designed around this idea, and Apple's MacTCP can be configured to do this for IP. However, this method of IP address assignment has disadvantages. A computer that needs a permanently-assigned IP number might be turned off and lose its number to a machine coming up. This has problems both for finding services and for security. A network might be temporarily divided into two non-communicating networks while a network component is not functioning. During this time, two different client-machines might end up claiming the same IP number. When the network comes back, they start malfunctioning. If such dynamic assignment is to be confined to ranges of IP addresses, then the ranges are configured in each desktop machine rather than being centrally administered. This can lead both to hidden configuration errors and to difficulty in changing the range. Another problem with the use of such ranges is keeping it easy to move a computer from one subnet to another.

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.

Can a BOOTP client boot from a DHCP server?
Only if the DHCP server is specifically written to also handle BOOTP queries.

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.

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.

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.

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.

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.

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. lient ID type 1 means you're using MAC addresses. However, client ID type 0 means an ASCII string.

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.

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.

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 allocable 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 DHCP DISCOVER 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 servers 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.