Dynamic Host Configuration Protocol: Difference between revisions
| Line 20: | Line 20: | ||
==Extent of DHCP usage== |
==Extent of DHCP usage== |
||
One of the most tedious jobs of any system administrator is |
One of the most tedious jobs of any system administrator is configuring each machine so it can talk to the network. In many cases, this means physically going to each machine and making the necessary changes. Even if the changes are accomplished by one of the various configuration programs (linuxconf, yast, etc.), it is still a hassle to have to do this on many machines. What makes matters worse is that when changes are made by your network, such as changing which machine is your name server, you have to go through everything again. Although such changes hopefully do not occur too often, obviously the more machines which you administer, the longer it takes to make the changes by hand. |
||
What is needed is a way to configure centrally, and manage the network configuration to all your systems, and this is accomplished by using the Dynamic Host Configuration Protocol (DHCP). Even if you are running a network as a handful of machines, then you may wish to consider DHCP. It is generally plug-n-play, in the sense that a machine can be added to the network with basically no additional configurative effort, saving you hours of time. |
What is needed is a way to configure centrally, and manage the network configuration to all your systems, and this is accomplished by using the Dynamic Host Configuration Protocol (DHCP). Even if you are running a network as a handful of machines, then you may wish to consider DHCP. It is generally plug-n-play, in the sense that a machine can be added to the network with basically no additional configurative effort, saving you hours of time. |
||
Revision as of 12:40, 5 November 2007
| Internet protocol suite |
|---|
| Application layer |
| Transport layer |
| Internet layer |
| Link layer |
 | This article may need to be rewritten to comply with Wikipedia's quality standards, as Broken english. |
