Dynamic Host Configuration Protocol ( DHCP ) is a network management protocol used on UDP/IP networks where DHCP servers dynamically assign IP addresses and other network configuration parameters to each device in network so they can communicate with other IP networks. The DHCP server allows the computer to request IP addresses and network parameters automatically from an Internet service provider (ISP), reducing the need for network administrators or users to manually assign IP addresses to all network devices. In the absence of a DHCP server, computers or other devices on the network must be manually assigned an IP address, or to set their own APIPA address, which will not allow it to communicate outside its local subnet.
DHCP can be implemented on networks ranging from home network size to large campus networks and regional Internet service provider networks. The residential router or gateway can be enabled to act as a DHCP server. Most residential network routers receive a unique global IP address within the ISP network. In a local network, the DHCP server assigns a local IP address for each device connected to the network.
Video Dynamic Host Configuration Protocol
Ringkasan
UDP/IP defines how devices on one network communicate with devices on other networks, and the DHCP server can manage UDP/IP settings for devices on the network, by automatically or dynamically assigning IP addresses to the device.
DHCP operates based on the client-server model. When a computer or other device is connected to a network, the DHCP client software sends a DHCP broadcast request asking for the required information. Any DHCP server on the network can serve requests. The DHCP server manages a collection of IP addresses and information about client configuration parameters such as default gateway, domain name, name server, and time server. Upon receiving a DHCP request, the DHCP server may respond with specific information to each client, as previously configured by the administrator, or with certain addresses and other information applicable to the entire network and for the timeframe for allocation ( rent ) apply. DHCP clients usually ask for this information immediately after boot, and periodically thereafter before the end of the information. When a DHCP client refreshes a task, it initially requests the same parameter value, but the DHCP server can assign a new address based on the assignment policy assigned by the administrator.
On large networks consisting of multiple links, one DHCP server can service the entire network when assisted by DHCP relay agents located on the connected router. Such agents deliver messages between DHCP clients and DHCP servers located on different subnets.
Depending on the implementation, the DHCP server may have three IP address allocation methods:
- Dynamic allocation
- The network administrator reserves multiple IP addresses for DHCP, and each DHCP client on the LAN is configured to request the IP address of the DHCP server during network initialization. The demand-and-grant process uses lease concepts with controlled time periods, allowing the DHCP server to reclaim and then reallocate non-updated IP addresses.
- Automatic allocation
- The DHCP server permanently assigns IP addresses to requested clients from a range specified by the administrator. It's like dynamic allocation, but the DHCP server stores the previous IP address assignment table, so it can assign clients to the same IP address that the client previously owned.
- Manual allocation (commonly called static allocation)
- The DHCP server issues a private IP address that depends on each client's MAC address, based on a mapping specified by the administrator. This feature is commonly called static DHCP assignment by DD-WRT, fixed-address by Netgear's dhcpd documentation, reservation address , DHCP Reservation or static DHCP by Cisco and Linksys, and IP address booking or MAC/IP address binding by other router manufacturers. If no match for the client's MAC address is found, the server may or may not optionally fall back to Dynamic or Automatic allocation.
DHCP is used for Internet Protocol version 4 (IPv4) and IPv6. While both versions serve the same purpose, the protocol details for IPv4 and IPv6 are quite different so they can be considered as separate protocols. For IPv6 operation, the device can alternately use automatic configuration of address without country. The IPv6 host can also use local linklinking to achieve operations that are limited to local network links.
Maps Dynamic Host Configuration Protocol
Operation
DHCP uses a connectionless service model, using User Datagram Protocol (UDP). This is implemented with two UDP port numbers for the same operation as the BOOTP protocol. UDP port number 67 is the server destination port, and the UDP port number 68 is used by the client.
DHCP operations fall into four phases: server discovery, IP lease offerings, IP rental requests, and IP lease recognition. These stages are often abbreviated DORA for discovery, supply, demand, and recognition.
The DHCP operation begins with the client sending the request. If the client and server are on a different subnet, DHCP Helper or DHCP Relay Agent can be used. Clients requesting an update from an existing lease can communicate directly through UDP unicast, because the client already has the IP address assigned at that time. In addition, there is a BROADCAST flag (B) that the client can use to show how (broadcast or unicast) can accept DHCPOFFER: 0x8000 for broadcast, 0x0000 for unicast. Typically, DHCPOFFER is sent via unicast. For hosts that can not receive unicast packets before an IP address is configured, this flag can be used to resolve this issue.
DHCP Discovery
The DHCP client broadcasts a DHCPDISCOVER message on a network subnet using a 255.255.255.255 destination address or a specific subnet broadcast address. The DHCP client can also request the last known IP address. If the client remains connected to the same network, the server can grant the request. Otherwise, it depends whether the server is set as authoritative or not. The authoritative server rejected the request, causing the client to issue a new request. The non-authoritative server simply ignores the request, which leads to the time-dependent implementation deadline for the client to terminate the request and request a new IP address.
For example, if HTYPE is set to 1, to specify that the media used is Ethernet, HLEN is set to 6 because the Ethernet address (MAC address) is 6 octets long. CHADDR is set to the MAC address used by the client. Some options are also set.
DHCP Offers
When the DHCP server receives the DHCPDISCOVER message from the client, which is the IP address lease request, the DHCP server stores the IP address for the client and makes the lease offer by sending the DHCPOFFER message to the client. This message contains the client's MAC address, the server's IP address, the subnet mask, the lease duration, and the IP address of the DHCP server that made the offer.
The DHCP server determines the configuration based on the client hardware address as specified in the CHADDR field (client hardware address). Here server, 192.168.1.1, specifies the client IP address in the YIADDR field (your IP address).
DHCP Request
In response to a DHCP offer, the client replied with a DHCPREQUEST message, broadcasting it to the server, requesting the address offered. The client may receive DHCP offers from multiple servers, but will only receive one DHCP offer. Based on the server identification option required in request and message broadcasting, the server is notified that the offer has been received by the client. When other DHCP servers receive this message, they withdraw all offers they have made to the client and return the offered IP address to the set of available addresses.
DHCP acknowledgment
When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The recognition phase involves sending DHCPACK packets to clients. This package includes the rental duration and other configuration information that may be requested by the client. At this point, the IP configuration process is complete.
The protocol expects a DHCP client to configure its network interface with negotiable parameters.
After the client obtains an IP address, he or she should investigate the newly received address (eg with the ARP Address Resolution Protocol) to prevent address conflicts caused by overlapping the DHCP server address pool.
DHCP information
DHCP clients can request more information than servers sent with the original DHCPOFFER. The client may also request recurring data for certain apps. For example, the browser uses DHCP Inform to get web proxy settings via WPAD .
DHCP release
The client sends a request to the DHCP server to release DHCP information and the client disables its IP address. Because client devices typically do not know when users can unplug them from the network, the protocol does not mandate delivery of the DHCP Release .
Client configuration parameters
The DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options specified by the Internet Assigned Numbers Authority (IANA) - DHCP and PARAMETER BOOTP.
A DHCP client can select, manipulate and override parameters provided by DHCP servers. In Unix-like systems, this client-level refinement usually occurs in accordance with the values ​​in the /etc/dhclient.conf configuration file.
DHCP options
The choice is an octet string of varying length. The first octet is the option code, the second octet is the number of the following octets and the remaining octets are code dependent. For example, the DHCP message type option for an offer will appear as 0x35, 0x01, 0x02, where 0x35 is code 53 for "DHCP message type", 0x01 means one octet follows and 0x02 is the "offer" value.
Documented in RFC 2132
The following table lists the available DHCP options, as listed in RFC 2132.
DHCP client vendor identification
There is an option to identify the vendor and the functionality of the DHCP client. Information is a variable length string or octet that has the meaning specified by the DHCP client vendor. One method that DHCP clients can use to communicate with servers that use certain types of hardware or firmware is by assigning a value in a DHCP request called the Vendor Class Identifier (VCI) (Option 60).
This method allows the DHCP server to distinguish between two types of client machines and process requests from two modem types appropriately. Some types of decoders also set VCI (Option 60) to inform the DHCP server about the hardware type and device functionality. The value of this option is set to provide instructions to the DHCP server about any necessary additional information that this client needs in a DHCP response.
Document other places
Relay agent sub-option information
The relay agent information option (option 82) specifies the container to attach sub-options to the DHCP request sent between the DHCP relay and the DHCP server.
DHCP relaying
In a small network, where only one IP subnet is managed, the DHCP client communicates directly with the DHCP server. However, the DHCP server can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not received an IP address can not communicate directly with a DHCP server using IP routing, as it does not have an IP address that can be routed, does not know the IP address of the router, and does not know the IP address of the DHCP server.
To allow DHCP clients on subnets that are not directly served by a DHCP server to communicate with a DHCP server, DHCP relay agents can be installed on this subnet. DHCP clients broadcast on local links; the relay agent receives the broadcast and sends it to one or more DHCP servers using unicast. Relay agents store their own IP addresses in the GIADDR field in the DHCP package. The DHCP server uses the GIADDR value to specify the subnet on which the relay agent receives the broadcast, and allocates the IP address on that subnet. When the DHCP server responds to the client, it sends a reply to the GIADDR-address, again using unicast. Relay agents then retransmit responses on the local network.
In this situation, communication between the relay agent and the DHCP server typically uses the source and destination UDP ports 67.
Reliability
DHCP ensures reliability in several ways: regular updates, loops, and failover. DHCP clients are allocated leases that last for several time periods. Clients start trying to renew their lease after half the rental interval has ended. They do this by sending a unicast DHCPREQUEST message to the DHCP server that assigns the original lease. If the server is down or unreachable, it will fail to respond to DHCPREQUEST . However, in this case the client repeats DHCPREQUEST from time to time, so if the DHCP server returns or becomes reachable again, the DHCP client will succeed in contacting and renewing the lease.
If the DHCP server can not be reached for a long period of time, the DHCP client will attempt to repeat, broadcasting DHCPREQUEST instead of revoking it. Because it is broadcast, the message DHCPREQUEST will reach all available DHCP servers. If some other DHCP server can renew the lease, it will be done at this time.
In order to perform rebinding in order to function, when the client successfully contacts the backup DHCP server, the server must have accurate information about the client's binding. Maintaining accurate and binding information between two servers is a complex issue; If both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on independent servers. Proposals for implementing fault-tolerant DHCP servers have been submitted to the Internet Engineering Task Force, but never formalized
If the rebinding fails, the lease will expire. When the lease expires, the client must stop using the IP address assigned to him in the lease. At that point it will restart the DHCP process from scratch by broadcasting the DHCPDISCOVER message. Since his contract has expired, he will receive the IP address offered to him. After having a new IP address (probably from a different DHCP server) it will once again be able to use the network. However, since the IP address has changed, the ongoing connection will be corrupted.
Security
The DHCP base does not include a mechanism for authentication. Because of this, he is vulnerable to various attacks. These attacks fall into three main categories:
- An unauthorized DHCP server provides false information to the client.
- Unauthorized clients gain access to resources.
- An attack runs out of resources from a malicious DHCP client.
Because the client has no way to validate the identity of the DHCP server, an unauthorized DHCP server (usually called "DHCP rogue") can be operated on the network, providing faulty information to the DHCP client. This can work as either a denial-of-service attack, preventing clients from gaining access to network connectivity, or as a man-in-the-middle attack. Because DHCP servers provide DHCP clients with server IP addresses, such as IP addresses of one or more DNS servers, an attacker can convince a DHCP client to perform DNS lookups via its own DNS server, and therefore can provide its own answer. for DNS requests from clients. This in turn allows an attacker to direct network traffic through itself, allowing to eavesdrop on the connection between the client and the network server being contacted, or simply replacing the network server itself.
Because the DHCP server does not have a secure mechanism to authenticate the client, the client may gain unauthorized access to the IP address by presenting credentials, such as the client identifier, owned by other DHCP clients. It also allows DHCP clients to spend the IP address of a DHCP server - by presenting new credentials each time requesting an address, the client can use all the IP addresses available on a particular network link, preventing other DHCP clients from obtaining services.
DHCP provides several mechanisms to overcome this problem. The Extension of Protocol Agreement Information Option Protocol (RFC 3046, usually referred to in the industry by its actual number as Option 82 â € <â € <) allows network operators to attach tags to DHCP messages because these messages arrive at network operator trusted network. This tag is then used as an authorization token to control client access to network resources. Because the client does not have access to the upstream network of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on authorization tokens.
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately, in 2002, RFC 3118 has not seen widespread adoption due to the problem of managing keys for a large number of DHCP clients. A 2007 book on DSL technology states it
there are many security vulnerabilities identified against security measures proposed by RFC 3118. This fact, combined with the introduction of 802.1x, slow deployment and take DHCP-level is confirmed, and has never been widely used.
The book of 2010 recorded it
[t] here are very few implementations of DHCP Authentication. The key management challenges and processing delays because hash computations have been considered as too heavy a price to pay for perceived benefits.
The architectural proposal from 2008 involves authenticating DHCP requests using 802.1x or PANA (both carrying EAP). The IETF proposal is created to include EAP in DHCP itself, called EAPoDHCP ; this does not seem to expand beyond the level of the IETF draft, the last of 2010.
IETF standard document
- RFC 2131, Dynamic Host Configuration Protocol
- RFC 2132, DHCP Options, and BOOTP Vendor Extensions
- RFC 3046, DHCP Relay Agent Information Options
- RFC 3397, Dynamic Host Configuration Search Dynamic Search Options (DHCP)
- RFC 3942, Re-Classifying the Fourth Dynamic Host Configuration Options Protocol Options (DHCPv4) Options
- RFC 4242, Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6
- RFC 4361, Node-Specific Client Identifier for Dynamic Host Configuration Protocol Version Four (DHCPv4)
- RFC 4436, Detecting Network Attachments in IPv4 (DNAv4)
- RFC 3442, Static Endless Route Options for Dynamic Host Configuration Protocol (DHCP) version 4
See also
Note
References
Source of the article : Wikipedia
0 Comments