Dynamic Host Configuration Protocol

Windows IT Pro

- Advertise

Dynamic Host Configuration Protocol
View the book table of contents

Author:	Emmett Dulaney Vijay Sankar Sharon E. Sankar
Published:	June 1999
Copyright:	1999
Publisher:	29th Street Press

Moving a DHCP Database to Another NT Server
The time will come (in most networks, anyway), when you will have to replace your present DHCP server. Unfortunately, simply configuring a new DHCP server and turning off the old one doesn’t work — clients that want to renew their leases are unable to find their original DHCP server and begin broadcasting for a new one. Once they locate the new server, they are given a new IP address, but not necessarily the one that they had originally.

One of the problems with the DHCP standard is that clients have the responsibility to manage an IP address once it is allocated. As a result, you will notice some inconsistencies in how DHCP clients behave.

Special Note: In our networks, we have noticed that Windows 95 computers usually ask for their previous IP address when they request a new lease from a different DHCP server. If the DHCP server has been moved to a new NT Server, most of the Windows 95 computers seem to receive the same IP address.

If NT Workstations can’t find the DHCP server at the end of their lease time, they send a dhcpdiscover message and get a new IP address. To our surprise, more NT Workstations ended up with different IP addresses than did Windows 95 computers.

If the new IP address is already in use because it has been given to a client from the old DHCP server, the new server won’t know that the IP address is in use. The new server then gives a duplicate address to the client, which causes confusion with applications that are using IP addresses to locate either of these two machines.

To set up a new server, you must move the DHCP database to another server. The Microsoft Technet CD contains an article entitled “How to Move a DHCP Database to Another Windows NT Server” (Q130642). Here, we’ve outlined the procedure from the article.

This procedure involves editing the Registry, and all standard advice regarding backups applies.

To stop the DHCP service on the existing computer, select the Services icon from the Control Panel, then choose DHCP Services and Stop. To prevent the service restarting once it has been transferred, click Startup and select Disabled.
Copy %Systemroot%\System32\DHCP to a new temporary directory on the new DHCP server. The temporary directory shouldn’t have the same name as the directory on the old server because the Registry editor may save the key on the wrong computer later in the procedure. For more information about this topic see the Technet CD article “Registry Editor Saves Key on Wrong Computer” (Q139600). A good name for the new directory might be c:\temp\system32\Dhcp.
Start the Registry editor on the old DHCP server and go to the subkey

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ DHCPServer\Configuration
Click Registry, then click Save Key. Give the Key a unique name, such as Temp1. (Don’t select “Save Subtree As”; unlike Save Key, the “Save Subtree As” option isn’t meant for restoring Registry information from one system to another. Instead, it is intended to be used to verify the values and subkeys of a tree — see the Microsoft Technet CD article, “Registry Editor Could Not Accomplish the Requested Operation” (Q158294) for more information.)
If you are going to continue to use the existing computer, but not as a DHCP server, you may now remove the DHCP service from the machine by following steps 6–8 below. If you choose instead to leave the DHCP service disabled, skip to step 9.
Remove the directory %Systemroot%\System32\DHCP.
Click Start and select Settings, Control Panel, and Network.
At this point, article Q130642 contains an error. Don’t select Protocols as directed; instead select Services to open the window shown in Figure 8.8. Select Microsoft DHCP Server, then click Remove and OK.
The following steps apply to the new DHCP server. Install TCP/IP and DHCP on the new computer and restart it. DHCP will start automatically.
Stop DHCP on the new server.
If you have NT 3.51, rename the System.mdb file in the temporary directory c:\temp\system32\Dhcp to System.src. If you have NT 4.0, skip this step because NT 4.0 doesn’t have this file.
Copy the c:\temp\system32\Dhcp files to %systemroot%\System32\.
Start the Registry editor and go to the subkey

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ DHCPServer\Configuration.
Click Restore on the Registry menu.
Select %Systemroot%\System32\DHCP\Backup\Dhcpcfg in the browse list.
Select Yes to overwrite the newly installed Dhcpcfg file and replace it with the file from the old computer.
If you receive the error message “Registry editor could not accomplish the requested operation,” it means that the Registry was trying to restore this file to the old (remote) computer as described in article Q139600. If this happens start from step 14 again, and in step 15 select the Dhcpcfg file from the temporary directory (c:\temp\system32\dhcp\backup\dhcpcfg). This should remedy the problem.
Exit the Registry editor, then restart the DHCP service.
Start the DHCP Manager and follow steps 8 and 9 of “Restoring a Backup Copy of the DHCP Database” (earlier in this chapter) to reconcile the scopes.

PLANNING DHCP SERVER CONFIGURATIONS

