DHCP IPv4

Client-server interaction – allocating a network address:
=======================================
DHCP Discover:
——————
-> broadcast, C -S
-> Port from 68 to 67
-> Client broadcast to locate available servers.

newly added Client in network:
Dest Mac: ff:ff:ff:ff:ff:ff
Source Mac: client mac
Source IP: 0.0.0.0
Dest IP: 255.255.255.255
client Identifier: client mac

DHCPOFFER:
—————-
-> broadcast, S- C
-> Server to client in response to DHCPDISCOVER with offer of configuration parameters.
-> All DHCP servers that receive a DHCPDiscover message and have a valid IP address to offer the DHCP client respond with a DHCPOffer message.
-> The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages.
-> your client IP address is set with ip address.
-> The DHCPOffer is sent via the media access control and IP broadcast because the DHCP client does not yet have a valid IP address.
-> The DHCP server reserves the IP address to prevent it from being offered to another DHCP client.

newly added Client in network:
Dest Mac: ff:ff:ff:ff:ff:ff
Source Mac: server’s mac
Source IP: server’s IP address
Dest IP: 255.255.255.255
Your client IP address: 1.2.3.4
server Identifier: Server IP
client Identifier: client mac

-> The DHCP client waits for a DHCPOffer message. If a DHCP client does not receive a DHCPOffer message from a DHCP server on startup, it will retry four times
(at intervals of 2, 4, 8, and 16 seconds, plus a random amount of time between 0 and 1,000 milliseconds). If a DHCP client does not receive a DHCPOffer after
four attempts, it waits 5 minutes, then retries at 5-minute intervals.

DHCPREQUEST:
————
-> broadcast, C – S
-> Client came to know the IP address it wants to lease(from DHCPOffer), so it broadcasts a DHCPRequest message to all DHCP servers. The client must use a broadcast
because it still does not have an assigned IP address.
-> The client broadcasts a DHCPREQUEST message that MUST include the ‘server identifier’ option to indicate which server it has selected, and that MAY include other
options specifying desired configuration values.
-> The ‘requested IP address’ option MUST be set to the same value of ‘yiaddr’ in the DHCPOFFER message from the server.
-> The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the
configuration parameters for the requesting client.
-> Those servers not selected by the DHCPREQUEST message use the message as notification that the client has declined that server’s offer.
-> The combination of ‘client identifier’ or ‘chaddr’ and assigned network address constitute a unique identifier for the client’s lease and are used by both the
client and server to identify a lease referred to in any DHCP messages.

newly added Client in network:
Dest Mac: ff:ff:ff:ff:ff:ff
Source mac: client’s mac
Source IP: 0.0.0.0
Destination IP: 255.255.255.255
Requested IP: 1.2.3.4
Server Identifier: Server IP address.
client Identifier: Client’s MAC

-> To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message,
the DHCPREQUEST message MUST use the same value in the DHCP message header’s ‘secs’ field and be sent to the same IP broadcast address as the original
DHCPDISCOVER message.
-> If the IP address of the client was just obtained with a DHCPDiscover or DHCPOffer exchange with a DHCP server, the client puts the IP address of that DHCP
server in the DHCPRequest. The specified DHCP server responds to the request, and any other DHCP servers retract their DHCPOffer. This ensures that the IP addresses
that were offered by the other DHCP servers go back to an available state for another DHCP client.

-> If the IP address of the client was known (that is, the computer restarted and is trying to lease its previous address), the broadcast is looked at by all of the
DHCP servers. The DHCP server that can lease the requested IP address responds with either a successful acknowledgment (DHCPAck) or an unsuccessful acknowledgment
(DHCPNak).
Renew already obtained IP address:
Dest Mac: server’s mac
Source mac: client’s mac
Source IP: 1.2.3.4
Destination IP: server IP
Renewing IP: 1.2.3.4
Server Identifier: Server IP address.
client Identifier: Client’s MAC

Rebinding:
-> If the DHCP client is unable to communicate with the DHCP server from which it obtained its lease, and 87.5 percent of its lease time has expired, it will attempt
to contact any available DHCP server by broadcasting DHCPRequest messages. Any DHCP server can respond with a DHCPAck message, renewing the lease, or a DHCPNak
message or client waits till lease expires, forcing the DHCP client to initialize and restart the lease process.

DHCPACK:
——–
-> broadcast, S – C
-> Server to client with configuration parameters,including committed network address.
-> Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding.
-> The ‘yiaddr’ field in the DHCPACK messages is filled in with the selected network address.

newly added Client in network:
Dest Mac: ffffffffffff
Source: client’s mac
Source IP: 0.0.0.0
Destination IP: 255.255.255.255
Requested IP: 1.2.3.4
Server Identifier: Server IP address.
client Identifier: Client’s MAC

-> The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the
DHCPACK message.  At this point, the client is configured.
-> If the client detects that the address is already in use (e.g., through the use of ARP), the client waits for min 10 sec (to avoid excessive n/w traffic in case of
loop) then sends a DHCPDECLINE message to the server and restarts the configuration process by requesting a new network address.

-> The client times out and retransmits the DHCPREQUEST message if the client receives neither a DHCPACK or a DHCPNAK message. The client retransmits the DHCPREQUEST
according to the retransmission algorithm.
->  The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client
(and the user of that client) to wait overly long before giving up.
->  retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds. If the client receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. client will notify user regarding initialization process has
failed and is restarting.

——————————————————————————-

DHCPNAK:
——–
-> Server to client indicating client’s notion of network address is incorrect (e.g., client has moved to new subnet) or client’s lease as expired.
-> If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a
DHCPNAK message. then client restarts the configuration process.

DHCPDECLINE:
———–
->  Client to server indicating network address is already in use.

DHCPRELEASE;
———–
-> Client to server relinquishing network address and cancelling remaining lease.
-> The client identifies the lease to be released with its ‘client identifier’, or ‘chaddr’ and network address in the DHCPRELEASE message.
-> If the client used a ‘client identifier’ when it obtained the lease, it MUST use the same ‘client identifier’ in the DHCPRELEASE message.

DHCPINFORM:
———–
-> Client to server,
-> asking only for local configuration parameters; client already has externally configured network address.
-> If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local
configuration parameters.
-> The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.  The server forms a DHCPACK message
containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.

==============================================================================================================================================

Client-server interaction – reusing a previously allocated network address:
—————–                 —————           ——————

-> If the client’s request is invalid (e.g., the client has moved to a new subnet), servers SHOULD respond with a DHCPNAK message to the client.
-> If the client receives a DHCPNAK message, it cannot reuse its  remembered network address.  It must instead request a new address by restarting the configuration
process.
-> If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client MAY choose to use the previously allocated
network address and configuration parameters for the remainder of the unexpired lease.