What is DHCP?

Dynamic Host Configuration Protocol (DHCP as abbreviated by abbreviationfinder) is an application protocol that works according to the service request model to automatically configure Internet Protocol version 4 hosts with network addresses and other configuration parameters. The protocol defines three types of hosts in the network: first, the server, which is the host that provides the self-configuration service, second, the client, which is the host that obtains the automatic configuration service, and third, the proxy, which is a host that plays the role of an intermediary between the server and the client if they are in two networks. Two different ones.

The development of the protocol began in 1993 AD, under the supervision of a group of Internet network engineers, and then the standard was developed in its final form in 1997 AD, as a request for comments document bearing the number (RFC 2131). The protocol plays the role of a repository of configuration parameters in the network, performs the process of automatic allocation of Internet Protocol version 4 address spaces and provides an automatic configuration service for hosts in the network. A special version of the protocol was developed to support IPv6 hosts, called the Automated Configuration Protocol for IPv6 Hosts.

The Automated Host Initialization Protocol is widely used worldwide and is supported in most popular operating systems such as GNU/Linux, Windows, Android and Macintosh.

Overview

Network topology terminology in the Automated Host Configuration Protocol.

Layered open systems interconnection model
˂7. Application layer
˂6. Presentation layer
˂5. Session layer
˂4. Transport layer
˂3. Network layer
˂2. Data link layer
˂1. Physical layer
· A· N

· T

Automated Host Configuration Protocol is an application protocol that operates on a service request model that provides IPv4 hosts with configuration parameters, including IP addresses, thus providing a self-configuration service to hosts, whether local or local. Far away. The protocol also defines a mechanism to allocate IPv4 address space into specific quotas that can be granted to hosts. According to the standard communication model, the protocol operates at the application layer, relies on the user packet data protocol as the transport protocol, and uses the port numbers (67) and (68) originally assigned to the preamble protocol.

The protocol is designed to operate according to the service request model, that is, it divides hosts in the network into servers and clients. As for the client, it is a host in the network that uses the Automated Host Configuration Protocol to obtain configuration information, including the Internet Protocol address. As for the server, it is a host in the network that provides configuration parameters to whom. It is requested from clients using the Automated Host Configuration Protocol. Servers are not randomly selected from among the hosts, but must be clearly and explicitly identified by network administrators, and provided with the Internet Protocol address space and identifiers used.

The protocol supports three types of quoting mechanisms for the Internet Protocol space. The first is self-quoting, in which the protocol grants the client who requested the service a permanent Internet Protocol address. The second is automatic quoting, in which the protocol grants the Internet Protocol address to the host that requests the service for a specific period of time. The third is manual quoting, in which the network administrator or system supervisor manually determines the quota of a host, and this is saved in the server, and it is limited to… The protocol’s task is to transfer that share to the host when it requests the automatic configuration service. All three forms of staking can be used together in the same network, and these uses are then determined by network policies.

Automated configuration is an option for systems that support IPv4 addresses. The host obtains the IP address either through automatic configuration or through static configuration, which requires direct intervention from the network administrator or host administrator. Later, self-configuration was added as a third option in IPv6 hosts. The automatic configuration protocol for hosts was designed in a way that allows clients to obtain configuration information automatically without intervention by the network manager or supervisor, meaning that there is no specific information or special identifiers that the client must have in order to obtain the configuration service. Automation. It is sufficient for the client to be connected to the network and support the necessary requirements for hosting the Internet Protocol when he resorts to the automatic configuration option.

The protocol server supports clients located in its local network and in remote networks. As for clients located in the server’s local network, they obtain the automatic configuration service by exchanging protocol messages directly with the server. While clients in a remote network rely on the protocol proxy (in English: Relay Agent) in order to transmit protocol messages across the remote network between the clients and the server, and the proxy is an Internet host, or a router that plays the role of mediator between agents of the automatic configuration protocol present in the proxy network. Local, and remote server for the protocol. Proxy setup requires manually adding configuration information to it.

The automatic configuration service is an optional service, and Internet Protocol hosts with manually configured settings can exist in the network in which the automatic configuration server operates, but this requires prior address space management, so that the manually configured addresses in the hosts are outside the allocation domain. Automated protocol, to ensure that the same address is not used more than once. However, the protocol ensures that no address in the address space used in the harvesting process is used more than once, and also includes mechanisms to track configuration information and addresses used and link them to the hosts that obtained them, so that they can obtain them again. Likewise when the service is requested again, including when the hosts or the server itself reboots.

