RFC 3942 Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

Опубликовано 26.11.2004 автором Nikolai Malykh 
Network Working Group                                            B. Volz
Request for Comments: 3942                           Cisco Systems, Inc.
Updates: 2132                                              November 2004
Category: Standards Track

Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options

Реклассификация опций протокола DHCPv4

PDF

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

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

Авторские права

Copyright (C) The Internet Society (2004).

Аннотация

Этот документ обновляет RFC 2132 для реклассификации кодов опций протокола DHCPv41 с десятичными значениями 128 – 223 как общедоступных с управлением IANA в соответствии с RFC 2939. Документ указывает IANA сделать эти опции доступными для распределения как общедоступных опций DHCP.

Оглавление

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

1. Введение

Определенный в DHCPv4 [RFC2131] диапазон общедоступных опций (1 – 127) почти исчерпан. Усилия, подобные [RFC3679] помогли продлить срок жизни этого пространства, однако в конце концов оно закончится.

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

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

3. Основания

Пространство опций DHCP (0 – 255) было разделено на два диапазона [RFC2132]:

  1. 1 – 127 – общедоступные опции, распределяемые в соответствии с [RFC2939];

  2. 128 – 254 – специфические для сайта опции.

Особые опции 0 (заполнение – pad) и 255 (конец опций – end) были определены в [RFC2131].

3.1. Диапазон общедоступных опций

Пространство опций общего назначение (1 – 127) почти закончилось. Недавняя работа [RFC3679] позволила продлить время, поскольку освободила часть выделенных, не не используемых опций. Время от времени можно пересматривать опции для определения неиспользуемых кодов, которые можно вернуть.

Однако желательно найти долгосрочное решение проблемы нехватки общедоступных опций. Рабочая группа DHC оценила несколько приведенных ниже решений.

  1. Использование кодов 126 и 127 для 16-битовых опций было предложено Ralph Droms в конце 1996 г. Однако это существенно усложняет первую опцию, выделенную в этом пространстве, поскольку требует реализации поддержки 16-битовых опций. В результате коды 126 и 127 были возвращены [RFC3679].

  2. Использование нового magic cookie и 16-битовых кодов опций. Однако это имеет целый рад недостатков:

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

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

    • требует поддержки обоих форматов сообщений в обозримом будущем;

    • требует от клиентов передавать множество сообщений DHCPDISCOVER (по 1 для каждого magic cookie).

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

3.2. Диапазон опций для сайтов

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

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

4. Реклассификация опций

Коды опций 128 – 223 классифицируются как общедоступные, а для сайтов остается 31 опция (224 – 254).

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

  1. Опции 128 – 223 будут переведены IANA в состояние недоступных (Unavailable) и пока не будут распределяться в качестве общедоступных.

  2. Производители, использующие одну или множество таких опций, в течение 6 месяцев после публикации этого RFC уведомляют рабочую группу DHC и IANA о применении конкретных номеров опций и согласии опубликовать документ об их использовании в серии RFC. IANA переведет эти опции из состояния Unavailable в Tentatively Assigned (предварительно распределены). У производителя будет 18 месяцев после публикации этого RFC’s до начала процесса документирования путем представления документа Internet-Draft.

    Примечание. Если на один номер опции будет претендовать несколько производителей, продемонстрировавших достаточно широкое применение опции, этот номер не будут выделен ни одному из них и они должны будут пройти обычный процесс получения номера общедоступной опции [RFC2939].

  3. Все опции, которые сохранят состояние Unavailable через 6 месяцев после публикации этого RFC, будут переведены IANA в состояние Unassigned (не выделено). Эти опции становятся доступными для распределения в соответствии с [RFC2939].

  4. Для опций в состоянии Tentatively Assigned у производителей будет 18 месяцев с момента публикации этого RFC на представление документа Internet-Draft, описывающего опцию. Документированное использование должно соответствовать реальному. После публикации документа об использовании опции как RFC агентство IANA переведет опцию в состояние Assigned (выделено).

    Если Internet-Draft не будет представлен в течение 18 месяцев или срок действия документов Internet-Draft истечет через 18 месяцев, IANA переведет опцию в состояние Unassigned и она станет доступной для обычного распределения в соответствии с [RFC2939].

Сайтам, использующим опции из реклассифицированного диапазона, следует предпринять действия по смене номеров своих опций на значения из оставшегося диапазона. Если сайту нужно более 31 опции, он должен решить свои задачи с помощью других опций, таких как Relay Agent Information [RFC3046].

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

Этот документ сам по себе не обеспечивает безопасности и не влияет на текущую безопасность DCHP, описанную в [RFC2131].

6. Взаимодействие с IANA

Ниже перечислены действия, запрашиваемые у агентства IANA.

  1. Расширить пространство общедоступных опций DHCPv4 с 1 – 127 до 1 – 223. Новые опции 128 – 223 указываются ка недоступные (Unavailable) и их недопустимо выделять.

  2. Принимать уведомления от производителей, использующих опции из диапазона 128-223 и желающих документировать их использование. Опции переводятся IANA в состояние Tentatively Assigned.

  3. Изменение статуса опций Unavailable на Available по истечении 6 с момента публикации этого RFC для распределения в соответствии с [RFC2939].

  4. Смена статуса Tentatively-Assigned на Unavailable по истечении 18 месяцев с момент публикации этого RFC и позднее (пока существует статус Tentatively-Assigned), если нет действующего документа Internet-Draft по использованию опции.

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

Большое спасибо Ralph Droms и Ted Lemon за их вклад и ранние работы по различным вариантам решения задачи.

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

8.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2131] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, March 1997.

[RFC2939] Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types”, BCP 43, RFC 2939, September 2000.

8.2. Дополнительная литература

[RFC3046] Patrick, M., “DHCP Relay Agent Information Option”, RFC 3046, January 2001.

[RFC3679] Droms, R., “Unused Dynamic Host Configuration Protocol (DHCP) Option Codes”, RFC 3679, January 2004.

Адрес автора

Bernard Volz

Cisco Systems, Inc.

1414 Massachusetts Ave.

Boxborough, MA 01719

USA

Phone: +1 978 936 0382

EMail: volz@cisco.com



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


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


nmalykh@gmail.com 


Полное заявление авторских прав


Copyright (C) The Internet Society (2004).


К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.


Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.


Интеллектуальная собственность


IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.


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


IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org. 


Подтверждение


Финансирование функций RFC Editor обеспеченоInternet Society.






1Dynamic Host Configuration Protocol version 4 – протокол динамической настройки конфигурации хоста, версия 4.



 											


		
						

							Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.