DHCP (born Dynamic Host Configuration Protocol - Dynamic Host Configuration Protocol ) is a network protocol that allows computers to automatically obtain an IP address and other parameters necessary for working on a TCP / IP network. This protocol works according to the client-server model. For automatic configuration, the client computer at the network device configuration stage accesses the so-called DHCP server and receives the necessary parameters from it. The network administrator can set the range of addresses that the server distributes to computers. This avoids manual configuration of network computers and reduces errors. DHCP is used on most TCP / IP networks.

DHCP is an extension of the BOOTP protocol that was previously used to provide diskless workstations with IP addresses when they are loaded. DHCP maintains backward compatibility with BOOTP.

Story

The DHCP protocol standard was adopted in October 1993. The current version of the protocol (March 1997) is described in RFC 2131. The new version of DHCP, intended for use in the IPv6 environment, is called DHCPv6 and defined in RFC 3315 (July 2003).

IP address allocation

DHCP provides three methods for allocating IP addresses:

• Manual distribution. With this method, the network administrator assigns a specific IP address to the hardware address (for Ethernet networks, this is the MAC address) of each client computer. In fact, this method of address allocation differs from manual configuration of each computer only in that address information is stored centrally (on a DHCP server), and therefore it is easier to change them if necessary.
• Automatic distribution. With this method, each computer is allocated for permanent use an arbitrary free IP address from the range defined by the administrator.
• Dynamic distribution. This method is similar to automatic distribution, with the exception that the address is given to a computer not for permanent use, but for a certain period. This is called a rental address . Upon expiration of the lease, the IP address is again considered free, and the client is obliged to request a new one (which, however, may be the same). In addition, the client himself can refuse the received address.

Some DHCP service implementations are capable of automatically updating DNS records corresponding to client computers when new addresses are allocated to them. This is done using the DNS update protocol described in RFC 2136.

1.2. Formulation of the problem

DHCP is intended to provide DHCP clients with the configuration parameters described in Host Requirements RFC. After receiving the necessary parameters via DHCP, the DHCP client must be ready to exchange packets with any other computer on the Internet. The TCP / IP stack options provided by DHCP are listed in Appendix A. Not all of these parameters are necessary for the initial initialization of the client. The client and server can agree on a list of required parameters.

DHCP allows, but does not require, configuration of client parameters that are not directly related to the IP protocol. DHCP does not contact the DNS system to register the address [12, 13]. DHCP cannot be used to configure routers.

1.3. Terminology

The following definitions apply in this document:

1.4. Goals

Below is a list of the main tasks of DHCP.

DHCP should:

DHCP options

In addition to the IP address, DHCP can also inform the client of additional parameters necessary for normal operation on the network. These options are called DHCP options . A list of standard options can be found in RFC 2132.

Options are variable-length octet strings. The first octet is the option code, the second octet is the number of the following octets, the remaining octets depend on the option code.

For example, the option “DHCP Message Type” when sending a message “Offer” will look like this: 0x35,0x01,0x02, where 0x35 is the code of the option “DHCP Message Type”, 0x01 means that only one octet follows, 0x02 means “ Offer ”.

Some of the most commonly used options are:

• The default IP address of the router
• Subnet mask;
• DNS server addresses;
• DNS domain name.

Some software providers may define their own advanced DHCP options.

The following tables list the available DHCP options as specified in RFC2132:

RFC1497 software vendor extensions.

  Used to complement other options so that they align to the word boundary.

  Must be sent after the “router” option (option 3) if both are enabled.

  Available routers should be listed in order of preference.

  Available servers for synchronization should be listed in order of preference.

  Available IEN 116 - server names must be listed in order of preference.    

  The length of the boot image in 4-kilobyte blocks.

  Path to the storage of emergency dumps.

Parameters of client IP level.

Interface parameters IP-level.

Interface level communication options.

TCP parameters

Parameters of services and applications.

DHCP extensions.

Supplier Identification.

An option exists to define the provider and functionality of the DHCP client. The information is represented by a string of variable length consisting of characters or octets that have the value specified by the DHCP client provider. One of the methods allows the DHCP client to notify the server that it uses a certain type of low-level software or firmware to fill in the Vendor Class Identifier (VCI) option (option 60). This method allows you to distinguish between requests from client machines and processes. The VCI option value gives the DHCP server a hint about any additional information that needs to be sent to the client in response.

