Интегрированные сети ISDN

         

Поля и опции, используемые DHCP-серверами



Таблица 3. Поля и опции, используемые DHCP-серверами



Поле

DHCPOFFER

DHCPACK

DHCPNAK

'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' Из RFC "Assigned Numbers"    
'hlen' Длина аппаратного адреса в октетах    
'hops' 0 0 0
'xid' 'xid' из сообщения клиента DHCPDISCOVER 'xid' из сообщения клиента DHCPREQUEST 'xid' из сообщения клиента DHCPREQUEST
'secs' 0 0 0
'ciaddr' 0 'ciaddr' из DHCPREQUEST или 0 0
'yiaddr' IP-адрес предложенный клиенту IP-адрес присвоенный клиенту 0
'siaddr' IP-адрес следующего сервера загрузки IP-адрес следующего сервера загрузки 0
'flags' 'flags' из сообщения клиента DHCPDISCOVER флаги' из сообщения клиента DHCPREQUEST 'flags' из сообщения клиента DHCPREQUEST
'giaddr' 'giaddr' из сообщения клиента DHCPDISCOVER 'giaddr' из сообщения клиента DHCPREQUEST 'giaddr' >из сообщения клиента DHCPREQUEST
'chaddr' 'chaddr' из сообщения клиента DHCPDISCOVER 'chaddr' из сообщения клиента DHCPREQUEST 'chaddr' из сообщения клиента DHCPREQUEST
'sname' Имя ЭВМ сервера

или опции

Имя ЭВМ сервера

или опции

(не используется)
'файл' Файл загруз. клиента

имя или опции

Файл загруз. клиента

имя или опции

(не используется)
'опции' опции опции  

Опция

DHCPOFFER

DHCPACK

DHCPNAK

Запрошенный IP-адрес не должен не должен не должен
IP-адрес lease time должен должен (DHCPREQUEST)

не должен (DHCPINFORM)

не должен
Использование полей 'файл'/'sname' может может не должен
Тип сообщения DHCP DHCPOFFER DHCPACKDHCPNAK  
Список параметров не должен не должен не должен
Сообщение должен должен должен
Идентификатор клиента не должен не должен может
Идентификатор Vendor class может может может
Идентификатор сервера должен должен должен
Макс. размер сообщения не должен не должен не должен
Все прочие может может не должен

Раз сетевой адрес и конфигурационный набор параметров определены, сервер формирует сообщение DHCPOFFER с предлагаемыми конфигурационными параметрами.
Для всех DHCP-серверов важно прислать одни и те же параметры (с единственно возможным исключением – новым предлагаемым сетевым адресом), что гарантирует предсказуемое поведение клиента вне зависимости от того, какой из серверов он выберет. Конфигурация параметров должна быть выбрана согласно следующим правилам, представленным ниже. Сетевой администратор ответственен за конфигурацию всех DHCP-серверов, что гарантирует однородность откликов этих серверов. Сервер должен прислать клиенту:


o Сетевой адрес клиента, как это определено правилами приведенными выше,
o Время действия клиентского набора, как это определено правилами из данного раздела,
o Параметры, запрошенные клиентом, согласно следующим правилам:
  - Если в сервере явно задано значение параметра по умолчанию, сервер должен включить это значение в соответствующую опцию поля 'option', в противном случае
  - Если сервер распознает параметр, как параметр, определенный в документе Host Requirements, сервер должен включить его значение по умолчанию (как это рекомендуется в документе Host Requirements), в соответствующую опцию в поле 'option', в противном случае
  - Сервер не должен присылать значение этого параметра

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

