| Line 13: | Line 13: | ||
| − | === DHCPv4 === | + | ==== DHCPv4<ref>https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol</ref><ref>https://tools.ietf.org/html/rfc2131</ref> ==== |
| − | DHCPv4 | + | [[File:800px-DHCP_session.svg.png|200px|thumb|DHCPv4]] |
| − | + | [[File:1280px-Dhcp-client-state-diagram.svg.png|500px|thumb|DHCPv4 client state-transition diagram]] | |
| − | + | The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client. | |
| + | DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement. | ||
| + | |||
| + | The DHCP operation begins with clients broadcasting a request. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may 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. | ||
| + | |||
| + | ===== Discovery ===== | ||
| + | The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet. | ||
| + | |||
| + | ===== Offer ===== | ||
| + | When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's client id (traditionally a 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 DHCP server may also take notice of the hardware-level MAC address in the underlying transport layer: according to current RFCs the transport layer MAC address may be used if no client ID is provided in the DHCP packet. | ||
| + | |||
| + | ===== Request ===== | ||
| + | In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,[a] requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. | ||
| + | |||
| + | The client also sends a DHCPREQUEST to extend its lease. | ||
| + | |||
| + | ===== Acknowledgement(ACK) / Non-Acknowledgement(NAK)===== | ||
| + | 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. | ||
| + | |||
| + | After the client obtains an IP address, it should probe the newly received address(e.g. with ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers. | ||
| + | |||
| + | If the client's request is invalid (e.g., the client has moved to a new subnet or the client requested with an invalid 'requested IP address'), the server responds to the client with a DHCPNAK message. | ||
| + | If the client receives a DHCPNAK message, the client restarts the configuration process. | ||
=== DHCPv6 === | === DHCPv6 === | ||
| − | + | ||
| − | |||
| − | |||
자세한 통신 흐름은 [[DHCPv6 communication]]을 참고하세요. | 자세한 통신 흐름은 [[DHCPv6 communication]]을 참고하세요. | ||
Revision as of 15:28, 9 April 2021
The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) local area networks. A DHCP server must be present on the network. A device connected to the network requests an IP address from the DHCP server using the DHCP protocol; the server assigns a unique address to the device, A device configured to use dynamic (DHCP) addressing that is connected to a different network will be assigned an address on that network without needing to be reconfigured.
DHCP operates based on the client–server model. When a computer or other device connects to a network, the DHCP client software sends a DHCP broadcast query requesting the necessary information. Any DHCP server on the network may service the request.
The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, and time servers.
On receiving a DHCP request, the DHCP server may respond with specific information for each client, as previously configured by an administrator, or with a specific address and any other information valid for the entire network and for the time period for which the allocation (lease) is valid.
A DHCP client typically queries for this information immediately after booting, and periodically thereafter before the expiration of the information. When a DHCP client refreshes an assignment, it initially requests the same parameter values, but the DHCP server may assign a new address based on the assignment policies set by administrators.
On large networks that consist of multiple links, a single DHCP server may service the entire network when aided by DHCP relay agents located on the interconnecting routers. Such agents relay messages between DHCP clients and DHCP servers located on different subnets. [1]
The imRAD provides both the DHCPv4 and DHCPv6 service.
DHCPv4[2][3]
The DHCP employs a connectionless service model, using the User Datagram Protocol (UDP). It is implemented with two UDP port numbers for its operations which are the same as for the bootstrap protocol (BOOTP). UDP port number 67 is the destination port of a server, and UDP port number 68 is used by the client.
DHCP operations fall into four phases: server discovery, IP lease offer, IP lease request, and IP lease acknowledgement. These stages are often abbreviated as DORA for discovery, offer, request, and acknowledgement.
The DHCP operation begins with clients broadcasting a request. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agent may 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.
Discovery
The client broadcasts a DHCPDISCOVER message on its local physical subnet. The DHCPDISCOVER message MAY include options that suggest values for the network address and lease duration. BOOTP relay agents may pass the message on to DHCP servers not on the same physical subnet.
Offer
When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the DHCP server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's client id (traditionally a 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 DHCP server may also take notice of the hardware-level MAC address in the underlying transport layer: according to current RFCs the transport layer MAC address may be used if no client ID is provided in the DHCP packet.
Request
In response to the DHCP offer, the client replies with a DHCPREQUEST message, broadcast to the server,[a] requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer.
The client also sends a DHCPREQUEST to extend its lease.
Acknowledgement(ACK) / Non-Acknowledgement(NAK)
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.
After the client obtains an IP address, it should probe the newly received address(e.g. with ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers.
If the client's request is invalid (e.g., the client has moved to a new subnet or the client requested with an invalid 'requested IP address'), the server responds to the client with a DHCPNAK message. If the client receives a DHCPNAK message, the client restarts the configuration process.
DHCPv6
자세한 통신 흐름은 DHCPv6 communication을 참고하세요.