Protocol device

DHCP is a client-server protocol, that is, a DHCP client and a DHCP server are involved in its work. Data transfer is performed using the UDP protocol. By default, requests from the client are made on port 67 to the server, the server in turn responds to port 68 to the client, issuing an IP address and other necessary information, such as a network mask, a router and DNS servers.

DHCP message structure

All DHCP messages are divided into fields, each of which contains certain information. All fields except the last (DHCP options fields) have a fixed length.

An example of the process of obtaining the address (the algorithm of the DHCP)

Consider an example of the process of obtaining an IP address by a client from a DHCP server. Suppose the client does not yet have its own IP-address, but he knows his previous address - 192.168.1.100. The process consists of four stages.

DHCP discovery

Initially, the client performs a broadcast request across the entire physical network in order to discover available DHCP servers. It sends a message like DHCPDISCOVER , while 0.0.0.0 is specified as the source IP address (since the computer does not have its own IP address yet), and the destination address is the broadcast address 255.255.255.255.

The client fills several message fields with initial values:

• The xid field contains a unique transaction identifier , which allows you to distinguish this process of obtaining an IP address from others proceeding at the same time.
• The chaddr field contains the client’s hardware address (MAC address).
• The options field indicates the last IP address known to the client. In this example, this is 192.168.1.100. This is optional and can be ignored by the server.

The DHCPDISCOVER message can be propagated outside the local physical network with the help of specially configured DHCP relay agents that redirect clients' DHCP messages to servers on other subnets.

Not always the process of obtaining an IP address begins with DHCPDISCOVER . If the client has previously received an IP address and its lease has not yet passed - the client can skip the DHCPDISCOVER stage, starting with a DHCPREQUEST request sent with the server identifier that issued the address last time. If there is no response from the DHCP server that issued the settings last time, the client sends a DHCPDISCOVER . Thus, the client begins the process of obtaining from the beginning, already accessing all DHCP servers in the network segment.

DHCP offer

After receiving a message from the client, the server determines the required configuration of the client in accordance with the settings specified by the network administrator. In this case, the DHCP server agrees with the requested client address 192.168.1.100. The server sends it a response ( DHCPOFFER ) in which it offers the configuration. The IP address offered to the client is indicated in the yiaddr field. Other parameters (such as addresses of routers and DNS servers) are indicated as options in the corresponding field.

This message is sent by the DHCP server to the host that sent the DHCPDISCOVER to its MAC. In certain circumstances, the message can be distributed as a broadcast. A client may receive several different DHCP offers from different servers; of them, he must choose the one that “suits” him.

DHCP request

By selecting one of the configurations suggested by the DHCP servers, the client sends a DHCP request ( DHCPREQUEST ). It is broadcast; at the same time, a special option is added to the options specified by the client in the DHCPDISCOVER message - server ID — indicating the address of the DHCP server selected by the client (in this case, 192.168.1.1).

DHCP acknowledgment

Finally, the server acknowledges the request and sends this acknowledgment ( DHCPACK ) to the client. After that, the client must configure its network interface using the options provided.

Kind of posts

Below are the values ​​of each field for each of the DHCP messages sent during the process.

Other DHCP messages

Помимо сообщений, необходимых для первоначального получения IP-адреса клиентом, DHCP предусматривает несколько дополнительных сообщений для выполнения иных задач.

Отказ DHCP

Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP ( DHCPDECLINE ), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.

Сообщение отмены DHCP ( DHCPNAK ). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.

Освобождение DHCP

Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP ( DHCPRELEASE ) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно.

Информация DHCP

Сообщение информации DHCP ( DHCPINFORM ) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизаторапо умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.

Implementations

Компания Microsoft впервые включила сервер DHCP в поставку серверной версии Windows NT 3.5, выпущенной в 1994 году. Начиная с Windows 2000 Server реализация DHCP-сервера от Microsoft позволяет динамически обновлять записи DNS, что используется в Active Directory.

Internet Systems Consortium выпустил первую версию ISC DHCP Server (для Unix-подобных систем) 6 декабря 1997 года. 22 июня 1999 года вышла версия 2.0, более точно соответствующая стандарту.

Компания Cisco включила сервер DHCP в Cisco IOS 12.0 в феврале 1999 года. Sun добавила DHCP-сервер в Solaris 8 в июле 2001 года.