The AHP was influenced by the bootstrap protocol. The AHP messages are structurally compatible with the bootstrap protocol messages, and this allows the two protocols to operate together in the same network, so that the AHP server supports the bootstrap protocols agents and clients. The AHP added two features They were not present in the preamble protocol. The first is to give a client the ability to automatically use an Internet Protocol address for a limited period of time, then edit it, thus allowing the possibility of using the same address again with another client. The second is to give the client the advantage of requesting the specifics of the Internet Protocol or the services that it supports. The network that the customer needs to perform his functions properly.

The use of the Automated Host Configuration Protocol is widespread, and is supported in the most widely used operating systems in the world such as Android, Windows, Macintosh , Linux, Cisco and Mikrotik.

Historical background

The development of the automatic configuration protocol for hosts was the result of a group of works that were developed separately, and in essence, they aimed to accomplish various parts of the self-configuration process for hosts with the least possible manual intervention, without the existence of an overarching framework that unifies all these efforts. A document described Request for Comments (RFC 951) for the Bootstrap Protocol in 1985 AD, and its primary goal was to enable a host that does not have a hard disk to discover its Internet Protocol address, the address of the file storage server, and the name of the file that contains the operating system to transfer to memory And booting from it, provided that all of this is done automatically.

In parallel, other protocols have been developed that perform some parts of the automatic initialization process while it is in operation, such as the Simple File Transfer Protocol, described in the document (RFC 1350), which provides a mechanism for transferring files, and also the Address Resolution Protocol which allows The host can discover the physical addresses of other hosts in the network, and also the Internet Control Message Protocol, described in the document (RFC 792) , which allows the host, through one of its options, to discover the address of the router connected to the local network.

Finally, two Request for Comment documents (RFC 1122) and (RFC 1123) set out a list of host requirements, including the configuration parameters that each host needs to be able to communicate properly with the network. They also proposed a mechanism for booting a host that does not have a disk. Solid. The document (RFC 1531) , which was issued in October of the year 1993, was the first document dedicated to the Automatic Host Configuration Protocol, and then some modifications were made to it to produce the document (RFC 1541), which was issued in the same month under the title “Automatic Host Configuration Protocol.”. Later in 1997, the document (RFC 2131) bearing the same name was issued and included a set of updates and additions, and it is the official standard adopted for the protocol today. Ralph Droms (in English: Ralph Droms) of Bucknell University wrote the previous three standard documents. The document (RFC 2132) includes a list of options that the protocol can use.

Later in 2003, the standard for the Automated Configuration Protocol for Internet Protocol version 6 hosts was released in the Request for Comments document (RFC 3315) and is known today by the abbreviation DHCPv6.

Protocol specifications

Protocol services

The protocol provides a self-configuration service for IPv4 hosts, and to achieve this, the protocol supports two additional services as well. The first is a storage repository for host configuration parameters, and the second is its automatic allocation of the IP address space.

Locator repository

The first service provided by the Automated Host Configuration Protocol is to provide a permanent store of clients ‘ network identifiers. To achieve this, the protocol builds a database that includes the identifiers of each client, and the unique database key is a unique identifier for each client, and this key corresponds to the identifiers The client’s private key may be a combination of his identifier and the network address that includes the Internet Protocol address given to him, or it may include the client’s physical address, or a combination of the Internet Protocol address and the client’s name, or any other value. Uniquely identifies the customer.

By default, the protocol in the client builds a unique identifier based on the network identifier taken from the Internet Protocol address hosted by the client, or from the client’s physical address. After that, the client sends the identifier it generated to the server via a special option, which is the client ID option. Which carries the option code number (61), in order to adopt it as a unique identifier for the client. A client who owns an item in the database can request to obtain its configuration information from the repository using the automated host configuration protocol, or can interrogate the server in order to obtain The value of a parameter. To achieve this, the client constructs an appropriate request message, and the server responds to the client with a response message containing the requested parameter.

Automated allocation of IP address space

The Automated Host Configuration Protocol also provides the service of automatic allocation of the address space used in the network. As a result, clients can obtain an Internet Protocol address from the server’s address space and use it temporarily or permanently. The staking mechanism is simple, and it starts from the client himself, who requests an Internet Protocol address from the address space. The protocol server, or group of servers, provides an address to the client and ensures that it is not displayed to any other client in the network during the period of its use by the client who Usage request.

