RFC 2132 DHCP Options and BOOTP Vendor Extensions

Network Working Group                                       S. Alexander
Request for Comments: 2132                        Silicon Graphics, Inc.
Obsoletes: 1533                                                 R. Droms
Category: Standards Track                            Bucknell University
                                                              March 1997

Опции DHCP и фирменные расширения BOOTP

DHCP Options and BOOTP Vendor Extensions

PDF

Статус документа

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашение к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Тезисы

Протокол динамической настройки конфигурации хоста (DHCP1) обеспечивает основу для передачи хостам конфигурационных параметров через сеть TCP/IP. Конфигурационные параметры и другая управляющая информация переносятся в помеченных элементах данных, которые записываются в поле options сообщения DHCP. Эти элементы данных называют также опциями.

Документ задает текущий набор опций DHCP. Новые опции будут задаваться в отдельных RFC. Текущий список действующих опций доступен по ссылке ftp://ftp.isi.edu/in-notes/iana/assignments2 [22].

Все фирменные расширения, определенные в RFC 1497 [2], могут использоваться в качестве опций DHCP. Определения из RFC 1497 включены в данный документ, который заменяет RFC 1497. Все опции DHCP, определенные в этом документе, за исключением описанных в разделе 9 опций DHCP, могут использоваться в качестве фирменных расширений BOOTP3.

Оглавление

Исключено в версии HTML.

1. Введение

Этот документ задает опции для использования в протоколах DHCP и BOOTP.

Полное описание формата пакетов DHCP приведено в спецификации DHCP [1], а пакетов BOOTP — в спецификации BOOTP [3]. Этот документ определяет формат информации в последнем поле пакетов DHCP (options) и BOOTP (vend). В оставшейся части этого раздела описано обобщенное использование этой области для предоставления информации, полезной для широкого класса машин, операционных систем и конфигураций. Сайты с одним сервером DHCP или BOOTP и разнотипными клиентами могут определять свои правила использования поля options.

В разделе 2 описаны форматы опций DHCP и фирменных расширений BOOTP. Раздел 3 посвящен опциям, определенным в предшествующих документах для использования с BOOTP (все они подходят для DHCP). Разделы 4 — 8 определяют новые опции, предназначенные для использования с DHCP и BOOTP, в разделе 9 определены опции, предназначенные только для DHCP.

Ссылки на дополнительные описания опций из разделов 2 — 6 приведены в разделе 12. Использование опций раздела 9 описано в спецификации DHCP [1].

Информация о регистрации новых опций приведена в разделе 10.

Этот документ обновляет определения опций DHCP/BOOTP, приведенные в RFC1533. Механизм классов расширен путем включения фирменных классов производителей, как лписано в параграфах 8.4 и 9.13. В разделе 10 описана процедура определения новых опций DHCP/BOOTP. Добавлено несколько новых опций, включая домен и сервер NIS+, домашний агент Mobile IP, серверы SMTP, TFTP и Bootfile. В параграфе 1.1 добавлены определения, используемые в этом документе. В параграф 9.14 добавлено обоснование необходимости уникальных идентификаторов клиентов.

1.1 Уровни требований

В этом документе слова, используемые для определения значимости конкретных требований выделены шрифтом. Эти уровни перечислены ниже.

MUST — необходимо

Это слово, а также термин требуется (REQUIRED) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

MUST NOT — недопустимо

Эта фраза означает абсолютный запрет в рамках спецификации.

SHOULD — следует

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

SHOULD NOT — не следует

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

MAY — возможно

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

1.2 Терминология

Ниже приведены определения используемых в документе терминов.

DHCP client – клиент DHCP

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

DHCP server – сервер DHCP

Сервером DHCP является хост Internet, который возвращает параметры конфигурации клиентам DHCP.

Binding — привязка

Привязкой называется набор параметров конфигурации, включающий как минимум адрес IP, который ассоциируется (привязан) к клиенту DHCP. Привязками управляет сервер DHCP.

2. Формат поля BOOTP Extension/DHCP Option

Опции DHCP имеют такой же формат, какой был определен для фирменных расширений BOOTP в RFC 1497 [2]. Опции могут иметь фиксированный или переменный размер. Все опции начинаются с октета тега, который однозначно указывает опцию. Опции фиксированного размера без данных содержат лишь октет тега. Фиксированный размер имеют лишь опции 0 и 255. Все остальные опции имеют переменный размер, указываемый октетом, следующим за октетом тега. Значение октета размера не учитывает два первых октета (тег и размер). За октетом размера следует заданное этим октетом число октетов данных. В опции с данными NVT ASCII не следует включать завершающий NULL-символ, однако получатели таких опций должны быть готовы удалить такие символы в конце полученных опций. Получателям недопустимо требовать включение в данные завершающего NULL-символа. Для некоторых опций переменного размера поле размера всегда имеет одинаковое значение, но его все равно нужно указывать.

Все опции, определенные после этого документа, должны включать октет размера даже при постоянном (в том числе 0) размере опции.

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

При использовании с BOOTP первые 4 октета поля информации производителя содержат значение magic cookie (предложено в RFC 951). Это поле указывает режим интерпретации последующих данных. Значение magic cookie в четырех первых октетах будет в десятичном формате с разделением точками 99.130.83.99 (шестнадцатеричное 63.82.53.63) с сетевым порядком байтов.

Все фирменные расширения (vendor extensions) из RFC 1497 являются также опциями DHCP.

Опции с десятичными кодами от 128 до 254 зарезервированы для локального (site-specific) определения.

Все опции, за исключением описанных в разделе 9, могут применяться как с DHCP, так и с BOOTP.

Многие из этих опций имеют принятые по умолчанию значения, которые определены в других документах. В частности, RFC 1122 [4] задает принятые по умолчанию значения для большинства параметров конфигурации IP и TCP.

Многие опции содержат один или несколько 32-битовых адресов IP. Использование IP-адресов вместо полных доменных имен FQDN (Fully-qualified Domain Name) может осложнить смену адресов IP в будущем. Использования таких адресов следует избегать на сайтах, где может потребоваться смена адресов.

3. Фирменные расширения RFC 1497

В этом разделе описаны фирменные расширения из RFC 1497. Раздел представлен лишь для полноты.

3.1. Заполнение

Опция pad может использоваться для выравнивания следующего поля по границе слова.

 Code
+-----+
|  0  |
+-----+


Поле code для опции pad имеет значение 0, а размер опции всегда составляет 1 октет.

3.2. Конец опций

Опция end указывает завершение действительной информации в поле vendor. Последующие октеты следует заполнять опцией pad.

Код опции end имеет значение 255, а размер опции всегда составляет 1 октет.

 Code
+-----+
| 255 |
+-----+


3.3. Маска подсети

Опция subnet mask задает маску подсети клиента в соответствии с RFC 950 [5].

Если в отклике DHCP указаны сразу опции subnet mask и router, маска подсети должна быть впереди.

Поле code для опции subnet mask имеет значение 1, а ее размер составляет 4 октета.

 Code   Len        Subnet Mask
+-----+-----+-----+-----+-----+-----+
|  1  |  4  |  m1 |  m2 |  m3 |  m4 |
+-----+-----+-----+-----+-----+-----+


3.4. Часовой пояс

Поле time offset4 задает временной сдвиг подсети клиента относительно часового пояса UTC5. Сдвиг указывается 32-битовым целым числом с дополнением до 2. Положительные значения указывают смещение к востоку от нулевого меридиана, отрицательные — к западу.

Поле code для опции time offset имеет значение 2, а ее размер составляет 4 октета.

 Code   Len        Time Offset
+-----+-----+-----+-----+-----+-----+
|  2  |  4  |  n1 |  n2 |  n3 |  n4 |
+-----+-----+-----+-----+-----+-----+


3.5. Маршрутизаторы

Опция router указывает список адресов IP для маршрутизаторов в подсети клиента. Маршрутизаторы следует указывать в порядке предпочтений.

Поле code для опции router имеет значение 3. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  3  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.6. Сервер времени

Опция time server задает список серверов времени RFC 868 [6], доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции time server имеет значение 4. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  4  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.7. Сервер имен

Опция name server задает список серверов имен IEN 116 [7], доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  5  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции name server имеет значение 5. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

3.8. Сервер DNS

Опция domain name server задает список серверов имен DNS6 (STD 13, RFC 1035 [8]), доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  6  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции domain name server имеет значение 6. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

3.9. Log-сервер

Опция log server задает список серверов протоколирования MIT-LCS UDP, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции log server имеет значение 7. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  7  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.10. Сервер Cookie

Опция cookie server задает список cookie-серверов RFC 865 [9], доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции log server имеет значение 8. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  8  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.11. Сервер LPR

Опция LPR server задает список серверов печати RFC 1179 [10], доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции LPR server имеет значение 9. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  9  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.12. Сервер Impress

Опция Impress server задает список серверов Imagen Impress, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции Impress server имеет значение 10. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  10 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.13. Сервер местоположения ресурсов

Опция задает список серверов Resource Location RFC 887 [11], доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  11 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для этой опции имеет значение 11. Минимальный размер опции составляет 4 октета, а реальный размер должен быть кратным 4.

3.14. Имя хоста

Эта опция указывает имя клиента, которое может (но не обязано) быть полным именем в локальном домене (см. описание получения доменного имени в параграфе 3.17). Ограничения на использование символов даны в RFC 1035.

Поле code для этой опции имеет значение 12, а минимальный размер составляет 1 октет.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  12 |  n  |  h1 |  h2 |  h3 |  h4 |  h5 |  h6 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


3.15. Размер загрузочного файла

Эта опция задает размер используемого по умолчанию загрузочного файла для клиента в 512-октетных блоках. Размер указывается 16-целым числом без знака.

 Code   Len   File Size
+-----+-----+-----+-----+
|  13 |  2  |  l1 |  l2 |
+-----+-----+-----+-----+


Поле code для этой опции имеет значение 13, а ее размер составляет 2 октета.

3.16. Путь для записи дампа памяти

Эта опция задает путь к файлу, в который должен сбрасываться дамп памяти клиента в случае отказа. Путь указывается строкой символов NVT ASCII.

 Code   Len      Dump File Pathname
+-----+-----+-----+-----+-----+-----+---
|  14 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+-----+-----+-----+-----+-----+-----+---


Поле code для этой опции имеет значение 14, а минимальный размер составляет 1 октет.

3.17. Имя домена

Эта опция задает имя домена, которое клиенту следует применять при преобразовании имен хостов с помощью DNS.

Поле code для этой опции имеет значение 15, а минимальный размер составляет 1 октет.

 Code   Len        Domain Name
+-----+-----+-----+-----+-----+-----+--
|  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
+-----+-----+-----+-----+-----+-----+--


3.18. Swap-сервер

Опция задает IP-адрес сервера, который клиент будет использовать для файла подкачки.

Поле code для этой опции имеет значение 16, а размер опции составляет 4 октета.

 Code   Len    Swap Server Address
+-----+-----+-----+-----+-----+-----+
|  16 |  n  |  a1 |  a2 |  a3 |  a4 |
+-----+-----+-----+-----+-----+-----+


3.19. Корневой путь

Эта опция задает путь к корневому диску клиента. Путь указывается строкой символов NVT ASCII.

Поле code для этой опции имеет значение 17, а минимальный размер составляет 1 октет.

 Code   Len      Root Disk Pathname
+-----+-----+-----+-----+-----+-----+---
|  17 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+-----+-----+-----+-----+-----+-----+---


3.20. Путь к расширениям

Строка для указания файла, доступного по протоколу TFTP и содержащего информацию, которая может быть интерпретирована как 64-октетное поле фирменного расширения производителя в отклике BOOTP с двумя исключениями:

  • размер файла не ограничен;

  • все ссылки на тег 18 (т. е. экземпляры поля BOOTP Extensions Path) в этом файле игнорируются.

Поле code для этой опции имеет значение 18, а минимальный размер составляет 1 октет.

 Code   Len      Extensions Pathname
+-----+-----+-----+-----+-----+-----+---
|  18 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+-----+-----+-----+-----+-----+-----+---


4. Параметры уровня IP для хоста

В этом разделе описаны опции, влияющие на работу уровня IP хоста в целом.

4.1. Опция управления пересылкой IP

Эта опция указывает, следует ли клиенту выполнять пересылку пакетов на уровне IP. Значение 0 отключает пересылку IP, 1 — включает .

 Code   Len  Value
+-----+-----+-----+
|  19 |  1  | 0/1 |
+-----+-----+-----+


Поле code для этой опции имеет значение 19, а ее размер составляет 1 октет.

4.2. Опция управления Non-Local Source Routing

Эта опция указывает, следует ли клиенту настраивать свой уровень IP на пересылку дейтаграмм с нелокальными маршрутами, заданными отправителем (см. обсуждение в параграфе 3.3.5 работы [4]). Значение 0 запрещает пересылку таких дейтаграмм, 1 — разрешает.

Поле code для этой опции имеет значение 20, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  20 |  1  | 0/1 |
+-----+-----+-----+


4.3. Опция фильтра правил

Эта опция задает фильтры правил для нелокальной маршрутизации, заданной отправителем. Фильтры представляют собой списки адресов IP и масок, которые задают пары получатель-маска для фильтрации входящих маршрутов source route.

Любую дейтаграмму source route, в которой адрес следующего маршрутизатора (next-hop) не соответствует фильтру, клиенту следует отбрасывать.

Дополнительная информация представлена в документе [4].

Поле code для этой опции имеет значение 21. Минимальный размер опции составляет 8 октетов, а реальный размер должен быть кратным 8 октетам.

 Code   Len         Address 1                  Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|  21 |  n  |  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
        Address 2                  Mask 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
|  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---


4.4. Максимальный размер собранной дейтаграммы

Эта опция задает максимальный размер дейтаграммы, которую клиент должен быть готов собрать. Размер указывает 16-битовым целым числом без знака. Минимальное пригодное значение составляет 576 октетов.

Поле code для этой опции имеет значение 22, а ее размер составляет 2 октета.

 Code   Len      Size
+-----+-----+-----+-----+
|  22 |  2  |  s1 |  s2 |
+-----+-----+-----+-----+


4.5. Используемое по умолчанию значение IP TTL

Эта опция задает принятое по умолчанию значение TTL7, которое клиенту следует использовать в исходящих дейтаграммах. TTL задается октетом со значениями от 1 до 255.

Поле code для этой опции имеет значение 23, а ее размер составляет 1 октет.

 Code   Len   TTL
+-----+-----+-----+
|  23 |  1  | ttl |
+-----+-----+-----+


