Taking BOOTP One Step Further: DHCP


Even though diskless workstations are a small percentage of the total number of network nodes in the world today, the concept of receiving configuration information from a central server has not gone away. The Dynamic Host Configuration Protocol (DHCP) was developed after BOOTP as a means for providing a workstation (or any other network device) not only with basic configuration information, but also with a lot of other configuration information, including the capability to add vendor-specific items to the networked computer. DHCP is an extension of the BOOTP protocol, and the relevant RFCs require that a DHCP server be backward compatible with BOOTP clients . This means that you can use a DHCP server on a network that contains newer clients that understand this protocol, as well as older clients that still use BOOTP. Like BOOTP, DHCP uses UDP. Messages are sent to port 67 on the DHCP server. Messages from the server are sent to the DHCP client's UDP port 68.

Note

The Dynamic Host Configuration Protocol is discussed in several RFCs. RFC 1541, "Dynamic Host Configuration Protocol," was an early document, and RFC 2131, also titled "Dynamic Host Configuration Protocol," further clarified the protocol. RFC 2131 added a new message type ("DHCPINFORM"), extended the classing mechanism to include vendor-specific classes, and removed the requirement for a minimum lease time. In addition, RFC 1533, "DHCP Options and BOOTP Vendor Extensions," provides for various options to be included in either BOOTP or DHCP packets. RFC 1533 was updated by RFC 2132, which has the same title. You might notice that some of these RFCs were mentioned earlier in this chapter. This shows the close relationship between BOOTP and DHCP.

DHCP supports various configuration message options that a server can offer as a resource to a booting network node. This includes all the standard IP configuration information, such as IP address, subnet mask, and default gateway. The original BOOTP did not include all the options that were listed earlier in Table 29.1. BOOTP (and DHCP as well) has been augmented over the years to allow for more flexibility and to allow for a larger exchange of configuration data between the client and the server. RFC 1533, "DHCP Options and BOOTP Vendor Extensions," added to the options that were first described in RFC 1497 and includes options for both BOOTP and DHCP. RFC 2132 superceded RFC 1533.

Note

If you want to find out about late-breaking developments with regard to DHCP, you might want to look at the Web site www.dhcp.org. This unofficial site contains links to recent developments, as well as links to the RFC documents that relate to DHCP.

Unix users also can use another Web site to download a free version of DHCP. The Internet Software Consortium has developed reference model implementations of DHCP and DNS (BIND) that you can compile on your local system. Visit the consortium's Web site at www.isc.org. This site also sponsors an email mailing list for DHCP topics. You can subscribe or unsubscribe from the main page. The latest version of DHCP available at this Web site at the time of this writing is version 3.0p1, which was released on May 8, 2002. This version fixes a serious vulnerability that was part of the original 3.x version.

RFC 2131 provides for three mechanisms that DHCP servers can use to provide addressing information to clients:

  • Automatic allocation ” DHCP simply assigns a client a permanent address.

  • Dynamic allocation ” The most widely used mechanism, this method leases the address to the client for a certain amount of time, until the client wants to abandon the lease (that is, the workstation shuts down), or until the lease time expires and is not renewed by the client.

  • Manual allocation ” Typically used by the administrator to manually enter addresses into the DHCP server's database for computers or other devices.

The dynamic method is the most useful in a network consisting of a large number of client computers that do not require a static address assignment. Using the dynamic method, the administrator can set the time limit for leases. Before a lease expires, the client will attempt to contact the server to renew the lease. If that fails, the client will seek another server from which it can obtain an IP address lease. This mechanism allows for IP addresses to be conserved when the network topology changes frequently. If an address is not being used because a workstation is down or has been moved to another subnet, the lease will eventually expire and the address can be reused.

Note