To achieve automatic staking, the protocol relies on the concept of term of use (in English: Lease), which is the period of time during which an Internet Protocol address has the share of a specific client, during which the client has the right to use the address. The client can extend the period of use, through a request submitted to the server, and he can also terminate his use of the quota and release the address. In addition, the client can request an unlimited period of use, but the final decision to grant the possibility of permanent staking remains with the server.

Automated configuration

Automated configuration (in English: Dynamic Configuration) is to provide hosts with the parameters necessary to perform their functions and tasks over the network automatically without direct intervention from network administrators, and it is the main function of the automatic configuration protocol for hosts, from which it got its name. Automatic configuration relies on the parameter repository, which is a database located on the protocol server, and an address space allocation mechanism to provide hosts with configuration parameters.

The identifiers that are automatically provided to hosts include the Internet Protocol address, the netmask, the router address in the local network, which is sometimes called the default router, the DNS server address, and other various server addresses, in addition to a number of identifiers that help the host perform other functions. Path List The constant used in the routing process or the maximum transfer unit necessary to accomplish the data segmentation process.

Client specifications

Table of customer-specific configuration parameters as provided in the original standard (not including expansions)
Selector name Type
Transport layer parameters, at the host level
Life time Integer
Temporary to maintain effectiveness Integer
Volume of data to maintain effectiveness Polyani
Internet layer specifiers, at the host level
Act as a mentor Polyani
Routing by non-local source Polyani
Routing policy filters by non-local source existing
Maximum reassembly volume Integer
Default life time Integer
Route maximum transfer unit usage time timer [b] Integer
Maximum transport unit group table existing
Internet layer specifiers, at the port level
Internet Protocol address Title
Partial network mask Title
Maximum transport unit Integer
The maximum transmission unit for all subnetworks Integer
General broadcast address pattern Title
Do mask detection Polyani
Acting as a mask provider Polyani
Perform router discovery Polyani
Directed solicitation address Title
Virtual exits existing
Static paths existing
Link layer parameters, at the host level
Support suffixes Polyani
Temporary memory allocated for the address resolution protocol Integer
Ethernet encapsulation According to the comment request documents and
Notes1. ^ Its equivalent in English is the abbreviation: TTL

2. ^ Its equivalent in English is the abbreviation: PMTU

3. ^ Its equivalent in English is the abbreviation: MTU

The success of the automatic configuration service depends on the server providing clients with the values ​​of the host configuration parameters, and the network address is one of them. Initial automatic configuration is defined as providing the host with the configuration parameters necessary to perform basic functions such as communication with the network. The success of the process does not require providing the client with the values ​​of all the parameters, but a specific set of them is sufficient, including a host address, a network mask, at least one virtual port address, and a name server address. At least one domain. ​​The customer can request the value of specific parameters, either during or after the initial configuration process.

There are two mechanisms used to reduce the number of specifiers sent from the server to the client. The first is to adopt the default value. According to this mechanism, the client requests the value of one or more specifiers in the request message, and the server provides him only with specifiers whose value is different from the default value, as for those whose value is identical to the value. The default values ​​are not mentioned in the confirmation message, and the server does not put them in the confirmation message. As a result, the client adopts default values ​​for the parameters that he requested from the server that were not mentioned in the confirmation message. The default values ​​were specified in the documentation requesting comments for the host requirements. The second mechanism is for the client to specify a list of parameters in the discovery and request messages, and then the server only provides him with the parameters in that list.

The client adds the “List of Required Parameters” option to the request or discovery message. This option includes a list of required parameters. In addition, the client may suggest to the server specific values ​​for some parameters, using special options such as the “Required Internet Protocol Address” option or the “Duration of Use of an Address” option. Internet Protocol,” but the server remains the final decision maker in choosing whether or not to use the suggested values, and the client also uses the “Maximum Automatic Configuration Protocol Message Size” option to inform the server of the maximum possible size of protocol messages.

Client parameters are divided according to the layers of the Internet model into three categories, which are transport layer parameters, Internet layer parameters, and link layer parameters. The transport layer specifiers are specific to the Transport Control Protocol. As for the Internet layer specifiers, they are divided into two groups according to the specifier’s field of work. Either its work is at the entire host level, or at the level of one of its ports, which is the case in which the host has more than one port. Finally, the link layer action parameters operate at the port level.

