The Dynamic Host Configuration Protocol Port (DHCP)

The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts.

DHCP is built on a client/server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server.

A host should not act as a DHCP server unless explicitly configured to do so by a system administrator. The diversity of hardware and protocol implementations in the Internet would preclude reliable operation if random hosts were allowed to respond to DHCP requests.
For example, IP requires the setting of many parameters within the protocol implementation software. Because IP can be used on many dissimilar kinds of network hardware, values for those parameters cannot be guessed or assumed to have correct defaults. Also, distributed address allocation schemes depend on a polling/defense mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.

DHCP supports three mechanisms for IP address allocation:

• In automatic allocation, DHCP assigns a permanent IP address to a client.
• In dynamic allocation, DHCP assigns an IP address to a client for a limited period of time (or until the client explicitly relinquishes the address).
• In manual allocation, a client's IP address is assigned by the network administrator, and DHCP is used simply to convey the assigned address to the client.

A particular network will use one or more of these mechanisms, depending on the policies of the network administrator.

Dynamic allocation is the only one of the three mechanisms that allows automatic reuse of an address that is no longer needed by the client to which it was assigned. Thus, dynamic allocation is particularly useful for assigning an address to a client that will be connected to the network only temporarily or for sharing a limited pool of IP addresses among a group of clients that do not need permanent IP addresses. Dynamic allocation may also be a good choice for assigning an IP address to a new client being permanently connected to a network where IP addresses are sufficiently scarce that it is important to reclaim them when old clients are retired.

Manual allocation allows DHCP to be used to eliminate the error-prone process of manually configuring hosts with IP addresses in environments where (for whatever reasons) it is desirable to manage IP address assignment outside of the DHCP mechanisms.

Terminology

DHCP client

A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address.

DHCP server

A DHCP server is an Internet host that returns configuration parameters to DHCP clients.

BOOTP relay agent

A BOOTP relay agent or relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification.

Binding

A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers.

Goal

The following list gives general design goals for DHCP.

• DHCP should be a mechanism rather than a policy. DHCP must allow local system administrators control over configurationparameters where desired; e.g., local system administrators should be able to enforce local policies concerning allocation and access to local resources where desired.
• Clients should require no manual configuration. Each client should be able to discover appropriate local configuration parameters without user intervention and incorporate those parameters into its own configuration.
• Networks should require no manual configuration for individual clients. Under normal circumstances, the network manager should not have to enter any per-client configuration parameters.
• DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.
• A DHCP client must be prepared to receive multiple responses to a request for configuration parameters. Some installations may include multiple, overlapping DHCP servers to enhance reliability and increase performance.
• DHCP must coexist with statically configured, non-participating hosts and with existing network protocol implementations.
• DHCP must interoperate with the BOOTP relay agent behavior as described by RFC 951 and by RFC 1542.
• DHCP must provide service to existing BOOTP clients.
  
  

The following list gives design goals specific to the transmission of the network layer parameters. DHCP must:

• Guarantee that any specific network address will not be in use by more than one DHCP client at a time,
• Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request,
• Retain DHCP client configuration across server reboots, and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,
• Allow automated assignment of configuration parameters to new clients to avoid hand configuration for new clients,
• Support fixed or permanent allocation of configuration parameters to specific clients.
  

Configuration of the DHCP port

The Dynamic Host Configuration Protocol port is labelled within the Abilis CPX with the acronym "DHCP" and it is provided with the parameters described in this section.

Here is an example on how to display the DHCP port parameters. Shown values are the default ones.

[11:56:24] ABILIS_CPX: D P PO:DHCP

PO:912 ------------------------------------------------------------------------
DHCP   LOG:DS          lowpo:902    ACT:NO            srvport:67   cliport:68    
       msg-len:1472    mode:RELAY   MAX-HOPS:4        SRV:#    
       LOCIPADD:R-ID (192.168.000.060)   
       WDIR:C:\APP\DHCP\                     

The parameters set changes on the base of the type of the DHCP port behaviour, i.e. on the base of the current value of the mode: parameter. By default it is set to "RELAY".

Here is an example of DHCP port parameters, when the mode: parameter is set to "SERVER"

[11:56:24] ABILIS_CPX: D P PO:DHCP

PO:912 - Not Saved (SAVE CONF), Not Refreshed (INIT) --------------------------
DHCP   ------------------------------------------------------------------------
       LOG:DS          lowpo:902    ACT:NO            srvport:67   cliport:68    
       msg-len:1472    mode:SERVER  max-clients:300   ICMPCHK:NO      
       MAC-FILTER:YES  MAC-LIST:#                     MAC-RULE:DENY  
       WDIR:C:\APP\DHCP\                     