So what happens when there is no DHCP server when a client attempts to attain configuration information? Automatic Private IP Addressing (APIPA) can solve this problem for Windows XP and Server 2003. The computer sends out the standard DHCP packet. If no response is received, the computer will assign its own configuration information automatically. The address range used is 169.254.0.1 through 169.254.255.254. The subnet mask is set to 255.255.0.0. Note that this range of IP addresses is not valid on the Internet, and is intended for use only on a LAN. If you connect to the Internet using a router (or a cable or xDSL modem for a SOHO office), then you will need to configure your router to use Network Address Translation (NAT) so that the router can translate between this private address space and the IP address used on the Internet. Most SOHO routers are already configured to use NAT, so you won't have to do anything. For more information about NAT, see Chapter 49, "Firewalls."

APIPA is ideal for a small network. Just set your network configuration to automatically obtain IP configuration information and forget it. For more information about APIPA, see the section near the end of this chapter titled "What Is APIPA?"

These three methods are not exclusive. For example, for most situations it is easy to configure a desktop client to obtain network configuration information automatically using DHCP and then simply boot the client. Yet, for servers that need a static address, such as file/print servers, DNS servers, or Web servers, the administrator can place a manual entry in the server's database so that the DHCP server will always provide the same address when the server boots.

Alternatively, it's still perfectly okay to configure the server manually with static information and then mark the address as allocated (or reserved) on the DHCP server so that it won't try to use the address. When using a small SOHO router with a cable/DSL modem, you can usually specify the range of addresses to be used, or excluded. One instance in which you might want to do this is when using a Windows domain, whether it be Windows NT/2000 or Server 2003. A domain controller needs to have a static address, whereas the clients do not. Simply assign the static addressing information for the domain controllers, and exclude these addresses from being assigned by NAT. Configure the clients to use automatic configuration (NAT), and the domain controllers to use static information.

Another note of interest is that cable/DSL providers also often turn to NAT. There are simply not enough IP addresses to assign every single computer and networking device in the world a unique address any more. So the Internet provider you use has a set of valid IP addresses, which are used to provide a connection to the Internet for the ISP's clients. The clients are then assigned addresses by the ISP via NAT. And then if you use a cable/DSL modem router, a second layer of NAT is used.

Note

A lease from a DHCP server is not as transient as it might seem at first. For example, when a client shuts down for a short period and then reboots, it is not automatically assigned a different IP address than it acquired during its previous lease. Instead, most DHCP servers keep track of IP addresses and the lease time. When a client reboots, it is reassigned the same IP address as long as no other client is using the address. Likewise, when the DHCP server itself is rebooted, all information should be retained in its database so that on reboot it will be able to continue to track existing leases or issue new ones.

However, keep in mind that if you move the client computer to a subnet that is served by a different DHCP server, the computer will be assigned an address from the pool of addresses available to that server and valid on the new subnet, and will thus obtain a new address that is valid on that particular subnet. On the same topic, if you have a server (such as a domain controller) that uses static configuration information, you'll have to change that when moving the server to a different subnet.

The DHCP Packet Format and Additional Options

Similar to BOOTP, DHCP uses a request/reply mechanism, and the packet format is almost the same for both, to provide for backward compatibility. The layout of the packet used by DHCP looks very much like the layout of the BOOTP packet, with a few exceptions. The first 11 fields are the same. However, the last field, which is called the Vendor Extensions area in the BOOTP packet, is called the Options field in the DHCP packet. The format of the options is the same as it was for BOOTP. However, some of the options that are defined in RFC 2132 are specific only to DHCP. The options available for use with BOOTP clients are a subset of those available for use with DHCP clients. Although this field was limited to 64 bytes in the BOOTP packet, it now is a variable-length field that has a minimum of 312 bytes for DHCP options.

Additional Options Available for DHCP Servers