Representation of time

When using the protocol, the client can request the use of one of the network addresses for a period of time, which may be specific or open, Therefore, there is a need to represent time within the protocol messages, and the problem becomes more difficult if the server and client are not synchronized, as the times used become relative.. In any case, the time in protocol messages is represented by one second, and in the event of non-synchronization the time is attributed to the client’s internal clock.

Time is represented using digits of length (32) without a sign, which means a wide range in which a time of up to one hundred years can be represented, which is a period much larger than any value the client may request. As for the unary value, which corresponds to the hexadecimal number system value.: FFFFFFFF It represents infinity, and is used to request an open period of use.

In the event that there is no synchronization between the server’s clock and the client’s clock, the previous working mechanism assumes that the internal clocks of the client and the server are stable with respect to each other, meaning that they measure the passage of time in the same way and without any displacement. If this is not achieved, the server that gives a client an Internet Protocol address, he may reuse it due to the expiration of the usage period and give it to another client, while the client’s address is still in use by the first client, which may cause an address conflict in the network. To solve this problem, the server can inform the client of a shorter usage period. Of the actual duration that it stores in its database.

Protocol timers

The automatic configuration protocol for hosts uses three timers: timer (T1), timer (T2), and timer. The goal of using them is to determine the times that the client waits in each case when requesting to renew the duration of use of the address. The client obtains the value of the timers from the positive confirmation message it receives in response to the request message. The time values ​​are relative, and the client attributes them to its internal clock, so there is no need for synchronization between the client and the server.

The value of the timers determines when transitions occur between the internal states of the client. The expiration of the time value of any of them causes a transition from the current state to another subsequent state in the following manner:

  • Timer (T1): Determines the time that the client spends in the committed state. The client activates the timer when entering the committed state, and when its value runs out, the client must move to the RENEWING state. When entering the renewal state, the customer requests a renewal of the term of use of the address from the server that was previously granted to him. The value of the timer (T1) is less than the address usage time, and by default it is half the usage time value.
  • Timer (T2): It determines the time that the customer spends in the re-renewal state. If no confirmation message arrives from the server about renewing the period of use, the customer starts the timer when entering the commitment state, and when the timer runs out, the client must move to the re-commitment state (REBINDING), in which the client re-sends the request message, but in a public broadcast form to reach any protocol server. The value of the timer (T2) must be greater than the value of the timer (T1), so that the client has the opportunity to request renewal of the usage period from other servers of the protocol. By default, the value of this timer is (87.5)%, or seven-eighths of the value of the usage duration.
  • Duration of use: It specifies the time during which the client can host a specific address, and it can be infinite, meaning that the address has been permanently granted to the client. Otherwise, the client triggers a timer for the duration of use when the client enters the committed state, and if the timer, the client, which will inevitably be in a recommitment state, because the value of the timers (T1) and (T2) is always less than the duration of use, moves to the initial state and begins the automatic initialization process from the beginning.

Protocol messages

The protocol client and its server exchange a set of messages called protocol messages. The exchange may be direct if the client and server are in the same local network, or via a proxy if the client is in a local network different from the server’s network. If the server knows the client’s address, it sends messages in the form of a unique broadcast with a unique destination. However, in the case where the client requests an Internet Protocol address, the server sends general broadcast messages to the client, because it does not host the address yet. In the case of a proxy, the messages exchanged between the server and the proxy are always broadcast messages with a unique destination, because they both host an explicit address. As for messages sent from the client to the server, directly or via a proxy, their routing pattern (unique or public broadcast) depends on The nature of the message itself and the client’s situation.

According to the original standard of the protocol, the client sends five types of messages to the server: the discovery message, the request message, the rejection message, the edit address message, and the notification message, while the server sends three messages: the offer message, the negative confirmation message, and the positive confirmation message. Each message has a specific function, but they all share the same structure, and differ by the value of the fields or the number and type of options used.

Later, the protocol was expanded and 10 more messages were added to perform specific tasks, bringing the total number of protocol messages to (18).

Automated host initialization protocol messages according to the original protocol standard (extension messages not included).
The name of the message in Arabic The name of the message is in English Direction of movement the use
Discovery message DHCPDISCOVER From the client to the server Sent by clients to determine which protocol servers are available.
Offer message DHCPOFFER From server to client A response to the discovery message, which contains an offer that the server presents to the client that includes a set of configuration information.
Request message DHCPREQUEST From the client to the server It is used in:· A response to a previous offer message, through which the parameters offered are requested from a specific server in a previous offer message. Sending this message means rejecting offers submitted by other servers, if they exist.