В настоящее время существуют реализации сервера DHCP для ОС Windows в виде отдельных программ, в том числе открытых ^[2] , позволяющих выполнять роль сервера DHCP компьютерам под управлением не серверных версий данной ОС.

Недостатки DHCP

Освобождая сетевых администраторов от множества рутинных операций, DHCP оставляет нерешенными ряд проблем, которые рано или поздно могут возникнуть в реальной сетевой среде.

К недостаткам этого протокола прежде всего следует отнести крайне низкий уровень информационной безопасности, что обусловлено непосредственным использованием протоколов UDP и IP. В настоящее время не существует практически никакой защиты от появления в сети несанкционированных DHCP-серверов, способных рассылать клиентам ошибочную или потенциально опасную информацию - некорректные или уже задействованные IP-адреса, неверные сведения о маршрутизации и т.д. И наоборот, клиенты, запущенные с неблаговидными целями, могут извлекать конфигурационные сведения, предназначенные для <законных> компьютеров сети, и тем самым оттягивать на себя значительную часть имеющихся ресурсов. Понятно, что возможности административного ограничения доступа, о которых говорилось выше, не способны закрыть эту брешь в системе информационной безопасности.

По мнению некоторых экспертов, в настоящее время DHCP недостаточно отказоустойчив. Протоколу явно недостает механизма активного уведомления клиентов об экстремальных ситуациях (например, о систематической нехватке адресов) и серверного подтверждения об освобождении адреса, иногда в сети наблюдаются всплески числа запросов на повторное использование адресов и т.д. Впрочем, работа над протоколом еще не завершена, и не исключено, что некоторые недостатки будут устранены в последующих редакциях.

* * *

Приступая к написанию статьи, автор ставил себе целью изложить основные принципы DHCP, которые позволили бы читателю получить представление о работе этого протокола, а также сопоставить его с другими механизмами распределения сетевых адресов. Многие детали при этом остались за кадром, однако следует иметь в виду, что DHCP еще не приобрел статуса индустриального стандарта, поэтому в ближайшее время могут увидеть свет новые его модификации.

Тем не менее, как частенько бывает в сетевой индустрии, механизмы DHCP уже реализованы в продуктах ряда производителей. К счастью, любые изменения в алгоритмах его работы легко учесть на программном уровне, так что, приобретая серверное или клиентское программное обеспечение определенной компании, можно не опасаться заточения в неприступную крепость патентованных решений. Скорее, следует обратить внимание на то, насколько удачно конкретная реализация DHCP вписывается в имеющуюся вычислительную среду и взаимодействует с другими сетевыми службами, в частности с DNS. Публикуемые в этом номере результаты сравнительных испытаний DNS- и DHCP-серверов (см. статью <Игра в имена>) способны стать неплохим подспорьем для пользователя.

Стоит принять во внимание и слабые стороны протокола, о которых говорилось выше. Внедряя в своей сети средства DHCP, администратор должен быть готов к возникновению проблем принципиального характера. Остается только надеяться, что их количество уменьшится в стандартизованном варианте протокола DHCP.

Распределение IP-адресов: возможны варианты

BOOTP, DRARP, TFTP, ICMP, NIP - вероятно, это еще не полный перечень протоколов, в той или иной мере претендующих на решение задачи управления IP-адресами и конфигурацией в сетевой среде. Не исключено, что после стандартизации DHCP довольно быстро вытеснит их со сцены, однако на сегодняшний день многие из названных протоколов нередко упоминаются в литературе и используются в готовых продуктах.

Like DHCP, the Bootstrap Protocol (BOOTP) today also has the status of a preliminary standard and is recommended for use by the IETF consortium. It should be considered the immediate predecessor of DHCP. The additions that appeared in 1993 expanded the list of configuration parameters covered by the BOOTP protocol. Moreover, by now even a modification of BOOTP has been proposed that supports dynamic assignment of IP addresses.

Протокол Reverse Address Resolution Protocol (RARP), впервые описанный в июне 1984 г. (RFC 903), используется компанией Sun Microsystems и рядом других производителей, в частности, для запуска бездисковых рабочих станций. Основной принцип его работы сводится к тому, что клиент должен самостоятельно отыскать свой IP-адрес, а не принять адрес, выделенный сервером. Сравнительно недавно появился динамический вариант этого протокола (Dynamic RARP, DRARP), реализующий алгоритм автоматического присвоения IP-адресов. Стоит отметить, что изначальный вариант RARP не поддерживает передачу клиенту каких-либо параметров конфигурации (кроме IP-адреса), в том числе применяемых при маршрутизации. В результате один сервер RARP способен обслуживать только одну локальную сеть.