4.6. Тайм-аут Path MTU

Эта опция задает время (в секундах) старения значений Path MTU, определенных с помощью механизмов RFC 1191 [12]. Тайм-аут указывается 32-битовым целым числом без знака.

Поле code для этой опции имеет значение 24, а ее размер составляет 4 октета.

 Code   Len           Timeout
+-----+-----+-----+-----+-----+-----+
|  24 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


4.7. Таблица значений Path MTU

Эта опция задает таблицу значений MTU для использования с механизмами Path MTU Discovery, определенными в RFC 1191. Таблица содержит набор 16-битовых целых чисел без знака, упорядоченных по возрастанию. Минимальное значение MTU не может быть меньше 68.

Поле code для этой опции имеет значение 25. Минимальный размер опции составляет 2 октета, а реальный размер всегда должен быть кратным 2 октетам.

 Code   Len     Size 1      Size 2
+-----+-----+-----+-----+-----+-----+---
|  25 |  n  |  s1 |  s2 |  s1 |  s2 | ...
+-----+-----+-----+-----+-----+-----+---


5. Параметры уровня IP для интерфейса

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

5.1. MTU для интерфейса

Эта опция задает значение MTU для интерфейса, указываемое 16-битовым целым числом без знака. Минимально допустимое значение MTU составляет 68 октетов.

Поле code для этой опции имеет значение 26, а ее размер составляет 2 октета.

 Code   Len      MTU
+-----+-----+-----+-----+
|  26 |  2  |  m1 |  m2 |
+-----+-----+-----+-----+


5.2. Опция All Subnets are Local

Эта опция указывает клиенту, может ли он считать что все подсети сети IP, к которой клиент подключен, используют то же значение MTU, что и подсеть клиента. Значение 1 указывает использование во всех подсетях одного значения MTU. Значение 0 говорит, что клиенту следует предполагать использование в некоторых подсетях, напрямую соединенных с сетью, меньших значений MTU.

 Code   Len  Value
+-----+-----+-----+
|  27 |  1  | 0/1 |
+-----+-----+-----+


Поле code для этой опции имеет значение 27, а ее размер составляет 1 октет.

5.3. Широковещательный адрес

Эта опция задает широковещательный адрес для использования в подсети клиента. Допустимые широковещательные адреса указаны в параграфе 3.2.1.3 документа [4].

Поле code для этой опции имеет значение 28, а ее размер составляет 4 октета.

 Code   Len     Broadcast Address
+-----+-----+-----+-----+-----+-----+
|  28 |  4  |  b1 |  b2 |  b3 |  b4 |
+-----+-----+-----+-----+-----+-----+


5.4. Определение маски

Эта опция показывает, следует ли клиенту определять маску подсети с помощью ICMP. Значение 0 указывает, что клиенту не следует выполнять определение маски, 1 указывает что это следует делать.

Поле code для этой опции имеет значение 29, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  29 |  1  | 0/1 |
+-----+-----+-----+


5.5. Опция Mask Supplier

Эта опция показывает, следует ли клиенту отвечать на запросы маски подсети с использованием ICMP. Значение 0 указывает, что клиенту не следует отвечать, 1 говорит, что отвечать на запросы следует.

Поле code для этой опции имеет значение 30, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  30 |  1  | 0/1 |
+-----+-----+-----+


5.6. Обнаружение маршрутизатора

Эта опция показывает, следует ли клиенту находить маршрутизаторы с помощью механизма Router Discovery, определенного в RFC 1256 [13]. Значение 0 указывает, что клиенту не следует выполнять обнаружение маршрутизаторов, 1 показывает, что следует.

Поле code для этой опции имеет значение 31, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  31 |  1  | 0/1 |
+-----+-----+-----+


5.7. Адрес для запросов обнаружения маршрутизаторов

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

Поле code для этой опции имеет значение 32, а ее размер составляет 4 октета.

 Code   Len            Address
+-----+-----+-----+-----+-----+-----+
|  32 |  4  |  a1 |  a2 |  a3 |  a4 |
+-----+-----+-----+-----+-----+-----+


5.8. Статический маршрут

Эта опция8 задает список статических маршрутов, которые клиенту следует поместить в свой кэш маршрутов. При наличии нескольких маршрутов к одному получателю их следует указывать в порядке снижения предпочтений.

Маршрут представляет собой список пар адресов IP, первым указывается адрес получателя, вторым — маршрутизатор.

Используемый по умолчанию маршрут (0.0.0.0) не пригоден в качестве статического (см. описание опции router в параграфе 3.5).

 Code   Len         Destination 1           Router 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|  33 |  n  |  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
        Destination 2           Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
|  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---


Поле code для этой опции имеет значение 33. Минимальный размер опции составляет 8 октетов, а реальный размер всегда должен быть кратным 8 октетам.

6. Параметры канального уровня для интерфейса

В этом разделе указаны опции, воздействующие на канальный уровень для отдельного интерфейса.

6.1. Трейлерная инкапсуляция

Эта опция показывает, следует ли клиенту согласовывать применение трейлеров (RFC 893 [14]) при использовании протокола ARP. Значение 0 говорит о том, что не следует пытаться использовать трейлеры, 1 указывает, что такую попытку следует предпринимать.

Поле code для этой опции имеет значение 34, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  34 |  1  | 0/1 |
+-----+-----+-----+


6.2. Тайм-аут для кэша ARP

Эта опция задает тайм-аут (в секундах) для записей кэша ARP. Время указывается 32-битовым целым числом без знака.

Поле code для этой опции имеет значение 35, а ее размер составляет 4 октета.

 Code   Len           Time
+-----+-----+-----+-----+-----+-----+
|  35 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


6.3. Инкапсуляция Ethernet

Эта опция показывает, следует ли клиенту использовать инкапсуляцию Ethernet Version 2 (RFC 894 [15]) или IEEE 802.3 (RFC 1042 [16]) на интерфейсе Ethernet. Значение 0 указывает применение инкапсуляции RFC 894, 1 — RFC 1042.

Поле code для этой опции имеет значение 36, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  36 |  1  | 0/1 |
+-----+-----+-----+


7. Параметры TCP

В этом разделе описаны опции, указывающие влияние на уровень TCP для отдельного интерфейса.

7.1. Опция TCP Default TTL

Эта опция задает принятое по умолчанию значение TTL, которое клиенту следует указывать при передаче сегментов TCP. Значение представляется 8-битовым целым числом без знака. Минимальное время жизни равно 1.

Поле code для этой опции имеет значение 37, а ее размер составляет 1 октет.

 Code   Len   TTL
+-----+-----+-----+
|  37 |  1  | 0/1 |
+-----+-----+-----+


7.2. Интервал TCP Keepalive

Эта опция задает для клиента интервал (в секундах) передачи сообщений TCP keepalive в соединениях TCP, указываемый 32-битовым целым числом без знака. Нулевое значение указывает, что клиенту не следует передавать сообщений keepalive, пока это явно не запрошено приложением.

Поле code для этой опции имеет значение 38, а ее размер составляет 4 октета.

 Code   Len           Time
+-----+-----+-----+-----+-----+-----+
|  38 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


7.3. Опция TCP Keepalive Garbage

Эта опция показывает, следует ли клиенту передавать сообщения TCP keepalive с «мусорным» (garbage) октетом для совместимости со старыми версиями. Значение 0 указывает, что этот октет не следует передавать, 1 указывает передачу октета garbage.

Поле code для этой опции имеет значение 39, а ее размер составляет 1 октет.

 Code   Len  Value
+-----+-----+-----+
|  39 |  1  | 0/1 |
+-----+-----+-----+


8. Параметры приложений и служб

В этом разделе описаны опции, служащие для настройки различных приложений и служб.

8.1. Домен сетевой информации

Эта опция задает для клиента имя домена NIS9 [17], указываемое строкой символов NVT ASCII.

 Code   Len      NIS Domain Name
+-----+-----+-----+-----+-----+-----+---
|  40 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+-----+-----+-----+-----+-----+-----+---


Поле code для этой опции имеет значение 40, а минимальный размер составляет 1 октет.

8.2. Серверы NIS

Эта опция задает список адресов IP доступных для клиента серверов NIS. Серверы следует указывать в порядке предпочтения.

Поле code для этой опции имеет значение 41. Минимальный размер опции составляет 4 октета, а реальный размер всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  41 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.3. Серверы NTP

Эта опция задает список адресов IP доступных для клиента серверов NTP10 [18]. Серверы следует указывать в порядке предпочтения.

Поле code для этой опции имеет значение 42. Минимальный размер опции составляет 4 октета, а реальный размер всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
|  42 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.4. Фирменная информация производителя

Эта опция используется клиентами и серверами для обмена фирменной информацией производителя. Эта информация представляет собой «непрозрачный» объект из n октетов, предположительно интерпретируемый клиентами и серверами по коду, заданному производителем. Назначение этой информации определяется производителем, который указывается опцией vendor class identifier. Серверы, не способные обрабатывать фирменные данные, отправленные клиентом, должны игнорировать их (но могут информировать об этом). Клиенту, не получившему фирменную информацию, следует предпринять попытку работы без нее, хотя это может приводить к деградации клиента (он должен сообщить об этом).

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

Поле Encapsulated vendor-specific options следует представлять в форме последовательности полей «код-размер-значение», идентичной полю опций DHCP, с учетом приведенных ниже ограничений.

  1. Не следует включать поле magic cookie в инкапсулированные фирменные расширения.

  2. Коды (за исключением 0 и 255) могут быть переопределены производителем внутри поля инкапсулированных фирменных расширений, но следует соответствовать синтаксису «тег-размер-значение», определенному в разделе 2.

  3. При наличии кода 255 (END) он означает завершение поля инкапсулированных фирменных расширений, а не всего поля фирменных расширений. Если код 255 не указан, поле фирменной информации завершается в конце поля инкапсулированных фирменных расширений.

Поле code для этой опции имеет значение 43, а минимальный размер составляет 1 октет.

 Code   Len   Vendor-specific information
+-----+-----+-----+-----+---
|  43 |  n  |  i1 |  i2 | ...
+-----+-----+-----+-----+---


При использовании поля инкапсулированных фирменных расширений байты информации 1-n имеют приведенный ниже формат.

 Code   Len   Data item        Code   Len   Data item       Code
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|  T1 |  n  |  d1 |  d2 | ... |  T2 |  n  |  D1 |  D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+


8.5. Сервер имен NetBIOS over TCP/IP

Опция NetBIOS name server (NBNS) задает список серверов имен NBNS RFC 1001/1002 [19] [20] в порядке предпочтения.

Поле code для этой опции имеет значение 44. Минимальный размер опции составляет 4 октета, а реальный размер всегда должен быть кратным 4 октетам.

 Code   Len           Address 1              Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
|  44 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----


8.6. Сервер NBDD

 Code   Len           Address 1              Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
|  45 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----


Опция NBDD11 server задает список серверов NBDD RFC 1001/1002 в порядке их предпочтения. Поле code для этой опции имеет значение 45. Минимальный размер опции составляет 4 октета, а реальный размер всегда должен быть кратным 4 октетам.

8.7. Тип узла NetBIOS over TCP/IP

Опция NetBIOS node type позволяет настраивать конфигурацию клиентов NetBIOS over TCP/IP в соответствии с RFC 1001/1002. Значение задается в одном октете, который указывает тип клиента, как показано в таблице.

Значение

Тип узла

0x1

B-node

0x2

P-node

0x3

M-node

0x4

H-node

В таблице префикс 0x указывает шестнадцатеричные значения.

Поле code для этой опции имеет значение 46, а размер опции всегда составляет 1 октет.

 Code   Len  Node Type
+-----+-----+-----------+
|  46 |  1  | see above |
+-----+-----+-----------+


8.8. Область действия NetBIOS over TCP/IP

Опция NetBIOS scope задает для клиента параметр NetBIOS over TCP/IP scope в соответствии с RFC 1001/1002. Ограничения для набора символов приведены в докуменатах [19], [20] и [8].

Поле code для этой опции имеет значение 47, а минимальный размер составляет 1 октет.

 Code   Len       NetBIOS Scope
+-----+-----+-----+-----+-----+-----+----
|  47 |  n  |  s1 |  s2 |  s3 |  s4 | ...
+-----+-----+-----+-----+-----+-----+----


8.9. Сервер шрифтов X Window System

Эта опция указывает список серверов шрифтов X Window System [21] Font, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для этой опции имеет значение 48. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 48  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.10. Менеджер системы X Window

Эта опция задает список адресов IP, указывающих доступные клиенту менеджеры X Window System Display. Адреса следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 49  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции this имеет значение 49. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

8.11. Домен NIS+

Эта опция задает для клиента имя домена NIS+12 [17], укзываемое строкой символов NVT ASCII.

Поле code для этой опции имеет значение 64, а минимальный размер составляет 1 октет.

 Code   Len      NIS Client Domain Name
+-----+-----+-----+-----+-----+-----+---
|  64 |  n  |  n1 |  n2 |  n3 |  n4 | ...
+-----+-----+-----+-----+-----+-----+---


8.12. Сервер NIS+

Эта опция задает список адресов IP, указывающих доступные клиенту серверы NIS+. Серверы следует указывать в порядке предпочтения.

Поле code для этой опции имеет значение 65. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 65  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.13. Домашний агент Mobile IP

Эта опция задает список адресов IP, указывающих доступные клиенту домашние агенты mobile IP. Агенты следует указывать в порядке предпочтения.

 Code Len    Home Agent Addresses (0 или более)
+-----+-----+-----+-----+-----+-----+--
| 68  |  n  | a1  | a2  | a3  | a4  | ...
+-----+-----+-----+-----+-----+-----+--


Поле code для этой опции имеет значение 68. Минимальный размер опции равен 0 (нет доступных домашних агентов), а реальный размер опции всегда должен быть кратным 4 октетам. Предполагается, что обычно размер будет составлять 4 октета (один домашний агент).

8.14. Сервер SMTP

Опция SMTP server задает список серверов SMTP13, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции SMTP server имеет значение 69. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 69  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.15. Сервер POP3

Опция POP3 server задает список серверов POP314, доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 70  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции POP3 server имеет значение 70. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

8.16. Сервер NNTP

Опция NNTP server задает список серверов NNTP15 available to the client. Servers SHOULD be listed in order of preference.

Поле code для опции NNTP server имеет значение 71. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 71  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.17. Используемый по умолчанию сервер WWW

Опция WWW server задает список серверов WWW16, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции WWW server имеет значение 72. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 72  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.18. Используемый по умолчанию сервер Finger

