What is the reason why the dhcprequest message is sent as a broadcast during the dhcpv4 process

What is the reason why the dhcprequest message is sent as a broadcast during the dhcpv4 process

DHCP Client jj] DHCP client broadcasts a DHCPDISCOVER packet

2\ DHCP servers broadcast a DHCP OFFER packet

J] DHCP client broadcasts a DHCPREQUEST packet

%- 'i/' 4 I DHCP Serverl broadcasts a DHC PACK packet

DHCP Client

Introduction

ILLEGAL FOR NON-TRAINER USE

DHCP uses a four-step process to lease IP addressing information to DCHP clients. The four steps are named after the DHCP packet types.

1. DHCP discover

2. DHCP offer

3. DHCP request

4. DHCP acknowledgement or DHCP negative acknowledgement

Definition

The DHCP client broadcasts a DHCPDISCOVER packet

The DHCP lease generation process is the process by which the DHCP client receives IP addressing configuration data from the DHCP server.

The DHCP client broadcasts a DHCPDISCOVER packet to locate a DHCP server. A DHCPDISCOVER packet is a message that DHCP clients send the first time that they attempt to log onto the network and request IP address information from a DHCP server.

There are two ways that the lease generation process can begin. The first occurs when a client computer either starts up or initializes TCP/IP for the first time. The second occurs when a client attempts to renew its lease and is denied. (For example, a client can be denied a renewal when you move it to another subnet.)

The DHCP server broadcasts a DHCPOFFER packet

The DHCP client broadcasts a DHCPREQUEST packet

The DHCP server broadcasts a DHCPACK packet

The DHCP server broadcasts a DHCPOFFER packet to the client. A DHCPOFFER packet is a message that DHCP servers use to offer the lease of an IP address to a DHCP client when it starts on the network.

Each responding DHCP server reserves the offered IP address in order not offer it to another DHCP client before the requesting client's acceptance.

If the client does not receive an offer after four requests, it uses an IP address in the reserved range from 169.254.0.1 to 169.254.255.254. The use of one of these auto-configured IP addresses ensures that clients located on a subnet with an unavailable DHCP server are able to communicate with each other. The DHCP client continues to attempt to find an available DHCP server every five minutes. When a DHCP server becomes available, clients receive valid IP addresses, allowing those clients to communicate with hosts both on and off their subnet.

The DHCP client broadcasts a DHCPREQUEST packet. A DHCPREQUEST packet is a message that a client sends to the DHCP server to request or renew the lease of the client's IP address.

The DHCP client responds to the first DHCPOFFER packet that it receives by broadcasting a DHCPREQUEST packet to accept the offer. The DHCPREQUEST packet includes the identification of the server whose offer the client accepted. All other DHCP servers then retract their offers and retain their IP addresses for other IP lease requests.

The DHCP server broadcasts a DHCPACK packet to the client. A DHCPACK packet is a message that the DHCP server sends to a client to acknowledge and complete a client's request for leased configuration. This message contains a valid lease for the IP address and other IP configuration data.

When the DHCP client receives the acknowledgment, TCP/IP initializes by using the IP configuration data that the DHCP server provides. The client also binds the TCP/IP protocol to the network services and network adapter, permitting the client to communicate on the network.

The DHCP server sends a DHCP negative acknowledgement (DHCPNAK packet) if the IP address that was offered is no longer valid or is now in use by another computer. The client must then begin the lease process again.

Important A DHCP server and a DHCP client communicate by using User Datagram Protocol (UDP) ports 67 and 68. Some switches do not properly forward DHCP broadcasts by default. For DHCP to function correctly, you may need to configure these switches to forward broadcasts over these ports.

Continue reading here: How the DHCP Lease Renewal Process Works

Was this article helpful?

What is the reason why the dhcprequest message is sent as a broadcast during the dhcpv4 process

If you ask people how DHCP works, most people will think that a computer gets connected to the network and an IP is handed to them. This is a simplistic view as to what REALLY happens. I will cover the process of the initial DHCP request and the subsequent packets as well as the DHCP Relay process and finally the renewal process. This blog post will cover IPv4 only.

What is the reason why the dhcprequest message is sent as a broadcast during the dhcpv4 process

First things first. When you plug you machine into a switch or connect to an SSID and your machine is configured for DHCP, your machine will go through the following steps. If you want to see this for yourself, I suggest setting up a SPAN port and capturing or using Wireshark on your PC while you boot up.

