In the Classless Inter Domain Routing (CIDR) environment of IPv4 the following parameters should be defined on every IPv4 host:
- IP Address
- Subnet Mask
- Default Gateway
Other information can be provided as well, such as Domain Name Service (DNS) server addresses.
The allocation method of assigning an ip settings for IPv4 clients can be divided into two different ways:
Manual Allocation: This mode of allocation, as the name suggests, requires you to manually configure the network settings for your device rather than applying any network concept. This allocation mode is much more time-consuming and is prone to errors because of user intervention. Later in this tutorial on what is DHCP, you will learn more about the steps on connecting our system to the internet.
The manual allocation is done by accessing the network configuration settings of the device and also requires other related configurations such as subnet mask, default gateway, and preferred DNS server.
Dynamic Allocation: The dynamic allocation mode involves the client (user device) sending a request message to the server (DHCP host).
After which, the server shares all the required network resources to the client device and configures the device automatically so that the system can access the internet and various network services.
With the advancement of technology, the need to configure network settings manually has almost become nonexistent. If you want to adminstrate a network with more then 1 host, you normally would need a good pair of running shoes. So for this kind of reason it would be nice to have a workflow which allows us to configure our hosts centralized and dynamically.
DHCP (Dynamic Host Configuration Protocol) is a network administration protocol that is responsible for the task of assigning an IP address to your system and network device. The DHCP network model is based on the client-server architecture, where the connection is established when the client device sends a request message to the server device for providing the system with an IP address.
The client sends a Limited Broadcasts (255.255.255.255) with a DHCP DISCOVER message, and shows so that he needs an IPv4 configuration.
The DHCP Server responds with an Unicast message wich contains a proposal for the new IPv4 address and the DHCP OFFER also may provide additional information like subnetmask, Default Gateway, DNS server and NTP
The client answers the proposal with a DHCP REQUEST again as a Limited Broadcast. With this DHCP REQUEST he also shows other DHCP servers which DHCP server the client has selected.
The server acknowledges the DHCP REQUEST with an Unicast DHCP ACK message.
When a client (PC) need network configuration, it broadcasts a DHCP Discover message over the Ethernet network to locate all available DHCP servers on the same subnet network (by setting the destination MAC address in the Ethernet header as Broadcast MAC=FF:FF:FF:FF:FF:FF), reaching all the DHCP servers on the same subnet network.
When a DHCP server receives the DHCP Discover message from the client, it also broadcasts a DHCP Offer message over the Ethernet network , informing the client that it is available. This message contains the network information, such as client IP address, subnet mask, default gateway IP address, DNS IP address, IP lease time and DHCP server IP address. The DHCP Offer message broadcasted is delivered to all the clients on the same subnet network, including the one that sent the DHCP Discover message.
The client, having received the DHCP Offer message, recognizes there is a DHCP server available on the same subnet. Then it broadcasts a DHCP Request message to the server over the Ethernet network, requesting network configuration data including an IP address for itself. If more than one DHCP server responds on the same subnet and hence the client receives multiple DHCP Offer messages, it selects one of the DHCP servers, and enters the IP address of the selected DHCP server in the DHCP Server Identifier (option 54) field of the DHCP Request message. Then it informs all the DHCP servers on the subnet network about such selection by broadcasting the DHCP Request message. Typically, all DHCP servers internally store the network configuration data (i.e. IP address for the client and other information) when they send a DHCP Offer message. So, the client broadcasts the DHCP Request message to all the DHCP servers, so that those not selected can also receive the message and delete the stored network configuration data from their memory.
The DHCP server which received the DHCP Request message from the client checks if the IP address shown in the DHCP Server Identifier (option 54) field matches its own. If it does, it broadcasts a DHCP Ack message ensuring the client can receive the message (Note: the client has NOT been allocated an IP address yet).
At this time, the DHCP server transfers all the network configuration data including the client IP address – the same data sent along with the DHCP Offer message - to the client. Then the client configures a network interface using the transferred data, finally connecting to the lan network.
Inside the Address DHCP OFFER and the DHCP ACK message a so called renewal time is defined. After this time the client ip address is expired. It needs to renewal his address by the DHCP address renewal. This is done in 2 Steps.
In our example, the lease time is given as 1 hour. When half of it has passed (i.e. 1,800 seconds/30 minutes from example), the client sends a DHCP Request message to the DHCP server to renew its lease time (Note: In case of IP renewal, no DHCP Discover/Offer process is required). Unlike in the IP address allocation/lease procedure, the client does not broadcast the DHCP Request message, but unicasts it (Destination MAC=DHCP Server MAC (m2), Destination IP=DHCP Server IP (22.214.171.124)). That is because the DHCP server and client have already known each other's IP address. The DHCP Request message for IP address renewal should include the IP address of the client requesting the renewal in the "Client IP Address (ciaddr)" field, but should exclude Requested IP Address (option 50) and DHCP Sever Identifier (option 54) fields.
Upon accepting the DHCP Request message (for IP address renewal) received from the client, the DHCP server also unicasts, and does not broadcast, a DHCP Ack message (Destination MAC=PC MAC (m1), Destination IP=PC IP (126.96.36.199)), including network configuration data such as the client IP address, subnet mask, default gateway IP address, DNS IP address and lease time, to the client. Once this process is completed, the client can keep its current IP address for the extended lease time as specified in the DHCP Ack message.
When a client is shut down gracefully, or "ipconfig/release" command is entered in the DOS command window of Windows, the client unicasts a DHCP Request message to the DHCP server in order to return its allocated IP address, as seen in example. Then it releases the network configuration data (i.e. client IP address, subnet mask, default gateway IP address, DNS IP address, etc.), consequently having no access to the Internet any more.
In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured. To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field . The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B: BROADCAST flag MBZ: MUST BE ZERO (reserved for future use) Figure 2: Format of the 'flags' field