Опция Finger server задает список серверов Finger, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции Finger server имеет значение 73. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 73  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


8.19. Используемый по умолчанию сервер IRC

Опция IRC server задает список серверов IRC17, доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 74  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции IRC server имеет значение 74. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

8.20. Сервер StreetTalk

Опция StreetTalk server задает список серверов StreetTalk, доступных для клиента. Серверы следует указывать в порядке предпочтения.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 75  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


Поле code для опции StreetTalk server имеет значение 75. Минимальный размер составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

8.21. Сервер STDA

Эта опция задает список серверов STDA18, доступных для клиента. Серверы следует указывать в порядке предпочтения.

Поле code для опции StreetTalk Directory Assistance server имеет значение 76. Минимальный размер опции составляет 4 октета, а реальный размер опции всегда должен быть кратным 4 октетам.

 Code   Len         Address 1               Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 76  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+--


9. Расширения DHCP

В этом разделе описаны опции, относящиеся только к протоколу DHCP.

9.1. Запрашиваемый адрес IP

Эта опция используется клиентом в сообщении DHCPDISCOVER для запроса определенного адреса IP.

Поле code для этой опции имеет значение 50, а ее размер составляет 4 октета.

 Code   Len          Address
+-----+-----+-----+-----+-----+-----+
|  50 |  4  |  a1 |  a2 |  a3 |  a4 |
+-----+-----+-----+-----+-----+-----+


9.2. Время аренды адреса IP

Эта опция используется в запросе клиента (DHCPDISCOVER или DHCPREQUEST) для предложения времени аренды адреса IP. В отклике DHCPOFFER сервер DHCP использует эту опцию для указания предлагаемого им срока аренды.

Время указывается в секундах 32-битовым целым числом без знака.

Поле code для этой опции имеет значение 51, а ее размер составляет 4 октета.

 Code   Len         Lease Time
+-----+-----+-----+-----+-----+-----+
|  51 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


9.3. «Перегрузка» опций

Эта опция используется для индикации использования полей sname и file для записи опций DHCP. Сервер DHCP добавляет эту опцию, если размер возвращаемых параметров превосходит доступое для опций простанство.

При наличии этой опции клиент обрабатывает указанные дополнительные поля опций после рассмотрения стандартных полей.

Поле code для этой опции имеет значение 52, а ее размер составляет 1 октет. Разрешенные значения даны в таблице.

Значение

Описание

1

Поле file служит для записи опций

2

Поле file служит для записи опций

3

Оба поля служат для записи опций

 Code   Len  Value
+-----+-----+-----+
|  52 |  1  |1/2/3|
+-----+-----+-----+


9.4 Имя сервера TFTP

Эта опция используется для указания сервера TFTP, когда поле sname в заголовке DHCP служит для записи опций.

Поле code для этой опции имеет значение 66, а минимальный размер составляет 1 октет.

 Code  Len   TFTP server
+-----+-----+-----+-----+-----+---
| 66  |  n  |  c1 |  c2 |  c3 | ...
+-----+-----+-----+-----+-----+---


9.5 Имя загрузочного файла

Эта опция используется для указания загрузочного файла, когда поле file в заголовке DHCP служит для записи опций.

 Code  Len   Bootfile name
+-----+-----+-----+-----+-----+---
| 67  |  n  |  c1 |  c2 |  c3 | ...
+-----+-----+-----+-----+-----+---


Поле code для этой опции имеет значение 67, а минимальный размер составляет 1 октет.

9.6. Тип сообщения DHCP

Эта опция служит для указания типа сообщения DHCP. Поле code имеет значение 53, а размер опции составляет 1 октет. Разрешенные коды типов сообщений приведены в таблице.

Значение

Тип сообщения

1

DHCPDISCOVER

2

DHCPOFFER

3

DHCPREQUEST

4

DHCPDECLINE

5

DHCPACK

6

DHCPNAK

7

DHCPRELEASE

8

DHCPINFORM

 Code   Len  Type
+-----+-----+-----+
|  53 |  1  | 1-9 |
+-----+-----+-----+


9.7. Идентификатор сервера

Эта опция используется в сообщениях DHCPOFFER и DHCPREQUEST, а также может включаться в сообщения DHCPACK и DHCPNAK. Сервер DHCP включает эту опцию в DHCPOFFER для того. Чтобы обеспечить клиенту возможность различать предложения аренды. Клиенты DHCP используют содержимое поля server identifier в качестве адреса получателя всех сообщений DHCP, направляемых по индивидуальному адресу сервера DHCP. Клиенты DHCP также указывают, какое из предложений аренды было принято, включая эту опцию в сообщение DHCPREQUEST.

Идентификатором является IP-адрес выбранного сервера.

Поле code для этой опции имеет значение 54, а ее размер составляет 4 октета.

 Code   Len            Address
+-----+-----+-----+-----+-----+-----+
|  54 |  4  |  a1 |  a2 |  a3 |  a4 |
+-----+-----+-----+-----+-----+-----+


9.8. Список запрашиваемых параметров

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

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

Поле code для этой опции имеет значение 55, а минимальный размер составляет 1 октет.

 Code   Len   Option Codes
+-----+-----+-----+-----+---
|  55 |  n  |  c1 |  c2 | ...
+-----+-----+-----+-----+---


9.9. Сообщение

Эта опция используется сервером DHCP для предоставления клиенту информации об ошибке в сообщении DHCPNAK при возникновении отказа. Клиент может использовать эту опцию в сообщении DHCPDECLINE для указания причины отказа от предложенных параметров. Сообщение включает n текста NVT ASCII, который клиент может вывести на доступное устройство отображения.

Поле code для этой опции имеет значение 56, а минимальный размер составляет 1 октет.

 Code   Len     Text
+-----+-----+-----+-----+---
|  56 |  n  |  c1 |  c2 | ...
+-----+-----+-----+-----+---


9.10. Максимальный размер сообщения DHCP

Эта опция задает максимальный размер сообщений DHCP, которые будут восприниматься. Размер задается 16-битовым целым числом без знака. Клиент может использовать опцию максимального сообщений DHCP в своих сообщениях DHCPDISCOVER и DHCPREQUEST, но не следует указывать ее в сообщениях DHCPDECLINE.

 Code   Len     Length
+-----+-----+-----+-----+
|  57 |  2  |  l1 |  l2 |
+-----+-----+-----+-----+


Поле code для этой опции имеет значение 57, а ее размер составляет 2. Минимальное пригодное значение поля составляет 576 октета.

9.11. Значение времени Renewal (T1)

Эта опция задает временной интервал с момента назначения адреса клиенту, по истечении которого клиент переходит в состояние RENEWING.

Время задается в секундах 32-битовым целым числом без знака.

Поле code для этой опции имеет значение 58, а ее размер составляет 4 октета.

 Code   Len         T1 Interval
+-----+-----+-----+-----+-----+-----+
|  58 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


9.12. Значение времени Rebinding (T2)

Эта опция задает временной интервал с момента назначения адреса клиенту, по истечении которого клиент переходит в состояние REBINDING.

Время задается в секундах 32-битовым целым числом без знака.

Поле code для этой опции имеет значение 59, а ее размер составляет 4 октета.

 Code   Len         T2 Interval
+-----+-----+-----+-----+-----+-----+
|  59 |  4  |  t1 |  t2 |  t3 |  t4 |
+-----+-----+-----+-----+-----+-----+


9.13. Идентификатор класса производителя

Эта опция используется клиентами DHCP для указания типа производителя и конфигурации клиента DHCP. Информация задается строкой из n октетов, интерпретируемых сервером. Производители могут определять свои идентификаторы классов для передачи определенной конфигурации или других идентификационных данных клиента. Например, идентификатор может представлять аппаратную конфигурацию клиента. Серверы, не способные интерпретировать относящуюся к определенному классу информацию клиента, должны игнорировать ее (хотя могут сообщать об этом). При ответе серверам следует использовать только опцию 43 для возврата клиенту фирменной информации производителя .

Поле code для этой опции имеет значение 60, а минимальный размер составляет 1 октет.

Code   Len   Vendor class Identifier
+-----+-----+-----+-----+---
|  60 |  n  |  i1 |  i2 | ...
+-----+-----+-----+-----+---


9.14. Идентификатор клиента

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

Серверам DHCP следует трактовать идентификаторы, как непрозрачные (не анализируемые) значения.

Идентификатор клиента может содержать пары «тип-значение» вроде полей htype/chaddr, определенных в [3]. Например, он может содержать тип оборудования и аппаратный адрес. В этом случае в качестве типа следует указывать один из аппаратных типов ARP, определенных в STD2 [22]. Тип оборудования 0 следует указывать в тех случаях, когда поле значения содержит идентификатор, не являющийся аппаратным адресом (например, полное доменное имя).

Для корректной идентификации клиентов client-identifier каждого клиента должен быть уникален в рамках подсети, к которой клиент подключен. За выбор уникальных идентификаторов для каждого клиента отвечают производители и системные администраторы.19

Поле code для этой опции имеет значение 61, а минимальный размер составляет 2 октета20.

Code   Len   Type  Client-Identifier
+-----+-----+-----+-----+-----+---
|  61 |  n  |  t1 |  i1 |  i2 | ...
+-----+-----+-----+-----+-----+---


10. Определение новых расширений

Авторам новых опций DHCP нужно следовать приведенным ниже рекомендациям для включения опции в процесс стандартизации DHCP (Internet Standard).

  1. Автор разрабатывает новую опцию.

  2. Для новой опции автор запрашивает номер, обратившись в IANA по адресу

    Internet Assigned Numbers Authority (IANA)
    USC/Information Sciences Institute
    4676 Admiralty Way
    Marina del Rey, California 90292-6695

    или по электронной почте iana@iana.org

  3. Автор описывает новую опцию с полученным для нее номером в документе Internet Draft.

  4. Автор представляет Internet Draft в обычный процесс стандартизации IETF в соответствии с Internet Official Protocol Standards (STD 1). Новая опция может быть принята в качестве Internet Standard.

  5. Новая опция проходит процесс стандартизации IETF и будет рассмотрена рабочей группой Dynamic Host Configuration (если группа продолжит работу) или представлена как Internet Draft не от рабочей группы IETF.

  6. Если новая опция не будет принята как Internet Standard, выделенный ей номер возвращается IANA.

    Такая процедура определения новых расширений гарантирует:

    • согласованное выделение номеров опций одной организацией;

    • рассмотрение новых опций с точки зрения корректности и применимости;

    • полноту документирования и публикации для новых опций.

11. Благодарности

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

Спасибо J. Allard, Mike Carney, Dave Lapp, Fred Lien и John Mendonca за организацию тестирования интероперабельности DHCP.

Разработка этого документа частично поддерживалась в рамках гранта Corporation for National Research Initiatives (CNRI), Bucknell University и Sun Microsystems.

12. Литература

[1] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, Bucknell University, March 1997.

[2] Reynolds, J., «BOOTP Vendor Information Extensions», RFC 1497, USC/Information Sciences Institute, August 1993.

[3] Croft, W., and J. Gilmore, «Bootstrap Protocol», RFC 951, Stanford University and Sun Microsystems, September 1985.

[4] Braden, R., Editor, «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

[5] Mogul, J., and J. Postel, «Internet Standard Subnetting Procedure», STD 5, RFC 950, USC/Information Sciences Institute, August 1985.

[6] Postel, J., and K. Harrenstien, «Time Protocol», STD 26, RFC 868, USC/Information Sciences Institute, SRI, May 1983.

[7] Postel, J., «Name Server», IEN 116, USC/Information Sciences Institute, August 1979.

[8] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[9] Postel, J., «Quote of the Day Protocol», STD 23, RFC 865, USC/Information Sciences Institute, May 1983.

[10] McLaughlin, L., «Line Printer Daemon Protocol», RFC 1179, The Wollongong Group, August 1990.

[11] Accetta, M., «Resource Location Protocol», RFC 887, CMU, December 1983.

[12] Mogul, J. and S. Deering, «Path MTU Discovery», RFC 1191, DECWRL, Stanford University, November 1990.

[13] Deering, S., «ICMP Router Discovery Messages», RFC 1256, Xerox PARC, September 1991.

[14] Leffler, S. and M. Karels, «Trailer Encapsulations», RFC 893, U. C. Berkeley, April 1984.

[15] Hornig, C., «Standard for the Transmission of IP Datagrams over Ethernet Networks», RFC 894, Symbolics, April 1984.

[16] Postel, J. and J. Reynolds, «Standard for the Transmission of IP Datagrams Over IEEE 802 Networks», RFC 1042, USC/Information Sciences Institute, February 1988.

[17] Sun Microsystems, «System and Network Administration», March 1990.

[18] Mills, D., «Internet Time Synchronization: The Network Time Protocol», RFC 1305, UDEL, March 1992.

[19] NetBIOS Working Group, «Protocol Standard for a NetBIOS Service on a TCP/UDP transport: Concepts and Methods», STD 19, RFC 1001, March 1987.

[20] NetBIOS Working Group, «Protocol Standard for a NetBIOS Service on a TCP/UDP transport: Detailed Specifications», STD 19, RFC 1002, March 1987.

[21] Scheifler, R., «FYI On the X Window System», FYI 6, RFC 1198, MIT Laboratory for Computer Science, January 1991.

[22] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 170021, USC/Information Sciences Institute, July 1992.

13. Вопросы безопасности

Вопросы безопасности не рассматриваются в этом документе.

14. Адреса авторов

Steve Alexander

Silicon Graphics, Inc.

2011 N. Shoreline Boulevard

Mailstop 510

Mountain View, CA 94043-1389

Phone: (415) 933-6172

EMail: sca@engr.sgi.com

Ralph Droms

Bucknell University

Lewisburg, PA 17837

Phone: (717) 524-1145

EMail: droms@bucknell.edu


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Dynamic Host Configuration Protocol.

2Ссылка утратила актуальность. Действующий список опций можно получить здесь. Прим. перев.

3Bootstrap Protocol — протокол загрузки.

4Использование этой опции отменено RFC 4833.

5Coordinated Universal Time.

6Domain Name System — система доменных имен.

7Time-to-live — время жизни.

8В RFC 3442 использование этой опции было отменено. Прим. перев.

9Network Information Service — сетевая информационная служба.

10Network Time Protocol — протокол сетевого времени.

11NetBIOS datagram distribution — распространение дейтаграмм NetBIOS.

12Network Information Service+ — сервер сетевой информации.

13Simple Mail Transport Protocol — простой протокол доставки почты.

14Post Office Protocol — протокол «постового офиса».

15Network News Transport Protocol — протокол доставки сетевых новостей.