There is a very nice Windows tool for troubleshooting DHCP. I have not run in since I went to Mac about 9 years ago, but it is worth a try.

1. DHCPDISCOVERY – Here the PC or device has no IP address and sends a broadcast essentially asking for a DHCP server to provide an IP address. This packet is a UDP packet on port 67. The reason this is a broadcast is that simply the device does not know where the DHCP server is. If there is no local DHCP and no BOOTP configured (more on this later), the device will revert to a ‘link-local IPv4’ (RFC 3927). APIPA.

What is the reason why the dhcprequest message is sent as a broadcast during the dhcpv4 process

2. DHCPOFFER – The next step is ALL DHCP servers that received the DHCPDISCOVERY broadcast packet will respond on UDP 68 with a

3. DHCPREQUEST -Once the client receives the DHCPOFFER, it replies with a DHCPREQUEST message, indicating that it plans to accept the parameters in the DHCPOFFER. If there are multiple DHCP servers (not a good practice), the device may receive multiple DHCPOFFER messages, one from each DHCP server that received the original DHCPDISCOVER message. The device will choose one DHCPOFFER and responds to THAT DHCP server only, declining all other DHCPOFFER messages. The server identifier is the IP address of a selected DHCP server. This option type is used in two possible ways. First, servers include this option type in DHCPOffer messages so that clients can distinguish between multiple lease offers. This option is used in DHCPOffer and DHCPRequest messages and sometimes appears in DHCP Acknowledgment messages (DHCPAck, DHCPNak)

4. DHCPACK – Once the DHCP server receives the DHCPREQUEST from the device/client, it sends and ACK packet for the request with a DHCPACK message. This comples the initialization process. Now, this DHCPACK message has a source IP address of the DHCP server and the destination address remains as a broadcast and contains the parameters that the client requested in the DHCPREQUEST message. When the device receives the DHCPACK, this is called the BOUND state. The DHCP server stores the leaseinformation into its database and identifies it using the client identifier or chaddr, and the assigned IP address.

5. DHCPNAK – If the server is unable to provide an IP for the DHCPREQUEST message, the DHCP server will respond with a DHCPNAK message. When the device receives a DHCPNAK message, or does not receive a response to a DHCPREQUEST message, the client restarts the process by going into the REQUESTING state. The device will then retransmit the DHCPREQUEST at least four times within 60 seconds before restarting the Initializing state.

6. DHCPDECLINE – The client receives the DHCPACK and CAN perform a final check on the parameters. The client performs this by sending Address Resolution Protocol ‘ARP’ requests for the IP address provided in the DHCPACK. If the client detects that the address is already in use by receiving a reply to the ARP request, the client will send a DHCPDECLINE message to the server and restart the configuration process by going into the Requesting state. This can be a device that has been assigned a static IP address from the pool of addresses defined in the DHCP scope.

7. DHCPINFORM – In some cases, you can define a static IP address on your device while still telling the OS to use DHCP for the domain name, DNS servers and other options (e.g. Option 150 for TFTP used for phones to boot their images). If this is the case the device will send a DHCPINFORM request message to obtain other local configuration parameters. This DHCPACK will be sent unicast to the client.

8. DHCPRELEASE – If a device wants to release its lease on a network address by sending a DHCPRELEASE message to the DHCP server. The device identifies the lease to be released by using the client identifier field and network address in the DHCPRELEASE message.

Renewing the Lease

The IP address assigned by the server belongs to the server and periodically the IP lease needs to be renewed. When the lease time has been reached its halfway point the client will try to renew the lease. The device will then re-enter into DHCPREQUEST mode. It will send this to the DHCP server that owns the lease. Once the server recieves this request it will reply to the request to renew with a DHCPACK message if in face, it wants to renew the lease. The DHCPACK message sent by the server to the client will contain the new lease and any new configuration parameters, in the event that any changes are made to the server during the time of the previous lease. If the device does not ger a response from the originating server, it will request a DHCP from any DHCP server that responds.

If the client previously had a DHCP assigned IP address and it is restarted, the client will request the previously leased IP address in a DHCPREQUEST packet. This DHCPREQUEST will still
have the source IP address as 0.0.0.0, and the destination as the IP broadcast address 255.255.255.255.

A client sending a DHCPREQUEST during a reboot does no fill in the server indentifier field, rather it will use the requested IP address option field. Strict RFC compliant clients will populate
the ciaddr field with the address requested instead of the DHCP option field. The DHCP server will accept either method.