Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
RFC 2939 устанавливает процедуру определения новых кодов опций и типов сообщений DHCP. Публичные коды назначаются IANA только при публикации соответствующей спецификации как RFC, одобренной на основе консенсуса IETF. Спецификации проходят рассмотрение IESG и рабочей группой DHC, если она существует, либо IETF; до назначения кода новые элементы не следует включать в продукты или другие спецификации. Коды 128–254 предназначены для частного использования и не должны (MUST NOT) использоваться в публично распространяемых реализациях DHCP.
Network Working Group R. Droms
Request for Comments: 2939 Bucknell University
BCP: 43 September 2000
Obsoletes: 2489
Category: Best Current Practice
Процедуры и руководящие указания IANA по определению
новых опций и типов сообщений DHCP
Статус этого меморандума
Этот документ определяет лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2000). All Rights Reserved.
Аннотация
Dynamic Host Configuration Protocol (DHCP) предоставляет механизм
передачи конфигурационной информации хостам в сети Transmission
Control Protocol/Internet Protocol (TCP/IP). Конфигурационные
параметры и другая управляющая информация передаются в помеченных
элементах данных, хранящихся в поле 'options' сообщения DHCP.
Сами элементы данных также называются «опциями».
Сообщения протокола DHCP идентифицируются опцией 'DHCP Message Type'
(код опции 51). Каждый тип сообщения определяется значением данных,
передаваемым в опции 'DHCP Message Type'.
Новые опции и типы сообщений DHCP могут определяться после публикации
спецификации DHCP для удовлетворения требований к передаче новых
конфигурационных параметров либо для поддержки новой семантики
протокола. Этот документ описывает процедуру определения новых опций
и типов сообщений DHCP.
1. Введение
Dynamic Host Configuration Protocol (DHCP) [1] предоставляет механизм
передачи конфигурационной информации хостам в сети TCP/IP.
Конфигурационные параметры и другая управляющая информация передаются
в помеченных элементах данных, хранящихся в поле 'options' сообщения
DHCP. Сами элементы данных также называются «опциями» [2].
Сообщения протокола DHCP идентифицируются опцией 'DHCP Message Type'
(код опции 51). Каждый тип сообщения определяется значением данных,
передаваемым в опции 'DHCP Message Type'.
Этот документ описывает процедуру определения новых опций и типов
сообщений DHCP. Эта процедура гарантирует, что:
* выделение номеров новых опций и номеров типов сообщений
координируется единым органом;
* новые опции и типы сообщений проверяются на техническую корректность
и уместность; и
* документация для новых опций и типов сообщений является полной и
опубликована.
Как указано в «Guidelines for Writing an IANA Considerations Section
in RFCs» (см. ссылки), IANA действует как центральный орган по
назначению номеров, таких как коды опций DHCP и типов сообщений.
Новая процедура, изложенная в этом документе, предоставит IANA
указания по назначению кодов новых опций и типов сообщений.
Этот документ обновляет и заменяет RFC 2489.
2. Обзор и предпосылки
Этот документ определяет процедуры для задания новых кодов опций и
типов сообщений.
2.1 Новые коды опций DHCP
Описанная в этом документе процедура изменяет и уточняет процедуру
определения новых опций в RFC 2131 [2]. Основное изменение касается
момента, когда новой опции DHCP присваивается номер опции. В процедуре,
описанной в этом документе, номер опции не присваивается, пока
спецификация опции не будет готова к публикации в качестве RFC.
После публикации RFC 2132 пространство номеров опций для публично
определённых опций DHCP (1–127) почти исчерпано. За многими
определёнными номерами опций не последовали Internet Drafts,
представленные в DHC WG. Со стороны DHC WG отсутствовали конкретные
указания IANA относительно назначения номеров опций DHCP.
Процедура, определённая в RFC 2132, не устанавливает ясно, что новые
опции должны по отдельности проверяться на техническую корректность,
уместность и полноту документации. RFC 2132 также не требует, чтобы
новые опции представлялись IESG для проверки, а автор спецификации
опции отвечал за доведение новых опций до сведения IESG. Наконец,
RFC 2132 не разъясняет, что вновь определённые опции не должны
включаться в продукты, включаться в другие спецификации либо иным
образом использоваться до публикации спецификации опции в качестве
RFC.
В дальнейшем новые коды опций DHCP будут назначаться по консенсусу
IETF. Новые опции DHCP будут документироваться в RFC, одобренных IESG,
а коды для этих опций будут назначаться в момент публикации
соответствующих RFC. Как правило, IESG будет запрашивать мнение о
предполагаемых назначениях у подходящих источников (например, у
соответствующей рабочей группы, если она существует). Группы связанных
опций могут объединяться в единую спецификацию и проверяться IESG как
совокупность. До назначения кода опции неуместно включать новые опции
в продукты, включать спецификацию в другие документы либо иным образом
использовать новые опции.
Пространство номеров опций DHCP (1–254) разделено на две части. Коды
опций, специфичные для сайта [2] (128–254), определены как «Private
Use» и не требуют проверки DHC WG. Коды опций, специфичные для сайта
(128–254), НЕ ДОЛЖНЫ (MUST NOT) определяться для использования в
каких-либо публично распространяемых реализациях сервера DHCP, клиента
или ретрансляционного агента. Эти коды опций явно зарезервированы для
частного определения и использования в пределах сайта или организации.
Публичные коды опций (0–127, 255) определены как «Specification
Required», и новые опции должны проверяться до назначения IANA номера
опции. Подробности процесса проверки приведены в следующем разделе
этого документа.
2.2 Новые типы сообщений DHCP
RFC 2131 не определяет какого-либо механизма для задания новых типов
сообщений DHCP. В дальнейшем новые типы сообщений DHCP будут
документироваться в RFC, одобренных IESG, а коды этих новых типов
сообщений будут назначаться в момент публикации соответствующих RFC.
Как правило, IESG будет запрашивать мнение о новых типах сообщений у
подходящих источников (например, у соответствующей рабочей группы,
если она существует). До назначения кода типа сообщения неуместно
включать новые типы сообщений в продукты, включать спецификацию в
другие документы либо иным образом использовать новые типы сообщений.
3. Процедура
Для получения одобрения опции и публикации спецификации опции в
качестве RFC автор новой опции или типа сообщения DHCP выполнит
следующие шаги:
1. Автор разрабатывает новую опцию или тип сообщения.
2. Автор документирует новую опцию или тип сообщения как Internet
Draft, оставляя код опции или код типа сообщения как «To Be
Determined» (TBD).
Требование документировать новую опцию или тип сообщения как
Internet Draft продиктовано практической целесообразностью.
Теоретически новую опцию или тип сообщения можно было бы
документировать на обороте конверта для представления; практически
спецификация в конечном итоге станет Internet Draft в рамках
процесса проверки.
3. Автор представляет Internet Draft на проверку IESG.
Предпочтительно, чтобы автор представил Internet Draft в DHC
Working Group, но автор может предпочесть представить Internet
Draft непосредственно IESG.
Обратите внимание, что простая публикация новой опции или типа
сообщения в качестве Internet Draft не доводит автоматически опцию
до сведения IESG. Автор новой опции или типа сообщения должен явно
направить запрос о рассмотрении новой опции в DHC WG или IESG.
4. Спецификация новой опции или типа сообщения проверяется IESG.
Спецификация проверяется DHC WG (если она существует) или IETF.
Если опция или тип сообщения принимается для включения в
спецификацию DHCP, спецификация опции или типа сообщения публикуется
в качестве RFC. Она может быть опубликована как RFC из ветви
стандартов либо как RFC вне ветви стандартов.
5. В момент публикации в качестве RFC IANA назначает новой опции или
типу сообщения код опции DHCP или код типа сообщения.
4. Ссылки
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
RFC 2142, November 1997.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489,
January 1999.
5. Изменения по сравнению с RFC 2489
Этот документ расширяет процедуры определения новых опций DHCP,
определённые в RFC 2489 [5], включая в них определение новых типов
сообщений DHCP. Формулировка, резервирующая коды опций, специфичные для
сайта, усилена, чтобы подчеркнуть требование: коды опций, специфичные
для сайта, не должны кодироваться в публично распространяемых
реализациях DHCP.
6. Вопросы безопасности
Информация, создающая или обновляющая назначение кода опции или кода
типа сообщения, должна быть аутентифицирована.
Анализ вопросов безопасности требуется для всех вновь определяемых
опций DHCP или типов сообщений. Описание вопросов безопасности в
спецификации новых опций или типов сообщений должно быть настолько
точным, насколько это возможно. Спецификация новой опции или типа
сообщения может ссылаться на раздел "Security Considerations" в
спецификации DHCP [1]; например (из "NetWare/IP Domain Name and
Information" [3]):
DHCP в настоящее время не предоставляет механизмов аутентификации
или безопасности. Возможные уязвимости для атак обсуждаются в
разделе 7 спецификации протокола DHCP [RFC 2131].
7. Соображения IANA
RFC 2132 и RFC 2489 предоставляли IANA указания о процедуре, которой
она должна следовать при назначении номеров опций для новых опций DHCP
или типов сообщений. Этот документ обновляет и заменяет эти указания.
В частности, IANA предлагается назначать коды опций DHCP или коды типов
сообщений только для опций или типов сообщений, одобренных для
публикации в качестве RFC; то есть документов, одобренных посредством
«консенсуса IETF», как он определён в RFC 2434 [4].
8. Адрес автора
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (570) 524-1145
EMail: droms@bucknell.edu
9. Полное заявление об авторском праве
Copyright (C) The Internet Society (2000). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, комментирующие или иным образом
объясняющие его либо содействующие его реализации, могут подготавливаться,
копироваться, публиковаться и распространяться полностью или частично,
без ограничений любого рода, при условии, что приведённое выше
уведомление об авторском праве и этот абзац включены во все такие копии
и производные работы. Однако сам этот документ не может изменяться
каким-либо образом, например путём удаления уведомления об авторском
праве или ссылок на Internet Society либо другие интернет-организации,
за исключением случаев, когда это необходимо для разработки стандартов
Интернета, в которых должны соблюдаться процедуры в отношении авторских
прав, определённые процессом Internet Standards, либо когда это
требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются по
принципу «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK
FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, ЛИБО ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.
Network Working Group R. Droms
Request for Comments: 2939 Bucknell University
BCP: 43 September 2000
Obsoletes: 2489
Category: Best Current Practice
Procedures and IANA Guidelines for Definition of
New DHCP Options and Message Types
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a Transmission
Control Protocol/Internet Protocol (TCP/IP) network. Configuration
parameters and other control information are carried in tagged data
items that are stored in the 'options' field of the DHCP message.
The data items themselves are also called "options".
DHCP protocol messages are identified by the 'DHCP Message Type'
option (option code 51). Each message type is defined by the data
value carried in the 'DHCP Message Type' option.
New DHCP options and message types may be defined after the
publication of the DHCP specification to accommodate requirements for
conveyance of new configuration parameters or to accommodate new
protocol semantics. This document describes the procedure for
defining new DHCP options and message types.
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. Configuration parameters and other control information are
carried in tagged data items that are stored in the 'options' field
of the DHCP message. The data items themselves are also called
"options" [2].
Droms Best Current Practice [Page 1]
RFC 2939 Procedures for New DHCP Options September 2000
DHCP protocol messages are identified by the 'DHCP Message Type'
option (option code 51). Each message type is defined by the data
value carried in the 'DHCP Message Type' option.
This document describes the procedure for defining new DHCP options
and message types. The procedure will guarantee that:
* allocation of new option numbers and message type numbers is
coordinated from a single authority,
* new options and message types are reviewed for technical
correctness and appropriateness, and
* documentation for new options and message types is complete and
published.
As indicated in, "Guidelines for Writing an IANA Considerations
Section in RFCs", (see references), IANA acts as a central authority
for assignment of numbers such as DHCP option and message type codes.
The new procedure outlined in this document will provide guidance to
IANA in the assignment of new option and message type codes.
This document updates and replaces RFC 2489.
2. Overview and background
This document specifies procedures for defining new option codes and
message types.
2.1 New DHCP option codes
The procedure described in this document modifies and clarifies the
procedure for defining new options in RFC 2131 [2]. The primary
modification is to the time at which a new DHCP option is assigned an
option number. In the procedure described in this document, the
option number is not assigned until specification for the option is
about to be published as an RFC.
Since the publication of RFC 2132, the option number space for
publicly defined DHCP options (1-127) has almost been exhausted.
Many of the defined option numbers have not been followed up with
Internet Drafts submitted to the DHC WG. There has been a lack of
specific guidance to IANA from the DHC WG as to the assignment of
DHCP option numbers.
The procedure as specified in RFC 2132 does not clearly state that
new options are to be reviewed individually for technical
correctness, appropriateness and complete documentation. RFC 2132
also does not require that new options are to be submitted to the
IESG for review, and that the author of the option specification is
Droms Best Current Practice [Page 2]
RFC 2939 Procedures for New DHCP Options September 2000
responsible for bringing new options to the attention of the IESG.
Finally, RFC 2132 does not make clear that newly defined options are
not to be incorporated into products, included in other
specifications or otherwise used until the specification for the
option is published as an RFC.
In the future, new DHCP option codes will be assigned by IETF
consensus. New DHCP options will be documented in RFCs approved by
the IESG, and the codes for those options will be assigned at the
time the relevant RFCs are published. Typically, the IESG will seek
input on prospective assignments from appropriate sources (e.g., a
relevant Working Group if one exists). Groups of related options may
be combined into a single specification and reviewed as a set by the
IESG. Prior to assignment of an option code, it is not appropriate
to incorporate new options into products, include the specification
in other documents or otherwise make use of the new options.
The DHCP option number space (1-254) is split into two parts. The
site-specific option codes [2] (128-254) are defined as "Private Use"
and require no review by the DHC WG. Site-specific options codes
(128-254) MUST NOT be defined for use by any publicly distributed
DHCP server, client or relay agent implementations. These option
codes are explicitly reserved for private definition and use within a
site or an organization.
The public option codes (0-127, 255) are defined as "Specification
Required" and new options must be reviewed prior to assignment of an
option number by IANA. The details of the review process are given
in the following section of this document.
2.2 New DHCP message types
RFC 2131 does not specify any mechanism for defining new DHCP message
types. In the future, new DHCP message types will be documented in
RFCs approved by the IESG, and the codes for these new message types
will be assigned at the time the relevant RFCs are published.
Typically, the IESG will seek input on new message types from
appropriate sources (e.g., a relevant Working Group if one exists).
Prior to assignment of a message type code, it is not appropriate to
incorporate new message types into products, include the
specification in other documents or otherwise make use of the new
message types.
Droms Best Current Practice [Page 3]
RFC 2939 Procedures for New DHCP Options September 2000
3. Procedure
The author of a new DHCP option or message type will follow these
steps to obtain approval for the option and publication of the
specification of the option as an RFC:
1. The author devises the new option or message type.
2. The author documents the new option or message type, leaving the
option code or message type code as "To Be Determined" (TBD), as
an Internet Draft.
The requirement that the new option or message type be documented
as an Internet Draft is a matter of expediency. In theory, the
new option or message type could be documented on the back of an
envelope for submission; as a practical matter, the specification
will eventually become an Internet Draft as part of the review
process.
3. The author submits the Internet Draft for review by the IESG.
Preferably, the author will submit the Internet Draft to the DHC
Working Group, but the author may choose to submit the Internet
Draft directly to the IESG.
Note that simply publishing the new option or message type as an
Internet Draft does not automatically bring the option to the
attention of the IESG. The author of the new option or message
type must explicitly forward a request for action on the new
option to the DHC WG or the IESG.
4. The specification of the new option or message type is reviewed by
the IESG. The specification is reviewed by the DHC WG (if it
exists) or by the IETF. If the option or message type is accepted
for inclusion in the DHCP specification, the specification of the
option or message type is published as an RFC. It may be
published as either a standards-track or a non-standards-track
RFC.
5. At the time of publication as an RFC, IANA assigns a DHCP option
code or message type code to the new option or message type.
4. References
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Droms Best Current Practice [Page 4]
RFC 2939 Procedures for New DHCP Options September 2000
[3] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information",
RFC 2142, November 1997.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Droms, R., "Procedure for Defining New DHCP Options", RFC 2489,
January 1999.
5. Changes from RFC 2489
This document extends the procedures for defining new DHCP options
specified in RFC 2489 [5] to include the definition of new DHCP
message types. The language reserving site-specific option codes has
been strengthened to emphasize the requirement that site-specific
option codes must not be encoded in publicly distributed DHCP
implementations.
6. Security Considerations
Information that creates or updates an option code or message type
code assignment needs to be authenticated.
An analysis of security issues is required for all newly defined DHCP
options or message types. The description of security issues in the
specification of new options or message types must be as accurate as
possible. The specification for a new option or message type may
reference the "Security Considerations" section in the DHCP
specification [1]; e.g., (from "NetWare/IP Domain Name and
Information" [3]):
DHCP currently provides no authentication or security mechanisms.
Potential exposures to attack are discussed in section 7 of the
DHCP protocol specification [RFC 2131].
7. IANA Considerations
RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure
it should follow when assigning option numbers for new DHCP options
or message types. This document updates and replaces those
instructions. In particular, IANA is requested to assign DHCP option
codes or message type codes only for options or message types that
have been approved for publication as RFCs; i.e., documents that have
been approved through "IETF consensus" as defined in RFC 2434 [4].
Droms Best Current Practice [Page 5]
RFC 2939 Procedures for New DHCP Options September 2000
8. Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (570) 524-1145
EMail: droms@bucknell.edu
Droms Best Current Practice [Page 6]
RFC 2939 Procedures for New DHCP Options September 2000
9. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Droms Best Current Practice [Page 7]