16World Wide Web.

17Internet Relay Chat.

18StreetTalk Directory Assistance.

19В соответствии с RFC 4361 этот и предшествующий абзац заменены текстом «Идентификатор клиента состоит из поля типа, которое обычно имеет значение 255, за которым следует 4-байтовое поле IA_ID, а затем значение DUID для клиента в соответствии с определением раздела 9 в RFC 3315». Прим. перев.

20В соответствии с RFC 4361 текст « , а минимальный размер составляет 2 октета» удален. Прим. перев.

21В RFC 3232 этот документ был заменен базой данных, доступной по ссылке. Прим. перев.




RFC 2131 Dynamic Host Configuration Protocol

Network Working Group                                           R. Droms
Request for Comments: 2131                           Bucknell University
Obsoletes: 1541                                               March 1997
Category: Standards Track

Протокол динамической настройки хоста (DHCP)

Dynamic Host Configuration Protocol

PDF

Статус документа

Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашение к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Тезисы

Протокол динамической настройки конфигурации хоста (DHCP1) обеспечивает основу для передачи хостам конфигурационных параметров через сеть TCP/IP. DHCP основан на протоколе загрузки BOOTP2 [7] и добавляет автоматическое выделение сетевых адресов, а также дополнительные конфигурационные опции [19]. DHCP может работать с трансляторами BOOTP [7, 21], а участники DHCP могут взаимодействовать с участниками BOOTP [9].

Оглавление

Исключено в версии HTML.

Список рисунков

Исключен в версии HTML.

Список таблиц

Исключен в версии HTML.

1. Введение

Протокол DHCP обеспечивает настройку конфигурационных параметров хостов Internet. DHCP включает две компоненты — протокол доставки конфигурационных параметров конкретного хоста с сервера DHCP и механизм выделения сетевых адресов для хостов.

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

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

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

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

Формат сообщений DHCP базируется на формате сообщений BOOTP для поддержки функций транслятора BOOTP, описанных в спецификации BOOTP [7, 21] и обеспечения взаимодействия имеющихся клиентов BOOTP с серверами DHCP. Использование агентов трансляции BOOTP избавляет от необходимости организации сервера DHCP в каждом физическом сегменте сети.

1.1 Отличия от RFC 1541

Этот документ обновляет спецификацию протокола DHCP, заданную в RFC1541. Добавлен новый тип сообщений DHCPINFORM (см. параграфы 3.4, 4.3 и 4.4). Механизм классов для идентификации клиентов DHCP на сервере DHCP был расширен путем добавления классов vendor, определенных в параграфах 4.2 и 4.3. Было снято ограничение для минимального срока аренды. Кроме того, внесены многочисленные редакторские правки, разъясняющие текст с учетом опыта тестирования интероперабельности DHCP.

1.2 Смежные работы

Имеется несколько протоколов Internet и связанных с ними механизмов, которые решают часть задачи динамической настройки конфигурации хостов. Протокол RARP3 [10] (за счет расширения DRARP4 [5]) явно решает задачу автоматического обнаружения сетевых адресов и включает механизм автоматического назначения адресов IP. Протокол TFTP5 [20] обеспечивает транспортировку загрузочного образа с сервера загрузки. Протокол ICMP6 [16] обеспечивает информирование хостов о дополнительных маршрутах с помощью сообщений ICMP redirect. ICMP также обеспечивает информацию о текущей маске подсети с помощью сообщений ICMP mask request и другую информацию, доступную с помощью (отмененных) сообщений ICMP information request. Хосты могут находить маршрутизаторы с помощью механизма ICMP router discovery [8].

BOOTP является транспортным механизмом для набора конфигурационной информации. Протокол BOOTP является расширяемым и официальные расширения [17] могут быть определены для некоторых конфигурационных параметров. Morgan предложил расширение BOOTP для динамического назначения адресов IP [15]. Протокол NIP7, используемый в проекте Athena института MIT, является распределенным механизмом динамического назначения адресов IP [19]. Протокол RLP8 [1] обеспечивает определение места расположения служб верхних уровней. Бездисковые станции Sun Microsystems используют процедуру загрузки на основе RARP, TFTP и механизма RPC, названного bootparams, для доставки конфигурационной информации и кода операционной системы на бездисковые рабочие станции (Sun Microsystems, Sun Workstation и SunOS — торговые знаки Sun Microsystems, Inc.). Некоторые сети Sun используют также DRARP и механизм автоматической инсталяции для автоматизации настройки конфигурации хостов в существующей сети.

В других смежных работах алгоритм определения MTU9 позволяет найти MTU для произвольного пути через сеть [14]. Пртокол ARP10 был предложен в качестве транспорта для определения местоположения и выбора ресурсов [6]. В документах Host Requirements [3, 4] указаны конкретные требования для реконфигурации хостов и предложен сценарий начальной настройки бездисковых хостов.

1.3 Постановка задачи

Протокол DHCP разработан для предоставления клиентам DHCP конфигурационных параметров, определенных в документах Host Requirements RFC. После получения параметров по протоколу DHCP клиент должен получить возможность обмена пакетами с любым хостом в сети Internet. Параметры стека TCP/IP, предоставляемые протоколом DHCP, перечислены в Приложении A.

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

DHCP позволяет, но не требует настройку параметров конфигурации клиентов, не связанных напрямую с протоколом IP. Протокол DHCP также не решает вопросов регистрации адресов недавно настроенных клиентов в системе доменных имен DNS11 [12, 13].

Протокол DHCP не предназначен для настройки конфигурации маршрутизаторов.

1.4 Уровни требований

В этом документе слова, используемые для определения значимости конкретных требований выделены шрифтом. Эти уровни перечислены ниже.

MUST — необходимо

Это слово, а также термин требуется (REQUIRED) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

MUST NOT — недопустимо

Эта фраза означает абсолютный запрет в рамках спецификации.

SHOULD — следует

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

SHOULD NOT — не следует

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

MAY — возможно

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

1.5 Терминология

Ниже приведены определения используемых в документе терминов.

DHCP client – клиент DHCP

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

DHCP server – сервер DHCP

Сервером DHCP является хост Internet, который возвращает параметры конфигурации клиентам DHCP.

BOOTP relay agent – агент-транслятор BOOTP

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

Binding — привязка

Привязкой называется набор параметров конфигурации, включающий как минимум адрес IP, который ассоциируется (привязан) к клиенту DHCP. Привязками управляет сервер DHCP.

1.6 Цели

Ниже перечислены основные цели, заданные при разработке протокола DHCP.

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

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

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

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

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

  • DHCP должен сосуществовать со статически настроенными, не участвующими в работе протокола хостами и существующими реализациями сетевых протоколов.

  • DHCP должен взаимодействовать с агентами трансляции BOOTP, поведение которых соответствует RFC 951 и RFC 1542 [21].

  • DHCP должен обеспечивать обслуживание имеющихся клиентов BOOTP.

Ниже перечислены цели разработки, связанные с передачей параметров сетевого уровня. Протокол DHCP должен:

  • гарантировать, что в каждый момент любой конкретный сетевой адрес будет использоваться лишь одним клиентом DHCP;

  • сохранять конфигурационные параметры клиента DHCP при его перезагрузке; одному и тому же клиенту следует по возможности предоставлять один набор конфигурационных параметров (например, сетевой адрес) при каждом запросе;

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

  • разрешать автоматизированное назначение конфигурационных параметров новых клиентов во избежание их настройки вручную;

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

2. Краткое описание протокола

С точки зрения клиентов DHCP является расширением механизма BOOTP. Такое поведение позволяет имеющимся клиентам BOOTP взаимодействовать с серверами DHCP без каких-либо изменений в программах инициализации клиентов. В RFC 1542 [2] подробно описано взаимодействие клиентов BOOTP и DHCP с серверами [9]. Имеется несколько новых необязательных транзакций, которые оптимизируют взаимодействие между клиентами DHCP и серверами, эти транзакции описаны в разделах 3 и 4.

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

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

DHCP несколько меняет терминологию в части прояснения смысла одного из полей. Поле vendor extensions из BOOTP переименовано в options для протокола DHCP. Помеченные элементы данных, использовавшиеся в поле BOOTP vendor extensions, которые назывались «фирменными расширениями», стали просто «опциями».

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
+---------------+---------------+---------------+---------------+
|                            xid (4)                            |
+-------------------------------+-------------------------------+
|           secs (2)            |           flags (2)           |
+-------------------------------+-------------------------------+
|                          ciaddr  (4)                          |
+---------------------------------------------------------------+
|                          yiaddr  (4)                          |
+---------------------------------------------------------------+
|                          siaddr  (4)                          |
+---------------------------------------------------------------+
|                          giaddr  (4)                          |
+---------------------------------------------------------------+
|                                                               |
|                          chaddr  (16)                         |
|                                                               |
|                                                               |
+---------------------------------------------------------------+
|                                                               |
|                          sname   (64)                         |
+---------------------------------------------------------------+
|                                                               |
|                          file    (128)                        |
+---------------------------------------------------------------+
|                                                               |
|                        options (переменный)                   |
+---------------------------------------------------------------+

Рисунок 1. Формат сообщения DHCP.


DHCP определяет новую опцию client identifier, которая служит для передачи явного идентификатора клиента серверу DHCP. Это избавляет от перегрузки поле chaddr в сообщениях BOOTP, где это поле применялось в качестве аппаратного адреса для передачи откликов BOOTP и идентификатора клиента. Поле client identifier является «непрозрачным» ключом, которые не интерпретируется сервером — это поле может содержать, например, аппаратный адрес, идентичный содержимому поля chaddr, или быть идентификатором другого типа (скажем, именем DNS)12. Значение client identifier, выбранное клиентом DHCP, должно быть уникальным для каждого клиента в подсети, где этот клиент размещается. Если клиент использует client identifier в одном сообщении, он должен использовать такой же идентификатор во всех последующих сообщениях, чтобы все серверы могли корректно распознать этого клиента.

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

Таблица 1. Описание полей сообщения DHCP.

Поле

Размер

Описание

op

1

Опирация (тип сообщения). 1 = BOOTREQUEST, 2 = BOOTREPLY

htype

1

Тип аппаратного адреса (см. раздел ARP в Assigned Numbers RFC13), например, 1 для 10mb ethernet.

hlen

1

Размер аппаратного адреса (например, 6 для 10mb ethernet).

hops

1

Клиент устанавливает 0, поле может использоваться агентами трансляции при загрузке через них.

xid

4

Идентификатор транзакции — случайное число, выбираемое клиентом. Используется клиентом и сервером для сопоставления сообщений и откликов на них.

secs

2

Число секунд с начала процесса получения или обновления адреса, указываемое клиентом.

flags

2

Флаги (см. рисунок 2).

ciaddr

4

IP-адрес клиента; указывается только в том случае, когда клиент находится в состоянии BOUND, RENEW или REBINDING и может отвечать на запросы ARP.

yiaddr

4

«Ваш» (клиента) адрес IP.

siaddr

4

IP-адрес следующего сервера для использования при загрузке. Возвращается сервером в сообщениях DHCPOFFER, DHCPACK.

giaddr

4

IP-адрес агента трансляции, используемый при загрузке через агент.

chaddr

16

Аппаратный адрес клиента.

sname

64

Необязательное имя сервера — строка, завершающаяся null-символом.

file

128

Имя загрузочного файла (строка, завершающаяся null-символом); «базовое» (generic) имя или null в DHCPDISCOVER, полный путь к файлу в DHCPOFFER.

options

переменный

Поле необязательных параметров. Список определенных опций можно найти в дополнительных документах.

Поле options имеет переменный размер. Клиент DHCP должен быть готов к получению сообщений DHCP с размером поля options по меньшей мере 312 октетов. Это требование предполагает, что клиент DHCP должен быть готов принимать сообщения размером до 576 октетов (минимальный размер дейтаграммы IP, который хост IP должен быть готов принимать [3]). Клиенты DHCP могут согласовать использование более крупных сообщений DHCP с помощью опции maximum DHCP message size. Поле опций может быть дополнительно расширено за счет полей file и sname.

Если клиент использует DHCP для начальной настройки (до полной настройки клиентских программ TCP/IP), DHCP требует творческого использования клиентских программ TCP/IP и мягкой интерпретации RFC 1122. Программам TCP/IP следует воспринимать и передавать на уровень IP все пакеты IP, доставленные на аппаратный адрес клиента, до того, как будет настроен протокол IP, поскольку серверы DHCP и агенты трансляции BOOTP могут оказаться не способны доставлять сообщения DHCP клиентам, которые не могут воспринимать дейтаграммы с индивидуальным аппаратным адресом до завершения настройки программ TCP/IP.

                    1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|             MBZ             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B — флаг широковещания;
MBZ — должны иметь нулевое значение
(резерв на будущее)

Рисунок 2. Формат поля flags.


Для работы с некоторыми клиентами, которые не способны воспринимать индивидуальные дейтаграммы IP до настройки программ TCP/IP, как отмечено выше, DHCP использует поле flags [21]. Левый бит этот поля служит флагом широковещания (BROADCAST) — B. Семантика этого флага рассматривается в параграфе 4.1. Остальные биты поля зарезервированы на будущее. Они должны устанавливаться в 0 клиентами и игнорироваться серверами и агентами трансляции. Формат поля flags показан на рисунке 2.

2.1 Репозиторий конфигурационных параметров

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

Например, ключом может быть пара (номер подсети IP, аппаратный адрес14), позволяющая последовательно или одновременно использовать один аппаратный адрес в разных подсетях, а также не заботиться о глобальной уникальности аппаратных адресов. Кроме того, ключом может служить пара (номер подсети IP, имя хоста), позволяющая серверу DHCP интеллектуально задавать параметры клиенту при его перемещении в другую подсеть или смене аппаратного адреса (возможно, в результате замены сетевого интерфейса). Протокол определяет использование в качестве ключа пары (номер подсети IP, аппаратный адрес), если клиент не предоставил свой идентификатор явно с помощью опции client identifier. Клиент может запросить у службы DHCP получение своих конфигурационных параметров. Интерфейс клиента в репозиторий конфигурационных параметров состоит из протокольных сообщений для запроса параметров и откликов сервера, содержащих эти параметры.

2.2 Динамическое выделение сетевых адресов

