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 makes 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. Upon disconnecting, the IP address is returned to the pool for use by another computer. This way, many other computers can use the same IP address within minutes of each other.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:
dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN is 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.
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 DHCP servers) is variously called Static DHCP Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), Address Reservation (by Netgear), DHCP reservation or Static DHCP (byCisco/Linksys), and IP reservation or MAC/IP binding (by various other router manufacturers).
[edit]Technical details
DHCP uses the same two ports assigned by IANA for BOOTP: destination UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature.
DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgement. These points are often abbreviated as DORA (Discovery, Offer, Request, Acknowledgement).
DHCP clients and servers on the same subnet communicate via UDP broadcasts, initially. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agentmay be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point.
[edit]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 may 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.
DHCPDISCOVER
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0x00000000
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s, or overflow space for additional options. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Discover
DHCP option 50: 192.168.1.100 requested
DHCP option 55: Parameter Request List:
Request Subnet Mask (1), Router (3), Domain Name (15),
Domain Name Server (6)
[edit]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.
DHCPOFFER
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Offer
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18
[edit]DHCP request
In response to the offer Client requests the server. The client replies DHCPRequest, unicast to the server, requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. 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. In some cases 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.
Read more: http://wiki.answers.com/Q/What_is_Dora_process_in_DHCP_and_how_it_works#ixzz1ljWKjqeA
DHCPREQUEST
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Request
DHCP option 50: 192.168.1.100 requested
DHCP option 54: 192.168.1.1 DHCP server.
[edit]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.
DHCPACK
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address switched by relay)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP ACK
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18
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.
[edit]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.
[edit]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.
[edit]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.[3]
[edit]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.
[edit]DHCP Relaying
In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it doesn't have a routable IP address, nor does it know the IP address of a router. In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast. The relay agent then retransmits the response on the local network.
[edit]Reliability
The DHCP protocol provides reliability in several ways: periodic renewal, rebinding, and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired. They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, the DHCPREQUEST will be repeated by the client from time to time,[specify] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.
If the DHCP server is unreachable for an extended period of time,[specify] the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.
In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A standard for implementing fault-tolerant DHCP servers was developed at the Internet Engineering Task Force.[4][note 1]
If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease. At that time, it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address, presumably from a different DHCP server, it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.
[edit]Security
The base DHCP protocol does not include any mechanism for authentication.[5] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
Unauthorized DHCP servers providing false information to clients.[6]
Unauthorized clients gaining access to resources.[6]
Resource exhaustion attacks from malicious DHCP clients.[6]
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can be operated on networks, providing incorrect information to DHCP clients. This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity[citation needed], or as a man-in-the-middle attack. Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[6] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[7] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[7]
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[citation needed] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[citation needed]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[5]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[8]
整個(gè)過程：
1. DHCP請(qǐng)求IP地址的過程 l 發(fā)現(xiàn)階段，即DHCP客戶端尋找DHCP服務(wù)器的階段。
客戶端以廣播方式發(fā)送DHCPDISCOVER包，只有DHCP服務(wù)器才會(huì)響應(yīng)。
l 提供階段，即DHCP服務(wù)器提供IP地址的階段。
DHCP服務(wù)器接收到客戶端的DHCPDISCOVER報(bào)文后，從IP地址池中選擇一個(gè)尚未分配的IP地址分配給客戶端，向該客戶端發(fā)送包含租借的IP地址和其他配置信息
的DHCPOFFER包。
l 選擇階段，即DHCP客戶端選擇IP地址的階段。如果有多臺(tái)DHCP服務(wù)器向該客戶端發(fā)送DHCPOFFER包，客戶端從中隨機(jī)挑選，然后以廣播形式向各DHCP服務(wù)
器回應(yīng)DHCPREQUEST包，宣告使用它挑中的DHCP服務(wù)器提供的地址，并正式請(qǐng)求該DHCP服務(wù)器分配地址。其它所有發(fā)送DHCPOFFER包的DHCP服務(wù)器接收
到該數(shù)據(jù)包后，將釋放已經(jīng)OFFER（預(yù)分配）給客戶端的IP地址。 如果發(fā)送給DHCP客戶端的DHCPOFFER包中包含無效的配置參數(shù)，客戶端會(huì)向服務(wù)器發(fā)送
DHCPCLINE包拒絕接受已經(jīng)分配的配置信息。
l 確認(rèn)階段，即DHCP服務(wù)器確認(rèn)所提供IP地址的階段。
當(dāng)DHCP服務(wù)器收到DHCP客戶端回答的DHCPREQUEST包后，便向客戶端發(fā)送包含它所提供的IP地址及其他配置信息的DHCPACK確認(rèn)包。然后，DHCP客戶端
將接收并使用IP地址及其他TCP/IP配置參數(shù)。
2. DHCP客戶端續(xù)租IP地址的過程
l DHCP服務(wù)器分配給客戶端的動(dòng)態(tài)IP地址通常有一定的租借期限，期滿后服務(wù)器會(huì)收回該IP地址。如果DHCP客戶端希望繼續(xù)使用該地址，需要更新IP租約。
實(shí)際使用中，在IP地址租約期限達(dá)到一半時(shí)，DHCP客戶端會(huì)自動(dòng)向DHCP服務(wù)器發(fā)送DHCPREQUEST包，以完成IP租約的更新。如果此IP地址有效，
則DHCP服務(wù)器回應(yīng)DHCPACK包，通知DHCP客戶端已經(jīng)獲得新IP租約。 如果DHCP客戶端續(xù)租地址時(shí)發(fā)送的DHCPREQUEST包中的IP地址與DHCP服務(wù)器當(dāng)前
分配給它的IP地址（仍在租期內(nèi)）不一致，DHCP服務(wù)器將發(fā)送DHCPNAK消息給DHCP客戶端。
3. DHCP客戶端釋放IP地址的過程
l DHCP客戶端已從DHCP服務(wù)器獲得地址，并在租期內(nèi)正常使用，如果該DHCP客戶端不想再使用該地址，則需主動(dòng)向DHCP服務(wù)器發(fā)送DHCPRELEASE包，
以釋放該地址，同時(shí)將其IP地址設(shè)為0.0.0.0。
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;