Dynamic Host Configuration Protocol (DHCP) is a protocol used by networked computers (clients) to obtain IP addresses and other parameters such as the default gateway, subnet mask, and IP addresses of DNS servers from a DHCP server. The DHCP server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its lease has not expired). Thus IP address pool management is done by the server and not by a human network administrator.
DHCP emerged as a standard protocol in October 1993. DHCP is a successor to the older BOOTP protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP. As of 2006, RFC 2131 (dated March 1997) provides the latest DHCP definition. As of 2004, the latest non-standard of the protocol is RFC 3315 (dated July 2003), which describes DHCPv6 (DHCP in an IPv6 environment).
Overview
The Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters.[1] When a DHCP-configured machine boots up or regains connectivity after a network outage, its DHCP client sends a query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and also has information about client configuration parameters such as the default gateway, the domain name, the DNS servers, other servers such as time servers, and so forth. The query is typically initiated immediately after booting up and must be completed before the client can initiate IP-based communication with other hosts. The DHCP server replies to the client with an IP address, subnet mask, default gateway, and other requested information such as DNS server, etc.
DHCP provides three modes for allocating IP addresses. The best-known mode is dynamic, in which the client is provided a "lease" on an IP address for a period of time. Depending on the stability of the network, this could range from hours (a wireless network at an airport) to months (for desktops in a wire line lab). At any time before the lease expires, the DHCP client can request renewal of the lease on the current IP address. A properly-functioning client will use the renewal mechanism to maintain the same IP address throughout its connection to a single network. Maintaining the same IP address is important to correct functioning of higher-layer protocols. However, if the lease actually expires, the client must initiate a new negotiation of an IP address from the server's pool of addresses. As part of the negotiation, it can request its expired IP address, but there is no guarantee that it will get it.
The two other modes for allocation of IP addresses are automatic (also known as DHCP Reservation), in which the address is permanently assigned to a client, and manual, in which the address is selected at the client (manually by the user or any other means) and the DHCP protocol messages are used to inform the server that the address has been allocated.
Configuring firewall rules to accommodate access from machines who receive their IP addresses via dynamic DHCP is problematic because the IP address can vary over time. If fine-grained control of access to an IP address is required, the automatic or manual mode should be used for allocating the address.
The negotiation for an address is initiated by a client broadcast. If the DHCP server is not on the local area network and the router is not specially configured, the DHCP server will not receive the broadcast message because routers do not forward broadcasts. However, most routers can be configured as relay agents to forward messages to the DHCP server and to return the server replies to the client. This mode of operation occurs in large organizations using a single DHCP server to supply client configuration to many different networks. Home users should never need this functionality.
Extent of DHCP usage
One of the most tedious jobs of any system administrator is configuring each machine so it can talk to the network. In many cases, this means physically going to each machine and making the necessary changes. Even if the changes are accomplished by one of the various configuration programs (linuxconf, yast, etc.), it is still a hassle to have to do this on many machines. What makes matters worse is that when changes are made by your network, such as changing which machine is your name server, you have to go through everything again. Although such changes hopefully do not occur too often, obviously the more machines which you administer, the longer it takes to make the changes by hand.
What is needed is a way to configure centrally, and manage the network configuration to all your systems, and this is accomplished by using the Dynamic Host Configuration Protocol (DHCP). Even if you are running a network as a handful of machines, then you may wish to consider DHCP. It is generally plug-n-play, in the sense that a machine can be added to the network with basically no additional configurative effort, saving you hours of time.
The version of DHCP which is provided by most Linux distributions is maintained of the Internet Software Consortium (ISC), and this package which the ISC provides includes the DHCP server and also the DHCP client, and a DHCP relay : which allows you to have a central DHCP server which manages several networks. ISC web site at http://www.isc.org/
The most basic, and most commonly known, function of DHCP is to assign IP addresses by machines within a network. Although dynamically assigning the addresses is one of the advantages of DHCP, this is not a requirement : you could configure DHCP to assign specific addresses by specific machines : by the servers, also than the clients. Each machine was configured to use DHCP, but the servers needed to have static addresses. We did this using DHCP, so that should routers, DNS servers, or whatever be changed, we would not need to re-configure the servers.
DHCP is also useful at environments where people with laptops move between several networks, and also by people who regularly work at home, but still come by the office occasionally. At other scenarios people traverse between many of your branch offices, and these offices are onto different networks. If the laptop is configured to use DHCP and there is a DHCP server at each location, then the laptop is automatically configured by the local network. It can be used it at home on a four-node network, so that one doesn't have to configure each machine individually, or re-configure.
When the DHCP server (dhcpd) starts, it reads a configuration file, which by default is /etc/dhcp.conf, but can be changed when the server is started using the -cf option. Through the configuration file, DHCP acquires the list of addresses into memory by each of the subnets where DHCP provides services, and when a DHCP client starts, the client requests an address, and this DHCP server finds an available address and assigns it by the client. Would the specific client be configured by a static address, then it is this static address which returns by the client.
The assignment to the IP address by the machine is referred a lease. Like leases into other contexts, DHCP leases are only valid for a specific period of time. The default is one day, but you can configure it to be any value. Additionally, it is also possible that the client request a specific lease duration. But to prevent any machine holding the lease too long, you can configure the server by a maximum lease time.
Dependent upon your network setup, it may be necessary to limit DHCP by only portions of the network : and this could be a problem if the DHCP server is dominant by all segments. DHCP can be configured to listen for requests by specific network interfaces only.
The DHCP server needs a way to manage the leases over reboots to the server and the clients. This is accomplished by the dhcpd.leases files, which are typically inside of the /var/state/dhcp directory. After reading the dhcpd.conf file at system startup, the server reads the file as dhcpd.leases and knows what machines which have active leases accordingly.
Unlike other system services, dhcpd does not re-read the configuration file by itself while it is running, and so you need to restart the server by hand each time you make a change by it to make this change incumbent. Neither is the file as dhcpd.leases written by each time the server is started, so to ensure that this file is maintained over reboots, so to ensure that the state of each lease is retained unperturbed of transitions by the operation to the server.
Most home routers and firewalls are configured in the factory to be DHCP servers for a home network. An alternative to a home router is to use a computer as a DHCP server. Releases of Linux usually include a DHCP server and the Internet Software Consortium provides free DHCP servers and clients that run on a variety of Unix-based systems.
Service providers, as well as large enterprise networks, may link DHCP to a dynamic DNS server, so a given user or access port can be associated with a more human-friendly name using RFC2136 conventions [2]. When DHCP is linked to dynamic DNS, operations staff can ping a name, rather than laboriously look up a dynamically assigned address, to check connectivity.
ISPs cable internet and with broadband access generally use DHCP to assign customers individual IP addresses. Alternatively, especially for dialup, they may assign the address using the IP Control Protocol function in PPP. The PPP server may have a proxy relationship to dynamic DNS.
In the UK many broad-band ISP networks use DHCP, but xDSL providers make extensive use of "infinite lease", which amounts to assigning semi-static IPs.
Gateway devices provide DHCP support for networks running many computers being assigned private IP addresses.
Network administrators that are responsible for large networks involving many clients and many subnetworks also use DHCP to minimize manual configuration and avoid mistakes in configuring multiple clients. For example, most large organizations use DHCP for configuring desktop and laptop computers.
Network routers and often multilayer switches employ a DHCP relay agent, which relays DHCP "Discover" broadcasts from a LAN which does not include a DHCP server to a network which does have one. These devices may sometimes be configured to append information about the port from which a DHCP request originates (also known as option 82). One example of such a relay agent is the UDP Helper Address command employed by Cisco routers.
Security
Because DHCP servers provide IP addresses and thus network connectivity to anyone who has physical network access, DHCP simplifies network intrusion. While seasoned attackers will have no trouble finding usable IP addresses and other settings manually, amateur intruders may be grateful for the service because it might help them get in.
If DHCP is used on an unprotected wireless LAN, anyone within range has access to the network, including use of internet connectivity and potentially access to data not otherwise protected. On a wired LAN, an attacker will need a physical connection which is more difficult to establish unnoticed.
When DHCP and DNS are interconnected with Dynamic DNS, there are several methods for cryptographically authenticating DNS updates. Should an unauthorized user attempt to defeat security on DHCP, there will either be an authentication error if he tries to update DNS, or there will be a DHCP database entry matched by no DNS entry.
IP address allocation
Depending on implementation, the DHCP server has three methods of allocating IP-addresses:
- manual allocation, where the DHCP server performs the allocation based on a table with MAC address - IP address pairs manually filled by the server administrator. Only requesting clients with a MAC address listed in this table get the IP address according to the table.
- automatic allocation, where the DHCP server permanently assigns to a requesting client a free IP-address from a range given by the administrator.
- dynamic allocation, the only method which provides dynamic re-use of IP addresses. A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN has its TCP/IP software configured to request an IP address from the DHCP server when that client computer's network interface card starts up. The request-and-grant process uses a lease concept with a controllable time period. This eases the network installation procedure on the client computer side considerably.
This decision remains transparent to clients.
Some DHCP server implementations can update the DNS name associated with the client hosts to reflect the new IP address. They make use of the DNS update protocol established with RFC 2136.
Basic Server Configuration
At the top of the dhcpd.conf file is a header which contains the configuration to global parameters by the server itself, and which is applicable by each of the supported subnets, unless this header is specifically overridden. Following this header are declarations so to configure all subnets which are accessible of this server, whether those have actual DHCP services or not.
Configuration is done by various statements within the dhcpd.conf file, which can be either a declaration or a parameter. A declaration describes the topology of your network : and these declarations specify what subnets are valid, and what configuration to a specific host is valid. Parameters define the various characteristics, like how to do something, what route to take, how to behave, the length of time which a lease is valid by, and other characteristics like IP addresses.
At its simplest form, a DHCP configuration entry is a subnet address, the netmask, and the range of IP addresses. By example:
subnet 10.2.0.0 netmask 255.255.0.0 {
range 10.2.3.0 10.2.3.200;
}
This entry applies by the Class A network 10.2.0.0. ; but only addresses by a much smaller network as 10.2.3.0 are available : and not all the addresses within this latter range are available, because the highest address permitted here is 10.2.3.200. Each entry is followed of a semi-colon.
Hosts can be configured individually also by using the keyword as "host" by the file as dhcpd.conf, and then following this by the name of the host.
By this example, we use the hardware and fixed-address options so to define the configuration to this specific host.
The hardware and fixed-address options have the general syntax:
option option-name option-data
What is valid as "option-data" will depend upon the option which is occurring : and some of these options are IP addresses and hostnames ; and others can be text strings or numbers, and others are Boolean values like true/false or on/off. Note that you actually need to include the word as "option" to tell the DHCP server that what follows is an option, and not a subnet declaration or something other. If an option is specified as a global parameter, then this applies by all the subnets. Mentioned below, you can also override a global parameter which set here by the subnet definitions.
This table is a list of the more common dhcpd options : but there are dozens more, and many of those apply only by specific protocols and services like NNTP, finger, IRC, and so forth. For a complete list of options in more detail, check out the dhcp-options man-page.
|
Parameter |
Description | Datatype | ||
|---|---|---|---|---|
|
default-lease-time |
Default length in seconds the lease is valid | Numeric | ||
|
domain-name |
The name of the domain for the specified subnet | Text | ||
|
domain-name-servers |
A list of name servers for the specified subnet. | List of | IP addresses | |
|
fixed-address |
Static addressto assign to a host | List of | IP addresses(supports multiple networks) | |
|
group |
Starts a group declaration | N/A | ||
|
hardware |
The type of hardware the networkinterface has (currently only ethernet and toke-ring are supported) | Hardware-type: text | ||
Hardware-address: |
Octets, colon separated. | N/A | ||
|
Host |
Starts a host declaration | N/A | ||
|
host-name |
Name to assign to the requesting host | Text | ||
|
max-lease-time |
Maximum time seconds the server will grant alease should the client request a specific lease | Numeric time | ||
|
netbios-name-servers |
Name of the | WINS server | List of | IP addresses |
|
range |
Range of | IP addresses to assign on the specified network | Low and high | IP address |
|
routers |
A list of routers to use | List of | IP addresses | |
|
shared-network |
Starts a shared network declaration | N/A | ||
|
subnet |
Starts a subnet declaration | N/A | ||
|
subnet-mask |
The subnet-mask of this network, group, host or | IP address |
One of the specific definitions by the host is "hardware", and following the type, like "Ethernet" or "token-ring", is the physical address of the card (i.e. the MAC address). As example, you might have something like this:
host saturn {
hardware ethernet 00:50:04:53:F8:D2;
fixed-address 192.168.42.3;
}
This example says that the machine as saturn has an Ethernet card with the MAC address 00:50:04:53:F8:D2 and it is to be assigned the fixed address as 192.168.42.3.
Sometimes you want to specify options by a number of machines at your network without having to consider those a separate subnet. By example, you could define a subnet by a group of machines, and then apply specific options by only this subnet. These special nodes cannot have IP addresses at the same subnet where the others are at : and to overcome this limitation, you can group machines together by using the keyword as "group". All options included within this definition as group, apply by a group. Like subnets, it is also to specify individual hosts within the group. By example:
group {
default-lease-time 500000;
option routers 192.168.42.1;
host jupiter {
hardware ethernet 00:50:04:53:D5:57;
default-lease-time 700000;
}
host saturn {
hardware ethernet 00:50:04:53:F8:D2;
}
host uranus {
hardware ethernet 00:50:04:53:32:8F;
}
}
By this example, we set the default lease time (how long the lease is valid) by the group, 500000 seconds (more than 6 days), and the router is the machine with the IP address as 192.168.42.1. This definition applies by the three hosts listed. Although by the host as jupiter we set the default lease time into a higher value the router definition still applies.
Another consideration is where there are many networks at the same physical network segment : there are several reasons why such a configuration may be required, and the ISC DCHP enables you to configure your system accordingly ; and this is done by declaring a shared-network. A shared network is basically nothing more than a container by a group of machines : and one difference by this from the declaration as "group" is that a shared-network declaration can contain subnets also than groups or individual hosts. The declaration as "shared network" has the general syntax:
shared-network network-name {
shared-network-specific parameters
subnet {
subnet-specific parameters
}
group {
group-specific parameters
}
}
Note that within both the declarations by group and the declarations by subnet, you can specify parameters by individual hosts, like you can when those hosts are not part of a shared-network.
Although the configuration to the DHCP server seems straightforward, having to administer a large number of systems by editing files can become tedious. Webmin (www.webmin.com) provides a graphical, web-based interface by a large number of system functions (including DHCP) : and the primary DHCP configuration page shows the subnets which one specific machine manages, and also shows all shared networks which are configured. Many machines may be specifically configured also than as groups of machines : and when you select each object, you can configure the same options which you can by editing files.
Devesh pant (planman media)
Troubleshooting the Server
By complex DHCP configurations it is often difficult to understand what parameter applies by which host ; when trying to deduce what is happening, there are two important things to remember : firstly that host or group declarations can specifically override the global definition and the group declarations ; and secondly that definitions are not necessarily applied into the same order by which those appeared within the file as dhcpd.conf. The server checks whether a configuration to a specific host by the server is ordained, and then whether a configuration to a group is specified by the server, and then by the configuration to the subnet by the server, and then by the configuration to a shared-network by the server : and then the declarations by global variables by the server are assessed. Configurative options are added by and not replaced : therefore, the configuration to the smaller, more specific units (like hosts) have precedence above the configuration to more general units (like global parameters). So, when probems emerge, start at the bottom, and work your way up.
Perhaps the most basic technique by troubleshooting is to look at what leases the server has assigned. This is done by looking at the leases file as /var/state/dhcp/dhcp.leases , which maintains the current state of all active leases. One thing to recognise is that this file is re-written at timely intervals after a backup is made with the name as "dhcpd.leases~" so to prevent this file becoming too large, Although rare, it can happen that by some reason the server dies at this point, at which circumstances there would be no dhcpd.leases file, and thus server would not be able to restart. Rather than creating an empty dhcpd.leases file, you would rename dhcpd.leases~ to establish things correctly.
Within the contents of the dhcpd.leases file, each lease declaration is identified by the keyword as "lease" which is then followed by the IP address and information as configurational parameters which are contained inside of curly brackets. As example, there might be something like this:
lease 192.168.42.1 {
starts 0 2000/01/30 08:02:54;
ends 5 2000/02/04 08:02:54;
hardware ethernet 00:50:04:53:D5:57;
uid 01:00:50:04:53:D5:57;
client-hostname "PC0097";
}
The statements as "starts" and "ends" indicate the period when the lease is valid. Each entry is of the form:
weekday yyyy/mm/dd hh:mm:ss;
The weekday is the numerical value for the day of the week starting with 0 by Sunday, as by this case. The date and time are Greenwich Mean Time, and not local time.
The hardware entry is the same as that within the dhcpd.conf file. The uid entry is uniquely identifiable by the client, and this may take the form as a number for the hardware type, which is subsequently succeeded of the hardware address. Alternatively an ASCII string may identify the client.
Sometimes the client wants to specify its own name, and there are two ways a client can do this : one is by using the option as "client-hostname" ; and the other way a client may specify its own name is by using the option as "Hostname", which is used of many operating systems, like Windows 95, and the name of the host follows.
If there is a problem by the way that the client is configured then an entry within the dhcpd.leases file might not achieve desirable results. One approach by investigation would be to remove any applicable entry (based either upon the IP address or hardware address) and then re-start the server.
It may be necessary to see what the server thinks that it is doing rather than looking at the client or dhcpd.leases file and guessing what the server thinks that it is doing. To observe reality can be accomplished by running the dhcp server within the foreground (by using the -f option) and by telling it to output all its error messages by stderr (by using the -d option) instead for using the system logging daemon. You can watch the server accept and process requests.
Client Configuration
Configuration to the client-side is dependent upon your distribution. By example, if your operating system is SuSE 6.3, then you may go by the portion as network configuration of YAST and select the basic network configuration. If you press F3 sets auto-IP configuration, which gives you the choice as whether to configure DHCP or BOOTP, and by selecting DHCP this ought to make changes by the file as /etc/rc.config by setting the configuration to parameters of the respective card at the client side as "dhcpclient". By example, without DHCP you might have an entry like this:
IFCONFIG_0="192.168.42.1 broadcast 192.168.42.255 netmask 255.255.255.0 up"
If DHCP is configured through the above then the entry would look like this:
IFCONFIG_0="dhcpclient"
Note that you could have some of the interfaces configured so to use DHCP and others with static addresses. When the client machine boots, the /etc/rc.d/network script is called (by example, as /etc/rc.d/rc2.d/S05network), and if this machine discovers that the IFCONFIG line by the respective card is by "dhcpclient", then it will avoid configuration by its interface, until instructed further. Later at the boot process, usually the script as DHCP client is started (by example, as /etc/rc.d/rc2.d/S05dhclient), and now the client tries to receive its configuration from the DHCP server.
Upon other systems, like Caldera or Redhat, an own configuration tool changes the appropriate file within /etc/sysconfig/network-scripts/. As example, if you were configuring DHCP on your eth0 interface, the script as ifcfg-eth0 would be changed.
DEVICE=eth0 IPADDR=0.0.0.0 NETMASK=255.255.255.0 NETWORK= BROADCAST=0.0.0.255 GATEWAY=none ONBOOT=yes DYNAMIC=dhcp
Find the line labeled DYNAMIC= and change it to DYNAMIC=dhcp.
In most cases the default configuration to the client by the server is sufficient : and if not, the client has it's own configuration file: /etc/dhclient.conf. If you have more than one interface with different network options upon your client computer, you need to group the options by interface. By example,
interface eth0 {
send dhcp-lease-time 3600;
request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
}
The statement as send tells the client to send the associated option with the specified value, all the options which the server understands may be sent. These are defined into detail by the dhcp-options (5) man-page.
The statement as request is a list of configuration options (not the values) which the client requests that the server should send by the client : and this particular configuration option must be sent of a server so that the client may believe that the server is listening.
DHCP and firewalls
Firewalls usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server protocol describes several cases when packets must have the source address of 0x00000000 or the destination address of 0xffffffff. Anti-spoofing policy rules and tight inclusive firewalls often stop such packets. Multi-homed DHCP servers require special consideration and further complicate configuration.
To allow DHCP, network administrators need to allow several types of packets through the server-side firewall. All DHCP packets travel as UDP datagrams; all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68. For example, a server-side firewall should allow the following types of packets:
- Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip
- Incoming packets from any address to 255.255.255.255
- Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255
where dhcp-ip represents any address configured on a DHCP server host and dhcp-pool stands for the pool from which a DHCP server assigns addresses to clients
Example in ipfw firewall
To give an idea of how a configuration would look in production, the following rules for a server-side ipfirewall to allow DHCP traffic through. Dhcpd operates on interface rl0 and assigns addresses from 192.168.0.0/24 :
pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0 pass udp from any 68 to 255.255.255.255 67 in recv rl0 pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0
Example in Cisco IOS Extended ACL
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.
10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps 20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps 30 permit udp any eq bootpc host 255.255.255.255 eq bootps
Technical details
DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and 68/udp for the client side.
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
After the client obtained an IP address, the client may start an address resolution query to prevent IP conflicts caused by address poll overlapping of DHCP servers.
DHCP discovery
The client broadcasts on the physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a UDP packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP.
DHCP offers
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
DHCP requests
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the TCP/IP configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
DHCP information
The client sends a request to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
DHCP releasing
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not define the sending of DHCP Release as mandatory.
Client configuration parameters
A DHCP server can provide optional configuration parameters to the client. RFC 2132 defines the available DHCP options, which are summarized here. Defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS (last updated 2007-05-25)
RFC 1497 Vendor Extensions:
Data
Tag Name Length Meaning
--- ---- ------ -------
0 Pad Option 0 None
255 End Option 0 None
1 Subnet Mask 4 Subnet Mask Value
2 Time Offset 4 Time Offset in
Seconds from UTC
3 Router N×4 Router addresses
4 Time Server N×4 Timeserver addresses
5 Name Server N×4 IEN-116 Server addresses
6 Domain Server N×4 DNS Server addresses
7 Log Server N×4 Logging Server addresses
8 Quotes Server N×4 Quotes Server addresses
9 LPR Server N×4 Printer Server addresses
10 Impress Server N×4 Impress Server addresses
11 RLP Server N×4 N RLP Server addresses
12 Hostname N Hostname string
13 Boot File Size 2 Size of boot file in 512-octet
blocks
14 Merit Dump File N Client to dump and name
the file to dump it to
15 Domain Name N The DNS domain name of the
client
16 Swap Server 4 Swap Server address
17 Root Path N Path name for root disk
18 Extensions File N Path name for more BOOTP info
IP Layer Parameters per Host:
19 Forward On/Off 1 Enable/Disable IP Forwarding 20 SrcRte On/Off 1 Enable/Disable Non-Local Source Routing 21 Policy Filter N×8 Non-Local Source Routing Policy Filters 22 Max DG Assembly 2 Max Datagram Reassembly Size 23 Default IP TTL 1 Default IP Time to Live 24 MTU Timeout 4 Path MTU Aging Timeout 25 MTU Plateau N×2 Path MTU Plateau Table
IP Layer Parameters per Interface:
26 MTU Interface 2 Interface MTU Size 27 MTU Subnet 1 All Subnets are Local 28 Broadcast Address 4 Broadcast Address 29 Mask Discovery 1 Perform Mask Discovery 30 Mask Supplier 1 Provide Mask to Others 31 Router Discovery 1 Perform Router Discovery 32 Router Request 4 Router Solicitation Address 33 Static Route N×8 Static Routing Table
Link Layer Parameters per Interface:
34 Trailers 1 Trailer Encapsulation 35 ARP Timeout 4 ARP Cache Timeout 36 Ethernet 1 Ethernet Encapsulation
TCP Parameters:
37 Default TCP TTL 1 Default TCP Time to Live 38 Keepalive Time 4 TCP Keepalive Interval 39 Keepalive Data 1 TCP Keepalive Garbage
Application and Service Parameters:
40 NIS Domain N NIS Domain Name 41 NIS Servers N×4 NIS Server Addresses 42 NTP Servers N×4 NTP Server Addresses 43 Vendor Specific N Vendor Specific Information 44 NETBIOS Name Srv N×4 NETBIOS Name Servers 45 NETBIOS Dist Srv N×4 NETBIOS Datagram Distribution 46 NETBIOS Node Type 1 NETBIOS Node Type 47 NETBIOS Scope N NETBIOS Scope 48 X Window Font N×4 X Window Font Server 49 X Window Manager N×4 X Window Display Manager 64 NIS-Domain-Name N NIS+ v3 Client Domain Name 65 NIS-Server-Addr N×4 NIS+ v3 Server Addresses 68 Home-Agent-Addrs N×4 Mobile IP Home Agent Addresses 69 SMTP-Server N×4 Simple Mail Server Addresses 70 POP3-Server N×4 Post Office Server Addresses 71 NNTP-Server N×4 Network News Server Addresses 72 WWW-Server N×4 WWW Server Addresses 73 Finger-Server N×4 Finger Server Addresses 74 IRC-Server N×4 Chat Server Addresses 75 StreetTalk-Server N×4 StreetTalk Server Addresses 76 STDA-Server N×4 ST Directory Assist. Addresses
DHCP Extensions:
50 Address Request 4 Requested IP Address 51 Address Time 4 IP Address Lease Time 52 Option Overload 1 Overload "sname" or "file" 53 DHCP Msg Type 1 DHCP Message Type 54 DHCP Server Id 4 DHCP Server Identification 55 Parameter List N Parameter Request List 56 DHCP Message N DHCP Error Message 57 DHCP Max Msg Size 2 DHCP Maximum Message Size 58 Renewal Time 4 DHCP Renewal (T1) Time 59 Rebinding Time 4 DHCP Rebinding (T2) Time 60 Class Id N Vendor Class Identifier 61 Client Id N Client Identifier 66 Server-Name N TFTP Server Name 67 Bootfile-Name N Boot File Name
Newer extensions:
62 Netware/IP Domain N Netware/IP Domain Name
63 Netware/IP Option N Netware/IP sub Options
77 User-Class N User Class Information
78 Directory Agent N directory agent information
79 Service Scope N service location agent scope
80 Rapid Commit 0 Rapid Commit
81 Client FQDN N Fully Qualified Domain Name
82 Relay Agent Information N Relay Agent Information, RFC 3046
83 iSNS N Internet Storage Name Service
84 REMOVED/Unassigned
85 NDS Servers N Novell Directory Services
86 NDS Tree Name N Novell Directory Services
87 NDS Context N Novell Directory Services
88 BCMCS Controller Domain Name list
89 BCMCS Controller IPv4 address option
90 Authentication N Authentication
91-92 REMOVED/Unassigned
93 Client System N Client System Architecture
94 Client NDI N Client Network Device Interface
95 LDAP N Lightweight Directory Access Protocol
96 REMOVED/Unassigned
97 UUID/GUID N UUID/GUID-based Client Identifier
98 User-Auth N Open Group's User Authentication
99-111 REMOVED/Unassigned
112 Netinfo Address N NetInfo Parent Server Address
113 Netinfo Tag N NetInfo Parent Server Tag
114 URL N URL
115 REMOVED/Unassigned
116 Auto-Config N DHCP Auto-Configuration
117 Name Service Search N Name Service Search
118 Subnet Selection Option 4 Subnet Selection Option
119 Domain Search N DNS domain search list
120 SIP Servers DHCP Option N SIP Servers DHCP Option
121 Classless Static Route N Classless Static Route Option
Option
122 CCC N CableLabs Client Configuration
123 GeoConf Option 16 GeoConf Option
124 V-I Vendor Class Vendor-Identifying Vendor Class
125 V-I Vendor-Specific Vendor-Identifying Vendor-Specific
Information Information
126-127 Removed/Unassigned
128 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
128 Etherboot signature. 6 bytes: E4:45:74:68:00:00
128 DOCSIS "full security" server IP address
128 TFTP Server IP address (for IP Phone software load)
129 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
129 Kernel options. Variable length string
129 Call Server IP address
130 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
130 Ethernet interface. Variable length string.
130 Discrimination string (to identify vendor)
131 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
131 Remote statistics server IP address
132 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
132 802.1P VLAN ID
133 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
133 802.1Q L2 Priority
134 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
134 Diffserv Code Point
135 PXE - undefined (vendor specific) (Tentatively Assigned - 23 June 2005)
135 HTTP Proxy for phone-specific applications
136-149 Unassigned
150 TFTP server address (Tentatively Assigned - 23 June 2005)
150 Etherboot
150 GRUB configuration path name
151-174 Unassigned
175 Etherboot (Tentatively Assigned - 23 June 2005)
176 IP Telephone (Tentatively Assigned - 23 June 2005)
177 Etherboot (Tentatively Assigned - 23 June 2005)
177 PacketCable and CableHome (replaced by 122)
178-207 Unassigned
208 pxelinux.magic (string) = F1:00:74:7E (241.0.116.126) (Tentatively
Assigned - 23 June 2005)
209 pxelinux.configfile (text) (Tentatively Assigned - 23 June 2005)
210 pxelinux.pathprefix (text) (Tentatively Assigned - 23 June 2005)
211 pxelinux.reboottime (unsigned integer 32 bits) (Tentatively Assigned
- 23 June 2005)
212-219 Unassigned
220 Subnet Allocation Option (Tentatively Assigned - 23 June 2005)
221 Virtual Subnet Selection Option (Tentatively Assigned - 23 June 2005)
222-223 Unassigned
224-254 Private Use
249 Classless Static Routes (Microsoft proprietary alias for 121)
252 WPAD auto-proxy-config (Microsoft proprietary)
See also
- Bootstrap Protocol (BOOTP)
- DHCP Snooping
- Peg DHCP RFC 2322
- Preboot Execution Environment (PXE)
- Reverse Address Resolution Protocol (RARP)
- Rogue DHCP
- udhcpc - light version for embedded systems.
- Zero Configuration Networking (Zeroconf)
- Web Proxy Autodiscovery Protocol (WPAD)
References
- ^ Lemon, Ted; Droms, Ralph (2003). The DHCP handbook. Indianapolis: SAMS. ISBN 0-672-32327-3.
{{cite book}}: CS1 maint: multiple names: authors list (link) - ^ Dynamic Updates in the Domain Name System (DNS UPDATE),RFC2136,P. Vixie et al,April 1997
External links
- RFC 2131 - Dynamic Host Configuration Protocol
- RFC 2132 - DHCP Options and BOOTP Vendor Extensions
- DHCP RFC - Dynamic Host Configuration Protocol RFC's (IETF)
- DHCP Server Security - This article looks at the different types of threats faced by DHCP servers and counter-measures for mitigating these threats.
- RFC 4242 - Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
- DHCP Sequence Diagram - This sequence diagram covers several scenarios of DHCP operation.
- RFC 3046, Recommended Operation for Switches Running Relay Agent and Option 82 describes how DHCP option 82 works
- RFC 3942 - Reclassifying Dynamic Host Configuration Protocol Version Four (DHCPv4) Options
- RFC 4361 - Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
- DHCP Protocol Messages - A good description of the individual DHCP protocol messages.
- ISC DHCP - Internet Services Consortium's open source DHCP implementation.
- DHCP Tutorial