Dynamic Host Configuration Protocol

From Wikipedia, the free encyclopedia

The Dynamic Host Configuration Protocol (DHCP) is a computer networking protocol used by hosts (DHCP clients) to retrieve IP address assignments and other configuration information. DHCP uses a client-server architecture. The client sends a broadcast request for configuration information. The DHCP server receives the request and responds with configuration information from its configuration database. In the absence of DHCP, all hosts on a network must be manually configured individually - a time-consuming and often error-prone undertaking. DHCP is popular with ISP's because it allows a host to obtain a temporary IP address.

Contents
[hide]

1 Histories 2 Technical overview 3 Technical details o 3.1 DHCP discovery o 3.2 DHCP offer o 3.3 DHCP request o 3.4 DHCP acknowledgement o 3.5 DHCP information o 3.6 DHCP releasing o 3.7 Client configuration parameters in DHCP o 3.8 Options o 3.9 DHCP Relaying o 3.10 Reliability 4 Security 5 See also 6 References 7 External links

Histories
RFC 1531 initially defined DHCP as a standard-track protocol in October 1993, succeeding the Bootstrap Protocol (BOOTP). The next update, RFC 2131 released in 1997 is the current DHCP definition for Internet Protocol version 4 (IPv4) networks. The extensions of DHCP for IPv6 (DHCPv6) were published as RFC 3315. Before BOOTP and DHCP, there was another protocol used to discover a host's network address. The protocol was RARP (Reverse Address Resolution Protocol) RFC 906, published June 1984. RARP, BOOTP, and DHCP provide a way to request a network layer address for a host.

Technical overview
Dynamic Host Configuration Protocol automates network-parameter assignment to network devices from one or more DHCP servers. Even in small networks, DHCP is useful because it can make it easy to add new machines to the network. When a DHCP-configured client (a computer or any other network-aware device) connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, other servers such as time servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a lease (length of time the allocation is valid), and other IP configuration parameters, such as the subnet mask and the default gateway. The query is typically initiated immediately after booting, and must complete before the client can initiate IP-based communication with other hosts. Depending on implementation, the DHCP server may have three methods of allocating IPaddresses:

dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN has its IP software configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed (dynamic re-use of IP addresses). automatic allocation: The DHCP server permanently assigns a free IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had. static allocation: The DHCP server allocates an IP address based on a table with MAC address/IP address pairs, which are manually filled in (perhaps by a network administrator). Only requesting clients with a MAC address listed in this table will be allocated an IP address. This feature (which is not supported by all devices) is variously called Static DHCP Assignment (by DD-WRT), fixed-address (by the dhcpd

documentation), DHCP reservation or Static DHCP (by Cisco/Linksys), and IP reservation or MAC/IP binding (by various other router manufacturers).

Technical details
DHCP uses the same two ports assigned by IANA for BOOTP: 67/udp for sending data to the server, and 68/udp for data to the client. DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgement. Where a DHCP client and server are on the same subnet, they will communicate via UDP broadcasts. When the client and server are on different subnets, IP discovery and IP request messages are sent via UDP broadcasts, but IP lease offer and IP lease acknowledgement messages are sent via unicast.

DHCP discovery
The client broadcasts messages on the physical subnet to discover available DHCP servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server from a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255 or the specific subnet broadcast address. A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100). If the client remains connected to a network for which 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 address immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.

DHCP offer
When a DHCP server receives an IP lease request from a client, it reserves an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, 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 (Client Hardware Address) field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR (Your IP Address) field.

DHCP request

A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer and broadcast a DHCP request message. Based on the Transaction ID field in the request, servers are informed whose offer the client has accepted. When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses. The DHCP request message is broadcast, instead of being unicast to a particular DHCP server, because the DHCP client has still not received an IP address. Also, this way one message can let all other DHCP servers know that another server will be supplying the IP address without missing any of the servers with a series of unicast messages.

DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The 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 IP configuration process is completed. The protocol expects the DHCP client to configure its network interface with the negotiated parameters.

