DHCP - LogeshVel/learning_resources GitHub Wiki

DHCP - Lease https://www.linkedin.com/pulse/deep-dive-dhcp-lease-time-client-behavior-lasya-gayathri-muramalla-yohhc

DHCP INFORM

https://www.linkedin.com/advice/3/what-dhcpinform-message-how-can-you-use-dhcp-qrhjc

PCAP: https://www.cloudshark.org/captures/19585c567c37

A DHCPINFORM packet is a type of DHCP (Dynamic Host Configuration Protocol) message that a client sends to a DHCP server to request additional configuration parameters, like DNS server addresses or gateway information, without requesting a new IP address lease. It's used when a client already has an IP address, potentially from manual configuration or another DHCP server, and needs supplementary network settings. The server responds with a DHCPACK message containing the requested information.

Here's a more detailed explanation:

DHCP Basics:

DHCP automates the process of assigning IP addresses and other network configuration parameters to devices on a network. Typically, a client goes through a four-step process (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK) to obtain an IP address lease from a server.

DHCPINFORM Purpose: Sometimes, a device already has an IP address, perhaps through static configuration or another DHCP server. In such cases, the device might need additional information, like DNS server addresses, gateway information, or custom options. Instead of going through the entire DHCP lease process, it can send a DHCPINFORM message to a DHCP server.

DHCPINFORM Process: The client sends a DHCPINFORM message to the server, requesting specific configuration parameters. The server receives the DHCPINFORM and, if it has the requested information, sends back a DHCPACK message. The client receives the DHCPACK and uses the provided information.

Key Differences: Unlike a standard DHCP request, the client sending a DHCPINFORM does not need to renew or release its existing IP address lease. The server doesn't need to update its lease database when responding to a DHCPINFORM.

DHCPNAK

A DHCPNAK (Negative Acknowledgement) message is sent by a DHCP server to a client to indicate that the requested IP address is invalid or cannot be assigned. This usually happens when the IP address is already in use by another device, or when the client's lease has expired or is no longer valid. In essence, the server is rejecting the client's request for a specific IP address.

Here's a breakdown of when DHCPNAK is used:

IP Address Already in Use: If a client requests an IP address that the server knows is currently assigned to another device, it will send a DHCPNAK.

Invalid IP Address Request: If the client requests an IP address outside the scope managed by the DHCP server, or if the requested IP address is invalid for any other reason, the server will send a DHCPNAK.

Expired or Invalid Lease: When a client tries to renew an IP address lease but the server's records indicate the lease is no longer valid (e.g., it has expired), the server will send a DHCPNAK.

Conflicting Information: If the DHCP server receives conflicting information about an IP address, it may send a DHCPNAK to the client to force a new lease negotiation.

Error Conditions: In some cases, DHCPNAK can be triggered by internal errors or misconfigurations on the DHCP server or client. When a client receives a DHCPNAK, it must restart the DHCP lease process to obtain a valid IP address. This typically involves broadcasting a DHCPDISCOVER message to find a suitable DHCP server and initiate a new lease negotiation.

DHCPDECLINE

A DHCPDECLINE message is sent by a DHCP client to a DHCP server to indicate that the IP address offered by the server is already in use on the network. This typically happens during the IP address assignment process when the client detects an address conflict.

Here's a more detailed explanation:

DHCP Process: DHCP (Dynamic Host Configuration Protocol) is used to automatically assign IP addresses and other network configuration parameters to devices on a network.

IP Address Allocation: When a DHCP-enabled client joins a network, it sends out a DHCPDISCOVER message to locate a DHCP server. The server then offers an IP address to the client via a DHCPOFFER message.

DHCPDECLINE in Action: If the client, upon receiving the offer, discovers that the proposed IP address is already in use (e.g., by another device already assigned that address), it sends a DHCPDECLINE message to the server.

Server Action: Upon receiving the DHCPDECLINE message, the server will mark the offered IP address as unavailable and may log the event as a possible configuration issue.

Purpose of DHCPDECLINE: The DHCPDECLINE message is crucial for preventing IP address conflicts and ensuring proper network operation. It allows the DHCP server to quickly identify and rectify address allocation errors.

In the DHCP Discover process, the host asks for the Subnet mask, Router(Default Gateway) , Domain Name Server in the OPtions

To check whether only that PC has that IP address it will send the ARP request for its own address. If it gets the ARP reply then that Host knows that another host exists with the same ip and it has the duplicate address and it will inform the DHCP server to get the new ip address by Decline and DORA Process.

If there is no response for the ARP request then the client knows that it has the unique IP and it sends out the Gratuitous ARP to say that he has this IP and its mac(just advertising itself)

Typically, after a client is assigned an address, it will validate that it's the only one with that address by sending out an ARP request for its own address. If it hears back from another device with the same address, it will know that this address is a duplicate, and it will inform the server that it needs a new address. To do this, the client will send a DHCP decline to the server, indicating that the offered address is already in use on the network. The servers should mark this address as assigned and move onto the next one in the dynamic pool.

In the DHCP process, the server will indicate to the client the length of time the address will be assigned. After this amount of time, the IP address will be released back into the dynamic pool for reassignment. At any point during the lease, the client has the ability to renew the lease and keep the same IP address as long as it's still available, or the server can tell the client when to request a renew.

The DHCP sequence is

Discover
Offer
Request
Acknowledge

Discover - Broadcast

In this Discover, the Client reaches for the DHCP server via Broadcast.

When a client is trying to set itself up, it know’s NOTHING about the network it is on. Therefore it has to send it’s message by broadcast as it does not know what IP address the DHCP server is currently on.

Therefore it broadcasts the Discover so that any and all DHCP servers on the same LAN segment can offer an IP address.

Likewise at the Request stage, the client still hasn’t finalised it’s network information, so it again has to broadcast the Request packet.

*Here the Broadcast flag is not set so it asks the Servers to Unicast the Offer and Acks

Offer - Unicast or Broadcast

The Offer is sent by the DHCP Server. It can be either Unicast or Broadcast, which depends on the Bootp flag set by the Client in the Discover request. If the Broadcast Flag under the Bootp Flags of the Discover request by the client is set then the response (Offer and ACK) from the Server will be Broadcast. If that flag is unset (0) then the Offer and ACK from the DHCP server will be a unicast.

*Here, the DHCP Offer is Unicast.

Request - Broadcast

Based on the offers from the multiple DHCP servers the Client selects an offer and sends the Request in Broadcast

Ack - Unicast or Broadcast

The Server then acknowledges with the DHCP request of the Client either via Unicast or Broadcast depending the Bootp Flag set at the Discover request.