To activate changes made on the parameters displayed by low case characters, it is needed to restart the system; on the contrary for activating changes made on upper case parameters it is enough to execute the initialization command INIT PO:.
Changes made on LOG: parameter are immediately active.

The "Not Saved (SAVE CONF)" message is displayed every time the port configuration is modified but not saved with the SAVE CONF command.

The "Not Refreshed (INIT)" message is displayed every time the port configuration is modified but not refreshed with the INIT PO: command.

Detail of the DHCP port parameters

Statistics of the DHCP port

Example on how to show state and statistics of the DHCP port through the command D S:

[11:40:35] ABILIS_CPX: D S PO:DHCP

PO:912 ------------------------------------------------------------------------
DHCP   MODE:RELAY     STATE:INACT     
       ------------------------------------------------------------------------
       Server mode
       -----------|---INPUT---|--OUTPUT---|-----------|---INPUT---|--OUTPUT---|
       REQUESTS   |          0|           |RESPONSES  |           |          0|
       CHAR       |          0|          0|PCK        |          0|          0|
       LONG       |          0|          0|BAD-FORMAT |          0|           |
       UNK-IPP    |          0|           |           |           |           |
       DISCOVER   |          0|           |OFFER      |           |          0|
       REQUEST    |          0|           |ACK        |           |          0|
       DECLINE    |          0|           |NAK        |           |          0|
       RELEASE    |          0|           |           |           |           |
       INFORM     |          0|           |
       ------------------------------------------------------------------------
       Relay mode
       -----------|---INPUT---|--OUTPUT---|-----------|---INPUT---|--OUTPUT---|
       REQUESTS   |          0|          0|RESPONSES  |          0|          0|
       HOP-EXCEED |          0|           |BAD-GW     |          0|           |
       ------------------------------------------------------------------------

Example on how to show extended statistics of the DHCP port through the command D SE:

[17:12:45] ABILIS_CPX: D SE PO:DHCP

PO:912 ------------------------------------------------------------------------
DHCP   --- Cleared 000:00:07:09 ago, on 02/04/2004 at 17:05:39 ----------------
       ------------------------------------------------------------------------
       Server mode
       -----------|---INPUT---|--OUTPUT---|-----------|---INPUT---|--OUTPUT---|
       REQUESTS   |          0|           |RESPONSES  |           |          0|
       CHAR       |          0|          0|PCK        |          0|          0|
       LONG       |          0|          0|BAD-FORMAT |          0|           |
       UNK-IPP    |          0|           |           |           |           |
       DISCOVER   |          0|           |OFFER      |           |          0|
       REQUEST    |          0|           |ACK        |           |          0|
       DECLINE    |          0|           |NAK        |           |          0|
       RELEASE    |          0|           |           |           |           |
       INFORM     |          0|           |
       ------------------------------------------------------------------------
       Relay mode
       -----------|---INPUT---|--OUTPUT---|-----------|---INPUT---|--OUTPUT---|
       REQUESTS   |          0|          0|RESPONSES  |          0|          0|
       HOP-EXCEED |          0|           |BAD-GW     |          0|           |
       ------------------------------------------------------------------------

The information "Cleared DDD:HH:MM:SS ago, at DD/MM/YYYY HH:MM:SS", referred by the extended statistics, shows the elapsed time from the last reset of the statistics (by the format "days:hours:minutes:seconds") and date/time of its execution (by the format "day/month/year" and "hours:minutes:seconds").

Details of the state fields and statistics of the DHCP port

DHCP bindings table

A bindings table is the memory data base which stores bindings allocated for DHCP clients.

A binding record includes the information about allocated IP address, start time and end time of lease, profile which is currently used by a DHCP client and some other information.

The Table of DHCP bindings is used in server mode only.

It is stored in the "DHCP.BND" file in the location defined by the WDIR: parameter, that is by default the "C:\APP\DHCP\" directory, and it allows storage of up to max-clients: bindings, one per each record.
Every one minute the DHCP server checks the bindings table in the memory and, if the table was changed since the last time it was updated, the DHCP server saves all bindings to the file.

During Abilis CPX DHCP port start-up the DHCP driver tries to read the bindings table from the disk.
If the DHCP server finds the bindings file, it check wheter the file is can be updated, making a write operation try.
If the writing attempt is successful the DHCP server goes to the ACTIVE state.
If writing attempt fails the DHCP server goes to the STOP state; it writes a warning message into the System Log (i.e. "W: DHCP STOPPED") and it doesn't load the bindings "DHCP.BND" file content.
If the DHCP server doesn't find the bindings file, it tries to create it. If it is not possible the server goes to the STOP state and it writes a warning message into the System Log (i.e. "W: DHCP STOPPED").