After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent IP conflicts caused by overlapping address pools of DHCP servers.

DHCP information
A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request 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 information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.

Client configuration parameters in DHCP

A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority (IANA) - DHCP and BOOTP PARAMETERS. A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[1]

Options
An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value that this option is set to give the DHCP server a hint about any required extra information that this client needs in a DHCP response.

DHCP Relaying
In small networks DHCP typically uses broadcasts. However, in some circumstances, unicast addresses will be used, for example: when networks have a single DHCP server that provides IP addresses for multiple subnets. When a router for such a subnet receives a DHCP broadcast, it converts it to unicast (with a destination MAC/IP address of the configured DHCP server, source MAC/IP of the router itself). The GIADDR field of this modified request is populated with the IP address of the router interface on which it received the original DHCP request. The DHCP server uses the GIADDR field to identify the subnet of the originating device in order to select an IP address from the correct pool. The DHCP server then sends the DHCP OFFER back to the router via unicast. The router then converts the DHCP OFFER back to a broadcast, sent out on the interface of the original device.

Reliability
A standard for implementing fault-tolerant DHCP servers has been discussed by the Internet Engineering Task Force,[2] but the draft standard has expired. The draft standard proposed redundant servers, one primary and one backup. The backup server tracks the IP address allocations made by the primary and takes over if the primary fails.

Security
This section contains close paraphrasing of one or more non-free copyrighted sources. Ideas in this article should be expressed in an original manner. See the talk page for details. (March 2009) The basic DHCP protocol became a standard before network security became a significant issue: it includes no security features, and is potentially vulnerable to two types of attacks:[3]

Unauthorized DHCP Servers: as you cannot specify the server you want, an unauthorized server can respond to client requests, sending client network configuration values that are beneficial to the attacker. As an example, a hacker can hijack the DHCP process to

configure clients to use a malicious DNS server or router (see also DNS cache poisoning). Unauthorized DHCP Clients: By masquerading as a legitimate client, an unauthorized client can gain access to network configuration and an IP address on a network it should otherwise not be allowed to use. Also, by flooding the DHCP server with requests for IP addresses, it is possible for an attacker to exhaust the pool of available IP addresses, disrupting normal network activity (a denial of service attack).

To combat these threats RFC 3118 ("Authentication for DHCP Messages") introduced authentication information into DHCP messages, allowing clients and servers to reject information from invalid sources. Although support for this protocol is widespread, a large number of clients and servers still do not fully support authentication, thus forcing servers to support clients that do not support this feature. As a result, other security measures are usually implemented around the DHCP server (such as IPsec) to ensure that only authenticated clients and servers are granted access to the network. Addresses should be dynamically linked to a secure DNS server, to allow troubleshooting by name rather than by a potentially unknown address.[citation needed] Effective DHCP-DNS linkage requires having a file of either MAC addresses or local names that will be sent to DNS that uniquely identifies physical hosts, 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, i.e., 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 network administrator.

References
1. ^ In Unix-like systems this client-level refinement typically takes place according to the values in a /etc/dhclient.conf configuration file. 2. ^ Droms, Ralph; Kinnear, Kim; Stapp, Mark; Volz, Bernie; Gonczi, Steve; Rabil, Greg; Dooley, Michael; Kapur, Arun (March 2003). DHCP Failover Protocol. IETF. I-D draftietf-dhc-failover-12. http://tools.ietf.org/html/draft-ietf-dhc-failover-12. Retrieved May 09, 2010. 3. ^ The TCP/IP Guide - Security Issues

External links

RFC 2131 - Dynamic Host Configuration Protocol RFC 2132 - DHCP Options and BOOTP Vendor Extensions DHCP RFC - Dynamic Host Configuration Protocol RFCs (IETF)

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.

Retrieved from "http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol" Categories: Internet standards | Application layer protocols Hidden categories: Articles needing additional references from April 2010 | All articles needing additional references | Articles with close paraphrasing from March 2009 | Articles needing cleanup from March 2009 | All pages needing cleanup | All articles with unsourced statements | Articles with unsourced statements from August 2009