Второй услугой DHCP является выделение временных или постоянных сетевых (IP) адресов клиентам. Базовый механизм динамического выделения сетевых адресов прост — клиент запрашивает использование адреса на некоторый интервал времени. Механизм выделения (набор серверов DHCP) гарантирует, что в течение запрошенного времени этот адрес не будет предоставляться другим клиентам, а по истечении времени будет предпринята попытка выделить тот же адрес при каждом последующем запросе этого клиента. В этом документе период, на который сетевой адрес предоставляется клиенту, называется «арендой» (lease) [11]. Клиент может расширить свою аренду с помощью последующего запроса. Клиент может передать сообщение для возврата арендованного адреса серверу, когда потребность в этом адресе отпадет. Клиент может запросить постоянное предоставления адреса, запросив бесконечный срок аренды. Даже при назначении «постоянного» адреса сервер может выбрать очень продолжительный, но конечный срок аренды, чтобы можно было обнаружить факт «ухода» клиента.

В некоторых средах требуется переназначать сетевые адреса по причине нехватки доступного адресного пространства. В таких случаях механизм выделения адресов будет снова выделять клиентам освобожденные адреса. Серверам следует использовать доступную в конфигурационном репозитории информацию при выборе адресов для повторного использования. Например, сервер может выбрать адрес, который дольше всего оставался свободным. В качестве проверки согласованности выделяющему адрес серверу следует протестировать адрес до его назначения (например, с помощью запроса ICMP echo), а клиенту следует проверить недавно полученный адрес (например, с помощью ARP).

3. Протокол «клиент-сервер»

DHCP использует формат сообщений BOOTP, определенный в RFC 951 и представленный на рисунке 1 и в таблице 1. Поле op каждого сообщения DHCP от клиента к серверу содержит значение BOOTREQUEST, а BOOTREPLY используется в поле op каждого отклика DHCP от сервера.

Первые 4 октета поля options в сообщении DHCP содержат десятичные значения 99, 130, 83 и 99, соответственно (это значение magic cookie, определенное в RFC 1497 [17]). Остальная часть поля options содержит список параметров с метками, которые называются опциями. Все фирменные расширения (vendor extensions), перечисленные в RFC 1497, являются также опциями DHCP. В RFC 1533 приведен полный набор опций, определенных для использования в DHCP.

До настоящего момента было определено несколько опций. Одна из таких опций — DHCP message type (тип сообщения) — должна включаться в каждое сообщение DHCP и определяет «тип» сообщения. Другие опции могут разрешаться, требоваться или запрещаться в зависимости от типа сообщения DHCP.

В этом документе сообщение DHCP с опцией DHCP message type будут указываться типом сообщения. Например, сообщение с DHCP message type 1 будет называться DHCPDISCOVER.

3.1 Выделение сетевого адреса

Приведенная ниже сводка протокольного обмена между клиентами и серверами относится к сообщениям DHCP, описанным в таблице 2. Временная диаграмма на рисунке 3 показывает последовательность типичного взаимодействия между клиентом и сервером. Если клиент уже знает свой адрес, некоторые этапы могут быть опущены — это сокращенное взаимодействие описано в параграфе 3.2.

  1. Клиент передает в широковещательном режиме сообщение DHCPDISCOVER в свою локальную физическую подсеть. Сообщение DHCPDISCOVER может включать опции, которые предлагают значения для сетевого адреса и срока аренды. Агенты трансляции BOOTP могут передавать это сообщение серверам DHCP в других физических подсетях.

  2. Каждый сервер может ответить сообщением DHCPOFFER, которое включает доступный сетевой адрес в поле yiaddr (и другие конфигурационные параметры в опциях DHCP). Сервер не обязан резервировать предложенный сетевой адрес, хотя протокол будет работать более эффективно, если сервер не будет предлагать тот же адрес другим клиентам. При выделении нового адреса серверам следует проверить предлагаемый адрес на предмет его занятости (например, сервер может отправить по этому адресу сообщение ICMP Echo Request). Серверы следует реализовать так, чтобы сетевые администраторы могли отключать проверку занятости недавно выделенных адресов. Сервер передает сообщение DHCPOFFER клиенту, используя при необходимости агент трансляции BOOTP.

Таблица 2. Сообщения DHCP.

Сообщение

Применение

DHCPDISCOVER

Клиент передает широковещательное сообщение для поиска доступных серверов.

DHCPOFFER

Сервер отвечает клиенту на сообщение DHCPDISCOVER, предлагая параметры конфигурации.

DHCPREQUEST

Клиент передает сообщение серверы для (a) запроса предложенных параметров и неявного отказа от всех прочих предложений, (b) подтверждения корректности ранее выделенного адреса (например, после перезагрузки) или (c) расширения срока аренды сетевого адреса.

DHCPACK

Сервер передает клиенту параметры конфигурации, включая назначенный сетевой адрес.

DHCPNAK

Сервер сообщает клиенту о непригодности указанного тем сетевого адреса (например, при переносе клиента в другую подсеть) или окончании аренды для этого клиента.

DHCPDECLINE

Клиент сообщает серверу о том, что сетевой адрес уже занят.

DHCPRELEASE

Клиент сообщает серверу об освобождении сетевого адреса и отказе от аренды.

DHCPINFORM

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

  1.   Сервер          Клиент          Сервер
    (не выбран)                      (выбран)
         v               v               v
         |               |               |
         |     Начало инициализации      |
         |               |               |
         | _____________/|\____________  |
         |/DHCPDISCOVER | DHCPDISCOVER  \|
         |               |               |
    Определение          |          Определение
    конфигурации         |          конфигурации
         |               |               |
         |\             |  ____________/ |
         | \________    | /DHCPOFFER     |
         | DHCPOFFER\   |/               |
         |           \  |                |
         |         Сбор откликов         |
         |             \|                |
         |       Выбор конфигурации      |
         |               |               |
         | _____________/|\____________  |
         |/ DHCPREQUEST  |  DHCPREQUEST\ |
         |               |               |
         |               |     Подача конфигурации
         |               |               |
         |               | _____________/|
         |               |/ DHCPACK      |
         |               |               |
         |    Инициализация завершена    |
         |               |               |
         .               .               .
         .               .               .
         |               |               |
         |    Аккуратное выключение      |
         |               |               |
         |               |\ ____________ |
         |               | DHCPRELEASE  \|
         |               |               |
         |               |      Завершение аренды
         |               |               |
         v               v               v

    Рисунок 3. Обмен сообщениями между клиентом и сервером при выделении сетевого адреса.


    Клиент получает одно или несколько сообщений DHCPOFFER от серверов и может принять решение об ожидании дополнительных откликов. Далее клиент выбирает один из серверов на основе параметров конфигурации, предложенных в сообщениях DHCPOFFER. Клиент передает в широковещательном режиме сообщение DHCPREQUEST, которое должно включать опцию server identifier для указания выбранного сервера и может включать другие опции, задающие желаемые параметры конфигурации. Опция requested IP address должна указывать значение yiaddr из сообщения DHCPOFFER от сервера. Сообщение DHCPREQUEST передается в широковещательном режиме и пересылается агентами трансляции DHCP/BOOTP. Чтобы трансляторы BOOTP пересылали сообщение DHCPREQUEST тем же серверам DHCP, которые получили исходное сообщение DHCPDISCOVER, в заголовке DHCPREQUEST должно использоваться то же значение поля secs и тот же широковещательные адрес IP, которые были заданы в исходном сообщении DHCPDISCOVER. Если клиент не получает сообщений DHCPOFFER, он повторяет передачу DHCPDISCOVER по тайм-ауту.

  2. Серверы получают широковещательное сообщение DHCPREQUEST от клиента. Те серверы, которые не указаны в сообщении DHCPREQUEST, используют его в качестве уведомления об отказе от сделанного ими предложения. Указанный в DHCPREQUEST сервер фиксирует привязку для клиента в своем постоянном хранилище и отвечает сообщением DHCPACK, содержащим конфигурационные параметры для запрашивающего клиента. Комбинация client identifier или chaddr15 с назначенным сетевым адресом создает уникальный идентификатор клиентской аренды, который используется клиентом и сервером для указания аренды во всех последующих сообщениях DHCP. Конфигурационные параметры в сообщении DHCPACK не должны противоречить параметрам из сообщения DHCPOFFER, на которое клиент ответил. Серверу не следует проверять предложенный сетевой адрес на этом этапе. В поле yiaddr сообщения DHCPACK указывается выбранный сетевой адрес.

    Если выбранный сервер не может выполнить запрос DHCPREQUEST (например, в результате того, что сетевой адрес уже был назначен), серверу следует ответить сообщением DHCPNAK.

    Сервер может помечать адреса, предложенные клиентам в сообщениях DHCPOFFER, как недоступные. Серверу следует снова помечать предложенный клиенту в сообщении DHCPOFFER адрес как доступный при отсутствии от этого клиента сообщения DHCPREQUEST.

  3. Клиент получает сообщение DHCPACK с конфигурационными параметрами. Ему следует окончательно проверить параметры (например, ARP для выделенного сетевого адреса) и зафиксировать продолжительность аренды, указанную в сообщении DHCPACK. С этого момента клиент настроен. Если будет обнаружено, что адрес уже занят (например, с помощью ARP), клиент должен передать серверу сообщение DHCPDECLINE и повторить процесс настройки. Клиенту следует выждать не менее 10 секунд перед началом нового процесса настройки для предотвращения избыточного трафика в случае петли.

    При получении сообщения DHCPNAK клиент начинает процедуру настройки заново.

    Клиент повторяет передачу DHCPREQUEST по тайм-ауту, если не было получено ни DHCPACK, ни DHCPNAK. Повтор выполняется в соответствии с алгоритмом, описанным в параграфе 4.1. Клиенту следует повторить передачу DHCPREQUEST достаточное число раз для обеспечения достаточной вероятности контакта с сервером, не заставляя клиента (и его пользователя) ждать слишком долго. Например, клиент выполняющий процедуру повтора в соответствии с параграфом 4.1, может передать сообщение DHCPREQUEST четыре раза с общей задержкой 60 секунд, прежде чем начать процедуру инициализации заново. Если клиент не получил ни DHCPACK, ни DHCPNAK в процессе повтора передачи, он возвращается в состояние INIT и начинает процесс инициализации заново. Клиенту следует уведомить пользователя об отказе и перезапуске процесса.

  4. Клиент может отказаться от аренды сетевого адреса, передав серверу сообщение DHCPRELEASE. Клиент указывает освобождаемую аренду с помощью client identifier или chaddr1 и сетевого адреса в сообщении DHCPRELEASE. Если клиент использовал client identifier при получении аренды, этот же идентификатор должен указываться в сообщении DHCPRELEASE.

3.2 Повторное использование адресов

  Сервер          Клиент          Сервер
     v                v               v
     |                |               |
     |     Начало инициализации       |
     |                |               |
     |               /|\              |
     |   ________ __/ | \__________   |
     | /DHCPREQU EST  |  DHCPREQUEST\ |
     |/               |              \|
     |                |               |
Нахождение            |          Нахождение
конфигурации          |          конфигурации
     |                |               |
     |\               |              /|
     | \              |  ___________/ |
     |  \             | /  DHCPACK    |
     |   \ _______    |/              |
     |     DHCPACK\   |               |
     |    Инициализация завершена     |
     |               \|               |
     |                |               |
     |           (Следующие           |
     |             DHCPACK            |
     |          игнорируются)         |
     |                |               |
     |                |               |
     v                v               v

Рисунок 4. Обмен сообщениями между клиентом и сервером при запросе прежнего сетевого адреса.


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

  1. Клиент передает широковещательное сообщение DHCPREQUEST в свою локальную подсеть. Сообщение включает сетевой адрес клиента в опции requested IP address. Поскольку клиент не получил адрес, ему недопустимо заполнять поле ciaddr. Агенты трансляции BOOTP передают сообщение серверам DHCP из других подсетей. Если клиент использовал для получения адреса client identifier, он должен указать это же значение в сообщении DHCPREQUEST.

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

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

    Если в сообщении DHCPREQUEST задано giaddr = 0x0, клиент относится к одной подсети с сервером. Сервер должен передать широковещательное сообщение DHCPNAK по адресу 0xffffffff, поскольку у клиента может не быть корректного сетевого адреса или маски сети и клиент не может ответить на запросы ARP. В противном случае сервер должен передать сообщение DHCPNAK по IP-адресу транслятора BOOTP, указанному в giaddr. Агент трансляции, в свою очередь, перешлет сообщение напрямую по аппаратному адресу клиента и сообщение DHCPNAK может быть доставлено даже при переносе клиента в другую подсеть.

  3. Клиент получает сообщение DHCPACK с конфигурационными параметрами. Он выполняет окончательную проверку параметров (см. параграф 3.1) и отмечает продолжительность аренды, указанную в DHCPACK. Конкретная аренда неявно указывается client identifier или chaddr16 и сетевым адресом. С этого момента конфигурация клиента настроена.

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

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

    Клиент повторяет передачу DHCPREQUEST по тайм-ауту, если не было получено ни DHCPACK, ни DHCPNAK. Повтор выполняется в соответствии с алгоритмом, описанным в параграфе 4.1. Клиенту следует повторить передачу DHCPREQUEST достаточное число раз для обеспечения достаточной вероятности контакта с сервером, не заставляя клиента (и его пользователя) ждать слишком долго. Например, клиент выполняющий процедуру повтора в соответствии с параграфом 4.1, может передать сообщение DHCPREQUEST четыре раза с общей задержкой 60 секунд, прежде чем начать процедуру инициализации заново. Если клиент не получил ни DHCPACK, ни DHCPNAK в процессе повтора передачи, он может продолжить использование полученного ранее сетевого адреса и параметров конфигурации до завершения срока аренды. Это соответствует переходу в состояние BOUND на диаграмме, показанной на рисунке 5.

  4. Клиент может отказаться от аренды сетевого адреса, передав серверу сообщение DHCPRELEASE. Клиент указывает освобождаемую аренду с помощью client identifier или chaddr1 и сетевого адреса в сообщении DHCPRELEASE.

    Отметим, что в случае, когда клиент сохраняет свой сетевой адрес локально, он обычно не освобождает аренду при аккуратном выключении. Лишь при явной потребности клиента отказаться от своей аренды (например, при перемещении в другую подсеть) этот клиент будет передавать сообщение 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. Применяется два метода снижения числа параметров, передаваемых от сервера к клиенту. В первом методе для большинства параметров используются принятые по умолчанию значения из Host Requirements RFC — если клиент не получает тот или иной параметр, он использует принятое по умолчанию значение. Во втором варианте клиент может указать серверу список нужных параметров в начальном сообщении DHCPDISCOVER или DHCPREQUEST. Если клиент включил список параметров в DHCPDISCOVER, он должен включать тот же список в последующие сообщения DHCPREQUEST.

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

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