Some of the most important considerations in configuring DHCP servers are related to lease times and ways to integrate DHCP with name resolution services.

Lease Time
The primary concern when optimizing DHCP is optimizing the lease times. What is the optimal lease time? As with so many other network tuning questions, the answer is, it depends. Microsoft gives a default value of three days, and many networks leave the default in place until problems occur, such as unusually heavy network traffic or clients being unable to receive IP addresses.

J. Wobus, in his article available at http://web.syr.edu/~jmwobus/comfaqs/ dhcp.faq.html#watgx, has some excellent suggestions for determining lease times. He starts with these three rules of thumb:

The more volatile the network (the more frequent the changes, and the more laptops used), the shorter the lease.
The less bandwidth available, the longer the lease (more DHCP requests and renewals cause more network traffic).
If users are sharing their IP addresses or if they’re using applications that require stable IP addresses, longer lease times or even reserved addresses are warranted.

Wobus also mentions relevant time — the amount of time a user wishes to keep his or her lease when the computer is turned off. He recommends that you set the lease time to a value at least twice the amount of time the computer is likely to be turned off. For example, if the user (or Administrative policy set by the user) wishes to keep the lease over a weekend (two days), the lease time should be set to 6 days. Setting it to this interval avoids having the computer go into a renewing state (at 50 percent of the lease time) as soon as it’s turned on after the weekend. Having every computer in an office go into a renewing state at about 8:30 on a Monday morning puts a large amount of traffic on the network. For a university, on the other hand, it may be impractical to give a lease that is twice the maximum amount of time that the computer is turned off, because university students are usually absent for three or four months over the summer.

Integrating with Name Resolution Services
In this section, we look at integrating DHCP with two of the most-used name resolution services: WINS and DNS.

WINS
Microsoft DHCP and WINS were designed to be companions. In fact, DHCP can’t currently exist without WINS because it requires a dynamic update of name-to-IP mappings to permit users to locate newly-registered or renewed DHCP-enabled clients. Current installations of DNS don’t permit integration with DHCP because DNS is a static name resolution service.

In most networks, the WINS server and DHCP server are on the same machine, although that configuration isn’t necessary. To allow an NT DHCP-enabled client to use WINS on an NT server machine, select TCP/IP Properties from the Network/Protocols page in the Control Panel, select WINS Address, and then add the IP addresses of the WINS servers. (Now you know why WINS servers must have static or reserved addresses.)

Dynamic DNS
Dynamic DNS is a new feature of 2000 Server and is described in detail in Chapter 6. To take full advantage of dynamic DNS, however, you must integrate it with DHCP. As of this writing, Microsoft is proposing to follow the draft standard available at ftp://ietf.cnri.reston.va.us/internet-drafts/ draft-ietf-dhc-dhcp-dns-08.txt.

In this section, we explain the proposed mechanism stated in the draft standard. For more information about topics in this sections, see the documents listed below:

DNS — RFC 1034, RFC 1035
DHCP — RFC 1541
Updates in DNS — RFC 2136
Dynamic update security — RFC 2137

Integrating DHCP with DNS involves updating both the A and PTR records in the DNS zone. To accomplish this task, a new option code has been defined (option code 81), called the client FQDN. This option consists of six fields, which are shown below. For a dhcprequest (from the client) the possible values of the options are as follows:

Code field — 81
Length field — minimum of four fields
Flags field — set to 0 (if client will be updating FQDN-to-IP-address mapping) or set to 1 (if server will be updating FQDN-to-IP-address mapping)
Rcode1 — set to 0
Rcode2 — set to 0
Domain Name — If the flags field is set to 0, the client will supply the domain name; if flags field is set to 1, the client may supply the domain name, or it may be left to the server to determine.

No matter what the values in the fields of the dhcprequest, the server always updates the corresponding PTR resource record.

The dhcpack from the server, has the following possible values.

Code field — 81
Length field — minimum of four fields
Flags field — set to the client flag or to 3 if the server is to override client permission to update record
Rcode1 — If the flags field is set to 0 (the client will update it), one of two things will happen:

If the server completes the DNS update before acknowledging to the client, Rcode1 is set to the Rcode for the PTR resource record.
If the server acknowledges the DNS update to the client before actually completing the update, the Rcode1 is set to 255.

Rcode2 — If the flags field is set to 0 (client update), Rcode2 is set to 0. If the flags field is set to 1 (server update) or 3 (server override of client update), one of two things can happen:

If the server completes the update before acknowledging it, Rcode2 is set to the Rcode for the A resource record.
If the server acknowledges the update to the client before completing the update, Rcode2 is set to 255.

