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

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).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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


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