Кроме того, клиент может предложить значения для сетевого адреса и срока аренды в сообщении DHCPDISCOVER. Клиент может включить опцию requested IP address, чтобы предложить определенный адрес IP для назначения и опцию IP address lease time для указания предлагаемого срока аренды. В сообщениях DHCPDISCOVER и DHCPREQUEST разрешены и другие опции с «советами» в части значений параметров. Однако эти опции могут игнорироваться сервером и разные серверы могут давать различные отклики. Опция requested IP address указывается только в сообщении DHCPREQUEST, когда клиент проверил полученные ранее параметры. Поле ciaddr клиент заполняет лишь в том случае, когда он имеет корректно настроенный адрес IP в состоянии BOUND, RENEWING или REBINDING.

Если сервер получает сообщение DHCPREQUEST с неприемлемым requested IP address, ему следует передать в ответ сообщение DHCPNAK. Информация об этом может быть также передана системному администратору. Сервер может включить сообщение об ошибке в опцию message.

3.6 Использование DHCP на клиентах с множеством интерфейсов

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

3.7 Когда клиенту следует применять DHCP

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

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

4. Спецификация протокола DHCP

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

4.1 Создание и передача сообщений DHCP

Клиенты и серверы DHCP создают сообщения DHCP, заполняя поля в разделах с фиксированным форматом и добавляют помеченные элементы данных в облать опций переменного размера. Область опций включает первые 4 октета magic cookie (см. раздел 3), за которыми следуют опции. Последней всегда должна указываться опция end.

DHCP использует транспортный протокол UDP. Сообщения DHCP от клиента к серверу передаются в порт DHCP server (67), а сообщения DHCP от сервера к клиенту — в порт DHCP client (68). Сервер с множеством сетевых адресов (например, многодомный хост) может использовать любой из своих адресов для исходящих сообщений DHCP.

Поле server identifier используется для идентификации сервера DHCP в сообщении, а также в качестве адреса получателя сообщений от клиента. Сервер с множеством сетевых адресов должен быть готов воспринимать любой из своих адресов в качестве идентификатора сервера в сообщении DHCP. С учетом возможности неполной связности сети сервер должен выбирать в качестве server identifier тот адрес, который с точки зрения сервера будет доступен для клиента. Например, если сервер и клиент DHCP подключены к одной подсети (т. е. в поле giaddr сообщения от клиента установлен 0), серверу следует выбрать IP-адрес, используемый для коммуникаций с этой подсетью, в качестве server identifier. Если сервер использует множество адресов IP в этой подсети, он может указать любой из них. Если сервер получил сообщение через транслятор DHCP, серверу следует выбрать адрес интерфейса, через который он получил такое сообщение, в качестве server identifier (если у сервера нет более лучшей информации для этого выбора). Клиент DHCP должен использовать IP-адрес из опции server identifier для любый запросов к серверу DHCP, направляемых по индивидуальному адресу.

Сообщения DHCP, передаваемые клиентом в широковещательном режиме до получения им адреса IP, должны указывать в поле IP-адреса отправителя значение 0.

Если поле giaddr в сообщении DHCP от клиента отлично от 0, сервер передает все отклики на сообщения в порт DHCP server транслятору BOOTP, адрес которого указан в поле giaddr. Если giaddr = 0, а поле ciaddr отлично от нуля, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному адресу ciaddr. Если giaddr = 0, ciaddr = 0 и установлен флаг broadcast, сервер передает сообщения DHCPOFFER и DHCPACK по широковещательному адресу 0xffffffff. Если флаг broadcast не установлен, а giaddr и ciaddr имеют значение 0, сервер передает сообщения DHCPOFFER и DHCPACK по индивидуальному аппаратному адресу клиента и yiaddr. Во всех случаях, когда giaddr = 0, сервер отправляет сообщения DHCPNAK по широковещательному адресу 0xffffffff.

Если опции в сообщении DHCP используют поля sname и file, в поле options должна присутствовать опция option overload со значением 1, 2 или 3, как указано в RFC 1533. Если опция option overload присутствует в поле options, опции этого поля должны завершаться опцией end и могут включать одну или несколько опций pad для заполнения поля. Опции в полях sname и file (если их использование указано опцией options overload) должны начинаться с первого октета этих полей, должны завершаться опцией end, за которой должны следовать опции pad для заполнения оставшейся части поля. Любая отдельная опция в поле options, sname или file должна полностью помещаться в это поле. Опции в поле options должны обрабатываться первыми, чтобы могли быть интерпретированы любые опции option overload. Следующим должно обрабатываться поле file (если опция option overload указывает, что это поле содержит опции DHCP), а затем — поле sname.

Данные для передачи в опции могут оказаться слишком велики для включения в 255 октетов, доступных для одной опции (например, список маршрутизаторов в опции router [21]). Опции могут включаться лишь однократно, если иного не указано в спецификации конкретной опции. Клиент объединяет значения множества экземпляров одной опции в один список параметров.

Клиенты DHCP отвечают за передачу всех повторных сообщений. Клиент должен применять стратегию повторов, использующую алгоритм случайного увеличения интервалов между повторами. Задержку между повторами следует выбирать так, чтобы времени хватило на доставку откликов от сервера с учетом характеристик соединения между клиентом и сервером. Например, в сети Ethernet 10 Мбит/с, задержку перед первым повтором следует случайно выбирать около 4 секунд из интервала от -1 до +1 с однородным распределением. Клиенты, часы которых обеспечивают точность лучше 1 секунды, могут выбирать дробные значения задержки. Перед следующим повтором задержку следует выбирать около 8 секунд с добавлением случайного значения из интервала от -1 до +1 с однородным распределением. Задержку повтора следует удваивать при каждом повторе до достижения максимального интервала в 64 секунды. Клиент может показывать попытки повтора пользователю для индикации процесса настройки конфигурации.

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

Обычно серверы DHCP и трансляторы BOOTP пытаются напрямую доставить сообщения DHCPOFFER, DHCPACK и DHCPNAK клиенту с использованием индивидуальной адресации. IP-адрес получается (в заголовке IP) устанавливается в соответствии с полем yiaddr, а адрес получателя канального уровня — в соответствии с полем chaddr из сообщения DHCP. К сожалению некоторые реализации клиентов не способны принимать такие индивидуальные дейтаграммы, пока не будет настроен действующий адрес IP (возникает тупик, когда IP-адрес не может быть доставлен клиенту, пока у того не настроен адрес IP).

Клиенту, который не способен принимать индивидуальные дейтаграммы IP, пока в его программах не настроен адрес IP, следует устанавливать бит BROADCAST в поле flags всех передаваемых сообщений DHCPDISCOVER и DHCPREQUEST. Флаг BROADCAST подсказывает серверам DHCP и трансляторам BOOTP, что сообщения нужно передавать в подсеть клиента с использованием широковещания. Клиенту, способному принимать индивидуальные дейтаграммы IP до настройки протокола, следует сбрасывать флаг BROADCAST. Последствия использования флага BROADCAST обсуждаются в документе, разъясняющем протокол BOOTP [21].

Серверам и трансляторам, передающим или пересылающим сообщения DHCP напрямую клиентам (т. е. без указания транслятора в поле giaddr), следует проверять бит BROADCAST в поле flags. При установленном (1) флаге сообщение DHCP следует передавать в широковещательном режиме, указывая широковещательный адрес IP (предпочтительно 0xffffffff) в поле получателя IP и широковещательный адрес канального уровня в поле адресата канального уровня. Если флаг BROADCAST сброшен (0), следует передавать сообщение по индивидуальному адресу IP из поля yiaddr и индивидуальному адресу канального уровня из поля chaddr. Если индивидуальная адресация невозможна, сообщение можно передать с использованием широковещательного адреса IP (предпочтительно 0xffffffff) и широковещательного адреса канального уровня.

4.2 Элементы администрирования сервера DHCP

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

В некоторых средах сервер DHCP будет принимать во внимание значения фирменных опций в сообщениях DHCPDISCOVER и DHCPREQUEST при определении подходящих параметров для конкретного клиента.

Серверу DHCP нужно использовать некий уникальный идентификатор для привязки клиента к его аренде. Клиент может явно предоставлять идентификатор в опции client identifier. В таких случаях клиент должен указывать этот же идентификатор во всех последующих сообщениях, а сервер должен использовать это значение для идентификации клиента. Если клиент не использует опцию client identifier, сервер должен использовать для идентификации клиента содержимое поля chaddr17. Для клиента крайне важно обеспечивать уникальность значения опции client identifier в рамках подсети. Использование chaddr в качестве идентификатора клиента может приводить к неожиданным результатам, поскольку этот идентификатор может быть связан с аппаратным интерфейсом, который может перейти к другому клиенту. Некоторые сайты могут использовать в качестве client identifier серийный номер оборудования для предотвращения неожиданного изменения сетевого адреса клиента при переносе интерфейса в другой компьютер. В качестве client identifier может использоваться имя DNS для привязки аренды к имени, а не к оборудованию18.

Клиенты DHCP свободны в выборе сервера DHCP из числа ответивших сообщениями DHCPOFFER. Реализациям клиентов DHCP следует давать пользователю механизм непосредственного выбора значений vendor class identifier.

4.3 Поведение сервера DHCP

Сервер DHCP обрабатывает входящие сообщения DHCP от клиентов на основе текущего состояния привязки для данного клиента. Сервер DHCP может получать от клиента сообщения:

  • DHCPDISCOVER;

  • DHCPREQUEST;

  • DHCPDECLINE;

  • DHCPRELEASE;

  • DHCPINFORM.

В таблице 3 описано использование полей и опций сообщений сервером DHCP. В оставшейся части этого параграфа описываются действия сервера DHCP для всех входящих сообщений.

4.3.1 Сообщение DHCPDISCOVER

При получении от клиента сообщения DHCPDISCOVER сервер выбирает для этого клиента сетевой адрес. Если доступных адресов нет, сервер может сообщить об этом системному администратору. Если доступные адреса имеются, при выборе следует руководствоваться приведенным ниже порядком:

  • адрес клиента, записанный текущей привязке для этого клиента;

  • предыдущий адрес клиента, сохраненный в (истекщей или освобожденной) привязке, если этот адрес доступен и свободен;

  • адрес, указанный в опции Requested IP Address, если он пригоден и не занят;

  • новый адрес из пула доступных с учетом подсети, из которой получено сообщение (если giaddr = 0), или адреса транслятора, переславшего сообщение (giaddr отличается от 0).

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

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

Хотя для корректной работы DHCP это не требуется, серверам не следует повторно использовать выбранный сетевой адрес до того, как клиент ответит на сообщение DHCPOFFER. Сервер может записывать адрес, предложенный клиенту.

Сервер также должен выбрать срок аренды адреса в соответствии в приведенными ниже правилами и порядком.

  • Если клиент не указал конкретный срок аренды в сообщении DHCPDISCOVER и уже имеет выделенный сетевой адрес, сервер возвращает срок завершения аренды для этого адреса (отметим, что клиент должен явно запросить конкретный срок для расширения времени аренды уже назначенного ему адреса).

  • Если клиент не указал конкретный срок аренды в сообщении DHCPDISCOVER и не еще имеет сетевого адреса, сервер задает принятое по умолчанию время аренды.

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

Таблица 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

flags из клиентского сообщения DHCPREQUEST

flags из клиентского сообщения DHCPREQUEST

giaddr

giaddr из клиентского сообщения DHCPDISCOVER

giaddr из клиентского сообщения DHCPREQUEST

giaddr из клиентского сообщения DHCPREQUEST

chaddr

chaddr из клиентского сообщения DHCPDISCOVER

chaddr из клиентского сообщения DHCPREQUEST

chaddr из клиентского сообщения DHCPREQUEST

sname

Имя сервера или опции

Имя сервера или опции

Не используется

file

Имя файла для загрузки клиента или опции

Имя файла для загрузки клиента или опции

Не используется

options

Опции

Опции

Опция

DHCPOFFER

DHCPACK

DHCPNAK

Запрошенный адрес IP

Недопустимо

Недопустимо

Недопустимо

Время аренды адреса IP

Требуется

Требуется (DHCPREQUEST)
Недопустимо (DHCPINFORM)

Недопустимо

Использование полей file/sname

Возможно

Возможно

Недопустимо

Тип сообщения DHCP

DHCPOFFER

DHCPACK

DHCPNAK

Список параметров запроса

Недопустимо

Недопустимо

Недопустимо

Сообщение

Следует

Следует

Следует

Идентификатор клиента

Недопустимо

Недопустимо

Возможно

Идентификатор класса производителя

Возможно

Возможно

Возможно

Идентификатор сервера

Требуется

Требуется

Требуется

Максимальный размер сообщения

Недопустимо

Недопустимо

Недопустимо

Все прочие

Возможно

Возможно

Недопустимо

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

  • Сетевой адрес клиента в соответствии с правилами, приведенными выше.

  • Срок завершения аренды, заданный в соответствии с приведенными выше правилами.

  • Параметры, запрошенные клиентом, в соответствии с приведенными ниже правилами:

  • если на сервере явно задано принятое по умолчанию значение параметра, сервер должен включать это значение в соответствующую опцию поля option;

  • если сервер распознает параметр, как определенный в документе Host Requirements, он должен включить принятое по умолчанию значение из Host Requirements в соответствующую опцию поля option;

  • в остальных случаях серверу недопустимо возвращать значение параметра.

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

  • Все параметры из существующих привязок, которые отличаются от принятых по умолчанию в Host Requirements.

  • Все специфические параметры клиента (как указывает содержимое полей chaddr19 и client identifier в сообщении DHCPDISCOVER или DHCPREQUEST), например, заданные администратором сети.

  • Все специфические для данного класса клиентов параметры (в соответствии с содержимым опции vendor class identifier в DHCPDISCOVER или DHCPREQUEST), например, заданные администратором сети. Параметры должны указываться в точном совпадении идентификаторов vendor class для клиента и идентификаторами классов клиентов на сервере.

  • Параметры, с отличающимися от принятых по умолчанию значениями для подсети клиента.

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

4.3.2 Сообщение DHCPREQUEST

Сообщения DHCPREQUEST могут приходить от клиентов, отвечающих на серверные сообщения DHCPOFFER, от клиентов, проверяющих выделенный ранее адрес IP, или от клиентов, желающих продлить аренду адреса. Если сообщение DHCPREQUEST включает опцию server identifier, оно является откликом на DHCPOFFER. В остальных случаях сообщение служит для проверки или продления имеющейся аренды. Если клиент использует client identifier в сообщении DHCPREQUEST, он должен указывать тот же идентификатор во всех последующих сообщениях. Если клиент указал список запрашиваемых параметров в сообщении DHCPDISCOVER, он должен включать этот же список параметров в последующие сообщения.

