DHCP and Migration Strategy

DHCP Overview

The Dynamic Host Configuration Protocol (DHCP) is designed to provide a centralized approach to the configuration and maintenance of IP address space. It allows the network administrator to configure various clients on the network from a single location. In addition to the management of IP addresses, DHCP can also configure parameters such as default gateway, domain name server and subnet masks for each machine running a DHCP client. In fact, the protocol currently describes over 70 parameters that can be configured using DHCP including parameters such as SMTP server and WWW server. New parameters specific to a particular software platform can also be easily supported.

The DHCP paradigm is based on the client-server model. Let's see how this model works by examining a simple case. When a DHCP client boots, it broadcasts a DHCP request asking for any DHCP server on the network to provide it with an IP address and configuration parameters. A DHCP server on the network that is authorized to configure this client will offer an IP address by sending a reply to the client. Upon receiving this offer, the client may decide to accept it or it may wait for additional offers from other servers on the network. At the end, the client decides on a particular offer and sends a request to accept the offer made by the server. Knowing that it has been chosen, the server will then send back an acknowledgment with the offered IP address and any other configuration parameters that the client might have requested. The server does not force any parameters on the client. It is up to the client to request the parameters that it is willing to accept.

The IP address offered to the client has an associated lease time. The lease time dictates for how long the IP address is valid. During the lifetime of this lease, the client will repeatedly ask the server to renew its lease. If the client chooses not to renew it or if the client machine is shutdown, the lease will eventually expire. Once the lease expires, the IP address can be recycled and given to another machine. When the client reboots later, it can be given the old address (if it is still available) or a new address. This helps the administrator to make sure that the IP address space is used efficiently especially for networks where there is a shortage of IP addresses.

The above example describes the essence of DHCP. The actual protocol is actually more robust and versatile. To get more information on DHCP and its supported configuration parameters, please refer to RFC 1531 and RFC 1534.

The Concept of Client ID

In the old BOOTP protocol, each client is uniquely identified by its MAC address. Since each network adapter card has its own unique MAC address, this is sufficiently unique to identify the client. With DHCP, a new object is defined to uniquely identify the client, the Client ID. The Client ID is an opaque object created by the client to uniquely identify itself to the DHCP server. By "opaque", the server is not supposed to interpret the content of the Client ID or make assumptions of its internal structure. For most DHCP clients available to day, the Client ID is simply the MAC address, just like the old identification used by BOOTP. For some clients, a variation of the MAC address is used as the client ID. For example, Windows 95 and NT prepend the hardware type to the hardware address and call the combined object the client ID.

According to the protocol, if a client ID is supplied in the client's request packet, the client ID should be used to unique identify the client. If a client ID is not included in the request then the MAC address should be used instead. For administrators who are used to assigning static IP address based on the MAC address, it may require a lot of manual work to re-specify the IP address for these new Client ID. JOIN has a Server/Security Parameter called "Use MAC addr as client ID" that will allow the server to use the MAC address as the unique identifier instead of the Cient ID. By setting the parameter to True, the server will ignore the Client ID even if it is sent by the client. Together with the bptojdb utility, this will allow the administrator to describe the same MAC-to-IP address mappings with minimal effort.

DHCP Migration Strategy

 If you are currently using BOOTP to manage your IP address space, you have a number of options for migrating to DHCP. The option you choose depends on what you intend to do with your clients.

These are some of the questions that will effect your migration strategy.

Keep Everything BOOTP-only

If you have an existing BOOTP environment with a standard bootptab file and you want the JOIN DHCP server to work exactly like a BOOTP server, the migration is trivial. JOIN can read the standard bootptab file as-is without any changes to your existing bootptab. You can simply rename your bootptab file to dhcpcap and JOIN will use it as-is. It will begin serving your existing BOOTP clients immediately without any further changes. This migration strategy assumes that you want to keep everything the same and do not want to convert your existing BOOTP clients to DHCP.

Switching to DHCP

If you want to use DHCP because you want to convert existing BOOTP clients to DHCP or because you have new DHCP capable clients appearing on your network, you'll need to think about your IP addressing strategy. DHCP allows the use of static IP address assignment and the more flexible dynamic IP address assignment. Traditional BOOTP uses a static, one-to-one mapping between the client's MAC address (i.e. Ethernet address) and its IP address. Whenever the client requests an address, it'll get the same pre-determined IP address. This is called static IP addressing. DHCP, on the other hand, can also use a new, dynamic addressing scheme where an address is allocated from a pool of IP addresses. Each address has a lease time that determines how long the client can use that IP address. This is different from BOOTP where an IP address is assigned permanently and not leased.

Static Addressing with DHCP

One typical reason for using static IP addressing is because you want to maintain an existing static assignment policy currently used in your network. Another reason for using static assignment is if you have devices or hosts that need to have the same IP address all the time. Devices such as printers or hosts such as file servers may require such a static IP address. When you define a static IP address for a client, you would usually define a permanent lease for that client. This ensures that your DHCP client will always get the same IP address whenever it boots.