If the server is in the STOP state you must check the disk (remove protection, etc.), try to remove the cause of stopped state and execute the INIT PO: command. The server will retry to check and load the binding file.

After loading the bindings from the "DHCP.BND" file, the DHCP server checks the bindings according to the current configuration of the DHCP driver and binding record that don't conform to the current configuration will be marked as "not valid" and they will not be used by the DHCP server.

The DHCP server makes the next checks of the loading bindings and marks the binding as "invalid" in all the following cases:

• The subnet record which is coressponding to the IP address from the binding is not found in the subnets table.
• The profile identifier from the binding is not found in the the profiles table.

If the binding is static (i.e. allocated from the hosts):

• The host record with the IP and MAC addresses which are corresponding to the IP and MAC addresses from the loading binding is not found in the hosts table.
• The IP address from the binding is found in one of the pools of the subnet record (i.e. if the corresponding subnet record was found).

if the binding is dynamic (i.e. allocated from the pools):

• The host record with the IP and MAC addresses which are corresponding to the IP and MAC adresses from the loading binding is found in the hosts table;
• The IP address from the binding is not found in one of the pools of the subnet record (i.e. if the corresponding subnet record was found);

Commands for handling Table of DHCP bindings are described in the DHCP bindings section of the document Commands relating to DHCP.

The available commands are the following:

In the following example are displayed all the entries of the table of Table of DHCP bindings. Displayed values are samples.

[19:07:12] ABILIS_CPX: D DHCP BIND

------------------+----------------+------+-----------------+------------------
MAC:              |IP              |PROF: |Last request(GMT)|Expiry on(GMT)   
------------------+----------------+------+-----------------+------------------
11-11-23-11-11-11  192.168.000.123    128  20/12/2002 10:10  29/12/2002 10:10     
11-11-23-11-11-11  010.010.010.005     21  20/12/2002 10:16  21/11/2002 10:16 E
11-11-23-11-11-15  192.168.000.150   NONE  20/12/2002 10:20  23/12/2002 10:10     
11-11-23-11-11-12  192.168.000.124      5  20/12/2002 10:30  21/11/2002 10:30 E
11-11-23-11-11-12  192.168.000.124      5  20/12/2002 10:40  23/12/2002 10:10

In the following example are displayed all the entries of the table of Table of DHCP bindings in extended format. Displayed values are samples.

[19:07:12] ABILIS_CPX: D DHCP BINDE

----+-----+-------------------+-----------------+-------+----------------------
 O: | ST: | MAC:              | IP:             | PROF: | Last request(GMT)   
                                                        | Expiry on(GMT)   
----+-----+-------------------+-----------------+-------+----------------------
 H    EXP   11-11-23-11-11-11   192.168.000.123     128   21/12/2002 10:10:10
                                                          21/12/2002 11:10:10
-------------------------------------------------------------------------------
 P    ACT   11-11-23-11-11-11   010.010.010.005     128   21/12/2002 10:10:10
                                                          29/12/2002 12:10:00
-------------------------------------------------------------------------------
 H    REL   11-11-23-11-11-15   192.168.000.150     128   21/12/2002 10:10:10
                                                          24/12/2002 11:10:10
-------------------------------------------------------------------------------
 H    ABD   11-11-23-11-11-30   000.000.000.000      10   21/12/2002 10:10:10
                                                          23/12/2002 11:10:10
-------------------------------------------------------------------------------
 P    ACT   11-11-23-11-11-12   192.168.000.124    NONE   21/12/2002 10:10:10
                                                          25/12/2002 11:10:10
-------------------------------------------------------------------------------
 P    EXP   11-11-23-11-11-18   192.168.000.100       5   21/12/2002 10:10:10
                                                          21/12/2002 11:10:10
-------------------------------------------------------------------------------

Binding records can also be cleared, however this action is very dangerous and it should carefully evaluated by the user.

The current user interface allows the clear all the records currently present in the database in memory and/or to clear a specific record by specifying the IP address binded to the client. In both cases the user confirmation is requested before the command execution.

Here there are few samples of bindings clear commands:

[15:00:45] ABILIS_CPX: C DHCP BIND IP:A

YOU ARE GOING TO DELETE THE WHOLE CONTENT OF THE DHCP BINDINGS DATA BASE IN MEMORY.
DO YOU WANT TO PROCEES (Y/N)? Y

COMMAND EXECUTED

[15:00:45] ABILIS_CPX: C DHCP BIND IP:192.168.0.60

YOU ARE GOING TO DELETE THE SPECIFIED DHCP BINDING ENTRY FROM THE DATA BASE IN MEMORY.
DO YOU WANT TO PROCEES (Y/N)? Y

COMMAND EXECUTED

Details of Binding record's parameters

Table of types of hardware addresses

Print this page