Following is a listing of the options that can be used for both types of clients. This list includes additional options defined in RFC 2132 that can be used, in addition to those found in Table 29.1, with DHCP servers and clients. The options listed here are not for use with BOOTP clients.

  • Requested IP Address (Opcode=50) ” The client can use this field to request a specific IP address.

  • IP Address Lease Time (Opcode=51) ” The client can use this field to request a particular lease time. The server can use this field to fill in the lease time it is willing to offer. The value used in this field is expressed in seconds.

  • Option Overload (Opcode=52) ” This option enables the server to use the fields originally allocated in the DHCP packet for the server name and filename fields to store options. This can be done when there are a large number of options to convey to the client. A value of 1 flags the filename field as holding options. A value of 2 flags the server name field as holding options. A value of 3 indicates that both fields hold options.

  • TFTP Server Name (Opcode=66) ” This field is used to specify the TFTP server when Option Overloading has used the field previously reserved for this.

  • Bootfile Name (Opcode=67) ” This field is used to identify the boot filename when Option Overloading has used the field previously reserved for this.

  • Server Identifier (Opcode=54) ” DHCP servers use this field so that clients can distinguish between multiple DHCP servers answering a request. Clients then will use this address when they need to send unicast messages to the server chosen from the offers received. DHCP clients also use this option when they accept an offer from a server. The value for Server Identifier is simply the IP address of the server.

  • Parameter Request List (Opcode=55) ” This option enables the client to request certain configuration values. A list of option codes follows this option.

  • Message (Opcode=56) ” The DHCP server uses this field to send an error message to the client, including it in the DHCPNAK message. The client can also use this field to specify a reason why it has declined to use certain parameters offered by the server. The client uses the DHCPDECLINE message type for this. Both of these message types are discussed shortly.

  • Maximum DHCP Message Size (Opcode=57) ” This value is the maximum length for a DHCP message that the client can accept. It is used in the DHCPDISCOVER or DHCPREQUEST messages, described later.

  • Renewal (T1) Time Value (Opcode=58) ” This value is the number of seconds that elapse before a client holding an IP address transitions to the renewing state, at which time it will try to renew an existing IP address lease.

  • Rebinding (T2) Time Value (Opcode=59) ” This value is the number of seconds that elapse before a client holding an IP address transitions to the rebinding state.

  • Vendor Class Identifier (Opcode=60) ” This parameter can be used by clients to identify the vendor type and configuration of the client. The DHCP server should respond to this option by using Option 43 to return to the client vendor-specific information. Servers that do not support this option should ignore it.

  • Client Identifier (Opcode=61) ” Clients can use this to specify a unique identifier. The server can use this value to search its database for addressing information for the client. The identifiers chosen by administrators should be unique on the subnet.

Remember that two option values don't have a data component. These are option zero (Pad option) and option 255 (which marks the end of the options list).

Option Overloading

When the Options Overload option is used in addition to the variable-length option field that is typically used for options, two other fields can be used to store options. This can be useful when a client or server has a maximum size for the total DHCP packet that is not large enough to store all the options the client/server needs to negotiate.

The Options Overload option data field can be 1, 2, or 3. As explained earlier, a value of 1 means that the server name field (sname) contains options. A value of 2 means that the boot filename field (file) contains options. A value of 3 means that both fields contain options.

In this case, other options can be used to store the values that are normally placed into these fields, if necessary. The following must also be done:

  • The actual options field must still be terminated with the 255 end option field. The Pad option (zero) can be used to pad the options field.

  • An option cannot be split across the options field, the sname field, or the file field. Each option tag and its value must be contained in the same field in the packet.

  • The order of precedence for interpreting options is to read them first from the options field, then the sname field, and then the file field (depending on whether the Options Overload field is set to 1, 2, or 3).

  • Some options can be used more than once in a packet, and if so, are concatenated by the client.

The DHCP Client/Server Exchange

Although based on the simple BOOTP protocol, the DHCP protocol client/server exchange is a little more complicated. Both sides communicate using a set of messages, as listed here:

  • DHCPDISCOVER ” The client broadcasts this message to locate DHCP servers.

  • DHCPOFFER ” The server uses this message type to offer a set of configuration parameters to the client.

  • DHCPREQUEST ” A client can use this message type to explicitly accept an offer from one server while implicitly implying that it is not going to use the offers made by other servers. This message type also can be used to confirm the configuration data when the client reboots or when it is attempting to extend a lease.

  • DHCPACK ” The client sends this acknowledgment to the server, including the configuration parameters that were accepted.

  • DHCPNAK ” The server sends this negative acknowledgment to the client to inform the client that the address it has requested is not correct. For example, when a client is moved to a new subnet and attempts to renew an old IP address, the server can use this message to inform it that it needs a different one.

  • DHCPDECLINE ” The client can send this message to a server to indicate that a particular IP address is already in use.

  • DHCPRELEASE ” The client can give up an IP address and use this message to tell the server that the address can be recycled.

  • DHCPINFORM ” The client can use this message to request local configuration information from the server when the client has already been configured with an IP address by some other means.