A simplified version of FTP — the Trivial File Transfer Protocol (TFTP) protocol — was released about 20 years ago; its second version is described in RFC 783. In fact, TFTP provides a transport mechanism for transferring a client system’s boot image from a server.

The Internet Control Message Protocol (ICMP) today can also be attributed to the generation of veterans of the World Wide Web. It allows computers to be informed about the presence of additional routers in the network (there is a special mechanism for detecting these devices), provides special types of messages for transmitting the subnet mask and other official information.

Finally, the Network Information Protocol (NIP) was developed in the late 1980s. employees at MIT as a distributed mechanism for dynamically assigning IP addresses on Ethernet networks.

Note also the specifications of RFC 1122 and 1123, which are used by a number of protocols (including DHCP). They contain requirements for the procedure for changing the configuration of computers on a network and, in addition, suggest a scenario for the initial configuration of diskless stations.

DHCP and VLAN: there are more differences than similarities

From time to time, one can come across a statement that DHCP and virtual private network technology (VLAN) are aimed at solving the same problem: they must ensure the free movement of clients in a network environment. In fact, the above abbreviations conceal two completely different concepts, and the approach based on virtual drugs is much more revolutionary.

The DHCP server and relay agents enable you to configure the computer’s configuration settings so that, after being removed from one subnet and connected to another, it immediately becomes a full member of the new subnet (since the configuration of the moved machine changes automatically). If, in addition, support is provided for a dynamic domain name server (Dynamic DNS), the computer acquires its former name.

The network equipment endowed with the dynamic formation of virtual LANs makes it possible to determine the network configuration in such a way that no matter which port of the hub or switch the client station is connected to, it will receive the same IP address and name and be included in the previously described virtual network. local network. The distribution of MAC addresses over virtual LANs can be set by the network configuration itself. Another option assumes that IP addresses are recognized by the packets that come from the client stations.

So, the differences between the DHCP protocol and the VLAN technology can be summarized as follows:

• DHCP changes the configuration of the roaming computer, whereas on a VLAN-enabled network, the network port to which the computer is connected changes;
• Dynamic reconfiguration by means of DHCP requires a DHCP server, a relay agent in each router, and TCP / IP client software support for this protocol. In the case of the use of VLAN technology, the same VLAN scheme must be supported by all hubs (switches) of the network, which opens up a wide scope for proprietary implementations;
• DHCP allows you to configure a new client station, but VLAN tools do not;
• DHCP protocol serves primarily to provide the most dynamic configuration of a network divided into subnets according to a territorial basis. The main purpose of VLAN technology is to unite users not according to geographical, but according to some other, for example, functional, principle (according to the nature of their activity or role in the company's business).

As is clear from this brief comparison, the simultaneous use of DHCP on a network (or its prototype BOOTP) and VLAN facilities can lead to serious conflicts. So, if the grouping of clients into virtual local networks is carried out on the basis of source IP addresses (i.e., a predefined configuration), then receiving configuration data over the network from a DHCP server is excluded.

3. Client-server protocol. DHCP algorithm

DHCP uses the BOOTP message format defined in RFC-951 and presented in Table 1 and Figure 2. 1. The 'op' field of each DHCP message sent by the client to the server contains a BOOTREQUEST. In the 'op' field of the DHCP message sent by the server to the client, BOOTREPLY is entered.

The first 4 octets of the option field of the DHCP message contain (decimal) codes 99, 130, 83, and 99, respectively (these are the same (magic cookie) codes as defined in RFC-1497 [17]). The rest of the 'options' field consists of a list of flagged parameters, called "options". All vendor extensions listed in RFC-1497 are also DHCP options. RFC-1533 provides a full set of options defined for use with DHCP.

Several options are already defined. One of them is the option "DHCP message type", which should be included in all DHCP messages. This option specifies the type of DHCP message. Additional options may be allowed, required or not allowed depending on the type of DHCP message.

For the purposes of this document, DHCP messages that contain the DHCP Message Type option will be interpreted according to the message type; for example, a DHCP message with an option type equal to 1 will be interpreted as a "DHCPDISCOVER" message.

3.1. Client and server interaction when allocating a network address

Below is a protocol exchange between the client and the server of the DHCP messages described in Table 2. The timing diagram in Figure 2. 3 shows a typical client / server interaction scheme. If the client already knows his address, some steps may be omitted; such simplified interaction is described in section 3.2.

Table 2: DHCP Messages

Fig. 3. Temporary messaging diagram between the DHCP client and the server during the assignment of a new network address

If the selected server cannot adequately respond to a DHCPREQUEST message (for example, the requested network address has already been allocated), the server should respond by sending a DHCPNAK message.

The server should mark the address offered to the client in the DHCPOFFER message as available if the server has not received any DHCPREQUEST message from the client.

The client implements a timeout and resends the DHCPREQUEST message if the client does not receive either DHCPACK or DHCPNAK messages. The client resends the DHCPREQUEST according to the re-forwarding algorithm described in section 4.1. The client must select an adequate number of retransmissions of the DHCPREQUEST message in order to ensure a sufficient likelihood of access to the server without forcing the client (and the user of this client) to wait too long; for example, a client, performing a re-forwarding as described in section 4.1, may re-send a DHCPREQUEST message four times, with a total delay of 60 seconds, before re-starting the initialization procedure. If the client does not receive either a DHCPACK or a DHCPNAK message after applying the re-forwarding algorithm, the client returns to its original state and restarts the initialization process. The client must notify the user that the initialization process has failed and a retry is made.

3.2. Client and server interaction when reusing previously allocated network addresses

If the client remembers and wants to use the previously allocated network address, it may omit some of the steps described in the previous section. The timing diagram in fig. Figure 4 shows the typical client and server interaction in the case of reusing the old network address.

Fig. .four. Timing messaging diagram between a DHCP client and server when reassigning a previously used network address

If the client request is not correct (for example, the client has moved to another subnet), the servers should respond by sending a DHCPNAK message to the client. Servers should not respond if their information is not absolutely reliable. For example, a server that identifies a request for a parameter set that belongs to another server and has an expired validity, the server should not respond with a DHCPNAK message, unless the servers explicitly use a coherent mechanism.

If the 'giaddr' in the DHCPREQUEST message is 0x0, the client is on the same subnet as the server. The server must broadcast a DHCPNAK message at 0xffffffff, because the client may not have the correct network address or network mask, and the client may not respond to an ARP request. Otherwise, the server should send a DHCPNAK message to the IP address of the BOOTP transport agent recorded in 'giaddr'. The transport agent, in turn, forwards the message directly to the client’s hardware address, so DHCPNAK will be delivered even if the client has moved to another network.

If the client detects that the IP address in the DHCPACK message has already been used, the client should send a DHCPDECLINE message to the server and rerun the configuration process by sending a request to the new network address. This action corresponds to the client transition to the INIT state in the DHCP state diagram, which is described in section 4.4.

If the client receives a DHCPNAK message, it cannot reuse its memorized network address. It must instead request a new address by re-running the configuration process. This action corresponds to the client transitioning to the INIT state in the DHCP state diagram.

The client times out and resends the DHCPREQUEST message. If the client does not receive either the DHCPACK message or the DHCPNAK, the client re-sends the DHCPREQUEST message according to the algorithm in section 4.1. The client must select an adequate number of retransmissions of the DHCPREQUEST message in order to ensure a sufficient likelihood of access to the server without forcing the client (and the user of this client) to wait too long. For example, a client, performing a re-forwarding as described in section 4.1, can retransmit the DHCPREQUEST message four times with a total delay of 60 seconds before re-starting the initialization procedure. If the client has not received any DHCPACK or DHCPNAK messages after the second transfer, it can decide to use the previously assigned network address and configuration parameters until their expiration date. This corresponds to the transition to the BOUND state in the client state diagram shown in Figure 2. five.

Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.

3.3. Интерпретация и представление значений времени

Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.

Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.

Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных.

3.4. Получение параметров при внешне заданных адресах

Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.

Сервер в целях совместимости должен проверить сетевой адрес в сообщении DHCPINFORM, но не должен проверять существующее значение времени действия конфигурационного набора. Сервер формирует сообщение DHCPACK, содержащее конфигурационные параметры для клиента, приславшего запрос, и посылает сообщение DHCPACK непосредственно клиенту.

3.5. Параметры клиента в DHCP

Не все клиенты требуют инициализации всех параметров, перечисленных в приложении A. Используются два способа сокращения числа параметров, пересылаемых от сервера клиенту. 1. Большинство параметров имеет значения по умолчанию, определенные в Host Requirements RFC; если клиент не получил параметров от сервера, которые переписывают значения по умолчанию, клиент использует эти значения. 2. В своем исходном сообщении DHCPDISCOVER или DHCPREQUEST, клиент может предоставить серверу список специфических параметров, которые ему нужны. Если клиент включает список параметров в сообщение DHCPDISCOVER, он должен включать этот список в любое последующее сообщение DHCPREQUEST.

Клиент должен включить опцию 'maximum DHCP message size', чтобы позволить серверу знать, максимальный размер его DHCP-сообщений. Параметры, присланные в ответ клиенту, могут иметь размер больший, чем выделено для опций в сообщении DHCP. В этом случае, два дополнительных опционных флага (которые должны присутствовать в поле 'опции' сообщения) индицируют, что для опций должны использоваться поля 'file' и 'sname'.

Клиент может проинформировать сервер о том, в каких конфигурационных параметрах заинтересован клиент, включив опцию 'parameter request list'.

Кроме того, клиент может предложить значения для сетевого адреса и времени его действия в сообщении DHCPDISCOVER. Клиент может включить опцию 'requested IP-адрес', чтобы предложить конкретное значение IP-адреса, которое он хотел бы получить, и может включить опцию 'IP-адрес lease time', чтобы предложить предпочтительное значение времени действия конфигурационного набора. Другие опции, представляющие рекомендации по конфигурационным параметрам, допустимы в сообщении DHCPDISCOVER или DHCPREQUEST. Однако дополнительные опции могут игнорироваться серверами, и разные серверы могут прислать различные отклики на одни и те же опции. Опция 'requested IP-адрес' должна заноситься только в сообщение DHCPREQUEST, когда клиент проверяет конфигурационные параметры, полученные ранее. Клиент заполняет поле 'ciaddr', только когда он имеет корректный IP-адрес в состояниях BOUND, RENEWING или REBINDING.

Если сервер получает сообщение DHCPREQUEST с некорректным 'запрошенным IP-адресом', он должен прислать клиенту сообщение DHCPNAK и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.

3.6. Применение DHCP для клиентов с несколькими интерфейсами

Клиент с несколькими сетевыми интерфейсами должен использовать DHCP для получения конфигурационных параметров через каждый из интерфейсов независимо.

3.7. Когда клиентам следует использовать DHCP?

Клиент должен использовать DHCP для нового запроса или верификации своего IP-адреса и сетевых параметров всякий раз, когда локальные конфигурационные параметры изменились; например, во время перезагрузки системы или после сетевого разрыва, так как локальная сетевая конфигурация может измениться без информирования об этом клиента или пользователя.

Если клиент знает предыдущий сетевой адрес и не может контактировать с локальным DHCP-сервером, клиент может продолжать использовать предыдущий сетевой адрес до тех пор, пока время действия адреса не истечет. Если время действия исчерпано до того, как клиент смог контактировать с DHCP-сервером, клиент должен немедленно прекратить использование текущего сетевого адреса и может проинформировать о данной проблеме локального пользователя.

Источники информации

Спецификация протокола DHCP описана в RFC 2131 и ряде вспомогательных документов, перечень и тексты которых можно найти в Internet по адресу http://www.ietf.org/html.charters/dhc-charter.html . Там же имеется обширный список предварительных спецификаций (Internet Drafts), регламентирующих различные аспекты работы данного протокола.

Документы RFC содержатся и на ряде других Web-серверов, например http://info.internet.isi.edu/ls/in-notes/rfc/ ; http://www.cis.ohio-state.edu/hypertext/information/rfc.html ; http://www.pmg.lcs.mit.edu/rfc.html .

Подборка документов Internet Drafts по протоколу DHCP размещена на серверах ftp.bucknell.edu/pub/dhcp/ и http://www.bucknell.edu/~droms/dhcp/ .

Информация по протоколу DHCP, что называется, из первых рук, а также многие вспомогательные материалы доступны на сервере соответствующей рабочей группы: http://www.dhcp.org .