Domain Name — supplied by the server or by the client, depending on the value of the Domain Name field in the originating dhcprequest. If both flags are set to 0, this value must be the value of the domain name sent in the originating dhcprequest. If the flags are set to 1 or if the dhcpack flag is set to 3, the value may be the value of the Domain Name field sent in the originating dhcprequest, if any value was present.

Having certain values in the fields of the dhcprequest and dhcpack messages has certain consequences:

If the flags field is set to 0 for both the dhcprequest and dhcpack messages (client update), the client is responsible for updating the A resource records. By correlation, the client should be responsible for deleting the resource record if it releases its address before expiration.
If the flags field is set to 1 for both messages or to 3 for the dhcpack message (server update), the server is responsible for updating both the A resource records and PTR records. By correlation the server should delete the A resource record and the PTR record. The same mechanism should be followed if the server initiates the lease termination.
If the flags field is set to 0 in the dhcprequest and dhcpack messages (client update), the server must ignore any values in the Rcode1 or Rcode2 fields.
For reasons of security, it is preferred that the client perform the update of the A resource record. (The flags fields are set to 0 in both messages.)
Only A resource records and PTR records are mentioned in the draft standard. Updates of other DHCP options are not covered.
Security is not covered in the draft standard. RFCs 2136 and 2137 address some security issues.

LIMITATIONS AND ADVANTAGES OF MICROSOFT DHCP

As is almost always the case, Microsoft DHCP has certain limitations and advantages. The limitations are

DHCP doesn’t support BOOTP, the legacy protocol on which it is based. BOOTP servers and clients must be excluded from the scope(s) of DHCP servers.
Server-to-server communication isn’t enabled. One DHCP server can’t communicate its IP pool or active leases to another DHCP server. Therefore, if a client’s lease expires when the DHCP server that leased the address is down, the client can’t renew its lease.
DHCP doesn’t have a user-class option that lets a client on a logical subnetwork select one scope on a DHCP server as opposed to another scope also defined on the DHCP server.
DHCP doesn’t distinguish legitimate clients from “bad” clients (for example, on the basis of a MAC address). Anyone who has access to the network or subnetwork configured with a DHCP/BOOTP relay can get an IP address from a DHCP server. Security therefore must be implemented by other means.
Selecting Active Leases on a server scope gives the computer (NetBIOS) name but not the host name (in NT 4.0). This feature is proposed for 2000 Server and is necessary for integration with dynamic DNS.
DHCP has no NIS/NIS + support, although it’s possible to provide IP addresses for NIS and NIS + servers and domains by using options 40 and 41 (NIS domain name and NIS servers) and options 64 and 65 (NIS + domain name and NIS + servers).

Integration with dynamic DNS is proposed for 2000 Server.
DHCP allows interaction with NIS servers through option codes 64 and 65 (see RFC 1541).

DHCP IN A MIXED UNIX AND NT ENVIRONMENT

If you need more functionality than Microsoft DHCP offers in a mixed Unix/NT network, you may want to look at two third-party DHCP products.

Join Systems’ Join IP Manager
Join Systems (originally Competitive Automation) has developed a product specifically for integrating DHCP with dynamic DNS. This product, called Join IP Manager, is currently available for the following platforms:

Solaris = SPARC Solaris 2
Solaris-x86 = Intel Solaris 2
SunOS4 = SPARC SunOS
dec32 = OS/1 v.3.2
dec40 = OS/1 v.4.0
hpux10 = HP-UX 10

Advantages of Join IP Manager include

Security — you can restrict the clients that may obtain IP addresses (or other information) from the DHCP server.
Support for dynamic and static BOOTP addressing.
Integration with dynamic DNS (proprietary).
A Web-based Java GUI that allows administration of the system from a browser.
Secondary addressing — a second pool of addresses can be defined on one DHCP server. This feature is equivalent to superscopes and child scopes within Microsoft DHCP.
Support for NIS/NIS+, RAS server, secure DDNS, and VLSM.

For more information about Join IP Manager, see http://www.join.com.

Sunsoft SolarNet PC
Sunsoft SolarNet PC — Admin 1.5 for Solaris is a DHCP server for Sunsoft PC-NFS clients. Apparently, other clients can also connect to this server but with less than full functionality. This server’s main claim to fame is that it can define not only address pools but also multiple classes within address pools, which allows PC-NFS clients to choose from which classes to receive the IP addresses. For name resolution, this server relies either on NIS or static HOST files. Unfortunately, this server is somewhat complex to set up.

The corresponding client for the Sunsoft SolarNet PC is SunSoft PC-NFS Pro 2.0. To access the full functionality of the server, PC-NFS should be placed on the NT client.

Page: 1, 2, 3, 4

ADS BY GOOGLE