The order in which these messages are exchanged appears in Figure 29.1.

Figure 29.1. The DHCP client/server message exchange is a simple process.

graphics/29fig01.gif

Requesting Configuration Information from the DHCP Server

The communication process between the DHCP client and server is simple. The client initially broadcasts a DHCPDISCOVER message on the local subnet to which it is attached. If known, the client can insert configuration options in this discover packet, such as the IP address and a requested lease time.

All DHCP servers that receive the DHCPDISCOVER request can respond with a DHCPOFFER message, including a suggested IP address and any other options it can offer. Because more than one server can respond to a DHCP request (remember that DHCP packets can be relayed across routers using BOOTP relay agents ), it then must decide which offer to accept.

Note that in Figure 29.1 the DHCPOFFER packet is sent as a unicast packet instead of a broadcast packet. The DHCP server can unicast or broadcast messages, which is determined in this way:

  • If the Gateway IP Address (giaddr) field in the client's packet is a nonzero value, the server assumes that this is the address of an intermediary router and unicasts the packet to this address, using the DHCP server port (67).

  • If the Gateway IP Address field is zero but the Client's IP Address (ciaddr) field is not, the server unicasts the packet to this address that the client has filled in.

  • If both of these fields are zero and the broadcast flag bit is set in the client's packet, the server broadcasts the packet to the client.

  • If both of these fields are zero and the broadcast flag bit is not set, the server unicasts the packet to the client's hardware address and the Client's IP Address (yiaddr) field.

When a selection has been made, the client broadcasts another packet that contains a DHCPREQUEST message. This packet must include the server identification option, indicating from which server the client has chosen to accept the offer.

When the servers see this broadcast packet, those not chosen by the client use it as a flag that their offer was not accepted, and no further communications need to take place between the client and these servers. The chosen server binds the client to the addressing configuration information, and then sends the client a DHCPACK acknowledgment message. This packet also contains the set of agreed-upon options and parameters. If the server cannot grant the request ”the IP address requested by the client is already in use, for example ”the server responds with a DHCPNAK negative acknowledgment message.

After the client receives an acknowledgment packet indicating that it can use the configuration information, it still must perform some checks to be sure that the information is correct and will allow the client to function on the network. A few simple checks are performed. For example, the client can use ARP to check that the IP address it is about to use is not already in use on the network. This can happen when a DHCP server has been configured incorrectly. If there are no challenges, the client has the information it needs and the configuration of its protocol stack is performed. The client now can participate in the network.

The Address Resolution Protocol (ARP) is covered in more detail in Chapter 25.


If this last-minute test informs the client that the address is already in use, the client sends the DHCP server a DHCPDECLINE message. In this case, or if the client has received a DHCPNAK message from the server, the process backs off for a few seconds and begins again.

If the client does not receive either the DHCPACK or the DHCPNAK message within a set amount of time, it also restarts the configuration process.

Implicitly Releasing Configuration Information

In a DHCP environment, configuration information usually is granted for a set amount of time, called a lease . When the lease expires and the client has made no attempt to renew it, the configuration information can be used for another client. This can happen if a computer is moved from one subnet to another. Eventually, the original address it had obtained on the previous subnet will expire.

A client also can choose to implicitly release the addressing information. For example, a client that is gracefully shutting down can send a DHCPRELEASE message to the DHCP server, telling it that the lease is no longer needed.

The ipconfig command can be used by Windows XP Professional/2000 Client and Windows 2003 servers to release or renew a lease obtained from a DHCP server. To release an address lease, use the following syntax:

 ipconfig /release ipconfig /renew 

If more than one network adapter is installed in the system, you can also specify the name of the adapter on the command line. This command releases the bindings obtained from DHCP servers for all adapters. If you are unsure of the adapter name, use the following command to display the current IP configuration for your computer:

 ipconfig /all  more 

