Lecture
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.
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).
DHCP provides three methods for allocating IP addresses:
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.
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.
The following definitions apply in this document:
DHCP client | A DHCP client is a computer connected to the Internet that uses DHCP to obtain configuration parameters, such as a network address. |
DHCP server | A DHCP server is a computer connected to the Internet that sends configuration parameters to a DHCP client. |
BOOTP forwarding agent | A BOOTP forwarding agent is a computer connected to the Internet or a router that communicates between a client and a DHCP server. DHCP is designed to be compatible with BOOTP protocol specifications. |
Binding | Pairing (binding) is a set of configuration parameters, including, at least, the IP address assigned to the DHCP client. Pairing is managed by DHCP servers. |
Below is a list of the main tasks of DHCP.
o | DHCP is a mechanism, not a policy. DHCP should be managed by local system administrators by setting the desired configuration parameters. |
o | Clients should not require manual configuration. Each client must be able to read the local configuration parameters. |
o | Networks should not require manual configuration for individual clients. Under normal circumstances, the network administrator should not enter any individual client configuration parameters. |
o | DHCP does not require a separate server for each subnet. |
o | The DHCP client should be ready to receive multiple responses to the request for configuration parameters. To increase reliability and speed, you can use multiple DHCP servers serving overlapping areas of the network. |
o | DHCP must coexist with computers that are manually configured. |
o | DHCP must be compatible with the BOOTP agent operation logic described in RFC-951 and RFC-1542 [21]. |
o | DHCP should service existing BOOTP clients. |
DHCP should:
o | Ensure that any specific network address is not used by more than one DHCP client at the same time. |
o | Support DHCP client configuration when starting restarting a DHCP client. The DHCP client should, with each request to the extent possible, be assigned the same set of configuration parameters (for example, a network address). |
o | Maintain the DHCP client configuration when the server is restarted, and, to the extent possible, the same set of configuration parameters should be assigned to the DHCP client. |
o | Allows you to automatically assign configuration settings to new clients to avoid manual configuration. |
o | Maintain a fixed or permanent assignment of configuration parameters for a given client. |
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:
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.
Code | Title | Length | Note |
---|---|---|---|
0 |
Pad |
0 octets |
Used to complement other options so that they align to the word boundary. |
one |
Subnet mask |
4 octets |
Must be sent after the “router” option (option 3) if both are enabled. |
2 |
Time offset |
4 octets |
|
3 |
Router |
multiple to 4 octets |
Available routers should be listed in order of preference. |
four |
Time server |
multiple to 4 octets |
Available servers for synchronization should be listed in order of preference. |
five |
Name Server |
multiple to 4 octets |
Available IEN 116 - server names must be listed in order of preference. |
6 |
Domain Name Server |
multiple to 4 octets |
Available DNS servers should be listed in order of preference. |
7 |
Log server |
multiple to 4 octets |
Available log-servers should be listed in order of preference. |
eight |
Cookie Server |
multiple to 4 octets |
|
9 |
LPR Server |
multiple to 4 octets |
|
ten |
Impress Server |
multiple to 4 octets |
|
eleven |
Resource Location Server |
multiple to 4 octets |
|
12 |
Host name |
at least 1 octet |
|
13 |
Boot file size |
2 octets |
The length of the boot image in 4-kilobyte blocks. |
14 |
Merit dump file |
at least 1 octet |
Path to the storage of emergency dumps. |
15 |
Domain Name |
at least 1 octet |
|
sixteen |
Swap Server |
4 octets |
|
17 |
Root path |
at least 1 octet |
|
18 |
Extensions path |
at least 1 octet |
|
255 |
End |
0 octets |
Used to mark the end of a field. |
Parameters of client IP level.
Code | Title | Length | Note |
---|---|---|---|
nineteen |
IP Forwarding Enable / Disable |
1 octet |
|
20 |
Non-Local Source Routing Enable / Disable |
1 octet |
|
21 |
Policy filter |
Multiple to 8 octets |
|
22 |
Maximum Datagram Reassembly Size |
2 octets |
|
23 |
Default IP Time-to-live |
1 octet |
|
24 |
Path MTU Aging Timeout |
4 octets |
|
25 |
Path MTU Plateau Table |
Multiple 2 octets |
Interface parameters IP-level.
Code | Title | Length | Note |
---|---|---|---|
26 |
Interface MTU |
2 |
|
27 |
All Subnets are Local |
one |
|
28 |
Broadcast Address |
four |
|
29 |
Perform Mask Discovery |
one |
|
thirty |
Mask Supplier |
one |
|
31 |
Perform Router Discovery |
one |
|
32 |
Router Solicitation Address |
four |
|
33 |
Static route |
Multiple to 8 octets |
Interface level communication options.
Code | Title | Length | Note |
---|---|---|---|
34 |
Trailer Encapsulation Option |
one |
|
35 |
ARP Cache Timeout |
four |
|
36 |
Ethernet encapsulation |
one |
TCP parameters
Code | Title | Length | Note |
---|---|---|---|
37 |
TCP Default TTL |
one |
|
38 |
TCP Keepalive Interval |
four |
|
39 |
TCP Keepalive Garbage |
one |
Parameters of services and applications.
Code | Title | Length | Note |
---|---|---|---|
40 |
Network Information Service Domain |
at least 1 octet |
|
41 |
Network Information Servers |
multiple to 4 octets |
|
42 |
Network Time Protocol Servers |
multiple to 4 octets |
|
43 |
Vendor Specific Information |
at least 1 octet |
|
44 |
NetBIOS over TCP / IP Name Server |
multiple to 4 octets |
|
45 |
NetBIOS over TCP / IP Datagram Distribution Server |
multiple to 4 octets |
|
46 |
NetBIOS over TCP / IP Node Type |
one |
|
47 |
NetBIOS over TCP / IP Scope |
at least 1 octet |
|
48 |
X Window System Font Server |
multiple to 4 octets |
|
49 |
X Window System Display Manager |
multiple to 4 octets |
|
64 |
Network Information Service + Domain |
at least 1 octet |
|
65 |
Network Information Service + Servers |
multiple to 4 octets |
|
68 |
Mobile IP Home Agent |
multiple to 4 octets |
|
69 |
Simple Mail Transport Protocol (SMTP) Server |
multiple to 4 octets |
|
70 |
Post Office Protocol (POP3) Server |
multiple to 4 octets |
|
71 |
Network News Transport Protocol (NNTP) Server |
multiple to 4 octets |
|
72 |
Default World Wide Web (WWW) Server |
multiple to 4 octets |
|
73 |
Default Finger Server |
multiple to 4 octets |
|
74 |
Default Internet Relay Chat (IRC) Server |
multiple to 4 octets |
|
75 |
Streettalk server |
multiple to 4 octets |
|
76 |
StreetTalk Directory Assistance (STDA) Server |
multiple to 4 octets |
DHCP extensions.
Code | Title | Length | Note |
---|---|---|---|
50 |
Requested IP address |
four |
|
51 |
IP address Lease Time |
four |
|
52 |
Option Overload |
one |
|
53 |
DHCP Message Type |
one |
|
54 |
Server identifier |
four |
|
55 |
Parameter Request List |
at least 1 octet |
|
56 |
Message |
at least 1 octet |
|
57 |
Maximum DHCP Message Size |
2 |
|
58 |
Renewal (T1) Time Value |
four |
|
59 |
Rebinding (T2) Time Value |
four |
|
60 |
Vendor class identifier |
at least 1 octet |
|
61 |
Client-identifier |
minimum 2 octets |
|
66 |
TFTP server name |
at least 1 octet |
|
67 |
Bootfile name |
at least 1 octet |
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.
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.
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.
Field | Description | Length (in bytes) |
---|---|---|
op | Message type For example, the values can be: BOOTREQUEST (1, request from client to server) and BOOTREPLY (2, response from server to client). | one |
htype | Type of hardware address. Valid values for this field are defined in RFC1700 Assigned Numbers. For example, for a 10 Mbps Ethernet MAC address, this field is 1. | one |
hlen | The length of the hardware address in bytes. For Ethernet MAC-address - 6. | one |
hops | The number of intermediate routers (called DHCP Relay Agents ) that the message went through. The client sets this field to 0. | one |
xid | A unique transaction identifier generated by the client at the beginning of the process for obtaining an address. | four |
secs | The time in seconds since the beginning of the process of obtaining the address. May not be used (in this case it is set to 0). | 2 |
flags | Field for flags - special parameters of the DHCP protocol. | 2 |
ciaddr | IP address of the client. It is filled in only if the client already has its own IP address and is able to respond to requests from the ARP (this is possible if the client performs the procedure for updating the address after the lease expires). | four |
yiaddr | The new client IP address offered by the server. | four |
siaddr | IP address of the server. Returned in the DHCP offer (see below). | four |
giaddr | The IP address of the relay agent, if one was involved in the delivery of the DHCP message to the server. | four |
chaddr | The hardware address (usually the MAC address) of the client. | sixteen |
sname | The optional server name as a null-terminated string. | 64 |
file | Optional file name on the server used by diskless workstations for remote boot. Like sname , is represented as a null-terminated string. | 128 |
options | DHCP options field. Various advanced configuration options are listed here. At the beginning of this field, four special bytes are specified with the values 99, 130, 83, 99 (“magic numbers”), allowing the server to determine the presence of this field. The field has a variable length, but the DHCP client must be ready to accept a DHCP message of 576 bytes in length (in this message, the options field is 340 bytes long). | variable |
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.
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 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.
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.
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).
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.
Below are the values of each field for each of the DHCP messages sent during the process.
|
|
|
|
Помимо сообщений, необходимых для первоначального получения IP-адреса клиентом, DHCP предусматривает несколько дополнительных сообщений для выполнения иных задач.
Если после получения подтверждения (DHCPACK) от сервера клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP ( DHCPDECLINE ), после чего процедура получения IP-адреса повторяется. Использование IP-адреса другим клиентом можно обнаружить, выполнив запрос ARP.
Сообщение отмены DHCP ( DHCPNAK ). При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса.
Клиент может явным образом прекратить аренду IP-адреса. Для этого он отправляет сообщение освобождения DHCP ( DHCPRELEASE ) тому серверу, который предоставил ему адрес в аренду. В отличие от других сообщений DHCP, DHCPRELEASE не рассылается широковещательно.
Сообщение информации DHCP ( DHCPINFORM ) предназначено для определения дополнительных параметров TCP/IP (например, адреса маршрутизаторапо умолчанию, DNS-серверов и т. п.) теми клиентами, которым не нужен динамический IP-адрес (то есть адрес которых настроен вручную). Серверы отвечают на такой запрос сообщением подтверждения (DHCPACK) без выделения IP-адреса.
Компания 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 оставляет нерешенными ряд проблем, которые рано или поздно могут возникнуть в реальной сетевой среде.
К недостаткам этого протокола прежде всего следует отнести крайне низкий уровень информационной безопасности, что обусловлено непосредственным использованием протоколов 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:
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.
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.
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.
one. | The client broadcasts the DHCPDISCOVER message over the local physical subnet. The DHCPDISCOVER message may include options that suggest values for the network address and the duration of its use. The BOOTP transport agent can send a message to DHCP servers that are located outside this physical subnet. |
2 | Each server can respond with a DHCPOFFER message that contains the network address in the 'yiaddr' field (and other configuration parameters in the DHCP options). Servers should not reserve the proposed network address, although the protocol will work more efficiently if the server avoids assigning the proposed network address to another client. When allocating a new address, the servers should check that the proposed network address is not used elsewhere; for example, the server can test the proposed address using an ICMP echo request. Servers must be implemented so that network administrators can select the desired tests for newly allocated addresses. The server sends a DHCPOFFER message to the client using, if necessary, BOOTP vehicles. |
Table 2: DHCP Messages
Message | Using |
DHCPDISCOVER | The client broadcasts a message to discover an available server. |
DHCPOFFER | It is sent by the server to the client in response to the DHCPDISCOVER message and contains a suggestion for configuration parameters. |
DHCPREQUEST | A client message to the server or (a) requesting parameters from one server and implicitly rejecting offers from other servers, (b) confirming the correctness of a previously assigned address after, for example, rebooting the system, or (c) requesting an extension of the lifetime of a specific network address. |
DHCPACK | It is sent by the server to the client and contains the configuration parameters, including the assigned network address. |
DHCPNAK | Sent by the server to the client, indicating that the network address is not correct (for example, the client has moved to a new subnet), or the client has expired |
DHCPDECLINE | The client and server found that the network address is already in use. |
DHCPRELEASE | It is sent by the client to the server in order to refuse the network address and cancels the remaining time of the address. |
DHCPINFORM | Sent by client to server for local configuration parameters; The client already has a network address received from outside. |
Fig. 3. Temporary messaging diagram between the DHCP client and the server during the assignment of a new network address
3 | A client receives one or more DHCPOFFER messages from one or more servers. The client may prefer to wait for several responses. The client selects one server to which it will send a request for configuration parameters, according to the proposal contained in the DHCPOFFER message. The client broadcasts a DHCPREQUEST message, which must contain the 'server identifier' option to indicate which server is selected by it, and which may include other options specifying the desired configuration values. The 'requested IP address' option in the DHCPOFFER server message should contain the value 'yiaddr'. The DHCPREQUEST message is broadcast by DHCP / BOOTP transport agents. To ensure that any BOOTP transport agent sends a DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message should use the same value of the 'secs' field of the DHCP message header and should be sent over the same broadcast IP address as the original DHCPDISCOVER message. The client implements a timeout and resends the DHCPDISCOVER message if it does not receive a DHCPOFFER message. |
four. | Servers receive a DHCPREQUEST broadcast message from the client. Servers not selected by the DHCPREQUEST message use the message as notifications that the client has rejected the server offer. The server selected by the DHCPREQUEST message writes the client's configuration set to persistent memory and responds with a DHCPACK message containing the configuration parameters for the client that sent the request. The combination of 'client identifier' or 'chaddr' and the assigned network address is a unique identifier for the duration of the client's address and is used by the client and server to identify this time in any DHCP message. Any configuration parameters in the DHCPACK message should not conflict with the parameters from the DHCPOFFER message to which the client responds. The server should not check the proposed network address. In the 'yiaddr' field of the DHCPACK messages, the selected network address is recorded. |
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.
five. | The client receives a DHCPACK message containing the configuration parameters. The client must perform a final check of the parameters (for example, run ARP for the allocated network address), and record the duration of the provision of the configuration parameters specified in the DHCPACK message. The client is finally configured. If the client detects that the address is already in use (for example, using ARP), it must send a DHCPDECLINE message to the server and rerun the configuration process. The client must wait at least 10 seconds before restarting the configuration procedure to avoid unnecessary network traffic. If the client receives a DHCPNAK message, the client restarts the configuration process. |
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.
6 | The client may decide to cancel the lease of the network address by sending a DHCPRELEASE message to the server. The client identifies the set of parameters that it refuses with its identifier, or 'chaddr' and the network address in the DHCPRELEASE message. If a client used a client identifier when it received a set of configuration parameters, the client must use the same client identifier in the DHCPRELEASE message. |
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.
one. | The client broadcasts a DHCPREQUEST message over the local subnet. The message includes the client’s network address in the 'requested IP address' option. Once the client has not received his network address, he does not have to fill in the 'ciaddr' field. BOOTP transport agents send a message to DHCP servers outside this subnet. If the client uses the 'client identifier' to obtain its address, the client must use the same 'client identifier' in the DHCPREQUEST message. |
2 | Servers that know the client’s configuration parameters respond with a DHCPACK message. Servers should not check if the client’s network address is already being used; The client may respond by sending an ICMP echo request. |
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.
3 | The client receives a DHCPACK message containing the configuration parameters. The client performs a final parameter check (as in Section 3.1), and marks the configuration validity time specified in the DHCPACK message. The action time value is implicitly specified by the 'client identifier' or 'chaddr' and the network address. From this point on, the client is considered configured. |
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.
four. | The client may decide to refuse the network address by sending a DHCPRELEASE message to the server. The client identifies the set of parameters that it refuses, using the 'client identifier', or 'chaddr' and the network address in the DHCPRELEASE message. |
Заметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, при корректном прерывании сессии (shutdown) он не должен отказываться от конфигурационного набора. Только в случае, когда клиенту нужно отказаться от конфигурационного набора, например, клиент намеривается перейти в другую субсеть, он будет должен послать сообщение DHCPRELEASE.
Клиент получает сетевой адрес на определенный период времени (который может быть бесконечным). В данном протоколе время измеряется в секундах. Значение времени 0xffffffff зарезервировано для обозначения бесконечности.
Так как клиент и сервер могут не иметь синхронизованных часов, значения времени в DHCP-сообщения являются относительными, и должны интерпретироваться с учетом показаний локальных часов клиента. Время измеряется в секундах и представляется в виде 32-битных кодов без знака. Это позволяет описывать относительные интервалы времени от 0 до примерно 100 лет, что вполне приемлемо для целей протокола DHCP.
Алгоритм интерпретации времени действия конфигурационного набора, представленный в предыдущем параграфе, предполагает, что часы клиента и сервера стабильны относительно друг друга. Если имеется относительный дрейф этих часов, сервер может считать время действия конфигурационного набора исчерпанным, а клиент - нет. Чтобы компенсировать такого рода эффект, сервер может послать клиенту значение времени действия короче того, которое он записывает в свою базу данных.
Если клиент получил сетевой адрес каким-то другим образом (например, при ручной конфигурации), он может использовать запрос-сообщение DHCPINFORM, чтобы получить другие локальные конфигурационные параметры. Серверы, получив сообщение DHCPINFORM, формируют сообщение DHCPACK с любыми конфигурационными параметрами, приемлемыми для клиента. При этом сетевой адрес не присваивается, не проверяется существующий набор параметров, не заполняется 'yiaddr' и не задаются параметры времени действия конфигурационного набора. Серверы должны послать ответ DHCPACK по уникастному адресу, заданному в поле 'ciaddr' сообщения DHCPINFORM.
Сервер в целях совместимости должен проверить сетевой адрес в сообщении DHCPINFORM, но не должен проверять существующее значение времени действия конфигурационного набора. Сервер формирует сообщение DHCPACK, содержащее конфигурационные параметры для клиента, приславшего запрос, и посылает сообщение DHCPACK непосредственно клиенту.
Не все клиенты требуют инициализации всех параметров, перечисленных в приложении 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 и может уведомить о проблеме системного администратора. Сервер может включить код ошибки в опцию сообщения.
Клиент с несколькими сетевыми интерфейсами должен использовать 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 .
Comments
To leave a comment
Computer networks
Terms: Computer networks