Конфигурационным параметрам в DHCPACK не следует противоречить параметрам из предыдущего сообщения DHCPOFFER, на которое клиент ответил. Клиенту следует применять параметры из DHCPACK для своей настройки.

Клиент передает сообщения DHCPREQUEST в соответствии с приведенными ниже описаниями.

  • DHCPREQUEST в состоянии SELECTING.

    Клиент помещает адрес выбранного сервера в server identifier, поле ciaddr должно быть равно 0, поле requested IP address должно содержать значение yiaddr из выбранного сообщения DHCPOFFER.

    Отметим, что клиент может собрать несколько сообщений DHCPOFFER и выбрать среди них «лучшее». Свой выбор клиент указывает включением предложившего его сервера в сообщение DHCPREQUEST. Если клиент не получил приемлемых предложений, он может повторить передачу сообщения DHCPDISCOVER. Поэтому серверы могут не получить конкретного сообщения DHCPREQUEST, из которого можно понять, было ли предложение принято клиентом. Поскольку серверы не фиксируют назначения сетевых адресов на основе своих предложений DHCPOFFER, они могут снова указать предлагавшийся ранее адрес в откликах на последующие запросы. В соответствии с деталями реализации некоторым серверам не следует снова использовать предложенные адреса и они могут использовать определяемые реализацией механизмы тайм-аутов для определения возможности снова использовать адрес.

  • DHCPREQUEST в состоянии INIT-REBOOT.

    Поле server identifier недопустимо заполнять, опция requested IP address должна указывать ранее назначенный адрес клиента, а поде ciaddr должно иметь значение 0. Клиент проверяет ранее выделенную, кэшированную им конфигурацию. Серверу следует передать в ответ сообщение DHCPNAK, если requested IP address указывает некорректный адрес или относится к неподходящей сети.

    Для определения корректности сети клиента в состоянии INIT-REBOOT проверяется содержимое giaddr, опция requested IP address и выполняется просмотр базы данных. Если сервер DHCP обнаруживает, что клиент находится в неподходящей сети (т. е. результат применения локальной или удаленной (если giaddr отличается от 0) маски подсети к значению опции requested IP address дает несоответствие), серверу следует вернуть клиенту сообщение DHCPNAK.

    Если сеть корректна, серверу DHCP следует проверить корректность указанного клиентом адреса IP. Если адрес не подходит, серверу следует передать сообщение DHCPNAK. Если у сервера DHCP нет записи для этого клиента, он должен оставить сообщение без ответа и может передать предупреждение администратору сети. Такое поведение требуется для «мирного сосуществования» не взаимодействующих серверов DHCP в одном физическом сегменте.

    Если в сообщении DHCPREQUEST giaddr = 0x0, клиент расположен в одной подсети с сервером. Сервер должен передать сообщение DHCPNAK по широковещательному адресу 0xffffffff, поскольку у клиента может не быть корректного сетевого адреса и маски подсети и он может не отвечать на запросы ARP.

    Если в сообщении DHCPREQUEST установлено отличное от нуля значение giaddr, клиент находится в другой подсети. Сервер должен установить флаг B в сообщении DHCPNAK, чтобы транслятор передал сообщение DHCPNAK клиенту по широковещательному адресу, поскольку у клиента может не быть корректного сетевого адреса и маски подсети и он может не отвечать на запросы ARP.

  • DHCPREQUEST в состоянии RENEWING.

    Поле server identifier и опцию requested IP address недопустимо заполнять, в поле ciaddr должен быть указан IP-адрес клиента. В этой ситуации клиент полностью настроен и пытается продлить срок аренды. Это сообщение будет передаваться по индивидуальному адресу без привлечения агентов трансляции. Поскольку giaddr в этом случае не указывается, сервер DHCP будет доверять значению ciaddr и использовать его при передаче отклика клиенту.

    Клиент может обновить или продлить аренду до истечения времени T1. Сервер может отказаться от продления аренды (например, в соответствии с политикой), но независимо от этого ему следует вернуть сообщение DHCPACK.

  • DHCPREQUEST в состоянии REBINDING.

    Поле server identifier и опцию requested IP address недопустимо заполнять, в поле 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 Сообщения клиента

В таблице 4 приведены различия между сообщениями от клиентов в разных состояниях.

Таблица 4. Клиентские сообщения для разных состояний.

INIT-REBOOT

SELECTING

RENEWING

REBINDING

broad/unicast

broadcast

broadcast

unicast

broadcast

server-ip

Недопустимо

Требуется

Недопустимо

Недопустимо

requested-ip

Требуется

Требуется

Недопустимо

Недопустимо

ciaddr

0

0

IP-адрес

IP-адрес

4.4 Поведение клиента DHCP

 --------                               -------
|        | +-------------------------->|       |<-------------------+
| INIT-  | |     +-------------------->| INIT  |                    |
| REBOOT |DHCPNAK/         +---------->|       |<---+               |
|        |Рестарт|         |            -------     |               |
 --------  |  DHCPNAK/     |               |                        |
    | Отбрасыв. предложения|      -/Передача DHCPDISCOVER           |
-/ Передача DHCPREQUEST    |               |                        |
    |      |     |      DHCPACK            v        |               |
 -----------     |   (не принято) /   -----------   |               |
|           |    |Перед. DHCPDECLINE |           |                  |
| REBOOTING |    |         |         | SELECTING |<----+            |
|           |    |        /          |           |     |DHCPOFFER/  |
 -----------     |       /            -----------   |  |Сбор        |
    |            |      /                  |   |       |откликов    |
DHCPACK/         |     /  +----------------+   +-------+            |
запись аренды,   |    |   v   Выбор предложения/                    |
таймеры T1, T2  ------------  передача DHCPREQUEST  |               |
    |   +----->|            |             DHCPNAK, аренда истекла/  |
    |   |      | REQUESTING |                 остановка сети        |
    DHCPOFFER/ |            |                       |               |
 отбрасывание   ------------                        |               |
    |   |        |        |                   -----------           |
    |   +--------+     DHCPACK/              |           |          |
    |              запись аренды,       -----| REBINDING |          |
    |          установ. таймеров T1, T2/     |           |          |
    |                     |        DHCPACK/   -----------           |
    |                     v  Запись аренды, установ.^               |
    +----------------> -------      /таймеров T1,T2 |               |
               +----->|       |<---+                |               |
               |      | BOUND |<---+                |               |
  DHCPOFFER, DHCPACK, |       |    |            T2 истекло/ DHCPNAK/
   DHCPNAK/Отбрасыв.   -------     |             широковещ. Останов. сети
               |       | |         |            DHCPREQUEST         |
               +-------+ |        DHCPACK/          |               |
                    T1 истекло/  Запись аренды, уст.|               |
            Передача DHCPREQUEST таймеров T1, T2    |               |
                 серверу аренды    |                |               |
                         |   ----------             |               |
                         |  |          |------------+               |
                         +->| RENEWING |                            |
                            |          |----------------------------+
                             ----------

Рисунок 5. Диаграмма смены состояний клиента DHCP.


На рисунке 5 приведена диаграмма состояний клиента DHCP.

Клиент может получать от сервера сообщения:

  • DHCPOFFER;

  • DHCPACK;

  • DHCPNAK.

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

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

4.4.1 Инициализация и выделение сетевого адреса

Клиент начинает с состояния INIT и создает сообщение DHCPDISCOVER. Клиенту следует ждать случайное время от 1 до 10 секунд для рассинхронизации использования DHCP при старте. Клиент устанавливает ciaddr = 0x00000000. Клиент может запросить конкретные параметры с помощью опции parameter request list. Клиент может предложить сетевой адрес и/или время аренды с помощью опций requested IP address и IP address lease time. Клиент должен включить свой аппаратный адрес в поле chaddr, если это требуется для доставки откликов DHCP. Клиент может включить в поле client identifier другой уникальный идентификатор20, как описано в параграфе 4.2. Если клиент указывает список желаемых параметров в сообщении DHCPDISCOVER, он должен включать тот же список во все последующие сообщения.

Клиент генерирует и записывает случайное значение идентификатора транзакции, а затем помещает его в поле xid. Клиент записывает свое локальное время и далее использует его для контроля срока аренды. После этого клиент передает сообщение DHCPDISCOVER по локальному широковещательному аппаратному адресу и широковещательному адресу IP 0xffffffff в порт UDP DHCP server.

Если значение xid в полученном сообщении DHCPOFFER не соответствует xid в последнем сообщении DHCPDISCOVER, сообщение DHCPOFFER следует отбросить без уведомления отправителя. Так же следует постыпать со всеми приходящими сообщениями DHCPACK.

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

Таблица 5. Поля и опции, используемые клиентом DHCP.

Поле

DHCPDISCOVER
DHCPINFORM

DHCPREQUEST

DHCPDECLINE
DHCPRELEASE

op

BOOTREQUEST

BOOTREQUEST

BOOTREQUEST

htype

Из RFC Assigned Numbers

hlen

Размер аппаратного адреса в октетах.

hops

0

0

0

xid

Выбирается клиентом

xid из клиентского сообщения DHCPOFFER

Выбирается клиентом

secs

0 или число секунд с начала процесса DHCP

0 или число секунд с начала процесса DHCP

0

flags

Установка флага BROADCAST, если клиенту нужно широковещательный отклик

Установка флага BROADCAST, если клиенту нужно широковещательный отклик

0

ciaddr

0 (DHCPDISCOVER)
Сетевой адрес клиента (DHCPINFORM)

0 или сетевой адрес клиента (BOUND/RENEW/REBIND)

0 (DHCPDECLINE)
Сетевой адрес клиента (DHCPRELEASE)

yiaddr

0

0

0

siaddr

0

0

0

giaddr

0

0

0

chaddr

Сетевой адрес клиента

Сетевой адрес клиента

Сетевой адрес клиента

sname

Опции, если указаны в опции sname/file, в остальных случаях не используется

Опции, если указаны в опции sname/file, в остальных случаях не используется

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

file

Опции, если указаны в опции sname/file, в остальных случаях не используется

Опции, если указаны в опции sname/file, в остальных случаях не используется

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

options

Опции

Опции

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

Опция

DHCPDISCOVER
DHCPINFORM

DHCPREQUEST

DHCPDECLINE
DHCPRELEASE

Requested IP address

Возможно (DISCOVER)
Недопустимо
(INFORM)

Требуется (SELECTING или INIT-REBOOT)
Недопустимо (BOUND или RENEWING)

Требуется (DHCPDECLINE)
Недопустимо (DHCPRELEASE)

IP address lease time

Возможно (DISCOVER)
Недопустимо
(INFORM)

Возможно

Недопустимо

Использование полей file/sname

Возможно

Возможно

Возможно

Тип сообщения DHCP

DHCPDISCOVER/ DHCPINFORM

DHCPREQUEST

DHCPDECLINE/ DHCPRELEASE

Client identifier

Возможно

Возможно

Возможно

Vendor class identifier

Возможно

Возможно

Недопустимо

Server identifier

Недопустимо

Требуется (после SELECTING)
Недопустимо (после INIT-REBOOT, BOUND, RENEWING или REBINDING)

Требуется

Parameter request list

Возможно

Возможно

Недопустимо

Maximum message size

Возможно

Возможно

Недопустимо

Message

Не следует

Не следует

Следует

Site-specific

Возможно

Возможно

Недопустимо

Все прочие

Возможно

Возможно

Недопустимо

Если параметры приемлемы, клиент записывает адрес сервера из поля server identifier и помещает этот адрес в одноименное поле DHCPREQUEST широковещательного сообщения. После приема от сервера сообщения DHCPACK клиент инициализирует себя и переходит в состояние BOUND. Сообщение DHCPREQUEST содержит то же значение xid, что и сообщение DHCPOFFER. Клиент записывает время завершения аренды как сумму времени отправки исходного запроса и продолжительности аренды, указанной в сообщении DHCPACK. Клиенту следует проверить предложенный адрес на предмет его занятости. Например, если в сети клиента поддерживается ARP, клиент может передать запрос ARP для предложенного адреса. При отправке широковещательного запроса ARP для предложенного адреса, клиент должен указать свой аппаратный адрес в поле отправителя и 0 в качестве IP-адреса отправителя, для предотвращения конфликта с кэшами ARP в других хостах той же подсети. Если сетевой адрес уже занят, клиент должен передать серверу сообщение DHCPDECLINE. Клиенту следует передать широковещательный отклик ARP для анонсирования нового адреса IP и сброса устаревших записей с кэшах ARP хостов подсети клиента.

4.4.2 Инициализация с известным сетевым адресом

Клиент начинает с состояния INIT-REBOOT и передает сообщение DHCPREQUEST. Клиент должен указать известный ему сетевой адрес в опции requested IP address сообщения DHCPREQUEST. Клиент может запросить конкретные параметры конфигурации, перечислив их в опции parameter request list. Клиент генерирует и записывает случайное значение идентификатора транзакции, а затем помещает его в поле xid. Клиент записывает локальное время для последующего контроля срока аренды. Клиенту недопустимо включать server identifier в сообщение DHCPREQUEST. Клиент передает сообщение DHCPREQUEST по локальному аппаратному широковещательному адресу в порт UDP DHCP server.

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

4.4.3 Инициализация с назначенным извне сетевым адресом

Клиент создает и записывает случайное значение идентификатора транзакции, а затем помещает его в поле xid, а свой сетевой адрес в поле ciaddr. Клиент передает сообщение DHCPINFORM и может запросить в нем конкретные параметры конфигурации, указав их в опции parameter request list. Клиенту не следует запрашивать срок аренды.

Клиент передает сообщение DHCPINFORM серверу DHCP по индивидуальному адресу, если тот известен или по адресу ограниченного широковещания (все 1). Сообщение DHCPINFORM должно направляться в порт UDP DHCP server.

После получения от сервера сообщения DHCPACK с полем xid, совпадающим с одноименным полем в DHCPINFORM клиент инициализирует самого себя.

Если клиент не получил сообщения DHCPACK в течение разумного срока ожидания (60 секунд или 4 попытки при использовании тайм-аута, предложенного в параграфе 4.1), ему следует вывести сообщение, информирующее пользователя о проблеме, а также следует начать работу в сети, используя подходящие значения из Приложения A.

4.4.4 Использование широковещания и индивидуальной адресации