· Confirmation of continuing to use a previously granted address, for example after rebooting the client.

· Request to extend the period of use of a previously granted address that is still in use.

· Request to reuse an address that was previously granted and has expired.

Positive affirmation message DHCPACK From server to client A response to the request message, containing configuration information and including the network address assigned to the client, or the client’s share of the address space. The server, or group of servers, that operates the protocol is obligated to ensure that the address is not given to any other client within a period of time determined by the period of use.
Negative confirmation message DHCPNAK From server to client A response to the request message, which is a notification from the server to the client that the Internet Protocol address that the client set in a previous request message is inappropriate. For example, the client changed his network but is still using his old Internet Protocol address.
Rejection letter DHCPDECLINE From the client to the server It is a notification from the client to the server, aiming to inform him that the network address that was allocated to the client is already in use.
Title edit message DHCPRELEASE From the client to the server It is a notification message from the client to the server, informing him that the address has become free for use by the server before the end of the use period. The client must not use the address again after sending this message.
Media message DHCPINFORM From the client to the server It is used to request local configuration parameters from the server, and what is meant by the word local is that it is specific to the client itself. The customer must previously host an IP address to be able to use this message. Do not use this message to request an IP grant address or to renew the use of an already granted address.

Discovery, request, and information messages sent by the client are public broadcast messages, unless the client knows the server address, in which case it sends them as uniquely destination messages. The client sends the address editing message in the form of a message that is always unique in destination, and its address is the address of the server that gave the client the address. As for the rejection message, it is always a public broadcast message.

Retransmission and waiting condition

Retransmission is when the client sends a protocol message again to the server because the previous message did not reach him or the response to it did not arrive. The server never retransmits. It is a function of the client, and it is always governed by the wait condition, which is a mechanism through which the client determines when it should resend the message again. There is no specific strict waiting condition, and it is left to the client to choose, but he must take into account the time required for the message to be transmitted from the client to the server and vice versa. It is also recommended that the waiting periods be exponentially increasing with a specific value that is not exceeded, provided that the number of replay times does not exceed Transmit (4) times within a time frame of about one minute. If the wait condition is not met, the client may set the parameters to default values, or use another mechanism supported by the operating system such as Automated Internet Protocol Private Addressing (APIPA).

For example, if Ethernet with a transmission rate of 10 Mbps is the link protocol used, then an appropriate waiting condition before retransmitting for the first time could be to wait for the response to arrive for a period of more than 4 seconds after transmission, and this value is doubled to (8) seconds that the client waits for the response to the first retransmission to arrive. If the response does not arrive either, the client sends the second retransmission message. The waiting period becomes (16) seconds, then (32) and finally (64). If the response does not arrive, the client does not Then try again, and set the parameter values ​​to the default values.

Working algorithm

The automatic host configuration protocol works according to the service request model, in addition to the method of data movement between the elements that make up the network topology according to the protocol.

The automatic host configuration protocol works according to the service request model, meaning that the work of the protocol is divided between the servers that provide the service and the clients who receive it. If the client and server are in the same local network, communication between them is direct, but if they are in two networks They are different, so it is necessary to use a proxy, which is a host in the client’s local network, which plays the role of a link between the local client and the remote server.

Communication between the parties running the protocol occurs through the exchange of protocol messages. These messages are sent between the server and the agent in the form of messages that always have a unique destination, because the two parties host explicitly known Internet Protocol addresses. As for the messages exchanged between the server and the client or between the agent and the client, they may They may be messages with a unique destination or they may be general broadcast messages, depending on the information available to the customer and the nature of the message.

In the client

Flow chart for the Automated Host Initialization Protocol in the protocol client. The operation of the timers (T1) and (T2) was neglected when renewing the address usage period, as this algorithm assumes that the usage duration is not infinite, in order to simplify the work mechanism.

The client uses the Automated Configuration Protocol to request an Internet Protocol address, to renew the use of a previously granted address, or to request specific configuration settings. It is recommended that the client verify that the values ​​of his current settings are compatible with the values ​​of the settings in the Automated Configuration Protocol server when any change occurs in The local network, in addition to the event that the host reboots or its connection with the network is interrupted for a short period. However, if the client loses his connection with the server for some reason, and he had previously obtained an address with a specific duration of use, he can use the address until the temporary duration of use runs out. If he continues to be unable to communicate with the server, then the client must not use the address after that.