There are two ways to define a static IP address, one using the xjoin GUI's Active IP Snapshot, the other using the jdbmod utility. The former is described in detail in Chapter 3, "Configure with xjoin," while the latter is described in Chapter 4, "Configure without xjoin," and the jdbmod (1) man page.

If you have an existing bootptab file that defines these static IP addresses, use the jdbmod utility to describe them to the JOIN DHCP server. You can also use the xjoin GUI to accomplish the same objective but it will take significantly more time because you'll have to re-type all the MAC-and-IP address pairs. To help you specify static IP addresses from a bootptab file, JOIN has a conversion utility (bptojdb) that will read a standard bootptab file and create static, infinite leases in the JOIN database. This is necessary because JOIN does not use the dhcpcap file to store lease information. JOIN uses its own internal databases for storing lease and other information. There are different ways to populate the JOIN database with your existing static information, however the following steps describes the simplest approach:

  1. Convert your existing bootptab file to JOIN format.

    # bptojdb bootptab > bootptab.join

  2. Stop the server if it is running.
  3. Populate the JOIN database with the new information

    # jbdmod bootptab.join

  4. Set the Server/Security Parameter, "Use MAC Addr as Client ID" as True.
  5. Restart the server.
Note: The above steps will convert all the BOOTP clients described in your bootptab file into DHCP clients with the same static IP address and an infinite lease.

Dynamic Addressing with DHCP

 If you do not care to use the old static IP addresses, you can use the new dynamic addressing scheme provided by DHCP. To use dynamic addressing, you basically define a pool of IP addresses for each subnet or network that you want the DHCP server to service. Upon getting a request, the server will then select an unused address from the pool and give it to the client. The administrator can specify a lease time as to how long the address is valid. The lease time is specific to your network and the nature of your clients. If you have clients that go up and down frequently or if you have a limited number of addresses but a large number of clients, you may want to keep a relatively short lease time. This will allow a more efficient use of your limited address pool. If you have clients that seldom go down or have a large address pool for few clients then you may want to use a longer lease time. There isn't a single, fixed formula for determining the optimal lease time. Each site has its unique environment and requirements. Dynamic addressing uses the full potential of DHCP but unfortunately most sites do not use strictly dynamic addressing. The typical network uses a combination of BOOTP, static DHCP addressing and dynamic DHCP addressing.

DHCP Parameters Configuration

 The previous sections deal primarily with one parameter, the client's IP address. However, there is more to a client's configuration than just the IP address. There are also configuration parameters such as the default gateway, DNS domain name and DNS servers. As far as these parameters are concerned, you can configured them for your clients using one of two methods. If these parameters are specified in your existing bootptab file for each specific client, you can continue to use them as-is. JOIN can give out the same configuration parameters defined in bootptab.

The other alternative is to define a set of parameters on a per-subnet basis instead of a per-node basis. This allows all the clients on a particular subnet to have the same configuration parameters. Although this may seem restrictive at first glance, it is actually quite useful. It allows the administrator to create a uniform set of parameters for all the clients on the same subnet. In most cases, clients on the same subnet do have the same parameters, for example, the same default gateway, the same DNS domain name, the same netmasks, etc.

New BOOTP Functionality from JOIN

 In addition to supporting the traditional BOOTP functionality, JOIN includes a few enhancements to the BOOTP protocol. They are provided because in some environments existing BOOTP clients cannot be migrated to DHCP. This could be because of software limitations on the client side or resource limitations on the existing networks. Yet, the administrator may wish to use some of the features provided by DHCP but with BOOTP clients instead. The two new features provided for BOOTP clients are Dynamic BOOTP and Finite BOOTP.

Dynamic BOOTP

Traditionally, BOOTP clients are configured with a static, one-to-one, MAC address to IP address mapping. This means the MAC address must be given a pre-configured IP address. A request from a client that doesn't have a pre-configured IP address will not be answered by the server. With the Dynamic BOOTP option enabled, there is no need for a pre-configured IP address. Upon seeing a BOOTP request and discovering that no pre-configured IP address is available, it will then allocate an IP address from the IP address pool used by DHCP. This allows the administrator to service BOOTP clients without having to know ahead of time the client's MAC address and its pre-determined IP address. To enable this feature, simply set the Server/Security parameter, "Use BOOTP Addr from Pool" to True. By default, once an address is given out in this manner, the address is given out permanently. Unlike DHCP, there is no lease time. However, JOIN also allows the "leasing" of IP address to BOOTP clients. This feature is known as Finite BOOTP.

Finite BOOTP