Клиент DHCP передает сообщения DHCPDISCOVER, DHCPREQUEST и DHCPINFORM, пока ему не известен адрес сервера DHCP. Сообщение DHCPRELEASE клиент передает по индивидуальному адресу сервера. Сообщение DHCPDECLINE передается в широковещательном режиме, поскольку клиент отвергает использование предложенного сервером адреса IP. Когда клиент DHCP в состоянии INIT или REBOOTING знает адрес сервера DHCP, он может использовать этот адрес в сообщении DHCPDISCOVER или DHCPREQUEST вместо широковещательного адреса IP. Клиент может также использовать индивидуальный адрес для передачи сообщения DHCPINFORM известному серверу DHCP. Если клиент не получает откликов на сообщения DHCP, отправленные по известному IP-адресу сервера DHCP, клиенту следует вернуться к использованию широковещательного адреса IP.

4.4.5 Завершение и повторная аренда

Клиент поддерживает параметры T1 и T2, определяющие момент времени, когда клиент пытается продлить свою аренду сетевого адреса. T1 указывает время, при котором клиент переходит в состояние RENEWING и пытается связаться с сервером, который назначил ему сетевой адрес. T2 указывает время, когда клиент переходит в состояние REBINDING и пытается связаться с любым сервером. Момент T1 должен наступать раньше T2, который, в свою очередь, должен наступать раньше завершения срока аренды.

Для предотвращения необходимости синхронизации часов значения T1 и T2 выражаются в опциях интервалами, а не абсолютным временем [2].

В момент T1 клиент переходит в состояние RENEWING и передает (по индивидуальному адресу) сообщение DHCPREQUEST серверу для расширения срока аренды. Клиент устанавливает в поле ciaddr сообщения DHCPREQUEST свой текущий сетевой адрес и записывает локальное время передачи сообщения DHCPREQUEST для вычисления срока завершения аренды. Клиенту недопустимо включать server identifier в сообщение DHCPREQUEST.

Любое сообщение DHCPACK, в котором поле xid не совпадает с одноименным полем в отправленном клиентом запросе DHCPREQUEST, отбрасывается без уведомления. При получении от сервера сообщения DHCPACK клиент рассчитывает срок завершения аренды, складывая срок аренды из сообщения DHCPACK со временем отправки DHCPREQUEST. После успешного обновления аренды сетевого адреса клиент возвращается в состояние BOUND и может продолжать работу в сети.

Если сообщение DHCPACK не приходит до момента T2, клиент переходит в состояние REBINDING и передает (по широковещательному адресу) сообщение DHCPREQUEST для продления срока аренды, устанавливая в поле ciaddr свой текущий сетевой адрес. Клиенту недопустимо включать server identifier в сообщение DHCPREQUEST.

Значения T1 и T2 настраиваются сервером с помощью опций. Для T1 по умолчанию используется значение в половину срока аренды (0,5 * duration_of_lease), для T2 — (0,875 * duration_of_lease). При выборе значений T1 и T2 следует добавлять случайное отклонение (fuzz) для предотвращения синхронизации разных клиентов.

Клиент может обновить или продить аренду до истечения времени T1. Сервер может принять решение о продлении аренды для клиента в соответствии с заданной сетевым администратором политикой. Серверу следует возвращать T1 и T2, а их значения следует подстраивать с учетом оставшегося времени аренды.

В состояниях RENEWING и REBINDING при отсутствии отклика на сообщение DHCPREQUEST клиенту следует выждать половину времени, оставшегося до T2 (RENEWING) или завершения срока аренды (REBINDING), но не менее 60 секунд до того, как повторить сообщение DHCPREQUEST.

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

4.4.6 DHCPRELEASE

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

5. Благодарности

Автор признателен множеству (слишком много для перечисления!) участников рабочей группы DHC за их неустанную работу по развитию DHCP и подготовке этого документа.

Спасибо J Allard, Mike Carney, Dave Lapp, Fred Lien и John Mendonca за организацию тестирования интероперабельности DHCP.

Разработка этого документа частично поддерживалась в рамках гранта Corporation for National Research Initiatives (CNRI), Bucknell University и Sun Microsystems.

6. Литература

[1] Acetta, M., «Resource Location Protocol», RFC 887, CMU, December 1983.

[2] Alexander, S., and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993.

[3] Braden, R., Editor, «Requirements for Internet Hosts – Communication Layers», STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

[4] Braden, R., Editor, «Requirements for Internet Hosts – Application and Support, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

[5] Brownell, D, «Dynamic Reverse Address Resolution Protocol (DRARP)», Work in Progress21.

[6] Comer, D., and R. Droms, «Uniform Access to Internet Directory Services», Proc. of ACM SIGCOMM ’90 (Special issue of Computer Communications Review), 20(4):50—59, 1990.

[7] Croft, B., and J. Gilmore, «Bootstrap Protocol (BOOTP)», RFC 951, Stanford and SUN Microsystems, September 1985.

[8] Deering, S., «ICMP Router Discovery Messages», RFC 1256, Xerox PARC, September 1991.

[9] Droms, D., «Interoperation between DHCP and BOOTP», RFC 1534, Bucknell University, October 1993.

[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, «A Reverse Address Resolution Protocol», RFC 903, Stanford, June 1984.

[11] Gray C., and D. Cheriton, «Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency», In Proc. Of the Twelfth ACM Symposium on Operating Systems Design, 1989.

[12] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[13] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[14] Mogul J., and S. Deering, «Path MTU Discovery», RFC 1191, November 1990.

[15] Morgan, R., «Dynamic IP Address Assignment for Ethernet Attached Hosts», Work in Progress.

[16] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, USC/Information Sciences Institute, September 1981.

[17] Reynolds, J., «BOOTP Vendor Information Extensions», RFC 1497, USC/Information Sciences Institute, August 1993.

[18] Reynolds, J., and J. Postel, «Assigned Numbers», STD 2, RFC 170022, USC/Information Sciences Institute, October 1994.

[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic Assignment of IP Addresses for use on an Ethernet. (Available from the Athena Project, MIT), 1989.

[20] Sollins, K., «The TFTP Protocol (Revision 2)», RFC 783, NIC, June 1981.

[21] Wimer, W., «Clarifications and Extensions for the Bootstrap Protocol», RFC 1542, Carnegie Mellon University, October 1993.

7. Вопросы безопасности

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

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

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

8. Адрес автора

Ralph Droms

Computer Science Department

323 Dana Engineering

Bucknell University

Lewisburg, PA 17837

Phone: (717) 524-1145

EMail: droms@bucknell.edu


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

A. Конфигурационные параметры хоста

Параметр

Значение

Документ

Параметры уровня IP, на хост

Be a router

on/off

RFC 1122, параграф 3.1

Non-local source routing

on/off

RFC 1122, параграф 3.3.5

Фильтры правил для нелокальной маршрутизации от отправителя

on/off

RFC 1122, параграф 3.3.5

Maximum reassembly size

integer

RFC 1122, параграф 3.3.2

Default TTL

integer

RFC 1122, параграф 3.2.1.7

PMTU aging timeout

integer

RFC 1191, параграф 6.6

MTU plateau table

(список)

RFC 1191, параграф 7

Параметры уровня IP, на интерфейс

Адрес IP

(адрес)

RFC 1122, параграф 3.3.1.6

Маска подсети

(маска адреса)

RFC 1122, параграф 3.3.1.6

MTU

integer

RFC 1122, параграф 3.3.3

All-subnets-MTU

on/off

RFC 1122, параграф 3.3.3

Broadcast address flavor

0x00000000/0xffffffff

RFC 1122, параграф 3.3.6

Выполнять определение маски

on/off

RFC 1122, параграф 3.2.2.9

Служить поставщиком маски

on/off

RFC 1122, параграф 3.2.2.9

Выполнять обнаружение маршрутизаторов

on/off

RFC 1256, параграф 5.1

Router solicitation address

(адрес)

RFC 1256, параграф 5.1

Используемый по умолчанию маршрутизаторы, список

адресов маршрутизаторов

(адрес)

RFC 1122, параграф 3.3.1.6

уровней предпочтения

integer

RFC 1122, параграф 3.3.1.6

Статические маршруты, список

получателей

(хост/подсеть/сеть)

RFC 1122, параграф 3.3.1.2

масок получателей

(маска адреса)

RFC 1122, параграф 3.3.1.2

типов обслуживания

integer

RFC 1122, параграф 3.3.1.2

первых маршрутизаторов

(адрес)

RFC 1122, параграф 3.3.1.2

игнорирование перенаправления

on/off

RFC 1122, параграф 3.3.1.2

PMTU

integer

RFC 1191, параграф 6.6

выполнять определение PMTU

on/off

RFC 1191, параграф 6.6

Параметры канального уровня, на интерфейс

Трейлеры

on/off

RFC 1122, параграф 2.3.1

Тайм-аут кэша ARP

integer

RFC 1122, параграф 2.3.2.1

Инкапсуляция Ethernet

(RFC 894/RFC 1042)

RFC 1122, параграф 2.3.3

TCP_parameters, на хост

TTL

integer

RFC 1122, параграф 4.2.2.19

Keep-alive interval

integer

RFC 1122, параграф 4.2.3.6

Keep-alive data size

0/1

RFC 1122, параграф 4.2.3.6

1Dynamic Host Configuration Protocol.

2Bootstrap Protocol — протокол загрузки.

3Reverse Address Resolution Protocol — протокол обратного преобразования адресов.

4Dynamic RARP — динамический RARP.

5Trivial File Transfer Protocol — ограниченный (тривиальный) протокол переноса файлов.

6Internet Control Message Protocol — протокол управляющих сообщений Internet.

7Network Information Protocol — протокол сетевой информации.

8Resource Location Protocol — протокол определения местоположения ресурсов.

9Maximum transmission unit — максимальный передаваемый блок. В оригинале ошибочно сказано «минимальный», см. https://www.rfc-editor.org/errata/eid488. Прим. перев.

10Address Resolution Protocol — протокол преобразования адресов.

11Domain Name System.

12В соответствии с RFC 4361 текст «- это поле может содержать, например, аппаратный адрес, идентичный содержимому поля chaddr, или быть идентификатором другого типа (скажем, именем DNS)» удален из спецификации. Прим. перев.

13В настоящее время эта информация доступна по ссылке. Прим. перев.

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

15В соответствии с RFC 4361 текст «или chaddr» удален из спецификации. Прим. перев.

16В соответствии с RFC 4361 текст «или chaddr» удален из спецификации. Прим. перев.

17В соответствии с RFC 4361 текст «Клиент может явно предоставлять идентификатор в опции client identifier. В таких случаях клиент должен указывать этот же идентификатор во всех последующих сообщениях, а сервер должен использовать это значение для идентификации клиента. Если клиент не использует опцию client identifier, сервер должен использовать для идентификации клиента содержимое поля chaddr» заменен словами «Клиент должен явно предоставить свой идентификатор с помощью опции client identifier. Клиент должен использовать одинаковую опцию client identifier во всех сообщениях». Прим. перев.

18В соответствии с RFC 4361 текст «Использование chaddr в качестве идентификатора клиента может приводить к неожиданным результатам, поскольку этот идентификатор может быть связан с аппаратным интерфейсом, который может перейти к другому клиенту. Некоторые сайты могут использовать в качестве client identifier серийный номер оборудования для предотвращения неожиданного изменения сетевого адреса клиента при переносе интерфейса в другой компьютер. В качестве client identifier может использоваться имя DNS для привязки аренды к имени, а не к оборудованию» заменен текстом «Клиенту DHCP недопустимо опираться на поле chaddr для идентификации». Прим. перев.

19В соответствии с RFC 4361 текст «chaddr» удален из спецификации. Прим. перев.

20В соответствии с RFC 4361 текст «Клиент может включить в поле client identifier другой уникальный идентификатор» «Клиент должен включить уникальный идентификатор». Прим. перев.

21Работа опубликована в RFC 1931. Прим. перев.

22В RFC 3232 документ Assigned Numbers отменен. Данные в настоящее время доступны по ссылке. Прим. перев.




RFC 2119 Key words for use in RFCs to Indicate Requirement Levels

Network Working Group                                     S. Bradner
Request for Comments: 2119                        Harvard University
BCP: 14                                                   March 1997
Category: Best Current Practice

 

Ключевые слова для обозначения уровня требований в RFC

Key words for use in RFCs to Indicate Requirement Levels

PDF

Статус документа

Этот документ относится к категории документов BCP (Best Current Practice) для сообщества Internet. Принимаются поправки и предложения, направленные на совершенствование документа. Допускается свободное распространение документа.

Тезисы

Во многих документах, описывающих стандарты, используются модальные глаголы для обозначения уровня требований. Такие слова часто выделяются заглавными буквами1. В данном документе определяется толкование этих глаголов и производных от них слов в документах IETF. Авторам документов, следующих приведенным здесь требованиям, рекомендуется помещать в начале документов приведенный ниже текст:

The key words «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» in this document are to be interpreted as described in RFC 21192.

Отметим, что «сила» этих глаголов зависит от уровня требований использующего их документа.

1. MUST — необходимо

Это слово, а также термины требуется (REQUIRED) и нужно (SHALL) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

2. MUST NOT — недопустимо

Эта фраза или слова SHALL NOT (не позволяется) означают абсолютный запрет в рамках спецификации.

3. SHOULD — следует

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

4. SHOULD NOT — не следует

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

5. MAY — возможно

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

6. Рекомендации по использованию

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

7. Вопросы безопасности

Рассматриваемые здесь термины часто используются при обсуждении вопросов безопасности. Отказ от выполнения необходимых (MUST) или рекомендуемых (SHOULD) требований или реализация недопустимых (MUST NOT)/нерекомендуемых (SHOULD NOT) может существенно влиять на безопасность. Авторы документов должны уделить внимание вопросам безопасности, чтобы не появлялись реализации с невыполненными требованиями или рекомендациями.

8. Благодарности

Определения терминов даны на основе использования этих терминов во множестве RFC. Кроме того, при подготовке документа были учтены предложения многих людей, включая Robert Ullmann, Thomas Narten, Neal McBurnett, Robert Elz.

9. Адрес автора

Scott Bradner

Harvard University

1350 Mass. Ave.

Cambridge, MA 02138

phone — +1 617 495 3864

email — sob@harvard.edu

Перевод на русский язык

Николай Малых

nmalykh@gmail.com


1В переводах на сайте www.protocols.ru используется выделение жирным шрифтом. Прим. перев.

2Ключевые слова необходимо, недопустимо, требуется, нужно, не нужно, следует, не следует, рекомендуется, не рекомендуется, возможно, необязательно в данном документе должны интерпретироваться в соответствии с требованиями RFC 2119.