The protocol begins working in the client by verifying that the client hosts an address from the fourth version of the Internet Protocol, and then verifies that it has the address of at least one automatic initialization server. If none of the previous two conditions are met, the protocol begins the initial initialization process. Once true, the protocol checks whether the client needs any additional configuration settings.

The initial configuration process includes searching for a server for the automatic initialization protocol, through the client sending a discovery message and waiting for offer messages from local or remote servers. After collecting the offer messages, the client chooses one of them, and sends a request message to the server that sent it, which may include A suggestion to use a title. The client applies the wait condition of the retransmission operation in the wait phase, either after sending the discovery or request message.

The response message arrives to the client from the server. If it is a positive confirmation, the address is accepted and the parameters contained in the message are used. If it is a negative confirmation, the initial initialization process is started again from the beginning. After that, the client verifies the uniqueness of the address on the network. If it is unique, its use is confirmed until the end of the usage period. If it is not unique, the client sends a rejection message to the server and restarts the initial initialization process again.

The client can then use the protocol to request specific configuration parameters by sending a notification message to the server, and it can also track timers for the usage period in order to request their renewal before the usage period runs out, by sending a request message to the server to do so. Finally, the client may wish to abandon the address before the end of its use period, in which case he must send a release address message to the server, and the client must not use the address he edited after that.

In the agent

The path of data movement when using the Automated Host Configuration Protocol in a distributed network, where the role of the agent appears, which plays the role of mediation between the server and the client.

By default, routers do not allow public broadcast messages to leave the boundaries of the public broadcast domain, so AAP clients can only receive the AAP service if they are within the public broadcast domain of the same server, and then the service is limited to local IP clients only. To solve this problem, a host, often a port of a router connected to the remote network, is configured to play the role of a protocol proxy for that network.

The primary task of the agent is to convert the general broadcast messages sent by the client, which have a local spread, into unique messages whose destination is the Automated Host Configuration Protocol server, and to convert the unique response messages sent by the server into general broadcast messages, to spread in the local network and reach the clients. By performing this routing process, the agent provides a link between the server and remote clients.

In the original protocol standard, a proxy does not generate any protocol messages, does not add or modify its headers, and merely forwards messages between the server and clients. Later, the protocol proxy information option was defined, which allows the proxy to add an option to messages received from clients, with the aim of providing the server with information that helps it choose appropriate policies for granting the address or specifying the values ​​of the required parameters.

On the server

The Automated Configuration Protocol server setup window in a Windows operating system can display the fields for the address field and some basic options such as the router address, network mask, and others.

For the protocol to work properly, each server must be pre-configured with at least one domain in the IP address space, in order to be used in the automated allocation process, as well as provided with a value of the initialization parameters. The server must have an explicit address and be connected to the network. Each server maintains a database containing the addresses granted, the duration of use for each, and the client’s belongings, so the automatic configuration protocol is described as stateful.

The work of the Automated Host Configuration Protocol server is interactive, meaning that it always responds to a previous event, and this event is receiving a message coming from one of the clients. Then the work of the server is determined according to the type of message it received, which may be:

  • Exploration message: The server responds by sending an offer message. First, the server must determine the network from which it will grant the address, and this depends on the source of the discovery message. If it is coming from a local client, the server displays an address from the local network, and if it is coming from a proxy in a remote network, the server displays an address from Remote proxy network, and the issue of determining the address and the duration of its use remains a matter specific to each server.
  • Request message: A client of the protocol has previously sent it in one of the following cases:
    • A client receives an offer message from a server, and responds to it with a request message. The request message must then contain the server ID option.
    • A client wants to check whether its address or parameter value has expired. For example, it has just booted.
    • A client wants to extend the lifetime of an IP address.

The server studies the request according to its policies, then determines whether to accept it, and then responds with a positive confirmation message containing the required configuration information, or with a negative confirmation message as a result of rejecting the previous request message.

  • Rejection message: It means that the address that was given in a previous positive confirmation message is in use by another host in the network, and the server must free the client record from the address, without adding it back to the address field prepared for staking.
  • Address Edit Message: Upon receiving this message from the client, the server marks the edited address with the tag Ungranted, and adds it again to the address field to grant it again. The server also keeps a copy of the address in the client’s records in the database.
  • Notification message: The server should respond to it by sending a positive confirmation message directly to the source of this message. The response contains the parameters requested by the client. The response message should not be used in this case to provide the client with an Internet Protocol address or to renew the usage period. The message The notification is used exclusively to request the value of a configuration parameter, excluding the IP address.