Finite BOOTP is developed to mimic the DHCP concept of a "leased" IP address. Traditionally, once an address is given to a BOOTP client, the address is gone for good and cannot be recycled. With Finite BOOTP, unbeknown to the client, a lease time is associated with the IP address offered. When the lease period ends and the server is trying to give this address to another client, it first checks to make sure that the address is not currently in use. It does that by pinging the IP address. If a reply is received, this means the old client is still using that IP address. The server will then automatically "extend" the lease and will not offer this address to the new client. It will continue to search for a free address to offer to the new client. If the server doesn't get a reply from its ping, it assumes that the client is no longer using that IP address. This address is now free and can be offered to the new client. The extension time is described by the parameter, "BOOTP Address Extension". For example, if you specify an extension time of one day, that address cannot be recycled for another day. At the end of that day, if that address is still being used, it'll automatically be extended for another day. If it is not used, i.e. there is no PING reply then the address can be given to another client.

Finite BOOTP is most useful in environments where you want to keep the clients BOOTP but still to want use DHCP-like IP address leasing functionality.

Switched Environment or Flat Networks

 The use of Ethernet and Token Ring switches for reducing LAN network congestion has created some problems for DHCP. For DHCP, the traditional method for logical segmentation of a network has been the use of subnets and routers. DHCP Relay Agents would simply forward packets from the client's subnet to the server. This forwarding of DHCP packets breaks down when switches instead of routers are used to logically partition a network. The switches do not have relay agents and they do not necessarily partition the network to different subnets. Instead, the switches can partition an arbitrary group of machines into a virtual network or VLAN. A broadcast packet within this VLAN can be configured not to go beyond the local virtual network. In other words, a broadcast packet may not go beyond its broadcast domain.

Imagine we have an environment where the entire network is logically partitioned using switches. Within this switching fabric, a DHCP server resides on one VLAN. The DHCP clients reside on the other VLANs in this fabric. When a client broadcasts a DHCP request, the broadcast may not get to the server at all. Since the switch doesn't have a relay agent, it does not modify the DHCP request and forward it to the DHCP server. More likely than not, the broadcast packet is limited to the broadcast domain where the client resides. The switch will not broadcast the DHCP request to the other virtual nets. As a result, the DHCP server will not see the DHCP broadcast request from the clients.One way to overcome this problem is to put a DHCP server on each virtual net. Although this will solve the problem, it can create an administrative problem if there are lots of virtual networks in the environment.

A more effective and manageable method is to put a DHCP relay agent in each VLAN. Since each relay agent can hear broadcasts within its VLAN, it can relay DHCP broadcast directly to the DHCP server. From the relay agent to the DHCP server, the DHCP packet is sent unicast instead of broadcast. More importantly, the relay agent can modify the DHCP request and let the server know which subnet the DHCP client belongs to. Managing a relay agent is child's play compared to managing a DHCP server. In addition, this solution allows the administrator to manage one DHCP server instead one on each VLAN. JOIN includes not only a DHCP server but also a relay agent (bprelay) for your specific platform. The relay agent is simply a Unix process that forwards DHCP packets between the clients and the server. For more information about the relay agent included in your JOIN package, please refer to its man page, bprelay (1).

Fault Tolerant and Redundant Server

 Since a DHCP server is responsible for the network's IP management, it can also be a potential point of network failure if it becomes unavailable. Unfortunately, there is no server-to-server protocol currently defined for DHCP. Although Competitive Automation has written and presented a draft on the DHCP server-to-server protocol, it has yet to work its way through the IETF. Until a server-to-server protocol is defined and implemented as a standard, there is no efficient way to provide fault-tolerance or redundancy.

One method that is being used to provide fault-tolerance in a limited fashion is to use multiple servers with non-overlapping IP address pools. This method can be easily explained by using an example. Imagine we have a simple situation where there are only two DHCP servers. Server A has an address pool of 100 IP addresses. Server B has a pool of 50 address that is completely different from Server A's. The two servers have non-overlapping pool of addresses. When a DHCP client broadcast for an address, both servers will respond, each offering an address from its own distinct pool. Upon receiving both offers, the client will choose one. Typically, the response that gets to the client first will be selected by the client. Suppose Server A's offer is selected by the client. Upon seeing that Server A's offer is selected, Server B will return its offered address to its own pool, allowing it to be offered again.

In the event that one of the servers is down, the remaining server will continue to service the DHCP clients. Instead of seeing two offers, the new client will see only one offer, from the remaining server. Clients that got their lease from the dead server will attempt to rebind with it. If the dead server does not come back in time, the clients will then attempt to get a new address from a new server. The remaining server can then offer an address from its own pool to the client. As a result, even though one server is down, the DHCP clients continue to function with the other server. One should note that the two DHCP servers operate without any communications or data sharing between them. Each server works as a standalone server, independent of each other.

Since most clients will select the first offer received, having two servers could result in both IP pools used partially. Sometimes it may be desirable to have a "primary" DHCP server with the bulk of the IP addresses while the "secondary" server has a smaller pool of IP addresses. One way to accomplish that configuration is to put the secondary server behind a router on a different subnet while the primary server stays on the same segment as the clients. This should allow the primary server to respond faster than the secondary server.

Last Modified: 11:19am , November 11, 1996