o Любые параметры из существующего набора, которые отличаются от значений по умолчанию документа Host Requirements,
o Любые параметры, специфичные для клиента (как это с пецифицировано в содержимом 'chaddr' или 'client identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором,
o Любые параметры специфичные для этого класса клиента (как это идентифицировано в опции 'vendor class identifier' сообщения DHCPDISCOVER или DHCPREQUEST), например, сконфигурированные сетевым администратором;
o Параметры со значениями, неравными величинам по умолчанию для клиентской субсети.
<


Сервер может прислать 'vendor class identifier', использованный чтобы определить параметры в сообщении DHCPOFFER, чтобы помочь клиенту решить, какой выбрать DHCPOFFER. Сервер вводит поле 'xid' из сообщения DHCPDISCOVER в поле 'xid' сообщения DHCPOFFER и посылает клиенту, приславшему запрос, сообщение DHCPOFFER.

4.3.2. Сообщение DHCPREQUEST

Сообщение DHCPREQUEST может прийти от клиента, реагирующего на сообщение сервера DHCPOFFER, от клиента, верифицирующего ранее выделенный IP-адрес, или от клиента, расширяющего время действия конфигурационного набора. Если сообщение DHCPREQUEST содержит опцию 'server identifier', то это отклик на сообщение DHCPOFFER. В противном случае, сообщение является запросом верификации или расширения времени действия набора. Если клиент использует 'client identifier' в сообщении DHCPREQUEST, он должен использовать его во всех последующих сообщениях. Если клиент включил список запрашиваемых параметров в сообщение DHCPDISCOVER, он должен включить этот список во все последующие сообщения. Любые конфигурационные параметры в сообщении DHCPACK не должны конфликтовать с полученными ранее в сообщении DHCPOFFER. Клиент должен использовать для конфигурации параметры из сообщения DHCPACK. Клиенты посылают сообщения DHCPREQUEST следующим образом:
o DHCPREQUEST, сформированный в состоянии SELECTING:
Клиент вводит адрес выбранного сервера 'server identifier', 'ciaddr' должен быть равен нулю, в ‘запрошенный IP-адрес' должно быть записано значение yiaddr, взятое из DHCPOFFER.
Заметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать наилучшее предложение. Клиент определяет свой выбор путем идентификации сервера в сообщении DHCPREQUEST. Если клиент получает неприемлемые предложения, клиент может попробовать другое сообщение DHCPDISCOVER. Следовательно, серверы не могут получить DHCPREQUEST, из которого они могли бы решить, принял ли клиент данное предложение. Так как серверы не осуществили присвоение какого-либо сетевого адреса на основе DHCPOFFER, они вольны повторно использовать предложенные сетевые адреса в откликах на последующие запросы.


Серверы не должны повторно использовать предложенные адреса и могут реализовать зависимый от реализации механизм таймаутов в процессе принятия решения о повторном использовании предложенных адресов.
o DHCPREQUEST генерируется в состоянии INIT-REBOOT:
Поле 'server identifier' не должно быть заполнено, в опции 'Запрошенный IP-адрес' должен быть записан предшествующий адрес, присвоенный клиенту. 'ciaddr' должен быть равен нулю. Клиент пытается верифицировать присвоенный ранее конфигурационный набор. Сервер должен клиенту послать сообщение DHCPNAK, если ‘запрошенный IP-адрес’ не корректен, или относится к неверной сети.
Определение того, находится ли клиент в состоянии INIT-REBOOT, осуществляется просмотром содержимого 'giaddr', опции 'requested IP-адрес', и базы данных. Если DHCP-сервер обнаружит, что клиент находится не в той сети (т.e., результат наложения локальной маски субсети или маски удаленной субсети (если 'giaddr' не равно нулю) на опцию 'запрошенный IP-адрес' выдает не реальный результат), тогда сервер должен послать клиенту сообщение DHCPNAK. Если с сетью все в порядке, тогда DHCP-сервер должен проверить, корректна ли запись клиента о его IP-адресе. Если нет, сервер должен послать клиенту сообщение DHCPNAK. Если DHCP-сервер не имеет записи об этом клиенте, тогда он должен оставаться пассивным, и может выдать предупреждение сетевому администратору.
Если 'giaddr' в сообщении DHCPREQUEST равен 0x0, клиент находится в той же субсети, что и сервер. Сервер должен широковещательно послать сообщение DHCPNAK по адресу 0xffffffff, так как клиент не может иметь корректный сетевой адрес или сетевую маску, и клиент не может откликаться на ARP-запросы.
Если в сообщении DHCPREQUEST установлен 'giaddr', клиент находится в другой субсети. Сервер должен установить широковещательный бит в DHCPNAK, агент отклика пошлет клиенту сообщение DHCPNAK широковещательно, так как клиент может не иметь корректного сетевого адреса или сетевой маски, и клиент может не откликаться на ARP-запросы.


o DHCPREQUEST генерируется в состоянии RENEWING:
' server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается расширить срок действия конфигурационного набора. Это сообщение будет послано по уникастному адресу, таким образом, в обмен не будет вовлечено никаких агентов транспортировки. Так как 'giaddr' не заполнен, DHCP-сервер будет полагаться на значениеn 'ciaddr', и использовать его при передаче данных клиенту.
Клиент может пожелать обновить или расширить время действия конфигурационного набора до T1. Сервер может пожелать не расширять время действия (например, по решению сетевого администратора), но должен в любом случае откликнуться сообщением DHCPACK.
o DHCPREQUEST генерируется в состоянии REBINDING:
'server identifier' не должен быть заполнен, опция 'запрошенный IP-адрес' не должна быть заполнена, в 'ciaddr' должен быть записан IP-адрес клиента. В этой ситуации, клиент полностью сконфигурирован, и пытается увеличить время действия набора параметров. Это сообщение должно быть передано широковещательно по IP-адресу 0xffffffff. DHCP-сервер должен проверить корректность 'ciaddr' прежде чем откликаться на DHCPREQUEST. DHCPREQUEST от клиента в состоянии REBINDING имеет целью согласовать узлы, имеющие несколько DHCP-серверов, а также предложить механизм для согласования времен действия конфигурационных наборов, предлагаемых разными серверами. DHCP-сервер может расширить время действия набора параметров клиента, только если он имеет для этого административные привилегии.

4.3.3. Сообщение DHCPDECLINE

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

4.3.4. Сообщение DHCPRELEASE

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

4.3.5. Сообщение DHCPINFORM

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

4.3.6. Сообщения клиента

Содержание раздела