Mechanism of action

Protocol header

Header structure

Flags field in the Automated Host Configuration Protocol header. In each client, the Internet layer must be able to pass the data packet to the link layer, receive the frame from it, and pass the encapsulated packet to the transport layer, even before the IP address is initialized at this layer, and the Internet layer in the client may not support this Therefore, the general broadcast bit is used within the flags field to solve this problem, and this flag is used in the Automated Host Configuration Protocol similarly to how it is used in the Bootstrap Protocol (BOOTP).

The Automatic Host Configuration Protocol header consists of 15 fields, 14 of which are fixed-length, and one variable-length field, which is the options field. The field may include sub-fields, such as the notification field, which includes the public broadcast flag, or the options field, which includes a group of options, each of which has a special structure. The same header is used in all protocol messages without any change in its structure or the number and arrangement of its fields.

Below are the fields that make up the protocol header, in the order in which they appear in the header. Next to each field is the English name as stated in the original protocol standard:

  • Operation encoding field(op): It is (1) byte long and specifies the type of message. The value (1) means that the message is a request message, and the value (2) means that the message is a reply message. Examples include the request message and also the positive confirmation message.
  • Physical address type(htype) field: Its length is (1) byte, and the physical address type is determined according to the data link layer standard used. For example, it takes the value (1) for Ethernet, the value (15) for Frame Switching Protocol, and the value (17) for For High Level Data Link Control Protocol and others.
  • Physical address length field(hlen): It is 1 byte long and contains the length of the physical address in bytes. For example, it takes the value (6) for the access control address of the Ethernet medium.
  • Number of hops field: It is (1) byte long. It will only be used if there is an agent. It contains the number of hops that separate the agent from the server. Protocol clients put the value (0) in this field and ignore it.
  • Customer ID(xid) field: (4) bytes long. It is a digital identifier that the customer generates that uniquely identifies the customer. The identifier can contain parts of the customer’s physical address, or the customer’s name in the Domain Name System, or part of it. This identifier helps to uniquely distinguish the client during the process of exchanging messages with the server. In order to obtain the automatic configuration service, the client must use the same identifier in all the messages he uses so that the protocol servers can identify him correctly.
  • Start time (secs) field: (2) bytes long. It is filled in by customers only. It contains the time that has elapsed since the start of the service request process, estimated in seconds.
  • Flags field: (2) bytes long, and contains one flag, which is the general broadcast, and it is the first bit in this field. The client raises this flag if he is unable to receive protocol messages before obtaining an Internet Protocol address, and sets its value to Zero is the opposite. The other bits in this field are not used, and must all be set to zero.
  • Client address field(ciaddr): It is (4) bytes long and contains the client’s Internet Protocol address. Only the client can fill it in if he is in one of the following states: commitment status, renewal status, or commitment renewal status. Otherwise, this field is ignored..
  • The address field sent to the client(yiddr): is (4) bytes long and contains the Internet Protocol address that the server displays to the client in the offer message, or which it gives to the client in the positive confirmation message. Otherwise, the field is ignored.
  • Server address field(siaddr): It is (4) bytes long and contains the Internet Protocol address of the server that the client wants to use. The server adds the address to this field in offer messages and positive confirmation notification messages.
  • Proxy address field(giaddr): It is (4) bytes long and contains the Internet Protocol address of the proxy. The proxy only adds it to the messages. The client and server ignore this field and set its value to zero when composing messages. A value other than zero in this field means that the client and the server are in two different networks and that there is an agent playing the role of an intermediary in transferring messages between them.
  • Physical client address field(chaddr): 16 bytes long.
  • Server Name(sname) field: It is (64) bytes long, and is used by the server only, in order to identify the client with the name of the host that hosts the server. It can also be used to expand the options field, provided that there is an option to “Use the server and file name fields” in the menu. Options.
  • File name field: It is (128) bytes long, and is used by the server to identify the client with the name of the file that it can use when booting. It can also be used to expand the options field, provided that there is an option to “Use the server and file name fields” in the list of options.
  • Option field: Variable length, containing one or more options from the protocol’s set of options.

What is DHCP