The ifconfig command can be used on Unix/Linux systems to perform configuration tasks related to IP. The syntax of this command varies from one implementation of Unix to another. However, this command on a Unix system performs a wider variety of tasks than the Windows ipconfig command, so use caution when using ifconfig . This ifconfig command can be used to configure each network interface on the Unix system, including address, subnet mask, and other important parameters. A general version of the command to release an IP address leased from a DHCP server for Unix is

 /sbin/ifconfig  interface  release 

Note that not all versions of Unix use the ifconfig command to manage DHCP, either the server or the client. As always with Unix, check the printed documentation and the manual (man) pages.

For example, Red Hat Linux uses the command dhclient to obtain a lease ( dhclient -l ) or release an address ( dhclient -r ).

Reusing an Address After Reboot

When a client is rebooted, it does not have to obtain a new IP address. Instead, it can request that the address assignment made from a previous exchange with a DHCP server be used. In this case, when the client reboots, it broadcasts a DHCPREQUEST packet that contains the requested IP address option. Servers that know about this configuration information should respond with a DHCPACK message to the client. However, if the information is invalid ”the client is now on a new subnet, for example ”the servers should respond with a DHCPNAK message to force the client into beginning the lease process again.

The client also makes its own checks, again using ARP to find out whether the address is in use by another client. If so, it sends a DHCPDECLINE message back to the server and starts the process over.

Using the DHCPINFORM Message

It is quite acceptable for the network administrator to configure some of the IP configuration information on a client and then let DHCP be used for the remaining data. For example, a client can be manually configured with an IP address and subnet mask by the administrator, and then set to get the remaining information from a DHCP server. In this case, the client will broadcast a DHCPINFORM packet that contains the manually configured information. The server then responds to this message with a DHCPACK message. However, the server should not fill in the fields telling the client what its IP address should be and should not include any lease time values. Additionally, the server should not check its own database to see whether a binding for this address already exists.

Because the DHCP server knows the client's address, the DHCPACK message is sent as a unicast packet instead of a broadcast one.

Lease Expiration and Renewal

If a client is using a lease and the lease time expires, the client must immediately stop using the IP address granted by the lease. There are two timers that the client uses to keep track of when and how to renew a lease. These are called T1 and T2. After the time value specified by T1 expires, the client begins trying to renew the existing lease. The client makes attempts to contact the DHCP server from which the lease was obtained to get this extension. At this point, the client is said to be in the RENEWING state.

If no response is received from the DHCP server when the time stored in T2 has expired , the client enters a REBINDING state and attempts to communicate with any other DHCP server so that it can obtain a new IP address.

Obviously, T1 is a value that is less than the lease time, because a lease must be renewed before it expires. The value for T2, likewise, must be longer than that for T1.

If a client is unable to renew or acquire a lease before the expiration of the current lease, the client must stop using the information acquired through the lease and enter into an INIT state to start the process of acquiring configuration information all over again.

After a client has successfully renewed a lease or acquired a new one, it is said to be in the BOUND state. This is the normal state at which configuration is complete and the client computer is functional on the network.

In addition, an administrator usually can renew a release manually. The Windows command ipconfig can be used for this:

 ipconfig /renew 

As with the /release option, you optionally can place an adapter name on the command line to specify an adapter for this operation. If none is specified and more than one adapter is installed and configured using DHCP, all adapters will undergo the renew process.

Overview of How a DHCP Server Chooses the Client's IP Address

RFC 2131 summarizes the process that a DHCP server goes through to decide what IP address to return to a client:

  • Use the client's current address as recorded in the client's current address binding, or

  • Use the client's previous address recorded in a previous binding that has already expired or has been released, as long as it's not already in use, or

  • Use the address found in the Requested IP Address option if specified and if not already in use, or

  • Use a new address from the pool of available addresses

In the last case, an address is selected to match the client's subnet or the subnet of the relay agent that forwarded the DHCP request.



Upgrading and Repairing Networks
Upgrading and Repairing Networks (5th Edition)
ISBN: 078973530X
EAN: 2147483647
Year: 2003
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net